FINAL Desarrollo Tesis

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA DE SISTEMAS
SISTEMA DE COMUNICACIN MVIL A-GPS EN

EL PROCESO DE ATENCIN DE LLAMADAS DE
EMERGENCIAS EN LA COMISARA DE SANTA
LUZMILA EN EL DISTRITO DE COMAS
TESIS PARA OPTAR EL TTULO PROFESIONAL DE
INGENIERO DE SISTEMAS
AUTOR:
Br. LPEZ CHVEZ, CARLOMAGNO
ASESOR:
Ing. BRAVO BALDEN, PERCY RUBN
LIMA PER
2013
DEDICATORIA
Dedico esta tesis a mi familia,

por ser quienes me apoyaron
incondicionalmente,
en
el
desarrollo de esta investigacin,
por su amor infinito.
ii
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. Adems a mis compaeros de
estudio con quienes compart muchas
experiencias en la casa de estudios de la
Universidad Csar Vallejo. De igual manera
agradezco a mis asesores, Ing. Percy Ruben
Bravo Balden y Mg. Mnica Daz Retegui,
quienes me guiaron en la elaboracin de la
presente investigacin. Adems a mis amigos
Ing. Jara Mendoza Omar e Ing. Morillo Cuya
Sergio
por su apoyo y consejo para el
desarrollo de esta tesis.
iii
RESUMEN
La investigacin comprendi el anlisis, desarrollo, implementacin y evaluacin de un
sistema de comunicacin Mvil A-GPS bajo las plataformas Mvil y Web para el
proceso de atencin de llamadas de emergencias en la comisara de Santa Luzmila en el
distrito de Comas. Este estudio incluye la problemtica, el tipo de investigacin para
esta tesis se determin que es experimental y el tipo de estudio aplicada, empleando un
diseo de investigacin pre-experimental. El objetivo principal de la tesis fue
determinar la influencia de un sistema de comunicacin Mvil A-GPS para la atencin
de llamadas de emergencias en la comisara de Santa Luzmila en el distrito de Comas.
Se estableci una poblacin de estudio de 63 registros de llamadas de alertas de la
poblacin durante 11 das en el mes de Octubre del 2012 en la comisara de Santa
Luzmila. La muestra obtenida fue de 48 registros de llamadas de emergencias y el
muestreo se estableci por estratos. Para la recoleccin de datos y anlisis se utiliz
instrumentos como las fichas de observacin y el cronmetro, la tcnica que se utiliz
fue la observacin. Para la validacin de la hiptesis se utiliz el mtodo estadstico de
la distribucin normal Z, ya que esta prueba es una distribucin de probabilidad que
surge del problema de estimar la media de una poblacin normalmente distribuida y que
a su vez el tamao de la muestra es mayor a 30.
Se plante el desarrollo de un sistema de comunicacin Mvil A-GPS, para la mejora
del proceso de atencin de llamadas de emergencias, se utiliz para su diseo la
metodologa Scrum por ser una metodologa gil y por la aprobacin de los expertos, el
lenguaje de programacin utilizado es Android para la aplicacin mvil y PHP para la
aplicacin web. El sistema gestor de base de datos fue SQL Server 2008.
Palabras Claves: Sistema Comunicacin Mvil Plataforma Android Plataforma
Web Proceso de atencin de llamadas de emergencia.
iv
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.
NDICE GENERAL
PORTADA.. i
DEDICATORIA..... ii
AGRADECIMIENTO.... iii
RESUMEN..... iv
ABSTRACT v
NDICE GENERAL... vi
NDICE DE FIGURAS.. viii
NDICE DE GRFICAS..... xi
NDICE DE TABLAS. xii
NDICE DE FRMULAS....... xiii
NDICE DE ANEXOS............ xiv
INTRODUCCIN... xv
I. PROBLEMA DE INVESTIGACIN...................... 1
1.1. Planteamiento del Problema.................... 1
1.2. Formulacin del problema........... 5
1.2.1. Problema General.. 5
1.2.2. Problemas Especficos... 5
1.3. Justificacin..... 5
1.3.1. Justificacin Tecnolgica.. 5
1.3.2. Justificacin Operativa.. 6
1.3.3. Justificacin Institucional.. 6
1.4. Limitacin.... 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. Especficos......................... 9
II. MARCO TERICO.... 10
2.1. Marco terico............... 10
2.2. Marco conceptual........ 35
III. MARCO METODOLGICO........... 36
3.1. Hiptesis...... 36
3.1.1. Hiptesis General... 36
3.1.2. Hiptesis Especficas. 36
3.2. Variables...... 36
3.2.1. Definicin Conceptual....... 36
3.2.2. Definicin Operacional..... 36
3.2.3. Indicadores............. 39
3.3. Metodologa. 40
3.3.1. Tipo de Estudio ..... 40
3.3.2. Diseo de Investigacin..... 40
3.3.3. Desarrollo de la Metodologa ... 41
3.4. Poblacin, muestra y muestreo.......... 97
3.4.1. Poblacin... 97
3.4.2. Muestra ....................................................................... 97
3.4.3. Muestreo 98
3.5. Mtodos de Investigacin........ 98
vi
3.6. Tcnicas e instrumentos de recoleccin de datos.... 98

3.6.1. Tcnicas..... 99
3.6.2. Instrumentos... 99
3.6.3. Fuentes... 100
3.7. Mtodos y tcnicas de procesamiento de anlisis de datos......100
IV. RESULTADOS. 104
4.1. Descripcin............................. 104
4.1.1. Anlisis de Confiabilidad...104
4.1.2. Prueba de Normalidad... 104
4.1.3. Prueba de Hiptesis... 105
4.2. Discusin..110
V. CONCLUSIONES Y SUGERENCIAS. 112
5.1. Conclusiones.... 112
5.2. Sugerencias...... 112
REFERENCIAS BIBLIOGRFICAS 113
ANEXOS. 116
vii
NDICE DE FIGURAS
Figura N 1 - Proceso de atencin de llamadas de la central de emergencias 105............... 2
Figura N 2 - Visin 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 - Ilustracin cmo funciona la metodologa Scrum...... 20
Figura N 6 - Fases de Kanban Clsico. 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 Kanban31
Figura N 13 - Estado inicial de la pizarra Primer Sprint......... 45
Figura N 14 - Descripcin Detallada de la Historia: Registro de Usuarios.... 46
Figura N 15 - Diseo de tarea 1.1 Validacin de Datos....47
Figura N 16 - Caso de Uso - Validacin de Datos... 48
Figura N 17 - Pruebas de Unidad Tarea 1.1.. 48
Figura N 18 - Interfaz concluida de la tarea 1.1 Validacin de datos... 49
Figura N 19 - Diseo de tarea 1.2 Trminos y condiciones del uso de la aplicacin... 50
Figura N 20 - Caso de uso - Trminos y condiciones del uso de la aplicacin50
Figura N 22 - Pizarrn - Fases de Diseo y Pruebas....51
Figura N 23 - Interfaz concluida de la tarea 1.2 - Trminos y condiciones del uso de la
aplicacin52
Figura N 24 - Descripcin detallada de la Historia: Confirmacin de Registro.. 52
Figura N 25 - Diseo de tarea 2.1 Activacin de Cuenta de Usuario... 53
Figura N 26 - Caso de uso - Activacin de Cuenta de Usuario... 53
Figura N 27 Entidades utilizadas en el Primer Sprint Modelo Lgico.. 54
Figura N 28 Entidades utilizadas en el Primer Sprint Modelo Fsico54
Figura N 30 - Interfaz concluida de la tarea 2.1 Activacin de Cuenta de Usuario. 55
Figura N 31 - Descripcin detallada de la Historia: Validacin de acceso..56
Figura N 32 - Diseo de tarea 4.1 Inicio de sesin va mvil... 57
Figura N 33 - Diseo de tarea 4.2 Inicio de sesin va 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.158
Figura N 36 - Prueba de Unidad Tarea 4.2....59
Figura N 37 - Interfaz concluida de la tarea 4.1 Inicio de sesin va Mvil. 59
Figura N 38 - Interfaz concluida de la tarea 4.2 Inicio de sesin va web 60
Figura N 39 - Descripcin detallada de la Historia: Ubicacin del lugar de incidencia. 60
Figura N 40 - Diseo de tarea 5.1 Ver ubicacin actual... 61
Figura N 41 - Caso de uso - Ver ubicacin actual... 62
Figura N 42 Entidades utilizadas en el Segundo Sprint Modelo Lgico... 62
Figura N 43 Entidades utilizadas en el Segundo Sprint Modelo Lgico... 63
Figura N 44 - Prueba de Unidad Tarea 5.1....63
Figura N 45 - Interfaz concluida de la tarea 5.1 Ver ubicacin actual..64
Figura N 46 - Estado final del segundo Sprint (Integracin de Tareas).. 64
viii
Figura N 47 - Descripcin detallada de la Historia: Tipos de alertas.. 65

Figura N 48 - Diseo 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 - Descripcin detallada de la Historia: Envo de alertas.. 68
Figura N 53 - Diseo 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 Lgico.. 70
Figura N 56 Entidades utilizadas en el Primer Sprint Modelo Fsico... 70
Figura N 58 - Interfaz concluida de la tarea 7.1 Enviar Alertas... 71
Figura N 59 - Descripcin detallada de la Historia: Atencin de Alertas... 71
Figura N 60 - Diseo 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 - Diseo de la tarea 9.2 Actualizar estado de alertas (Plataforma mvilweb)... 75
Figura N 65 - Caso de uso - Actualizar estado de alertas (Plataforma mvil).... 75
Figura N 66 - Caso de uso - Actualizar estado de alertas (Plataforma web)... 76
Figura N 67 Entidades utilizadas en el Cuarto Sprint Modelo Lgico.. 76
Figura N 68 Entidades utilizadas en el Primer Sprint Modelo Lgico.. 77
Figura N 70 - Interfaz concluida de la tarea 9.2 Actualizar estado de alerta
(Plataforma mvil)......................... 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 descripcin del cambio Enviar alertas.. 80
Figura N 73 Cambios realizados en el Modelo Lgico del Cuarto Sprint... 80
Figura N 74 Cambios realizados en el Modelo Fsico del Cuarto Sprint..... 81
Figura N 75 - Interfaz concluida de la Solicitud de Cambio....81
Figura N 76 - Pizarrn, Estado final del cuarto Sprint.....82
Figura N 77 - Descripcin detallada de la Historia: Reporte de Alertas..83
Figura N 78 - Diseo 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 descripcin 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 - Descripcin detallada de la Historia: Enviar mensaje al celular... 87
Figura N 84 - Diseo de la tarea 8.1 - Reportar alerta a Policas (Plataforma web)... 88
Figura N 85 - Diseo de la tarea 8.2 - Enviar mensaje de atencin al usuario
(Plataforma web)....88
Figura N 86 - Caso de Uso - Reportar alerta a Policas 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 Policas (Plataforma
web)90
ix
Figura N 89 - Interfaz concluida de la tarea 8.2 Enviar mensaje de atencin al usuario

(Plataforma web) 90
Figura N 90 - Descripcin detallada de la Historia: Registro de Personal Policial. 91
Figura N 91 - Diseo 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 - Descripcin detallada de la Historia: Enviar mensaje al celular... 93
Figura N 96 - Diseo de la tarea 10.1 Recuperar Contrasea... 94
Figura N 97 - Caso de Uso Recuperar Contrasea94
Figura N 98 - Prueba de Unidad: Tarea 10.1... 95
Figura N 99 - Interfaz concluida de la tarea 10.1 Recuperar contrasea (Plataforma
web)95
Figura N 100 - Pizarrn, fase final de la pila del Producto (Backlog). 96
NDICE DE GRFICOS
Grfica N 1 - Tiempo promedio de respuesta de la Polica... 3
Grfica N 2 - Porcentaje promedio de registro de alertas falsas........ 4
Grfica N 3 - Tendencias de denuncias por delitos en el Per.. 16
Grfica N 4 - Burn Down Chart Inicio Quinto Sprint. 82
Grfica N 5 - Burn Down Chart al finalizar el ultimo Sprint.... 96
Grfica N 6 - Distribucin Normal Z. 103
Grfica N 7 - Tiempo promedio de respuesta de la Polica (Comparativa general).. 106
Grfica N 8 Contrastes de Hiptesis (Tiempo promedio de respuesta de la Polica). 107
Grfica N 9 - Porcentaje promedio de registros de alertas falsas (Comparativa
general).....109
Grfica N 10 - Contrastes de Hiptesis (Porcentaje de registros de alertas falsas)... 110
xi
NDICE DE TABLAS
Tabla N 1 Ventas de telfonos 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 Metodologas...... 18
Tabla N 3 Criterios de seleccin de Metodologa.. 19
Tabla N 4 Formato de Historias de usuarios..... 21
Tabla N 5 Formato de Release Plan.. 24
Tabla N 6 Formato de Descripcin de Historia de Usuario... 27
Tabla N 7 Lenguaje de Programacin 32
Tabla N 8 Criterio de seleccin del lenguaje de programacin..... 33
Tabla N 9 Gestor de base de Datos 34
Tabla N 10 Criterio de seleccin del gestor de Base de Datos.. 35
Tabla N 11 Operacionalizacin de Variables........ 38
Tabla N 12 Indicadores.. 39
Tabla N 13 Diseo de Estudio Pre Experimental.. 41
Tabla N 14 Grupo de Trabajo.... 41
Tabla N 15 Informacin de la Pila del Producto (Product Backlog). 43
Tabla N 16 Release Plan (Sprint Backlog).... 44
Tabla N 17 Determinacin de la Poblacin... 97
Tabla N 18 Tcnicas e Instrumentos de recoleccin 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 Polica (Pre Test).... 104
Tabla N 22 Prueba de Normalidad Tiempo de respuesta de la Polica (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 Clculo de las medias (1) 106
Tabla N 26 Prueba de Rangos con signo de Wilcoxon (1).... 107
Tabla N 27 Clculo de las medias (2).... 108
Tabla N 28 Prueba de Rangos con signo de Wilcoxon (2).... 109
xii
NDICE DE FRMULAS
Frmula (2.1) - Medicin del tiempo de respuesta de la Polica............. 16
Frmula (2.2) - Tiempo promedio de respuesta de la Polica 17
Frmula (2.3) - Porcentaje de Registros de alertas falsas.. 17
Frmula (3.1) - Clculo de la muestra... 97
Frmula (3.2) - Indicadores...100
Frmula (3.3) - Estadstica de Prueba....102
Frmula (3.4) - Promedio...102
Frmula (3.5) - Varianza....103
Frmula (3.6) - Desviacin Estndar.....103
xiii
NDICE DE ANEXOS
Anexo N 1 Matriz de Consistencia.... 116
Anexo N 2 Ficha de Observacin.......................... 117
Anexo N 3 Entrevista al comisario.... 118
Anexo N 4 Ficha de observacin para determinar la Poblacin.... 120
Anexo N 5 Ficha de Observacin: Tiempo de respuesta de la Polica (Pre Test)..... 121
Anexo N 6 Ficha de Observacin: Porcentaje de registro de alertas falsas (Pre Test).. 123
Anexo N 7 Ficha de Observacin: Tiempo de respuesta de la Polica (Post Test)....... 124
Anexo N 8 Ficha de Observacin: Porcentaje de registro de alertas falsas(Post Test).... 126
Anexo N 9 Tabla de criterios para la seleccin de metodologa (1)..... 127
Anexo N 10 Tabla de criterios para la seleccin de metodologa (2)... 128
Anexo N 11 Tabla de criterios para la seleccin de metodologa (3)... 129
Anexo N 12 Tabla de criterios para la seleccin del lenguaje de programacin (1).... 130
Anexo N 15 Criterios de evaluacin de experto gestor de Base de Datos (1).. 133
Anexo N 18 Tabla evaluacin de experto fichas de observacin (1)... 136
Anexo N 19 Tabla evaluacin de experto fichas de observacin (2).137
Anexo N 20 Tabla evaluacin de experto fichas de observacin (3)... 138
Anexo N 21 Cronograma de Desarrollo de la Aplicacin..... 139
Anexo N 22 Modelo Lgico.. 140
Anexo N 23 Modelo Fsico... 141
Anexo N 24 Diagrama de Base de Datos SQL Server 142
Anexo N 25 Carta de Conformidad de Finalizacin 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 Polica al lugar de
la alerta (1)..... 153
la alerta (2). 154
la alerta (3). 155
Anexo N 38 Mapa del mbito Jurisdiccional de la Comisara de Santa Luzmila. 156
Anexo N39 Cdigo fuente del acceso al sistema.. 157
xiv
INTRODUCCIN
Hoy en da uno de los principales problemas que afronta el pas, es la inseguridad
ciudadana. El distrito de Comas, presenta una serie de problemas de inseguridad en
diferentes lugares de su jurisdiccin, problemas tales como: robos, asaltos, consumo de
bebidas alcohlicas, homicidios, estafas, pandillaje, drogadiccin, faltas contra la fe
pblica, violencia familiar, etctera. Durante el periodo del ao 2011, los registros de
las seis comisaras con las que cuenta este distrito, han reportado denuncias por
diferentes delitos y faltas, violencia familiar, accidentes de trnsito 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 tecnologa juega un rol importante como herramienta de control y monitoreo ante
estos sucesos delictivos para las comisarias. Un sistema de comunicacin mvil A-GPS
forma parte de estas herramientas y ayuda en el proceso de atencin de las llamadas de
emergencias.
La presente tesis se realiz en la comisara de Santa Luzmila del distrito de Comas, con
la finalidad de mejorar el proceso de atencin de las llamadas de emergencias que
realizan da a da los ciudadanos, ayudando a tener una respuesta rpida y exacta hacia
el lugar de la emergencia.
La problemtica actual es el tiempo de respuesta de la polica ante un llamada de
emergencia, a esto se suma que muchas de estas llamadas son falsas o tambin
conocidas como llamadas perturbadoras.
El objetivo principal de esta tesis es determinar la influencia de un Sistema de
Comunicacin Mvil A-GPS para la atencin de llamadas de emergencias en la
comisara de Santa Luzmila en el distrito de Comas.
El contenido est organizado de la siguiente manera: El primer captulo, Problema de la
Investigacin, define la problemtica en la organizacin y las preguntas planteadas
para responder a la problemtica, con los objetivos que se desean alcanzar, los
antecedentes que se han encontrado respecto al tema investigado, en el segundo
captulo, Marco Terico presenta la definicin de los conceptos utilizados en el
proyecto para su entendimiento general, el tercer captulo, Marco Metodolgico
describe la metodologa de investigacin, la formulacin de la hiptesis general y
especficas, contiene la metodologa utilizada para el desarrollo del proyecto, la
definicin conceptual y operacional de las variables, el tipo y diseo de investigacin,
las tcnicas de recoleccin de datos y mtodo de anlisis, el cuarto captulo, Resultados
se ofrece los resultados obtenidos de la investigacin, en el quinto captulo,
Conclusiones y Sugerencias se indica las conclusiones y sugerencias, y por ltimo la
presentacin de las referencias bibliogrficas y anexos utilizados.
xv
Universidad Csar Vallejo
Escuela de Ingeniera de Sistemas
I. PROBLEMA DE INVESTIGACIN
1.1
Planteamiento del Problema

En la actualidad, los pases latinoamericanos estn sufriendo el incremento de los
ndices de violencia y criminalidad, as como de la percepcin de inseguridad por
parte de la poblacin, la cual exige a los estados la adopcin 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 (Federacin
Iberoamericana de OMBUDSMAN, 2012).
Para Dammert (2010, p. 32), este incremento del uso de la violencia, la cotidianeidad
de los delitos y la percepcin de carencia de proteccin, son hechos que preocupan a
los ciudadanos y autoridades.
Hoy en da, 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 vctima de un asalto y esto genera un miedo constante en la
poblacin.
Segn (Ipsos Apoyo, 2012), un 75% de peruanos coloca a Lima como la ciudad ms
peligrosa del Per, seguida por Trujillo (52%) y Chiclayo (22%). La percepcin 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 va pblica como el lugar ms
inseguro. Pero la va pblica es casi igual de peligrosa como el transporte pblico,
segn el 83% de los encuestados.
Segn la Encuesta Metropolitana de Victimizacin 2011, realizada por el Municipio
de Lima, seala que el distrito de Comas en Lima Norte es el que tiene la mayor
percepcin de inseguridad ciudadana. El distrito de Comas, presenta una serie de
problemas de inseguridad en diferentes lugares de su jurisdiccin, problemas tales
como: Robos, asaltos, consumo de bebidas alcohlicas, homicidios, estafas,
pandillaje, drogadiccin,
violencia familiar entre otros; estos se agravan
dependiendo la zona en la que se ubica. Estos actos delictivos muchas veces en la
mayora de los casos, no son atendidos al momento por las fuerzas del orden,
dificultando la localizacin 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 nmero de incidencias delictivas del cono Norte de Lima (Instituto Nacional
de Estadstica e Informtica, 2010).
Estos actos delictivos que se presentan da a da, delitos como: robos, secuestros,
extorciones, asaltos a mano armada, etctera. Muchas veces en la mayora de los
casos estos hechos no son atendidos al momento por las fuerzas del orden,
dificultando la localizacin del infractor o presunto delincuente.
El distrito de Comas cuenta con 5 comisaras para atender cualquier tipo de
emergencia:
- Comisara PNP Santa Luzmila, ubicada en Av. Gerardo Unger 6500, Urb. Santa
Luzmila.
Sistema de Comunicacin Mvil A-GPS en el

proceso de atencin de llamadas de emergencias
en la comisara de Santa Luzmila en el distrito
de Comas.
Lpez Chvez, Carlomagno
- Comisara PNP Universidad, ubicada en Av. Universitaria, Cdra. 8, Santa

Luzmila.
- Comisara PNP Tpac Amaru, ubicada en Av. 28 de Julio 1121, km. 11, Av.
Tpac Amaru.
- Comisara PNP Collique, ubicada en Av. Revolucin, Cdra. 26.
- Comisara PNP La Pascana, ubicada en Jr. Jos Carlos Maritegui.
La comisara de Santa Luzmila es responsable de cubrir una rea de 9.70 Km2,
teniendo como lmites de su jurisdiccin las siguientes vas: Av. Panamericana
Norte, Riveras del Rio Chilln, 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 atencin de las llamadas de emergencias.
Elaboracin Propia
Figura N 1
Proceso de atencin de llamadas de la central de emergencias 105.

En la figura N 1 se puede visualizar el proceso de atencin 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, ubicacin donde se produjo la
incidencia, que tipo de incidencia es (Asalto, accidente de trnsito, pandillaje, etc.),
posteriormente, el operador policial deriva esta llamada hacia un efectivo policial
encargado de acuerdo a la ubicacin 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 va radio con la
comisara ms cercana donde se produjo la incidencia para informar la incidencia
de Comas.
registrada, luego la comisara designa de acuerdo a la jurisdiccin que mvil debe

acudir al lugar de la emergencia.
Toda esta secuencia de comunicaciones, desde la central 105 o desde la misma
comisaria hasta la mvil que se encuentra patrullando su jurisdiccin, se ven
dificultados con un sistema de comunicacin radial que muchas veces la batera de
los equipos se encuentran descargados o inoperativos, a esto se suma la demora en
la asignacin policial. Los datos recepcionados respecto al tiempo de respuesta de la
polica ante una llamada de emergencia se puede observar en la grfica N 1, el cual
es resumen de la evaluacin de un pre test, que permiti medir el tiempo de respuesta
de la polica 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 comunicacin radial tiene
muchas deficiencias y muchos equipos se encuentran inoperables debido a la
antigedad de los mismos.
Elaboracin Propia
Grfica N 1
Tiempo promedio de respuesta de la Polica.

Segn las 30 mil llamadas de emergencias telefnicas 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, situacin que
genera saturacin de la lnea 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, situacin que genera saturacin de la lnea
ocasionando que el ciudadano tenga dificultades para comunicarse con la comisaria,
de Comas.
es aqu donde nace otra problemtica, ya que se deja de atender las llamadas de
emergencias reales, ocasionando prdidas de tiempo, econmicas ya que para este
tipo de atencin requieren de toda una planificacin logstica. En la comisaria de
Santa Luzmila del distrito de Comas se obtuvo un resumen de la evaluacin de un
pre test (Ver anexo N 6), donde se registraron 22 alertas falsas durante 11 das,
obteniendo un porcentaje promedio de 45.83%, como se puede apreciar en la grfica
N 2. Este porcentaje es preocupante para la fuerza policial que da seguridad a los
vecinos del distrito de Comas.
Elaboracin Propia
Grfica N 2
Porcentaje promedio de registro de alertas falsas.

A esto se suma, que existen casos cuando en la asignacin de una mvil acude a
atender una emergencia, no existe la manera de conocer si la mvil que fue asignada
se encuentra en el lugar que reportan, ya que en ocasiones para deslindar
responsabilidades se reportan en un ubicacin que no corresponde a su jurisdiccin.
Al analizar la situacin actual para combatir la inseguridad ciudadana, se puede
apreciar que existe una serie de deficiencias, uno de ellos es el sistema de
comunicacin para atencin 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 polica, adems de las llamadas perturbadoras. Esto genera que la poblacin se
sienta desprotegida por las autoridades que brindan seguridad. Si esta problemtica
continua puede ocasionar que la poblacin tome medidas radicales como hacer
justicia por s mismos, generando caos y descontrol en la ciudad.

de Comas.

1.2
Formulacin del problema

1.2.1 Problema General
De qu manera influye un sistema de comunicacin Mvil A-GPS para el
proceso de atencin de llamadas de emergencias en la comisara de Santa
Luzmila en el distrito de Comas?
1.2.2 Problemas Especficos
De qu manera influye un sistema de comunicacin mvil A-GPS en el
tiempo de respuesta de la polica frente a las llamadas de emergencias en la
comisara de Santa Luzmila en el distrito de Comas?
De qu manera influye un sistema de comunicacin mvil A-GPS en el
porcentaje de registros de alertas falsas en la comisara de Santa Luzmila en
el distrito de Comas?
1.3
Justificacin
En el desarrollo se implement un Sistema de Comunicacin Mvil A-GPS que
integra el proceso de atencin de llamadas de emergencias en la comisaria de Santa
Luzmila del distrito de Comas, ya que el sistema de comunicacin con el que cuentan
es va radio con aproximadamente ms de 10 aos de antigedad, en consecuencia
daba como resultado retraso en comunicar a las mviles para acudir al lugar del
incidente, siendo perjudicial para los ciudadanos y los policas que atienden los
llamados de emergencias.
1.3.1 Justificacin Tecnolgica
En el mbito de la tecnologa, esta tesis dota de un nuevo sistema de
comunicacin mvil A-GPS, integrado con una base de datos actualizada que
sistematiza todo el proceso de atencin de llamadas de emergencias en la
comisaria de Santa Luzmila del distrito de Comas, situndola en una
institucin comprometida en la lucha contra el crimen y la delincuencia,
donde la tecnologa y su uso se vuelven necesarias para este proceso.
El desarrollo de las telecomunicaciones durante los ltimos aos ha resultado
fundamental para el desarrollo de la sociedad de la informacin, tecnologas
como las comunicaciones por satlite, desarrollo de la telefona inalmbrica,
la fibra ptica, internet entre otros tecnologas posibilitan el desarrollo
econmico, social y cultural del pas en el que se viene dando avances, pero
an queda mucho por hacer (Instituto Nacional de Estadstica e Informtica,
2002).
A travs del sistema de comunicaciones Mvil A-GPS, facilit una
comunicacin directa entre ciudadano y autoridad, transparente, en tiempo
real haciendo que el ciudadano sea partcipe en su apoyo para combatir la
inseguridad ciudadana haciendo uso de un dispositivo mvil.

de Comas.
1.3.2 Justificacin Operativa

Con el sistema de comunicacin mvil A-GPS la institucin se favoreci
totalmente, donde mejor el proceso de atencin de llamadas de emergencias,
ya que los datos son obtenidos en forma automtica. Facilit la labor de los
efectivos policiales y mejor los procedimiento, hacindolo dinmico y
efectivo. El xito en la gestin de la cadena logstica requiere nfasis en la
integracin de actividades, la cooperacin, coordinacin y el intercambio de
informacin a lo largo de toda la cadena desde la institucin hasta los
ciudadanos. Para hacer frente a la problemtica de la inseguridad ciudadana
se necesit herramientas tecnolgicas, como plataformas, que agilicen los
procesos. Estos sistemas tienen un impacto positivo en la comunicacin, en el
intercambio de informacin favoreciendo a la institucin donde sta se ha
implementado (Serra, 2005, p.85).
Adems a la institucin le sirvi para mejor sus procesos operativos en la
atencin de las llamadas de emergencias, dando una respuesta rpida al
ciudadano.
1.3.3 Justificacin Institucional
Implementado el sistema de comunicacin mvil A-GPS, posicion a la
comisaria de Santa Luzmila a la par con la tecnologa, donde la utilizacin de
herramientas tecnolgicas ya es una realidad y estar ajena a ella dificulta una
adecuada competitividad, a partir de ello la visin y misin de la institucin
establece otros objetivos y metas fortalecindose para combatir la inseguridad
ciudadana. Las Tecnologas de Informacin y la Comunicacin (TICS),
extendidas por toda la organizacin, hacen cambiar a la organizacin, la
competitividad de la empresa depende, en buena parte, de su habilidad de
combinar e integrar estas tecnologas, (Pere y Jaume, 2003, p. 50).
Ello tiene un impacto positivo en la comisaria de Santa Luzmila, ya que el fin
de esta institucin es brindar un buen servicio a la ciudadana, por ello la
implementacin de un sistema comunicacin mvil A-GPS, permiti agilizar
el proceso de atencin de llamadas de emergencias, a su vez garantiza una
mejor imagen institucional hacia los ciudadanos.
1.4
Limitacin
Una de las limitaciones que se tuvo fue el acceso a la informacin 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 comunicacin mvil A-GPS est desarrollado sobre la plataforma
Android, el cual solo puede ser instalado sobre celulares que cuentan con esta
plataforma, versin superior a 2.2.
La aplicacin web, en algunas interfaces se ha desarrollado con cdigo jQuery y
JavaScript para su diseo, la cual funciona correctamente en el explorador web
Google Chrome, sin embargo en otros navegadores como Internet Explorer, el diseo
de la interfaz puede distorsionarse. Es por ello es recomendable utilizar el explorador
web Google Chrome.

de Comas.
En lugares cerrados el sistema de comunicacin Mvil A-GPS, puede perder la

conexin a la Base de Datos del servidor.
1.5
Antecedentes
1.5.1 Antecedentes Internacionales
En el ao 2012, Andrs Quijada, en la tesis Metodologa basada en el
enfoque gil y la gerencia de proyectos de tecnologa de informacin para el
desarrollo de aplicaciones mviles, desarrollada en la Facultad de Ingeniera
escuela de Ingeniera Informtica de la Universidad Catlica Andrs Bello de
la ciudad de Caracas - Venezuela, trat el siguiente problema: Hoy en da el
ambiente con respecto a las aplicaciones mviles es muy voltil y presenta
una evolucin continua en el tiempo. Debido a la importancia que en la
actualidad presentan estos sistemas, la creacin eficiente de una aplicacin
mvil debe darse a travs de un proyecto de desarrollo, el cual, debe estar
sujeto a una metodologa que permita la efectiva ejecucin del proyecto.
El objetivo de la investigacin fue elaborar una metodologa basada en el
enfoque gil y la gerencia de proyectos de tecnologa de informacin para el
desarrollo de aplicaciones mviles de calidad. La metodologa de desarrollo
que utilizo fue el modelo Scrum y cada uno de las tcnicas, como bases para
desarrollar una metodologa de trabajo enfocada a cubrir problemas
vinculados a desarrollo de aplicaciones mviles.
Finalmente la investigacin concluye que la combinacin de tcnicas
provenientes de la gestin de proyectos de tecnologa de informacin,
mtodos, modelos y principios del desarrollo gil, se puede construir una
metodologa que encare todas las situaciones cruciales que sufre el desarrollo
de una aplicacin mvil, y a su vez que pueda adaptarse al dinamismo y
velocidad que presenta el mercado de aplicaciones mviles de la actualidad.
El aporte de la investigacin de Andrs Quijada, que se tom fue la
metodologa de desarrollo Scrum y cada uno de las tcnicas utilizadas. Esta
metodologa sirvi como base para el desarrollo de la investigacin enfocada
a cubrir problemas vinculados a desarrollo de aplicaciones mviles.
Diana Carolina Arce Cuesta y Sebastin Alejandro Cceres Abril en el ao
2011, en la tesis Implementacin de un Web GIS que permita ubicar
llamadas de emergencias para el Benemrito Cuerpo de Bomberos
Voluntarios de la Ciudad de Cuenca, desarrollada en la Universidad
Politcnica Salesiana sede Cuenca, trato la siguiente problemtica: Cuando un
individuo advierte que la vida, salud o propiedad de las personas se encuentra
en peligro debido a algn acontecimiento imprevisto, puede llamar
gratuitamente a la lnea 102 desde cualquier telfono fijo o pblico. El
operador se encarga de tomar los datos necesarios siendo estos; la direccin
exacta de la emergencia, tipo de emergencia (Incendio, accidente de trnsito,
personas heridas, etctera) y nombre completo de la persona que realiza la
llamada, en este proceso existe el riesgo de que la informacin brindada por
el ciudadano no sea la correcta ya sea por el nerviosismo del individuo u otros
aspectos que impidan una buena comunicacin. El objetivo principal de la
investigacin 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.
metodologa utilizada fue RUP y el tipo de investigacin fue experimental

aplicada. Finalmente la investigacin concluye que mediante el Sistema de
Informacin Geogrfico desarrollado con arquitectura Web permite ubicar
una llamada de emergencia de manera gil y oportuna, lo cual es beneficioso
para la ciudadana, y de gran apoyo para el Benemrito Cuerpo de Bomberos
de Cuenca.
De esta investigacin se tom como aporte la estructura de desarrollo web
para el control de registros de alertas que realizan los ciudadanos a la
institucin.
1.5.2 Antecedentes Nacionales
En el ao 2009, Omar Steve Cotrina Daz, en la tesis Aplicacin Web
GIS/GPS basado en Base de Datos Especiales y Algoritmos de Grafos para la
planificacin 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
tecnolgicos y/o clculos matemticos) las rutas a seguir por los vehculos y
flotas de vehculos. El objetivo principal es desarrollar un sistema informtico
capaz de poder planificar rutas y viajes ptimos de transporte usando
tecnologas GIS/GPS y teora de grafos. La Justificacin del proyecto abarca
un rea recurrente todos los das en la ciudad como el uso de vehculos de
transportes con varias finalidades. Con una correcta planificacin de rutas se
puede y viajes se puede obtener ahorro de combustible, mejoras en los
tiempos, mejor uso del personal, etctera. La metodologa de investigacin
utilizada fue Aplicativa. La poblacin son todos los vehculos de Lima
Metropolitana. La muestra son los vehculos de la empresa CLS (Collecte
Localisation Satellites) Per. La metodologa de desarrollo del sistema Web
fue RUP.
De esta tesis se tom como aporte el uso de los mtodos de obtencin de la
ubicacin exacta de un punto en la tierra mediante el principio matemtico de
la triangulacin, adems los datos necesarios para la recepcin de datos GPS.
En el ao 2012, la Unidad de Investigacin FIA de la Universidad San Martin
de Porres, en el proyecto Jallpa Kuyuy Sistema de comunicacin Mvil
GPS Post sismo, trata el siguiente problema: El Per es un pas altamente
ssmico, por lo cual est expuesto a movimientos ssmicos peridicamente,
luego de producirse el movimiento telrico la comunicacin es vital para
conocer el estado de los familiares, en la mayora de veces las lneas
telefnicas colapsan, siendo el medio ms utilizado en esos casos. El objetivo
principal del proyecto tiene como fin desarrollar una aplicacin mvil
integrada con las redes sociales, tecnologa GPS y Cloud Computing, para
contribuir con las comunicaciones entre grupos familiares instantes despus
de ocurrido un sismo. La justificacin del proyecto es muy importante, ya que
mediante este sistema se puede conocer de manera rpida la situacin de los
familiares o amistades. La metodologa que utiliza es Aplicativa. Los
resultados que obtuvieron son de una arquitectura estructurada en mltiples
niveles y diseada para soportar diferentes de plataformas mviles y cloud
computing. El tiempo de respuesta que obtuvieron como mnimo es de 5
minutos ante la respuesta de un familiar segn las pruebas realizadas por el
de Comas.
equipo del proyecto. Adems concluyen que es una solucin que integra las
ventajas de las comunicaciones por redes sociales, la velocidad de la
tecnologa mvil, la precisin de ubicacin de los receptores GPS y las
ventajas de procesamiento y almacenamiento de datos que proveen los
servicios cloud, asegura la comunicacin con los grupos familiares despus
de un sismo. La metodologa que utilizaron para el desarrollo de la aplicacin
fue MSF (Microsft Solution FrameWork).
De este proyecto se tom como aporte el modelo de registro de grupos
familiares o amistades, la posicin frente a una seal de alerta despus de
ocurrido un sismo, adems la ubicacin geogrficamente de las personas, el
indicador tiempo de respuesta ante una emergencia y los resultados obtenidos
para la discusin de resultados.
1.6
Objetivos
1.6.1 Objetivo General
O: Determinar la influencia de un sistema de comunicacin Mvil A-GPS
para el proceso de atencin de llamadas de emergencias en la comisara de
Santa Luzmila en el distrito de Comas.
1.6.2 Objetivos Especficos
O-1: Determinar la influencia de un sistema de comunicacin Mvil A-GPS
en el tiempo de respuesta de la Polica en la atencin de llamadas de
emergencias en la comisara de Santa Luzmila en el distrito de Comas.
O-2: Determinar la influencia de un sistema de comunicacin mvil A-GPS
en el porcentaje de registros de alertas falsas en la comisara de Santa
Luzmila en el distrito de Comas.
O-3: Implementar un sistema de comunicacin mvil A-GPS para mejorar el
proceso de atencin de llamadas en la comisara de Santa Luzmila en el
distrito de Comas.

de Comas.
II. MARCO TERICO

2.1
Marco Terico
2.1.1 Sistema de Comunicacin Mvil A-GPS
El sistema de comunicacin mvil GPS (Sistema de Posicionamiento Global)
est formado por una constelacin de satlites que orbita la tierra dos veces al
da, transmitiendo informacin precisa de tiempo y posicin a cualquier lugar
de la tierra, las 24 horas del da.
La constelacin GPS est formada por 24 satlites que giran alrededor de la
tierra en seis planos fijos, que estn inclinados 60 desde el Ecuador. La
constelacin de satlites es operada y verificada por la fuerza area de los
Estados Unidos de Norteamrica, desde su estacin principal en Colorado.
Esta estacin est equipada con sistemas para monitoreo de satlites
telemetra, transmisin y recepcin de datos, etctera. Adems de esta
estacin en Colorado, otras estaciones y antenas estn instaladas alrededor del
mundo, para hacer el seguimiento de los satlites y enviar la informacin a la
estacin central. Con esta red de estaciones, se mantiene y actualiza la
posicin exacta de los satlites y la precisin de los datos, ajustndose las
pequeas discrepancias que puedan observarse cada vez que es preciso
(Unidad de Investigacin FIA/USMP 2004, p.140).
Segn Van Diggelen (2006, p. 11), un Assisted GPS (A-GPS) mejora en el
rendimiento del GPS estndar, proporcionando informacin, a travs de un
canal de comunicacin alternativo, que el receptor GPS normalmente recibe
de los propios satlites. El A-GPS no es excusa para el receptor de recibir y
procesar las seales de los satlites, sino que simplemente hace que esta tarea
sea ms fcil y reduce al mnimo la cantidad de tiempo y la informacin
necesaria de los satlites. El receptor A-GPS todava hace mediciones de los
satlites, pero puede hacerlo ms rpidamente, y con seales ms dbiles, que
un receptor sin ayuda.
Frank Van Diggelen, 2009.
Figura N 2
Visin general de la asistencia A-GPS.

de Comas.
10
La figura N 2 muestra al servidor de localizacin y la base de estacin

celular proporcionar algn subconjunto de la informacin mostrada. Los
datos de asistencia se usan en el receptor A-GPS para reducir la frecuencia y
la bsqueda de cdigo de retardo. El rango de bsqueda se indica por las cajas
rectangulares blancas, y la seal del satlite deseado se encuentra en la
interseccin de las dos cajas. Cuanto ms precisa los datos de asistencia, ms
estrecho ser el intervalo de bsqueda se puede prestar asistencia siempre
proporciona cierta reduccin en la bsqueda de frecuencia, pero hay una
reduccin en la bsqueda del cdigo de retardo slo si bien en tiempo de
asistencia est disponible.
Un servidor de Assisted GPS proporciona datos a un terminal inalmbrico
que es especfica a la ubicacin aproximada del telfono con el fin de
minimizar la TTFF (The Time to First Fixe) y maximizar el rendimiento. La
localizacin aproximada de la unidad porttil se puede determinar por
diversos medios. Si el telfono se encuentra en una red celular, puede venir de
la ubicacin de la torre de la clula, que puede haber sido introducida por el
usuario al seleccionar una ciudad de un mapa, que puede haber sido calculado
utilizando otra tecnologa de localizacin, o que puede venir desde una
ubicacin almacenada previamente en el terminal inalmbrico, de esta manera
explica Harper (2009, p. 5).
Para Zandbergen y Barbeau (2011, p. 383), sostiene que el Assisted GPS es
una tecnologa popular que mejora el GPS convencional, especialmente en el
rea de redes de telefona mvil. En sistemas A-GPS, la informacin til se
proporciona por la red celular que puede ayudar al receptor del GPS para
calcular una posicin precisa ms rpidamente. A-GPS utiliza informacin de
ms de una fuente, mientras que el clculo de la posicin del dispositivo.
Herramientas para el desarrollo del Sistema de Comunicacin Mvil AGPS:
Para el desarrollo de la aplicacin mvil de la presente investigacin se
realiz bajo la plataforma Android. Para esto fue necesario de un IDE Eclipse
y un plugin Android Development Tools (ADT) que est diseado para darle
un ambiente potente, integrado en la construccin de aplicaciones de
Android.
Cada vez son ms los dispositivos mviles 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 telfonos inteligentes en todo el mundo a los
usuarios finales por sistemas operativos en el primer trimestre de los aos
2012 y 2013.

de Comas.
11
Tabla N 1 Ventas de telfonos inteligentes en todo el mundo a usuarios finales

por el sistema operativo en el 1T13 (Miles de Unidades)
1T13
1T12
Sistema
1T13
Participacin
1T12
Participacin
Operativo Unidades Mercado (%) Unidades 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 telfonos mviles inteligentes o tabletas basado
en Linux, es conocido como el representante de software libre en el mundo
mvil 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 mviles y que incluye tanto un sistema operativo, como
middleware y diversas aplicaciones de usuario. Representa la primera
incursin seria de Google en el mercado mvil y nace con la pretensin de
extender su filosofa a dicho sector.
Todas las aplicaciones para Android se programan en lenguaje Java y son
ejecutadas en una mquina virtual especialmente diseada para esta
plataforma, que ha sido bautizada con el nombre de Dalvik. El ncleo de
Android est basado en Linux 2.6. La licencia de distribucin elegida para
Android ha sido Apache 2.0, lo que lo convierte en software de libre
distribucin. A los desarrolladores se les proporciona de forma gratuita un
SDK y la opcin de un plug-in para el entorno de desarrollo Eclipse varias
que incluyen todas las API necesarias para la creacin de aplicaciones, as
como un emulador integrado para su ejecucin. Existe adems disponible una
amplia documentacin de respaldo para este SDK. Adems de todo ello, otro
aspecto bsico para entender la aparicin de Android es que pretende facilitar
la integracin de estos dispositivos con las posibilidades cada da mayor
ofrecidos por la Web. Por ejemplo, una aplicacin desarrollada en Android
podra ser aquella que indicase al usuario, a travs de Google Maps, la
localizacin de sus diferentes contactos de la agenda y que avisase cuando
stos se encuentren a una distancia cercana o en una ubicacin determinada.
Para entender mejor, a continuacin cito el diagrama de la arquitectura
Android:

de Comas.
12
Recuperado de:
http://androideity.com/2011/07/04/arquitectura-deandroid/
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 libreras 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 comunicacin fluida entre la institucin y los
ciudadanos, con la tendencia a convertirse con el tiempo en una red de
comunicacin con las dems comisarias. La ventaja de una plataforma web es
que cuenta con un interfaz de fcil manejo para el operador y que pueda
comunicarse en el menor tiempo posible con los usuarios y efectivos
policiales. El sistema de comunicacin mvil A-GPS es de gran aporte para la
institucin ya que permite mejorar sus procesos y obtener resultados en
tiempo real. Gracias a la plataforma web los ciudadanos tienen la opcin de
registrarse gratuitamente y descargar la aplicacin mvil para instalar en su
dispositivo mvil.
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 funcin de servidor se puede instalar
ms 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 travs de un URL (Uniform
Resource Locator), las versiones ms utilizadas del protocolo HTTP son:

de Comas.
13
0.9: Esta versin estaba destinada a la transmisin de pginas web en formato

HTML. Slo soporta un mtodo de envo de las solicitudes, no se devuelve al
cliente ninguna informacin acerca del contenido de las pginas.
1.0: Entre los grandes cambios introducidos en esta versin se encuentra el
soporte para ms 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 versin, las novedades ms importantes son la presencia de la
conexin y el soporte de hosts virtuales. Se han aadido los mtodos
siguientes: PUT, DELETE, OPTIONS y TRACE. A la autenticacin BASIC
se ha aadido el modo de autenticacin DIGEST. Antes de que apareciese la
persistencia de conexin, una pgina web con imgenes realizaba tantas
conexiones con el servidor web como archivos tuviera que transmitir.
Recuperado de:
http://androideity.com/2012/07/05/login-enandroid-usando-php-y-mysql/
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
ningn mtodo que permita conectarse a travs 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 cul se pueda acceder a l
pasando diversos parmetros nos devuelve ya sea en formato XML o JSON,
para la presente investigacin se utiliz XML, HTML y PHP.
2.1.2 Proceso de atencin de llamadas de emergencias:

Para Heinz y Barnes (2011, p. 9), las llamadas de emergencia son una funcin
crtica del sistema telefnico actual; ya no son una caracterstica opcional.
de Comas.
14
Con el fin de obtener ayuda en caso de emergencia, la gente recurre al

telfono ms cercano y llama a un nmero de emergencia conocido.
Una llamada de emergencia es con frecuencia la accin que inicia una
respuesta de emergencia, pero rara vez es la nica forma de comunicacin
que tiene lugar como parte de esa respuesta. Adems 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 pblica (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 ms fcil, 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 informacin que brindan las personas a menudo no
proporciona la informacin suficiente o en otros casos brindan informacin
incorrecta, hacindose dificultoso la ubicacin de la persona. Por esta razn,
los sistemas que proporcionan informacin de la ubicacin exacta de la
persona a la operadora puede ser una mejora esencial para un sistema de
llamadas de emergencias.
Segn Carrion y Dammert (2009), la ciudadana del Per, actualmente siente
insatisfaccin ante la respuesta inmediata de los delitos que se suscitan da a
da, ya que afectan directa y cotidianamente a las personas. Entre los delitos
estn los asaltos en la va pblica, pandillaje, robo de vehculos y de
accesorios, micro comercializacin 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 sensacin de peligro contra la integridad fsica o los bienes materiales
percibida por los ciudadanos en estos ltimos aos debe ser contrastada con la
informacin que efectivamente registra la Polica Nacional del Per en cuanto
a denuncias sobre delitos y faltas contra la persona, el patrimonio, las buenas
costumbres y la seguridad pblica.
En la grfica N 3 se observa que, durante el ao 2010, la Polica 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 ms que el ao
anterior, representando un incremento de 13.07% en la incidencia delictiva.

de Comas.
15
Anuario Estadstico 2010 PNP
Grfica N 3
Tendencias de denuncias por delitos en el Per.

Por otra parte, los delitos contra el patrimonio (hurto, robo, apropiacin
ilcita, estafas, otros) se present la mayor cantidad de denuncias,
registrndose 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
trmino por los delitos contra la seguridad pblica (TID, micro
comercializacin 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 Estadstico
2010, Polica Nacional del Per).
Para la presente investigacin se tomaron las dimensiones: Tiempo de
respuesta de la polica y llamadas de emergencias perturbadoras.
A. Tiempo de respuesta de la polica.
Se define como el tiempo que pasa desde que se enva una alerta y se recibe
la respuesta.
Clculo del tiempo de respuesta de la polica ante las llamadas de
emergencias:
Para este clculo se ha utilizado una metodologa con una situacin real para
determinar el tiempo de respuesta de la polica ante una llamada de
emergencia.
Segn Taha (2004, p. 665), el tiempo de atencin se resume con la siguiente
frmula:
T = (Hip Hrll)
..Frmula (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).

de Comas.
16
Luego se tiene:
Dnde:
T
Hrll
Hip
TA
.........Frmula (2.2)
= Tiempo de respuesta de la polica.

= Hora de recepcin de llamada.
= Hora de intervencin policial.
= Tiempo Promedio de respuesta de la Polica.
Para Kazmier y Daz (1999, p. 304), un nmero 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
atencin haciendo uso de la lnea telefnica.
Clculo 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 frmula a un registro de alerta falsa se le
considera tambin como llamada falsa, distractora o perturbadora y se toma
la formula por cantidades (Adecuado).
Para este clculo se ha utilizado la siguiente frmula:
Praf =
Traf
X 100
Tra
Frmula (2.3)
Dnde:
Praf = Porcentaje de Registro de Alertas Falsas.
Traf = Total de Registros de alertas falsas
Tra = Total de Registro de alertas
C. Metodologa de desarrollo del Sistema de Comunicacin Mvil AGPS.
Para Figueroa, Sols y Cabrera (2010), desarrollar un buen software depende
de un sin nmero de actividades y etapas, donde el impacto de elegir la mejor
metodologa para un equipo, en un determinado proyecto es trascendental
para el xito del producto. El papel preponderante de las metodologas 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.
de Comas.
17
Para la presente tesis se evaluaron tres principales metodologas de desarrollo

de software, determinando as cual es la ms adecuada para el desarrollo del
sistema de comunicacin mvil A-GPS como apoyo al proceso de atencin de
llamadas de emergencias o a su vez una combinacin de dichas metodologas.
En la tabla N 2 detalla las diferencias existentes en dichas metodologas de
desarrollo de software.
Tabla N 2 Cuadro comparativo de Metodologas
METODOLOGA
RUP
Scrum
MSF
XP
VENTAJAS
DESVENTAJAS
- La ventaja principal de RUP es

que se basa todo en las mejores
prcticas 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 duracin 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)
- Programacin organizada.
- Menor taza de errores.
- Satisfaccin del programador.
- Es ms fcil comprobar el
progreso del proyecto ya que las
reuniones frecuentes son parte de
la misma.
- Aplica mucho e incentiva al
trabajo en equipo y a la
colaboracin.
- Es til para proyectos de pequea
y gran escala.
- Crea una disciplina de anlisis de
riesgos que ayuda y evoluciona
con el proyecto.
- Cuenta con plantillas que ayudan
para
el
proceso
de
documentacin.
- Desarrollo iterativo e incremental
- Pensado para proyectos y equipos
grandes, con roles designados y
con una duracin extendida.
- Programacin organizada
- Menor taza de errores
- Es recomendable emplearlo solo

en proyectos a corto plazo.
- Altas comisiones en caso de
fallar.
- Por ser un modelo prescriptivo,

solicita
demasiada
documentacin en sus fases.
- El anlisis de riesgos es
necesario, pero si se lo hace
muy exhaustivo puede demorar
o hasta frenar el proyecto.
- Al estar basado en tecnologa
Microsoft, trata de obligar a
usar herramientas de ellos
mismo.
-Proyectos cortos con equipos
pequeos y rotables en cuanto a
roles.
- Recomendable su empleo solo
en proyectos a corto plazo.
- Altas comisiones en caso de
fallar.
Fuente: Elaboracin Propia

de Comas.
18
Tabla N 3 Criterios de seleccin de Metodologa

CRITERIOS
RUP
Scrum
MSF
XP
TOTAL
15
15
13.33
10
53.33
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 documentacin
adecuada
Facilita la integracin entre
etapas de desarrollo
Relacin con UML
16.66
15
10
10
51.66
11.66
16.66
10
11.66
49.98
18.33
13.33
11.66
10
53.32
Permite desarrollo software

sobre cualquier tecnologa
TOTAL
11.33
15
10
10
46.33
116.31
123.32
88.31
83.32
Grado de conocimiento
Soporte orientado a objetos

Luego de evaluar las metodologas mencionadas en la tabla N 3, donde se observa
el puntaje de evaluacin, validado por tres expertos (Ver anexos 9, 10 y 11), por lo
tanto se lleg a determinar el uso de una metodologa gil como es el modelo
Scrum y cada una de las tcnicas que utiliza, como bases para el desarrollo de la
aplicacin mvil y web.
a) Metodologa Scrum
Scrum es un SDM (Reunin diaria de Scrum) gil que divide el desarrollo en
iteraciones (sprints). Las caractersticas de cada sprint provienen de la acumulacin
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 reevaluacin del
uso de SDM. Esta era de reevaluacin hizo hincapi en la necesidad y la
importancia de un mtodo vlido y fiable de evaluacin, especialmente despus de
la implementacin de un SDM, de esta manera lo define Fujita y Domnico (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
iteracin es un ciclo corto de construccin repetitivo). Cada ciclo o iteracin
termina con una pieza de software ejecutable que incorpora nueva funcionalidad.
Las iteraciones en general tienen una duracin entre 2 y 4 semanas. Scrum se utiliza
como marco para otras prcticas de ingeniera de software como RUP o Extreme
Programming, el proceso de funcionalidad de Scrum se visualiza en la figura N 5.

de Comas.
19
Recuperado de:
http://www.scrummanager.net/files/
sm_proyecto.pdf
Figura N 5
Ilustracin cmo funciona la metodologa Scrum.

A continuacin se describe como se da la combinacin del modelo Scrum y cada
una de las tcnicas:
Iniciacin del Proyecto.
Para poder iniciar un proyecto de aplicacin mvil existen una seria de
preguntas que deben ser contestadas para comenzar el desarrollo teniendo una
visin general del problema que se desea resolver. El documento de iniciacin
debe contener la siguiente informacin:
-
Informacin del Cliente o Empresa.

Cul ser el nombre comercial de la aplicacin mvil?
Objetivo general de la aplicacin mvil?
Bajo qu plataformas ser ejecutada la aplicacin?
Qu tipo de aplicacin ser? Nativa, WEB o Hbrida
Cualquier otra informacin de inters para el proyecto puede ser incluida en este
documento de iniciacin 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 mvil, dispositivos o tipo de
aplicacin.
Historias de Usuario.
Segn Quesada X. (2009), las historias de usuario deben aportar valor al negocio
de forma independiente e incremental. Tambin 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 funcin (el por qu). La estructura
de una historia de usuario est formada por:
de Comas.
20
- Nombre breve y descriptivo.

- Descripcin de la funcionalidad en forma de dilogo o monlogo del
usuario describiendo la funcionalidad que desea realizar.
- Criterio de validacin y verificacin que determinar para considerar
terminado y aceptable por el cliente el desarrollo de la funcionalidad
descrita.
Y adicionalmente por la informacin que resulte necesaria por el modelo de
implementacin: Prioridad, Riesgo, Tamao, etc.
Tabla N 4 Formato de Historias de usuarios
Nombre de la Historia
Descripcin de la Historia de Usuario
Prioridad del Cliente
Condiciones de Satisfaccin
(De ser necesario)
Nmero de Complejidad
(Puntos de Historia)
Fuente: Elaboracin 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 aplicacin
lo antes posible. Las prioridades deben darse a travs de colores, como se
muestra a continuacin:
- Primer color: Indicar las funciones que deben desarrollarse lo antes
posible, las que posiblemente estn implementadas para el primer
lanzamiento y en las cuales se base la idea principal de la aplicacin.
- Segundo Color: Referenciar aquellas historias de usuario que contengan
funciones secundarias que complementen la idea principal de la aplicacin.
- Tercer Color: Cualidades o caractersticas de la aplicacin que aporten
valor pero que no se requiera de ellas para que el usuario pueda realizar la
funcin principal.
Asignacin del Nmero de Complejidad:
Con respecto a la estimacin de esfuerzos se utiliz la tcnica Planning Poker.
Segn Quesada (2009), esta tcnica trata de un consenso entre los
desarrolladores llevado a cabo con una serie de serie de Fibonacci, teniendo
en cuenta que entre ms bajo es el nmero acordado, menor ser la
complejidad historia. La unidad que representa la numeracin de complejidad
de la historia de usuario por lo general es llamada Puntos de Historias, y son
de Comas.
21
distintos para cada grupo de desarrollo ya que no todos los equipos asignaran
el mismo nmero de complejidad a la misma historia de usuario.
Los pasos para esta tcnica se describen a continuacin:
- 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
satisfaccin 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 simultneamente, con la finalidad de
no condicionar los esfuerzos de los desarrolladores.
- Las personas que tuvieron los nmeros ms altos explican porque
seleccionaron ese nmero (pueden aparecer problemas que no fueron
pensados por los dems) y los que seleccionaron un nmero ms 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 Mvil:
Una manera en la cual las historias de usuario pueden satisfacer en parte las
meta-requerimientos, es si estas mantienen un vnculo con los dispositivos
mviles. Si resulta complejo adaptar las historias de usuarios a funciones
que puedan ser desarrolladas bajo una plataforma mvil lo ms 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 mvil estarn incluidas en el desarrollo porque de
ellas depende el buen funcionamiento de la aplicacin.
Ya que el desarrollo mvil por lo general mantiene situaciones generales en
cuanto a desarrollo, dentro del modelo existirn algunas historias de usuario
estndar. Es decir, sern historias que pueden ser incluidas en el desarrollo
presentando adaptaciones al problema que se trata. Estas historias estndar
se muestran a continuacin:
- Configuracin de la App: Todo usuario mvil por lo general tiene la
capacidad de personalizar su aplicacin para adaptar su contenido a su
preferencia, generando ms agrado y satisfaciendo de forma ms cmoda
sus necesidades. Es por esto que dentro de las historias de usuario puede
existir alguna que trate sobre la configuracin y personalizacin de la
aplicacin.
- Agrado o deteccin de errores: Con la finalidad de conocer las
debilidades y errores de la aplicacin, esta debe contar con una funcin
que permita a los usuarios finales evaluar la aplicacin de forma sencilla
de Comas.
22
(Cualitativamente o Cuantitativamente) o informar a los desarrolladores

de algn error para que este pueda ser corregido a la brevedad posible.
- Actualizar o Descargar: El desarrollo de las aplicaciones mviles por lo
general vincula muchas actividades orientadas a las ventas, implicando
las configuraciones necesarias para poder incluir la aplicacin 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 aplicacin pueden estar incluidas
en una historia de usuario.
Descomposicin de Historias de Usuario:

Para que las historias de usuario puedan ser desarrolladas, estas deben ser
descompuestas en tareas. La definicin de estas tareas presenta un factor
importante para el resto del desarrollo. A continuacin, tomando en cuenta lo
descrito por Garzs J. (2012), se describen buenas prcticas para la
descomposicin de historias de usuario:
- A la hora de descomponer las historias de usuario en tareas, se debe tener
en cuenta que el tamao de la tarea debe permitirle a un integrante del
equipo desarrollarla entre medio da hasta un mximo de 4 das de trabajo,
Garzs plantea que las tareas de muy poco tiempo (menores a medio da de
trabajo) generan prdidas de tiempo al ser gestionadas, mientras que
cuando pasan de 4 das lo ms probable es que esta tarea pueda ser
dividida en tareas ms pequeas y as facilitar su gestin.
- 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 mdulo de registro de usuario o
mdulo de atencin al cliente. De esta forma, las tareas no dependen de
otras tareas para poder ser probadas.
- No es recomendable dedicar mucho tiempo al anlisis de tareas para
determinar estimaciones. Garzs opina que muchas veces el equipo de
desarrollo analiza con exactitud los detalles de la tarea para generar una
estimacin ms precisa, lo que puede generar demoras de tiempo
innecesarias en el proceso de divisin 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
informacin durante el desarrollo y as facilitar su gestin.
Release Plan.
Una vez que las historias de usuario son definidas el equipo de desarrollo puede
armar un release plan donde indicar cuales historias sern desarrolladas en cada
uno de los Sprint del proyecto. Dicho plan mantiene una referencia fuera de los
Sprints de cmo ir siendo el desarrollo y como se darn los avances, teniendo
de Comas.
23
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.
Sprint
Primera Versin
Tabla N 5 Formato de Release Plan

Historias
Complejidad Complejidad Total
Historia 2
Historia 5
Historia 1
Historia 3
Historia 4
2
6
4
6
5
Historia Y
Sprint X
Historia Z
Historia W
4
4
4
Sprint 1
Sprint 2
12
11
Versin M
12
Un aspecto importante que hay que considerar es indicar cuales Sprint

conformarn las versiones que se espera de la aplicacin manteniendo como
premisa que el desarrollo de una versin, puede contar con el desarrollo de
varios Sprint.
Sprint.
Al basar la metodologa 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 algn software operativo.
Cuando inicia un sprint, inicia la oportunidad de gestionar el desarrollo de la
aplicacin ya que las historias de usuario seleccionadas para el sprint actual no
podrn ser cambiadas mientras este se lleva a cabo. Es aqu donde entran las
tcnicas justo a tiempo y las reuniones tpicas de Scrum (Orientadas a los metarequerimientos) para gestionar el sprint y optimizar el desarrollo de los mismo.
Reuniones de Sprints:
Estas reuniones ayudarn a vincular a todo el equipo en la toma de decisiones
del proyecto. Entre estas reuniones se discutirn temas orientados al
desarrollo de aplicaciones mviles:
- Reuniones de Planificacin: Estas son las reuniones en las cuales el
equipo de desarrollo decide que historias de usuario sern 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 versin viable para el cliente con la
finalidad de que pueda ser lanzada al mercado lo antes posible. De igual
de Comas.
24
manera se definen con mayor precisin las historias de usuario y cules

sern las actividades de la misma.
- Reuniones Diarias: Reuniones cortas (15 a 20 minutos) en las que se
habla del trabajo realizado el da anterior, expectativas del da actual y
errores inesperados.
De igual manera informacin relevante para el desarrollo debe ser
mencionada en estas reuniones constantemente, como cualidades
importantes de la plataforma o virtudes importantes de libreras mviles
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 diseo.
Por lo general, cuando esto ocurre es posible que la reunin se prolongue
ms tiempo.
- Reuniones de Revisin: En estas reuniones el cliente prueba las funciones
de la aplicacin mvil 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 retroalimentacin del
cliente para indicar posibles cambios dentro de la aplicacin y verificar la
satisfaccin del mismo en cuanto al producto obtenido.
- Retrospectiva del Sprint: Para el desarrollo mvil esta puede ser la

reunin ms importante, porque en ellas el equipo decide en funcin de la
experiencia recibida en el sprint, que historias de usuarios deben
permanecer, ser agregadas o quitadas de la actual versin 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 cundo sacar o dejar una historia de
usuario para una versin determinada. Si el desarrollo presenta retrasos,
probablemente el equipo deba optar restringir la prxima versin a las
historias de usuario claves, y posponer aquellas de priorizacin media o
baja para posteriores versiones o actualizaciones. Si el desarrollo se ha
venido dando ms rpido de lo esperado, es posible que nuevas historias
de usuarios puedan entrar en la versin actual con la finalidad de proveer
ms funciones en una misma versin.
Gestin de un Sprint:
Para guiar el desarrollo dentro del sprint la metodologa se basar en las
distintas tcnicas justo a tiempo que fueron seleccionadas en el captulo
anterior para gestionar el desarrollo de cada una de las tareas.
- Descripcin de Fases:
Basndose en el modelo visual de Kanban clsico (Figura N 6), el equipo
de desarrollo utiliz una pizarra de tareas para conocer cmo fluye el
trabajo.

de Comas.
25
Recuperador de: http://www.crisp.se/fileuploads/Kanban-vs-Scrum.pdf
Figura N 6
Fases de Kanban Clsico

Las historias de usuario totales del proyecto y de las que son seleccionadas en el
sprint actual, la primera fase del modelo clsico 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 estarn
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.
Recuperado de: http://www.crisp.se/fileuploads/Kanban-vs-Scrum.pdf
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 tambin hacer uso de la Reunin de Planificacin con el
cliente. En estas charlas, a travs de preguntas, el equipo debe documentar la
descripcin de la historia de usuario con mayor claridad, sus posibles
de Comas.
26
condiciones de satisfaccin 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 funcin o es para corregir algn error detectado. Este documento debe
estar revisado y aprobado tanto por el cliente como por el encargado de gestionar
la historia de usuario (posiblemente lder del proyecto). Debe manejarse un
documento de este tipo (Ver tabla N 6) para cada historia incluida en el sprint,
con el propsito de facilitar no solo la toma de decisiones con respecto a cada
historia sino tambin el proceso de validacin con el cliente una vez que la
historia este implementada.
Tabla N 6 Formato de Descripcin 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,
nmero de identificacin con la historia, indicar (si es posible) todas las
dependencia que tenga esa tarea con respecto a las dems 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):
Elaboracin Propia
Figura N 8
Formato de Tareas

de Comas.
27
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 mviles dicha fase estar dividida en 3 subfases.
Diseo Mvil: Tomando en cuenta Mobinex V4 (2009) el diseo de
aplicaciones mviles debe estar dirigido a dos secciones. La primera debe ir
orientada al aspecto visual de la aplicacin (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 cmo deben ser
las interfaces que se desarrollarn ms adelante. Esta tcnica promueve la
creatividad del usuario y con la ayuda de algn integrante del equipo se
aclaran de forma ms 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 diseos referentes a la seccin detrs de la
aplicacin (back-end), es decir, las estructuras que permitan manipular la
informacin de forma dinmica si es necesario. Estas estructuras pueden estar
basadas en modelos cliente/servidor, Stub Service o Servicios Online. Esto se
puede definir a travs de modelos entidad relacin, 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 sern los utilizadas para implementar la aplicacin, tales como
Servicios WEB, JSON u otros y podran contar con un listado de mensajes de
errores en caso de alguna falla en particular.
Recuperado de:
http://www.scrummanager.net/files/sm_proyecto.pdf
Figura N 9
Formato de Story Boards.

Planificacin de Pruebas: El modelo debe contar con tcnicas que
promuevan la fcil deteccin de errores, ya que entre ms rpido se detecta un
de Comas.
28
error, ms fcil es corregirlo. Haciendo uso de Jidoka la segunda fase la

conformarn la planificacin de las pruebas de unidad y de integracin, para
contar con un mecanismo que permita alertar ante posibles situaciones
errneas y poder plantear una solucin de respuesta a dicha situacin 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
implementacin). El siguiente formato de la figura N 10 permiti registrar
los casos utilizados para las pruebas de unidad y ya que las pruebas de
integracin estn conformadas por la unin de todas las pruebas de unidad,
los casos de pruebas unitarias contaban con una seccin que les permiti
registrar resultados en la fase de integracin, 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, diseador de la
prueba, modelo de dispositivos donde se ejecut las pruebas, y versiones de
Sistemas Operativos (Descritos en el documento de inicio) adems 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.
Recuperado de:
http://www.scrummanager.net/files/sm_proyecto.pdf
Figura N 10
Formato de Pruebas de unidad

Implementacin: Por ltimo, dentro del trabajo en progreso, est la fase de
implementacin donde se implementaron todas las tareas del sprint. En esta
fase del desarrollo el programador pudo contar con las pruebas de unidad para
de Comas.
29
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 cdigo rpidamente. De igual
forma la parte de implementacin est compuesta por dos subfases como lo
plantea Mobinex V4 (2009):
- Implementacin de Interfaces de Usuario: El primer paso dentro de la
implementacin est dirigido a las interfaces de usuario. Con la ayuda del
documento de descripcin de la historia y los Story Boards, el
programador mantiene una visin de cmo deben lucir las interfaces y los
elementos que esta debe contener. Ahora bien, ya que los Story Boards no
mostrarn 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 ms
sencillo garantizar la satisfaccin del cliente.
- Implementacin de Servicios e Integracin de Tarea: En esta fase el
equipo de desarrollo no solo hace uso del documento de descripcin de la
historia, diagramas de diseo de servicios (Modelo E-R, Casos de Uso,
entre otros) y documentos de pruebas, sino tambin de las interfaces
implementadas. De esta manera, el equipo est claro en cmo crear las
estructuras ya que conoce con exactitud como los datos sern manipulados
por las interfaces. Una vez que los ambas partes han sido desarrolladas
(interfaces y servicios), el programador debe integrarlas asegurndose que
al final, la tarea ya implementada pase la prueba de unidad respectiva.
Recuperado de:
http://www.scrummanager.net/files/
sm_proyecto.pdf
Figura N 11
Fases de Trabajo en Progreso.

Para la fase final de trabajo realizado, ser necesario hacer una pequea pero
importante modificacin. En muchas situaciones ser necesaria la integracin de
diversas tareas para culminar una funcin o historia, es por ello que una vez que
las tareas son desarrolladas y probadas individualmente, estas deben culminar en
una fase de integracin para completar la implementacin de la historia de
usuario. En esta fase de la metodologa se usarn los documentos de prueba para
de Comas.
30
verificar que no existen errores luego de la integracin de tareas (para formar

una historia), los cuales detectarn si existe algn inconveniente en dicha
integracin, 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 integracin tambin se debe llevar a cabo antes de pasar al trabajo
realizado. Los resultados de las pruebas de integracin deben quedar
documentados ya que los errores detectados y corregidos a travs de estas
pruebas difcilmente pueden ocurrir nuevamente si el equipo mantiene un
registro de ellos, de igual forma ante problemas similares en el futuro, estas
pruebas de integracin pueden servir de patrn.
Una vez que las historias llegan a la ltima fase de trabajo realizado, el equipo
debe mantener informacin de los errores que contenga esa historia que no
pudieron ser corregidos a tiempo si llegase a tenerlos. Esta informacin en
conjunto con las descripciones de tareas y casos de prueba puede ser utilizada en
las distintas reuniones para platear estrategias de solucin entre los
desarrolladores.
Recuperado de:
http://www.scrummanager.net/files/sm_
proyecto.pdf
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 programacin
Para Josep (2007) un lenguaje de programacin es como un conjunto de smbolos
y textos inteligibles por la unidad de programacin que le sirve al usuario para
codificar sobre un cierto autmata las leyes de control deseadas, mientras que
lenguaje de exploracin 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 programacin que se utilizan comnmente para crear sitios
web. A diferencia de las pginas HTML estticas habituales, sitios web ASP y PHP
son ms dinmicos y pueden permitir a los usuarios interactuar e intercambiar

de Comas.
31
informacin a travs de bases de datos desde el sitio web, en la siguiente tabla se

hace una comparacin entre estos dos lenguajes de programacin.
Tabla N 7 Lenguaje de Programacin
ASP.Net
PHP
- ASP (Active Server Pages) - PHP o Hypertext Preprocessor, corre
necesita
un
servidor
de
con Linux o UNIX. Los programas
Microsoft para que el sitio web
PHP ms actualizados ahora se
funcione.
pueden ejecutar en un servidor NT.
- ASP slo puede trabajar con las - Programas PHP tambin se puede
plataformas
basadas
en
ejecutar en Windows, Solaris, Unix y
Window. Recientemente, ASP
Linux.
ahora se puede ejecutar en una
plataforma Linux dado que no - PHP slo requerira que se ejecuta en
existe un programa de ASPun servidor Linux, que se puede
Apache instalado en su servidor.
obtener sin costo alguno.
- ASP es muy similar a la sintaxis
y la interfaz de programacin
Visual
Basic.
Esto
es
bsicamente debido a que
Visual Basic est relacionada
bsicamente 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. Adems pueda que
tenga que comprar herramientas
adicionales.
- PHP es muy flexible en trminos de

conectividad de base de datos. Se
puede conectar a varias bases de datos
de los cuales el ms utilizado es el
MySQL, cuyo costo para usar es cero.
- Cdigos PHP se ejecuta mucho ms
rpido que ASP, bsicamente, porque
se ejecuta en su propio espacio de
memoria.
- Al trabajar con PHP, la mayora de las
herramientas relacionadas con el
programa son el software de cdigo
abierto en su mayora por lo que no
tiene que pagar por ellos.
- ASP utiliza un servidor de

gastos generales y se utiliza una
arquitectura basada en COM.
- En trminos de conectividad de
base de datos ASP necesita de
MS-SQL, un producto de
Microsoft, el cual implica un
costo.
Fuente: http://www.aspvsphp.com/

de Comas.
32
Tabla N 8 Criterio de seleccin del lenguaje de programacin

CRITERIOS
Posee documentacin
adecuada
Grado de conocimiento
Posee el cdigo abierto
Soporte en varias
plataformas
Requiere definicin de
variables
Soporte gran cantidad de
base de datos.
Total :
PHP
ASP.Net
Total
18.33
11.66
29.99
15
20
10
11.66
25
31.66
18.33
15
33.33
15
15
30
18.33
11.66
29.93
104.99
74.98
En conclusin, tanto en PHP y ASP tienen sus propias ventajas y desventajas como
se puede visualizar en la tabla N 7. Adems se elabor un cuadro de criterios de
seleccin del lenguaje de programacin realizado a tres expertos (Ver anexos 12, 13
y 14), siendo PHP el lenguaje de programacin con el mayor puntaje obtenido (Ver
tabla N 8) y el que mejor se ajusta a los requerimientos de la aplicacin web. PHP
ha sido elegido para el desarrollo de la aplicacin web para el proceso de atencin
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 abstraccin (fsico, lgico y externo), permite la manipulacin de los datos en la
base de datos, accede a la opcin 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 descripcin, manipulacin y
control:
Funcin de definicin.- Va a permitir al diseador de base de datos especificar
los elementos que la integran, su estructura y las relaciones que existen entre
ellos, las reglas de integridad semntica, etctera, as como las caractersticas
de tipo fsico y las vistas lgicas de los usuarios. Esta funcin la realiza el
Lenguaje de Definicin de Datos (DDL), que es propio de cada SGBD.
Funcin de manipulacin.- Despus de describir los datos, es necesario
cargarlos en las estructuras previamente creadas, para posteriormente poder
utilizarlos. Los usuarios podrn recuperar la informacin o actualizarla.
Funcin 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 estadsticas de utilizacin y funciones de
seguridad tales como:
de Comas.
33
- Copias de seguridad.
- Reiniciar el sistema.
- Proteccin frente a accesos no autorizados.
SQL Server
- Vienen en diferentes
tipos de paquetes.
- Se basa en la tecnologa
de
clsteres
de
Microsoft.
- Solo tiene un sistema de
almacenamiento
para
todo.
- Facilidad de instalacin,
distribucin
y
utilizacin.
- 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 tambin un
potente entorno grfico
de administracin, que
permite el uso de
comandos DDL y DML
grficamente.
- T-SQL (Transact-SQL)
es el principal medio de
programacin
y
administracin de SQL
Server.
Tabla N 9 Gestor de base de Datos

MySQL
Oracle
- Facilidad de instalacin.
- Viene en una sola - Conformidad con los
estndares en el nivel de
versin o paquete.
SQL
- Multiproceso, es decir entrada
puede usar varias CPU, correlacionado y permite
sub
consultas
si
stas
estn las
correlacionadas.
disponibles.
de
SQL
- Sistema de contraseas Virtuales
y
privilegios
muy estructuras de la lengua
como las vistas y los
flexibles y seguros.
sinnimos (Muy bueno).
- Bajo
costo
en
parmetros
requerimientos para la Muchos
un
control
elaboracin de base de permiten
preciso
de
la
secuencia.
datos, ya que debido a
su bajo consumo puede - Conversin automtica de
ser ejecutado en una pginas de cdigos (por
maquina con escasos ejemplo, entre cliente y
recursos sin ningn servidor).
- Capacidad
para
dar
problema.
servicio
a
una
gran
- Su
conectividad,
velocidad, y seguridad cantidad de conexiones en
hacen
de
MySQL paralelo a una base de
Server
altamente datos - el uso de
apropiado para acceder multitheaded servidor.
a bases de datos en - Idiomas para escribir
procedimientos
internet.
- Baja probabilidad de almacenados: PL/SQL y
corromper
datos, Java.
usuarios
est
incluso si los errores no - El
se producen en el identificado en la base de
de
sesin
y
propio gestor, sino en el inicio
contrasea,
tambin
hay
sistema en el que est.
posibilidad de utilizar el
sistema operativo de nivel
de autorizacin.

En la tabla N 9 se hace una comparacin entre los principales gestores de base de
datos.

de Comas.
34
Tabla N 10 Criterio de seleccin del gestor de Base de Datos

CRITERIOS
SQL Server
MySQL
Oracle
Rapidez del servidor
16.66
13.33
11.66
relacional de base de datos
Trabajo en entornos cliente
18.33
16.66
15
servidor
Accesibilidad
18.33
13.33
11.66
Control de accesos de
usuarios
Soporta en diferentes
sistemas operativos
Probabilidad de corromper
datos
Manejo sencillo
Total :
Total
41.65
49.99
43.32
16.66
11.66
13.33
41.65
13.33
11.66
10
34.99
11.66
11.66
13.33
36.65
15
15
10
40
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 ms alto (Ver tabla N 9), por tal motivo se eligi el sistema
gestor de base de datos SQL Server para la elaboracin de la base de datos.
2.2
Marco Conceptual.
Sistema de Comunicacin Mvil A-GPS.
Un Assisted GPS es una tecnologa popular que mejora el GPS convencional,
especialmente en el rea de redes de telefona mvil. En sistemas A-GPS, la
informacin til se proporciona por la red celular que puede ayudar al receptor del
GPS para calcular una posicin precisa ms rpidamente. A-GPS utiliza informacin
de ms de una fuente, mientras que el clculo de la posicin del dispositivo, as lo
define Zandbergen y Barbeau (2011, p. 383).
Proceso de atencin de llamadas de emergencias

Las llamadas de emergencia son una funcin crtica del sistema telefnico actual; ya
no son una caracterstica opcional. Con el fin de obtener ayuda en caso de
emergencia, la gente intuitivamente para llegar al telfono ms cercano y llamar a un
nmero de emergencia conocido, segn Heinz y Barnes (2010, p. 9).

de Comas.
35
III. MARCO METODOLGICO

3.1
Hiptesis
3.1.1 Hiptesis General:
El sistema de comunicacin Mvil A-GPS mejora el proceso de atencin
de llamadas de emergencias en la comisara de Santa Luzmila en el distrito
de Comas.
3.1.2 Hiptesis Especficas:
H-1 El sistema de comunicacin Mvil A-GPS reduce el tiempo de
respuesta de la Polica en la atencin de llamadas de emergencias en la
comisara de Santa Luzmila del distrito de Comas.
H-2 El sistema de comunicacin Mvil A-GPS reduce el porcentaje de
registros de alertas falsas en la comisara de Santa Luzmila en el distrito de
Comas.
3.2
Variables
3.2.1 Definicin Conceptual:
Se han determinado las siguientes variables:
Variable Independiente (VI):
Sistema de Comunicacin Mvil A-GPS.- Es una tecnologa
popular que mejora el GPS convencional, especialmente en el rea
de redes de telefona mvil. En sistemas A-GPS, la informacin til
se proporciona por la red celular que puede ayudar al receptor del
GPS calcular una posicin precisa ms rpidamente Zandbergen y
Barbeau (2011, p. 383).
Variable Dependiente (VD):
Proceso de atencin de llamadas de emergencias.- Para Heinz y
Barnes (2011, p. 9), una llamada de emergencia es con frecuencia la
accin que inicia una respuesta de emergencia, pero rara vez es la
nica forma de comunicacin que tiene lugar como parte de esa
respuesta. Adems 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 Definicin Operacional:
Los indicadores son factores determinantes para todo proceso, llmese
logstico y de produccin, para que se lleve a cabo con xito, se debe

de Comas.
36
implementar un sistema adecuado de indicadores para medir la gestin de

los mismos (Mora, 2008, p. 102).
Sistema de Comunicacin Mvil A-GPS.
Sistema de comunicacin mvil A-GPS que gestiona el proceso de
atencin de llamadas de emergencias en una institucin, permitiendo la
comunicacin directa entre el ciudadano y los efectivos policiales,
consulta de incidencias y reportes.
Para ello utiliza la tecnologa, el sistema gestor de base de datos, el
software adecuado, todo ello conforma el sistema elaborado siguiendo
una metodologa adecuada.
Proceso de atencin de llamadas de emergencias
El proceso de atencin de llamadas de emergencias est conformado
por procesos, a su vez es medible las dimensiones en estudio, y para
clculo de los indicadores es necesario realizar mediciones al tiempo de
respuesta de la polica ante las llamadas de emergencia, porcentaje de
registros de alertas falsas, lo cual es obtenido de las fichas de
observacin, entrevistas a los encargados de la institucin.

de Comas.
37
Operacionalizacin de Variables
En la siguiente tabla N 11 se explica las definiciones correspondientes:
Tabla N 11 Operacionalizacin de Variables
TIPO DE
VARIABLE
VARIABLE
Sistema de
Comunicacin
VARIABLE
INDEPENDIENTE Mvil A-GPS
VARIABLE
DEPENDIENTE
Proceso de
atencin de
llamadas de
emergencia.
DEFINICIN OPERACIONAL
Sistema de comunicacin mvil
A-GPS que gestiona el proceso
de atencin de llamadas de
emergencia en una institucin,
permitiendo la comunicacin
directa entre el ciudadano y los
efectivos policiales.
El proceso de atencin de
llamadas de emergencia est
conformado por procesos, a su
vez es medible las dimensiones
en estudio, y para clculo de los
indicadores es necesario realizar
mediciones al tiempo de
respuesta de la polica ante las
llamadas
de
emergencia,
porcentaje de registro de alertas
falsas, lo cual es obtenido de las
fichas
de
observacin,
entrevistas a los encargados de
la institucin.
DIMENSIN
Tiempo
Porcentaje de
alertas falas
DESCRIPCIN
El proceso de
atencin 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.
Cuando el efectivo
policial registra las
llamadas como
perturbadoras o
falsas.
INDICADOR
Tiempo de
respuesta de
la polica
Porcentaje
de registro
de alertas
falsas
DESCRIPCIN
INDICADOR
Determina el tiempo de
respuesta de la polica
ante una llamada de
emergencia que realizan
los ciudadanos.
Determina el porcentaje
de registros de alertas
falsas en el proceso de
atencin de llamadas de
emergencia.

de Comas.
38
3.2.3 Indicadores:
Tabla N 12 Indicadores
VARIABLE
INDICADOR
Tiempo de
respuesta de
la polica
Proceso de
atencin de
llamadas de
emergencia.
Porcentaje de
registro de
alertas falsas
DESCRIPCIN
TCNICA
Determina el tiempo
empleado en la
respuesta de la
polica ante una
Observacin
llamada de
emergencia.
Determina el
porcentaje de
registros de alertas
falsas.
Observacin
INSTRUMENTO UNIDAD DE
MEDIDA
FRMULA
Ficha de
observacin
(Cronmetro)
Minutos
Trp: Tiempo de respuesta de la polica

Hip: Hora de intervencin policial
Hrll: Hora de recepcin de llamada.
Ficha de
observacin
(Contador)
Porcentaje
Praf: Porcentaje de registro de alertas

falsas.
Nraf: Nmero de registros de alertas
falsas.
Ntra: Nmero total de registros de
alertas.

de Comas.
39

3.3
Metodologa.
3.3.1 Tipo de Estudio.
La presente investigacin es de tipo experimental, basada en la causa y el
efecto. Se trata de una intervencin por parte del investigador, que introduce
una variable y registra su efecto. Diseos experimentales de investigacin
permiten al investigador controlar o manipular una o ms variables en un
esfuerzo para examinar la relacin entre las variables. Variables tpicamente
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).
Segn Tamayo (2004) el objeto de estudio en la presente investigacin es de
tipo Aplicada, ya qu se implementa el sistema de comunicacin mvil con el
fin de medir su influencia en el proceso de atencin de llamadas de
emergencias en la comisara la Santa Luzmila y as comprobar las hiptesis
planteadas mediante los indicadores formulados y de este modo beneficia a
una sociedad, es as como lo describe (p. 43).
3.3.2 Diseo de Investigacin.
Son los que permiten un control muy escaso o nulo de las variables extraas,
por lo cual tienen muchas fuentes de invalidez interna, como el diseo de un
grupo con pre-prueba y pos prueba y el diseo esttico de dos grupos, de esta
manera lo define Hurtado y Toro (2007, p. 104).
1. Diseo 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. Diseo pre-experimental esttico, de dos grupos: "consta de dos grupos, y
solo uno es sometido al tratamiento experimental o variable independiente.
Para la presente investigacin se utiliz el diseo 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.
40
Tabla N 13 Diseo de Estudio Pre Experimental

Diseo
Especificaciones
O1
Pre test
X
Aplicacin de la variable experimental
Proceso de
atencin de
llamadas de
emergencias.
Aplicacin de
un sistema de
comunicacin
mvil A-GPS.
Dnde:
O1= Proceso de atencin de
Pos test
llamadas de emergencias
antes de la aplicacin.
Proceso de
atencin de X= Aplicacin del Sistema
llamadas de de Comunicacin Mvil
emergencias. A-GPS.
O2= Proceso de atencin de
despus de la aplicacin.
O2

3.3.3 Desarrollo de la Metodologa.
A continuacin se describe el caso de estudio y como se aplic la
metodologa propuesta en el desarrollo de una aplicacin mvil. Varios
sprints de la metodologa fueron desarrollados y todos los productos a lo
largo de esos sprints tanto en documentacin 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 Lpez Chvez
Desarrollador Lder (ScrumMaster)
Elvis Regalado Guerrero
Team (Equipo Desarrollador)
May. Gilmer Torres Carrera
Product Owner - Cliente (Comisario)
Mg. Mnica Daz Retegui
Asesor Metodolgico
Ing. Percy Rubn Bravo Balden Asesor Temtico
B) Informacin de Iniciacin del Proyecto:
Informacin de la empresa o cliente: Comisara Santa Luzmila del distrito de
Comas.
Nombre Comercial de la Aplicacin: Sis-CoMvil A-GPS.
Plataforma donde se ejecutar la aplicacin: Todas aquellas que contengan
navegador web que puedan ejecutar JQuery Mobile.
Modelos de dispositivos mviles: Todos aquellos que utilicen Sistema
Operativo Android versin superior a 2.2
Tipo de aplicacin: Aplicacin mvil y Web.
C) Historias de Usuario:
Las historias de usuario definidas por el cliente en colaboracin 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
de Comas.
41
equipo de desarrollo para definir los puntos de historias (Complejidad) en

cada historia fueron los valores comprendidos entre 0 y 21 de la sucesin de
Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21). A continuacin se encuentran descritas
las historias de usuario con su informacin de inters:
1. Registrar Usuario: Cualquier persona que cuente con un correo
electrnico, documento de identidad y un celular con tecnologa GPS
puede ser capaz de registrase en la base de datos del Sis-CoMvil.
2. Confirmacin de Registro: El usuario registrado para tener habilitado su
cuenta deber confirmar su activacin de cuenta va 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. Validacin de acceso: El usuario registrado podr descargar e instalar la
aplicacin mvil en su celular y acceder al Sis-CoMvil previo logueo
donde el login es el documento de identidad y la clave es la que registr.
5. Ubicacin del Lugar de la Incidencia: El usuario registrado podr
visualizar la ubicacin 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 mvil
las incidencias a la central de recepcin 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 mvil, a efectivos policiales que se
encuentran patrullando las calles y a un determinado usuario.
9. Atencin de Alertas: Los efectivos policiales podrn atender las alertas
desde el dispositivo mvil, as mismo el administrador usuario podr
atender las alertas desde la aplicacin web.
10. Recuperar Contrasea: El usuario debe poder recuperar su contrasea
cuando lo solicite.
11. El Administrador: El usuario de tipo administrador debe poder tener
control total del Sis-CoMvil 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 informacin descrita anteriormente, la tabla N 15 indica el
resto de la informacin referente a cada historia de usuario, como sus
condiciones de satisfaccin, Prioridad asignada por el cliente y Complejidad
reflejada en puntos de historia.
de Comas.
42
Tabla N 15 Informacin de la Pila del Producto (Product Backlog)

ID
1
2
3
4
5
6
9
10
11
12
Nombres de las
Historias
Condiciones de
Satisfaccin
Registrar Usuario - Determinar datos

principales.
Confirmacin de - Determinar activacin de
Registro
cuenta va correo electrnico
Registro de
- Poder registrar a los
Personal Policial efectivos policiales.
Validacin de - Determinar identificacin
acceso
de usuario registrado.
Ubicacin del - Determinar localizacin
lugar de
actual de la incidencia.
incidencia
- Ver ubicacin en el mapa.
Tipos de Alertas - Asignar un tipo de alerta
para reportar la incidencia.
- Poder enviar una alerta.
Envo de Alertas - Ver ubicacin en el mapa
donde se produjo la
incidencia.
- Poder enviar un mensaje os
efectivos policiales que
Enviar mensaje patrullan.
- Poder enviar un mensaje a
al celular
un usuario que se est
atendiendo la alerta enviada.
Atencin de alertas- Poder atender alertas.
Recuperar
- Poder recuperar la
Contrasea
contrasea del usuario.
Administrador - Poder tener control total de
los registros.
Reporte de
- Poder obtener reportes de
Alertas
tipo de incidencias basados
en fechas.
Prioridad Complejidad del Tiempo

del Cliente Equipo (Puntos (das)
de Historia)
Muy Alta
3
5
Alta
Media
Alta
6
6
Muy alta
13
Alta
Muy Alta
Alta
13
Muy Alta
10
Media
Alta
Alta
13

La asignacin de los tiempos a cada Sprint se puede ver al detalle en el
Cronograma de Desarrollo de la Aplicacin (Ver anexo N 21).
Hay que recordar que los valores de complejidad que asign el equipo de
desarrollo pertenecen a la sucesin de Fibonacci y fueron definidos utilizando
la tcnica Planning Poker descrita anteriormente. Mientras que las
condiciones de satisfaccin surgieron de charlas con el cliente para aclarar
con mayor precisin la funcin que comprenden las historias de usuario.
D) Release Plan:
Con las historias de usuario definidas, el cliente particip en la elaboracin
del release plan con el propsito 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.
de Comas.
43
Tabla N 16 Release Plan (Sprint Backlog)

Sprints
Historias de Usuario
Complejidad de
las Historias
Primera Versin
1-Registro de Usuarios
1
2-Confirmacin de Registro
3
5
3
4-Validacin de acceso
Complejidad
del Sprint
8
16
5-Ubicacin del lugar de la

incidencia
6-Tipos de Alertas
13
7-Envo de alerta
16
9-Atencin de alertas
13
13
Segunda Versin
12-Reporte de Alertas
5
6
7
8- Enviar mensaje al celular
13
3-Registro de Personal Policial
10-Recuperar contrasea
11-Administrador
16
6

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
Confirmacin de Registro, respectivamente), mientras que en el segundo se
desarroll la historia N 4 y 5 (Validacin de acceso y Ubicacin 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 Envo de alertas
respectivamente) y el cuarto sprint se desarroll la historia 9 (Atencin de
Alertas).
La idea que se mantena para la primera versin de la app. (Ver release plan,
tabla N 11) era la de contar con una aplicacin 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 adems, proveer ciertas
evidencias al momento que se suscita una emergencia, el equipo de desarrollo
y el cliente acordaron la modificacin de la historia de usuario 7 (Envi de
alertas) al finalizar la primera versin. En la segunda versin la historia de
usuario 12 (Reporte de alertas) corresponde al quinto Sprint, con la finalidad
de poder medir los indicadores de la investigacin.
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 contrasea y Administrador, respectivamente) del sprint N 7.
Como se hizo mencin anteriormente las solicitudes de cambio aprobadas que
surgieron al finalizar el cuarto sprint tambin fueron tomadas en cuenta.
de Comas.
44
Haciendo uso de las reuniones de planificacin, las historias seleccionadas

fueron pasadas a la fase de Historias de Usuario del Sprint donde el
documento de descripcin de historia fue realizado y se definira la
descomposicin de tareas. La figura N 13 muestra el estado del pizarrn al
iniciar el sprint con todas las tareas ya descompuestas.
Elaboracin Propia.
Figura N 13
Estado inicial de la pizarra Primer Sprint

En ese entonces, la figura N 13 refleja las historias de usuario 7 (Envo 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, mantenindose 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 continuacin se detalla las historias de los usuarios con las tareas que
fueron asignadas a cada Sprint.

de Comas.
45
Elaboracin Propia.
Figura N 14
Descripcin detallada de la Historia: Registro de Usuarios.

Como se puede observar en la figura N 14, la mayora de la documentacin
se manej de forma manuscrita, con la finalidad de que se pudieran tener a la
mano rpidamente los documentos necesarios para el desarrollo de las tareas.
Siguiendo con la descripcin detallada de la historia de usuario Registro de
Usuarios, en la seccin de Descripcin de Condiciones de Satisfaccin se
encuentran definidas dos condiciones de satisfaccin para especificar en lo
posible la historia de usuario y as, minimizar ambigedades.
Registrar datos Personales.- Que las personas puedan ingresar sus datos
personales de forma obligatoria.
Determinar trminos y condiciones de uso de la aplicacin.- Que las
personas pueda conocer las clausulas establecidas para el uso de la
aplicacin.
Por otro lado, la figura anterior tambin muestra las dos tareas referentes a la
historia de usuario Registro de Usuarios que fueron desarrolladas:
1.1. Validacin de Datos.- Desarrollar la seccin que los usuarios ingresen
todos los datos correctamente.
1.2. Trminos y condiciones de uso de la aplicacin.- Para poder ser
registrado es necesario aceptar los trminos y condiciones del uso de la
aplicacin.

de Comas.
46
Los stickers referentes a estas tareas se pueden observar en el pizarrn 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 deban pasar por la
fase de Diseo Mvil, en la cual participaba el cliente a travs de reuniones
diarias ayudando a definir los Story Boards. De igual forma, en la fase de
diseo mvil para la historia de usuario nmero 1 Registro de Usuarios, se
gener un caso de uso de cada tarea con el fin de complementar la
informacin referente a los Story Boards antes mencionada. Las herramientas
utilizadas en la fase de diseo mvil fueron Microsoft Visio 2010. A
continuacin se presenta la informacin de diseo referente a cada tarea de la
historia de usuario Registro de Usuarios.
Elaboracin Propia.
Figura N 15
Diseo de tarea 1.1 Validacin de Datos

El diseo de la tarea se 1.1 Validacin 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.

de Comas.
47
Elaboracin Propia.
Figura N 16
Caso de Uso - Validacin de Datos

En la figura N 16 se visualiza el caso de uso para la tarea 1.1 Validacin de
datos.
Todos los documentos de prueba fueron generados por el desarrollador Elvis
Regalado, que tambin mantuvieron un formato manuscrito para poder
brindar la informacin a los programadores y que los mismos puedan
manejarla libremente. A continuacin se muestra el documento de prueba que
gener la tarea 1.1 de la historia de usuario nmero 1.
Elaboracin Propia.
Figura N 17
Pruebas de Unidad Tarea 1.1

de Comas.
48
Cada prueba de unidad dentro del sprint, contena 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 algn error era detectado, se deba notificar la gravedad del mismo
en la seccin de Gravedad del Error, de lo contrario no aplica.
Una vez que una tarea supera la fase de planificacin de pruebas, esta pas
directamente a la fase de interfaces de usuario, de la cual solo se necesitaba la
autorizacin 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 cdigos de base de datos.
Elaboracin Propia.
Figura N 18
Interfaz concluida de la tarea 1.1 Validacin de datos.

En la figura N 18 se puede visualizar la interface concluida de la tarea 1.1
(Validacin de datos), quedando lista para integrar pero deba esperar la tarea
1.2 (Trminos y condiciones de uso de la aplicacin).
El diseo de la tarea se 1.2 Trminos y condiciones del uso de la aplicacin
se visualiza en el Story Board de la figura N 19, es pre requisito para el
registro del usuario.

de Comas.
49
Elaboracin Propia.
Figura N 19
Diseo de tarea 1.2 Trminos y condiciones del uso de la aplicacin.

En la figura N 20 se visualiza el caso de uso para la tarea 1.2 Trminos y
condiciones del uso de la aplicacin.
Elaboracin Propia.
Figura N 20
Caso de uso - Trminos y condiciones del uso de la aplicacin.

de Comas.
50
En la figura N 21 se muestra el documento de prueba que gener la tarea 1.2

de la historia de usuario nmero 1.
Elaboracin Propia.
Figura N 21

La figura N 22 muestra un estado del pizarrn donde la tarea 2.1 se
encuentra en estado de planificacin (Historia de Usuario 2).
Elaboracin Propia.
Figura N 22
Pizarrn - Fases de Diseo y Pruebas

En la figura N 23 se puede visualizar la interfaz concluida de la tarea 1.2
(Trminos y condiciones de uso).

de Comas.
51
Elaboracin Propia.
Figura N 23
Interfaz concluida de la tarea 1.2 - Trminos y condiciones del uso de la

aplicacin.
Una vez que las tareas 1.1 y 1.2 fueron desarrolladas se procede a la
integracin de las mismas y se garantiza a travs de los resultados de las
pruebas de unidad, que no se generen errores en la integracin, concluyendo
la historia de usuario 1 e iniciando la historia 2.
Elaboracin Propia.
Figura N 24
Descripcin detallada de la Historia: Confirmacin de Registro.

En la figura N 24, se detalla la descripcin de condiciones de satisfaccin:

de Comas.
52
Conformidad de Registro.-Que el usuario pueda obtener el link de

activacin de la cuenta.
Por otro lado, la figura anterior tambin muestra la tarea Activacin de cuenta
de Usuario referente a la historia de usuario Confirmacin de Registro que
fueron desarrolladas:
2.1 Activacin de cuenta de Usuario.-Desarrollar la seccin en la cual se
pueda enviar al correo del usuario la direccin web para la activacin de
la cuenta.
A continuacin en la siguiente figura se visualiza el Story board del diseo
referente a la tarea Activacin de cuenta de usuario de la historia de usuario
Confirmacin de Registro.
Elaboracin Propia.
Figura N 25
Diseo de tarea 2.1 Activacin de Cuenta de Usuario.
Elaboracin Propia.
Figura N 26
Caso de uso - Activacin de Cuenta de Usuario

de Comas.
53
En la figura N 26 se visualiza el caso de uso Activacin 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 Lgico de las Historias de Usuarios 1 y 2 (Registro de Usuarios y
Confirmacin de Registro respectivamente) correspondientes al Primer
Sprint, del mismo modo en la figura N 28 se puede visualizar las entidades
del modelo Fsico.
Elaboracin Propia.
Figura N 27
Entidades utilizadas en el Primer Sprint Modelo Lgico.
Elaboracin Propia.
Figura N 28
Entidades utilizadas en el Primer Sprint Modelo Fsico.

de Comas.
54
Elaboracin Propia.
Figura N 29

Elaboracin Propia.
Figura N 30
Interfaz concluida de la tarea 2.1 Activacin de Cuenta de Usuario.

En la figura N 30 se puede visualizar el link de activacin que el usuario
recibe en su correo electrnico y posteriormente al ingresar al link muestra la
ventana de confirmacin de registro del usuario, esto indica que la tarea 2.1
de Comas.
55
(Activacin de cuenta de usuario) ha sido concluida. De esta forma culmina el

primer Sprint, dando inicio al siguiente Sprint.
Elaboracin Propia.
Figura N 31
Descripcin detallada de la Historia: Validacin de acceso.

En la figura N 31, se detalla la descripcin de condicin de satisfaccin:
Validar datos.-Que los datos ingresados por el usuario sean validados con
la base de datos.
Por otro lado, la figura anterior tambin muestra las tareas Inicio de sesin va
mvil e Inicio de sesin va web referente a la historia de usuario Validacin
de acceso que fueron desarrolladas:
4.1. Inicio de sesin va mvil.-Desarrollar la seccin que permita a los
usuarios registrados puedan tener acceso a la aplicacin mvil.
4.2. Inicio de sesin va web.-Desarrollar la seccin que permita ingresar por
la pgina web a los usuarios registrados para actualizar sus datos y descargar
la aplicacin mvil.
A continuacin en la siguiente figura se presenta la informacin del diseo
referente a las tareas de la historia de usuario Validacin de acceso.

de Comas.
56
Elaboracin Propia.
Figura N 32
Diseo de tarea 4.1 Inicio de sesin va mvil
Elaboracin Propia.
Figura N 33
Diseo de tarea 4.2 Inicio de sesin va web.

de Comas.
57
En las figuras N 32 y 33 se visualiza los Story Board para las tareas Inicio de
sesin va mvil y va web respectivamente, ya que el usuario puede acceder
a la aplicacin mvil y a la pgina web. Adems en la figura N 34 describe
el caso de uso para la historia validacin de acceso.
Elaboracin Propia.
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 nmero 4.
Elaboracin Propia.
Figura N 35
Prueba de Unidad Tarea 4.1

de Comas.
58
Elaboracin Propia.
Figura N 36

En la figura N 37 y 38 se puede visualizar las tareas 4.1 y 4.2 (Inicio de
sesin va Mvil e inicio de sesin va web) concluidas.
Elaboracin Propia.
Figura N 37
Interfaz concluida de la tarea 4.1 Inicio de sesin va Mvil

de Comas.
59
Elaboracin Propia.
Figura N 38
Interfaz concluida de la tarea 4.2 Inicio de sesin va web

En la figura N 38 se puede visualizar la tarea 4.2 concluida, el cual muestra
la interfaz de acceso a la aplicacin web, para un usuario. De esta manera
concluye la historia de usuario 4 dando inicio a la siguiente historia de
usuario del segundo Sprint.
Elaboracin Propia.
Figura N 39
Descripcin detallada de la Historia: Ubicacin del lugar de incidencia.

de Comas.
60

Determinar localizacin actual.- Que los usuarios registrados puedan
conocer su posicin actual (GPS-Geo localizacin).
Adems, la figura anterior tambin muestra la tarea Ver ubicacin actual
referente a la historia de usuario Ubicacin del lugar de incidencia que fue
desarrollada:
5.1. Ver ubicacin actual.-Una vez ingresado a la aplicacin mvil el
usuario puede visualizar en el mapa la ubicacin actual donde se encuentra
observando la incidencia.
A continuacin en la siguiente figura, se presenta la informacin del diseo
referente a la tarea de la historia de usuario Ubicacin del lugar de incidencia.
Elaboracin Propia.
Figura N 40
Diseo de tarea 5.1 Ver ubicacin actual

de Comas.
61
En la figura N 41 se visualiza el caso de uso de la tarea ver ubicacin actual.
Elaboracin Propia.
Figura N 41
Caso de uso - Ver ubicacin actual.

Modelo Lgico de las Historias de Usuarios 4 y 5 (Validacin de acceso y
Ubicacin del lugar de la incidencia) correspondientes al Segundo Sprint, del
mismo modo en la figura N 43 se puede visualizar las entidades del modelo
Fsico.
Elaboracin Propia.
Figura N 42
Entidades utilizadas en el Segundo Sprint Modelo Lgico.

de Comas.
62
Elaboracin Propia.
Figura N 43
Entidades utilizadas en el Segundo Sprint Modelo Fsico.

Elaboracin Propia.
Figura N 44

de Comas.
63
Elaboracin Propia.
Figura N 45
Interfaz concluida de la tarea 5.1 Ver ubicacin actual.

En la figura N 45, se puede visualizar la tarea 5.1 concluida, en la cual el
usuario puede ver su ubicacin actual. De esta forma culmina el segundo
Sprint, mediante la integracin de las tareas de las historias de usuario 4 y 5,
en la figura N 46 se puede apreciar estado final del segundo Sprint.
Elaboracin Propia.
Figura N 46
Estado final del segundo Sprint (Integracin de Tareas).

de Comas.
64
Elaboracin Propia.
Figura N 47
Descripcin 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.
Adems, la figura anterior tambin 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 informacin del diseo referente a la tarea
de la historia de usuario Tipos de alertas.

de Comas.
65
Elaboracin Propia.
Figura N 48
Diseo de tarea 6.1 Ver tipos de alertas
Elaboracin Propia.
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 nmero 6.

de Comas.
66
Elaboracin Propia.
Figura N 50
Elaboracin Propia.
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.
de Comas.
67
Elaboracin Propia.
Figura N 52
Descripcin detallada de la Historia: Envo de alertas.

Determinar ubicacin.- Que los usuarios registrador puedan visualizar en
una mapa su ubicacin 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
descripcin.
Adems, la figura anterior tambin muestra la tarea Enviar alerta referente a
la historia de usuario Envo 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 Envo de aletas.

de Comas.
68
Elaboracin Propia.
Figura N 53
Diseo de la tarea 7.1 Enviar Alerta.
Elaboracin Propia.
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 Lgico 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 Fsico.

de Comas.
69
Elaboracin Propia.
Figura N 55
Entidades utilizadas en el Tercer Sprint Modelo Lgico.
Elaboracin Propia.
Figura N 56
Entidades utilizadas en el Tercer Sprint Modelo Fsico.

Elaboracin Propia.
Figura N 57

de Comas.
70
Elaboracin Propia.
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 integracin de las tareas de las historias de usuario
6 y 7. A continuacin se da inicio al cuarto Sprint.
Elaboracin Propia.
Figura N 59
Descripcin detallada de la Historia: Atencin de Alertas.

de Comas.
71

Registro de alertas ordenadas por fecha y hora.- De esta forma el
efectivo policial sabe que alerta es la ms reciente.
Ver ubicacin y detalles de la alerta.- Cualquier efectivo policial
registrado puede visualizar los detalles de cada alerta (DNI, celular, tipo de
alerta, IMEI estado, ubicacin en un mapa).
Adems, la figura anterior tambin muestra las tareas Listar alertas
registradas y Actualizar estado de alertas referentes a la historia de usuario
Atencin de alertas que fue desarrollada:
9.1. Listar alertas registradas.- Listar las alertas actualizadas y ordenadas a
la ms 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 Atencin de alertas.
Elaboracin Propia.
Figura N 60
Diseo de la tarea 9.1 - Listar alertas registradas.

de Comas.
72
En la figura N 61 se puede visualizar el caso de uso de la tarea Listar Alertas

Registradas.
Elaboracin Propia.
Figura N 61
Caso de uso - Listar Alertas Registradas.

Elaboracin Propia.
Figura N 62

de Comas.
73
Elaboracin Propia.
Figura N 63
Interfaz concluida de la tarea 9.1 Listar alertas registradas.

efectivo policial puede visualizar las ultimas alertas registradas.
A continuacin se visualiza el Story board del diseo referente a la tarea
Actualizar estado de alertas de la historia de usuario Atencin de alertas. En
esta tarea, se disea para ambas plataformas mvil y web.

de Comas.
74
Elaboracin Propia.
Figura N 64
Diseo de la tarea 9.2 Actualizar estado de alertas (Plataforma

mvil-web)
Elaboracin Propia.
Figura N 65
Caso de uso - Actualizar estado de alertas (Plataforma mvil).

de Comas.
75
En la figura anterior nos indica el caso de uso Actualizar estado de alerta en la

plataforma mvil, en este proceso solo puede realizado por el usuario de tipo
efectivo policial.
Elaboracin Propia.
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 Lgico de la Historias de Usuarios 9 (Atencin de Alertas)
correspondientes al cuarto Sprint, del mismo modo en la figura N 68 se
puede visualizar las entidades del modelo Fsico.
Elaboracin Propia.
Figura N 67
Entidades utilizadas en el Cuarto Sprint Modelo Lgico.

de Comas.
76
Elaboracin Propia.
Figura N 68
Entidades utilizadas en el Cuarto Sprint Modelo Fsico.

Elaboracin Propia.
Figura N 69

de Comas.
77
Elaboracin Propia.
Figura N 70
Interfaz concluida de la tarea 9.2 Actualizar estado de alerta

(Plataforma mvil).
efectivo policial puede atender una alerta desde su mvil, 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.

de Comas.
78
Elaboracin Propia.
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 Envo de alertas del tercer Sprint, se hicieron unas
mejoras la cual no requiri de ninguna integracin ya que se trataba de una
mejora proveniente de un cambio generado al culminar el tercer Sprint. Dicho
cambio se gener a travs de la solicitud de cambio mostrada en la figura N
72, de igual forma la descripcin detallada del cambio se encuentra reflejada
en dicha imagen.

de Comas.
79
Elaboracin Propia.
Figura N 72
Solicitud de cambio y descripcin 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 Lgico y Fsico (Ver figuras N 73 y
74) del cuarto Sprint.
Elaboracin Propia.
Figura N 73
Cambios realizados en el Modelo Lgico del cuarto Sprint.

de Comas.
80
Elaboracin Propia.
Figura N 74
Cambios realizados en el Modelo Fsico del cuarto Sprint.
Elaboracin Propia.
Figura N 75
Interfaz concluida de la Solicitud de Cambio

El sprint tena pautado durar 11 das de desarrollo, la evolucin de la grfica
Burn Down Chart antes de comenzar el quinto Sprint (Segunda Versin) luca
como lo refleja en la grfica N 4.

de Comas.
81
Elaboracin Propia.
Grfica N 4
Burn Down Chart Inicio Quinto Sprint

Se debe aclarar en la grfica N 4, que la subida presenciada al final del
desarrollo del cuarto sprint (color rojo) se da debido a la agregacin 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 integracin de las tareas
de la historia de usuario 9, en la figura N 76 se puede apreciar la integracin
del cuarto Sprint y la finalizacin de la primera versin de la pila del producto
(Backlog).
Elaboracin Propia.
Figura N 76
Pizarrn, Estado final del cuarto Sprint.

de Comas.
82
Elaboracin Propia.
Figura N 77
Descripcin detallada de la Historia: Reporte de Alertas

Consultar y mostrar las incidencias detalladas.- Que los registros de
incidencias se puedan visualizar e imprimir.
Adems, la figura anterior tambin 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 informacin del diseo referente a las tareas
de la historia de usuario Reporte de alertas.

de Comas.
83
Elaboracin Propia.
Figura N 78
Diseo de la tarea 12.1 Reporte de alertas (Plataforma web).
Elaboracin Propia.
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 modificacin se
gener a travs de una solicitud de cambio mostrada en la figura N 80, de
igual modo la descripcin detallada del cambio se encuentra reflejada en
dicha figura.

de Comas.
84
Elaboracin Propia.
Figura N 80
Solicitud de cambio y descripcin 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 funcin
que permite al efectivo policial obtener los reportes de manera rpida y
detallada. Como se observ anteriormente dicho cambio fue desarrollado de
inmediato a travs 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 lgico y fsico 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 ningn cambio en los
modelos, solo fue necesario de la codificacin en PHP.
12.1 de la historia de usuario nmero 12, despus de la modificacin que se
realiz por solicitud del cliente.

de Comas.
85
Elaboracin Propia.
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 finalizacin del quinto Sprint.
Elaboracin Propia.
Figura N 82
Interfaz concluida de la tarea 12.1 Reporte de alerta (Plataforma web).

de Comas.
86
Elaboracin Propia.
Figura N 83
Descripcin detallada de la Historia: Enviar mensaje al celular.

Enviar mensaje al celular del efectivo Policial.- Que los policas 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 atencin de alerta.
Adems, la figura anterior tambin muestra las tareas definidas en la reunin
que fueron desarrolladas:
8.1. Reporta alerta a Policas.- Desarrollar la funcin de envo de mensajes
a la Polica.
8.2. Enviar mensaje de atencin al usuario.- Desarrollar la funcin de
envo de mensajes al usuario que reporto una alerta.
En las figuras N 84 y 85 se presentan la informacin del diseo referente a
las tareas de la historia de usuario Enviar mensaje al celular.

de Comas.
87
Elaboracin Propia.
Figura N 84
Diseo de la tarea 8.1 Reportar alerta a Policas (Plataforma web).
Elaboracin Propia.
Figura N 85
Diseo de la tarea 8.2 Enviar mensaje de atencin al usuario

(Plataforma web).

de Comas.
88
Elaboracin Propia.
En la figura N 86 se puede visualizar el caso de uso de las tareas 8.1 y 8.2

Reportar alerta a Policas y Enviar mensaje de atencin al usuario
respectivamente.
Figura N 86
Caso de Uso - Reportar alerta a Policas 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 nmero 8.
Elaboracin Propia.
Figura N 87
Prueba de Unidad: Tareas 8.1 y 8.2.

de Comas.
89
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 estn patrullando en las calles.
Elaboracin Propia.
Figura N 88
Interfaz concluida de la tarea 8.1 Reportar alerta a Policas (Plataforma web).
Elaboracin Propia.
Figura N 89
Interfaz concluida de la tarea 8.2 Enviar mensaje de atencin al usuario

(Plataforma web).
Con las tareas desarrolladas se concluye la historia de usuario 8, dando inicio
a la siguiente historia de usuario.

de Comas.
90
Elaboracin Propia.
Figura N 90
Descripcin 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 seccin que permita registrar
a un efectivo Policial.
de la historia de usuario Registrar Efectivo Policial.
Elaboracin Propia.
Figura N 91
Diseo de la tarea 3.1 Registrar efectivo Policial.

de Comas.
91
En la figura N 92 se puede visualizar el caso de uso de las tareas 3.1

Registrar efectivo Policial.
Elaboracin Propia.
Figura N 92
Caso de Uso Registrar efectivo Policial.

Los modelos lgico y fsico se pueden visualizar en los anexos N 22 y 23.
Elaboracin Propia.
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 Polica. De esta manera
concluye la historia de usuario 3 y el Sexto Sprint, dando inicio al sptimo
Sprint.

de Comas.
92
Elaboracin Propia.
Figura N 94
Interfaz concluida de la tarea 3.1 Registrar efectivo Policial (Plataforma web).
F Elaboracin Propia.
Figura N 95
Descripcin detallada de la Historia: Enviar mensaje al celular.

Recuperar Password.- Permitir a los usuarios recuperar su password.
10.1. Recuperar Contrasea.- Desarrollar la opcin que el usuario ingrese
su DNI y correo electrnico para enviar una nueva clave.
de la historia de usuario Recuperar Contrasea.
de Comas.
93
Elaboracin Propia.
Figura N 96
Diseo de la tarea 10.1 Recuperar Contrasea.

En la figura N 97 se puede visualizar el caso de uso de la tarea 10.1
Recuperar Contrasea.
Elaboracin Propia.
Figura N 97
Caso de Uso Recuperar Contrasea.

Finalmente los modelos lgico y fsico se concluyeron (Ver anexos N 22 y
23) ya que no fue necesario de ninguna modificacin ms, as mismo se
elabor el Diagrama de Base de Datos en SQL Server 2008 (Ver anexo N
24).

de Comas.
94
Elaboracin Propia.
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 contrasea. De esta manera concluye
la historia de usuario 10.
Elaboracin Propia.
Figura N 99
Interfaz concluida de la tarea 10.1 Recuperar contrasea(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
finalizacin de la segunda versin y de la pila del producto (Product
Backlog), quedando el cliente conforme.

de Comas.
95
Elaboracin Propia.
Figura N 100
Pizarrn, fase final de la pila del Producto (Backlog).
Elaboracin Propia.
Grfica N 5
Burn Down Chart al finalizar el ultimo Sprint

En la grfica N 5 (Burn Down Chart) se detalla la evolucin del avance del
desarrollo de los sprints. El desarrollo del primer sprint sirvi como base para
marcar pautas y cubrir puntos flojos de la metodologa que se encontraban
ambiguos o no haban 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 metodologa 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 grfica
anterior se muestra como Trabajo Nuevo (color rojo oscuro).

de Comas.
96

3.4
Poblacin, muestra y muestreo.

3.4.1 Poblacin:
Para Martnez (2005), la poblacin es el conjunto de unidades o elementos
que representan una caracterstica comn, tambin se le considera como
conjunto de medidas. Esto debe entenderse como un grupo de personas,
familias, establecimientos, manzanas, barrios, objetos, etctera, pero en
realidad es un conjunto de medidas obtenidas de las caractersticas estudiadas
(p. 828).
Por consiguiente en la presente investigacin se considera como poblacin a
63 registros de llamadas que la operadora registra en un cuaderno de la
comisara Santa Luzmila del distrito de Comas (Ver anexo N 3), en la Tabla
N 17 se resume la poblacin obtenida.
Tabla N 17 Determinacin de la Poblacin
Indicador
Cantidad de
Poblacin
Tipo de Poblacin
Registros de alertas
Tiempo de respuesta de la polica

63
Porcentaje de alertas falsas

3.4.2 Muestra:
Para Martnez (2005, p. 834), la muestra lo define como un conjuntos de

medidas pertenecientes a una parte de la poblacin.
Adems indica que las unidades deben ser aleatorias, lo que equivale a decir
probabilstica, con el fin de obtener una muestra representativa de la
poblacin, respecto de todas o algunas de sus caractersticas, para los cuales
el valor del parmetro es desconocido, en caso contrario se habla de una
muestra no aleatoria.
Para el clculo de la muestra, en la presente investigacin se considera la
frmula de poblacin finita, debido a que est constituida por un determinado
o limitado nmero de elementos o unidades.
Se consider la siguiente frmula:
(
......Formula (3.1)
Dnde:
N = Total de la poblacin (63 Registros de llamadas)
Z2 = 1.962 (si la seguridad es del 95%)

de Comas.
97
p = Proporcin o frecuencia con que la caracterstica 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= Precisin (en este caso se desea un 3%)
Para el indicador Tiempo de respuesta de la polica se toma los siguientes
datos:
Remplazando los valores en la frmula para hallar la muestra de los
indicadores Tiempo de respuesta de la polica.
(
(
3.4.3
)
)
Muestreo:
Se cuenta con una poblacin de 63 registros de llamadas, se aplicar un
muestreo de tipo intencionado o de conveniencia, ya que segn Carrasco
(2006 p. 243), se encuentra dentro de los muestreos de tipo no probabilsticos,
la cual se caracteriza porque es el investigador es quien selecciona, segn su
criterio y conocimiento de caractersticas de la poblacin que estudia a los
individuos que conforman la muestra considerndolos los ms
representativos. En la presente investigacin se consider 48 Registros de
llamadas realizadas del 1 al 11 de Octubre del ao 2012, en la comisaria
Santa Luzmila del distrito de Comas (Ver anexo N 4).
3.5
Mtodo de Investigacin:
Para Tafur (1995, p. 18), la investigacin es el acto de indagar o averiguar, segn
su uso natural y genrico, es la bsqueda de algo desconocido y, de ese modo, se
entiende el recurso a la originalidad como un criterio de investigacin.
Para saber si el sistema de comunicacin mvil A-GPS es favorable para el proceso
de atencin de llamadas de emergencias, el mtodo de investigacin que se utiliz
es el mtodo cuantitativo deductivo, ya que segn Bernal (2009), el mtodo
cuantitativo o mtodo tradicional se fundamenta en la medicin de las
caractersticas de los fenmenos 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 mtodo tiende a
generalizar y normalizar resultados (p. 57).
3.6
Tcnicas e instrumentos de recoleccin de datos.

Segn Ortega (2009, p. 18) la recoleccin de datos se refiere a los mtodos usados
para obtener informacin pertinente de las unidades elementales introducidas en
una muestra o en una poblacin. Existen diferentes vas de obtener informacin, las
que se utiliz en la presente investigacin son:

de Comas.
98
3.6.1 Tcnicas.
Las principales tcnicas que se utilizaron en el desarrollo de la presente tesis
son:
- Observacin: Es una tcnica de recopilacin de datos semi primaria por la
cual el investigador acta sobre los hechos a veces con la ayuda de algn
instrumento, de esta manera lo define Valderrama y Len (2009, p. 214).
Se hizo uso de esta tcnica, para comprobar el tiempo de respuesta de la
polica, para esto se utiliz instrumentos como cuaderno de registro de
llamadas y cronometro.
- Entrevista: Es una forma de interaccin social, donde el investigador se
sita frente al investigado y le formula preguntas, as lo define Valderrama
y Len (2009, p. 82), adems seala que la entrevista como instrumento de
investigacin social tiene una gran importancia ya que permite obtener
determinadas conclusiones sobre lo que se est investigando. Para la
presente investigacin se aplic esta tcnica para obtener informacin
necesaria de la problemtica de la institucin, la cual permiti encontrar
los puntos dbiles en cuanto a la atencin de llamadas de emergencias que
se registran en la comisara Santa Luzmila del distrito de Comas (Ver
anexo N 2).
- Tcnicas de Lectura: Para Carrasco (2005), define como el conjunto de
habilidades y destrezas fsicas y mentales para captar, comprender e
interpretar el contenido de documentos escritos (p. 279). Se hizo uso de
esta tcnica para la comprensin de los registros de llamadas de
emergencias, (Ver anexo N 6) ya que se evalu detalladamente la
informacin registrada por la operadora de llamadas.
3.6.2 Instrumentos.
- Ficha de observacin: 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 atencin
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 polica en minutos (Medicin PreTest). Luego para la medicin Post-Test, se midi el tiempo desde que un
usuario realiza un registro de alerta desde su mvil hasta la actualizacin
de la atencin de la alerta del efectivo policial ya sea por el dispositivo
mvil o desde la aplicacin web.
- Cronmetro: Es un reloj o una funcin del reloj que se utiliza para medir
fracciones de tiempo, por lo general muy cortas y de manera muy precisa.

de Comas.
99
3.6.3 Fuentes.
- Proceso de atencin de llamadas de emergencias en la comisaria de Santa
- Proceso de atencin de llamadas de emergencias en la comisaria de Santa
Luzmila en el distrito de Comas
Tabla N 18 Tcnicas e Instrumentos de recoleccin de datos
INDICADOR
TCNICA
Tiempo de
Respuesta de
la Polica
Porcentaje de
alertas falsas
-Observacin
-Lectura
INSTRUMENTO
-Cronometro
-Cuaderno de
Registro de llamadas.
-Partes Policiales
-Contador
-Cuaderno de
Registro de llamadas
-Observacin
-Lectura
FUENTE
63
Registros
de llamadas
INFORMANTE
-Operadora,
recepcionista de
las llamadas.
-Comisario

En la tabla N 18 se detalla las tcnicas e instrumentos empleadas para la
recoleccin de datos.
3.7
Mtodos y tcnicas de procesamiento de anlisis de datos:

El mtodo de anlisis de datos de esta investigacin es cuantitativo, ya que es Pre
experimental y se obtienen estadsticas que ayuden a comprobar si la hiptesis es
correcta. Segn Valderrama y Len (2009, p. 22), se puede formular solamente
cuando los datos del estudio que se van a recolectar y analizar para probar o
disprobar las hiptesis son cuantitativos (nmeros, porcentajes, promedio, ndices,
etctera)
En la presente investigacin se tom una muestra mayor a 30, por ello se aplic el
mtodo de la prueba Z de diferencias de medidas, en la siguiente tabla N 19, se
visualiza la frmula general:
N
1
2
3
4
Ia
I1a
I2a
I3a
I4a
Tabla N 19 Prueba Z
Ip
I1p
I2p
I3p
I4p

de Comas.
.Frmula (3.2)
100
Se utilizara el procesador Sistemtico Computarizado (SPSS), versin 20.0 siendo un

programa especial para estadstica y recopilacin de datos.
Indicador: Tiempo de respuesta de la polica
a) Definicin de variables:
Ia = Indicador medido antes de la aplicacin de un sistema de comunicacin mvil
A-GPS (Sistema actual).
Ip = Indicador medido despus de la aplicacin de un sistema del comunicacin
mvil A-GPS (Sistema Propuesto).
b) Hiptesis Especfica 1:
Hiptesis HE1: El sistema de Comunicacin Mvil A-GPS reduce el tiempo de
respuesta de la polica frente a las llamadas de emergencias en la comisara de
Santa Luzmila del distrito de Comas.
Variables:
Ia1: Tiempo de respuesta de la polica medido antes de la aplicacin de un sistema
de comunicacin mvil A-GPS.
Ip1: Tiempo de respuesta de la polica medido despus de la aplicacin de un
sistema de comunicacin mvil A-GPS.
Hiptesis Nula (H0): Un sistema de comunicacin mvil A-GPS no disminuye el
tiempo de respuesta de la polica para el proceso de atencin de llamadas de
emergencias en la comisaria de Santa Luzmila en el distrito de Comas.
Hiptesis Alternativa (Ha): Un sistema de comunicacin mvil A-GPS

disminuye el tiempo de respuesta de la polica para el proceso de atencin de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito de
Comas.
c) Hiptesis Especfica 2:
Hiptesis HE2: El sistema de Comunicacin Mvil 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 aplicacin de un
sistema de comunicacin mvil A-GPS.
Ip2: Porcentaje de registros de alertas falsas medido despus de la aplicacin de
un sistema de comunicacin mvil A-GPS.

de Comas.
101
Hiptesis Nula (H0): Un sistema de comunicacin mvil A-GPS no disminuye el

porcentaje de registros de alertas falsas para el proceso de atencin de llamadas de
Hiptesis Alternativa (Ha): Un sistema de comunicacin mvil A-GPS

disminuye el porcentaje de registros de alertas para el proceso de atencin de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito de
Comas.
Segn aupas (2009), la Hiptesis Nula son las que niega a la hiptesis de la
investigacin (Hiptesis de Trabajo), se simboliza con H0 y las Hiptesis
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) Estadstica de Prueba
. (Frmula 3.3)
Dnde:
= Varianza
= Media Poblacional
n= Tamao de la muestra
= Media muestral
f) Regin de rechazo:
La regin de rechazo es Z = Zx, donde Zx es tal que:
P [Z >Zx] = 0.05, donde Zx = Valor Tabular (tabla de distribucin normal Z)
Luego la regin de rechazo es: Z >Zx
Tambin es necesario considerar las siguientes frmulas para el clculo:
o
Promedio:

de Comas.
...Frmula (3.4)
102
o Varianza:
)
. (Frmula (3.5)
o Desviacin Estndar:
)
.... (Frmula (3.6)
Luego en la siguiente figura tenernos la distribucin Z (normal):
Hernndez (2006)
Grfica N 6
Distribucin Normal Z
En la grfica N 6, se puede visualizar la regin de rechazo (conocida como regin crtica)
y la regin de aceptacin (regin de no aceptacin).

de Comas.
103
RESULTADOS
4.1
Descripcin.
4.1.1 Anlisis de Confiabilidad.
Se realiz el anlisis de confiabilidad en los indicadores tiempo de respuesta
de la polica y porcentaje de registros de alertas falsas, las condiciones de
confiabilidad se definen en la tabla N 20.
Tabla N 20 Condiciones de confiabilidad
Condicin
Resultado
Sig < 0.05
Adopta una distribucin no normal
Sig 0.05
Adopta una distribucin normal

4.1.2 Prueba de normalidad.
Se procedi a realizar la prueba de normalidad en cada uno de los indicadores
mediante el mtodo Kolgomorov Smirnov, debido a la cantidad de la muestra
conformada por 48 registros de alertas, segn Caetano( p. 150, 2003). Dicha
prueba se realiz introduciendo los datos de cada indicador en el software
estadstico 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 Polica (Pre Test).
Tabla N 21 Prueba de Normalidad Tiempo de respuesta de la Polica
(Pre test)
Kolmogorov-Smirnova
Estadstico
gl
Sig.
Pre Test
0,166
48
0,002
Como se puede observar en la tabla N 21 el valor Sig es de 0.002 < 0.05, por
lo tanto adopta una distribucin no normal.
Indicador: Tiempo de respuesta de la Polica (Post Test)
Tabla N 22 Prueba de Normalidad Tiempo de respuesta de la Polica
(Post Test)
Post Test
Kolmogorov-Smirnova
Estadstico
gl
0,160
48
Sig.
0,003

de Comas.
104
Como se puede observar en la tabla N 22 el valor Sig. es de 0.003 < 0.05,

por lo tanto adopta una distribucin 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)
Kolmogorov-Smirnova
Estadstico
gl
Sig.
Pre Test
0,318
11
0,003
Indicador: Porcentaje de Registros de alertas falsas (Post Test)
Tabla N 24 Prueba de Normalidad Porcentaje de Registros de alertas falsas
(Post Test)
Kolmogorov-Smirnova
Estadstico
gl
Post Test
0,353
11
Sig.
0,000

4.1.3 Prueba de hiptesis
a) Hiptesis Especifica 1:
H1: El sistema de comunicacin mvil A-GPS disminuye el tiempo

de respuesta de la Polica en el proceso de atencin de llamadas de
Indicador: Tiempo de respuesta de la Polica.
Hiptesis Estadsticas
Hiptesis Ho: El sistema de comunicacin mvil A-GPS no reduce
el tiempo de respuesta de la polica en el proceso de atencin de
llamadas de emergencias en la comisaria de Santa Luzmila en el
distrito de Comas.
Por lo tanto:
de Comas.
105
El indicador del Sistema de proceso actual es mejor que el indicador

del sistema propuesto.
Hiptesis Ha: El sistema de comunicacin mvil A-GPS reduce el
tiempo de respuesta de la Polica en el proceso de atencin de
distrito de Comas.
Por lo tanto:
El indicador del sistema propuesto es mejor que el indicador del
sistema actual.
Tabla N 25 Clculo de las medias (1)
N
Pre_Test_Registro
Post_Test_Registro
N vlido (segn lista)
48
48
48
Media
29 min.
7 min.
Elaboracin Propia
Grfica N 7
Tiempo promedio de respuesta de la Polica (Comparativa

general).
De acuerdo a la Grfica N 7, se puede observar que existe una reduccin
muy importante en el tiempo promedio de respuesta de la polica en el
proceso de atencin de llamadas de emergencias a manera general se reduce
en 22 minutos, es decir, existe una disminucin porcentual del 75.85%.
La siguiente tabla nos muestra la prueba de los rangos con signo de
Wilcoxon.

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

Respecto al resultado de la tabla N 26 del contraste de hiptesis se aplic la
Prueba de Wilcoxon debido a que es una muestra de distribucin no normal,
la cual fue anteriormente explicada en el punto 4.1.2. El nivel crtico de
contraste (Sig.) es 0,000, y dado que es claramente menor a 0.05 entonces se
rechaza la hiptesis nula aceptando la hiptesis alterna con un 95% de
confianza, grficamente se puede apreciar en la siguiente grfica.
Elaboracin Propia
Grfica N 8
Contrastes de Hiptesis (Tiempo promedio de respuesta de la Polica)

de Comas.
107
b) Hiptesis Especifica 2:
H2: El sistema de comunicacin mvil A-GPS disminuye el

porcentaje de registros de alertas falsas en el proceso de atencin de
llamadas de emergencias en la comisaria de Santa Luzmila en el distrito
de Comas.
Indicador: Porcentaje de registros de alertas falsas.
Hiptesis Estadsticas
Hiptesis Ho: El sistema de comunicacin mvil A-GPS no reduce el
porcentaje de registros de alertas falsas en el proceso de atencin de
distrito de Comas.
Por lo tanto:
El indicador del sistema de proceso actual es mejor que el indicador
del sistema propuesto.
Hiptesis Ha: El sistema de comunicacin mvil A-GPS disminuye
el porcentaje de registros de alertas falsas en el proceso de atencin de
distrito de Comas.
Por lo tanto:
El indicador del sistema propuesto es mejor que el indicador del
sistema actual.
Tabla N 27 Clculo de las medias (2)
N
Pre_Test_Registro
Post_Test_Registro
N vlido (segn lista)
48
48
48
Media
45.83 %
10.41 %

de Comas.
108
Elaboracin Propia
Grfica N 9
Porcentaje promedio de registros de alertas falsas (Comparativa general).
De acuerdo a la Grfica N 9, se puede observar que existe una reduccin

muy importante en el porcentaje de registros de alertas falsas en el proceso de
atencin de llamadas de emergencias a manera general se reduce en 35.42%,
es decir, existe una disminucin 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 hiptesis se aplic la
Prueba de Wilcoxon debido a que es una muestra de distribucin no normal,
la cual fue anteriormente explicada en el punto 4.1.2. El nivel crtico de
contraste (Sig.) es 0,000, y dado que es claramente menor a 0.03 entonces se

de Comas.
109
rechaza la hiptesis nula aceptando la hiptesis alterna con un 95% de

confianza, grficamente se puede apreciar en la siguiente grfica.
Elaboracin Propia
Grfica N 10
Contrastes de Hiptesis (Porcentaje de registros de alertas falsas)
4.2
Discusin
1. El Sistema de Comunicacin Mvil A-GPS reduce el tiempo de respuesta de la
Polica en el proceso de atencin de llamadas de emergencias en la comisara de
Santa Luzmila en el distrito de Comas.
Existe una reduccin importante en el tiempo promedio de respuesta de la polica
en el proceso de atencin de llamadas de emergencias a manera general se reduce
en 22 minutos, es decir, existe una disminucin porcentual del 75.85%.
Se han obtenido tiempos menores de respuesta de la Polica ante una emergencia
de 3 y 4 minutos en comparacin con el proyecto de investigacin Jallpa Kuyuy
Sistema de comunicacin Mvil GPS Post sismo de la Unidad de Investigacin
FIA de la Universidad San Martin de Porres, la cual obtuvieron como resultados
de 5 minutos como el menor tiempo.
2. El Sistema de Comunicacin Mvil A-GPS reduce el porcentaje de alertas falsas
en el proceso de atencin de llamadas de emergencias en la comisara de Santa
Tambin existe una reduccin considerable en el porcentaje de registro de alertas
falsas en el proceso de atencin de llamadas de emergencias, ya que anteriormente
se tena un registro del total de registros de alertas el 45.83% eran consideradas
como alertas falsas, ahora con la implementacin de la aplicacin se redujo al
10.41%, es decir existe una disminucin porcentual del 77.29%.
3. De acuerdo a la hiptesis planteada, el sistema de comunicacin Mvil A-GPS
influyo de manera positiva en el tiempo de respuesta de la Polica ante las
llamadas de emergencias de la comisara 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 instantneas del operador

de Comas.
110
de la Comisaria de Santa Luzmila en comparacin con la investigacin

Implementacin de un Web GIS que permita ubicar llamadas de emergencia para
el Benemrito Cuerpo de Bomberos Voluntarios de la Ciudad de Cuenca de
Diana Carolina Arce Cuesta y Sebastin Alejandro Cceres Abril, la cual el
tiempo de respuesta de la aplicacin no fue el ms ptimo ya que la herramienta
que utilizaron (OpenLayers) tiende a demorar en cargar la informacin, esto
ocasiona que se genera un cola de las llamadas de emergencias.
Finalmente luego de haber obtenido resultados favorables con la implementacin
del sistema, se not la mejora del proceso de atencin de llamadas de emergencia
en la comisara de Santa Luzmila en el distrito de Comas.
4. El Sistema de Comunicacin Mvil A-GPS bajo la plataforma mvil y web
mejora el proceso de atencin de llamadas de emergencias al haber disminuido el
tiempo de respuesta de la polica y el porcentaje de registro de alertas falsas.

de Comas.
111
V. CONCLUSIONES Y SUGERENCIAS
5.1
Conclusiones.
1. Se concluye que el sistema de comunicacin mvil A-GPS reduce el tiempo de
respuesta de la Polica en el proceso de atencin de llamadas de emergencias en la
comisaria de Santa Luzmila, ya que influye positivamente en el proceso en
mencin. Sin el sistema se promedi 29 minutos y con la implementacin del
sistema se redujo a los 7 minutos, lo que significa una reduccin de 22 minutos en
dicho proceso. En consecuencia se produce una disminucin porcentual de
75.85%.
2. Se concluye que el sistema de comunicacin mvil A-GPS reduce el porcentaje de
registros de alertas falsas en el proceso de atencin de llamadas en la comisaria de
Santa Luzmila en el distrito de Comas, ya que influye positivamente en el proceso
en mencin. Sin el sistema se obtuvo un 45.83 % y con la implementacin del
sistema alcanz los 10.41% de registros de alertas falsas, lo que significa una
reduccin porcentual de 77.29 %
3. Finalmente despus de haber obtenido resultados satisfactorios de los indicadores
del estudio, se concluye que la implementacin del sistema de comunicacin
mvil A-GPS mejora el proceso de atencin 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 continuacin se detalla las recomendaciones para futuras investigaciones:
1. A la presente investigacin se puede profundizar con otros requerimientos
funcionales de las dems comisaras del distrito de Comas y el Serenazgo de la
Municipalidad de Comas, para mejorar el proceso de atencin de llamadas de
emergencias.
2. Se sugiere incorporar al Sis-CoMvil A-GPS un medio de validacin 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 informacin ms real de
los usuarios que se registran y de este modo reducir el porcentaje de registros de
alertas falsas.
3. En el anlisis de los datos solo se ha considerado variables cuantitativas como son
el tiempo de respuesta de la polica y porcentaje de registros de alertas falsas. Por
ello, esta investigacin podra continuarse teniendo en cuenta variables
cualitativas como el nivel de satisfaccin de los usuarios con el sistema. Adems
se puede desarrollar el sistema para otras plataformas como: Windows Phone,
BlackBerry SO, Symbian OS entre otros.

de Comas.
112
REFERENCIAS BIBLIOGRFICAS
-
Carrasco, S. (2006). Metodologa de la investigacin cientfica. (1a ed.) Lima:

Editorial San Marcos.
Carrin, F. y Dammert, M. (2009). Economa Poltica de la Seguridad Ciudadana. (1a

ed.). Quito: FLACSO.
Dammert, L. (2010). Crimen e inseguridad: polticas, temas y problemas en las

Amricas. (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 Carrin, F. (2008). Ensayos Sobre Seguridad Ciudadana. (1a ed.).

Ecuador: Flacso-Sede Ecuador.
Fabregas Ll., J. (2005) Gerencia de Proyectos de Tecnologa de Informacin. (1

ed.). Caracas: Editorial CEC, SA.
Federacin Iberoamericana de OMBUDSMAN (2011). VII Informe sobre Derechos

Humanos Seguridad Ciudadana.
Recuperado de:
http://www.portalfio.org/inicio/repositorio/informesfio/informe_seguridad_ciudadana.pdf
Figueroa, R., Sols, C. y Cabrera, A. (2008) Metodologas Tradicionales vs.

Metodologas giles. ECC/UTPL.
Fujita, H. y Domnico, M. (2010). New Trends in Software Methodologies, Tools and

Techniques. (1a ed.). Amsterdam, Netherlands: IOS Press BV.
Garzs J. (2011). Calidad de Software y Otros Temas Relacionados. Espaa

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

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 Mtodos de Investigacin en Tiempos

de Cambios. (5 ed.). Caracas: CEC, SA.

de Comas.
113
Instituto de Opinin Pblica. Segunda Encuesta Metropolitana de Victimizacin 2012.

Recuperado de:
http://www.ciudadnuestra.org/facipub/upload/cont/3222/cont/files/encuesta_victimiza
cion_2012_cn_2.pdf
Instituto Nacional de Estadstica e Informtica. Actualizacin del Impacto de las

tecnologas de Informacin y Comunicacin 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). Estadstica Aplicada a la administracin y a la

economa. (3 ed.). Mxico DF: McGraw-Hill.
Martnez B., C. (2005). Estadstica y muestreo (12 ed.) ECOE-Ediciones.
Mora, L. (2008). Indicadores de la gestin logstica (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). Metodologa de la Investigacin cientfica y Asesoramiento de

Tesis. (1 ed.). Grfica RETAI SAC.
Ortega M., C. (2009). Estadstica General. (1 ed.). Lima: AE/UCV-LIMA.
Quesada X. (2009). Introduccin a la Estimacin y Planificacin gil

Recuperado de:
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
Taha H., A. (2004). Investigacin de Operaciones. (7a ed.). Mxico DF: Pearson
Education.
Tafur P., R. (1995) La tesis Universitaria. (1 ed.) Lima: Editorial Mantaso.
Tamayo y Tamayo M. (2004) El Proceso de la Investigacin Cientfica. (4 ed.).

Mexico DF: Limusa.
Serra, D. (2005). La Logstica empresarial en el nuevo milenio. (2da ed.). Bogota.
Sommerville, I. (2005). Ingeniera del Software. (7 ed.) Madrid: Pearson Education.
Valderrama, S. y Len, L. (2009). Tcnicas e instrumentos para la obtencin de datos

en la investigacin cientfica. (1 ed.). Lima.
Van Diggelen, F. (2009). A-GPS, Assisted GPS, GNSS, and SBAS. (1a ed.). United
States of America: Artech House.

de Comas.
114
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

de Comas.
115
ANEXOS
Anexo N 1 Matriz de Consistencia
TTULO: Sistema de Comunicacin Mvil A-GPS en el proceso de atencin de llamadas de emergencias en la comisara de Santa Luzmila en el
distrito de Comas.
RESPONSABLE: Lpez Chvez, Carlomagno.
OPERACIONALIZACIN DE VARIABLES
PROBLEMA
OBJETIVOS
HIPTESIS
VARIABLE
Secundarios
Especficos
Especficos
De qu manera influye un sistema Determinar la influencia de un sistema El sistema de comunicacin Mvil Ade comunicacin mvil A-GPS en de comunicacin Mvil A-GPS en el GPS disminuye el tiempo de respuesta
el tiempo de respuesta de la Polica tiempo de respuesta de la Polica en la de la Polica en la atencin de
frente
a
las
llamadas
de atencin de llamadas de emergencias llamadas de emergencias en la
emergencias en la comisara de en la comisara de Santa Luzmila en el comisara de Santa Luzmila en el
Santa Luzmila en el distrito de distrito de Comas.
distrito de Comas.
Comas?
De qu manera influye un sistema Determinar la influencia de un sistema El sistema de comunicacin Mvil
de comunicacin mvil A-GPS en de comunicacin mvil A-GPS en el GPS disminuye el porcentaje
el porcentaje de registros de alertas porcentaje de registros de alertas falsas registros de alertas falsas en
en la comisara de Santa Luzmila en en la comisara de Santa Luzmila en el comisara de Santa Luzmila en
el distrito de Comas?
distrito de Comas.
distrito de Comas.
Tiempo de
respuesta de
la polica
Tiempo
A- Proceso de atencin
de
de llamadas de
la
emergencias
el
Implementar
un
sistema
de
comunicacin mvil A-GPS para
mejorar el proceso de atencin de
llamadas en la comisara de Santa
Porcentaje de
alertas falsas
116
METODOLOGA
Tipo de Investigacin:
El tipo de estudio de este trabajo
de investigacin es experimentalaplicada.
Diseo de Estudio:
La investigacin requiere del
diseo pre-experimental debido a
que se pretende gestionar el
proceso de atencin de registro
de llamadas de emergencias en la
modalidad
de
prepruebaFicha de
Observacin posprueba, es decir se analiza el
(Cronometro) estado en que se encuentra dicho
proceso y se observan los
cambios.
Poblacin:
Son los 63 registros de llamadas
de emergencias.
Muestra:
Son 48 registros de llamadas de
emergencias.
Mtodo de Investigacin:
El mtodo de investigacin que
se usa para saber si el sistema
comunicacin mvil A-GPS es
Ficha de
favorable en el proceso de
observacin
atencin de llamadas de
emergencias es el mtodo
cuantitativo deductivo.
Tcnicas e Instrumentos de
recoleccin de datos:
Observacin,
entrevista,
tcnicas de lectura.
DIMENSIONES INDICADORES INSTRUMENTOS
General
General
General
Independiente
De qu manera influye un sistema Determinar la influencia de un sistema El sistema de comunicacin Mvil Ade comunicacin Mvil A-GPS de comunicacin Mvil A-GPS para el GPS mejora el proceso de atencin de
Sistema de
para el proceso de atencin de proceso atencin de llamadas de llamadas de emergencias en la Comunicacin Mvil
llamadas de emergencias en la emergencias en la comisara de Santa comisara de Santa Luzmila en el
A-GPS
comisara de Santa Luzmila en el Luzmila en el distrito de Comas.
distrito de Comas.
distrito de Comas?
Dependiente
Porcentaje de
registros de
alertas falsas
Anexo N 2 Ficha de Observacin

FICHA DE OBSERVACIN N 1
ANALISTA: Lpez Chvez, Carlomagno.
Fecha: 17/09/2012
DESCRIPCIN
El proceso de atencin 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, ubicacin donde se produjo la incidencia, que tipo de incidencia es (Asalto,
accidente de trnsito, pandillaje, etc.), posteriormente, el operador policial deriva esta
llamada hacia un efectivo policial encargado de acuerdo a la ubicacin 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 va radio con la comisara ms cercana donde se produjo la incidencia para
informar los datos brindados por el ciudadano, luego la comisara designaba de acuerdo
a la jurisdiccin que mvil debe acudir al lugar de la emergencia. El tiempo promedio
de respuesta de la polica ante una llamada de emergencia era de 29 minutos
aproximadamente.
117
Anexo N 3 Entrevista al comisario
118
119
Anexo N 4 Ficha de observacin para determinar la Poblacin.

Investigador: Lpez Chvez, Carlomagno
Organizacin: Comisara de Santa Luzmila - Comas
Tipo de Prueba: PRE TEST
Direccin: Av. Gerardo Unger 6500, Urb. Santa Luzmila
Fecha: 01/10/2012 11/10/2012
Fecha
Lunes 01/10/2012
Martes 02/10/2012
Mircoles 03/10/2012
Jueves 04/10/2012
Viernes 05/10/2012
Sbado 06/10/2012
Domingo 07/10/2012
Lunes 08/10/2012
Martes 09/10/2012
Mircoles 10/10/2012
Jueves 11/10/2012
Total
Cantidad de registros de
5
7
3
10
4
4
16
3
5
4
2
63
Observacin: Para el clculo de la poblacin se consider 11 das desde el 01 de Octubre

del 2012 hasta el 11 de Octubre del 2012, obteniendo una poblacin de 63 registros de
llamadas de emergencias.
120
Anexo N 5 Ficha de Observacin: Tiempo de respuesta de la Polica.

Fecha: 01/10/2012 11/10/2012
N Reg.
Hora de Registro
Llamada
Llamada
Reg. 01 01/10/2012 21:00:00
Hora de llegada al
lugar del incidente
01/10/2012 21:24:00
Reg. 02
01/10/2012 21:34:00
01/10/2012 22:04:00
Reg. 03
Reg. 04
Reg. 05
02/10/2012 12:19:00
02/10/2012 11:39:00
02/10/2012 12:01:00
02/10/2012 13:17:00
02/10/2012 12:10:00
02/10/2012 12:28:00
Reg. 06
Reg. 07
Reg. 08
Reg. 09
Reg. 10
02/10/2012
02/10/2012
02/10/2012
03/10/2012
04/10/2012
02/10/2012
02/10/2012
02/10/2012
03/10/2012
04/10/2012
Reg. 11
Reg. 12
04/10/2012 20:08:00
04/10/2012 22:23:00
04/10/2012 20:32:00
04/10/2012 22:55:00
Reg. 13
Reg. 14
Reg. 15
Reg. 16
Reg. 17
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
04/10/2012
Reg. 18
Reg. 19
05/10/2012 08:48:00
05/10/2012 11:33:00
05/10/2012 09:23:00
05/10/2012 12:28:00
Reg. 20
05/10/2012 10:00:00
05/10/2012 10:29:00
Reg. 21
Reg. 22
05/10/2012 08:30:00
06/10/2012 18:15:00
05/10/2012 08:57:00
06/10/2012 18:52:00
Reg. 23
Reg. 24
06/10/2012 15:14:00
06/10/2012 16:15:00
06/10/2012 15:42:00
06/10/2012 16:39:00
Reg. 25
07/10/2012 02:08:00
07/10/2012 02:35:00
Reg. 26
Reg. 27
07/10/2012 03:21:00
07/10/2012 03:00:00
07/10/2012 03:47:00
07/10/2012 03:23:00
09:09:00
09:21:00
10:43:00
15:40:00
04:08:00
21:26:00
19:54:00
21:47:00
22:26:00
00:07:00
09:31:00
09:47:00
11:16:00
16:05:00
04:35:00
21:50:00
20:27:00
22:28:00
22:56:00
00:33:00
121
Tiempo
Respuesta
Motivo
24 min. Alteracin del Orden
Pblico
30 min.
Asalto (cruce El
lamo/Av. Collique)
58 min. Accidente de Transito
31 min.
Infarto
27 min. Vehculo sospechoso
(color blanco)
31 min.
Agresin Familiar
33 min
Accidente transito
25 min.
Cada de Pared
27 min
Rotura de tubo de
agua
24 min. Supuesto Delincuente
33 min
Pandilleros
(Parque Belen)
24 min. Espalda Colegio 2005
33 min. Accidente de Transito
41 min.
Agresin fsica
30 min.
Pandilleros
26 min. Sujeto arrojado de una
mvil
35 min. Accidente de transito
55 min. Agresin con rotura
de cabeza
29 min.
Asalto y Robo con
arma de fuego 4
sujetos
27 min.
Agresin
37 min.
Enfrentamiento,
amenazo a su ex
yerno.
28 min.
Delincuentes
24 min.
Emergencia (Av.
Trapiche/Av. Incas)
27 min.
Pandilleros (Av.
Jamaica/Universitaria)
26 min.
San Diego
23 min. Emergencia del 105
N Reg.
Hora de Registro
Llamada
Llamada
Reg. 28 07/10/2012 04:43:00
Reg. 29 07/10/2012 05:15:00
Reg. 30 07/10/2012 01:58:00
Reg. 31
07/10/2012 05:54:00
Reg. 32
07/10/2012 06:26:00
Reg. 33
07/10/2012 21:24:00
Reg. 34
07/10/2012 22:39:00
Reg. 35
07/10/2012 22:48:00
Reg. 36
07/10/2012 22:49:00
Reg. 37
Reg. 38
07/10/2012 00:02:00
08/10/2012 09:29:00
Reg. 39
08/10/2012 11:59:00
Reg. 40
09/10/2012 14:17:00
Reg. 41
Reg. 42
09/10/2012 15:54:00
09/10/2012 13:32:00
Reg. 43
Reg. 44
09/10/2012 17:49:00
09/10/2012 14:54:00
Reg. 45
10/10/2012 01:50:00
Reg. 46
10/10/2012 22:47:00
Reg. 47
10/10/2012 19:45:00
Reg. 48
11/10/2012 07:30:00
Hora de llegada al
lugar del incidente
07/10/2012 05:09:00
07/10/2012 05:37:00
07/10/2012 02:23:00
Tiempo
Respuesta
Motivo
26 min. Alteracin del O.P.
22 min.
Agresin fsica
Pblico
07/10/2012 06:19:00
25 min. Accidente de Trnsito
(ovalo infantas)
07/10/2012 06:58:00
32 min. Accidente de Trnsito
(Trapiche/Incas)
07/10/2012 21:52:00
28 min. Pandilleros (colegio
ustas)
07/10/2012 23:13:00
34 min. Robo va pblica (Av.
Sangara)
07/10/2012 23:20:00
32 min.
Sujeto tendido
(Universitaria Jamaica)
07/10/2012 23:24:00
Pblico
07/10/2012 00:26:00
24 min.
Asalto va publica
08/10/2012 09:54:00
25 min. Robo de dinero (Jr.
Libertad 195)
08/10/2012 00:32:00
33 min. Alteracin del orden
publico
09/10/2012 14:48:00
31 min.
Tocamientos
indebidos
09/10/2012 16:20:00
26 min.
Av. Trapiche
09/10/2012 13:57:00
25 min.
Agresin fsica (El
lamo Mz.K1 Lt.4)
09/10/2012 18:17:00
28 min.
Agresin fsica
09/10/2012 15:24:00
30 min.
Va a la misma
direccin del Reg. 32
10/10/2012 02:18:00
(color rojo)
10/10/2012 23:15:00
24 min. Pandilleros (Belaunde
-Universitaria)
10/10/2012 20:10:00
25 min. Accidente Transito
(Universitaria/
Guillermo La Fuente)
11/10/2012 08:04:00
34 min.
Primera de Pro.
Promedio : 29 min.
122
Anexo N 6 Ficha de Observacin: Porcentaje de registro de alertas falsas.

Fecha: 01/10/2012 11/10/2012
N Reg. Llamada
Reg. 01
Reg. 02
Reg. 03
Reg. 04
Reg. 05
Reg. 06
Reg. 07
Reg. 08
Reg. 09
Reg. 10
Reg. 11
Fecha de Registro
Llamada
01/10/2012
02/10/2012
03/10/2012
04/10/2012
05/10/2012
06/10/2012
07/10/2012
08/10/2012
09/10/2012
10/10/2012
11/10/2012
Total :
alertas falsas
1
2
1
3
2
2
2
2
2
3
2
22
De acuerdo a la frmula del indicador de porcentaje de registros de alertas falsa, se realiz

el remplazo de los valores para el clculo correspondiente:
Porcentaje de registro de alertas falsas = (22 / 48)*100 = 45.83%
123
Anexo N 7 Ficha de Observacin: Tiempo de respuesta de la Polica.

Tipo de Prueba: POST TEST
Fecha: 15/05/2013 - 25/05/2013
N Reg.
Hora de Registro
Llamada
Llamada
Reg. 01 15/05/2013 20:00:00
Reg. 02 15/05/2013 22:34:00
Reg. 03 15/05/2013 12:19:00
Reg. 04
Reg. 05
Reg. 06
16/05/2013 10:39:00
16/05/2013 12:01:00
16/05/2013 09:11:00
Reg. 07
Reg. 08
16/05/2013 07:05:00
16/05/2013 10:43:00
Reg. 09
Reg. 10
Reg. 11
17/05/2013 15:40:00
17/05/2013 04:08:00
17/05/2013 23:08:00
Reg. 12
17/05/2013 20:23:00
Reg. 13
Reg. 14
Reg. 15
Reg. 16
18/05/2013
18/05/2013
18/05/2013
18/05/2013
Reg. 17
18/05/2013 00:09:00
Reg. 18
Reg. 19
Reg. 20
18/05/2013 08:25:00
18/05/2013 11:11:00
18/05/2013 10:00:00
Reg. 21
Reg. 22
Reg. 23
19/05/2013 08:37:00
19/05/2013 16:15:00
19/05/2013 15:10:00
Reg. 24
Reg. 25
Reg. 26
19/05/2013 18:25:00
20/05/2013 02:11:00
20/05/2013 03:28:00
Reg. 27
20/05/2013 03:07:00
13:26:00
19:54:00
21:47:00
11:26:00
Hora de llegada al
Tiempo
lugar del incidente Respuesta
Motivo
15/05/2013 20:10:00
10 min. Accidente Transito
15/05/2013 22:42:00
8 min.
Robo
15/05/2013 12:25:00
Otros: Persona
6 min.
Sospechosa
16/05/2013 10:46:00
7 min.
Robo
16/05/2013 12:09:00
8 min.
Pandillaje
16/05/2013 09:20:00
Otros: Camin
9 min.
malogrado Av. Incas
16/05/2013 07:12:00
7 min. Otros: Pelea callejera
16/05/2013 10:47:00
Otros: Persona Ebrio
4 min.
hace escndalo.
17/05/2013 15:49:00
9 min.
Accidente Transito
17/05/2013 04:16:00
8 min.
Robo
17/05/2013 23:15:00
Otros: Pelea dos
7 min.
jvenes (Retablo)
17/05/2013 20:29:00
Otros: Se oyeron
6 min.
disparos (Retablo).
18/05/2013 13:35:00
9 min.
Robo
18/05/2013 20:04:00
8 min.
Accidente Transito
18/05/2013 21:54:00
7 min.
Persona Prdida
18/05/2013 11:30:00
Otros: Auto
4 min. Sospechoso, color rojo
lunas polarizadas
18/05/2013 00:20:00
Otros: Moto taxista
11 min.
peleando con pasajero
18/05/2013 08:31:00
6 min.
Accidente Trnsito
18/05/2013 11:18:00
7 min.
Robo
18/05/2013 10:19:00
Otros: Persona
9 min.
sospechosa en
paradero Seguro
19/05/2013 08:42:00
5 min.
Otros
19/05/2013 16:18:00
3 min.
Asalto
19/05/2013 15:17:00
Otros: Poste
7 min.
alumbrado pblico
cado
19/05/2013 18:36:00
11 min.
Robo
20/05/2013 02:16:00
5 min.
Asalto
20/05/2013 03:35:00
Otros: Persona
7 min.
desmayada en
paradero
20/05/2013 03:17:00
10 min.
Robo
124
N Reg.
Hora de Registro
Llamada
Llamada
Reg. 28 20/05/2013 04:43:00
Reg. 29 20/05/2013 05:35:00
Hora de llegada al
lugar del incidente
20/05/2013 04:51:00
20/05/2013 05:45:00
Tiempo
Respuesta
8 min.
Reg. 30
Reg. 31
21/05/2013 01:59:00
21/05/2013 05:50:00
21/05/2013 02:07:00
21/05/2013 05:57:00
8 min.
Reg. 32
Reg. 33
Reg. 34
21/05/2013 06:26:00
21/05/2013 21:24:00
21/05/2013 22:49:00
21/05/2013 06:32:00
21/05/2013 21:31:00
21/05/2013 22:57:00
6 min.
7 min.
Reg. 35
Reg. 36
21/05/2013 20:40:00
21/05/2013 21:50:00
21/05/2013 20:48:00
21/05/2013 21:57:00
8 min.
Reg. 37
22/05/2013 00:02:00
22/05/2013 00:07:00
Reg. 38
22/05/2013 06:29:00
22/05/2013 06:36:00
Reg. 39
Reg. 40
Reg. 41
23/05/2013 11:59:00
23/05/2013 13:10:00
23/05/2013 14:54:00
23/05/2013 00:08:00
23/05/2013 13:17:00
23/05/2013 14:58:00
10 min.
7 min.
8 min.
7 min.
5 min.
7 min.
9 min.
7 min.
4 min.
Reg. 42
23/05/2013 13:32:00
23/05/2013 13:40:00
Reg. 43
Reg. 44
23/05/2013 07:49:00
24/05/2013 09:54:00
23/05/2013 07:54:00
24/05/2013 10:00:00
5 min.
Reg. 45
Reg. 46
24/05/2013 08:50:00
24/05/2013 22:47:00
24/05/2013 08:54:00
24/05/2013 22:56:00
4 min.
Reg. 47
Reg. 48
25/05/2013 19:49:00
25/05/2013 05:55:00
25/05/2013 19:57:00
25/05/2013 06:02:00
Promedio :
8 min.
7 min.
7 min.
125
8 min.
6 min.
9 min.
Motivo
Robo
Otros: Disparos al aire
libre
Secuestro
Otros: Desalojo de
vendedores en calle
Accidente Transito
Otros: Auto sin placa
Otros: Persona
sospechosa
Otros: Pique de autos
Otros: rbol cado en
media av. universitaria
Otros: Buzn abierto
cerca a colegio peligro
Otros: Persona ebria
problemas va publica
Pandillaje
Robo
Accidente transito:
Mototaxi choco con
auto
Secuestro: En
restaurante
Robo en av. 22 agosto
Otros: Se incendia una
casa
Pandillaje
Otros: Pelea de bandas
en Retablo
Robo a transente
Otros: Persona herida
Anexo N 8 Ficha de Observacin: Porcentaje de registro de alertas falsas.

Organizacin: Comisaria de Santa Luzmila - Comas
Tipo de Prueba: POST TEST
Fecha: 15/05/2013 - 25/05/2013
N Reg. alerta
Reg. 01
Reg. 02
Reg. 03
Reg. 04
Reg. 05
Reg. 06
Reg. 07
Reg. 08
Reg. 09
Reg. 10
Reg. 11
Fecha de Registro alerta
alertas falsas
15/05/2013
16/05/2013
17/05/2013
18/05/2013
19/05/2013
20/05/2013
21/05/2013
22/05/2013
23/05/2013
24/05/2013
25/05/2013
0
1
0
1
0
1
0
1
0
1
0
Total
De acuerdo a la frmula del indicador de porcentaje de registros de alertas falsas, se realiz

el remplazo de los valores para el clculo correspondiente:
Porcentaje de registro de alertas falsas = (5 / 48)*100 = 10.41%
126
Anexo N 9 Tabla de criterios para la seleccin de metodologa (1).
127
128
129
Anexo N 12 Tabla de criterios para la seleccin del lenguaje de programacin (1).
130
131
132
Anexo N 15 Criterios de evaluacin de experto gestor de Base de Datos (1).
133
134
135
Anexo N 18 Tabla evaluacin de experto fichas de observacin (1).
136
137
138
Anexo N 21 Cronograma de Desarrollo de la Aplicacin.
139
Anexo N 22 Modelo Lgico
140
Anexo N 23 Modelo Fsico
141
Anexo N 24 Diagrama de Base de Datos SQL Server
142
Anexo N 25 Carta de Conformidad de la Finalizacin del Proyecto de Investigacin
143
Anexo N 26 Registro de Llamadas de emergencias (1)
144
145
146
147
148
149
150
151
152
Anexo N 35 Parte Policial para determinar la hora de llegada de la Polica al lugar de la

alerta (1).
153

alerta (2).
154

alerta (3).
155
Anexo N 38 Mapa del mbito Jurisdiccional de la Comisara de Santa Luzmila.
156
Anexo N 39 Cdigo Fuente Acceso a la aplicacin

import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
java.util.ArrayList;
org.apache.http.NameValuePair;
org.apache.http.message.BasicNameValuePair;
org.json.JSONArray;
org.json.JSONException;
org.json.JSONObject;
test.Droidlogin.library.Httppostaux;
android.app.Activity;
android.app.ProgressDialog;
android.content.Context;
android.content.Intent;
android.net.Uri;
android.os.AsyncTask;
android.os.Bundle;
android.os.SystemClock;
android.os.Vibrator;
android.util.Log;
android.view.View;
android.widget.Button;
android.widget.EditText;
android.widget.TextView;
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
157
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
158
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];
159
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();
}
}
}
}
160

FINAL Desarrollo Tesis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

FINAL Desarrollo Tesis

Hochgeladen von

Copyright:

Verfügbare Formate

FACULTAD DE INGENIERA

ESCUELA DE INGENIERA DE SISTEMAS

SISTEMA DE COMUNICACIN MVIL A-GPS EN

Dedico esta tesis a mi familia,

La presente tesis, para su desarrollo ha

3.6. Tcnicas e instrumentos de recoleccin de datos.... 98

Figura N 47 - Descripcin detallada de la Historia: Tipos de alertas.. 65

Figura N 89 - Interfaz concluida de la tarea 8.2 Enviar mensaje de atencin al usuario

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

Planteamiento del Problema

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

- Comisara PNP Universidad, ubicada en Av. Universitaria, Cdra. 8, Santa

Proceso de atencin de llamadas de la central de emergencias 105.

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

registrada, luego la comisara designa de acuerdo a la jurisdiccin que mvil debe

Tiempo promedio de respuesta de la Polica.

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

Porcentaje promedio de registro de alertas falsas.

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

Formulacin del problema

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

1.3.2 Justificacin Operativa

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

En lugares cerrados el sistema de comunicacin Mvil A-GPS, puede perder la

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

metodologa utilizada fue RUP y el tipo de investigacin fue experimental

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

II. MARCO TERICO

Frank Van Diggelen, 2009.

Visin general de la asistencia A-GPS.

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

La figura N 2 muestra al servidor de localizacin y la base de estacin

Sistema de Comunicacin Mvil A-GPS en el

Lpez Chvez, Carlomagno

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas