Facultad de Ingeniería Carrera de Ingeniería de …repositorio.utp.edu.pe/bitstream/UTP/1988/1/Jhon Anampa...Facultad de Ingeniería Carrera de Ingeniería de Software Tesis ³Diseño

Facultad de Ingeniería Carrera de Ingeniería de Software

Tesis

“Diseño de una aplicación móvil para registrar e informar casos de bullying en un colegio privado de Lima”

Autor: Jhon Paul Anampa García

Para obtener el Título profesional de

Ingeniero de Software

Asesor: Ivan Petrlik Azabache

Lima - Perú, Mayo de 2019

I

DEDICATORIA

A mi madre por su apoyo incondicional durante toda mi vida desde mi educación hasta mi

superación personal. Además, a mis familiares y amigos por su apoyo durante el desarrollo

del presente trabajo.

JHON PAUL ANAMPA GARCIA

II

AGRADECIMIENTOS

En primer lugar, a todos los profesores que he tenido a lo largo de mi formación por guiarme

en el proceso de generación de aprendizaje.

Agradezco también a la institución educativa que me permitió elaborar esta investigación

en sus instalaciones y todo su personal.

Finalmente, agradezco a los instructores de diversas disciplinas que me han orientado a lo

largo de mi vida.

III

RESUMEN

El presente trabajo de investigación busca determinar el impacto de la implementación de

un prototipo funcional de una aplicación móvil en la gestión de casos de bullying y violencia

escolar en un colegio privado del Lima en el año 2018. Se examinaron diversas

dimensiones como facilidad de uso de la aplicación, tiempo de respuesta, presentación

amigable de la información y consumo de recursos. Para ello se construyó una aplicación

móvil para gestionar estos casos. Además, se aplicó un cuestionario a diversos miembros

de la comunidad educativa sobre el impacto de la aplicación. Los datos analizados

muestran que en general se observa una mayor facilidad y reducción de tiempo para

realizar los reportes de casos de bullying o violencia escolar mediante la aplicación.

Asimismo, la aplicación provee de forma amigable la información con la que trabaja el

personal de la institución educativa, cumpliendo con las normativas que establece la ley

peruana. Se describe el procedimiento del desarrollo de la aplicación siguiendo el proceso

unificado de Rational y detallando cada fase. Finalmente, el presente trabajo tiene como

una finalidad servir como base para el futuro análisis del impacto de aplicaciones móviles

en las instituciones aplicando tecnologías actuales y programación en capas.

Palabras clave: Implementación de un prototipo funcional, aplicaciones móviles nativas,

impacto de la implementación de una aplicación.

IV

ABSTRACT

This research work has as purpose to determine the impact of the implementation of a

functional prototype of a mobile application in the management of cases of bullying and

school violence in a private school in Lima in 2018. Several dimensions were examined

such as usability of the application, response time, good visual presentation of information

and consumption of resources. To do this, an application was developed. In addition, a

questionnaire was applied to various members of the educational community to determine

the impact of the implementation. The data analyzed show, in general, a greater facility and

a reduction in the time to report cases of school bullying or school violence through the

application. Likewise, the application shows the information in a friendly way to the

personnel of the educational institution to work with it, complying with the normative of the

Peruvian law. The software development procedure is described in each phase using the

Rational unified process. Finally, the purpose of this work is to serve as a basis for future

analysis of the impact of mobile applications in institutions applying current techniques and

programming in layers.

Keywords: Implementation of a functional prototype, native mobile applications, impact of

the implementation of an application.

V

LISTA DE TABLAS

Tabla 1. Versiones de Android .........................................................................................34

Tabla 2. Resultados de la valoración de expertos ............................................................65

Tabla 3. Escala de adecuación del instrumento ...............................................................66

Tabla 4. Primer cronograma de desarrollo .......................................................................69

Tabla 5. Cronograma final de desarrollo ..........................................................................70

Tabla 6. Participantes según rol en la IEP y si poseen dispositivos móviles ....................76

Tabla 7. Catálogo de actores ...........................................................................................91

Tabla 8. Requisitos funcionales del sistema ....................................................................92

Tabla 9. Detalles del requisito funcional RQF-0001 .........................................................93

Tabla 10. Detalles del requisito funcional RQF-0002 .......................................................93








Tabla 18. Requisitos no funcionales ................................................................................97

Tabla 19. Catálogo de requisitos final ..............................................................................98

Tabla 20. Casos de uso del sistema .............................................................................. 100

Tabla 21. Especificación del caso de uso CUS-001. ...................................................... 107

Tabla 22. Especificación del caso de uso CUS-002 ....................................................... 108










VI




Tabla 35. Diccionario de datos de la tabla gender ......................................................... 146

Tabla 36. Diccionario de datos de la tabla level ............................................................. 146

Tabla 37. Diccionario de datos de la tabla grade ........................................................... 147

Tabla 38. Diccionario de datos de la tabla role............................................................... 147

Tabla 39. Diccionario de datos de la tabla section ......................................................... 147

Tabla 40. Diccionario de datos de la tabla status ........................................................... 148

Tabla 41. Diccionario de datos de la tabla user.............................................................. 148

Tabla 42. Diccionario de datos de la tabla case ............................................................. 149

Tabla 43. Diccionario de datos de la tabla incident ........................................................ 150

Tabla 44. Diccionario de datos de la tabla information ................................................... 150

Tabla 45. Presupuesto del talento humano .................................................................... 175

Tabla 46. Presupuesto de equipamiento, redes y muebles ............................................ 176

Tabla 47. Presupuesto de programas necesarios .......................................................... 176

Tabla 48. Flujo de efectivo proyectado a 5 meses ......................................................... 177

Tabla 49. Flujo de caja del proyecto .............................................................................. 178

Tabla 50. TIR y VAN para el proyecto ............................................................................ 178

Tabla 51. Resumen de procesamiento de casos ........................................................... 180

Tabla 52. Resultados de las estadísticas de fiabilidad ................................................... 180

Tabla 53. Estadísticas descriptivas de las preguntas 1, 2, 3, 4, 5, 6 y 7 ......................... 195

Tabla 54. Estadísticas descriptivas de la pregunta 11 .................................................... 196

Tabla 55. Estadísticas descriptivas de las preguntas 8, 9, 10, 12, 13, 14 y 15 ............... 197

Tabla 56. Estadísticas descriptivas de las preguntas 16 y 17 ........................................ 198

VII

LISTA DE FIGURAS

Figura 1. Evolución de los sistemas operativos en smartphones y tabletas. ..................... 9

Figura 2. Distribución de los dispositivos Android por versión. .......................................... 9

Figura 3. Los SO ocultan el hardware feo con abstracciones hermosas. .........................23

Figura 4. Isotipo y logotipo de Android. ............................................................................33

Figura 5. Entorno de un sistema de bases de datos simplificado. ....................................48

Figura 6. Proceso de desarrollo de software. ...................................................................50

Figura 7. Fases y flujos de trabajo del RUP. ....................................................................53

Figura 8. Clases y objetos en la programación orientada a objetos. ................................54

Figura 9. Escala de tiempo proyectada inicialmente. .......................................................70

Figura 10. Escala de tiempo final. ....................................................................................71

Figura 11. Posesión de dispositivos móviles. ...................................................................75

Figura 12. Sistema operativo usado. ................................................................................76

Figura 13. Versión de Android utilizada............................................................................77

Figura 14. Captura de pantalla de Android Studio del 07/05/2018. ..................................78

Figura 15. Número de víctimas o testigos de bullying. .....................................................78

Figura 16. Número de víctimas o testigos de cyberbullying. .............................................79

Figura 17. Desean tener la aplicación (No estudiantes). ..................................................79

Figura 18. Desean tener la aplicación (Estudiantes). .......................................................80

Figura 19. Valoración por parte de los estudiantes. .........................................................80

Figura 20. Valoración de la aplicación por la comunidad educativa. ................................81

Figura 21. Diagrama de casos de uso del negocio. .........................................................83

Figura 22. Caso de uso del negocio: Reportar caso. .......................................................84

Figura 23. Caso de uso del negocio: Recibir información. ...............................................85

Figura 24. Caso de uso del negocio: Mostrar libro. ..........................................................86

Figura 25. Diagrama de actividades del negocio de reportar caso. ..................................87

Figura 26. Diagrama de actividades del negocio de enviar información. ..........................88

Figura 27. Diagrama de actividades del negocio de mostrar libro. ...................................89

Figura 28. Caso de uso de inicio y cierre de sesión. ..................................................... 101

Figura 29. Casos de uso de reporte de casos e incidencias. ......................................... 102

Figura 30. Casos de uso de gestión de casos................................................................ 103

Figura 31. Casos de uso de gestión de incidencias. ...................................................... 104

Figura 32. Casos de uso de gestión de información de convivencia escolar. ................. 105

Figura 33.Diagrama general de casos de uso. ............................................................... 106

Figura 34. Capas del patrón MVVM. .............................................................................. 119

VIII

Figura 35. Diagrama de paquetes con sus respectivas capas. ...................................... 120

Figura 36. Distribución de los archivos View-Model. ...................................................... 121

Figura 37. Diagrama de clases de: CUS-001 Iniciar sesión. .......................................... 122

Figura 38. Diagrama de colaboración de: CUS-001 Iniciar sesión. propia. ..................... 122

Figura 39. Diagrama de secuencia de: CUS-001 Iniciar sesión. propia. ......................... 123

Figura 40. Diagrama de clases de: CUS-002 Cerrar sesión. .......................................... 123

Figura 41. Diagrama de colaboración de: CUS-002 Cerrar sesión. ................................ 124

Figura 42. Diagrama de secuencia de: CUS-002 Cerrar sesión. propia. ........................ 124

Figura 43. Diagrama de clases de: CUS-003 Reportar un caso. propia. ........................ 125

Figura 44. Diagrama de colaboración de: CUS-003 Reportar un caso. .......................... 125

Figura 45. Diagrama de secuencia de: CUS-003 Reportar un caso. .............................. 126

Figura 46. Diagrama de clases de: CUS-004 Consultar casos. ...................................... 126

Figura 47. Diagrama de colaboración de: CUS-004 Consultar casos. ............................ 127

Figura 48. Diagrama de secuencia de: CUS-004 Consultar casos. ................................ 127

Figura 49. Diagrama de clases de: CUS-005 Archivar caso. .......................................... 128

Figura 50. Diagrama de colaboración de: CUS-005 Archivar caso. ................................ 128

Figura 51. Diagrama de secuencia de: CUS-005 Archivar caso. .................................... 129

Figura 52. Diagrama de clases de: CUS-006 Reportar una incidencia. .......................... 129

Figura 53. Diagrama de colaboración de: CUS-006 Reportar una incidencia ................. 130

Figura 54. Diagrama de secuencia de: CUS-006 Reportar una incidencia. .................... 130

Figura 55. Diagrama de clases de: CUS-006 Reportar una incidencia (alterno). ............ 131

Figura 56. Diagrama de colaboración de: CUS-006 Reportar una incidencia (alterno). .. 131

Figura 57. Diagrama de secuencia de: CUS-006 Reportar una incidencia (alterno). ...... 132

Figura 58. Diagrama de clases de: CUS-007 Consultar incidencia. ............................... 132

Figura 59. Diagrama de colaboración de: CUS-007 Consultar incidencia. ..................... 133

Figura 60. Diagrama de secuencia de: CUS-007 Consultar incidencia. ......................... 133

Figura 61. Diagrama de clases de: CUS-008 Descargar libro de incidencias. ................ 134

Figura 62. Diagrama de colaboración de: CUS-008 Descargar libro de incidencias. ...... 134

Figura 63. Diagrama de secuencia de: CUS-008 Descargar libro de incidencias. .......... 135

Figura 64. Diagrama de clases de: CUS-009 Inscribir incidencia. .................................. 135

Figura 65. Diagrama de colaboración de: CUS-009 Inscribir incidencia. ........................ 136

Figura 66. Diagrama de secuencia de: CUS-009 Inscribir incidencia. ............................ 136

Figura 67. Diagrama de clases de: CUS-010 Archivar incidencia. ................................. 137

Figura 68. Diagrama de colaboración de: CUS-010 Archivar incidencia. ....................... 137

Figura 69. Diagrama de secuencia de: CUS-010 Archivar incidencia. ........................... 138

Figura 70. Diagrama de clases de: CUS-011 Remover incidencia. ................................ 138

Figura 71. Diagrama de colaboración de: CUS-011 Remover incidencia. ...................... 139

Figura 72. Diagrama de secuencia de: CUS-011 Remover incidencia. .......................... 139

Figura 73. Diagrama de clases de: CUS-012 Enviar datos. ........................................... 140

IX

Figura 74. Diagrama de colaboración de: CUS-012 Enviar datos. ................................. 140

Figura 75. Diagrama de secuencia de: CUS-012 Enviar datos. ..................................... 141

Figura 76. Diagrama de clases de: CUS-013 Enviar información. .................................. 141

Figura 77. Diagrama de colaboración de: CUS-013 Enviar información. ........................ 142

Figura 78. Diagrama de secuencia de: CUS-013 Enviar información. ............................ 142

Figura 79. Diagrama de clases de: CUS-014 Visualizar información. ............................ 143

Figura 80. Diagrama de colaboración de: CUS-014 Visualizar información. .................. 143

Figura 81. Diagrama de secuencia de: CUS-014 Visualizar información........................ 144

Figura 82. Modelo lógico de las entidades. .................................................................... 144

Figura 83. Diagrama EER de la base de datos. ............................................................. 145

Figura 84. Archivo Navigation XML que muestra el flujo de la aplicación. ...................... 151

Figura 85. Pantallas de inicio de sesión, principal y menú básico. ................................. 152

Figura 86. Menús para cada tipo de usuario. ................................................................. 153

Figura 87. Interfaz gráfica para reportar un caso. .......................................................... 153

Figura 88. Interfaz gráfica para los consultar y revisar casos. ........................................ 154

Figura 89. Interfaz gráfica para responder un caso. ....................................................... 155

Figura 90. Interfaz gráfica para reportar una incidencia. ................................................ 156

Figura 91. Interfaz gráfica para los consultar, revisar y remover incidencias. ................. 157

Figura 92. Interfaz gráfica para los enviar y ver información de convivencia escolar...... 158

Figura 93. Interfaz gráfica para descargar el libro de incidencias. .................................. 159

Figura 94. Interfaz gráfica para los enviar los datos de quien hace un reporte. .............. 159

Figura 95. Ubicación de los archivos de la capa view model. ......................................... 160

Figura 96.Ubicación de los archivos de la capa model. .................................................. 161

Figura 97. Diagrama de componentes general. ............................................................. 161

Figura 98. Diagrama de despliegue. .............................................................................. 162

Figura 99. Resultados de pruebas unitarias. .................................................................. 163

Figura 100. Servicios REST testeados mediante Postman. ........................................... 165

Figura 101. Resultado de las pruebas instrumentadas. ................................................. 166

Figura 102. Dispositivos virtuales emulados. ................................................................. 168

Figura 103. Dispositivo virtual con Android 4.0.3. .......................................................... 168

Figura 104. Dispositivo virtual con Android 4.4. ............................................................. 169

Figura 105. Capturas del dispositivo físico con Android 7.0. .......................................... 169

Figura 106. Dispositivo virtual con Android 9.0. ............................................................. 170

Figura 107. Consumo de almacenamiento de la aplicación. .......................................... 171

Figura 108. Uso de memoria RAM. ............................................................................... 172

Figura 109. Consumo de recursos por la aplicación al iniciar sesión. ............................ 172

Figura 110. Consumo de recursos por la aplicación al hacer un listado de información. 173

Figura 111. Recuento de: "Reportar un caso mediante la aplicación resulta" ................ 182

Figura 112. Recuento de: "Responder a un caso reportado mediante la aplicación". ..... 183

X

Figura 113. Recuento de: "Reportar una incidencia mediante la aplicación (inscribiendo,

archivando o removiendo) mediante la aplicación resulta" ............................................. 184

Figura 114. Recuento de: "Agregar información sobre la convivencia escolar pacífica a

través del formulario de la aplicación resulta" ................................................................ 185

Figura 115. Recuento de: "El tiempo de respuesta para iniciar sesión en la aplicación" 186

Figura 116. Recuento de: “¿En qué medida los datos (nombre, código u otro) que

permitan identificar a quién realizó un reporte de un caso son protegidos?” .................. 187

Figura 117. Recuento de: "El tiempo de respuesta para ver listados de casos o

incidencias en la aplicación es" ...................................................................................... 188

Figura 118. Recuento de: "El tiempo de respuesta para ver casos o incidencias a detalle

en la aplicación es" ........................................................................................................ 188

Figura 119. Recuento de: “¿Qué tanto la aplicación agiliza la consulta de casos e

incidencias respecto al proceso manual?” ..................................................................... 189

Figura 120. Recuento de: "¿La aplicación reduce el tiempo para reportar casos?" ........ 190

Figura 121. Recuento de: "¿La aplicación reduce el tiempo para responder a los casos o

incidencias de bullying y/o violencia escolar?" ............................................................... 190

Figura 122. Recuento de: "¿La aplicación reduce el tiempo para obtener un libro de

incidencias en formato electrónico?" .............................................................................. 191

Figura 123. Recuento de: "¿Compartir información sobre la convivencia escolar pacífica

mediante la aplicación en términos de tiempo es?" ........................................................ 192

Figura 124. Recuento de: "El tiempo de respuesta para ver información sobre la

convivencia escolar pacífica en la aplicación es" ........................................................... 192

Figura 125. Recuento de: "La consulta del listado de casos mediante la aplicación resulta

un proceso" .................................................................................................................... 193

Figura 126. Recuento de: "La consulta del listado de incidencias mediante la aplicación

resulta un proceso" ........................................................................................................ 193

Figura 127. Recuento de: "La consulta de la información sobre convivencia escolar

enviada por el área de psicología resulta un proceso". .................................................. 194

XI

INTRODUCCIÓN ........................................................................................................... XIV

CAPÍTULO 1. GENERALIDADES .................................................................................... 1

1.1 Situación problemática .......................................................................................... 1

1.2 Planteamiento del problema .................................................................................. 3

1.2.1 Formulación del problema ................................................................................. 3

1.3 Objetivos ............................................................................................................... 3

1.3.1 General ............................................................................................................. 3

1.3.2 Específicos ....................................................................................................... 4

1.4 Justificación ........................................................................................................... 4

1.5 Alcances ...............................................................................................................10

1.6 Limitaciones .........................................................................................................11

1.7 Hipótesis ..............................................................................................................11

1.7.1 Hipótesis general .............................................................................................11

1.7.2 Hipótesis específicas .......................................................................................11

CAPÍTULO 2. MARCO TEÓRICO ...................................................................................13

2.1 Antecedente de la Investigación ...........................................................................13

2.2 Bases Teóricas .....................................................................................................15

2.2.1 Violencia escolar ..............................................................................................16

2.2.2 Bullying ............................................................................................................17

2.2.3 Teléfono inteligente (Smartphone) ...................................................................21

2.2.4 Sistema operativo ............................................................................................23

2.2.5 Aplicaciones móviles de Android ......................................................................34

2.2.6 Requisito de Software ......................................................................................40

2.2.7 Base de datos ..................................................................................................41

2.2.8 Sistema de administración de base de datos (DBMS). ....................................46

2.2.9 Sistemas de bases de datos ............................................................................47

2.2.10 Proceso Unificado de desarrollo de software ..............................................49

2.2.11 Metodología de desarrollo orientado a objetos ...........................................54

2.3 Marco Legal..........................................................................................................57

2.3.1 Ley N° 29719: Ley que promueve la convivencia sin violencia en las instituciones educativas ............................................................................................58

2.3.2 Ley N° 28612: Ley que norma el uso, adquisición y adecuación del software en la administración pública. ..........................................................................................59

2.3.3 Ley N° 29733: Ley de protección de datos personales ....................................59

CAPÍTULO 3. MARCO METODOLÓGICO ......................................................................61

3.1 Variables ..............................................................................................................61

3.1.1 Variable Independiente ....................................................................................61

3.1.2 Variable Dependiente ......................................................................................61

3.2 Diseño de la investigación ....................................................................................61

XII

3.3 Población de estudio ............................................................................................62

3.4 Instrumentos de medición.....................................................................................63

3.4.1 Encuesta sobre dispositivos móviles y convivencia escolar .............................63

3.4.2 Cuestionario sobre la aplicación móvil .............................................................64

3.5 Recolección de datos ...........................................................................................67

3.6 Métodos y procedimientos de software .................................................................68

CAPÍTULO 4. DESARROLLO DEL PROYECTO DE SOFTWARE .................................72

4.1 Resumen ejecutivo ...............................................................................................72

4.1.1 Reseña ............................................................................................................72

4.1.2 Problemática ....................................................................................................73

4.1.3 Alcance ............................................................................................................74

4.1.4 Solución planteada ..........................................................................................74

4.2 Ámbito o Entorno ..................................................................................................81

4.3 Administración del proyecto ..................................................................................82

4.4 Modelo del negocio ..............................................................................................82

4.4.1 Modelo de Casos de Uso de Negocio ..............................................................83

4.4.2 Modelo de Análisis del Negocio .......................................................................84

4.5 Matriz de trazabilidad ...........................................................................................89

4.6 Requisitos .......................................................................................................... 101

4.6.1 Integración de los casos de uso y actores ..................................................... 101

4.6.2 Especificación de los casos de uso ................................................................ 106

4.7 Modelo de Análisis ............................................................................................. 118

4.7.1 Análisis de la Arquitectura .............................................................................. 118

4.8 Diseño y realización de los casos de uso ........................................................... 121

4.8.1 CUS-001 Iniciar sesión .................................................................................. 122

4.8.2 CUS-002 Cerrar sesión .................................................................................. 123

4.8.3 CUS-003 Reportar un caso ............................................................................ 125

4.8.4 CUS-004 Consultar casos .............................................................................. 126

4.8.5 CUS-005 Archivar caso ................................................................................. 128

4.8.6 CUS-006 Reportar una incidencia .................................................................. 129

4.8.7 CUS-007 Consultar incidencia ....................................................................... 132

4.8.8 CUS-008 Descargar libro de incidencias ........................................................ 134

4.8.9 CUS-009 Inscribir incidencia .......................................................................... 135

4.8.10 CUS-010 Archivar incidencia .................................................................... 137

4.8.11 CUS-011 Remover incidencia ................................................................... 138

4.8.12 CUS-012 Enviar datos .............................................................................. 140

4.8.13 CUS-013 Enviar información .................................................................... 141

4.8.14 CUS-014 Visualizar información ............................................................... 143

4.9 Modelo de Diseño .............................................................................................. 144

XIII

4.9.1 Capa de la vista ............................................................................................. 151

4.10 Implementación del prototipo .............................................................................. 161

4.11 Pruebas .............................................................................................................. 162

4.11.1 Pruebas unitarias ...................................................................................... 163

4.11.2 Pruebas de los servicios REST................................................................. 163

4.11.3 Pruebas instrumentadas ........................................................................... 166

4.11.4 Pruebas de estrés .................................................................................... 167

4.11.5 Pruebas de configuración ......................................................................... 167

4.11.6 Pruebas de rendimiento: CPU, RAM, redes, almacenamiento y batería ... 170

CAPÍTULO 5. ANÁLISIS COSTO - BENEFICIO ........................................................... 175

5.1 Presupuesto ....................................................................................................... 175

5.2 Tasa interna de rentabilidad (TIR) y valor actual neto (VAN) .............................. 178

5.3 Periodo de recuperación de inversión (PRI) ....................................................... 179

CAPÍTULO 6. RESULTADOS ....................................................................................... 180

6.1 Fiabilidad del instrumento de medición ............................................................... 180

6.2 Análisis de los resultados ................................................................................... 181

6.2.1 Adaptabilidad a los usuarios .......................................................................... 181

6.2.2 Rendimiento al usuario .................................................................................. 182

6.2.3 Facilidad para reportar ................................................................................... 182

6.2.4 Seguridad de la aplicación ............................................................................. 185

6.2.5 Consulta de reportes y visualización de información ...................................... 187

6.3 Validación de la hipótesis ................................................................................... 194

OBSERVACIONES ....................................................................................................... 199

CONCLUSIONES .......................................................................................................... 201

RECOMENDACIONES .................................................................................................. 203

Apéndices .................................................................................................................... 204

Apéndice A ................................................................................................................. 204

Apéndice B ................................................................................................................. 205

Apéndice C ................................................................................................................ 206

Apéndice D ................................................................................................................ 210

Apéndice E ................................................................................................................. 218

Apéndice F ................................................................................................................. 224

Apéndice G ................................................................................................................ 228

Apéndice H ................................................................................................................ 230

Apéndice I .................................................................................................................. 231

Apéndice J ................................................................................................................. 237

Apéndice K ................................................................................................................. 238

BIBLIOGRAFÍA ............................................................................................................. 247

XIV

INTRODUCCIÓN

El presente trabajo de investigación posee un enfoque correlacional-causal con uso de

instrumentos cuantitativos que busca establecer el impacto de una aplicación móvil en la

gestión de casos de bullying y violencia escolar en una institución educativa aplicando el

proceso unificado de desarrollo Rational (RUP), la programación en capas y utilizando las

ultimas herramientas tecnológicas en la programación Android (Android Jetpack).

En este ámbito la problemática que ocasiona la violencia escolar y el bullying en las

escuelas en nuestro país se incrementa con el paso de los años, lo cual se ve reflejado en

los informes nacionales e internacionales, siendo un mal que ocurre a nivel mundial. En

este aspecto diversas organizaciones mundiales recomiendan utilizar las TIC como un

medio para frenar su avance y concientizar sobre la convivencia escolar, que en un futuro

se ve reflejado en la convivencia ciudadana.

El caso que se analiza es de una institución educativa privada en la ciudad de Lima, en la

cual se llevó a cabo la implementación de un prototipo funcional de una aplicación para la

gestión de casos de bullying, obteniendo resultados que validan la hipótesis planteada.

Esta aplicación permite ingresar mediante un usuario que es el correo institucional del

miembro de la comunidad educativa y dentro de acuerdo con el cargo rol dentro de la

institución poder realizar diversas funciones como reportar casos de bullying hasta

visualizar información sobre la convivencia.

XV

Uno de los pilares de esta aplicación es la protección de datos que ofrece a los testigos o

víctimas de estos casos, pero manteniendo mediante un repositorio electrónico esta

información a fin de poder contrastarla si fuera necesario hacerlo.

Además, permite hacer un seguimiento por parte de coordinación y dirección de los casos

de bullying e incidencias que se han reportado, así como los descargos que dan los tutores

o psicólogos y ver las pruebas (imágenes) que estos adjuntan a sus reportes. Además,

generar un libro de incidencias electrónico.

Finalmente, la aplicación al permitir compartir información sobre la convivencia escolar y

generar el libro de incidencia electrónico favorece a la institución a cumplir con las

disposiciones que establece la ley 29719 “Ley que promueve la convivencia sin violencia

en las instituciones educativas”

Ante ello este trabajo de investigación detalla cada fase del desarrollo de la aplicación:

concepción, análisis, diseño, programación y pruebas, utilizando para ello diversos

programas de uso libre y con licencia empleando tecnologías novedosas como Android

Jetpack y el diseño y programación en capas siguiendo el patrón de diseño MVVM (Modelo

– Vista – Vista Modelo) que permite total independencia entre las capas de la aplicación y

volver al sistema en sí escalable a diversos lenguajes, adicionando portales web o de

escritorio e incluso modificaciones a la base de datos sin tener que alterar el código de la

aplicación, ya que la comunicación entre aplicaciones se hace mediante servicios Web

REST.

XVI

Una vez implementado el prototipo funciona se realizaron pruebas para conocer su

consumo de recursos, si es compatible con versiones antiguas de Android y si realiza lo

definido en la matriz de requisitos.

Luego los usuarios mediante demostraciones presenciales y virtuales manipularon la

aplicación y todas sus funcionalidades. Con ello, se aplicó un instrumento de medición

cuantitativo para determinar si el sistema influye de manera positiva o no en la gestión de

casos de bullying en la institución.

Finalmente, con la información obtenida se elaboraron conclusiones, observaciones y

recomendaciones que muestran como la implementación de una aplicación móvil puede

influir positivamente en el manejo de un proceso que se realiza por lo general de forma

manual en nuestro país.

1

CAPÍTULO 1

GENERALIDADES

El presente capitulo tiene por finalidad definir los objetivos en base al problema planteado

del presente estudio, justificar el estudio, definir los límites y alcances, así como la

metodología de la investigación.

1.1 Situación problemática

La convivencia escolar libre de bullying y/o violencia es un problema que presentamos a

nivel global. La violencia escolar se presenta en diversas formas y es causada por distintos

factores. Una de las carencias para combatirla es la falta de un sistema que permita su

recolección y tener la información disponible. (United Nations Educational, Scientific and

Cultural Organization [UNESCO], 2017)

En el Perú según informes del Ministerio de Educación (MINEDU), Ministerio de la Mujer y

Poblaciones Vulnerables (MIMP) y el Instituto Nacional de Estadística e informática (INEI)

los casos de violencia escolar o bullying han llegado a niveles alarmantes, estos indican

que aproximadamente el 75% de escolares sufre o ha sufrido de casos de violencia escolar

(Ministerio de Educación [MINEDU], 2017). Si bien se realizan campañas para su

prevención, se siguen dando los casos y las instituciones educativas aún mantienen

procesos tradicionales para registrar estos casos y darle tratamiento, los cuales son

relativamente tediosos y resultan complicados al no tener un repositorio que permita

realizar una consulta sencilla sobre los casos.

2

Dentro del Piloto de Evaluación Censal de Estudiantes - Cuestionario de convivencia

escolar 2013, realizado a 65 mil alumnos se detectó un nivel alarmante de violencia escolar

y esto generó diversas campañas para mitigarlo (WORLD VISION PERÚ, 2016).

Los medios de comunicación más eficientes como Internet han desencadenado también la

aparición del llamado cyberbullying (García et al., 2010). Este permite que los actos de

bullying y/o violencia puedan realizarse a través de las TIC utilizando dispositivos

electrónicos que permitan una conexión a internet, redes de telefonía celular u otras.

Las instituciones buscan métodos para frenar los casos y poder llevar un registro confiable

sobre los ya ocurridos, pero se topan por lo general con soluciones manuales y que resultan

en abultadas carpetas con documentos los cuales hacen complicada una búsqueda rápida

y eficiente de estos o un medio no muy confiable de almacenamiento de esta información.

Por esta razón las instituciones escolares en nuestro país buscan permanentemente

actualizarse y van creando desde sencillas tablas en Excel hasta complejos sistemas de

gestión de sus estudiantes, los cuales pueden ser utilizados como base para tener un

control y repositorio sobre los casos de bullying y/o violencia escolar.

La entidad educativa analizada en el presente estudio, donde la gestión de casos de

bullying y/o violencia escolar utilizan un procedimiento manual, se encuentra también que

las campañas de concientización sobre convivencia escolar son difundidas de la misma

manera a través de medios físicos como carteles, periódicos murales y en reuniones

presenciales con los miembros de la comunidad educativa teniendo de apoyo a las redes

sociales de la institución.

3

1.2 Planteamiento del problema

1.2.1 Formulación del problema

Problema general:

- ¿De qué manera el diseño e implementación de una aplicación móvil en el sistema

operativo Android mejora la gestión de reportes de casos de bullying y/o violencia

escolar en un colegio privado de Lima?

Problemas específicos:

- ¿Cómo influye el diseño e implementación de una aplicación móvil en el sistema

operativo Android en el tiempo de espera para reportar de casos de bullying y/o

violencia escolar?

- ¿El diseño e implementación de una aplicación móvil en el sistema operativo

Android para reportar de casos de bullying acoso y/o violencia escolar protege la

anonimidad?

- ¿Cómo influye el diseño e implementación de una aplicación móvil en el sistema

operativo Android en la facilidad de consulta de los reportes de casos de bullying

y/o violencia escolar?

- ¿Cómo influye diseño e implementación de una aplicación móvil en el sistema

operativo Android en la concientización sobre casos de bullying y/o violencia

escolar?

1.3 Objetivos

1.3.1 General

Diseñar e implementar un prototipo de una aplicación móvil en el sistema operativo Android

para gestionar de casos de bullying y/o violencia escolar de un colegio privado de Lima.

4

1.3.2 Específicos

- Diseñar e implementar un prototipo de una aplicación móvil en el sistema operativo

Android que reduzca los tiempos para llevar a cabo reportes de bullying y/o

violencia escolar de un colegio privado de Lima.


Android que brinde seguridad en los datos de quienes reporten casos de bullying

y/o violencia escolar de un colegio privado de Lima.


Android que permita consultar los de casos de bullying y/o violencia escolar de un

colegio privado de Lima.


Android para brindar información y concientizar sobre bullying y/o violencia escolar

de un colegio privado de Lima.

1.4 Justificación

Hoy en día muchos procesos manuales han sido automatizados teniendo como objetivo

agilizar, optimizar, dar mayor seguridad, etc. obteniendo una mejora sustancial. Además,

provee a la organización de un valor agregado frente a la competencia y sus clientes,

siendo para ello una de las herramientas actuales favoritas las aplicaciones móviles, dentro

de ese marco de referencia, se propone diseñar una aplicación móvil en el sistema

operativo Android la cual permita a los estudiantes de una institución, personal docente y/o

administrativo reportar los casos de bullying y/o violencia escolar de los que pueden ser

víctimas o testigos de manera segura y sencilla proveyendo de un entorno grafico

amigable. Asimismo, protegiendo la anonimidad, que es la principal causa por la cual las

víctimas o testigos no revelan que son víctimas o testigos de estos, a través de métodos

que permitan asegurar la identidad de quienes realizan los reportes para que quienes

5

reciban y procesen estos reportes puedan llevar a cabo las medidas correctivas para

ayudar de manera integral y eficiente a todos los involucrados. Además, apoyando a las

instituciones, en este caso la analizada, a tener un libro de incidencias, que es requerido

por la Ley 29719, con fácil acceso por medio de un sistema de base de datos y su

correspondiente aplicación móvil para hacer los reportes de las incidencias y luego servir

a los responsables y encargados en las tareas ya mencionadas.

Un punto importante que señalar es que desde hace ya varios años se ha venido

estudiando como los estudiantes y personas en general vienen haciendo uso de las

tecnologías de la información y la comunicación (TIC) para realizar actos de acoso y/o

violencia en el mundo entero, y este no es ajeno a las instituciones educativas, donde el

llamado cyberbullying viene causando graves estragos. Estudios españoles como el de

Cerezo (2012) nos menciona en su obra diversos estudios de casos ya analizados desde

el 2006. Asimismo, estudios brasileros recientes como el de sobre el uso de estrategias

para mitigar y prevenir el cyberbullying, los cuales señalan la importancia de la participación

de los diferentes miembros de la comunidad educativa y su entrenamiento en el manejo de

las TIC, así como el apoyo de profesionales en las escuelas (De Oliveira et al., 2017). Y en

caso de nuestro país se han llevado a cabo estudios de enfoque cuantitativo, que revela al

medio preferido para llevar a cabo actos de acoso por medios electrónicos, este es el

internet a través del uso de redes sociales, mientras el uso de mensajes de texto o llamadas

telefónicas es menor. (García et al., 2010). Como se puede apreciar estos casos vienen

ocurriendo durante muchos años y se ha estudiado desde sus inicios, se ha planteado

medidas correctivas y hasta determinado los canales más usado para llevarlos a cabo. Esto

demuestra la importancia que tiene el tema en diversos contextos y realidades incluyendo

la realidad peruana.

6

En el documento de trabajo “Era como ir todos los días al matadero...” realizado por

diversas entidades incluida la UNESCO en nuestra región y teniendo al Perú como uno de

los países dentro de este estudio, se analiza la reacción de los estudiantes que son testigos

frente a hechos como el bullying por razones de genero (considerando los modelos y

expectativas de cómo debe comportarse un varón o una mujer según los mismos

estudiantes) y se resalta del estudio realizado que la víctima no tiene muchas opciones

para hacer una queja o solicitar ayuda inmediata sin llamar la atención de los agresores o

ser detectada por ellos o su entorno. (Cáceres y Salazar, 2013). De ello, se deduce que se

necesita proporcionar un medio confiable y seguro tanto para los testigos como las víctimas

de manera que puedan recibir apoyo inmediato y de esta manera reducir el número de

casos, actuar como un medio de disuasión y que esta información recopilada de los casos

registrados pueda servir como materia prima para la creación de programas de prevención

y concientización de la comunidad educativa y la sociedad.

Actualmente en nuestro país existe un portal de reporte de casos de Bullying, el cual es

administrado por el MINEDU llamado: “Sí se ve”, el cuál arroja estadísticas muy bajas

(MINEDU, 2018) en comparación al Piloto de Evaluación Censal de Estudiantes –

Cuestionario de convivencia escolar del 2013 (WORLD VISION PERÚ ,2016) respecto al

número de casos de bullying y/o violencia escolar ocurridos. Los factores que influyen son:

la poca difusión del portal, su versión es solo para escritorio, no posee una aplicación para

los diversos sistemas operativos móviles y que esta es para todas las instituciones

educativas del país, donde los contextos de una ciudad y otra no son idénticos, incluso

dentro de un mismo departamento. Por ello, se propone la creación de un sistema en

particular para una institución educativa, adaptada a sus necesidades, visión y misión a fin

de cumplir con los objetivos de esta y el estado, puesto que cada institución educativa

incluso por sede dentro de una franquicia posee sus cualidades únicas y diferentes que

dependen del contexto y los integrantes en su comunidad educativa.

7

En los últimos años la proliferación de acceso a redes móviles a través de dispositivos

móviles en nuestro país ha ido aumentando considerablemente (Organismo Supervisor de

Inversión Privada en Telecomunicaciones [OSIPTEL], 2016). Por esta razón, el uso de los

teléfonos inteligentes en los escolares también ha aumentado y con ello la posibilidad de

usar esta poderosa herramienta que posee acceso tanto por teléfono como internet para

realizar actos de cyberbullying, lo cual no significa que debamos prohibirlos o censurarlos,

pues resultaría el remedio peor que la enfermedad, sino que en lugar de ello se puede

aprovechar las potencialidades que no permite este acceso a las redes móviles para la

creación de aplicaciones móviles que permitan administrar de manera confiable y eficiente

los registros sobre los casos de bullying o violencia escolar ocurridos en una institución

educativa de manera que permita mitigar estos actos y sobre todo prevenirlos. Asimismo,

utilizar estos mismos medios para concientizar a la comunidad educativa. En

consecuencia, es necesario también llevar a cabo todo un análisis minucioso para

automatizar un proceso por lo general manual como son el registro de las incidencias y las

consultas de estas, empleando las tecnologías de la computación móvil.

Para poder emplear de manera efectiva una aplicación móvil que nos permita cambiar esta

situación se deberá diseñar la estructura de un sistema que de soporte a la esta, lo cual

permitirá a la institución un control más eficiente de sus estudiantes, al área de psicología

tener un referente más para sus labores en identificación de los perfiles de los estudiantes

y a los estudiantes un medio que les permita sentirse seguros y tranquilos, sabiendo que

pueden dar un aviso rápido y confiable, pues el bullying ha sido y es aún causa de graves

daños psicológicos y sociales a los estudiantes

Es así importante proveer una herramienta que permita conservar la anonimidad de la

víctima y/o testigo y a la vez poderle brindar de forma rápida apoyo y soporte,

8

comunicándose con ella por canales que permitan hacer un proceso seguro para su

identidad dándoles una sensación de seguridad, pero que a la vez provea una forma de

detectar casos reportados fraudulentos. Incluso, se convierta en una alternativa disuasoria

en los potenciales agresores y permita llevar a cabo mejores planes de prevención y

concientización de la comunidad educativa.

Para la elección de la institución educativa donde se desarrolló el estudio, la necesidad

tecnológica que debemos tener en cuenta para llevar a cabo nuestro estudio hace

manifiesto que la mejor opción es un colegio particular de la ciudad capital Lima, donde la

mayoría de miembros de la comunidad educativa posee un dispositivo móvil, este hecho

que no fue asumido, sino consultado previo a iniciar el estudio mediante sondeos y

consultas a miembros de la comunidad educativa y dentro del estudio medido mediante un

cuestionario para validar dichas aseveraciones.

Para la elección del sistema operativo a usar tenemos que observar que nuestro país

atraviesa un auge en cuanto a la computación móvil, teniendo como principal expositor al

sistema operativo Android que según un reporte estadístico realizado por la compañía

comScore en su reporte Futuro Digital Perú 2014 muestra al sistema operativo Android

como el de mayor uso en nuestro país con más del 70% de dispositivos se resalta también

que quienes más utilizan estos dispositivos en nuestro país son personas entre los 15 y 24

años y tenemos un tiempo promedio al estar conectados a internet mayor que la media

mundial (comScore, 2014).

9

Figura 1.Evolución de los sistemas operativos en smartphones y tabletas. Adaptado de: StatCounter GlobalStats (2018)

Siguiendo las estadísticas sobre sistemas operativos para dispositivos móviles, podemos

apreciar en la figura 1 la evolución de los dispositivos Android frente a su competencia

directa que son los iOS y Windows para móviles en nuestro país, a los cuales lleva amplia

ventaja que se ha ido incrementando en los últimos años. (StatCounter GlobalStats, 2018).

Figura 2. Distribución de los dispositivos Android por versión. No se muestran versiones con una distribución inferior al 0,1%. Datos recopilados durante un período de 7 días desde el 01/01/2018 hasta el 08/01/2018. Adaptado de: Android (2018a)

72.30%

80.50%85.48% 87.33%

13.51% 11.10% 9.25% 9.11%

5.73% 4.33% 2.14% 1.08%0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

2015 2016 2017 2018

Años

"Android"

"iOS"

"Windows"

0.30% 0.40%1.70% 2.60%

0.70%

12.00%

5.40%

19.20%

28.10%

22.30%

6.20%

0.80% 0.30%0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

2.3.3 -2.3.7

4.0.3 -4.0.4

4.1.x 4.2.x 4.3 4.4 5 5.1 6 7 7.1 8 8.1

Po

rcen

taje

de

dis

po

siti

vos

Versiones de Android

10

En la figura 2 se muestra que las versiones de Android con mayor cantidad de dispositivos

hasta el año 2018 abarcan desde la versión 4.4 de Android llamada KitKat hasta la versión

8.1 llamada Oreo (Android, 2014)

Finalmente, el estudio está ligado al estudio de las ciencias informáticas, en este caso la

computación móvil, sistemas operativos e información, seguridad informática y diseño de

software y bases de datos.

De todo lo anterior podemos afirmar que el estudio sobre el diseño de una aplicación móvil

en el sistema operativo Android y su sistema de información son de suma importancia para

la gestión de los casos de bullying que ocurren en esta institución educativa mejorando la

calidad brindada y generará un precedente para estudios posteriores y desarrollo de

proyectos en diversas instituciones atendiendo los requerimientos de cada una de ellas en

particular.

1.5 Alcances

El presente estudio se desarrolló desde el mes de noviembre del 2017 hasta el mes de

junio del 2018.

Se llevó a cabo en un colegio privado de Lima metropolitana “Pamer - Salamanca” ubicado

en el distrito de Ate.

11

Contó con la participación de la comunidad educativa del colegio: docentes, personal

administrativo, padres de familia y principalmente alumnos de los grados de tercero, cuarto

y quinto de secundaria.

1.6 Limitaciones

En el presente estudio de investigación se presentaron las siguientes limitaciones:

- La solución planteada está orientada al sistema operativo Android, por ser el que posee

una mayoría casi absoluta en los miembros de la comunidad, aunque el análisis y diseño

puede servir de base para hacer la codificación, prototipo e implementación en otros

lenguajes para otras plataformas.

- La solución planteada llegará hasta la fase de prototipo funcional por motivos de

recursos económicos por parte del investigador y de personal que requeriría la

institución para llevar a cabo una implementación completa.

1.7 Hipótesis

1.7.1 Hipótesis general

Si se diseña e implementa una aplicación móvil en el sistema operativo Android. Entonces

mejorará la gestión de casos de bullying y/o violencia escolar de un colegio Privado de

Lima.

1.7.2 Hipótesis específicas

- El diseño e implementación de una aplicación móvil en el sistema operativo Android

reduce el tiempo para reportar casos de bullying y/o violencia escolar.

12


salvaguarda la identidad de quienes reportan casos de bullying y/o violencia

escolar.


facilita la consulta de los registros de casos de bullying y/o violencia escolar.


permite compartir información y concientizar sobre el bullying y/o violencia escolar.

13

CAPÍTULO 2

MARCO TEÓRICO

El presente capitulo tiene como finalidad describir los antecedentes a la investigación,

señalando mediciones realizadas por diversas entidades e investigadores sobre el bullying,

acoso y/o violencia escolar, luego describir las bases teóricas para tener un entendimiento

del porque son importantes, como han ido evolucionando e incluso aclarar ciertas

terminologías en el campo de las ciencias informáticas y conceptos relacionados a la

convivencia escolar. Finalmente describir el marco metodológico de la investigación y el

marco legal en cuanto a la convivencia escolar, como la adquisición de software para

entidades públicas, que usaremos como una referencia para el caso de la Institución

Privada que será objeto de estudio y sobre la protección de datos en las aplicaciones

informáticas.

2.1 Antecedente de la Investigación

La violencia escolar, acoso escolar o bullying han creado hoy en día una preocupación

alarmante por parte de padres de familia, docentes y autoridades en general al punto de

promulgarse el 2011 una Ley para la no violencia en la convivencia escolar (ley 29719),

pero esta ley al analizarla según las secciones que posee establecía ciertas normas

básicas que debían cumplir las instituciones educativas, que fueron posteriormente

modificadas el año 2012, de modo que la prevención de los actos de acoso, violencia y

bullying escolar es su principal prioridad.

Estudios realizados por la UNESCO, ONG y diversos medios de divulgación científica

muestran cifras en nuestra región como una de las que poseen índices más altos

14

(UNESCO, 2017) y dentro del Perú encontramos de manera similar niveles elevados de

estos (WORLD VISION PERÚ, 2016) y para ellos se han ejecutado proyectos para mitigarlo

como: “Campaña Basta de Bullying”, la cual trabajó en conjunto con el MINEDU y la

plataforma “Sí se Ve” durante 3 años para la concientización sobre el bullying, la

convivencia escolar sin violencia y acabar con la indiferencia de testigos de estos casos.

Oliveros y Barrientos (2007) realizaron estudios sobre una población de alumnos

pertenecientes a los dos últimos años de educación secundaria en un distrito limeño, donde

constataron que poco más de la mitad de los alumnos sufrieron en algún momento acoso

escolar o bullying, de este porcentaje la diferencia entre varones y mujeres es leve, siendo

las mujeres víctimas en menor cantidad y siendo la agresión verbal cercana al 40% y la

física en un porcentaje similar. Algo que hay que resaltar de este estudio son los datos que

arrojan sobre los testigos de los actos de acoso, violencia o bullying que en más de un 80%

no defendieron a sus compañeros.

Si bien el portal “Sí se Ve” sigue funcionando y brindando apoyo a las diversas entidades

educativas a nivel nacional (MINEDU, 2018), el número de reportes es menor a los casos

indicados según el Piloto de Evaluación Censal de Estudiantes – Cuestionario de

convivencia escolar (2013) (WORLD VISION PERÚ, 2016). A pesar de ello, es alarmante

la cantidad de casos que han recopilado durante sus 5 años de funcionamiento.

Durante el 2013 se realizó un estudio que agrupo al Perú, Guatemala y Chile, arrojando

para el caso peruano niveles alarmantes de bullying, dicho estudio de enfoque cuantitativo

examina la forma de comportamiento de los estudiantes, mostrando que tan vulnerable es

un estudiante a ser víctima por no cumplir con los modelos y expectativas del modelo tanto

masculino como femenino por parte de sus pares que se asemejan más a estos modelos.

También, se resalta la opinión de los estudiantes y docentes frente a estos

15

comportamientos, que muchas veces no son considerados serios (Cáceres y Salazar,

2013). En consecuencia, esta pasividad podría traer consecuencias muy negativas en las

victimas y seguiría perpetuando el nefasto modelo actual.

OSIPTEL (2016) realizó un reporte estadístico que muestra el crecimiento del acceso a

redes móviles por parte de los peruanos. Pese a ello, actualmente no existe una aplicación

móvil, tan necesaria debido a los cambios de estilo de vida del ciudadano peruano y los

escolares en cuanto al uso de tecnología, para tratar con el tema de bullying y/o violencia

escolar.

Existen diversas aplicaciones móviles en el sistema operativo Android que son poco

conocidas en nuestro entorno como Parental Click (la cual permite incluso obtener pruebas

legales de la violencia escolar o bullying según la normativa española), “Bullying

Semáforo”, “Stop!t”, “Know Bullying”, “Brave Up”, “My Mobile Watchdog”, “Bully Tag”,

“Anonymous Alerts”. etc. Las cuales permiten desde reportes muy completos hasta

simplemente proveer información para detectar o conocer sobre bullying, acoso y/o

violencia escolar. Ahora bien, no existe una aplicación móvil adaptada al sistema legal

peruano, el cual norma que las instituciones deben tener un registro de incidencias en estos

casos y proveer de información al inicio del año escolar (Ley 29719, 2011), ni a nuestro

contexto socio cultural y mucho menos a la realidad o contexto de cada institución

educativa. En el caso de la institución analizada en el presente estudio, esta realiza aún de

manera manual todo el proceso de registro y consulta.

2.2 Bases Teóricas

Para tener una mejor claridad del tema, el problema planteado y su contexto tecnológico

comenzaremos con la concepción del bullying y la violencia escolar, según diversos

autores y trabajos de investigación y luego con el contexto tecnológico.

16

2.2.1 Violencia escolar

Definir la violencia, dependerá en mucho del contexto donde se use, es en este sentido

que, la violencia se entiendo como: “Acción y efecto de violentar o violentarse” (Real

Academia Española [RAE], 2014, 23a ed.). Y si este concepto lo contextualizamos dentro

del entorno escolar se define a la violencia como: Poner a alguien en una situación que

implique el uso de la fuerza, física o moral; o hacer que se moleste o enoje.

Encontramos que definir violencia escolar resulta más complejo de lo que se piensa, tal

como menciona Castillo-Pulido (2011), donde en base a autores como Amaya y un informe

de la Organización Mundial de la Salud resalta que la definición de violencia depende

altamente del campo donde esta sea estudiada y así mismo una clasificación sobre la

violencia en 3 grandes campos:

Violencia autoinfligida: producida por uno mismo, como los pensamientos suicidas.

Violencia interpersonal: aquella ocurrida en entornos cercanos o una comunidad, como

el maltrato de pareja.

Violencia colectiva: aquella que basada en lo social o cultural justifica el uso de la

violencia contra otros, como las cruzadas llevadas por la iglesia.

De ahí podemos situar a la violencia escolar dentro de la violencia interpersonal que se

produce entre los miembros de esta comunidad y en los espacios donde se desarrollen

actividades escolares, aun cuando sean extracurriculares. (Castillo-pulido, 2011)

En base a lo anterior podemos definir a la violencia escolar como la acción violenta que

ejerce el agresor sobre la víctima, siendo ambos miembros de la comunidad educativa, en

17

un ambiente escolar o relacionado, y que puede tener o no espectadores, también

miembros de la comunidad educativa.

En los actos de violencia se pueden evidenciar tres personajes: la víctima o agredido que

es quien sufre la violencia por parte del agresor, el agresor quien ejerce violencia sobre la

víctima y los testigos o espectadores quienes son observadores o tienen conocimiento del

acto de violencia.

De lo anterior señalado Castillo-Pulido (2011), quien se basa en los estudios realizados por

Olweus, menciona que los espectadores podrían ser también una especie de agresores

pasivos, que no realizan el acto de violencia, sin embargo, no hacen nada por detenerlo o

son seguidores, o cómplices del agresor.

2.2.2 Bullying

El bullying llamado también acoso escolar (Castillo-Pullido 2011; Enriques y Garzón 2016)

o intimidación (Oliveros y Barrientos 2007; García et al, 2011) es considerado un actuar

frecuente por parte del agresor o agresores hacia la víctima o víctimas, a las cuales les

causa daño físico y/o psicológico de manera intencional.

El termino bullying como señalan Castillo-Pulido (2011), y Enriques y Garzón (2015)

proviene de los estudios de Olweus en Noruega por fines de los setenta donde el menciona

el mobbing que se entiende como el hostigamiento de una persona o grupo hacia otra

persona o grupo, posteriormente se realizaron estudios en diversos países y fue

apareciendo el actual, el cual se basa en la palabra bull en inglés, que significa toro, donde

el agresor o grupo agresor pasa por encima del agredido o grupo agredido como si fuera

una estampida. De esta forma se establece una relación de control y sumisión entre agresor

y víctima.

18

La diferencia entre la violencia escolar y bullying radica principalmente en la frecuencia con

la que se produce, cuando el acto de causar daño es poco frecuente o solo una vez, se

considera violencia o maltrato, pero cuando este se vuelve reiterado estamos frente a un

caso de bullying (Castillo-Pullido, 2011; Enriques y Garzón, 2016; García et al, 2011).

Dentro del ámbito escolar, podemos definir a la víctima de bullying como aquel miembro

de la comunidad educativa que es frecuentemente agredido de forma física y/o psicológica

por diversas razones como: vestimenta, idioma, raza, orientación sexual, etc.

En el caso de las formas de bullying encontramos: agresiones verbales y físicas (directa e

indirecta), amenazas y chantaje, exclusión de los grupos y acoso sexual. (Cerezo-Ramírez,

2012). Ahora bien, para autores como Rodríguez (2006), la importancia no radica en la

correcta traducción del término bullying, puesto que es una trivialidad frente al hecho de

que estos actos ocurren. En cambio, el principal objeto de estudio respecto a este debe ser

la forma cómo detectarlo, prevenirlo y mitigarlo.

Para ello es necesario saber las causas de que ocurran estos actos, Cerezo-Ramírez

(2012) señala las causas por las cuales se da este fenómeno y entre ellas menciona al

deseo de competencia del estudiante donde debe superar a otros y el bullying es utilizado

como el medio para alcanzar su objetivo. También, el deseo de afiliación en el cuál caen

mucho de los agresores pasivos al no defender a la víctima o brindar alguna ayuda, de

forma que ellos pueden sentirse como parte del grupo que consideran dominante. Inclusive,

el deseo de poder condicionar el actuar y pensar de los otros. Sin embargo, existen muchas

otras causas que pueden desencadenar estos actos y se necesita un trabajo integrador

entre los miembros de la comunidad educativa para erradicarlos.

19

Analizando a la víctima quien no sabe que es víctima al primer instante de estos actos,

pues recordemos es un acto recurrente, Rodríguez (2006) define tres fases donde la

víctima se identifica como tal. En principio, aparecen sobrenombres inocentes o actos que

podrían no ser considerados violentos u hostigadores por parte del agresor o la víctima,

pero la frecuencia hace que quien sufre de estos sea de alguna forma visto por el agresor

o grupo agresor como alguien a quien pueden someter o controlar, en esta fase los demás

miembros de la comunidad educativa que pueden ser testigos pasan a ser espectadores

muchas veces por temor a convertirse en la víctima. En la segunda fase, los actos que

parecían inocentes o que no causaban daño empiezan a hacerlo y genera confusión en la

víctima, es probable que aparezca el daño físico en esta fase según señala Rodríguez.

Finalmente, la última fase es la de aislamiento donde la víctima se encuentra angustiada,

sola y desconfiada, y es ahí donde su reacción es completamente inesperada.

De lo anterior podemos resaltar que las reacciones de las víctimas no se pueden evidenciar

a corto plazo, en muchos casos sobre todo el extranjero las víctimas han llevado venganzas

o actos contra los demás miembros de su comunidad en muchos casos mortales, pudiendo

convertir a los agresores en víctimas y también hemos visto los casos que causan daño

físico, el cual puede llegar a causar daño irreparable o la muerte a la víctima; y en casos

de daño psicológico, el suicidio.

Todos los miembros de la comunidad educativa están inmersos en esta problemática, si

bien existe el bullying entre iguales, es decir alumnos con alumnos, estos pueden escalar

a los diversos miembros de la comunidad educativa como docentes u otros miembros de

la comunidad a los estudiantes o viceversa. También, es importante entender los alcances

e implicancias que se ven día a día sobre los efectos o consecuencias a futuro no solo en

las victimas de bullying, sino también en los agresores.

20

En base a todo lo anterior podemos definir al bullying como un acto de violencia

interpersonal repetitivo por parte de un agresor o grupo agresor hacia una víctima o grupo

de víctimas, que forman parte de la comunidad educativa, dentro del espacio educativo o

extracurricular.

2.2.2.1 Cyberbullying

Varios estudios (López ,2017; De Oliveira et al., 2017; García et al., 2010) llaman al

cyberbullying como acoso cibernético, señalando además a este como una forma indirecta

de bullying a través de medios electrónicos (celulares, correo electrónico, redes sociales,

etc.). Asimismo, las TIC pueden ser utilizadas para estos fines.

Las características que posee adicionalmente a las del bullying son: a) el desarrollo es a

través de un medio virtual. Es decir, no tiene una interacción cara a cara necesariamente;

b) el agresor tiene la posibilidad de mantenerse anónimo, ya que puede crear cuentas

falsas para realizar el hostigamiento; c) utiliza diversos medios electrónicos o información

como fotos, videos, mensajes, etc. para utilizarlos con el objetivo de causar daño a la

víctima (López ,2017; De Oliveira et al., 2017; García et al., 2010).

Si bien parece ser simplemente una variante del bullying, este se torna mucho más

peligroso, pues puede exponer a la víctima no solo frente a los miembros de su comunidad

educativa, sino incluso frente a todas las personas con acceso a la información que se ha

utilizado para causar daño. Lo mencionado se evidencia en el caso de videos en la

plataforma YouTube o imágenes en redes sociales como Facebook. Esta exposición puede

causar un daño psicológico tan grave que podría provocar el suicidio o represalias con

consecuencias muy negativas para los involucrados.

21

Con base a todo lo anterior podemos definir al cyberbullying como una forma de realizar

actos de bullying a través de medios que trascienden los espacios físicos educativos y por

uso de diversas tecnologías de la comunicación como celulares, redes sociales, correo,

etc. donde la exposición de la víctima es mucho mayor.

2.2.3 Teléfono inteligente (Smartphone)

Un teléfono celular según la RAE es definido como: “un aparato portátil de un sistema de

telefonía móvil”. (2014, 23a ed.).

Meier (2009) indica que antes de la llegada de los teléfonos inteligentes los teléfonos

celulares tendían a ser transportables en los bolsillos, proporcionando mayor comodidad y

duración prolongada de la batería, menciona también que estos permitían llenar la

necesidad de estar conectados permitiendo comunicarnos sin la necesidad de una

conexión física alámbrica. Con el transcurso de los avances tecnológicos se fueron

incluyendo cámaras, grabadoras, etc. y llegando hoy en día a ser dispositivos muy

avanzados y prácticamente indispensables para el grueso de la población con acceso a

esta tecnología.

El teléfono inteligente llamado Smartphone en inglés tiene su origen en las computadoras

de bolsillo (handheld, hand-held computer o hand-held device) o PDA (Personal Digital

Assistant) los cuales son computadoras muy pequeñas que pueden ser transportadas muy

fácilmente en los bolsillos, de ahí su nombre, y realizaban funciones sencillas como bloc

de notas, libreta, calendario, etc. También contaban con acceso a redes inalámbricas como

Wi-Fi y ya habían incluido pantallas táctiles y sistemas de posicionamiento global GPS.

El término Smart en dispositivos electrónicos indica la diferencia entre un aparato

cualquiera y una computadora, es así como un teléfono es un aparato, mas no una

22

computadora, mientras un Smartphone o teléfono inteligente es una computadora al tener

un procesador, memorias y permitir ingreso y salida de datos.

Los teléfonos inteligentes fusionaron los computadores de bolsillo con los teléfonos

celulares, manteniendo diferencias en sus procesadores, los cuales hoy en día son mucho

más potentes para los teléfonos inteligentes, así mismo los teléfonos inteligentes utilizan

sistemas operativos más complejos en comparación de los PDA, asemejándose cada vez

más a una computadora de escritorio al permitir mayor ejecución de aplicaciones y

funciones. (Tanenbaum, 2009)

Cabe resaltar que los teléfonos inteligentes pueden conectarse a diversas redes

inalámbricas como LTE, 3G, Wi-Fi, bluetooth e incluso a las nuevas redes como Wi-Fi

Aware. Esta capacidad de conectarse a diversas redes e incluso servir como repetidores

de señal los hace altamente eficaces en términos de portabilidad y conectividad para el

usuario.

En cuanto a los componentes internos o hardware de los teléfonos inteligentes estos, como

se explica en la obra de Meier (2009) estos han venido reduciéndose en tamaño, pero

aumentando su potencia como el caso de los procesadores, memorias, etc. solo las

pantallas escapan a esta reducción de tamaño y peso. Así mismo han incrementado la

cantidad de periféricos y/o accesorios que poseen, se les puede agregar o usar en

conjunto. Tampoco podemos dejar de mencionar a su batería, la cual permite cada vez

mayor duración y se va optimizando su uso en los sistemas operativos.

En base a ello definiremos a los teléfonos inteligentes como computadoras con todas las

funcionalidades de un teléfono celular, es decir que posee dimensiones, peso y forma

prácticos para su transporte y conectividad.

23

2.2.4 Sistema operativo

El concepto el sistema operativo que es ampliamente estudiado por Andrew Tanenbaum

(2009) quién en su obra coloca al sistema operativo como el nexo o punto medio entre la

parte electrónica del computador y la interfaz gráfica que vemos en nuestras

computadoras, celulares inteligentes u otros dispositivos, y es así como su definición

depende de dos factores que no poseen una relación estrecha y dependerá si lo vemos

desde el hardware hacia el software que ve el usuario final o viceversa.

Se tiene entonces dos conceptos para el sistema operativo: el manejo de los recursos del

hardware de manera eficiente para ser usados por las aplicaciones y proveer al

programador de las diversas abstracciones (archivos, carpetas, etc.) que permiten trabajar

de forma armoniosa con el hardware del computador sin preocuparnos de las direcciones

reales expresadas en bytes y campos.

Figura 3. Los SO ocultan el hardware feo con abstracciones hermosas. Fuente: Tanenbaum (2009, p. 5)

24

Observando la figura 3 y según Tanenbaum (2009) podemos definir de dos formas al

sistema operativo dependiendo de donde lo veamos:

- Si lo vemos desde las aplicaciones hacia el hardware, el sistema operativo es el

encargado de proveer de los recursos llamados abstracciones como archivos o

carpetas, a los programadores, sin preocuparse de todo el proceso que ocurre entre

estos dos.

- Si lo vemos desde el hardware hacia las aplicaciones, el sistema operativo es el

gestor de todos los recursos de hardware que posea el computador para ser usados

por las aplicaciones que posea este, teniendo en cuenta el tiempo en que es usado

el recurso por una aplicación o varias y el espacio que usa una aplicación o varias

de un recurso.

Tanenbaum (2009) también realiza una clasificación de los sistemas operativos en base al

tipo de computadora para el cual están diseñados y lo podemos resumir de la siguiente

manera:

- Sistemas operativos de mainframe: la orientación de estos sistemas operativos es

el procesamiento de muchas tareas, cabe resaltar que los mainframes son

computadores enormes con capacidades abrumadoras en comparación con una

computadora de escritorio. Estos sistemas operativos permiten la ejecución de

miles de tareas en corto tiempo, en algunos casos sin intervención del usuario.

- Sistemas operativos de servidores: son sistemas operativos orientados

generalmente a almacenar páginas WEB y también a compartir recursos tanto

hardware como software dentro de una red.

25

- Sistemas operativos de computadoras personales y sistemas operativos de

multiprocesadores: ambos sistemas operativos están orientados hacia un usuario,

la diferencia radica en la cantidad de procesadores que poseen, siendo el

multiprocesador el cual trabaja con dos o más procesadores. Sobre esta notación

cabe resaltar que prácticamente hoy en día todos los computadores personales son

multiprocesadores.

- Sistemas operativos de computadoras de bolsillo: son sistemas operativos

diseñados para computadores de bolsillo, los cuales son pequeños en comparación

con un equipo de escritorio o portátil. Permiten actualmente la instalación y

ejecución de aplicaciones, asemejándose cada vez más a un sistema operativo de

computador personal. Estos sistemas están actualmente mucho más orientados a

las conexiones inalámbricas.

- Sistemas operativos integrados: son sistemas diseñados para aparatos, no

computadoras, que no aceptarán modificaciones o nuevas aplicaciones más que

las que vienen preinstaladas. Mucho más sencillos que los sistemas operativos

móviles o de computadoras personales. Generalmente son los que encontramos en

aparatos como lavadoras, hornos microondas, etc. se considera su principal

característica la de no permitir instalar nuevas aplicaciones por parte del usuario.

- Sistemas operativos de nodos sensores: son sistemas diseñados para redes de

sensores, donde esta red está compuesta de nodos (pequeñas computadoras) que

realizan procesos relativamente muy sencillos como mediciones o capturar alguna

información. Los sistemas operativos de nodos sensores se instalan en cada nodo

y no en la red de sensores, son además mucho más sencillos en comparación con

26

los integrados por las limitaciones del hardware y no permiten la instalación o

ejecución de aplicaciones luego de ser encendidos (deben estar previamente

precargados)

- Sistemas operativos en tiempo real: estos sistemas trabajan con el tiempo como su

parámetro, siendo su campo de acción los procesos industriales o aquellos que

tengan al tiempo como un factor crítico principal, además se subdividen en dos:

sistemas operativos en tiempo real duros y sistemas operativos en tiempo real

suaves, se diferencia uno del otro por la tolerancia que pueden tener en cuanto a

salir del rango de tiempo al que deberían trabajar o realizar una tarea siendo el

sistemas operativos en tiempo real duro intolerante a las fallas, mientras los

sistemas operativos en tiempo real suaves permiten que en ciertas ocasiones se

salga del rango de tiempo establecido. Al igual que los integrados, no permiten la

instalación de nuevas aplicaciones.

- Sistemas operativos de tarjetas inteligentes: son aquellos que encontramos en los

chips, como las tarjetas de débito con chip. Estos operan sobre un chip de CPU y

es activado generalmente al contacto con el lector. Son os sistemas operativos más

simples, y es debido a las grandes limitaciones en cuando a recursos de hardware

donde operan.

Durante los últimos años han aparecido también dispositivos como relojes inteligentes, los

cuales tiene un sistema operativo orientado para dispositivos corporales como Android

Wear.

En base a todo lo anterior definiremos al sistema operativo como el administrador de los

recursos de un computador y a la vez el proveedor de estos recursos a las aplicaciones

27

que crean los programadores y utilizan los usuarios. Asimismo, estos se subdividen de

acuerdo con el tipo de computador o aparato para el cual está orientado su uso.

2.2.4.1 Sistema operativo móvil

Un sistema operativo móvil es un sistema operativo de computadoras de bolsillo como

teléfonos inteligentes, PDA, etc. (Tanenbaum, 2009)

Meier (2009) menciona a los inicios de los sistemas operativos móviles en los cuales resalta

la necesidad de escribir código de bajo nivel por parte de los desarrolladores quienes por

esta razón debían tener conocimiento del hardware para el cual desarrollaban. Podemos

resaltar de esto que era un limitante, pues solo permitía la construcción de aplicaciones en

muchos casos para un solo dispositivo o de un solo fabricante.

Hoy en día el panorama es distinto, los sistemas móviles actuales permiten a los

desarrolladores la creación de aplicaciones, por lo general, sin la necesidad de emplear

código de bajo nivel y aprovechando los recursos de los que dispone el hardware según

las necesidades.

De esta manera podemos definir a un sistema operativo móvil como un gestor de los

recursos (cámara, tarjetas de red, pantalla táctil, grabador de sonido, CPU, memorias,

discos duros, etc.) del dispositivo móvil donde se encuentra instalado y proveedor de estos

recursos a las aplicaciones instaladas por el usuario y/o aplicaciones de fábrica

(calculadora, pantalla de inicio, etc.), así como una interfaz a los desarrolladores de las

mencionadas aplicaciones.

28

2.2.4.1.1 Sistema operativo móvil Android

Android que es un tipo de sistema operativo móvil, el cual posee las siguientes

características:

- Es de código abierto, es decir cualquiera puede descargarlo, hacer modificaciones

y utilizarlo como desee incluyendo fines comerciales para de esta manera no tener

un freno en la evolución e innovación del sistema operativo, así mismo la detección

de fallos es más veloz.

- Está basado en el núcleo LINUX, el cual también es un software de código abierto.

- Diseñado para adaptarse a diversos dispositivos que varían en cuanto a sus

dimensiones y forma, soportando diversas tecnologías de comunicación (SMS,

Bluetooth, Wi-Fi, LTE, etc.), multimedia (MP3, 3GP, WAV, JPEG, PNG, etc.) y

hardware que posea el dispositivo (cámaras de fotos y/o vídeo, pantallas táctiles,

GPS, acelerómetros, giroscopios, etc.)

- Permite la instalación de aplicaciones nativas programadas en el lenguaje Java o

Kotlin mediante el uso de máquinas virtuales como ART y, también, de aplicaciones

híbridas que usan HTML5, CSS y JavaScript.

- Orientado fuertemente al uso de redes inalámbricas.

Cabe resaltar que la principal fortaleza de Android es que se encuentra en casi todas las

marcas fabricantes de dispositivos móviles. De esa forma la evolución de Android ha sido

en cierta forma muy veloz y su difusión a través del mundo y el mercado peruano ha sido

prácticamente imparable.

En base a lo anterior, debemos aclarar que el sistema operativo Android instalado en un

dispositivo de una determinada marca puede ser muy diferente al instalado en otra, aunque

sean de la misma versión y es debido a que cada fabricante hace sus propias

29

modificaciones al sistema Android con el fin de obtener un valor agregado que los diferencie

de su competencia. Un caso peculiar es la desaparición de botones físicos en muchas

marcas, mientras que en otras no.

Con todo ello podemos definir al sistema operativo Android como un sistema operativo de

código abierto orientado a una gama diversa de dispositivos móviles, gestionando los

recursos hardware del dispositivo para su uso por parte de las aplicaciones y brindando las

interfaces necesarias para el desarrollo de aplicaciones que usen los diversos recursos

hardware del dispositivo.

El inicio de este coloso de los sistemas operativos se dio con la empresa Android Inc. el

2003 la cual tenía respaldo de Google y fue posteriormente comprada el 2005, luego de

ello aproximadamente dos años después se organiza una alianza llamada “Open Handset

Alliance” (Open Handset Alliance 2007) un conglomerado de fabricantes de software,

hardware y operadores de servicios en telecomunicaciones, siendo un total de 84

miembros, en aquella fecha el 5 de noviembre del 2007 se anuncia la primera versión de

Android 1.0 Apple Pie y a la vez liberando la mayor parte del código de Android, algo que

revolucionaría las innovaciones, estando los primeros dispositivos con este sistema

operativo listos al año siguiente, esta primera versión de este sistema operativo ya permitía

tener aplicaciones que daban acceso a páginas web, así como reproductores multimedia y

de YouTube, acceder a servidores de correo electrónico y sincronizar su cuenta de Gmail

(Correo electrónico de Google), soporte para la cámara del dispositivo y diversas

aplicaciones de fabrica; todo ello sumado a las funcionalidades de un teléfono celular.

Continuó el 2009 con su primera actualización, iniciando el proceso de mejora y solución

de errores y así sucesivamente encontrando un hito en la versión 1.5 la cuál introdujo la

posibilidad de incluir teclados virtuales y los Widgets (aplicaciones sencillas que permiten

30

acceder de forma más sencilla a una aplicación o ciertas tareas de una aplicación) de

terceros y siendo el primer dispositivo con pantalla táctil el HTC Magic. (HTC Corporation,

2009)

Sin embargo, el cambio más fuerte fue la versión 1.6 Donut el 2009, que permitía la

adaptación a prácticamente cualquier resolución de pantalla móvil, y la mejora del Android

Market (actualmente llamado Google Play) debido al incremento de aplicaciones de

terceros disponibles para Android. (Android, 2014).

A finales del 2009 se liberaría la nueva versión 2.1 Eclair que introducía la navegación por

GPS y Google Maps, la función de convertir texto a voz e incorporó soporte al HTML5.

(Android, 2014).

A mediados del 2010 se lanzó la versión 2.2 Froyo que permitía generar acciones a través

de la voz, de esta manera permitía llevar a cabo acciones hablando en lugar de utilizar la

pantalla táctil o botones. La otra innovación en los equipos con esta versión fue la

posibilidad de utilizar el teléfono como un Hotspot portátil que permite compartir los datos

móviles como una red 3G a través de Wi-Fi a otros dispositivos e incluye mejoras de

rendimiento utilizando un nuevo compilador llamado JIL (justo a tiempo, Just in Time en

inglés) que mejoro la performance del equipo en cuanto a consumo de CPU y además

incorporó mejoras al JavaScript para páginas web. (Android, 2014).

Luego de ello llego la versión 2.3 que traía soporte para la cámara frontal, mejoras en la

gestión de batería al controlar el uso que hacían las aplicaciones en ella y permitió a los

desarrolladores niveles de acceso mejorados a los gráficos, principalmente en 3D, para

potenciar el desarrollo de videojuegos más llamativos y adelantándose a la época incluyo

soporte a la tecnología NFC (tecnología que permite el intercambio de datos entre

31

dispositivos que compartan esta tecnología en una frecuencia elevada, hoy en día muy

usada en Google Wallet para realizar compras con solo acercar el dispositivo al lector.).

(Android, 2014).

Su siguiente versión la 3.0 tuvo su principal característica la compatibilidad con tabletas o

Tablet (dispositivo móvil similar a un Smartphone de mayores dimensiones) en inglés, en

muchos modelos se eliminó los botones físicos de Inicio, Atrás y Menú, pero fabricantes

como Samsung aún los mantienen. (Android, 2014).

En octubre del 2011 llega la versión 4.0 introduce el concepto de carpeta en la pantalla de

inicio, emulando a las carpetas en un escritorio de Windows donde dentro puede haber

más accesos a aplicaciones, soporte para compartir datos (música, aplicaciones, archivos,

etc.) mediante la tecnología NFC y un administrador de uso de datos móviles. (Android,

2014).

El 2012 se lanza la versión 4.1, que introduce Google Now (Un asistente inteligente de voz,

que brinda diferentes servicios), emulando una vez más a un sistema operativo de un

computador personal, se incluyó soporte para que varios usuarios pudieran compartir un

mismo dispositivo con Android, donde cada uno tiene personalizada su información.

(Android, 2014).

La siguiente versión 4.4, incluye diversos algoritmos que permiten mayor transparencia al

usuario, como el OK Google que mejora la ya anterior forma de dar órdenes al teléfono por

medio de la voz u marcadores inteligentes que dan prioridad a ciertos contactos o números

de acuerdo con nuestra interacción con ellos. Lo más resaltante de esta versión es el

ingreso de un nuevo entorno de aplicación llamado ART (Android Runtime) alternativo a

DALVIK (Máquina Virtual Dalvik), que reduciendo el número de veces que se compilaba

32

una aplicación permitía un ahorro de energía de la batería. (Android, 2017a). ART y DALVIK

son sistemas que permiten a Android ejecutar aplicaciones programadas en el lenguaje

JAVA. (Android, 2014).

Es en este punto el 2014, en la versión 5.0 donde Android se vuelve compatible con casi

cualquier dispositivo como: relojes, televisores, cámaras, computadores de automóviles,

etc., adaptándose a las diferentes pantallas y la posibilidad de sincronizar diversos

dispositivos que compartan el sistema operativo como relojes o vehículos, aquí aparecen

las variantes del sistema operativo Android como Android TV (Android, s.f.). Otro hito

importante es el soporte para sistemas de 64 bits y el reemplazo de DALVIK por ART para

poder ejecutar las aplicaciones. (Android, 2014).

Posterior a ello en el 2015 llega la versión 6.0 lo más resaltante es la capacidad de que sea

el usuario quien decida los permisos a conceder a una aplicación al ser instalada o posterior

a la instalación, cosa que no podía hacer antes (se han establecido 8 categorías de

permisos), adicional a ellos se realizaron mejoras en el ahorro de batería de los equipos

móviles. Cabe señalar que es la versión con mayor cantidad de equipos activos hasta el

momento. (Android, 2014).

El 2016 llegaría la versión 7.0 Nougat, la segunda más utilizada por dispositivos móviles

actualmente, habilita la posibilidad de tener dos aplicaciones al mismo tiempo, siempre y

cuando las aplicaciones lo permitan (poco usual en juegos), asemejándose a una pantalla

de escritorio de un sistema operativo de computadora personal. Se incluye asimismo la API

Vulkan para la mejora de gráficos y rendimiento en juegos, también mejores controles de

uso de batería, gestión de las notificaciones y siguiendo las innovaciones hechas por los

fabricantes Samsung se incorporó para todos los dispositivos Android el soporte nativo

para de realidad virtual. (Android, 2014).

33

La última versión lanzada es la 8.0 Oreo, donde la gestión eficiente de batería sigue siendo

una prioridad, el sistema operativo limita los recursos de los procesos en segundo plano

para el ahorro de batería en los dispositivos, incluye una nueva forma de tener en ejecución

dos aplicaciones al mismo tiempo llamada “picture-in-picture”, así como mejoras en la

navegación entre aplicaciones y una novedad es el soporte para la tecnología Wi-Fi Aware

(un tipo de conexión inalámbrica que permite conectarse entre diversos dispositivos con

esta tecnología sin la necesidad de estar dentro de internet o una intranet). (Android, 2014).

Actualmente se encuentra en gran variedad de dispositivos que no cumplen con la

característica de dispositivos móviles o computadoras de bolsillo (aquellos dispositivos que

pueden ser transportados de manera fácil por el usuario) como por ejemplo: televisores

inteligentes, el punto que debemos aclarar aquí es que esos dispositivos utilizan otro

sistema operativo que no está considerado dentro de los sistemas operativos para

computadores de bolsillo, uno de ellos es el llamado Android TV, el cual es un sistema

operativo similar a Android, pero diferente al no estar orientado a dispositivos móviles, sino

por ejemplo a televisores inteligentes o, también, dispositivos corporales como relojes

inteligentes utilizan Android, pero estos no usan el sistema operativo Android propiamente

dicho, sino otro llamado Android Wear (Android, s.f.).

Figura 4. Isotipo y logotipo de Android. Fuente: Android (2018a)

34

Tabla 1 Versiones de Android

Letra Nombre Versión

A Apple Pie 1

B Banana Bread 1.1

C Cupcake 1.5

D Donut 1.6

E Eclair 2.0 / 2.1

F Froyo 2.2

G Gingerbread 2.3

H Honeycomb 3.0 / 3.1 / 3.2

I Ice Cream Sandwich 4

J Jelly Bean 4.1 / 4.2 / 4.3

K KitKat 4.4

L Lollipop 5.0 / 5.1

M Marshmallow 6.0 / 6.0.1

N Nougat 7.0 / 7.1 / 7.1.2

O Oreo 8.0 / 8.1 Fuente: Android (2014)

Podemos decir así que Android y su integración a gran cantidad de dispositivos móviles y

no móviles demuestra la adaptabilidad de este sistema, esto debido al objetivo que se

planteó el proyecto Android que tiene como finalidad la de proveer de un sistema operativo

que cualquier fabricante o persona pueda utilizar, modificar, innovar y distribuir a fin de

evitar que unos eviten las innovaciones o cambios de otros. (Android, 2017b).

2.2.5 Aplicaciones móviles de Android

Según la RAE, se define a aplicación en el contexto informático como: “un programa

preparado para una utilización específica” (RAE, 2014, 23a ed.). Es decir, para realizar

determinadas tareas o procesos.

En este punto podemos decir que una aplicación es un programa como el procesador de

texto utilizado para la elaboración de un documento, un videojuego, aquel software que

permite editar fotografías o una calculadora online.

https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.0_Apple_Pie

https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.1_Banana_Bread

https://es.wikipedia.org/wiki/Android_Cupcake

https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.6_Donut

https://es.wikipedia.org/wiki/Android_Eclair

https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_2.2.x_Froyo

https://es.wikipedia.org/wiki/Android_Gingerbread

https://es.wikipedia.org/wiki/Android_Honeycomb

https://es.wikipedia.org/wiki/Android_Ice_Cream_Sandwich

https://es.wikipedia.org/wiki/Android_Jelly_Bean

https://es.wikipedia.org/wiki/Android_KitKat

https://es.wikipedia.org/wiki/Android_Lollipop

https://es.wikipedia.org/wiki/Android_Marshmallow

https://es.wikipedia.org/wiki/Android_Nougat

https://es.wikipedia.org/wiki/Android_Oreo

35

La RAE define a móvil como: “que puede moverse o se mueve por sí mismo” (RAE, 2014,

23a ed.). Teniendo en cuenta el entorno haríamos referencia a un dispositivo móvil, es decir

aquel dispositivo que podemos transportar.

Tanenbaum (2009) en su obra define a los dispositivos móviles como aquellos de fácil

transportación como: teléfonos celulares, agendas electrónicas de bolsillo, calculadoras de

mano, etc.

Santiago et al. (2015) hace referencias a una aplicación móvil como todo aquel programa

informático diseñado para su ejecución en dispositivos móviles.

Estas aplicaciones al igual que las de escritorio u otras, debe cumplir con ciertas

características de usabilidad por parte del usuario final, pues si el usuario final no es capaz

de manejarla o le genera demoras, esta aplicación pierde su utilidad, por ello es necesario

no solo evitar que la aplicación presente errores durante su ejecución, sino sea entendible

y amigable para el usuario.

En cuanto a la usabilidad de aplicaciones móviles Enríquez y Casas (2013) señalan que la

efectividad, eficiencia y satisfacción son los principales atributos en cuanto a la usabilidad.

En efectividad se refieren a la calidad de la respuesta que provee la aplicación frente a una

actividad o tarea que debe realizar, en cuanto a la eficiencia se toma en consideración

principalmente el tiempo que toma aprender a usar la aplicación, el tiempo de respuesta

de la aplicación ante determinados eventos o tareas y el esfuerzo que hace el usuario

(mientras menor sea este, la aplicación cumplirá mejor con sus objetivos) y el aspecto de

satisfacción que señalan los autores es muy subjetivo, pero lo podemos relacionar con las

actitudes que muestra el usuario al emplear la aplicación para la ejecución de una tarea.

36

Cabe mencionar que, durante su comparación entre aplicaciones de escritorio, sitios web

y las aplicaciones móviles; se amplían otros atributos a los tres ya mencionados para medir

la usabilidad en aplicaciones móviles, estos están relacionados al tema de seguridad,

portabilidad, contexto y facilidad de aprendizaje.

No se puede hablar de un instrumento único que mida todas estas variables en cuanto al

uso de una aplicación, puesto que cada aplicación apunta a sus propios objetivos. No

podríamos aplicar un cuestionario de usabilidad de un videojuego al uso de una aplicación

de ventas. En ese sentido Enríquez y Casas (2013) señalan puntualmente que el ambiente

para el cual está desarrollada la aplicación es fundamental como factor para medir la

usabilidad.

En cuanto a los sistemas operativos móviles y el contexto en el que se encuentran, se

puede decir que Android están íntimamente ligados a los teléfonos inteligentes y tabletas,

pero con la aparición de los llamados aparatos “Smart”, que no poseen las dimensiones

que una computadora de bolsillo, parecería que debemos ampliar su definición. Un ejemplo

son los televisores inteligentes llamados Smart TV en inglés los cuales son computadoras

en sí, pues poseen las características básicas de: CPU, memoria (RAM y/o ROM) y permitir

el ingreso y salida de datos, utilizan sistemas operativos inicialmente diseñados para

móviles al igual que los teléfonos inteligentes y permiten a diferencia de los sistemas

operativos integrados en televisores más antiguos instalar aplicaciones por parte del

usuario, pero estos sistemas operativos como por ejemplo Android TV no son sistemas

operativos móviles, son otro tipo de sistema operativo y por lo tanto las aplicaciones que

poseen son aplicaciones para el sistema operativo Android TV y no para el sistema

operativo Android que utilizan los smartphones.

37

Finalmente, desde esa perspectiva y en base a los conceptos del sistema operativo Android

podemos definir a una aplicación móvil en Android como un programa desarrollado para

ser utilizado en el sistema operativo Android y realizar determinadas tareas utilizando los

recursos hardware y conectividad a redes del dispositivo móvil donde es instalado.

2.2.5.1 Aplicaciones nativas e híbridas

Las aplicaciones móviles se pueden clasificar en nativas e híbridas. Las aplicaciones

nativas son aquellas desarrolladas específicamente para un sistema operativo móvil, en el

caso de Android estas aplicaciones nativas son construidas en los lenguajes de

programación nativos Java y Kotlin, mientras que para iOS son Objetive C y Swift. En

cambio, las aplicaciones híbridas son aquellas que son desarrolladas para cualquier tipo

de dispositivo independientemente de su sistema operativo, se utiliza generalmente HTML5

con JavaScript para su construcción en combinación con otros programas y/o librerías

como: CordovaJS, Iconic, Xamarin, etc.

Dos expertos en desarrollo móvil llevaron a cabo un extenso debate sobre las aplicaciones

híbridas versus las aplicaciones nativas (Batanero y Sesma, 2017) y el informe del XVIII

Congreso Argentino de Ciencias de la Computación CACIC en el 2013 (Delia, Galdamez,

Thomas y Pesado, 2013), tratan sobre las diferencias, ventajas y desventajas que

presentan las aplicaciones nativas, entre sus características tenemos que estas permiten

aprovechar al máximo los recursos hardware del dispositivo, puesto que trabajan con API

(subrutinas, funciones y métodos) nativas en comparación con otros tipos de aplicaciones

móviles que requieren de complementos adicionales para obtener acceso y hacer uso de

los recursos tratando de asemejarse a una aplicación nativa, las aplicaciones compilan a

través de sus máquinas virtuales (ART para Android), lo cual acelera su tiempo de

ejecución en comparación con otros tipos de aplicaciones móviles que tiene otra máquina

virtual sobre la cual se ejecutan y uno de los puntos importantes es el consumo de batería

38

y memoria el cual resulta más eficiente en las aplicaciones nativas que en otros tipos de

aplicaciones al estar diseñadas para las arquitecturas donde son instaladas, permitir la

ejecución de tareas en segundo plano sin necesidad constante de ejecutarse y usar

recursos del CPU del dispositivo, la desventaja más marcada que presenta es que para

cada plataforma donde se desee implementar la aplicación, se debe construir la aplicación

en su propio lenguaje, generando costos adicionales en las fases posteriores al diseño.

2.2.5.2 Android Jetpack y la arquitectura de componentes

En el marco del desarrollo de aplicaciones móviles nativas, el IDE Android Studio ha

implementado lo que ellos llaman la arquitectura de componentes para Android con el

nombre de Android Jetpack, que tiene como principal misión la de simplificar el desarrollo

de aplicaciones. Además, orientación sobre el desarrollo como el uso de una arquitectura

Clean donde existe una marcada separación de capas, evolucionando el llamado Android

Clásico y MVC a patrones de diseño como MVP y MVVM. (Android, 2018b)

Este conjunto de componentes ofrece compatibilidad con versiones anteriores de Android,

el lenguaje Kotlin, archivos DEX y para pruebas. (Android, 2018b)

La arquitectura de componentes se puede relacionar con la obra de Robert C. Martin sobre

la arquitectura Clean. Según Martin (2017) la arquitectura de software debe permitir a los

equipos de desarrollo trabajar de forma eficiente no solo durante las primeras etapas de

vida del software, sino al ir más allá del desarrollo e implementación, específicamente en

el mantenimiento del producto, a través de la separación de capas: los datos, los

controladores y las interfaces gráficas se vuelven independientes. Esta separación según

Martin permite no solo mejorar la calidad y facilidad de las pruebas en el programa, sino

volverlo prácticamente independiente del dispositivo donde se ejecute.

39

El ciclo de vida del software luego de su lanzamiento suele ser el más costoso y que genera

una enorme carga en cuanto a recursos para lanzar nuevas versiones o adaptarse a

nuevos entornos, por lo que mediante la encapsulación de capas se puede generar un

mantenimiento del software más eficiente reduciendo costos y maximizando la producción.

La arquitectura de componentes en Android en este punto recomiendo el uso del patrón de

diseño MVVM (model – view – view model).

Para ello, debemos entender que un programa se separa en capas, porque en cada una

de ellas se encontrará un lenguaje preponderante, por ejemplo, en la capa más cercana a

los datos (capa de persistencia o modelo) el lenguaje preponderante, por lo general, es

SQL. En la capa de la vista dependiendo de la aplicación puede ser HTML si fuera web,

XML para Android, etc. y entre ambos existe una capa que hace de intermediario

(controlador, presentador, vista modelo, etc.) entre los datos y las vistas, en esta capa el

lenguaje preponderante es en el cuál es desarrollada la aplicación. Esta separación por

capas permite tener un código ordenado, fácil de entender y escalable en el tiempo. Para

el caso del patrón de diseño MVVM, la capa model se encarga de los datos siendo estos

de la base de datos propia del sistema u obtenida de una fuente externa (cloud data,

servidores, etc.), la capa view contiene todas las interfaces gráficas (actividades y

fragmentos) que deben contener la mínima lógica del negocio posible y la capa view model

que es un intermediario entre ambas capas, es aquí donde se maneja el ciclo de vida de la

capa view.

Jetpack provee para ello las funcionalidades de LiveData que junto con la librería

DataBinding permiten evitar código repetitivo y tedioso en la capa de la vista,

específicamente cuando la actividad o fragmento cambia de estado. Cabe resaltar que

DataBinding tiene una especie de puente entre las capas de model y view.

40

En cuanto a la navegación entre actividades o fragmentos, Jetpack provee de la

funcionalidad llamada navigation que mediante un archivo XML permite establecer una

secuencia de estas, incluso enviando datos a través de las distintas vistas (una de estas

es usando SafeArguments) y maneja las animaciones entre transiciones.

2.2.6 Requisito de Software

Muchas veces la traducción incorrecta de requirement es interpretado como requerimiento,

cuando la traducción correcta de requirement es requisito, mientras requerimiento es

request en el idioma inglés, y aunque se suele usar ambos términos de manera coloquial

para referirse a los requisitos de un software, debemos tener claro que son dos conceptos

distintos, no son siquiera sinónimos. Según la RAE se define al requerimiento como: “la

acción y efecto de requerir” (RAE, 2014, 23a ed.). Es decir, de necesitar algo.

En el campo de las ciencias informáticas cuando se habla de requerimientos de un sistema

o software, no se habla de acciones, sino exigencias para el normal funcionamiento de un

programa o sistema operativo en cuanto al hardware.

Sobre la traducción correcta de software requirement, la traducción correcta sería requisito

de software, y para definirlo en el contexto de la ingeniería de software podemos mencionar

a la definición brindada en el IEEE Standard Glossary of Software Engineering

Terminology, según el cual un requisito se define como:

(1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A document representation of a condition or capability as in (1) or (2). (The Institute of Electrical and Electronics Engineers [IEEE], 1990, p. 62)

41

En la primera condición encontramos que define al requisito como aquello que necesita el

usuario para obtener el resultado deseado, mientras en la segunda parte menciona que

esta necesidad debe poseer las características en cuanto a límites y alcances del proyecto

a desarrollar para lograr los objetivos deseados y finalmente en el último punto menciona

que un requisito puede ser cualquier representación que cumpla con alguna de las

definiciones previas.

Wiegers y Beatty (2013) mencionan primero a los requisitos de información estableciendo

tipos y niveles de estos como: requisitos del negocio, reglas del negocio, restricciones,

atributos, etc. y subdividiendo los requisitos de acuerdo con su importancia y ubicación

para el proyecto de desarrollo. De esta manera señalan que los requisitos de software son

todas aquellas características o funcionalidades que deben ser implementadas y describen

en el sistema como y que tan bien debe ejecutarse considerando las restricciones del

negocio, usuario y del mismo sistema.

En base a todo lo anterior podemos definir a los requisitos de software como todas aquellas

condiciones, restricciones y capacidades (funcionalidades) que tiene un programa

informático para lograr alcanzar los objetivos planteados por el cliente.

2.2.7 Base de datos

Para definir una base de datos, es preciso definir primero que es un dato dentro del

contexto de la ingeniería de software. Para ello, recurriremos al: IEEE Standard Glossary

of Software Engineering Terminology: “A representation of facts, concepts or instructions in

a manner suitable for communication, interpretation or processing by humans or by

automatic means.” (IEEE, 1990, p. 23)

42

Esta definición nos permite vislumbrar a los datos en el plano computacional como un

hecho conocido, el cual es representado de forma tal que permite llevar a cabo un

procesamiento de estos para alcanzar diversos objetivos planteados. Un ejemplo sencillo

de dato es la edad de una persona o el número de DNI, pues son hechos conocidos que

pueden ser procesados para diversos objetivos como cálculo de fecha de nacimiento o

permitir registrarse en una página web que obliga al usuario a ser mayor de edad.

Haremos una distinción entre dato e información, considerando a la información la

interpretación de un dato o grupo de ellos por parte de los usuarios. Respecto a este punto

algunos autores como Date (2001) tratan ambos términos como sinónimos para simplificar

lo explicado en su obra, pero hace reconocimiento explícito a que es importante entender

esa diferenciación y aclararla antes de hablar de información y datos.

Date (2001) menciona que los datos dentro de una base de datos serán: integrados y

compartidos, eliminando la redundancia de los datos y permitiendo el acceso a múltiples

usuarios para los diversos fines que posean.

En base a la definición de datos, se puede ir aclarando el concepto de una base de datos

como una colección de datos que poseen una relación entre ellos. (Elmasri y Navathe,

2007). Asimismo, Date (2001) menciona que los datos encontrados en una base de datos

deben ser persistentes. Es decir, tener una duración no efímera y relevante para los

objetivos que fue diseñada la base de datos.

Pero una base de datos debe cumplir además con otras características como las señaladas

en la obra de Elmasri y Navathe (2007):

- Representa algún aspecto del mundo real, de modo que los cambios ocurrido en el

mundo real se reflejan en la representación de la base de datos.

43

- Es una colección de datos relacionados de manera lógica con algún tipo de

significado, por lo tanto, un conjunto de datos aleatorios no forma una base de

datos.

- La creación y diseño de la base de datos atiende a objetivos, es decir será objeto

de uso de usuarios y aplicaciones que utilicen la base de datos para determinados

propósitos.

El nivel de complejidad de una base de datos no tiene un límite y está determinado por la

representación del mundo real a la cual atiende y lo que se pretende lograr en base a ella.

Al ser una colección de datos, están ocupan espacios de memoria que dependerán de la

cantidad de registros que posea la base de datos, el tipo de datos que serán almacenados,

por ejemplo el tamaño necesario para almacenar texto plano es mucho menor que el

necesario para almacenar archivos multimedia como videos o audio y así mismo, el número

de datos almacenados determinará su tamaño, el cual no tiene un límite y puede ser tan

pequeña como una lista de deberes en Excel o Access por parte de una persona o tan

extensa como la información de todos los habitantes del Perú, que tiene almacenado el

Registro Nacional de Identidad y Estado Civil (RENIEC).

Ahora bien, cabe señalar que una base de datos puede ser una lista escrita o

computarizada, para efectos del análisis en el campo de la Ingeniería de Software,

consideraremos las bases de datos computarizadas.

Las bases de datos hoy en día se encuentran también evolucionando, en ese sentido

apreciamos la aparición de bases de datos no relacionales, para entender su diferencia

con las bases de datos relacionales es importante analizar a las bases de datos

relacionales primero. Partimos con Chen (1976), quien estableció el modelo entidad

44

relación, a través de un estudio donde genero un modelo que sacaba la ventaja de tres

modelos ya existentes, entre ellos el modelo relacional de Edgar F. Codd, mediante su

representación se puede establecer las relaciones que existen entre los datos de un

sistema, su modelo ha sido ampliamente estudiado y ello ha conllevado a la mejora y

refinamiento del modelo que planteó Chen en su inicio. (Luque, Gómez-Nieto, López y

Cerruela, 2001)

Edgar Codd fue quien planteó el modelo relacional que tiene sus bases en la teoría de

normalización de relaciones, este modelo al igual que el modelo de 1976 de Chen tiene

como objeto la representación o abstracción del mundo real, de manera que sea posible

una comprensión de las relaciones entre los diversos objetos que componen el contexto

analizado, las características de este modelo permiten esquematizar el problema dando

paso a una fácil comprensión por parte de personas sin entrenamiento en informática del

este, la capacidad de escalabilidad de estos esquemas sin dañar la lógica ya existente y

una adaptación frente a los escenarios esperados e incluso aquellos no previstos. Lo más

destacado del modelo relacional es la normalización de relaciones, que permite eliminar

las redundancias de manera que se obtiene un mayor espacio de almacenamiento y a la

vez mitiga los problemas de integridad de la información de esta manera facilita las

posibilidades de escalabilidad de la base de datos, así como su desempeño, de este

modelo nacen las bases de datos relacionales que utilizan el lenguaje SQL, el cual permite

definir o establecer las estructuras de las bases de datos, las consultas y modificaciones a

los datos almacenados y administrar el acceso a los datos de la base de datos. Además,

las bases de datos relacionales utilizan identificadores primarios y foráneos que permiten

que las tablas contenidas se relaciones entre sí y aplicar la normalización, en cuanto a las

operaciones que realiza estas se sujetan a la atomicidad de manera que se ejecutan por

completo o no lo hacen (dentro del código SQL se le llama rollback). (Luque et al., 2001;

Redmond y Wilson, 2012)

45

El modelo de bases de datos relacionales no es el único que existe actualmente, desde

hace más de una década han venido emergiendo alternativas, en este sentido se han

venido difundiendo las bases de datos no relacionales o llamadas NoSQL, estas bases de

datos se caracterizan por: soportar la computación distribuida de forma que la base de

datos se aloja en múltiples ordenadores en lugar de un solo servidor, permiten hacer

modificaciones a la base de datos mientras esta sigue estando activa sin necesidad de

tener que detener los procesos para llevar a cabo un proceso de escalabilidad; pero a ello

se le suman también los inconvenientes del uso de estas, donde encontramos: una falta

de estandarización lo cual no ocurre con las bases de datos relacionales, la variedad

existente de bases de datos noSQL como: MongoDB, Riak, CouchDB, etc. trabajan con

distintos lenguajes de consulta y resulta complicado hacer la migración entre ellos

(Redmond y Wilson, 2012).

Tenemos dentro del grupo que no sigue el modelo de las bases relacionales a las bases

de datos orientadas a grafos como Neo4J, que han sido implementadas por múltiples

empresas de gran envergadura y representan un futuro prometedor para la bioinformática,

al permitir respuestas mucho más rápidas que los otros modelos al tratar a las relaciones

entre las tablas como grafos y permitir recuperar información de grandes volúmenes de

datos de manera más eficiente. (Have y Jensen, 2013; Redmond y Wilson, 2012), al

respecto se hizo una prueba en el campo de la bioinformática (Have y Jensen, 2013) sobre

el tiempo de respuesta de una base de datos relacional versus una base de datos orientada

a grafos en donde se llevó a cabo un análisis de tiempos de respuesta frente a un volumen

inmenso de interacciones, de manera que la base de datos orientada a grafos tuvo un

rendimiento muy superior frente a la base de datos relacional, pero se destaca del estudio

que la complejidad de la consulta es el elemento diferenciador entre la elección de una

base de datos orientada a grafos.

46

El largo tiempo que poseen las bases de datos relacionales frente a las otras genera una

ventaja en cuanto a conocimiento de esta y la reducción de costos al usarla frente a sus

contrarias, teniendo a disposición una cantidad enorme de alternativas en cuanto a

gestores de bases de datos y personal calificado para estas.

Con base a lo analizado podemos definir a una base de datos como una agrupación de

datos relevantes almacenados en medios electrónicos que permiten una representación de

un aspecto de la realidad a través de aplicaciones diseñadas para hacer uso de los datos

que estas contienen consiguiendo los objetivos establecidos por los usuarios, ambas

características definirán su nivel de complejidad y tamaño.

2.2.8 Sistema de administración de base de datos (DBMS).

Un sistema de administración de base de datos o DBMS (database management system)

son un conjunto de programas informáticos cuya función principal es la de crear y mantener

bases de datos a los usuarios. (Elmasri y Navathe, 2007)

Haciendo una analogía a un sistema operativo que actúa como nexo entre los

componentes de hardware y el software, un DBMS cumple una función similar, al permitir

que los datos almacenados de forma física en un dispositivo de almacenamiento sean

accedidos por los usuarios. También, Date (2001) sitúa al DBMS como una capa entre la

base de datos física y el usuario.

Elmasri y Navathe (2007) nos indican la complejidad con que estos sistemas están

elaborados, permitiendo principalmente: definir, construir, manipular y compartir bases de

datos entre diversos usuarios y programas informáticos o aplicaciones.

47

Es importante recalcar la diferencia entre una base de datos, que es la colección de datos,

y un DBMS que es en sí un conjunto de programas que permiten que los usuarios

manipulen la base de datos.

Con ello podemos definir que un Sistema de administración de base de datos (DBMS), es

un conjunto de programas informáticos complejo que permite a los usuarios crear,

manipular, compartir y dar mantenimiento a las bases de datos a través de diversos

programas informáticos.

2.2.9 Sistemas de bases de datos

Teniendo como base los conceptos de bases de datos y sistemas de administración de

base de datos. Podemos comenzar a hablar de un sistema de bases de datos, en el cual

aparecerán involucrados: datos, hardware, software y usuarios. (Date 2001)

Se tiene a los datos que son la materia prima de un sistema, el hardware es conformado

por todos los componentes electrónicos que permiten el almacenamiento físico de los datos

como: procesadores, memorias, volúmenes de almacenamiento, periféricos,

controladores, etc., el software contempla de manera principal al DBMS, descrito

anteriormente y por último a los usuarios, quienes son los principales interesados en

interactuar con este sistema.

Date (2001) menciona a tres tipos de usuarios: los programadores, los usuarios finales y

los administradores de base de datos; son los programadores y usuarios finales son

quienes interactúan con los datos almacenados, siendo los programadores quienes

generan aplicaciones en lenguajes de alto nivel para que los usuarios finales puedan tener

acceso, consulten y/o manipulen a las bases de datos, pero los administradores de base

48

de datos o DBA (database administrator) son los encargados de la creación de la base de

datos y la implementación de medidas para el funcionamiento correcto del sistema.

En cuanto a las medidas para el correcto funcionamiento, se puede hablar de asignar

usuarios, preparar procedimientos almacenados, disparadores, configurar el cotejamiento

del lenguaje de entrada (muy importante para dar un soporte óptimo a idiomas que añaden

letras o símbolos como las tildes o la letra eñe), la creación de la base de datos (incluyendo

nombres de tablas, claves primarias, relaciones, etc.) y demás medidas.

Figura 5. Entorno de un sistema de bases de datos simplificado. Fuente: Elmasri y Navathe (2007)

Usuarios/Programadores

Programas de aplicación/Consultas

Software para procesar consultas/Programas

Software para acceder a los datos almacenados

Definición de la base de datos almacenada (metadatos)

Base de datos almacenada.

Software DBMS

Sistema de bases de datos

49

En la figura 5, se puede apreciar cómo funciona a grandes rasgos un sistema de bases de

datos y los diferentes niveles que posee, observándose que este se asemeja a un sistema

para almacenar registros y hacer uso de ellos posteriormente mediante consultas,

modificaciones, etc. la definición de los datos (como ejemplo un diccionario de datos) son

los llamados metadatos, mientras los datos como: edades, nombres, direcciones URL, etc.

son los que componen la base de datos almacenada, estos son consultados por

aplicaciones externas a la base de datos a través del software del DBMS.

Con todo ello definiremos a un sistema de base de datos como el acoplamiento entre una

base de datos computarizada y una capa de software llamada DBMS, que les permiten a

los usuarios acceder a los datos y modificarlos para conseguir los objetivos planteados por

la entidad a la que corresponda el sistema.

2.2.10 Proceso Unificado de desarrollo de software

Como su nombre menciona es un proceso, el cual tiene la finalidad de convertir los

requisitos del usuario en una solución informática, mediante diversas actividades que

garantizarán un análisis y diseño a través de casos de uso que son quienes guiarán

posteriormente el desarrollo, implementación y pruebas del software para su posterior

mantenimiento en el tiempo. Todo ello haciendo uso de un enfoque iterativo e incremental

que permite reducir costos y tiempos en el desarrollo del proyecto. (Jacobson, Booch, y

Rumbaugh, 1999)

El proceso más extendido y que posee un mayor estudio y mejoras es el Proceso Unificado

de Rational (RUP), el cual es un proceso de desarrollo de software llevado a cabo y

mantenido por la marca registrada de IBM, Rational Software, de la cual resalta como su

punto fuerte la documentación del software. (Kruchten, 2003)

50

RUP ha sido actualizada y refinada durante muchos años y mediante múltiples aportes,

dentro del RUP lo que prima es la relación entre el proceso unificado con el lenguaje de

modelado unificado (UML), que permite una estandarización del proceso apoyándose de

la definición y asignación de roles y tareas al equipo de desarrollo del software. (Jacobson

et al., 1999; Kruchten, 2003)

De forma que RUP comparte todas las características del Proceso Unificado de desarrollo

de software, apoyándose en el software Rational.

Figura 6. Proceso de desarrollo de software. Adaptado de: Jacobson et al. (1999).

Un proceso de desarrollo de software engloba a todas las actividades que hacen posible

transformar los requisitos de un usuario en un software que satisfaga estos requisitos,

como apreciamos en la figura 6.

Las principales características del Proceso Unificado de desarrollo de software (Jacobson

et al., 1999):

- Está orientado por los casos de uso, está centrado en la arquitectura del sistema y

es iterativo e incremental.

- Posee cuatro fases bien definidas: inicio, elaboración, construcción y transición que

se relacionan con cinco flujos de trabajo fundamentales: requisitos, análisis, diseño,

implementación y prueba.

Requisitos del cliente

Proceso de desarrollo

Solución informática

51

- Orientado a una gama extensa de tipos de proyectos en cuanto a tamaño,

complejidad, áreas de aplicación y tipos de organizaciones.

- Está basado en componentes, generará gran cantidad de entregables en sus

diversas fases de acuerdo con el tipo de proyecto, utilizando el UML.

- Su finalidad es la de permitir una gestión eficiente para la producción de software

de buena calidad con un costo apropiado.

Este aporta al desarrollo de software las pautas y guías para trabajar de forma coordinada

en la fabricación de software, se adapta dependiendo del tipo de proyecto de manera que

puede ser utilizado tanto para grandes proyectos como para pequeños proyectos

centrándose en la documentación, los procesos para obtenerlos, las personas implicadas

en la elaboración y los flujos que establecen los tiempos.

Vemos que una de sus principales características es la de estar orientado o dirigido por los

casos de uso. Al respecto, debemos entender primero lo que es un caso de uso, un caso

de uso es una representación visual o gráfica de una interacción que es una funcionalidad

requerida por el usuario, cada caso de uso representa una parte de lo que debe hacer el

sistema para cada usuario de este, al ser representaciones gráficas permiten un

entendimiento óptimo por parte de los distintos involucrados en el desarrollo del sistema.

Estos fragmentos del sistema son los que van a conducir todo el desarrollo que vendrá en

adelante, relacionándose directamente con los requisitos y su especificación, la matriz de

trazabilidad, artefactos posteriores y luego servir en las pruebas del software donde se

determinará si el sistema cumple sus objetivos, de manera que enlazan todos los flujos del

proceso para las iteraciones correspondientes. (Jacobson et al., 1999; Kruchten, 2003)

En cuanto a la arquitectura, para la construcción de un software, esta expresa la necesidad

de definir en qué condiciones se desarrollará el sistema y que condiciones cumplirá el

52

mismo, en este sentido tenemos desde las plataformas, sistemas operativos, hardware,

redes, etc. hasta los requisitos no funcionales como la velocidad, confiabilidad, etc. Su

utilidad permite la reutilización del software, las pruebas por componentes individuales, así

como integrados y generar flexibilidad y adaptación a los cambios. (Jacobson et al., 1999;

Kruchten, 2003)

Finalmente, su característica de iterativo e incremental hace referencia a que los procesos

son continuamente repetidos y a la vez mejorados, integra los casos de uso que dirigen al

desarrollo, apoyándose en la arquitectura y esto se va trabajando de manera continua y

repetitiva hasta alcanzar un alto grado de calidad de manera estructurada y sistemática

(encontramos las fases y disciplinas que componen este proceso de desarrollo) sin que

suponga un sobrecosto, sino que se encuentre todo planificado. (Jacobson et al., 1999;

Kruchten, 2003)

La característica de iterativo e incremental, permite entender cómo es que se subdivide la

vida del software según este proceso, donde desde la concepción hasta el retiro del

software, se divide en cuatro fases: inicio, elaboración, construcción y transición. Y cada

fase se subdivide en iteraciones controladas donde se va actualizando el sistema de modo

que una mala iteración no afecte las iteraciones que ya han sido previamente avanzadas

reduciendo el riesgo y costos del proyecto, las iteraciones desarrollan los llamados flujos

de trabajo que son cinco: requisitos, análisis, diseño, implementación y pruebas; que son

conocidas también como las etapas de desarrollo de software, de manera que tras cada

iteración cada flujo se va refinando y a la vez incrementando sus componentes o

artefactos. (Jacobson et al., 1999; Kruchten, 2003)

53

Figura 7. Fases y flujos de trabajo del RUP. Fuente: Kruchten (2003, p. 23)

Como observamos en la figura 7. Durante cada iteración se trabaja algo de los flujos de

trabajo, dependiendo de la fase donde nos encontremos trabajaremos en mayor medida

un flujo que otro, tras cada iteración se va mejorando, optimizando y refinando los procesos,

una fase no es lo mismo que un flujo y las fases pueden concluir, pero los flujos continúan

a través de las fases.

Encontramos dentro una gran cantidad de artefactos que componen todo este ciclo de vida

para este proceso de desarrollo, si bien este proceso no pretende ser un manual al pie de

la letra sino una guía, es necesario definir los principales procesos y artefactos que lo

componen, que son desarrollados además siguiendo el estándar del UML. (Jacobson et

al., 1999; Kruchten, 2003; Rumbaugh, Jacobson y Booch, 2007):

54

2.2.11 Metodología de desarrollo orientado a objetos

Es un enfoque de desarrollo de software que tiene su principal característica en que aplica

el paradigma orientado a objetos para las diversas fases de desarrollo que provee

facilidades para el desarrollo por medio de componentes.

Esta metodología introduce diversos conceptos que nos ayudan a la representación de la

realidad tal cual la percibe una persona en el entorno de la ingeniería de software: entre

ellos tenemos principalmente a las clases y objetos.

Weitzenfeld (2005) en su obra va definiendo al objeto de acuerdo con sus múltiples

acepciones y llegando contexto informático, de tal manera que lo define como la

abstracción de un concepto del mundo real, este integra sus atributos o características y

las operaciones o comportamientos disponibles que realiza y las clases son abstracciones

que definen a un determinado tipo de objetos con características o atributos y operaciones

que realiza

Figura 8. Clases y objetos en la programación orientada a objetos. Fuente: elaboración propia

En la figura 8 se aprecia a la clase perro, que contiene dos objetos que son perro A y B, de

ambos aparece el concepto de instanciación que consiste en la creación de objetos que

pertenecen a una misma clase.

55

En base a esos conceptos básicos gira el paradigma orientado a objetos y tenemos así los

siguientes métodos orientados a objetos a las diferentes fases de desarrollo (Weitzenfeld,

2005; Bruegge y Dutoit, 2002):

OOA, análisis orientado a objetos: analiza los requisitos desde una óptica de clases y

objetos que encontrará durante los flujos de trabajo fundamentales de requisitos y

análisis

OOD, diseño orientado a objetos: diseña el software en base a módulos, que a su vez

están basados en los objetos que han sido abstraídos del problema

OOP, programación orientada a objetos: construye el código del programa o solución

utilizando clases y objetos aplicando propiedades de herencia.

De la combinación de los dos primeros tenemos al análisis y diseño orientado a objetos

(OOAD, Object-oriented analysis and design)

El propósito de esta es definir en un primer momento a todas las clases y objetos relevantes

que participaran en el proceso analizado (jerarquía de clases), pues una clase puede tener

superclases; así como heredar atributos y/u operaciones para luego hacer las

representaciones de cómo se relacionan los objetos entre sí y de forma iterativa ir

modelando las relaciones entre objetos hasta tener completo el modelo que permite

representar la realidad en objetos y clases.

La programación orientada a objetos usa como guía todo lo realizado en el proceso de

análisis y diseño y lo traslada a código en un lenguaje de programación.

56

Martin (2017) en su análisis sobre las arquitecturas de los sistemas hace un análisis sobre

la programación orientada a objetos donde cuestiona su definición como la combinación

de funciones y datos. Asimismo, al encapsulamiento, herencia y polimorfismo. Esto lo hace

señalando y ejemplificando como lenguajes que siguen el paradigma de la programación

estructurada han implementado anteriormente funciones y argumentos, llamadas a otros

programas (simulando las funciones GET y SET), generando una herencia entre clases

muy sencilla y permitiendo un polimorfismo básico. Considerando algunas definiciones o

explicaciones sobre el paradigma orientado a objetos como ambiguos o evasivos a la

pregunta de lo que realmente significan, pero resalta de la programación orientada a

objetos que simplifica los procesos de encapsulamiento, herencia y principalmente

haciendo más seguro y eficiente el polimorfismo en la programación, de manera que ya los

programas no dependen del dispositivo donde son instalados en su totalidad, siendo estos

fácilmente adaptados a otros dispositivos.

Weitzenfeld (2005) menciona las características de la metodología orientada a objetos y

como estas mejoran la calidad de los sistemas:

Abstracción: es el análisis de los objetos y su agrupación en clases y estas a la vez en

superclases en un alto nivel, es decir con bastante cercanía a la realidad percibida por

las personas.

Encapsulación: este aspecto implica que cada objeto tenga dos capas, una es la

interfase de sus funciones que son con las que se relaciona con otros objetos y la otra

es la implementación de sus funciones, algo exclusivo del objeto y que no interactúa con

otros objetos, esto permite que cualquier cambio en el objeto no impacte de manera

catastrófica en los demás objetos.

57

Modularidad: en la programación orientada a objetos su misión es la de dividir al sistema

en componentes de alto nivel basados en los objetos con la finalidad de simplificar el

sistema.

Extensibilidad: característica que permite la modificación del sistema a lo largo del

tiempo, en este aspecto la característica de modularidad es clave fundamental, pues

llegado el momento de modificar un sistema es más factible modificar un módulo u

objeto que modificar todo el sistema como sucede con la programación tradicional

secuencial.

Reutilización: para desarrollar una aplicación compleja, la posibilidad de poder volver a

utilizar aquello que ya se posee es de sumo beneficio en términos de costo y tiempo de

desarrollo, gracias a estar compuesto por módulos y las clases poseer herencia, es

posible mediante los lenguajes orientados a objetos un aumento significativo de la

reutilización de componentes frente a lenguajes no orientados a objetos, de tal manera

que lo más complicado en este campo es la construcción de módulos genéricos que

permitan su uso en diferentes áreas.

En base a lo visto, podemos definir a la metodología de desarrollo orientada a objetos como

un enfoque de desarrollo que tiene como eje las abstracciones de objetos y clases, así

como el uso de módulos para poder analizar y diseñar un software mediante el análisis y

diseño orientado a objetos y posteriormente con ello desarrollar dicho sistema mediante la

programación orientada a objetos que debe soportar como mínimo el encapsulamiento,

herencia y polimorfismo. Para continuar luego con las demás fases de desarrollo.

2.3 Marco Legal

La presente investigación tiene sus bases legales en tres leyes, una de las cuales trata

sobre la convivencia escolar y las otras dos sobre la adquisición de software por parte de

instituciones públicas, para tener una referencia frente a instituciones privadas y en el caso

58

que este análisis pueda implementarse en instituciones estatales o mixtas y por último la

ley de protección de datos personales, de importancia ya que establece normas sobre la

protección de datos de los involucrados, para el caso de nuestro estudio por lo general las

víctimas o testigos que reporten estos casos, más aun teniendo en cuenta que casi todos

los involucrados serán menores de edad y se necesitará consentimiento de sus padres

para el uso de la aplicación.

2.3.1 Ley N° 29719: Ley que promueve la convivencia sin violencia en las

instituciones educativas

Esta ley tiene como su objetivo establecer diferentes medios para diagnosticar, prevenir,

evitar, sancionar y erradicar los actos de violencia, hostigamiento o acoso en las

instituciones educativas.

Esta ley en el artículo 7 menciona las obligaciones del director del centro educativo para

informar a los padres de familia y convocar al Consejo Educativo Institucional al

presentarse casos de actos de acoso entre alumnos.

En el artículo 11 se menciona que las Instituciones debe tener un Libro de Registro de

Incidencias, donde contiene los actos de acoso cometidos, el tratamiento y sanciones

respectivas.

En su artículo 13 trata sobre la prevención de los actos de acoso, entregando boletines

informativos al inicio del año, por cualquier medio, considerando también los medios

electrónicos y virtuales.

En base a lo anterior, podemos reforzar nuestra justificación inicial y dar un sustento de los

beneficios que tendría tener ese libro de registros en una base de datos y su respectiva

59

aplicación que permita una consulta rápida por diferentes actores implicados en estos

casos de bullying y al tener una aplicación móvil, difundir con mayor facilidad los boletines

informativos, sin dejar de lado claro está los canales tradicionales de información, y sobre

todo al existir esta aplicación funcione como un método de prevención de estos casos y ser

así un apoyo en la erradicación de estos actos de acoso en las instituciones educativas.

2.3.2 Ley N° 28612: Ley que norma el uso, adquisición y adecuación del software

en la administración pública.

Si bien la presente investigación tiene como objeto de estudio a la comunidad educativa de

una institución particular, es decir que no pertenece al estado, este análisis puede

posteriormente adecuarse a instituciones públicas y será necesario tener la información

pertinente para su adecuación.

En el artículo 4 de esta ley se establece que no se puede adquirir recursos hardware que

obliguen a utilizar exclusivamente un tipo software, dado ello no podríamos obligar a la

escuela a comprar teléfonos inteligentes para que las aplicaciones móviles sean utilizadas,

pues las realidades en colegios naciones dista de las realidades de colegios particulares,

donde la gran mayoría dispone de estos dispositivos mientras en los colegios nacionales

ocurre lo inverso.

2.3.3 Ley N° 29733: Ley de protección de datos personales

Esta ley norma la protección y salvaguarda de los datos personales, según el artículo 2

numeral 6 de la Constitución Política del Perú, a través de un tratamiento adecuado.

Así mismo en el artículo 2, define los diferentes conceptos utilizados en la redacción de la

ley y en el artículo 3 menciona que su ámbito de aplicación es tanto para empresas públicas

60

como privadas, teniendo especial cuidado en la protección de datos sensibles, definidos

en el artículo 2 de la ley.

Los datos sensibles son definidos como:

Datos personales constituidos por los datos biométricos que por sí mismos

pueden identificar al titular; datos referidos al origen racial y étnico; ingresos

económicos, opiniones o convicciones políticas, religiosas, filosóficas o

morales; afiliación sindical; e información relacionada a la salud o a la vida

sexual. (Ley N° 29733, art. 2)

En su artículo 4, prohíbe la recopilación de datos por medios fraudulentos y en el artículo

5 que debe haber consentimiento del titular para brindar sus datos, en los artículos

posteriores, indican que se debe señalar la finalidad para la recolección de los datos,

garantizar la seguridad y otros.

En los demás artículos se norma de manera muy minuciosa el tratamiento que deben tener

los datos, la seguridad que el sistema que los manejo debe tener y el uso apropiado de

estos datos por parte de la institución, luego norma las sanciones en caso de incumplir con

los diversos reglamentos dados.

En base a esta ley, podemos realizar un análisis más normado y un tratamiento de los

datos más cuidadoso, salvaguardando estos datos y proveyendo del marco legal para la

protección de los datos de quien realice el reporte del acto de acoso o violencia escolar.

61

CAPÍTULO 3

MARCO METODOLÓGICO

El presente capitulo describe las variables utilizadas para recolección de la información que

servirán para las distintas fases de vida de la aplicación móvil para gestionar casos de

bullying y/o violencia escolar el cuál llamaremos en adelante: Antibullying-Shield, asimismo

describirá el tipo de diseño y el tratamiento de dichos datos, la población y muestra

seleccionadas. Los resultados obtenidos y su análisis están incluidos dentro de los

capítulos siguientes de acuerdo con la fase para los que son necesarios.

3.1 Variables

La operacionalización de las variables se aprecia en el apéndice A.

3.1.1 Variable Independiente

Implementación de un prototipo de la aplicación móvil.

3.1.2 Variable Dependiente

Impacto del prototipo de la aplicación móvil en la gestión de casos de bullying y/o violencia

escolar.

3.2 Diseño de la investigación

La presente investigación posee un método de la investigación cuantitativo con un diseño

de tipo transversal correlacional-causal, para poder identificar cómo influye la

implementación del prototipo de la aplicación móvil en la gestión de casos de bullying y/o

violencia escolar. (Hernández, Fernández y Baptista, 2010)

62

Previamente al análisis correlacional, la presente investigación aplicó un instrumento con

un enfoque cuantitativo con un diseño de tipo transversal descriptivo en una primera parte

durante la fase de análisis, para poder reconocer datos sobre la población analizada en un

momento dado. (Hernández et al., 2010). Este instrumento y sus resultados sirven como

un punto de inicio para el proceso de desarrollo, mas no tuvo como misión determinar la

validez de la hipótesis.

Para poder llevar a cabo ambas mediciones se solicitó el permiso de la directora del Colegio

Pamer - Salamanca mediante una carta de compromiso para poder hacer uso de los datos

recabados en su institución, donde acepta participar en este estudio de investigación (ver

apéndice B).

Con el instrumento de diseño descriptivo (ver apéndice C) se pudo identificar en su primera

parte cuantos miembros de la comunidad educativa poseen dispositivos móviles, el sistema

operativo más utilizado, valoración de la posible implementación de la aplicación móvil y

en la segunda parte donde se llevan a cabo mediciones correlacionales-causales se pudo

determinar la influencia de la variable independiente sobre la variable dependiente.

3.3 Población de estudio

La IEP posee un total de 15 tutores de los cuales se encuestó a 8 tutores, 9 docentes de

los cuales se encuestó a 8 docentes, 9 miembros del personal administrativo, de los cuáles

se encuesto a los 9 miembros y 34 estudiantes que se encuentran entre tercero y quinto

de secundaria. En total 60 miembros de la comunidad educativa participaron del

cuestionario sobre la aplicación (Ver apéndice E).

63

3.4 Instrumentos de medición

Se tiene los siguientes instrumentos, le dos cuales el primero sirvió como apoyo para el

proyecto y el segundo para demostrar la validez de la hipótesis.

3.4.1 Encuesta sobre dispositivos móviles y convivencia escolar

Este instrumento de tipo cuestionario (ver apéndice C) que posee un total de 11 preguntas

tiene como finalidad obtener datos generales de los miembros de la comunidad educativa

como: género, edad y rol dentro de la institución. Permite conocer datos sobre sus

dispositivos electrónicos como: el número de miembros de la comunidad educativa que

poseen un dispositivo móvil, el sistema operativo que utilizan y la versión del sistema

operativo. Además, si los estudiantes han sido víctimas o testigos de bullying y/o

cyberbullying. Finalmente, conocer si los miembros deseaban tener la aplicación y como la

valoraron.

Las preguntas son de opción múltiple en su mayoría, salvo la última donde se tiene una

escala en la valoración de la aplicación.

Se debe señalar que los datos obtenidos en este cuestionario tienen como principal objetivo

aportar al proceso de análisis del desarrollo de la aplicación móvil, el cual servirá

posteriormente para las fases de diseño y prototipado, pero los datos obtenidos pueden

servir de guía o referencia para estudios similares o relacionados con la implementación

de sistemas informáticos en instituciones de rubro similar, asimismo el instrumento puede

ser adaptado o reutilizado para proyectos y/o estudios afines. Este instrumento es de apoyo

para el estudio, y sirve para dar sustento a las decisiones técnicas del proyecto.

64

Se encuestó a 5 tutores, 8 docentes, 9 miembros del personal administrativo, 262

estudiantes de los grados de tercero, cuarto y quinto de secundaria de un total de 317 y a

2 padres de familia.

3.4.2 Cuestionario sobre la aplicación móvil

Este cuestionario de tipo encuesta (ver apéndice E) que posee un total de 17 preguntas

tiene como finalidad obtener la relación entre la implementación del prototipo y la gestión

de casos de bullying de la institución, si esta mejora, me mantiene igual o empeora, todas

estas en función de la operacionalización de variables (ver apéndice A).

Las preguntas son de escala de Likert donde los encuestados dieron sus valoraciones al

tiempo de respuesta de la aplicación, su facilidad de uso y su impacto en la gestión de

casos.

Los datos obtenidos en este cuestionario (ver apéndice G) tienen como principal objetivo

validar la hipótesis de la investigación.

3.4.2.1 Validación del instrumento

El instrumento fue evaluado mediante Juicio de Expertos, para el presente se requirió de

tres expertos, quienes dieron su valoración a los 17 ítems que componen el instrumento

mediante una valoración de escala de Likert y su aprobación para que el instrumento sea

aplicado (ver apéndice F). Para el caso del instrumento todos los expertos dieron su visto

bueno al instrumento y su aplicación.

Además, se empleó el método de distancia de puntos múltiples (DPP) para darle una

validez estadística al instrumento

65

Para el método de distancia de puntos múltiples, se construyó una tabla con la valoración

de los expertos que va del 1 al 5 y el promedio para uno de los ítems que componen el

instrumento.

Tabla 2 Resultados de la valoración de expertos

Ítem Valoración de expertos

Promedio xn 1 2 3

1 4 4 5 4.33

2 4 4 5 4.33

3 4 4 5 4.33

4 4 4 5 4.33

5 4 4 5 4.33

6 4 5 4 4.33

7 4 5 4 4.33

8 4 5 5 4.67

9 4 4 5 4.33

10 3 5 5 4.33

11 5 5 4 4.67

12 4 4 5 4.33

13 4 4 5 4.33

14 4 4 5 4.33

15 4 4 5 4.33

16 4 4 5 4.33

17 5 4 4 4.33 Fuente: elaboración propia.

De los valores obtenidos en la tabla 2, aplicamos la ecuación:

Dpp = √(𝑥1 − 𝑦)2 + (𝑥2 − 𝑦)2 + (𝑥3 − 𝑦)2 +⋯(𝑥17 − 𝑦)2

En este caso el valor de “𝑥𝑛” es el promedio para cada uno de los elementos del

instrumento y el valor de “𝑦” es el máximo valor que puede alcanzar, para este caso el valor

máximo fue de 5. Se obtuvo el valor:

Dpp = 2.62

66

Se realizó luego el cálculo de Dmax del valor que se obtuvo mediante la ecuación:

𝐷𝑚𝑎𝑥 = √(𝑥1 − 𝑦)2 + (𝑥2 − 𝑦)2 + (𝑥3 − 𝑦)2 +⋯(𝑥17 − 𝑦)2

En este caso el valor de “𝑥𝑛” es el valor más alto que cada elemento del instrumento ha

alcanzado, para este caso el valor máximo fue de 5 en todos los elementos y el valor de

“𝑦” es el mínimo valor que puede alcanzar cada ítem, para este caso el valor mínimo fue

de 1. Se obtuvo el valor:

𝐷𝑚𝑎𝑥 = 16.49

Este nuevo valor se divide con el valor Dpp, se obtuvo el valor de 3.30. Con este valor se

construye una escala y se ubica el valor de Dpp en esta, de manera que si se encuentra

entre la primera o segunda se considera que la adecuación del instrumento es óptima.

Tabla 3 Escala de adecuación del instrumento

Escala Valoración Valoración de expertos

0 3.30 A = Adecuación total 2.62

3.30 6.60 B = Adecuación en gran medida

6.60 9.90 C = Adecuación promedio

9.90 13.19 D = Escasa adecuación

13.19 16.49 E = Inadecuación Fuente: elaboración propia

Con lo observado en la tabla 3, se concluye que el instrumento está adecuado para su

aplicación.

De esta manera, el instrumento fue aprobado mediante los expertos para su aplicación y

mediante el método de distancia del punto múltiple se ratifica su consistencia interna.

67

3.5 Recolección de datos

En la primera fase del estudio, durante la fase de análisis del desarrollo de software se

realizó una recolección de datos a los miembros de la comunidad educativa del colegio

Pamer – Salamanca el día 17 de abril del 2018, mediante un cuestionario aplicando la

encuesta sobre dispositivos móviles y convivencia escolar (Ver apéndice C).

De esta primera recolección de información se extrajo datos generales sobre la comunidad

educativa como: genero, año de nacimiento, si poseen un dispositivo móvil y el sistema

operativo de su sistema móvil. Además, se recolectaron datos sobre su conocimiento de

casos de bullying y/o violencia escolar en su institución educativa o a través de medios

digitales (cyberbullying). Finalmente, si les gustaría o no tener una aplicación para

gestionar estos casos y como la valorarían en una escala del 1 al 5.

Teniendo como insumo estos datos, se procedió al desarrollo de la aplicación móvil, de

manera coordinada con el stakeholder de la institución y una vez validadas y aceptados los

reportes de la etapa de prueba que validan aspectos como: disponibilidad del sistema,

compatibilidad con las versiones 4.0.3 en delante de Android y consumo de recursos de

los dispositivos.

Luego se realizó la validación del instrumento mediante expertos entre noviembre y

diciembre de 2018 (ver apéndice F), luego se procedió a realizar la aplicación del

instrumento sobre la valoración de los usuarios (miembros de la comunidad educativa)

sobre los tiempos de respuesta, visualización y facilidad de uso de la aplicación entre el 7

de enero y el 20 de febrero mediante demostraciones presenciales y virtuales de la

aplicación a un total de 60 miembros de la comunidad educativa.

68

Los datos recolectados fueron procesados mediante software estadístico SPSS y Microsoft

Excel 2016. Sus resultados están incluidos en los apéndices D y G. El análisis del

instrumento de apoyo está incluido en la sección de resumen ejecutivo del capítulo 4 y del

instrumento para validar la hipótesis en el capítulo de resultados.

3.6 Métodos y procedimientos de software

Para el presente estudio se consideró utilizar una metodología para gestionar el proyecto

de la aplicación móvil para gestionar casos de bullying y/o violencia escolar. Para ello la

presente investigación se basa en dos metodologías de desarrollo de software: el Proceso

Racional Unificado (RUP) y el análisis y diseño orientado a objetos (OOAD. Object-oriented

analysis and design). La elección de los métodos RUP y OOAD se basa en el tipo de

lenguaje al que posteriormente se tendrá que programar la aplicación, el cual es JAVA, y

además de ello porque estos enfoques de desarrollo prestan especial interesen las fases

previas al desarrollo, que son el análisis y diseño de manera que previenen cambios en las

fases finales las cuales generan costos adicionales en tiempo, recursos y personal. Este

enfoque de desarrollo junto con la OOAD aplicará la técnica de modelado orientado a

objetos (OOM) que le permitirá aplicar el paradigma orientado a objetos a las diversas fases

de desarrollo del software.

Combinando ambos enfoques de desarrollo la presente investigación contendrá las

siguientes actividades de desarrollo: análisis, diseño y prototipado (con pruebas); donde se

seguirá en cada una de ellas el paradigma orientado a objetos y para su documentación y

análisis el enfoque RUP, incluyendo procesos iterativos en cada fase para hacer los ajustes

de cada una de las fases previas.

69

RUP posee las fases de: inicio, elaboración, construcción, y transición. (Jacobson et al.,

1999). Para el presente estudio se realizaron 3 de las 4 fases: inicio, elaboración y

construcción. La fase de transición no ha sido realizada por razones ajenas al presente

estudio (contempladas dentro de las limitaciones), lo cual implica que tampoco se llevó a

cabo ningún mantenimiento al software. Se inició con la etapa de requisitos, siguiendo

luego con el análisis, diseño e implementación del prototipo funcional.

Se planificó un tiempo de desarrollo considerando 5 días hábiles por semana para el

desarrollo de manera que se obtuvo la proyección de 100 días de desarrollo, que incluye

las fases de inicio, elaboración y construcción.

Tabla 4 Primer cronograma de desarrollo

Fase Duración Comienzo Fin Involucrados

Fase de inicio 6 días 9/04/18 16/04/18 Analista; Stakeholder

Fase de elaboración

16 días 17/04/18 8/05/18 Analista; Diseñador; Programador; Stakeholder

Fase de construcción

78 días 9/05/18 24/08/18 Analista; Diseñador; Programador; Stakeholder; Tester

Fuente: elaboración propia.

En la tabla 4 se aprecia la estimación de los tiempos para el desarrollo del proyecto,

involucrados y las fechas de inicio y fin, pero estos tiempos se vieron modificados por

distintos factores como: fechas festivas, en las cuales el stakeholder se encontraba de

licencia, motivos de fuerza mayor como enfermedades, etc.

Se observa también los involucrados en los distintos procesos, el investigador cumplió los

roles de jefe de proyecto, análisis, diseñador, programador y tester, por el lado de la

institución un coordinador académico con experiencia en el área de innovación tuvo el lugar

del stakeholder y como representante de la institución.

70

Figura 9. Escala de tiempo proyectada inicialmente. Fuente: elaboración propia

En la figura 9 se muestra las fases de desarrollo con sus respectivas iteraciones

proyectadas, de manera que para la primera fase tenía una iteración, para la fase de

elaboración tenía dos iteraciones y finalmente para la construcción se llevaría a cabo tres

iteraciones.

Tabla 5 Cronograma final de desarrollo

Fase Duración Comienzo Fin Involucrados

Fase de inicio 6 días 9/04/18 16/04/18 Analista; Stakeholder

Fase de elaboración

23 días 17/04/18 17/05/18 Analista; Diseñador; Programador; Stakeholder

Fase de construcción

88 días 18/05/18 18/09/18 Analista; Diseñador; Programador; Stakeholder; Tester


71

La tabla 5 muestra los tiempos reales que tomaron cada una de las fases de desarrollo de

la aplicación, puesto que los casos fueron casi de carácter extraordinario, el tiempo

adicional requerido no superó las 4 semanas.

Figura 10. Escala de tiempo final. Fuente: elaboración propia

En la figura 10 se observa las distintas iteraciones para las fases de acuerdo con el

cronograma final del desarrollo del proyecto, se aprecia que los cambios fueron

sustancialmente en la fase de construcción, debido a inconvenientes del stakeholder y el

jefe de proyectos de coincidir en fechas de reuniones sobre el proyecto por actividades

propias de la institución.

72

CAPÍTULO 4

DESARROLLO DEL PROYECTO DE SOFTWARE

El presente capítulo describirá las fases de desarrollo de software siguiendo la metodología

RUP.

4.1 Resumen ejecutivo

Para llevar a cabo la implementación de la aplicación Antibullying-Shield, debemos primero

describir la situación actual de la IEP Pamer – Salamanca.

4.1.1 Reseña

La Institución educativa privada Pamer – Salamanca es una de las sedes de la franquicia

Pamer, se encuentra ubicada en el distrito de Ate en la provincia de Lima, departamento

de Lima, Perú. En su local de la avenida Paracas 947, ofrece los servicios de educación

secundaria desde primer hasta quinto grado. Esta cuenta con tres aulas por grado,

teniendo un total de 15 aulas, diversos ambientes como espacio deportivo, cafeterías, salas

de profesores, área de psicología, coordinación académica, sala de recepciones, oficinas

administrativas y Dirección. Cada aula cuenta con su propio tutor y está compuesta por

aproximadamente 35 alumnos. Además, posee una coordinadora académica, dos

psicólogos y nueve docentes. Además de contar con personal de limpieza, vigilancia,

secretarias, etc.

Los cargos o roles de las personas dentro de la comunidad educativa de la IEP son:

estudiante, profesor, tutor, psicólogo, coordinador académico, director y personal

administrativo (secretarias, encargados de limpieza, vigilantes, etc.).

73

La institución posee una estructura organizacional sólida y personal dedicado a proveer

una educación y atención de calidad a los estudiantes y padres de familia. Para ello integra

diversas técnicas de tutoría, TIC y metodologías de aprendizaje. Además, infraestructura

adecuada para el desenvolvimiento de las actividades educativas y extracurriculares.

4.1.2 Problemática

La IEP busca mejorar los servicios que ofrece y cumplir con lo establecido por la Ley que

promueve la convivencia sin violencia en las instituciones educativas (Ley N° 29719, 2011),

por consiguiente desea integrar a las campañas de concientización y apoyo psicológico,

que brinda tanto a estudiantes como padres de familia, recursos tecnológicos para de esta

manera alcanzar un ambiente de armonía en su comunidad educativa y cumplir con las

disposiciones de la ley como son el libro de incidencias y brindar información sobre bullying,

acoso y/o violencia escolar a su comunidad educativa en tiempo real y saltando la barrera

del espacio físico al poder ser enviada esta información de manera virtual y controlada.

En este sentido, se encuentra la necesidad de mejorar el sistema de gestión de casos de

bullying y/o violencia escolar en la comunidad educativa y al mismo tiempo abordar el tema

del cyberbullying en entornos extracurriculares, estos son actualmente procesos manuales.

Además, poder optimizar la recepción de estos casos y a la vez automatizar el libro de

incidencias para llevar a cabo un control más eficaz sobre los casos para brindar las

medidas correctivas necesarias.

En este caso se sugiere la implementación de la aplicación móvil Antibullying Shield, para

mejorar la gestión de casos de bullying y/o violencia escolar en la IEP.

74

4.1.3 Alcance

El objetivo de implementar la aplicación fue mejorar la gestión de casos de bullying y/o

violencia escolar en la IEP, para poder mejorar el servicio brindado, brindar información

sobre la convivencia escolar pacífica, tener un libro de incidencias electrónico y de esa

manera cumplir con la normativa peruana para las instituciones educativas. Se procedió a

dividir el proyecto en tres etapas: levantamiento de información, desarrollo del software y

medir su impacto.

4.1.4 Solución planteada

La solución planteada fue la de crear un prototipo funcional que es una aplicación móvil en

el SO Android para:

- Gestionar los casos de bullying y/o violencia escolar.

- Gestionar las incidencias que derivan de los casos.

- Visualizar el libro de incidencias.

- Proteger la anonimidad de quienes realizan los reportes.

- Compartir información sobre la convivencia escolar a la comunidad educativa.

En el plano tecnológico, la aplicación móvil fue construida en un lenguaje nativo de Android

para todos los usuarios a partir de la versión 4.0.3 “IceCreamSandwich” hasta 8.0 “Oreo”,

un servidor remoto para almacenar los WebServices REST (escritos en lenguaje PHP) y

utilizando una base de datos en el motor MySQL. Estos se definieron mediante la aplicación

de una encuesta a la comunidad educativa sobre sus expectativas sobre la aplicación

móvil, posesión de tecnología móvil y el estado de la convivencia escolar en la institución

(ver apéndices C y D).

En la primera etapa se llevó a cabo el análisis del proceso manual para gestionar casos de

bullying y/o violencia escolar en la IEP, para ello se llevó a cabo reuniones con personal

75

docente y administrativo de la IEP con la finalidad de describir este proceso cuando lo

realizan diferentes actores de esa manera se analizó a la IEP desde el 10 de marzo del

2018 hasta el 26 de marzo del 2018.

De este primer análisis se pudo determinar la forma manual como se reporta un caso de

bullying y/o violencia escolar y como llega este a ser o no inscrito en el libro de incidencias

de la institución.

Durante este periodo de observación y análisis de la situación, se elaboró y aplicó una

encuesta (Ver apéndice C) para conocer: si la población conocía sobre casos de bullying

(en la institución o a través de TIC), información sobre sus dispositivos móviles y la

valoración de la aplicación por parte de la comunidad educativa. Esta encuesta se efectuó

el día 17 de marzo del 2018 y permitió conocer datos relevantes para la consolidación del

sistema operativo elegido (Android), la versión desde la cual operar y si desean tener una

aplicación para estos casos y como la valorarían.

De sus resultados (Ver apéndice D), se desprende información relevante para la

elaboración de la aplicación. Primero se debía confirmar que la comunidad educativa de la

IEP posee los medios tecnológicos necesarios.

Figura 11. Posesión de dispositivos móviles. Fuente: elaboración propia

12 5

269

No Sí (De uso compartido) Sí (De uso personal)

0

50

100

150

200

250

300

Poseen dispositivos móviles

Mie

mb

ros

de

la c

om

un

idad

e

du

cati

va

76

Tabla 6

Participantes según rol en la IEP y si poseen dispositivos móviles

Rol/cargo en la IEP Número Tienen dispositivo móvil

Coordinador(a) académico(a) 1 1

Director(a) académico(a) 1 1

Docente 8 8

Estudiante 262 250

Otro 2 2

Padre de familia/Apoderado 2 2

Personal Administrativo 3 3

Psicólogo(a) 2 2

Tutor(a) 5 5

TOTAL 286 274

Fuente: elaboración propia

Es así como en la figura 11 se puede observar, que la mayoría de los miembros de la

comunidad educativa que fueron encuestados poseen dispositivos móviles de uso

personal. En cuanto al personal docente y administrativo de acuerdo con la tabla 6, todos

poseen dispositivos electrónicos móviles.

Figura 12. Sistema operativo usado. Fuente: elaboración propia

220

50

4

0

50

100

150

200

250

Android iOS Otro

Mie

mb

ros

de

la c

om

un

idad

ed

uca

tiva

SO utilizado

77

El sistema operativo favorito, como lo indica la figura 12, es Android, de esta manera

corroborando lo planteado inicialmente sobre el dominio de este sistema operativo en el

mercado peruano. (StatCounter GlobalStats, 2018)

Lo cual hace factible la implementación de un sistema móvil y basado en el sistema

operativo Android.

También se consultó a los encuestados sobre la versión del sistema operativo que utilizan,

de donde se definió la versión base de Android para la cual se construirá la aplicación

móvil. Es importante mencionar que por proceso de observación se encontró que cuentan

con sala de profesores equipadas con ordenadores personales, así como las áreas de

dirección, psicología y coordinación académica cuentan con entre una a tres computadoras

por área.

Figura 13. Versión de Android utilizada. NR significa no respondió. Fuente: elaboración

propia.

1 1 1 27

19

1 1 1 1 1 1 1

191

0

50

100

150

200

250

4 4.2 4.4 5 6 6.1 7 7.1 8 8.1 5.0.1 5.1.1 5.1.2 6.0.1 NR

Mie

mb

ros

de

la c

om

un

idad

ed

uca

tiva

Versión de Android que utilizan

Total

78

Figura 14. Captura de pantalla de Android Studio del 07/05/2018. Fuente: elaboración

propia.

Por lo tanto, el desarrollo para el sistema operativo Android se podía ir perfilando a partir

de la versión 4.0.3 “IceCreamSandwich” hasta 8.0 “Oreo”, debido a que la mayoría de

encuestados no respondió sobre la versión de dispositivo que utilizan como se aprecia en

la figura 13, la menor versión conocida fue 4 en los resultados de la encuesta (Ver apéndice

D), en base a las estadísticas brindadas por Android. (Android, 2018) y la misma aplicación

Android Studio como se aprecia en la figura 14.

Luego de ello se evaluó si los distintos miembros de la comunidad educativa habían sido

testigos o víctimas de casos de bullying y/o violencia escolar.

Figura 15. Número de víctimas o testigos de bullying. Fuente: elaboración propia

85

50

81

70

0

10

20

30

40

50

60

70

80

90

No Sí

Mie

mb

ros

de

la c

om

un

idad

e

du

cati

va

¿Alguna vez has sido víctima o testigo de un caso de bullying en la escuela?

Mujer

Varón

79

Figura 16. Número de víctimas o testigos de cyberbullying. Fuente: elaboración propia

De las figuras 15 y 16 se observa que los casos de bullying de los cuales cuentan los

estudiantes son menores a los promedios en las escuelas peruanas según los estudios de

WORLD VISION PERÚ (2016), pero aun así se evidencia la presencia de conductas que

atentan contra una sana convivencia escolar.

Finalmente se consultó si era deseable para la comunidad educativa poseer una aplicación

para gestionar estos casos y como la valoran.

Figura 17. Desean tener la aplicación (No estudiantes). Fuente: elaboración propia

102

33

112

39

0

20

40

60

80

100

120

No Sí

Mie

mb

ros

de

la c

om

un

idad

e

du

cati

va

¿Alguna vez has sido víctima o testigo de un caso de bullying por Internet o teléfono por compañeros de tu colegio?

Mujer

Varón

4%

96%

¿Te gustaría tener una aplicación en su celular que te permita reportar un caso de bullying de manera anónima y segura?

No

Sí

80

Figura 18. Desean tener la aplicación (Estudiantes). Fuente: elaboración propia

De las figuras 17 y 18 se desprende que la mayoría de los miembros docentes y

administrativos gustarían de tener una aplicación para poder gestionar estos casos.

Mientras en el plano estudiantes, más del 75% gustaría de tener esta aplicación. Luego,

mediante una escala del 1 al 5, que va desde nada útil hasta muy útil, se midió la valoración

por parte de la comunidad educativa de esta herramienta.

Figura 19. Valoración por parte de los estudiantes. Fuente: elaboración propia

No22%

Sí78%

¿Te gustaría tener una aplicación en su celular que te permita reportar un caso de bullying de manera anónima y segura?

No

Sí

64

2022

25

15

13

25

30

4 5

25

30

47

0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5

Nú

me

ro d

e e

stu

dia

nte

s

Escala de valoración de la aplicación del 1 al 5 (Nada útil a muy útil)

Si tuvieras una aplicación en tu celular o tablet que permita de manera anónima informar de estos hechos como lo valorarías del 1 al 5

Cuarto de secundaria

Quinto de secundaria

Tercero de secundaria

81

De la figura 19 se observa que la comunidad educativa en cuanto a los estudiantes de los

últimos grados reacciono de manera positiva en cuanto a la valoración de una aplicación

que les permita realizar reportes de casos que no favorecen una convivencia escolar sin

violencia.

Figura 20. Valoración de la aplicación por la comunidad educativa. Fuente: elaboración

propia

De la figura 20, se puede observar que una mayoría amplia valora positivamente el tener

una aplicación que permita informar de los casos de bullying, haciendo viable la propuesta.

4.2 Ámbito o Entorno

Se identificó los diversos entregables para las fases y flujos que contempla la metodología

RUP. Por ello, se construyó un plan de desarrollo de software (ver apéndice I), este

documento contempla los objetivos del proyecto, su alcance, requerimientos para su

desarrollo y la estrategia de ejecución de este.

Al tratarse de un estudio de investigación sobre los efectos de implementar una plataforma

móvil para medir su impacto, los costos de desarrollo (personal, equipos, etc.) fueron

asumidos íntegramente por el investigador.

11

14

60

84

117

1

2

3

4

5

Si tuvieras una aplicación en tu celular o tablet que permita de manera anónima informar de estos hechos como lo valorarías del 1 al 5

82

4.3 Administración del proyecto

Para llevar a cabo un control sobre el proceso de desarrollo se realizó la construcción de

un cronograma, donde se detallan las fases, flujos e iteraciones con los tiempos que

tomaron, este se detalla dentro del plan de desarrollo de software (ver apéndice I).

4.4 Modelo del negocio

El proceso más importante de la institución para este proyecto es el proceso manual que

se utiliza para dar tratamiento a los actos que atentan contra la convivencia escolar sin

violencia inicia cuando un estudiante desea reportar un caso de bullying y/o violencia

escolar, siempre que este lo reporte a un miembro que no sea otro estudiante, el caso pasa

a manos de su tutor, quien evalúa e indaga sobre el caso tomando la decisión de llevar el

caso al departamento psicológico, donde se inscribirá este en el libro de incidencias y se

dará tratamiento al caso. En caso el estudiante pase directamente con el psicólogo o la

directora, estos de igual forma darán parte al tutor para que indague e informe al área de

psicología si el caso procede o no a ser inscrito en el libro.

En caso el estudiante le reporte a un docente o personal diferente al tutor, este se lo reporta

al tutor del aula del estudiante y se repite el proceso anterior. En caso el estudiante se lo

reporte directamente al psicólogo, coordinador académico o director, este procede a

comunicárselo al tutor y en conjunto evalúan el caso. En caso el estudiante le comenta a

otro estudiante y este desee reportar el caso, lo hace siguiendo uno de los caminos

descritos anteriormente, solo se debe acotar que el tutor corresponderá al estudiante

involucrado en el caso reportado.

Se considera un caso cuando se reporta de lo sucedido al tutor, cuando este indaga y

concluye que debe ser remitido al departamento de psicología por tratarse de un caso de

bullying y/o violencia escolar, el caso pasa a llamarse incidencia y estas son analizadas

83

por el psicólogo educativo, quien decide si debe ser inscrita en el libro de incidencias (físico)

o no, y se va dando seguimiento hasta resolverlo según las políticas de la IEP.

Si lleváramos esto al plano de la automatización tendríamos que todos los reportes deben

llegar primero al tutor (área de tutoría), quien hará las indagaciones y de acuerdo con su

decisión se procederá a elevar el caso al área de psicología donde el caso se transforma

en una incidencia donde el psicólogo decide si debe ser inscrito en el libro de incidencias

o no y dar el respectivo tratamiento al caso, salvo el caso que el psicólogo considere que

un caso que ha observado se debe tratar directamente con él y no pasar primero por tutoría.

4.4.1 Modelo de Casos de Uso de Negocio

Los actores externos al negocio (Colegio Pamer) son dos: primero tenemos al miembro de

la comunidad educativa, que reporta los casos de los que es testigo y/o víctima. Además,

recibe información sobre la convivencia escolar libre de violencia por parte de la institución.

Por último, el MINEDU, ente el cual recibe la información del libro de incidencias por parte

de la institución.

Figura 21. Diagrama de casos de uso del negocio. Fuente: elaboración propia.

MINEDU

Mostrar libro

(from Colegio Pamer)

Recibir información


Miembro

Reportar caso


84

4.4.2 Modelo de Análisis del Negocio

La especificación de casos de uso del negocio (CUN) es la siguiente:

Figura 22. Caso de uso del negocio: Reportar caso. Fuente: elaboración propia.

Nombre: Reportar caso.

Actores: Miembro (miembro de la comunidad educativa).

Propósito: Recibir el reporte de caso de bullying y/o violencia escolar, indagar sobre el

tema y tomar una acción.

Resumen: El caso de uso se inicia cuando el Miembro reporta un caso del cual es víctima

o testigo. El proceso da seguimiento al caso, indagando sobre este para decidir si procede

como una incidencia hacia el área de psicología o este es archivado, luego el departamento

de psicología indaga sobre esta incidencia y toma la decisión de inscribirlo en el libro de

incidencias o archivarlo, para luego tomar las acciones que ellos crean convenientes. El

caso de uso finaliza cuando el psicólogo decide inscribir la incidencia en el libro de

incidencias o archivarlo.

Flujo básico:

1) El miembro reporta un caso del cual es víctima o testigo al tutor del aula.

2) El tutor indaga sobre el caso tomando la decisión de llevar el caso al departamento

psicológico o archivarlo.

3) Si el caso pasa como incidencia al área de psicología, se indaga sobre este y se

decide si se inscribe en el libro de incidencias o es archivado.

Prioridad: Alta.

Reportar caso

(from Colegio Pamer)Miembro

85

Mejoras:

- El reporte de casos será realizado a través de una aplicación móvil.

- Los tutores y psicólogos recibirán los casos e incidencias reportados de manera

electrónica.

- Las razones por la cual un caso o incidencia es archivado serán almacenadas en

un registro virtual.

- Los casos e incidencias se almacenarán en un repositorio virtual.

- Los tutores y psicólogos tendrán acceso a la base de datos de casos e incidencias.

- La anonimidad de quien reporta el caso será protegida.

Figura 23. Caso de uso del negocio: Recibir información. Fuente: elaboración propia.

Nombre: Recibir información.

Actores: Miembro (miembro de la comunidad educativa).

Propósito: Recibir información sobre la convivencia escolar libre de violencia (bullying,

acoso y/o violencia escolar).

Resumen: El caso de uso se inicia cuando el área de psicología o tutoría envía información

sobre la convivencia escolar al Miembro de la comunidad educativa, el caso finaliza cuando

el Miembro ha recibido esta información.

Flujo básico

1) El tutor o psicólogo envía información acerca de la convivencia escolar libre de

violencia a los miembros de la comunidad educativa.

2) El miembro de la comunidad educativa recibe dicha información.

Recibir información

(from Colegio Pamer)Miembro

86

Prioridad: Media.

Mejoras:

- Los tutores y psicólogos enviarán la información de manera electrónica.

- El miembro de la comunidad educativa recibirá la información a través de su

aplicación móvil.

- La información estará almacenada en un repositorio, de manera que podrá ser

visualizada las veces que el miembro desee.

Figura 24. Caso de uso del negocio: Mostrar libro. Fuente: elaboración propia.

Nombre: Mostrar libro

Actores: MINEDU (Ministerio de educación)

Propósito: Hacer saber al MINEDU que la institución cuenta con un libro de incidencias

como lo exige la normativa peruana sobre convivencia escolar libre de violencia.

Resumen: El caso de uso se inicia cuando la institución envía la documentación a la UGEL

(ente que forma parte del MINEDU) sobre la posesión y uso responsable de un libro de

incidencias. El caso de uso finaliza cuando se ha enviado la información y se recibe un

cargo por dicho documento.

Flujo básico

1) El coordinador académico o psicólogo envía la documentación del libro de

incidencias a la UGEL.

2) La UGEL devuelve un cargo informando la recepción de la documentación.

MINEDU

Mostrar libro


87

Prioridad: Alta.

Restricciones:

El proceso de enviar la documentación debe realizarse de manera manual o vía SIAGIE

(plataforma del MINEDU).

Mejoras:

- El libro de incidencias será electrónico.

- Se puede consultar el libro de incidencias a través del sistema Antibullying Shield.

- Los coordinadores académico y director tendrán acceso al libro de incidencias y

podrán exportarlo a un documento para hacer su envío.

4.4.2.1 Diagramas de actividades

Figura 25. Diagrama de actividades del negocio de reportar caso. Fuente: elaboración propia.

88

En la figura 25 se muestra el diagrama de actividades del negocio de reportar caso, en la

cual se aprecia el proceso de decisión que se toma primero al analizar el caso por parte

del tutor y luego por el psicólogo en la incidencia, para optar por inscribir la misma o

archivarla, se aprecia claramente una jerarquía en cuanto a la revisión de los casos

ocurridos.

Figura 26. Diagrama de actividades del negocio de enviar información. Fuente: elaboración propia.

En la figura 26 se muestra el diagrama de actividades del negocio de enviar información,

en el cual es la institución a través del área de tutoría o psicología que inicia la actividad,

esta es enviada de forma física por lo general mediante los periódicos murales, volantes o

afiches. También, a través de conferencias, charlas y reuniones. En cuanto al formato

digital, se envía mediante correo electrónico y publicidad en redes sociales.

89

Figura 27. Diagrama de actividades del negocio de mostrar libro. Fuente: elaboración propia.

En la figura 27 se muestra el diagrama de actividades del negocio de mostrar libro, en el

cual es la institución a través del área de coordinación académica que inicia la actividad.

4.5 Matriz de trazabilidad

Los objetivos de la construcción e implementación del prototipo funcional de la aplicación

móvil son los de permitir reportar casos e incidencias. Además, la implementación del libro

de incidencias electrónico, donde se registrarán los casos e incidencias. Por ello, se

definieron los siguientes alcances de la solución:

- La aplicación permite ingresar a la aplicación mediante el correo electrónico

institucional del miembro de la comunidad y una contraseña.

- La aplicación permite reportar un caso en tiempo real, adjuntando si lo desea un

archivo multimedia (imagen), el cuál será derivado al tutor de la sección

correspondiente. El tutor decide si el caso prosigue para convertirse en una

incidencia.

90

- La aplicación protege los datos de quien realizó el caso. Solo ciertos miembros

clave de la comunidad educativa tendrán acceso a esos datos.

- La aplicación permite que un caso se transforme en una incidencia, luego el

psicólogo educativo decidirá si se inscribe o no en el libro de incidencias.

- La aplicación permite que una incidencia sea escrita en el libro de incidencias.

Asimismo, permite la consulta de casos e incidencias en tiempo real por parte de

los miembros de la comunidad educativa que poseen ese nivel de acceso.

- La aplicación permite que se comparta información a los estudiantes a través de

esta para concientizar sobre la convivencia escolar.

Teniendo como base a estas condiciones, se definió de manera general las limitaciones o

restricciones para el sistema.

- Todos los miembros de la institución pueden reportar un caso del que sean víctimas

y/o testigos.

- Solo los tutores deciden luego de hacer una indagación si el caso para a ser una

incidencia o no.

- Solo los psicólogos deciden luego de hacer una indagación si la incidencia pasa a

ser inscrita en el libro de incidencias o no.

- Solo el psicólogo puede reportar una incidencia directamente.

- Se protege los datos de quien realiza el reporte. Solo los coordinadores académicos

y director tendrán acceso a esta información y podrán brindarla a quien se lo solicite,

cuando ellos lo consideren necesario.

- La veracidad de los casos depende del factor humano, al ser estos quienes realizan

los reportes, la indagación y toma de decisiones.

91

Tras este proceso de observación y el levantamiento de información por la encuesta (ver

apéndice D), se determinó los actores que interactúan con el sistema, donde el actor

“miembro” en el análisis del modelo del negocio, se ha dividido en cuatro actores para el

sistema.

Tabla 7 Catálogo de actores

Nombre Descripción Acciones

Usuario básico Estudiantes, profesores y personal administrativo

Iniciar y cerrar sesión mediante correo electrónico institucional.

Reporta los casos de los que es testigo o víctima dentro de la comunidad educativa.

Visualiza Información sobre números de apoyo y sitios web.

Visualiza Información sobre la convivencia escolar pacífica.

Visualizar el manual de uso.

Usuario tutor Tutores Todas las acciones del usuario básico.

Consultar los reportes de casos de su sección correspondiente.

Reporta incidencias a partir de los casos que ha recibido.

Usuario psicólogo

Psicólogos Todas las acciones del usuario básico.

Reporta las incidencias.

Consultar los reportes de incidencias.

Agrega incidencias al libro de incidencias.

Remover incidencias del libro de incidencias.

Envía información sobre la convivencia escolar pacífica.

Usuario observador

Director y coordinador académico.

Todas las acciones del usuario básico.

Consultar los reportes de casos.

Consultar los reportes de incidencias.

Visualizar el libro de incidencias y exportarlo a un archivo en formato Excel.

Enviar datos de quien reporta un caso.


92

En la tabla 7 fueron definidos los actores. Además, se señaló las acciones que realizarían

estos en el sistema. Basándonos en el análisis realizado, las reuniones con el stakeholder

y su validación, se extrajo los siguientes requisitos tanto funcionales como no funcionales.

Tabla 8 Requisitos funcionales del sistema

Código Nombre

RQF-0001 Iniciar sesión

RQF-0002 Cerrar sesión

RQF-0003 Interfaz de usuario propia

RQF-0004 Reportar un caso

RQF-0005 Reportar una incidencia

RQF-0006 Gestionar casos

RQF-0007 Gestionar incidencias

RQF-0008 Gestionar información sobre convivencia escolar

RQF-0009 Administrar datos sensibles.


En la tabla 8, se muestra los nombres de los requisitos funcionales y su codificación, se

procedió luego con la especificación de requisitos, detallando cada requisito funcional.

También, se señala su origen (si nació en el análisis inicial o mediante una solicitud del

stakeholder) y su situación (si es que fue modificado o no sufrió alteraciones).

Adicionalmente se colocan comentarios en algunos de los requisitos para dejar en claro

algunos casos especiales y/o precondiciones para los cuales fueron tomados en cuenta,

así como para los usuarios a los que van dirigidos.

93

Tabla 9 Detalles del requisito funcional RQF-0001

RQF-0001 Iniciar sesión

Detalle El sistema administra el acceso a la aplicación. Los usuarios acceden al sistema móvil utilizando su correo electrónico de Pamer ([email protected]) y su contraseña.

Origen Requisito inicial

Situación Sin modificaciones



RQF-0002 Cerrar sesión

Detalle El sistema permite al usuario cerrar su sesión desde el menú principal.





RQF-0003 Interfaz de usuario propia

Detalle El sistema mostrará una interfaz de usuario propia para cada usuario según su cargo o rol en la comunidad educativa en el sistema operativo Android desde la versión 4.0.3 (API 15)



Comentarios Se tiene 4 perfiles de usuarios establecidos:

- usuarios básicos

- usuarios tutores

- usuarios psicólogos

- usuarios observadores.


mailto:[email protected]

94


RQF-0004 Reportar un caso

Detalle El sistema permite que todos los usuarios puedan reportar un caso de bullying y/o violencia escolar a través de la aplicación móvil una vez que inició sesión.



Comentarios Los usuarios deben ingresar la fecha que ocurrió, la sección a la que corresponde, una descripción del caso, y de manera opcional pueden adicionar pruebas(imágenes) sus reportes de casos.


El requisito de reportar un caso a través de la aplicación que se detalla en la tabla 12 es

unos de los que poseen mayor prioridad para la institución.


RQF-0005 Reportar una incidencia

Detalle El sistema permite que los usuarios tutores y psicólogos pueden reportar una incidencia a través de la aplicación móvil una vez que han iniciado sesión.



Comentarios En caso del usuario tutor, este puede reportar la incidencia a partir de un caso que recibió en su sección.

En caso de los usuarios psicólogos, estos pueden reportar una incidencia directamente.

Los usuarios deben ingresar una descripción (psicólogos) o descargo (tutores), y de manera opcional pueden adicionar pruebas(imágenes) sus reportes de incidencias.


El requisito de reportar una incidencia a partir de un caso o directamente por el área de

psicología a través de los psicólogos, usando la aplicación, se detalla en la tabla 11 y tiene

prioridad alta para la institución, pues es la materia prima para la generación del libro de

incidencias.

95


RQF-0006 Gestionar casos

Detalle El sistema permite que los usuarios observadores y tutores pueden consultar los casos reportados desde la aplicación móvil.

El usuario tutor al recibir un caso toma la decisión de reportarlo como incidencia o archivar el caso, en ambos casos la información se almacena en un repositorio virtual.



Comentarios El usuario tutor visualiza todos los casos correspondientes a su sección, mientras el usuario observador puede visualizar los casos correspondientes a todas las secciones.

Al reportar como incidencia o archivar el caso, el usuario tutor debe dar su descargo y de manera opcional adicionar una prueba(imágenes) en su descargo.

En los reportes de casos e incidencias, no se puede evidenciar quien realizó el reporte del caso (protegiendo la anonimidad de quien reporta).



RQF-0007 Gestionar incidencias

Detalle El sistema permite que los usuarios observadores y psicólogos pueden consultar las incidencias reportadas desde la aplicación móvil.

El usuario psicólogo al recibir la incidencia toma la decisión de inscribirlo en el libro o archivar la incidencia, la información se almacena en un repositorio virtual.

El usuario psicólogo puede remover una incidencia del libro y etiquetarla como archivada.



Comentarios Al inscribir, archivar o remover, el usuario psicólogo debe dar su descargo y de manera opcional adicionar una prueba (imágenes) en su descargo.

Al remover la incidencia se modifica el descargo dado inicialmente, de manera que contienen el descargo anterior y el nuevo.


96


RQF-0008 Gestionar información sobre convivencia escolar

Detalle El sistema permite que el usuario psicólogo puede enviar información sobre la convivencia escolar libre de violencia en las escuelas desde la aplicación móvil.

El sistema permite que todos los usuarios pueden visualizar la información enviada en la aplicación móvil.



Comentarios La información contiene de manera obligatoria título y descripción. Además, de manera opcional puede incluir una imagen y/o un enlace.

La información enviada depende exclusivamente del criterio del psicólogo.



RQF-0009 Administrar datos sensibles

Detalle El sistema almacena en una base de datos toda la información del usuario que realiza un reporte, pero este no puede ser visualizado por los demás para garantizar la anonimidad del testigo o víctima. Son los usuarios de más alto rango (usuarios observadores) en la institución quienes tienen acceso a esta información y pueden enviarla a quienes lo soliciten, cuando ellos lo crean conveniente.



Comentarios Son los usuarios observadores (coordinadores académicos y director) quienes tienen esta posibilidad de compartir datos de los miembros de la comunidad educativa que realizan un reporte de un caso.


El requisito detallado en la tabla 17 se encuentra ligado a la protección de quienes reportan

los casos, pero esta información no puede desaparecer completamente al reportar un caso,

pues en caso de falsas acusaciones, acusaciones muy graves o mal uso de la aplicación

es importante conocer quien realizó dicho reporte y tomarse las medidas correctivas según

políticas que tiene establecida la institución.

97

Para las condiciones y restricciones del sistema (requisitos no funcionales) se tomaron en

cuenta los siguientes:

Tabla 18 Requisitos no funcionales

Código Descripción

RNF-0001 Eficiencia

RNF-0002 Disponibilidad

RNF-0003 Confidencialidad


Conforme a lo señalado en la tabla 18. En cuanto a eficiencia, el sistema debe permitir el

envío de información a través de dispositivos móviles y consulta de esta información a

través de la aplicación móvil un tiempo que dependerá de la velocidad de conexión de

internet, por lo general menor a los 5 segundos.

En cuanto a disponibilidad, este debe estar operativo las 24 horas del día y para una amplia

gama de dispositivo Android para la versión móvil, que va desde la 4.0.3 (API 15) en

adelante.

En seguridad, el sistema debe cumplir con la reglamentación peruana de protección de

datos, así como proveer de anonimidad a los usuarios que reporten un caso. Para en

encriptado de contraseñas se utilizó el encriptado AES. Y para el manejo de los datos de

los miembros de comunidad educativa que reportan un caso, esta información sensible

solamente será observable por el coordinador académico o director.

Usando como insumo los requisitos funcionales y no funcionales, se les asigno una

prioridad, y se validaron por medio del stakeholder, un miembro clave de la comunidad

98

educativa que conoce todos los procesos que realiza la institución y amplia experiencia en

la misma, durante la fase de inicio y la etapa de análisis nos reunimos constantemente

intercambiando información mediante entrevistas y reuniones personales.

Tabla 19 Catálogo de requisitos final

Requisito Tipo Prioridad Estado Validado por (Persona y

fecha)

RQF-0001 Inicial Alta Aceptado Stakeholder (16-05-2018)

RQF-0002 Inicial Baja Aceptado Stakeholder (16-05-2018)






RQF-0008 Inicial Media Aceptado Stakeholder (16-05-2018)


RNF-0001 Inicial Alta Aceptado Stakeholder (16-05-2018)




De la tabla 19, se aprecia que todo el análisis realizado y la captura de requisitos, y sus

detalles, estos fueron trabajados en conjunto con el stakeholder para su comprobación y

aceptación durante la fase de elaboración.

Las constantes reuniones e involucrarse en el contexto donde la aplicación sería

desplegada permitió una captura de requisitos muy sólida, a tal punto que estos

permanecieron inmutables durante todo el proceso.

99

Se planteó, a partir de los requisitos, los siguientes casos de uso para el sistema, teniendo

como base los casos de uso del negocio y los requisitos:

- Iniciar sesión: los usuarios pueden acceder al sistema mediante su correo

institucional a través de la aplicación móvil.

- Cerrar sesión: los usuarios pueden cerrar sesión en su dispositivo.

- Reportar un caso: todos los usuarios pueden reportar casos de bullying y/o violencia

escolar, de manera que el reporte llega al usuario tutor sin que este sepa quien lo

envió.

- Consultar casos: los usuarios tutores pueden consultar los casos reportados de su

sección (los que ha recibido, los que envió como incidencias y los archivados), los

usuarios observadores pueden consultar todos los casos.

- Archivar caso: los usuarios tutores pueden archivar los casos de bullying y/o

violencia escolar que han recibido.

- Reportar una incidencia: los usuarios tutores pueden reportar incidencias a partir

de los casos que han recibido, el usuario psicólogo puede reportar una incidencia

directamente.

- Consultar incidencias: los usuarios de psicólogos y observadores pueden consultar

las incidencias reportadas (las que ha recibido, los que envió al libro y las

archivadas).

- Descargar libro de incidencias: el usuario observador puede descargar en un

archivo Excel las incidencias inscritas en el libro de incidencias.

- Inscribir incidencia: Los usuarios psicólogos pueden agregar incidencias que han

recibido al libro de incidencias.

- Archivar incidencia: Los usuarios psicólogos pueden archivar incidencias que han

recibido.

100

- Remover incidencia: Los usuarios psicólogos pueden remover incidencias del libro

de incidencias y etiquetarlas como archivadas.

- Enviar datos: Los usuarios observadores, pueden acceder a los datos de quienes

han realizado reportes y enviarlos según su criterio a través de la aplicación móvil.

- Enviar información: el usuario psicólogo envía información sobre la convivencia

escolar sin violencia.

- Visualizar información: todos los usuarios visualizan información sobre la

convivencia escolar sin violencia.

Tabla 20 Casos de uso del sistema

Código Caso de uso

CUS-001 Iniciar sesión

CUS-002 Cerrar sesión

CUS-003 Reportar un caso

CUS-004 Consultar casos

CUS-005 Archivar caso

CUS-006 Reportar una incidencia

CUS-007 Consultar incidencias

CUS-008 Descargar Libro de incidencias

CUS-009 Inscribir incidencia

CUS-010 Archivar incidencia

CUS-011 Remover incidencia

CUS-012 Enviar datos

CUS-013 Enviar información

CUS-014 Visualizar información


En la tabla 20, se observa los casos de uso y su codificación designada.

101

Mediante el análisis de los casos de uso, se puede establecer una relación directa con la

especificación de requisitos. En consecuencia, se construyó la matriz de trazabilidad donde

confluyen ambos (ver apéndice H).

4.6 Requisitos

4.6.1 Integración de los casos de uso y actores

Se realizó los casos de uso utilizando el lenguaje de modelado unificado UML mediante el

programa IBM Rational Rose Enterprise Edition versión 7.0

Cabe señalar que, para poder realizar cualquier caso de uso, el usuario debe previamente

haber iniciado sesión.

Figura 28. Caso de uso de inicio y cierre de sesión. Fuente: elaboración propia.

En la figura 28 se observa a la funcionalidad de inicio y cierre de sesión de la aplicación.

102

Figura 29. Casos de uso de reporte de casos e incidencias. Fuente: elaboración propia.

Una vez que el usuario se encuentre con sesión activa en el sistema, se puede apreciar en

la figura 29 como interactúan los diferentes usuarios en el caso de reportar casos e

incidencias, donde todos los tipos de usuarios pueden realizar reportes de casos, pero solo

los usuarios tutores o psicólogos pueden realizar reportes de incidencias.

Los tutores reportan las incidencias a partir de casos que han analizado y los psicólogos lo

pueden hacer directamente.

Usuario básico

(f rom Actors)

Usuario observador

(f rom Actors)

Usuario psicólogo

(f rom Actors)

Reportar una incidencia

(from Reportar una incidencia)

Reportar un caso

(from Reportar un caso)

Iniciar sesión

(from Iniciar sesión)

<<include>>

<<include>>

Usuario tutor

(f rom Actors)

103

Figura 30. Casos de uso de gestión de casos. Fuente: elaboración propia.


la figura 30 como interactúan los diferentes usuarios en el caso de gestionar casos, que

implican consultar, archivar o enviar datos de estos.

El usuario tutor puede consultar los casos correspondientes únicamente a su sección,

mientras el usuario observador puede consultar los casos de todas las secciones.

Se aprecia que el usuario observador posee acceso a los datos de quienes realizan los

reportes y puede compartirlos (Enviar datos).

Archivar caso

(from Archivar caso)

Usuario tutor

(f rom Actors)

Consultar casos

(from Consultar casos)

Enviar datos

(from Enviar datos)

Usuario observador

(f rom Actors)

Iniciar sesión


<<include>>

<<include>>

<<include>>

104

Figura 31. Casos de uso de gestión de incidencias. Fuente: elaboración propia.


la figura 31 como interactúan los diferentes usuarios en el caso de gestionar incidencias,

que implican consultar, archivar, remover o inscribir estas.

Inscribir incidencia

(from Agregar incidencia)

Consultar incidencia

(from Consultar incidencia)

Archivar incidencia

(from Archivar incidencia)

Descargar libro

(from Descargar libro)



Remover incidencia

(from Remover incidencia)

Usuario observador

(f rom Actors)

Iniciar sesión


Usuario psicólogo

(f rom Actors)

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

105

Figura 32. Casos de uso de gestión de información de convivencia escolar. Fuente:

elaboración propia.


la figura 32 como interactúan los diferentes usuarios en el caso de gestionar la información

sobre convivencia escolar, que implican enviar y visualizar esta.

Todos los usuarios pueden visualizar la información que envíe el área de psicología

mediante sus psicólogos. Son los psicólogos los que envían esta información de acuerdo

con su criterio.

Teniendo como insumo la matriz de trazabilidad de requisitos y los actores encontrados,

se procedió a realizar el diagrama de casos de uso del sistema.

Iniciar sesión


Usuario básico

(f rom Actors)

Usuario observador

(f rom Actors)

Visualizar información

(from Visualizar información)

Usuario tutor

(f rom Actors)

<<include>>

Enviar información

(from Enviar información)

Usuario psicólogo

(f rom Actors)

<<include>>

106

Figura 33.Diagrama general de casos de uso. Fuente: elaboración propia.

En la figura 33 se puede apreciar la integración entre los casos de uso y actores del

sistema, obviando los casos de iniciar y cerrar sesión, para facilitar su visualización.

4.6.2 Especificación de los casos de uso

Los casos de uso fueron descritos de manera textual y detallada para indicar los actores

que participan en este, un resumen de lo que representa, las condiciones iniciales para dar

inicio, las condiciones finales, los casos de uso necesarios para que este inicie, los

alternativo y de los que hereda funciones. Finalmente, el flujo de eventos, el cual describe

paso a paso la interacción del usuario con el sistema.

Visualizar información

(from Visualizar información)

Enviar datos

(from Enviar datos)

Consultar incidencia

(from Consultar incidencia)

Enviar información

(from Enviar información)

Inscribir incidencia

(from Agregar incidencia)

Archivar incidencia

(from Archivar incidencia) Remover incidencia

(from Remover incidencia)

Usuario básico

(f rom Actors)

Usuario psicólogo

(f rom Actors)



Consultar casos

(from Consultar casos)

Reportar un caso

(from Reportar un caso)

Usuario tutor

(f rom Actors)

Archivar caso

(from Archivar caso)

Descargar libro

(from Descargar libro)

Usuario

observador(f rom Actors)

<<include>>

107

Tabla 21. Especificación del caso de uso CUS-001.

CUS-001 Iniciar sesión

Actores Usuario básico, usuario tutor, usuario psicólogo y usuario observador.

Resumen Permite al usuario registrado en el sistema, ingresar al sistema mediante su correo institucional ([email protected]) y su contraseña.

Precondiciones El usuario debe estar registrado en el sistema.

Postcondiciones El usuario ingresa al sistema y visualiza una interfaz según su rol en la institución.

Se almacena su sesión en el dispositivo.

Incluye -

Extiende -

Hereda -

Flujo de eventos 1. El caso de uso inicia cuando el usuario inicia la aplicación móvil.

2. El usuario ingresa su usuario y contraseña.

3. El sistema valida sus datos.

3.1. Si los datos son correctos, se muestra un mensaje: “sesión iniciada”

3.2. Si los datos fueran incorrectos, el usuario visualiza un mensaje: “usuario o contraseña incorrecta” y vuelve al paso 2.

4. El usuario visualiza la interfaz correspondiente a su rol o cargo.

5. Finaliza el caso de uso.


Los datos de los usuarios están ubicados en una base de datos externa al dispositivo móvil,

a la cual se hace las llamadas mediante servicios REST, utilizando JSON como lenguaje

de transferencia de datos, la contraseña está encriptada con el algoritmo de seguridad

AES.

Esto permite en cuanto a escalabilidad y compatibilidad del sistema: permitir el uso de otros

medios como aplicaciones de escritorio o páginas web para gestionar casos en la

institución y su acoplamiento a otros sistemas paralelos que pueden ser implementados.


108

Tabla 22. Especificación del caso de uso CUS-002

CUS-002 Cerrar sesión


Resumen Permite al usuario con sesión activa, cerrar esta.


El usuario debe estar con sesión activa en el sistema.

Postcondiciones El usuario sale del sistema.

Incluye Iniciar sesión

Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona el menú.

2. El usuario selecciona la opción de cerrar sesión.

3. El sistema cierra la sesión activa.

4. El usuario visualiza la interfaz de iniciar sesión.


Tabla 23. Especificación del caso de uso CUS-003

CUS-003 Reportar un caso


Resumen Permite a los usuarios reportar casos de bullying y/o violencia escolar de los cuales son víctimas y/o testigos.



Postcondiciones Se envía el reporte, el usuario tutor recibe el caso reportado y es almacenado en un repositorio virtual siendo etiquetado como pendiente.


Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona del menú la opción REPORTAR UN CASO.

2. El usuario visualiza un formulario con un contenedor de texto donde describe el caso, una casilla donde selecciona la sección del tutor al cual enviar el reporte, una casilla donde selecciona la fecha y un botón de adjuntar un archivo en la que

109

tiene la posibilidad de adicionar una prueba(imagen) y la opción REPORTAR.

3. El usuario completa todos los campos (adjuntar un archivo es opcional) y selecciona la opción REPORTAR.

4. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas reportar este caso?”

4.1. El usuario acepta, se envía el reporte al tutor de la sección elegida y recibe una notificación de “Reporte enviado”.

4.2. El usuario no acepta y se repite el proceso desde el paso 2.


Tabla 24 Especificación del caso de uso CUS-004

CUS-004 Consultar casos

Actores Usuario tutor y usuario observador.

Resumen Permite a los usuarios consultar el repositorio con los casos reportados (pendientes, reportados y archivados).



Postcondiciones El usuario visualiza los casos.


Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona del menú la opción CONSULTAR CASOS

1.1. Si el usuario es tutor, el sistema muestra un listado con los casos reportados de su sección que contiene: código, fecha, estado (pendiente, reportado o archivado), descripción y archivo adjunto (icono).

1.2. Si el usuario es observador, el sistema muestra un listado con los casos reportados que contiene: código, fecha, estado (pendiente, reportado o archivado), sección, descripción y archivo adjunto (icono).

2. El usuario selecciona el caso que desea consultar.

3. El sistema muestra: el código del caso, el estado, la fecha que fue reportado, la fecha en que ocurrió el caso, la descripción del caso, la prueba (imagen) si la hubiera con la opción de descarga. Si el caso tuviera estado reportado o archivado, mostrará el descargo del caso y la prueba (imagen) con la opción de descarga. Finalmente, la opción: REGRESAR.

3.1. Si el usuario selecciona la opción REGRESAR, el sistema lo enviará al listado de casos.


110


CUS-005 Archivar caso

Actores Usuario tutor.

Resumen Permite al usuario archivar un caso recibido.



Postcondiciones El caso es almacenado en un repositorio virtual, siendo etiquetado su estado como archivado.


Extiende -

Hereda -

Flujo de eventos 1. El usuario de tutor selecciona la opción REVISAR CASOS del menú principal.

2. El sistema muestra un listado con los casos reportados con estado pendiente y que pertenecen a la sección del usuario que inicio sesión, que contiene: código, fecha, descripción y archivo adjunto (icono).

3. El usuario tutor selecciona el caso que desea analizar. 4. El sistema le muestra: el código del caso, el estado (pendiente),

la fecha que fue reportado, la fecha en que ocurrió el caso, la descripción del caso, la prueba (imagen) si la hubiera con la opción de descarga, luego un campo de texto donde da su descargo y la opción de adjuntar una prueba (imagen) que es opcional. Finalmente, las opciones: REPORTAR COMO INCIDENCIA, ARCHIVAR y CANCELAR.

5. El usuario describe sus razones para no enviar el caso al área de psicología, tiene la posibilidad de adjuntar un archivo (imagen).

6. El usuario selecciona la opción ARCHIVAR 7. El sistema muestra un mensaje de confirmación: “¿Seguro que

deseas archivar este caso?” 7.1. El usuario acepta y recibe una notificación de “Caso

archivado”. 7.2. El usuario no acepta y se repite el proceso desde el paso

4.


111


CUS-006 Reportar una incidencia

Actores Usuario de nivel 2 y usuario psicólogo.

Resumen Permite al usuario enviar un caso recibido como incidencia.



Postcondiciones El caso es almacenado en un repositorio virtual, siendo etiquetado su estado como reportado.

Se envía la incidencia al usuario psicólogo, que es almacenada en el repositorio virtual siendo etiquetada como pendiente.


Extiende -

Hereda -

Flujo de eventos 1. El usuario de tutor selecciona la opción REVISAR CASOS del menú principal.

2. El sistema muestra un listado con los casos reportados con estado pendiente y que pertenecen a la sección del usuario que inicio sesión, que contiene: código, fecha, descripción y archivo adjunto (icono).

3. El usuario de nivel 2 selecciona el caso que desea analizar. 4. El sistema le muestra: el código del caso, el estado (pendiente),

la fecha que fue reportado, la fecha en que ocurrió el caso, la descripción del caso, la prueba (imagen) si la hubiera con la opción de descarga, luego un campo de texto donde da su descargo y la opción de adjuntar una prueba (imagen) que es opcional. Finalmente, las opciones: REPORTAR COMO INCIDENCIA, ARCHIVAR y CANCELAR.

5. El usuario describe sus razones para enviar el caso al área de psicología, tiene la posibilidad de adjuntar un archivo (imagen).

6. El usuario selecciona la opción REPORTAR COMO INCIDENCIA

7. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas reportar esta incidencia?” 7.1. El usuario acepta y recibe una notificación de “Incidencia

reportada”. 7.2. El usuario no acepta y se repite el proceso desde el paso

4.

Flujo alternativo 1. El usuario psicólogo selecciona del menú la opción REPORTAR UNA INCIDENCIA.

2. El usuario visualiza un formulario con un contenedor de texto donde describe la incidencia, una casilla donde selecciona la fecha y un botón de adjuntar un archivo en la que tiene la posibilidad de adicionar una prueba(imagen) y la opción REPORTAR.

112

3. El usuario completa todos los campos (adjuntar es opcional) y selecciona la opción REPORTAR.

4. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas reportar esta incidencia?”

4.1. El usuario acepta, se envía la incidencia al usuario psicólogo y recibe una notificación de “Incidencia reportada”.




CUS-007 Consultar incidencia

Actores Usuario psicólogo y usuario observador.

Resumen Permite a los usuarios consultar el repositorio con las incidencias reportadas (pendiente, inscrita y archivada).



Postcondiciones El usuario visualiza las incidencias.


Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona del menú la opción CONSULTAR INCIDENCIAS

2. El sistema muestra un listado con las incidencias reportadas que contiene: código, fecha, estado (pendiente, inscrita y archivada), sección (si hubiera sido hecha por un tutor, no aparecerá si fue una incidencia creada por un usuario psicólogo), descripción y archivo adjunto (icono).

3. El usuario selecciona la incidencia que desea consultar.

4. El sistema le muestra: el código de la incidencia. Si la incidencia proviene de un caso, mostrará el código del caso y la sección, en caso contrario señalará que fue reportada por el área de psicología. Luego la fecha que fue reportada, la descripción de la incidencia (descargo del tutor o descripción que da el psicólogo si él hubiera reportado la incidencia directamente) y el archivo multimedia recibido si lo hubiera con la opción de descarga. Si la incidencia tuviera estado inscrita o archivada, mostrará el descargo de la incidencia y la prueba (imagen) con la opción de descarga. Finalmente, la opción: REGRESAR.

4.1. Si el usuario selecciona la opción REGRESAR, el sistema le envía al listado de incidencias.


113


CUS-008 Descargar libro de incidencias

Actores Usuario observador

Resumen Permite al usuario inscribir una incidencia en el libro de incidencias.



Postcondiciones La incidencia es almacenada en el repositorio virtual, siendo etiquetado su estado como inscrita.

Incluye Iniciar sesión y consultar incidencia

Extiende -

Hereda -

Flujo de eventos 1. El usuario observador selecciona del menú la opción LIBRO DE INCIDENCIAS.

2. El sistema muestra un botón con nombre DESCARGAR LIBRO DE INCIDENCIAS y un listado con las incidencias con estado de inscritas que contiene: código, fecha, estado, sección (si hubiera sido hecha por un tutor, no aparecerá si fue una incidencia creada por un usuario psicólogo), descripción y archivo adjunto (icono).

3. El usuario selecciona la opción DESCARGAR LIBRO DE INCIDENCIAS.

3.1. Se descarga al dispositivo un archivo Excel conteniendo las incidencias inscritas, este contiene el id, fecha, descripción y descargo del caso.



CUS-009 Inscribir incidencia

Actores Usuario psicólogo

Resumen Permite al usuario inscribir una incidencia en el libro de incidencias.



Postcondiciones La incidencia es almacenada en el repositorio virtual, siendo etiquetado su estado como inscrita.


Extiende -

114

Hereda -

Flujo de eventos 4. El usuario de psicólogo selecciona la opción REVISAR INCIDENCIAS del menú principal.

5. El sistema muestra un listado con las incidencias reportadas con estado pendiente, que contiene: código, fecha, descripción, sección (si hubiera sido hecha por un tutor, no aparecerá si fue una incidencia creada por un usuario psicólogo), descargo y archivo adjunto (icono).

6. El usuario selecciona la incidencia que desea analizar. 7. El sistema le muestra: el código de la incidencia. Si la

incidencia proviene de un caso, mostrará el código del caso y la sección, en caso contrario señalará que fue reportada por el área de psicología. Luego la fecha que fue reportada, la descripción de la incidencia (descargo del tutor o descripción que da el psicólogo si él hubiera reportado la incidencia directamente) y el archivo multimedia recibido si lo hubiera con la opción de descarga. Luego un campo para que ingrese su descargo y la opción de agregar una prueba (imagen) que es opcional. Finalmente, las opciones: INSCRIBIR, ARCHIVAR y REGRESAR.

8. El usuario hace su descargo y puede agregar una prueba, luego selecciona la opción INSCRIBIR

9. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas inscribir esta incidencia?” 9.1. El usuario acepta, se inscribe la incidencia y recibe una

notificación de “Incidencia inscrita”. 9.2. El usuario no acepta y se repite el proceso desde el paso

4.



CUS-010 Archivar incidencia


Resumen Permite al usuario archivar una incidencia recibida.



Postcondiciones La incidencia es almacenada en el repositorio virtual, siendo etiquetada como archivada en su estado.


Extiende -

Hereda -

Flujo de eventos 1. El usuario de psicólogo selecciona la opción REVISAR INCIDENCIAS del menú principal.

2. El sistema muestra un listado con las incidencias reportadas con estado pendiente, que contiene: código, fecha,

115

descripción, sección (si hubiera sido hecha por un tutor, no aparecerá si fue una incidencia creada por un usuario psicólogo), descargo y archivo adjunto (icono).

3. El usuario selecciona la incidencia que desea analizar. 4. El sistema le muestra: el código de la incidencia. Si la

incidencia proviene de un caso, mostrará el código del caso y la sección, en caso contrario señalará que fue reportada por el área de psicología. Luego la fecha que fue reportada, la descripción de la incidencia (descargo del tutor o descripción que da el psicólogo si él hubiera reportado la incidencia directamente) y el archivo multimedia recibido si lo hubiera con la opción de descarga. Luego un campo para que ingrese su descargo y la opción de agregar una prueba (imagen) que es opcional. Finalmente, las opciones: INSCRIBIR, ARCHIVAR y CANCELAR.

5. El usuario hace su descargo y puede agregar una prueba, luego selecciona la opción ARCHIVAR

6. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas archivar esta incidencia?” 6.1. El usuario acepta, se inscribe la incidencia y recibe una

notificación de “Incidencia archivada”. 6.2. El usuario no acepta y se repite el proceso desde el paso

4.



CUS-011 Remover incidencia


Resumen Permite al usuario remover una incidencia del libro de incidencias, cambiando su estado de inscrita a archivada en el repositorio virtual.



Postcondiciones La incidencia es almacenada en el repositorio virtual, su descargo es modificado, adicionando las razones para ser removida y siendo etiquetado su estado como archivada.


Extiende -

Hereda -

Flujo de eventos 1. El usuario de psicólogo selecciona del menú la opción REMOVER INCIDENCIA del menú principal.

2. El sistema muestra un listado con las incidencias inscritas en el libro de incidencias, que contiene: código, fecha, descripción, sección (si hubiera sido hecha por un tutor, no aparecerá si fue una incidencia creada por un usuario psicólogo), descargo y archivo adjunto (icono).

116

3. El usuario selecciona la incidencia que desea remover. 4. El sistema le muestra: el código de la incidencia. Si la

incidencia proviene de un caso, mostrará el código del caso y la sección, en caso contrario señalará que fue reportada por el área de psicología. Luego la fecha que fue reportada, la descripción de la incidencia (descargo del tutor o descripción que da el psicólogo si él hubiera reportado la incidencia directamente) y el archivo multimedia recibido si lo hubiera con la opción de descarga. Luego un campo para que ingrese su descargo y la opción de agregar una prueba (imagen) que es opcional. Luego un campo para que ingrese su descargo y la opción de agregar una prueba (imagen) que es opcional. Finalmente, las opciones: REMOVER y CANCELAR

5. El usuario escribe su descargo y puede adjuntar una imagen, luego selecciona la opción REMOVER.

6. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas remover esta incidencia?” 6.1. El usuario acepta, la incidencia cambia su estado como

archivada, se modifica su descargo y recibe una notificación de “Incidencia removida”. En caso se agregó una prueba, esta reemplaza a la anterior.




CUS-012 Enviar datos

Actores Usuario observador

Resumen Permite al usuario tener acceso a los datos de quienes realizan reportes y enviarlos a terceros.



Postcondiciones Los datos de quien ha reportado el caso se copian al portapapeles.


Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona la opción ENVIAR DATOS del menú principal.

2. El sistema muestra un listado con los casos reportados que contiene: código, fecha, estado (pendiente, reportado o archivado), sección, descripción y archivo adjunto (icono).

3. El usuario selecciona el caso del que desea enviar su información.

117

4. El sistema muestra un mensaje de confirmación: “¿Está seguro de que desea enviar la información de este caso?” 4.1. El usuario acepta, la incidencia cambia su estado como

archivada, se modifica su descargo y recibe una notificación de “Incidencia removida”. En caso se agregó una prueba, esta reemplaza a la anterior.


5. El sistema muestra la opción para compartir los datos a través de diversas aplicaciones como: correo, redes sociales, etc.

6. El usuario decide como compartir o almacenar la información (esta información es un texto plano).



CUS-013 Enviar información


Resumen Permite al usuario enviar información que contiene título, texto y opcionalmente una imagen o enlace, para que sea visualizada por los usuarios de nivel 1.



Postcondiciones La información es almacenada en un repositorio virtual.


Extiende -

Hereda -

Flujo de eventos 1. El usuario selecciona la opción ENVIAR INFORMACIÓN del menú principal.

2. El sistema le muestra un formulario donde debe colocar título, texto, opcionalmente una imagen y/o enlace y la opción ENVIAR INFORMACIÓN.

3. El usuario selecciona la opción ENVIAR INFORMACIÓN luego de completar los campos requeridos.

4. El sistema muestra un mensaje de confirmación: “¿Seguro que deseas enviar esta información?” 4.1. El usuario acepta, el sistema almacena la información en

un repositorio virtual y recibe una notificación de “Información enviada”.



118


CUS-014 Visualizar información

Actores Usuario de nivel 1

Resumen Permite a los usuarios ver información que ha enviado el área de psicología en sus dispositivos móviles a través de la aplicación móvil del sistema.



Postcondiciones El usuario ha visualizado la información enviada.


Extiende -

Hereda -

Flujo de eventos

1. El usuario selección la opción CONVIVENCIA ESCOLAR.

2. El sistema le muestra un listado con la información enviada por el área de psicología, mostrando título, texto descriptivo e imágenes o enlaces si los tuviera.


4.7 Modelo de Análisis

4.7.1 Análisis de la Arquitectura

Se opto por basarse en la arquitectura conocida como Clean Architecture, que refiere

abstracción de capas, donde las capas externas utilizan a las capas internas y estas a su

vez no hacen llamados a las capas externas.

En base a la obra de Martin (2007) donde hace énfasis en la separación de capas

considerando, se realizó una separación de clases siguiendo el patrón de diseño MVVM,

donde la capa más externa es la capa view que contiene las actividades y fragmentos, la

capa model que contiene los objetos del dominio (entidades) y repositorios (que es una

especie de DAO), esta última es considerada una buena práctica y recomendada por

Android (2018b). Se aprecia también la capa intermedia view model que simula la capa

119

“controlador” del patrón MVC o “presentador” de MVP, con la diferencia que este puede ser

llamado por múltiples vistas y no tiene conocimiento de estas.

Figura 34. Capas del patrón MVVM. Fuente: elaboración propia.

Lo mostrado en la figura 34 muestra parte del esquema que se utiliza la arquitectura Clean

haciendo una variante en cuanto a la capa intermediaria entre las vistas y las entidades,

donde entra la capa view model, siguiendo el patrón de desarrollo MVVM.

Se tienen 3 capas bien definidas: En la capa model se trabajó con un servidor que aloja los

datos en una base de datos que utiliza MySQL y para llevar a cabo la comunicación de

datos con la aplicación se utiliza la arquitectura REST con JSON, conteniendo dentro del

servidor su propia API escrito en lenguaje PHP. Esta separación en capas permite al

sistema trabajar con otros motores de bases de datos, sin necesidad de modificarse el

código, solo el archivo de configuración que contiene la ruta de la base de datos.

Model

View-model

View Activity / Fragment

View Model

Repository

WebServices Entities

120

Las capas view y view model se encargan de la presentación gráfica al usuario y la lógica

del negocio respectivamente, estas se comunican utilizando LiveData facilitando las

labores de testeo y escalabilidad de la aplicación para el futuro.

Figura 35. Diagrama de paquetes con sus respectivas capas. Fuente: elaboración propia.

En la figura 35, se aprecia la conformación de los paquetes, si bien se aprecia la capa

model y view (ui), la capa view model no se puede apreciar, puesto que los archivos que lo

componen se encuentran dentro de los paquetes de la interfaz de usuario (ui).

Mediante las iteraciones se determinó que era la forma más eficiente para su ubicación

debido a la generación de fragmentos con su archivo view model por parte del IDE Android

Studio, sin necesidad de declarar muchos métodos como públicos.

model

ui

entities(from model)

repositories(from model)

retrofit adaptersEstos paquetes tienen funciones de complemento

cases

(from ui)

informations

(from ui)

incidents

(from ui)

login

(from ui)

main

(from ui)

121

Figura 36. Distribución de los archivos View-Model. Fuente: elaboración propia.

En la figura 36 se observa cómo están ubicados los archivos que componen la capa view

model dentro del proyecto. Cabe mencionar que el uso de un patrón de diseño no es

obligatorio, pero es recomendado su uso como un estándar en el desarrollo de programas,

este es una guía y no una norma rígida que seguir al pie de la letra, dando flexibilidad a los

proyectos de desarrollo.

4.8 Diseño y realización de los casos de uso

Teniendo como insumo inicial a los flujos descritos en la especificación de casos de uso,

se procedió a realizar las vistas de interacción, conteniendo los diagramas de clases, de

colaboración y secuencia para cada caso de uso.

La realización de casos de uso incluye los diagramas de clases, colaboración y secuencia

utilizando el lenguaje de modelado unificado y a través del programa IBM Rational Rose

Enterprise Edition versión 7.0.

122

4.8.1 CUS-001 Iniciar sesión

Figura 37. Diagrama de clases de: CUS-001 Iniciar sesión. Fuente: elaboración propia.

Figura 38. Diagrama de colaboración de: CUS-001 Iniciar sesión. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)

Usuario


Usuario tutor

(f rom Actors)

Usuario básico

(f rom Actors)

LoginViewModel(f rom login)

UserLoginActivity

(f rom ui)

LoginFragment

(f rom login)

MainActivity

(f rom ui)

mainFragment

(f rom main)

usuario : LoginActivity

: LoginViewModel

: MainActivity

: User

1: Ingresa correo y contraseña 2: Tranferir datos

3: Valida las credenciales y captura el cargo

4: Almacena datos del usuario

5: Muestra la actividad principal de acuerdo con el cargo

123

Figura 39. Diagrama de secuencia de: CUS-001 Iniciar sesión. Fuente: elaboración propia.

4.8.2 CUS-002 Cerrar sesión

Figura 40. Diagrama de clases de: CUS-002 Cerrar sesión. Fuente: elaboración propia.

LoginViewModel(f rom login)

Usuario básico

(f rom Actors)

Usuario observador

(f rom Actors)

Usuario psicólogo

(f rom Actors)

MainActivity(f rom ui)

Usuario tutor

(f rom Actors)

LoginFragment

(f rom login)

LoginActivity

(f rom ui)

124

Figura 41. Diagrama de colaboración de: CUS-002 Cerrar sesión. Fuente: elaboración propia.

Figura 42. Diagrama de secuencia de: CUS-002 Cerrar sesión. Fuente: elaboración propia.

usuario

: MainActivity

: LoginViewModel

: LoginActivity

1: Selecciona la

opcion de cerrar

sesión

2: llama a la función

cerrar sesión

3: Se eliminan los datos del

usuario en el dispositivo y

se envía a la actividad de

inicio de sesión

125

4.8.3 CUS-003 Reportar un caso

Figura 43. Diagrama de clases de: CUS-003 Reportar un caso. Fuente: elaboración propia.

Figura 44. Diagrama de colaboración de: CUS-003 Reportar un caso. Fuente: elaboración propia.

Usuario básico

(f rom Actors)

Usuario observador

(f rom Actors)

Usuario psicólogo

(f rom Actors)

Usuario tutor

(f rom Actors)


Section(f rom entit ies)

ReportCaseFragment

(f rom cases)

SectionRepository(f rom repositories)

<<repository>>

CaseViewModel(f rom cases)

CaseRepository(f rom repositories)

<<repository>>

usuario

: MainActivity

: CaseViewModel

: ReportCaseFragment

3: Se cargan las

secciones en el

formulario

1: El usuario

selecciona la

opcion de

menu

2: Selcciona la opcion reportar caso

4: El usuario

envía su

reporte

: mainFragment

5: Se muestra un

mensaje de

confirmación y se

muestra la interfaz

de inicio

126

Figura 45. Diagrama de secuencia de: CUS-003 Reportar un caso. Fuente: elaboración propia.

4.8.4 CUS-004 Consultar casos

Figura 46. Diagrama de clases de: CUS-004 Consultar casos. Fuente: elaboración propia.

Usuario tutor

(f rom Actors)

Case(f rom entit ies)

ConsultCasesFragment

(f rom cases)

CaseRepository

(f rom repositories)

SeeCaseFragment

(f rom cases)



Usuario


127

Figura 47. Diagrama de colaboración de: CUS-004 Consultar casos. Fuente: elaboración propia.

Figura 48. Diagrama de secuencia de: CUS-004 Consultar casos. Fuente: elaboración propia.

usuario

: MainActivity : ConsultCasesFragment

: CaseViewModel

: SeeCaseFragment

4: se devuelve la llamada

7: se devuelve el caso

seleccionado

1: Selecciona el menu

2: Selecciona consultar casos

3: se llama a la funcion de

consultar casos

5: se muestra los casos

6: se selecciona un caso

8: se visualiza el caso a detalle

128

4.8.5 CUS-005 Archivar caso

Figura 49. Diagrama de clases de: CUS-005 Archivar caso. Fuente: elaboración propia.

Figura 50. Diagrama de colaboración de: CUS-005 Archivar caso. Fuente: elaboración propia.

Usuario tutor

(f rom Actors)

Case

(f rom entit ies)



<<repository>>

CheckCaseFragment

RespondCaseFragment

(f rom cases)


tutor : Usuario tutor : MainActivity : CheckCaseFragment

: RespondCaseFragment

: CaseViewModel

4: devuelve la llamada

1: Selecciona

el menu 2: Selecciona revisar

casos

3: Se llama a la funcion de

consultar casos del tutor con

estado pendiente

5: Se muestran los casos con

estado pendiente del tutor

6: Selecciona un caso

para responder

7: Se devuelve el caso seleccionado

8: se visualiza el

caso y el

formulario para

responder

9: Responde al caso archivándolo

10: Regresa al listado de

casos pendientes

129

Figura 51. Diagrama de secuencia de: CUS-005 Archivar caso. Fuente: elaboración propia.

4.8.6 CUS-006 Reportar una incidencia

Figura 52. Diagrama de clases de: CUS-006 Reportar una incidencia. Fuente: elaboración propia.

Usuario tutor

(f rom Actors)

Case

(f rom entit ies)



<<repository>>

CheckCaseFragment


RespondCaseFragment

(f rom cases)

130

Figura 53. Diagrama de colaboración de: CUS-006 Reportar una incidencia. Fuente: elaboración propia.

Figura 54. Diagrama de secuencia de: CUS-006 Reportar una incidencia. Fuente: elaboración propia.

tutor : MainActivity : CheckCaseFragment

: CaseViewModel

: RespondCaseFragment


2: Selecciona la

opcion revisar

casos

3: Se llama a la funcion de

consultar casos del tutor con

estado pendiente

4: devuelve la llamada

5: Se muestran los casos

con estado pendiente del

tutor

6: Selecciona un

caso para

responder

7: Se devuelve el caso seleccionado

8: se visualiza el caso y el

formulario para responder

9: Responde al caso reportandolo como

incidencia

10: Regresa al listado de

casos pendientes

131

Figura 55. Diagrama de clases de: CUS-006 Reportar una incidencia (Flujo alterno). Fuente: elaboración propia.

Figura 56. Diagrama de colaboración de: CUS-006 Reportar una incidencia (Flujo alterno). Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)


ReportIncidentFragment

(f rom incidents)

IncidentViewModel(f rom incidents)

IncidentRepository(f rom repositories)

<<repository>>

psicólogo : MainActivity

: IncidentViewModel

: ReportIncidentFragment

: mainFragment


2: Selecciona la opcion

reportar incidencia

4: Se envía un mensaje de

confirmación y se visualiza la

interfaz de inicio

3: Reporta la incidencia

132

Figura 57. Diagrama de secuencia de: CUS-006 Reportar una incidencia (Flujo alterno). Fuente: elaboración propia.

4.8.7 CUS-007 Consultar incidencia

Figura 58. Diagrama de clases de: CUS-007 Consultar incidencia. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)

Usuario



ConsultIncidentFragment

(f rom incidents)

SeeIncidentFragment

(f rom incidents)

Incident(f rom entit ies)



<<repository>>

133

Figura 59. Diagrama de colaboración de: CUS-007 Consultar incidencia. Fuente: elaboración propia.

Figura 60. Diagrama de secuencia de: CUS-007 Consultar incidencia. Fuente: elaboración propia.

usuario : MainActivity : ConsultIncidentFragment

: IncidentViewModel

: SeeIncidentFragment

4: Se devuelve la llamada

1: Selecciona el

menu


consultar incidencias


consultar incidencia

5: Se muestra

las

incidencias

6: Se selecciona una

incidencia

7: Se devuelve la incidencia seleccionada

8: Se visualiza la incidencia a

detalle

134

4.8.8 CUS-008 Descargar libro de incidencias

Figura 61. Diagrama de clases de: CUS-008 Descargar libro de incidencias. Fuente: elaboración propia.

Figura 62. Diagrama de colaboración de: CUS-008 Descargar libro de incidencias. Fuente: elaboración propia.

Incident

(f rom entit ies)

Usuario observador

(f rom Actors)


<<repository>>



IncidentBookFragment

(f rom incidents)

usuario : MainActivity : IncidentBookFragment

: IncidentViewModel


1: Selecciona el menu2: Selecciona la opción Libro de

incidencias


consultar incidencia 5: Se muestra las

incidencias con

estado: "inscritas"


descargar libro

7: Se descarga el lirbo

en formato Excel en el

dispositivo

135

Figura 63. Diagrama de secuencia de: CUS-008 Descargar libro de incidencias. Fuente: elaboración propia.

4.8.9 CUS-009 Inscribir incidencia

Figura 64. Diagrama de clases de: CUS-009 Inscribir incidencia. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)

Incident

(f rom entities)



<<repository>>

CheckIncidentFragment(f rom incidents)

RespondIncidentFragment

(f rom incidents)


136

Figura 65. Diagrama de colaboración de: CUS-009 Inscribir incidencia. Fuente: elaboración propia.

Figura 66. Diagrama de secuencia de: CUS-009 Inscribir incidencia. Fuente: elaboración propia.

usuario : MainActivity : CheckIncidentFragment

: IncidentViewModel

: RespondIncidentFragment


7: Devuelve la incidencia seleccionada

1: Selecciona el menu2: Selecciona la opción

revisar incidencias

3: se llama a la funcion de consultar

incidencia5: Se muestra las

incidencias con estado:

"pendiente"

6: Selecciona la

incidencia a responder

10: Se retorna al listado

de incidencias

8: Se visualiza la incidencia a detalle y el

formulario para responder a esta

9: Se rellena los campos y se inscribe la incidencia

137

4.8.10 CUS-010 Archivar incidencia

Figura 67. Diagrama de clases de: CUS-010 Archivar incidencia. Fuente: elaboración propia.

Figura 68. Diagrama de colaboración de: CUS-010 Archivar incidencia. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)

Incident

(f rom entities)



<<repository>>

CheckIncidentFragment(f rom incidents)

RespondIncidentFragment

(f rom incidents)


usuario : MainActivity : CheckIncidentFragment

: IncidentViewModel

: RespondIncidentFragment

1: Selecciona el menu2: Selecciona la opción

revisar incidencias

3: se llama a la funcion de consultar incidencia5: Se muestra las

incidencias con

estado: "pendiente"

6: Selecciona la incidencia a responder

10: Se retorna al listado

de incidencias





9: Se rellena los campos y se archiva la incidencia

138

Figura 69. Diagrama de secuencia de: CUS-010 Archivar incidencia. Fuente: elaboración propia.

4.8.11 CUS-011 Remover incidencia

Figura 70. Diagrama de clases de: CUS-011 Remover incidencia. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)


RemoveIncidentFragment(f rom incidents)

DeleteIncidentFragment(f rom incidents)


Incident(f rom entit ies)


<<repository>>

139

Figura 71. Diagrama de colaboración de: CUS-011 Remover incidencia. Fuente: elaboración propia.

Figura 72. Diagrama de secuencia de: CUS-011 Remover incidencia. Fuente: elaboración propia.

usuario : MainActivity : RemoveIncidentFragment

: IncidentViewModel

: DeleteIncidentFragment

1: Selecciona el menu2: Se selecciona la opción

remover incidencia

3: se llama a la funcion de consultar incidencia


5: Se muestra las

incidencias con estado:

"inscrita"

6: Selecciona la incidencia a remover




9: Se rellena los campos y se remueve la

incidencia del libro

10: Se retorna al

listado de

incidencias

140

4.8.12 CUS-012 Enviar datos

Figura 73. Diagrama de clases de: CUS-012 Enviar datos. Fuente: elaboración propia.

Figura 74. Diagrama de colaboración de: CUS-012 Enviar datos. Fuente: elaboración propia.

Case(f rom entities)

Usuario observador

(f rom Actors)


<<repository>>



SendDataFragment

(f rom cases)

usuario : MainActivity : SendDataFragment

: CaseViewModel

1: Selecciona el

menu

2: Selecciona la opción

enviar datos

3: Se llama a la función consultar casos

4: Se devuelven los casos

5: Se muestra el

listado de casos

6: Se selecciona el caso del cual se

desea enviar los datos

7: Se envían los datos mediante una aplicación externa

8: Se visualiza el

listado de casos

141

Figura 75. Diagrama de secuencia de: CUS-012 Enviar datos. Fuente: elaboración propia.

4.8.13 CUS-013 Enviar información

Figura 76. Diagrama de clases de: CUS-013 Enviar información. Fuente: elaboración propia.

Usuario psicólogo

(f rom Actors)


SendInfoFragment(f rom inf ormations)

InformationRepository(f rom repositories)

<<repository>>

InformationViewModel(f rom inf ormations)

142

Figura 77. Diagrama de colaboración de: CUS-013 Enviar información. Fuente: elaboración propia.

Figura 78. Diagrama de secuencia de: CUS-013 Enviar información. Fuente: elaboración propia.

usuario : MainActivity : SendInfoFragment

: InformationViewModel

: mainFragment


2: Selecciona la opción enviar

información

3: Envía la información

4: Se muestra un mensaje de confirmación y

se envía a la interfaz de inicio

143

4.8.14 CUS-014 Visualizar información

Figura 79. Diagrama de clases de: CUS-014 Visualizar información. Fuente: elaboración propia.

Figura 80. Diagrama de colaboración de: CUS-014 Visualizar información. Fuente: elaboración propia.

Usuario básico

(f rom Actors)

Usuario observador

(f rom Actors)

Usuario psicólogo

(f rom Actors)

Usuario tutor

(f rom Actors)


SeeInfoFragment(f rom inf ormations)

InformationViewModel(f rom inf ormations)

Information(f rom entities)

InformationRepository(f rom repositories)

<<repository>>

: MainActivity : SeeInfoFragment

: InformationViewModel

4: Se devuelve el listado

usuario


conviencia escolar

3: Se llama a la funcion para

mostrar el listado de

informacion 5: Se muestra el listado

de información sobre

convivencia escolar


144

Figura 81. Diagrama de secuencia de: CUS-014 Visualizar información. Fuente: elaboración propia.

4.9 Modelo de Diseño

Se empleó en este caso el modelo físico y lógico, cuya codificación se encuentra en el

idioma inglés, para evitar problemas de escritura con las letras propias del idioma español,

así como tildes.

Figura 82. Modelo lógico de las entidades. Fuente: elaboración propia.

145

En la figura 82, se aprecia el modelo lógico de la aplicación, que ira estrechamente

relacionado con las demás clases (con sus atributos y operaciones) que tendrá la

aplicación en sus capas exteriores.

Figura 83. Diagrama EER de la base de datos. Fuente: elaboración propia.

En la figura 83, se aprecia el diseño de la base de datos relacional, siguiendo los principios

de la normalización, esta da el soporte en la capa de datos a la aplicación, permitiendo

almacenar los usuarios, contraseñas, casos, pruebas, etc.

146

Del modelo de la base de datos que se detalla en la figura 83, se extrae su diccionario de

datos, donde se especifica las características de los campos que componen a las tablas

elaboradas incluyendo su notación, tipo, restricción y características. Entre ellas tenemos:

clave primaria (PK), clave foránea (FK), no nulo (NN), único (UQ), valor binario (BIN), sin

signo (UN), completar con ceros (ZF) y autoincremento (AI).

Todas las tablas están definidas bajo estas especificaciones en el archivo script.sql, y los

datos de inicialización en el archivo data.sql.

Tabla 35 Diccionario de datos de la tabla gender

Nombre del campo Tipo de dato PK FK NN UQ BIN UN ZF AI

id TINYINT (1) X X X X

name VARCHAR (10) X


En la tabla 35 se observa el diccionario de datos de la tabla gender (género), incluye los

valores femenino y masculino con sus identificadores.

Tabla 36 Diccionario de datos de la tabla level



name VARCHAR (15) X X


En la tabla 36 se observa el diccionario de datos de la tabla level (nivel), incluye los valores

de inicial, primaria y secundaria.

147

Tabla 37 Diccionario de datos de la tabla grade


Id TINYINT (1) X X X X

name VARCHAR (20) X

level TINYINT (1) X X X


En la tabla 37 se observa el diccionario de datos de la tabla grade (grado), incluye los

valores de 3, 4 y 5 años para el nivel primaria, de primero a sexto para primaria y primero

a quinto para secundarios.

Tabla 38 Diccionario de datos de la tabla role



name VARCHAR (30) X

description VARCHAR (255)


En la tabla 38 se observa el diccionario de datos de la tabla role (cargo), incluye los valores

los cargos o roles que se encontró durante el análisis de la institución que son de

importancia para el manejo de interfaces de usuario de acuerdo con su rol en la institución.

Tabla 39 Diccionario de datos de la tabla section



name CHAR (1) X

grade TINYINT (1) X X

tutor VARCHAR (12) X X X


148

En la tabla 39 se observa el diccionario de datos de la tabla section (sección), sus campos

mencionan un identificador, el nombre (A, B, C, etc.), el grado mediante una clave foránea

a la tabla de nivel y el código del tutor identificado con su código como clave foránea.

Tabla 40 Diccionario de datos de la tabla status



name VARCHAR (25) X


En la tabla 40 se observa el diccionario de datos de la tabla status (estado), para tener

conocimiento del estado en el cual se encuentra un caso o incidencia y poder recuperar

casos que necesiten ser revisados o incidencias ya inscritas en el libro de incidencias para

ser exportado a un archivo o removidas del libro.

Tabla 41 Diccionario de datos de la tabla user


code VARCHAR (12) X X

names VARCHAR (50) X

lastName VARCHAR (45) X

mothersLastName VARCHAR (45) X

mail VARCHAR (45) X

password TINYBLOB X

section TINYINT (1) X

role TINYINT (1) X X

gender TINYINT (1) X X


En la tabla 41 se observa el diccionario de datos de la tabla user (usuario), incluyendo los

datos básicos del usuario, y sus claves foráneas haciendo referencia a sección, cargo y

género. Manejar identificadores numéricos en lugar de cadenas de texto reduce

149

significativamente el tamaño de la base de datos cuando el número de usuarios aumenta.

El campo correo que se usara para ingresar a la aplicación tiene como restricción que no

puede repetirse, la contraseña es de tipo binario, para almacenar mediante el algoritmo de

encriptación AES es valor, de manera que solo el usuario conoce la contraseña, para el

uso de AES, se utilizará como semilla de encriptación la misma contraseña que provee el

usuario.

Tabla 42 Diccionario de datos de la tabla case


id INT X X X X

description TEXT X

section TINYINT (1) X X

dateHappened DATE X

caseProof VARCHAR (150)

dateReport DATETIME X

userCode VARCHAR (12) X X X

status TINYINT (1) X X

responseDescription TEXT

responseProof VARCHAR (150)


En la tabla 42 se observa el diccionario de datos de la tabla case (caso), incluye su

identificador, la descripción que proporciona quien lo reporta, la sección del tutor quien lo

revisará, la fecha que se vio el acto de bullying y/o violencia escolar, una prueba opcional

(imagen), la fecha y hora en que fue reportado, el usuario que realizó el reporte (este solo

podrá ser visible para los usuarios que sean coordinadores académicos o director), el

identificador del estado de caso (al ser reportado será pendiente, luego de ser revisado por

el tutor podrá pasar como reportado o archivado), la respuesta del caso por parte del tutor

y una prueba opcional (imagen).

150

Tabla 43 Diccionario de datos de la tabla incident


id INT X X X X

description TEXT X

incidentProof VARCHAR (150)

status TINYINT (1) X X

caseId INT X

dateReport DATETIME X

response TEXT

responseProof VARCHAR (150)

userCode VARCHAR (12) X X X


En la tabla 43 se observa el diccionario de datos de la tabla incident (incidencia), incluye

su identificador, la descripción de esta (en caso venga de un caso, está será igual a la

respuesta del tutor frente al caso.), una prueba opcional (imagen), el estado de la

incidencia, el identificador del caso del que proviene si fuese así, la fecha y hora en que se

reportó, la respuesta por parte del área de psicología, una prueba opcional (imagen) y el

código del psicólogo que realizó el descargo.

Tabla 44 Diccionario de datos de la tabla information


id INT X X X X

title VARCHAR (225) X

description TEXT X

image VARCHAR (150)

url VARCHAR (500)

psychologist VARCHAR (12) X X X

dateUpload DATE X


En la tabla 44 se observa el diccionario de datos de la tabla information (información),

incluye su identificador, el título de la información sobre convivencia escolar, la descripción

151

de esta o su contenido, una imagen (opcional), un enlace (opcional), el código del psicólogo

que la envió y la fecha en que fue enviada. Esta tabla se puede usar con múltiples

propósitos que considere la institución, ya que permite enviar cualquier tipo de información

según lo consideren en el área de psicología.

4.9.1 Capa de la vista

El proyecto siguió el patrón de desarrollo MVVM, por ello se divide en tres capas bien

marcadas: la capa view, contiene las interfaces gráficas con las que el usuario va a

interactuar.

Figura 84. Archivo Navigation XML que muestra el flujo de la aplicación. Fuente: elaboración propia.

152

En la figura 84 se observa la vista gráfica del archivo de navegación, una de las nuevas

herramientas de desarrollo dentro de Android Jetpack. Se debe señalar que este

documento XML no solo permite definir el flujo entre interfaces gráficas, sino provee

además de la posibilidad de enviar ciertos datos, llamados argumentos, entre pantallas.

Figura 85. Pantallas de inicio de sesión, principal y menú básico. Fuente: elaboración propia.

En la figura 85 se visualiza las interfaces de inicio de sesión, donde se ingresa el usuario

(correo institucional) y la contraseña. Además, se aprecia la pantalla principal en la que se

visualiza un mensaje de bienvenida e indica el símbolo del menú que se encuentra en la

esquina superior. Finalmente, se muestra el menú del usuario básico (que incluye a

alumnos y personal docente) este es un menú desplegable desde la izquierda.

Dentro de los requisitos se encuentra el de tener una interfaz diferente para cada tipo de

usuario, esto se materializa en los menús donde cada tipo de usuario tiene las

funcionalidades de acuerdo con lo establecido en la especificación de requisitos.

153

Figura 86. Menús para cada tipo de usuario. Fuente: elaboración propia.

En la figura 86 se muestra los menús de los usuarios: tutores, psicólogos y observador.

Figura 87. Interfaz gráfica para reportar un caso. Fuente: elaboración propia.

154

Se puede apreciar en la figura 87 las pantallas para reportar un caso, donde se pide

ingresar la descripción, sección, fecha y opcionalmente una imagen como prueba. Se pide

a la vez una confirmación antes de reportar el caso.

Figura 88. Interfaz gráfica para los consultar y revisar casos. Fuente: elaboración propia.

La consulta de casos es una funcionalidad disponible tanto para tutores (visualizan los

casos de su sección) como usuarios observadores (visualizan todos los casos de todas las

secciones), en la figura 88 se muestra primero la interfaz gráfica que contiene el listado de

casos, luego la funcionalidad de revisar casos (funcionalidad exclusiva de los usuarios

tutores) en la que se muestra solo los casos con estado pendiente y correspondientes a su

sección.

Se puede distinguir el número identificador de un caso, la fecha en que ocurrió, estado

(usándose un código de colores para una fácil ubicación) y la descripción, en esta última,

155

se muestra solo parte de esta, si supera los 245 caracteres y se completa con puntos

suspensivos. Finalmente se aprecia un icono de archivo adjunto, este indica si el caso

posee una prueba digital (imagen).

Figura 89. Interfaz gráfica para responder un caso. Fuente: elaboración propia.

En caso el tutor decida revisar un caso, podrá reportarlo como incidencia al área de

psicología o archivarlo, en ambos casos se le solicita los datos establecidos en el análisis

de casos de uso y una confirmación, esto se muestra en la figura 89.

En caso el tutor reporte el caso como incidencia, se podrá visualizar en el listado de

incidencias por parte de los usuarios psicólogos y observadores.

156

En el caso de simplemente consultar un caso, se muestra de la misma forma todos los

detalles incluyendo el descargo del caso y su prueba si lo tuviera, pero sin el formulario

para responder al caso.

Figura 90. Interfaz gráfica para reportar una incidencia. Fuente: elaboración propia.

La figura 90 muestra las interfaces gráficas para el reporte de una incidencia directa por

parte del usuario psicólogo, se muestra el proceso completo, donde se le solicita los datos,

los completa y se pide su confirmación para proseguir.

157

Figura 91. Interfaz gráfica para los consultar, revisar y remover incidencias. Fuente: elaboración propia.

El usuario psicólogo puede consultar todas las incidencias (el usuario observador puede

realizar esta tarea también), revisarlas para dar un descargo y remover aquellas que están

en el libro de incidencias. En el caso de las incidencias reportadas por el psicólogo, estas

no tendrán sección cuando sean consultadas y al ser vistas a detalle se visualizará que

fueron reportadas directamente por el área de psicología. Estas interfaces gráficas se

muestran en la figura 91.

158

Figura 92. Interfaz gráfica para los enviar y visualizar información sobre convivencia escolar. Fuente: elaboración propia.

Los usuarios psicólogos pueden además enviar información sobre la convivencia escolar,

esta información será visible para todos los demás usuarios, esto se aprecia en la figura

92, el usuario psicólogo debe completar los campos que fueron especificados en el análisis

de casos de uso, y confirmar el envío de dicha información que será posteriormente

visualizada por los demás usuarios.

Los usuarios observadores pueden consultar las incidencias, pero solo los usuarios

psicólogos pueden responder a estas, decidiendo si son inscritas en el libro de incidencias

o archivadas.

159

Figura 93. Interfaz gráfica para descargar el libro de incidencias. Fuente: elaboración propia.

Figura 94. Interfaz gráfica para los enviar los datos de quien hace un reporte de un caso. Fuente: elaboración propia.

Además, los usuarios observadores pueden visualizar el libro de incidencias (figura 93),

descargarlo en formato Excel y tener acceso a los datos de quienes han realizado un

reporte de un caso (figura 94), para según su criterio utilizar la información como ellos

160

dispongan, la aplicación en ese sentido permite compartir dicha información vía correo,

portapapeles u otras aplicaciones.

La otra capa que compone al patrón MVVM es la capa de view model, la cual es encargada

de mediar con todas las interfaces gráficas, cumpliendo la función de mediador entre las

capas model y view. Se opto por la creación de cinco view model:

- LoginViewModel: maneja todo lo relacionado al inicio de sesión, asignar menú

según rol de usuario y cierre de sesión.

- MainViewModel: maneja los permisos de la aplicación para lectura y escritura en el

dispositivo.

- CaseViewModel: maneja todo lo relacionado con los casos (reporte, consulta, etc.).

- IncidentViewModel: maneja todo lo relacionado con las incidencias (reporte,

consulta, etc.).

- InformationViewModel: maneja todo lo relacionado con la información (envío y

visualización).

Figura 95. Ubicación de los archivos de la capa view model. Fuente: Elaboración propia.

161

En la figura 95 se señala los archivos de la capa view model que están relacionados con

las vistas, estos usan generalmente para su comunicación la funcionalidad de Live Data

ligado al ciclo de vida de la actividad o fragmento.

En la capa model, se incluye la implementación del diagrama lógico y las clases repositorio,

que, si bien no son parte del modelo MVVM, son ampliamente considerados una buena

práctica en el desarrollo de aplicaciones. (Android 2018)

Figura 96.Ubicación de los archivos de la capa model. Fuente: Elaboración propia.

En la figura 96 se aprecia los archivos de las entidades y repositorios, las entidades son

las tradicionales clases encapsuladas, mientras el repositorio hace uso de estas para

cargar datos desde las bases de datos del propio sistema Android o mediante servicios

web, como es el caso del presente proyecto mediante servicios REST.

4.10 Implementación del prototipo

Figura 97. Diagrama de componentes general. Fuente: Elaboración propia.

Servidor

api

<<php>>

images

<<php>>

Shield

script.sql

Android 4.0.3 - 8.0

Shield.apk

<<Application>>

162

En la figura 97 se aprecia el diagrama de componentes, la aplicación que soporta desde la

versión 4.0.3 hasta las más actuales se conecta al servidor mediante una API que usa

servicios REST con JSON como estándar de comunicación y en el servidor se almacenan

las pruebas (imágenes), mientras que la API hace peticiones e inserciones en la base de

datos. La base de datos sigue lo especificado en el modelo físico.

Figura 98. Diagrama de despliegue. Fuente: Elaboración propia.

En la figura 98 se aprecia como el diagrama de despliegue replica la arquitectura elegida

junto con los dispositivos que interactúan, entre ellos los dispositivos Android que hacen

peticiones a través de servicios REST, que son procesados en el servidor y hacen llamadas

a la base de datos, retornando una respuesta de vuelta hacia el dispositivo.

4.11 Pruebas

Se llevaron a cabo varias pruebas funcionales (unitarias e instrumentadas) y no funcionales

(estrés, carga y configuración). Luego de que salieron exitosas se procedió a validar las

API

<<Web Services REST>>

Dispositivo Android

<<device>>

Base de datos

MySQL

<<Database>>

Servidor

<<device>>

163

mismas con el Stakeholder que hace de representante de la institución y tener su visto

bueno mediante un acta de conformidad (ver apéndice J).

4.11.1 Pruebas unitarias

Se evaluaron diversos métodos de formato de textos (fechas), la carga de datos desde los

servicios REST, que incluyen métodos GET y POST utilizando las librerías: Glide, Retrofit2

y Volley.

Figura 99. Resultados de pruebas unitarias. Fuente: Elaboración propia.

En la figura 99 se aprecia los resultados de las principales funciones o métodos de carga

y formatos de fechas. Estas pruebas dieron resultados satisfactorios y permitieron llevar a

cabo un desarrollo más fluido al no depender de las pruebas de mayor envergadura, donde

resulta más complicado detectar donde que porción de código es la que genera resultados

no deseados.

4.11.2 Pruebas de los servicios REST

Se utilizó el software Postman para probar los servicios REST de la aplicación, estos están

escritos en lenguaje PHP.

164

El servicio REST está compuesto por 16 llamadas que hacen de intermediario entre la

aplicación y la base de datos, estos incluyen: validar usuarios al iniciar sesión, obtener las

secciones, reportar un caso, obtener los casos (para usuarios observadores y tutores),

obtener en detalle un caso por su identificador (id), enviar datos de un usuario que ha

realizado un reporte de un caso, reportar un incidente a partir de un caso, reportar un

incidente directamente, obtener los incidentes, obtener en detalle un incidente por su

identificador (id), obtener incidencias inscritas en el libro de incidencias, responder (dar

descargo) a una incidencia asignándole un estado (inscrita o archivada, permitiendo

remover incidencias del libro), insertar información sobre convivencia escolar en la base de

datos, obtener la lista que contiene la información sobre convivencia escolar (todas las que

fueron enviadas) y la inserción de imágenes (estas no se almacenan en la base de dato,

sino en el servidor y su URL es la que se almacena en la base de datos).

Hacer estas pruebas fue fundamental, ya que permitían saber los resultados que tendrían

las peticiones que realizaría la aplicación. Asimismo, conocer que datos debían enviarse

para una correcta interacción.

165

Figura 100. Servicios REST testeados mediante Postman. Fuente: elaboración propia.

En la figura 100, se muestra los 16 casos de los servicios REST que fueron evaluados de

manera intensiva durante las primeras etapas de desarrollo, esto garantizaría la

disponibilidad del servidor en todo momento, así como la respuesta de este frente a las

diversas llamadas.

166

4.11.3 Pruebas instrumentadas

Se utilizó la librería Espresso para llevar a cabo las pruebas instrumentadas, dividiéndose

estas en nueve para probar las distintas características de la aplicación como son:

- Inicio y cierre de sesión.

- Reportar casos.

- Reportar Incidencias.

- Consulta de casos, visualización y dar descargo de estos.

- Consulta de incidencias, visualización y dar descargo de estas.

- Visualizar el libro de incidencias.

- Consulta de información sobre convivencia escolar.

- Agregar información sobre convivencia escolar.

- Enviar datos de quién reporta un caso.

Figura 101. Resultado de las pruebas instrumentadas. Fuente: elaboración propia.

167

En la figura 101 se observa que todas las pruebas instrumentadas resultaron exitosas tras

todas las iteraciones que se llevaron a cabo.

4.11.4 Pruebas de estrés

Para llevar a cabo las pruebas de estrés se utilizó MONKEY a la interfaz gráfica de inicio

de sesión y la principal con 10, 50, 100, 500 y 1000 acciones para ambos casos, los

resultados fueron favorables, puesto que no se presentaron errores ni la aplicación se

detuvo. Los resultados de mil acciones se pueden observar en los resultados del apéndice

K.

La razón para llevar a cabo pruebas hasta con 1000 acciones fue que en las pruebas con

menor cantidad de acciones en el primer intento no se detectaron errores y se siguió

probando con una mayor cantidad para detectar estos, pero tras las mil acciones se obtuvo

resultados positivos.

4.11.5 Pruebas de configuración

La presente aplicación móvil está diseñada para dispositivos Android desde el API 15 en

adelante, se ejecutó la aplicación y se realizó pruebas con diversos dispositivos entre

físicos y virtuales que contemplan las API: 15, 19, 24 y 28.

Durante el desarrollo se fue haciendo pruebas en los distintos dispositivos de manera

iterativa, de estas se determinó que el uso de ConstraintLayout, ListView, ScrollView,

NestedScrollView, entre otras para los archivos XML permitían una correcta visualización

en los diferentes dispositivos tanto virtuales como el físico.

En los dispositivos emulados se realizó las pruebas con el idioma inglés por defecto,

mientras en el dispositivo físico se utilizó por defecto el idioma español.

168

Figura 102. Dispositivos virtuales emulados. Fuente: elaboración propia.

En la figura 102 se aprecia los tres dispositivos virtuales empleados para validar el

funcionamiento de la aplicación en las distintas versiones del sistema operativo Android.

Comprende: la versión 4.0.3 con API 15, la 4.4 con API 19 y la 9.0 con API 28.

Figura 103. Dispositivo virtual con Android 4.0.3. Fuente: elaboración propia.

169

En la figura 103 se aprecia la ejecución de la aplicación en el API 15, el SDK mínimo para

el presente proyecto, con la versión de Android 4.0.3 y una pantalla de 4 pulgadas para

garantizar su usabilidad aún en dispositivos muy pequeños y de gama media a baja.

Figura 104. Dispositivo virtual con Android 4.4. Fuente: elaboración propia.

En la figura 104 se aprecia la ejecución de la aplicación en un dispositivo virtual con API

19, se aprecia la correcta visualización de los elementos gráficos, aunque la pantalla sigue

siendo 4 pulgadas.

Figura 105. Capturas del dispositivo físico con Android 7.0. Fuente: elaboración propia.

170

En la figura 105, se aprecia las capturas de pantalla de la aplicación ejecutada sobre el

dispositivo físico con API 24. Este dispositivo es una Samsung Galaxy S7 con versión de

Android 7.0 y una pantalla de 5,1 pulgadas.

Figura 106. Dispositivo virtual con Android 9.0. Fuente: elaboración propia.

En la figura 106, se aprecia la ejecución de la aplicación en un dispositivo virtual con API

28, que emula una pantalla de 6 pulgadas, se aprecia igualmente una correcta visualización

de los componentes de las interfaces gráficas.

4.11.6 Pruebas de rendimiento: CPU, RAM, redes, almacenamiento y batería

Otro punto importante era el de verificar que aplicación no consumiera demasiados

recursos de los dispositivos donde se encontrara, por ello se comparó los consumos de

almacenamiento, CPU, memoria RAM, batería y el uso de las redes móviles.

171

Cabe señalar que la aplicación consume recursos de manera óptima, incrementando su

consumo de almacenamiento en el caso de descargar las pruebas (imágenes).

Figura 107. Consumo de almacenamiento de la aplicación. Fuente: elaboración propia.

Se muestra en la figura 107 la comparación de espacio usado por la aplicación en un

dispositivo virtual (versión 4.4) y un dispositivo físico (versión 7.0). Cabe señalar las

diferencias entre ambos en cuanto a la capacidad de almacenamiento, el dispositivo

emulado posee 2 Gb de almacenamiento (interno y externo), mientras el dispositivo físico

posee 32 Gb de almacenamiento interno y 16 Gb de almacenamiento externo, en caso del

dispositivo físico el espacio utilizado es mayor puesto que en este se ha realizado varias

descargas de imágenes y el libro de incidencias. En ese sentido el espacio que utilice la

aplicación dependerá en gran medida de la cantidad de pruebas que descarguen los

usuarios.

172

Figura 108. Uso de memoria RAM. Fuente: elaboración propia.

Sobre la memoria RAM, el dispositivo emulado posee 1 Gb de RAM, mientras el dispositivo

físico posee 4 Gb, el consumo que hace de memoria RAM es bajo, elevándose solo en

casos donde carga listas extensas o carga y/o descarga imágenes o documentos.

Figura 109. Consumo de recursos por la aplicación al iniciar sesión. Fuente: elaboración propia.

173

La figura 109, muestra mediante el uso de la herramienta Android Profiler de Android

Studio, el consumo de los diferentes recursos al iniciar sesión, el uso del CPU no llega a

sobrepasar el 50%, el consumo de memoria RAM es bajo, el uso de redes se da solamente

durante la llamada a la función y el consumo de batería no llega a sobrepasar el consumo

medio.

Figura 110. Consumo de recursos por la aplicación al hacer un listado de información. Fuente: elaboración propia.

La figura 110, muestra el consumo de los recursos al cargar una lista, el uso del CPU,

igualmente, no llega a sobrepasar el 50%, el consumo de memoria RAM se eleva un poco

más, pero no de forma drástica, el uso de redes se da nuevamente solo durante la llamada

a la función, pero se aprecia que el consumo de batería llega en determinado momento a

sobrepasar el consumo medio, pero por un tiempo corto para luego de llamada la función

seguir con un consumo medio a bajo.

174

Durante los momentos que la aplicación no interactúa con el usuario, su consumo de

recursos como CPU y batería es mínimo, de la misma forma el consumo de red. Se puede

visualizar que su consumo de redes es realizado solo cuando se hacen consultas a listas

o formularios sin incluir la carga o descarga de archivos, donde el uso de redes móviles

dependerá en mayor parte del tamaño de los archivos.

175

CAPÍTULO 5

ANÁLISIS COSTO - BENEFICIO

El presente capítulo describirá el análisis de los costos y beneficios de la implementación

del sistema en la parte económica.

El presente capítulo describe el análisis de los costos y beneficios del proyecto de

desarrollo si fuese implementado en la institución educativa.

5.1 Presupuesto

Con base a lo descrito en el plan de desarrollo de del proyecto se extrae los siguientes

costos en equipos, materiales, insumos y personal que serían requeridos para la

implementación.

Tabla 45 Presupuesto del talento humano

Cargo Nro. de

personas Pago por

hora (soles) Horas al día

Días Sueldo al mes

Sueldo mensual

Jefe de Proyecto

01 15.00 4 30 1800.00 360.00

Documentador 01 8.00 3 20 480.00 96.00

Analista de sistemas

01 11.00 4 35 1540.00 308.00

Programador 01 14.00 3 45 1890.00 378.00

Diseñador 01 11.00 3 15 495.00 99.00

Analista de base de datos

01 11.00 3 35 1155.00 231.00

Total 7360.00 1472.00


176

En la tabla 45 se aprecia el supuesto de contratación de personal para desplegar el

proyecto, estos son estimados teniendo concordancia con el tiempo planificado según el

cronograma de desarrollo, luego del tiempo de desarrollo la institución asumiría el

mantenimiento del sistema.

Tabla 46 Presupuesto de equipamiento, redes y muebles

Descripción Cantidad Costo total (soles)

PC personal 1 2000.00

Laptop 1 1700.00

Smartphone 1 450.00

Alquiler de un servidor por 5 meses. 1 100.00

Escritorios 2 120.00

Sillas 2 60.00

Cableado para 2 equipos s/n 10.00

Línea Telefónica con Internet por 5 meses 1 300.00

Switch. 1 400.00

Total 5140.00


En la tabla 46 se aprecia los costos estimados para un despliegue del proyecto durante el

tiempo de desarrollo según en el cronograma de desarrollo (ver apéndice I).

Tabla 47 Presupuesto de programas necesarios

Descripción Cantidad Costo (soles)

NetBeans IDE 1 0.00

MySQL Workbench 6.3 CE 1 0.00

Android Studio 1 0.00

StarUML 1 0.00

Corel Draw 2018 (versión de prueba) 1 0.00

Adobe Photoshop CS6 (versión de) 1 0.00

Editores de texto (Google Drive, Open office) 1 0.00

Total 0.00


177

En la tabla 47 se detalla los programas necesarios para la documentación y desarrollo del

proyecto y en caso de programas con licencia, se usa las versiones de prueba, ya que

estos no serán requeridos más de un mes.

Tabla 48 Flujo neto de efectivo proyectado a 5 meses

Detalles Meses

1 2 3 4 5

Ingresos (soles)

Venta del sistema al colegio

7000.00 3500.00 3500.00 3500.00 3500.00

Capacitación a los usuarios

0.00 0.00 0.00 0.00 1500.00

Egresos (soles)

Personal para el proyecto 1472.00 1472.00 1472.00 1472.00 1472.00

Equipamiento necesario 4230.00 0.00 0.00 0.00 0.00

Herramientas de software 0.00 0.00 0.00 0.00 0.00

Total (mensual) 1298.00 2028.00 2028.00 2028.00 3528.00

Total (acumulado) 1298.00 3326.00 5354.00 7382.00 10910.00


El proyecto tiene un valor de venta estimado en S/ 21000.00 que pueden ser distribuidos

en 6 pagos, el primer pago es una cuota doble para que cubra los gastos de inversión

iniciales sin depender de créditos financieros y los demás en cuotas mensuales iguales.

Además, se aprecia el costo que asume la institución por concepto de capacitación a su

personal en el último mes del proyecto.

178

5.2 Tasa interna de rentabilidad (TIR) y valor actual neto (VAN)

Teniendo como insumo los flujos de caja desde el desembolso de inversión del proyecto y

las ganancias acumuladas, se procedió al cálculo de la tasa interna de rentabilidad y el

valor actual neto que nos indican el porcentaje de rendimiento del proyecto tras los cinco

meses de desarrollo.

Tabla 49 FNE del proyecto considerando el desembolso

Período (mes) Flujo de Fondos (soles)

0 -5702.00

1 1298.00

2 3326.00

3 5354.00

4 7382.00

5 10910.00


E la figura 49 se muestran los flujos de caja desde el desembolso inicial del proyecto que

se considera periodo cero que hasta la obtención al final de este, con este se calculó la TIR

y el VAN para el presente proyecto.

Tabla 50 TIR y VAN para el proyecto

Período (mes) Flujo de Fondos (soles)

58,91% 14065.56


De la tabla 50 se puede inferir que el TIR es mayor a la tasa mínima de aceptable de

rendimiento (TMAR) que se calcula mediante la tasa de inflación anual del país, el riesgo

179

de la inversión, tasas bancarias activas y pasivas. En este caso análisis de costo beneficio

del proyecto se solventaría con fondos del primer abono por parte de la institución sin

necesidad de un préstamo bancario. Por ello sería necesario conocer solo la tasa de

inflación que en Perú cerro con 2,48% de inflación el 2018 (Banco Central de Reserva del

Perú, 2018), del cual el TIR estimado para este proyecto supera ampliamente.

5.3 Periodo de recuperación de inversión (PRI)

Mediante este instrumento utilizando el FNE del proyecto se puede pronosticar el tiempo

de retorno del capital invertido inicialmente en el proyecto. Para el supuesto que se requiere

un costo de inversión inicial de S/ 5702.00 y un primer pago de S/ 7000.00 se ubicaría el

retorno de la inversión en menos de un mes, pero dependiendo de cómo se realicen los

pagos por el desarrollo del proyecto este puede variar, es decir en cuantos meses y a que

cuotas se realice, el tiempo de retorno puede variar.

180

CAPÍTULO 6

RESULTADOS

El presente capítulo describirá los resultados obtenidos tras emplear los instrumentos de

medición sobre el impacto de la implementación del prototipo funcional de la aplicación.

6.1 Fiabilidad del instrumento de medición

Se aplicó el método de Alfa de Cronbach para tener una confiabilidad de correlación entre

los elementos del instrumento.

Tabla 51 Resumen de procesamiento de casos

N %

Casos válidos 60 100%

Casos excluidos 0 0%

Casos totales 60 100%


La tabla 51 muestra el número de casos procesados que alcanza un total 60 casos, con

ellos se procedió a calcular el alfa de Cronbach

Tabla 52 Resultados de las estadísticas de fiabilidad

Alfa de Cronbach

Alfa de Cronbach basada en elementos estandarizados

N de elementos

0,809 0,825 17


181

En la tabla 52 se aprecia el resultado obtenido que fue de 0,809, superando el valor 0,7

mostrando una consistencia interna aceptable según los indicadores del alfa de Cronbach.

De esta manera, el alfa de Cronbach ratifica la fiabilidad y consistencia interna del

instrumento aplicado.

6.2 Análisis de los resultados

Teniendo como base la matriz de consistencia (ver apéndice A), se procedió a analizar los

resultados obtenidos en las diversas pruebas realizas a la aplicación y los resultados del

instrumento aplicado sobre la aplicación (Ver apéndices E y G).

6.2.1 Adaptabilidad a los usuarios

En esta dimensión se analizó si la aplicación es compatible con los dispositivos que poseen

los usuarios, donde se detectó que la menor versión de uno de ellos era la versión 4 de

Android, para este caso mediante pruebas de configuración se pudo ejecutar manera

exitosa la aplicación en dispositivos virtuales que ejecutan la versión 4.0.3 de Android.

Esta dimensión analiza también la disponibilidad de la aplicación, la aplicación al estar

alojada en el dispositivo móvil se comunica con la base de datos mediante WebServices,

que funcionan las 24 horas del día al estar alojados en un servidor Web.

La aplicación usa como usuario para iniciar sesión un dato ya conocido para los miembros

de la comunidad educativa y es su correo (@pamer.pe), evitando la creación de nuevos

usuarios.

182

6.2.2 Rendimiento al usuario

En cuanto a esta dimensión, analiza el nivel de consumo por parte de la aplicación de los

recursos como CPU, RAM y batería del dispositivo donde se encuentra alojado. Los

reportes de las pruebas de rendimiento muestran un consumo muy bajo en el dispositivo

físico donde se realizó la prueba y el mismo consumo bajo en los dispositivos virtuales. La

aplicación no consume recursos en segundo plano y hace un uso bajo de los recursos del

dispositivo, incluido el consumo de internet, puesto que al trabajar con el lenguaje de

transferencia JSON, la gran cantidad de datos viaja en forma de texto plano a la aplicación,

mostrándose solo un incremento al momento de visualizar imágenes, en cuyo caso

depende exclusivamente del peso del archivo en mención.

6.2.3 Facilidad para reportar

La facilidad para reportar casos en la aplicación está ligada a lo intuitiva que resulta la

aplicación, por ello las preguntas del instrumento con identificador 8, 9, 10 y 17.

Figura 111. Recuento de: "Reportar un caso mediante la aplicación resulta". Fuente: Elaboración propia

0 0

4

18

38

0

5

10

15

20

25

30

35

40

Muy difícil Difícil Ni fácil ni difícil Fácil Muy fácil

Reportar un caso mediante la aplicación resulta:

183

En la figura 111 se determina que la mayoría de los miembros considera que reportar un

caso (el proceso principal) no resulta en ningún caso difícil, por el contrario, el proceso es

para la mayoría fácil o muy fácil.

Figura 112. Recuento de: "Responder a un caso reportado mediante la aplicación resulta". Fuente: Elaboración propia

En la figura 112 se muestra los resultados de la percepción de los usuarios sobre la

funcionalidad de responder a un caso, proceso exclusivo de los tutores, pero donde los

miembros manifestaron su punto de vista considerando el proceso en su mayoría de fácil

o muy fácil uso.

La facilidad para realizar reportes de casos de bullying es uno de los requisitos principales

de la aplicación, otro de ellos es la funcionalidad de realizar reportes de incidencias y su

facilidad para responder a las mismas, pues la aplicación permite a los usuario psicólogos

que luego de hacer todo el proceso correspondiente a su área determinen si la incidencia

debe archivarse o enviarse al libro de incidencias, en este último caso, teniendo en cuenta

la delicadeza de inscribir una incidencia en el libro, se da la posibilidad de remover una

0 0

6

14

40

0

5

10

15

20

25

30

35

40

45


Responder a un caso reportado mediante la aplicación resulta:

184

incidencia de dicho libro actualizando el reporte del caso y dando todas las razones por las

cuales es removida.

Figura 113. Recuento de: "Reportar una incidencia mediante la aplicación (inscribiendo, archivando o removiendo) mediante la aplicación resulta". Fuente: Elaboración propia

En la figura 113 se aprecia que los usuarios consideran el proceso de reportar incidencia y

darles una repuesta es un proceso sencillo, cabe recordar que tanto tutores como

psicólogos pueden reportar incidencias, siendo luego los del área de psicología los

encargados de responder a estas incidencias para archivarlas o inscribirlas.

Otra de las funcionalidades de la aplicación es la de subir información de convivencia

escolar, que es señalado en la Ley 29719 (2011), para ello la aplicación provee de un

formulario donde los usuarios ´sicólogos pueden agregar dicha información conteniendo

texto, imágenes e incluso enlaces a sitios web externos, por ello resulta importante conocer

la percepción de los usuarios sobre la facilidad de agregar información sobre la convivencia

escolar pacífica a través del formulario de la aplicación.

0 0

6

29

25

0

5

10

15

20

25

30

35


Reportar una incidencia mediante la aplicación (inscribiendo, archivando o removiendo) mediante la aplicación resulta:

185

Figura 114. Recuento de: "Agregar información sobre la convivencia escolar pacífica a través del formulario de la aplicación resulta". Fuente: Elaboración propia

En la figura 114 se muestra el recuento de la percepción de los miembros de la comunidad

educativa frente a la pregunta si les parece fácil o difícil compartir información sobre la

convivencia escolar pacífica mediante la aplicación (respectivamente el formulario que

usarán los psicólogos). En este caso la mayoría afirma que el proceso es muy sencillo.

6.2.4 Seguridad de la aplicación

Para la seguridad de la aplicación al iniciar sesión en la aplicación se empleó el algoritmo

de encriptación AES, utilizando como palabra semilla a la misma contraseña, de manera

que solamente es el propio usuario quien tiene conocimiento de la contraseña y no es un

dato conocido ni por el programador, ni administrador de bases de datos.

Adicional a ello se emplearon pruebas instrumentadas en el inicio y cierre de sesión,

dirigiendo al usuario al menú correspondiente según su rol en la comunidad educativa.

Además, pruebas al servicio web que permite la autentificación del usuario, obteniendo

resultados favorables.

0 0 0

10

50

0

10

20

30

40

50

60


Agregar información sobre la convivencia escolar pacífica a través del formulario de la aplicación resulta:

186

También, se midió el tiempo que estiman los usuarios al iniciar sesión en el dispositivo

mediante la pregunta con número de ítem 1: “El tiempo de respuesta para iniciar sesión en

la aplicación es”

Figura 115. Recuento de: "El tiempo de respuesta para iniciar sesión en la aplicación es". Fuente: Elaboración propia

En la figura 115 se muestra la percepción de los usuarios frente al tiempo que les toma

iniciar sesión en la aplicación, se puede apreciar que se considera que el inicio de sesión

es veloz para los usuarios.

Para medir la percepción de los usuarios sobre la protección de datos de quien reporta, se

empleó la pregunta con número de identificador 11: “¿En qué medida los datos (nombre,

código u otro) que permitan identificar a quién realizó un reporte de un caso son

protegidos?”, luego de mostrarles en video todas las funcionalidades de la aplicación y

como esta maneja la identidad de quienes reportan un caso.

0 0 0

16

44

0

5

10

15

20

25

30

35

40

45

50

Muy lento Lento Ni rápido ni lento Rápido Muy rápido

El tiempo de respuesta para iniciar sesión en la aplicación es:

187

Figura 116. Recuento de: “¿En qué medida los datos (nombre, código u otro) que permitan identificar a quién realizó un reporte de un caso son protegidos?”. Fuente: Elaboración propia

La figura 116 muestra que una gran mayoría los miembros de la comunidad educativa

sienten que sus datos se encuentran protegidos. Cabe resaltar que esta es una de las

razones por las cuales los testigos o víctimas de casos de bullying o violencia escolar no

suelen contar lo sucedido a las autoridades de las instituciones educativas.

6.2.5 Consulta de reportes y visualización de información

En este aspecto se tomó en cuenta dos factores: el tiempo para realizar consultas, realizar

reportes, responder a estos reportes y la visualización amigable de la información al

usuario.

Para obtener la apreciación sobre el tiempo de respuesta de la aplicación se tuvo en cuenta

las preguntas con número de ítem: 2, 3, 4, 5, 6, 7 y 16

0 0 1

8

51

0

10

20

30

40

50

60

Nada protegidos Poco protegidos Ni poco ni muyprotegidos

Bien protegidos Muy protegidos

¿En qué medida los datos (nombre, código u otro) que permitan identificar a quién realizó un reporte de un caso son protegidos?

188

Figura 117. Recuento de: "El tiempo de respuesta para ver listados de casos o incidencias en la aplicación es". Fuente: Elaboración propia

Figura 118. Recuento de: "El tiempo de respuesta para ver casos o incidencias a detalle en la aplicación es". Fuente: Elaboración propia

Las figuras 117 y 118 muestran las percepciones de los miembros de la comunidad

educativa frente a la presentación de datos en términos de tiempo, en este caso los listados

de casos e incidencias de bullying, los resultados indican que hay una sensación de

0 0 0

13

47

0

5

10

15

20

25

30

35

40

45

50


El tiempo de respuesta para ver listados de casos o incidencias en la aplicación es:

0 0 0

11

49

0

10

20

30

40

50

60


El tiempo de respuesta para ver casos o incidencias a detalle en la aplicación es:

189

velocidad en la presentación de información e incluso cuando se observa el caso o

incidencia a detalle.

La pregunta con ítem número 15 del cuestionario sobre la aplicación: “¿Qué tanto la

aplicación agiliza la consulta de casos e incidencias respecto al proceso manual?” hace

una referencia directa a los entrevistados sobre su percepción en cuestión de tiempo entre

el proceso manual y el proceso mediante la aplicación móvil de la cual se obtuvo el

siguiente resultado.

Figura 119. Recuento de: “¿Qué tanto la aplicación agiliza la consulta de casos e incidencias respecto al proceso manual?”. Fuente: Elaboración propia

En la figura 119 se aprecia que una mayoría prácticamente absoluta de miembros de la

comunidad considera que se ha mejorado el tiempo que tomaba reportar un caso de

bullying de forma manual, debemos tener en cuenta que usando la aplicación pueden

realizar reportes desde cualquier punto donde cuenten con acceso a internet, en cualquier

momento del día y a estos reportes le dan seguimiento el área de coordinación y dirección.

Además, de dar seguimiento a los incidentes que se desprenden de estos casos o los

reportados por el área de psicología.

0 0 1

16

43

0

5

10

15

20

25

30

35

40

45

50

Muy poco Poco Ni poco ni mucho Mucho Muchísimo

¿Qué tanto la aplicación agiliza la consulta de casos e incidencias respecto al proceso manual?

190

Figura 120. Recuento de: "¿La aplicación reduce el tiempo para reportar casos de bullying y/o violencia escolar?". Fuente: Elaboración propia

Figura 121. Recuento de: "¿La aplicación reduce el tiempo para responder a los casos o incidencias de bullying y/o violencia escolar?". Fuente: Elaboración propia

De la figura 120 y 121 se observa que la percepción de los miembros de la comunidad

educativa sobre la reducción de tiempo para llevar a cabo el proceso de reportar un caso

0 0 1

23

36

0

5

10

15

20

25

30

35

40


¿La aplicación reduce el tiempo para reportar casos de bullying y/o violencia escolar?

0 0

6

14

40

0

5

10

15

20

25

30

35

40

45


¿La aplicación reduce el tiempo para responder a los casos o incidencias de bullying y/o violencia escolar?

191

y el tiempo que le toma al tutor dar una respuesta es que se ha reducido en gran medida

respecto a realizar el proceso de forma manual.

Otra de las funcionalidades que requiere la institución es la elaboración de un documento

que contenga todos los incidentes reportados en la institución, aquí la aplicación permite a

los usuarios coordinadores y directores obtener de forma casi instantánea el libro de

incidencia en formato electrónico en formato Excel.

Figura 122. Recuento de: "¿La aplicación reduce el tiempo para obtener un libro de incidencias en formato electrónico?". Fuente: Elaboración propia

En este punto la percepción de los miembros de la comunidad educativa frente a la

diferencia en términos de tiempo entre obtener este libro de incidencias mediante la

aplicación o mediante un proceso manual es que se ha reducido de forma amplia el tiempo

de espera, como se puede apreciar en la figura 122.

0 0 1

12

47

0

5

10

15

20

25

30

35

40

45

50


¿La aplicación reduce el tiempo para obtener un libro de incidencias en formato electrónico?

192

Figura 123. Recuento de: "¿Compartir información sobre la convivencia escolar pacífica mediante la aplicación en términos de tiempo es?". Fuente: Elaboración propia

Figura 124. Recuento de: "El tiempo de respuesta para ver información sobre la convivencia escolar pacífica en la aplicación es". Fuente: Elaboración propia

En las figuras 123 y 124 se aprecia la valoración que le dan los usuarios al tiempo de

respuesta para compartir y ver información sobre la convivencia escolar pacífica en la

aplicación, la cual carga texto, imágenes y enlaces web, aunque la cantidad de datos que

esta carga es relativamente amplia tiene una valoración positiva en términos de velocidad

por parte de los miembros de la comunidad educativa.

0 04 5

51

0

10

20

30

40

50

60


¿Compartir información sobre la convivencia escolar pacífica mediante la aplicación en términos de tiempo es?

0 0 0

22

38

0

5

10

15

20

25

30

35

40


El tiempo de respuesta para ver información sobre la convivencia escolar pacífica en la aplicación es:

193

Para obtener la apreciación sobre lo amigable que resulta la aplicación al mostrar listados

de casos, incidencias o información se usó como indicador los resultados del instrumento

de medición, específicamente las preguntas con número de ítem: 12 ,13 y 14. Estos

demuestran si la consulta de los

Figura 125. Recuento de: "La consulta del listado de casos mediante la aplicación resulta un proceso". Fuente: Elaboración propia

Figura 126. Recuento de: "La consulta del listado de incidencias mediante la aplicación resulta un proceso". Fuente: Elaboración propia

0 0 1

6

53

0

10

20

30

40

50

60


La consulta del listado de casos mediante la aplicación resulta un proceso:

0 0 1

6

53

0

10

20

30

40

50

60


La consulta del listado de incidencias mediante la aplicación resulta un proceso:

194

Figura 127. Recuento de: "La consulta de la información sobre convivencia escolar enviada por el área de psicología resulta un proceso". Fuente: Elaboración propia

Las figuras 125, 126 y 127 muestra la percepción de los usuarios frente a como les resulta

el proceso para consultar los listados de casos, incidencias y de información sobre

convivencia escolar. En este aspecto, los miembros de la comunidad educativa manifiestan

en su mayoría que el proceso de consulta de estos es amigable y sencillo.

6.3 Validación de la hipótesis

La hipótesis general es: “Si se diseña e implementa una aplicación móvil en el sistema

operativo Android entonces, entonces mejorará la gestión de casos de bullying y/o violencia

escolar de un colegio Privado de Lima”

Para ello validaremos cada una de las hipótesis específicas:

La primera hipótesis específica afirma: “El diseño e implementación de una aplicación móvil

en el sistema operativo Android reduce el tiempo para reportar casos de bullying y/o

violencia escolar.”

0 0 1

6

53

0

10

20

30

40

50

60


La consulta de la información sobre convivencia escolar enviada por el área de psicología resulta un proceso:

195

Para esta hipótesis se analizó los resultados de las preguntas sobre la percepción del

tiempo de respuesta de la aplicación.

Tabla 53 Estadísticas descriptivas de las preguntas 1, 2, 3, 4, 5, 6 y 7

N Media Desviación estándar

Desviación error

promedio

El tiempo de respuesta para iniciar sesión en la aplicación es:

60 4,73 0,446 0,058

El tiempo de respuesta para ver listados de casos o incidencias en la aplicación es:

60 4,78 0,415 0,054

El tiempo de respuesta para ver casos o incidencias a detalle en la aplicación es:

60 4,82 0,39 0,05

El tiempo de respuesta para ver información sobre la convivencia escolar pacífica en la aplicación es:

60 4,63 0,486 0,063

¿La aplicación reduce el tiempo para reportar casos de bullying y/o violencia escolar?

60 4,58 0,53 0,068

¿La aplicación reduce el tiempo para responder a los casos o incidencias de bullying y/o violencia escolar?

60 4,68 0,504 0,065

¿La aplicación reduce el tiempo para obtener un libro de incidencias en formato electrónico?

60 4,77 0,465 0,06


En la tabla 53 observamos los estadísticos descriptivos para estas preguntas, estas tienen

una media entre 4,58 y 4,82 situándose entre una reducción de tiempo de mucho y

muchísimo.

196

La segunda hipótesis específica afirma: “El diseño e implementación de una aplicación

móvil en el sistema operativo Android salvaguarda la identidad de quienes reportan casos

de bullying y/o violencia escolar.”

Para esta hipótesis en específica es la pregunta con número de ítem 11: “¿En qué medida

los datos (nombre, código u otro) que permitan identificar a quién realizó un reporte de un

caso son protegidos?” la que será analizada, asignamos valores: nada protegidos (1), poco

protegidos (2), ni poco ni muy protegidos (3), bien protegidos (4) y muy protegidos (5).

Tabla 54 Estadísticas descriptivas de la pregunta 11


Desviación error promedio

¿En qué medida los datos (nombre, código u otro) que permitan identificar a quién realizó un reporte de un caso son protegidos?

60 4,83 0,418 0,054


En la tabla 54 observamos los estadísticos descriptivos para esta pregunta tiene una media

de 4,83 situándose muy cerca de muy protegidos.

La tercera hipótesis específica afirma: “El diseño e implementación de una aplicación móvil

en el sistema operativo Android facilita la consulta de los registros de casos de bullying y/o

violencia escolar.”

197

Para esta hipótesis se analizó los resultados de las preguntas sobre la percepción de

facilidad que encuentran los usuarios al reportar o consultar casos e incidencias en la

aplicación

Tabla 55 Estadísticas descriptivas de las preguntas 8, 9, 10, 12, 13, 14 y 15


Desviación error

promedio

Reportar un caso mediante la aplicación resulta:

60 4,57 0,621 0,08

Responder a un caso reportado mediante la aplicación resulta:

60 4,57 0,673 0,087

Reportar una incidencia mediante la aplicación (inscribiendo, archivando o removiendo) mediante la aplicación resulta:

60 4,32 0,651 0,084

La consulta del listado de casos mediante la aplicación resulta un proceso:

60 4,87 0,389 0,05

La consulta del listado de incidencias mediante la aplicación resulta un proceso:

60 4,63 0,52 0,067

La consulta de la información sobre convivencia escolar enviada por el área de psicología (visible por todos los usuarios) resulta un proceso:

60 4,43 0,621 0,08

¿Qué tanto la aplicación agiliza la consulta de casos e incidencias respecto al proceso manual?

60 4,7 0,497 0,064


En la tabla 55 observamos los estadísticos descriptivos para estas preguntas, estas tienen

una media de entre 4.32 y 4.87 situándose en valores que indican la facilidad que perciben

los usuarios al interactuar con la aplicación y puntualmente en la pregunta 15 que tiene una

198

media de 4,7 indicando que la aplicación agiliza entre mucho y muchísimo la consulta de

casos respecto del proceso manual.

La cuarta hipótesis específica afirma: “El diseño e implementación de una aplicación móvil

en el sistema operativo Android permite compartir información y concientizar sobre el

bullying y/o violencia escolar.”

Para esta hipótesis en específica debemos recurrir a la matriz de trazabilidad (ver apéndice

H) y el acta de conformidad (Ver apéndice J) que comprueban que la aplicación permite

compartir información y de esa manera concientizar sobre el bullying y/o violencia escolar.

Tabla 56 Estadísticas descriptivas de las preguntas 16 y 17


Desviación error promedio

¿Compartir información sobre la convivencia escolar pacífica mediante la aplicación en términos de tiempo es?

60 4,78 0,555 0,072

Agregar información sobre la convivencia escolar pacífica a través del formulario de la aplicación resulta

60 4,83 0,376 0,049


En la tabla 56 observamos los estadísticos descriptivos para las preguntas con identificador

16 y 17 que hacen referencia a compartir información sobre convivencia escolar, teniendo

estas medias de 4,78 y 4,83. Los valores señalan que compartir información se sitúa entre

rápido y muy rápido, y agregar esta información se ubica entre fácil y muy fácil.

199

OBSERVACIONES

Se ratifica que RUP es adaptable a diversos tipos de proyectos de software según su

tamaño. Además, su énfasis en las etapas de análisis y diseño optimizan las etapas

posteriores de desarrollo al tener claros los objetivos, requisitos y expectativas del cliente.

La elección de Android Studio como herramienta de desarrollo fue un factor decisivo que

permitió explotar las nuevas herramientas tecnológicas que provee Google (Android

Jetpack) para generar una programación fluida.

La comunicación constante con el cliente durante la fase de inicio y elaboración jugó un

papel crucial para tener los requisitos claros y evitar sobre tiempos en el proyecto.

El involucramiento durante varios días en la entidad educativa realizando preguntas a

diversos miembros y observando el proceso manual de registro, la preparación del personal

en cuanto a tecnologías informáticas y su disposición a mejorar la gestión de casos de

bullying, permitió modelar de manera más eficiente el sistema.

El presente proyecto utilizó software con licencia para el modelado, pero para el desarrollo

se utilizó software con licencia gratuita, de la misma forma en la fase de pruebas.

Se utilizó el patrón de diseño MVVM que facilitó la gestión de pruebas y encapsulamiento

de las distintas capas de la aplicación que mediante Web Services le dieron total

independencia a la aplicación de la base de datos.

200

De acuerdo con la encuesta realizada, se observa que el modelo educativo de la IEP Pamer

– Salamanca posee mejores niveles de convivencia escolar libre de violencia frente al

promedio en nuestro país y la región, pero siguen implementando diversas alternativas

para seguir mejorando estos niveles. Asimismo, la encuesta realizada confirma los

resultados de estudios previos sobre preferencias en cuanto a computación móvil por parte

de los peruanos al preferir Android, pero también muestra cierto desconocimiento sobre las

versiones que utilizan de sus sistemas operativos.

201

CONCLUSIONES

En relación con los resultados y análisis del instrumento aplicado se desprende que la

implementación del prototipo funcional mejora la gestión de casos de bullying en cuanto al

tiempo respecto del proceso manual, de forma que los miembros de la comunidad

educativa pueden realizar de manera más rápida los procesos para reportar casos por los

miembros de la comunidad educativa, elevar incidencias por parte de los tutores al área de

psicología e inscribir o archivar las incidencias en el libro de incidencias por parte del área

de psicología, puesto que en concordancia con los resultados de las pruebas a la

aplicación: el sistema se encuentra disponible durante las 24 horas, brinda compatibilidad

dispositivos con el sistema operativo Android desde la versión 4.0.3 y tiene un consumo

eficiente de recursos del dispositivo móvil donde se encuentra instalado.


implementación del prototipo funcional en la gestión de casos de bullying provee un

mecanismo de protección de datos que los miembros de la comunidad que reportan los

casos consideran seguro.


implementación del prototipo funcional mejora la gestión de casos de bullying brindando

facilidades de uso en la consulta de casos por parte de los tutores, consulta de incidencias

por parte del área de psicología y visualización de información sobre convivencia escolar

por los miembros de la comunidad educativa. Además, el tiempo de espera para obtener

202

el libro de incidencias por parte del área de coordinación académica y Dirección es menor

que si el proceso fuera manual y accesible en cualquier momento y lugar.

En relación con los resultados y análisis del instrumento aplicado se desprende que el

prototipo funcional permite compartir información sobre la concientización de casos de

bullying y/o violencia escolar a todos los miembros de la comunidad educativa. Además,

generar el libro de incidencias cumpliendo con lo dispuesto en la ley 29733

203

RECOMENDACIONES

Realizar un estudio previo no solo de los procesos que se desean automatizar, sino también

de las expectativas de los futuros usuarios y si se dispone de los recursos tecnológicos

para poder llevar a cabo una implementación y mantenimiento de las soluciones

informáticas.

Para futuras investigaciones y proyectos se recomienda involucrarse con la entidad a

analizar y mantener una comunicación constante con los principales involucrados, ya que

esta comunicación permite mantener un desarrollo con una guía muy marcada reduciendo

el sobrecosto de agregar requisitos o modificarlos drásticamente durante la fase de

desarrollo.

El uso de patrones de desarrollo que facilitan la ejecución de pruebas, separación de capas

y seguir las buenas prácticas son de gran ayuda para un proyecto que tiene como horizonte

seguir escalando, junto a ello la exploración y uso de las nuevas tecnologías y herramientas

de desarrollo, como el caso de Android Jetpack, dan un soporte a los programadores para

tener una solución informática a la vanguardia de los cambios y aprovechándolos.

204

Apéndices

Apéndice A

CUADRO DE OPERACIONALIZACIÓN DE VARIABLES

Operacionalización de variables

Variables Dimensiones Indicadores Instrumentos

Independiente (variable “x”): Diseño e implementación de un prototipo de la aplicación móvil. Dependiente (variable “y”): Impacto del prototipo de la aplicación móvil en la gestión de casos de bullying acoso y/o violencia escolar

Adaptabilidad a los usuarios

Es compatible con los dispositivos que poseen Funciona las 24 horas

Reporte de pruebas de configuración Reporte de pruebas de servicios REST

Rendimiento al usuario

Nivel de consumo de recursos

Reporte de pruebas

Facilidad para reportar

Facilidad para reportar un caso Facilidad para reportar un incidente Facilidad para subir información de convivencia escolar

Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario)

Seguridad de la aplicación.

Protección de datos de quien reporta. Nivel de seguridad de la aplicación al iniciar sesión.

Instrumento de medición (Cuestionario)

Reporte de pruebas de estrés y servicios REST e instrumento de medición (Cuestionario)

Consulta de reportes y visualización de información (anuncios para informar y concientizar sobre bullying)

Tiempo de respuesta al consultar casos. Tiempo de respuesta al consultar incidencias. Tiempo de respuesta al consultar el libro de incidencias Visualización amigable al consultar casos. Visualización amigable al consultar incidencias. Visualización amigable al consultar el libro de incidencias Visualización amigable al consultar información sobre convivencia escolar. Tiempo de respuesta al visualizar información sobre convivencia escolar.

Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario) Instrumento de medición (Cuestionario)

Instrumento de medición (Cuestionario)----- ------- Instrumento de medición (Cuestionario)

205

Apéndice B

CARTA DE COMPROMISO DE LA INSTITUCIÓN CON LA INVESTIGACIÓN

206

Apéndice C

ENCUESTA SOBRE DISPOSITIVOS MÓVILES Y CONVIVENCIA ESCOLAR

Consentimiento informado El propósito del presente es el de brindar a los participantes en esta investigación el rol que

tendrán al participar y las características de la investigación titulada: "Diseño de una

aplicación móvil para registrar e informar casos de bullying en un colegio privado de Lima"

El objetivo de la investigación en la cual puede ser participante es la de desarrollar un

prototipo de una aplicación móvil para gestionar (reportar y consultar) casos de bullying y/o

violencia escolar. Asimismo, informar sobre la convivencia escolar pacífica en la comunidad

educativa de su Institución. La presente investigación es conducida por el investigador Jhon

Paul Anampa García.

Si usted accede a participar en este estudio, se le pedirá resolver un cuestionario, lo que

le tomará 10 a 15 minutos aproximadamente. Para ello solo se requiere del registro de sus

respuestas en el cuestionario que se le presentará a continuación.

Su participación es completamente voluntaria, todos los datos recogidos serán con fines

educativos, de investigación y confidenciales.

Solo se requiere que indique su rol en la institución educativa, de manera que el

cuestionario resuelto por usted será absolutamente confidencial.

Si tiene alguna duda con relación al desarrollo del proyecto, comunicarse con al correo

[email protected]

Usted si lo decide puede finalizar su participación del presente estudio cuando lo desee,

sin que esto implique algún perjuicio a su persona.

Muchas gracias por su participación.

207

A: INFORMACIÓN PERSONAL

1. Género (Marca solo un recuadro.)

Mujer

Varón

2. Año de nacimiento: __________

B: INFORMACIÓN SOBRE SU INSTITUCIÓN

3. Cuál es su rol/cargo en la institución Educativa (Marca solo un recuadro.)

Promotor(a) Pasa a la pregunta 5.

Director(a) académico(a) Pasa a la pregunta 5.

Psicólogo(a) Pasa a la pregunta 5.

Tutor(a) Pasa a la pregunta 5.

Docente Pasa a la pregunta 5.

Personal Administrativo Pasa a la pregunta 5.

Coordinador(a) académico(a) Pasa a la pregunta 5.

Estudiante Pasa a la pregunta 4.

Padre de familia/Apoderado de un(os) estudiante(s) Pasa a la pregunta 4.

Otro: (Especificar) _______________ Pasa a la pregunta 4.

B1: Grado (En caso sea usted padre de familia, señalar el grado en el cual se encuentra

su hijo.) 4. Actualmente te encuentras en: (Marca solo un recuadro.)

Tercero de Secundaria

Cuarto de Secundaria

Quinto de secundaria

Otro: (Especificar) _______________

208

C: DISPOSITIVOS MÓVILES

5. ¿Posees algún dispositivo móvil? Por ejemplo: Smartphone, Tablet, iPhone, iPad, etc.

(Marca solo un recuadro.)

Sí (De uso personal) Pasa a la pregunta 6.

Sí (De uso compartido con: mis padres, hermanos(as), etc.) Pasa a la pregunta 6.

No Pasa a la pregunta 8.

C1: INFORMACIÓN DEL DISPOSITIVO

6. ¿Qué sistema operativo usas? (Puedes marcar más de uno si tuvieras más de un

dispositivo.)

Android (Samsung, HTC, Asus, Sony, Motorola, LG, Huawei, etc.)

iOS (iPhone, iPad, etc.)

Otro: ________________

7. ¿Qué versión del sistema operativo utilizas? (En caso no lo sepas, puedes dejarlo en

blanco)

_______________________

209

D: Sobre el Bullying (En caso de no ser estudiante señale si como miembro

de la comunidad educativa ha sido testigo o víctima).

8. ¿Alguna vez has sido víctima o testigo de un caso de bullying en la escuela? (Marca

solo un recuadro.)

Sí

No

9. ¿Alguna vez has sido víctima o testigo de un caso de bullying por Internet o teléfono

por compañeros de tu colegio? (Marca solo un recuadro.)

Sí

No

E: VALORACIÓN DE LA APLICACIÓN (En caso de no ser

estudiante considérelo de acuerdo con su rol como miembro de la comunidad educativa, y en caso de no poseer un dispositivo móvil, señale su respuesta en el supuesto que lo tuviera)

10. ¿Te gustaría tener una aplicación en su celular que te permita reportar un caso de

bullying de manera anónima y segura? (Marca solo un recuadro.)

Sí

No

11. Si tuvieras una aplicación en tu celular o tablet que permita de manera anónima

informar de estos hechos como lo valorarías (Marca solo un óvalo.)

Nada útil O O O O O

Muy útil 1 2 3 4 5

GRACIAS: Para cualquier duda comunicarse con el investigador Jhon Paul Anampa García al correo: [email protected]


210

Apéndice D

RESULTADOS DE LA ENCUESTA SOBRE DISPOSITIVOS MÓVILES Y

CONVIVENCIA ESCOLAR

P1 ¿Alguna vez has sido víctima o testigo de un caso de bullying en la escuela?

P2 ¿Alguna vez has sido víctima o testigo de un caso de bullying por Internet o teléfono por compañeros de tu colegio?

P3 ¿Te gustaría tener una aplicación en su celular que te permita reportar un caso de bullying de manera anónima y segura?

P4 Si tuvieras una aplicación en tu celular o Tablet que permita de manera anónima informar de estos hechos como lo valorarías del 1 al 5

Género Año de

nacimiento Rol/cargo

Grado del estudiante

Tiene dispositivo SO Versión del SO

P1 P2 P3 P4

Mujer 1995 Padre de familia/Apoderado de un(os) estudiante(s)

Inicial Sí (De uso personal)

Android NR No No Sí 5

Varón 1976 Padre de familia/Apoderado de un(os) estudiante(s)

Sexto de primaria

Sí (De uso personal)

Android 7 Sí Sí Sí 5

Varón 2002 Estudiante Cuarto de secundaria



Mujer 2003 Estudiante Cuarto de secundaria


iOS NR Sí No Sí 4






Otro NR No Sí Sí 4






Android NR Sí No Sí 5



Android NR Sí Sí Sí 5






Otro NR Sí Sí Sí 5






Android NR No Sí Sí 2












Android NR Sí No No 3



iOS 11 Sí No Sí 2



iOS 11 Sí No Sí 5



Android 6 No No No 4






iOS 11 Sí Sí Sí 5






Android NR Sí Sí No 3







211



iOS 11 Sí Sí Sí 5









Android NR No No No 3






Android 6.0.1 No No No 2





















iOS 11.2 Sí No Sí 3



iOS NR No No Sí 4



iOS NR No No No 1


















iOS NR No No Sí 4



iOS NR No No Sí 5









iOS NR No Sí No 1






























iOS 11.03 Sí Sí Sí 3






iOS NR No No Sí 4






iOS NR Sí No Sí 5



iOS 11 No Sí Sí 4




212

























Varón 2001 Estudiante Quinto de secundaria






Mujer 2002 Estudiante Quinto de secundaria




















Android NR No Sí No 4






Android 8.1 Sí No Sí 5



iOS NR Sí No No 4





















Android 7.1 Sí No Sí 4



iOS NR Sí No Sí 4









Android 5.1.2 Sí Sí Sí 5






Android 6 Sí Sí No 3



iOS 5.5 Sí Sí No 3












Android 5.1.1 Sí Sí Sí 4










213



iOS NR No No Sí 5









Android 5.0.1 Sí No Sí 4












Android 6 No No Sí 5



iOS NR No No Sí 2















iOS NR No No No 2






iOS 11.8 No No Sí 4




































iOS 10 No No Sí 4












iOS 11 Sí Sí No 3






iOS NR No No Sí 5









Android 4.2 Sí No No 3




Mujer 2004 Estudiante Tercero de secundaria


iOS 11 Sí No Sí 5

Varón 2003 Estudiante Tercero de secundaria






214









iOS 11.3 No Sí Sí 5






iOS 11.3 Sí Sí Sí 5















iOS NR No No Sí 4






Android 6 Sí No Sí 5



iOS NR Sí No Sí 5





















iOS 11 No No Sí 3









iOS 11.0.2 No No No 2






iOS NR No No Sí 4






iOS NR No No Sí 4



iOS 5 No No No 1




































iOS NR Sí No Sí 5




215















Android NR No Sí No 3





















Android 6.1 Sí Sí Sí 3






iOS NR No No Sí 3









iOS NR Sí No Sí 4
























iOS NR Sí No Sí 4















Android 5 No Sí Sí 3






iOS NR No No No 2















iOS NR No No No 5













216





















iOS NR No No Sí 3
























Android 4.4 No No No 1




Mujer 1983 Coordinador(a) académico(a)

Sí (De uso personal) Android

4 No Sí Sí 5

Mujer 1985 Personal Administrativo


NR No No Sí 5

Varón 1992 Docente


7 Sí Sí Sí 5

Mujer 1988 Docente


NR Sí No Sí 4

Mujer 1988 Docente


NR Sí No Sí 5

Mujer 1989 Tutor(a)


NR Sí No Sí 5

Mujer 1993 Tutor(a)

Sí (De uso personal) Android 6

Sí No Sí 4

Varón 1982 Psicólogo(a)


NR No No Sí 5


Sí (De uso personal) Android 6 No Sí Sí 5

Varón 1950 Otro

Sí (De uso personal) Otro

NR No No Sí 5

Varón 1986 Otro


NR Sí Sí Sí 3

Mujer 1964 Director(a) académico(a)


NR No Sí Sí 5

Varón 1980 Docente


NR No No No 3

Varón 1980 Docente


NR Sí No Sí 4

Varón 1984 Docente


NR Sí Sí Sí 4

Varón 1985 Docente


NR Sí No Sí 4


Sí (De uso personal) Android 7 Sí Sí Sí 4

Mujer 1992 Tutor(a)

Sí (De uso personal) iOS

NR No No Sí 5

Mujer 1994 Tutor(a)


NR No No Sí 5

Mujer 1971 Psicólogo(a)


NR Sí No Sí 5

Mujer 1984 Tutor(a)


NR No No Sí 4

Mujer 1995 Docente

Sí (De uso personal) iOS 11.3 Sí Sí Sí 5


Sí (De uso compartido)







Otro NR Sí No Sí 4

217



iOS NR No No No 3



iOS NR No Sí Sí 5


No No No Sí 4


No Sí No Sí 5


No Sí No Sí 3


No Sí Sí Sí 4


No No No Sí 4


No No No Sí 5


No No No Sí 5


No No No No 3


No No No Sí 5


No No No Sí 4


No No No Sí 4


No No No Sí 5

218

Apéndice E

CUESTIONARIO SOBRE LA APLICACIÓN ANTIBULLYING-SHIELD

Consentimiento informado para participantes

El propósito del presente es el de brindar a los participantes en esta investigación el rol que tendrán al participar y las características de la investigación titulada: "Diseño de una aplicación móvil para registrar e informar casos de bullying en un colegio privado de Lima" El objetivo de la investigación en la cual puede ser participante es la de desarrollar un prototipo de una aplicación móvil para gestionar (reportar y consultar) casos de bullying y/o violencia escolar. Asimismo, informar sobre la convivencia escolar pacífica en la comunidad educativa de su Institución. La presente investigación es conducida por el investigador Jhon Paul Anampa García. Si usted accede a participar en este estudio, se le pedirá resolver un cuestionario, luego de observar una demostración del prototipo de la aplicación, que puede visualizar en el siguiente enlace: https://youtu.be/gqXsbSz2dco Su participación es completamente voluntaria, todos los datos recogidos serán con fines educativos, de investigación y confidenciales. Solo se requiere que indique su rol en la institución educativa, de manera que el cuestionario resuelto por usted será absolutamente confidencial. Si tiene alguna duda con relación al desarrollo del proyecto, comunicarse con al correo [email protected] Usted si lo decide puede finalizar su participación del presente estudio cuando lo desee, sin que esto implique algún perjuicio a su persona.

Muchas gracias por su participación.

Cuál es su rol/cargo en la institución Educativa (Marca solo un recuadro.)

Director(a) académico(a)

Coordinador(a) académico(a)

Psicólogo(a)

Tutor(a)

Docente

Estudiante

Padre de familia/Apoderado de un(os) estudiante(s)

Otro: (Especificar) _______________

https://youtu.be/gqXsbSz2dco


219

A: Tiempo de respuesta de la aplicación. Una vez conectados a una red de internet, valorar el tiempo de respuesta de la aplicación. Nota: algunas funciones son solo de determinados usuarios, pero conteste de acuerdo con su criterio sobre la fácil o difícil que considere usted al proceso.

1. El tiempo de respuesta para iniciar sesión en la aplicación es: (Marca solo un óvalo.)

Muy lento O O O O O

Muy rápido 1 2 3 4 5

2. El tiempo de respuesta para ver listados de casos o incidencias en la aplicación es:

(Marca solo un óvalo.)

Muy lento

O O O O O Muy rápido

1 2 3 4 5

3. El tiempo de respuesta para ver casos o incidencias a detalle en la aplicación es:


Muy lento O O O O O


220

4. El tiempo de respuesta para ver información sobre la convivencia escolar pacífica en

la aplicación es: (Marca solo un óvalo.)

Muy lento O O O O O


5. ¿La aplicación reduce el tiempo para reportar casos de bullying y/o violencia escolar?


Muy poco O O O O O

Muchísimo 1 2 3 4 5

6. ¿La aplicación reduce el tiempo para responder a los casos o incidencias de bullying

y/o violencia escolar? (Marca solo un óvalo.)

Muy poco O O O O O


7. ¿La aplicación reduce el tiempo para obtener un libro de incidencias en formato

electrónico? (Marca solo un óvalo.)

Muy poco O O O O O


221

B: Reporte de casos e incidencias. Nota: algunas funciones son solo de determinados usuarios, pero conteste de acuerdo con su criterio sobre la fácil o difícil que considere usted al proceso.

8. Reportar un caso mediante la aplicación resulta: (Marca solo un óvalo.)

Muy difícil O O O O O

Muy fácil 1 2 3 4 5

9. Responder a un caso reportado mediante la aplicación resulta: (Marca solo un óvalo.)



10. Responder a una incidencia (inscribiendo, archivando o removiendo) mediante la

aplicación resulta: (Marca solo un óvalo.)



11. ¿En qué medida los datos (nombre, código u otro) que permitan identificar a quién

realizó un reporte de un caso son protegidos? (Marca solo un óvalo.)

Nota: Cuando un estudiante o cualquier miembro de la comunidad educativa reporta un caso, este

permanece anónimo, pero se puede solicitar a la directora o coordinadora académica los datos

según lo consideren necesario. Por ejemplo, cuando se realiza una acusación falsa, se envían

mensajes ofensivos o se hace mal uso de la plataforma.

Nada protegidos

O O O O O Muy protegidos 1 2 3 4 5

222

C: Consulta de información. Nota: algunas funciones son solo de determinados usuarios, pero conteste de acuerdo con su criterio sobre la fácil o difícil que considere usted al proceso.

12. La consulta del listado de casos mediante la aplicación resulta un proceso: (Marca solo

un óvalo.)



13. La consulta del listado de incidencias mediante la aplicación resulta un proceso:




14. La consulta de la información sobre convivencia escolar enviada por el área de

psicología resulta un proceso: (Marca solo un óvalo.)



15. ¿Qué tanto la aplicación agiliza la consulta de casos e incidencias respecto al proceso

manual? (Marca solo un óvalo.)

Muy poco O O O O O


223

D: La convivencia escolar pacífica Nota: algunas funciones son solo de determinados usuarios, pero conteste de acuerdo con su criterio sobre la fácil o difícil que considere usted al proceso.

16. ¿Compartir información sobre la convivencia escolar pacífica mediante la aplicación en

términos de tiempo es? Ejemplo: al cargar una imagen o un enlace web. (Marca solo un

óvalo.)

Muy lento O O O O O


17. Agregar información sobre la convivencia escolar pacífica a través del formulario de la

aplicación resulta: (Marca solo un óvalo.)

Muy difícil

O O O O O Muy fácil

1 2 3 4 5

GRACIAS: Para cualquier duda comunicarse con el investigador Jhon Paul Anampa García al correo: [email protected]


224

Apéndice F

VALIDACIÓN DEL INSTRUMENTO DE INVESTIGACIÓN MEDIANTE OPINIÓN DE

EXPERTO

DATOS GENERALES:

Apellidos y Nombres del informante:

Grado académico del informante:

Apellidos y Nombres del investigador: Anampa García, Jhon Paul

Título de la investigación: Diseño de una aplicación móvil para registrar e informar casos de bullying en un colegio privado de Lima

Título del instrumento: Cuestionario sobre la aplicación Antibullying-Shield

ASPECTOS DE LA VALIDACIÓN:

Número de pregunta

Deficiente (1)

Regular (2)

Bueno (3)

Muy bueno (4)

Excelente (5)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Total

OPINIÓN SOBRE LA APLICABILIDAD ( ) El instrumento puede ser aplicado ( ) El instrumento debe mejorarse antes de su aplicación.

Lima, __de _________ de 2018

Firma del experto informante DNI: Teléfono:

225

226

227

228

Apéndice G

RESULTADOS DEL CUESTIONARIO SOBRE LA APLICACIÓN ANTIBULLYING-

SHIELD

Leyenda:

Número Pregunta

P01 El tiempo de respuesta para iniciar sesión en la aplicación es:

P02 El tiempo de respuesta para ver listados de casos o incidencias en la aplicación es:

P03 El tiempo de respuesta para ver casos o incidencias a detalle en la aplicación es:

P04 El tiempo de respuesta para ver información sobre la convivencia escolar pacífica en la aplicación es:

P05 ¿La aplicación reduce el tiempo para reportar casos de bullying y/o violencia escolar?

P06 ¿La aplicación reduce el tiempo para responder a los casos o incidencias de bullying y/o violencia escolar?

P07 ¿La aplicación reduce el tiempo para obtener un libro de incidencias en formato electrónico?

P08 Reportar un caso mediante la aplicación resulta:

P09 Responder a un caso reportado mediante la aplicación resulta:

P10 Reportar una incidencia mediante la aplicación (inscribiendo, archivando o removiendo) mediante la aplicación resulta:

P11 ¿En qué medida los datos (nombre, código u otro) que permitan identificar a quién realizó un reporte de un caso son protegidos?

P12 La consulta del listado de casos mediante la aplicación resulta un proceso:

P13 La consulta del listado de incidencias mediante la aplicación resulta un proceso:

P14 La consulta de la información sobre convivencia escolar enviada por el área de psicología (visible por todos los usuarios) resulta un proceso:

P15 ¿Qué tanto la aplicación agiliza la consulta de casos e incidencias respecto al proceso manual?

P16 ¿Compartir información sobre la convivencia escolar pacífica mediante la aplicación en términos de tiempo es?

P17 Agregar información sobre la convivencia escolar pacífica a través del formulario de la aplicación resulta:

229

Resultados:

N P01 P02 P03 P04 P05 P06 P07 P08 P09 P10 P11 P12 P13 P14 P15 P16 P17

1 5 5 4 4 5 5 5 5 5 4 5 5 5 4 5 5 5

2 4 4 4 4 3 3 3 3 4 4 3 3 3 3 3 4 4

3 4 4 4 4 4 4 5 3 3 3 5 5 5 5 5 5 5

4 5 5 5 5 4 4 5 5 5 5 5 5 5 5 5 5 5

5 4 5 5 4 5 5 5 5 3 3 5 5 5 5 5 5 5

6 5 5 5 5 5 5 5 5 5 4 5 5 5 3 5 5 4

7 4 4 4 4 5 5 5 5 5 5 5 5 4 4 5 4 4

8 5 5 5 5 4 5 5 5 5 4 5 4 4 4 4 5 5

9 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

10 5 5 5 4 5 5 4 5 5 5 5 5 5 5 5 5 5

11 4 4 5 4 5 5 5 5 5 5 5 5 5 5 5 5 5

12 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5

13 5 5 5 4 5 4 4 4 4 5 5 5 5 5 5 4 5

14 5 5 5 5 5 4 5 4 4 4 4 4 4 4 5 5 5

15 5 5 5 5 5 5 4 4 4 4 4 5 5 4 5 5 4

16 5 5 5 4 5 5 5 5 5 4 4 5 4 4 4 5 5

17 5 4 5 4 4 4 4 5 5 5 5 5 4 4 4 3 5

18 4 5 5 5 4 5 5 4 4 4 5 5 5 5 4 5 5

19 5 5 5 5 4 4 5 5 5 5 5 5 4 4 5 5 5

20 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

21 5 5 5 5 5 5 5 4 4 4 5 5 5 5 5 5 5

22 5 5 5 5 5 5 5 4 5 4 5 5 5 5 5 5 5

23 5 5 4 5 5 5 4 5 5 5 5 5 5 4 5 5 5

24 5 5 5 5 5 5 5 4 5 4 5 5 5 5 5 5 5

25 5 5 5 5 5 5 4 4 4 4 4 5 5 4 5 5 4

26 5 5 5 4 5 5 5 5 5 4 4 5 4 4 4 5 5

27 5 4 5 4 4 4 4 5 5 5 5 5 4 4 4 3 5

28 4 5 5 5 4 5 5 4 4 4 5 5 5 5 4 5 5

29 5 5 5 5 4 4 5 5 5 5 5 5 4 4 5 5 5

30 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

31 5 5 5 5 5 5 5 4 4 4 5 5 5 5 5 5 5

32 5 5 5 5 5 5 5 4 5 4 5 5 5 5 5 5 5

33 5 5 4 5 5 5 4 5 5 5 5 5 5 4 5 5 5

34 5 5 5 5 5 5 5 4 5 4 5 5 5 5 5 5 5

35 5 5 5 5 5 5 4 4 4 4 4 5 5 4 5 5 4

36 5 5 5 4 5 5 5 5 5 4 4 5 4 4 4 5 5

37 5 4 5 4 4 4 4 5 5 5 5 5 4 4 4 3 5

38 4 5 5 5 4 5 5 4 4 4 5 5 5 5 4 5 5

39 5 5 5 5 4 4 5 5 5 5 5 5 4 4 5 5 5

40 4 4 4 4 4 4 5 3 3 3 5 5 5 5 5 5 5

41 5 5 5 5 4 4 5 5 5 5 5 5 5 5 5 5 5

42 4 5 5 4 5 5 5 5 3 3 5 5 5 5 5 5 5

43 5 5 5 5 5 5 5 5 5 4 5 5 5 3 5 5 4

44 4 4 4 4 5 5 5 5 5 5 5 5 4 4 5 4 4

45 5 5 5 5 4 5 5 5 5 4 5 4 4 4 4 5 5

46 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

47 5 4 5 4 4 4 4 5 5 5 5 5 4 4 4 3 5

48 4 5 5 5 4 5 5 4 4 4 5 5 5 5 4 5 5

49 5 5 5 5 4 4 5 5 5 5 5 5 4 4 5 5 5

50 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

51 5 5 5 5 5 5 5 4 4 4 5 5 5 5 5 5 5

52 5 5 5 5 5 5 5 4 5 4 5 5 5 5 5 5 5

53 4 4 4 4 4 4 5 3 3 3 5 5 5 5 5 5 5

54 5 5 5 5 4 4 5 5 5 5 5 5 5 5 5 5 5

55 4 5 5 4 5 5 5 5 3 3 5 5 5 5 5 5 5

56 5 5 5 5 5 5 5 5 5 4 5 5 5 3 5 5 4

57 4 4 4 4 5 5 5 5 5 5 5 5 4 4 5 4 4

58 5 5 5 5 4 5 5 5 5 4 5 4 4 4 4 5 5

59 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

60 5 5 5 5 4 5 5 5 5 4 5 4 4 4 4 5 5

230

Apéndice H

MATRIZ DE TRAZABILIDAD DE CASOS DE USO Y REQUISITOS

Requisitos

Casos de uso

CU

S-0

01 I

nic

iar

sesió

n

CU

S-0

02 C

err

ar

sesió

n

CU

S-0

03 R

eport

ar

un c

aso

CU

S-0

04 C

onsultar

casos

CU

S-0

05 A

rchiv

ar

caso

CU

S-0

06 R

eport

ar

una

incid

encia

CU

S-0

07 C

onsultar

incid

encia

CU

S-0

08 D

escarg

ar

libro

de in

cid

encia

s

CU

S-0

09 I

nscrib

ir

incid

encia

CU

S-0

10 A

rchiv

ar

incid

encia

CU

S-0

11 R

em

over

incid

encia

CU

S-0

12 E

nvia

r dato

s

CU

S-0

13 E

nvia

r

info

rma

ció

n

CU

S-0

14 V

isualiz

ar

info

rma

ció

n

Código El sistema debe permitir:

RQF-0001

Iniciar sesión.

X

RQF-0002

Cerrar sesión.

X X

RQF-0003

Interfaz de usuario propia.

X X X X X X X X X X X X X X

RQF-0004

Reportar un caso.

X X

RQF-0005

Reportar una incidencia.

X X

RQF-0006

Gestionar casos.

X X X X

RQF-0007

Gestionar incidencias.

X X X X X X X

RQF-0008

Gestionar información sobre convivencia escolar.

X X X

RQF-0009

Administrar datos sensibles.

X X X

231

Apéndice I

PLAN DE PROYECTO DE DESARROLLO

PLAN DE DESARROLLO DE SOFTWARE

IEP PAMER – SALAMANCA

Sistema de reporte de casos de bullying, acoso y/o violencia escolar- “ANTIBULLYING-SHIELD”

Actualizado al 08-05-2018

Versión: 1.2

232

HISTORIAL DE LAS REVISIONES

Nro. Versión Fecha Autor Descripción Estado Responsable de

Revisión y/o Aprobación

01 1.0 13/04/2018 Jhon Paul

Anampa García Versión preliminar En revisión Angela De La Cruz

02 1.1 17/04/2018 Jhon Paul

Anampa García Versión preliminar En revisión Angela De La Cruz

03 1.2 08/05/2018 Jhon Paul

Anampa García Versión final Aprobado Angela De La Cruz

1. INTRODUCCIÓN

Este documento detalla el plan de desarrollo del proyecto “Sistema de reporte de casos de bullying y/o violencia escolar”. Este proyecto utiliza el modelo de desarrollo RUP, del cual detalla cada etapa y tiene como finalidad la compresión del ciclo de desarrollo del proyecto.

1.1. PROPÓSITO DEL PLAN

Este documento tiene el fin de brindar la información del proyecto, para su control y describir el modelo de desarrollo seguido. El actual documento es desarrollado por el jefe de proyecto y los miembros del grupo del proyecto pueden acceder a este.

1.2. ALCANCE

El presente documento tiene como fin describir el plan usado para el desarrollo del “Sistema de reporte de casos de bullying, acoso y/o violencia escolar”, en este se definen las características del producto a desarrollar. 2. RESUMEN EJECUTIVO

La IEP Pamer – Salamanca busca mejorar los servicios que ofrece y cumplir con lo establecido por la Ley que promueve la convivencia sin violencia en las instituciones educativas (N° 29719 - 2011), por consiguiente desea integrar a las campañas de concientización y apoyo psicológico, que brinda tanto a estudiantes como padres de familia, recursos tecnológicos para de esta manera alcanzar un ambiente de armonía en su comunidad educativa y cumplir con las disposiciones de la Ley N° 29719 como son el libro de incidencias y brindar información sobre bullying y/o violencia escolar a su comunidad educativa en tiempo real. En este caso se sugiere la implementación de la aplicación móvil Antibullying-Shield, para mejorar la gestión de casos de bullying y/o violencia escolar en la IEP.

3. ANTECEDENTES

El proceso manual que se utiliza para dar tratamiento a los actos que atentan contra la convivencia escolar sin violencia inicia cuando un estudiante desea reportar un caso de bullying, acoso y/o violencia escolar, siempre que este lo reporte a un miembro que no sea otro estudiante, el caso pasa a manos de su tutor, quien evalúa e indaga sobre el caso tomando la decisión de llevar el caso al departamento psicológico, donde el psicólogo evaluará la situación y decidirá si procede a inscribirse este en el libro de incidencias.

233

Finalmente, dará tratamiento al caso. En caso el estudiante pase directamente con el psicólogo o la directora, estos de igual forma darán parte al tutor para que indague e informe al área de psicología, para continuar con el proceso. En este sentido, se encuentra la necesidad de mejorar el sistema de gestión de casos de bullying, acoso y/o violencia escolar en la comunidad educativa y el cyberbullying en entornos extracurriculares, los cuales son procesos manuales. Además, poder optimizar la recepción de estos casos y a la vez automatizar el libro de incidencias para tener llevar a cabo un control más preciso y en tiempo real sobre los casos.

4. OBJETIVO DEL PROYECTO

El presente proyecto tiene como objetivo implementar el sistema Antibullying-Shield para la gestión de casos de bullying, acoso y/o violencia escolar. 5. ALCANCE DEL PROYECTO

5.1. DESCRIPCIÓN DEL SISTEMA

El sistema automatiza el proceso manual de reportes de casos de bullying y/o violencia escolar, permite consultas en tiempo real sobre los mismos (ambos a través de una aplicación móvil para Android), la creación de un libro de incidencias electrónico y difundir información sobre la convivencia escolar libre de violencia a los estudiantes. Permite asegurar la anonimidad de quienes reportan los casos y pueden ser realizados durante cualquier momento del día. Los casos e incidencias pueden ser visualizados por ciertos miembros de la comunidad educativa, desde sus dispositivos móviles o computadoras. Permite que el área de psicología y/o tutoría envíen información a los estudiantes, los cuales la visualizarán en sus dispositivos móviles.

5.2. DESCRIPCIÓN DE LOS PROCESOS DE NEGOCIO (REPORTAR)

Para llevar a cabo cualquier acción el miembro de la comunidad educativa debe iniciar sesión en la aplicación móvil. Cualquier miembro puede realizar un reporte a través de la aplicación móvil, para ello debe indicar la fecha, descripción, sección y opcionalmente un archivo multimedia, este reporte llega al tutor, quien hará las indagaciones según corresponda y decidirá si procede como una incidencia o no. A través de la misma aplicación indicando su descargo de manera textual e indicar si procede como incidencia o no y opcionalmente un archivo multimedia. En caso proceda, el psicólogo recibirá la incidencia y realizará las indagaciones y tratamiento que considere y escribirá su descargo textual, indicará si procede o no a inscribirse en el libro de incidencias y opcionalmente agregar un archivo multimedia. Si este procede, se inscribirá en el libro de incidencias con todos sus detalles.

5.3. DENTRO DE ALCANCE

- La aplicación permite ingresar a la aplicación mediante el código del miembro de

la comunidad y una contraseña.

- La aplicación permite reportar un caso en tiempo real, adjuntando si lo desea un

archivo multimedia, el cuál será derivado al tutor de la sección correspondiente. El

tutor decide si el caso prosigue para convertirse en una incidencia.

- La aplicación protege los datos de quien realizó el caso. Solo ciertos miembros

clave de la comunidad educativa tendrán acceso a esos datos.

234

- La aplicación permite que un caso se transforme en una incidencia, luego el

psicólogo educativo decidirá si se inscribe o no en el libro de incidencias. Solo el

tutor o el psicólogo pueden reportar una incidencia directamente.

- La aplicación permite que una incidencia sea escrita en el libro de incidencias.

Asimismo, permite la consulta de casos e incidencias en tiempo real por parte de

los miembros de la comunidad educativa que poseen ese nivel de acceso.

- La aplicación permite que se comparta información a los estudiantes a través de

esta para concientizar sobre la convivencia escolar.

5.4. FUERA DE ALCANCE

- Solo los tutores deciden luego de hacer una indagación si el caso para a ser una incidencia o no (de acuerdo con su criterio).

- Solo los psicólogos deciden luego de hacer una indagación si la incidencia pasa a ser inscrita en el libro de incidencias o no (de acuerdo con su criterio).

- Se protege los datos de quien realiza el reporte. Solo el encargado de dicha información (designado por la comunidad educativa) tendrá acceso y podrá brindarla a quien se lo solicite, de forma que no se puede controlar el factor humano.

- La veracidad de los casos depende del factor humano, al ser estos quienes realizan los reportes.

5.5. RESTRICCIONES

Ítem Restricciones

1 El desarrollo del Sistema debe estar desarrollado en Java, PHP y MySQL

2 El administrador debe tener todos los accesos al sistema y permisos de modificación de usuarios.

6. REQUERIMIENTOS DEL PROYECTO

6.1. REQUERIMIENTOS DE PERSONAL

Nro. de

Personas Cargo / Rol

01 Jefe de Proyecto

01 Documentador

01 Analista de sistemas

01 Diseñador

01 Programador

01 Analista de base de datos

6.2. EQUIPOS Y DISPOSITIVOS

Ítem Descripción Cantidad Fecha en que se requiere

1 PC personal 1 14/02/2018

2 Laptop 1 25/02/2018

3 Smartphone 1 14/02/2018

235

6.3. SERVIDORES

6.4. REDES Y COMUNICACIONES

6.5. SOFTWARE

- NetBeans IDE

- MySQL Workbench 6.3 CE

- Android Studio

- StarUML o Rational Rose

- Corel Draw 2018

- Adobe Photoshop CS6

- Open Office, Microsoft Office o Google Documents

6.6. INFRAESTRUCTURA Y MOBILIARIO


1 Escritorios 2 14/02/2018

2 Sillas 2 14/02/2018

7. ESTRATEGIA DE EJECUCIÓN DEL PROYECTO

7.1. MODELO DE DESARROLLO

Se utiliza el método RUP.


1 Servidor que soporte MySQL y PHP 1 14/02/2018

Ítem Descripción Cantidad Fecha en

que se requiere

1 Cableado para 2 equipos s/n 14/02/2018

2 Línea Telefónica con Internet 1 14/02/2018

3 Switch administrable Cisco. 1 14/02/2018

236

7.2. FASES DEL PROYECTO

Fase Iteraciones Duración

Inicio 1 6 días

Elaboración 2 23 días

Construcción 3 88 días

7.3. CALENDARIO

Jhon Paul Anampa García Jefe de proyecto

Stakeholder de la organización

237

Apéndice J

DOCUMENTO DE CONFORMIDAD

ACTA DE CONFORMIDAD

Lima, 18 de septiembre de 2018

Mediante la presente se da la conformidad por el trabajo realizado de implementación de

un prototipo funcional para la gestión de casos de bullying, dejando constancia que el

investigador Jhon Paul Anampa García deja con buen funcionamiento el prototipo de la

aplicación móvil para el sistema operativo Android llamado: “Antibullying – Shield”, que

forma parte de la investigación de título: “Diseño de una aplicación móvil para registrar e

informar casos de bullying en un colegio privado de Lima”.

Sin otro particular.

Jhon Paul Anampa García Jefe de proyecto

Stakeholder de la organización

238

Apéndice K

RESULTADOS DEL TEST MONKEY

1. Resultados para LoginActivity.java

1.1. Sentencia en el terminal de Android:

Sdk\platform-tools>adb shell monkey -p com.example.jhon.antibullying -v 1000

1.2. Respuesta

bash arg: -p bash arg: com.example.jhon.antibullying bash arg: -v bash arg: 1000 args: [-p, com.example.jhon.antibullying, -v, 1000] arg: "-p" arg: "com.example.jhon.antibullying" arg: "-v" arg: "1000" data="com.example.jhon.antibullying" :Monkey: seed=1540291733137 count=1000 :AllowPackage: com.example.jhon.antibullying :IncludeCategory: android.intent.category.LAUNCHER :IncludeCategory: android.intent.category.MONKEY // Event percentages: // 0: 15.0% // 1: 10.0% // 2: 2.0% // 3: 15.0% // 4: -0.0% // 5: -0.0% // 6: 25.0% // 7: 15.0% // 8: 2.0% // 9: 2.0% // 10: 1.0% // 11: 13.0% :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.LoginActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.LoginActivity } in package com.example.jhon.antibullying :Sending Trackball (ACTION_MOVE): 0:(-2.0,3.0) :Sending Touch (ACTION_DOWN): 0:(1149.0,433.0) :Sending Touch (ACTION_UP): 0:(1203.9458,432.42407) :Sending Touch (ACTION_DOWN): 0:(995.0,1726.0) :Sending Touch (ACTION_UP): 0:(997.7499,1731.0173) :Sending Trackball (ACTION_MOVE): 0:(0.0,-1.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,2.0) :Sending Touch (ACTION_DOWN): 0:(1362.0,1355.0) :Sending Touch (ACTION_UP): 0:(1357.5286,1356.0789) :Sending Touch (ACTION_DOWN): 0:(49.0,564.0) :Sending Touch (ACTION_UP): 0:(38.619457,574.5332) :Sending Touch (ACTION_DOWN): 0:(1396.0,895.0) :Sending Touch (ACTION_UP): 0:(1359.9746,941.9805) :Sending Trackball (ACTION_MOVE): 0:(2.0,3.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,-1.0) :Sending Touch (ACTION_DOWN): 0:(774.0,1847.0) //[calendar_time:2018-10-21 12:40:31.421 system_uptime:3267234] // Sending event #100 :Sending Touch (ACTION_UP): 0:(742.16205,1805.0028) :Sending Trackball (ACTION_MOVE): 0:(-5.0,4.0) :Sending Touch (ACTION_DOWN): 0:(79.0,38.0)

239

:Sending Touch (ACTION_UP): 0:(78.75176,40.181442) :Sending Touch (ACTION_DOWN): 0:(861.0,1749.0) :Sending Touch (ACTION_UP): 0:(835.5083,1761.0981) :Sending Touch (ACTION_DOWN): 0:(1084.0,37.0) :Sending Touch (ACTION_UP): 0:(1071.1041,30.137676) :Sending Touch (ACTION_DOWN): 0:(641.0,2219.0) :Sending Touch (ACTION_UP): 0:(633.34534,2230.5767) :Sending Touch (ACTION_DOWN): 0:(1311.0,524.0) :Sending Touch (ACTION_UP): 0:(1359.8413,630.52625) :Sending Trackball (ACTION_MOVE): 0:(4.0,2.0) :Sending Touch (ACTION_DOWN): 0:(1038.0,1563.0) :Sending Touch (ACTION_UP): 0:(1038.4211,1566.5657) :Sending Touch (ACTION_DOWN): 0:(307.0,2293.0) :Sending Touch (ACTION_UP): 0:(310.7331,2305.635) :Sending Touch (ACTION_DOWN): 0:(320.0,745.0) :Sending Touch (ACTION_UP): 0:(321.74033,803.4879) :Sending Trackball (ACTION_MOVE): 0:(4.0,-3.0) :Sending Touch (ACTION_DOWN): 0:(1080.0,530.0) :Sending Touch (ACTION_UP): 0:(1075.1403,553.65424) //[calendar_time:2018-10-21 12:40:32.367 system_uptime:3268180] // Sending event #200 //[calendar_time:2018-10-21 12:40:32.368 system_uptime:3268181] // Sending event #200 :Sending Touch (ACTION_DOWN): 0:(961.0,2104.0) :Sending Touch (ACTION_UP): 0:(964.2124,2108.765) :Sending Touch (ACTION_DOWN): 0:(211.0,254.0) :Sending Touch (ACTION_UP): 0:(227.97137,256.0681) :Sending Touch (ACTION_DOWN): 0:(225.0,232.0) :Sending Touch (ACTION_UP): 0:(221.68617,211.33133) :Sending Touch (ACTION_DOWN): 0:(306.0,461.0) :Sending Touch (ACTION_UP): 0:(265.30518,448.99576) :Sending Touch (ACTION_DOWN): 0:(551.0,2007.0) :Sending Touch (ACTION_UP): 0:(551.8652,2013.8613) :Sending Touch (ACTION_DOWN): 0:(1197.0,463.0) :Sending Touch (ACTION_UP): 0:(1286.8961,382.07794) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.LoginActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.LoginActivity } in package com.example.jhon.antibullying :Sending Trackball (ACTION_MOVE): 0:(2.0,-3.0) // Rejecting start of Intent { act=android.intent.action.CALL_BUTTON cmp=com.google.android.dialer/com.google.android.apps .dialer.extensions.GoogleDialtactsActivity } in package com.google.android.dialer :Sending Touch (ACTION_DOWN): 0:(628.0,1258.0) :Sending Touch (ACTION_UP): 0:(650.10345,1269.0359) :Sending Touch (ACTION_DOWN): 0:(413.0,1986.0) :Sending Touch (ACTION_UP): 0:(410.37857,1974.6023) :Sending Touch (ACTION_DOWN): 0:(19.0,2293.0) :Sending Touch (ACTION_UP): 0:(2.0364265,2273.3787) :Sending Touch (ACTION_DOWN): 0:(1245.0,1840.0) :Sending Touch (ACTION_UP): 0:(1268.2635,1787.0852) :Sending Touch (ACTION_DOWN): 0:(1174.0,1953.0) :Sending Touch (ACTION_UP): 0:(1223.9478,1965.51) :Sending Touch (ACTION_DOWN): 0:(346.0,855.0) :Sending Touch (ACTION_UP): 0:(209.6019,839.6669) :Sending Touch (ACTION_DOWN): 0:(278.0,1600.0) :Sending Touch (ACTION_UP): 0:(279.5184,1608.5216) :Sending Touch (ACTION_DOWN): 0:(589.0,1695.0) //[calendar_time:2018-10-21 12:40:33.388 system_uptime:3269201] // Sending event #300 :Sending Touch (ACTION_UP): 0:(613.1906,1695.6807) :Sending Trackball (ACTION_MOVE): 0:(-2.0,2.0) :Sending Touch (ACTION_DOWN): 0:(200.0,509.0) :Sending Touch (ACTION_UP): 0:(212.51607,518.8298) :Sending Touch (ACTION_DOWN): 0:(80.0,406.0) :Sending Touch (ACTION_UP): 0:(214.21725,285.87906) :Sending Touch (ACTION_DOWN): 0:(562.0,2042.0) :Sending Touch (ACTION_UP): 0:(553.02216,2033.3193) :Sending Trackball (ACTION_MOVE): 0:(-1.0,3.0) :Sending Trackball (ACTION_MOVE): 0:(-1.0,-2.0) :Sending Trackball (ACTION_UP): 0:(0.0,0.0)

240

:Sending Trackball (ACTION_MOVE): 0:(-4.0,4.0) :Sending Touch (ACTION_DOWN): 0:(647.0,2199.0) :Sending Touch (ACTION_UP): 0:(617.8627,2206.8337) :Sending Trackball (ACTION_MOVE): 0:(-2.0,-3.0) :Sending Touch (ACTION_DOWN): 0:(1289.0,341.0) :Sending Touch (ACTION_UP): 0:(1282.7457,349.48373) :Sending Touch (ACTION_DOWN): 0:(1016.0,2213.0) :Sending Touch (ACTION_UP): 0:(1021.10675,2224.3667) //[calendar_time:2018-10-21 12:40:34.733 system_uptime:3270546] // Sending event #400 :Sending Trackball (ACTION_MOVE): 0:(4.0,0.0) :Sending Touch (ACTION_DOWN): 0:(436.0,1502.0) :Sending Touch (ACTION_UP): 0:(414.92877,1469.3943) :Sending Trackball (ACTION_MOVE): 0:(-4.0,3.0) :Sending Touch (ACTION_DOWN): 0:(540.0,843.0) :Sending Touch (ACTION_UP): 0:(542.24994,849.7837) :Sending Touch (ACTION_DOWN): 0:(1112.0,221.0) :Sending Touch (ACTION_UP): 0:(1121.7615,210.22147) :Sending Trackball (ACTION_MOVE): 0:(-1.0,-4.0) :Sending Trackball (ACTION_MOVE): 0:(-1.0,2.0) :Sending Trackball (ACTION_MOVE): 0:(0.0,4.0) :Sending Touch (ACTION_DOWN): 0:(164.0,2158.0) :Sending Touch (ACTION_UP): 0:(163.8932,2171.9944) :Sending Touch (ACTION_DOWN): 0:(1092.0,1733.0) :Sending Touch (ACTION_UP): 0:(1082.8872,1729.8674) :Sending Touch (ACTION_DOWN): 0:(746.0,732.0) :Sending Touch (ACTION_UP): 0:(868.8463,811.4637) :Sending Touch (ACTION_DOWN): 0:(426.0,105.0) //[calendar_time:2018-10-21 12:40:35.560 system_uptime:3271374] // Sending event #500 :Sending Touch (ACTION_UP): 0:(425.21103,104.3967) :Sending Touch (ACTION_DOWN): 0:(362.0,2389.0) :Sending Touch (ACTION_UP): 0:(308.88184,2392.0) :Sending Touch (ACTION_DOWN): 0:(1208.0,1832.0) :Sending Touch (ACTION_UP): 0:(1202.9698,1844.8966) :Sending Touch (ACTION_DOWN): 0:(1241.0,476.0) :Sending Touch (ACTION_UP): 0:(1256.5454,479.96408) :Sending Touch (ACTION_DOWN): 0:(648.0,1829.0) :Sending Touch (ACTION_UP): 0:(567.0761,1886.674) :Sending Touch (ACTION_DOWN): 0:(763.0,491.0) :Sending Touch (ACTION_UP): 0:(762.59595,492.647) :Sending Touch (ACTION_DOWN): 0:(594.0,742.0) :Sending Touch (ACTION_UP): 0:(602.7677,736.9464) :Sending Trackball (ACTION_MOVE): 0:(2.0,3.0) :Sending Touch (ACTION_DOWN): 0:(566.0,138.0) :Sending Touch (ACTION_UP): 0:(582.5533,139.18748) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.LoginActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.LoginActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(1098.0,1317.0) :Sending Touch (ACTION_UP): 0:(1095.9685,1315.1769) :Sending Touch (ACTION_DOWN): 0:(1313.0,1091.0) :Sending Touch (ACTION_UP): 0:(1321.0647,1091.4896) :Sending Touch (ACTION_DOWN): 0:(423.0,958.0) :Sending Touch (ACTION_UP): 0:(328.8544,1040.5791) //[calendar_time:2018-10-21 12:40:36.682 system_uptime:3272495] // Sending event #600 //[calendar_time:2018-10-21 12:40:36.684 system_uptime:3272499] // Sending event #600 :Sending Touch (ACTION_DOWN): 0:(1218.0,2299.0) :Sending Touch (ACTION_UP): 0:(1220.1848,2305.8872) :Sending Touch (ACTION_DOWN): 0:(1147.0,1741.0) :Sending Touch (ACTION_UP): 0:(1137.4193,1738.952) :Sending Touch (ACTION_DOWN): 0:(341.0,1797.0) :Sending Touch (ACTION_UP): 0:(340.17136,1789.5605) :Sending Touch (ACTION_DOWN): 0:(34.0,1030.0) :Sending Touch (ACTION_UP): 0:(27.022623,1014.227)

:Sending Trackball (ACTION_MOVE): 0:(2.0,-5.0) :Sending Touch (ACTION_DOWN): 0:(258.0,1178.0) :Sending Touch (ACTION_UP): 0:(283.012,1163.5427)

241

:Sending Touch (ACTION_DOWN): 0:(693.0,561.0) :Sending Touch (ACTION_UP): 0:(738.8029,541.3723) :Sending Touch (ACTION_DOWN): 0:(13.0,262.0) :Sending Touch (ACTION_UP): 0:(3.4568987,265.20837) :Sending Touch (ACTION_DOWN): 0:(691.0,1378.0) :Sending Touch (ACTION_UP): 0:(740.4296,1404.386) :Sending Touch (ACTION_DOWN): 0:(1107.0,2369.0) :Sending Touch (ACTION_UP): 0:(1140.8109,2392.0) :Sending Touch (ACTION_DOWN): 0:(7.0,63.0) :Sending Touch (ACTION_UP): 0:(0.0,79.18049) :Sending Touch (ACTION_DOWN): 0:(89.0,2131.0) :Sending Touch (ACTION_UP): 0:(91.28352,2138.724) :Sending Trackball (ACTION_MOVE): 0:(-3.0,-1.0) :Sending Touch (ACTION_DOWN): 0:(399.0,2279.0) //[calendar_time:2018-10-21 12:40:37.999 system_uptime:3273812] // Sending event #700 :Sending Touch (ACTION_UP): 0:(426.1911,2313.0964) :Sending Trackball (ACTION_MOVE): 0:(-5.0,-1.0) :Sending Trackball (ACTION_MOVE): 0:(1.0,3.0) :Sending Trackball (ACTION_MOVE): 0:(0.0,2.0) :Sending Touch (ACTION_DOWN): 0:(128.0,407.0) :Sending Touch (ACTION_UP): 0:(129.27493,394.17676) :Sending Trackball (ACTION_MOVE): 0:(-5.0,-1.0) :Sending Trackball (ACTION_MOVE): 0:(-4.0,0.0) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.LoginActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.LoginActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(823.0,1294.0) :Sending Touch (ACTION_UP): 0:(807.7572,1284.3552) // Rejecting start of Intent { act=android.intent.action.CALL_BUTTON cmp=com.google.android.dialer/com.google.android.apps .dialer.extensions.GoogleDialtactsActivity } in package com.google.android.dialer :Sending Touch (ACTION_DOWN): 0:(500.0,398.0) :Sending Touch (ACTION_UP): 0:(399.16357,355.76535) :Sending Touch (ACTION_DOWN): 0:(225.0,2374.0) :Sending Touch (ACTION_UP): 0:(231.22691,2366.4695) :Sending Touch (ACTION_DOWN): 0:(29.0,873.0) :Sending Touch (ACTION_UP): 0:(23.41121,864.81165) :Sending Trackball (ACTION_MOVE): 0:(2.0,-5.0) //[calendar_time:2018-10-21 12:40:38.761 system_uptime:3274575] // Sending event #800 :Sending Trackball (ACTION_MOVE): 0:(1.0,-5.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,4.0) :Sending Touch (ACTION_DOWN): 0:(1433.0,1942.0) :Sending Touch (ACTION_UP): 0:(1431.5302,1936.4017) :Sending Touch (ACTION_DOWN): 0:(1166.0,782.0) :Sending Touch (ACTION_UP): 0:(1163.0571,790.5565) // Rejecting start of Intent { cmp=com.google.android.setupwizard/.predeferred.PreDeferredSetupWizardActivity } in package com.google.android.setupwizard :Sending Touch (ACTION_DOWN): 0:(1394.0,138.0) :Sending Touch (ACTION_UP): 0:(1385.1913,142.27858) :Sending Touch (ACTION_DOWN): 0:(286.0,1973.0) :Sending Touch (ACTION_UP): 0:(391.39645,1953.758) :Sending Touch (ACTION_DOWN): 0:(158.0,305.0) :Sending Touch (ACTION_UP): 0:(150.46732,304.7524) :Sending Trackball (ACTION_MOVE): 0:(1.0,-5.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,1.0) :Sending Touch (ACTION_DOWN): 0:(818.0,1330.0) :Sending Touch (ACTION_UP): 0:(810.8757,1339.3912) :Sending Trackball (ACTION_MOVE): 0:(-1.0,-5.0) //[calendar_time:2018-10-21 12:40:39.637 system_uptime:3275450] // Sending event #900 :Sending Trackball (ACTION_MOVE): 0:(0.0,1.0) :Sending Trackball (ACTION_MOVE): 0:(0.0,-1.0) :Sending Trackball (ACTION_MOVE): 0:(-5.0,-3.0) :Sending Trackball (ACTION_MOVE): 0:(-4.0,4.0) :Sending Touch (ACTION_DOWN): 0:(537.0,2166.0) :Sending Touch (ACTION_UP): 0:(538.5361,2169.174) :Sending Touch (ACTION_DOWN): 0:(444.0,1645.0)

242

:Sending Touch (ACTION_UP): 0:(452.1687,1648.908) :Sending Trackball (ACTION_MOVE): 0:(-4.0,1.0) :Sending Touch (ACTION_DOWN): 0:(308.0,508.0) :Sending Touch (ACTION_UP): 0:(308.04996,504.89954) :Sending Trackball (ACTION_MOVE): 0:(0.0,-1.0) Events injected: 1000 :Sending rotation degree=0, persist=false :Dropped: keys=0 pointers=0 trackballs=0 flips=0 rotations=0 ## Network stats: elapsed time=10292ms (0ms mobile, 0ms wifi, 10292ms not connected) // Monkey finished

2. Resultados para LoginActivity.java

2.1. Sentencia en el terminal de Android:

Sdk\platform-tools>adb shell monkey -p com.example.jhon.antibullying -c android.intent.category.MONKEY -v 1000

2.2. Respuesta

bash arg: -p bash arg: com.example.jhon.antibullying bash arg: -c bash arg: android.intent.category.MONKEY bash arg: -v bash arg: 1000 args: [-p, com.example.jhon.antibullying, -c, android.intent.category.MONKEY, -v, 1000] arg: "-p" arg: "com.example.jhon.antibullying" arg: "-c" arg: "android.intent.category.MONKEY" arg: "-v" arg: "1000" data="com.example.jhon.antibullying" data="android.intent.category.MONKEY" :Monkey: seed=1540149051242 count=1000 :AllowPackage: com.example.jhon.antibullying :IncludeCategory: android.intent.category.MONKEY // Event percentages: // 0: 15.0% // 1: 10.0% // 2: 2.0% // 3: 15.0% // 4: -0.0% // 5: -0.0% // 6: 25.0% // 7: 15.0% // 8: 2.0% // 9: 2.0% // 10: 1.0% // 11: 13.0% :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component= com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Flip keyboardOpen=false :Sending Touch (ACTION_DOWN): 0:(806.0,432.0) :Sending Touch (ACTION_UP): 0:(804.8092,434.8079) :Sending Flip keyboardOpen=true :Sending Touch (ACTION_DOWN): 0:(543.0,935.0) :Sending Touch (ACTION_UP): 0:(626.8995,930.6556) :Sending Touch (ACTION_DOWN): 0:(1423.0,178.0) :Sending Touch (ACTION_UP): 0:(1420.7312,188.40329) :Sending Touch (ACTION_DOWN): 0:(1400.0,930.0) :Sending Touch (ACTION_UP): 0:(1410.6075,930.1719) :Sending Touch (ACTION_DOWN): 0:(1127.0,1850.0)

243

:Sending Touch (ACTION_UP): 0:(1118.7225,1862.8622) // Rejecting start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.android.conta cts/.activities.PeopleActivity } in package com.android.contacts :Sending Trackball (ACTION_MOVE): 0:(-5.0,-5.0) :Sending Trackball (ACTION_MOVE): 0:(-1.0,2.0) :Sending Trackball (ACTION_MOVE): 0:(-4.0,3.0) :Sending Touch (ACTION_DOWN): 0:(696.0,841.0) //[calendar_time:2018-10-21 13:09:00.755 system_uptime:4976568] // Sending event #100 :Sending Touch (ACTION_UP): 0:(679.3478,956.4574) :Sending Touch (ACTION_DOWN): 0:(938.0,1354.0) :Sending Touch (ACTION_UP): 0:(936.5242,1360.5073) :Sending Trackball (ACTION_MOVE): 0:(-4.0,-2.0) :Sending Touch (ACTION_DOWN): 0:(1342.0,1377.0) :Sending Touch (ACTION_UP): 0:(1271.0181,1323.899) :Sending Trackball (ACTION_MOVE): 0:(-5.0,-1.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,-2.0) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(183.0,24.0) :Sending Touch (ACTION_UP): 0:(173.15967,13.543947) :Sending Trackball (ACTION_MOVE): 0:(4.0,3.0) :Sending Touch (ACTION_DOWN): 0:(568.0,2003.0) :Sending Touch (ACTION_UP): 0:(506.46936,2057.7048) //[calendar_time:2018-10-21 13:09:01.444 system_uptime:4977257] // Sending event #200 :Sending Trackball (ACTION_MOVE): 0:(1.0,-1.0) :Sending Trackball (ACTION_UP): 0:(0.0,0.0) :Sending Flip keyboardOpen=false :Sending Touch (ACTION_DOWN): 0:(573.0,165.0) :Sending Touch (ACTION_UP): 0:(588.3891,171.2108) :Sending Touch (ACTION_DOWN): 0:(1361.0,1149.0) :Sending Touch (ACTION_UP): 0:(1365.4512,1155.4642) :Sending Touch (ACTION_DOWN): 0:(1213.0,1036.0) :Sending Touch (ACTION_UP): 0:(1202.1068,1037.6753) // Rejecting start of Intent { cmp=com.android.settings/.deviceinfo.StorageWizardInit } in package com.android.settings :Sending Trackball (ACTION_MOVE): 0:(-2.0,4.0) :Sending Touch (ACTION_DOWN): 0:(1286.0,1297.0) :Sending Touch (ACTION_UP): 0:(1221.5211,1203.4408) :Sending Trackball (ACTION_MOVE): 0:(-2.0,-5.0) :Sending Touch (ACTION_DOWN): 0:(1028.0,264.0) :Sending Touch (ACTION_UP): 0:(1021.4486,277.10422) //[calendar_time:2018-10-21 13:09:03.509 system_uptime:4979322] // Sending event #300 //[calendar_time:2018-10-21 13:09:03.510 system_uptime:4979323] // Sending event #300 :Sending Touch (ACTION_DOWN): 0:(152.0,1546.0) :Sending Touch (ACTION_UP): 0:(143.94221,1537.106) :Sending Touch (ACTION_DOWN): 0:(339.0,267.0) :Sending Touch (ACTION_UP): 0:(352.6806,271.9829) :Sending Touch (ACTION_DOWN): 0:(1407.0,167.0) :Sending Touch (ACTION_UP): 0:(1428.295,158.28014) :Sending Touch (ACTION_DOWN): 0:(1439.0,1927.0) :Sending Touch (ACTION_UP): 0:(1434.518,1909.0612) :Sending Touch (ACTION_DOWN): 0:(934.0,170.0) :Sending Touch (ACTION_UP): 0:(936.2529,174.27837) :Sending Trackball (ACTION_MOVE): 0:(-3.0,2.0) :Sending Trackball (ACTION_MOVE): 0:(3.0,-5.0) :Sending Touch (ACTION_DOWN): 0:(1239.0,1266.0) :Sending Touch (ACTION_UP): 0:(1241.9579,1275.0045) :Sending Touch (ACTION_DOWN): 0:(1215.0,1000.0) :Sending Touch (ACTION_UP): 0:(1274.3765,1033.3405) // Rejecting start of Intent { act=android.intent.action.CALL_BUTTON cmp=com.google.android.dialer/com.google.android.apps.dialer.extensions.GoogleDialtactsActivity } in package com.google.android.dialer :Sending Touch (ACTION_DOWN): 0:(76.0,1565.0) :Sending Touch (ACTION_UP): 0:(72.29746,1577.2567)

244

:Sending Trackball (ACTION_MOVE): 0:(-5.0,0.0) :Sending Touch (ACTION_DOWN): 0:(1400.0,797.0) :Sending Touch (ACTION_UP): 0:(1397.3611,874.8093) :Sending Touch (ACTION_DOWN): 0:(647.0,1130.0) :Sending Touch (ACTION_UP): 0:(653.23444,1134.2422) :Sending Trackball (ACTION_MOVE): 0:(3.0,1.0) //[calendar_time:2018-10-21 13:09:04.511 system_uptime:4980324] // Sending event #400 :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component= com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.a ntibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(45.0,697.0) :Sending Touch (ACTION_UP): 0:(48.373344,683.39484) :Sending Touch (ACTION_DOWN): 0:(987.0,199.0) :Sending Touch (ACTION_UP): 0:(981.3302,206.74507) :Sending Trackball (ACTION_MOVE): 0:(2.0,-2.0) // Rejecting start of Intent { act=android.intent.action.CALL_BUTTON cmp=com.google.android.dialer/com.google.android.apps.dialer.extensions.GoogleDialtactsActivity } in package com.google.android.dialer // Rejecting start of Intent { cmp=com.android.settings/.deviceinfo.StorageWizardInit } in package com.android.settings :Sending Touch (ACTION_DOWN): 0:(593.0,1220.0) :Sending Touch (ACTION_UP): 0:(593.5445,1199.3525) :Sending Touch (ACTION_DOWN): 0:(343.0,688.0) :Sending Touch (ACTION_UP): 0:(341.69006,702.2681) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(998.0,1388.0) :Sending Touch (ACTION_UP): 0:(999.05444,1402.5713) :Sending Touch (ACTION_DOWN): 0:(1397.0,1906.0) :Sending Touch (ACTION_UP): 0:(1440.0,2011.501) :Sending Trackball (ACTION_MOVE): 0:(-5.0,-5.0) :Sending Trackball (ACTION_UP): 0:(0.0,0.0) :Sending Touch (ACTION_DOWN): 0:(1120.0,239.0) :Sending Touch (ACTION_UP): 0:(1117.7639,219.59471) :Sending Touch (ACTION_DOWN): 0:(507.0,1711.0) :Sending Touch (ACTION_UP): 0:(506.1332,1693.3483) :Sending Touch (ACTION_DOWN): 0:(648.0,1672.0) :Sending Touch (ACTION_UP): 0:(669.1542,1657.2394) :Sending Touch (ACTION_DOWN): 0:(360.0,808.0) :Sending Touch (ACTION_UP): 0:(312.528,760.07434) :Sending Touch (ACTION_DOWN): 0:(68.0,178.0) //[calendar_time:2018-10-21 13:09:06.125 system_uptime:4981939] // Sending event #500 :Sending Touch (ACTION_UP): 0:(59.445614,144.35362) :Sending Touch (ACTION_DOWN): 0:(1229.0,1136.0) :Sending Touch (ACTION_UP): 0:(1196.0114,1155.2494) :Sending Trackball (ACTION_MOVE): 0:(3.0,2.0) :Sending Touch (ACTION_DOWN): 0:(336.0,150.0) :Sending Touch (ACTION_UP): 0:(365.1404,125.552986) :Sending Trackball (ACTION_MOVE): 0:(-2.0,4.0) :Sending Touch (ACTION_DOWN): 0:(371.0,1444.0) :Sending Touch (ACTION_UP): 0:(388.704,1446.1823) // Rejecting start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.android.conta cts/.activities.PeopleActivity } in package com.android.contacts :Sending Trackball (ACTION_MOVE): 0:(-2.0,0.0) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(4.0,1757.0) :Sending Touch (ACTION_UP): 0:(16.717697,1757.9202)

245

:Sending Touch (ACTION_DOWN): 0:(693.0,988.0) :Sending Touch (ACTION_UP): 0:(674.6487,1060.807) :Sending Touch (ACTION_DOWN): 0:(647.0,1459.0) :Sending Touch (ACTION_UP): 0:(641.02875,1459.2068) :Sending Touch (ACTION_DOWN): 0:(137.0,487.0) :Sending Touch (ACTION_UP): 0:(199.13391,452.42145) // Rejecting start of Intent { cmp=com.google.android.googlequicksearchbox/com.google.android.apps.gsa.staticplugins.opa.OpaActivity } in package com.google.android.googlequicksearchbox //[calendar_time:2018-10-21 13:09:12.231 system_uptime:4988044] // Sending event #600 :Sending Trackball (ACTION_MOVE): 0:(-5.0,-3.0) :Sending Touch (ACTION_DOWN): 0:(924.0,185.0) :Sending Touch (ACTION_UP): 0:(901.82526,128.67497) :Sending Touch (ACTION_DOWN): 0:(1103.0,1331.0) :Sending Touch (ACTION_UP): 0:(1130.2266,1349.4434) :Sending Touch (ACTION_DOWN): 0:(1128.0,2324.0) :Sending Touch (ACTION_UP): 0:(1130.8452,2320.669) :Sending Touch (ACTION_DOWN): 0:(755.0,1332.0) :Sending Touch (ACTION_UP): 0:(756.86005,1323.3511) :Sending Touch (ACTION_DOWN): 0:(142.0,834.0) :Sending Touch (ACTION_UP): 0:(119.50451,918.87146) :Sending Trackball (ACTION_MOVE): 0:(-5.0,4.0) :Sending Touch (ACTION_DOWN): 0:(1134.0,1386.0) :Sending Touch (ACTION_UP): 0:(1122.3087,1389.2045) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(435.0,1151.0) :Sending Touch (ACTION_UP): 0:(416.49655,1199.0848) :Sending Touch (ACTION_DOWN): 0:(625.0,297.0) :Sending Touch (ACTION_UP): 0:(621.2591,283.06656) :Sending Flip keyboardOpen=true :Sending Touch (ACTION_DOWN): 0:(833.0,1488.0) :Sending Touch (ACTION_UP): 0:(833.41296,1478.7914) :Sending Trackball (ACTION_MOVE): 0:(-1.0,0.0) :Sending Trackball (ACTION_MOVE): 0:(-3.0,-1.0) //[calendar_time:2018-10-21 13:09:13.394 system_uptime:4989208] // Sending event #700 :Sending Trackball (ACTION_MOVE): 0:(-1.0,2.0) :Sending Trackball (ACTION_MOVE): 0:(4.0,-5.0) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Trackball (ACTION_MOVE): 0:(1.0,-3.0) :Sending Touch (ACTION_DOWN): 0:(1101.0,1648.0) :Sending Touch (ACTION_UP): 0:(1125.7935,1656.8661) :Sending Flip keyboardOpen=false :Sending Touch (ACTION_DOWN): 0:(415.0,1254.0) :Sending Touch (ACTION_UP): 0:(411.01254,1138.7458) :Sending Touch (ACTION_DOWN): 0:(1414.0,1138.0) :Sending Touch (ACTION_UP): 0:(1413.7739,1145.9135) :Sending Touch (ACTION_DOWN): 0:(1351.0,2057.0) :Sending Touch (ACTION_UP): 0:(1362.7283,2045.8857) :Sending Trackball (ACTION_MOVE): 0:(1.0,0.0) :Sending Trackball (ACTION_MOVE): 0:(-1.0,1.0) :Sending Trackball (ACTION_MOVE): 0:(-1.0,2.0) //[calendar_time:2018-10-21 13:09:14.041 system_uptime:4989854] // Sending event #800 :Sending Touch (ACTION_DOWN): 0:(1392.0,1990.0) :Sending Touch (ACTION_UP): 0:(1409.472,1991.2191) :Sending Touch (ACTION_DOWN): 0:(173.0,1375.0) :Sending Touch (ACTION_UP): 0:(171.80194,1370.2527) // Rejecting start of Intent { act=com.android.intent.action.SHOW_BRIGHTNESS_DIALOG cmp=com.android.systemui/.settings.Bri ghtnessDialog } in package com.android.systemui :Sending Trackball (ACTION_MOVE): 0:(-5.0,-4.0)

246

:Sending Trackball (ACTION_UP): 0:(0.0,0.0) :Sending Touch (ACTION_DOWN): 0:(787.0,432.0) :Sending Touch (ACTION_UP): 0:(785.46344,474.32632) :Sending Touch (ACTION_DOWN): 0:(688.0,1888.0) :Sending Touch (ACTION_UP): 0:(612.75146,1916.0897) :Sending Trackball (ACTION_MOVE): 0:(-1.0,2.0) // Rejecting start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.google.android.calendar/com.android.calendar.AllInOneActivity } in package com.google.android.calendar :Sending Touch (ACTION_DOWN): 0:(1308.0,239.0) :Sending Touch (ACTION_UP): 0:(1305.7886,246.00845) :Sending Touch (ACTION_DOWN): 0:(1310.0,1618.0) :Sending Touch (ACTION_UP): 0:(1320.8643,1633.3094) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(142.0,644.0) :Sending Touch (ACTION_UP): 0:(157.08104,639.83813) :Sending Touch (ACTION_DOWN): 0:(589.0,216.0) :Sending Touch (ACTION_UP): 0:(583.4313,202.9385) :Sending Trackball (ACTION_MOVE): 0:(-1.0,3.0) //[calendar_time:2018-10-21 13:09:15.078 system_uptime:4990891] // Sending event #900 :Sending Trackball (ACTION_UP): 0:(0.0,0.0) :Sending Flip keyboardOpen=true :Sending Touch (ACTION_DOWN): 0:(174.0,1665.0) :Sending Touch (ACTION_UP): 0:(185.52649,1623.134) :Sending Trackball (ACTION_MOVE): 0:(-3.0,3.0) :Sending Touch (ACTION_DOWN): 0:(1374.0,908.0) :Sending Touch (ACTION_UP): 0:(1440.0,796.3576) :Sending Touch (ACTION_DOWN): 0:(286.0,662.0) :Sending Touch (ACTION_UP): 0:(285.5845,675.0213) :Switch: #Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10200000;component=com.example.jhon.antibullying/.MainActivity;end // Allowing start of Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.jhon.antibullying/.MainActivity } in package com.example.jhon.antibullying :Sending Touch (ACTION_DOWN): 0:(371.0,1844.0) :Sending Touch (ACTION_UP): 0:(362.94543,1835.419) :Sending Touch (ACTION_DOWN): 0:(1071.0,153.0) :Sending Touch (ACTION_UP): 0:(993.3619,80.47874) :Sending Touch (ACTION_DOWN): 0:(215.0,954.0) :Sending Touch (ACTION_UP): 0:(154.84349,1024.305) :Sending Touch (ACTION_DOWN): 0:(631.0,587.0) :Sending Touch (ACTION_UP): 0:(630.6774,582.2702) :Sending Trackball (ACTION_MOVE): 0:(0.0,3.0) Events injected: 1000 :Sending rotation degree=0, persist=false :Dropped: keys=0 pointers=0 trackballs=0 flips=0 rotations=0 ## Network stats: elapsed time=16402ms (0ms mobile, 0ms wifi, 16402ms not connected) // Monkey finished

247

BIBLIOGRAFÍA

Android. (2014). Android – History. Recuperado de: https://www.android.com/history/

Android. (2018a). Dashboards: Platform versions. Recuperado de: https://developer.android.com/about/dashboards/index.html

Android. (2017a). ART and Dalvik. Recuperado de: https://source.android.com/devices/tech/dalvik/

Android. (2017b). The Android Source Code. Recuperado de: https://source.android.com/setup/

Android. (2018b). Android Jetpack. Recuperado de: https://developer.android.com/jetpack/

Android. (s.f.). Android TV. Recuperado de: https://www.android.com/intl/es_es/tv/ BCRP (Banco Central de Reserva del Perú). (diciembre 2018). Reporte de inflación.

Recuperado de: http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2018/diciembre/reporte-de-inflacion-diciembre-2018.pdf

Batanero, A. y Sesma, M. (2017). VERSUS: Apps híbridas VS Apps Nativas. Recuperado

de: https://www.paradigmadigital.com/dev/versus-apps-hibridas-vs-apps-nativas/ Bruegge, B. y Dutoit, A. (2002) Ingeniería de Software orientado a objetos. (Trad. Ruíz, S.).

México: Pearson Educación.

Cáceres, C. y Salazar, X. (eds.). (2013). “Era como ir todos los días al matadero...”: El bullying homofóbico en instituciones educativas públicas de Chile, Guatemala y Perú. Lima: Instituto de Estudios en Salud, Sexualidad y Desarrollo Humano - Universidad Peruana Cayetano Heredia - PNUD - UNESCO.

Castillo-Pulido, L. E. (2011). El acoso escolar. De las causas, origen y manifestaciones a la

pregunta por el sentido que le otorgan los actores. magis, Revista Internacional de Investigación en Educación, 4(8) Edición especial La violencia en las escuelas, 415-428. Recuperado de: http://revistas.javeriana.edu.co/index.php/MAGIS/article/viewFile/3572/2687

Cerezo-Ramírez, F. (2012). Bullying a través de las TIC. Boletín Científico Sapiens

Research, 2(2), 24-29. Recuperado de: http://www.sapiensresearch.org/images/pdf/v2n2/V2N2_Psique_2.pdf

Chen. P. (1976) The Entity-Relationship Model: Toward a Unified View of Data Export. ACM

Transactions on Database Systems, (1), pp. 9-36.

https://www.android.com/history/

https://developer.android.com/about/dashboards/index.html

https://source.android.com/devices/tech/dalvik/

https://source.android.com/setup/

https://www.android.com/intl/es_es/tv/

http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2018/diciembre/reporte-de-inflacion-diciembre-2018.pdf

http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2018/diciembre/reporte-de-inflacion-diciembre-2018.pdf

https://www.paradigmadigital.com/dev/versus-apps-hibridas-vs-apps-nativas/

http://revistas.javeriana.edu.co/index.php/MAGIS/article/viewFile/3572/2687

http://www.sapiensresearch.org/images/pdf/v2n2/V2N2_Psique_2.pdf

248

comScore (2014). Futuro Digital Perú 2014. Recuperado de: https://www.comscore.com/esl/Prensa-y-Eventos/Presentaciones-y-libros-blancos/2014/2014-Peru-Digital-Future-in-Focus

Date, C. J. (2001). Introducción a los sistemas de bases de datos. (7a ed.). (Trad. Ruíz, S.).

México: Pearson Educación.

De Oliveira, N., Landenberger, T., Bastos, A. S., Bernardi, C. y De Lima, I. I. (2017). Estrategias de manejo e intervención en Acoso Cibernético - Una revisión sistemática. Perspectivas en Psicología, 14(1), 7-17. Recuperado de https://dialnet.unirioja.es/descarga/articulo/6043319.pdf

Delia, L., Galdamez, N., Thomas, P. y Pesado P. (2013). Un análisis experimental de tipo de aplicaciones para dispositivos móviles. XVIII Congreso Argentino de Ciencias de la Computación CACIC 2013, 766-776. Recuperado de: https://digital.cic.gba.gob.ar/handle/11746/2091

Elmasri, R., y Navathe, S. (2011). Fundamentos de sistemas de bases de datos. (5a ed.).

(Trad. Díaz, J.). Madrid: Pearson Educación.

Enríquez, J. G. y Casas, S. I. (2013). Usabilidad en aplicaciones móviles. Informe Científico Técnico UNPA, 5(2), 25-47. Recuperado de: https://dialnet.unirioja.es/descarga/articulo/5123524.pdf

Enríquez, M. F. y Garzón, F. (2015). El acoso escolar. Saber, Ciencia y Libertad, 10(1), 219-

233. Recuperado de: https://dialnet.unirioja.es/descarga/articulo/5329121.pdf

Fling, B. (2009). Mobile design and development. Sebastopol: O'Reilly Media.

García, L., Orellana, O., Pomalaya V., R., Yanac, E., Orellana, D., Sotelo L., L., Herrera F., E., Sotelo L., N. y Chávez, H. (2011). Intimidación entre iguales (bullying): empatía e inadaptación social en participantes de bullying. Revista de Investigación en Psicología, 14(2), 271-276. doi: 10.15381/rinvp.v14i2.2097

García, L., Orellana, O., Pomalaya V., R., Yanac, E., Sotelo L., L., Sotelo L., N., Herrera F.,

E., Chávez C., H., García Z., N., Macazana F., D., Orellana, D. y Fernandini Q., P. (2010). Cyberbullying en escolares de educación secundaria de Lima Metropolitana. Revista de Investigación en Psicología, 13(2), 83-99. doi: 10.15381/rinvp.v13i2.3714

Gasca, M. C., Camargo, L. L. y Medina, B. (2014). Metodología para el desarrollo de

aplicaciones móviles. Revista Tecnura, 18(40), 20-35. doi: 10.14483/udistrital.jour.tecnura.2014.2.a02

Haseman, C. (2008). Android essentials. Berkele: Apress.

Have, C. T., y Jensen, L. J. (2013). Are graph databases ready for bioinformatics?. Bioinformatics, 29(24), 3107–3108. doi: 10.1093/bioinformatics/btt549

Hernández, R., Fernández, C. y Baptista, P. (2010). Metodología de la investigación (5a ed.). México: McGraw-Hill.

https://www.comscore.com/esl/Prensa-y-Eventos/Presentaciones-y-libros-blancos/2014/2014-Peru-Digital-Future-in-Focus

https://www.comscore.com/esl/Prensa-y-Eventos/Presentaciones-y-libros-blancos/2014/2014-Peru-Digital-Future-in-Focus

https://dialnet.unirioja.es/descarga/articulo/6043319.pdf

https://digital.cic.gba.gob.ar/handle/11746/2091


http://dx.doi.org/10.15381/rinvp.v14i2.2097

249

HTC Corporation. (2009). Especificaciones del Smartphone HTC Magic. https://web.archive.org/web/20101230093921/http://www.htc.com/www/product/magic/specification.html

IEEE (The Institute of Electrical and Electronics Engineers). (1990). IEEE Standard Glossary

of Data Management Terminology. doi: 10.1109/IEEESTD.1990.101064

Jacobson, I., Booch, G. y Rumbaugh, J. (1999) El proceso unificado de desarrollo de software. (Trad. Sánchez, S. et al.). Madrid: Pearson Educación.

Kruchten, P. (2003) The Rational Unified Process -- An Introduction (3a ed.). Reading, MA: Addison-Wesley-Longman.

Ley N° 28612. Ley que norma el uso, adquisición y adecuación del software en la administración pública. Diario oficial El Peruano, Perú, 18 de octubre del 2005.

Ley N° 29719. Ley que promueve la convivencia sin violencia en las instituciones

educativas. Diario oficial El Peruano, Perú, 25 de junio del 2011.

Ley N° 29733. Ley de protección de datos personales. Diario oficial El Peruano, Perú, 3 de julio del 2011.

Llorca, A. (2016). 14 aplicaciones para combatir el acoso escolar. Recuperado de: https://www.genbeta.com/a-fondo/14-aplicaciones-para-combatir-el-acoso-escolar

López, M. G. (2017). Acoso escolar y cibernético en estudiantes universitarios. Revista de

investigación en educación, 1(15), 11-26. Recuperado de https://dialnet.unirioja.es/descarga/articulo/5966880.pdf

Luque, I., Gómez-Nieto, M., López, E. y Cerruela, G. (2001). Bases de Datos: desde Chen hasta Codd con ORACLE. Madrid, España: RA-MA

Martin, Robert C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and

Design. Estados Unidos de América: Pearson Educación. Meier, R. (2009). Professional Android™ 4 application development. Indianapolis: Wiley

Publishing, Inc.

MINEDU (Ministerio de Educación). (2017). En el Perú, 75 de cada 100 escolares han sufrido de violencia física y psicológica. Recuperado de: http://www.minedu.gob.pe/n/noticia.php?id=42630

MINEDU (Ministerio de Educación). (2018). Número de Casos Reportados en el SíseVe a Nivel nacional (www.siseve.pe) Del 15/09/2013 al 31/01/2018. Recuperado de: http://www.siseve.pe/Seccion/ObtenerPDF

Murphy, M. (2009a). The busy coder's guide to advanced android development. [S.l.]: CommonsWare.

https://web.archive.org/web/20101230093921/http:/www.htc.com/www/product/magic/specification.html

https://web.archive.org/web/20101230093921/http:/www.htc.com/www/product/magic/specification.html

https://doi.org/10.1109/IEEESTD.1990.101064

https://www.genbeta.com/a-fondo/14-aplicaciones-para-combatir-el-acoso-escolar


http://www.minedu.gob.pe/n/noticia.php?id=42630

http://www.siseve.pe/Seccion/ObtenerPDF

250

Murphy, M. (2009b). The busy coder's guide to android development. Estados Unidos de América: CommonsWare.

Nuseibeh, B. y Easterbrook, S. (2000). Requirements engineering. Proceedings of the

conference on The future of Software engineering - ICSE '00, 35-46. doi: 10.1145/336512.336523

Oliveros, M. y Barrientos, A. (2007) Incidencia y factores de riesgo de la intimidación

(bullying) en un colegio particular de Lima-Perú, 2007. Revista peruana de pediatría, 60(3), 150-155. Recuperado de: http://sisbib.unmsm.edu.pe/bvrevistas/rpp/v60n3/pdf/a03v60n3.pdf

Open Handset Alliance (2018). Industry Leaders Announce Open Platform for Mobile

Devices | Open Handset Alliance. http://www.openhandsetalliance.com/press_110507.html

OSIPTEL (Organismo Supervisor de Inversión Privada en Telecomunicaciones). (2016).

Reporte estadístico – Febrero 2016. Recuperado de http://www.osiptel.gob.pe/Archivos/Publicaciones/reporte_estadistico_febrero/reporte_estadistico_febrero.html#1/z

Pressman, Roger S. (2010) Ingeniería de software: un enfoque práctico. (7a ed.). (Trad.

Campos, V. y Enríquez, J.). México: McGraw-Hill. RAE (Real Academia Española). (2014). Diccionario de la lengua española (23a ed.).

Recuperado de: http://dle.rae.es/index.html Rodríguez, N. (2006). Bullying: un problema de todos. Pirineos. Revista de la Consejería de

Educación de la Embajada de España en Andorra, (2), 70-73. Recuperado de https://sede.educacion.gob.es/publiventa/pirineos-n-2-revista-de-la-consejeria-de-educacion-de-la-embajada-de-espana-en-andorra/ensenanza-lengua-espanola/13105

Redmond, E. y Wilson, J. (2012). Seven Databases in Seven Weeks. Estados Unidos: The pragmatic programmers.

Rumbaugh, J., Jacobson, I. y Booch, G. (2007) El lenguaje unificado de modelado: manual

de referencia. (2a ed.). (Trad. Sánchez, S., San Juan, O. y García-Bermejo, R.). Madrid: Pearson Educación.

Santiago, R. et al. (2015) Mobile learning: nuevas realidades en el aula. Grupo Océano.

StatCounter GlobalStats (2018). Mobile & Tablet Operating System Market Share Peru 2015-2018. Recuperado de: http://gs.statcounter.com/os-market-share/mobile-tablet/peru/#yearly-2015-2018

Schwaber K. (1997) SCRUM Development Process. En: Sutherland J., Casanave C., Miller J., Patel P., Hollowell G. (eds.) Business Object Design and Implementation. Londres: Springer. doi.org: 10.1007/978-1-4471-0947-1_11

Tanenbaum, A. (2009) Sistemas operativos modernos. (3a ed.). (Trad. Vidal, A.). México:

Pearson Educación.

http://sisbib.unmsm.edu.pe/bvrevistas/rpp/v60n3/pdf/a03v60n3.pdf

http://www.openhandsetalliance.com/press_110507.html

http://www.osiptel.gob.pe/Archivos/Publicaciones/reporte_estadistico_febrero/reporte_estadistico_febrero.html#1/z

http://www.osiptel.gob.pe/Archivos/Publicaciones/reporte_estadistico_febrero/reporte_estadistico_febrero.html#1/z

http://dle.rae.es/index.html

https://sede.educacion.gob.es/publiventa/pirineos-n-2-revista-de-la-consejeria-de-educacion-de-la-embajada-de-espana-en-andorra/ensenanza-lengua-espanola/13105

https://sede.educacion.gob.es/publiventa/pirineos-n-2-revista-de-la-consejeria-de-educacion-de-la-embajada-de-espana-en-andorra/ensenanza-lengua-espanola/13105

http://gs.statcounter.com/os-market-share/mobile-tablet/peru/#yearly-2015-2018

http://gs.statcounter.com/os-market-share/mobile-tablet/peru/#yearly-2015-2018

251

UNESCO (United Nations Educational, Scientific and Cultural Organization). (2017). School Violence and Bullying: Global Status Report. Francia: UNESCO.

Weitzenfeld, A. (2005). Ingeniería de Software orientada a objetos con UML, Java e Internet.

México: International Thomson Editores.

Wiegers, K. y Beatty, J. (2013) Software Requirements: Developer Best Practices. (3a ed.). Estados Unidos de América: Microsoft Press.

WORLD VISION PERÚ (2016). Memoria: Basta de bullying, no te quedes callado. Lima:

PRAISE Inversiones SAC.