SOFTWARE EDUCATIVO EN APOYO AL PROCESO DE APRENDIZAJE DE LAS OPERACIONES BÁSICAS MATEMÁTICAS DE LOS ESTUDIANTES DE

PRIMARIA DEL PROGRAMA DE TIFLOLOGÍA DEL COLEGIO OEA I.E.D

LAURA ALEJANDRA DOMÍNGUEZ BARBOSA

ANDRÉS DAVID ROZO CHIQUIZA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA

TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS BOGOTÁ D.C

2017

SOFTWARE EDUCATIVO EN APOYO AL PROCESO DE APRENDIZAJE DE LAS OPERACIONES BÁSICAS MATEMÁTICAS DE LOS ESTUDIANTES DE

PRIMARIA DEL PROGRAMA DE TIFLOLOGÍA DEL COLEGIO OEA I.E.D

LAURA ALEJANDRA DOMÍNGUEZ BARBOSA

ANDRÉS DAVID ROZO CHIQUIZA

Proyecto de grado en la modalidad de pasantía para optar por el título de:

Tecnólogo en Sistematización de Datos

Director del proyecto:

NORBERTO NOVOA TORRES INGENIERO DE SISTEMAS

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA

TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS BOGOTÁ D.C

2017

Nota de Aceptación

Director del Proyecto Ing. Norberto Novoa Torres

Jurado Ing. Juan Carlos Guevara Bolaños

Bogotá D.C, 04 abril 2017

Queremos agradecer principalmente a Dios ya que él nos brinda el privilegio de habitar en el mundo junto al beneficio

de alcanzar nuestros niveles educativos mediante una institución pública de educación superior como lo es la nuestra, en la cual podemos adquirir los conocimientos necesarios para

aportar al desarrollo tecnológico de nuestro país.

Además, dedicamos este logro de excelencia a nuestros padres quienes han sido el motor de inspiración de nuestro proceso

educativo y el principal apoyo para el cumplimiento de éste.

AGRADECIMIENTOS

Los autores expresan especial gratitud:

• Al ingeniero en sistemas Norberto Novoa Torres, docente de la Universidad Distrital Francisco José de Caldas y tutor del proyecto, quien mediante su apoyo, generosidad y valiosos aportes, orientó el desarrollo del proyecto.

• Al ingeniero en sistemas Luis Felipe Wanumen Silva, docente de la Universidad Distrital Francisco José de Caldas, quien mediante sus aportes consejos y valiosas observaciones, encaminó el desarrollo del proyecto.

• A los tiflólogos Melba García y Pedro Aldana, docentes del Colegio OEA I.E.D, quienes mediante su apoyo y generosidad permitieron que el desarrollo del proyecto logrará orientarse a la solución de la problemática planteada.

• A Esilda Tejeda Vásquez y Teresa Pérez Pérez, miembros del cuerpo directivo del Colegio OEA I.E.D, por permitir la elaboración del proyecto bajo la modalidad de pasantía en dicha institución.

• A los docentes del proyecto curricular de Tecnología en Sistematización de Datos, por brindarnos sus conocimientos y enseñanzas en el transcurso de nuestro proceso de formación educativa.

• A nuestros familiares, quienes con sus consejos, apoyo y amistad nos ayudaron tanto en nuestro proceso educativo como en la realización de este proyecto.

TABLA DE CONTENIDO

RESUMEN .............................................................................................................. 1

ABSTRACT ............................................................................................................. 2

INTRODUCCIÓN .................................................................................................... 3

1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN ....................... 5

1.1. TÍTULO DEL PROYECTO ...................................................................... 5

1.2. TEMA ...................................................................................................... 5

1.3. PLANTEAMIENTO DEL PROBLEMA ..................................................... 5

1.3.1. DESCRIPCIÓN DEL PROBLEMA ....................................................... 5

1.3.2. FORMULACIÓN DEL PROBLEMA ..................................................... 6

1.4. OBJETIVOS ............................................................................................ 7

1.4.1. OBJETIVO GENERAL ......................................................................... 7

1.4.2. OBJETIVOS ESPECÍFICOS ............................................................... 7

1.5. ALCANCES Y DELIMITACIONES .......................................................... 7

1.5.1. ALCANCES ......................................................................................... 7

1.5.2. DELIMITACIONES .............................................................................. 8

1.6. JUSTIFICACIÓN ................................................................................... 10

1.7. MARCO DE REFERENCIA ................................................................... 12

1.7.1. ESTADO DEL ARTE ......................................................................... 12

1.7.1.1. FUENTES PRIMARIAS .................................................................. 12

1.7.1.2. FUENTES SECUNDARIAS ............................................................ 13

1.7.1.3. PROYECTOS RELACIONADOS ................................................... 14

1.7.2. MARCO TEÓRICO ............................................................................ 16

1.7.3. MARCO CONCEPTUAL .................................................................... 24

1.7.4. MARCO INSTITUCIONAL ................................................................. 32

1.7.5. DIAGRAMAS DE PROCESOS .......................................................... 34

1.7.5.1. DIAGRAMAS DE PROCESOS ....................................................... 34

1.7.5.2. DIAGRAMAS DE PROCESO: [M1] NODO NAVEGACIÓN DOCENTES .................................................................................................... 35

1.7.5.3. DIAGRAMAS DE PROCESO: [M2] NODO NAVEGACIÓN ESTUDIANTES ............................................................................................... 36

1.7.5.4. DIAGRAMAS DE PROCESO: [A1] ADMINISTRACIÓN DEL SOFTWARE ................................................................................................... 37

1.8. METODOLOGÍA ................................................................................... 38

1.8.1. Cronograma ....................................................................................... 41

1.9.FACTIBILIDAD .......................................................................................... 43

1.9.1. FACTIBILIDAD TÉCNICA. ....................................................................... 43

1.9.2.FACTIBILIDAD OPERATIVA .................................................................... 44

1.9.3. FACTIBILIDAD LEGAL ...................................................................... 44

1.9.4. FACTIBILIDAD ECONÓMICA ................................................................. 45

2. FASE DE ELABORACIÓN ......................................................................... 47

2.1. ANÁLISIS PARA LA ELABORACIÓN ................................................... 47

2.1.1. CARACTERÍSTICAS DE LA POBLACIÓN OBJETIVO ..................... 47

2.1.2. PROBLEMA O NECESIDAD A ATENDER ........................................ 47

2.1.3. JUSTIFICACIÓN DE USO DE LOS MEDIOS INTERACTIVOS ........ 48

2.1.3.1. Justificación .................................................................................... 48

2.1.3.2. Procedimiento ................................................................................ 48

2.1.3.3. Validez ............................................................................................ 48

2.1.4. PRINCIPIOS PEDAGÓGICOS Y DIDÁCTICOS APLICABLES ......... 49

2.2. DEFINICIÓN DEL DISEÑO ................................................................... 51

2.2.1. EDUCATIVO ...................................................................................... 51

2.2.2. COMUNICACIONAL .......................................................................... 53

2.2.2.1. HERRAMIENTAS ........................................................................... 53

2.2.2.2. INTERFACES ................................................................................. 53

2.2.3. COMPUTACIONAL ........................................................................... 73

2.3. DEFINICIÓN DE REQUERIMIENTOS .................................................. 73

2.3.1. REQUERIMIENTOS FUNCIONALES ................................................ 73

2.3.2. REQUERIMIENTOS NO FUNCIONALES ......................................... 76

2.4. DEFINICIÓN DE ACTORES Y CASOS DE USO ................................. 77

2.4.1. ACTORES ......................................................................................... 77

2.4.2. DIAGRAMA DE ACTORES ............................................................... 78

2.4.3. CASOS DE USO ............................................................................... 78

2.4.4. DOCUMENTACIÓN CASOS DE USO .............................................. 79

2.4.5. DIAGRAMA DE CASOS DE USO ..................................................... 97

2.5. DIAGRAMAS DE SECUENCIA ............................................................. 98

2.6. DIAGRAMA DE ACTIVIDADES .......................................................... 116

2.7. DIAGRAMA DE ESTADO ................................................................... 128

2.8. DIAGRAMA DE CLASES .................................................................... 137

3. FASE DE CONTRUCCIÓN .................................................................... 139

3.1. DESCRIPCIÓN ELEMENTOS OPEN UP ........................................... 139

3.1.1. ROLES ............................................................................................ 139

3.1.2. Sprint ............................................................................................... 140

3.1.3. Cronograma sprints ......................................................................... 141

3.1.3.1. Sprint 1 ......................................................................................... 142

3.1.3.2. Sprint 2 ......................................................................................... 143

3.1.3.3. Sprint 3 ......................................................................................... 144

3.1.3.4. Sprint 4 ......................................................................................... 145

3.1.3.5. Sprint 5 ......................................................................................... 146

3.2. MODELO DE DOMINIO ...................................................................... 147

3.3. DIAGRAMA DE DESPLIEGUE ........................................................... 148

4. FASE DE TRANSICIÓN ......................................................................... 149

4.1. INSTALACIÓN FINAL DEL SOFTWARE ............................................ 149

4.2. PRUEBAS ........................................................................................... 149

4.2.3. PRUEBAS DE VALIDACIÓN: PRUEBA PILOTO ............................ 149

4.2.4. PRUEBAS DE VALIDACIÓN: PRUEBAS DE CAMPO (usando TAM) 152

4.2.5. PRUEBAS DE CASOS DE USO ..................................................... 159

5. RECOMENDACIONES .......................................................................... 175

6. CONCLUSIONES .................................................................................. 176

7. BIBLIOGRAFÍA ..................................................................................... 177

8. ANEXOS .............................................................................................. 1779

LISTA DE TABLAS

Tabla 1. Estado del arte: Fuentes primarias. ......................................................... 13

Tabla 2. Estado del arte: Fuentes secundarias. .................................................... 14 Tabla 3. Marco Institucional: Presentación del establecimiento ............................ 32 Tabla 4. Factibilidad técnica: Equipo 1 de desarrollo. ........................................... 43 Tabla 5. Factibilidad técnica: Equipo 2 de desarrollo ............................................ 43

Tabla 6. Factibilidad técnica: Equipo instalación final del software ....................... 44 Tabla 7. Factibilidad técnica: Recursos de software. ............................................ 44 Tabla 8. Factibilidad económica: Recursos humanos. .......................................... 45

Tabla 9. Factibilidad económica: Recursos técnicos. ............................................ 45 Tabla 10. Factibilidad económica: Costo total. ...................................................... 46

Tabla 11. Fase elaboración: Técnicas e instrumentos de investigación. ............... 49 Tabla 12. Fase elaboración: Resumen resultado de la investigación. ................... 50

Tabla 13. Fase elaboración: Técnicas e instrumentos para el diseño. .................. 50 Tabla 14. Definición del diseño educativo: Definición de competencias, fase I. .... 51 Tabla 15. Definición del diseño educativo: Definición de competencias, fase II. ... 52

Tabla 16. Diseño educativo: Acciones mediante las cuales se evalúa. ................. 52 Tabla 17. Diseño educativo: Diseño del MEC. ...................................................... 53

Tabla 18. Requerimientos funcionales. ................................................................. 75 Tabla 19. Fase elaboración: Definición casos de uso. .......................................... 77

Tabla 20. Documentación casos de uso: Caso 1- Login usuario. ......................... 79 Tabla 21. Documentación casos de uso: Caso 2 - Registrar estudiante. .............. 80

Tabla 22. Documentación casos de uso: Caso 3 - Modificar estudiante. .............. 81 Tabla 23.Documentación casos de uso: Caso 4 – Consultar información del estudiante. ............................................................................................................. 82

Tabla 24. Documentación casos de uso: Caso 5 – Consultar información detallada estudiante. ............................................................................................................. 83

Tabla 25. Documentación casos de uso: Caso 6 – Eliminar estudiante. ............... 84 Tabla 26. Documentación casos de uso: Caso 7 - Registrar tipo condición. ......... 85

Tabla 27. Documentación casos de uso: Caso 8 - Modificar tipo condición. ......... 86 Tabla 28. Documentación casos de uso: Caso 09 – Consultar tipo condición. ..... 87 Tabla 29. Documentación casos de uso: Caso 10 – Consulta detalles tipo condición. .............................................................................................................. 88 Tabla 30. Documentación casos de uso: Caso 11 – Eliminar tipo condición. ....... 89

Tabla 31. Documentación casos de uso: Caso 12 – Gestión Cuenta. .................. 90 Tabla 32. Documentación casos de uso: Caso 13 – Ver créditos. ........................ 91 Tabla 33. Documentación casos de uso: Caso 14 - Iniciar juego. ......................... 92 Tabla 34. Documentación casos de uso: Caso 15 - Responder el juego. ............. 93 Tabla 35. Documentación casos de uso: Caso 16 - Modificar configuraciones..... 94 Tabla 36. Documentación casos de uso: Caso 17 – Ver tutorial. Fuente: Autor. .. 95

Tabla 37. Documentación casos de uso: Caso 18 – Cerrar sesión. ...................... 96 Tabla 38. Lista priorizada: Sprints. ...................................................................... 141 Tabla 39. Sprint 1. ............................................................................................... 142 Tabla 40. Sprint 2. ............................................................................................... 143

Tabla 41. Sprint 3. ............................................................................................... 144 Tabla 42. Sprint 4. ............................................................................................... 145 Tabla 43. Sprint 5. ............................................................................................... 146 Tabla 44. Recurso requerido vs Recurso disponible. .......................................... 149 Tabla 45. Pruebas TAM estudiantes: Resultados PU. ........................................ 153

Tabla 46. Pruebas TAM estudiantes: Resultados PEOU. ................................... 154 Tabla 47. Pruebas TAM estudiantes: Resultados A. ........................................... 155

Tabla 48.Pruebas TAM docentes: Resultados PU. ............................................. 156

Tabla 49. Pruebas TAM estudiantes: Proceso PEOU. ........................................ 157 Tabla 50. Pruebas TAM estudiantes: Proceso A. ................................................ 158

LISTA DE FIGURAS

Figura 1. Marco teórico: Unity. .............................................................................. 16 Figura 2. Marco teorico: C#. .................................................................................. 18 Figura 3. Marco teorico: SQLite. ............................................................................ 21

Figura 4. Marco teórico: UML. ............................................................................... 23 Figura 5. Marco institucional: Organigrama. .......................................................... 33 Figura 6. Diagrama de procesos software educativo ............................................ 34 Figura 7. Diagrama Procesos: [M1] Nodo navegación docentes........................... 35 Figura 8. Diagrama procesos: [M2] Nodo navegación estudiantes ....................... 36

Figura 9. Diagrama procesos: [A1] Administración del software ........................... 37

Figura 10 . Metodología Open Up. ........................................................................ 39 Figura 11. Metodología: Cronograma 1. ................................................................ 41

Figura 12. Metodología: Cronograma 2. ................................................................ 42 Figura 13. Vista interfaz 1: Presentación. .............................................................. 54 Figura 14. Vista interfaz 2: Iniciar Sesión. ............................................................. 55

Figura 15. Vista interfaz 3: Menú principal administrador. ..................................... 56 Figura 16. Vista interfaz 4: Consulta información estudiantes. .............................. 57 Figura 17. Vista interfaz 5: Ver información detallada del estudiante. ................... 58

Figura 18. Vista interfaz 6: Actualizar información estudiante. .............................. 59 Figura 19. Vista interfaz 7: Eliminación estudiante. ............................................... 60

Figura 20. Vista Interfaz 8: Consultar Información Tipo Condición ........................ 61

Figura 21. Vista Interfaz 10: Registro Tipo Condición. .......................................... 62

Figura 22. Vista Interfaz 10: Actualizar condición visual. ...................................... 63 Figura 23. Vista interfaz 11: Eliminación condición visual. .................................... 64

Figura 24. Vista interfaz 12: Gestión información cuenta. ..................................... 65 Figura 25. Vista Interfaz 13: Créditos. ................................................................... 66 Figura 26. Vista Interfaz 14. Menú principal estudiantes invidentes. ..................... 67

Figura 27. Vista Interfaz 15: Menú tipo de juego. .................................................. 68 Figura 28. Vista Interfaz 16: Selección tipo de juego. ........................................... 69 Figura 29. Vista Interfaz 17: Menú de configuración del juego. ............................. 70

Figura 30. Vista Interfaz 18: Juego educativo. ...................................................... 71 Figura 31. Vista Interfaz 19: Pérdida del juego...................................................... 72 Figura 32. Diagrama de casos de uso: Actores ..................................................... 78

Figura 33. Diagrama de casos de uso. .................................................................. 97 Figura 34. Diagramas de Secuencia: Registrar Estudiante. .................................. 98 Figura 35. Diagramas de secuencia: Modificar Estudiante.................................... 99

Figura 36. Diagramas de Secuencia: Consultar Estudiante. ............................... 100 Figura 37. Diagramas de Secuencia: Consultar Detalles Estudiante. ................. 101 Figura 38. Diagramas de Secuencia: Eliminar Estudiante. ................................. 102 Figura 39. Diagramas de Secuencia: Registrar Tipo Condición. ......................... 103 Figura 40. Diagramas de Secuencia: Modificar Tipo Condición. ......................... 104

Figura 41. Diagramas de Secuencia: Consultar Tipo Condición. ........................ 105 Figura 42. Diagramas de Secuencia: Consultar Detalle Tipo Condición. ............ 106 Figura 43. Diagramas de Secuencia: Eliminar Tipo Condición............................ 107

Figura 44. Diagramas de Secuencia: Gestionar Cuenta. .................................... 108 Figura 45. Diagramas de Secuencia: Ver Créditos ............................................. 109 Figura 46. Diagramas de Secuencia: Iniciar Sesión. ........................................... 110 Figura 47. Diagramas de Secuencia: Cerrar Sesión. .......................................... 111

Figura 48. Diagramas de Secuencia: Modificar Configuraciones. ....................... 112 Figura 49. Diagramas de Secuencia: Iniciar Juego. ............................................ 113 Figura 50. Diagramas de Secuencia: Responder Juego. .................................... 114 Figura 51. Diagramas de Secuencia: Ver Tutorial. .............................................. 115 Figura 52. Diagramas de Actividades: Registro Estudiante. ............................... 116

Figura 53. Diagrama de Actividades: Modificar Estudiante. .............................. 117 Figura 54. Diagramas de Actividades: Consultar Estudiante............................... 118

Figura 55. Diagrama de Actividades. Consulta Detalle Estudiante. .................. 118

Figura 56. Diagramas de Actividades: Eliminar Estudiante. ................................ 119 Figura 57. Diagramas de Actividades: Registrar Tipo Condición ........................ 120 Figura 58. Diagramas de Actividades: Modificar Tipo Condición. ....................... 121

Figura 59. Diagramas de Actividades: Consultar Tipo Condición. ....................... 122 Figura 60. Diagrama de Actividades: Consultar Detalle Tipo Condición ........... 122 Figura 61. Diagramas de Actividades: Eliminar Tipo Condición. ......................... 123

Figura 62. Diagramas de Actividades: Gestionar Cuenta. ................................... 124 Figura 63. Diagramas de Actividades: Ver Créditos ............................................ 124

Figura 64. Diagramas de Actividades: Iniciar Sesión. ......................................... 125 Figura 65. Diagramas de Actividades: Cerrar Sesión. ......................................... 125

Figura 66. Diagramas de Actividades. Modificar Configuraciones ...................... 126 Figura 67. Diagrama de Actividades: Iniciar Juego ........................................... 126

Figura 68. Diagramas de Actividades: Responder Juego. .................................. 127 Figura 69. Diagramas de Actividades: Ver Tutorial. ............................................ 127 Figura 70. Diagramas de Estado: Registrar Estudiante. ..................................... 128

Figura 71. Diagramas de Estado: Modificar Estudiante. ..................................... 128 Figura 72. Diagramas de Estado: Consultar Estudiante. ..................................... 129 Figura 73. Diagramas de Estado: Consultar Detalle Estudiante. ......................... 129

Figura 74. Diagramas de Estado: Eliminar Estudiante. ....................................... 130 Figura 75. Diagramas de Estado: Registrar Tipo Condición. .............................. 130 Figura 76. Diagramas de Estado: Modificar Tipo Condición. .............................. 131 Figura 77. Diagramas de Estado: Consultar Tipo Condición ............................... 131

Figura 78. Diagramas de Estado: Consultar Detalle Tipo Condición. .................. 132 Figura 79.Diagramas de Estado: Eliminar Tipo Condición. ................................ 132

Figura 80. Diagramas de Estado: Gestión Cuenta. ............................................. 133 Figura 81. Diagramas de Estado: Ver Créditos ................................................... 133 Figura 82. Diagramas de Estado: Iniciar Sesión. ................................................ 134 Figura 83. Diagramas de Estado: Cerrar Sesión. ................................................ 134 Figura 84. Diagramas de Estado: Modificar Configuraciones.............................. 135

Figura 85. Diagramas de Estado: Iniciar Juego ................................................... 135 Figura 86. Diagramas de Estado: Responder Juego. .......................................... 136 Figura 87. Diagramas de Estado: Ver Tutorial. ................................................... 136 Figura 88. Diagrama de clases: Parte I ............................................................. 137

Figura 89. Diagrama de Clases: Parte II ............................................................. 138 Figura 90. Roles y componentes de la metodología Open Up ............................ 139 Figura 91. Modelo de dominio. ............................................................................ 147 Figura 92. Diagrama de Despliegue. ................................................................... 148

Figura 93. Prueba inicial: Manejo de operaciones. .............................................. 150 Figura 94.Prueba inicial: Manejo de operaciones ................................................ 150 Figura 95. Prueba inicial. Interfaz gráfica con contraste. ..................................... 151 Figura 96. Prueba inicial: Uso de sonido. Fuente: Autor ..................................... 151 Figura 97. Pruebas TAM estudiantes: Resultados PU. ....................................... 153

Figura 98. Pruebas TAM estudiantes: Resultados PEOU. .................................. 154 Figura 99.Pruebas TAM estudiantes: Resultados A. ........................................... 155

Figura 100. Pruebas TAM docentes: Resultados PU. ......................................... 156

Figura 101. Pruebas TAM docentes: Resultados PEOU. .................................... 157 Figura 102. Pruebas TAM estudiantes: Proceso A. Fuente: Autor ...................... 158 Figura 103. Pruebas Caos de Uso: Iniciar Sesión I. ............................................ 159

Figura 104. Pruebas Caos de Uso: Iniciar Sesión II. ........................................... 159 Figura 105. Pruebas Casos de Uso: CU-02 Registrar Estudiante I. .................... 160 Figura 106. Pruebas Casos de Uso: CU-02 Registrar Estudiante II. ................... 160

Figura 107. Pruebas Casos de Uso: CU-02 Registrar Estudiante III. .................. 161 Figura 108. Pruebas Casos de Uso: CU-02 Registrar Estudiante IV. ................. 161

Figura 109. Pruebas Casos de Uso: CU-03 Modificar Estudiante I. .................... 162 Figura 110. Pruebas Casos de Uso: CU-03 Modificar Estudiante II. ................... 162

Figura 111. Pruebas Casos de Uso: CU-03 Modificar Estudiante III. .................. 163 Figura 112. Pruebas Casos de Uso: CU-04 Consultar Estudiante I. ................... 163

Figura 113. Pruebas Casos de Uso: CU-05 Consultar Detalle Estudiante I. ....... 164 Figura 114. Pruebas Casos de Uso: CU-06 Eliminar Estudiante I. ..................... 164 Figura 115. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición I. ............. 165

Figura 116. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición II. ............ 165 Figura 117. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición III. ........... 166 Figura 118. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición IV. .......... 166

Figura 119. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición I. ............. 167 Figura 120. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición II. ............ 167 Figura 121. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición III. ........... 168 Figura 122. Pruebas Casos de Uso: CU-09 Consultar Tipo Condición ............... 168

Figura 123. Pruebas Casos de Uso: CU-10 Consultar Detalle Tipo Condición ... 169 Figura 124. Pruebas Casos de Uso: CU-11 Eliminar Tipo condición. ................. 169

Figura 125. Pruebas Casos de Uso: CU-12 Gestionar Cuenta I. ........................ 170 Figura 126. Pruebas Casos de Uso: CU-12 Gestionar Cuenta II. ....................... 170 Figura 127. Pruebas Casos de Uso: CU-13 Ver Créditos. .................................. 171 Figura 128. Pruebas Casos de Uso: CU-14 Cerrar Sesión. ................................ 171 Figura 129. Pruebas Casos de Uso: CU-15 Modificar Configuraciones. ............. 172

Figura 130. Pruebas Casos de Uso: CU-16 Iniciar Juego I. ................................ 172 Figura 131. Pruebas Casos de Uso: CU-16 Iniciar Juego II. ............................... 173 Figura 132. Pruebas Casos de Uso: CU-17 Responder Juego I ......................... 173 Figura 133. Pruebas Casos de Uso: CU-18: Ver Tutorial. ................................... 174

LISTA DE ANEXOS

Anexo A. Manual del Usuario .............................................................................. 180 Anexo B. Manual del Programador ................................................................. 24181 Anexo C. Modelo Relacional ............................................................................... 183

Anexo D. Formato encuesta levantamiento de requerimientos ........................... 184 Anexo E. Formato pruebas TAM ......................................................................... 184

GLOSARIO

Unity 3D: Unity 3D es un motor gráfico desarrollado por Unity Technologies desde 2001 con el objetivo de permitir a todo el mundo crear atractivos entornos 3D.

SQLite: Es una biblioteca escrita en leguaje C que implementa un Sistema de gestión de bases de datos transaccionales SQL auto-contenido, sin servidor y sin configuración.

C#: Es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft

Monodevelop: Es un entorno de desarrollo integrado libre y gratuito, diseñado primordialmente para C# y otros lenguajes

Programación orientada a objetos: Forma de diseño y metodología de desarrollo de software, que puede ser aplicada a cualquier tipo de lenguaje de programación. Permite a los programadores escribir software, de forma que esté organizado en la misma manera que el problema que trata de modelizar.

Clase: Una clase es algo abstracto que define la "forma" del objeto, se podría hablar de la clase como el molde de los objetos.

Objeto: El cual puede referirse a cualquier entidad y que presentará dos características; un estado y un comportamiento, el primero incluirá las cualidades del objeto y el segundo definirá las acciones que el objeto ejecutará.

Atributo: Los atributos son las características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades.

Método: Es un programa procedimental que está asociado a un objeto determinado y cuya ejecución solo puede desencadenarse a través del mensaje correspondiente.

Script: Es un documento que contiene instrucciones, escritas en códigos de programación.

Interfaz: Conjunto de elementos de la pantalla que permiten al usuario realizar acciones sobre sistema que está visitando.

Educación incluyente: Es un modelo educativo que busca atender las necesidades de aprendizaje de todos los niños, jóvenes y adultos con especial énfasis en aquellos que son vulnerables a la marginalidad y la exclusión social.

Software educativo: Conjunto de programas que se utilizan para la instrucción, formación o enseñanza.

Juego educativo: Es un material multimedia interactivo por medio del cual se puede aprender uno o varios temas

Discapacidad visual: Se define con base en la agudeza visual de la vista de los ojos, así como el campo visual. Se habla de discapacidad visual del ojo cuando existe una disminución significativa de la agudeza visual del ojo aun con el uso de lentes, o bien, una disminución significativa del campo visual del ojo.

Tiflología: Es la ciencia que estudia las condiciones y la problemática que rodea a las personas con discapacidad visual (invidentes e hipovidentes)

Invidencia: Es una diversidad funcional de tipo sensorial que consiste en la pérdida total o parcial del sentido de la vista

Baja visión (hipovisión): es la cualidad de la persona con una privación parcial de la vista que no puede ser corregida adecuadamente con gafas convencionales, lentes de contacto, medicamentos o cirugía.

1

RESUMEN

El aprendizaje de las matemáticas genera en los niños cierto tipo de problemáticas debido al grado de complejidad de determinadas temáticas, lo anterior se relaciona con la efectividad del método de enseñanza y las capacidades que el estudiante presenta; por lo que para solucionar esta problemática lo conveniente es dar un nuevo enfoque al método de enseñanza manejado, implementando herramientas que generen apoyo al proceso de aprendizaje del estudiante y que además se enfoquen en las capacidades de los mismos.

En el caso específico en el que el estudiante presente algún tipo de discapacidad, en este caso visual, el enfoque educativo debe fundamentarse en los lineamientos de la educación inclusiva, y además debe suministrarse al estudiante herramientas que no solo incentiven el aprovechamiento de sus capacidades, sino que también apoyen al estudiante en su proceso de aprendizaje, para de tal manera generar las bases necesarias para la adquisición de conocimientos a futuro.

En ese orden de ideas el presente documento describe una problemática relacionada a lo expuesto anteriormente y se define la solución tecnológica a dicha problemática, la cual consiste en el desarrollo de un software educativo enfocado a apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes del programa de tiflología del Colegio OEA I.E.D, mediante el uso de un juego educativo. Se plantean las fases de inicio, elaboración, construcción y desarrollo establecidas por la metodología de desarrollo Open Up y el enfoque hacia el aspecto educativo que la solución tecnológica presenta.

2

ABSTRACT

The learning of mathematics generates in children certain types of problems due to the degree of complexity of certain topics, the above is related to the effectiveness of the teaching method and the abilities that the student presents; So that to solve this problem it is convenient to give a new approach to the method of teaching managed, implementing tools that generate support for the learning process of the student and also focus on the capabilities of the same.

In the specific case in which the student presents some type of disability, in this visual case, the educational approach must be based on the guidelines of inclusive education, and in addition the student should be provided with tools that not only encourage the use of their abilities but That also support the student in his learning process, in order to generate the necessary bases for the acquisition of knowledge in the future.

In this context, this document describes a problem related to the above and defines the technological solution to this problem, which consists in the development of educational software focused on supporting the learning process of the basic mathematical operations of the Students of the typhology program of the OEA IED College, through the use of an educational game. The stages of initiation, elaboration, construction and development established by the Open Up development methodology and the approach towards the educational aspect that the technological solution presents are presented.

3

INTRODUCCIÓN

La educación inclusiva se fundamenta bajo la definición de ser “un modelo de escuela en la que no existen requisitos de entrada, ni mecanismos de selección o discriminación de ningún tipo, para hacer realmente efectivos los derechos a la educación, a la igualdad de oportunidades y a la participación”1; por lo tanto la educación inclusiva tiene como objetivo principal permitir el acceso a la educación a todos los niños, sin importar su condición social o si presenta algún tipo de discapacidad.

En Colombia el Ministerio de Educación Nacional cuenta con el programa «Educación para Todos», el cual “se propone atender a los niños, niñas y jóvenes con discapacidades a lo largo de todo el ciclo educativo, desde la educación inicial hasta la superior”2, y para ello cuenta con instituciones educativas distritales enfocadas en el impartimiento de la educación enfocado en las capacidades con las que cuenten los estudiantes.

El colegio OEA es una de las instituciones educativas estructuradas bajo el programa de «Educación para Todos», ya que cuenta con el manejo del programa de tiflología, el cual se encuentra orientado a las discapacidades visuales de los estudiantes de los grados desde pre escolar hasta bachillerato.

El presente documento contiene las fases de desarrollo de un proyecto de grado en la modalidad de pasantía implementado en dicha institución, el proyecto consiste en la elaboración de un software educativo, orientado a apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria que presentan algún tipo de discapacidad visual; de éste modo se suministra una herramienta tecnológica innovadora para los estudiantes y que además les permitirá tanto el aprovechamiento de sus capacidades como el acercamiento a las tecnologías de la información.

El documento está estructurado en relación a las fases de la metodología de desarrollo seleccionada (OpenUp), las cuales son: fase de definición, planeación y organización, fase de elaboración, fase de construcción y fase de transición.

La fase de inicio está compuesta por diversos aspectos como, la definición y formulación del problema, los objetivos, la justificación, los alcances y limitaciones entre otros.

1 BLANCO, Rosa. Hacia una Escuela para Todos y con Todo. UNESCO. Santiago de chile, Chile, [citado 22 sept 2016]. Disponible en: http://www.ite.educacion.es/formacion/materiales/72/cd/curso/unidad1/u1.I.8.htm 2 MINISTERIO DE EDUCACIÓN. Educación para todos [en línea]. Colombia. [citado 22 septiembre 2016].

Disponible en: http://www.mineducacion.gov.co/1621/article-141881.html

4

La fase de elaboración está compuesta por la definición del análisis de la elaboración, la definición del diseño del sistema, la definición de requerimientos, la definición y documentación de los casos de uso y la presentación de los diagramas relacionados a los módulos del proyecto.

La fase de construcción está compuesta por la descripción de los roles del equipo de trabajo del proyecto de acuerdo con la metodología implementada, así como la descripción y desarrollo de los sprits relacionados con la elaboracion del software.

La fase de transición está compuesta por la presentación de las pruebas realizadas al sistema.

Finalmente se presentan las recomendaciones y conclusiones asociadas al proyecto, así como los anexos, entre los que se pueden encontrar el diccionario de datos, los formatos de las encuestas implementadas para las pruebas y el manual del usuario.

5

1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN

1.1. TÍTULO DEL PROYECTO

Software educativo en apoyo al proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria del programa de tiflología del Colegio OEA I.E.D.

1.2. TEMA

El desarrollo del proyecto implica abordar las siguientes temáticas

• Software educativo orientado a estudiantes invidentes. • Juegos educativos con implementación de sonido. • Programación orientada a objetos. • Bases de datos.

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. DESCRIPCIÓN DEL PROBLEMA

Las discapacidades visuales (invidencia y baja visión) generan dificultad en la obtención de determinado tipo de conocimientos, como lo son los asociados a la asignatura académica de las matemáticas; la adecuada adquisición de los conocimientos incorporados en esta área del conocimiento permitirá que el estudiante obtenga una buena base para su proceso educativo a futuro, ya que “los aprendizajes matemáticos constituyen una cadena en la que cada conocimiento va enlazado con los anteriores. Las dificultades iniciales en éste aprendizaje pueden llevar a dificultades posteriores aún mayores”3, así que, el primer ciclo del proceso educativo (básica primaria) debe establecer en los estudiantes las bases de conocimiento necesarias para la adecuada evolución educativa de los mismos, además la educación debe estar orientada a las capacidades de los estudiantes, por lo que, en Colombia se cuenta con una política de educación

3 ARANDA, Miriam; PÉREZ, Miguel y SÁNCHEZ, Blanca. Bases Psicopedagógicas de la Ed Especial. Dificultades en el Aprendizaje Matemático [en línea]. Ciudad de México, México. [citado 22 septiembre 2016]. p 22. Disponible en: https://www.uam.es/personal_pdi/stmaria/.../DificultadesMatematicasLenguaje1.pdf

6

inclusiva, la cual “se propone atender a los niños, niñas y jóvenes con discapacidades a lo largo de todo el ciclo educativo, desde la educación inicial hasta la superior”4, para ello se cuenta con establecimientos educativos capacitados para el suministro de la educación a estudiantes que presenten algún tipo de discapacidad.

El Colegio OEA I.E.D, es una de éstas instituciones, ya que cuenta con un programa de tiflología, el cual está orientado a los estudiantes invidentes y de baja visión presentes en los cursos desde preescolar a once, generando así un esquema de inclusión, no solo al permitirles el acceso a la institución y el suministro de conocimientos sino también al incentivar la convivencia de los mismos con los demás estudiantes de la institución. Los estudiantes del programa de tiflología adquieren los conocimientos suministrados por los docentes en el aula de clase y además cuentan con el apoyo de los tiflólogos en aspectos como el suministro de materiales y adecuación de los textos requeridos por los estudiantes.

En este sentido, mediante observación directa, se identificó que el proceso de aprendizaje de estos estudiantes genera un alto grado de dificultad para los mismos debido a la discapacidad que presentan, aun así, la institución se esmera por suministrar el apoyo necesario a los estudiantes, por ejemplo, en el área de matemáticas los estudiantes cuentan con el seguimiento de un tiflólogo que se encarga de dictarle los conceptos que el docente ha escrito en el tablero, así como apoyarlo en el desarrollo de ejercicios y problemas; sin embargo, sumado a la dificultad que pueden generar cierto tipo de temáticas, el estudiante no cuenta con una herramienta que le permita apoyar su proceso de adquisición de conocimientos y el efectivo aprendizaje de los mismos, por lo que se propone un software educativo que apoye el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes del programa de tiflología de la institución, con la finalidad de suministrar una herramienta que permita a los estudiantes fortalecer las bases adecuadas para su proceso educativo e incentive la inclusión en los espacios tecnológicos de la institución, así como el manejo de las tecnologías de la información y la comunicación por parte de los estudiantes con discapacidades visuales.

1.3.2. FORMULACIÓN DEL PROBLEMA

¿Cómo apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria que presentan discapacidades

4 MINISTERIO DE EDUCACIÓN. Educación para todos [en línea]. Colombia. [citado 22 septiembre 2016]. Disponible en: http://www.mineducacion.gov.co/1621/article-141881.html

7

visuales y que se encuentran en su proceso de formación académica en el colegio OEA I.E.D?

1.4. OBJETIVOS

1.4.1. OBJETIVO GENERAL

Desarrollar un software educativo que permita apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes del programa de tiflología del Colegio OEA I.E.D.

1.4.2. OBJETIVOS ESPECÍFICOS

• Diseñar e implementar una base de datos que permita el almacenaje de la información asociada a los usuarios del sistema, es decir, los estudiantes y docentes.

• Desarrollar un módulo para el gestionamiento de la información de los usuarios, en el que dependiendo del rol que cumpla el usuario dentro del sistema podrá registrar, modificar, eliminar y consultar información.

• Elaborar un módulo de acceso a la aplicación que previo al proceso de

registro, permita acceder al aplicativo a cada uno de los usuarios del sistema.

• Diseñar y desarrollar un juego enfocado al manejo de las operaciones

básicas matemáticas como herramienta principal del software.

• Implementar en el diseño del software aspectos asociados al manejo de las capacidades de los estudiantes, tales como sonido, contraste de colores y tamaño de la fuente.

• Validar el funcionamiento del sistema en un caso específico de estudio

referente al uso del aplicativo por los estudiantes y los docentes.

1.5. ALCANCES Y DELIMITACIONES

1.5.1. ALCANCES El proyecto en desarrollo tiene como principal alcance apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de

8

básica primaria del programa de tiflología del Colegio OEA I.E.D, por lo que el producto a entregar consta del diseño, desarrollo e implementación de:

• La respectiva base de datos requerida para el almacenaje de la información asociada a los usuarios del aplicativo, es decir, estudiantes y docentes (quienes cumplen el rol de administrador).

• Los diferentes componentes que en conjunto conforman el software final, entre los cuales destacan:

◦ El juego educativo asociado al software, el cual se orienta a la solución de operaciones básicas matemáticas, es decir, suma, resta, multiplicación y división. El juego implementará el uso de sonido como fuente de salida de información, así como el uso del teclado numérico como fuente de entrada de información; además manejará el uso de animaciones que suministraran a los estudiantes un aplicativo amigable, atractivo y orientado a su edad y capacidades.

◦ Los módulos para el gestionamiento de la información de los usuarios del software.

1.5.2. DELIMITACIONES • Geográfico: Hace referencia al espacio geográfico en el cual se

realizará tanto el desarrollo del software como la implementación del mismo.

◦ Desarrollo: El desarrollo del software se realizará en el sitio de

trabajo designado por los desarrolladores, específicamente los hogares de los mismos, haciendo uso de los recursos técnicos y operativos requeridos.

◦ Implementación: La implementación del sistema se realizará en el

aula de tiflología del colegio OEA I.E.D y podrá ser consultado por un determinado usuario desde el ordenador designado por la institución para la instalación final del software.

• Temático: El software educativo permitirá a los estudiantes con

discapacidades visuales del ciclo de básica primaria, presentes en los cursos tercero (3°), cuarto (4°) y quinto (5°), apoyar su proceso de aprendizaje de las operaciones básicas matemáticas, mediante la

9

implementación de un juego educativo orientado a la temática ya especificada, el cual suministrará a los estudiantes herramientas para la interacción con la aplicación, tales como el uso de sonidos, uso de contraste de colores y propiedades de la fuente, con la finalidad de generar el aprovechamiento máximo de las capacidades de los niños. El software permitirá a los docentes realizar un seguimiento de los avances de los estudiantes a través del tiempo de uso del software, mediante la generación consultas a los datos almacenados en la base de datos.

• Temporal: El tiempo estimado para la realización de este proyecto es de 6 meses, pero en caso de presentarse algún inconveniente en el suministro de los equipos y software necesario para la implementación de la aplicación se correrán las fechas estimadas en el cronograma.

• Técnico: El software educativo utilizará como motor de base de datos

SQLite, como herramienta de desarrollo Unity, como generador de sonidos el software Acapela, metodología de desarrollo Open Up, y lenguaje de modelado UML 2.x.

• Funcional: El software será entregado e implementado bajo las

respectivas pruebas generadas en el ordenador suministrado por la institución para la instalación final.

Además, asumiendo la amplia variedad de contenidos que podrían ser incorporados en este proyecto, es preciso estipular las siguientes limitaciones temáticas:

◦ El manejo de las operaciones matemáticas está orientado a los

estudiantes de los cursos tercero, cuarto y quinto; por lo que este software no garantiza el manejo de operaciones matemáticas complejas, ya que se encuentra orientada a las capacidades de los estudiantes de dichos cursos.

◦ El principal método de salida de información del software es el sonido,

pero este software no asegura el manejo de entrada de información mediante sonido, debido a que no solo está orientado a estudiantes invidentes sino también a estudiantes con baja visión y sin limitaciones visuales (videntes).

◦ Respecto al apartado visual, el software está orientado al uso de

estudiantes con discapacidades visuales por lo que se genera el uso de contrastes (escala de grises), así que visualmente el software

10

puede ser poco llamativo; sin embargo, se realiza la implementación de apariencias y/o configuración de colores, una enfocada a los estudiantes con discapacidades visuales y otra para los estudiantes videntes.

◦ El software está pensado para que funcione en computadores, la

iniciativa para implementarlo en plataformas móviles está contemplada, sin embargo, se encuentra en una posibilidad que en determinado caso podría no darse, ya que podrían generarse problemáticas con factores que aún no están contemplados y que pueden influir más adelante en el desarrollo.

◦ No se garantiza que el software funcione en todos los sistemas

operativos, inicialmente se encuentra contemplado su funcionamiento para sistemas Windows y algunos Linux (claro está que al presentarse el proyecto se dará informe sobre su compatibilidad, requerimientos y versiones de uso).

◦ El software no contará con características multiusuario, así mismo no

se conectará a la red para el uso de complementos, contenidos o conexiones adicionales.

◦ La base de datos asociada al software es local, esto debido a los

requerimientos especificados en la institución, ya que el aula de tiflología cuenta con un solo equipo orientado al uso de los estudiantes.

1.6. JUSTIFICACIÓN

La educación y los modelos de enseñanza se encuentran establecidos bajo estructuras tradicionales orientadas a la enseñanza de diversas temáticas pertenecientes a áreas específicas del conocimiento bajo el suministro de conocimientos en las aulas, pero en la actualidad la educación debe transformarse con la finalidad de que el sistema educativo esté a la par de los avances tecnológicos y científicos, todo esto de una manera acelerada y no lenta como ha venido ocurriendo, específicamente en el uso de las tecnologías de la Información y de la Comunicación (TIC), el problema radica en que gran parte de los docentes prefieren seguir utilizando las herramientas y metodologías tradicionales para el proceso de enseñanza, sin tener en cuenta que los estudiantes de hoy en día nacen en una era tecnológica y computarizada, en la cual el uso de la tecnología permitirá a los mismos tener una disposición para aprender a través del uso de herramientas tecnológicas orientadas al manejo de

11

diversas temáticas y bajo entornos didácticos y atractivos para los estudiantes, y que además permiten explotar al máximo las capacidades de los mismos.

En la actualidad los estudiantes se encuentran en una etapa en la que la predisposición al proceso de enseñanza se está perdiendo, se genera desinterés y por lo tanto la perdida de las facultades de querer aprender, lo que contribuye a la problemática de deserción escolar, ya que en 2014 el Ministerio de Educación Nacional, encontró que una de las cinco principales causas de deserción escolar en el país es el hecho de que a los niños no les gusta el estudio, esto debido a que en las aulas no se genera una motivación para los estudiantes la cual “determina la manera de enfrentar y realizar las actividades, tareas educativas y entender la evaluación que contribuye a que el alumno/a participe en ellas de una manera más o menos activa”5. La implementación de la tecnología en la educación permite abarcar ésta problemática y además suministra una herramienta tecnológica capaz de explotar las capacidades de los estudiantes, como lo es el caso de estudiantes con discapacidades visuales, los cuales debido al bajo nivel de inclusión de la tecnología en la educación presentan poca interacción con ésta, por lo que al implementar herramientas tecnológicas en el proceso educativo de este tipo de estudiantes no solo se generará en ellos una mejor predisposición hacia el aprendizaje, sino que también se podrá contribuir al aprovechamiento de sus capacidades, con la finalidad de apoyar su proceso educativo.

Actualmente se cuenta con una amplia variedad de software educativo, muchos de ellos diseñados para el uso de estudiantes con discapacidades visuales, los cuales suministran a los estudiantes una herramienta para aprender de una manera didáctica y recreativa, y que además permite el desarrollo de habilidades y capacidades que contribuyen a la mejora de su rendimiento académico. En este sentido, el software educativo es “considerado como el conjunto de recursos informáticos diseñados con la intención de ser utilizados en el contexto del proceso enseñanza - aprendizaje”6, así que, un software educativo es capaz de contribuir a mejorar el aprendizaje a través de procedimientos de obtención de conocimientos valiosos y significativos por parte del estudiante, asociados a las temáticas y contenidos que le generen algún tipo de dificultad.

En función de ello, la presente investigación y desarrollo de proyecto, tiene relevancia teórica, pedagógica y social. En el aspecto teórico estará apoyando el proceso de aprendizaje de las operaciones básicas por parte de los estudiantes de primaria del programa de tiflología de la institución ya establecida; en cuanto

5 MORÓN, Carmén. La importancia de la motivación en la educación infantil [en línea]. Andalucía, España:

Revista digital para profesionales de la enseñanza, ene. 2011. 1p. [citado 30 sep, 2016]. Disponible en: https://www.feandalucia.ccoo.es/docu/p5sd7914.pdf 6 OJEDA, Julio y PIÑA Carmen. Software en el contexto del Proceso Enseñanza – Aprendizaje [en línea]. Texinfo 2 ed. Querétaro, México: Odiseo, dic. 2010. 10p. [citado 30 sep, 2016]. Disponible en: http://www.odiseo.com.mx/correoslector/software-contexto-proceso-ensenanza-aprendizaje

12

a la relevancia pedagógica, el software educativo cumple una función de gran importancia en el manejo de la comunicación de información en la enseñanza tanto a nivel grupal como individual, así como permitir cambiar el rol del docente a un facilitador de herramientas y orientador de conocimientos, e igualmente cambiar el rol del alumno reflejado en el autoaprendizaje, la responsabilidad y la retroalimentación de conocimiento, permitiendo así promover el uso de las tecnologías de la información como una herramienta para el proceso educativo de un estudiante, orientado a las capacidades presentadas por el mismo y que además permita la generación de nuevas habilidades y aptitudes para los estudiantes; y una relevancia social en cuanto a que el proyecto está orientado a la contribución de una herramienta que permita el aprovechamiento de las capacidades de un población que así lo requiere.

Con base a lo planteado el desarrollo de este proyecto será de gran beneficio para los estudiantes, específicamente para los estudiantes del programa de tiflología, ya que se suministrará a los mismos la oportunidad de trabajar con un entorno tecnológico, orientado al aprovechamiento de sus capacidades y que apoyará su proceso de aprendizaje, además de permitirle relacionarse con los recursos tecnológicos de la institución y el uso de las tecnologías de la información y la comunicación.

1.7. MARCO DE REFERENCIA

1.7.1. ESTADO DEL ARTE

Partiendo de diferentes fuentes de información, se corrobora que el uso de herramientas tecnológicas orientadas a estudiantes con discapacidades visuales para el aprendizaje de diversos campos de conocimiento, en este caso las matemáticas, es un área que vale la pena seguir desarrollando, por el impacto y el aporte que genera, por lo anterior en la actualidad son muchos los desarrolladores que trabajan en esta área y que implementan diversas herramientas y contenidos novedosos.

1.7.1.1. FUENTES PRIMARIAS

TITULO AUTOR AÑO PAÍS INSTITUCIÓN

El software educativo un medio de enseñanza eficiente

Morejón Sonia 2011 España Universidad de Málaga

13

1.7.1.2. FUENTES SECUNDARIAS

Software Educativos Vidal María,

Gómez Fredy & Ruiz Alina

2010 Cuba N.A

Colección de software para invidentes y débiles visuales

Ávalo Elíade, Nieves

Osmany & Socorrás Silvio

2005 España CIVE

La educación inclusiva: el camino hacia el futuro

Blanco Rosa, Ouane Adama & Aguerrondo

Inés

2008 Francia UNESCO

Guía de buenas prácticas en educación inclusiva

Solla Carmén 2013 España N.A

Tendencias innovadoras en educación matemática

Guzmán Miguel

2003 España Universidad Complue-

tense

Tabla 1. Estado del arte: Fuentes primarias.

TITULO AUTOR AÑO PAÍS INSTITUCIÓN

Bases psico-pedagógicas de la ed. Especial. Dificultades en el aprendizaje matemático

Aranda Miriam, Pérez Miguel & Sánchez Blanca

2004 España N.A

La enseñanza de la matemática a los ciegos

Fernández José 2004

España ONCE

14

1.7.1.3. PROYECTOS RELACIONADOS

En la documentación de los siguientes proyectos; “Software de Enseñanza-Aprendizaje de Operaciones Básicas de las Matemáticas, la Suma y la Resta, Dirigida a la Educación de Transición y Primero de Primaria”7, proyecto tecnológico desarrollado por Adriana Ricardo e Ingrid Parra para la Universidad Nacional Abierta y a Distancia (UNAD) en el año 2009, y “Desarrollo de un Videojuego Educativo con Diseño 3D, Enfocado Hacia el Apoyo en el Aprendizaje de las Tablas de Multiplicar”8, proyecto tecnológico desarrollado por Brandon Castillo para la

7 RICARDO Adriana y PARRA Ingrid. Software de enseñanza - Aprendizaje de las operaciones básicas de las matemáticas, la suma y la resta, dirigida a la educación de transición y primero de primaria. Universidad Nacional Abierta y a Distancia (UNAD), Bogotá, 2009. 8 CASTILLO, Brandon. Desarrollo de un Videojuego Educativo con Diseño 3D, enfocado hacia el Apoyo en el Aprendizaje de las Tablas de Multiplicar. Universidad Distrital Francisco José de Caldas, Bogotá, 2014

La enseñanza de la matemática a los alumnos ciegos y disminuidos visuales. El relato de una experiencia

Mántica Ana, Götte Marcela &

Dal Susana 2014 Argentina

Universidad Nacional del

Litoral

Estrategias para enseñar contenidos matemáticos a alumnos ciegos o con baja visión.

Blanco Rosa, Ouane Adama & Aguerrondo

Inés

2013 Uruguay Universidad

de Barcelona

Inclusión de TIC en escuelas para alumnos con discapacidad visual

Zappalá Daniel, Köppel Andrea & Suchodolski

Miriam

2011 Argentina Ministerio Educación

España

Las TIC al servicio de la inclusión educativa

Rodríguez Marisol &

Arroyo María 2014 España N.A

Ingeniería de Software Educativo

Galvis Álvaro 2011 Colombia Universidad

de los Andes

Tabla 2. Estado del arte: Fuentes secundarias.

15

Universidad Distrital Francisco José de Caldas en el año 2014, se evidencia la evolución que se plantea en referencia al modelo educativo actual, ya que ambos proyectos se centran en el uso de las TIC en la educación, mediante la inclusión de herramientas que por medio de computadores permitan hacer las clases más interactivas, recreativas, atrayentes y eficaces, al añadir diferentes materiales en una plataforma virtual.

Sin embargo, los anteriores proyectos no presentan un enfoque de educación inclusiva ni el manejo de accesibilidad para estudiantes con algún tipo de discapacidad, así que mediante un arduo proceso de búsqueda, se encontró en la red un juego orientado a niños con discapacidades visuales, “Cantaletras”9, desarrollado por el Centro de Desarrollo de Tecnologías de Inclusión (CEDETI) de chile, el cual ayudo a los niños en el aprendizaje de la escritura; otro de los juegos educativos presentes en la red es “El Caracol Serafín”10, desarrollado por la Organización Nacional de Ciegos Españoles, el cual mediante la narración de cuentos permite a los niños mejorar la atención y la comprensión.

En referencia a lo anterior se evidencia que aunque actualmente se está abordando el campo de desarrollo de software educativo orientado a estudiantes con baja visión, son limitadas las áreas de conocimiento que se manejan, por lo que en el caso de las matemáticas no se encontró un software inclusivo gratuito que estuviera orientado al manejo de temáticas en ésta área; así que el desarrollo de este proyecto es innovador y además orientado socialmente al suministro de herramientas para un población que lo requiere.

Además, en cuanto a la elaboración de proyectos tecnológicos inclusivos orientados a la elaboración de software educativo incluyente por parte de la Universidad Distrital Francisco José de Caldas son pocas las iniciativas generadas, una de las pocas propuestas que abarca tanto el manejo de las matemáticas como la inclusión educativa, es la del proyecto de grado “Enseñanza Aprendizaje de las Matemáticas desde una Perspectiva Inclusiva para Personas en Condición de Discapacidad Visual”11 desarrollado por Nelly Santos de la Facultad de Educación; en este orden de ideas nuestro proyecto será el primero resultado de la UDFJC que se enfoque en el manejo de las Tecnologías de la Información y la Comunicación en la educación, orientado a estudiantes con

9 CEDETI, Centro de Desarrollo de Tecnologías de Inclusión, Cantaletras. Pontificia Universidad Católica de Chile, Chile, 2006. 10 ONCE, Organización Nacional de Ciegos Españoles, El Caracol Serafín, 11SANTOS, Nelly. Enseñanza Aprendizaje de las Matemáticas desde una Perspectiva Inclusiva para Personas en Condición de Discapacidad Visual. Universidad Distrital Francisco José de Caldas, Bogotá, 2016.

16

discapacidades visuales, ofreciendo así una herramienta realmente benéfica para una población educativa que la aprovechará al máximo, y de este modo se estará promoviendo el cumplimiento de la visión de nuestro proyecto curricular en cuanto al aporte de desarrollo tecnológico e investigativo para nuestro país.

1.7.2. MARCO TEÓRICO

El marco teórico se centra en la conceptualización de los diversos aspectos técnicos relacionados con el desarrollo del proyecto tales como:

• Unity

Unity 3D es un motor de creación de videojuegos 3D lanzado oficialmente como tal el 1 de Junio 2005. Este motor permite la creación de juegos y otros contenidos interactivos como diseños arquitectónicos o animaciones 3D en tiempo real.12

Muchas personas interesadas por el desarrollo se topan con la dificultad de aprender los lenguajes

de programación y los motores que los utilizan. Sin estudios de programación o de animación por ordenador, el aprendizaje de los conceptos, métodos y los principios necesarios para la creación de un videojuego se hace muy difícil.

Unity Technologies es una de las empresas que ha decido rectificar esta situación. Desde el lanzamiento de la primera versión 1.0.1 en 2001, esta empresa danesa se ha esforzado para que sus herramientas sean accesibles y fáciles de usar. El equipo de desarrollo de unity ha decido mantener el código fuente ofreciendo al usuario una interfaz gráfica completa de manera a que el usuario pueda controlar el código fuente sin tener que crear nuevos elementos en el código. Este factor ha hecho que unity sea muy popular entre los desarrolladores de videojuegos.

12 OUAZZANI, Iman. Manual de Creación de Videojuegos con Unity 3D [en línea]. Universidad Carlos III de Madrid. Madrid, España, 2012, [citado 02 oct, 2016]. Disponible en: http://e-archivo.uc3m.es/bitstream/handle/10016/16345/PFC_Iman_Ouazzani.pdf

Figura 1. Marco teórico: Unity. Fuente: http://www.uniat.com/wp-

content/uploads/2015/07/Unity-Logo.png

17

Unity es una aplicación 3D en tiempo real y multimedia además de ser motor 3D y físico utilizado para la creación de juegos en red, de animación en tiempo real, de contenido interactivo compuesto por audio, video y objetos 3D.

Este motor no permite la modelización, pero permite crear escenas que soportan iluminación, terrenos, cámaras, texturas. Fue creado en un principio para la plataforma Mac y ha sido exportado a Windows, permite obtener aplicaciones compatibles con Windows, Mac OS X, iOS, Android, Wii, Playstation 3, Xbox 360, Nintendo, iPad, iPhone con Web gracias a un plugin y recientemente desde la versión 3.5 con el formato Flash de Adobe.

Unity presenta varias ventajas que hacen que sea uno de los motores de videojuego más cotizado del momento. En los siguientes párrafos se van a ir citando todas estas ventajas:

◦ Permite la importación de numerosos formatos 3D como 3ds Max, Maya, Cinema 4D, Cheetah3D y Softimage, Blender, Modo, ZBrush, FBX o recursos variados tales como texturas Photoshop, PNG, TIFF, audios y videos. Estos recursos se optimizan posteriormente mediante filtros.

◦ Es compatible con las API graficas de Direct3D, OpenGL y Wii. Además de ser compatible con QuickTime y utilizar internamente el formato Ogg Vorbis.

◦ En Unity, el juego se construye mediante el editor y un lenguaje de

scripts por lo cual el usuario no tiene que ser un experto en programación para usarlo. En efecto, este software tiene la particularidad de incluir la herramienta de desarrollo MonoDevelop con la que se pueden crear scripts en JavaScript, C# y un dialecto de Python llamado Boo con los que extender la funcionalidad del editor, utilizando las API que provee y la cual encontramos documentada junto a tutoriales y recursos en su web oficial.

◦ La estructura de los juegos creados por Unity viene definida mediante

escenas que representan alguna parte del juego. ◦ Incluye un editor de terrenos que permite la creación de estos partiendo

de cero. Este editor permite esculpir la geometría del terreno, su texturización y la inclusión de elementos 3D importados desde aplicaciones 3D o ya predefinidos en Unity.

◦ En cuanto a los usuarios que no tienen ninguna noción de programación

existen plugins como Playmaker que permiten "programar con cajitas"

18

mediante máquinas de estados, de una forma visual. La utilización de estos plugins supone un coste añadido.

◦ Dispone de una interfaz de desarrollo muy bien definida e intuitiva que

permite crear rápidamente min-juegos. ◦ Tal como se ha especificado antes es multiplataforma por lo cual permite

la creación de juegos compatibles con distintas consolas (Para la mayoría de las plataformas citadas, se requiere una licencia adicional):

- Microsoft Windows o Mac OS X ejecutable. - Linux. - En la web (a través del plugin Unity Web Player para Internet

Explorer, Firefox, Safari, Mozilla, Netscape, Opera, Google Chrome y Camino) en Windows y OS X.

- En Mac OS X Dashboard widget. - Para Nintendo Wii. - iPhone / iPad. - Google Android. - Google Native Client. - Microsoft Xbox 360. - Adobe Flash. - Sony PlayStation 3. - BlackBerry PlayBook.

• C#

C# es el nuevo lenguaje de propósito general diseñado por Microsoft para su plataforma .NET. Sus principales creadores son Scott Wiltamuth y Anders Hejlsberg, éste último también conocido por haber sido el diseñador del lenguaje Turbo Pascal y la herramienta RAD Delphi.

Aunque es posible escribir código para la plataforma .NET en muchos otros lenguajes, C# es el único que ha sido diseñado específicamente para ser utilizado en ella, por lo que programarla usando C# es mucho más sencillo e intuitivo que hacerlo con cualquiera de los otros lenguajes ya que C# carece de elementos heredados

Figura 2. Marco teorico: C#. Fuente: https://cdn.codementor.io/assets/tut

ors/c-sharp-tutors-online.png

19

innecesarios en .NET. Por esta razón, se suele decir que C# es el lenguaje nativo de .NET.

La sintaxis y estructuración de C# es muy similar a la C++, ya que la intención de Microsoft con C# es facilitar la migración de códigos escritos en estos lenguajes a C# y facilitar su aprendizaje a los desarrolladores habituados a ellos. Sin embargo, su sencillez y el alto nivel de productividad son equiparables a los de Visual Basic. 13

Dentro de las principales características del lenguaje se presentan:

◦ Sencillez: C# elimina muchos elementos que otros lenguajes incluyen y que son innecesarios en .NET.

◦ Modernidad: C# incorpora en el propio lenguaje elementos que a lo largo de los años ha ido demostrándose son muy útiles para el desarrollo de aplicaciones y que en otros lenguajes como Java o C++ hay que simular, como un tipo básico decimal que permita realizar operaciones de alta precisión con reales de 128 bits (muy útil en el mundo financiero), la inclusión de una instrucción foreach que permita recorrer colecciones con facilidad y es ampliable a tipos definidos por el usuario, entre otros.

◦ Orientación a objetos: Como todo lenguaje de programación de

propósito general actual, C# es un lenguaje orientado a objetos, aunque eso es más bien una característica del CTS que de C#. Una diferencia de este enfoque orientado a objetos respecto al de otros lenguajes como C++ es que el de C# es más puro en tanto que no admiten ni funciones ni variables globales, sino que todo el código y datos han de definirse dentro de definiciones de tipos de datos, lo que reduce problemas por conflictos de nombres y facilita la legibilidad del código.

◦ Orientación a componentes: La propia sintaxis de C# incluye

elementos propios del diseño de componentes que otros lenguajes tienen que simular mediante construcciones más o menos complejas. Es decir, la sintaxis de C# permite definir cómodamente propiedades (similares a campos de acceso controlado), eventos (asociación controlada de funciones de respuesta a notificaciones) o atributos (información sobre un tipo o sus miembros).

13 GONZÁLEZ, José. El Lenguaje de Programación C# [en línea]. [citado 02 oct, 2016]Disponible en: José

Antonio González Seco .

20

◦ Gestión automática de memoria: Como ya se comentó, todo lenguaje de .NET tiene a su disposición el recolector de basura del CLR. Esto tiene el efecto en el lenguaje de que no es necesario incluir instrucciones de destrucción de objetos. Sin embargo, dado que la destrucción de los objetos a través del recolector de basura es indeterminista y sólo se realiza cuando éste se active –ya sea por falta de memoria, finalización de la aplicación o solicitud explícita en el fuente-, C# también proporciona un mecanismo de liberación de recursos determinista a través de la instrucción using.

◦ Seguridad de tipos: C# incluye mecanismos que permiten asegurar

que los accesos a tipos de datos siempre se realicen correctamente, lo que permite evita que se produzcan errores difíciles de detectar por acceso a memoria no perteneciente a ningún objeto y es especialmente necesario en un entorno gestionado por un recolector de basura.

◦ Instrucciones seguras: Para evitar errores muy comunes, en C# se

han impuesto una serie de restricciones en el uso de las instrucciones de control más comunes.

◦ Sistema de tipos unificado: A diferencia de C++, en C# todos los tipos

de datos que se definan siempre derivarán, aunque sea de manera implícita, de una clase base común llamada System.Object, por lo que dispondrán de todos los miembros definidos en ésta clase (es decir, serán “objetos”).

◦ Extensibilidad de tipos básicos: C# permite definir, a través de

estructuras, tipos de datos para los que se apliquen las mismas optimizaciones que para los tipos de datos básicos. Es decir, que se puedan almacenar directamente en pila (luego su creación, destrucción y acceso serán más rápidos) y se asignen por valor y no por referencia.

◦ Extensibilidad de operadores: Para facilitar la legibilidad del código y

conseguir que los nuevos tipos de datos básicos que se definan a través de las estructuras estén al mismo nivel que los básicos predefinidos en el lenguaje

◦ Extensibilidad de modificadores: C# ofrece, a través del concepto de

atributos, la posibilidad de añadir a los metadatos del módulo resultante de la compilación de cualquier fuente información adicional a la generada por el compilador que luego podrá ser consultada en tiempo ejecución a través de la librería de reflexión de .NET. Esto, que más bien es una característica propia de la

21

plataforma .NET y no de C#, puede usarse como un mecanismo para definir nuevos modificadores.

◦ Versionable: C# incluye una política de versionado que permite crear

nuevas versiones de tipos sin temor a que la introducción de nuevos miembros provoquen errores difíciles de detectar en tipos hijos previamente desarrollados y ya extendidos con miembros de igual nombre a los recién introducidos.

◦ Eficiente: En principio, en C# todo el código incluye numerosas

restricciones para asegurar su seguridad y no permite el uso de punteros. Sin embargo, y a diferencia de Java, en C# es posible saltarse dichas restricciones manipulando El lenguaje de programación C# a través de punteros.

◦ Compatible: Para facilitar la migración de programadores, C# no sólo

mantiene una sintaxis muy similar a C, C++ o Java que permite incluir directamente en código escrito en C# fragmentos de código escrito en estos lenguajes, sino que el CLR también ofrece, a través de los llamados Platform Invocation Services (PInvoke), la posibilidad de acceder a código nativo escrito como funciones sueltas no orientadas a objetos tales como las DLLs de la API Win32.

• SQLite

SQLite es una librería compacta y autocontenida de código abierto y distribuida bajo dominio público que implementa un gestor de bases de datos SQL embebido, sin

configuración y transaccional.

Los usuarios más conocidos que la utilizan actualmente en sus aplicaciones son: Adobe, Apple, Mozilla, Google, McAfee, Microsoft, Philips, Sun y Toshiba, entre otros.14 Entre las principales características de SQLite se encuentran:

14 PONSADA, Daniel. Introducción a SQLite [en línea]. Alicante, España, 2008, [citado 02 oct, 2016]. Disponible en: https://iessanvicente.com/colaboraciones/sqlite.pdf

Figura 3. Marco teorico: SQLite. Fuente: https://cdn.worldvectorlogo.com/logos/sqlite.svg

22

◦ Compacta: Con todas las características habilitadas, el tamaño de la librería es inferior a 250Kb. Deshabilitando características opcionales, el tamaño puede quedarse por debajo de los 180Kb. Esto la hace muy apropiada para usarla en dispositivos con poca memoria, como teléfonos móviles, PDAs y reproductores MP3.

◦ Autocontenida: Requiere muy poco soporte de librerías externas o del sistema operativo. Esto la hace adecuada para usarla en pequeños dispositivos que no son tan completos como los PC de escritorio.

Está escrita en ANSI-C y debería compilarse fácilmente con cualquier compilador de C estándar. Hace un uso mínimo de las librerías estandar de C. Sólo utiliza siete funciones que son: memset(), memcpy(), memcmp(), strcmp(), malloc(), free() y realloc().

◦ Fichero único. La base de datos se almacena en un único fichero, cuyo formato es multiplataforma (Es posible leer el fichero en sistemas de 32 y 64 bits o en arquitecturas big-endian y little-endian). Estas características hacen que SQLite sea popular para usarlo como formato de archivo de las aplicaciones. O dicho de otra forma: Se puede usar SQLite como sustituto de Oracle o como sustituto de fopen().

◦ Manifiesto de tipado. La mayoría de motores SQL utilizan tipado estático. Cada columna de una tabla se asocia con un tipo de datos, y solo pueden introducirse valores de un tipo particular. SQLite elimina esta restricción, y hace que el tipo de datos pueda ser una propiedad del valor en sí, y no de la columna.

◦ Registros de longitud variable. Muchos otros motores SQL, fijan

una cantidad de espacio para cada todas las filas, de forma que, por ejemplo, si declaramos una columna como varchar(100), el motor reservará 100 bytes de espacio para todas las filas sin tener en cuenta la información que se guarde. SQLite, por el contrario, usa sólo la cantidad de disco que necesita para almacenar la información en una fila.

◦ Seguridad de los datos. Más de dos tercios del código están

dedicados puramente a la prueba y verificación. Una aplicación automatizada ejecuta cientos de miles de pruebas empleando millones de consultas SQL. SQLite responde perfectamente a fallos de reserva de memoria, y errores de E/S de disco.

23

• UML (Lenguaje de Modelado Unificado) UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. 15 Este lenguaje indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo. Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

◦ Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.

◦ Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.

◦ Construir: A partir de los modelos especificados se pueden

construir los sistemas diseñados.

◦ Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es los suficientemente expresivo como para modelar sistemas que no son informáticos, como flujos de trabajo (workflow ) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware.

Un modelo UML está compuesto por tres clases de bloques de contrucción:

15 HERNÁNDEZ, Enrique. El Lenguaje Unificado de Modelado (UML) [en línea]. Universidad Politécnica de Valencia. Valencia, España, 2010, [citado 02 oct, 2016]. Disponible en: http://www.disca.upv.es/enheror/pdf/ActaUML.PDF

Figura 4. Marco teórico: UML. Fuente: http://grssocial.com/wp-

content/uploads/2014/05/UML-logo1.jpg

24

◦ Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.).

◦ Relaciones: relacionan los elementos entre sí.

◦ Diagramas: Son colecciones de elementos con sus relaciones.

1.7.3. MARCO CONCEPTUAL

El marco conceptual se encuentra relacionado a la conceptualización de las temáticas que fundamentan la elaboración del proyecto, tales como:

• Educación

El término «educación» es de uso habitual en la vida cotidiana porque a todos nos afecta de algún modo. Todo el mundo se atrevería a dar una definición de educación. Aunque existen diversas maneras, de concebirla, y más aún de llevarla a cabo, se da como denominador común la idea de perfeccionamiento, vinculada a una visión ideal del hombre y la sociedad. La educación aparece precisamente como posibilitadora de los ideales humanos.16

En sentido amplio, la educación es tan antigua como el hombre. En efecto, desde su aparición, el hombre se preocupó de criar y cuidar a sus hijos hasta que pudieran valerse por sí mismos, y es con este significado que surge el término «educación». En visión actual se le pueden aplicar tres significaciones generales.

1. Hablar de educación supone muchas veces referirse a una institución social: el sistema educativo. Es así como se habla de la educación occidental, de la educación española, de la educación moderna, etc., dándole un contenido histórico-comparativo o socio-político.

2. También se emplea la palabra «educación» para designar el

resultado o producto de una acción. Así se habla de una «buena» o «mala» educación, de una educación adaptada o no a las exigencias de los tiempos, de una educación conservadora o progresista, etc.

3. El tercer significado se refiere al proceso que relaciona de manera

prevista o imprevista a dos o más seres humanos y los pone en situación de intercambio y de influencias recíprocas.

16 SARRAMONA, Jaime. Concepto de Educación [en línea]. CEAC. España, 1889 [citado 02 oct, 2016]. Disponible en: https://www.uv.mx/personal/rdegasperin/files/2011/07/Antologia.Comunicacion-Unidad1.pdf

25

• Educación inclusiva

La educación inclusiva se asocia frecuentemente con la participación de los niños con discapacidad en la escuela común y de otros alumnos etiquetados "con necesidades educativas especiales". Sin embargo, esta acepción estaría más relacionada, según lo expresado anteriormente, con el concepto de integración educativa y no el de inclusión. 17

El concepto de educación inclusiva es más amplio que el de integración y parte de un supuesto distinto, porque está relacionado con la naturaleza misma de la educación regular y de la escuela común. La educación inclusiva implica que todos los niños y niñas de una determinada comunidad aprendan juntos independientemente de sus condiciones personales, sociales o culturales, incluidos aquellos que presentan una discapacidad.

Se trata de un modelo de escuela en la que no existen "requisitos de entrada" ni mecanismos de selección o discriminación de ningún tipo, para hacer realmente efectivos los derechos a la educación, a la igualdad de oportunidades y a la participación.

El proceso de integración educativa ha tenido como preocupación central reconvertir la educación especial para apoyar la educación de los niños integrados a la escuela común, trasladando, en muchos casos, el enfoque individualizado y rehabilitador, propio de la educación especial, al contexto de la escuela regular. Desde esta perspectiva, se hacían ajustes y adaptaciones sólo para los alumnos etiquetados "como especiales" y no para otros alumnos de la escuela.

El enfoque de educación inclusiva, por el contrario, implica modificar substancialmente la estructura, funcionamiento y propuesta pedagógica de las escuelas para dar respuesta a las necesidades educativas de todos y cada uno de los niños y niñas, de forma que todos tengan éxito en su aprendizaje y participen en igualdad de condiciones. En la escuela inclusiva todos los alumnos se benefician de una enseñanza adaptada a sus necesidades y no sólo los que presentan necesidades educativas especiales.

• Discapacidad visual

Es la deficiencia en la estructura o funcionamiento de los órganos visuales, cualquiera que sea la naturaleza o extensión de la misma que causa una limitación, que aún con la mejor corrección, interfiere con el aprendizaje

17 UNICEF, UNESCO, Fundación HINENI. Hacia el Desarrollo de Escuelas Inclusivas. 2000

26

normal o accidental a través de la visión y constituye, por lo tanto, una desventaja educativa.18

Dentro de las capacidades visuales se presentan las siguientes:

◦ Ceguera: El órgano receptor es el ojo cuando algunas de las partes constitutivas de la visión no funcionan adecuadamente e interfiere en la transmisión y percepción de las impresiones luminosas en su viaje al cerebro se produce disminución visual o pérdida súbita.

- Ceguera legal: Se considera ciego o ciega legal cuya persona tiene acuidad visual igual o menor de 20 /200.

La ausencia de percepción de luz no se debe confundir con sensaciones de deslumbramiento que son sensaciones producidas cuando la luminosidad externa es muy exagerada es decir muy fuerte o por destellos luminosos debido a la actividad eléctrica retiniana o cortical. Con fines legales se considera ciego legal al niño, niña, joven, adulto o adulto mayor cuya acuidad visual es igual o menor a 20/200. La OMS establece límites en términos de agudeza o campo visual. La agudeza visual va desde 0 (cero) que es la falta de percepción lumínica hasta un décimo que equivale a la pérdida del 90 % y el campo visual restringido del 20% en el diámetro más amplio. Así es como se define legalmente la ceguera. La agudeza visual es la percepción de los objetos y sus cualidades de lejos y de cerca, expresadas en cifras, que permite tener una connotación objetiva, expresada en forma de quebrado o decimales, el numerador indica la distancia entre la persona evaluada y el objeto denominado opto-tipo, y el denominador la distancia desde el ojo normal que podría identificar el estímulo.

◦ Baja visión: La organización Mundial de la Salud en Bangkok y en

Tailandia propone definiciones desde el criterio funcional expuestas por Ardite y Rosenthal según ellos, la baja visión es una limitación de la capacidad visual que afecta a la persona en la ejecución de algunas actividades o tareas que caen en el campo funcional, funcionamiento que no mejora con corrección refractiva, tampoco

18 DIRECCIÓN PROVINCIAL DE EDUCACIÓN DEL GUAYAS. Discapacidad visual [en línea]. Gran Guayaquil, Ecuador, [citado 02 oct, 2016]. Disponible en: http://www.educar.ec/noticias/visual.pdf

27

con medicación o con cirugía. La baja visión tiene las siguientes manifestaciones que pueden ser una o más en una misma persona:

- Reducción visual menor a 20 sobre 60 en el mejor ojo y con la mejor corrección.

- Campo visual reducido, menos de 20 grados en el meridiano más ancho del ojo, con el campo visual central intacto o menos intacto.

- Reducción de la sensibilidad al contraste en el mejor ojo y en condiciones de luminosidad y distancias habituales.

La clasificación de Baja visión que nos permite trabajar en educación es la siguiente:

- Baja Visión Severa: Las personas afectadas perciben la luz necesitan aprender Braille para leer y escribir.

- Baja Visión Moderada: Las personas afectadas son capaces de distinguir objetos grandes y medianos en movimiento, sin discriminar detalles especiales y o del color. Pueden aprender a leer y escribir en tinta y también Braille.

- Baja Visión Leve: Las personas afectadas tienen la capacidad

de percibir objetos pequeños, dibujos y símbolos.

• Educación para personas con discapacidad visual Los alumnos con discapacidad visual (sin otra discapacidad) logran integrarse al aula regular y realizar la mayoría de las actividades junto con el resto de sus compañeros del grupo, siempre y cuando se le ofrezcan apoyos específicos. 19 Los apoyos abarcan materiales específicos, personas y estrategias metodológicas y de intervención que el docente ofrece a los alumnos con discapacidad visual para que alcancen los objetivos propuestos en el grupo en el que se encuentran integrados. Varían en función del tipo de discapacidad visual (ceguera o baja visión) y el grado de visión del alumno (si ve sombras, luces, sólo por una parte de su campo visual). Incluyen el sistema Braille para aprender a leer y escribir o la escritura

19 CONAFE. Discapacidad Visual: Guía Didáctica para la Inclusión en Educación Inicial y Básica [en línea].

México, 2010, [citado 02 oct, 2016]. Disponible en: http://www.educacionespecial.sep.gob.mx/2016/pdf/discapacidad/Documentos/Atencion_educativa/Visual/1discapacidad_visual.pdf

28

de letras comunes, pero más grandes o con marcadores más gruesos. Al jugar en el patio y correr con amigos, tal vez el niño con discapacidad visual requiera lentes oscuros, viseras o la guía de alguna persona o hacer esta actividad en algún momento específico del día de acuerdo con la cantidad de iluminación que necesite. Los niños con discapacidad visual suelen ser más pasivos que el resto de sus compañeros, porque sienten inseguridad al caminar o desplazarse de un lugar a otro. Para disminuir la inseguridad, conviene que en la escuela y la familia se motive y anime al niño a realizar las actividades y asumir responsabilidades similares a las del resto de sus compañeros; en este sentido, es importante adecuar los espacios, para que sean seguros, y hacer un trabajo previo con el alumno para que reconozca el área y el espacio donde se moverá. Se recomienda ofrecerle algunas referencias táctiles y visuales que le ayuden a orientarse en los espacios, por ejemplo: colocar un listón en el respaldo de la silla, o un botón en su lugar de mesa de trabajo, orientarlo para que reconozca en qué parte del baño se encuentra el lavabo o pegar un gran círculo verde en la puerta del salón.

- Educación para estudiantes de primaria con discapacidades visuales: Los alumnos con discapacidad visual pueden efectuar la mayoría de las actividades propuestas para el nivel de primaria. Requieren sólo algunos apoyos específicos. Al igual que el resto de sus compañeros, tienen ya nociones acerca del mundo y experiencias previas que serán útiles para construir nuevos conocimientos. Algunas veces se mueven y relacionan con sus compañeros sin ningún problema, y otras veces han sido más protegidos por sus padres y entonces sus experiencias se basan en las actividades en casa. En este último caso precisan más motivación y confianza del instructor y el resto del grupo, para que él y sus padres se den cuenta de lo que son capaces de hacer y aprender.

• Matemáticas para estudiantes de primaria con discapacidades

visuales

No hay ninguna diferencia en el aprendizaje de las matemáticas entre el niño ciego o con baja visión y el niño con visión normal. Sin embargo, conviene seguir varias recomendaciones relacionadas con la forma en

29

que el niño con discapacidad visual construye imágenes mentales y conceptos20:

1. Retoma los conocimientos previos del niño y plantéale situaciones significativas para él.

2. Presentación de objetos concretos que pueda tocar, manipular y

conocer con claridad.

3. Para el aprendizaje de la geometría, el niño debe contar con un esquema corporal muy bien identificado, y tener interiorizada la lateralidad (izquierda y derecha) y conceptos Discapacidad visual. Guía didáctica para la inclusión en educación inicial y básica 47 espaciales (arriba, abajo y dentro fuera), así como destreza y habilidad para tomar objetos y manipularlos.

4. El alumno requerirá más indicaciones verbales y tal vez explorar

los objetos con más detenimiento, a través de la vista o el tacto, por lo que podría utilizar más tiempo que el resto de sus compañeros. El ábaco es muy útil para que los alumnos con discapacidad visual a partir del nivel III de primaria comunitaria y el resto del grupo realicen cálculos. El Anexo 3 describe el uso del ábaco.

• Software educativo ◦ Diseño tradicional de software educativo

El diseño de software educativo o de software escolar, La tarea de diseñar software educativo luego de ser analizada desde varios puntos de vista21:

- Desde la perspectiva metodológica son herramientas y técnicas

para diseñar software (diseño orientado a objetos, diseño

estructurado, diseño top-down, etc.)

20 CONAFE. Discapacidad Visual: Guía Didáctica para la Inclusión en Educación Inicial y Básica [en línea].

México, 2010, [citado 02 oct, 2016]. Disponible en: http://www.educacionespecial.sep.gob.mx/2016/pdf/discapacidad/Documentos/Atencion_educativa/Visual/1discapacidad_visual.pdf 21 HINOSTROZA, Enrique. MELLAR, Harvey y REHBEIN, Lucio. Diseño De Software Educativo O De Software Escolar [en línea]. Universidad de los Andes. Bogotá, Colombia, 1997, [citado 02 oct, 2016]. Disponible en: http://www.colombiaaprende.edu.co/html/mediateca/1607/articles-112508_archivo.pdf

30

- Desde la perspectiva de diseño de los componentes de software

(interfaz humano computador, contenidos, funcionalidad, etc.).

- Desde la perspectiva de las intenciones del autor del software,

esto es, mirando el producto completo tal como fue concebido.

◦ Clasificación del software educativo:

- Por tema: “Esencialmente este sistema provee una clasificación

de software basado en las áreas Curriculares escolares. No es

un buen sistema de clasificación cuando se discute sobre

principios de informática educativa, pero es útil si sólo se desea

describir áreas específicas enseñadas en las escuelas.”

- Por tipo de software: Con las siguientes categorías:

Computador como tutor: Para funcionar como un tutor en un área

temática específica, el computador debe ser programado para ser

profesor del usuario.

Computador como herramienta: El computador debe tener software

genérico, como procesadores de texto, planillas de cálculo, de base

de datos, etc.

Computador como aprendiz: El computador provee un ambiente en

el cual el usuario puede expresar sus propias ideas y soluciones a

problemas.

- Por paradigma educacional: Esta clasificación incluye cuatro

paradigmas:

De Instrucciones: por ejemplo, software de ensayo y

error, asociado a una perspectiva conductista.

Revelatorio: por ejemplo, simulaciones, asociado a un

aprendizaje por descubrimiento o experimentación.

Conjetural: por ejemplo, programación, asociado a la

aplicación de constructivismo y otras visiones cognitivas

de uso y desarrollo de software.

Emancipatorio: por ejemplo, procesadores de texto,

asociado a reducir la carga de trabajo, sin incurrir en el

consumo de tiempo del procesamiento de datos.

31

- Por uso: está basada en los dominios relevantes o áreas de

aprendizaje que los profesores planean que los niños exploren:

Imágenes, Sonidos, Texto, Cuentos, Hechos, Consecuencias y

figuras. Esas áreas enfatizan la naturaleza integrada del

aprendizaje de los niños.

- Por impulsos de aprender: Propuesta por Bruce en su

publicación interna en 1996, donde entrega una tipificación

exhaustiva de géneros de recursos educativos (incluyendo

software). Usa las maneras en que apoyan el aprendizaje

integrado, basado en preguntas como código de clasificación.

Define cuatro categorías amplias: pregunta, comunicación,

construcción y expresión.

• TIC en la educación de personas discapacidad visual El uso de las tecnologías digitales permite a las personas con discapacidad visual un mayor acceso a la información, autonomía en la comunicación e independencia en el manejo de materiales y propuestas de estudio, brindando estas condiciones una mejor calidad de vida. 22 Pueden distinguirse dos ejes primordiales para que una propuesta educativa con incorporación de TIC permita a los alumnos apropiarse de los recursos digitales alcanzando su máximo potencial:

- Por un lado, las ayudas tecnológicas, es decir el desarrollo de programas específicos para el acceso a las TIC y su relación con el diseño de materiales accesibles.

- Por otro lado, las estrategias pedagógicas que mediante el uso de estos recursos específicos sumados a otros de uso estándar, orientan la incorporación de TIC en la escuela; facilitando no sólo el acceso a los contenidos curriculares y el aprendizaje, sino el logro de una autonomía tal que promueva la inclusión de los alumnos en las distintas trayectorias educativas a lo largo de su vida académica.

22 ZAPPALÁ, Daniel, KÖPPEL, Andrea & SUCHODOLSKI, Miriram. Inclusión de TIC en escuelas para alumnos con discapacidad visual [en línea]. Buenos Aires, Argentina, 2011, [citado 02 oct, 2016]. Disponible en: http://escritorioeducacionespecial.educ.ar/datos/recursos/pdf/m-visuales-1-48.pdf

32

En lo que se refiere al manejo de las tecnologías digitales, pueden distinguirse dos grandes grupos entre las personas con discapacidad visual:

1. Las personas con baja visión, que pueden trabajar con la pantalla y el mouse pero que requieren configuraciones específicas, programas de ampliación y/o que los elementos de la pantalla estén en un tamaño, color y contraste adecuados a sus posibilidades.

2. Las personas que presentan ceguera total o parcial, quienes no podrían manejar los programas interactuando con el mouse y la pantalla.

1.7.4. MARCO INSTITUCIONAL

Con el objetivo de conocer el contexto institucional del Colegio OEA I.E.D se define:

• Presentación del establecimiento ◦ Datos generales

Nombre Colegio OEA I.E.D – Sede A

Dirección carrera 72 L # 34 – 19 sur Bogotá D.C.

Teléfono 4527015/ 4527016/ 5630829

URL http://colegiooea.edu.co/

Contacto cedoea8@redp.edu.co

Tabla 3. Marco Institucional: Presentación del establecimiento

33

◦ Organigrama

Figura 5. Marco institucional: Organigrama.

34

1.7.5. DIAGRAMAS DE PROCESOS

A continuación, se presenta el diagrama general de los procesos realizados por parte del software educativo, así como los diagramas específicos de cada uno de éstos procesos y la correspondiente descripción de cada uno de ellos.

1.7.5.1. DIAGRAMAS DE PROCESOS

El proceso del software educativo ha sido dividido en tres tipos de procesos de negocio, enfocados al uso del software educativo para el apoyo al aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria del programa de tiflología «MatematiCAT».

El primer tipo de proceso de negocio es el de “Procesos Estratégicos”; en este grupo se encuentra el software educativo al cada uno de los demás tipos de procesos dan soporte.

El segundo tipo de proceso de negocio es el de “Procesos Misionales”; en este grupo se encuentran los procesos principales que se enfocan específicamente en los nodos de navegación de la plataforma web. De este modo se obtienen dos procesos del tipo misional: Nodo Navegación Docentes y Nodo Navegación Estudiantes.

Finalmente se presenta el tipo de negocio de “Procesos de Apoyo” cuya función principal es el registro y administración de la información suministrada en los procesos del tipo misional.

Figura 6. Diagrama de procesos software educativo

35

1.7.5.2. DIAGRAMAS DE PROCESO: [M1] NODO NAVEGACIÓN DOCENTES

Figura 7. Diagrama Procesos: [M1] Nodo navegación docentes.

Dentro de los procesos del tipo misional para el Software Educativo MatematiCat, es el más importante ya que de éste depende el comportamiento de los demás procesos misionales dentro de la solución.

El proceso del “Nodo navegación docentes” inicia cuando ocurre el evento “Solicitud ingreso al sistema” por parte del “Docente” y culmina con una notificación de acceso y permisividad para la libre navegación en el sistema, el proceso será el insumo para el proceso misional “Nodo navegación estudiantes”.

Se encuentra compuesto por los subprocesos [M1.1] “Gestión Información Cuenta”, [M1.2] “Gestión Información Estudiante” y [M1.3] “Gestión Información Discapacidad”, subprocesos en los cuales el docente (administrador) podrá gestionar la información asociada a su cuenta, a los estudiantes y a los tipos de discapacidades.

36

1.7.5.3. DIAGRAMAS DE PROCESO: [M2] NODO NAVEGACIÓN ESTUDIANTES

Figura 8. Diagrama procesos: [M2] Nodo navegación estudiantes

Dentro de los procesos del tipo misional para el Software Educativo MatematiCat, es el proceso principal requerido por parte de los usuarios.

El proceso del “Nodo navegación estudiantes” inicia cuando ocurre el evento “Solicitud ingreso al sistema” por parte del “Estudiante” y culmina con una notificación de acceso y libre navegación en el sistema”.

Se encuentra compuesto por los subprocesos: [M2.1] “Ingresar Juego Educativo”, en el cual el estudiante podrá acceder y hacer uso del juego educativo; y [M2.2] “Gestión configuración juego”, en el cual el estudiante podrá configurar el juego según sus preferencias y capacidades.

37

1.7.5.4. DIAGRAMAS DE PROCESO: [A1] ADMINISTRACIÓN DEL SOFTWARE

Figura 9. Diagrama procesos: [A1] Administración del software

Es el proceso principal del tipo de apoyo del Software educativo, es el encargado de apoyar la gestión de la información manejada por parte del software, ya sea de los usuarios, las discapacidades o la navegación en el juego.

Este proceso está dividido en dos sub procesos: [A1.1] Alta y actualización de información y [A1.2] Baja Información: los cuales permiten llevar a cabo el gestionamiento de la información anteriormente especificada.

38

1.8. METODOLOGÍA

La metodología Open Up es “un proceso modelo y extensible, dirigido a la gestión y desarrollo de proyectos de software basados en un desarrollo iterativo, ágil e incremental apropiado para pequeños proyectos y de bajo recursos, es aplicable a un amplio conjunto de plataformas y aplicaciones de desarrollo”23. Basado en lo anterior, Open Up es la metodología apropiada para el desarrollo de este proyecto, ya que aunque su objetivo principal es incluir solo el contenido fundamental y necesario, es una metodología completa en el sentido en que presenta por completo el proceso de construir un sistema, además es una metodología extensible, lo que permite añadir o adaptar contenido de otro proceso que pueda ser necesario

La metodología Open Up tiene como principios:

• Colaborar para sincronizar intereses y compartir conocimiento: Este principio promueve prácticas que impulsan un ambiente de equipo saludable, que facilitan la colaboración y además desarrollan un conocimiento compartido del proyecto. Gracias al manejo de este principio se obtendrá el adecuado ambiente de trabajo para los desarrolladores de este proyecto, permitiendo así colaborar en pro del adecuado desarrollo del software.

• Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados del proyecto: Este principio promueve prácticas que permiten a los participantes del proyecto desarrollar una solución que maximice los beneficios obtenidos por los participantes. El manejo de este principio permite realizar la priorización del cumplimiento de los requisitos y objetivos del proyecto con la finalidad de suministrar al usuario (estudiantes de tiflología) una herramienta que apoye su proceso de aprendizaje de las operaciones básicas matemáticas.

• Centrarse en la arquitectura de forma temprana para minimizar el riesgo y

organizar el desarrollo: Este principio permite establecer las pautas necesarias para la adecuada planificación del proyecto y de tal manera evitar riesgos y fallos a futuro.

• Desarrollo evolutivo para obtener retroalimentación y mejoramiento

continuo: Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los participantes del proyecto. La implementación de este principio promueve la comunicación entre los desarrolladores de este proyecto, lo que

23 OLGUIN, Efraín. Metodología Open Up [En línea]. Baja California, México, sep. 2013. [citado 13 octubre 2016].

Disponible en: http://openupeaojmp.blogspot.com.co/2013/09/metodologia-open-up.html

39

permitirá conocer a tiempo los avances correspondientes al avance y desarrollo del proyecto.

Un proyecto realizado siguiendo la metodología Open Up se divide en cuatro fases:

1. Fase inicial (definición inicial, planeación). 2. Fase de elaboración (análisis, definición de la estructura y diseño). 3. Fase de construcción (implementación). 4. Fase de transición (fin del proyecto y puesta en producción).

Figura 10 . Metodología Open Up. Fuente: https://es.wikipedia.org/wiki/OpenUP#/media/File:Ciclo_de_Vida_OpenUP.png

En casa fase se ejecutarán varias iteraciones, y dentro de cada una de ellas se seguirá un modelo de cascada orientado al manejo de las actividades de cada una de las fases, las iteraciones en cada una de las fases se encargarán de:

• Fase inicial: Las primeras iteraciones se enfocan en comprender las necesidades de cada uno de los participantes del proyecto con la finalidad de ser tomadas en cuenta en la definición de los objetivos, por lo que las iteraciones presentes en esta fase hacen un mayor énfasis en actividades relacionadas con la definición y planificación del proyecto.

En esta fase se realizará un estudio del proyecto a realizar y su factibilidad, teniendo en cuenta todos los aspectos que afectan el desarrollo del mismo, logrando así identificar si su realización en viable o no; por lo tanto, se definirá para el proyecto el ámbito, los limites, los casos de uso críticos y además se realizará el entendimiento de los costos, cronograma, alcances y limitaciones del proyecto.

40

• Fase de elaboración: Las iteraciones de esta fase se orientan a la realización de tareas para el análisis del dominio y la definición de la arquitectura del sistema. Se debe elaborar un plan de proyecto, estableciendo unos requisitos y arquitectura estables. En esta fase se realizará el levantamiento de requerimientos, el modelamiento del negocio, en este caso la institución educativa, lo anterior con el objetivo de determinar los procesos internos relacionados al aprendizaje de los niños. Se realizará la definición de la baseline de la arquitectura, el análisis, diseño y una parte de la implementación orientada a la base de la arquitectura del programa. Sumado a lo anterior se tendrá una definición clara y precisa de los casos de uso y los actores y además se tendrá un prototipo ejecutable que definirá la arquitectura del software; la arquitectura contendrá el proceso de logueo a la aplicación y el de gestionamiento de la información de la base de datos.

• Fase de construcción: Las iteraciones de esta fase se orientan al manejo de los componentes y funcionalidades del sistema que falten por implementar sean realizados, probados e integrados. En esta fase se realizará el desarrollo de los juegos educativos, con la finalidad de complementar la arquitectura base establecida y generar un aplicativo completo, que cumpla con los objetivos del proyecto. Para todo el proceso de desarrollo se tendrán en cuenta los casos de uso, con la finalidad de realizar adecuadamente cada uno de los procesos establecidos. Al finalizar el proceso de desarrollo se realizarán las pruebas pertinentes con la finalidad de refinar y corregir posibles fallos.

• Fase de transición: Las iteraciones de esta última fase tienen como propósito asegurar que el sistema sea entregado a los usuarios y que además se realice la correspondiente evaluación de la funcionalidad del ultimo entregable de la fase de construcción. En esta fase se realizará la implementación del software en la institución, se realizarán pruebas pertinentes para evaluar el adecuado funcionamiento del software tanto en el equipo final de instalación como del uso del mismo, además se realizará la capacitación de usuario final, en este caso el docente encargado de implementar el software al proceso de enseñanza. Finalmente se realizará un testeo a los usuarios con la finalidad de determinar si se alcanzaron las expectativas y objetivos establecidos, es caso de que se realice una solicitud por la mayoría de los usuarios se realizará su implementación, la respectiva prueba y la entrega final.

41

1.8.1. Cronograma

• Cronograma (Fechas)

Figura 11. Metodología: Cronograma 1.

42

• Cronograma (Diagrama)

Figura 12. Metodología: Cronograma 2.

43

1.9. FACTIBILIDAD

1.9.1. FACTIBILIDAD TÉCNICA

Para la realización de este proyecto la Institución Educativa Distrital O.E.A, garantiza los recursos tecnológicos necesarios para el correcto funcionamiento del software educativo brindando los equipos y herramientas necesarias para la implementación del mismo en la institución.

◦ Equipo 1 de desarrollo de software

DESCRIPCIÓN REFERENCIA

Modelo MS-7309

Procesador AMD Athlon 64 x2 Dual Core Processor 5000+ 2.61 GHz

Memoria 4,00 GB

Disco Duro 78,0 GB para programas 386 GB para datos

Teclado, Mouse Si

Sistema Operativo Windows 7 Ultimate

Tabla 4. Factibilidad técnica: Equipo 1 de desarrollo.

◦ Equipo 2 de desarrollo de software

DESCRIPCIÓN REFERENCIA

Modelo PCSMART 9

Procesador AMD Athlon(tm) II X3 425 Processor 2.70 Ghz

Memoria 2,00 GB

Disco duro 73,0 GB para programas 76,0 GB para datos

Teclado, Mouse Si

Sistema Operativo Windows 7 Ultimate

Tabla 5. Factibilidad técnica: Equipo 2 de desarrollo

44

◦ Equipo de prueba e instalación final del software

DESCRIPCIÓN REFERENCIA

Modelo PCS GOB61 SED

Procesador Intel Core i3-3220 CPU 3.30 GHz

Memoria 4,00 GB

Teclado, Mouse Si

Sistema Operativo Windows Professional

Tabla 6. Factibilidad técnica: Equipo instalación final del software

◦ Recursos de software

DESCRIPCIÓN REFERENCIA

Análisis y diseño Metodología Open Up

Programa de desarrollo

Unity 5.0.1

Base de Datos SQLite

Sistema Operativo Windows 7 Ultimate

Tabla 7. Factibilidad técnica: Recursos de software.

1.9.2. FACTIBILIDAD OPERATIVA

El software educativo será diseñado y desarrollado por: Laura Alejandra Domínguez Babosa y Andrés David Rozo Chiquiza, estudiantes de la facultad tecnológica de la Universidad Distrital Francisco José de Caldas, quienes con la elaboración de este proyecto optan por el título de: Tecnólogos en Sistematización de Datos.

Se cuenta con el apoyo técnico del ingeniero Norberto Novoa Torres, docente de la facultad tecnológica de la UDFJC.

1.9.3. FACTIBILIDAD LEGAL

Garantizando la legalidad del software se implementan para el desarrollo del mismo software libre, además la licencia del sistema operativo del equipo de instalación final es suministrada por la institución educativa.

45

Los textos usados como referencia han sido tomados de documentos free en internet a quienes se certifica en las referencias del presente documento.

Además, el proyecto el proyecto se llevará a cabo conforme con el decreto 460 de 1995, en el que se reglamenta el Registro Nacional del Derecho de Autor y se regula el Depósito Legal.

1.9.4. FACTIBILIDAD ECONÓMICA

La factibilidad económica está asociada al manejo financiero tanto de los recursos humanos como de los recursos técnicos necesarios para el desarrollo del software. A continuación, mediante el uso de tablas se definirá la factibilidad económica relacionada a los recursos anteriormente nombrados, así como una breve descripción de los mismos.

◦ RECURSOS HUMANOS

Los recursos humanos constarán de las tutorías por parte del tutor necesarias para la definición y planeación del software, así como el personal de desarrollo de la aplicación.

◦ RECURSOS TÉCNICOS

Los recursos técnicos están atribuidos a los equipos necesarios para el desarrollo del software, así como el equipo de implementación e instalación final.

Tipo Descripción Valor Hora Cantidad Total

Tutor Hora trabajo tutor

$35.000 15 $525.000

Desarrolladores Hora trabajo desarrollador

$15.000 500 $7.500.000

Total recursos humanos $8.025.000

Tabla 8. Factibilidad económica: Recursos humanos. Fuente: Autor

Tipo Descripción Valor Unitario Cantidad Total

Computador Equipos para el desarrollo e implementa-ción del software.

$1.200.000 3 $3.600.000

Total recursos técnicos $3.600.000

Tabla 9. Factibilidad económica: Recursos técnicos.

46

◦ COSTO TOTAL

El costo total comprende los recursos humanos, los recursos técnicos, otros costos asociados a la papelería y el acceso a internet, así como el valor de costos imprevistos a lo largo del desarrollo del proyecto.

Recurso Valor

Total recursos humanos $8.025.000

Total recursos técnicos $3.600.000

Total otros recursos $300.000

Costo total $11.925.000

Tabla 10. Factibilidad económica: Costo total. Fuente: Autor

47

2. FASE DE ELABORACIÓN

2.1. ANÁLISIS PARA LA ELABORACIÓN

El estudio y análisis permite la definición de la base de desarrollo del software, suministrando así el plan de trabajo y los lineamientos para la ejecución de la fase de construcción. El análisis se encuentra relacionado en su mayoría con la fundamentación en cuanto al campo educativo asociado al proyecto, por lo que se plantea el análisis de los siguientes aspectos:

2.1.1. CARACTERÍSTICAS DE LA POBLACIÓN OBJETIVO

El presente software educativo está estimado para que sus usuarios sean los estudiantes de los grados tercero (3°), cuarto (4°) y quinto (5°) de primaria, cuyas edades están comprendidas entre los 9 y 11 años, y que además presentan discapacidades visuales tales como invidencia o baja visión; por lo que a estos usuarios estarán dirigidos los temas o materiales pedagógicos con los que cuenta el proyecto.

El software no solo está pensado para estudiantes con discapacidades visuales, así que los estudiantes que no presenten algún tipo de limitación visual podrán hacer uso del software sin generarse ninguna problemática.

2.1.2. PROBLEMA O NECESIDAD A ATENDER

La problemática a atender está orientada al suministro de una herramienta tecnológica que permita apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria de la institución, quienes presenten algún tipo de discapacidad visual. (La definición de la problemática, se abarca ampliamente en la sección 1.3.1: Descripción del problema, de este documento).

Así que la definición de la formulación de la problemática a resolver es:

¿Cómo apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes de primaria que presentan discapacidades visuales y que se encuentran en su proceso de formación académica en el colegio OEA I.E.D?

48

2.1.3. JUSTIFICACIÓN DE USO DE LOS MEDIOS INTERACTIVOS

2.1.3.1. Justificación

La principal virtud del proyecto es el aprovechamiento de las herramientas tecnológicas predispuestas por la institución para el uso de los estudiantes, permitiéndose así la inclusión de las TIC en los procesos de enseñanza orientados a los niños de tiflología; asegurándose de ésta manera, el acercamiento entre los estudiantes que presentan algún tipo de discapacidad visual y el uso de herramientas tecnológicas con la finalidad de incentivar el aprovechamiento de sus capacidades y promover la mejora de la calidad educativa.

2.1.3.2. Procedimiento

Para poner en marcha el desarrollo pedagógico del proyecto, se cuenta con la asesoría de los docentes de la institución educativa, tanto del programa de tiflología, como del área de las matemáticas, ésto con la finalidad de identificar los diferentes factores educativos que pueden ser incluidos en el software durante su desarrollo.

Además, se define un grupo específico de estudiantes desde el inicio del desarrollo del proyecto, con la finalidad de presentar un proceso secuencial de cada una de las actividades asociadas a la elaboración del proyecto, tales como el levantamiento de requerimientos, la definición de temáticas y modelos abarcados, la realización de pruebas, entre otros.

2.1.3.3. Validez

El hecho de realizar una investigación permite evidenciar con mayor claridad el entorno en el cual se piensa ubicar el producto final, la labor que debe cumplir el software en dicho entorno y la abstracción de los puntos de interés e ideas que sean útiles para el diseño del sistema y de este modo garantizar el cumplimento de los objetivos planteados inicialmente.

La validez se ve evidenciada a lo largo del proceso de desarrollo, inicialmente en la actitud suministrada por parte de los estudiantes en referencia a la presentación inicial del proyecto a los mismos, ya que se

49

afirmó el interés tanto de los estudiantes como de los docentes frente al desarrollo del software, y se espera que esta actitud prevalezca a lo largo del proceso de desarrollo y de entrega final, teniendo en cuenta que se motivará al estudiante mediante el suministro de una herramienta innovadora y que además permitirá realizar un cambio en cuanto a la rutina académica.

Teniendo en cuenta la aceptación por parte de los estudiantes de los cursos entre tercero a quinto, es preciso decir, adecuando algunos nuevos temas y funcionalidades el proyecto podría aplicar satisfactoriamente a otros escenarios pedagógicos y temáticos a ser implementados.

2.1.4. PRINCIPIOS PEDAGÓGICOS Y DIDÁCTICOS APLICABLES

◦ Técnicas e instrumentos de investigación

Procedimientos Técnicas Instrumentos

Comportamiento del niño durante una clase de matemáticas

Observación directa de los participantes

Diario de campo

Cuestionarios Observación sistemática (entrevistas a los estudiantes)

Cuestionarios, encuestas, dialogo abierto

Tabla 11. Fase elaboración: Técnicas e instrumentos de investigación.

◦ Resumen resultado de la investigación

Actor Debilidades detectadas

Mejoras conseguidas

Proyecciones

Estudiante

Los niños de esta edad experimentan curiosidad por conocer el mundo, y por lo mismo en ocasiones dan prioridad a otro tipo de actividades diferentes a las académicas

Los estudiantes tienen ahora una herramienta que hará su método de aprendizaje más ameno, atractivo y recreativo.

Con el tiempo puede desarrollarse un proyecto pedagógico en el que los estudiantes se sientan atraídos por el aprendizaje de las matemáticas

50

Docente

El docente tiene conocimientos sobre la pedagogía infantil, sin embargo, en ocasiones la actitud de los estudiantes frente a la materia dificulta el proceso de enseñanza.

En la actualidad los docentes implementan la elaboración de actividades lúdicas, recreativas e interactivas para que los estudiantes tengan una mejor aceptación en relación a la clase y sus temáticas.

Con el tiempo las herramientas virtuales suministraran al docente un apoyo para la elaboración de clases innovadoras y atrayentes para los estudiantes.

Tabla 12. Fase elaboración: Resumen resultado de la investigación.

◦ Técnicas e instrumentos para el diseño

Procedimientos Técnicas Instrumentos

Indagación sobre los temas pedagógicos

Revisión teórica

Uso de internet Textos guías Consulta a los docentes

Construcción del micro proyecto pedagógico

Observación sistemática

Etapa del proyecto Exploración Planeación Ejecución

Evaluación y retroalimentación

Auto evaluación de progresos en el proyecto

Revisión de objetivos Revisión requerimientos

Tabla 13. Fase elaboración: Técnicas e instrumentos para el diseño.

◦ Conclusiones

El juego educativo presentará el manejo de las operaciones básicas matemáticas (suma, resta, multiplicación y división), ya que son éstas las manejadas por los estudiantes de los cursos de terco a quinto.

El juego buscará apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes, orientado al aprovechamiento de sus capacidades e incentivando la mejora continua mediante el uso de la competitividad y la superación en referencia al juego.

51

2.2. DEFINICIÓN DEL DISEÑO

2.2.1. EDUCATIVO

El diseño educativo está relacionado con la definición de las competencias manejadas por parte del estudiante, las acciones mediante las cuales se evalúan estas competencias y el diseño asignado al MEC según el manejo de las mismas.

• Diseño de competencias

Para la definición de las competencias debe tenerse en cuenta que el software será un recurso para apoyar el proceso de aprendizaje del estudiante, por lo que la principal competencia del estudiante debe ser aplicar los conceptos que tiene sobre la temática.

Diseño de competencias: Fase I

Programa Básica primaria: 3°, 4° y 5°

Núcleo temático principal

Área de matemáticas: Operaciones básicas

Competencia Aplicación de los conocimientos previamente obtenidos en el proceso de aprendizaje de las operaciones básicas

Propósito de la competencia

El estudiante debe

◦ Aplicar los conocimientos previamente adquiridos.

◦ Fortalecer los conocimientos de la

temática.

◦ Interactuar con las tecnologías de la información y la comunicación.

Tabla 14. Definición del diseño educativo: Definición de competencias, fase I.

52

Diseño de competencias: Fase II

Conocimiento a utilizar ◦ Solución de operaciones básicas

(suma, resta, multiplicación y división).

Habilidades relacionadas

◦ Interpretar ◦ Analizar ◦ Aplicar ◦ Conocer ◦ Argumentar

Habilidades que busca el desarrollador

◦ Interpretación de las operaciones mediante el uso del sonido.

◦ Reforzamiento del conocimiento previamente adquirido.

◦ Acercamiento con las TIC como recurso para la aplicación del aprendizaje.

Tabla 15. Definición del diseño educativo: Definición de competencias, fase II.

• Acciones mediante las cuales se evalúa

La evaluación está asociada a la interpretación y aplicación de los conocimientos que el estudiante tiene, por lo que se verá reflejado en el tiempo de respuesta de acuerdo al nivel de complejidad de la operación.

De tipo interpretativo Argumentativo

[I1] Interpreta la operación básica indicada por el juego.

[I2] Fortalece sus debilidades en el área específica tras ser evaluado.

[A1] Identifica la respuesta acertada a la operación.

[A2] Aplica los conocimientos previamente obtenidos para dar solución a la operación.

Tabla 16. Diseño educativo: Acciones mediante las cuales se evalúa.

53

• Diseño del MEC

Contenido temático asociado

Actividades en el proceso de apoyo del aprendizaje

Ítem de la competencia relacionado

Escena Videojuego educativo

Presentación enunciado operación

[I1]

Ingreso de la respuesta mediante el uso del teclado

[I1] [A1] [A2]

Presentación del puntaje [I2]

Retroalimentación y repetición de la actividad

[I2]

Tabla 17. Diseño educativo: Diseño del MEC.

2.2.2. COMUNICACIONAL

2.2.2.1. HERRAMIENTAS

Para el desarrollo de las interfaces se implementará el uso de Unity 3D (la cual fue previamente descrita en la sección 1.7.2), ya que ésta contiene una serie de herramientas que están orientadas a la creación de este tipo de software.

Para el desarrollo de las interfaces y el diseño comunicacional se implementó el uso del editor de Unity 3D, el cual permite interactuar de una manera directa con los objetos predeterminados del Unity, así que se facilita el uso y la manipulación de los mismos, al ofrecer una interfaz dinámica y de fácil acceso para el usuario.

2.2.2.2. INTERFACES

• Interfaz número uno: Presentación

◦ Objetivo: Presentar a manera introductoria la aplicación.

◦ Descripción: Sirve como introducción al sistema, presentando a Tobías, el instructor del software quien se encargará de hacer el rol de guía en cuanto al manejo del aplicativo; además hace

54

la presentación formal del software y su nombre «matematiCAT».

◦ Vista

Figura 13. Vista interfaz 1: Presentación.

◦ Componentes

La interfaz da la bienvenida al software educativo, mediante la presentación de Tobías, una imagen que tiene asociada una animación, por lo que la interfaz se compone de tres imágenes, la del fondo, la de la mascota del juego y la del logo del juego.

55

• Interfaz número dos: Inicio Sesión

◦ Objetivo: Permitir el ingreso al sistema por parte de un usuario

registrado.

◦ Descripción: Contiene los campos de la información necesaria para el acceso de un usuario previamente registrado en el sistema.

◦ Vista

Figura 14. Vista interfaz 2: Iniciar Sesión.

◦ Componentes La interfaz de inicio de sesión muestra al usuario los campos para el ingreso de la información necesaria para efectuar el inicio de sesión, por lo que cuenta con componentes como text, inputfields y botones.

56

• Interfaz número tres: Menú principal administrador (docente)

◦ Objetivo: Permitir al usuario ingresar a las diferentes opciones suministradas por el sistema.

◦ Descripción: Contiene los botones que permiten acceder a las

demás interfaces del software orientadas al uso del rol «Administrador»

◦ Vista

Figura 15. Vista interfaz 3: Menú principal administrador.

◦ Componentes

La interfaz del menú principal para el administrador, permite al mismo acceder a los diferentes submenús suministrados por el sistema, mediante el uso de botones.

57

• Interfaz número cuatro: Consulta información estudiantes

◦ Objetivo: Permitir al administrador consultar y gestionar la información del estudiante.

◦ Descripción: Contiene las tablas y botones relacionados al

gestionamiento de la información de los estudiantes que se encuentren registrados en la base de datos.

◦ Vista

Figura 16. Vista interfaz 4: Consulta información estudiantes.

◦ Componentes

La interfaz muestra el resultado de la información previamente consultada al realizarse la petición del registro de un estudiante, esto lo hace mediante el uso de un table, y además ofrece más funcionalidades según sea requerido gracias a la presencia de botones.

58

• Interfaz número cinco: Consulta información estudiantes

◦ Objetivo: Permite al administrador consultar la información detallada de un determinado estudiante.

◦ Descripción: Contiene la tabla asociada a la información

detallada (avance en el juego) de determinado estudiante.

◦ Vista

Figura 17. Vista interfaz 5: Ver información detallada del estudiante.

• Componentes

La interfaz permite al administrador conocer la información detallada de un estudiante previamente seleccionado mediante el uso de de texts y un table.

59

• Interfaz número seis: Actualizar información estudiante

◦ Objetivo: Permite actualizar la información de un determinado estudiante.

◦ Descripción: Contiene los campos de para ingresar la

información que desea ser modificada de un estudiante en específico.

◦ Vista

Figura 18. Vista interfaz 6: Actualizar información estudiante.

◦ Componentes

La interfaz permite al administrador realizar la actualización de la información del estudiante previamente seleccionado, esto lo hace mediante el uso de text informativos, inputfields para el ingreso de la información y un combo box.

60

• Interfaz número siete: Eliminación Estudiante

◦ Objetivo: Permitir al administrador confirmar si desea o no eliminar el estudiante seleccionado.

◦ Descripción: Imprime por pantalla un mensaje de confirmación

previo a la selección de un registro a eliminar.

◦ Vista

Figura 19. Vista interfaz 7: Eliminación estudiante.

◦ Componentes La interfaz imprime en pantalla un mensaje para la confirmación de la eliminación de un estudiante previamente seleccionado, por lo que hace uso de text y botontes.

61

• Interfaz número ocho: Consulta condiciones visuales

◦ Objetivo: Permitir al administrador consultar la información asociada a las condiciones visuales registradas en la base de datos.

◦ Descripción: Imprime en la pantalla la información de la

condición visual seleccionada por el usuario.

◦ Vista

Figura 20. Vista Interfaz 8: Consultar Información Tipo Condición

◦ Componentes

La interfaz le permite al administrador conocer los tipos de discapacidades que se encuentran registrados en el sistema a través de la interfaz y mediante el uso de un table, texts y botones que además permiten seleccionar funcionalidades a realizar en referencia a la información de los tipos de condiciones.

62

• Interfaz número nueve: Registro nueva condición visual

◦ Objetivo: Permitir al administrador registrar un nuevo tipo de

condición visual

◦ Descripción: Habilita en la pantalla los campos de texto requeridos para el ingreso de la información de la actualización.

◦ Vista

Figura 21. Vista Interfaz 10: Registro Tipo Condición.

◦ Componentes Se maneja la impresión de los resultados en un apartado de la interfaz de la consulta de la condición visual; así que presenta text, inputfileds, un toggle y un botón para la inserción de la información.

63

• Interfaz número diez: Actualización información condición visual

◦ Objetivo: Permitir al administrador consultar la información asociada a las condiciones visuales registradas en la base de datos.

◦ Descripción: Imprime en la pantalla la información de la

condición visual seleccionada por el usuario.

◦ Vista

Figura 22. Vista Interfaz 10: Actualizar condición visual.

◦ Componentes Se maneja la impresión de los resultados en un apartado de la interfaz de la consulta de la condición visual; así que presenta text, inputfileds, un toggle y un botón para la inserción de la información y el registro de la actualización.

64

• Interfaz número once: Eliminación condición visual

◦ Objetivo: Permitir al administrador la eliminación de las

condiciones visuales registradas en la base de datos.

◦ Descripción: Imprime en la pantalla un mensaje de confirmación de la eliminación de la condición visual seleccionada, y en caso de estar relacionado con el registro de uno estudiante no se podrá efectuar la eliminación.

◦ Vista:

Figura 23. Vista interfaz 11: Eliminación condición visual.

◦ Componentes Se maneja la impresión de los resultados en un apartado de la interfaz de la consulta de la condición visual; así que presenta text y botones.

65

• Interfaz número doce: Gestión información de la cuenta

◦ Objetivo: Permitir al administrador gestionar la información de

su cuenta.

◦ Descripción: Suministra los campos necesarios para la actualización de la cuenta del administrador.

◦ Vista:

Figura 24. Vista interfaz 12: Gestión información cuenta.

◦ Componentes

La interfaz permite gestionar la información asociada a la cuenta del administrador por lo que suministra inputfields para el ingreso de la nueva información y botones para efectuar las diferentes funcionalidades suministradas por el sistema; además hace uso de textfields para los títulos y subtitulos.

66

• Interfaz número trece: Gestión información de la cuenta

◦ Objetivo: Da a conocer al usuario los créditos asociados al

proceso de desarrollo del proyecto.

◦ Descripción: Presenta la interfaz asociada a los créditos de los aspectos relacionados al desarrollo del proyecto, como los desarrolladores, el arte visual, el sonido, entro otros aspectos

◦ Vista:

Figura 25. Vista Interfaz 13: Créditos.

◦ Componentes La interfaz está compuesta por textos que presentan los aspectos relacionados a los créditos así como la presentación de imágenes relacionadas con los mismos.

67

• Interfaz número catorce: Menú principal estudiantes

◦ Objetivo: Presenta al estudiante el acceso al eje principal del

software, el juego educativo.

◦ Descripción: Presenta al estudiante el recurso para acceder al juego educativo.

◦ Vista:

Figura 26. Interfaz 14. Menú principal estudiantes invidentes.

◦ Competencias:

El menú principal presentará cuatro opciones diferentes a los estudiantes, por lo que cuenta con cuatro botones que redireccionán a las interfaces asociadas a cada función, además cuenta con una imagen de la mascota del juego.

68

• Interfaz número quince: Menú tipo de juego

◦ Objetivo: Presenta al estudiante las opciones de juego disponibles.

◦ Descripción: Permite al estudiante seleccionar entre 5

modalidades diferentes de juego (suma, resta, multiplicación, división o la unión de todas).

◦ Vista:

Figura 27. Vista interfaz 15: Menú tipo de juego.

◦ Competencias:

Está compuesta cinco botones principales, los cuales están asociados a los diferentes tipos de juegos, además tiene una imagen que hace referencia a la mascota del juego.

69

• Interfaz número dieciséis: Tutorial (Teclas)

◦ Objetivo: Permite al estudiante conocer la funcionalidad de las teclas en el juego.

◦ Descripción: Permite al estudiante conocer la función que tiene

cada una de las teclas en el juego, para de tal manera garantizar la buena navegabilidad en el sistema y el buen uso de los recursos del mismo.

◦ Vista

Figura 28. Interfaz 16: Selección tipo de juego.

◦ Componentes Está compuesta por un botón que contiene un text, el cual, de acuerdo a la tecla seleccionada, imprimirá su valor en la pantalla y procederá a dar la descripción respectiva; también hace uso de un text para el título y una imagen para la mascota del juego.

70

• Interfaz número diecisiete: Configuración del juego

(estudiantes sin discapacidades visuales)

◦ Objetivo: Permite al estudiante configurar algunas variables relacionadas con el juego.

◦ Descripción: El estudiante podrá configurar algunas variables relacionadas con el juego, como la velocidad, los colores y el tamaño de la fuente (dependiendo del rol que el estudiante presente dentro del sistema).

◦ Vista:

Figura 29. Vista interfaz 17: Menú de configuración del juego.

◦ Componentes La interfaz se encuentra dividida por diversas secciones orientadas a un tipo de configuración diferente, como por ejemplo los colores, la velocidad de las operaciones, el tamaño de la fuente, entre otras, para esto hace uso de text y scrollbars.

71

• Interfaz número dieciocho: Interfaz del juego educativo

◦ Objetivo: Permite al estudiante apoyar su proceso de aprendizaje de las operaciones matemáticas mediante el uso de un juego educativo.

◦ Descripción: El juego está orientado al aprovechamiento de las

capacidades del estudiante al implementar el manejo de contrastes, el uso de sonidos y el manejo del tamaño de la fuente orientado a los estudiantes con baja visión.

◦ Vista

Figura 30. Interfaz 18: Juego educativo. Fuente: Autor.

◦ Componentes Está compuesto por dos paneles, el panel principal es aquel en el que las operaciones van apareciendo con la finalidad de esperar la respuesta correctar del estudiante; el segundo panel está relacionado con las vidas que tiene el estudiante y la impresión del puntaje asociado al avance del estudiante en el juego que se encuentra desarrollando en el momento. Por lo que está compuesto por los dos paneles, texts y un botón.

72

• Interfaz número diecinueve: Interfaz de la pérdida del juego

◦ Objetivo: Permite al estudiante conocer el puntaje final obtenido.

◦ Descripción: El estudiante tendrá 4 vidas, las cuales al perderse generaran la interacción con la interfaz de la perdida del juego, en la que se presenta al estudiante el puntaje final obtenido.

◦ Vista:

Figura 31. Vista Interfaz 19: Pérdida del juego. Fuente: Autor

◦ Componentes: Está compuesto por los text que indican el puntaje final del estudiante y el botón que le permite retornar al menú principal para el inicio de un nuevo juego.

73

2.2.3. COMPUTACIONAL

Computacionalmente se espera que el software brinde las siguientes funcionalidades:

• Contenga un contenido que pedagógicamente permita apoyar el proceso de aprendizaje de las operaciones básicas matemáticas.

• Brinde una interfaz que maneje el uso de contrastes, con la finalidad de orientarse al aprovechamiento de las capacidades de los estudiantes con discapacidades visuales.

• Permita a los docentes conocer el progreso de los estudiantes

mediante consultas de la base de datos.

• Sirva como un recurso tanto para docentes como para estudiantes, que permita apoyar el proceso de aprendizaje de los estudiantes.

• Pueda ser utilizado tanto por estudiantes con discapacidades visuales

como por estudiantes que no tengan ningún tipo de limitación visual.

2.3. DEFINICIÓN DE REQUERIMIENTOS

2.3.1. REQUERIMIENTOS FUNCIONALES

En la Tabla 29 se presentan los requerimientos funcionales del sistema, los cuales fueron concertados con la asesora externa del proyecto (Melba García, tiflóloga del colegio OEA I.E.D):

Código Requerimiento RE-01

Nombre Ingresar al software

Descripción El software debe solicitar un usuario y una contraseña para permitir el ingreso a la aplicación y sus diferentes funcionalidades

Código Requerimiento RE-02

Nombre Gestionar cuenta

Descripción El software permite al administrador (docente) la modificación de los usuarios y contraseñas tanto del usuario administrador, como de los estudiantes previamente registrador.

74

Código Requerimiento RE-03

Nombre Registrar estudiante

Descripción

El software debe permitir al administrador el registro de un estudiante, mediante la solicitud de información como los datos personales y el tipo de discapacidad.

Código Requerimiento RE-04 Nombre Modificar estudiante

Descripción El software debe permitir al administrador la modificación de la información del estudiante previamente registrado.

Código Requerimiento RE-05

Nombre Eliminar estudiante

Descripción El software debe permitir al administrador la eliminación del estudiante previamente registrado.

Código Requerimiento RE-06

Nombre Consultar información estudiante

Descripción

El software debe permitir al administrador la consulta de la información del estudiante, tanto de los datos asociados a la cuenta, como la información de los avances del mismo en el juego.

Código Requerimiento RE-07 Nombre Registrar tipo de condición

Descripción

El software debe permitir al administrador el registro de un tipo de condición, mediante la solicitud de información como el nombre, la descripción y si se presenta discapacidad visual o no.

Código Requerimiento RE-08

Nombre Modificar tipo de condición

Descripción El software debe permitir al administrador la modificación de un tipo de condición previamente registrado.

Código Requerimiento RE-09

Nombre Eliminar tipo de condición

Descripción El software debe permitir al administrador la eliminación de un tipo de condición previamente registrado.

75

Código Requerimiento RE-10

Nombre Consultar tipo de condición

Descripción El software debe permitir al administrador la consulta de la información asociada a un tipo de condición previamente registrado.

Código Requerimiento RE-11

Nombre Modificar configuraciones

Descripción

El software debe permitir a los usuarios modificar las configuraciones asociadas a su rol, algunas de estas modificaciones están asociadas al sonido, manejo de colores, entre otras.

Código Requerimiento RE-12

Nombre Consulta tutorial del juego

Descripción El software debe permitir a los estudiantes consultar el tutorial asociado al manejo del juego.

Código Requerimiento RE-13

Nombre Seleccionar tipo de juego

Descripción

El software debe permitir a los estudiantes consultar el tipo de juego (está asociado a la operación: suma, resta, multiplicación, división o todas).

Código Requerimiento RE-14

Nombre Iniciar juego

Descripción El software debe permitir al estudiante iniciar y el juego, previo al proceso de la selección del nivel.

Código Requerimiento RE-15

Nombre Consultar créditos

Descripción El software debe permitir al usuario consultar los créditos asociados al desarrollo del proyecto.

Código Requerimiento RE-16

Nombre Cerrar sesión

Descripción El software debe permitir al usuario el cierre de la sesión iniciada.

Tabla 18. Requerimientos funcionales.

76

2.3.2. REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales están asociados a los requerimientos del diseño del sistema, como las interfaces de software y hardware, entre otros.

• Apariencia (Interfaz Usuario)

La interfaz del software debe estar asociada a las capacidades de los estudiantes, por lo que se debe realizar el manejo de sonidos, contrastes y propiedades de la fuente.

• Disposición y requerimientos de navegación (Interfaz Usuario) Es importante que el software este diseñado de forma que facilite su manejo, aprendizaje y navegación, implementando el uso del sonido y el manejo del teclado numérico y las teclas de dirección.

• Interfaces de hardware El software se debe instalar en un equipo con las siguientes especificaciones como mínimo:

◦ Teclado, pantalla y altavoces.

◦ 1 GB de memoria ram.

◦ 200 MB de espacio disponible en disco.

◦ Procesador de 32 o 64 bits.

◦ Tarjeta de video.

77

2.4. DEFINICIÓN DE ACTORES Y CASOS DE USO

2.4.1. ACTORES

A continuación, se describen los actores que interactúan con el software y lo que cada uno de éstos puede realizar en el sistema.

Actor Rol que desempeña Funcional

Administrador (Docente)

El administrador (docente) accederá al software con la finalidad de administrar el gestionamiento de la información, tanto de los estudiantes como del administrador y además podrá hacer las consultas a la base de datos relacionadas con el avance del estudiante.

◦ Ingresar al software ◦ Gestionar cuenta ◦ Registrar estudiante ◦ Modificar estudiante ◦ Eliminar estudiante ◦ Consultar información

estudiante ◦ Registrar tipo de

condición ◦ Modificar tipo de

condición ◦ Eliminar tipo de

condición ◦ Consultar tipo de

condición. ◦ Consultar créditos ◦ Cerrar sesión

Estudiante

(Con discapacidad o sin discapacidad

visual)

El estudiante accederá al software con la finalidad de hacer uso del juego educativo.

◦ Consultar tutorial del juego

◦ Iniciar juego ◦ Modificar

configuraciones (asociadas al tipo de usuario)

◦ Cerrar sesión

Tabla 19. Fase elaboración: Definición casos de uso.

78

2.4.2. DIAGRAMA DE ACTORES

Figura 32. Diagrama de casos de uso: Actores

2.4.3. CASOS DE USO

A continuación, se especifican los casos de uso asociados al software:

• Iniciar sesión. • Registrar estudiante. • Modificar estudiante. • Consultar información estudiante.

◦ «extend» Consultar información general estudiante. ◦ «extend» Consultar detalles del estudiante.

• Eliminar estudiante. • Registrar tipo de condición. • Modificar tipo de condición. • Consultar tipo de visión. • Eliminar tipo de visión. • Gestionar cuenta. • Ver créditos. • Iniciar juego. • Ingresar respuestas. • Modificar opciones. • Ver tutorial. • Cerrar sesión.

79

2.4.4. DOCUMENTACIÓN CASOS DE USO

• Caso 01: Iniciar sesión

IDENTIFICACION CASO DE USO ACTORES

CU-01 Iniciar sesión Administrador, Estudiante

OBJETIVO

Permitir el logueo del usuario en el software.

DESCRIPCION

El caso de uso permite el ingreso del usuario (administrador, estudiante) al

software mediante el suministro de la información correspondiente (usuario y

contraseña).

Precondiciones • El usuario debe abrir el programa desde el computador.

Post-condiciones • El usuario ingresa correctamente al software.

Alternativas y

excepciones

• El usuario suministra datos incorrectos para el logueo.

• El usuario no se encuentra registrado en la base de datos.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El usuario solicita la petición de ingreso al software.

3. El usuario ingresa la información solicitada.

4. El usuario envía la petición al sistema para poderse logear.

6. El usuario ingresa de forma exitosa al sistema y puede navegar en él.

2. El sistema solicita el ingreso de la información necesaria para el logueo (usuario y contraseña).

5. El sistema verifica la información suministrada exitosamente.

PUNTOS DE INTERRUPCION

◦ El usuario puede cancelar la operación en el punto 3. ◦ El sistema no puede validar la información suministrada por lo que el

sistema solicita el nuevo ingreso de la misma, redirección al punto 3. Tabla 20. Documentación casos de uso: Caso 1- Login usuario. Fuente: Autor

80

• Caso de uso 02: Registro estudiante

IDENTIFICACION CASO DE USO ACTORES

CU-02 Registrar estudiante Administrador

OBJETIVO

Registrar la información asociada a un estudiante.

DESCRIPCION

El caso de uso permite registrar cada uno de los datos relacionados a un estudiante del colegio.

Precondiciones

• El administrador debe estar logueado en el sistema.

• Debe conocerse la información necesaria del estudiante.

Post-condiciones • El administrador registra de forma exitosa el estudiante.

Alternativas y excepciones

• Los datos del registro están incompletos.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza una petición a la interfaz de registro del estudiante.

3. El administrador ingresa la información del estudiante.

4. El administrador envía la petición de registro del estudiante.

2. El sistema re direcciona al administrador a la interfaz del registro.

5. El sistema registra de forma exitosa el estudiante.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 3. ◦ Alguno de los datos ingresados en el punto 3 son incorrectos, redirección

a punto 3. ◦ El estudiante ya se ha registrado previamente, redirección al punto 3.

Tabla 21. Documentación casos de uso: Caso 2 - Registrar estudiante.

81

• Caso uso 03: Modificar estudiante

IDENTIFICACION CASO DE USO ACTORES

CU-03 Modificar estudiante Administrador

OBJETIVO

Actualizar o modificar la información respectiva del estudiante

DESCRIPCION

El caso de uso permite modificar o actualizar la información de un estudiante.

Precondiciones

• El administrador debe estar logueado en el sistema.

• El administrador debe estar en la interfaz de gestionamiento de información del estudiante.

• El estudiante debió ser previamente registrado en el sistema.

Post-condiciones • El administrador modifica de forma exitosa la información del estudiante

Alternativas y

excepciones • Los datos del registro ingresados están

incompletos.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona del listado disponible el estudiante al cual desea modificar su información.

4. El administrador ingresa la nueva información del estudiante.

5. El administrador envía la petición de modificación del estudiante.

2. El sistema redirecciona al administrador a la interfaz de actualización de la información del estudiante.

3. El sistema despliega los campos para la modificación del estudiante.

6. El sistema obtiene los datos del estudiante.

7. El sistema modifica exitosamente los nuevos datos del estudiante.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 1 y 4. ◦ La información suministrada en el punto 4 es incorrecta, el sistema

redirecciona a 4. Tabla 22. Documentación casos de uso: Caso 3 - Modificar estudiante.

82

• Caso de uso 04: Consultar información estudiante

IDENTIFICACION CASO DE USO ACTORES

CU-04 Consultar estudiante Administrador

OBJETIVO

Consultar la información asociada a un estudiante.

DESCRIPCION

El caso de uso permite realizar la consulta sobre la información de un artículo

en el sistema. (dos tipos de consulta)

Precondiciones • El administrador debe estar logueado en el

sistema. • El administrador debe estar en el menú principal.

Post-condiciones • El administrador consulta de forma exitosa la información del estudiante.

Alternativas y

excepciones • No se encuentra ningún estudiante registrado en

el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza la solicitud para efectuar la consulta de los estudiantes registrados en el sistema (haciendo uso del botón dispuesto en el menú principal).

2. El sistema re direcciona al administrador a la interfaz del gestionamiento de la información del estudiante.

3. El sistema despliega una tabla con la información general de los estudiantes que se encuentran registrados en el sistema .

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 1.

Tabla 23. Documentación casos de uso: Caso 4 – Consultar información del estudiante.

83

• Caso de uso 05: Consulta detalles estudiante

IDENTIFICACION CASO DE USO ACTORES

CU-05 Consultar información

detallada estudiante. Administrador

OBJETIVO

Consultar los detalles de la información asociada a un estudiante.

DESCRIPCION

El caso de uso permite al administrador consultar la información detallada de

determinado estudiante (avance en el juego).

Precondiciones

• El administrador debe estar logueado en el sistema. • El administrador debe estar en la interfaz de

gestionamiento de información del estudiante. • El estudiante debe estar registrado en el sistema.

Post-condiciones • El administrador consulta satisfactoriamente la información del estudiante especificado.

Alternativas y

excepciones • El administrador no está logueado en el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona de la lista desplegada el estudiante de quien desea ver los detalles.

2. El administrador realiza la solicitud de consulta al sistema.

3. El sistema despliega una tabla con la información detallada del estudiante (información asociada al avance del estudiante).

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar el proceso en el punto 1.

Tabla 24. Documentación casos de uso: Caso 5 – Consultar información detallada estudiante.

84

• Caso uso 06: Eliminar estudiante

IDENTIFICACION CASO DE USO ACTORES

CU-07 Eliminar estudiante Administrador

OBJETIVO

Eliminar el registro asociado a un determinado estudiante.

DESCRIPCION

El caso de uso permite eliminar el registro de un determinado estudiante en el

sistema.

Precondiciones

• El estudiante debe estar previamente registrado en el sistema.

• El administrador debe estar en la interfaz de gestión de la información del estudiante.

Post-condiciones • El administrador elimina de forma exitosa el registro de algún estudiante.

Alternativas y

excepciones • El administrador no está logueado en el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona de la lista desplegada el estudiante que desea eliminar.

2. El administrador envía la petición de eliminación del estudiante seleccionado.

4. El administrador confirma la eliminación

3. El sistema despliega una ventana para confirmar la eliminación del estudiante.

5. El sistema elimina de forma exitosa la información del estudiante.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 1 y 4.

Tabla 25. Documentación casos de uso: Caso 6 – Eliminar estudiante.

85

• Caso de uso 07: Registro tipo condición

IDENTIFICACION CASO DE USO ACTORES

CU-07 Registrar tipo condición Administrador

OBJETIVO

Registrar la información asociada a un nuevo tipo de condición.

DESCRIPCION

El caso de uso permite registrar la información de los datos asociados a un

tipo de condición (en cuanto a las discapacidades presentes) .

Precondiciones

• El administrador debe estar logueado en el sistema.

• El administrador debe estar en el menú principal. • Debe conocerse la información necesaria del tipo

de condición.

Post-condiciones • El administrador registra de forma exitosa el tipo de visión.

Alternativas y

excepciones • Los datos del registro están incompletos.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza una petición a la interfaz de registro de tipo de condición.

3. El administrador ingresa la información del tipo de condición.

4. El administrador envía la petición de registro del tipo de condición.

2. El sistema re direcciona al administrador a la interfaz en la que podrá registrar la información del tipo de condición.

5. El sistema registra de forma exitosa el tipo de condición.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 3. ◦ Alguno de los datos ingresados en el punto 3 son incorrectos, redirección

a punto 3. ◦ El tipo de condición ya se ha registrado previamente, redirección al punto

3. Tabla 26. Documentación casos de uso: Caso 7 - Registrar tipo condición.

86

• Caso uso 08: Modificar tipo condición

IDENTIFICACION CASO DE USO ACTORES

CU-09 Modificar tipo condición Administrador

OBJETIVO

Actualizar o modificar la información respectiva del tipo de condición

DESCRIPCION

El caso de uso permite modificar o actualizar la información de un tipo de

condición específico.

Precondiciones

• El administrador debe estar logueado en el sistema.

• El tipo de condición debió ser previamente registrado en el sistema.

Post-condiciones • El administrador modifica de forma exitosa la información del tipo de condición.

Alternativas y

excepciones • El tipo de condición no se encuentra registrado

en el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona del listado disponible el tipo de condición que desea modificar.

2. El administrador realiza una petición a la interfaz de modificación de información del tipo de condición.

5. El administrador ingresa la información del estudiante.

6. El administrador envía la petición de modificación del estudiante.

3. El sistema re direcciona al administrador a la interfaz de actualización de la información del tipo de condición.

4. El sistema despliega los campos para la modificación del estudiante.

7. El sistema obtiene los datos del estudiante.

8. El sistema modifica exitosamente los nuevos datos del estudiante.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 5.

Tabla 27. Documentación casos de uso: Caso 8 - Modificar tipo condición.

87

• Caso uso 09: Consultar tipo de condición

IDENTIFICACION CASO DE USO ACTORES

CU-09 Consultar tipo de

condición Administrador

OBJETIVO

Consultar la información asociada a un tipo de condición.

DESCRIPCION

El caso de uso permite realizar consultas sobre la información de algún

determinado tipo de condición en el sistema.

Precondiciones

• El administrador debe estar previamente registrado en el sistema.

• El administrador debe estar en la interfaz de gestionamiento de la información del tipo de condición.

Post-condiciones • El administrador consulta de forma exitosa la información de algún tipo de condición.

Alternativas y

excepciones • No existe ningún tipo de condición registrado en

el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza la solicitud para efectuar la consulta de los tipos de condiciones registrados en el sistema (haciendo uso del botón dispuesto en el menú principal).

2. El sistema re direcciona al administrador a la interfaz del gestionamiento de la información del tipo de condición.

3. El sistema despliega una tabla con la información general de los tipos de condiciones que se encuentran registrados en el sistema .

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 1.

Tabla 28. Documentación casos de uso: Caso 09 – Consultar tipo condición.

88

• Caso de uso 10: Consulta detalles tipo condición

IDENTIFICACION CASO DE USO ACTORES

CU-10 Consultar información

detallada tipo de condición. Administrador

OBJETIVO

Consultar los detalles de la información asociada a un tipo de condición.

DESCRIPCION

El caso de uso permite al administrador consultar la información detallada de

determinado tipo de condición.

Precondiciones

• El administrador debe estar logueado en el sistema. • El administrador debe estar en la interfaz de

gestionamiento de información del tipo de condición. • El tipo de condición debe estar registrado en el

sistema.

Post-condiciones • El administrador consulta satisfactoriamente la información del tipo de condición especificado.

Alternativas y

excepciones • El administrador no está logueado en el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona de la lista desplegada el tipo de condición del cual desea ver los detalles.

2. El administrador realiza la solicitud de consulta al sistema.

3. El sistema despliega una tabla con la información detallada del tipo de condición.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar el proceso en el punto 1.

Tabla 29. Documentación casos de uso: Caso 10 – Consulta detalles tipo condición.

89

• Caso uso 11: Eliminar tipo de condición

IDENTIFICACION CASO DE USO ACTORES

CU-11 Eliminar tipo condición Administrador

OBJETIVO

Eliminar el registro asociado a un determinado tipo de condición.

DESCRIPCION

El caso de uso permite eliminar el registro de un determinado tipo de condición

en el sistema.

Precondiciones

• El tipo de condición debe estar previamente registrado en el sistema.

• El administrador debe estar en la interfaz de gestión de la información del tipo de condición.

Post-condiciones • El administrador elimina de forma exitosa el registro de algún tipo de condición.

Alternativas y

excepciones • El tipo de condición no se encuentra registrado en

el sistema.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador selecciona el tipo de condición que desea eliminar.

2. El administrador envía la petición de eliminación del tipo de condición.

3. El sistema elimina de forma exitosa la información del tipo de condición.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 1. ◦ El sistema no puede realizar la eliminación del registro en el punto 3, ya

que el tipo de condición se encuentra asociado a un estudiante. Tabla 30. Documentación casos de uso: Caso 11 – Eliminar tipo condición.

90

• Caso de uso 12: Gestión cuenta

IDENTIFICACION CASO DE USO ACTORES

CU-12 Gestionar cuenta Administrador

OBJETIVO

Actualizar o modificar la información asociada a la cuenta del administrador

DESCRIPCION

El caso de uso permite modificar o actualizar la información de la cuenta del

administrador (usuario y contraseña)

Precondiciones • El administrador debe estar logueado en el sistema..

Post-condiciones • El administrador modifica de forma exitosa la información de la cuenta.

Alternativas y excepciones

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza una petición a la interfaz de gestión de la cuenta.

4. El administrador ingresa la nueva información de la cuenta.

5. El administrador envía la solicitud de modificación de la cuenta.

2. El sistema redirecciona al administrador a la interfaz de la gestión de la cuenta.

3. El sistema despliega los campos para la modificación de la cuenta.

6. El sistema obtiene los datos de la cuenta.

7. El sistema modifica exitosamente los nuevos datos de la cuenta.

PUNTOS DE INTERRUPCION

◦ El administrador puede cancelar la operación en el punto 4.

Tabla 31. Documentación casos de uso: Caso 12 – Gestión Cuenta.

91

• Caso de uso 13: Ver créditos

IDENTIFICACION CASO DE USO ACTORES

CU-13 Ver créditos Administrador

OBJETIVO

Ver los créditos relacionados al desarrollo del software.

DESCRIPCION

El caso de uso permite visualizar los créditos relacionados al desarrollo del

software.

Precondiciones • El administrador debe estar logueado en el sistema.

Post-condiciones • El administrador visualiza de manera exitosa los créditos.

Alternativas y excepciones

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza una petición a la interfaz de créditos.

2. El sistema redirecciona al administrador a la interfaz.

3. El sistema despliega la información de los créditos.

PUNTOS DE INTERRUPCION

◦ El estudiante puede cancelar la operación en el punto 1.

Tabla 32. Documentación casos de uso: Caso 13 – Ver créditos.

92

• Caso de uso 14: Iniciar juego

IDENTIFICACION CASO DE USO ACTORES

CU-14 Iniciar juego Estudiante

OBJETIVO

Iniciar un nuevo juego en la aplicación.

DESCRIPCION

El caso de uso permite al estudiante iniciar de acuerdo al tipo de juego que

desee (jugar con las sumas, restas, multiplicaciones, divisiones).

Precondiciones • El estudiante debe estar logueado en el sistema.

Post-condiciones • Estudiante inicia el juego de forma exitosa.

Alternativas y excepciones

• Estudiante cancela el proceso

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El estudiante realiza una petición a la interfaz jugar.

3. El estudiante selecciona el tipo de juego.

2. El sistema redirecciona al estudiante a la interfaz de selección del tipo de juego.

4. El sistema redirecciona a la interfaz del juego.

PUNTOS DE INTERRUPCION

◦ El estudiante puede cancelar la operación en el punto 1.

Tabla 33. Documentación casos de uso: Caso 14 - Iniciar juego.

93

• Caso de uso 15: Responder juego

IDENTIFICACION CASO DE USO ACTORES

CU-15 Ingresar respuesta Estudiante

OBJETIVO

Ingresar la respuesta de las operaciones del juego educativo.

DESCRIPCION

El caso de uso permite al estudiante responder las operaciones relacionadas

con el juego educativo.

Precondiciones • El estudiante debe estar logueado en el

sistema. • El estudiante debe estar jugando.

Post-condiciones • Estudiante responde a las operaciones..

Alternativas y excepciones

• Estudiante cancela el proceso.

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

2. El estudiante ingresa la respuesta a la operación. 3. El estudiante hace la solicitud de respuesta al sistema.

1. El sistema despliega las operaciones matemáticas relacionadas con el juego.

4. El sistema acepta la respuesta, consulta si está correcto.

PUNTOS DE INTERRUPCION

◦ El estudiante puede pausar el juego. ◦ Si el resultado suministrado en 3 es correcto, redirecciona a 1. ◦ Si el resultado suministrado en 3 es incorrecto, redirecciona a 2.

Tabla 34. Documentación casos de uso: Caso 15 - Responder el juego.

94

• Caso de uso 16: Modificar configuraciones

IDENTIFICACION CASO DE USO ACTORES

CU-16 Modificar configuraciones Estudiante

OBJETIVO

Modificar las configuraciones permitidas por el software.

DESCRIPCION

El caso de uso permite al estudiante modificar las configuraciones permitidas

al software (las cuales están orientadas al tipo de discapacidad que presente

el estudiante).

Precondiciones • El estudiante debe estar logueado en el sistema.

Post-condiciones • El estudiante modifica las configuraciones exitosamente.

Alternativas y excepciones

• El estudiante cancela el proceso

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El estudiante realiza una petición a la interfaz de opciones.

3. El usuario modifica las configuraciones que desee.

2. El sistema redirecciona al usuario a la interfaz de opciones.

3. El sistema registra las nuevas configuraciones.

PUNTOS DE INTERRUPCION

◦ El estudiante puede cancelar la operación en el punto 3.

Tabla 35. Documentación casos de uso: Caso 16 - Modificar configuraciones.

95

• Caso de uso 17: Ver tutorial

IDENTIFICACION CASO DE USO ACTORES

CU-17 Ver tutorial Estudiante

OBJETIVO

Ver el tutorial relacionado al juego el software.

DESCRIPCION

El caso de uso permite visualizar el tutorial relacionado al manejo del juego del

software.

Precondiciones • El estudiante debe estar logueado en el sistema.

Post-condiciones • El estudiante visualiza el tutorial de manera exitosa.

Alternativas y excepciones

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El administrador realiza una petición a la interfaz del tutorial.

2. El sistema redirecciona al administrador a la interfaz.

3. El sistema despliega la información del tutorial.

PUNTOS DE INTERRUPCION

◦ El estudiante puede cancelar la operación en el punto 3.

Tabla 36. Documentación casos de uso: Caso 17 – Ver tutorial. Fuente: Autor.

96

• Caso de uso 18: Cerrar sesión

IDENTIFICACION CASO DE USO ACTORES

CU-18 Cerrar sesión Administrador, Estudiante

OBJETIVO

Realizar el cierre de sesión.

DESCRIPCION

El caso de uso permite al usuario cerrar la sesión que se encuentre abierta en

el software.

Precondiciones • El usuario debe estar logueado en el sistema.

Post-condiciones • El usuario cierra sesión de manera exitosa.

Alternativas y excepciones

CURSO NORMAL DE LOS EVENTOS

Acción del actor Respuesta del sistema

1. El usuario realiza la petición del cierre de sesión.

2. El sistema realiza el cierre de sesión.

3. El sistema redirecciona a la interfaz de logueo.

PUNTOS DE INTERRUPCION

Tabla 37. Documentación casos de uso: Caso 18 – Cerrar sesión.

97

2.4.5. DIAGRAMA DE CASOS DE USO

Figura 33. Diagrama de casos de uso.

98

2.5. DIAGRAMAS DE SECUENCIA

• Diagrama secuencia: Registrar Estudiante

Figura 34. Diagramas de Secuencia: Registrar Estudiante.

99

• Diagrama secuencia: Modificar Estudiante

Figura 35. Diagramas de secuencia: Modificar Estudiante.

100

• Diagrama secuencia: Consultar Estudiante

Figura 36. Diagramas de Secuencia: Consultar Estudiante.

101

• Diagrama secuencia: Consultar Detalles Estudiante

Figura 37. Diagramas de Secuencia: Consultar Detalles Estudiante.

102

• Diagrama secuencia: Eliminar Estudiante

Figura 38. Diagramas de Secuencia: Eliminar Estudiante.

103

• Diagrama secuencia: Registrar Tipo de Condición

Figura 39. Diagramas de Secuencia: Registrar Tipo Condición.

104

• Diagrama secuencia: Modificar Tipo de Condición

Figura 40. Diagramas de Secuencia: Modificar Tipo Condición.

105

• Diagrama secuencia: Consultar Tipo de Condición

Figura 41. Diagramas de Secuencia: Consultar Tipo Condición.

106

• Diagrama secuencia: Consultar Detalle Tipo de Condición

Figura 42. Diagramas de Secuencia: Consultar Detalle Tipo Condición.

107

• Diagrama secuencia: Eliminar Tipo de Condición

Figura 43. Diagramas de Secuencia: Eliminar Tipo Condición

108

• Diagrama secuencia: Gestionar cuenta

Figura 44. Diagramas de Secuencia: Gestionar Cuenta.

109

• Diagrama secuencia: Ver Créditos

Figura 45. Diagramas de Secuencia: Ver Créditos

110

• Diagrama secuencia: Iniciar Sesión

Figura 46. Diagramas de Secuencia: Iniciar Sesión.

111

• Diagrama secuencia: Cerrar Sesión

Figura 47. Diagramas de Secuencia: Cerrar Sesión.

112

• Diagrama secuencia: Modificar Configuraciones

Figura 48. Diagramas de Secuencia: Modificar Configuraciones.

113

• Diagrama secuencia: Iniciar Juego

Figura 49. Diagramas de Secuencia: Iniciar Juego.

114

• Diagrama secuencia: Responder Juego

Figura 50. Diagramas de Secuencia: Responder Juego.

115

• Diagrama secuencia: Ver Tutorial

Figura 51. Diagramas de Secuencia: Ver Tutorial.

116

2.6. DIAGRAMA DE ACTIVIDADES

• Diagrama de actividades: Registro Estudiante

Figura 52. Diagramas de Actividades: Registro Estudiante.

117

• Diagrama de actividades: Modificar Estudiante

Figura 53. Diagrama de Actividades: Modificar Estudiante.

118

• Diagrama de actividades: Consultar Estudiante

Figura 54. Diagramas de Actividades: Consultar Estudiante.

• Diagrama de actividades: Consultar Detalle Estudiante

Figura 55. Diagrama de Actividades. Consulta Detalle Estudiante.

119

• Diagrama de actividades: Eliminar Estudiante

Figura 56. Diagramas de Actividades: Eliminar Estudiante.

120

• Diagrama de actividades: Registrar Tipo de Condición

Figura 57. Diagramas de Actividades: Registrar Tipo Condición

121

• Diagrama de actividades: Modificar Tipo de Condición

Figura 58. Diagramas de Actividades: Modificar Tipo Condición.

122

• Diagrama de actividades: Consultar Tipo de Condición

Figura 59. Diagramas de Actividades: Consultar Tipo Condición.

• Diagrama de actividades: Consultar Detalle Tipo de Condición

Figura 60.Diagrama de Actividades: Consultar Detalle Tipo Condición

123

• Diagrama de actividades: Eliminar Tipo de Condición

Figura 61. Diagramas de Actividades: Eliminar Tipo Condición.

124

• Diagrama de actividades: Gestión Cuenta

Figura 62. Diagramas de Actividades: Gestionar Cuenta.

• Diagrama de actividades: Ver créditos

Figura 63. Diagramas de Actividades: Ver Créditos

125

• Diagrama de actividades: Iniciar Sesión

Figura 64. Diagramas de Actividades: Iniciar Sesión.

• Diagrama de actividades: Cerrar Sesión

Figura 65. Diagramas de Actividades: Cerrar Sesión.

126

• Diagrama de actividades: Modificar Configuraciones

Figura 66. Diagramas de Actividades. Modificar Configuraciones

• Diagrama de actividades: Iniciar Juego

Figura 67. Diagrama de Actividades: Iniciar Juego

127

• Diagrama de actividades: Responder Juego

Figura 68. Diagramas de Actividades: Responder Juego.

• Diagrama de actividades: Ver Tutorial

Figura 69. Diagramas de Actividades: Ver Tutorial.

128

2.7. DIAGRAMA DE ESTADO

• Diagrama de estado: Registrar Estudiante

Figura 70. Diagramas de Estado: Registrar Estudiante.

• Diagrama de estado: Modificar Estudiante

Figura 71. Diagramas de Estado: Modificar Estudiante.

129

• Diagrama de estado: Consultar Estudiante

Figura 72. Diagramas de Estado: Consultar Estudiante.

• Diagrama de estado: Consultar Detalle Estudiante

Figura 73. Diagramas de Estado: Consultar Detalle Estudiante.

130

• Diagrama de estado: Eliminar Estudiante

Figura 74. Diagramas de Estado: Eliminar Estudiante.

• Diagrama de estado: Registrar Tipo Condición

Figura 75. Diagramas de Estado: Registrar Tipo Condición.

131

• Diagrama de estado: Modificar Tipo Condición

Figura 76. Diagramas de Estado: Modificar Tipo Condición.

• Diagrama de estado: Consultar Tipo Condición

Figura 77. Diagramas de Estado: Consultar Tipo Condición

132

• Diagrama de estado: Consultar Detalle Tipo Condición

Figura 78. Diagramas de Estado: Consultar Detalle Tipo Condición.

• Diagrama de estado: Eliminar Tipo Condición

Figura 79.Diagramas de Estado: Eliminar Tipo Condición.

133

• Diagrama de estado: Gestión Cuenta

Figura 80. Diagramas de Estado: Gestión Cuenta.

• Diagrama de estado: Ver Créditos

Figura 81. Diagramas de Estado: Ver Créditos

134

• Diagrama de estado: Iniciar Sesión

Figura 82. Diagramas de Estado: Iniciar Sesión.

• Diagrama de estado: Cerrar Sesión

Figura 83. Diagramas de Estado: Cerrar Sesión.

135

• Diagrama de estado: Modificar Configuraciones

Figura 84. Diagramas de Estado: Modificar Configuraciones.

• Diagrama de estado: Iniciar Juego

Figura 85. Diagramas de Estado: Iniciar Juego

136

• Diagrama de estado: Responder Juego

Figura 86. Diagramas de Estado: Responder Juego.

• Diagrama de estado: Ver Tutorial

Figura 87. Diagramas de Estado: Ver Tutorial.

137

2.8. DIAGRAMA DE CLASES

Figura 88. Diagrama de clases: Parte I

138

Figura 89. Diagrama de Clases: Parte II

139

3. FASE DE CONTRUCCIÓN

3.1. DESCRIPCIÓN ELEMENTOS OPEN UP

La metodología open up se encuentra compuesta por varios elementos de gran importancia, como lo son los roles que los integrantes de trabajo efectúan durante el desarrollo del proyecto y sus respectivas funciones; y también los sprints necesarios para la elaboración del proyecto, los cuales son aquellos aspectos fundamentales para que el proyecto se encuentre completo y cumpla a a cabalidad con los requerimientos expuestos por el usuario final.

Figura 90. Roles y componentes de la metodología Open Up. Fuente: http://4.bp.blogspot.com/-xb92Sc1r-2o/UwwoChuWtjI/AAAAAAAAAGs/Yfju1Tb_Kbw/s1600/ciclo.jpg

3.1.1. ROLES

• Skateholders

Representan al grupo que está interesado en el proyecto, quienes necesariamente deberán de ser satisfechos por el mismo. En este caso serán tantos los estudiantes como los docentes, en primera estancia del programa de tiflología y en segunda instancia los demás estudiantes y docentes de la institución, claro está, que pertenezcan al nivel académico de básica primaria.

• Líder del proyecto

El proyecto es desarrollado bajo la dirección del Ing. Norberto Novoa Torres, quien tiene como responsabilidad validar el trabajo del equipo, ver si las metas se están cumpliendo conformemente, brindar soluciones a eventuales obstáculos para cumplir los requerimientos, orientar y finalmente apoyar al equipo.

140

• Equipo Cumplirá las funciones de los demás roles adscritos a la metodología open up, como lo son el analista, el arquitecto, el desarrollador y el tester; en este caso, serán Laura Alejandra Domínguez Barbosa y Andrés David Rozo Chiquiza, ejecutores del proyecto y por lo tanto los que cumplirán con las responsabilidades de cada uno de éstos roles.

3.1.2. Sprint

El sprint es el medio por el cual se define los parámetros sobre los cuales se agregan funcionalidades al software, de modo que al terminar el periodo del Sprint, se mostrará el software con nuevas características agregadas.

En el momento de la formulación de cada sprint, y de acuerdo a la metodología Open Up, se tuvieron en cuenta los siguientes parámetros:

• Planificación

Desde la creación del sprint se definen cuáles serán sus alcances y se trabaja en pro del cumplimiento de las metas específicas propuestas.

Algunas de las consideraciones propuestas por la metodología son, evitar los cambios en los objetivos del sprint hasta que no se tengan los módulos propuestos en funcionamiento; también tener en cuenta al momento de la definición del Sprint, todo lo referente a las necesidades del equipo para el desarrollo, como lo son los entornos de desarrollo, los equipos necesarios, los posibles modelados, entre otros.

• Historia de usuario

El Sprint se divide en historias de usuario, las cuales definen los requerimientos desde la perspectiva de los diferentes usuarios del software.

• Sprint Backlog

Hace referencia a la definición de un Script Backlog, el cual cumple la función de ser una tarea que debe permitir el cumplimiento del requerimiento funcional definido en la historia del usuario.

141

• Estimaciones

Esto hace referencia al orden cronológico que el equipo de trabajo debe generar en referencia al cumplimiento de sus tareas, tomando un reporte de los posibles eventos que se presenten.

3.1.3. Cronograma sprints

• Lista limitada

Prioridad Historia de usuario

1 Yo como usuario quiero acceder al aplicativo para poder hacer uso de sus funcionalidades.

2 Yo como estudiante quiero apoyar mi proceso de aprendizaje de las operaciones básicas mediante el uso de un juego educativo.

3 Yo como administrador quiero gestionar la información de los estudiantes.

4 Yo como administrador quiero gestionar las condiciones visuales que pueda tener un estudiante.

5 Yo como administrador quiero gestionar la información asociada a mi cuenta.

Tabla 38. Lista priorizada: Sprints.

142

3.1.3.1. Sprint 1

HISTORIA DE USUARIO 1

Yo como usuario quiero acceder al aplicativo para poder hacer uso de sus

funcionalidades.

BACKLOG

1. Creación de la interfaz gráfica para el logueo del usuario (para cualquier

rol).

2. Asignación de sonido asociado a la manipulación de los componentes de

la interfaz, esto con el objetivo de orientar el software a las capacidades

de los estudiantes con discapacidades visuales.

3. Implementar el manejo de contrastes (escala de grises), con la finalidad

de orientar el software a los estudiantes de baja visión.

Pruebas de Aceptación

Que el usuario ingrese a la aplicación en repetidas ocasiones para

garantizar el adecuado funcionamiento del software.

Tabla 39. Sprint 1.

Para empezar el diseño de las interfaces se realizó mediante el editor de Unity 3D, el cual ofrece una fácil interacción con el entorno de desarrollo y los componentes que éste ofrece.

Cada una de las interfaces está orientada a las capacidades presentadas por parte de los usuarios finales, en este caso, estudiantes con discapacidades visuales, por lo que se implementó el uso de contrastes, propiedades de la fuente y principalmente el manejo de sonidos asociados a cada una de las interfaces y que facilitan la navegabilidad del estudiante en el sistema y el entendimiento del software.

143

3.1.3.2. Sprint 2

HISTORIA DE USUARIO 2

Yo como estudiante quiero apoyar mi proceso de aprendizaje de las

operaciones básicas mediante el uso de un juego educativo.

BACKLOG

1. Estudiar las metodologías de aprendizaje implementadas en la

institución con los estudiantes del programa de tiflología.

2. Crear la interfaz gráfica para el estudiante, con la cual se puede

interactuar mediante el uso del teclado.

3. Desarrollar un juego educativo, que apoye el conocimiento

previamente adquirido en relación a la operación básica, orientado a

los cursos de 3 ° a 5 °.

4. Implementar en el juego herramientas orientadas a las capacidades

de los estudiantes, como el uso de sonidos, contrastes y tamaños de

la fuente.

Pruebas de Aceptación

• Uso continuo del juego para evidenciar el avance a través del tiempo, bajo el control del docente a cargo.

Tabla 40. Sprint 2.

Con la finalidad de cumplir este Sprinti, se realizó la elaboración del eje principal del software educativo, el videojuego matemático, el cual está orientado tanto a las capacidades de los estudiantes como a las edades y niveles educativos que cada uno de ellos se encuentre.

Las pruebas de aceptación se realizaron a lo largo del proceso de la pasantía, ya que con determinado grupo de estudiantes se realizaba el proceso de pruebas del aplicativo, así que se evidencio que para los estudiantes el juego era atrayente, divertido y entretenido y que además les permitiría reforzar sus conocimientos matemáticos previamente adquiridos.

144

3.1.3.3. Sprint 3

HISTORIA DE USUARIO 3

Yo como administrador quiero gestionar la información de los estudiantes.

BACKLOG

1. Elaboración de la interfaz mediante el editor de Unity 3D, el cual

suministre al administrador (docente) funcionalidades relacionadas al

gestiona miento de la información del estudiante.

2. Elaboración de interfaces individuales, orientadas a la manipulación

de la información (Registro, actualización, eliminación y consulta).

3. Implementación del lenguaje SQLite tanto para el almacenaje y

gestiona miento de la información.

Pruebas de Aceptación

Pruebas asociadas al gestionamiento de la información, al elaborar

registros, consultas y modificaciones de la información.

Tabla 41. Sprint 3. Fuente: Autor

Para poder efectuar el gestionamiento de la información de los estudiantes se hizo un proceso de desarrollo paralelo, en el que no solo se elaboró el software educativo y el videojuego, sino que también se realizó el desarrollo de la base de datos asociada al sistema, teniendo en cuenta los requerimientos tanto del sistema como del usuario.

Las pruebas de aceptación realizadas para éste sprint, consistieron en la elaboración de registros, consultas, modificaciones y eliminaciones de la información, con el objetivo de probar que cada una de éstas funcionalidades pudieran efectuarse satisfactoriamente y de tal modo permitir al administrador realizar el gestionamiento de la información del estudiante.

145

3.1.3.4. Sprint 4

HISTORIA DE USUARIO 4

Yo como administrador quiero gestionar las condiciones visuales que pueda

tener un estudiante.

BACKLOG

1. Elaboración de la interfaz asociada al gestionamiento de las

condiciones visuales de los estudiantes, esto con la finalidad de

generar una limitación en cuanto a las funcionalidades y

configuraciones del juego en relación a la condición visual del

estudiante.

2. Asignación de la interacción a nivel de información entre los datos del

estudiante y los datos de la condición visual, con la finalidad de crear

una relación.

3. Uso del SQLite para el control y manipulación de la información

asociada con las condiciones visuales.

Pruebas de Aceptación

Pruebas asociadas al gestionamiento al elaborar encuestas y pruebas

directas con los estudiantes. Tabla 42. Sprint 4.

Para el manejo de éste Sprint se tuvo en cuenta un aspecto fundamental, y es el tipo de configuraciones que podrían ejecutarse por los dos tipos de rol de los estudiantes que harán uso del software, es decir, los estudiantes con discapacidades visuales o los estudiantes que no presentan ningún tipo de discapacidad; por lo que se realizó un estudio directo con los estudiantes para conocer cuáles aspectos eran necesarios modificar para el eficaz manejo del juego educativo.

Finalmente se realizaron las pruebas directas con los estudiantes, en las cuales éstos haciendo uso del software y nos suministraban su opinión en referencia a opciones disponibles y demás aspectos; se obtuvo una respuesta satisfactoria por parte de los mismos por lo que surgieron las interfaces asociadas a la configuración del juego.

146

3.1.3.5. Sprint 5

HISTORIA DE USUARIO 5

Yo como administrador quiero gestionar la información asociada a mi cuenta.

BACKLOG

1. Elaboración de una interfaz sencilla orientada a la manipulación de la

información relacionada con la cuenta del administrador, esto con la

finalidad de ofrecer seguridad al software.

2. Implementación del lenguaje SQLite para el gestionamiento de la

información.

3. Relación del SQLite y la base de datos y la programación, con la

finalidad de garantizar la efectiva interacción entre el software y la

base de datos.

Pruebas de Aceptación

Pruebas asociadas al funcionamiento del sprint al realizar en repetidas

ocasiones actualizaciones de esta información.

Tabla 43. Sprint 5.

Para poder efectuar el gestionamiento de la información de la cuenta se hizo un proceso de desarrollo paralelo, en el que no solo se elaboró el software educativo y el videojuego, sino que también se realizó el desarrollo de la base de datos asociada al sistema, teniendo en cuenta los requerimientos tanto del sistema como del usuario.

Así que el gestionamiento de la información asociada a la cuenta del administrador, en este caso el docente, es de vital importancia, ya que es la cuenta principal para el gestionamiento de otro tipo de información como lo es la información asoaciada a los estudiantes y a los tipos de discapacidades.

Para la prueba de aceptación del sprint, se realizó en varias ocasiones modificación de la información asociada a la cuenta para de tal manera comprobar que no solo el sprint se cumplía a cabalidad sino que también lo hacía el caso de uso.

147

3.2. MODELO DE DOMINIO

Figura 91. Modelo de dominio.

148

3.3. DIAGRAMA DE DESPLIEGUE

Figura 92. Diagrama de Despliegue.

149

4. FASE DE TRANSICIÓN

La fase de transición se compone de dos aspectos principales, inicialmente el proceso de instalación final del software en el ordenador suministrado por parte de la institución, y finalmente la elaboración de las pruebas necesarias para la evaluación del software en cuanto a aspectos relevantes como la ejecución en el equipo de instalación final, así como la usabilidad y funcionalidad para los usuarios; por lo que para la fase de transición se define:

4.1. INSTALACIÓN FINAL DEL SOFTWARE

En cuanto a lo que este apartado se refiere, se realiza el enfoque de la instalación en relación a la compatibilidad del software y la necesidad de los recursos que éste requiere por parte del ordenador de la instalación final, así se define:

Recurso Recurso requerido Recurso disponible

Sistema Operativo Windows xp en adelante Windows 7 Professional

RAM 1 GB 4 GB

Espacio en disco 40 MB 355 GB

Velocidad procesador

2.0 GB 3.30 GB

Periféricos Mouse, Teclado, Altavoces

Mouse, Teclado, Altavoces

Tabla 44. Recurso requerido vs Recurso disponible. Fuente: Autor

4.2. PRUEBAS

4.2.3. PRUEBAS DE VALIDACIÓN: PRUEBA PILOTO

La prueba piloto se vio comprendida en dos fases, las cuales se exponen a continuación:

• Prueba inicial: Mediante el uso de una versión beta del software, se realizaron pruebas orientadas al levantamiento de los requerimientos solicitados por parte de

150

los estudiantes, en cuanto a los aspectos relacionados con la accesibilidad del software; la prueba fue realizada a una totalidad de 13 estudiantes comprendidos entre los cursos (3°) y quinto (5°) de primaría, los cuales presentan discapacidades visuales tales como invidencia y baja visión, así como algunos estudiantes sin dichas limitaciones; tras la elaboración de la prueba se obtuvieron los siguientes resultados:

◦ Manejo de operaciones básicas

Figura 93. Prueba inicial: Manejo de operaciones. Fuente: Autor

◦ Velocidad de juego

Figura 94.Prueba inicial: Manejo de operaciones. Fuente: Autor

3°

4°

5°

0

1

2

3

4

5

6

Suma Resta Multiplicación División

MANEJO DE OPERACIONES

3° 4° 5°

218%

218%

327%

437%

VELOCIDAD DE JUEGO

20 30 40 50

151

◦ Interfaz gráfica con contraste

Figura 95. Prueba inicial. Interfaz gráfica con contraste. Fuente: Autor

◦ Uso de sonido

Figura 96. Prueba inicial: Uso de sonido. Fuente: Autor

B/N73%

Color27%

MANEJO CONTRASTE EN LA INTERFAZ

B/N Color

Si73%

No27%

MANEJO DE SONIDO

152

• Pruebas durante el desarrollo: Las pruebas e iteraciones de los módulos y subsistemas del software, fueron realizadas en el transcurso de la fase de construcción de la metodología Open Up, en la que cada uno de los módulos era ejecutado en repetidas ocasiones con la finalidad de encontrar inconsistencias. Por lo cual se hace la omisión de una prueba piloto específica y se efectúa la elaboración de las pruebas unitarias, mediante el uso del Modelo de Aceptación Tecnológica (TAM).

4.2.4. PRUEBAS DE VALIDACIÓN: PRUEBAS DE CAMPO (usando TAM)

El Modelo de Aceptación Tecnológica (TAM) fue creado para explicar el uso de las TI en diferentes ambientes, modelando cómo los usuarios aceptan y utilizan una herramienta tecnológica. 24

TAM establece que las relaciones entre las convicciones, actitud, intención y comportamiento predicen la aceptación del usuario con respecto a las TI.

En el caso e este proyecto en específico, pueden elaborarse pruebas al software en referencia a la funcionalidad, pero no se puede llegar a predecir aspectos como la aceptación del software por parte de los estudiantes, si éste no es puesto en prueba, mediante la implementación de un método como este.

Las pruebas se hacen mediante el manejo de cuestionarios y encuestas (ANEXO. FORMATO ENCUESTA PRUEBA TAM), con las posibles respuestas por parte del usuario y teniendo en cuenta que las pruebas TAM evalúan tres aspectos fundamentales:

◦ Utilidad percibida (PU): Grado en el que una persona estima que el uso de un software mejoraría su rendimiento.

◦ Facilidad de uso percibida (PEOU): Grado en el que una persona cree que el uso de un software es fácil o cómodo.

◦ Actitud hacia el uso (A): Sentimiento positivo o negativo con respecto a la

realización de una conducta (por ejemplo, utilizar un sistema), normalmente evaluado por un observador.

24 LEYTON, Diego. Extensión al modelo de aceptación de Tecnología TAM, para ser aplicado a sistemas

colaborativos, en el contexto de pequeñas y medianas empresas [en línea]. Universidad de Santiago de Chile, Chile. Chile, 2013, [citado 30 mar, 2016]. Disponible en: http://repositorio.uchile.cl/bitstream/handle/2250/115509/cf-leyton_ds.pdf?sequence=1

153

De acuerdo a la elaboración de las pruebas TAM a estudiantes y docentes se obtuvieron los siguientes

• Pruebas TAM estudiantes

◦ Resultados PU

No. Pregunta Bajo Medio Alto

1 El uso del software te permite apoyar tu proceso de aprendizaje de las operaciones básicas matemáticas

0 3 8

2 El uso de este software te ayudará a mejorar la solución de operaciones básicas

0 1 10

3 El uso de este software te ayudará a mejorar tu concentración y comprensión

0 3 8

4 El uso de este software te ofrecerá nuevas experiencias útiles

0 2 9

Tabla 45. Pruebas TAM estudiantes: Resultados PU.

◦ Gráfica asociada

Figura 97. Pruebas TAM estudiantes: Resultados PU.

Bajo

Medio

Alto

0

2

4

6

8

10

12

34

Bajo

Medio

Alto

154

◦ Resultados PEOU

No. Pregunta Bajo Medio Alto

1 Es cómodo el uso del software 0 2 9

2 Aprender a usar el software se te facilita 0 4 7

3 Se te facilita entender cómo jugar 0 2 9

4 Las diferentes funciones son entendibles 0 1 10

5 Encuentras el software fácil de usar 0 4 7

6 Podrías llegar a ser un experto en el manejo del software

0 3 8

Tabla 46. Pruebas TAM estudiantes: Resultados PEOU.

◦ Gráfica asociada

Figura 98. Pruebas TAM estudiantes: Resultados PEOU.

Bajo

Alto0

2

4

6

8

10

1 2 3 4 5 6

Bajo

Medio

Alto

155

◦ Resultados A

No. Pregunta Bajo Medio Alto

1 Encuentras entretenido el software 0 2 9

2 El usuario puede utilizar bien el sistema 0 3 8

3 El usuario invierte su tiempo en el sistema

0 5 6

4 El usuario se interesa por adquirir el producto

0 0 11

5 El usuario demuestra avances frente al uso del software

0 2 9

Tabla 47. Pruebas TAM estudiantes: Resultados A.

◦ Gráfica asociada

Figura 99.Pruebas TAM estudiantes: Resultados A.

Bajo

Medio

Alto0

2

4

6

8

10

12

12

34

5

Bajo

Medio

Alto

156

• Pruebas TAM docentes

◦ Resultados PU

No. Pregunta Bajo Medio Alto

1 Considera que el software permite apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes

0 0 5

2 Considera que el software es una herramienta de innovación tecnológica que aportará grandes ventajas a los estudiantes

0 0 5

3 Considera que el software será una herramienta que suministrará grandes aportes al desarrollo en la materia que usted imparte

0 2 3

4 El software le ofrece funcionalidades orientadas a su rol de docente

0 5 0

5 Los módulos orientados a los docentes serán de gran ayuda para su proceso de enseñanza

0 3 2

Tabla 48.Pruebas TAM docentes: Resultados PU.

◦ Gráfica asociada

Figura 100. Pruebas TAM docentes: Resultados PU.

Bajo

Medio

Alto

0

1

2

3

4

5

1 2 3 4 5

Bajo Medio Alto

157

◦ Resultados PEOU

No. Pregunta Bajo Medio Alto

1 Se le facilita aprender a usar el software 0 2 3

2 El uso del software es cómodo 0 0 5

3 Se le facilita entender los diferentes módulos y funcionalidades del sistema

0 2 3

4 Encuentra fácil el uso del software 0 1 4

5 Considera que podría llegar a ser un experto en el manejo del software

0 0 5

6 Podrías llegar a ser un experto en el manejo del software

0 5 0

Tabla 49. Pruebas TAM estudiantes: Proceso PEOU.

◦ Gráfica asociada

Figura 101. Pruebas TAM docentes: Resultados PEOU.

Bajo

Alto0

2

4

6

8

10

1 2 3 4 5 6

Bajo

Medio

Alto

158

◦ Resultados A

No. Pregunta Bajo Medio Alto

1 Encuentra interesante el software y las funcionalidades que éste ofrece

0 2 3

2 Considera que el software puede ser atractivo para los estudiantes

0 1 4

3 El usuario puede utilizar bien el sistema 0 0 5

4 El usuario invierte su tiempo en el sistema 0 2 3

5 El usuario se interesa por adquirir el producto

1 2 2

Tabla 50. Pruebas TAM estudiantes: Proceso A. Fuente: Autor

◦ Gráfica asociada

Figura 102. Pruebas TAM estudiantes: Proceso A. Fuente: Autor

Bajo

Medio

Alto

0

1

2

3

4

5

1 2 3 4 5

Bajo Medio Alto

159

4.2.5. PRUEBAS DE CASOS DE USO

A continuación, se propone una serie de pruebas a los casos de uso con la finalidad de verificar el cumplimiento de cada uno de ellos según lo establecido en la fase 2 del presente documento

• Prueba caso de uso: CU-01 Iniciar Sesión Se realiza el inicio de sesión con la cuenta del administrador, la cual ya fue previamente registrada en el sistema, así que se ingresaran los datos «Admin» para el usuario o identificación y «Admin» como contraseña. ◦ Ingreso de la información

Figura 103. Pruebas Caos de Uso: Iniciar Sesión I.

◦ Inicio de sesión exitoso (Redireccionamiento menú principal docente)

Figura 104. Pruebas Caos de Uso: Iniciar Sesión II.

160

• Prueba caso de uso: CU-02 Registrar Estudiante Se realiza el registro de un nuevo estudiante, teniendo en cuenta la información solicitada por el sistema para efectuar el registro del mismo. ◦ Estudiantes iniciales

Figura 105. Pruebas Casos de Uso: CU-02 Registrar Estudiante I.

◦ Ingreso de la información

Figura 106. Pruebas Casos de Uso: CU-02 Registrar Estudiante II.

161

◦ Registro exitoso

Figura 107. Pruebas Casos de Uso: CU-02 Registrar Estudiante III.

◦ Consulta base de datos

Figura 108. Pruebas Casos de Uso: CU-02 Registrar Estudiante IV.

162

• Prueba caso de uso: CU-03 Modificar Estudiante Se realiza la modificación del registro previamente realizado. ◦ Ingreso de la información

Figura 109.Pruebas Casos de Uso: CU-03 Modificar Estudiante I.

◦ Modificación exitosa

Figura 110. Pruebas Casos de Uso: CU-03 Modificar Estudiante II.

163

◦ Consulta base de datos

Figura 111. Pruebas Casos de Uso: CU-03 Modificar Estudiante III.

• Prueba caso de uso: CU-04 Consultar Estudiante

Se realiza la consulta de la información general de los estudiantes registrados en el sistema. ◦ Consulta exitosa

Figura 112. Pruebas Casos de Uso: CU-04 Consultar Estudiante I.

164

• Prueba caso de uso: CU-05 Consultar Detalle Estudiante Se realiza la consulta detalla de uno de los estudiantes previamente registrados en el sistema. ◦ Consulta detallada exitosa

Figura 113. Pruebas Casos de Uso: CU-05 Consultar Detalle Estudiante I.

• Prueba caso de uso: CU-06 Eliminar Estudiante

Se realiza la eliminación del estudiante previamente registrado.

Figura 114. Pruebas Casos de Uso: CU-06 Eliminar Estudiante I.

165

• Prueba caso de uso: CU-07 Registrar Estudiante Se realiza el registro de un nuevo tipo de condición estudiante, teniendo en cuenta la información solicitada por el sistema para efectuar el registro del mismo. ◦ Tipos de condiciones iniciales

Figura 115. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición I.

◦ Ingreso de la información

Figura 116. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición II.

166

◦ Registro exitoso

Figura 117. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición III.

◦ Consulta base de datos

Figura 118. Pruebas Casos de Uso: CU-07 Registrar Tipo Condición IV.

167

• Prueba caso de uso: CU-08 Modificar Tipo Condición Se realiza la modificación del registro previamente realizado. ◦ Ingreso de la información

Figura 119. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición I.

◦ Modificación exitosa

Figura 120. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición II.

168

◦ Consulta base de datos

Figura 121. Pruebas Casos de Uso: CU-08 Modificar Tipo Condición III.

• Prueba caso de uso: CU-09 Consultar Tipo de condición

Se realiza la consulta de la información general de los tipos de condición registrados en el sistema. ◦ Consulta exitosa

Figura 122. Pruebas Casos de Uso: CU-09 Consultar Tipo Condición

169

• Prueba caso de uso: CU-10 Consultar Detalle Tipo de Condición

Se realiza la consulta detalla de uno de los tipos de condición previamente registrados en el sistema. ◦ Consulta detallada exitosa

Figura 123. Pruebas Casos de Uso: CU-10 Consultar Detalle Tipo Condición

• Prueba caso de uso: CU-11 Eliminar Estudiante

Se realiza la eliminación del estudiante previamente registrado.

Figura 124. Pruebas Casos de Uso: CU-11 Eliminar Tipo condición.

170

• Prueba caso de uso: CU-12 Gestionar Cuenta Se realiza la modificación de algún dato de la cuenta del administrador. ◦ Ingreso de la información

Figura 125. Pruebas Casos de Uso: CU-12 Gestionar Cuenta I.

◦ Modificación Exitosa

Figura 126. Pruebas Casos de Uso: CU-12 Gestionar Cuenta II.

171

• Prueba caso de uso: CU-13 Ver Créditos Se realiza el acceso a la interfaz de créditos

Figura 127. Pruebas Casos de Uso: CU-13 Ver Créditos.

• Prueba caso de uso: CU-14 Cerrar Sesión

Se realiza el cierre de sesión, redirección al inicio de sesión.

Figura 128. Pruebas Casos de Uso: CU-14 Cerrar Sesión.

172

• Prueba caso de uso: CU-15 Modificar Configuraciones Se configuran algunos aspectos desde el menú de opciones de un estudiante vidente.

Figura 129. Pruebas Casos de Uso: CU-15 Modificar Configuraciones.

• Prueba caso de uso: CU-16 Iniciar Juego

Se selecciona el tipo de juego y se inicia un nuevo juego. ◦ Selección tipo de juego

Figura 130. Pruebas Casos de Uso: CU-16 Iniciar Juego I.

173

◦ Inicio juego exitoso

Figura 131. Pruebas Casos de Uso: CU-16 Iniciar Juego II.

• Prueba caso de uso: CU-17 Responder Juego

Se responde una de las operaciones del juego y se observa que incrementa el puntaje.

Figura 132. Pruebas Casos de Uso: CU-17 Responder Juego I

174

• Prueba caso de uso: CU-18 Ver Tutorial Se responde la petición de ingreso al tutorial del juego

Figura 133. Pruebas Casos de Uso: CU-18: Ver Tutorial.

175

5. RECOMENDACIONES

• El software está orientado al aprovechamiento de las capacidades de estudiantes invidentes y de baja visión, mediante el manejo de sonidos, contrastes y tamaños de letras y objetos; por lo que debe considerarse que le método de salida de información es el sonido y el método de ingreso de información se realiza mediante el uso del teclado, por lo que el estudiante debe tener un previo conocimiento del teclado, específicamente del teclado numérico.

• Las configuraciones de personalización del juego, estas enfocadas al uso de estudiantes que no poseen discapacidades visuales, ya que se manipulan variables como el aumento de la velocidad, el uso de velocidades aleatorias, el cambio de colores, entre otros; variables que afectarían los requerimientos de los estudiantes invidentes o de baja visión presentan.

• La dificultad asociada al juego está relacionada con el avance del estudiante durante el juego, es decir, entre menor sea el tiempo de respuesta de la operación mayor será la velocidad y el puntaje adquirido; por lo que la manipulación de las configuraciones de personalización en relación a la velocidad afectaría el desarrollo y evolución del juego para el estudiante, debido a la confusión en referencia a los sonidos de las operaciones que aparece en pantalla.

• La interfaz está orientada a los estudiantes con discapacidades visuales por lo que se trabaja el manejo de contrastes a escala de grises, así que visualmente el software no será atractivo para todo tipo de estudiantes.

• El software está orientado para correrse en sistemas operativos Windows, por lo que se recomienda la ejecución en los Windows recientes, ya que posiblemente en versiones antiguas genere problemáticas.

176

6. CONCLUSIONES

La implementación de las tecnologías de la información y la comunicación en la educación es sin duda una herramienta de gran ayuda para la mejora de la pedagogía infantil, ya que permite nutrir con elementos innovadores los métodos de enseñanza trabajando en paralelo con la evolución tecnológica que ha surgido a través de esta era informática. No obstante, una herramienta cómo ésta, no podrá suplir por completo los aspectos asociados al proceso de enseñanza y aprendizaje de un estudiante, ni reemplazará la labor de un docente, solo pueden denotarse a las herramientas tecnológicas como recursos para el enriquecimiento de dichos procesos, y como una herramienta que actuando en conjunto con otras actividades y formas de enseñanza, pueden conformar un fuerte componente pedagógico.

El uso de las tecnologías de la información y la comunicación enfocadas a la educación inclusiva permite reforzar la base de formación de la misma, ya que su principal objetivo es brindar el derecho a la educación a cualquier estudiante sin importar las condiciones que éste presente, incluidas las discapacidades físicas; así que, al trabajar el componente pedagógico en conjunto de las TICs, se estará suministrando a los estudiantes herramientas que le permitan interactuar con la tecnología sin importar las discapacidades que presente. Este proyecto está desarrollado con el objetivo de apoyar a la inclusión, ya que se orienta a las capacidades de estudiantes con discapacidades visuales, lo que nos permitió generar herramientas orientadas a una población con la que poca relación se tiene en cuanto al desarrollo de productos tecnológicos orientados a sus limitaciones.

El principal enfoque de la elaboración de éste proyecto es la accesibilidad en cuanto a las discapacidades visuales, sin embargo, el software está orientado tanto para estudiantes que posean discapacidades visuales, como para aquellos que no las posean; así que el proyecto trabaja conceptos de inclusión, accesibilidad e integración bajo el suministro de una herramienta tecnológica que permita el apoyo del proceso de aprendizaje de los estudiantes, es decir, el suministro de un recurso para su proceso académico, y para el fortalecimiento de la pedagogía ofrecida en la institución en la que se realizó la pasantía.

La elaboración de este proyecto fue una experiencia bastante enriquecedora, ya que nos suministró una seria de grandes enseñanzas, debido a la relación directa con estudiantes que presentan discapacidades no solo visuales, si no también cognitivas; los niños y los docentes nos enseñaron a ver el mundo de una nueva manera, y al comprender cómo es su mundo y cómo lo perciben, es bastante satisfactorio saber que se elaboró un proyecto con un fuerte enfoque social y que además será una herramienta de gran aprovechamiento por una población que realmente merece éste tipo de herramientas para incentivar su evolución y el fortalecimiento de la inclusión.

177

7. BIBLIOGRAFÍA

ARANDA, Miriam; PÉREZ, Miguel y SÁNCHEZ, Blanca. Bases Psicopedagógicas de la Ed Especial. Dificultades en el Aprendizaje Matemático [en línea]. Ciudad de México, México. Disponible en: https://www.uam.es/personal_pdi/stmaria/.../DificultadesMatematicasLenguaje1.pdf

BLANCO, Rosa. Hacia una Escuela para Todos y con Todo. UNESCO. Santiago de chile, Chile. Disponible en: http://www.ite.educacion.es/formacion/materiales/72/cd/curso/unidad1/u1.I.8.htm

CASTILLO, Brandon. Desarrollo de un Videojuego Educativo con Diseño 3D, enfocado hacia el Apoyo en el Aprendizaje de las Tablas de Multiplicar. Universidad Distrital Francisco José de Caldas, Bogotá, 2014

CEDETI, Centro de Desarrollo de Tecnologías de Inclusión, Cantaletras. Pontificia Universidad Católica de Chile, Chile, 2006.

CONAFE. Discapacidad Visual: Guía Didáctica para la Inclusión en Educación Inicial y Básica [en línea]. México, 2010. Disponible en: http://www.educacionespecial.sep.gob.mx/2016/pdf/discapacidad/Documentos/Atencion_educativa/Visual/1discapacidad_visual.pdf

ECURED. Open Up [en línea]. Cuba, sep. 2012. Disponible en: https://www.ecured.cu/OpenUp

GONZALEZ, José. El lenguaje de programación C# [en línea]. Madrid, España, oct. 2014. Disponible en: dis.um.es/~bmoros/privado/bibliografia/LibroCsharp.pdf

HERNANDEZ, Enrique [en línea]. Valencia, España: Departamento de Informática de Sistemas y Computadores (DISCA), sep 2013. P 2. Disponible en: www.disca.upv.es/enheror/pdf/ActaUML.PDF

MINISTERIO DE EDUCACIÓN. Educación para todos [en línea]. Colombia. Disponible en: http://www.mineducacion.gov.co/1621/article-141881.html

MORÓN, Carmén. La importancia de la motivación en la educación infantil [en línea]. Andalucía, España: Revista digital para profesionales de la enseñanza, ene. 2011. 1p. Disponible en: https://www.feandalucia.ccoo.es/docu/p5sd7914.pdf

OJEDA, Julio y PIÑA Carmen. Software en el contexto del Proceso Enseñanza – Aprendizaje [en línea]. Texinfo 2 ed. Querétaro, México: Odiseo, dic. 2010. Disponible en: http://www.odiseo.com.mx/correoslector/software-contexto-proceso-ensenanza-aprendizaje

178

OLGUIN, Efraín. Metodología Open Up [en línea]. Baja California, México, sep. 2013. [citado 13 oct, 2016]. Disponible en: http://openupeaojmp.blogspot.com.co/2013/09/metodologia-open-up.html

OUAZZANI, Iman. Manual de creación de videojuegos con Unity 3D [en línea]. Madrid, España: Universidad Carlos III de Madrid, ago. 2012. p 21. Disponible en: e-archivo.uc3m.es/bitstream/handle/10016/16345/PFC_Iman_Ouazzani.pdf...1

RICARDO Adriana y PARRA Ingrid. Software de enseñanza - Aprendizaje de las operaciones básicas de las matemáticas, la suma y la resta, dirigida a la educación de transición y primero de primaria. Universidad Nacional Abierta y a Distancia (UNAD), Bogotá, 2009.

ROUSE, Margaret. MySQL [en línea]. New York, Estados Unidos: TechTarget, en 2015. Disponible en: http://searchdatacenter.techtarget.com/es/definicion/MySQL

SANTOS, Nelly. Enseñanza Aprendizaje de las Matemáticas desde una Perspectiva Inclusiva para Personas en Condición de Discapacidad Visual. Universidad Distrital Francisco José de Caldas, Bogotá, 2016.

SARRAMONA, Jaime. Concepto de Educación [en línea]. CEAC. España, 1889 [citado 02 oct, 2016]. Disponible en: https://www.uv.mx/personal/rdegasperin/files/2011/07/Antologia.Comunicacion-Unidad1.pdf

UNICEF, UNESCO, Fundación HINENI. Hacia el Desarrollo de Escuelas Inclusivas. 2000

VIDAL, María; GÓMEZ Freddy y RUIZ, Alina. Software Educativos [en línea]. La Habana, Cuba, jun 2010. Disponible en: scielo.sld.cu/pdf/ems/v24n1/ems12110.pdf

ZAPPALÁ, Daniel, KÖPPEL, Andrea & SUCHODOLSKI, Miriram. Inclusión de TIC en escuelas para alumnos con discapacidad visual [en línea]. Buenos Aires, Argentina, 2011. Disponible en: http://escritorioeducacionespecial.educ.ar/datos/recursos/pdf/m-visuales-1-48.pdf

179

8. ANEXOS

180

4-4-2017 4-4-2017

Anexo A. Manual del Usuario

ANEXO A [Manual del usuario]

MANUAL DEL USUARIO

Software educativo en apoyo al proceso de aprendizaje de las operaciones

básicas matemáticas de los estudiantes de primaria del programa de tiflología

del Colegio OEA I.E.D.

El presente documento es una herramienta para comprender el funcionamiento del software, así como cada una de las funcionalidades que éste ofrece tanto para el administrador (docente) como para el estudiante

SINOPSIS

TABLA DE CONTENIDO

1. OBJETIVOS DEL SOFTWARE ........................................................................ 1

2. INGRESO AL SOFTWARE ............................................................................... 3

3. USO DEL APLICATIVO .................................................................................... 5

3.1. INICIAR SESIÓN ........................................................................................... 5

3.2. MÓDULO ADMINISTRADOR ........................................................................ 6

3.2.1. Menú principal ............................................................................................ 7

3.3. MÓDULO ESTUDIANTES ........................................................................... 17

3.3.1. Menú principal .......................................................................................... 17

1

MANUAL DEL USUARIO

1. OBJETIVOS DEL SOFTWARE

El software tiene como objetivo principal apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de estudiantes de primaria que presentan discapacidades visuales, mediante el suministro de un videojuego educativo, el cual se encuentra enfocado en el aprovechamiento de las capacidades de los estudiantes, debido al uso de aspectos como el manejo de sonidos, el uso de contrastes y propiedades en la fuente.

El software educativo hace uso de dos módulos principales, uno enfocado a los estudiantes y otro a los docentes, quienes cumplen el rol de administrador; a continuación, se presenta una pequeña descripción de los módulos y sus funcionalidades.

• Modulo Estudiantes: El módulo está enfocado en dos tipos de

estudiantes, primordialmente aquellos que presentan limitaciones visuales tales como invidencia y baja visión, y aquellos que no presentan ningún tipo de discapacidad, ofrece las siguientes funcionalidades:

◦ Jugar: El estudiante podrá hacer uso del juego educativo, en el cual podrá responder a operaciones básicas matemáticas según, esto según la operación elegida por el estudiante.

◦ Opciones: Los estudiantes de acuerdo a sus capacidades podrán modificar las configuraciones asociadas a la velocidad, los colores, el tamaño de la fuente, el volumen del sonido, entre otros.

◦ Tutorial: El estudiante podrá acceder a un tutorial en el que

podrá conocer el funcionamiento de cada una de las teclas en referencia al uso tanto del juego como del software.

• Modulo Docentes: El modulo está enfocado en suministrar una herramienta a los docentes para conocer los avances de los estudiantes a través del tiempo, ofrece las siguientes funcionalidades:

◦ Gestionar información estudiante: Le permite al administrador gestionar la información relacionada a los

2

estudiantes, es decir, el registro, modificación, consulta y eliminación de la información.

◦ Gestionar información tipo de condición: Le permite al administrador gestionar la información relacionada a los tipos de condiciones (discapacidades), es decir, el registro, modificación, consulta y eliminación de la información.

◦ Gestionar información cuenta: Le permite al administrador

modificar la información relacionada con su cuenta, es aspectos tales como el usuario y la contraseña.

◦ Ver créditos: Le permite al administrador conocer la

información relacionada con el desarrollo del software y las herramientas implementadas para lo mismo.

3

2. INGRESO AL SOFTWARE

Para iniciar el aplicativo solo es necesario acceder al sitio en el cual se encuentra guardado el ejecutable del juego y luego de esto abrir el ejecutable como cualquier otro programa.

• Búsqueda del lugar de almacenaje del ejecutable del software, en este caso, el escritorio:

• Apertura de la carpeta, la cual debe contener tanto el ejecutable .exe como la carpeta de datos, cabe aclarar que el aplicativo no funcionará sin tener ésta carpeta de datos, ya que allí se encuentra la información necesaria para la eficaz ejecución del mismo.

4

• Ejecución del .exe del juego

• Interfaz inicial del juego

La interfaz inicial presenta a Tobías, la mascota del juego quien sirve de guía para la navegación en el aplicativo por parte de los estudiantes. Tobías se encarga de presentarse y dar una introducción al juego, solicita el ingreso de un dato numérico cualquiera para el inicio el redireccionamiento a la interfaz del inicio de sesión.

5

3. USO DEL APLICATIVO

A continuación, se presenta el uso del aplicativo en referencia a tres aspectos principales, el inicio de sesión, el uso del módulo del administrador y el uso del módulo de los estudiantes, con su respectiva explicación paso a paso y la presentación de capturas de pantalla del proceso.

3.1. INICIAR SESIÓN

El inicio de sesión debe ser realizado por todos los usuarios del sistema, sean el administrador (docentes) o los estudiantes (con o sin discapacidad).

• Requerimientos previos:

- El usuario debe estar registrado en el sistema: ◦ En el caso del administrador los datos de ingreso por defecto son:

Usuario: Tiflologia

Contraseña: tiflo

◦ En el caso de los estudiantes, el administrador tiene la responsabilidad de realizar el registro de cada uno de los estudiantes que deseen hacer uso del aplicativo, por lo que la información correspondiente para el usuario y la contraseña serán los indicados en el proceso del registro; se recomienda trabajar el número de identificación como el valor del usuario.

• Iniciar sesión: Ubicados en la interfaz de inicio de sesión se realizan los siguientes pasos: 1. Se realiza el ingreso del dato correspondiente al usuario

(identificación). 2. Se realiza el ingreso del dato correspondiente a la contraseña del

usuario anteriormente indicado. 3. Luego de ingresada la información, se oprime la tecla «Enter» en

botón «Ingresar».

6

En la anterior imagen se puede observar la interfaz del Inicio de Sesión, en la cual se cuenta con los campos de texto para el ingreso de los datos anteriormente especificados y además se cuenta con dos opciones extra, la primera permite silenciar el sonido del menú, en el caso de ser uno de los docentes quien se encuentra ingresando a la aplicación o un estudiante que no presenta discapacidad visual alguna; y la segunda la opción de salir, que cerrará el aplicativo por completo.

3.2. MÓDULO ADMINISTRADOR

El principal objetivo de esto modulo es suministrar al docente, quien cumple el rol de administrador, herramientas que permitan tanto el gestionamiento de la información de los estudiantes como la elaboración de un seguimiento en referencia a los avances de los alumnos a lo largo del uso del aplicativo.

A continuación, se presentarán las funcionalidades y herramientas ofrecidas por parte del módulo al administrador del software educativo, teniendo en cuenta las interfaces correspondientes a cada una de ellas.

1

2

3

O

7

3.2.1. Menú principal

El menú principal contiene los botones que permiten el redireccionamiento por parte del sistema a las interfaces correspondientes a cada una de las funcionalidades que software suministra al administrador, éstas opciones son:

1. Consultar estudiantes: Permite acceder a la interfaz para el gestionamiento de la información de los estudiantes.

2. Condiciones visuales: Permite acceder a la interfaz para el gestionamiento de la información de las condiciones visuales.

3. Administrar cuenta: Permite acceder a la interfaz para el

gestionamiento de la información de la cuenta:

4. Créditos: Permite acceder a la interfaz de los créditos (información asociada a los desarrolladores y herramientas para la elaboración del software).

5. Salir: Permite cerrar la sesión y volver al menú principal.

1

2

3

4

5

8

3.2.1.1. Consultar estudiantes

Esta interfaz se divide en dos paneles principales, el primero presenta el listado de los estudiantes que han sido registrados previamente en el sistema, y el segundo presenta los botones para el acceso a las interfaces correspondientes a cada funcionalidad.

El segundo panel presenta las opciones: 1. Detalles: Previa la selección de uno de los

estudiantes presentes en el listado del panel 1, se puede acceder a la interfaz «Detalles», la cual permite consultar la información específica del estudiante.

2. Actualizar: Accede a la interfaz «Actualizar», la cual permite modificar la información del estudiante seleccionado.

3. Eliminar: Permite eliminar la información del estudiante seleccionado.

4. Nuevo: Accede a la interfaz «Registro», la cual permite registrar un nuevo estudiante.

5. Volver: Permite volver al menú principal.

1

2

9

Interfaz Detalles Estudiante La interfaz se divide en dos paneles principales:

- El panel A: Presenta la información general del estudiante, como el nombre, apellido, identificación, contraseña y el tipo de condición visual que presenta.

- El panel B: Presenta la información detallada de los avances del alumno en referencia al uso del videojuego a través del tiempo; la información que presenta es: el tipo de juego (sumas, restas, multiplicaciones, divisiones, o todas las operaciones), la cantidad de operaciones cuya respuesta fue correcta, el puntaje obtenido en la partida, el número de intentos, la duración de la partida y la fecha en que se realizó la partida.

- Además, contiene el botón «Volver», el cual permite al

administrador regresar a la interfaz anterior.

A

B

10

Interfaz Actualizar Estudiante La interfaz actualizar estudiante está compuesta por dos paneles principales:

- El panel A: Contiene los campos para ingresar la nueva información del estudiante.

- El panel B: Imprime en la pantalla las notificaciones correspondientes al proceso, es decir, imprime un mensaje si la información del usuario ha sido actualizada correctamente o si se presenta algún error referente a la información suministrada.

- Además, contiene los botones actualizar estudiante y

volver, los cuales realizan la actualización de la información y permiten regresar a la interfaz anterior respectivamente.

A

B

11

Interfaz Eliminar Estudiante La interfaz eliminar estudiante es muy sencilla, consta de una sección para la impresión de un mensaje para la confirmación de la eliminación del registro, en el cual se pregunta al usuario si desea o no eliminar el estudiante y se presentan dos botones para la ejecución de la decisión que haya tomado el usuario.

Interfaz Nuevo Estudiante Está compuesta por dos paneles principales:

- El panel A: Contiene los campos para el ingreso de la información requerida por la base de datos, como lo es: la identificación el nombre, el apellido, el tipo de condición visual que presenta, la contraseña y la confirmación de la misma.

- El panel B: Imprime en pantalla las notificaciones asociadas al proceso: registro exitoso o algún error referente a la información ingresada.

- Además, contiene los botones para confirmar el

registro de la información y para regresar a la anterior interfaz.

12

3.2.1.2. Condiciones visuales

Esta interfaz está compuesta por cuatro paneles:

- El panel A: Imprime en pantalla un listado de los registros referentes a la información de las condiciones visuales que se encuentran en la base de datos.

- El panel B: Contiene los botones que permiten mostrar en pantalla los elementos asociados a cada funcionalidad:

Detalles: Para imprimir en el panel C la

información detallada del tipo de condición seleccionado.

Nuevo: Para realizar el registro de un nuevo tipo de condición visual.

Actualizar: Para actualizar la información del tipo de condición seleccionado.

Eliminar: Para eliminar la información del tipo de condición seleccionado.

- El panel C: Donde se despliegan los elementos correspondientes a cada funcionalidad.

A

B

13

- El panel D: Imprime en pantalla las notificaciones asociadas a cada proceso.

- Además, contiene el botón volver, que permite regresar al menú principal.

Interfaz Detalles Tipo de Condición Imprime en el panel C de la interfaz la información detallada del tipo de condición seleccionado.

A B

C

D

14

Interfaz Nuevo Tipo de Condición Despliega en el panel C los campos necesarios para el registro de un nuevo tipo de condición, como lo son el nombre, la descripción y si presenta o no una limitación visual; también presenta el botón para confirmar el nuevo registro.

Interfaz Nuevo Tipo de Condición Despliega en el panel C los campos necesarios para la actualización del tipo de condición seleccionado.

15

Interfaz Eliminar Tipo de Condición Imprime en el panel C el mensaje para la confirmación de la eliminación, o en este caso un mensaje indicado que el tipo de condición seleccionado para eliminarse no puede ser eliminado de la base de datos ya que está asociado a otro registro, es decir, es uno de los atributos de la información de uno de los estudiantes registrado.

3.2.1.3. Administrar cuenta

Esta interfaz está compuesta por tres paneles:

- El panel A: Contiene los campos asociados a la información del usuario de la cuenta, con el botón de confirmación respectivo.

- El panel B: Contiene los campos asociados a la información de la contraseña de la cuenta, con el botón de confirmación respectivo.

- El panel C: Imprime en la pantalla las notificaciones

asociadas al proceso.

- Además, contiene un botón que permite regresar al menú principal.

16

3.2.1.4. Créditos

Esta interfaz despliega la información correspondiente a los desarrolladores y herramientas requeridas para la elaboración del software. Contiene un botón que permite regresar al menú principal.

A

B

C

17

3.3. MÓDULO ESTUDIANTES

El principal objetivo de este módulo es suministrar a los estudiantes una herramienta para apoyar su proceso de aprendizaje de las operaciones básica matemáticas, en este caso mediante el suministro de un videojuego matemático.

A continuación, se presentarán las funcionalidades y herramientas ofrecidas por parte del módulo a los estudiantes que harán uso del software educativo, teniendo en cuenta las interfaces correspondientes a cada una de ellas.

3.3.1. Menú principal

El menú principal contiene los botones que permiten el redireccionamiento por parte del sistema a las interfaces correspondientes a cada una de las funcionalidades que el software suministra al estudiante, éstas opciones son:

1. Jugar: Permite acceder a la interfaz para la selección del tipo de juego y seguido de esto permite acceder a la interfaz del juego.

2. Teclas: Permite acceder a la interfaz del tutorial para la navegación en el teclado.

3. Opciones: Permite acceder a la interfaz para la

configuración de las opciones del juego.

Cabe aclarar que se tienen dos interfaces para la configuración de las opciones, una orientada a los estudiantes que presentan algún tipo de discapacidad visual, y otra orientada a los estudiantes que no tienen ningún tipo de limitación visual; con esto se plantea el suministro de una herramienta tecnológica inclusiva que esté orientada a las capacidades de los alumnos, sin importar que estos presente o no algún tipo de discapacidad visual.

4. Volver: Permite cerrar la sesión y regresar a la interfaz para

el inicio de sesión.

18

3.3.1.1. Jugar

Al seleccionar la opción jugar, se accede a la interfaz que permite seleccionar el tipo de juego, es decir, las operaciones con las cuales el alumno desea jugar (suma, resta, multiplicación, división, todas).

1

2

3

4

19

Luego, según la selección del estudiante, se direcciona a la interfaz del juego, la cual está compuesta por dos paneles:

- El panel A: Es el panel principal del juego, en el cual se imprimirán las operaciones a resolver por el estudiante.

- El panel B: Este compuesto por dos secciones, la primera es el indicador de las vidas que el alumno tiene en el juego y la perdida de las mismas; el segundo imprime en pantalla el mensaje acumulado del estudiante a lo largo de la partida.

- Además, contiene el botón ingresar que permite

ingresar la respuesta (en el caso de los estudiantes sin limitaciones visuales).

Finalizado el juego se imprime en pantalla el puntaje final.

A

B

20

3.3.1.2. Teclas

Esta interfaz contiene un cuadro en el cual se imprimirá el valor de la tecla seleccionada, así como un cuadro de dialogo que imprime la función de la misma.

3.3.1.3. Opciones

Como se mencionó anteriormente, hay dos interfaces para la configuración del juego, una orientada a estudiantes con discapacidades visuales y otra a estudiantes que no presentan ningún tipo de discapacidad visual.

Interfaz opciones para estudiantes con discapacidades visuales Este compuesto por dos paneles:

- El panel A: Presenta las opciones a configurar:

Volumen de fondo: Permite subir o bajar la música de fondo.

Volumen del menú: Permite subir o bajar el volumen de las indicaciones del menú.

21

- El panel B: Presenta la visualización de las configuraciones.

Interfaz opciones para estudiantes sin discapacidades visuales

- El panel A: Presenta las opciones a configurar:

Tiempo para que aparezca una operación después de la otra: Permite configurar el tiempo de aparición de las operaciones.

Velocidad aleatoria: Genera velocidades de aparición aleatorias

A

B

22

Tamaño de las operaciones: Permite configurar el tamaño de la fuente de las operaciones.

Colores aleatorios: Permite establecer colores aleatorios para la fuente de las operaciones o un color en específico.

Configuración de sonidos: Permite subir, bajar, activar o desactivar los sonidos asociados a la música de fondo, el sonido de las indicaciones del menú y el sonido del juego.

23

- El panel B: Presenta la visualización de las

configuraciones.

A

B

181

4-4-2017

Anexo B. Manual del Programador

ANEXO B

[Manual del Programador]

MANUAL DEL PROGRAMADOR

Software educativo en apoyo al proceso de aprendizaje de las operaciones

básicas matemáticas de los estudiantes de primaria del programa de tiflología

del Colegio OEA I.E.D.

El presente documento es una herramienta para comprender la estructuración en cuando al desarrollo del software en referencia a la herramienta de desarrollo implementada, es decir, Unity

SINOPSIS

TABLA DE CONTENIDO

1. Software de desarrollo: Unity ............................................................................ 1

1.1. Requisitos del sistema y dirección descarga .............................................. 1

2. Interfaz grafica .................................................................................................. 2

3. LIBRERÍAS ....................................................................................................... 4

4. SCRIPTS ...................................................................................................... 111

4.1. Clases estáticas ..................................................................................... 111

4.2. Otras clases ........................................................................................... 111

5. Posibles Inconvenientes ............................................................................... 144

1

MANUAL DEL PROGRAMADOR

1. Software de desarrollo: Unity

1.1. Requisitos del sistema y dirección descarga

• Requisitos básicos del sistema para la instalación de Unity

OS: Windows 7 SP1+, 8, 10; Mac OS X 10.8+.

GPU: Capacidades de tarjeta de vídeo con DX9 (modelo de shader

2.0). Todo lo que se haya lanzado desde 2004 debería funcionar.

Para mayor información se puede realizar la consulta del url:

https://unity3d.com/es/unity/system-requirements

• Descarga del software

Unity es un software libre que puede ser descargado desde el sitio web oficial de Unity: https://store.unity.com/es

2

2. Interfaz grafica

En el editor de Unity, cada uno de los componentes de la jerarquia (Hierarchy) son denominados como « GameObject»

Un ejemplo es la instrucción GetComponentsInChildren<T>() donde T indica un Objeto, por ejemplo se desea obtener una lista los GameObject hijos de ‘Canvas’, el resultado será un vector con los componentes ‘ControlVolumen’, ‘ObjetosSonidos’, ‘SonidosJuego’, y los hijos de cada uno de ellos.

La instrucción será GetComponentsInChildren<GameObject>();

Otro ejemplo para obtener componentes hijos. Es mediante el GameObject ‘Panel’, el cual contiene a la clase ‘NavItems’, y los GameObjects hijos contienen la clase ‘Item’. Para obtener los hijos ‘Item’ del GameObject ‘panel’ se utiliza la instrucción:

GetComponentsInChildren<Item>();

La cual retornará un vector con los ‘GameObjects’ que contengan la clase ‘Item’, como se evidencia en la siguiente imagen:

3

En la pestaña ‘Inspector’ se aprecian todos los atributos públicos que tiene una clase o un componente, como por ejemplo la clase ‘item’ contiene los atributos id_aud,Select, ClipStart, ClipEnd, Init, SetText, Txt y ManagerMenu., éstos se instancian arrastrando el componente adecuado.

4

3. LIBRERÍAS

Las librerías utilizadas en el software son:

• System.Collections y System.Collections.Generic

Nombre Librería System.Collections y System.Collections.Generic

Descripción Librería

El espacio de nombre «System.Collections» contiene interfaces y clases que definen varias colecciones de objetos, como listas, colas, matrices de bits, tablas hash y diccionarios.

El espacio de nombres «System.Collections.Generic» contiene interfaces y clases que definen colecciones genéricas, lo que permite que los usuarios creen colecciones fuertemente tipadas para proporcionar una mayor seguridad de tipos y un rendimiento mejor que los de las colecciones no genéricas fuertemente tipadas.

System.Collections – System.Collections.Generic

En conclusión, en las colecciones genéricas se establece un tipo de dato, mientras que las no genéricas es se manejan de tipo global.

Implementación Descripción using System.Collections;

[…]

public static class varGameOper {

Se implementan las colecciones no genéricas haciendo uso de un tipo de dato ‘ArrayList’.

5

public static ArrayList l

stOpers = new ArrayList();

[…]

}

Este atributo sirve para almacenar todas las operaciones cuando el usuario este jugando o cambiando las opciones.

• UnityEngine.UI

Nombre Librería UnityEngine.UI

Descripción Librería

El sistema de interfaz de usuario (UI), permite crear interfaces de usuario rápidas e intuitivas. A continuación, se presenta una introducción a las principales características del sistema de interfaz de usuario de la Unidad.

El editor de Unity permite el ajuste del componente tales como Ancho, Alto, Colores (Si contiene una propiedad ‘Color’), entre otros.

Al interactuar con éstos elementos ya sea mediante el teclado o el mouse, se generan eventos (UnityEvent) y estos son controlados mediante programación. Cabe destacar que solo se generan eventos si el GameObject contiene un componente ‘Selectable’.

Se pueden crear estos eventos mediante la implementación de los componentes de la interfaz ‘UnityEngine.EventsSystem’ añadiendo un componente ‘Selectable’ al GameObject o de lo contrario no funcionará.

Implementación Descripción

Text Permite mostrar al usuario un texto en pantalla

Toggle Su funcionamiento se basa en añadir un estado activo o inactivo (On/Off).

Slider Una barra deslizante que permite obtener un valor numérico dado un valor mínimo y máximo

Entre otros.

6

• UnityEngine.Events

Nombre Librería UnityEngine.Events

Descripción Librería

Es una forma de generar eventos (UnityEvent) retornando desde 0 hasta 4 tipos de datos diferentes, luego, al accionar este evento se llaman funciones que el usuario desee por medio del editor de Unity sin usar programación.

Implementación/ejemplo Descripción

[...]

using UnityEngine.Events;

[System.Serializable]

public class EventTable: UnityEvent

<string> {

public class Table: MonoBehaviour {

public EventTable OnClickItem;

public void setEvent(string

valItem){

if (selReg) {

valor.text = valItem;

}

if (OnClickItem != null) {

OnClickItem.Invoke (valItem);

}

}

}

En este ejemplo se crea una clase la cual hereda de UnityEvent pasando un solo parámetro, esto significa que retorna un String cuando se llame al método ‘setEvent’.

El llamado del método se hace mediante la programación o algunos eventos de teclado o mouse.

7

• UnityEngine.Audio

Nombre Librería UnityEngine.Audio

Descripción Librería

Maneja lo referente al mezclador de audio, es base fundamental del programa ya que es orientado a personas en condición de discapacidad visual.

Implementación/ejemplo Descripción

[...]

using UnityEngine.Audio;

public class ManagerLoginSounds:

MonoBehaviour {

public AudioMixer BackGround;

[...]

}

Se crea un atributo público ‘AudioMixer’ este se instancia por medio del editor de Unity.

Su funcionamiento es controlar la salida de audio.

• UnityEngine.EventsSystems

Nombre Librería UnityEngine.EventSystems

Descripción Librería

Se implementan métodos los cuales sirven para generar eventos ya sea mediante el uso del teclado o del mouse.

Los ejemplos tienen la instrucción ‘[RequireComponent(typeof(Selectable))]’, la cual tiene como objetivo que el GameObject tenga un componente obligatorio ‘Selectable’ para su funcionamiento.

Implementación Descripción

IPointerClickHandler:

using UnityEngine.EventSystems;

Cuando el puntero hace Click en el componente seleccionable.

8

[RequireComponent(typeof(Select

able))]

public class Item:

MonoBehaviour, [...],

IPointerClickHandler, [...] {

[...]

public void

OnPointerClick(PointerEventData

eventData){

if

(GetComponent<Button> () ==

null) {

SetSelect ();

play ();

}

}

[...]

}

ISelectHandler:

using UnityEngine.EventSystems;

[RequireComponent(typeof(Select

able))]

public class Item:

MonoBehaviour,

ISelectHandler, [...] {

Se llama cuando el GameObject se convierte en el componente seleccionado.

9

[...]

public void

OnSelect(BaseEventData

eventData){

play ();

NavItems ni =

GetComponentInParent<NavItems>

();

if (ni != null)

ni.selectEspecific (this);

}

[...]

}

IDeselectHandler:

using UnityEngine.EventSystems;

[RequireComponent(typeof(Selectabl

e))]

public class Item: MonoBehaviour,

[...],

IDeselectHandler,[...]{

[...]

public void

OnDeselect(BaseEventData

eventData){

select = false;

}

[...]

}

Cuando se deselecciona el GameObject, se activa este evento.

10

• System, System.Data y Mono.Sata.sqlite

Nombre Librería System, System.Data y Mono.Data.Sqlite

Descripción Librería

Estas librerías se utilizan para la manipulación de la base de datos SQLITE.

Implementación Descripción

[…]

using System;

using System.Data;

using Mono.Data.Sqlite;

public static class CRUD

{

[…]

[…]

}

Esta clase estática controla el flujo de datos de la base de datos SQLite.

Se puede hacer CRUD, o incuso crear la estructura de la base de datos.

11

4. SCRIPTS

4.1. Clases estáticas

• varScore: Representa el Score del jugador; las operaciones correctas, los intentos (número de veces que no respondió bien), puntos, y la duración del juego.

• varGameOper: Contiene un ArrayList donde se ubicarán las operaciones que vayan apareciendo a lo largo del juego, así como los atributos dentro de la interfaz gráfica; velocidad, color, tamaño, cantidad de operaciones, que operaciones aparecerán, entre otros aspectos. El llenado de la lista de operaciones es realizado por la clase ‘Resultado’.

• Usuario: Guarda la información del usuario (No ADMIN) que ingresa

al programa, y dependiendo de esa información se activa un panel u

otro, por ejemplo, si el usuario no presenta ningún tipo de discapacidad

visual, las opciones de configuración van a ser más que las de aquellos

usuarios que si presenten una limitación visual. Estas acciones se

controlan con la clase ‘SQLiteLogin’, la cual decide qué panel se

mostrará.

• CRUD: Controlador de las instrucciones hechas a la base de datos

SQLite, este tiene dos métodos estáticos, uno controla las peticiones,

es decir las consultas y el otro controla las demás opciones.

4.2. Otras clases

• Item y NavItems: Estas son de las clases más importantes del programa, ya que son las responsables de la interacción del usuario invidente.

La clase ‘Item’ se le agrega a cada GameObject con el cual el usuario tenga interacción y por lo tanto requiera el sonido, como por ejemplo al ingresar el usuario, la contraseña, el botón de ingresar, al momento de seleccionar si quiere jugar con las sumas, restas o demás; todos esos componentes tienen la clase ‘Item’.

12

La clase ‘NavItems’ es el padre de las clases ’Item’, este controla los eventos del teclado (flecha arriba, flecha abajo, control, shift). Por ejemplo, si el usuario oprime flecha arriba o flecha abajo ‘NavItems’ se encarga de desplazarse por los ítems de arriba o abajo respectivamente, la tecla control sirve para repetir lo que se ha escrito (Solo sirve para la sección del logueo) y Shift sirve para repetir el sonido del componente.

‘NavItems’ contiene un vector público ‘Items’ de tipo ‘Item’, el cual se llena por medio de una función del MonoBehaviour, la cual es ‘GetComponentsInChildren<Item> ()’. Esta función lo que hace es generar un vector con los componentes hijos de tipo ‘Item’, de esta manera se llena el vector. ‘NavItems’ permite la comunicación entre otras clases de esa misma clase, por ejemplo se tiene GameObject1 y GameObject2 y cada uno contiene la clase ’NavItems’. Para la comunicación entre esos dos componentes hay que asignar al GameObject1 al atributo otherDown del GameObject2 y al GameObject2 al atributo otherUp del GameObject1; de ésta manera el usuario solo necesita navegar con flecha arriba y flecha abajo. Lo que a nivel de programación quedaría de la siguiente manera:

GameObject1 Contiene ’NavItems’ GameObject2 Contiene ‘NavItems’

GameObject1.otherDown = GameObject2

GameObject2.otherUp = GameObject1

La instanciación se hace por medio del Editor de Unity arrastrando el componente.

• Resultado y Operación

Resultado:

Se encarga de generar operaciones tanto en el juego como en la configuración de los usuarios dependiendo de tiene discapacidades visuales o no, de los valores de las operaciones, de la operación,

13

validar divisiones por cero y decidir si se reproduce o no el sonido de la operación, entre otras funciones. Cuando se está en el menú de opciones no se capturan los eventos del teclado numérico, es decir no se juega. Otras de sus funcionalidades son:

- Captura los eventos de teclado numérico en el juego, cuando el usuario está respondiendo. Además de la tecla ‘Enter’ y ‘Delete’.

- Es el encargado de comprobar si el número digitado coincide con el resultado de la(s) operación(es) en el juego.

- Encargado de asignar la velocidad a cada operación.

Operación:

- Se encarga de moverse según la velocidad asignada.

- Valida si se ha pasado del valor mínimo en la pantalla, si es así desaparece y envía un mensaje a ‘Resultado’ para que la vida disminuya.

- Ejecuta la animación para desaparecer la operación.

• Table: Las tablas que aparecen en la sección del administrador son generadas por esta clase, la información allí presente es tomada de la base de datos. Tiene la opción de seleccionar un registro activando en el editor de Unity el atributo ‘selReg’ e instanciando el atributo ‘valor’ con un elemento UI Text, de esta forma el primer valor del registro que se seleccione se mostrará en el componente ‘Text’. Si se desactiva no se permite la selección de ningún registro. El registro seleccionado aparece de color más oscuro y el que no está seleccionado más claro, esto se puede configurar en el inspector cambiando el color de los atributos ColorNormal y ColorPressed. El espacio entre cada registro corresponde al atributo ‘Space’.

14

En la siguiente imagen se puede evidenciar lo mencionad anteriormente:

• ClipsGoodBad, ClipsLetras, ClipsNumeros, ClipsOperaciones y

ManagerAudioNumbers:

ManagerAudioNumbers: Es otra parte fundamental del programa ya que este es el responsable de coordinar los sonidos que se van a reproducir. Este se apoya de los sonidos de las letras, de los números, de los operadores entre otros. Cabe destacar que el sonido de fondo es independiente. El volumen de todo el juego se controla con flecha izquierda y flecha derecha en el teclado para bajar o subir el volumen respectivamente.

5. Posibles Inconvenientes

• El software está especialmente hecho para usuarios con problemas visuales,

es decir se basa en los sonidos para la interacción. Si el usuario posee

problemas auditivos, cognitivos o de otra índole pueda que presente

problemas al interactuar con el software.

15

• Al momento de realizarse el registro de varios tipos de condiciones se

presenta una dificultad en el registro de un nuevo usuario. Las condiciones

visuales se salen del panel y por tal no se pueden seleccionar algunas de las

opciones, como se evidencia a continuación:

182

4-4-2017

ANEXO C

[Modelo Relacional]

183

ANEXO C. MODELO RELACIONAL

Anexo C. Modelo Relacional

184

4-4-2017

Anexo D. Formato encuesta levantamiento de requerimientos

ANEXO D [Formato Encuestas

Levantamiento de Requerimientos]

185

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS ENCUENTAS PARA EL LEVANTAMIENTO DE REQUERIMIENTOS

ENCUESTA TIPO 1: ESTUDIANTES

Nombres: _____________________________________ Edad: _____________

Apellidos: _____________________________________ Curso: _____________

Discapacidad visual: Si ____ No ____ Tipo discapacidad: ____________________

Objetivo de la encuesta: Recolectar la información necesaria para la definición de los requerimientos asociados a la fase de planificación del proyecto; es decir, obtener la información necesaria para la definición de los aspectos clave a manejar en el desarrollo del software, teniendo en cuenta la opinión del usuario principal (estudiantes), con el objetivo de orientar el proyecto a las capacidades y requerimientos de los mismos.

• Relación: estudiante - matemáticas:

1. ¿Te gustan las matemáticas?

a. Si: ____

b. No: ____

1.1. ¿Por qué?

______________________________________________________________________________________________________________________________________________________________________________

2. En una escala de 1 – 5 especifica el gusto que tienes hacia las

matemáticas:

1: ____ 2: ____ 3: ____ 4: ____ 5: ____

3. ¿Te parece que las matemáticas se te dificultan?

a. Si: ____

b. No: ____

186

3.1. ¿Por qué?

____________________________________________________________________________________________________________________

4. ¿Se te facilita resolver operaciones matemáticas básicas (suma, resta,

multiplicación y división)?

a. Si: ____

b. No: ____

4.1. ¿Por qué?

___________________________________________________________________________________________________________________________________________________________________________

5. De las siguientes operaciones ¿Cuáles manejas?

a. Suma:

b. Resta:

c. Multiplicación:

d. División:

• Relación: estudiante – TICs

1. ¿Conoces el término “Tecnología de la Información y la Comunicación

(TICs)”

a. Si: ____

b. No: ____

2. ¿Haces uso de las TICs en tu proceso académico en el colegio?

a. Si: ____

b. No: ____

Bien ____ Regular ____ Mal ____ Bien ____ Regular ____ Mal ____ Bien ____ Regular ____ Mal ____ Bien ____ Regular ____ Mal ____

187

3. ¿Dentro de las materias de tu grado académico cuentan con alguna que

implemente el uso de las TICs, tales como tecnología, informática, u otra?

a. Si: ____ ¿Cuál? ________________________

b. No: ____

4. De ser así, ¿cuentan con el uso de espacios dedicados a la materia, tales

como un aula de informática u otra?

a. Si: ____ ¿Cuál? ________________________

b. No: ____

5. ¿Cómo es tu desarrollo frente a la materia?

______________________________________________________________________________________________________________________________________________________________________________

• Aspectos relacionados al desarrollo del proyecto:

1. ¿Usualmente haces uso del computador?

a. Si: ____

b. No: ____

1.1. ¿Cuánto tiempo dedicas al uso del computador?

a. Menos de 1 hora diaria: _____

b. 1 a 2 horas diarias: _____

c. 2 a 4 horas diarias: _____

d. Más de 4 horas diarias: _____

1.2. ¿Qué tipo de actividades realizas en el computador?

a. Educativas: ____

b. Uso de videojuegos: ____

c. Navegación en redes sociales: ____

188

2. ¿Te gustan los videojuegos?

a. Si: ____

b. No: ____

2.1. ¿Qué tipo de videojuegos te gustan?

a. Acción: ____

b. Estrategia: ____

c. Simulación: ____

d. Deporte: ____

e. Rol: ____

f. Educativos: ____

¿Por qué?

___________________________________________________________________________________________________________________________________________________________________________

3. ¿Te gustaría hacer uso de un videojuego que te permitiera practicar las

matemáticas?

a. Si: ____

b. No: ____

¿Por qué? ___________________________________________________________________________________________________________________________________________________________________________

4. ¿Te gustaría que en tu colegio haya este tipo de videojuegos?

a. Si: ____

b. No: ____

4.1. ¿Utilizarías el videojuego?

a. Si: ____

b. No: ____

189

¿Por qué?

___________________________________________________________________________________________________________________________________________________________________________

5. ¿Te gustaría que el colegio implementará el uso de las Tecnologías de la

Información y la Comunicación como herramienta educativa en otras

áreas académicas, tales como español, biología, sociales, entre otras?

a. Si: ____

b. No: ____

• Test matemático:

Objetivo: El objetivo de este test matemático es medir el manejo que los estudiantes tienen frente a la elaboración de operaciones básicas matemáticas, con la finalidad de obtener valores cuantitativos que definirán aspectos asociados al desarrollo del software educativo. ◦ Suma:

- 0 + 3 = Tiempo respuesta: _______

- 2 + 4 = Tiempo respuesta: _______

- 7 + 8 = Tiempo respuesta: _______

- 10 + 2 = Tiempo respuesta: _______

- 25 + 3 = Tiempo respuesta: _______

- 11 + 11 = Tiempo respuesta: _______

- 19 + 3 = Tiempo respuesta: _______

- 23 + 7 = Tiempo respuesta: _______

- 42 + 19 = Tiempo respuesta: _______

- 94 + 5 = Tiempo respuesta: _______

◦ Resta:

- 2 - 0 = Tiempo respuesta: _______

- 3 - 3 = Tiempo respuesta: _______

- 8 - 3 = Tiempo respuesta: _______

- 10 - 4 = Tiempo respuesta: _______

- 12 - 3 = Tiempo respuesta: _______

190

- 15 - 9 = Tiempo respuesta: _______

- 20 - 7 = Tiempo respuesta: _______

- 32 - 12 = Tiempo respuesta: _______

- 45 - 11 = Tiempo respuesta: _______

- 98 - 12 = Tiempo respuesta: _______

◦ Multiplicación:

- 1 x 0 = Tiempo respuesta: _______

- 5 x 1 = Tiempo respuesta: _______

- 6 x 2 = Tiempo respuesta: _______

- 3 x 4 = Tiempo respuesta: _______

- 6 x 6 = Tiempo respuesta: _______

- 4 x 8 = Tiempo respuesta: _______

- 7 x 9 = Tiempo respuesta: _______

- 11 x 3 = Tiempo respuesta: _______

- 13 x 4 = Tiempo respuesta: _______

- 20 x 13 = Tiempo respuesta: _______

◦ División

- 2 ÷ 0 = Tiempo respuesta: _______

- 4 ÷ 1 = Tiempo respuesta: _______

- 6 ÷ 2 = Tiempo respuesta: _______

- 9 ÷ 3 = Tiempo respuesta: _______

- 10 ÷ 5 = Tiempo respuesta: _______

- 18 ÷ 6 = Tiempo respuesta: _______

- 28 ÷ 7 = Tiempo respuesta: _______

- 56 ÷ 8 = Tiempo respuesta: _______

- 22 ÷ 11 = Tiempo respuesta: _______

- 24 ÷ 12 = Tiempo respuesta: _______

◦ Combinación suma y resta

- 5 + 3 + 2 = Tiempo respuesta: _______

- 9 + 2 + 5 = Tiempo respuesta: _______

- 12 + 7 + 2 = Tiempo respuesta: _______

- 20 + 12 + 1 = Tiempo respuesta: _______

- 9 – 4 – 1 = Tiempo respuesta: _______

- 12 – 5 – 2 = Tiempo respuesta: _______

- 20 – 10 – 3 = Tiempo respuesta: _______

- 52 – 23 – 1 = Tiempo respuesta: _______

191

4-4-2017

Anexo E. Formato pruebas TAM

ANEXO E [Formato pruebas TAM:

Estudiantes]

192

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

ENCUENTAS PRUEBAS TIPO TAM

ENCUESTA TIPO 1: ESTUDIANTES

Nombre: _____________________________________ Curso: _____________

• Utilidad percibida (PU)

Bajo Medio Alto

1. ¿El uso del software te permite apoyar tu proceso de aprendizaje de las operaciones básicas matemáticas?

2. ¿El uso de este software te ayudará a mejorar la solución de operaciones básicas?

3. ¿El uso de este software te ayudará a mejorar tu concentración y comprensión?

4. ¿El uso de este software te ofrecerá nuevas experiencias útiles?

• Facilidad de Uso Percibida (PEOU)

Bajo Medio Alto

1. ¿Es cómodo el uso del software?

2. ¿Aprender a usar el software se te facilita?

3. ¿Se te facilita entender cómo jugar?

4. ¿Las diferentes funciones son entendibles?

5. ¿Encuentras el software fácil de usar?

6. ¿ Podrías llegar a ser un experto en el manejo del software?

193

• Actitud hacia el uso (A)

Bajo Medio Alto

1. ¿Encuentras entretenido el software?

2. ¿El usuario puede utilizar bien el sistema?

3. ¿El usuario invierte su tiempo en el sistema?

4. ¿El usuario se interesa por adquirir el producto?

5. ¿El usuario demuestra avances frente al uso del software?

194

4-4-2017

ANEXO E [Formato pruebas TAM:

Docentes]

195

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS ENCUENTAS PRUEBAS TIPO TAM

ENCUESTA TIPO 2: DOCENTES

Nombre: _____________________________________ Curso: _____________

Objetivo: El objetivo de la presente encuesta es evaluar diversos aspectos relacionados tanto con la funcionalidad del software como con la aceptación y utilidad percibida por el usuario, en este caso, los docentes; en referencia al uso del sistema.

Desarrollo: Conteste las siguientes preguntas teniendo en cuenta su experiencia en cuanto al uso del software, marque X según el nivel que considere:

Encuesta:

• Utilidad percibida (PU)

Bajo Medio Alto

1. ¿Considera que el software permite apoyar el proceso de aprendizaje de las operaciones básicas matemáticas de los estudiantes ?

2. ¿Considera que el software es una herramienta de innovación tecnológica que aportará grandes ventajas a los estudiantes?

3. ¿Considera que el software será una herramienta que suministrará grandes aportes al desarrollo en la materia que usted imparte?

4. ¿El software le ofrece funcionalidades orientadas a su rol de docente?

5. ¿Los módulos orientados a los docentes serán de gran ayuda para su proceso de enseñanza?

196

• Facilidad de Uso Percibida (PEOU)

Bajo Medio Alto

1. ¿Se le facilita aprender a usar el software?

2. ¿El uso del software es cómodo?

3. ¿Se le facilita entender los diferentes módulos y funcionalidades del sistema?

4. ¿Encuentra fácil el uso del software?

5. ¿Considera que podría llegar a ser un experto en el manejo del software?

6. ¿Considera que a los estudiantes se les facilitará el uso del software?

• Actitud hacia el uso (A)

Bajo Medio Alto

1. ¿Encuentra interesante el software y las funcionalidades que éste ofrece?

2. ¿Considera que el software puede ser atractivo para los estudiantes?

3. ¿El usuario puede utilizar bien el sistema?

4. ¿El usuario invierte su tiempo en el sistema?

5. ¿El usuario se interesa por adquirir el producto?