final desarrollo tesis

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° 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° 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° 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° 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° 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° 30 Registro de Llamadas de emergencias (5)……………………………….... 148





Anexo N° 35 Parte Policial para determinar la hora de llegada de la Policía al lugar de

la alerta (1)…………...……………………………………………………..

153


la alerta (2)………………………………………………………………….

154


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.





de Comas.


- 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





de Comas.


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





de Comas.


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





de Comas.


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.





de Comas.


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.





de Comas.


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





de Comas.


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





de Comas.


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.





de Comas.


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

.





de Comas.


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.





de Comas.


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:





de Comas.


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

/





de Comas.


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/





de Comas.


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.





de Comas.


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)





de Comas.


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

∑





de Comas.


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.





de Comas.


Tabla N° 3 Criterios de selección de Metodología


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





de Comas.


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

http://www.scrummanager.net/files/sm_proyecto.pdf

http://www.scrummanager.net/files/sm_proyecto.pdf





de Comas.


- 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





de Comas.


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





de Comas.


(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





de Comas.


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


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





de Comas.


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.





de Comas.


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

.pdf

Rec

uper

ado d

e: h

ttp

://w

ww

.cri

sp.s

e/fi

le-

uplo

ads/

Kan

ban

-vs-

Scr

um

.pdf





de Comas.


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


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





de Comas.


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





de Comas.


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





de Comas.


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





de Comas.


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





de Comas.


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/





de Comas.


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


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:





de Comas.


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


En la tabla N° 9 se hace una comparación entre los principales gestores de base de

datos.





de Comas.


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


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





de Comas.


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





de Comas.


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.





de Comas.


Operacionalización de Variables

En la siguiente tabla N° 11 se explica las definiciones correspondientes:

Tabla N° 11 Operacionalización de Variables


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.





de Comas.


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.






de Comas.


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.





de Comas.


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


después de la aplicación.


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


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.





de Comas.


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.





de Comas.


Tabla N° 15 Información de la Pila del Producto (Product Backlog)


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





de Comas.


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


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.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


Figura N° 29




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

.





de Comas.


(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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


Figura N° 36


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

.





de Comas.


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

.





de Comas.



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

.





de Comas.


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.


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

.





de Comas.


Figura N° 43

Entidades utilizadas en el Segundo Sprint – Modelo Físico.



Figura N° 44


© E

labora

ción P

ropia

.

© E

labora

ción P

ropia

.





de Comas.


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

.





de Comas.


Figura N° 47

Descripción detallada de la Historia: Tipos de alertas


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

.





de Comas.


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

.





de Comas.


Figura N° 50


Figura N° 51

Interfaz concluida de la tarea 6.1 – Tipos de Alertas.


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

.





de Comas.


Figura N° 52

Descripción detallada de la Historia: Envío de alertas.


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.


de la historia de usuario Envío de aletas.

© E

labora

ción P

ropia

.





de Comas.


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.


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

.





de Comas.


Figura N° 55

Entidades utilizadas en el Tercer Sprint – Modelo Lógico.

Figura N° 56

Entidades utilizadas en el Tercer Sprint – Modelo Físico.



Figura N° 57


© E

labora

ción P

ropia

.

©

Ela

bora

ción P

ropia

.

© E

labora

ción P

ropia

.





de Comas.


Figura N° 58

Interfaz concluida de la tarea 7.1 – Enviar Alertas


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

.





de Comas.



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


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

.





de Comas.


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.



Figura N° 62


© E

labora

ción P

ropia

.

©

Ela

bora

ción P

ropia

.





de Comas.


Figura N° 63

Interfaz concluida de la tarea 9.1 – Listar alertas registradas.


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

.





de Comas.


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

.





de Comas.


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.


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

.





de Comas.


Figura N° 68

Entidades utilizadas en el Cuarto Sprint – Modelo Físico.



Figura N° 69


© E

labora

ción P

ropia

.

© E

labora

ción P

ropia

.





de Comas.


Figura N° 70

Interfaz concluida de la tarea 9.2 – Actualizar estado de alerta

(Plataforma móvil).


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


Figura N° 77

Descripción detallada de la Historia: Reporte de Alertas


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

.





de Comas.


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

.





de Comas.


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.


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

.





de Comas.


Figura N° 81


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

.





de Comas.


Figura N° 83

Descripción detallada de la Historia: Enviar mensaje al celular.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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

.





de Comas.


Figura N° 90

Descripción detallada de la Historia: Registro de Personal Policial.


Registrar y Efectivos Policiales.- Que el operador Policial pueda registrar

a los efectivos policiales que laboran en la comisaria.



3.1. Registrar efectivo Policial.- Desarrollar la sección que permita registrar

a un efectivo Policial.


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

.





de Comas.


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.



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

.





de Comas.


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.


Recuperar Password.- Permitir a los usuarios recuperar su password.



10.1. Recuperar Contraseña.- Desarrollar la opción que el usuario ingrese

su DNI y correo electrónico para enviar una nueva clave.


de la historia de usuario Recuperar Contraseña.

© E

labora

ción P

ropia

.

F©

Ela

bora

ción P

ropia

.





de Comas.


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



© E

labora

ción P

ropia

.

©

Ela

bora

ción P

ropia

.





de Comas.


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

.





de Comas.


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

.





de Comas.


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


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

( )





de Comas.


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:

( )

( ) ( ) ( )





de Comas.


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.





de Comas.


3.6.3 Fuentes.

- Proceso de atención de llamadas de emergencias en la comisaria de Santa


- 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


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

∑( )

∑( )

∑( )

∑( )


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

∑

∑





de Comas.


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.





de Comas.


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


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)

∑





de Comas.


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

)





de Comas.


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


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)


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)


Kolmogorov-Smirnova

Estadístico gl Sig.

Pre Test 0,166 48 0,002

Kolmogorov-Smirnova


Post Test 0,160 48 0,003





de Comas.


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)




Indicador: Porcentaje de Registros de alertas falsas (Post Test)

Tabla N° 24 Prueba de Normalidad – Porcentaje de Registros de alertas falsas

(Post Test)




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


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


Pre Test 0,318 11 0,003

Kolmogorov-Smirnova


Post Test 0,353 11 0,000





de Comas.


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


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)


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





de Comas.


Tabla N° 26 Prueba de Rangos con signo de Wilcoxon (1).


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





de Comas.


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


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


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)


N Media

Pre_Test_Registro 48 45.83 %

Post_Test_Registro 48 10.41 %

N válido (según lista) 48





de Comas.


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


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





de Comas.


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


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





de Comas.


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.





de Comas.


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.





de Comas.


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.

http://www.google.com.pe/search?hl=es&tbo=p&tbm=bks&q=inauthor:%22Richard+Barnes%22





de Comas.


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





de Comas.


- 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


General

El sistema de comunicación Móvil A-GPS mejora el proceso de atención de

llamadas de emergencias en la


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


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

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


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.





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



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)


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. 44 09/10/2012 14:54:00 09/10/2012 15:24:00 30 min. Va a la misma

dirección del Reg. 32


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





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.



Tipo de Prueba: POST TEST


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


Organización: Comisaria de Santa Luzmila - Comas

Tipo de Prueba: POST TEST


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


129


130

Anexo N° 12 Tabla de criterios para la selección del lenguaje de programación (1).

131


132


133

Anexo N° 15 Criterios de evaluación de experto gestor de Base de Datos (1).

134


135


136

Anexo N° 18 Tabla evaluación de experto fichas de observación (1).

137


138


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


146


147


148


149


150


151


152


153

Anexo N° 35 Parte Policial para determinar la hora de llegada de la Policía al lugar de la

alerta (1).

154


alerta (2).

155


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(); } } } }

final desarrollo tesis

Documents