Upload
yuri-argamonte-huamani
View
26
Download
1
Embed Size (px)
DESCRIPTION
informe final de desarrollo de tesis
Citation preview
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS
SISTEMA DE COMUNICACIÓN MÓVIL A-GPS EN
EL PROCESO DE ATENCIÓN DE LLAMADAS DE
EMERGENCIAS EN LA COMISARÍA DE SANTA
LUZMILA EN EL DISTRITO DE COMAS
TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE
INGENIERO DE SISTEMAS
AUTOR:
Br. LÓPEZ CHÁVEZ, CARLOMAGNO
ASESOR:
Ing. BRAVO BALDEÓN, PERCY RUBÉN
LIMA – PERÚ
2013
ii
DEDICATORIA
Dedico esta tesis a mi familia,
por ser quienes me apoyaron
incondicionalmente, en el
desarrollo de esta investigación,
por su amor infinito.
iii
AGRADECIMIENTO
La presente tesis, para su desarrollo ha
requerido de un arduo trabajo, sin duda valió la
pena el sacrificio y haber superado las
dificultades y limitaciones. Agradezco en
primer lugar a mis padres y mi familia por su
apoyo perenne. Además a mis compañeros de
estudio con quienes compartí muchas
experiencias en la casa de estudios de la
Universidad César Vallejo. De igual manera
agradezco a mis asesores, Ing. Percy Ruben
Bravo Baldeón y Mg. Mónica Díaz Reátegui,
quienes me guiaron en la elaboración de la
presente investigación. Además a mis amigos
Ing. Jara Mendoza Omar e Ing. Morillo Cuya
Sergio por su apoyo y consejo para el
desarrollo de esta tesis.
iv
RESUMEN
La investigación comprendió el análisis, desarrollo, implementación y evaluación de un
sistema de comunicación Móvil A-GPS bajo las plataformas Móvil y Web para el
proceso de atención de llamadas de emergencias en la comisaría de Santa Luzmila en el
distrito de Comas. Este estudio incluye la problemática, el tipo de investigación para
esta tesis se determinó que es experimental y el tipo de estudio aplicada, empleando un
diseño de investigación pre-experimental. El objetivo principal de la tesis fue
determinar la influencia de un sistema de comunicación Móvil A-GPS para la atención
de llamadas de emergencias en la comisaría de Santa Luzmila en el distrito de Comas.
Se estableció una población de estudio de 63 registros de llamadas de alertas de la
población durante 11 días en el mes de Octubre del 2012 en la comisaría de Santa
Luzmila. La muestra obtenida fue de 48 registros de llamadas de emergencias y el
muestreo se estableció por estratos. Para la recolección de datos y análisis se utilizó
instrumentos como las fichas de observación y el cronómetro, la técnica que se utilizó
fue la observación. Para la validación de la hipótesis se utilizó el método estadístico de
la distribución normal Z, ya que esta prueba es una distribución de probabilidad que
surge del problema de estimar la media de una población normalmente distribuida y que
a su vez el tamaño de la muestra es mayor a 30.
Se planteó el desarrollo de un sistema de comunicación Móvil A-GPS, para la mejora
del proceso de atención de llamadas de emergencias, se utilizó para su diseño la
metodología Scrum por ser una metodología ágil y por la aprobación de los expertos, el
lenguaje de programación utilizado es Android para la aplicación móvil y PHP para la
aplicación web. El sistema gestor de base de datos fue SQL Server 2008.
Palabras Claves: Sistema Comunicación Móvil – Plataforma Android – Plataforma
Web – Proceso de atención de llamadas de emergencia.
v
ABSTRACT
The research included the analysis, development, implementation and evaluation of a
mobile communication system A-GPS on Mobile and Web platforms for the care
process emergency calls in the police station of Saint Luzmila in the district of Comas.
This study includes the problems, the type of research for this thesis was determined to
be experimental and applied type of study, a research design using pre-experimental.
The main objective of the thesis was to determine the influence of a mobile
communication system A-GPS for emergency care call in the police station of Saint
Luzmila in the district of Comas. It established a study population of 63 call records
alerts the population for 11 days in the month of October 2012 at the station of St.
Luzmila. The sample obtained was 48 emergency call records and was established by
sampling strata. For data collection and analysis instruments are used as observation
forms and stopwatch, the technique used was observation. To validate the hypothesis we
used statistical method Z normal distribution, since this test is a probability distribution
that arises from the problem of estimating the mean of a normally distributed population
and in turn the size of the sample is over 30.
It was suggested to develop a communication system Mobile A-GPS, to improve the
care process emergency calls, was used to design the methodology Scrum for being an
agile methodology and the adoption of the experts, the language of Android
programming is used for the mobile application and PHP for the Web application. The
system manager database was SQL Server 2008.
Keywords: Mobile Communication System - Android Platform - Web Platform -
Process emergency calls attention.
vi
ÍNDICE GENERAL
PORTADA…………………………….…………………………………………………. i
DEDICATORIA………………………………………………………………………..... ii
AGRADECIMIENTO……………………………………………………….……….….. iii
RESUMEN……………………………………………………………………………..... iv
ABSTRACT……………………………………………………………………………… v
ÍNDICE GENERAL……………………………………………………………………... vi
ÍNDICE DE FIGURAS………………………………………………………………….. viii
ÍNDICE DE GRÁFICAS.………………………………………………...…………….… xi
ÍNDICE DE TABLAS.…………………………………………………………………… xii
ÍNDICE DE FÓRMULAS……………………………………………………………....... xiii
ÍNDICE DE ANEXOS.……………………………………………………….…….......... xiv
INTRODUCCIÓN………………………………………………………………………... xv
I. PROBLEMA DE INVESTIGACIÓN………………………………..…….................... 1
1.1. Planteamiento del Problema……………………………………..…….................. 1
1.2. Formulación del problema...………..………………………………..………..….. 5
1.2.1. Problema General………………………………………………………..… 5
1.2.2. Problemas Específicos…………………………………………………..…. 5
1.3. Justificación……………………………………………………..………………... 5
1.3.1. Justificación Tecnológica………………………………………………..… 5
1.3.2. Justificación Operativa…………………………………………………..… 6
1.3.3. Justificación Institucional………………………………………………..… 6
1.4. Limitación………………………………………………..……………………….. 6
1.5. Antecedentes……………………………………………………………………………… 7
1.5.1. Antecedentes Internacionales……………………………………….…..…. 7
1.5.2. Antecedentes Nacionales……..………………………………….……..….. 8
1.6. Objetivos…………………………………………………………………………. 9
1.6.1. General………………………………………………………………........... 9
1.6.2. Específicos…………………………………………………......................... 9
II. MARCO TEÓRICO………..………………………………………………………….. 10
2.1. Marco teórico……………....………………………………………………........... 10
2.2. Marco conceptual...……………………………………………………………..... 35
III. MARCO METODOLÓGICO…………………………………………………........... 36
3.1. Hipótesis………………………………………………………………….……..... 36
3.1.1. Hipótesis General…………………………………………………………... 36
3.1.2. Hipótesis Específicas………………………………………….…………… 36
3.2. Variables…………………………………………………………….…………..... 36
3.2.1. Definición Conceptual…...………………………………………….……... 36
3.2.2. Definición Operacional…………………………………..…….………….. 36
3.2.3. Indicadores..………………….……………………………………….......... 39
3.3. Metodología………………………………………………………………………. 40
3.3.1. Tipo de Estudio ………..…………………………………………….…….. 40
3.3.2. Diseño de Investigación…………………………………………….…….... 40
3.3.3. Desarrollo de la Metodología ……………………………………………... 41
3.4. Población, muestra y muestreo…………………………………………….......... 97
3.4.1. Población…………………………………………………………………... 97
3.4.2. Muestra ……………………....................................................................... 97
3.4.3. Muestreo…………………………………………………………………… 98
3.5. Métodos de Investigación……………...………………………………………..... 98
vii
3.6. Técnicas e instrumentos de recolección de datos………………….……………... 98
3.6.1. Técnicas…………………………………………………………………..... 99
3.6.2. Instrumentos………………………………………………………………... 99
3.6.3. Fuentes……………………………………………………………….…….. 100
3.7. Métodos y técnicas de procesamiento de análisis de datos……………………...... 100
IV. RESULTADOS………………………………………………………………………. 104
4.1. Descripción……………………………………………………............................. 104
4.1.1. Análisis de Confiabilidad…………………………………………………... 104
4.1.2. Prueba de Normalidad……………………………………………………... 104
4.1.3. Prueba de Hipótesis…………………………………………….………….. 105
4.2. Discusión………………………………………………………………………….. 110
V. CONCLUSIONES Y SUGERENCIAS………………………………………………. 112
5.1. Conclusiones.…………………………………………………………….……….. 112
5.2. Sugerencias………………………………………………………………….…..... 112
REFERENCIAS BIBLIOGRÁFICAS…………………………………………………… 113
ANEXOS…………………………………………………………………………….…… 116
viii
ÍNDICE DE FIGURAS
Figura N° 1 - Proceso de atención de llamadas de la central de emergencias 105............... 2
Figura N° 2 - Visión general de la asistencia A-GPS…………………………………….... 10
Figura N° 3 - Arquitectura Android………………………………………...……………… 13
Figura N° 4 - Funcionamiento Plataforma Android con acceso a Web Service…………... 14
Figura N° 5 - Ilustración cómo funciona la metodología Scrum………..…….…………... 20
Figura N° 6 - Fases de Kanban Clásico……………………………………………………. 26
Figura N° 7 - Fases Primarias del Modelo…………………………………………...…..... 26
Figura N° 8 - Formato de Tareas……………………………………………………........... 27
Figura N° 9 - Formato de Story Boards……………………………………………………. 28
Figura N° 10 - Formato de Pruebas de unidad…………………………………………….. 29
Figura N° 11 - Fases de Trabajo en Progreso…………………………………………....... 30
Figura N° 12 - Modelo culminado Kanban………………………………………………… 31
Figura N° 13 - Estado inicial de la pizarra – Primer Sprint.…………………...………..... 45
Figura N° 14 - Descripción Detallada de la Historia: Registro de Usuarios………...……. 46
Figura N° 15 - Diseño de tarea 1.1 – Validación de Datos…………………………...……. 47
Figura N° 16 - Caso de Uso - Validación de Datos………………………………………... 48
Figura N° 17 - Pruebas de Unidad – Tarea 1.1…………………………………………….. 48
Figura N° 18 - Interfaz concluida de la tarea 1.1 – Validación de datos…………………... 49
Figura N° 19 - Diseño de tarea 1.2 – Términos y condiciones del uso de la aplicación…... 50
Figura N° 20 - Caso de uso - Términos y condiciones del uso de la aplicación…………… 50
Figura N° 21 - Pruebas de Unidad – Tarea 1.2…………………………………………….. 51
Figura N° 22 - Pizarrón - Fases de Diseño y Pruebas…………………………………….... 51
Figura N° 23 - Interfaz concluida de la tarea 1.2 - Términos y condiciones del uso de la
aplicación……………………………………………………………………
52
Figura N° 24 - Descripción detallada de la Historia: Confirmación de Registro………….. 52
Figura N° 25 - Diseño de tarea 2.1 – Activación de Cuenta de Usuario…………………... 53
Figura N° 26 - Caso de uso - Activación de Cuenta de Usuario…………………………... 53
Figura N° 27 – Entidades utilizadas en el Primer Sprint – Modelo Lógico……………….. 54
Figura N° 28 – Entidades utilizadas en el Primer Sprint – Modelo Físico………………… 54
Figura N° 29 - Pruebas de Unidad – Tarea 2.1…………………………………………….. 55
Figura N° 30 - Interfaz concluida de la tarea 2.1 – Activación de Cuenta de Usuario….… 55
Figura N° 31 - Descripción detallada de la Historia: Validación de acceso……………….. 56
Figura N° 32 - Diseño de tarea 4.1 – Inicio de sesión vía móvil…………………………... 57
Figura N° 33 - Diseño de tarea 4.2 – Inicio de sesión vía web…………………………….. 57
Figura N° 34 - Caso de uso para las tareas 4.1 y 4.2………………………………………. 58
Figura N° 35 - Prueba de Unidad – Tarea 4.1……………………………………………… 58
Figura N° 36 - Prueba de Unidad – Tarea 4.2…………………………………………….... 59
Figura N° 37 - Interfaz concluida de la tarea 4.1 – Inicio de sesión vía Móvil……………. 59
Figura N° 38 - Interfaz concluida de la tarea 4.2 – Inicio de sesión vía web……………… 60
Figura N° 39 - Descripción detallada de la Historia: Ubicación del lugar de incidencia…. 60
Figura N° 40 - Diseño de tarea 5.1 – Ver ubicación actual………………………………... 61
Figura N° 41 - Caso de uso - Ver ubicación actual…………………………………….….. 62
Figura N° 42 – Entidades utilizadas en el Segundo Sprint – Modelo Lógico……….…….. 62
Figura N° 43 – Entidades utilizadas en el Segundo Sprint – Modelo Lógico……….…….. 63
Figura N° 44 - Prueba de Unidad – Tarea 5.1…………………………………………….... 63
Figura N° 45 - Interfaz concluida de la tarea 5.1 – Ver ubicación actual………………….. 64
Figura N° 46 - Estado final del segundo Sprint (Integración de Tareas)………………….. 64
ix
Figura N° 47 - Descripción detallada de la Historia: Tipos de alertas…………………….. 65
Figura N° 48 - Diseño de tarea 6.1 – Ver tipos de alertas…………………………………. 66
Figura N° 49 - Caso de uso - Ver tipos de alertas…………………………………………. 66
Figura N° 50 - Prueba de Unidad – Tarea 6.1……………………………………………... 67
Figura N° 51 - Interfaz concluida de la tarea 6.1 – Tipos de Alertas………………………. 67
Figura N° 52 - Descripción detallada de la Historia: Envío de alertas…………………….. 68
Figura N° 53 - Diseño de la tarea 7.1 – Enviar Alerta……………………………………... 69
Figura N° 54 - Caso de uso - Enviar alerta……………………………………………….... 69
Figura N° 55 – Entidades utilizadas en el Tercer Sprint – Modelo Lógico………….……. 70
Figura N° 56 – Entidades utilizadas en el Primer Sprint – Modelo Físico………..………. 70
Figura N° 57 - Prueba de Unidad – Tarea 7.1……………………………………….…….. 70
Figura N° 58 - Interfaz concluida de la tarea 7.1 – Enviar Alertas………………….…….. 71
Figura N° 59 - Descripción detallada de la Historia: Atención de Alertas………………... 71
Figura N° 60 - Diseño de la tarea 9.1 - Listar alertas registradas………………………….. 72
Figura N° 61 - Caso de uso - Listar Alertas Registradas…………………………………... 73
Figura N° 62 - Prueba de Unidad – Tarea 9.1……………………………………………... 73
Figura N° 63 - Interfaz concluida de la tarea 9.1 – Listar alertas registradas…………….... 74
Figura N° 64 - Diseño de la tarea 9.2 – Actualizar estado de alertas (Plataforma móvil-
web)…………………………………………………………………….…..
75
Figura N° 65 - Caso de uso - Actualizar estado de alertas (Plataforma móvil)………….... 75
Figura N° 66 - Caso de uso - Actualizar estado de alertas (Plataforma web)……………... 76
Figura N° 67 – Entidades utilizadas en el Cuarto Sprint – Modelo Lógico………….….… 76
Figura N° 68 – Entidades utilizadas en el Primer Sprint – Modelo Lógico……………..… 77
Figura N° 69 - Prueba de Unidad – Tarea 9.2……………………………………………... 77
Figura N° 70 - Interfaz concluida de la tarea 9.2 – Actualizar estado de alerta
(Plataforma móvil)………………………………………….........................
78
Figura N° 71 - Interfaz concluida de la tarea 9.2 – Actualizar estado de alerta
(Plataforma web)…………………………………………………………....
79
Figura N° 72 - Solicitud de cambio y descripción del cambio Enviar alertas…………….. 80
Figura N° 73 – Cambios realizados en el Modelo Lógico del Cuarto Sprint……..………. 80
Figura N° 74 – Cambios realizados en el Modelo Físico del Cuarto Sprint….…..……..… 81
Figura N° 75 - Interfaz concluida de la Solicitud de Cambio……………………….……... 81
Figura N° 76 - Pizarrón, Estado final del cuarto Sprint……………………………….….... 82
Figura N° 77 - Descripción detallada de la Historia: Reporte de Alertas………………..… 83
Figura N° 78 - Diseño de la tarea 12.1 – Reporte de alertas (Plataforma web)………….... 84
Figura N° 79 - Caso de uso - Reporte de Alertas (Plataforma web)……………………….. 84
Figura N° 80 - Solicitud de cambio y descripción detallada del cambio Reporte de
Alertas.……………………………………………………………………...
85
Figura N° 81 - Prueba de Unidad – Tarea 12.1…………………………………………….. 86
Figura N° 82 - Interfaz concluida de la tarea 12.1 – Reporte de alerta (Plataforma web)... 86
Figura N° 83 - Descripción detallada de la Historia: Enviar mensaje al celular…………... 87
Figura N° 84 - Diseño de la tarea 8.1 - Reportar alerta a Policías (Plataforma web)……... 88
Figura N° 85 - Diseño de la tarea 8.2 - Enviar mensaje de atención al usuario
(Plataforma web)…………………………………………...……………….
88
Figura N° 86 - Caso de Uso - Reportar alerta a Policías y Enviar mensaje al usuario……. 89
Figura N° 87 - Prueba de Unidad: Tareas 8.1 y 8.2……………………………………….. 89
Figura N° 88 - Interfaz concluida de la tarea 8.1 – Reportar alerta a Policías (Plataforma
web)…………………………………………………………………………
90
x
Figura N° 89 - Interfaz concluida de la tarea 8.2 – Enviar mensaje de atención al usuario
(Plataforma web)……………………………………………………………
90
Figura N° 90 - Descripción detallada de la Historia: Registro de Personal Policial………. 91
Figura N° 91 - Diseño de la tarea 3.1 – Registrar efectivo Policial……………………..…. 91
Figura N° 92 - Caso de Uso – Registrar efectivo Policial………………………………..... 92
Figura N° 93 - Prueba de Unidad: Tarea 3.1…………………………………………….… 92
Figura N° 94 - Interfaz concluida de la tarea 3.1 – Registrar efectivo Policial
(Plataforma web)…….……………………………………………………..
93
Figura N° 95 - Descripción detallada de la Historia: Enviar mensaje al celular…………... 93
Figura N° 96 - Diseño de la tarea 10.1 – Recuperar Contraseña…………………………... 94
Figura N° 97 - Caso de Uso – Recuperar Contraseña……………………………………… 94
Figura N° 98 - Prueba de Unidad: Tarea 10.1……………………………………………... 95
Figura N° 99 - Interfaz concluida de la tarea 10.1 – Recuperar contraseña (Plataforma
web)…………………………………………………………………………
95
Figura N° 100 - Pizarrón, fase final de la pila del Producto (Backlog)……………………. 96
xi
ÍNDICE DE GRÁFICOS
Gráfica N° 1 - Tiempo promedio de respuesta de la Policía……………………………... 3
Gráfica N° 2 - Porcentaje promedio de registro de alertas falsas……………………........ 4
Gráfica N° 3 - Tendencias de denuncias por delitos en el Perú………………………….. 16
Gráfica N° 4 - Burn Down Chart – Inicio Quinto Sprint…………………………………. 82
Gráfica N° 5 - Burn Down Chart al finalizar el ultimo Sprint……………………….…... 96
Gráfica N° 6 - Distribución Normal Z……………………………………………………. 103
Gráfica N° 7 - Tiempo promedio de respuesta de la Policía (Comparativa general)…..… 106
Gráfica N° 8 – Contrastes de Hipótesis (Tiempo promedio de respuesta de la Policía)…. 107
Gráfica N° 9 - Porcentaje promedio de registros de alertas falsas (Comparativa
general)………………………………………………………………….....
109
Gráfica N° 10 - Contrastes de Hipótesis (Porcentaje de registros de alertas falsas)……... 110
xii
ÍNDICE DE TABLAS
Tabla N° 1 Ventas de teléfonos inteligentes en todo el mundo a usuarios finales por l
Sistema Operativo en el 1T13 (Miles de Unidades)………………..……….
12
Tabla N° 2 Cuadro comparativo de Metodologías……………….…..…………………... 18
Tabla N° 3 Criterios de selección de Metodología……….………………………………. 19
Tabla N° 4 Formato de Historias de usuarios…………………………………………..... 21
Tabla N° 5 Formato de Release Plan…………………………………………………….. 24
Tabla N° 6 Formato de Descripción de Historia de Usuario……………………………... 27
Tabla N° 7 Lenguaje de Programación…………………………………………………… 32
Tabla N° 8 Criterio de selección del lenguaje de programación………………………..... 33
Tabla N° 9 Gestor de base de Datos……………………………………………………… 34
Tabla N° 10 Criterio de selección del gestor de Base de Datos………………………….. 35
Tabla N° 11 Operacionalización de Variables……………………………..……….…..... 38
Tabla N° 12 Indicadores………………………………………………………………….. 39
Tabla N° 13 Diseño de Estudio Pre Experimental……………………………………….. 41
Tabla N° 14 Grupo de Trabajo………………………………………………………….... 41
Tabla N° 15 Información de la Pila del Producto (Product Backlog)……………………. 43
Tabla N° 16 Release Plan (Sprint Backlog)…………………………………………….... 44
Tabla N° 17 Determinación de la Población……………………………………………... 97
Tabla N° 18 Técnicas e Instrumentos de recolección de datos…………………………... 100
Tabla N° 19 “Prueba Z”………………………………………………………………….. 100
Tabla N° 20 Condiciones de confiabilidad……………………………………………….. 104
Tabla N° 21 Prueba de Normalidad – Tiempo de respuesta de la Policía (Pre Test)….... 104
Tabla N° 22 Prueba de Normalidad – Tiempo de respuesta de la Policía (Post Test)..….. 104
Tabla N° 23 Prueba de Normalidad – Porcentaje de Registros de alertas falsas (Pre
Test)....…………..……………………………………………………….....
105
Tabla N° 24 Prueba de Normalidad – Porcentaje de Registros de alertas falsas (Post
Test)…………………..……………………………………………………..
105
Tabla N° 25 Cálculo de las medias (1)…………………………………………………… 106
Tabla N° 26 Prueba de Rangos con signo de Wilcoxon (1)…………………………….... 107
Tabla N° 27 Cálculo de las medias (2)………………………………………………….... 108
Tabla N° 28 Prueba de Rangos con signo de Wilcoxon (2)…………………………….... 109
xiii
ÍNDICE DE FÓRMULAS
Fórmula (2.1) - Medición del tiempo de respuesta de la Policía…………………............. 16
Fórmula (2.2) - Tiempo promedio de respuesta de la Policía……………………………… 17
Fórmula (2.3) - Porcentaje de Registros de alertas falsas………………………………….. 17
Fórmula (3.1) - Cálculo de la muestra……………………………………………………... 97
Fórmula (3.2) - Indicadores………………………………………………………………... 100
Fórmula (3.3) - Estadística de Prueba…………………………………………………...…. 102
Fórmula (3.4) - Promedio………………………………………………………………...… 102
Fórmula (3.5) - Varianza………………………………………………………………….... 103
Fórmula (3.6) - Desviación Estándar……………………………………………………..... 103
xiv
ÍNDICE DE ANEXOS
Anexo N° 1 Matriz de Consistencia……………..……………………………………….. 116
Anexo N° 2 Ficha de Observación………………..………………………........................ 117
Anexo N° 3 Entrevista al comisario………………..…………………………………….. 118
Anexo N° 4 Ficha de observación para determinar la Población……….………………... 120
Anexo N° 5 Ficha de Observación: Tiempo de respuesta de la Policía (Pre Test)…....…. 121
Anexo N° 6 Ficha de Observación: Porcentaje de registro de alertas falsas (Pre Test)….. 123
Anexo N° 7 Ficha de Observación: Tiempo de respuesta de la Policía (Post Test)…....... 124
Anexo N° 8 Ficha de Observación: Porcentaje de registro de alertas falsas(Post Test).... 126
Anexo N° 9 Tabla de criterios para la selección de metodología (1)…………………..... 127
Anexo N° 10 Tabla de criterios para la selección de metodología (2)…………………... 128
Anexo N° 11 Tabla de criterios para la selección de metodología (3)…………………... 129
Anexo N° 12 Tabla de criterios para la selección del lenguaje de programación (1)….... 130
Anexo N° 13 Tabla de criterios para la selección del lenguaje de programación (2)….... 131
Anexo N° 14 Tabla de criterios para la selección del lenguaje de programación (3)….... 132
Anexo N° 15 Criterios de evaluación de experto gestor de Base de Datos (1)……….…. 133
Anexo N° 16 Criterios de evaluación de experto gestor de Base de Datos (2)………….. 134
Anexo N° 17 Criterios de evaluación de experto gestor de Base de Datos (3)……….…. 135
Anexo N° 18 Tabla evaluación de experto fichas de observación (1)…………………... 136
Anexo N° 19 Tabla evaluación de experto fichas de observación (2)……………………. 137
Anexo N° 20 Tabla evaluación de experto fichas de observación (3)…………………... 138
Anexo N° 21 Cronograma de Desarrollo de la Aplicación……………………………..... 139
Anexo N° 22 Modelo Lógico…………………………………………………………….. 140
Anexo N° 23 Modelo Físico……………………………………………………………... 141
Anexo N° 24 Diagrama de Base de Datos – SQL Server………………………………… 142
Anexo N° 25 Carta de Conformidad de Finalización del Proyecto………………………. 143
Anexo N° 26 Registro de Llamadas de emergencias (1)…………………………………. 144
Anexo N° 27 Registro de Llamadas de emergencias (2)………………………………..... 145
Anexo N° 28 Registro de Llamadas de emergencias (3)………………………………..... 146
Anexo N° 29 Registro de Llamadas de emergencias (4)…………………………………. 147
Anexo N° 30 Registro de Llamadas de emergencias (5)……………………………….... 148
Anexo N° 31 Registro de Llamadas de emergencias (6)…………………………………. 149
Anexo N° 32 Registro de Llamadas de emergencias (7)……………………………….... 150
Anexo N° 33 Registro de Llamadas de emergencias (8)……………………………….... 151
Anexo N° 34 Registro de Llamadas de emergencias (9)………………………………..... 152
Anexo N° 35 Parte Policial para determinar la hora de llegada de la Policía al lugar de
la alerta (1)…………...……………………………………………………..
153
Anexo N° 36 Parte Policial para determinar la hora de llegada de la Policía al lugar de
la alerta (2)………………………………………………………………….
154
Anexo N° 37 Parte Policial para determinar la hora de llegada de la Policía al lugar de
la alerta (3)………………………………………………………………….
155
Anexo N° 38 Mapa del ámbito Jurisdiccional de la Comisaría de Santa Luzmila…….… 156
Anexo N°39 Código fuente del acceso al sistema……………………………………….. 157
xv
INTRODUCCIÓN
Hoy en día uno de los principales problemas que afronta el país, es la inseguridad
ciudadana. El distrito de Comas, presenta una serie de problemas de inseguridad en
diferentes lugares de su jurisdicción, problemas tales como: robos, asaltos, consumo de
bebidas alcohólicas, homicidios, estafas, pandillaje, drogadicción, faltas contra la fe
pública, violencia familiar, etcétera. Durante el periodo del año 2011, los registros de
las seis comisarías con las que cuenta este distrito, han reportado denuncias por
diferentes delitos y faltas, violencia familiar, accidentes de tránsito y otros, entre los
principales problemas de delincuencia que afectan la seguridad ciudadana en el distrito
de Comas (Plan Local de Seguridad Ciudadana y Convivencia Social – Comas, 2012).
La tecnología juega un rol importante como herramienta de control y monitoreo ante
estos sucesos delictivos para las comisarias. Un sistema de comunicación móvil A-GPS
forma parte de estas herramientas y ayuda en el proceso de atención de las llamadas de
emergencias.
La presente tesis se realizó en la comisaría de Santa Luzmila del distrito de Comas, con
la finalidad de mejorar el proceso de atención de las llamadas de emergencias que
realizan día a día los ciudadanos, ayudando a tener una respuesta rápida y exacta hacia
el lugar de la emergencia.
La problemática actual es el tiempo de respuesta de la policía ante un llamada de
emergencia, a esto se suma que muchas de estas llamadas son falsas o también
conocidas como llamadas perturbadoras.
El objetivo principal de esta tesis es determinar la influencia de un Sistema de
Comunicación Móvil A-GPS para la atención de llamadas de emergencias en la
comisaría de Santa Luzmila en el distrito de Comas.
El contenido está organizado de la siguiente manera: El primer capítulo, Problema de la
Investigación, define la problemática en la organización y las preguntas planteadas
para responder a la problemática, con los objetivos que se desean alcanzar, los
antecedentes que se han encontrado respecto al tema investigado, en el segundo
capítulo, Marco Teórico presenta la definición de los conceptos utilizados en el
proyecto para su entendimiento general, el tercer capítulo, Marco Metodológico
describe la metodología de investigación, la formulación de la hipótesis general y
específicas, contiene la metodología utilizada para el desarrollo del proyecto, la
definición conceptual y operacional de las variables, el tipo y diseño de investigación,
las técnicas de recolección de datos y método de análisis, el cuarto capítulo, Resultados
se ofrece los resultados obtenidos de la investigación, en el quinto capítulo,
Conclusiones y Sugerencias se indica las conclusiones y sugerencias, y por último la
presentación de las referencias bibliográficas y anexos utilizados.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
1 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
I. PROBLEMA DE INVESTIGACIÓN
1.1 Planteamiento del Problema
En la actualidad, los países latinoamericanos están sufriendo el incremento de los
índices de violencia y criminalidad, así como de la percepción de inseguridad por
parte de la población, la cual exige a los estados la adopción de medidas inmediatas y
efectivas para garantizar el pleno respeto de derechos fundamentales tan importantes
como los referidos a la vida, la integridad y el patrimonio (Federación
Iberoamericana de OMBUDSMAN, 2012).
Para Dammert (2010, p. 32), este incremento del uso de la violencia, la cotidianeidad
de los delitos y la percepción de carencia de protección, son hechos que preocupan a
los ciudadanos y autoridades.
Hoy en día, uno de los principales problemas que afronta el Perú es la inseguridad
ciudadana. Caminar por las calles de Lima ya no es tan seguro como era antes. Nadie
está exento de ser víctima de un asalto y esto genera un miedo constante en la
población.
Según (Ipsos Apoyo, 2012), un 75% de peruanos coloca a Lima como la ciudad más
peligrosa del Perú, seguida por Trujillo (52%) y Chiclayo (22%). La percepción de
inseguridad del ciudadano es tan alta que no quiere ni salir a la calle. Por ello no
sorprende que el 84% de los encuestados considere la vía pública como el lugar más
inseguro. Pero la vía pública es casi igual de peligrosa como el transporte público,
según el 83% de los encuestados.
Según la Encuesta Metropolitana de Victimización 2011, realizada por el Municipio
de Lima, señala que el distrito de Comas en Lima Norte es el que tiene la mayor
percepción de inseguridad ciudadana. El distrito de Comas, presenta una serie de
problemas de inseguridad en diferentes lugares de su jurisdicción, problemas tales
como: Robos, asaltos, consumo de bebidas alcohólicas, homicidios, estafas,
pandillaje, drogadicción, violencia familiar entre otros; estos se agravan
dependiendo la zona en la que se ubica. Estos actos delictivos muchas veces en la
mayoría de los casos, no son atendidos al momento por las fuerzas del orden,
dificultando la localización del infractor o presunto delincuente, así lo describe el
comité Distrital de Seguridad Ciudadana de Comas en su “Plan Local de Seguridad
Ciudadana y Convivencia Social 2012- Comas”, ubicando al distrito de Comas con el
mayor número de incidencias delictivas del cono Norte de Lima (Instituto Nacional
de Estadística e Informática, 2010).
Estos actos delictivos que se presentan día a día, delitos como: robos, secuestros,
extorciones, asaltos a mano armada, etcétera. Muchas veces en la mayoría de los
casos estos hechos no son atendidos al momento por las fuerzas del orden,
dificultando la localización del infractor o presunto delincuente.
El distrito de Comas cuenta con 5 comisarías para atender cualquier tipo de
emergencia:
- Comisaría PNP Santa Luzmila, ubicada en Av. Gerardo Unger 6500, Urb. Santa
Luzmila.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
2 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
- Comisaría PNP Universidad, ubicada en Av. Universitaria, Cdra. 8, Santa
Luzmila.
- Comisaría PNP Túpac Amaru, ubicada en Av. 28 de Julio 1121, km. 11, Av.
Túpac Amaru.
- Comisaría PNP Collique, ubicada en Av. Revolución, Cdra. 26.
- Comisaría PNP La Pascana, ubicada en Jr. José Carlos Mariátegui.
La comisaría de Santa Luzmila es responsable de cubrir una área de 9.70 Km2,
teniendo como límites de su jurisdicción las siguientes vías: Av. Panamericana
Norte, Riveras del Rio Chillón, Av. Los Incas, Av. Universitaria, Av. Gerardo Unger
y Av. San Bernardo (Ver anexo N° 37), la cual cuenta con 110 efectivos policiales y
4 patrulleros para enfrentar la inseguridad ciudadana (Plan Local de Seguridad
Ciudadana y Convivencia Social - Comas, 2012).
En la entrevista realizada al Comisario Cnel. Jorge Iparraguirre Mestanza, (Ver
anexo N° 3), explica el procedimiento de atención de las llamadas de emergencias.
Figura N° 1
Proceso de atención de llamadas de la central de emergencias 105.
En la figura N° 1 se puede visualizar el proceso de atención de llamadas de
emergencias, esto se inicia cuando el ciudadano realiza una llamada a la central de
llamadas de emergencias (105) ubicada en Av. Alfonso Ugarte Cdra. 13 - Cercado
de Lima o la misma comisaria de “Santa Luzmila”, donde se atienden las llamadas de
emergencias. El operador es el encargado de tomar apunte en un cuaderno los datos
que brinda el ciudadano como son: Su nombre, ubicación donde se produjo la
incidencia, que tipo de incidencia es (Asalto, accidente de tránsito, pandillaje, etc.),
posteriormente, el operador policial deriva esta llamada hacia un efectivo policial
encargado de acuerdo a la ubicación del origen de la llamada, informando de los
detalles que dio el ciudadano. La central de emergencias 105 esta subdividida por 4
sectores de acuerdo a las zonas: Zona Norte, Sur, Este y Oeste. Para el distrito de
Comas corresponde la zona Norte, posteriormente se comunica vía radio con la
comisaría más cercana donde se produjo la incidencia para informar la incidencia
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
3 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
registrada, luego la comisaría designa de acuerdo a la jurisdicción que móvil debe
acudir al lugar de la emergencia.
Toda esta secuencia de comunicaciones, desde la central 105 o desde la misma
comisaria hasta la móvil que se encuentra patrullando su jurisdicción, se ven
dificultados con un sistema de comunicación radial que muchas veces la batería de
los equipos se encuentran descargados o inoperativos, a esto se suma la demora en
la asignación policial. Los datos recepcionados respecto al tiempo de respuesta de la
policía ante una llamada de emergencia se puede observar en la gráfica N° 1, el cual
es resumen de la evaluación de un pre test, que permitió medir el tiempo de respuesta
de la policía ante una llamada de emergencia, la muestra obtenida fue de 48 registros
de llamadas, obteniendo un promedio de 29 minutos (Ver anexo N° 5), es aquí donde
se identificó un problema, debido a que el sistema de comunicación radial tiene
muchas deficiencias y muchos equipos se encuentran inoperables debido a la
antigüedad de los mismos.
Gráfica N° 1
Tiempo promedio de respuesta de la Policía.
Según las 30 mil llamadas de emergencias telefónicas que diariamente recibe la
Central de Emergencia 105 de Lima, el 70% son perturbadoras o distractoras. Es
decir, cerca de 21 mil falsas llamadas de emergencia ocurren a diario, situación que
genera saturación de la línea en perjuicio de las llamadas reales, así lo reveló el Jefe
Operativo de la Central 105 comandante Juan Herrera en la entrevista al periodista
Augusto Álvarez Rodrich en la radio emisora Radio Capital el 21 de Setiembre del
2012.
La central de llamadas de emergencias (105) y la comisaria de Santa Luzmila del
distrito de Comas, diariamente reciben todo tipo de llamadas muchas de estas son
falsas, distractoras e insultantes, situación que genera saturación de la línea
ocasionando que el ciudadano tenga dificultades para comunicarse con la comisaria,
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
4 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
es aquí donde nace otra problemática, ya que se deja de atender las llamadas de
emergencias reales, ocasionando pérdidas de tiempo, económicas ya que para este
tipo de atención requieren de toda una planificación logística. En la comisaria de
Santa Luzmila del distrito de Comas se obtuvo un resumen de la evaluación de un
pre test (Ver anexo N° 6), donde se registraron 22 alertas falsas durante 11 días,
obteniendo un porcentaje promedio de 45.83%, como se puede apreciar en la gráfica
N° 2. Este porcentaje es preocupante para la fuerza policial que da seguridad a los
vecinos del distrito de Comas.
Gráfica N° 2
Porcentaje promedio de registro de alertas falsas.
A esto se suma, que existen casos cuando en la asignación de una móvil acude a
atender una emergencia, no existe la manera de conocer si la móvil que fue asignada
se encuentra en el lugar que reportan, ya que en ocasiones para deslindar
responsabilidades se reportan en un ubicación que no corresponde a su jurisdicción.
Al analizar la situación actual para combatir la inseguridad ciudadana, se puede
apreciar que existe una serie de deficiencias, uno de ellos es el sistema de
comunicación para atención de las llamadas de emergencias, lo cual ocasiona la
demora en el tiempo de respuesta para acudir al lugar de la emergencia por parte de
la policía, además de las llamadas perturbadoras. Esto genera que la población se
sienta desprotegida por las autoridades que brindan seguridad. Si esta problemática
continua puede ocasionar que la población tome medidas radicales como hacer
justicia por sí mismos, generando caos y descontrol en la ciudad.
© E
labora
ció
n P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
5 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
1.2 Formulación del problema
1.2.1 Problema General
¿De qué manera influye un sistema de comunicación Móvil A-GPS para el
proceso de atención de llamadas de emergencias en la comisaría de Santa
Luzmila en el distrito de Comas?
1.2.2 Problemas Específicos
¿De qué manera influye un sistema de comunicación móvil A-GPS en el
tiempo de respuesta de la policía frente a las llamadas de emergencias en la
comisaría de Santa Luzmila en el distrito de Comas?
¿De qué manera influye un sistema de comunicación móvil A-GPS en el
porcentaje de registros de alertas falsas en la comisaría de Santa Luzmila en
el distrito de Comas?
1.3 Justificación
En el desarrollo se implementó un Sistema de Comunicación Móvil A-GPS que
integra el proceso de atención de llamadas de emergencias en la comisaria de Santa
Luzmila del distrito de Comas, ya que el sistema de comunicación con el que cuentan
es vía radio con aproximadamente más de 10 años de antigüedad, en consecuencia
daba como resultado retraso en comunicar a las móviles para acudir al lugar del
incidente, siendo perjudicial para los ciudadanos y los policías que atienden los
llamados de emergencias.
1.3.1 Justificación Tecnológica
En el ámbito de la tecnología, esta tesis dota de un nuevo sistema de
comunicación móvil A-GPS, integrado con una base de datos actualizada que
sistematiza todo el proceso de atención de llamadas de emergencias en la
comisaria de Santa Luzmila del distrito de Comas, situándola en una
institución comprometida en la lucha contra el crimen y la delincuencia,
donde la tecnología y su uso se vuelven necesarias para este proceso.
El desarrollo de las telecomunicaciones durante los últimos años ha resultado
fundamental para el desarrollo de la sociedad de la información, tecnologías
como las comunicaciones por satélite, desarrollo de la telefonía inalámbrica,
la fibra óptica, internet entre otros tecnologías posibilitan el desarrollo
económico, social y cultural del país en el que se viene dando avances, pero
aún queda mucho por hacer (Instituto Nacional de Estadística e Informática,
2002).
A través del sistema de comunicaciones Móvil A-GPS, facilitó una
comunicación directa entre ciudadano y autoridad, transparente, en tiempo
real haciendo que el ciudadano sea partícipe en su apoyo para combatir la
inseguridad ciudadana haciendo uso de un dispositivo móvil.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
6 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
1.3.2 Justificación Operativa
Con el sistema de comunicación móvil A-GPS la institución se favoreció
totalmente, donde mejoró el proceso de atención de llamadas de emergencias,
ya que los datos son obtenidos en forma automática. Facilitó la labor de los
efectivos policiales y mejoró los procedimiento, haciéndolo dinámico y
efectivo. El éxito en la gestión de la cadena logística requiere énfasis en la
integración de actividades, la cooperación, coordinación y el intercambio de
información a lo largo de toda la cadena desde la institución hasta los
ciudadanos. Para hacer frente a la problemática de la inseguridad ciudadana
se necesitó herramientas tecnológicas, como plataformas, que agilicen los
procesos. Estos sistemas tienen un impacto positivo en la comunicación, en el
intercambio de información favoreciendo a la institución donde ésta se ha
implementado (Serra, 2005, p.85).
Además a la institución le sirvió para mejor sus procesos operativos en la
atención de las llamadas de emergencias, dando una respuesta rápida al
ciudadano.
1.3.3 Justificación Institucional
Implementado el sistema de comunicación móvil A-GPS, posicionó a la
comisaria de Santa Luzmila a la par con la tecnología, donde la utilización de
herramientas tecnológicas ya es una realidad y estar ajena a ella dificulta una
adecuada competitividad, a partir de ello la visión y misión de la institución
establece otros objetivos y metas fortaleciéndose para combatir la inseguridad
ciudadana. Las Tecnologías de Información y la Comunicación (TIC’S),
extendidas por toda la organización, hacen cambiar a la organización, la
competitividad de la empresa depende, en buena parte, de su habilidad de
combinar e integrar estas tecnologías, (Pere y Jaume, 2003, p. 50).
Ello tiene un impacto positivo en la comisaria de Santa Luzmila, ya que el fin
de esta institución es brindar un buen servicio a la ciudadanía, por ello la
implementación de un sistema comunicación móvil A-GPS, permitió agilizar
el proceso de atención de llamadas de emergencias, a su vez garantiza una
mejor imagen institucional hacia los ciudadanos.
1.4 Limitación
Una de las limitaciones que se tuvo fue el acceso a la información de la comisaria de
Santa Luzmila, debido a que el acceso a los registros de las denuncias son
restringidas, es necesario de la orden del Comisario.
El sistema de comunicación móvil A-GPS está desarrollado sobre la plataforma
Android, el cual solo puede ser instalado sobre celulares que cuentan con esta
plataforma, versión superior a 2.2.
La aplicación web, en algunas interfaces se ha desarrollado con código jQuery y
JavaScript para su diseño, la cual funciona correctamente en el explorador web
Google Chrome, sin embargo en otros navegadores como Internet Explorer, el diseño
de la interfaz puede distorsionarse. Es por ello es recomendable utilizar el explorador
web Google Chrome.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
7 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En lugares cerrados el sistema de comunicación Móvil A-GPS, puede perder la
conexión a la Base de Datos del servidor.
1.5 Antecedentes
1.5.1 Antecedentes Internacionales
En el año 2012, Andrés Quijada, en la tesis “Metodología basada en el
enfoque ágil y la gerencia de proyectos de tecnología de información para el
desarrollo de aplicaciones móviles”, desarrollada en la Facultad de Ingeniería
escuela de Ingeniería Informática de la Universidad Católica Andrés Bello de
la ciudad de Caracas - Venezuela, trató el siguiente problema: Hoy en día el
ambiente con respecto a las aplicaciones móviles es muy volátil y presenta
una evolución continua en el tiempo. Debido a la importancia que en la
actualidad presentan estos sistemas, la creación eficiente de una aplicación
móvil debe darse a través de un proyecto de desarrollo, el cual, debe estar
sujeto a una metodología que permita la efectiva ejecución del proyecto. El objetivo de la investigación fue elaborar una metodología basada en el
enfoque ágil y la gerencia de proyectos de tecnología de información para el
desarrollo de aplicaciones móviles de calidad. La metodología de desarrollo
que utilizo fue el modelo Scrum y cada uno de las técnicas, como bases para
desarrollar una metodología de trabajo enfocada a cubrir problemas
vinculados a desarrollo de aplicaciones móviles.
Finalmente la investigación concluye que la combinación de técnicas
provenientes de la gestión de proyectos de tecnología de información,
métodos, modelos y principios del desarrollo ágil, se puede construir una
metodología que encare todas las situaciones cruciales que sufre el desarrollo
de una aplicación móvil, y a su vez que pueda adaptarse al dinamismo y
velocidad que presenta el mercado de aplicaciones móviles de la actualidad.
El aporte de la investigación de Andrés Quijada, que se tomó fue la
metodología de desarrollo Scrum y cada uno de las técnicas utilizadas. Esta
metodología sirvió como base para el desarrollo de la investigación enfocada
a cubrir problemas vinculados a desarrollo de aplicaciones móviles.
Diana Carolina Arce Cuesta y Sebastián Alejandro Cáceres Abril en el año
2011, en la tesis “Implementación de un Web GIS que permita ubicar
llamadas de emergencias para el Benemérito Cuerpo de Bomberos
Voluntarios de la Ciudad de Cuenca”, desarrollada en la Universidad
Politécnica Salesiana sede Cuenca, trato la siguiente problemática: Cuando un
individuo advierte que la vida, salud o propiedad de las personas se encuentra
en peligro debido a algún acontecimiento imprevisto, puede llamar
gratuitamente a la línea 102 desde cualquier teléfono fijo o público. El
operador se encarga de tomar los datos necesarios siendo estos; la dirección
exacta de la emergencia, tipo de emergencia (Incendio, accidente de tránsito,
personas heridas, etcétera) y nombre completo de la persona que realiza la
llamada, en este proceso existe el riesgo de que la información brindada por
el ciudadano no sea la correcta ya sea por el nerviosismo del individuo u otros
aspectos que impidan una buena comunicación. El objetivo principal de la
investigación fue la influencia de un sistema web en el tiempo de respuesta
para el cuerpo de bomberos voluntarios de la ciudad de Cuenca. La
Universidad César Vallejo Escuela de Ingeniería de Sistemas
8 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
metodología utilizada fue RUP y el tipo de investigación fue experimental
aplicada. Finalmente la investigación concluye que mediante el Sistema de
Información Geográfico desarrollado con arquitectura Web permite ubicar
una llamada de emergencia de manera ágil y oportuna, lo cual es beneficioso
para la ciudadanía, y de gran apoyo para el Benemérito Cuerpo de Bomberos
de Cuenca.
De esta investigación se tomó como aporte la estructura de desarrollo web
para el control de registros de alertas que realizan los ciudadanos a la
institución.
1.5.2 Antecedentes Nacionales
En el año 2009, Omar Steve Cotrina Díaz, en la tesis “Aplicación Web
GIS/GPS basado en Base de Datos Especiales y Algoritmos de Grafos para la
planificación de rutas y viajes el caso de Lima Metropolitana”, desarrollada
en la Universidad Nacional Mayor de San Marcos, trató el problema
siguiente: La ciudad de Lima Metropolitana no planifica (basado en criterios
tecnológicos y/o cálculos matemáticos) las rutas a seguir por los vehículos y
flotas de vehículos. El objetivo principal es desarrollar un sistema informático
capaz de poder planificar rutas y viajes óptimos de transporte usando
tecnologías GIS/GPS y teoría de grafos. La Justificación del proyecto abarca
un área recurrente todos los días en la ciudad como el uso de vehículos de
transportes con varias finalidades. Con una correcta planificación de rutas se
puede y viajes se puede obtener ahorro de combustible, mejoras en los
tiempos, mejor uso del personal, etcétera. La metodología de investigación
utilizada fue Aplicativa. La población son todos los vehículos de Lima
Metropolitana. La muestra son los vehículos de la empresa CLS (Collecte
Localisation Satellites) Perú. La metodología de desarrollo del sistema Web
fue RUP.
De esta tesis se tomó como aporte el uso de los métodos de obtención de la
ubicación exacta de un punto en la tierra mediante el principio matemático de
la triangulación, además los datos necesarios para la recepción de datos GPS.
En el año 2012, la Unidad de Investigación FIA de la Universidad San Martin
de Porres, en el proyecto Jallpa Kuyuy – Sistema de comunicación Móvil
GPS Post sismo, trata el siguiente problema: El Perú es un país altamente
sísmico, por lo cual está expuesto a movimientos sísmicos periódicamente,
luego de producirse el movimiento telúrico la comunicación es vital para
conocer el estado de los familiares, en la mayoría de veces las líneas
telefónicas colapsan, siendo el medio más utilizado en esos casos. El objetivo
principal del proyecto tiene como fin desarrollar una aplicación móvil
integrada con las redes sociales, tecnología GPS y Cloud Computing, para
contribuir con las comunicaciones entre grupos familiares instantes después
de ocurrido un sismo. La justificación del proyecto es muy importante, ya que
mediante este sistema se puede conocer de manera rápida la situación de los
familiares o amistades. La metodología que utiliza es Aplicativa. Los
resultados que obtuvieron son de una arquitectura estructurada en múltiples
niveles y diseñada para soportar diferentes de plataformas móviles y cloud
computing. El tiempo de respuesta que obtuvieron como mínimo es de 5
minutos ante la respuesta de un familiar según las pruebas realizadas por el
Universidad César Vallejo Escuela de Ingeniería de Sistemas
9 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
equipo del proyecto. Además concluyen que es una solución que integra las
ventajas de las comunicaciones por redes sociales, la velocidad de la
tecnología móvil, la precisión de ubicación de los receptores GPS y las
ventajas de procesamiento y almacenamiento de datos que proveen los
servicios cloud, asegura la comunicación con los grupos familiares después
de un sismo. La metodología que utilizaron para el desarrollo de la aplicación
fue MSF (Microsft Solution FrameWork).
De este proyecto se tomó como aporte el modelo de registro de grupos
familiares o amistades, la posición frente a una señal de alerta después de
ocurrido un sismo, además la ubicación geográficamente de las personas, el
indicador tiempo de respuesta ante una emergencia y los resultados obtenidos
para la discusión de resultados.
1.6 Objetivos
1.6.1 Objetivo General
O: Determinar la influencia de un sistema de comunicación Móvil A-GPS
para el proceso de atención de llamadas de emergencias en la comisaría de
Santa Luzmila en el distrito de Comas.
1.6.2 Objetivos Específicos
O-1: Determinar la influencia de un sistema de comunicación Móvil A-GPS
en el tiempo de respuesta de la Policía en la atención de llamadas de
emergencias en la comisaría de Santa Luzmila en el distrito de Comas.
O-2: Determinar la influencia de un sistema de comunicación móvil A-GPS
en el porcentaje de registros de alertas falsas en la comisaría de Santa
Luzmila en el distrito de Comas.
O-3: Implementar un sistema de comunicación móvil A-GPS para mejorar el
proceso de atención de llamadas en la comisaría de Santa Luzmila en el
distrito de Comas.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
10 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
II. MARCO TEÓRICO
2.1 Marco Teórico
2.1.1 Sistema de Comunicación Móvil A-GPS
El sistema de comunicación móvil GPS (Sistema de Posicionamiento Global)
está formado por una constelación de satélites que orbita la tierra dos veces al
día, transmitiendo información precisa de tiempo y posición a cualquier lugar
de la tierra, las 24 horas del día.
La constelación GPS está formada por 24 satélites que giran alrededor de la
tierra en seis planos fijos, que están inclinados 60° desde el Ecuador. La
constelación de satélites es operada y verificada por la fuerza aérea de los
Estados Unidos de Norteamérica, desde su estación principal en Colorado.
Esta estación está equipada con sistemas para monitoreo de satélites
telemetría, transmisión y recepción de datos, etcétera. Además de esta
estación en Colorado, otras estaciones y antenas están instaladas alrededor del
mundo, para hacer el seguimiento de los satélites y enviar la información a la
estación central. Con esta red de estaciones, se mantiene y actualiza la
posición exacta de los satélites y la precisión de los datos, ajustándose las
pequeñas discrepancias que puedan observarse cada vez que es preciso
(Unidad de Investigación FIA/USMP 2004, p.140).
Según Van Diggelen (2006, p. 11), un Assisted GPS (A-GPS) mejora en el
rendimiento del GPS estándar, proporcionando información, a través de un
canal de comunicación alternativo, que el receptor GPS normalmente recibe
de los propios satélites. El A-GPS no es excusa para el receptor de recibir y
procesar las señales de los satélites, sino que simplemente hace que esta tarea
sea más fácil y reduce al mínimo la cantidad de tiempo y la información
necesaria de los satélites. El receptor A-GPS todavía hace mediciones de los
satélites, pero puede hacerlo más rápidamente, y con señales más débiles, que
un receptor sin ayuda.
Figura N° 2
Visión general de la asistencia A-GPS.
© F
rank V
an D
iggel
en, 2
009
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
11 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
La figura N° 2 muestra al servidor de localización y la base de estación
celular proporcionar algún subconjunto de la información mostrada. Los
datos de asistencia se usan en el receptor A-GPS para reducir la frecuencia y
la búsqueda de código de retardo. El rango de búsqueda se indica por las cajas
rectangulares blancas, y la señal del satélite deseado se encuentra en la
intersección de las dos cajas. Cuanto más precisa los datos de asistencia, más
estrecho será el intervalo de búsqueda se puede prestar asistencia siempre
proporciona cierta reducción en la búsqueda de frecuencia, pero hay una
reducción en la búsqueda del código de retardo sólo si bien en tiempo de
asistencia está disponible.
Un servidor de Assisted GPS proporciona datos a un terminal inalámbrico
que es específica a la ubicación aproximada del teléfono con el fin de
minimizar la TTFF (The Time to First Fixe) y maximizar el rendimiento. La
localización aproximada de la unidad portátil se puede determinar por
diversos medios. Si el teléfono se encuentra en una red celular, puede venir de
la ubicación de la torre de la célula, que puede haber sido introducida por el
usuario al seleccionar una ciudad de un mapa, que puede haber sido calculado
utilizando otra tecnología de localización, o que puede venir desde una
ubicación almacenada previamente en el terminal inalámbrico, de esta manera
explica Harper (2009, p. 5).
Para Zandbergen y Barbeau (2011, p. 383), sostiene que el Assisted GPS es
una tecnología popular que mejora el GPS convencional, especialmente en el
área de redes de telefonía móvil. En sistemas A-GPS, la información útil se
proporciona por la red celular que puede ayudar al receptor del GPS para
calcular una posición precisa más rápidamente. A-GPS utiliza información de
más de una fuente, mientras que el cálculo de la posición del dispositivo.
Herramientas para el desarrollo del Sistema de Comunicación Móvil A-
GPS:
Para el desarrollo de la aplicación móvil de la presente investigación se
realizó bajo la plataforma Android. Para esto fue necesario de un IDE Eclipse
y un plugin Android Development Tools (ADT) que está diseñado para darle
un ambiente potente, integrado en la construcción de aplicaciones de
Android.
Cada vez son más los dispositivos móviles que vienen con este sistema
operativo. Android sigue siendo el sistema operativo que domina nada menos
que un 75% del mercado en todo el mundo, en la tabla N° 1 se puede apreciar
los resultados de las ventas de teléfonos inteligentes en todo el mundo a los
usuarios finales por sistemas operativos en el primer trimestre de los años
2012 y 2013.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
12 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 1 Ventas de teléfonos inteligentes en todo el mundo a usuarios finales
por el sistema operativo en el 1T13 (Miles de Unidades)
Sistema
Operativo
1T13
Unidades
1T13
Participación
Mercado (%)
1T12
Unidades
1T12
Participación
Mercado (%)
Android 156,186.0 74.4 83,684.4 56.9
iOS 38,331.8 18.2 33,120.5 22.5
BlackBerry 6,218.6 3.0 9,939.3 6.8
Microsoft 5,989.2 2.9 2,722.5 1.9
Bada 1,370.8 0.7 3,843.7 2.6
Symbian 1,349.4 0.6 12,466.9 8.5
Otros 600.3 0.3 1,242.9 0.8
Total 210,046.1 100.0 147,020.2 100.0
Fuente: http://www.gartner.com/newsroom/id/2482816
La Plataforma Android.
Es un Sistema operativo para teléfonos móviles inteligentes o tabletas basado
en Linux, es conocido como el representante de software libre en el mundo
móvil y es desarrollado por Open Handset Allience, la cual es liderada por
Google (Fuentes S, 2007).
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. Representa la primera
incursión seria de Google en el mercado móvil y nace con la pretensión de
extender su filosofía a dicho sector.
Todas las aplicaciones para Android se programan en lenguaje Java y son
ejecutadas en una máquina virtual especialmente diseñada para esta
plataforma, que ha sido bautizada con el nombre de Dalvik. El núcleo de
Android está basado en Linux 2.6. La licencia de distribución elegida para
Android ha sido Apache 2.0, lo que lo convierte en software de libre
distribución. A los desarrolladores se les proporciona de forma gratuita un
SDK y la opción de un plug-in para el entorno de desarrollo Eclipse varias
que incluyen todas las API necesarias para la creación de aplicaciones, así
como un emulador integrado para su ejecución. Existe además disponible una
amplia documentación de respaldo para este SDK. Además de todo ello, otro
aspecto básico para entender la aparición de Android es que pretende facilitar
la integración de estos dispositivos con las posibilidades cada día mayor
ofrecidos por la Web. Por ejemplo, una aplicación desarrollada en Android
podría ser aquella que indicase al usuario, a través de Google Maps, la
localización de sus diferentes contactos de la agenda y que avisase cuando
éstos se encuentren a una distancia cercana o en una ubicación determinada.
Para entender mejor, a continuación cito el diagrama de la arquitectura
Android:
Universidad César Vallejo Escuela de Ingeniería de Sistemas
13 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 3
Arquitectura Android
En la figura N° 3 se distinguen claramente cada una de las capas: la que
forma parte del propio Kernel de Linux, donde Android puede acceder a
diferentes controladores, las librerías creadas para el desarrollo de
aplicaciones Android, la siguiente capa que organiza los diferentes
administradores de recursos, y por último, la capa de las aplicaciones a las
que tiene acceso.
Plataforma Web
La plataforma web ofrece una comunicación fluida entre la institución y los
ciudadanos, con la tendencia a convertirse con el tiempo en una red de
comunicación con las demás comisarias. La ventaja de una plataforma web es
que cuenta con un interfaz de fácil manejo para el operador y que pueda
comunicarse en el menor tiempo posible con los usuarios y efectivos
policiales. El sistema de comunicación móvil A-GPS es de gran aporte para la
institución ya que permite mejorar sus procesos y obtener resultados en
tiempo real. Gracias a la plataforma web los ciudadanos tienen la opción de
registrarse gratuitamente y descargar la aplicación móvil para instalar en su
dispositivo móvil.
Un servidor web es un ordenador en el que se ejecuta un programa servidor
HTTP( HyperText Transfer Protocol), por lo que puede denominarse servidor
HTPP, es un ordenador que ejerce la función de servidor se puede instalar
más de un tipo de software servidor (Brochard, 2006, p.11). Los navegadores
deben poder comunicar con el servidor web y entender el protocolo HTTP, el
objetivo principal del protocolo HTTP es la transferencia de archivos
principalmente de formatos HTML, localizados a través de un URL (Uniform
Resource Locator), las versiones más utilizadas del protocolo HTTP son:
Rec
up
erad
o d
e:
htt
p:/
/and
roid
eity
.com
/20
11
/07/0
4/a
rqu
itec
tura
-de-
and
roid
/
Universidad César Vallejo Escuela de Ingeniería de Sistemas
14 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
0.9: Esta versión estaba destinada a la transmisión de páginas web en formato
HTML. Sólo soporta un método de envío de las solicitudes, no se devuelve al
cliente ninguna información acerca del contenido de las páginas.
1.0: Entre los grandes cambios introducidos en esta versión se encuentra el
soporte para más tipos de archivos gracias a los tipos MIME (Multipurpose
Internet Mail Extensions: dos breves cadena se caracteres separadas por una
barra “/”).
1.1: En esta versión, las novedades más importantes son la presencia de la
conexión y el soporte de hosts virtuales. Se han añadido los métodos
siguientes: PUT, DELETE, OPTIONS y TRACE. A la autenticación BASIC
se ha añadido el modo de autenticación DIGEST. Antes de que apareciese la
persistencia de conexión, una página web con imágenes realizaba tantas
conexiones con el servidor web como archivos tuviera que transmitir.
Figura N° 4
Funcionamiento Plataforma Android con acceso a Web Service.
En la figura N° 4 se puede visualizar el funcionamiento de la plataforma
Android y el Web Service, ya que de momento el API de Android no provee
ningún método que permita ‘conectarse’ a través de internet directamente a
una Base de Datos Remota y ejecutar una consulta dentro de ella. Para poder
realizar esto se puede utilizar un web service al cuál se pueda acceder a él
pasando diversos parámetros nos devuelve ya sea en formato XML o JSON,
para la presente investigación se utilizó XML, HTML y PHP.
2.1.2 Proceso de atención de llamadas de emergencias:
Para Heinz y Barnes (2011, p. 9), las llamadas de emergencia son una función
crítica del sistema telefónico actual; ya no son una característica opcional.
Rec
uper
ado d
e:
htt
p:/
/andro
idei
ty.c
om
/2012/0
7/0
5/l
ogin
-en-
andro
id-u
sando-p
hp
-y-m
ysq
l/
Universidad César Vallejo Escuela de Ingeniería de Sistemas
15 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Con el fin de obtener ayuda en caso de emergencia, la gente recurre al
teléfono más cercano y llama a un número de emergencia conocido.
Una llamada de emergencia es con frecuencia la acción que inicia una
respuesta de emergencia, pero rara vez es la única forma de comunicación
que tiene lugar como parte de esa respuesta. Además de la llamada de
emergencia, operarios, personal de emergencia, y otras entidades que se
comunican entre sí, y a veces es necesario enviar alertas a otros individuos.
Las llamadas de emergencia se conectan a puntos de seguridad pública (PSAP
contestadores) - estos son los "calls centers" para llamadas de emergencia.
Allí, un operador de llamadas contesta la llamada, y suelen pedir de
inmediato lo que ha sucedido y el lugar del incidente. Respuestas precisas a
estas preguntas hacen que el trabajo a la operadora sea más fácil, ya que la
emergencia debe ser clasificadas y los servicios de emergencia pertinentes,
enviado al efectivo policial correspondiente al lugar de la emergencia.
Desafortunadamente, la información que brindan las personas a menudo no
proporciona la información suficiente o en otros casos brindan información
incorrecta, haciéndose dificultoso la ubicación de la persona. Por esta razón,
los sistemas que proporcionan información de la ubicación exacta de la
persona a la operadora puede ser una mejora esencial para un sistema de
llamadas de emergencias.
Según Carrion y Dammert (2009), la ciudadanía del Perú, actualmente siente
insatisfacción ante la respuesta inmediata de los delitos que se suscitan día a
día, ya que afectan directa y cotidianamente a las personas. Entre los delitos
están los asaltos en la vía pública, pandillaje, robo de vehículos y de
accesorios, micro comercialización y consumo de drogas, proxenetismo,
violencia familiar, violaciones sexuales, entre otros, cuya frecuencia es
permanente y afecta a todos los estratos sociales (p. 83).
La sensación de peligro contra la integridad física o los bienes materiales
percibida por los ciudadanos en estos últimos años debe ser contrastada con la
información que efectivamente registra la Policía Nacional del Perú en cuanto
a denuncias sobre delitos y faltas contra la persona, el patrimonio, las buenas
costumbres y la seguridad pública.
En la gráfica N° 3 se observa que, durante el año 2010, la Policía Nacional
del Perú registró un total de 181,866 denuncias por los diferentes tipos de
delitos a nivel nacional, cifra que es superior en 21,018 casos más que el año
anterior, representando un incremento de 13.07% en la incidencia delictiva.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
16 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Gráfica N° 3
Tendencias de denuncias por delitos en el Perú.
Por otra parte, los delitos contra el patrimonio (hurto, robo, apropiación
ilícita, estafas, otros) se presentó la mayor cantidad de denuncias,
registrándose un total de contra la vida, cuerpo y la salud (homicidios, aborto,
lesiones, otros) con 22,285 denuncias que representa el 12.25%, en tercer
término por los delitos contra la seguridad pública (TID, micro
comercialización de drogas, tenencia ilegal de armas, otros) con 16,345
denuncias y en cuarto lugar por los delitos contra la libertad (personal,
intimidad, domicilio, sexual, otros) con 8,686 denuncias (Anuario Estadístico
2010, Policía Nacional del Perú).
Para la presente investigación se tomaron las dimensiones: Tiempo de
respuesta de la policía y llamadas de emergencias perturbadoras.
A. Tiempo de respuesta de la policía.
Se define como el tiempo que pasa desde que se envía una alerta y se recibe
la respuesta.
Cálculo del tiempo de respuesta de la policía ante las llamadas de
emergencias:
Para este cálculo se ha utilizado una metodología con una situación real para
determinar el tiempo de respuesta de la policía ante una llamada de
emergencia.
Según Taha (2004, p. 665), el tiempo de atención se resume con la siguiente
fórmula:
………………………..Fórmula (2.1)
Hip se obtiene de los partes policiales (Ver anexos 31-33) y el Hrll de los
registros de llamadas (Ver anexos 22-30).
© A
nuar
io E
stad
ísti
co 2
010 P
NP
T = (Hip – Hrll)
Universidad César Vallejo Escuela de Ingeniería de Sistemas
17 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Luego se tiene:
…..……………….......Fórmula (2.2)
Dónde:
T = Tiempo de respuesta de la policía.
Hrll = Hora de recepción de llamada.
Hip = Hora de intervención policial.
TA = Tiempo Promedio de respuesta de la Policía.
Para Kazmier y Díaz (1999, p. 304), un número índice es un valor relativo
expresado como porcentaje o cociente, que mide un periodo dado contra un
periodo base determinado.
B. Porcentaje de registros de alertas falsas. Son las llamadas malintencionadas que buscan perturbar, distraer o llamar la
atención haciendo uso de la línea telefónica.
Cálculo del Porcentaje de registro de alertas falsas:
Para controlar el porcentaje de los registros de alertas falsas que se realizan,
se toma como variable total de registros de alertas falsas y el total de
registros de alertas. En la siguiente fórmula a un registro de alerta falsa se le
considera también como llamada falsa, distractora o perturbadora y se toma
la formula por cantidades (Adecuado).
Para este cálculo se ha utilizado la siguiente fórmula:
Praf = X 100
…………Fórmula (2.3)
Dónde:
Praf = Porcentaje de Registro de Alertas Falsas.
Traf = Total de Registros de alertas falsas
Tra = Total de Registro de alertas
C. Metodología de desarrollo del Sistema de Comunicación Móvil A-
GPS.
Para Figueroa, Solís y Cabrera (2010), desarrollar un buen software depende
de un sin número de actividades y etapas, donde el impacto de elegir la mejor
metodología para un equipo, en un determinado proyecto es trascendental
para el éxito del producto. El papel preponderante de las metodologías es sin
duda esencial en un proyecto y en el paso inicial, que debe encajar en el
equipo, guiar y organizar actividades que conlleven a las metas trazadas en el
grupo.
Traf
Tra
∑
Universidad César Vallejo Escuela de Ingeniería de Sistemas
18 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Para la presente tesis se evaluaron tres principales metodologías de desarrollo
de software, determinando así cual es la más adecuada para el desarrollo del
sistema de comunicación móvil A-GPS como apoyo al proceso de atención de
llamadas de emergencias o a su vez una combinación de dichas metodologías.
En la tabla N° 2 detalla las diferencias existentes en dichas metodologías de
desarrollo de software.
Tabla N° 2 Cuadro comparativo de Metodologías
Fuente: Elaboración Propia
METODOLOGÍA VENTAJAS DESVENTAJAS
RUP
- La ventaja principal de RUP es
que se basa todo en las mejores
prácticas que se han orientado y
se han probado en el campo.
- Uso de arquitectura basada en
componentes.
- Pensado para proyectos y equipos
grandes, con roles designados y
con una duración extendida.
- Permite evaluar tempranamente
los riesgos.
- Puede no resultar muy adecuado
por el grado de complejidad.
- Requiere de conocimientos de
los procesos y de UML.
- Se tarda mucho tiempo en pasar
por todo el ciclo.
- Dificultad para especificar
claramente los requerimientos al
comienzo del proyecto(no
permite flexibilidad en los
cambios)
Scrum
- Programación organizada.
- Menor taza de errores.
- Satisfacción del programador.
- Es más fácil comprobar el
progreso del proyecto ya que las
reuniones frecuentes son parte de
la misma.
- Es recomendable emplearlo solo
en proyectos a corto plazo.
- Altas comisiones en caso de
fallar.
MSF
- Aplica mucho e incentiva al
trabajo en equipo y a la
colaboración.
- Es útil para proyectos de pequeña
y gran escala.
- Crea una disciplina de análisis de
riesgos que ayuda y evoluciona
con el proyecto.
- Cuenta con plantillas que ayudan
para el proceso de
documentación.
- Por ser un modelo prescriptivo,
solicita demasiada
documentación en sus fases.
- El análisis de riesgos es
necesario, pero si se lo hace
muy exhaustivo puede demorar
o hasta frenar el proyecto.
- Al estar basado en tecnología
Microsoft, trata de obligar a
usar herramientas de ellos
mismo.
XP
- Desarrollo iterativo e incremental
- Pensado para proyectos y equipos
grandes, con roles designados y
con una duración extendida.
- Programación organizada
- Menor taza de errores
-Proyectos cortos con equipos
pequeños y rotables en cuanto a
roles.
- Recomendable su empleo solo
en proyectos a corto plazo.
- Altas comisiones en caso de
fallar.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
19 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 3 Criterios de selección de Metodología
Fuente: Elaboración Propia
Luego de evaluar las metodologías mencionadas en la tabla N° 3, donde se observa
el puntaje de evaluación, validado por tres expertos (Ver anexos 9, 10 y 11), por lo
tanto se llegó a determinar el uso de una metodología ágil como es el modelo
Scrum y cada una de las técnicas que utiliza, como bases para el desarrollo de la
aplicación móvil y web.
a) Metodología Scrum
Scrum es un SDM (Reunión diaria de Scrum) ágil que divide el desarrollo en
iteraciones (sprints). Las características de cada sprint provienen de la acumulación
de productos que contiene los requisitos de alto nivel de trabajo por hacer. Con sus
diarios reuniones scrum es posible de una estrecha vigilancia y el control del
proyecto. El equipo es facilitado por un Scrum-Master que facilita las reuniones y
el progreso.
El momento actual se ha definido como una época donde hay una reevaluación del
uso de SDM. Esta era de reevaluación hizo hincapié en la necesidad y la
importancia de un método válido y fiable de evaluación, especialmente después de
la implementación de un SDM, de esta manera lo define Fujita y Doménico (2010.
p. 165).
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el
desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una
iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración
termina con una pieza de software ejecutable que incorpora nueva funcionalidad.
Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza
como marco para otras prácticas de ingeniería de software como RUP o Extreme
Programming, el proceso de funcionalidad de Scrum se visualiza en la figura N° 5.
CRITERIOS RUP Scrum MSF XP TOTAL
Grado de conocimiento 15 15 13.33 10 53.33
Soporte orientado a objetos 13.33 13.33 10 11.66 48.32
Adaptable a cambios 10 20 11.66 10 51.66
Basado en casos de uso 20 15 11.66 10 56.66
Posee documentación
adecuada 16.66 15 10 10 51.66
Facilita la integración entre
etapas de desarrollo 11.66 16.66 10 11.66 49.98
Relación con UML 18.33 13.33 11.66 10 53.32
Permite desarrollo software
sobre cualquier tecnología 11.33 15 10 10 46.33
TOTAL 116.31 123.32 88.31 83.32
Universidad César Vallejo Escuela de Ingeniería de Sistemas
20 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 5
Ilustración cómo funciona la metodología Scrum.
A continuación se describe como se da la combinación del modelo Scrum y cada
una de las técnicas:
Iniciación del Proyecto.
Para poder iniciar un proyecto de aplicación móvil existen una seria de
preguntas que deben ser contestadas para comenzar el desarrollo teniendo una
visión general del problema que se desea resolver. El documento de iniciación
debe contener la siguiente información:
- Información del Cliente o Empresa.
- ¿Cuál será el nombre comercial de la aplicación móvil?
- ¿Objetivo general de la aplicación móvil?
- ¿Bajo qué plataformas será ejecutada la aplicación?
- ¿Qué tipo de aplicación será? Nativa, WEB o Híbrida
Cualquier otra información de interés para el proyecto puede ser incluida en este
documento de iniciación que debe ser revisado por el cliente. Por otro lado, el
equipo de desarrollo puede participar aconsejando al usuario para proponer las
mejores soluciones en cuanto a la plataforma móvil, dispositivos o tipo de
aplicación.
Historias de Usuario.
Según Quesada X. (2009), las historias de usuario deben aportar valor al negocio
de forma independiente e incremental. También destaca que las historias de
usuario son un requerimiento del negocio visto desde el punto de vista del
cliente, y que los mismos deben mantener el siguiente formato: “El actor XXX,
quiere hacer YYY con el objetivo de ZZZ” donde XXX es el tipo de usuario
(quien), YYY es lo que el sistema debe estar en la capacidad de hacer (el que) y
ZZZ es el valor y objetivo de cumplir con esa función (el por qué). La estructura
de una historia de usuario está formada por:
Rec
uper
ado d
e:
htt
p:/
/ww
w.s
crum
man
ager
.net
/fil
es/
sm_p
royec
to.p
df
Universidad César Vallejo Escuela de Ingeniería de Sistemas
21 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
- Nombre breve y descriptivo.
- Descripción de la funcionalidad en forma de diálogo o monólogo del
usuario describiendo la funcionalidad que desea realizar.
- Criterio de validación y verificación que determinará para considerar
terminado y aceptable por el cliente el desarrollo de la funcionalidad
descrita.
Y adicionalmente por la información que resulte necesaria por el modelo de
implementación: Prioridad, Riesgo, Tamaño, etc.
Tabla N° 4 Formato de Historias de usuarios
Nombre de la Historia
Descripción de la Historia de Usuario
Prioridad del Cliente
Condiciones de Satisfacción Número de Complejidad
(De ser necesario) (Puntos de Historia)
Fuente: Elaboración Propia.
Prioridad del Cliente:
El cliente debe asignar prioridades a cada una de las historias para que el
equipo de desarrollo pueda tener una referencia del valor y la importancia que
tiene cada historia de usuario para el negocio. Tener en cuenta estas
prioridades ayuda al equipo a determinar posibles versiones de la aplicación
lo antes posible. Las prioridades deben darse a través de colores, como se
muestra a continuación:
- Primer color: Indicará las funciones que deben desarrollarse lo antes
posible, las que posiblemente estén implementadas para el primer
lanzamiento y en las cuales se base la idea principal de la aplicación.
- Segundo Color: Referenciará aquellas historias de usuario que contengan
funciones secundarias que complementen la idea principal de la aplicación.
- Tercer Color: Cualidades o características de la aplicación que aporten
valor pero que no se requiera de ellas para que el usuario pueda realizar la
función principal.
Asignación del Número de Complejidad:
Con respecto a la estimación de esfuerzos se utilizó la técnica Planning Poker.
Según Quesada (2009), esta técnica trata de un consenso entre los
desarrolladores llevado a cabo con una serie de serie de Fibonacci, teniendo
en cuenta que entre más bajo es el número acordado, menor será la
complejidad historia. La unidad que representa la numeración de complejidad
de la historia de usuario por lo general es llamada Puntos de Historias, y son
Universidad César Vallejo Escuela de Ingeniería de Sistemas
22 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
distintos para cada grupo de desarrollo ya que no todos los equipos asignarían
el mismo número de complejidad a la misma historia de usuario.
Los pasos para esta técnica se describen a continuación:
- El cliente lee una historia de Usuario.
- El equipo procede a realizar preguntas para aclarar y conocer mejor el
alcance de dicha historia de usuario.
o En este punto las preguntas contestadas pueden generar condiciones de
satisfacción para la historia.
o Pueden aparecer historias de usuario nuevas.
- Cada desarrollador piensa en el esfuerzo necesario para realizar esa
historia y todos muestran sus cartas simultáneamente, con la finalidad de
no condicionar los esfuerzos de los desarrolladores.
- Las personas que tuvieron los números más altos explican porque
seleccionaron ese número (pueden aparecer problemas que no fueron
pensados por los demás) y los que seleccionaron un número más bajo
deben explicar porque consideraron la historia tan sencilla (pueden surgir
soluciones simples).
- El equipo vuelve a votar tomando en cuenta lo discutido en los resultados
hasta llegar a un acuerdo.
Historias de Usuario Móvil:
Una manera en la cual las historias de usuario pueden satisfacer en parte las
meta-requerimientos, es si estas mantienen un vínculo con los dispositivos
móviles. Si resulta complejo adaptar las historias de usuarios a funciones
que puedan ser desarrolladas bajo una plataforma móvil lo más probable es
que esa historia deba ser resuelta usando otra plataforma (Escritorio o Web
generalmente). De igual manera estas funciones que deben desarrollarse
fuera de la plataforma móvil estarán incluidas en el desarrollo porque de
ellas depende el buen funcionamiento de la aplicación.
Ya que el desarrollo móvil por lo general mantiene situaciones generales en
cuanto a desarrollo, dentro del modelo existirán algunas historias de usuario
estándar. Es decir, serán historias que pueden ser incluidas en el desarrollo
presentando adaptaciones al problema que se trata. Estas historias estándar
se muestran a continuación:
- Configuración de la App: Todo usuario móvil por lo general tiene la
capacidad de personalizar su aplicación para adaptar su contenido a su
preferencia, generando más agrado y satisfaciendo de forma más cómoda
sus necesidades. Es por esto que dentro de las historias de usuario puede
existir alguna que trate sobre la configuración y personalización de la
aplicación.
- Agrado o detección de errores: Con la finalidad de conocer las
debilidades y errores de la aplicación, esta debe contar con una función
que permita a los usuarios finales evaluar la aplicación de forma sencilla
Universidad César Vallejo Escuela de Ingeniería de Sistemas
23 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
(Cualitativamente o Cuantitativamente) o informar a los desarrolladores
de algún error para que este pueda ser corregido a la brevedad posible.
- Actualizar o Descargar: El desarrollo de las aplicaciones móviles por lo
general vincula muchas actividades orientadas a las ventas, implicando
las configuraciones necesarias para poder incluir la aplicación en un
repositorio como App Store (Apple) o Android Market (Android). De
esta forma, las funciones requeridas para que los usuarios finales puedan
comprar, descargar o bien actualizar la aplicación pueden estar incluidas
en una historia de usuario.
Descomposición de Historias de Usuario:
Para que las historias de usuario puedan ser desarrolladas, estas deben ser
descompuestas en tareas. La definición de estas tareas presenta un factor
importante para el resto del desarrollo. A continuación, tomando en cuenta lo
descrito por Garzás J. (2012), se describen buenas prácticas para la
descomposición de historias de usuario:
- A la hora de descomponer las historias de usuario en tareas, se debe tener
en cuenta que el tamaño de la tarea debe permitirle a un integrante del
equipo desarrollarla entre medio día hasta un máximo de 4 días de trabajo,
Garzás plantea que las tareas de muy poco tiempo (menores a medio día de
trabajo) generan pérdidas de tiempo al ser gestionadas, mientras que
cuando pasan de 4 días lo más probable es que esta tarea pueda ser
dividida en tareas más pequeñas y así facilitar su gestión.
- Definir tareas que una vez concluidas generen un producto entregable. Por
ejemplo: En vez de definir tareas como “Construir interfaces de usuario” o
“Construir Modelo E-R”, las tareas al ser completadas deben entregar
funcionalidad, algo como “Construir módulo de registro de usuario” o
“módulo de atención al cliente”. De esta forma, las tareas no dependen de
otras tareas para poder ser probadas.
- No es recomendable dedicar mucho tiempo al análisis de tareas para
determinar estimaciones. Garzás opina que muchas veces el equipo de
desarrollo analiza con exactitud los detalles de la tarea para generar una
estimación más precisa, lo que puede generar demoras de tiempo
innecesarias en el proceso de división de las historias.
Hay que tener en cuenta que el descomponer las historias de usuario en tareas
no es suficiente, el equipo de desarrollo en conjunto con el cliente debe
determinar si existen dependencias entre las tareas para tener presente esa
información durante el desarrollo y así facilitar su gestión.
Release Plan.
Una vez que las historias de usuario son definidas el equipo de desarrollo puede
armar un release plan donde indicará cuales historias serán desarrolladas en cada
uno de los Sprint del proyecto. Dicho plan mantiene una referencia fuera de los
Sprints de cómo irá siendo el desarrollo y como se darán los avances, teniendo
Universidad César Vallejo Escuela de Ingeniería de Sistemas
24 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
siempre presente que este plan está sometido a cambios inesperados y el cual
probablemente no se mantenga igual durante todo el proyecto.
Un aspecto clave en estos planes es que se debe tener muy clara la prioridad del
cliente en las historias, y es con la ayuda del mismo que se deben armar los
release plan. El release plan deberá mantener un formato parecido al reflejado en
la tabla N° 5.
Tabla N° 5 Formato de Release Plan
Sprint Historias Complejidad Complejidad Total
Primera Versión
Sprint 1
Historia 2 2
12 Historia 5 6
Historia 1 4
Sprint 2
Historia 3 6
11 Historia 4 5
… …
Versión M
Sprint X
Historia Y 4
12 Historia Z 4
Historia W 4
Fuente: Elaboración Propia
Un aspecto importante que hay que considerar es indicar cuales Sprint
conformarán las versiones que se espera de la aplicación manteniendo como
premisa que el desarrollo de una versión, puede contar con el desarrollo de
varios Sprint.
Sprint.
Al basar la metodología en Scrum obligatoriamente se deben utilizar los sprints
para definir los lapsos de desarrollo, cada uno de los sprint que se lleven a cabo
en el proyecto deben concluir con algún software operativo.
Cuando inicia un sprint, inicia la oportunidad de gestionar el desarrollo de la
aplicación ya que las historias de usuario seleccionadas para el sprint actual no
podrán ser cambiadas mientras este se lleva a cabo. Es aquí donde entran las
técnicas justo a tiempo y las reuniones típicas de Scrum (Orientadas a los meta-
requerimientos) para gestionar el sprint y optimizar el desarrollo de los mismo.
Reuniones de Sprints:
Estas reuniones ayudarán a vincular a todo el equipo en la toma de decisiones
del proyecto. Entre estas reuniones se discutirán temas orientados al
desarrollo de aplicaciones móviles:
- Reuniones de Planificación: Estas son las reuniones en las cuales el
equipo de desarrollo decide que historias de usuario serán implementadas
en el sprint. Es aquí donde se hace uso de la prioridad de las historias de
usuario teniendo en cuenta sus dependencias para seleccionar aquellas
historias que pueden generar una versión viable para el cliente con la
finalidad de que pueda ser lanzada al mercado lo antes posible. De igual
Universidad César Vallejo Escuela de Ingeniería de Sistemas
25 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
manera se definen con mayor precisión las historias de usuario y cuáles
serán las actividades de la misma.
- Reuniones Diarias: Reuniones cortas (15 a 20 minutos) en las que se
habla del trabajo realizado el día anterior, expectativas del día actual y
errores inesperados.
De igual manera información relevante para el desarrollo debe ser
mencionada en estas reuniones constantemente, como cualidades
importantes de la plataforma o virtudes importantes de librerías móviles
utilizadas, y entre otras cosas, cualidades que ayuden a los desarrolladores
a evitar errores frecuentes. Es posible que en algunas reuniones el cliente
este presente para aclarar dudas o ayudar a definir cuestiones de diseño.
Por lo general, cuando esto ocurre es posible que la reunión se prolongue
más tiempo.
- Reuniones de Revisión: En estas reuniones el cliente prueba las funciones
de la aplicación móvil que fueron desarrolladas en el sprint, se toman en
cuenta aspectos importantes que surgieron durante el desarrollo que
puedan servir por el resto del proyecto y se usa la retroalimentación del
cliente para indicar posibles cambios dentro de la aplicación y verificar la
satisfacción del mismo en cuanto al producto obtenido.
- Retrospectiva del Sprint: Para el desarrollo móvil esta puede ser la
reunión más importante, porque en ellas el equipo decide en función de la
experiencia recibida en el sprint, que historias de usuarios deben
permanecer, ser agregadas o quitadas de la actual versión en desarrollo. Se
debe tomar en cuenta la importancia de las historias de usuario para el
cliente, como va fluyendo el desarrollo de los ciclos y el tiempo
transcurrido del proyecto para decidir cuándo sacar o dejar una historia de
usuario para una versión determinada. Si el desarrollo presenta retrasos,
probablemente el equipo deba optar restringir la próxima versión a las
historias de usuario claves, y posponer aquellas de priorización media o
baja para posteriores versiones o actualizaciones. Si el desarrollo se ha
venido dando más rápido de lo esperado, es posible que nuevas historias
de usuarios puedan entrar en la versión actual con la finalidad de proveer
más funciones en una misma versión.
Gestión de un Sprint: Para guiar el desarrollo dentro del sprint la metodología se basará en las
distintas técnicas justo a tiempo que fueron seleccionadas en el capítulo
anterior para gestionar el desarrollo de cada una de las tareas.
- Descripción de Fases: Basándose en el modelo visual de Kanban clásico (Figura N° 6), el equipo
de desarrollo utilizó una pizarra de tareas para conocer cómo fluye el
trabajo.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
26 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 6
Fases de Kanban Clásico
Las historias de usuario totales del proyecto y de las que son seleccionadas en el
sprint actual, la primera fase del modelo clásico de Kanban (Trabajo por hacer)
estuvo divida en dos: Historias de Usuario del Proyecto e Historias de Usuario
del Sprint. Con la finalidad de observar los colores para conocer su prioridad a
simple vista, con la diferencia de que las historias de usuario del sprint estarán
dividas en las tareas necesarias para que se pueda desarrollar esa historia de
usuario. De esta forma, las tareas mantienen una referencia de su historia de
usuario y son dichas tareas las que fluyen por el trabajo en progreso. El modelo
ahora se plantea como se visualiza en la figura N° 7.
Figura N° 7
Fases Primarias del Modelo
En la fase de Historias de Usuario del Sprint se deben colocar en la pizarra las
historias de usuario y también hacer uso de la Reunión de Planificación con el
cliente. En estas charlas, a través de preguntas, el equipo debe documentar la
descripción de la historia de usuario con mayor claridad, sus posibles
Rec
uper
ador
de:
htt
p:/
/ww
w.c
risp
.se/
file
-
uplo
ads/
Kan
ban
-vs-
Scr
um
Rec
uper
ado d
e: h
ttp
://w
ww
.cri
sp.s
e/fi
le-
uplo
ads/
Kan
ban
-vs-
Scr
um
Universidad César Vallejo Escuela de Ingeniería de Sistemas
27 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
condiciones de satisfacción y tareas que sean descompuestas de dicha historia.
De igual forma el documento debe indicar si la historia es nueva, es una mejora
de alguna función o es para corregir algún error detectado. Este documento debe
estar revisado y aprobado tanto por el cliente como por el encargado de gestionar
la historia de usuario (posiblemente líder del proyecto). Debe manejarse un
documento de este tipo (Ver tabla N° 6) para cada historia incluida en el sprint,
con el propósito de facilitar no solo la toma de decisiones con respecto a cada
historia sino también el proceso de validación con el cliente una vez que la
historia este implementada.
Tabla N° 6 Formato de Descripción de Historia de Usuario
Fuente: Elaboración Propia
De igual forma las tareas que se descomponen de alguna historia de usuario
deben mantener el color indicando la prioridad de la historia, nombre de la tarea,
número de identificación con la historia, indicar (si es posible) todas las
dependencia que tenga esa tarea con respecto a las demás y en caso de que
alguien esté trabajando sobre esa tarea, se debe indicar el desarrollador que lo
hace. Se recomienda el uso de stickers manteniendo un formato parecido a la
figura N° 8 (asumiendo que el color rojo representa alguna prioridad, todo
dependerá de los colores que utilicen los equipos para determinar sus
prioridades):
Figura N° 8
Formato de Tareas
©E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
28 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Luego de contar con dos fases determinadas a manejar visualmente las historias
de usuario y tareas, la fase del trabajo en progreso se nota un poco general. Para
desarrollar aplicaciones móviles dicha fase estará dividida en 3 subfases.
Diseño Móvil: Tomando en cuenta Mobinex V4 (2009) el diseño de
aplicaciones móviles debe estar dirigido a dos secciones. La primera debe ir
orientada al aspecto visual de la aplicación (front-end), es decir, utilizar las
Reuniones Diarias para que el equipo de desarrollo en conjunto con el cliente
defina una serie de Story Boards que muestren una idea de cómo deben ser
las interfaces que se desarrollarán más adelante. Esta técnica promueve la
creatividad del usuario y con la ayuda de algún integrante del equipo se
aclaran de forma más sencilla las interfaces de usuario. Para realizar los Story
Boards se puede utilizar un formato como el que se muestra en la figura N° 9.
Por el otro lado, se encuentran los diseños referentes a la sección detrás de la
aplicación (back-end), es decir, las estructuras que permitan manipular la
información de forma dinámica si es necesario. Estas estructuras pueden estar
basadas en modelos cliente/servidor, Stub Service o Servicios Online. Esto se
puede definir a través de modelos entidad relación, modelos relacionales,
casos de uso o diagramas de flujo de datos (de bajo nivel) o flujogramas de
ser necesario. De igual forma en estos documentos se deben indicar que
servicios serán los utilizadas para implementar la aplicación, tales como
Servicios WEB, JSON u otros y podrían contar con un listado de mensajes de
errores en caso de alguna falla en particular.
Figura N° 9
Formato de Story Boards.
Planificación de Pruebas: El modelo debe contar con técnicas que
promuevan la fácil detección de errores, ya que entre más rápido se detecta un
Rec
uper
ado d
e:
htt
p:/
/ww
w.s
crum
man
ager
.net
/fil
es/s
m_pro
yec
to.p
df
Universidad César Vallejo Escuela de Ingeniería de Sistemas
29 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
error, más fácil es corregirlo. Haciendo uso de Jidoka la segunda fase la
conformarán la planificación de las pruebas de unidad y de integración, para
contar con un mecanismo que permita alertar ante posibles situaciones
erróneas y poder plantear una solución de respuesta a dicha situación lo antes
posible. Estas pruebas deben ser bastante simples para que puedan ejecutarse
con facilidad en cualquier momento durante el sprint (en especial durante la
implementación). El siguiente formato de la figura N° 10 permitió registrar
los casos utilizados para las pruebas de unidad y ya que las pruebas de
integración están conformadas por la unión de todas las pruebas de unidad,
los casos de pruebas unitarias contaban con una sección que les permitió
registrar resultados en la fase de integración, pudiendo evaluar las pruebas de
unidad como un conjunto. Las pruebas de unidad deben indicar la tarea que
identifican, historia de usuario a la cual pertenece esa tarea, diseñador de la
prueba, modelo de dispositivos donde se ejecutó las pruebas, y versiones de
Sistemas Operativos (Descritos en el documento de inicio) además de las
entradas de cada caso de prueba y los resultados esperados. Es importante
resaltar que el equipo de desarrollo debe manejar niveles de gravedad en los
casos donde se detecten errores, Mobile-D maneja los niveles de error
superficial, error menor y error mayor.
Figura N° 10
Formato de Pruebas de unidad
Implementación: Por último, dentro del trabajo en progreso, está la fase de
implementación donde se implementaron todas las tareas del sprint. En esta
fase del desarrollo el programador pudo contar con las pruebas de unidad para
Rec
uper
ado d
e:
htt
p:/
/ww
w.s
crum
man
ager
.net
/fil
es/s
m_pro
yec
to.p
df
Universidad César Vallejo Escuela de Ingeniería de Sistemas
30 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
poder ejecutarlas en cualquier momento. De esta forma el programador no
solo conoce lo que debe realizar para implementar la tarea como lo espera el
cliente, sino que pudo detectar fallas en su código rápidamente. De igual
forma la parte de implementación está compuesta por dos subfases como lo
plantea Mobinex V4 (2009):
- Implementación de Interfaces de Usuario: El primer paso dentro de la
implementación está dirigido a las interfaces de usuario. Con la ayuda del
documento de descripción de la historia y los Story Boards, el
programador mantiene una visión de cómo deben lucir las interfaces y los
elementos que esta debe contener. Ahora bien, ya que los Story Boards no
mostrarán con exactitud como lucirá la interfaz al final del desarrollo (ya
que son bocetos hechos a mano), el programador debe hacer uso de las
Reuniones Diarias para mostrar las interfaces al cliente, y de esta forma
dicho cliente deba aprobarlas para continuar con el desarrollo. Así, el
equipo minimiza las posibilidades de cambios al final del sprint y es más
sencillo garantizar la satisfacción del cliente.
- Implementación de Servicios e Integración de Tarea: En esta fase el
equipo de desarrollo no solo hace uso del documento de descripción de la
historia, diagramas de diseño de servicios (Modelo E-R, Casos de Uso,
entre otros) y documentos de pruebas, sino también de las interfaces
implementadas. De esta manera, el equipo está claro en cómo crear las
estructuras ya que conoce con exactitud como los datos serán manipulados
por las interfaces. Una vez que los ambas partes han sido desarrolladas
(interfaces y servicios), el programador debe integrarlas asegurándose que
al final, la tarea ya implementada pase la prueba de unidad respectiva.
Figura N° 11
Fases de Trabajo en Progreso.
Para la fase final de trabajo realizado, será necesario hacer una pequeña pero
importante modificación. En muchas situaciones será necesaria la integración de
diversas tareas para culminar una función o historia, es por ello que una vez que
las tareas son desarrolladas y probadas individualmente, estas deben culminar en
una fase de integración para completar la implementación de la historia de
usuario. En esta fase de la metodología se usarán los documentos de prueba para
Rec
uper
ado d
e:
htt
p:/
/ww
w.s
crum
man
ager
.net
/fil
es/
sm_p
royec
to.p
df
Universidad César Vallejo Escuela de Ingeniería de Sistemas
31 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
verificar que no existen errores luego de la integración de tareas (para formar
una historia), los cuales detectarán si existe algún inconveniente en dicha
integración, la figura N° 11, describe el progreso de trabajo de esta fase. En
algunos casos, pueden existir situaciones donde las historias necesiten ser
integradas para mostrar al cliente el software funcional como un todo, en esta
fase esa integración también se debe llevar a cabo antes de pasar al trabajo
realizado. Los resultados de las pruebas de integración deben quedar
documentados ya que los errores detectados y corregidos a través de estas
pruebas difícilmente pueden ocurrir nuevamente si el equipo mantiene un
registro de ellos, de igual forma ante problemas similares en el futuro, estas
pruebas de integración pueden servir de patrón.
Una vez que las historias llegan a la última fase de trabajo realizado, el equipo
debe mantener información de los errores que contenga esa historia que no
pudieron ser corregidos a tiempo si llegase a tenerlos. Esta información en
conjunto con las descripciones de tareas y casos de prueba puede ser utilizada en
las distintas reuniones para platear estrategias de solución entre los
desarrolladores.
De esta forma el modelo basado en Kanban quedará como se visualiza en la
figura N° 12:
Figura N° 12
Modelo culminado Kanban.
b) Lenguaje de programación
Para Josep (2007) un lenguaje de programación es como un “conjunto de símbolos
y textos inteligibles por la unidad de programación que le sirve al usuario para
codificar sobre un cierto autómata las leyes de control deseadas, mientras que
lenguaje de exploración será el conjunto de órdenes y comandos que el usuario
puede enviar desde la misma unidad o desde un terminal” (p.195).
Son tantos lenguajes de programación que se utilizan comúnmente para crear sitios
web. A diferencia de las páginas HTML estáticas habituales, sitios web ASP y PHP
son más dinámicos y pueden permitir a los usuarios interactuar e intercambiar
Rec
uper
ado d
e:
htt
p:/
/ww
w.s
crum
man
ager
.net
/fil
es/s
m_
pro
yec
to.p
df
Universidad César Vallejo Escuela de Ingeniería de Sistemas
32 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
información a través de bases de datos desde el sitio web, en la siguiente tabla se
hace una comparación entre estos dos lenguajes de programación.
Tabla N° 7 Lenguaje de Programación
ASP.Net PHP
- ASP (Active Server Pages)
necesita un servidor de
Microsoft para que el sitio web
funcione.
- ASP sólo puede trabajar con las
plataformas basadas en
Window. Recientemente, ASP
ahora se puede ejecutar en una
plataforma Linux dado que no
existe un programa de ASP-
Apache instalado en su servidor.
- ASP es muy similar a la sintaxis
y la interfaz de programación
Visual Basic. Esto es
básicamente debido a que
Visual Basic está relacionada
básicamente con los productos y
los programas de Microsoft.
- Cuando se trata de los costos y
gastos, ASP necesita para
funcionar en Windows con IIS
instalado en el servidor. Es
necesario comprar este
componente. Además pueda que
tenga que comprar herramientas
adicionales.
- ASP utiliza un servidor de
gastos generales y se utiliza una
arquitectura basada en COM.
- En términos de conectividad de
base de datos ASP necesita de
MS-SQL, un producto de
Microsoft, el cual implica un
costo.
- PHP o Hypertext Preprocessor, corre
con Linux o UNIX. Los programas
PHP más actualizados ahora se
pueden ejecutar en un servidor NT.
- Programas PHP también se puede
ejecutar en Windows, Solaris, Unix y
Linux.
- PHP sólo requeriría que se ejecuta en
un servidor Linux, que se puede
obtener sin costo alguno.
- PHP es muy flexible en términos de
conectividad de base de datos. Se
puede conectar a varias bases de datos
de los cuales el más utilizado es el
MySQL, cuyo costo para usar es cero.
- Códigos PHP se ejecuta mucho más
rápido que ASP, básicamente, porque
se ejecuta en su propio espacio de
memoria.
- Al trabajar con PHP, la mayoría de las
herramientas relacionadas con el
programa son el software de código
abierto en su mayoría por lo que no
tiene que pagar por ellos.
Fuente: http://www.aspvsphp.com/
Universidad César Vallejo Escuela de Ingeniería de Sistemas
33 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 8 Criterio de selección del lenguaje de programación
CRITERIOS PHP ASP.Net Total
Posee documentación
adecuada 18.33 11.66 29.99
Grado de conocimiento 15 10 25
Posee el código abierto 20 11.66 31.66
Soporte en varias
plataformas 18.33 15 33.33
Requiere definición de
variables 15 15 30
Soporte gran cantidad de
base de datos. 18.33 11.66 29.93
Total : 104.99 74.98
Fuente: Elaboración Propia
En conclusión, tanto en PHP y ASP tienen sus propias ventajas y desventajas como
se puede visualizar en la tabla N° 7. Además se elaboró un cuadro de criterios de
selección del lenguaje de programación realizado a tres expertos (Ver anexos 12, 13
y 14), siendo PHP el lenguaje de programación con el mayor puntaje obtenido (Ver
tabla N° 8) y el que mejor se ajusta a los requerimientos de la aplicación web. PHP
ha sido elegido para el desarrollo de la aplicación web para el proceso de atención
de llamadas de emergencias en la comisaria de Santa Luzmila en el distrito de
Comas.
c) Sistema Gestor de Base de Datos
Un sistema gestor de base de datos permite definir los datos a los distintos niveles
de abstracción (físico, lógico y externo), permite la manipulación de los datos en la
base de datos, accede a la opción de insertar, modificar, borrar y consultar los datos,
control de la privacidad y seguridad de los datos en la base de datos, Nevado (2008,
p.32).
Funciones de un SGBD Las funciones principales de un SGBD son las de descripción, manipulación y
control:
Función de definición.- Va a permitir al diseñador de base de datos especificar
los elementos que la integran, su estructura y las relaciones que existen entre
ellos, las reglas de integridad semántica, etcétera, así como las características
de tipo físico y las vistas lógicas de los usuarios. Esta función la realiza el
Lenguaje de Definición de Datos (DDL), que es propio de cada SGBD.
Función de manipulación.- Después de describir los datos, es necesario
cargarlos en las estructuras previamente creadas, para posteriormente poder
utilizarlos. Los usuarios podrán recuperar la información o actualizarla.
Función de control.- Debe de integrar una serie de instrumentos para facilitar
la tarea del administrador. Permite funciones de servicio como: cambiar la
capacidad de los ficheros, obtener estadísticas de utilización y funciones de
seguridad tales como:
Universidad César Vallejo Escuela de Ingeniería de Sistemas
34 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
- Copias de seguridad.
- Reiniciar el sistema.
- Protección frente a accesos no autorizados.
Tabla N° 9 Gestor de base de Datos
SQL Server MySQL Oracle
- Vienen en diferentes
tipos de paquetes.
- Se basa en la tecnología
de clústeres de
Microsoft.
- Solo tiene un sistema de
almacenamiento para
todo.
- Facilidad de instalación,
distribución y
utilización.
- Posee una gran variedad
de herramientas
administrativas y de
desarrollo que permite
mejorar la capacidad de
instalar, distribuir,
administrar y utilizar.
- Escalabilidad,
estabilidad y seguridad.
- Soporta procedimientos
almacenados.
- Incluye también un
potente entorno gráfico
de administración, que
permite el uso de
comandos DDL y DML
gráficamente.
- T-SQL (Transact-SQL)
es el principal medio de
programación y
administración de SQL
Server.
- Facilidad de instalación.
- Viene en una sola
versión o paquete.
- Multiproceso, es decir
puede usar varias CPU,
si éstas están
disponibles.
- Sistema de contraseñas
y privilegios muy
flexibles y seguros.
- Bajo costo en
requerimientos para la
elaboración de base de
datos, ya que debido a
su bajo consumo puede
ser ejecutado en una
maquina con escasos
recursos sin ningún
problema.
- Su conectividad,
velocidad, y seguridad
hacen de MySQL
Server altamente
apropiado para acceder
a bases de datos en
internet.
- Baja probabilidad de
corromper datos,
incluso si los errores no
se producen en el
propio gestor, sino en el
sistema en el que está.
- Conformidad con los
estándares en el nivel de
entrada SQL
correlacionado y permite
las sub consultas
correlacionadas.
- Virtuales de SQL
estructuras de la lengua
como las vistas y los
sinónimos (Muy bueno).
Muchos parámetros
permiten un control
preciso de la secuencia.
- Conversión automática de
páginas de códigos (por
ejemplo, entre cliente y
servidor).
- Capacidad para dar
servicio a una gran
cantidad de conexiones en
paralelo a una base de
datos - el uso de
multitheaded servidor.
- Idiomas para escribir
procedimientos
almacenados: PL/SQL y
Java.
- El usuarios está
identificado en la base de
inicio de sesión y
contraseña, también hay
posibilidad de utilizar el
sistema operativo de nivel
de autorización.
Fuente: Elaboración Propia
En la tabla N° 9 se hace una comparación entre los principales gestores de base de
datos.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
35 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 10 Criterio de selección del gestor de Base de Datos
CRITERIOS SQL Server MySQL Oracle Total
Rapidez del servidor
relacional de base de datos 16.66 13.33 11.66 41.65
Trabajo en entornos cliente
servidor 18.33 16.66 15 49.99
Accesibilidad 18.33 13.33 11.66 43.32
Control de accesos de
usuarios 16.66 11.66 13.33 41.65
Soporta en diferentes
sistemas operativos 13.33 11.66 10 34.99
Probabilidad de corromper
datos 11.66 11.66 13.33 36.65
Manejo sencillo 15 15 10 40
Total : 109.97 93.30 84.98
Fuente: Elaboración Propia
Se realizaron las evaluaciones a tres expertos (Ver anexo 15, 16 y 17), para
determinar el uso del gestor de base de datos, obteniendo como resultado a SQL
Server como el puntaje más alto (Ver tabla N° 9), por tal motivo se eligió el sistema
gestor de base de datos SQL Server para la elaboración de la base de datos.
2.2 Marco Conceptual.
Sistema de Comunicación Móvil A-GPS.
Un Assisted GPS es una tecnología popular que mejora el GPS convencional,
especialmente en el área de redes de telefonía móvil. En sistemas A-GPS, la
información útil se proporciona por la red celular que puede ayudar al receptor del
GPS para calcular una posición precisa más rápidamente. A-GPS utiliza información
de más de una fuente, mientras que el cálculo de la posición del dispositivo, así lo
define Zandbergen y Barbeau (2011, p. 383).
Proceso de atención de llamadas de emergencias
Las llamadas de emergencia son una función crítica del sistema telefónico actual; ya
no son una característica opcional. Con el fin de obtener ayuda en caso de
emergencia, la gente intuitivamente para llegar al teléfono más cercano y llamar a un
número de emergencia conocido, según Heinz y Barnes (2010, p. 9).
Universidad César Vallejo Escuela de Ingeniería de Sistemas
36 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
III. MARCO METODOLÓGICO
3.1 Hipótesis
3.1.1 Hipótesis General:
El sistema de comunicación Móvil A-GPS mejora el proceso de atención
de llamadas de emergencias en la comisaría de Santa Luzmila en el distrito
de Comas.
3.1.2 Hipótesis Específicas:
H-1 El sistema de comunicación Móvil A-GPS reduce el tiempo de
respuesta de la Policía en la atención de llamadas de emergencias en la
comisaría de Santa Luzmila del distrito de Comas.
H-2 El sistema de comunicación Móvil A-GPS reduce el porcentaje de
registros de alertas falsas en la comisaría de Santa Luzmila en el distrito de
Comas.
3.2 Variables
3.2.1 Definición Conceptual:
Se han determinado las siguientes variables:
Variable Independiente (VI):
Sistema de Comunicación Móvil A-GPS.- Es una tecnología
popular que mejora el GPS convencional, especialmente en el área
de redes de telefonía móvil. En sistemas A-GPS, la información útil
se proporciona por la red celular que puede ayudar al receptor del
GPS calcular una posición precisa más rápidamente Zandbergen y
Barbeau (2011, p. 383).
Variable Dependiente (VD):
Proceso de atención de llamadas de emergencias.- Para Heinz y
Barnes (2011, p. 9), una llamada de emergencia es con frecuencia la
acción que inicia una respuesta de emergencia, pero rara vez es la
única forma de comunicación que tiene lugar como parte de esa
respuesta. Además de la llamada de emergencia, operarios, personal
de emergencia, y otras entidades que se comunican entre sí, y a
veces es necesario enviar alertas a otros individuos.
3.2.2 Definición Operacional:
“Los indicadores son factores determinantes para todo proceso, llámese
logístico y de producción, para que se lleve a cabo con éxito, se debe
Universidad César Vallejo Escuela de Ingeniería de Sistemas
37 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
implementar un sistema adecuado de indicadores para medir la gestión de
los mismos” (Mora, 2008, p. 102).
Sistema de Comunicación Móvil A-GPS.
Sistema de comunicación móvil A-GPS que gestiona el proceso de
atención de llamadas de emergencias en una institución, permitiendo la
comunicación directa entre el ciudadano y los efectivos policiales,
consulta de incidencias y reportes.
Para ello utiliza la tecnología, el sistema gestor de base de datos, el
software adecuado, todo ello conforma el sistema elaborado siguiendo
una metodología adecuada.
Proceso de atención de llamadas de emergencias
El proceso de atención de llamadas de emergencias está conformado
por procesos, a su vez es medible las dimensiones en estudio, y para
cálculo de los indicadores es necesario realizar mediciones al tiempo de
respuesta de la policía ante las llamadas de emergencia, porcentaje de
registros de alertas falsas, lo cual es obtenido de las fichas de
observación, entrevistas a los encargados de la institución.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
38 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Operacionalización de Variables
En la siguiente tabla N° 11 se explica las definiciones correspondientes:
Tabla N° 11 Operacionalización de Variables
Fuente: Elaboración Propia.
TIPO DE
VARIABLE
VARIABLE DEFINICIÓN OPERACIONAL DIMENSIÓN DESCRIPCIÓN INDICADOR DESCRIPCIÓN
INDICADOR
VARIABLE
INDEPENDIENTE
Sistema de
Comunicación
Móvil A-GPS
Sistema de comunicación móvil
A-GPS que gestiona el proceso
de atención de llamadas de
emergencia en una institución,
permitiendo la comunicación
directa entre el ciudadano y los
efectivos policiales.
VARIABLE
DEPENDIENTE
Proceso de
atención de
llamadas de
emergencia.
El proceso de atención de
llamadas de emergencia está
conformado por procesos, a su
vez es medible las dimensiones
en estudio, y para cálculo de los
indicadores es necesario realizar
mediciones al tiempo de
respuesta de la policía ante las
llamadas de emergencia,
porcentaje de registro de alertas
falsas, lo cual es obtenido de las
fichas de observación,
entrevistas a los encargados de
la institución.
Tiempo
El proceso de
atención de
llamadas de
emergencia consiste
en atender a la
brevedad posible
ante una incidencia
que ponga en
peligro la integridad
de las personas así
como de los bienes.
Tiempo de
respuesta de
la policía
Determina el tiempo de
respuesta de la policía
ante una llamada de
emergencia que realizan
los ciudadanos.
Porcentaje de
alertas falas
Cuando el efectivo
policial registra las
llamadas como
perturbadoras o
falsas.
Porcentaje
de registro
de alertas
falsas
Determina el porcentaje
de registros de alertas
falsas en el proceso de
atención de llamadas de
emergencia.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
39 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
3.2.3 Indicadores:
Tabla N° 12 Indicadores
VARIABLE
INDICADOR
DESCRIPCIÓN
TÉCNICA
INSTRUMENTO
UNIDAD DE
MEDIDA
FÓRMULA
Proceso de
atención de
llamadas de
emergencia.
Tiempo de
respuesta de
la policía
Determina el tiempo
empleado en la
respuesta de la
policía ante una
llamada de
emergencia.
Observación
Ficha de
observación
(Cronómetro)
Minutos
Trp: Tiempo de respuesta de la policía
Hip: Hora de intervención policial
Hrll: Hora de recepción de llamada.
Porcentaje de
registro de
alertas falsas
Determina el
porcentaje de
registros de alertas
falsas.
Observación
Ficha de
observación
(Contador)
Porcentaje
Praf: Porcentaje de registro de alertas
falsas.
Nraf: Número de registros de alertas
falsas.
Ntra: Número total de registros de
alertas.
Fuente: Elaboración Propia.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
40 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
3.3 Metodología.
3.3.1 Tipo de Estudio.
La presente investigación es de tipo experimental, basada en la causa y el
efecto. Se trata de una intervención por parte del investigador, que introduce
una variable y registra su efecto. Diseños experimentales de investigación
permiten al investigador controlar o manipular una o más variables en un
esfuerzo para examinar la relación entre las variables. Variables típicamente
son designadas como dependiente e independiente. La variable independiente
es la variable controlada o manipulada por el investigador. La variable
dependiente se produce como resultado de la influencia de la variable
independiente. En otras palabras, la variable dependiente refleja los efectos de
la variable independiente, así lo define Gropper, Smith y Groff (2009, p. 568).
Según Tamayo (2004) el objeto de estudio en la presente investigación es de
tipo Aplicada, ya qué se implementa el sistema de comunicación móvil con el
fin de medir su influencia en el proceso de atención de llamadas de
emergencias en la comisaría la Santa Luzmila y así comprobar las hipótesis
planteadas mediante los indicadores formulados y de este modo beneficia a
una sociedad, es así como lo describe (p. 43).
3.3.2 Diseño de Investigación.
Son los que permiten un control muy escaso o nulo de las variables extrañas,
por lo cual tienen muchas fuentes de invalidez interna, como el diseño de un
grupo con pre-prueba y pos prueba y el diseño estático de dos grupos, de esta
manera lo define Hurtado y Toro (2007, p. 104).
1. Diseño Pre-experimental de un grupo con pre prueba y pos prueba:
Casi siempre consta de tres etapas: La administrar una prueba preliminar
para medir la variable dependiente, 2ª aplicar el tratamiento experimental
"X" a los sujetos, 3ª administrar un pos prueba que mida otra vez la
variable dependiente.
2. Diseño pre-experimental estático, de dos grupos: "consta de dos grupos, y
solo uno es sometido al tratamiento experimental o variable independiente.
Para la presente investigación se utilizó el diseño Pre experimental de un
grupo con pre prueba y pos prueba, en la tabla N° 13 se resume el tipo de
estudio utilizado.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
41 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 13 Diseño de Estudio Pre Experimental
Diseño Especificaciones
O1 X O2
Pre test Aplicación de la variable experimental Pos test
Dónde:
O1= Proceso de atención de
llamadas de emergencias
antes de la aplicación.
X= Aplicación del Sistema
de Comunicación Móvil
A-GPS.
O2= Proceso de atención de
llamadas de emergencias
después de la aplicación.
Fuente: Elaboración Propia
3.3.3 Desarrollo de la Metodología.
A continuación se describe el caso de estudio y como se aplicó la
metodología propuesta en el desarrollo de una aplicación móvil. Varios
sprints de la metodología fueron desarrollados y todos los productos a lo
largo de esos sprints tanto en documentación como en software funcional
fueron implementados.
A) Grupo de Trabajo:
En el desarrollo del proyecto de caso de estudio estuvieron presentes 2
desarrolladores, 2 asesores y un cliente como se muestra en la tabla N° 14:
Tabla N° 14 Grupo de Trabajo
Nombre Rol
Carlomagno López Chávez Desarrollador Líder (ScrumMaster)
Elvis Regalado Guerrero Team (Equipo Desarrollador)
May. Gilmer Torres Carrera Product Owner - Cliente (Comisario)
Mg. Mónica Díaz Reátegui Asesor Metodológico
Ing. Percy Rubén Bravo Baldeón Asesor Temático
Fuente: Elaboración Propia.
B) Información de Iniciación del Proyecto:
Información de la empresa o cliente: Comisaría Santa Luzmila del distrito de
Comas.
Nombre Comercial de la Aplicación: Sis-CoMóvil A-GPS.
Plataforma donde se ejecutará la aplicación: Todas aquellas que contengan
navegador web que puedan ejecutar JQuery Mobile.
Modelos de dispositivos móviles: Todos aquellos que utilicen Sistema
Operativo Android versión superior a 2.2
Tipo de aplicación: Aplicación móvil y Web.
C) Historias de Usuario: Las historias de usuario definidas por el cliente en colaboración con el equipo
de desarrollo tomaron en cuenta los valores “Media”, “Alta” y “Muy Alta”
para definir la prioridad del cliente. Por otro lado, los valores utilizados por el
Proceso de
atención de
llamadas de
emergencias.
Proceso de
atención de
llamadas de
emergencias.
Aplicación de
un sistema de
comunicación
móvil A-GPS.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
42 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
equipo de desarrollo para definir los puntos de historias (Complejidad) en
cada historia fueron los valores comprendidos entre 0 y 21 de la sucesión de
Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21). A continuación se encuentran descritas
las historias de usuario con su información de interés:
1. Registrar Usuario: Cualquier persona que cuente con un correo
electrónico, documento de identidad y un celular con tecnología GPS
puede ser capaz de registrase en la base de datos del Sis-CoMóvil.
2. Confirmación de Registro: El usuario registrado para tener habilitado su
cuenta deberá confirmar su activación de cuenta vía el correo que fue
ingresado.
3. Registro Personal Policial: El usuario Administrador podrá registrar y
actualizar los datos de los efectivos policiales de la comisaria.
4. Validación de acceso: El usuario registrado podrá descargar e instalar la
aplicación móvil en su celular y acceder al Sis-CoMóvil previo logueo
donde el login es el documento de identidad y la clave es la que registró.
5. Ubicación del Lugar de la Incidencia: El usuario registrado podrá
visualizar la ubicación actual cuando se presenta una incidencia.
6. Tipos de Alertas: El usuario registrado podrá enviar una alerta indicando
el tipo de alerta que está visualizando.
7. Envió de Alertas: El usuario registrado debe poder enviar desde su móvil
las incidencias a la central de recepción de alertas de la comisaria de Santa
Luzmila.
8. Enviar mensaje de alerta a Usuarios: El Operador debe poder enviar 2
tipos de mensajes al dispositivo móvil, a efectivos policiales que se
encuentran patrullando las calles y a un determinado usuario.
9. Atención de Alertas: Los efectivos policiales podrán atender las alertas
desde el dispositivo móvil, así mismo el administrador usuario podrá
atender las alertas desde la aplicación web.
10. Recuperar Contraseña: El usuario debe poder recuperar su contraseña
cuando lo solicite.
11. El Administrador: El usuario de tipo administrador debe poder tener
control total del Sis-CoMóvil para poder administrar los registros de los
usuarios, efectivos policiales y las alertas que son enviadas.
12. Reporte de Alertas: El usuario administrador podrá consultar los
reportes de las alertas registradas, así como conocer el tiempo de respuesta
ante una alerta.
Para completar la información descrita anteriormente, la tabla N° 15 indica el
resto de la información referente a cada historia de usuario, como sus
condiciones de satisfacción, Prioridad asignada por el cliente y Complejidad
reflejada en puntos de historia.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
43 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 15 Información de la Pila del Producto (Product Backlog)
Fuente: Elaboración Propia
La asignación de los tiempos a cada Sprint se puede ver al detalle en el
Cronograma de Desarrollo de la Aplicación (Ver anexo N° 21).
Hay que recordar que los valores de complejidad que asignó el equipo de
desarrollo pertenecen a la sucesión de Fibonacci y fueron definidos utilizando
la técnica Planning Poker descrita anteriormente. Mientras que las
condiciones de satisfacción surgieron de charlas con el cliente para aclarar
con mayor precisión la función que comprenden las historias de usuario.
D) Release Plan: Con las historias de usuario definidas, el cliente participó en la elaboración
del release plan con el propósito de conocer como (al inicio del proyecto) se
esperaba que se diera el orden de desarrollo de las historias, la tabla N° 16
detalla el Release Plan.
ID Nombres de las
Historias
Condiciones de
Satisfacción
Prioridad
del Cliente
Complejidad del
Equipo (Puntos
de Historia)
Tiempo
(días)
1 Registrar Usuario - Determinar datos
principales.
Muy Alta 3 5
2 Confirmación de
Registro
- Determinar activación de
cuenta vía correo electrónico
Alta 5 4
3 Registro de
Personal Policial
- Poder registrar a los
efectivos policiales.
Media 3 4
4 Validación de
acceso
- Determinar identificación
de usuario registrado.
Alta 3 6
5
Ubicación del
lugar de
incidencia
- Determinar localización
actual de la incidencia.
- Ver ubicación en el mapa.
Muy alta
13
6
6 Tipos de Alertas - Asignar un tipo de alerta
para reportar la incidencia.
Alta
8
4
7
Envío de Alertas
- Poder enviar una alerta.
- Ver ubicación en el mapa
donde se produjo la
incidencia.
Muy Alta
8
8
8
Enviar mensaje
al celular
- Poder enviar un mensaje os
efectivos policiales que
patrullan.
- Poder enviar un mensaje a
un usuario que se está
atendiendo la alerta enviada.
Alta
13
6
9 Atención de alertas - Poder atender alertas. Muy Alta 8 10
10
Recuperar
Contraseña
- Poder recuperar la
contraseña del usuario.
Media
3 8
11 Administrador - Poder tener control total de
los registros.
Alta 3 8
12
Reporte de
Alertas
- Poder obtener reportes de
tipo de incidencias basados
en fechas.
Alta
13
9
Universidad César Vallejo Escuela de Ingeniería de Sistemas
44 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 16 Release Plan (Sprint Backlog)
Sprints Historias de Usuario Complejidad de
las Historias
Complejidad
del Sprint
Primera Versión
1
1-Registro de Usuarios 3
8 2-Confirmación de Registro 5
2
4-Validación de acceso 3
16 5-Ubicación del lugar de la
incidencia 13
3
6-Tipos de Alertas 8
16 7-Envío de alerta 8
4 9-Atención de alertas 13 13
Segunda Versión
5 12-Reporte de Alertas 8 8
6
8- Enviar mensaje al celular 13
16 3-Registro de Personal Policial 3
7
10-Recuperar contraseña 3
6 11-Administrador 3
Fuente: Elaboración Propia
E) Sprints:
Se debe mencionar, que el caso de estudio contó con el desarrollo de los
cuatro primeros sprint. Como se puede observar en el release plan, en el
primero fueron desarrolladas las historias 1 y 2 (Registro de usuarios y
Confirmación de Registro, respectivamente), mientras que en el segundo se
desarrolló la historia N° 4 y 5 (Validación de acceso y Ubicación del lugar de la
incidencia respectivamente), tomando en cuenta algunos cambios propuestos al
final del primer Sprint acerca de la historia de usuario 1, el tercer sprint
fueron desarrolladas las historias 6 y 7 (Tipos de alertas y Envío de alertas
respectivamente) y el cuarto sprint se desarrolló la historia 9 (Atención de
Alertas).
La idea que se mantenía para la primera versión de la app. (Ver release plan,
tabla N° 11) era la de contar con una aplicación en la cual el usuario
registrado pudiera enviar una alerta de incidencia, con los datos principales
(Lugar de incidencia y el tipo de alerta). Pero además, proveer ciertas
evidencias al momento que se suscita una emergencia, el equipo de desarrollo
y el cliente acordaron la modificación de la historia de usuario 7 (Envió de
alertas) al finalizar la primera versión. En la segunda versión la historia de
usuario 12 (Reporte de alertas) corresponde al quinto Sprint, con la finalidad
de poder medir los indicadores de la investigación.
Las historias de usuario 8 y 3 (Enviar mensaje al celular, Registro de Personal
Policial, respectivamente) para el sexto Sprint, y las historias 10 y 11
(Recuperar contraseña y Administrador, respectivamente) del sprint N° 7.
Como se hizo mención anteriormente las solicitudes de cambio aprobadas que
surgieron al finalizar el cuarto sprint también fueron tomadas en cuenta.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
45 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Haciendo uso de las reuniones de planificación, las historias seleccionadas
fueron pasadas a la fase de Historias de Usuario del Sprint donde el
documento de descripción de historia fue realizado y se definiría la
descomposición de tareas. La figura N° 13 muestra el estado del pizarrón al
iniciar el sprint con todas las tareas ya descompuestas.
Figura N° 13
Estado inicial de la pizarra – Primer Sprint
En ese entonces, la figura N° 13 refleja las historias de usuario 7 (Envío de
Evidencias) del sprint N° 5 y las historias de usuario 8 y 3 (Reporte de alertas y
Registro de Personal Autorizado, respectivamente) del sprint N° 6 permaneciendo
en espera por ser desarrolladas, manteniéndose ubicadas en la fase Historias
del Proyecto. En la siguiente fase, Historias del Sprint, se encontraban todas
las historias vinculadas al desarrollo del sprint actual, utilizando el color
amarillo para las historias de muy alta prioridad, rosadas las de alta prioridad
y verde aquellas tareas de prioridad media.
A continuación se detalla las historias de los usuarios con las tareas que
fueron asignadas a cada Sprint.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
46 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 14
.
Descripción detallada de la Historia: Registro de Usuarios.
Como se puede observar en la figura N° 14, la mayoría de la documentación
se manejó de forma manuscrita, con la finalidad de que se pudieran tener a la
mano rápidamente los documentos necesarios para el desarrollo de las tareas.
Siguiendo con la descripción detallada de la historia de usuario Registro de
Usuarios, en la sección de “Descripción de Condiciones de Satisfacción” se
encuentran definidas dos condiciones de satisfacción para especificar en lo
posible la historia de usuario y así, minimizar ambigüedades.
Registrar datos Personales.- Que las personas puedan ingresar sus datos
personales de forma obligatoria.
Determinar términos y condiciones de uso de la aplicación.- Que las
personas pueda conocer las clausulas establecidas para el uso de la
aplicación.
Por otro lado, la figura anterior también muestra las dos tareas referentes a la
historia de usuario Registro de Usuarios que fueron desarrolladas:
1.1. Validación de Datos.- Desarrollar la sección que los usuarios ingresen
todos los datos correctamente.
1.2. Términos y condiciones de uso de la aplicación.- Para poder ser
registrado es necesario aceptar los términos y condiciones del uso de la
aplicación.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
47 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Los stickers referentes a estas tareas se pueden observar en el pizarrón de la
figura N° 13, en la parte superior de la fase Historias del Sprint. Todos de
color rosado ya que su historia de usuario es de Alta Prioridad.
Una vez que las tareas se empezaron a desarrollar estas debían pasar por la
fase de Diseño Móvil, en la cual participaba el cliente a través de reuniones
diarias ayudando a definir los Story Boards. De igual forma, en la fase de
diseño móvil para la historia de usuario número 1 Registro de Usuarios, se
generó un caso de uso de cada tarea con el fin de complementar la
información referente a los Story Boards antes mencionada. Las herramientas
utilizadas en la fase de diseño móvil fueron Microsoft Visio 2010. A
continuación se presenta la información de diseño referente a cada tarea de la
historia de usuario Registro de Usuarios.
Figura N° 15
Diseño de tarea 1.1 – Validación de Datos
El diseño de la tarea se 1.1 Validación de datos se visualiza en el Story Board
de la figura N° 15, la cual indica que todos los campos son obligatorios para
el registro del usuario.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
48 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 16
Caso de Uso - Validación de Datos
En la figura N° 16 se visualiza el caso de uso para la tarea 1.1 Validación de
datos.
Todos los documentos de prueba fueron generados por el desarrollador Elvis
Regalado, que también mantuvieron un formato manuscrito para poder
brindar la información a los programadores y que los mismos puedan
manejarla libremente. A continuación se muestra el documento de prueba que
generó la tarea 1.1 de la historia de usuario número 1.
Figura N° 17
Pruebas de Unidad – Tarea 1.1
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
49 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Cada prueba de unidad dentro del sprint, contenía una serie de entradas de
caso de pruebas, una serie de respuestas esperadas para cada uno de esos
casos de pruebas, y unos resultados a la hora de integrar las tareas. De igual
forma si algún error era detectado, se debía notificar la gravedad del mismo
en la sección de Gravedad del Error, de lo contrario no aplica.
Una vez que una tarea supera la fase de planificación de pruebas, esta pasó
directamente a la fase de interfaces de usuario, de la cual solo se necesitaba la
autorización del cliente para pasar de fase, por lo que el cliente verificó la
interfaz usuario antes de que se desarrollaran los scripts del lado del servidor
y códigos de base de datos.
Figura N° 18
Interfaz concluida de la tarea 1.1 – Validación de datos.
En la figura N° 18 se puede visualizar la interface concluida de la tarea 1.1
(Validación de datos), quedando lista para integrar pero debía esperar la tarea
1.2 (Términos y condiciones de uso de la aplicación).
El diseño de la tarea se 1.2 Términos y condiciones del uso de la aplicación
se visualiza en el Story Board de la figura N° 19, es pre requisito para el
registro del usuario.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
50 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 19
Diseño de tarea 1.2 – Términos y condiciones del uso de la aplicación.
En la figura N° 20 se visualiza el caso de uso para la tarea 1.2 Términos y
condiciones del uso de la aplicación.
Figura N° 20
Caso de uso - Términos y condiciones del uso de la aplicación.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
51 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 21 se muestra el documento de prueba que generó la tarea 1.2
de la historia de usuario número 1.
Figura N° 21
Pruebas de Unidad – Tarea 1.2
La figura N° 22 muestra un estado del pizarrón donde la tarea 2.1 se
encuentra en estado de planificación (Historia de Usuario 2).
Figura N° 22
Pizarrón - Fases de Diseño y Pruebas
En la figura N° 23 se puede visualizar la interfaz concluida de la tarea 1.2
(Términos y condiciones de uso).
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
52 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 23
Interfaz concluida de la tarea 1.2 - Términos y condiciones del uso de la
aplicación.
Una vez que las tareas 1.1 y 1.2 fueron desarrolladas se procede a la
integración de las mismas y se garantiza a través de los resultados de las
pruebas de unidad, que no se generen errores en la integración, concluyendo
la historia de usuario 1 e iniciando la historia 2.
Figura N° 24
Descripción detallada de la Historia: Confirmación de Registro.
En la figura N° 24, se detalla la descripción de condiciones de satisfacción:
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
53 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Conformidad de Registro.-Que el usuario pueda obtener el link de
activación de la cuenta.
Por otro lado, la figura anterior también muestra la tarea Activación de cuenta
de Usuario referente a la historia de usuario Confirmación de Registro que
fueron desarrolladas:
2.1 Activación de cuenta de Usuario.-Desarrollar la sección en la cual se
pueda enviar al correo del usuario la dirección web para la activación de
la cuenta.
A continuación en la siguiente figura se visualiza el Story board del diseño
referente a la tarea Activación de cuenta de usuario de la historia de usuario
Confirmación de Registro.
Figura N° 25
Diseño de tarea 2.1 – Activación de Cuenta de Usuario.
Figura N° 26
Caso de uso - Activación de Cuenta de Usuario
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
54 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 26 se visualiza el caso de uso Activación de Cuenta de
Usuario, la cual permite al usuario activar su cuenta.
En la figura N° 27 se puede visualizar las entidades que se utilizaron en el
Modelo Lógico de las Historias de Usuarios 1 y 2 (Registro de Usuarios y
Confirmación de Registro respectivamente) correspondientes al Primer
Sprint, del mismo modo en la figura N° 28 se puede visualizar las entidades
del modelo Físico.
Figura N° 27
Entidades utilizadas en el Primer Sprint – Modelo Lógico.
Figura N° 28
Entidades utilizadas en el Primer Sprint – Modelo Físico.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
55 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 29
Pruebas de Unidad – Tarea 2.1
En la figura N° 29 se muestra el documento de prueba que generó la tarea 2.1
de la historia de usuario número 2.
Figura N° 30
Interfaz concluida de la tarea 2.1 – Activación de Cuenta de Usuario.
En la figura N° 30 se puede visualizar el link de activación que el usuario
recibe en su correo electrónico y posteriormente al ingresar al link muestra la
ventana de confirmación de registro del usuario, esto indica que la tarea 2.1
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
56 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
(Activación de cuenta de usuario) ha sido concluida. De esta forma culmina el
primer Sprint, dando inicio al siguiente Sprint.
Figura N° 31
Descripción detallada de la Historia: Validación de acceso.
En la figura N° 31, se detalla la descripción de condición de satisfacción:
Validar datos.-Que los datos ingresados por el usuario sean validados con
la base de datos.
Por otro lado, la figura anterior también muestra las tareas Inicio de sesión vía
móvil e Inicio de sesión vía web referente a la historia de usuario Validación
de acceso que fueron desarrolladas:
4.1. Inicio de sesión vía móvil.-Desarrollar la sección que permita a los
usuarios registrados puedan tener acceso a la aplicación móvil.
4.2. Inicio de sesión vía web.-Desarrollar la sección que permita ingresar por
la página web a los usuarios registrados para actualizar sus datos y descargar
la aplicación móvil.
A continuación en la siguiente figura se presenta la información del diseño
referente a las tareas de la historia de usuario Validación de acceso.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
57 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 32
Diseño de tarea 4.1 – Inicio de sesión vía móvil
Figura N° 33
Diseño de tarea 4.2 – Inicio de sesión vía web.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
58 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En las figuras N° 32 y 33 se visualiza los Story Board para las tareas Inicio de
sesión vía móvil y vía web respectivamente, ya que el usuario puede acceder
a la aplicación móvil y a la página web. Además en la figura N° 34 describe
el caso de uso para la historia validación de acceso.
Figura N° 34
Caso de uso para las tareas 4.1 y 4.2.
En las figuras N° 35 y 36 se muestran los documentos de prueba que generó
las tareas 4.1 y 4.2 de la historia de usuario número 4.
Figura N° 35
Prueba de Unidad – Tarea 4.1
© E
lab
ora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
59 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 36
Prueba de Unidad – Tarea 4.2
En la figura N° 37 y 38 se puede visualizar las tareas 4.1 y 4.2 (Inicio de
sesión vía Móvil e inicio de sesión vía web) concluidas.
Figura N° 37
Interfaz concluida de la tarea 4.1 – Inicio de sesión vía Móvil
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
60 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 38
Interfaz concluida de la tarea 4.2 – Inicio de sesión vía web
En la figura N° 38 se puede visualizar la tarea 4.2 concluida, el cual muestra
la interfaz de acceso a la aplicación web, para un usuario. De esta manera
concluye la historia de usuario 4 dando inicio a la siguiente historia de
usuario del segundo Sprint.
Figura N° 39
Descripción detallada de la Historia: Ubicación del lugar de incidencia.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
61 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 39, se detalla la descripción de condiciones de satisfacción:
Determinar localización actual.- Que los usuarios registrados puedan
conocer su posición actual (GPS-Geo localización).
Además, la figura anterior también muestra la tarea Ver ubicación actual
referente a la historia de usuario Ubicación del lugar de incidencia que fue
desarrollada:
5.1. Ver ubicación actual.-Una vez ingresado a la aplicación móvil el
usuario puede visualizar en el mapa la ubicación actual donde se encuentra
observando la incidencia.
A continuación en la siguiente figura, se presenta la información del diseño
referente a la tarea de la historia de usuario Ubicación del lugar de incidencia.
Figura N° 40
Diseño de tarea 5.1 – Ver ubicación actual
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
62 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 41 se visualiza el caso de uso de la tarea ver ubicación actual.
Figura N° 41
Caso de uso - Ver ubicación actual.
En la figura N° 42 se puede visualizar las entidades que se utilizaron en el
Modelo Lógico de las Historias de Usuarios 4 y 5 (Validación de acceso y
Ubicación del lugar de la incidencia) correspondientes al Segundo Sprint, del
mismo modo en la figura N° 43 se puede visualizar las entidades del modelo
Físico.
Figura N° 42
Entidades utilizadas en el Segundo Sprint – Modelo Lógico.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
63 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 43
Entidades utilizadas en el Segundo Sprint – Modelo Físico.
En la figura N° 44 se muestra el documento de prueba que generó la tarea 5.1
de la historia de usuario número 5.
Figura N° 44
Prueba de Unidad – Tarea 5.1
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
64 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 45
Interfaz concluida de la tarea 5.1 – Ver ubicación actual.
En la figura N° 45, se puede visualizar la tarea 5.1 concluida, en la cual el
usuario puede ver su ubicación actual. De esta forma culmina el segundo
Sprint, mediante la integración de las tareas de las historias de usuario 4 y 5,
en la figura N° 46 se puede apreciar estado final del segundo Sprint.
Figura N° 46
Estado final del segundo Sprint (Integración de Tareas).
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
65 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 47
Descripción detallada de la Historia: Tipos de alertas
En la figura N° 47, se detalla la descripción de condiciones de satisfacción:
Determinar Tipo de alerta.- Permitir que los usuarios puedan seleccionar
el tipo de alerta, esto se debe mostrar en un combo.
Además, la figura anterior también muestra la tarea Ver tipos de alertas
referentes a la historia de usuario Tipos de alertas que fue desarrollada:
6.1. Ver tipos de alertas.-Listar los tipos de alertas que manejan los efectivos
policiales.
En la figura N° 48 se presenta la información del diseño referente a la tarea
de la historia de usuario Tipos de alertas.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
66 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 48
Diseño de tarea 6.1 – Ver tipos de alertas
Figura N° 49
Caso de uso - Ver tipos de alertas.
En la figura N° 49 se puede visualizar el caso de uso de la tarea ver tipos de
alertas.
En la siguiente figura se muestra el documento de prueba que generó la tarea
6.1 de la historia de usuario número 6.
© E
labora
ción P
ropia
.
© E
lab
ora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
67 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 50
Prueba de Unidad – Tarea 6.1
Figura N° 51
Interfaz concluida de la tarea 6.1 – Tipos de Alertas.
En la figura N° 51, se puede visualizar la tarea 6.1 concluida, en la cual el
usuario puede seleccionar el tipo de alerta mediante un controlador
desplegable, de esta manera concluye la historia de usuario 6, dando inicio la
historia de usuario 7.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
68 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 52
Descripción detallada de la Historia: Envío de alertas.
En la figura N° 52, se detalla la descripción de condiciones de satisfacción:
Determinar ubicación.- Que los usuarios registrador puedan visualizar en
una mapa su ubicación actual
Listar tipo de alerta.- Que los usuarios registrados puedan seleccionar un
tipo de alerta.
Enviar alerta.- Que los usuarios puedan enviar una alerta con una
descripción.
Además, la figura anterior también muestra la tarea Enviar alerta referente a
la historia de usuario “Envío de alertas” que fue desarrollada:
7.1. Enviar alerta.- Los usuarios registrados puedan enviar alertas a la
comisaria de Santa Luzmila.
En la figura N° 53 se presenta la información del diseño referente a la tarea
de la historia de usuario Envío de aletas.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
69 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 53
Diseño de la tarea 7.1 – Enviar Alerta.
Figura N° 54
Caso de uso - Enviar alerta
En la figura N° 54 se puede visualizar el caso de uso de la tarea Enviar alerta,
en este proceso cabe resaltar que un efectivo policial puede comportarse
como un usuario normal, ya que tiene las mismas opciones de poder registrar
una incidencia.
En la figura N° 55 se puede visualizar las entidades que se utilizaron en el
Modelo Lógico de las Historias de Usuarios 6 y 7 (Tipos de Alertas y Envió
de Alerta) correspondientes al tercer Sprint, del mismo modo en la figura N°
56 se puede visualizar las entidades del modelo Físico.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
70 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 55
Entidades utilizadas en el Tercer Sprint – Modelo Lógico.
Figura N° 56
Entidades utilizadas en el Tercer Sprint – Modelo Físico.
En la siguiente figura se muestra el documento de prueba que generó la tarea
7.1 de la historia de usuario número 7.
Figura N° 57
Prueba de Unidad – Tarea 7.1
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
71 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 58
Interfaz concluida de la tarea 7.1 – Enviar Alertas
En la figura N° 58, se puede visualizar la tarea 7.1 concluida, en la cual el
usuario puede enviar una alerta desde su celular. De esta forma culmina el
tercer Sprint, mediante la integración de las tareas de las historias de usuario
6 y 7. A continuación se da inicio al cuarto Sprint.
Figura N° 59
Descripción detallada de la Historia: Atención de Alertas.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
72 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 59, se detalla la descripción de condiciones de satisfacción:
Registro de alertas ordenadas por fecha y hora.- De esta forma el
efectivo policial sabe que alerta es la más reciente.
Ver ubicación y detalles de la alerta.- Cualquier efectivo policial
registrado puede visualizar los detalles de cada alerta (DNI, celular, tipo de
alerta, IMEI estado, ubicación en un mapa).
Además, la figura anterior también muestra las tareas Listar alertas
registradas y Actualizar estado de alertas referentes a la historia de usuario
Atención de alertas que fue desarrollada:
9.1. Listar alertas registradas.- Listar las alertas actualizadas y ordenadas a
la más reciente.
9.2. Actualizar estado de alertas.- Los efectivos policiales registrados
pueden actualizar el estado de la alerta (Pendiente, Atendido y alerta Falsa).
En la figura N° 60 se presenta la información del diseño referente a la tarea
de la historia de usuario Atención de alertas.
Figura N° 60
Diseño de la tarea 9.1 - Listar alertas registradas.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
73 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 61 se puede visualizar el caso de uso de la tarea Listar Alertas
Registradas.
Figura N° 61
Caso de uso - Listar Alertas Registradas.
En la siguiente figura se muestra el documento de prueba que generó la tarea
9.1 de la historia de usuario número 9.
Figura N° 62
Prueba de Unidad – Tarea 9.1
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
74 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 63
Interfaz concluida de la tarea 9.1 – Listar alertas registradas.
En la figura N° 63, se puede visualizar la tarea 9.1 concluida, en la cual el
efectivo policial puede visualizar las ultimas alertas registradas.
A continuación se visualiza el Story board del diseño referente a la tarea
Actualizar estado de alertas de la historia de usuario Atención de alertas. En
esta tarea, se diseña para ambas plataformas móvil y web.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
75 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 64
Diseño de la tarea 9.2 – Actualizar estado de alertas (Plataforma
móvil-web)
Figura N° 65
Caso de uso - Actualizar estado de alertas (Plataforma móvil).
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
76 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura anterior nos indica el caso de uso Actualizar estado de alerta en la
plataforma móvil, en este proceso solo puede realizado por el usuario de tipo
efectivo policial.
Figura N° 66
Caso de uso - Actualizar estado de alertas (Plataforma web).
En la figura N° 66 nos indica el caso de uso Actualizar estado de alerta en la
plataforma web, en este proceso el operador (efectivo policial), asigna a un
efectivo policial que atendió la alerta.
En la figura N° 67 se puede visualizar las entidades que se utilizaron en el
Modelo Lógico de la Historias de Usuarios 9 (Atención de Alertas)
correspondientes al cuarto Sprint, del mismo modo en la figura N° 68 se
puede visualizar las entidades del modelo Físico.
Figura N° 67
Entidades utilizadas en el Cuarto Sprint – Modelo Lógico.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
77 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 68
Entidades utilizadas en el Cuarto Sprint – Modelo Físico.
En la siguiente figura se muestra el documento de prueba que generó la tarea
9.2 de la historia de usuario número 9.
Figura N° 69
Prueba de Unidad – Tarea 9.2
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
78 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 70
Interfaz concluida de la tarea 9.2 – Actualizar estado de alerta
(Plataforma móvil).
En la figura N° 70, se puede visualizar la tarea 9.2 concluida, en la cual el
efectivo policial puede atender una alerta desde su móvil, pudiendo
actualizar como a una alerta atendida o una alerta falsa.
Así mismo la figura N° 71, indica que la tarea 9.2 concluida, en la cual el
operador autorizado puede actualizar una incidencia asignando al efectivo
policial que atendió la alerta, esto se realiza mediante la plataforma web.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
79 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 71
Interfaz concluida de la tarea 9.2 – Actualizar estado de alerta
(Plataforma web).
Antes de finalizar el cuarto Sprint el cliente, solicito unas mejoras en el caso
de la historia de usuario 7 Envío de alertas del tercer Sprint, se hicieron unas
mejoras la cual no requirió de ninguna integración ya que se trataba de una
mejora proveniente de un cambio generado al culminar el tercer Sprint. Dicho
cambio se generó a través de la solicitud de cambio mostrada en la figura N°
72, de igual forma la descripción detallada del cambio se encuentra reflejada
en dicha imagen.
© E
labora
ción
Pro
pia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
80 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 72
Solicitud de cambio y descripción del cambio Enviar alertas.
En la figura N° 73 se puede visualizar que ha sido agregada la entidad
T_IMAGENES, debido a la solicitud de cambio hecha por el cliente, esto
ocasionó modificaciones en el modelo Lógico y Físico (Ver figuras N° 73 y
74) del cuarto Sprint.
Figura N° 73
Cambios realizados en el Modelo Lógico del cuarto Sprint.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
81 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 74
Cambios realizados en el Modelo Físico del cuarto Sprint.
Figura N° 75
Interfaz concluida de la Solicitud de Cambio
El sprint tenía pautado durar 11 días de desarrollo, la evolución de la gráfica
Burn Down Chart antes de comenzar el quinto Sprint (Segunda Versión) lucía
como lo refleja en la gráfica N° 4.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
82 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Gráfica N° 4
Burn Down Chart – Inicio Quinto Sprint
Se debe aclarar en la gráfica N° 4, que la subida presenciada al final del
desarrollo del cuarto sprint (color rojo) se da debido a la agregación de puntos
de historia referentes a las modificaciones planteadas a la historia de usuario
Enviar Alerta, definidas al terminar el cuarto sprint.
De esta forma culmina el cuarto Sprint, mediante la integración de las tareas
de la historia de usuario 9, en la figura N° 76 se puede apreciar la integración
del cuarto Sprint y la finalización de la primera versión de la pila del producto
(Backlog).
Figura N° 76
Pizarrón, Estado final del cuarto Sprint.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
83 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 77
Descripción detallada de la Historia: Reporte de Alertas
En la figura N° 77, se detalla la descripción de condiciones de satisfacción:
Consultar y mostrar las incidencias detalladas.- Que los registros de
incidencias se puedan visualizar e imprimir.
Además, la figura anterior también muestra las tareas Reporte de Incidencias
atendidas por tiempo y fecha, reporte de incidencias registradas como falsas
alertas referentes a la historia de usuario Reporte de alertas que fue
desarrollada:
12.1. Reporte de Incidencias atendidas por tiempo y fecha.- Desarrollar un
reporte en la que se visualice que tiempo llevo a atender cada incidencia entre
un rango de fechas.
12.2. Reporte de incidencias registradas como falsas alertas.- Desarrollar
un reporte para conocer la cantidad y porcentaje de alertas falsas.
En la figura N° 68 se presenta la información del diseño referente a las tareas
de la historia de usuario Reporte de alertas.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
84 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 78
Diseño de la tarea 12.1 – Reporte de alertas (Plataforma web).
Figura N° 79
Caso de uso - Reporte de Alertas (Plataforma web).
En la figura N° 79, se puede visualizar el caso de uso de la tarea Reporte de
Alertas. Esta tarea fue mejorada a pedido del cliente. Dicha modificación se
generó a través de una solicitud de cambio mostrada en la figura N° 80, de
igual modo la descripción detallada del cambio se encuentra reflejada en
dicha figura.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
85 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 80
Solicitud de cambio y descripción detallada del cambio
Reporte de Alertas
El cambio generado al finalizar el quinto Sprint fue de clase 1 ya que no
afectaba ninguna otra historia de usuario y su objetivo era mejorar la función
que permite al efectivo policial obtener los reportes de manera rápida y
detallada. Como se observó anteriormente dicho cambio fue desarrollado de
inmediato a través de las tareas 12.1 y 12.2 definidas al inicio del proyecto,
que fueron integradas en la tarea 12.1 de nombre “Reporte de alertas” con
complejidad 3 y prioridad media.
El modelo lógico y físico del quinto Sprint es el mismo con la que se
concluyó el cuarto Sprint (Ver figuras N° 73 y 74) debido a que la historia de
Usuario 12 (Reporte de Alertas) no necesitó de ningún cambio en los
modelos, solo fue necesario de la codificación en PHP.
En la siguiente figura se muestra el documento de prueba que generó la tarea
12.1 de la historia de usuario número 12, después de la modificación que se
realizó por solicitud del cliente.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
86 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 81
Prueba de Unidad – Tarea 12.1
En la figura N° 82 se puede visualizar la tarea 12.1 concluida, en cual el
efectivo policial (Operador) puede obtener los reportes requeridos, así mismo
con la finalización del quinto Sprint.
Figura N° 82
Interfaz concluida de la tarea 12.1 – Reporte de alerta (Plataforma web).
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
87 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 83
Descripción detallada de la Historia: Enviar mensaje al celular.
En la figura N° 83, se detalla la descripción de condiciones de satisfacción:
Enviar mensaje al celular del efectivo Policial.- Que los policías en
patrullaje se mantengan informados al instante de las incidencias.
Enviar mensaje al celular del usuario.- Que los usuarios puedan recibir un
mensaje de la atención de alerta.
Además, la figura anterior también muestra las tareas definidas en la reunión
que fueron desarrolladas:
8.1. Reporta alerta a Policías.- Desarrollar la función de envío de mensajes
a la Policía.
8.2. Enviar mensaje de atención al usuario.- Desarrollar la función de
envío de mensajes al usuario que reporto una alerta.
En las figuras N° 84 y 85 se presentan la información del diseño referente a
las tareas de la historia de usuario Enviar mensaje al celular.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
88 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 84
Diseño de la tarea 8.1 – Reportar alerta a Policías (Plataforma web).
Figura N° 85
Diseño de la tarea 8.2 – Enviar mensaje de atención al usuario
(Plataforma web).
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
89 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 86 se puede visualizar el caso de uso de las tareas 8.1 y 8.2
Reportar alerta a Policías y Enviar mensaje de atención al usuario
respectivamente.
Figura N° 86
Caso de Uso - Reportar alerta a Policías y Enviar mensaje al usuario.
En la siguiente figura se muestra el documento de prueba que generaron las
tareas 8.1 y 8.2 de la historia de usuario número 8.
Figura N° 87
Prueba de Unidad: Tareas 8.1 y 8.2.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
90 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En las figuras N° 88 y 89 se pueden visualizar las tareas 8.1 y 8.2 concluidas,
en la cual el Operador (Efectivo Policial) puede enviar mensajes al celular de
los usuarios y a los efectivos policiales que están patrullando en las calles.
Figura N° 88
Interfaz concluida de la tarea 8.1 – Reportar alerta a Policías (Plataforma web).
Figura N° 89
Interfaz concluida de la tarea 8.2 – Enviar mensaje de atención al usuario
(Plataforma web).
Con las tareas desarrolladas se concluye la historia de usuario 8, dando inicio
a la siguiente historia de usuario.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
91 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 90
Descripción detallada de la Historia: Registro de Personal Policial.
En la figura N° 90, se detalla la descripción de condiciones de satisfacción:
Registrar y Efectivos Policiales.- Que el operador Policial pueda registrar
a los efectivos policiales que laboran en la comisaria.
Además, la figura anterior también muestra las tareas definidas en la reunión
que fueron desarrolladas:
3.1. Registrar efectivo Policial.- Desarrollar la sección que permita registrar
a un efectivo Policial.
En la figura N° 91 se presenta la información del diseño referente a la tarea
de la historia de usuario Registrar Efectivo Policial.
Figura N° 91
Diseño de la tarea 3.1 – Registrar efectivo Policial.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
92 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
En la figura N° 92 se puede visualizar el caso de uso de las tareas 3.1
Registrar efectivo Policial.
Figura N° 92
Caso de Uso – Registrar efectivo Policial.
Los modelos lógico y físico se pueden visualizar en los anexos N° 22 y 23.
En la siguiente figura se muestra el documento de prueba que generó la tarea
3.1 de la historia de usuario número 3.
Figura N° 93
Prueba de Unidad: Tarea 3.1
En la figura N° 94 se puede visualizar la interfaz concluida de la tarea 3.1, en
la cual el efectivo policial (Operador) puede seleccionar a un usuario para
registrar y transferir los datos al tipo de usuario Policía. De esta manera
concluye la historia de usuario 3 y el Sexto Sprint, dando inicio al séptimo
Sprint.
© E
labora
ción P
ropia
.
© E
labora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
93 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 94
Interfaz concluida de la tarea 3.1 – Registrar efectivo Policial (Plataforma web).
Figura N° 95
Descripción detallada de la Historia: Enviar mensaje al celular.
En la figura N° 95, se detalla la descripción de condiciones de satisfacción:
Recuperar Password.- Permitir a los usuarios recuperar su password.
Además, la figura anterior también muestra las tareas definidas en la reunión
que fueron desarrolladas:
10.1. Recuperar Contraseña.- Desarrollar la opción que el usuario ingrese
su DNI y correo electrónico para enviar una nueva clave.
En la figura N° 96 se presenta la información del diseño referente a la tarea
de la historia de usuario Recuperar Contraseña.
© E
labora
ción P
ropia
.
F©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
94 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 96
Diseño de la tarea 10.1 – Recuperar Contraseña.
En la figura N° 97 se puede visualizar el caso de uso de la tarea 10.1
Recuperar Contraseña.
Figura N° 97
Caso de Uso – Recuperar Contraseña.
Finalmente los modelos lógico y físico se concluyeron (Ver anexos N° 22 y
23) ya que no fue necesario de ninguna modificación más, así mismo se
elaboró el Diagrama de Base de Datos en SQL –Server 2008 (Ver anexo N°
24).
En la siguiente figura se muestra el documento de prueba que generó la tarea
10.1 de la historia de usuario número 10.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
95 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 98
Prueba de Unidad: Tarea 10.1
En la figura N° 99 se puede visualizar la interfaz concluida de la tarea 10.1,
en la cual el usuario puede recuperar su contraseña. De esta manera concluye
la historia de usuario 10.
Figura N° 99
Interfaz concluida de la tarea 10.1 – Recuperar contraseña(Plataforma web).
En la figura N° 100, se puede visualizar que las historias de usuario han sido
concluidas en tu totalidad, de este modo se concluyó con el último Sprint, la
finalización de la segunda versión y de la pila del producto (Product
Backlog), quedando el cliente conforme.
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
96 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Figura N° 100
Pizarrón, fase final de la pila del Producto (Backlog).
Gráfica N° 5
Burn Down Chart al finalizar el ultimo Sprint
En la gráfica N° 5 (Burn Down Chart) se detalla la evolución del avance del
desarrollo de los sprints. El desarrollo del primer sprint sirvió como base para
marcar pautas y cubrir puntos flojos de la metodología que se encontraban
ambiguos o no habían sido descritos claramente. Por ello, una vez finalizado
el primer Sprint, se hicieron los ajustes pertinentes, se explicaron los ajustes
al equipo de desarrollo, y se empezó el segundo, tercer, cuarto, quinto, sexto
y último sprint con la metodología mejorada. Las historias de usuarios 7 y 12
del cuarto y quinto Sprint respectivamente fueron mejoradas a pedido del
cliente es por ello el incremento de los puntos en estas historias, en la gráfica
anterior se muestra como Trabajo Nuevo (color rojo oscuro).
© E
labora
ción P
ropia
.
©
Ela
bora
ción P
ropia
.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
97 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
3.4 Población, muestra y muestreo.
3.4.1 Población:
Para Martínez (2005), la población es el conjunto de unidades o elementos
que representan una característica común, también se le considera como
conjunto de medidas. Esto debe entenderse como un grupo de personas,
familias, establecimientos, manzanas, barrios, objetos, etcétera, pero en
realidad es un conjunto de medidas obtenidas de las características estudiadas
(p. 828).
Por consiguiente en la presente investigación se considera como población a
63 registros de llamadas que la operadora registra en un cuaderno de la
comisaría Santa Luzmila del distrito de Comas (Ver anexo N° 3), en la Tabla
N° 17 se resume la población obtenida.
Tabla N° 17 Determinación de la Población
Fuente: Elaboración Propia
3.4.2 Muestra:
Para Martínez (2005, p. 834), la muestra lo define como un conjuntos de
medidas pertenecientes a una parte de la población.
Además indica que las unidades deben ser aleatorias, lo que equivale a decir
probabilística, con el fin de obtener una muestra representativa de la
población, respecto de todas o algunas de sus características, para los cuales
el valor del parámetro es desconocido, en caso contrario se habla de una
muestra no aleatoria.
Para el cálculo de la muestra, en la presente investigación se considera la
fórmula de población finita, debido a que está constituida por un determinado
o limitado número de elementos o unidades.
Se consideró la siguiente fórmula:
…………......Formula (3.1)
Dónde:
N = Total de la población (63 Registros de llamadas)
Z2
= 1.962 (si la seguridad es del 95%)
Indicador Cantidad de
Población
Tipo de Población
Tiempo de respuesta de la policía
63
Registros de alertas
Porcentaje de alertas falsas
( )
Universidad César Vallejo Escuela de Ingeniería de Sistemas
98 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
p = Proporción o frecuencia con que la característica en estudio se encuentra
en el universo (en este caso 5% = 0.05).
q = Complemento de p (1 – p) en este caso 1- 0.05 = 0.95
d= Precisión (en este caso se desea un 3%)
Para el indicador Tiempo de respuesta de la policía se toma los siguientes
datos:
Remplazando los valores en la fórmula para hallar la muestra de los
indicadores Tiempo de respuesta de la policía.
3.4.3 Muestreo:
Se cuenta con una población de 63 registros de llamadas, se aplicará un
muestreo de tipo intencionado o de conveniencia, ya que según Carrasco
(2006 p. 243), se encuentra dentro de los muestreos de tipo no probabilísticos,
la cual se caracteriza porque es el investigador es quien selecciona, según su
criterio y conocimiento de características de la población que estudia a los
individuos que conforman la muestra considerándolos los más
representativos. En la presente investigación se consideró 48 Registros de
llamadas realizadas del 1 al 11 de Octubre del año 2012, en la comisaria
Santa Luzmila del distrito de Comas (Ver anexo N° 4).
3.5 Método de Investigación:
Para Tafur (1995, p. 18), la investigación es el acto de “indagar o averiguar”, según
su uso natural y genérico, es la búsqueda de algo desconocido y, de ese modo, se
entiende el recurso a la originalidad como un criterio de investigación.
Para saber si el sistema de comunicación móvil A-GPS es favorable para el proceso
de atención de llamadas de emergencias, el método de investigación que se utilizó
es el método cuantitativo deductivo, ya que según Bernal (2009), el método
cuantitativo o método tradicional se fundamenta en la medición de las
características de los fenómenos sociales, lo cual supone derivar de un marco
conceptual pertinente al problema analizado, una serie de postulados que expresen
relaciones entre las variables estudiadas de forma deductiva. Este método tiende a
generalizar y normalizar resultados (p. 57).
3.6 Técnicas e instrumentos de recolección de datos.
Según Ortega (2009, p. 18) la recolección de datos se refiere a los métodos usados
para obtener información pertinente de las unidades elementales introducidas en
una muestra o en una población. Existen diferentes vías de obtener información, las
que se utilizó en la presente investigación son:
( )
( ) ( ) ( )
Universidad César Vallejo Escuela de Ingeniería de Sistemas
99 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
3.6.1 Técnicas.
Las principales técnicas que se utilizaron en el desarrollo de la presente tesis
son:
- Observación: Es una técnica de recopilación de datos semi primaria por la
cual el investigador actúa sobre los hechos a veces con la ayuda de algún
instrumento, de esta manera lo define Valderrama y León (2009, p. 214).
Se hizo uso de esta técnica, para comprobar el tiempo de respuesta de la
policía, para esto se utilizó instrumentos como cuaderno de registro de
llamadas y cronometro.
- Entrevista: Es una forma de interacción social, donde el investigador se
sitúa frente al investigado y le formula preguntas, así lo define Valderrama
y León (2009, p. 82), además señala que la entrevista como instrumento de
investigación social tiene una gran importancia ya que permite obtener
determinadas conclusiones sobre lo que se está investigando. Para la
presente investigación se aplicó esta técnica para obtener información
necesaria de la problemática de la institución, la cual permitió encontrar
los puntos débiles en cuanto a la atención de llamadas de emergencias que
se registran en la comisaría Santa Luzmila del distrito de Comas (Ver
anexo N° 2).
- Técnicas de Lectura: Para Carrasco (2005), define como el conjunto de
habilidades y destrezas físicas y mentales para captar, comprender e
interpretar el contenido de documentos escritos (p. 279). Se hizo uso de
esta técnica para la comprensión de los registros de llamadas de
emergencias, (Ver anexo N° 6) ya que se evaluó detalladamente la
información registrada por la operadora de llamadas.
3.6.2 Instrumentos.
- Ficha de observación: “Se emplea para registrar datos que se generan
como resultado del contacto directo entre el observador y la realidad que
observa” (Carrasco, 2005, p. 313), se realizó visitas a la comisaria de Santa
Luzmila del distrito de Comas para poder evaluar el proceso de atención
de llamadas de emergencias que realizan los ciudadanos, se midió el
tiempo en que un ciudadano realiza una llamada donde se registraba en un
cuaderno de incidencias (Ver anexos N° 24 - 33) hasta que el efectivo
policial elabora el parte policial (Ver anexos N° 34 - 36), de esta manera se
obtuvo el tiempo de respuesta de la policía en minutos (Medición Pre-
Test). Luego para la medición Post-Test, se midió el tiempo desde que un
usuario realiza un registro de alerta desde su móvil hasta la actualización
de la atención de la alerta del efectivo policial ya sea por el dispositivo
móvil o desde la aplicación web.
- Cronómetro: Es un reloj o una función del reloj que se utiliza para medir
fracciones de tiempo, por lo general muy cortas y de manera muy precisa.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
100 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
3.6.3 Fuentes.
- Proceso de atención de llamadas de emergencias en la comisaria de Santa
Luzmila en el distrito de Comas.
- Proceso de atención de llamadas de emergencias en la comisaria de Santa
Luzmila en el distrito de Comas
Tabla N° 18 Técnicas e Instrumentos de recolección de datos
Fuente: Elaboración Propia.
En la tabla N° 18 se detalla las técnicas e instrumentos empleadas para la
recolección de datos.
3.7 Métodos y técnicas de procesamiento de análisis de datos:
El método de análisis de datos de esta investigación es cuantitativo, ya que es Pre
experimental y se obtienen estadísticas que ayuden a comprobar si la hipótesis es
correcta. Según Valderrama y León (2009, p. 22), se puede formular solamente
cuando los datos del estudio que se van a recolectar y analizar para probar o
disprobar las hipótesis son cuantitativos (números, porcentajes, promedio, índices,
etcétera)
En la presente investigación se tomó una muestra mayor a 30, por ello se aplicó el
método de la prueba “Z” de diferencias de medidas, en la siguiente tabla N° 19, se
visualiza la fórmula general:
Tabla N° 19 “Prueba Z”
N° Ia Ip ( ) ( )
1 I1a I1p
2 I2a I2p
3 I3a I3p
4 I4a I4p
∑( )
∑( )
∑( )
∑( )
Fuente: Elaboración Propia
…………………….Fórmula (3.2)
INDICADOR TÉCNICA INSTRUMENTO FUENTE INFORMANTE
Tiempo de
Respuesta de
la Policía
-Observación
-Lectura
-Cronometro
-Cuaderno de
Registro de llamadas.
63
Registros
de llamadas
-Operadora,
recepcionista de
las llamadas.
-Comisario
-Partes Policiales
Porcentaje de
alertas falsas
-Observación
-Lectura
-Contador
-Cuaderno de
Registro de llamadas
∑
∑
Universidad César Vallejo Escuela de Ingeniería de Sistemas
101 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Se utilizara el procesador Sistemático Computarizado (SPSS), versión 20.0 siendo un
programa especial para estadística y recopilación de datos.
Indicador: Tiempo de respuesta de la policía
a) Definición de variables:
Ia = Indicador medido antes de la aplicación de un sistema de comunicación móvil
A-GPS (Sistema actual).
Ip = Indicador medido después de la aplicación de un sistema del comunicación
móvil A-GPS (Sistema Propuesto).
b) Hipótesis Específica 1:
Hipótesis HE1: El sistema de Comunicación Móvil A-GPS reduce el tiempo de
respuesta de la policía frente a las llamadas de emergencias en la comisaría de
Santa Luzmila del distrito de Comas.
Variables:
Ia1: Tiempo de respuesta de la policía medido antes de la aplicación de un sistema
de comunicación móvil A-GPS.
Ip1: Tiempo de respuesta de la policía medido después de la aplicación de un
sistema de comunicación móvil A-GPS.
Hipótesis Nula (H0): Un sistema de comunicación móvil A-GPS no disminuye el
tiempo de respuesta de la policía para el proceso de atención de llamadas de
emergencias en la comisaria de Santa Luzmila en el distrito de Comas.
Hipótesis Alternativa (Ha): Un sistema de comunicación móvil A-GPS
disminuye el tiempo de respuesta de la policía para el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito de
Comas.
c) Hipótesis Específica 2:
Hipótesis HE2: El sistema de Comunicación Móvil A-GPS reduce el porcentaje de
registros de alertas falsas en la comisaria de Santa Luzmila del distrito de Comas.
Variables:
Ia2: Porcentaje de registros de alertas falsas medido antes de la aplicación de un
sistema de comunicación móvil A-GPS.
Ip2: Porcentaje de registros de alertas falsas medido después de la aplicación de
un sistema de comunicación móvil A-GPS.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
102 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Hipótesis Nula (H0): Un sistema de comunicación móvil A-GPS no disminuye el
porcentaje de registros de alertas falsas para el proceso de atención de llamadas de
emergencias en la comisaria de Santa Luzmila en el distrito de Comas.
Hipótesis Alternativa (Ha): Un sistema de comunicación móvil A-GPS
disminuye el porcentaje de registros de alertas para el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito de
Comas.
Según Ñaupas (2009), la Hipótesis Nula son las que niega a la hipótesis de la
investigación (Hipótesis de Trabajo), se simboliza con H0 y las Hipótesis
Alternativas son las que dan respuesta a un problema de manera significativa con
varias posibilidades se simboliza con (p. 123).
d) Nivel de significancia:
X = 5% (error)
Nivel de confiabilidad ((1 – X) = 0.95)
e) Estadística de Prueba
……………………………….……… (Fórmula 3.3)
Dónde:
= Varianza
= Media Poblacional
n= Tamaño de la muestra
= Media muestral
f) Región de rechazo:
La región de rechazo es Z = Zx, donde Zx es tal que:
P [Z >Zx] = 0.05, donde Zx = Valor Tabular (tabla de distribución normal Z)
Luego la región de rechazo es: Z >Zx
También es necesario considerar las siguientes fórmulas para el cálculo:
o Promedio:
…………………….…..Fórmula (3.4)
∑
Universidad César Vallejo Escuela de Ingeniería de Sistemas
103 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
o Varianza:
…………………. (Fórmula (3.5)
o Desviación Estándar:
……………...……. (Fórmula (3.6)
Luego en la siguiente figura tenernos la distribución Z (normal):
Gráfica N° 6
Distribución Normal Z
En la gráfica N° 6, se puede visualizar la región de rechazo (conocida como región crítica)
y la región de aceptación (región de no aceptación).
∑ ( )
∑ ( )
© H
ernán
dez
(2006
)
Universidad César Vallejo Escuela de Ingeniería de Sistemas
104 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
RESULTADOS
4.1 Descripción.
4.1.1 Análisis de Confiabilidad.
Se realizó el análisis de confiabilidad en los indicadores tiempo de respuesta
de la policía y porcentaje de registros de alertas falsas, las condiciones de
confiabilidad se definen en la tabla N° 20.
Tabla N° 20 Condiciones de confiabilidad
Condición Resultado
Sig < 0.05 Adopta una distribución no normal
Sig ≥ 0.05 Adopta una distribución normal
Fuente: Elaboración Propia
4.1.2 Prueba de normalidad.
Se procedió a realizar la prueba de normalidad en cada uno de los indicadores
mediante el método Kolgomorov Smirnov, debido a la cantidad de la muestra
conformada por 48 registros de alertas, según Caetano( p. 150, 2003). Dicha
prueba se realizó introduciendo los datos de cada indicador en el software
estadístico SPSS 20.0, para un nivel de confiabilidad del 95%, bajo las
condiciones mostrados en la tabla N° 20.
Indicador: Tiempo de respuesta de la Policía (Pre Test).
Tabla N° 21 Prueba de Normalidad – Tiempo de respuesta de la Policía
(Pre test)
Fuente: Elaboración Propia
Como se puede observar en la tabla N° 21 el valor Sig es de 0.002 < 0.05, por
lo tanto adopta una distribución no normal.
Indicador: Tiempo de respuesta de la Policía (Post Test)
Tabla N° 22 Prueba de Normalidad – Tiempo de respuesta de la Policía
(Post Test)
Fuente: Elaboración Propia
Kolmogorov-Smirnova
Estadístico gl Sig.
Pre Test 0,166 48 0,002
Kolmogorov-Smirnova
Estadístico gl Sig.
Post Test 0,160 48 0,003
Universidad César Vallejo Escuela de Ingeniería de Sistemas
105 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Como se puede observar en la tabla N° 22 el valor Sig. es de 0.003 < 0.05,
por lo tanto adopta una distribución no normal.
Indicador: Porcentaje de Registros de alertas falsas (Pre Test)
Tabla N° 23 Prueba de Normalidad – Porcentaje de Registros de alertas falsas
(Pre test)
Fuente: Elaboración Propia
Como se puede observar en la tabla N° 23 el valor Sig. es de 0.003 < 0.05,
por lo tanto adopta una distribución no normal.
Indicador: Porcentaje de Registros de alertas falsas (Post Test)
Tabla N° 24 Prueba de Normalidad – Porcentaje de Registros de alertas falsas
(Post Test)
Fuente: Elaboración Propia
Como se puede observar en la tabla N° 24 el valor Sig. es de 0.000 < 0.05,
por lo tanto adopta una distribución no normal.
4.1.3 Prueba de hipótesis
a) Hipótesis Especifica 1:
H1: El sistema de comunicación móvil A-GPS disminuye el tiempo
de respuesta de la Policía en el proceso de atención de llamadas de
emergencias en la comisaria de Santa Luzmila en el distrito de Comas.
Indicador: Tiempo de respuesta de la Policía.
Hipótesis Estadísticas
Hipótesis Ho: El sistema de comunicación móvil A-GPS no reduce
el tiempo de respuesta de la policía en el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el
distrito de Comas.
Por lo tanto:
Kolmogorov-Smirnova
Estadístico gl Sig.
Pre Test 0,318 11 0,003
Kolmogorov-Smirnova
Estadístico gl Sig.
Post Test 0,353 11 0,000
Universidad César Vallejo Escuela de Ingeniería de Sistemas
106 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
El indicador del Sistema de proceso actual es mejor que el indicador
del sistema propuesto.
Hipótesis Ha: El sistema de comunicación móvil A-GPS reduce el
tiempo de respuesta de la Policía en el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el
distrito de Comas.
Por lo tanto:
El indicador del sistema propuesto es mejor que el indicador del
sistema actual.
Tabla N° 25 Cálculo de las medias (1)
Fuente: Elaboración Propia
Gráfica N° 7
Tiempo promedio de respuesta de la Policía (Comparativa
general).
De acuerdo a la Gráfica N° 7, se puede observar que existe una reducción
muy importante en el tiempo promedio de respuesta de la policía en el
proceso de atención de llamadas de emergencias a manera general se reduce
en 22 minutos, es decir, existe una disminución porcentual del 75.85%.
La siguiente tabla nos muestra la prueba de los rangos con signo de
Wilcoxon.
N Media
Pre_Test_Registro 48 29 min.
Post_Test_Registro 48 7 min.
N válido (según lista) 48
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
107 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Tabla N° 26 Prueba de Rangos con signo de Wilcoxon (1).
Fuente: Elaboración Propia
Respecto al resultado de la tabla N° 26 del contraste de hipótesis se aplicó la
Prueba de Wilcoxon debido a que es una muestra de distribución no normal,
la cual fue anteriormente explicada en el punto 4.1.2. El nivel crítico de
contraste (Sig.) es 0,000, y dado que es claramente menor a 0.05 entonces se
rechaza la hipótesis nula aceptando la hipótesis alterna con un 95% de
confianza, gráficamente se puede apreciar en la siguiente gráfica.
Gráfica N° 8
Contrastes de Hipótesis (Tiempo promedio de respuesta de la Policía)
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
108 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
b) Hipótesis Especifica 2:
H2: El sistema de comunicación móvil A-GPS disminuye el
porcentaje de registros de alertas falsas en el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito
de Comas.
Indicador: Porcentaje de registros de alertas falsas.
Hipótesis Estadísticas
Hipótesis Ho: El sistema de comunicación móvil A-GPS no reduce el
porcentaje de registros de alertas falsas en el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el
distrito de Comas.
Por lo tanto:
El indicador del sistema de proceso actual es mejor que el indicador
del sistema propuesto.
Hipótesis Ha: El sistema de comunicación móvil A-GPS disminuye
el porcentaje de registros de alertas falsas en el proceso de atención de
llamadas de emergencias en la comisaria de Santa Luzmila en el
distrito de Comas.
Por lo tanto:
El indicador del sistema propuesto es mejor que el indicador del
sistema actual.
Tabla N° 27 Cálculo de las medias (2)
Fuente: Elaboración Propia
N Media
Pre_Test_Registro 48 45.83 %
Post_Test_Registro 48 10.41 %
N válido (según lista) 48
Universidad César Vallejo Escuela de Ingeniería de Sistemas
109 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
Gráfica N° 9
Porcentaje promedio de registros de alertas falsas (Comparativa general).
De acuerdo a la Gráfica N° 9, se puede observar que existe una reducción
muy importante en el porcentaje de registros de alertas falsas en el proceso de
atención de llamadas de emergencias a manera general se reduce en 35.42%,
es decir, existe una disminución porcentual del 77.29%.
La siguiente tabla nos muestra la prueba de los rangos con signo de
Wilcoxon.
Tabla N° 28 Prueba de Rangos con signo de Wilcoxon (2).
Fuente: Elaboración Propia
Respecto al resultado de la tabla N° 28 del contraste de hipótesis se aplicó la
Prueba de Wilcoxon debido a que es una muestra de distribución no normal,
la cual fue anteriormente explicada en el punto 4.1.2. El nivel crítico de
contraste (Sig.) es 0,000, y dado que es claramente menor a 0.03 entonces se
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
110 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
rechaza la hipótesis nula aceptando la hipótesis alterna con un 95% de
confianza, gráficamente se puede apreciar en la siguiente gráfica.
Gráfica N° 10
Contrastes de Hipótesis (Porcentaje de registros de alertas falsas)
4.2 Discusión
1. El Sistema de Comunicación Móvil A-GPS reduce el tiempo de respuesta de la
Policía en el proceso de atención de llamadas de emergencias en la comisaría de
Santa Luzmila en el distrito de Comas.
Existe una reducción importante en el tiempo promedio de respuesta de la policía
en el proceso de atención de llamadas de emergencias a manera general se reduce
en 22 minutos, es decir, existe una disminución porcentual del 75.85%.
Se han obtenido tiempos menores de respuesta de la Policía ante una emergencia
de 3 y 4 minutos en comparación con el proyecto de investigación Jallpa Kuyuy –
Sistema de comunicación Móvil GPS Post sismo de la Unidad de Investigación
FIA de la Universidad San Martin de Porres, la cual obtuvieron como resultados
de 5 minutos como el menor tiempo.
2. El Sistema de Comunicación Móvil A-GPS reduce el porcentaje de alertas falsas
en el proceso de atención de llamadas de emergencias en la comisaría de Santa
Luzmila en el distrito de Comas.
También existe una reducción considerable en el porcentaje de registro de alertas
falsas en el proceso de atención de llamadas de emergencias, ya que anteriormente
se tenía un registro del total de registros de alertas el 45.83% eran consideradas
como alertas falsas, ahora con la implementación de la aplicación se redujo al
10.41%, es decir existe una disminución porcentual del 77.29%.
3. De acuerdo a la hipótesis planteada, el sistema de comunicación Móvil A-GPS
influyo de manera positiva en el tiempo de respuesta de la Policía ante las
llamadas de emergencias de la comisaría de Santa Luzmila en el distrito de
Comas. En las pruebas de rendimientos se realizaron registros de alertas seguidas
durante un determinado tiempo, obteniendo respuestas instantáneas del operador
© E
labora
ción P
ropia
Universidad César Vallejo Escuela de Ingeniería de Sistemas
111 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
de la Comisaria de Santa Luzmila en comparación con la investigación
“Implementación de un Web GIS que permita ubicar llamadas de emergencia para
el Benemérito Cuerpo de Bomberos Voluntarios de la Ciudad de Cuenca” de
Diana Carolina Arce Cuesta y Sebastián Alejandro Cáceres Abril, la cual el
tiempo de respuesta de la aplicación no fue el más óptimo ya que la herramienta
que utilizaron (OpenLayers) tiende a demorar en cargar la información, esto
ocasiona que se genera un cola de las llamadas de emergencias.
Finalmente luego de haber obtenido resultados favorables con la implementación
del sistema, se notó la mejora del proceso de atención de llamadas de emergencia
en la comisaría de Santa Luzmila en el distrito de Comas.
4. El Sistema de Comunicación Móvil A-GPS bajo la plataforma móvil y web
mejora el proceso de atención de llamadas de emergencias al haber disminuido el
tiempo de respuesta de la policía y el porcentaje de registro de alertas falsas.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
112 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
V. CONCLUSIONES Y SUGERENCIAS
5.1 Conclusiones.
1. Se concluye que el sistema de comunicación móvil A-GPS reduce el tiempo de
respuesta de la Policía en el proceso de atención de llamadas de emergencias en la
comisaria de Santa Luzmila, ya que influye positivamente en el proceso en
mención. Sin el sistema se promedió 29 minutos y con la implementación del
sistema se redujo a los 7 minutos, lo que significa una reducción de 22 minutos en
dicho proceso. En consecuencia se produce una disminución porcentual de
75.85%.
2. Se concluye que el sistema de comunicación móvil A-GPS reduce el porcentaje de
registros de alertas falsas en el proceso de atención de llamadas en la comisaria de
Santa Luzmila en el distrito de Comas, ya que influye positivamente en el proceso
en mención. Sin el sistema se obtuvo un 45.83 % y con la implementación del
sistema alcanzó los 10.41% de registros de alertas falsas, lo que significa una
reducción porcentual de 77.29 %
3. Finalmente después de haber obtenido resultados satisfactorios de los indicadores
del estudio, se concluye que la implementación del sistema de comunicación
móvil A-GPS mejora el proceso de atención de llamadas de emergencias en la
comisaria de Santa Luzmila del distrito de Comas ya que influye positivamente en
el proceso mencionado.
5.2 Sugerencias.
A continuación se detalla las recomendaciones para futuras investigaciones:
1. A la presente investigación se puede profundizar con otros requerimientos
funcionales de las demás comisarías del distrito de Comas y el Serenazgo de la
Municipalidad de Comas, para mejorar el proceso de atención de llamadas de
emergencias.
2. Se sugiere incorporar al Sis-CoMóvil A-GPS un medio de validación con la base
de datos de la RENIEC, al momento del registro de los usuarios para contar con
una Base de Datos actualizada, de este modo tener una información más real de
los usuarios que se registran y de este modo reducir el porcentaje de registros de
alertas falsas.
3. En el análisis de los datos solo se ha considerado variables cuantitativas como son
el tiempo de respuesta de la policía y porcentaje de registros de alertas falsas. Por
ello, esta investigación podría continuarse teniendo en cuenta variables
cualitativas como el nivel de satisfacción de los usuarios con el sistema. Además
se puede desarrollar el sistema para otras plataformas como: Windows Phone,
BlackBerry SO, Symbian OS entre otros.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
113 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
REFERENCIAS BIBLIOGRÁFICAS
- Carrasco, S. (2006). Metodología de la investigación científica. (1a ed.) Lima:
Editorial San Marcos.
- Carrión, F. y Dammert, M. (2009). Economía Política de la Seguridad Ciudadana. (1a
ed.). Quito: FLACSO.
- Dammert, L. (2010). Crimen e inseguridad: políticas, temas y problemas en las
Américas. (1a ed.). Chile: FLACSO-Chile / Catalonia
- Debrauwer, L. y Van der Heyde, F. (2009). UML 2. (2ª ed.). Barcelona: Ediciones
ENI.
- De Mesquita, P. y Carrión, F. (2008). Ensayos Sobre Seguridad Ciudadana. (1a ed.).
Ecuador: Flacso-Sede Ecuador.
- Fabregas Ll., J. (2005) Gerencia de Proyectos de Tecnología de Información. (1ª
ed.). Caracas: Editorial CEC, SA.
- Federación Iberoamericana de OMBUDSMAN (2011). VII Informe sobre Derechos
Humanos – Seguridad Ciudadana.
Recuperado de:
http://www.portalfio.org/inicio/repositorio/informes-
fio/informe_seguridad_ciudadana.pdf
- Figueroa, R., Solís, C. y Cabrera, A. (2008) Metodologías Tradicionales vs.
Metodologías Ágiles. ECC/UTPL.
- Fujita, H. y Doménico, M. (2010). New Trends in Software Methodologies, Tools and
Techniques. (1a ed.). Amsterdam, Netherlands: IOS Press BV.
- Garzás J. (2011). Calidad de Software y Otros Temas Relacionados. España
Recuperado de:
http://www.javiergarzas.com/archivos
- Gropper, S., Smith, J. y Groff, J. (2009). Advanced Nutrition and Human Metabolism
(7a ed.). United Stated of American: Cengage Learning.
- Guerra C., (2004). Sistema de Posicionamiento Global Instituto De Investigación.
Revista Campus FIA /USMP.
- Harper G., N. (2009). Server-side GPS and Assisted-GPS in Java. (1a ed.). United
State of American: Artech House.
- Heinz, W. y Barnes R. (2011). VoIP Emergency Calling. (1ª ed.). United Kingdom:
John Wiley & Sons Ltd.
- Hurtado L., I. y Toro G. (2007). Paradigmas y Métodos de Investigación en Tiempos
de Cambios. (5ª ed.). Caracas: CEC, SA.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
114 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
- Instituto de Opinión Pública. Segunda Encuesta Metropolitana de Victimización 2012.
Recuperado de:
http://www.ciudadnuestra.org/facipub/upload/cont/3222/cont/files/encuesta_victimiza
cion_2012_cn_2.pdf
- Instituto Nacional de Estadística e Informática. Actualización del Impacto de las
tecnologías de Información y Comunicación en el Perú. Diciembre del 2002.
Recuperado de:
http://www.ongei.gob.pe/estudios/publica/estudios/Lib5151/Libro.pdf
- Kazmier, L. y Diaz, A. (1999). Estadística Aplicada a la administración y a la
economía. (3ª ed.). México DF: McGraw-Hill.
- Martínez B., C. (2005). Estadística y muestreo (12ª ed.) ECOE-Ediciones.
- Mora, L. (2008). Indicadores de la gestión logística (2da
ed.)Bogotá, Colombia.
- Municipalidad Distrital de Comas. Plan Local De Seguridad Ciudadana Y
Convivencia Social 2012.
Recuperado de:
http://www.municomas.gob.pe/anuncios/Plan_Local_de_Seg_Ciud_y_Conv_Social_2
012_aprobado.pdf
- Ñaupas P., H. (2009). Metodología de la Investigación científica y Asesoramiento de
Tesis. (1ª ed.). Gráfica RETAI SAC.
- Ortega M., C. (2009). Estadística General. (1ª ed.). Lima: AE/UCV-LIMA.
- Quesada X. (2009). Introducción a la Estimación y Planificación Ágil
Recuperado de:
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
- Taha H., A. (2004). Investigación de Operaciones. (7a ed.). México DF: Pearson
Education.
- Tafur P., R. (1995) La tesis Universitaria. (1ª ed.) Lima: Editorial Mantaso.
- Tamayo y Tamayo M. (2004) El Proceso de la Investigación Científica. (4ª ed.).
Mexico DF: Limusa.
- Serra, D. (2005). La Logística empresarial en el nuevo milenio. (2da
ed.). Bogota.
- Sommerville, I. (2005). Ingeniería del Software. (7ª ed.) Madrid: Pearson Education.
- Valderrama, S. y León, L. (2009). Técnicas e instrumentos para la obtención de datos
en la investigación científica. (1ª ed.). Lima.
- Van Diggelen, F. (2009). A-GPS, Assisted GPS, GNSS, and SBAS. (1a ed.). United
States of America: Artech House.
Universidad César Vallejo Escuela de Ingeniería de Sistemas
115 Sistema de Comunicación Móvil A-GPS en el
proceso de atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito
de Comas.
López Chávez, Carlomagno
- Villarreal M., J. (2000). Cucunuba – Modelo para un desarrollo sostenible. (1ª ed.).
Bogotá.
- Zandbergen, P. y Barbeau, S. (2011). Positional Accuracy of Assisted GPS Data from
High-Sensitivity GPS-enabled Mobile Phones. The Royal Institute of Navigation. vol.
64, 381-399 pp.
Recuperado de:
http://www.paulzandbergen.com/files/Zandbergen_Barbeau_JON_2011.pdf
116
ANEXOS
Anexo N° 1 Matriz de Consistencia
TÍTULO: Sistema de Comunicación Móvil A-GPS en el proceso de atención de llamadas de emergencias en la comisaría de Santa Luzmila en el
distrito de Comas.
RESPONSABLE: López Chávez, Carlomagno.
PROBLEMA
OBJETIVOS
HIPÓTESIS
OPERACIONALIZACIÓN DE VARIABLES
METODOLOGÍA VARIABLE DIMENSIONES INDICADORES INSTRUMENTOS
General
¿De qué manera influye un sistema de comunicación Móvil A-GPS
para el proceso de atención de
llamadas de emergencias en la comisaría de Santa Luzmila en el
distrito de Comas?
Secundarios
¿De qué manera influye un sistema
de comunicación móvil A-GPS en el tiempo de respuesta de la Policía
frente a las llamadas de
emergencias en la comisaría de Santa Luzmila en el distrito de
Comas?
¿De qué manera influye un sistema
de comunicación móvil A-GPS en
el porcentaje de registros de alertas
en la comisaría de Santa Luzmila en
el distrito de Comas?
General
Determinar la influencia de un sistema de comunicación Móvil A-GPS para el
proceso atención de llamadas de
emergencias en la comisaría de Santa Luzmila en el distrito de Comas.
Específicos
Determinar la influencia de un sistema
de comunicación Móvil A-GPS en el tiempo de respuesta de la Policía en la
atención de llamadas de emergencias
en la comisaría de Santa Luzmila en el distrito de Comas.
Determinar la influencia de un sistema
de comunicación móvil A-GPS en el
porcentaje de registros de alertas falsas
en la comisaría de Santa Luzmila en el
distrito de Comas.
Implementar un sistema de
comunicación móvil A-GPS para
mejorar el proceso de atención de llamadas en la comisaría de Santa
Luzmila en el distrito de Comas.
General
El sistema de comunicación Móvil A-GPS mejora el proceso de atención de
llamadas de emergencias en la
comisaría de Santa Luzmila en el distrito de Comas.
Específicos
El sistema de comunicación Móvil A-
GPS disminuye el tiempo de respuesta de la Policía en la atención de
llamadas de emergencias en la
comisaría de Santa Luzmila en el distrito de Comas.
El sistema de comunicación Móvil A-
GPS disminuye el porcentaje de
registros de alertas falsas en la
comisaría de Santa Luzmila en el
distrito de Comas.
Independiente
Sistema de
Comunicación Móvil
A-GPS
Tipo de Investigación:
El tipo de estudio de este trabajo de investigación es experimental-
aplicada.
Diseño de Estudio:
La investigación requiere del
diseño pre-experimental debido a
que se pretende gestionar el proceso de atención de registro
de llamadas de emergencias en la
modalidad de preprueba-posprueba, es decir se analiza el
estado en que se encuentra dicho
proceso y se observan los cambios.
Población: Son los 63 registros de llamadas de emergencias.
Muestra: Son 48 registros de llamadas de
emergencias.
Método de Investigación:
El método de investigación que se usa para saber si el sistema
comunicación móvil A-GPS es
favorable en el proceso de atención de llamadas de
emergencias es el método cuantitativo deductivo.
Técnicas e Instrumentos de
recolección de datos:
Observación, entrevista,
técnicas de lectura.
Dependiente
Proceso de atención de llamadas de
emergencias
Tiempo
Tiempo de
respuesta de
la policía
Ficha de
Observación (Cronometro)
Porcentaje de
alertas falsas
Porcentaje de
registros de alertas falsas
Ficha de
observación
117
Anexo N° 2 Ficha de Observación
FICHA DE OBSERVACIÓN N° 1
ANALISTA: López Chávez, Carlomagno.
Fecha: 17/09/2012
DESCRIPCIÓN
El proceso de atención de registros de llamadas de emergencias: Cuando el ciudadano
realizaba una llamada de emergencia a la central 105 o la comisaria de Santa Luzmila
del distrito de Comas, era atendida por un operador. Él era el encargado de tomar
apuntes en un cuaderno de registros los datos que brinda el ciudadano como son: Su
nombre, ubicación donde se produjo la incidencia, que tipo de incidencia es (Asalto,
accidente de tránsito, pandillaje, etc.), posteriormente, el operador policial deriva esta
llamada hacia un efectivo policial encargado de acuerdo a la ubicación del origen de la
llamada, informando de los detalles que dio el ciudadano. La central de emergencias
105 esta subdividida por 4 sectores de acuerdo a las zonas: Zona Norte, Sur, Este y
Oeste. Para el distrito de Comas corresponde la zona Norte, posteriormente se
comunicaba vía radio con la comisaría más cercana donde se produjo la incidencia para
informar los datos brindados por el ciudadano, luego la comisaría designaba de acuerdo
a la jurisdicción que móvil debe acudir al lugar de la emergencia. El tiempo promedio
de respuesta de la policía ante una llamada de emergencia era de 29 minutos
aproximadamente.
118
Anexo N° 3 Entrevista al comisario
119
120
Anexo N° 4 Ficha de observación para determinar la Población.
Observación: Para el cálculo de la población se consideró 11 días desde el 01 de Octubre
del 2012 hasta el 11 de Octubre del 2012, obteniendo una población de 63 registros de
llamadas de emergencias.
Investigador: López Chávez, Carlomagno
Organización: Comisaría de Santa Luzmila - Comas
Tipo de Prueba: PRE TEST
Dirección: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 01/10/2012 – 11/10/2012
Fecha Cantidad de registros de
llamadas de emergencias
Lunes 01/10/2012 5
Martes 02/10/2012 7
Miércoles 03/10/2012 3
Jueves 04/10/2012 10
Viernes 05/10/2012 4
Sábado 06/10/2012 4
Domingo 07/10/2012 16
Lunes 08/10/2012 3
Martes 09/10/2012 5
Miércoles 10/10/2012 4
Jueves 11/10/2012 2
Total 63
121
Anexo N° 5 Ficha de Observación: Tiempo de respuesta de la Policía.
Investigador: López Chávez, Carlomagno
Organización: Comisaría de Santa Luzmila - Comas
Tipo de Prueba: PRE TEST
Dirección: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 01/10/2012 – 11/10/2012
N° Reg.
Llamada
Hora de Registro
Llamada
Hora de llegada al
lugar del incidente
Tiempo
Respuesta
Motivo
Reg. 01 01/10/2012 21:00:00 01/10/2012 21:24:00 24 min. Alteración del Orden
Público
Reg. 02 01/10/2012 21:34:00 01/10/2012 22:04:00 30 min. Asalto (cruce El
álamo/Av. Collique)
Reg. 03 02/10/2012 12:19:00 02/10/2012 13:17:00 58 min. Accidente de Transito
Reg. 04 02/10/2012 11:39:00 02/10/2012 12:10:00 31 min. Infarto
Reg. 05 02/10/2012 12:01:00 02/10/2012 12:28:00 27 min. Vehículo sospechoso
(color blanco)
Reg. 06 02/10/2012 09:09:00 02/10/2012 09:31:00 31 min. Agresión Familiar
Reg. 07 02/10/2012 09:21:00 02/10/2012 09:47:00 26 min. Vehículo sospechoso
Reg. 08 02/10/2012 10:43:00 02/10/2012 11:16:00 33 min Accidente transito
Reg. 09 03/10/2012 15:40:00 03/10/2012 16:05:00 25 min. Caída de Pared
Reg. 10 04/10/2012 04:08:00 04/10/2012 04:35:00 27 min Rotura de tubo de
agua
Reg. 11 04/10/2012 20:08:00 04/10/2012 20:32:00 24 min. Supuesto Delincuente
Reg. 12 04/10/2012 22:23:00 04/10/2012 22:55:00 33 min Pandilleros
(Parque Belen)
Reg. 13 04/10/2012 21:26:00 04/10/2012 21:50:00 24 min. Espalda Colegio 2005
Reg. 14 04/10/2012 19:54:00 04/10/2012 20:27:00 33 min. Accidente de Transito
Reg. 15 04/10/2012 21:47:00 04/10/2012 22:28:00 41 min. Agresión física
Reg. 16 04/10/2012 22:26:00 04/10/2012 22:56:00 30 min. Pandilleros
Reg. 17 04/10/2012 00:07:00 04/10/2012 00:33:00 26 min. Sujeto arrojado de una
móvil
Reg. 18 05/10/2012 08:48:00 05/10/2012 09:23:00 35 min. Accidente de transito
Reg. 19 05/10/2012 11:33:00 05/10/2012 12:28:00 55 min. Agresión con rotura
de cabeza
Reg. 20 05/10/2012 10:00:00 05/10/2012 10:29:00 29 min. Asalto y Robo con
arma de fuego 4
sujetos
Reg. 21 05/10/2012 08:30:00 05/10/2012 08:57:00 27 min. Agresión
Reg. 22 06/10/2012 18:15:00 06/10/2012 18:52:00 37 min. Enfrentamiento,
amenazo a su ex
yerno.
Reg. 23 06/10/2012 15:14:00 06/10/2012 15:42:00 28 min. Delincuentes
Reg. 24 06/10/2012 16:15:00 06/10/2012 16:39:00 24 min. Emergencia (Av.
Trapiche/Av. Incas)
Reg. 25 07/10/2012 02:08:00 07/10/2012 02:35:00 27 min. Pandilleros (Av.
Jamaica/Universitaria)
Reg. 26 07/10/2012 03:21:00 07/10/2012 03:47:00 26 min. San Diego
Reg. 27 07/10/2012 03:00:00 07/10/2012 03:23:00 23 min. Emergencia del 105
122
N° Reg.
Llamada
Hora de Registro
Llamada
Hora de llegada al
lugar del incidente
Tiempo
Respuesta
Motivo
Reg. 28 07/10/2012 04:43:00 07/10/2012 05:09:00 26 min. Alteración del O.P.
Reg. 29 07/10/2012 05:15:00 07/10/2012 05:37:00 22 min. Agresión física
Reg. 30 07/10/2012 01:58:00 07/10/2012 02:23:00 25 min. Alteración del Orden
Público
Reg. 31 07/10/2012 05:54:00 07/10/2012 06:19:00 25 min. Accidente de Tránsito
(ovalo infantas)
Reg. 32 07/10/2012 06:26:00 07/10/2012 06:58:00 32 min. Accidente de Tránsito
(Trapiche/Incas)
Reg. 33 07/10/2012 21:24:00 07/10/2012 21:52:00 28 min. Pandilleros (colegio
Ñustas)
Reg. 34 07/10/2012 22:39:00 07/10/2012 23:13:00 34 min. Robo vía pública (Av.
Sangara)
Reg. 35 07/10/2012 22:48:00 07/10/2012 23:20:00 32 min. Sujeto tendido
(Universitaria -
Jamaica)
Reg. 36 07/10/2012 22:49:00 07/10/2012 23:24:00 35 min. Alteración del Orden
Público
Reg. 37 07/10/2012 00:02:00 07/10/2012 00:26:00 24 min. Asalto vía publica
Reg. 38 08/10/2012 09:29:00 08/10/2012 09:54:00 25 min. Robo de dinero (Jr.
Libertad 195)
Reg. 39 08/10/2012 11:59:00 08/10/2012 00:32:00 33 min. Alteración del orden
publico
Reg. 40 09/10/2012 14:17:00 09/10/2012 14:48:00 31 min. Tocamientos
indebidos
Reg. 41 09/10/2012 15:54:00 09/10/2012 16:20:00 26 min. Av. Trapiche
Reg. 42 09/10/2012 13:32:00 09/10/2012 13:57:00 25 min. Agresión física (El
álamo Mz.K1 Lt.4)
Reg. 43 09/10/2012 17:49:00 09/10/2012 18:17:00 28 min. Agresión física
Reg. 44 09/10/2012 14:54:00 09/10/2012 15:24:00 30 min. Va a la misma
dirección del Reg. 32
Reg. 45 10/10/2012 01:50:00 10/10/2012 02:18:00 28 min. Vehículo sospechoso
(color rojo)
Reg. 46 10/10/2012 22:47:00 10/10/2012 23:15:00 24 min. Pandilleros (Belaunde
-Universitaria)
Reg. 47 10/10/2012 19:45:00 10/10/2012 20:10:00 25 min. Accidente Transito
(Universitaria/
Guillermo La Fuente)
Reg. 48 11/10/2012 07:30:00 11/10/2012 08:04:00 34 min. Primera de Pro.
Promedio : 29 min.
123
Anexo N° 6 Ficha de Observación: Porcentaje de registro de alertas falsas.
Investigador: López Chávez, Carlomagno
Organización: Comisaría de Santa Luzmila - Comas
Tipo de Prueba: PRE TEST
Dirección: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 01/10/2012 – 11/10/2012
N° Reg. Llamada Fecha de Registro
Llamada
Cantidad de registros de
alertas falsas
Reg. 01 01/10/2012 1
Reg. 02 02/10/2012 2
Reg. 03 03/10/2012 1
Reg. 04 04/10/2012 3
Reg. 05 05/10/2012 2
Reg. 06 06/10/2012 2
Reg. 07 07/10/2012 2
Reg. 08 08/10/2012 2
Reg. 09 09/10/2012 2
Reg. 10 10/10/2012 3
Reg. 11 11/10/2012 2
Total : 22
De acuerdo a la fórmula del indicador de porcentaje de registros de alertas falsa, se realizó
el remplazo de los valores para el cálculo correspondiente:
Porcentaje de registro de alertas falsas = (22 / 48)*100 = 45.83%
124
Anexo N° 7 Ficha de Observación: Tiempo de respuesta de la Policía.
Investigador: López Chávez, Carlomagno
Organización: Comisaría de Santa Luzmila - Comas
Tipo de Prueba: POST TEST
Dirección: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 15/05/2013 - 25/05/2013
N° Reg.
Llamada
Hora de Registro
Llamada
Hora de llegada al
lugar del incidente
Tiempo
Respuesta
Motivo
Reg. 01 15/05/2013 20:00:00 15/05/2013 20:10:00 10 min. Accidente Transito
Reg. 02 15/05/2013 22:34:00 15/05/2013 22:42:00 8 min. Robo
Reg. 03 15/05/2013 12:19:00 15/05/2013 12:25:00 6 min.
Otros: Persona
Sospechosa
Reg. 04 16/05/2013 10:39:00 16/05/2013 10:46:00 7 min. Robo
Reg. 05 16/05/2013 12:01:00 16/05/2013 12:09:00 8 min. Pandillaje
Reg. 06 16/05/2013 09:11:00 16/05/2013 09:20:00 9 min.
Otros: Camión
malogrado Av. Incas
Reg. 07 16/05/2013 07:05:00 16/05/2013 07:12:00 7 min. Otros: Pelea callejera
Reg. 08 16/05/2013 10:43:00 16/05/2013 10:47:00 4 min.
Otros: Persona Ebrio
hace escándalo.
Reg. 09 17/05/2013 15:40:00 17/05/2013 15:49:00 9 min. Accidente Transito
Reg. 10 17/05/2013 04:08:00 17/05/2013 04:16:00 8 min. Robo
Reg. 11 17/05/2013 23:08:00 17/05/2013 23:15:00 7 min.
Otros: Pelea dos
jóvenes (Retablo)
Reg. 12 17/05/2013 20:23:00 17/05/2013 20:29:00 6 min.
Otros: Se oyeron
disparos (Retablo).
Reg. 13 18/05/2013 13:26:00 18/05/2013 13:35:00 9 min. Robo
Reg. 14 18/05/2013 19:54:00 18/05/2013 20:04:00 8 min. Accidente Transito
Reg. 15 18/05/2013 21:47:00 18/05/2013 21:54:00 7 min. Persona Pérdida
Reg. 16 18/05/2013 11:26:00 18/05/2013 11:30:00
4 min.
Otros: Auto
Sospechoso, color rojo
lunas polarizadas
Reg. 17 18/05/2013 00:09:00 18/05/2013 00:20:00 11 min.
Otros: Moto taxista
peleando con pasajero
Reg. 18 18/05/2013 08:25:00 18/05/2013 08:31:00 6 min. Accidente Tránsito
Reg. 19 18/05/2013 11:11:00 18/05/2013 11:18:00 7 min. Robo
Reg. 20 18/05/2013 10:00:00 18/05/2013 10:19:00
9 min.
Otros: Persona
sospechosa en
paradero “Seguro”
Reg. 21 19/05/2013 08:37:00 19/05/2013 08:42:00 5 min. Otros
Reg. 22 19/05/2013 16:15:00 19/05/2013 16:18:00 3 min. Asalto
Reg. 23 19/05/2013 15:10:00 19/05/2013 15:17:00
7 min.
Otros: Poste
alumbrado público
caído
Reg. 24 19/05/2013 18:25:00 19/05/2013 18:36:00 11 min. Robo
Reg. 25 20/05/2013 02:11:00 20/05/2013 02:16:00 5 min. Asalto
Reg. 26 20/05/2013 03:28:00 20/05/2013 03:35:00
7 min.
Otros: Persona
desmayada en
paradero
Reg. 27 20/05/2013 03:07:00 20/05/2013 03:17:00 10 min. Robo
125
N° Reg.
Llamada
Hora de Registro
Llamada
Hora de llegada al
lugar del incidente
Tiempo
Respuesta
Motivo
Reg. 28 20/05/2013 04:43:00 20/05/2013 04:51:00 8 min. Robo
Reg. 29 20/05/2013 05:35:00 20/05/2013 05:45:00 10 min.
Otros: Disparos al aire
libre
Reg. 30 21/05/2013 01:59:00 21/05/2013 02:07:00 8 min. Secuestro
Reg. 31 21/05/2013 05:50:00 21/05/2013 05:57:00 7 min.
Otros: Desalojo de
vendedores en calle
Reg. 32 21/05/2013 06:26:00 21/05/2013 06:32:00 6 min. Accidente Transito
Reg. 33 21/05/2013 21:24:00 21/05/2013 21:31:00 7 min. Otros: Auto sin placa
Reg. 34 21/05/2013 22:49:00 21/05/2013 22:57:00 8 min.
Otros: Persona
sospechosa
Reg. 35 21/05/2013 20:40:00 21/05/2013 20:48:00 8 min. Otros: Pique de autos
Reg. 36 21/05/2013 21:50:00 21/05/2013 21:57:00 7 min.
Otros: Árbol caído en
media av. universitaria
Reg. 37 22/05/2013 00:02:00 22/05/2013 00:07:00 5 min.
Otros: Buzón abierto
cerca a colegio peligro
Reg. 38 22/05/2013 06:29:00 22/05/2013 06:36:00 7 min.
Otros: Persona ebria
problemas vía publica
Reg. 39 23/05/2013 11:59:00 23/05/2013 00:08:00 9 min. Pandillaje
Reg. 40 23/05/2013 13:10:00 23/05/2013 13:17:00 7 min. Robo
Reg. 41 23/05/2013 14:54:00 23/05/2013 14:58:00
4 min.
Accidente transito:
Mototaxi choco con
auto
Reg. 42 23/05/2013 13:32:00 23/05/2013 13:40:00 8 min.
Secuestro: En
restaurante
Reg. 43 23/05/2013 07:49:00 23/05/2013 07:54:00 5 min. Robo en av. 22 agosto
Reg. 44 24/05/2013 09:54:00 24/05/2013 10:00:00 6 min.
Otros: Se incendia una
casa
Reg. 45 24/05/2013 08:50:00 24/05/2013 08:54:00 4 min. Pandillaje
Reg. 46 24/05/2013 22:47:00 24/05/2013 22:56:00 9 min.
Otros: Pelea de bandas
en Retablo
Reg. 47 25/05/2013 19:49:00 25/05/2013 19:57:00 8 min. Robo a transeúnte
Reg. 48 25/05/2013 05:55:00 25/05/2013 06:02:00 7 min. Otros: Persona herida
Promedio : 7 min.
126
Anexo N° 8 Ficha de Observación: Porcentaje de registro de alertas falsas.
Investigador: López Chávez, Carlomagno
Organización: Comisaria de Santa Luzmila - Comas
Tipo de Prueba: POST TEST
Dirección: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 15/05/2013 - 25/05/2013
N° Reg. alerta Fecha de Registro alerta Cantidad de registros de
alertas falsas
Reg. 01 15/05/2013 0
Reg. 02 16/05/2013 1
Reg. 03 17/05/2013 0
Reg. 04 18/05/2013 1
Reg. 05 19/05/2013 0
Reg. 06 20/05/2013 1
Reg. 07 21/05/2013 0
Reg. 08 22/05/2013 1
Reg. 09 23/05/2013 0
Reg. 10 24/05/2013 1
Reg. 11 25/05/2013 0
Total 5
De acuerdo a la fórmula del indicador de porcentaje de registros de alertas falsas, se realizó
el remplazo de los valores para el cálculo correspondiente:
Porcentaje de registro de alertas falsas = (5 / 48)*100 = 10.41%
127
Anexo N° 9 Tabla de criterios para la selección de metodología (1).
128
Anexo N° 10 Tabla de criterios para la selección de metodología (2).
129
Anexo N° 11 Tabla de criterios para la selección de metodología (3).
130
Anexo N° 12 Tabla de criterios para la selección del lenguaje de programación (1).
131
Anexo N° 13 Tabla de criterios para la selección del lenguaje de programación (2).
132
Anexo N° 14 Tabla de criterios para la selección del lenguaje de programación (3).
133
Anexo N° 15 Criterios de evaluación de experto gestor de Base de Datos (1).
134
Anexo N° 16 Criterios de evaluación de experto gestor de Base de Datos (2).
135
Anexo N° 17 Criterios de evaluación de experto gestor de Base de Datos (3).
136
Anexo N° 18 Tabla evaluación de experto fichas de observación (1).
137
Anexo N° 19 Tabla evaluación de experto fichas de observación (2).
138
Anexo N° 20 Tabla evaluación de experto fichas de observación (3).
139
Anexo N° 21 Cronograma de Desarrollo de la Aplicación.
140
Anexo N° 22 Modelo Lógico
141
Anexo N° 23 Modelo Físico
142
Anexo N° 24 Diagrama de Base de Datos – SQL Server
143
Anexo N° 25 Carta de Conformidad de la Finalización del Proyecto de Investigación
144
Anexo N° 26 Registro de Llamadas de emergencias (1)
145
Anexo N° 27 Registro de Llamadas de emergencias (2)
146
Anexo N° 28 Registro de Llamadas de emergencias (3)
147
Anexo N° 29 Registro de Llamadas de emergencias (4)
148
Anexo N° 30 Registro de Llamadas de emergencias (5)
149
Anexo N° 31 Registro de Llamadas de emergencias (6)
150
Anexo N° 32 Registro de Llamadas de emergencias (7)
151
Anexo N° 33 Registro de Llamadas de emergencias (8)
152
Anexo N° 34 Registro de Llamadas de emergencias (9)
153
Anexo N° 35 Parte Policial para determinar la hora de llegada de la Policía al lugar de la
alerta (1).
154
Anexo N° 36 Parte Policial para determinar la hora de llegada de la Policía al lugar de la
alerta (2).
155
Anexo N° 37 Parte Policial para determinar la hora de llegada de la Policía al lugar de la
alerta (3).
156
Anexo N° 38 Mapa del ámbito Jurisdiccional de la Comisaría de Santa Luzmila.
157
Anexo N° 39 Código Fuente Acceso a la aplicación
import java.util.ArrayList; import org.apache.http.NameValuePair; import org.apache.http.message.BasicNameValuePair; import org.json.JSONArray; import org.json.JSONException; import org.json.JSONObject; import test.Droidlogin.library.Httppostaux; import android.app.Activity; import android.app.ProgressDialog; import android.content.Context; import android.content.Intent; import android.net.Uri; import android.os.AsyncTask; import android.os.Bundle; import android.os.SystemClock; import android.os.Vibrator; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.EditText; import android.widget.TextView; import android.widget.Toast;
public class Login extends Activity { EditText user; EditText pass; Button blogin; TextView registrar; Httppostaux post; String IP_Server="192.168.0.182:8080";//IP DE NUESTRO PC String URL_connect="http://"+IP_Server+"/droidlogin/acces.php"; boolean result_back; private ProgressDialog pDialog; @Override public void onCreate(Bundle savedInstanceState) { System.out.print(URL_connect); super.onCreate(savedInstanceState); setContentView(R.layout.main); post=new Httppostaux(); user= (EditText) findViewById(R.id.edusuario); pass= (EditText) findViewById(R.id.edpassword); blogin= (Button) findViewById(R.id.Blogin); registrar=(TextView) findViewById(R.id.link_to_register); //Login button action blogin.setOnClickListener(new View.OnClickListener(){ public void onClick(View view){ //Extreamos datos de los EditText String usuario=user.getText().toString(); String passw=pass.getText().toString(); //verificamos si estan en blanco
158
if( checklogindata( usuario , passw )==true){ new asynclogin().execute(usuario,passw); }else{ err_login(); } } }); registrar.setOnClickListener(new View.OnClickListener(){ public void onClick(View view){ //Abre el navegador al formulario adduser.html String url = "http://"+IP_Server+"/droidlogin/adduser.html"; Intent i = new Intent(Intent.ACTION_VIEW); i.setData(Uri.parse(url)); startActivity(i); } }); } //vibra y muestra un Toast public void err_login(){ Vibrator vibrator =(Vibrator) getSystemService(Context.VIBRATOR_SERVICE); vibrator.vibrate(200); Toast toast1 = Toast.makeText(getApplicationContext(),"Error:Nombre de usuario o password incorrectos", Toast.LENGTH_SHORT); toast1.show(); } public boolean loginstatus(String username ,String password ) { int logstatus=-1; ArrayList<NameValuePair> postparameters2send= new ArrayList<NameValuePair>(); postparameters2send.add(new BasicNameValuePair("usuario",username)); postparameters2send.add(new BasicNameValuePair("password",password)); //realizamos una peticion y como respuesta obtenes un array JSON JSONArray jdata=post.getserverdata(postparameters2send, URL_connect); SystemClock.sleep(950); //si lo que obtuvimos no es null if (jdata!=null && jdata.length() > 0){ JSONObject json_data; //creamos un objeto JSON
159
try { json_data = jdata.getJSONObject(0); logstatus=json_data.getInt("logstatus");//accedemos al valor Log.e("loginstatus","logstatus= "+logstatus);//muestro por log que obtuvimos } catch (JSONException e) { // TODO Auto-generated catch block e.printStackTrace(); } //validamos el valor obtenido if (logstatus==0){// [{"logstatus":"0"}] Log.e("loginstatus ", "invalido"); return false; } else{// [{"logstatus":"1"}] Log.e("loginstatus ", "valido"); return true; } }else{ //json obtenido invalido verificar parte WEB. Log.e("JSON ", "ERROR"); return false; } } //validamos si no hay ningun campo en blanco public boolean checklogindata(String username ,String password ){ if (username.equals("") || password.equals("")){ Log.e("Login ui", "checklogindata user or pass error"); return false; }else{ return true; } } class asynclogin extends AsyncTask< String, String, String > { String user,pass; protected void onPreExecute() { //para el progress dialog pDialog = new ProgressDialog(Login.this); pDialog.setMessage("Autenticando...."); pDialog.setIndeterminate(false); pDialog.setCancelable(false); pDialog.show(); } protected String doInBackground(String... params) { //obtnemos usr y pass user=params[0];
160
pass=params[1]; //enviamos y recibimos y analizamos los datos en segundo plano. if (loginstatus(user,pass)==true){ return "ok"; //login valido }else{ return "err"; //login invalido } } protected void onPostExecute(String result) { pDialog.dismiss();//ocultamos progess dialog. Log.e("onPostExecute=",""+result); if (result.equals("ok")){ Intent i=new Intent(Login.this, HiScreen.class); i.putExtra("user",user); startActivity(i); }else{ err_login(); } } } }