PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO
Dirección de Postgrados
APLICATIVO MÓVIL CON MACHINE LEARNING PARA EL FORTALECIMIENTO DE LA COMUNICACIÓN DE LENGUA DE SEÑAS ECUATORIANA, EN LA CARRERA DE GASTRONOMÍA DEL INSTITUTO SUPERIOR TECNOLÓGICO CALAZACÓN. Trabajo de Titulación previo a la obtención del título de Magíster en Tecnologías de la Información Modalidad Proyecto de titulación con componente de investigación aplicada y/o desarrolloMTI Línea de Investigación: Tecnologías de la información y la comunicación. Autoría: JENEFFER JOSELIN BARBERÁN MOREIRA MIGUEL ÁNGEL MANTUANO CASUAL Dirección: Mg. WILLIAN JAVIER OCAMPO PAZOS Santo Domingo – Ecuador Julio, 2021
PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO
Dirección de Postgrados
HOJA DE APROBACIÓN APLICATIVO MÓVIL CON MACHINE LEARNING PARA EL FORTALECIMIENTO DE LA COMUNICACIÓN DE LENGUA DE SEÑAS ECUATORIANA, EN LA CARRERA DE GASTRONOMÍA DEL INSTITUTO SUPERIOR TECNOLÓGICO CALAZACÓN Línea de Investigación: Tecnologías de la información y la comunicación. Autoría: JENEFFER JOSELIN BARBERÁN MOREIRA MIGUEL ÁNGEL MANTUANO CASUAL
Willian Javier Ocampo Pazos, Mg. DIRECTOR DE TRABAJO DE TITULACIÓN Rodolfo Sirilo Córdova Gálvez, Mg.
CALIFICADOR Fausto Ernesto Orozco Iguasnia, Mg.
CALIFICADOR Yullio Cano de la Cruz, Mg DIRECTOR DE POSTGRADOS f._____________________
f._____________________
Santo Domingo – Ecuador Julio, 2021
iv
v
INFORME DE TRABAJO DE TITULACIÓN ESCRITO DE POSTGRADO Yullio Cano de la Cruz, Mg. Dirección de Postgrados Pontificia Universidad Católica del Ecuador Sede Santo Domingo De mi consideración, Por medio del presente informe en calidad del director/a del Trabajo de Titulación de Postgrado de MAESTRÍA EN TECNOLOGÍAS DE LA INFORMACIÓN, titulado APLICATIVO MÓVIL CON MACHINE LEARNING PARA EL FORTALECIMIENTO DE LA COMUNICACIÓN DE LENGUA DE SEÑAS ECUATORIANA, EN LA CARRERA DE GASTRONOMÍA DEL INSTITUTO SUPERIOR TECNOLÓGICO CALAZACÓN, realizado por los maestrantes: Jeneffer Joselin Barberán Moreira con cédula: 1718960360 y Miguel Ángel Mantuano Casual con cédula: 1722394770, previo a la obtención del Título de Magíster en Tecnologías de la Información, informo que el presente trabajo de titulación escrito se encuentra finalizado conforme a la guía y el formato de la Sede vigente. Santo Domingo, 29 de julio de 2021.
Atentamente, Ing. Willian Javier Ocampo Pazos, Mg. Profesor Titular Auxiliar I
vi
AGRADECIMIENTOS Agradezco a Dios por concederme el hermoso don de la vida, por mostrarme el camino correcto a seguir a pesar de las dificultades, ayudarme a levantar, seguir, no decaer ante nada y haber logrado llegar a esta meta propuesta. A mi madre por ser mi apoyo incondicional siempre en todas las situaciones posibles y por su infinito amor que me motiva a crecer cada vez más. A toda la comunidad educativa Instituto Superior Tecnológico Calazacón por permitirme desarrollar este proyecto en su prestigiosa institución junto a sus catedráticos y estudiantes con discapacidad auditiva, por permitir aportar A la Pontificia Universidad Católica del Ecuador PUCE Sede Santo Domingo, por permitir formarme en esta etapa de mis estudios. A nuestro director de Trabajo de Titulación el Ing. Willian Javier Ocampo Pazos, Mg. Por su aporte, dedicación y gran ayuda en el desarrollo de este trabajo de investigación. A mis compañeros de clase que junto a ellos he recorrido esta etapa que culmina y que es de infinita motivación y muy grata a su vez por el significado invaluable que representa, en especial a Jeneffer Joselin Barberán Moreira por ser mi compañera de trabajo de titulación y que ha sido de gran ayuda y aporte en el desarrollo y culminación del mismo. Muchas gracias a todos.
Miguel Ángel Mantuano Casual
vii
AGRADECIMIENTOS Quiero expresar mi agradecimiento a todas las personas que colaboraron en la realización del trabajo de titulación por medio de su aporte científico y humano. Agradezco al Instituto Superior Tecnológico Calazacón que ha hecho posible la realización del trabajo al permitirnos desarrollar el proyecto es su prestigiosa institución, junto a los docentes y estudiantes que forman parte de la carrera de Gastronomía. Muy especialmente a mi director de Trabajo de Titulación el Ing. Willian Javier Ocampo Pazos, Mg, por la acertada orientación que permitió la realización del trabajo de investigación. A mis compañeros de maestría, especialmente a mi compañero de trabajo de titulación Miguel Ángel Mantuano Casual por esos momentos de apoyo en el desarrollo de mismo. Finalmente, agradezco a mi familia por su comprensión, comunicación constante y apoyo incondicional. De manera muy especial a mi esposo Franklin Torres y mi hijo Jherath Torres quienes han estado a mi lado durante este proceso y me dieron las fuerzas para llegar hasta el final. Muchas gracias a todos.
Jeneffer Joselin Barberán Moreira
viii
DEDICATORIA El presente trabajo de titulación está dedicado a Dios y a toda mi familia. A Dios por darme la vida y permitirme alcanzar una nueva meta como persona y profesional; a mis padres Isabel Moreira y Ricter Cercado por brindarme su cariño, amor y apoyo incondicional ya que son el principal cimiento para la construcción de mi vida profesional. A mi esposo Franklin Torres y mi hijo Jherath quienes han estado a mi lado compartiendo mis alegrías y angustias, brindándome apoyo y ayuda incondicional en cada momento, gracias a ellos encontré las fuerzas necesarias para llegar hasta el final de esta etapa. Jeneffer Joselin Barberán Moreira
El presente trabajo investigativo está dedicado a Dios y a toda mi familia. A Dios por darme la oportunidad de culminar esta nueva etapa de mi vida y poder apreciar que cuando existe perseverancia, constancia, dedicación y responsabilidad se puede conseguir lo que uno se proponga. A mi madre María Casual quien ha sido el pilar fundamental durante toda mi carrera, a quien le debo absolutamente todo de inicio a fin, por los buenos valores inculcados y por esa actitud positiva de que pase lo que pase siempre hay que seguir adelante y no dejarse vencer jamás. ¡Amo a mi madre! A mis hermanas Mayra, Jessica, Carolina y Verónica, quienes han sido mi motivación y que me han estado apoyado siempre dándome ese aliento que necesito para no decaer y seguir hacia adelante. Miguel Ángel Mantuano Casual
ix
RESUMEN En la actualidad, la comunicación entre estudiantes con discapacidad auditiva y demás actores que forman un establecimiento educativo, posee una brecha a pesar de existir los recursos tecnológicos. En la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón del cantón Santo Domingo, se evidenció a docentes con escaso conocimiento en lengua de señas ecuatoriana, los intérpretes poseen nociones básicas sobre terminología técnica, lo que dificulta la comunicación en las asignaturas que imparten. La metodología empleada en esta investigación es de enfoque mixto (cualitativo y cuantitativo), el tipo de investigación es aplicada con un alcance descriptivo y el experimento es de campo. Los resultados se componen de 3 etapas: en la primera se conoció las necesidades educativas mediante la entrevista a la intérprete de lengua señas y docentes de la carrera; en la segunda se empleó un sistema pictográfico basado en lengua de señas que los estudiantes pactaron junto a su intérprete y este a su vez fue generado en archivos .GIF para su correcta interpretación; en la tercera se desarrolló e implementó el aplicativo móvil “SignIES”, en el lenguaje Java, Payara como servidor y Oracle XE. Se aplicó la encuesta en dos escenarios (antes y después) a 163 personas, en donde 160 son oyentes y 3 son estudiantes con discapacidad auditiva. Se validó la hipótesis alternativa donde se determinó que el aplicativo móvil con machine learning influye significativamente en la comunicación de lengua de señas ecuatoriana, en la carrera mencionada en esta investigación. Palabras clave: Machine learning; Aplicativo móvil; Android; Discapacidad auditiva; Lengua de señas ecuatoriana.
x
ABSTRACT At present, communication between students with hearing impairment and other members that constitute an educational establishment, has a gap, despite the existence of technological resources. In the Gastronomy career at the Calazacón Higher Technological Institute in the city of Santo Domingo, teachers with little knowledge of Ecuadorian sign language were evidenced, interpreters have basic notions about technical terminology, which makes communication difficult in the subjects they teach. The methodology used in this research is of a mixed approach (qualitative and quantitative), the type of research is applied with a descriptive scope and the experiment is in the field. The results are made up of 3 stages: in the first, the educational needs were met by interviewing the sign language interpreter and from the career; In the second, a pictographic system based on sign language was used, which the students agreed with their interpreter and this in turn was generated in .GIF files for its correct interpretation; in the third, the mobile application "SignIES" was developed and implemented, in the Java language, Payara as a server and Oracle XE. The survey was applied in two scenarios (before and after) to 163 people, where 160 are listeners and 3 are students with hearing disabilities. The alternative hypothesis was validated where it was determined that the mobile application with machine learning significantly influences the communication of the Ecuadorian sign language, in the career mentioned in this research. Keywords: Machine learning; Mobile application; Android; Hearing impairment; Ecuadorian sign language.
xi
ÍNDICE DE CONTENIDOS
1.
INTRODUCCIÓN.............................................................................................. 1
1.1.
Antecedentes ........................................................................................................ 1
1.2.
Delimitación del problema ................................................................................... 2
1.3.
Formulación y sistematización del problema ....................................................... 3
1.3.1.
Formulación del problema. .................................................................................. 3
1.3.2.
Sistematización del problema. Preguntas específicas. ......................................... 3
1.4.
Justificación de la investigación........................................................................... 3
1.5.
Objetivos de la investigación ............................................................................... 4
1.5.1.
Objetivo general. .................................................................................................. 4
1.5.2.
Objetivos específicos. .......................................................................................... 4
2.
REVISIÓN DE LA LITERATURA ................................................................. 6
2.1.
Fundamentos teóricos........................................................................................... 6
2.1.1.
Aplicativo móvil................................................................................................... 7
2.1.1.1.
Sistemas Operativos móviles ............................................................................... 7
2.1.1.1.1.
Android ................................................................................................................ 7
2.1.1.1.2.
iOS........................................................................................................................ 7
2.1.1.1.3.
Windows Phone ................................................................................................... 8
2.1.1.2.
Aplicación móvil .................................................................................................. 8
2.1.1.2.1.
Nativa ................................................................................................................... 8
2.1.1.2.2.
Web ...................................................................................................................... 9
2.1.1.2.3.
Hibrida.................................................................................................................. 9
2.1.1.3.
Lenguaje de programación ................................................................................... 9
2.1.1.3.1.
Java ....................................................................................................................... 9
2.1.1.3.2.
JavaScript ........................................................................................................... 10
xii 2.1.1.3.3.
Kotlin.................................................................................................................. 10
2.1.1.4.
Accesibilidad de aplicaciones móviles............................................................... 10
2.1.1.4.1.
Principios de desarrollo de aplicaciones móviles accesibles ............................. 10
2.1.1.4.2.
Herramientas de evaluación de accesibilidad..................................................... 11
2.1.1.4.3.
Productos o herramientas de apoyo .................................................................... 11
2.1.2.
Machine Learning o aprendizaje automático ..................................................... 12
2.1.2.1.
Modelos de Machine Learning........................................................................... 12
2.1.2.1.1.
Modelo Probabilístico ........................................................................................ 12
2.1.2.1.2.
Modelo Lógico ................................................................................................... 12
2.1.2.2.
Tipos de Aprendizaje de Machine Learning ...................................................... 13
2.1.2.2.1.
Aprendizaje supervisado .................................................................................... 13
2.1.2.2.2.
Aprendizaje no supervisado ............................................................................... 13
2.1.2.2.3.
Aprendizaje por refuerzo .................................................................................... 14
2.1.3.
Lengua de señas ecuatorianas (LSEC) ............................................................... 14
2.1.3.1.
Técnicas de interpretación.................................................................................. 15
2.1.3.1.1.
Interpretación simultanea ................................................................................... 15
2.1.3.1.2.
Interpretación consecutiva ................................................................................. 15
2.1.3.2.
Tipos de interpretación ....................................................................................... 15
2.1.3.2.1.
Interpretación Bilateral o de contacto ................................................................ 15
2.1.3.2.2.
Interpretación Unilateral .................................................................................... 16
2.1.3.3.
Gramática de la Lengua de Señas Ecuatoriana .................................................. 16
2.1.3.3.1.
Fonología............................................................................................................ 16
2.1.3.3.2.
Sintaxis ............................................................................................................... 16
2.1.3.3.3.
Morfología.......................................................................................................... 17
2.2.
Predicción científica ........................................................................................... 17
3.
METODOLOGÍA DE LA INVESTIGACIÓN ............................................. 18
xiii 3.1.
Enfoque, diseño y tipo de investigación ............................................................ 18
3.1.1.
Enfoque .............................................................................................................. 18
3.1.2.
Diseño de la investigación ................................................................................. 18
3.1.3.
Tipo de investigación ......................................................................................... 19
3.2.
Población y muestra ........................................................................................... 19
3.3.
Operacionalización de las variables ................................................................... 21
3.4.
Técnicas e instrumentos de recogida de datos ................................................... 25
3.4.1.
Encuesta ............................................................................................................. 25
3.4.2.
Entrevista............................................................................................................ 25
3.5.
Técnicas de análisis de datos.............................................................................. 25
4.
RESULTADOS ................................................................................................. 26
4.1.
Resultado uno: Necesidades comunicativas de los estudiantes con DA ............ 26
4.1.1.
Resultados de la entrevista a la intérprete de LSEC .......................................... 26
4.1.2.
Resultados de las entrevistas a los docentes de la carrera de Gastronomía ....... 28
4.1.3.
Diagrama de actividades del proceso de comunicación ..................................... 31
4.1.4.
Resultados de las encuestas a la comunidad educativa oyente .......................... 32
4.1.5.
Resultados de las encuestas a la comunidad educativa con DA ........................ 37
4.2.
Resultado dos: Sistema pictográfico para estudiantes con DA .......................... 42
4.2.1.
Sistema pictográfico ........................................................................................... 42
4.2.1.1.
Ventajas de los pictogramas ............................................................................... 43
4.2.1.2.
¿Cómo se elaboran los pictogramas? ................................................................. 43
4.2.1.3.
Pictogramas como medio de comunicación ....................................................... 44
4.2.2.
Diagrama del proceso de pactar señas ............................................................... 44
4.2.3.
Pictogramas desarrollados .................................................................................. 45
4.3.
Resultado tres: Aplicativo móvil con machine learning .................................... 46
4.3.1.
Nomenclatura y logotipo .................................................................................... 46
xiv 4.3.2.
Marco de trabajo Scrum ..................................................................................... 47
4.3.3.
Sprint 1 ............................................................................................................... 47
4.3.3.1.
Planificación del Sprint 1 ................................................................................... 47
4.3.3.1.1.
Roles ................................................................................................................... 47
4.3.3.1.2.
Arquitectura de Software ................................................................................... 47
4.3.3.1.3.
Parametrización .................................................................................................. 48
4.3.3.1.4.
Control de versiones ........................................................................................... 48
4.3.3.1.5.
Product Backlog ................................................................................................. 49
4.3.3.1.6.
Estimación .......................................................................................................... 49
4.3.3.1.7.
Velocidad de desarrollo...................................................................................... 49
4.3.3.1.8.
Fertilización cruzada .......................................................................................... 49
4.3.3.1.9.
Escenarios de prueba .......................................................................................... 50
4.3.3.1.10.
Gestión de incidencias ........................................................................................ 50
4.3.3.1.11.
Sprint Backlog .................................................................................................... 51
4.3.3.2.
Reuniones diarias del Sprint 1 –Daily Scrum .................................................... 52
4.3.3.2.1.
Historia de usuario 1: Login ............................................................................... 52
4.3.3.2.2.
Historia de usuario 2: Registro ........................................................................... 55
4.3.3.2.3.
Historia de usuario 3: Contacto .......................................................................... 57
4.3.3.2.4.
Gráfico de trabajo pendiente del Sprint 1 .......................................................... 59
4.3.3.3.
Revisión del Sprint 1 .......................................................................................... 59
4.3.3.4.
Retrospectiva del Sprint 1 .................................................................................. 60
4.3.4.
Sprint 2 ............................................................................................................... 60
4.3.4.1.
Planificación del sprint 2 – Sprint Planning ....................................................... 60
4.3.4.2.
Reuniones diarias del Sprint 2 –Daily Scrum .................................................... 61
4.3.4.2.1.
Historia de usuario 4: Chat ................................................................................. 61
4.3.4.2.2.
Historia de usuario 5: Categorías ....................................................................... 64
xv 4.3.4.2.3.
Historia de usuario 8: Destacar .......................................................................... 66
4.3.4.2.4.
Historia de usuario 9: Reenviar .......................................................................... 67
4.3.4.2.5.
Gráfico de trabajo pendiente del Sprint 2 .......................................................... 68
4.3.4.3.
Revisión del Sprint 2 .......................................................................................... 68
4.3.4.4.
Retrospectiva del Sprint 2 .................................................................................. 69
4.3.5.
Sprint 3 ............................................................................................................... 69
4.3.5.1.
Planificación del sprint 3 – Sprint Planning ....................................................... 69
4.3.5.2.
Reuniones diarias del Sprint 3 –Daily Scrum .................................................... 70
4.3.5.2.1.
Historia de usuario 7: Machine learning ............................................................ 70
4.3.5.2.2.
Historia de usuario 6: Pictogramas .................................................................... 80
4.3.5.2.3.
Historia de usuario 10: Perfil de Usuario ........................................................... 82
4.3.5.2.4.
Historia técnica 1: Disponibilidad ...................................................................... 84
4.3.5.2.5.
Historia técnica 2: Rendimiento ......................................................................... 84
4.3.5.2.6.
Gráfico de trabajo pendiente del Sprint 3 .......................................................... 85
4.3.5.3.
Revisión del Sprint 3 .......................................................................................... 85
4.3.5.4.
Retrospectiva del Sprint 3 .................................................................................. 85
4.4.
Validación de Hipótesis ..................................................................................... 86
5.
DISCUSIÓN...................................................................................................... 88
6.
CONCLUSIONES Y RECOMENDACIONES ............................................. 90
6.1.
Conclusiones ...................................................................................................... 90
6.2.
Recomendaciones ............................................................................................... 91
7.
REFERENCIAS BIBLIOGRÁFICAS ........................................................... 92
8.
ANEXOS ........................................................................................................... 96
Anexo I. Carta de aprobación, tabla de recursos, cronograma y acta de entrega .................... 96 Anexo II. Carta de impacto, consentimiento informado, árbol del problema.......................... 97 Anexo III. Validación de los instrumentos por el experto en investigación ............................ 98
xvi Anexo IV. Validación de los instrumentos por el experto en estadística .............................. 101 Anexo V. Validación de los instrumentos por el experto en Lengua de Señas Ecuatoriana . 104 Anexo VI. Evidencia de las encuestas y entrevistas .............................................................. 107 Anexo VII. Historias de usuario y escenarios de prueba ....................................................... 108 Anexo VIII. Pruebas de aceptación del primer Sprint ........................................................... 111 Anexo IX. Pruebas de aceptación del segundo Sprint ........................................................... 112 Anexo X. Pruebas de aceptación del tercer Sprint ................................................................. 113 Anexo XI. Manual de Usuario ............................................................................................... 114 Anexo XII. Manual Técnico .................................................................................................. 121
ÍNDICE DE FIGURAS Figura 1. Índice de la revisión de literatura de la variable independiente aplicativo móvil ...... 6 Figura 2. Índice de la revisión de literatura de la variable independiente machine learning ..... 6 Figura 3. Índice de la revisión de literatura de la variable dependiente LSEC .......................... 6 Figura 4. Fórmula para calcular la muestra de una población finita ........................................ 20 Figura 5. Diagrama del proceso de una clase regular .............................................................. 31 Figura 6. Relación del nivel de frecuencia de aplicaciones de mensajería .............................. 32 Figura 7. Probabilidad de comunicación en tiempo real.......................................................... 32 Figura 8. Nivel de frecuencia de uso de aplicaciones que sugieren predicciones ................... 33 Figura 9. Tipo de aplicaciones en los dispositivos digitales .................................................... 34 Figura 10. Cantidad de aplicaciones en el celular.................................................................... 34 Figura 11. Sistema operativo en el móvil ................................................................................ 35 Figura 12. Probabilidad de poder transmitir una idea a un estudiante con DA ....................... 35 Figura 13. Aplicaciones en el celular con accesibilidad para personas con DA...................... 36 Figura 14. Aplicaciones de mensajería que permiten la comunicación mediante LSEC ........ 37
xvii Figura 15. Relación del nivel de frecuencia de aplicaciones de mensajería ............................ 38 Figura 16. Probabilidad de comunicación en tiempo real con personas oyentes..................... 38 Figura 17. Nivel de frecuencia de uso de aplicaciones que sugieren predicciones ................. 39 Figura 18. Tipo de aplicaciones en los dispositivos digitales .................................................. 39 Figura 19. Cantidad de aplicaciones en el celular.................................................................... 40 Figura 20. Sistema operativo en el móvil ................................................................................ 40 Figura 21. Probabilidad de transmitir una idea a un oyente .................................................... 41 Figura 22. Aplicaciones en el celular que permitan entender y usar sus funcionalidades ....... 41 Figura 23. Aplicaciones de mensajería que permiten la comunicación mediante LSEC ........ 42 Figura 24. Diagrama del proceso de pactar señas .................................................................... 44 Figura 25. Logotipo de aplicativo móvil.................................................................................. 46 Figura 26. Product backlog ...................................................................................................... 51 Figura 27. Modelo físico para el sprint 1 ................................................................................. 52 Figura 28. Drive ojdbc8 para conexión de la base de datos con el servidor Payara ................ 53 Figura 29. Cambio de puerto del servidor Payara.................................................................... 53 Figura 30. Cambio de puerto LISTENER_PORT del system ................................................. 53 Figura 31. Activar servidor Payara .......................................................................................... 53 Figura 32. Fichero de configuración JPA persistence.xml ...................................................... 53 Figura 33. Clase UsuarioFacade.java....................................................................................... 54 Figura 34. Clase AbastractFacade.java .................................................................................... 54 Figura 35. Controlador UserLoginController.java................................................................... 55 Figura 36. Pruebas Unitarias del Login en JUnits4 ................................................................. 55 Figura 37. Creación de la interfaz Serializable para el registro del usuario ............................ 56 Figura 38. Parámetros para el registro del usuario .................................................................. 56 Figura 39. Conexión del controlador con el registro.xhtml ..................................................... 56 Figura 40. Creación de usuario exitoso y direccionamiento a la vista login.xhtml ................. 56
xviii Figura 41. Trigger TGUSUARIOBEFORE para país y usuario.............................................. 57 Figura 42. Creación del modelo Contactos.java con la interfaz Serializable .......................... 57 Figura 43. Creación de contacto .............................................................................................. 58 Figura 44. Edición de contacto registrado ............................................................................... 58 Figura 45. Creación de contacto y vista del mismo ................................................................. 58 Figura 46. Secuencia para la generación de valores únicos ..................................................... 58 Figura 47. Trigger para la inserción del campo concodigo ..................................................... 59 Figura 48. Gráfico de Sprint 1 ................................................................................................. 59 Figura 49. Clase Chat para el ingreso de campos .................................................................... 62 Figura 50. Vista chat para obtener un listado del chat ............................................................. 62 Figura 51. Creación de la clase ui-fuild y p-field para el ingreso de texto en el chat .............. 63 Figura 52. Estilo CSS del Chat ................................................................................................ 63 Figura 53. Verificación de contacto con la aplicación ............................................................. 63 Figura 54. Almacenar y enviar el mensaje............................................................................... 64 Figura 55. Visualización de categorías .................................................................................... 64 Figura 56. Modelo para definir los campos de la tabla categorías........................................... 64 Figura 57. Creación de botones para crear, editar y listar pictogramas de categorías ............. 64 Figura 58. Visualización de las imágenes en tipo Slider ......................................................... 65 Figura 59. Creación y actualización de categorías................................................................... 65 Figura 60. Método para listar todas las categorías ................................................................... 65 Figura 61. Relación del modelo Destacados con la tabla Chat y Usuarios.............................. 66 Figura 62. Creación del submenú destacar o eliminar mensaje ............................................... 66 Figura 63. Visualización de los datos del usuario logueado .................................................... 67 Figura 64. Controlador Destacados para mantener la sesión de los datos ............................... 67 Figura 65. Método List para obtener el listado de mensajes destacados ................................. 67 Figura 66. Método para remover mensajes destacados ........................................................... 67
xix Figura 67. Método para reenviar mensajes .............................................................................. 68 Figura 68. Vista chat-move para el reenvio de mensaje .......................................................... 68 Figura 69. Método para almacenar el mensaje enviado en la base de datos ............................ 68 Figura 70. Gráfico del Sprint 2 ................................................................................................ 68 Figura 71. Ingresar y enviar texto a un contacto ...................................................................... 71 Figura 72. Activación de Machine Learning ........................................................................... 72 Figura 73. Detección de contactos en la plataforma para enviar mensaje ............................... 72 Figura 74. Machine Learning concatenado .............................................................................. 73 Figura 75. Reconocimiento de voz .......................................................................................... 73 Figura 76. Script creado para el proceso de Reconocimiento de Voz ..................................... 75 Figura 77. Creación del botón para grabar el audio ................................................................. 75 Figura 78. Guardar el audio en la ruta del servidor ................................................................. 76 Figura 79. Capturar audio en el navegador y Android............................................................. 77 Figura 80. Almacenar audio en una variable para poder descargarlo ...................................... 78 Figura 81. Configuración del servelet ...................................................................................... 78 Figura 82. Configurar el máximo almacenamiento para audio................................................ 79 Figura 83. Respaldo de los audios en el servidor..................................................................... 80 Figura 84. Modelo pictograma ................................................................................................. 80 Figura 85. Vista para observar los pictogramas de las categorías ........................................... 80 Figura 86. Vista para crear nuevo pictograma ......................................................................... 81 Figura 87. Vista para editar un pictograma .............................................................................. 81 Figura 88. Vista para editar un pictograma .............................................................................. 82 Figura 89. Creación de categorías colaborativas ..................................................................... 82 Figura 90. Método para actualizar los pictogramas ................................................................. 82 Figura 91. Método para listar las imágenes y los pictogramas ................................................ 82 Figura 92. Método para listar las imágenes y los pictogramas ................................................ 83
xx Figura 93. Actualización de los datos de una cuenta ............................................................... 83 Figura 94. Cambio de clave en una cuenta .............................................................................. 84 Figura 95. Validación de las sesiones ...................................................................................... 84 Figura 96. Verificación en DomainTools Whois Lookup ....................................................... 84 Figura 97. Verificación en cmd ............................................................................................... 84 Figura 98. Rendimiento del disco ............................................................................................ 85 Figura 99. Gráfico de trabajo pendiente del Sprint 3 ............................................................... 85
ÍNDICE DE TABLAS Tabla 1. Comunidad educativa de la carrera de Gastronomía del ISTC .................................. 19 Tabla 2. Variable independiente: Aplicativo móvil ................................................................. 22 Tabla 3. Variable independiente: Machine Learning ............................................................... 23 Tabla 4. Operacionalización de la variable dependiente ......................................................... 24 Tabla 5. Expertos para la validación de los instrumentos de recolección ............................... 26 Tabla 6. Docentes entrevistados .............................................................................................. 28 Tabla 7. Pictogramas clasificados por categoría ...................................................................... 45 Tabla 8. Roles Scrum ............................................................................................................... 47 Tabla 9. Parametrización ......................................................................................................... 48 Tabla 10. Product Backlog versión 1.4 .................................................................................... 49 Tabla 11. Sprint Backlog del Sprint 1 ...................................................................................... 51 Tabla 12. Sprint Backlog del Sprint 2 ...................................................................................... 60 Tabla 13. Retrospectiva del Sprint 2 ........................................................................................ 69 Tabla 14. Sprint Backlog del Sprint 3 ...................................................................................... 69 Tabla 15. Retrospectiva del Sprint 3 ........................................................................................ 86 Tabla 16. Análisis cruzado de los indicadores en función de la aplicación ............................. 87
1
1.
INTRODUCCIÓN
1.1. Antecedentes Hoy en día, la discapacidad se entiende “como aquella condición bajo la cual ciertas personas presentan algunas deficiencias físicas, mentales, intelectuales o sensoriales que imposibilitan interactuar con diversas actividades rutinarias” (Sosa, 2012), esta condición no puede ser ajena a las nuevas tecnologías (Zamora, Salamanca, & Cañon, 2013). A nivel mundial, se han gestado nuevos proyectos como -Háblalo- que muestra los principales nichos de mercado para personas con discapacidad auditiva, mejorando su calidad de vida con aplicaciones de este tipo, ya que no requiere conexión a internet (Asteroid Technologies, 2020). En la Universidad del Cauca (Colombia), Cano, Muñoz, Collazos & Bustos (2015), realizaron una aplicación móvil para el aprendizaje de la lectoescritura con FitzGeralt para niños con discapacidad auditiva. Entre sus resultados lograron crear una herramienta educativa inclusiva, a través de la obtención de conceptos y estructura de oración, además adaptar el nivel de aprendizaje del juego a partir de los atributos captados del niño. Por otro lado, Zamora, Salamanca & Cañon (2013), realizaron un prototipo de aplicación inclusiva con el fin de enseñar el alfabeto dactilológico colombiano a través de dispositivos móviles, permitiendo a una persona con discapacidad auditiva interactuar de manera dinámica la representación del lenguaje oral a lenguaje dactilológico. Además, Mendoza, Salazar, Del Carmen & Herrera (2018), en la Universidad Tecnológica de la Huasteca Hidalguense, desarrollaron una aplicación móvil alternativa que mejore la comunicación de personas con discapacidad auditiva y del habla. Entre sus resultados obtuvieron el aprendizaje de las letras del abecedario a través de imágenes, también expresiones y frases por medio de juegos y actividades lúdicas. Además, la posibilidad de que una persona con discapacidad auditiva escriba una frase y obtenga el audio por medio de la aplicación.
2
1.2. Delimitación del problema A nivel mundial existe 466 millones de personas que poseen pérdida de audición, representando un porcentaje mayor al 5%, donde 432 millones son adultos y la diferencia son menores de edad, la mayoría vive en países subdesarrollados. La Organización Mundial de la Salud (OMS) proyecta que hasta el 2050 una de cada diez personas la padecerá. Se considera que una persona tiene pérdida de audición cuando su nivel auditivo en ambos oídos es igual o superior a 25dB, de acuerdo a la pérdida en decibelios (dB) se clasifica en grado leve, moderado, grave o profunda (Organización Mundial de la Salud (OMS), 2020). En Ecuador, la población con discapacidad auditiva de acuerdo a los datos del Consejo Nacional para la Igualdad de las Discapacidades (CONADIS), está conformada por 67 929 personas registradas, de las cuales 54.74% son hombres, 45.25% son mujeres y el 0.1% pertenecen a la comunidad LGBTI (Lesbianas, Gays, Bisexuales, Transgénero, Transexuales, Travestis e Intersex). En la provincia de Santo Domingo de los Tsáchilas existen 1 384 personas con discapacidad auditiva registradas, de las cuales el 54.18% son hombres y el 46.82% son mujeres (Consejo Nacional para la Igualdad de Discapacidades (CONADIS), 2020). El Instituto Superior Tecnológico Calazacón (de ahora en adelante referido como “ISTC”), es una institución de educación superior pública, se encuentra ubicado en el cantón Santo Domingo, perteneciente a la provincia Santo Domingo de los Tsáchilas. Actualmente, en el ISTC existen 683 estudiantes, de los cuales 3 poseen discapacidad auditiva (de ahora en adelante referido como “DA”), y pertenecen a la carrera de Tecnología Superior en Gastronomía, dicha información fue facilitada por Vicerrectorado de la institución. Luego de la visita in situ, se pudo evidenciar a docentes con escaso conocimiento en lengua de señas ecuatoriana, lo que dificulta la comunicación en las asignaturas que imparten. Además, la intérprete posee nociones básicas sobre terminología técnica en la carrera anteriormente mencionada, generando una brecha en el proceso de aprendizaje de los estudiantes con DA. Por último, toda la comunidad educativa de la carrera no logra una comunicación fluida, debido a que existe una intérprete de lengua de señas ecuatoriana para todas las asignaturas, en consecuencia, no pueden transmitir sus mensajes de manera entendible y oportuna.
3 Luego del análisis en base a la problemática planteada, se pudo evidenciar una limitada comunicación entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad educativa de la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón.
1.3. Formulación y sistematización del problema 1.3.1. Formulación del problema. ¿Cómo fortalecer la comunicación entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad académica dentro de la carrera de Gastronomía en el Instituto Superior Tecnológico Calazacón? 1.3.2. Sistematización del problema. Preguntas específicas. ¿Cuáles son las necesidades comunicativas de los estudiantes con discapacidad auditiva en la carrera de Gastronomía? ¿Qué técnica se puede emplear para tener una comunicación efectiva entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad académica? ¿Qué solución tecnológica se puede implementar para reforzar los procesos en la comunicación entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad académica?
1.4. Justificación de la investigación Este plan de trabajo de titulación se relaciona con la Constitución de la República del Ecuador, Título II, artículo 11, numeral 2, “Todas las personas son iguales y gozarán de los mismos derechos, deberes y oportunidades”, siendo prioridad la inclusión de personas con discapacidad auditiva (Asamblea Nacional Constituyente, 2008). De igual manera, el trabajo de investigación se asocia con el Plan Nacional de Desarrollo “Toda una vida” elaborado en el 2017 por la Secretaría Nacional de Planificación y
4 Desarrollo (SENPLADES), el cual instituye una vida digna con igualdad de oportunidades para la sociedad (Secretaria Nacional de Planificación y Desarrollo (SENPLADES), 2017, pág. 48). Apuntando en el literal 1.5 de las políticas, la cual menciona: Fortalecer el sistema de inclusión y equidad social, protección integral, protección especial, atención integral y el sistema de cuidados durante el ciclo de vida de las personas, con énfasis en los grupos de atención prioritaria, considerando los contextos territoriales y la diversidad sociocultural (Secretaria Nacional de Planificación y Desarrollo (SENPLADES), 2017, pág. 58).
Actualmente, las Tecnologías de la Información y la Comunicación (TIC), no poseen como meta central ofrecer accesibilidad a personas con discapacidad, sin embargo, existen herramientas enfocadas en mejorar la comunicación que poco a poco incluyen más componentes, tales como apps y proyectos que fortalecen la inserción social (Luna, 2013). Esta investigación se enfocó en el desarrollo de un aplicativo móvil basado en machine learning y su adaptación a la técnica de pictogramas, para fortalecer la comunicación entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad académica del ISTC. El presente proyecto se considera importante ya que contribuye a mejorar la calidad de vida e inclusión de las personas con DA dentro de la sociedad.
1.5. Objetivos de la investigación 1.5.1. Objetivo general. Implementar un aplicativo móvil con machine learning para el fortalecimiento de la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón del cantón Santo Domingo. 1.5.2. Objetivos específicos. Conocer las necesidades comunicativas de los estudiantes con discapacidad auditiva para lograr una mejor interacción con sus compañeros, docentes y autoridades. Emplear el sistema pictográfico para estudiantes con discapacidad auditiva dentro de las áreas técnicas de bares y restaurantes, cocina de alto volumen y ecuatoriana.
5 Desarrollar un aplicativo móvil con machine learning para mejorar la comunicación entre estudiantes con discapacidad auditiva y demás actores que conforman la comunidad académica del ISTC. El presente trabajo comprende la siguiente estructura: revisión de literatura, en el cual se plantean los fundamentos teóricos y la predicción científica; la metodología de la investigación, que define el enfoque, diseño y tipo de investigación, así como la población y muestra, de esta manera se realiza la operacionalización de las variables; además de seleccionar las técnicas e instrumentos de recogida y análisis de datos. Por último, se detallan los resultados, referencias bibliográficas y anexos.
6
2.
REVISIÓN DE LA LITERATURA
2.1. Fundamentos teóricos A continuación, se plantea la literatura que conforma cada una de las variables de la presente investigación, empezando por las variables independientes como son: aplicativo móvil y machine learning (Figura 1 y 2), y la variable dependiente que pertenece a la lengua de señas ecuatoriana (LSEC) (Figura 3).
Figura 1. Índice de la revisión de literatura de la variable independiente aplicativo móvil
Figura 2. Índice de la revisión de literatura de la variable independiente machine learning
Figura 3. Índice de la revisión de literatura de la variable dependiente LSEC
7 2.1.1. Aplicativo móvil 2.1.1.1.
Sistemas Operativos móviles
2.1.1.1.1.
Android
Android es un sistema operativo inicialmente pensado para teléfonos móviles y tablets, hasta que con el paso del tiempo ha ido dominando mercados y ahora se lo puede encontrar en televisores, relojes e incluso coches. La gran ventaja es que está basado en Linux (libre y multiplataforma). Una ventaja muy importante es la facilidad de desarrollar aplicaciones y subirlas a Play Store con posibilidad de poder monetizar las mismas (Guimerá, 2018). A nivel mundial el sistema operativo móvil más usado es Android, en la actualidad existen muchos fabricantes que lo incorporan en sus dispositivos, existen mejoras en cada versión lanzada, lo cual lo convierte en un duro competidor de iOS y actualmente su última versión es la 11. Existen más de un millón de aplicaciones en la actualidad para este sistema operativo en su tienda Play Store. El proyecto Android fue adquirida por Google en 2005. 2.1.1.1.2.
iOS
Sistema Operativo que se instala en el iPod Touch, iPhone y iPad, es basado en MacOS disponible en ordenadores de Apple. Se le atribuye en nacimiento del ecosistema de móviles inteligente modernos táctiles. Su tienda App Store ha sido el punto de referencia para las demás empresas de tecnología que impulsa plataformas móviles. Las aplicaciones de iOS se desarrollan en los lenguajes de programación Objective C y Swift, este último presentado por Apple para un desarrollo más ágil (Serna & Pardo, 2016). iOS es el sistema operativo desarrollado por Apple Inc. para ser usado en sus dispositivos móviles, es el segundo sistema operativo más popular del mercado (después de Android), es de código cerrado por lo que otros fabricantes no tienen acceso a su código fuente, originalmente iOS fue presentado en la primera generación del iPhone en 2007, siendo incorporado después a las iPad y iPod Touch, la versión actual es la 14 y sus actualizaciones principales son lanzadas cada año.
8 2.1.1.1.3.
Windows Phone
Sistema operativo de Microsoft lanzado en 2010, enfocado en pantallas táctiles, surgió una alianza con Nokia para adaptarlo en sus terminales Nokia Lumia. El diseño presentado en estos modelos es muy diferente a Android e iOS. Las aplicaciones para este sistema se desarrollan en Visual Studio utilizando los lenguajes soportados por Microsoft como VB, C# y C++, en cuanto a la parte gráfica las aplicaciones son construidas en el lenguaje XAML (variante de XML), creada por Microsoft para el diseño de interfaces en aplicaciones (Serna & Pardo, 2016). Sistema operativo enfocado para dispositivos móviles táctiles, desarrollado desde cero de la mano de Microsoft. En 2011 se lanzaron los primeros móviles lanzados con este sistema operativo fue el Lumia 710 y Lumia 800. En la actualidad es un sistema que dejó de desarrollarse debido a que los fabricantes se enfocaron en implementar dentro de sus terminales Android y su cuota de mercado bajo notablemente, así como la falta del desarrollo de aplicaciones para el mismo. 2.1.1.2.
Aplicación móvil
2.1.1.2.1.
Nativa
Son aplicaciones desarrolladas en el IDE que ofrece cada sistema operativo, se conoce de forma genérica como Software Development Kit o SDK. Cada sistema operativo como Android, iOS y Windows Phone tienen su propio entorno de desarrollo integrado para programar y diseñar aplicaciones que se ejecuten en su propia plataforma (Cuello & Vittone, 2013). Android, iOS o Windows Phone tienen su propio lenguaje de programación Java-Klotin (Android), Swift (iOS), C++ y Javascript para Windows Phone. Entre las ventajas se encuentra el aprovechamiento de las funcionalidades del dispositivo para el que fueron desarrollado y pueden funcionar sin conexión a internet. Las actualizaciones de estas aplicaciones por lo general son costosas, por ejemplo, WhatsApp.
9 2.1.1.2.2.
Web
Las aplicaciones web son una versión de la misma pero optimizada para su uso en dispositivos móviles. Siendo un documento web, se basa en HTML5 y CSS3. El resultado final es poder acceder desde cualquier buscador que se encuentre instalado en un dispositivo indistintamente del sistema operativo que use (Santiago, Trabaldo, Kamijo, & Fernández, 2015). Estas aplicaciones se desarrollan con Javascript, CSS o HTML. Contrario a las nativas, este tipo de aplicativo es adaptable a cualquier sistema operativo (se ajusta a los diferentes navegadores instalados en el dispositivo móvil). Si bien es cierto el desarrollo abarata costos, no funciona si no hay conexión a internet. 2.1.1.2.3.
Hibrida
Combinan los lenguajes de programación del sistema operativo con elementos web en el entorno de comunicación con el usuario. Estas aplicaciones utilizan elementos incrustados que se visualizan en el navegador. Son empaquetadas y distribuidas a través de los mercados de aplicaciones al igual que el software nativo (Cuello & Vittone, 2013). Este tipo de aplicaciones fusionan elementos de apps nativas y web según la conveniencia del desarrollador. Por una parte, se usa Javascript, CSS o HTML, y por otro admiten la accesibilidad a las funcionalidades del dispositivo. Instagram es un modelo de este tipo de aplicaciones. 2.1.1.3.
Lenguaje de programación
2.1.1.3.1.
Java
“Es un lenguaje de programación orientado a objetos, sencillo, fácil de usar, potente y adaptado para la programación de aplicaciones en la red” (Duran, Gutierrez, & Pimentel, 2007). Java es un lenguaje similar a C o C++, lo que permitió la fácil migración y aprendizaje de Java por la familiarización con estos lenguajes. Además, es un lenguaje interpretado y compilado permitiendo mejorar el rendimiento de la interpretación cuando se quiere migrar un programa de una plataforma a otra, haciéndolo a Java multiplataforma (Garrido, 2015).
10 Java posee un alto rendimiento, es distribuido, concurrente y es bastante robusto debido a que realiza una comprobación de sintaxis y ciertas situaciones, adicional durante la ejecución vuelve a realizar comprobaciones de la sintaxis lo que no hacen otros lenguajes de programación y puede originar fallos inesperados (Garrido, 2015). 2.1.1.3.2.
JavaScript
Es un lenguaje de programación de scripts, abreviado como JS, desarrollado por Netscape Communications, creado para funcionar cliente/servidor a través del internet, los scripts pueden ejecutarse en el navegador web sin la necesidad de que pase por el servidor. JavaScripts se basa en el lenguaje C y, utiliza algunos nombres que son propios de Java, aunque Java y JavaScript no tienen ninguna relación entre sí. Los navegadores populares soportan JavaScript independientemente de su sistema operativo, se debe a que JavaScript está integrado dentro del motor de los navegadores, siendo esta una de sus principales ventajas. Además, es versátil para el desarrollo de aplicaciones web dinámico y aplicaciones móviles, es multiplataforma, es soportado por todos los dispositivos móviles actuales y se relaciona de modo fluido con HTML y CSS (Luna, 2013). 2.1.1.3.3.
Kotlin
Es un lenguaje de programación, surgió como una alternativa a Java debido a sus problemas habituales de dicho lenguaje. Hoy en día es el lenguaje oficial para el desarrollo en Android. Dentro de sus características se puede mencionar el seguro contra nulos, se ahorra código a diferencia de otros lenguajes de programación que necesitan de varias líneas para realizar una sentencia. Además, Kotlin permite trabajar en modo orientada a objetos y en funcional, es fácil de usar al estar basado en Java, C# o Scala (Guimerá, 2018). 2.1.1.4.
Accesibilidad de aplicaciones móviles
2.1.1.4.1.
Principios de desarrollo de aplicaciones móviles accesibles
La garantía de que una app móvil sea asequible, es que debe contar con principios básicos de diseño y a la vez requisitos de desarrollo, sin olvidar las necesidades reales de las personas con discapacidad, garantizando el acceso y compatibilidad a los servicios provistos por el sistema operativo. Existen muchas plataformas que no proporcionan accesibilidad, sin embargo, el desarrollador lo puede subsanar utilizando herramientas de apoyo que dispone la
11 plataforma por medio de la capa de accesibilidad que proporciona información suficiente para ofrecer el acceso universal (Aguado & Estrada, 2017). 2.1.1.4.2.
Herramientas de evaluación de accesibilidad
Para aseverar que una aplicación desarrollada cumpla con las particularidades necesarias para considerarse viables, se debe otorgar algunos aspectos, como herramientas que automatizan estos procesos o suministran la labor de la comprobación manual. Una herramienta de evaluación automatizada genera informes de manera automática, mientras que la manual requiere la intervención del usuario para facilitar la información. En la actualidad dentro de la plataforma Android existen herramientas de evaluación de accesibilidad gratuitas, lo que evita más gastos en la etapa del desarrollo como: Accessibility Scanner, Accessibility Test Framework, Node Tree Debugging, UI Automator Viewer, Lint, Espresso y Robolectric; estas herramientas permiten el análisis automático, la visualización de la jerarquía de elementos de la interfaz, verificación del cumplimiento de comportamiento o condiciones y otras características (Aguado & Estrada, 2017). En la plataforma iOS se tiene la herramienta Accesibility Inspector que permite visualizar las propiedades de accesibilidad de las unidades de la interfaz, acciones relacionadas y lugar en la jerarquía de acceso, también posee el Accesibility Verifier para generar informes con inconvenientes relacionados a la accesibilidad que se detectan de forma automática sobre la app. La plataforma Windows Phone también posee herramientas de evaluación de accesibilidad gratuita como el UI Accessibility Checker(AccChecker) para experimentar diferentes entornos, verificar la precisión de la información relacionada a la accesibilidad y hallar problemas en tiempo de ejecución, otra herramienta es la AccScope que chequea el acceso de la aplicación a la fase de diseño y desarrollo, con ello se puede visualizar las características e información en un lector de pantalla. 2.1.1.4.3.
Productos o herramientas de apoyo
Software o hardware que admite la accesibilidad de una persona con discapacidad a una particularidad, que de otra forma no sería posible. Ofrecen ventajas como, por ejemplo, reconocimiento de voz, software de texto a voz o las configuraciones de texto de grandes
12 proporciones o contraste. Las herramientas de apoyo más utilizadas son: “lector de pantalla, magnificador, alto contraste, texto grande, escala de grises, sonido monoaural, control por voz, dictado por voz, control por interruptor, control por barrido y texto predictivo” (Aguado & Estrada, 2017). 2.1.2. Machine Learning o aprendizaje automático Es una rama de la inteligencia artificial cuyo propósito es el aprendizaje automático de máquinas, dicho aprendizaje se basa en un algoritmo que revisa los datos para predecir futuras acciones o realizar otros tipos de toma de decisiones bajo incertidumbre mediante ejemplos, experiencias e información adicional. Los algoritmos de machine learning deben ser eficientes, se diferencia el uno del otro en base al tiempo de ejecución y el espacio utilizado para tratar gran cantidad de datos. La incertidumbre dentro del machine learning se presenta en varias formas: “¿cuál es la mejor predicción sobre el futuro teniendo en cuenta algunos datos del pasado? ¿cuál es el mejor modelo para explicar algunos datos? ¿qué medición debo realizar a continuación? etc.” (Murphy, 2012). 2.1.2.1.
Modelos de Machine Learning
2.1.2.1.1.
Modelo Probabilístico
El modelo se enfoca en asumir que existe algún proceso aleatorio subyacente que genera los valores para estas variables, de acuerdo con una distribución de probabilidad bien definida pero desconocida. Usan la idea de probabilidad para clasificar entidades nuevas, observando características y variables objetivas como variables aleatorias. El modelo probabilístico busca crear nuevos puntos de datos a partir de la relación entre dos variables, y con ello sus etiquetas a este modelo probabilístico se lo denomina predictivo y generativo. Dentro del modelo probabilístico también se tiene a Naive Bayes que busca la probabilidad de que algo suceda, en base a algo sucedido anteriormente (Flach, 2012). 2.1.2.1.2.
Modelo Lógico
Este modelo utiliza una expresión lógica para dividir los datos en agrupaciones homogéneas con la finalidad de construir métodos de agrupación. El modelo lógico consta de reglas que son fáciles de interpretar por los humanos, dichas reglas se organizan basándose en una estructura de árbol llamado también árbol de características. El espacio de la instancia se
13 divide en base a las características de la tarea a resolver; las hojas del árbol se pueden etiquetar con una clase, probabilidad, un valor real, etc. (Flach, 2012). Un aspecto importante de los modelos lógicos, es que proporciona explicaciones por sus predicciones hasta un cierto punto leyendo las condiciones que llevaron a la predicción de raíz a hoja, a diferencia de otros modelos. Adicional, el modelo puede ser inspeccionado fácilmente por humanos, es decir que no están restringidos a reglas simples por lo que comúnmente al modelo lógico se lo llama como modelo declarativo (Flach, 2012). 2.1.2.2.
Tipos de Aprendizaje de Machine Learning
2.1.2.2.1.
Aprendizaje supervisado
Este tipo de modelo se basa en datos etiquetados donde los resultados son conocidos previamente, realizando un mapeo a partir de las entradas X a salidas Y. El aprendizaje supervisado realiza predicciones de datos que no han sido procesados a partir de la alimentación de un conjunto de resultados anteriores, partiendo de una muestra constituida por n relaciones de un par de variables, se crea una función en la cual una variable de entrada predice las salidas con cierto nivel de confiabilidad (Alpaydin, 2014). Este aprendizaje es muy utilizado en las aplicaciones tecnológicas para la detección de spam en correos, reconocimiento de dígitos, voz y rostro, clasificación de escritura, imágenes y documentos, diagnostico, detección de fraudes e imágenes en captchas (Murphy, 2012). Los algoritmos de machine learning basado en el aprendizaje supervisado son: árboles de decisión, regresión logística, support vector machines (SVM) y clasificación de Naive Bayes. 2.1.2.2.2.
Aprendizaje no supervisado
Este aprendizaje solo proporciona datos de salida sin ningún tipo de entrada, a diferencia del aprendizaje supervisado no muestra un resultado por cada entrada, es decir que realiza un descubrimiento. El aprendizaje no supervisado modela una distribución subyacente a los datos para conseguir mayor información, esto se debe a que los datos de entrenamiento no están clasificados ya sea porque no existen o no se conoce la clasificación (Murphy, 2012). El aprendizaje no supervisado es el más aplicado dentro del aprendizaje humano debido a que, no se necesita de un experto humano para el etiquetado de los datos lo cual resulta
14 costoso y contiene poca información al momento de estimar de manera confiable los parámetros de modelos complejos. Los problemas los subdividen en problemas de clustering y asociación, donde el clustering clasifica los datos agrupándolos según sus características, mientras que la asociación genera reglas que engloben enormes volúmenes de datos. El aprendizaje no supervisado es utilizado para la segmentación de clientes en diversas empresas (Alpaydin, 2014). 2.1.2.2.3.
Aprendizaje por refuerzo
Analiza las acciones pasadas para generar políticas en base a resultados que se generaron por cada una de las acciones, dichas políticas permiten aumentar el rendimiento de acciones futuras, de tal forma que la nueva acción cumpla con el objetivo para lo cual fueron aplicadas. Este método de aprendizaje se denomina algoritmos de aprendizaje por refuerzo, debido a que toma modelos existentes para predecir el futuro con los datos disponibles, es decir, usando un proceso de retroalimentación aprendiendo en base al ensayo-error. Un ejemplo de este aprendizaje se evidencia en los juegos, al momento que buscamos, seleccionamos y perfeccionamos las estrategias con el fin de salir victoriosos en el juego, además en el control de robots, programa de ascensores y ruteo de paquetes (Alpaydin, 2014). 2.1.3. Lengua de señas ecuatorianas (LSEC) La lengua de señas no es un lenguaje universal, cada país posee su propia adaptación en lengua de señas al igual como sucede con las lenguas habladas. En la Ley Orgánica de Discapacidades, en el artículo 70 menciona: “Se reconoce la lengua de señas ecuatoriana como lengua propia y medio de comunicación de las personas con discapacidad auditiva.”. Además, dentro del Manual Práctico para Intérpretes en la Lengua de Señas Ecuatoriana cita “El tener acceso a la lengua de señas es clave para cualquier persona sorda, niño o adulto para su desarrollo cognitivo, social, emocional y lingüístico” (Consejo Nacional para la Igualdad de Discapacidades (CONADIS), Consejo de Regulación y Desarrollo de Información y Comunicación (CORDICOM), Federación Nacional de Personas Sordas del Ecuador (FENASEC), 2020). Es importante conocer la lengua de señas ecuatoriana, ya que fomenta el acceso, comunicación e información, incentivando a la comunidad oyente a la inclusión de las personas con discapacidad auditiva del Ecuador. El diccionario de lengua de señas ecuatoriano “Gabriel
15 Román” cuenta actualmente con palabras, gráficos y videos explicativos en lengua de señas ecuatoriana. 2.1.3.1.
Técnicas de interpretación
2.1.3.1.1.
Interpretación simultanea
Se utiliza cuando la interpretación se realiza al mismo tiempo mientras se escucha el discurso del expositor, el intérprete juega un papel importante, debe escuchar el contenido, entenderlo, buscar mentalmente las expresiones adecuadas para expresar lo dicho por el expositor y transmitirlo; mientras analiza y asimila la siguiente idea. Este tipo de interpretación es complicada y requiere un gran proceso cognitivo (Consejo Nacional para la Igualdad de Discapacidades (CONADIS), Consejo de Regulación y Desarrollo de Información y Comunicación (CORDICOM), Federación Nacional de Personas Sordas del Ecuador (FENASEC), 2020). 2.1.3.1.2.
Interpretación consecutiva
La interpretación se realiza después de breves intervalos de pausa que realiza el expositor en su discurso, permitiendo al intérprete transmitir la información ya sea tras cada frase o un grupo de frases. En la interpretación consecutiva es preponderante la retención de información por parte del intérprete. 2.1.3.2.
Tipos de interpretación
2.1.3.2.1.
Interpretación Bilateral o de contacto
Es de doble direccionalidad, es decir el proceso de transmisión se realiza del lenguaje hablado a lengua de señas y viceversa, sin embargo, existen muchas dificultades en este tipo de interpretación debido a que deben acostumbrarse a cambiar de un código lingüístico a otro en cuestión de segundos (Martí & Muñoz, 2012). También es denominada de contacto al ser una interpretación que está ligada a la visibilidad puesto que el intérprete es percibido como interprete persona. Además, se abre la posibilidad de pedir aclaraciones a los interlocutores, debido a que no existe distancia física entre el interlocutor y el intérprete.
16 2.1.3.2.2.
Interpretación Unilateral
La interpretación unilateral es en una sola dirección, la comunicación solo se da desde un sentido o vía, mientras el otro sentido no puede comunicarse, es aplicado a nivel de medios de comunicación. En los medios, la interpretación del mensaje es simultanea de manera unilateral; escuchando y comprendiendo el significado del contenido, al mismo tiempo aplicando reglas lingüísticas a través de la estructura gramatical de la LSEC. 2.1.3.3.
Gramática de la Lengua de Señas Ecuatoriana
2.1.3.3.1.
Fonología
La fonología en las personas oyentes es la experiencia audiovisual del habla, mientras que la fonología en las personas con discapacidad auditiva está influenciada por la lectura labial, dactilología, lectura y experiencias visuales del habla. Existen tres parámetros para describir señas en la lengua de señas como la posición, configuración y movimiento de las manos. La posición de las manos hace referencia a la parte del cuerpo en la que se articula la seña, mientras que la configuración de las manos analiza la disposición de los dedos y la orientación de las manos, el último parámetro el movimiento de las manos observa si es recto, giratorio, hacia arriba, hacia abajo, etc. (Castro, 2018). El significado de la seña puede variar con simplemente modificar uno de los tres parámetros, es decir una seña puede tener la misma posición y configuración de las manos, pero contrastar el movimiento de las mismas, esto implica que la seña tendrá diferente significado con un mínimo cambio ya sea por contrastar solo la posición, la configuración o el movimiento de las manos (Castro, 2018). 2.1.3.3.2.
Sintaxis
En la LSEC estudia la estructura y la finalidad de las señas dentro del mensaje basándose en elementos como la perspectiva del autor, variaciones en la postura corporal, la configuración manual de los verbos y el espacio mental. En la lengua de señas ecuatoriana no se maneja artículos o preposiciones cuando se estructura una oración. Las señas dentro de una oración pueden actuar de la siguiente manera: sujeto (señas que representan personas, animales, cosas, pronombre personales y demostrativos), atributo (adjetivos y sustantivos adjetivos) y circunstancias (señas de circunstancias locativas, de estado de las personas o eventos).
17 2.1.3.3.3.
Morfología
La morfología en la LSEC es la combinación de las señas para obtener variaciones y conocer cómo se relacionan con el significado, siendo el fonema la unidad mínima de significado. La morfología se divide en clasificadores de sustantivos, números en sustantivos y clasificadores de verbos. Por ejemplo, la palabra dentista, actúan dos morfemas el clasificador que son características propias de la entidad (personas o animales) que representa un individuo y el sustantivo para dientes, lo que resulta el dentista (Castro, 2018).
2.2. Predicción científica H0: El aplicativo móvil con machine learning no influye significativamente en la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón. H1: El aplicativo móvil con machine learning influye significativamente en la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón.
18
3.
METODOLOGÍA DE LA INVESTIGACIÓN
3.1. Enfoque, diseño y tipo de investigación 3.1.1. Enfoque Según Hernández & Mendoza (2018), el enfoque cuantitativo se basa en la “recolección de datos para probar hipótesis con base en la medición numérica y el análisis estadístico, con el fin de establecer pautas de comportamiento y probar teorías” (pág. 4). El enfoque cualitativo de acuerdo a Hernández & Mendoza (2018), “utiliza la recolección y análisis de los datos para afinar las preguntas de investigación o relevar las nuevas interrogantes en el proceso de interpretación” (pág. 7). El enfoque de la investigación es de tipo mixta, utiliza el enfoque cualitativo y cuantitativo, como afirma Hernández & Mendoza (2018), “no es reemplazar a la investigación cuantitativa ni a la investigación cualitativa, sino utilizar las fortalezas de ambos tipos de indagación, combinándolas y tratando de minimizar sus debilidades potenciales” (pág. 532). El enfoque cualitativo se aplica mediante la recolección de datos a través de la entrevista realizada a la intérprete de lengua de señas ecuatoriana y los docentes que imparten clases a los estudiantes con DA en la carrera de Tecnología Superior en Gastronomía. El enfoque cuantitativo se refleja en la tabulación de los datos recolectados en la encuesta realizada a la comunidad educativa. 3.1.2. Diseño de la investigación El presente trabajo de investigación tiene un diseño experimental (diseño de preprueba y posprueba con un solo grupo “preexperimental” con un grado de control mínimo), donde se realizó un pre test, luego se aplicó el estímulo y finalmente se empleó un post test (Hernández & Mendoza, 2018). De acuerdo a Hernández & Mendoza (2018) “la variable independiente se considera como supuesta causa en una relación entre variables (condición antecedente), y al efecto provocado por dicha causa se le denomina variable dependiente (consecuente)” (pág. 130).
19 3.1.3. Tipo de investigación En el presente proyecto, el tipo de investigación es aplicada ya que se plantea un problema determinado que se pretende dar solución de manera inmediata y es ejecutable al entorno real. Según Behar (2008) la investigación aplicada realiza el estudio de problemas en circunstancias y características concretas, siendo aplicada a la brevedad para obtener resultados inmediatos. Además, la investigación es descriptiva debido a que se “pretende medir o recoger la información de manera independiente o conjunta sobre los conceptos o las variables” (Hernández & Mendoza, 2018, pág. 92), para especificar propiedades o características del grupo a analizar. Es importante que se precise lo que se va a medir y sobre que se medirá, teniendo en cuenta la muestra e instrumento a utilizar dentro del estudio descriptivo. Adicional, dado que la investigación se realiza propiamente en el sitio de estudio, es decir en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón, es de campo, el estudio se realiza en situaciones “reales” donde se manipularán una o más variables, es decir, “se lleva a cabo en el ambiente cotidiano de los sujetos” (Hernández & Mendoza, 2018). El investigador se dirige al sitio para recolectar los datos en forma directa de la “realidad” y posteriormente ser procesados.
3.2. Población y muestra En la presente investigación la población analizada es toda la comunidad educativa de la carrera Gastronomía del Instituto Superior Tecnológico Calazacón del cantón Santo Domingo, de acuerdo a los datos proporcionados por vicerrectorado del ISTC son 239 oyentes y 3 personas con discapacidad auditiva, como se muestra en la tabla 1. Tabla 1. Comunidad educativa de la carrera de Gastronomía del ISTC Instituto Superior Tecnológico Calazacón
N°
Nivel
Periodo I-2020 Estudiantes
Paralelo
F O
1
Primero
A
18
DA
M
Total
Docentes Administrativos Total
O DA 12
30
12
3
20 2
Primero
B
26
3
29
3
Primero
C
14
14
28
4
Primero
D
21
8
29
5
Tercero
A
17
11
28
6
Cuarto
A
18
7
Quinto
A
17
10
27
8
Quinto
B
16
11
27
148
79
227
Total
1
8
2
29
12
3
242
Nota: Datos proporcionados por Vicerrectorado del Instituto Superior Tecnológico Calazacón F= Femenino M= Masculino O= Oyente DA= Discapacidad Auditiva
En los casos de estudio donde la variable es de tipo cuantitativo, la población es infinita cuando es mayor a 10 000, caso contrario se convierte en una población finita, como lo define Aguilar (2005), la fórmula para calcular la muestra en el caso de la población finita es la que se observa a continuación (Figura 4):
Figura 4. Fórmula para calcular la muestra de una población finita
Reemplazando los datos en la fórmula para obtener el tamaño de la muestra, queda de la siguiente manera:
N = 242
Z = 2.24. Con un nivel de confianza de 97.5%.
S = 0.5
21
d = 5%
=
242 (2.24) (0.5) = 163 (0.05) (242 − 1) + (2.24) (0.5)
Por lo tanto, con una población de 242 personas que conforman la comunidad educativa de la carrera Gastronomía del ISTC, teniendo un nivel de confianza de 97.5% y un límite aceptable de error muestral del 5% se obtuvo una muestra de 163 personas, en donde 160 son oyentes y 3 restantes son estudiantes con discapacidad auditiva.
3.3. Operacionalización de las variables Dentro de la operacionalización de las variables se determinaron las variables para observar la solución del problema, se operacionalizó las variables independientes aplicativo móvil y machine learning; la variable dependiente Lengua de señas ecuatoriana (LSEC), como se observa en la tabla 2, 3 y 4.
22
Tabla 2. Variable independiente: Aplicativo móvil Conceptualización Aplicativo móvil Una aplicación móvil también llamada app, está diseñada para ejecutarse en un dispositivo móvil como lo es un smartphone o tableta. En programación hay diferentes métodos para construir una app con particularidades, las mismas que pueden ser aplicaciones nativas, web o híbridas (Cuello & Vittone, 2013).
Categorías Sistemas Operativos
Indicadores Android iOS Windows Phone
Ítems ¿Qué tipos de aplicaciones tiene usted actualmente en su(s) dispositivo(s) digitales (computadoras, tabletas, teléfonos, etc.)? Marque todas las que aplique ¿Cuántas aplicaciones tiene usted actualmente en su celular? ¿Qué sistema operativo posee en su móvil?
Instrumento o técnica Encuesta a la comunidad educativa oyente y con discapacidad auditiva Encuesta a la comunidad educativa oyente y con discapacidad auditiva
Nativa
Aplicación móvil Web
Híbrida
Lenguaje programación
Accesibilidad aplicaciones móviles
de
de
Java JavaScript Kotlin Principios de desarrollo de aplicaciones móviles accesibles Herramientas de evaluación de accesibilidad Productos o herramientas de apoyo
¿Considera que las aplicaciones móviles podrían ayudarle a comunicarse de mejor manera con los estudiantes con discapacidad auditiva? ¿De qué forma considera usted que las tecnologías móviles aportan en la comunicación con las personas con discapacidad auditiva? ¿Consideraría utilizar un aplicativo móvil que permita la comunicación mediante texto, voz y pictogramas? ¿Está de acuerdo con una implementación móvil que permita la comunicación con estudiantes con discapacidad auditiva de la carrera de Gastronomía y que además se focalice en la gastronomía nacional e internacional? ¿Considera que un aplicativo móvil debe estar desarrollado con las últimas tecnologías, de fácil uso e interactivo para el usuario?
Entrevista al docente
Entrevista al docente
¿Cuántas aplicaciones en su celular permiten a personas con discapacidad auditiva tener total acceso a sus funcionalidades?
Encuesta a la comunidad educativa oyente
¿Cuántas aplicaciones en su celular permiten le entender y usar todas sus funcionalidades?
Encuesta a la comunidad educativa con discapacidad auditiva
23
Tabla 3. Variable independiente: Machine Learning Conceptualización Machine Learning El Machine Learning o aprendizaje automático forma parte de la inteligencia artificial, el propósito es el aprendizaje automático de máquinas, dicho aprendizaje se basa en un algoritmo que revisa los datos para predecir futuras acciones o realizar otros tipos de toma de decisiones bajo incertidumbre mediante ejemplos, experiencias e información adicional. Los algoritmos de Machine Learning deben ser eficientes, se diferencia el uno del otro en base al tiempo de ejecución y el espacio utilizado para tratar gran cantidad de datos. La incertidumbre dentro del Machine Learning se presenta en varias formas: “¿cuál es la mejor predicción sobre el futuro teniendo en cuenta algunos datos del pasado? ¿cuál es el mejor modelo para explicar algunos datos? ¿qué medición debo realizar a continuación? etc.” (Murphy, 2012).
Categorías
Indicadores
Modelo Probabilístico Modelos de Machine Learning
Ítems
Instrumento o técnica
¿Con que frecuencia usa aplicaciones de mensajería que guarden emoticones o GIF relacionados a la lengua de señas y los vuelva a sugerir automáticamente?
Encuesta a la comunidad educativa oyente y con discapacidad auditiva
¿Con qué frecuencia usa aplicaciones que sugieran predicciones de palabras o pictogramas (emoticones o GIF) usados con anterioridad?
Encuesta a la comunidad educativa oyente y con discapacidad auditiva
¿Considera que debería desarrollarse un aplicativo móvil que le ayude a comunicarse de mejor forma con sus estudiantes sordos?
Entrevista al docente
Modelo Lógico
Aprendizaje supervisado
Tipos de Aprendizaje de Machine Learning Aprendizaje no supervisado
Aprendizaje por refuerzo
¿Consideraría usar una aplicación móvil que aprenda de las configuraciones guardadas en el aplicativo por usuario?
24
Tabla 4. Operacionalización de la variable dependiente Conceptualización Lengua de señas ecuatoriana (LSEC) La lengua de señas no es un lenguaje universal, cada país posee su propia adaptación en lengua de señas al igual como sucede con las lenguas habladas. En la Ley Orgánica de Discapacidades, en el artículo 70 menciona: “Se reconoce la lengua de señas ecuatoriana como lengua propia y medio de comunicación de las personas con discapacidad auditiva.”. Además, dentro del Manual Práctico para Intérpretes en la Lengua de Señas Ecuatoriana cita “El tener acceso a la lengua de señas es clave para cualquier persona sorda, niño o adulto para su desarrollo cognitivo, social, emocional y lingüístico”. (Consejo Nacional para la Igualdad de Discapacidades (CONADIS), Consejo de Regulación y Desarrollo de Información y Comunicación (CORDICOM), Federación Nacional de Personas Sordas del Ecuador (FENASEC), 2020)
Categorías Técnicas de interpretación
Indicadores Interpretación simultanea Interpretación consecutiva
Tipos de interpretación
Gramática de la Lengua de Señas Ecuatoriana
Ítems ¿Qué tan probable es que logre comunicarse en tiempo real a través de lengua de señas con una persona sorda? ¿Cuál es la probabilidad de poder transmitir una idea a un estudiante con discapacidad auditiva si no se encuentra el intérprete de lengua de señas y/o la utilización de una aplicación educativa?
Instrumento o técnica
¿Qué tan probable es que logre comunicarse en tiempo real a través de lengua de señas con una persona oyente? ¿Cuál es la probabilidad de poder transmitir una idea a una persona oyente si no se encuentra un intérprete de lengua de señas y/o la utilización de una aplicación inclusiva?
Encuesta a la comunidad educativa con discapacidad auditiva
Interpretación bilateral o de contacto
¿Cómo le parece el rol que cumple el intérprete dentro de su clase? ¿Por qué? ¿Cuáles serían los efectos al dar clases dónde se incluyan a estudiantes con discapacidad auditiva y en la cual no se encuentre presenta el/la interprete? ¿Cree usted estar preparado para brindar su clase sin intérprete de lengua de señas? En general, ¿Qué porcentaje de conocimiento tiene sobre los tipos de lengua de señas ecuatorianas?
Interpretación Unilateral
¿Considera importante el uso del lenguaje de señas dentro del aula de clase? ¿Por qué?
Fonología
¿Considera que las aplicaciones de mensajería en su smartphone ayudan a personas con discapacidad auditiva a comunicarse mediante lengua de señas?
Sintaxis Morfología
Encuesta comunidad oyente
a la educativa
Entrevista al docente
Entrevista al docente
Encuesta a la comunidad educativa oyente y con discapacidad auditiva
25
3.4. Técnicas e instrumentos de recogida de datos 3.4.1. Encuesta Permite la recolección de datos mediante preguntas de forma estratégica que determinan el alcance de la investigación. Esta técnica incluyó un cuestionario estructurado dirigido a la muestra de 163 (160 oyentes y 3 personas con DA) que pertenecen a la carrera de Tecnología Superior en Gastronomía del ISTC. 3.4.2. Entrevista Es una vía de comunicación interpersonal entre el investigador, docentes e intérprete a fin de tener respuestas a las interrogantes planteadas sobre la problemática propuesta. Constó de un banco de preguntas abiertas, que sirvieron para obtener datos que apoyaron en el desarrollo del aplicativo móvil.
3.5. Técnicas de análisis de datos Se empleó el análisis estadístico, para procesar todos los datos recolectados a través de la encuesta y transformarlos en datos numéricos, reflejados en gráficos y análisis cruzado de Chi cuadrado para validar la hipótesis, para lo cual se usó la herramienta SPSS, la cual permite visualizar la correlación entre los indicadores.
26
4.
RESULTADOS
4.1. Resultado uno: Necesidades comunicativas de los estudiantes con DA Antes de realizar las encuestas y entrevistas, se realizó la validación de los instrumentos de recopilación de información por expertos en el área de investigación, estadística y lengua de señas ecuatoriana como se muestra en la tabla 5. Tabla 5. Expertos para la validación de los instrumentos de recolección N° 1
Nombre del experto Estuardo Cevallos Uve
Título académico Doctor en Ciencias Económicas
Área relacionada Investigación
Evidencia de validación Anexo III
2
Ángel Ramón Sabando García
Estadística
Anexo IV
3
Elvis Steveen Benítez Hidalgo
Magíster en Gerencia Educativa Maestrante en Estadística Aplicada Técnico Superior en Interpretación de Lengua de Señas Ecuatoriana
Lengua de señas ecuatoriana (LSEC)
Anexo V
4.1.1. Resultados de la entrevista a la intérprete de LSEC La entrevista fue aplicada a la intérprete de lengua de señas ecuatoriana, Lic. Yidah Pinzón (Anexo VI), quien proporcionó información sustancial para el conocimiento del proceso de comunicación. Los resultados se detallan a continuación: Pregunta 1: ¿Considera importante el uso del lenguaje de señas dentro del aula de clase? ¿Por qué? Por supuesto, si tenemos personas con discapacidad auditiva es necesario que haya lengua de señas para poder llegar la información para ellos y que sea exacta. Es necesario que todos podamos tener conocimiento en lengua de señas. Pregunta 2: ¿Cómo le parece el rol que cumple el intérprete dentro de su clase? ¿Por qué? Es muy importante el rol del intérprete dentro de clases, porque de eso depende que el alumno pueda entender, comprender y desenvolverse en sus actividades y deberes, es necesario que el intérprete se actualice todos los días en las señas para hacer una buena interpretación y ayudar como amiga a los estudiantes. Pregunta 3: ¿Cuáles serían los efectos en la clase dónde se incluyan a estudiantes con discapacidad auditiva y en la cual no se encuentre presenta el/la interprete?
27 Los estudiantes con discapacidad auditiva se frustran y se ponen tristes al no entender casi nada, recurren a la lectura, pero al no ser su lengua nativa no logran discernir muchas cosas. Es necesario siempre el intérprete de lengua de señas. Pregunta 4: ¿Cree usted estar preparado para brindar su clase sin intérprete de lengua de señas? Sí, me siento preparada. Ya que reviso el contenido de la clase, me preparo e investigo. Chequeo adicionalmente siempre la herramienta Google Classroom (contenido de la clase) y si hay alguna palabra nueva trato de idear una seña para que el estudiante comprenda. Uno debe estar en constante actualización y preparación. Además, me comunico con los docentes para aportar sugerencias para que los estudiantes puedan entender los contenidos de su materia. Pregunta 5: ¿Considera que las aplicaciones móviles podrían ayudarle a comunicarse de mejor manera con los estudiantes con discapacidad auditiva? Las aplicaciones móviles son muy buenas y podrían ayudar a comunicarse a estudiantes oyentes y docentes con los estudiantes que tienen discapacidad auditiva. Pregunta 6: ¿De qué forma considera usted que las tecnologías móviles aportan en la comunicación con las personas con discapacidad auditiva? Es una forma de comunicarse y es muy interesante la propuesta que ustedes están enfocándose para lograr este objetivo. Pregunta 7: ¿Considera que debería desarrollarse un aplicativo móvil que le ayude a comunicarse de mejor forma con sus estudiantes sordos? Si, si hay nuevas ideas de innovar adelante y estaríamos muy agradecidos de ello. Pregunta 8: ¿Consideraría usar una aplicación móvil que aprenda de las configuraciones guardadas en el aplicativo por usuario? Sí. Pregunta 9: ¿Consideraría utilizar un aplicativo móvil que permita la comunicación mediante texto, voz y pictogramas? Es una buena idea y tenemos que seguirnos actualizando.
28 Pregunta 10: ¿Está de acuerdo con la implementación móvil que permita la comunicación con estudiantes (discapacidad auditiva) de la carrera de Gastronomía y que además se focalice en la gastronomía nacional e internacional? Estoy de acuerdo, sobre todo en la carrera de Gastronomía donde existen muchas palabras técnicas y vocabulario y sería de gran ayuda entre los estudiantes oyentes, estudiantes con discapacidad auditiva y los docentes. Pregunta 11: En general, ¿Qué porcentaje de conocimiento tiene sobre los tipos de lengua de señas ecuatorianas? Sigo actualizándome todos los días, porque todos los días se aprende algo nuevo, y considero del 1 al 10, un 8.5 en conocimiento. Pregunta 12: ¿Considera que un aplicativo móvil debe estar desarrollado con las últimas tecnologías, de fácil uso e interactivo para el usuario? Por supuesto, debería siempre contar con las últimas tecnologías, de fácil uso e implementación para el usuario. 4.1.2. Resultados de las entrevistas a los docentes de la carrera de Gastronomía Las entrevistas se aplicaron a los docentes que imparten clases a los estudiantes con discapacidad auditiva, se consideró hacer varias entrevistas porque es importante tener el punto de vista y experiencia de la planta docente (Anexo VI). Los docentes entrevistados y el enlace de la entrevista se encuentran en la tabla 6. Tabla 6. Docentes entrevistados N° 1
Nombre del docente Karla Verónica Carrión Román
Título académico Ingeniería en Ciencias Gastronómicas
2 3
Felipe Sebastián Espinoza Ordóñez José Alfonso Espinoza Gómez
Ingeniero en Gestión de Alimentos y Bebidas Licenciado en Gestión Gastronómica
4
Jaime Estuardo González Amagua
5
Paola Fernanda Mogollón Mena
6
Natalia Vanessa Paredes Meza
Ingeniero en Gestión de Alimentos y Bebidas Master en Ingeniería del Software y Sistemas Computacionales Magíster en Pedagogía del Inglés como Lengua Extranjera
Asignatura que imparte Costo y Control de Alimentos y Bebidas Técnicas de bar y restaurante Cocina de Alto Volumen Cocina Ecuatoriana Ética Profesional Inglés
Link de la entrevista
bit.ly/374YA0c
29 A continuación, se detalla el resultado de cada pregunta parafraseada en relación a la entrevista realizada a cada docente que imparte clases a los estudiantes con discapacidad auditiva. Pregunta 1: ¿Considera importante el uso del lenguaje de señas dentro del aula de clase? ¿Por qué? Claro que sí, tomando en cuenta que tenemos estudiantes con discapacidad auditiva y ellos necesitan comunicarse, transmitir las ideas y no solamente por medio de un intérprete, además el docente debería comprender que es lo que desea manifestar el estudiante. Se fomenta la inclusión. Pregunta 2: ¿Cómo le parece el rol que cumple el intérprete dentro de su clase? ¿Por qué? Realmente importante, ya que la intérprete de Lengua de Señas es una conexión entre el estudiante y el docente para poder comunicar los contenidos de la clase. Ellos requieren a la interprete porque crean sus propias señas (pactar señas). Pregunta 3: ¿Cuáles serían los efectos en la clase dónde se incluyan a estudiantes con discapacidad auditiva y en la cual no se encuentre presenta el/la interprete? Existiría la falta de comprensión, a medida que uno ha ido laborando, se ha creado la familiaridad con los estudiantes, de tal manera que cuando hay ausencia del interprete uno trata de copiar la forma de escribir (mas no en señas) de como ellos entienden (ya que no tienen buena gramática en español) para de alguna manera tratar de guiar al mismo. Pregunta 4: ¿Cree usted estar preparado para brindar su clase sin intérprete de lengua de señas? Al 100% no, de pronto entre un 50% al 60%. Hay situaciones en la que la intérprete es muy importante que esté presente. Los estudiantes son muy visuales y siempre tienen dudas y preguntas a realizar y cada uno de ellos tiene formas diferentes de asimilar la información, muchas veces se requiere tutoría. Pregunta 5: ¿Considera que las aplicaciones móviles podrían ayudarle a comunicarse de mejor manera con los estudiantes con discapacidad auditiva?
30 Realmente sí, considerando la era digital. Sería una muy buena fuente de comunicación. De hecho, hay aplicaciones que brindan de alguna forma la ayuda que ellos requieren, pero no se han implementado por la presencia la mayor parte del tiempo del interprete. Pregunta 6: ¿De qué forma considera usted que las tecnologías móviles aportan en la comunicación con las personas con discapacidad auditiva? En la parte académica a los estudiantes les ha favorecido el poder aprender tecnologías y poseer estos recursos para estar al día, sobre todo porque es un medio entre los docente e intérpretes al permitir estar comunicados por través de las redes sociales. Pregunta 7: ¿Considera que debería desarrollarse un aplicativo móvil que le ayude a comunicarse de mejor forma con sus estudiantes sordos? Si, sería muy bueno e interesante. Se podría desarrollar una aplicación que incluya los términos técnicos que para ellos es difícil comprender. Pregunta 8: ¿Consideraría usar una aplicación móvil que aprenda de las configuraciones guardadas en el aplicativo por usuario? Sí, porque sería una forma más rápida que la aplicación brinde ayuda a los estudiantes con discapacidad auditiva. Pregunta 9: ¿Consideraría utilizar un aplicativo móvil que permita la comunicación mediante texto, voz y pictogramas? Sí, tomando en consideración que hay personas visuales y auditivas, incluso se podría trabajar de mejor manera con la a Federación Nacional de Personas Sordas del Ecuador "FENASEC". Adicionalmente sería importante que contenga señas en algún tipo de biblioteca para que los oyentes nos podamos identificar qué significan. Pregunta 10: ¿Está de acuerdo con la implementación móvil que permita la comunicación con estudiantes (discapacidad auditiva) de la carrera de Gastronomía y que además se focalice en la gastronomía nacional e internacional? Muy de acuerdo. Una idea sería el hecho de que se pueda compartir con el resto de estudiantes y docentes. Se incrementaría el nivel de entendimiento y sería un apoyo para el
31 tema de tutorías de clases y que el estudiante con discapacidad auditiva empiece a entender la estructura de las palabras. Pregunta 11: En general, ¿Qué porcentaje de conocimiento tiene sobre los tipos de lengua de señas ecuatorianas? Realmente muy poco. Del 1 al 100%, un 10% Pregunta 12: ¿Considera que un aplicativo móvil debe estar desarrollado con las últimas tecnologías, de fácil uso e interactivo para el usuario? Efectivamente. 4.1.3. Diagrama de actividades del proceso de comunicación Para conocer las necesidades comunicativas de los estudiantes con discapacidad auditiva, se determinó el proceso de comunicación mediante un diagrama de actividades de una clase regular, dicho diagrama está comprendido por docente, estudiante oyente, interprete y estudiante con discapacidad auditiva, como se observa en la figura 5.
Figura 5. Diagrama del proceso de una clase regular
32 4.1.4. Resultados de las encuestas a la comunidad educativa oyente La encuesta se aplicó en dos etapas (pre y post test) a 160 oyentes de la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón. Pregunta 1: ¿Con qué frecuencia usa aplicaciones de mensajería que guarden emoticones o GIF relacionados a la lengua de señas y los vuelva a sugerir automáticamente?
Figura 6. Relación del nivel de frecuencia de aplicaciones de mensajería
Análisis e interpretación: En la figura 6 se aprecia con claridad el nivel de frecuencia de uso de aplicaciones de mensajería por parte de la comunidad académica. En el pre test lo que más predominó fue “Casi nunca” con 28.13%, seguido con “A veces” con 25.63%, “Frecuentemente” con 18.13%, “Rara vez” con 17.50% y “Casi siempre” con 10.63%. Por otro lado, en el post test se mostró un nivel frecuencia de uso mayor en “Casi siempre” con 87.50%, “Frecuentemente” con 11.88% y “A veces” con 0.63%. Con los datos recabados se observó que en mayor porcentaje las personas comenzaron a utilizar aplicaciones de mensajería que le permitieran guardar GIF o emoticones relacionados con lengua de señas. Pregunta 2: ¿Qué tan probable es que logre comunicarse en tiempo real a través de lengua de señas con una persona sorda?
Figura 7. Probabilidad de comunicación en tiempo real
33 Análisis e interpretación: En la figura 7 se aprecia el nivel de probabilidad de comunicación en tiempo real por medio de lengua de señas. En el caso del pre test lo que predominó fue 1 (uno) con 23.13%, seguido con otros aspectos como 2 (dos) con 13.13%, 3 (tres) y 5 (cinco) con 12.50%, 0 (cero) con 10.00%, 4 (cuatro) con 10.63%, 6 (seis) con 5.63%, 8 (ocho) con 4.38%, 7 (siete) con 3.75%, 10 (diez) 2.50% y 9 (nueve) con 1.88%. Mientras que con el post test se observó un cambio significativo, ya que el 86.25% mencionó que un 10 (diez), 9 (nueve) con 13.13% y 8 (ocho) con 0.63%. Con los resultados obtenidos se constató un incremento en el uso del aplicativo, a su vez aumentó la posibilidad de poderse comunicar por medio de lengua de señas en tiempo real. Pregunta 3: ¿Con qué frecuencia usa aplicaciones que sugieran predicciones de palabras o pictogramas (emoticones o GIF) usados con anterioridad?
Figura 8. Nivel de frecuencia de uso de aplicaciones que sugieren predicciones
Análisis e interpretación: En la figura 8 se observa un nivel de frecuencia de uso de aplicaciones que sugirieran predicciones. Para el pre test lo que más se caracterizó fue “A veces” con un 30.00%, seguido con “Rara vez” con 25.00%, “Frecuentemente” con 17.50%, “Casi nunca” con 16.88% y “Casi siempre” con el 10.63%. Mientras que el post test se puede evidenciar un nivel de frecuencia mayor en “Casi siempre” con 58.13%, seguido por “Frecuentemente” con 40.63% y “A veces” con 1.25%. Con la información recolectada se observó que en mayor porcentaje se extendió la posibilidad de usar aplicaciones que sugieran predicciones. Pregunta 4: ¿Qué tipos de aplicaciones tiene usted actualmente en su(s) dispositivo(s) digitales (computadoras, tabletas, teléfonos, etc.)? Marque todas las que aplique.
34
Figura 9. Tipo de aplicaciones en los dispositivos digitales
Análisis e interpretación: En la figura 9 se observa el tipo de aplicaciones instaladas en los dispositivos. Para el pre test lo que más destacó fue “Redes sociales” con un 41.13%, seguido con los resultados de los otros aspectos como “Utilidades” con 22.58%, “Educativas” con 9.41%, “Juegos” con 9.41%, “Noticias” con 7.53% “Viajes” con 5.11% y “Deportes” con 4.84%. Mientras que con el post test destacó un incremento del 11.48% en el uso de aplicaciones educativas que llegó a tener 20.89%, “Redes sociales” con 20.11%, “Utilidades” con 15.24%, “Juegos” con 13.27%, “Noticias” con 12.88%, “Viajes” con 8.94% y “Deportes” con 8.67%. Con los datos tabulados se observó que existe un aumento en el uso de aplicaciones relacionas con lengua de señas ecuatoriana. Pregunta 5: ¿Cuántas aplicaciones tiene actualmente en su celular?
Figura 10. Cantidad de aplicaciones en el celular
Análisis e interpretación: En la figura 10 se observa la cantidad de aplicaciones instaladas en el móvil. Se realizó sólo el pre test por la particularidad de la pregunta, lo que más se caracterizó es “10 o más” con un 34.38%, seguido con los resultados de “4-6” con 31.25%, “7-9” con 19.38%, “1-3” con 13.75% y “0” con 1.25%. Con los resultados obtenidos
35 se observó que en mayor porcentaje los usuarios tienen 10 o más aplicaciones de uso cotidiano en su vida laboral y personal. Pregunta 6: ¿Qué sistema operativo posee en su móvil?
Figura 11. Sistema operativo en el móvil
Análisis e interpretación: En la figura 11 se determina el sistema operativo móvil instalado en los dispositivos de las personas encuestadas. Se realizó sólo el pre test por la particularidad de la pregunta, lo que más predominó fue “Android” con un 88.75%, por otro lado “iOS” con 10.00%, “KaiOS” y “Windows Phone” con 0.63%. Con los resultados obtenidos se observó que en mayor porcentaje los usuarios tienen Android como sistema operativo, siendo el software más común entre ellos. Cabe indicar que esta pregunta fue realizada para capturar las historias técnicas en la ingeniería de requerimientos con enfoque ágil. Pregunta 7: ¿Cuál es la probabilidad de poder transmitir una idea a un estudiante con discapacidad auditiva si no se encuentra el intérprete de lengua de señas y/o la utilización de una aplicación educativa?
Figura 12. Probabilidad de poder transmitir una idea a un estudiante con DA
Análisis e interpretación: En la figura 12 se observa el nivel de probabilidad de que un usuario pueda transmitir una idea a un estudiante con discapacidad auditiva. Para el pre test lo que más predomina es 1 (uno) con un 15.00%, 2 (dos) y 3 (tres) con 13.75%, 4 (cuatro) con
36 11.25%, 5 (cinco) con 8.75%, 0 (cero) con 8.75%, 8 (ocho) con 8.13%, mientras que con el post test se detalla un cambio extremo, ya que el 91.88% menciona un 10 (diez) y 9 (nueve) con 8.13%. Con los resultados reflejados se observó que, en mayor porcentaje mediante el uso del aplicativo, los oyentes pueden comunicarse con las personas con DA. Pregunta 8: ¿Cuántas aplicaciones en su celular permiten a personas con discapacidad auditiva tener total acceso a sus funcionalidades?
Figura 13. Aplicaciones en el celular con accesibilidad para personas con DA
Análisis e interpretación: En la figura 13 se observa la cantidad de aplicaciones con accesibilidad para personas con DA. Para el pre test lo que más se caracterizó fue 0 (cero) con un 45.63%, seguido con los resultados de 1-3 (una a tres) con 34.38%, 4-6 (cuatro a seis) con 12.50%, 7-9 (siete a nueve) con 4.38% y 10 o más con 3.13%; mientras que con el post test se detalla un cambio extremo, ya que el 100.00% mencionó que 1-3 (una a tres). Con los datos obtenidos se observó un incremento satisfactorio en el número de aplicaciones que los usuarios con DA pueden tener accesibilidad. Pregunta 9: ¿Considera que las aplicaciones de mensajería en su smartphone ayudan a personas con discapacidad auditiva a comunicarse mediante lengua de señas?
37
Figura 14. Aplicaciones de mensajería que permiten la comunicación mediante LSEC
Análisis e interpretación: En la figura 14 se observa el nivel de ayuda de aplicaciones de mensajería que permiten la comunicación mediante LSEC. Para el pre test lo que más predominó fue “Poco” con un 33.13%, seguido con los resultados de “Suficiente” con 25.38%, “Mucho” con 25.00%, “Demasiado” con 11.25% y “Nada” con 6.25%, mientras que con el post test se detalla un cambio significativo, ya que el 83.13% mencionó que “Demasiado” con 83.13%, seguido con “Mucho” con 16.88%. Con los datos obtenidos se reflejó un aumento significativo en el nivel de aplicaciones de mensajería que permiten la comunicación mediante la lengua de señas ecuatoriana. 4.1.5. Resultados de las encuestas a la comunidad educativa con DA La encuesta se aplicó en dos etapas (pre y post test) a los 3 estudiantes con DA de la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón. Cabe indicar que cada pregunta fue adaptada en lengua de señas ecuatoriana en formato video y se detallan a continuación: Pregunta 1: ¿Con qué frecuencia usa aplicaciones de mensajería que guarden emoticones o GIF relacionados a la lengua de señas y los vuelva a sugerir automáticamente? Enlace para personas con DA: bit.ly/3ycDtFg
38
Figura 15. Relación del nivel de frecuencia de aplicaciones de mensajería
Análisis e interpretación: En la figura 15 se aprecia con claridad el nivel de frecuencia de uso de aplicaciones de mensajería por parte de los alumnos con DA, luego de haber utilizado el aplicativo. En el pre test lo que más predominó es “Rara vez” con el 100.00%, en cambio en el post test se mostró un nivel de interés mayor en “Frecuentemente” con 100.00%. Con los datos recabados se observó que los estudiantes con DA usan aplicaciones de mensajería que les permita guardar GIF o emoticones relacionados con lengua de señas. Pregunta 2: ¿Qué tan probable es que logre comunicarse en tiempo real a través de lengua de señas con una persona oyente? Enlace para personas con DA: bit.ly/3iSN3qn
Figura 16. Probabilidad de comunicación en tiempo real con personas oyentes
Análisis e interpretación: En la figura 16 se aprecia el nivel de probabilidad de comunicación en tiempo real por medio de lengua de señas ecuatoriana. En el caso del pre test lo que predominó es 1 (uno) con un 100.00% mientras que con el post test se observa un cambio significativo, ya que 100.00% mencionó que un 9 (nueve). Con los datos reflejados se observó un mayor porcentaje en el uso del aplicativo, ya que las personas con DA pueden comunicarse con los oyentes mediante LSEC en tiempo real.
39 Pregunta 3: ¿Con qué frecuencia usa aplicaciones que sugieran predicciones de palabras o pictogramas (emoticones o GIF) usados con anterioridad? Enlace para personas con DA: bit.ly/3kYB6C9
Figura 17. Nivel de frecuencia de uso de aplicaciones que sugieren predicciones
Análisis e interpretación: En la figura 17 se observa el nivel de frecuencia de uso de aplicaciones que sugieran predicciones. Para el pre test predominó “A veces” con un 30.06%, seguido “Rara vez” con 24.54%, “Frecuentemente” con 17.79%, “Casi nunca” con 16.56% y “Casi siempre” con 11.04%, mientras que con el post test el 58.28% mencionó que “Casi siempre”, “Frecuentemente” un 40.49% y “A veces” con 1.23%, determinando un cambio significativo. Con los datos obtenidos se observó mayor frecuencia en el uso de aplicaciones que sugieran predicciones. Pregunta 4: ¿Qué tipos de aplicaciones tiene usted actualmente en su(s) dispositivo(s) digitales (computadoras, tabletas, teléfonos, etc.)? Marque todas las que aplique. Enlace para personas con DA: bit.ly/3rDw6UK
Figura 18. Tipo de aplicaciones en los dispositivos digitales
Análisis e interpretación: En la figura 18 se observa el tipo de aplicaciones en los dispositivos. Para el pre test lo que predominó es “Redes sociales”, seguido de “Utilidades” y “Juegos” con un 33.33%, mientras que con el post test destacó un incremento del 11.30% en
40 aplicaciones educativas, llegando al 25.00% al igual que “Redes Sociales”, “Utilidades” y “Juegos”. Con los datos tabulados se determinó que existe un aumento en el uso de aplicaciones relacionas con LSEC. Pregunta 5: ¿Cuántas aplicaciones tiene actualmente en su celular? Enlace para personas con DA: bit.ly/3rCo5iM
Figura 19. Cantidad de aplicaciones en el celular
Análisis e interpretación: En la figura 19 se observa la cantidad de aplicaciones instaladas en el móvil. Se realizó sólo el pre test por la particularidad de la pregunta, lo que más se caracterizó es “4-6” con el 100.00%. Con los resultados obtenidos se determinó el número de aplicaciones de uso cotidiano en el ámbito personal, educativo y laboral. Pregunta 6: ¿Qué sistema operativo posee en su móvil? Enlace para personas con DA: bit.ly/2UT5t29
Figura 20. Sistema operativo en el móvil
Análisis e interpretación: En la figura 20 se determina el sistema operativo móvil instalado en los dispositivos de los estudiantes con DA. Se realizó sólo el pre test por la particularidad de la pregunta, se observó al sistema operativo Android con el 100.00%. Con los resultados obtenidos se comprobó que todos los estudiantes tienen Android. Cabe indicar
41 que esta pregunta fue realizada para capturar las historias técnicas en la ingeniería de requerimientos con enfoque ágil. Pregunta 7: ¿Cuál es la probabilidad de poder transmitir una idea a una persona oyente si no se encuentra un intérprete de lengua de señas y/o la utilización de una aplicación inclusiva? Enlace para personas con DA: bit.ly/3i7p0EL
Figura 21. Probabilidad de transmitir una idea a un oyente
Análisis e interpretación: En la figura 21 se observa el nivel de probabilidad de que una persona con DA pueda transmitir una idea a una persona oyente. Para el pre test lo que más prevaleció fue 1 (uno) con 66.67% y 0 (cero) con 33.33%, mientras que con el post test se detalló un cambio evidente, ya que el 66.67% mencionó que 9 (nueve) y el 33.33% un 10 (diez). Con los datos obtenidos se determinó un mayor uso del aplicativo por parte de las personas con DA para poder comunicarse con un oyente sin la intervención del intérprete. Pregunta 8: ¿Cuántas aplicaciones en su celular le permiten entender y usar todas sus funcionalidades? Enlace para personas con DA: bit.ly/3l4003c
Figura 22. Aplicaciones en el celular que permitan entender y usar sus funcionalidades
42 Análisis e interpretación: En la figura 22 se observa la cantidad de aplicaciones con accesibilidad para personas con DA. Para el pre test lo que más predominó es 0 (cero) con el 100.00%, mientras que con el post test se constató un cambio extremo, ya que el 100.00% menciona que 1-3 (una a tres). Con los datos obtenidos se concluyó que, con el uso absoluto del aplicativo se incrementó satisfactoriamente el número de aplicaciones, en donde los usuarios con DA logren tener accesibilidad a todas sus funciones. Pregunta 9: ¿Considera que las aplicaciones de mensajería en su smartphone ayudan a personas con discapacidad auditiva a comunicarse mediante lengua de señas? Enlace para personas con DA: bit.ly/3i7Tl6k
Figura 23. Aplicaciones de mensajería que permiten la comunicación mediante LSEC
Análisis e interpretación: En la figura 23 se observa el nivel de ayuda de aplicaciones de mensajería que permiten la comunicación mediante LSEC. Para el pre test lo que más predominó es “Poco” con el 100.00%, mientras que en el post test se evidenció un cambio significativo, ya que el 66.67% mencionó que “Demasiado” y otro 33.33% “Mucho”. Con los datos obtenidos se determinó un aumento significativo en el nivel de aplicaciones de mensajería, que permiten la comunicación mediante la lengua de señas ecuatoriana a estudiantes con DA.
4.2. Resultado dos: Sistema pictográfico para estudiantes con DA 4.2.1. Sistema pictográfico El sistema SPC (Símbolos Pictográficos para la Comunicación) es una ayuda que requiere recursos técnicos y externos para llevar a cabo el acto comunicativo, permite una
43 comunicación intuitiva por medio de símbolos pictográficos, no dispone de reglas sintácticas o gramaticales. Es utilizado por personas que no pueden hablar, leer, escribir o demuestran dificultad para hacerlo. Desde el punto de vista de Aymerich (2009), los pictogramas son signos o dibujos, es un tipo de escritura que utiliza recursos gráficos para simbolizar una frase, oración o párrafo, explicar un hecho o cualquier otra forma de comunicación escrita. Además, son perceptibles, simples y permanentes a la hora de comprender la idea que se quiere dar a conocer. Pictograma es una estructura gráfica que se conforma de un símbolo y elementos adicionales como un borde, dibujo o color de fondo y sirve para comunicar algo concreto. Dentro de sus características se tiene que son recursos educativos que muestran información limitada o completa. Además, de ser llamativo, colorido e interesante (Parra, 2018). 4.2.1.1.
Ventajas de los pictogramas De acuerdo a Escandel, Marrero & Casado (2014), dentro del área académica las
ventajas al usar pictogramas son:
Permite al alumno tener mucha seguridad y tranquilidad al poder anticipar lo que vendrá.
4.2.1.2.
Disminuye la frustración por no poder leer.
Personalización.
Indiferente al idioma, se logra comprender.
Los puede usar cualquier persona.
Funcional. ¿Cómo se elaboran los pictogramas?
Según Naranjo (2017), para elaborar un pictograma de manera efectiva es recomendable lo siguiente:
Los dibujos deben ser de manera sencilla, posean un esquema y que se ajusten a la realidad.
44
Que se escriba en la parte superior o inferior la descripción textual de lo que representa.
Que en el dibujo se incrementen señales de forma determinada para ampliar la información de lo que se quiere representar.
Que se desarrolle en acompañamiento y sugerencia de la parte beneficiada
Verificar si es entendible para la persona que lo va a usar
4.2.1.3.
Pictogramas como medio de comunicación
Los pictogramas permiten expresar por medio de dibujos o símbolos una frase o un escrito, hoy en día son muy utilizados como un recurso didáctico dentro de los primeros años de educación escolar, lo que permite fortalecer la comunicación, desarrollar el lenguaje, especialmente en alumnos con necesidades especiales y problemas del habla. 4.2.2. Diagrama del proceso de pactar señas
Figura 24. Diagrama del proceso de pactar señas
En el proceso de pactar señas participa el intérprete y el estudiante con discapacidad auditiva, quienes identifican los términos dentro del diccionario de lengua de señas ecuatoriana
45 “Gabriel Román”, en caso de no existir la seña se la crea basándose en sinónimos o características del término nuevo, como se muestra en la figura 24.
4.2.3. Pictogramas desarrollados Por medio del proceso de pactar señas entre el intérprete y el estudiante con discapacidad auditiva, se crearon señas para términos no existentes en el diccionario de lengua de señas ecuatoriana “Gabriel Román” y se plasmaron en animaciones GIF, los términos creados son en relación a las materias técnicas impartidas en el semestre que se encuentran las personas con discapacidad auditiva, como se muestra en la tabla 7. Tabla 7. Pictogramas clasificados por categoría Materia
Categoría
Guarnición
Platos
Postres Cocina Ecuatoriana
Términos
Técnicas de bares y restaurantes
Ninguna
Palabra Caramelo de naranja y ají Clarificación Crujiente de queso parmesano Flor de tomate cherry Flores con rábanos y pepinos Ganache de chocolate Mousse de aguacate Nido de remolacha Bolones de queso y chicharrón Caldo de gallina Cariucho de cuy Guarnición con huevo Locro tradicional Maito Papa crocante Pato al lodo Tortillas de maíz Cheescake Crema de queso Dulce de higos Frutas frescas Aguacate Atún Banano/Guineo Bolón Camarón Ceviche Choclo Cuy Humitas Patacón Aperitivo Barra mostrador Bebidas alcohólicas Buffet Cafetería Canapés Cóctel Cócteles aperitivos Cócteles de sobremesa Cócteles digestivos Cócteles nutritivos Cócteles refrescantes Montaje de mesa
Link del repositorio
bit.ly/3BXlrJo
bit.ly/3rGCZVs
bit.ly/3x7KXId
https://bit.ly/3rF7ZVS
https://bit.ly/2VcGNkX
46
Cocina de alto volumen
Ninguna
Abecedario
Ninguna
Términos generales usados en el aula
Ninguna
Plancha de cocina Sándwiches fríos Servicio a la francesa Servicio a la inglesa Servicio gueridón Servicio al plato Tostadas Blunch Brinner Brunch Buffet Calorías Campestre Catering eventos especiales Catering industrial Catering móvil Cocktail Cocktail de fiesta Dieta hipo proteica Dieta hipo sódica Drunk fast Picnic TMB (tasa metabólica basal) Abecedario Aprobado Atraso Aula Autoridad Clase Coordinador Deber Esperar Examen Explicar Exposición Internet Investigación – Investigar Meet Notas Página web Pregunta
https://bit.ly/3iX3t0G
bit.ly/3yhodXs
bit.ly/37bqCao
4.3. Resultado tres: Aplicativo móvil con machine learning 4.3.1. Nomenclatura y logotipo La aplicación móvil con machine learning tiene la nomenclatura “SignIES”, en la figura 25 se encuentra el logotipo. La nomenclatura proviene de dos palabras: Sign proviene de Seña, IES de Institución de Educación Superior.
Figura 25. Logotipo de aplicativo móvil
47 4.3.2. Marco de trabajo Scrum Según Schwaber & Sutherland (2020), “Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo” (pág. 3). Con esta premisa, se utilizó el marco de trabajo denominado Scrum, que permite el desarrollo de la app mediante la gestión adaptativa en el desarrollo del aplicativo móvil con machine learning para el fortalecimiento de la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón. Se detalla el procedimiento a continuación para la evidencia del desarrollo de la propuesta. 4.3.3. Sprint 1 4.3.3.1.
Planificación del Sprint 1 Planificar es la primera etapa para el proceso de desarrollo, es una de las más
importantes para el éxito de la aplicación. El contexto de trabajo Scrum se ejecuta a través de un sprint tomando como base las prioridades y/o necesidades del cliente. 4.3.3.1.1.
Roles
En el contexto del proceso se fijan los roles, marcando su función. El Product Owner es el responsable del Product Backlog permitiendo alcanzar los objetivos de mejor forma, por otro lado, el Scrum Master garantiza que el equipo de desarrollo se adapte correctamente al marco de trabajo, mientras que el Scrum Team son los encargados de elaborar y entregar la app terminada. El rol asignado de cada persona se observa en la tabla 8. Tabla 8. Roles Scrum Rol Product Owner Scrum Master Scrum Team
Persona Tnlga. Yidah Julia Pinzón Alvarado Mg. William Ocampo Ing. Miguel Mantuano e Ing. Jeneffer Barberán
Área Intérprete de la carrera de Gastronomía Docente PUCE-SD Analistas, diseñadores, testers y desarrolladores
Nota: Adaptado de “What is Scrum?”, https://www.scrum.org/resources/what-is-scrum
4.3.3.1.2.
por
Scrum,
2020,
recuperado
de
Arquitectura de Software
En base a las historias técnicas se definió el patrón arquitectónico Modelo-VistaControlador.
48
Modelo: es donde se almacena los datos del sistema, se utilizó la base de datos Oracle XE.
Vista: muestra los datos para el usuario.
Controlador: tiene como finalidad recibir los datos del modelo y presentarlos en vista para el usuario.
4.3.3.1.3.
Parametrización
Para llegar a un acuerdo entre el equipo de desarrollo se recurrió a la parametrización de los distintos compendios en el código fuente de la app móvil y se muestra en la tabla 9. Tabla 9. Parametrización Modelo Categorias.java Chat.java Contactos.java Destacados.java Paises.java Pictogramas.java Roles.java Usuarios.java
Vista index.xhtml login.xhtml cambiarclave.xhtml contacto.xhtml mensajes.xhtml contactos-edit.xhtml contactos-form.xhtml registro.xhtml categorias.xhtml chat.xhtml destacados.xhtml micuenta.xhtml categorias-edit.xhtml categorias-form.xhtml chat-move.xhtml pictogramas-edit.xhtml pictogramas-form.xhtml pictogramas-list.xhtml claves.xhtml chat.xhtml chat-audio.xhtml chat-recognition.xhtml
Controlador UserLoginController.java ContactosController.java UsuarioController.java CategoriasController.java ChatController.java PictogramasController.java DestacadosController.java Agente.java
Nota: Modelo, vista y controladores obtenidos desde Netbeans
4.3.3.1.4.
Control de versiones
Para el correcto control de versiones se usó GitHub, la cual posibilita el desarrollo colaborativo, almacenamiento y administración del código fuente, permitiendo crear versiones de prueba sin dañar la versión funcional, además permite editar a todos los desarrolladores, generando que se trabaje en forma específica todas las partes de la app y que funcione de manera correcta para lograr una versión final óptima.
49 4.3.3.1.5.
Product Backlog
Contiene todas las funcionalidades de la app móvil, previamente se organizó una reunión con las partes interesadas para irlas generando y fijar sus prioridades. Las historias de usuario y los escenarios de prueba se encuentran en el anexo VII. Se detalla el nombre de la historia, ID, prioridad (1-100), la estimación de cada historia de usuario y el riesgo de desarrollo estimado como se muestra en la tabla 10. Tabla 10. Product Backlog versión 1.4 N° 1 2 3 4 5 6 7 8 9 10
Historias Login Registro Contactos Chat Categorías Pictogramas Machine Learning Destacar Reenviar Perfil de usuario
Estimación 13 13 13 13 13 13 13 8 5 5
Prioridad 90 90 90 80 70 70 70 30 30 30
Riesgo de desarrollo Alto Alto Alto Alto Alto Alto Alto Bajo Medio Bajo
Nota: Elaboración propia.
4.3.3.1.6.
Estimación
Se aplicó la métrica de puntos de historias, que se basa en la práctica del equipo de desarrollo. Además, se usó la serie Fibonacci, que es una variante de Planning Poker, durante las reuniones de los miembros del equipo de desarrollo se le asignó una baraja a cada uno y los números de la misma representaron la complejidad de la historia, por otra parte entre todos los que integran el grupo se evaluó la historia para asignar un valor de estimación, luego cada uno levantó una baraja que muestra la estimación de su experiencia, si todos los miembros eligen la misma carta se asigna el valor a la historia, por el contrario, se discute un acuerdo. 4.3.3.1.7.
Velocidad de desarrollo
Se tomó en cuenta la estimación de cada una de las historias de usuario que se priorizó por parte del dueño del producto, asignando para el primer sprint la primera, segunda y tercera historia con un total de 40 puntos de estimación, que es la velocidad de desarrollo. 4.3.3.1.8.
Fertilización cruzada
Permitió obtener la funcionalidad para la aplicación en las historias de usuario y dando prioridad a cada una de ellas, mediante las reuniones donde participó el propietario del producto
50 de manera directa y el equipo de desarrolladores. Además, se detallan los escenarios de prueba que se realizaron en cada historia. 4.3.3.1.9.
Escenarios de prueba
En la etapa de planificación se elaboraron las historias de usuario que incluyen los escenarios de prueba de las mismas, a través del método (dado, cuando, entonces). Los escenarios se convirtieron más tarde en pruebas de aceptación que fueron aprobados por la intérprete de lengua de señas ecuatoriana de la carrera de Gastronomía, la cual aprobó la funcionalidad terminada de cada una de ellas (Anexo VII). 4.3.3.1.10.
Gestión de incidencias
En la elaboración de la aplicación se usó la gestión de incidencias, como una herramienta para la gestión de trabajos ágiles, permitiendo solventar problemas o hechos inesperados, haciendo que los desarrolladores se sientan seguros de que existe un control total sobre cualquier situación o incidencia. Para la gestión de incidencias se utilizó la herramienta Jira que permite la visualización del progreso durante el ciclo de desarrollo, por medio de la comunicación y transparencia, la planificación de sprints y desarrollo interactivo, además permitió mejorar el enfoque y la organización del equipo al dividir el trabajo en etapas (Atlassian, 2021). Según Atlassian (2021), en Jira software se tiene como opción la plantilla del proyecto Scrum, donde el tablero Kanban está estructurado de la siguiente manera:
Primera columna se colocan las actividades por hacer.
Segunda columna se encuentran las actividades en curso.
Tercera columna las tareas ya finalizadas del sprint seleccionado.
En la figura 26 se observa el product backlog, las tareas realizadas y el punto de estimación de cada una. Las tareas que no se encuentran dentro de un sprint se quedan en el backlog hasta que sean arrastradas y colocadas dentro de un sprint.
51
Figura 26. Product backlog
4.3.3.1.11.
Sprint Backlog
Se seleccionó para el primer sprint las 3 historias con más prioridad según el Product Owner, las cuales suman 39 puntos de estimación. Luego, se procedió a realizar el Sprint Backlog, donde se plasman las tareas específicas que pertenecen a las historias de usuarios que se van a ejecutar en el sprint, trabajando de forma conjunta para lograr los objetivos planteados (Tabla 11). Tabla 11. Sprint Backlog del Sprint 1 Sprint Backlog Objetivo: Desarrollar la funcionalidad del primer producto mínimo viable correspondiente al inicio de sesión, registro de usuario y creación de contactos.
SPRINT
HISTORIA
HU1-Login
EST CATEGORÍA
13
Diseño Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Tester Desarrollo Desarrollo
HU2-Registro
13
1
Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo
HU3-Contactos
13 Desarrollo Desarrollo Desarrollo
TAREA
EST
Modelado del diagrama entidad-relación, modelo lógico y físico. Creación de la BD en el motor Oracle XE Crear la conexión de la base de datos con el servidor Payara Creación de la AbstractFacade.java que contenga el CRUD Creación del modelo Usuario.java y de la vista login.xhtml Elaborar el controlador UserLoginController.java para la conexión entre el modelo y la vista, además de verificar que el usuario se encuentre registrado en la BD Pruebas unitarias de la clase mediante JUnit Creación de la interfaz Serializable en el modelo Usuario.java, donde se encuentran los campos requeridos para el registro del usuario. Creación de la vista registro.xhtml para interpretar los datos del registro Conexión del controlador UserLoginController.java con la vista registro.xhtml para que los datos llenados sean enviados a la BD. Creación del método create para mostrar un mensaje de confirmación al crear la cuenta. Creación del trigger TGUSUARIOSBEFORE para prevenir errores en la tabla Usuarios de la BD Creación del modelo Contactos.java con la interfaz Serializable. Elaborar la vista contactos-form.xhtml para la creación del contacto en la cuenta de la persona logueada. Elaborar la vista contactos-edit.xhtml para la edición de los contactos. Elaborar las vistas contacto.xhtml para la vista de todos los contactos registrados en la cuenta. Creación del método create en el controlador ContactoController.java y el enlace con la vista contacto.xhtml Creación de una secuencia SEQCONCODIGO para la generación de valores únicos Creación del trigger TGUCONTACTOSBEFORE para prevenir errores en la tabla contactos de la BD
2 2 2 2 2
Nota: Elaboración propia. HU: Historia de usuario.
2 1 2 3 3 3 2 2 2 2 2 3 1 1
52 4.3.3.2.
Reuniones diarias del Sprint 1 –Daily Scrum Son reuniones informales donde se reunió el equipo de trabajo de 10 a 15 minutos antes
del inicio de la jornada para describir avances, planeación diaria, novedades o inconvenientes en relación a las tareas a realizar en dicha jornada. Las reuniones diarias permitieron evaluar el proceso del sprint. Para visualizar las actividades realizadas se utilizó Jira que es un software de gestión de proyectos para medir el rendimiento y la creación de informes. Jira permite trabajar con el marco Scrum que promueve la toma de decisiones de manera rápida a través de la planificación y supervisión de las actividades por hacer, en curso y listas. 4.3.3.2.1.
Historia de usuario 1: Login
Las descripciones de las historias de usuario se encuentran en el Anexo VII, en la parte de diseño se realizó el diagrama entidad-relación para el primer sprint, se procedió con el modelo lógico y finalmente el modelo físico donde se representa a los objetos de datos relacionales (tablas, columnas, claves principales y claves externas) y sus relaciones como se observa en la figura 27.
Figura 27. Modelo físico para el sprint 1
Para crear la historia 1, se instaló Oracle XE que es el motor de base de datos, luego se configuró el Payara Server Community (servidor de aplicaciones de código abierto derivado de GlassFish Server Open Source Edition). La conexión de la base de datos con el servidor Payara requirió el driver de Oracle XE que es ojdbc8-12.2.0.1 en la ruta C:\payara5\glassfish\domains\domain1\lib\ext como se muestra en la figura 28.
53
Figura 28. Drive ojdbc8 para conexión de la base de datos con el servidor Payara
Oracle XE y los servidores web Java como Payara, Glassfish, Tomcat, JBoss, Weblogic utilizan el puerto 8080, por ese motivo se cambió el puerto de listener de los clientes modificando
el
archivo
domian.xml
que
se
encuentra
en
la
ruta
C:\payara5\glassfish\domains\domain1\config, luego se cambió el listener al puerto 7777 y el LISTENER_PORT del system de 28080 a 27777 como se observa en la figura 29 y 30, respectivamente.
Figura 29. Cambio de puerto del servidor Payara
Figura 30. Cambio de puerto LISTENER_PORT del system
Para iniciar el servidor Payara se abrió el archivo asadmin en la ruta C:\payara5\bin, una vez abierta la consola se escribió y ejecutó el comando start-domain y stop-domain para iniciar el servidor y apagarlo respectivamente, como se muestra en la figura 31.
Figura 31. Activar servidor Payara
El framework de persistencia que se ocupó es el JPA que permitió trabajar con entidades persistentes conectadas a una base de datos. El fichero de configuración JPA es persistence.xml, donde la unidad de persistencia (PU) es inclusivaPU de tipo JTA, es decir que la PU se encarga de administrar las transacciones del lado del servidor aislando la mayor parte al programador de abrir o cerrar las transacciones, para ello se enlazó la conexión Pool JDBC con InclusivaDS, como se muestra en la figura 32.
Figura 32. Fichero persistence.xml
de
configuración
JPA
La clase UsuariosFacade.java permite interactuar varios subsistemas mediante una única interfaz como se muestra en la figura 33. Esta a su vez está enlazada a la clase AbstractFacade.java que es una clase abstracta que contiene lo necesario para el CRUD
54 (Create, Read, Update and Delete) permite crear, leer, actualizar y borrar los registros de la base de datos (Figura 34).
Figura 33. Clase UsuarioFacade.java
Figura 34. Clase AbastractFacade.java
El controlador responde a las interacciones que hace el usuario y realiza las peticiones al modelo para luego pasarlos a la vista. Se creó el controlador UserLoginController.java para la conexión entre el modelo usuario.java y la vista login.xhtml, validando la información de usuario y clave ingresadas con la base de datos, permitiendo el ingreso a la aplicación si los datos son correctos, caso contrario saldrá un mensaje de “Credenciales incorrectas”. Se agregó la librería ScryptUtil que permite chequear a un usuario para verificar si su clave está o no encriptada. Es decir, si una clave es igual a la registrada en la base de datos permite el ingreso. Además, se obliga el cambio de clave para poderla encriptar, como se muestra en la figura 35. El software JUnit es un framework para realizar y automatizar las pruebas de aplicaciones en Java. Las pruebas unitarias en JUnit se realizaron para la detección de errores, permitiendo aumentar la fiabilidad del software, a la vez implica el seguimiento de buenas prácticas. En la figura 36 se observan las pruebas unitarias del Login, dando un porcentaje de 100% analizado sin errores.
55
Figura 35. Controlador UserLoginController.java
4.3.3.2.2.
Figura 36. Pruebas Unitarias del Login en JUnits4
Historia de usuario 2: Registro
El modelo utilizado para el registro de usuario es el usuario.java creado con anterioridad, ahora con una interfaz Serializable, donde se encuentran los campos para el registro del usuario como el usuusuario, usuclave, usunombres, usunumcelular, usuaceptaterminos, usufotoperfil para el id del usuario registrado, la clave para la cuenta, nombres, número de celular, aceptación de términos y foto de perfil respectivamente, como se observa en la figura 37. Dentro de la vista registro.xhtml se observa los parámetros: usuario, clave, nombres, correo y celular que se deben ingresar para poder registrar un usuario a la aplicación, además se solicita estar de acuerdo con los términos y condiciones para la creación de la cuenta. Adicional, se muestra un mensaje cuando un campo no es llenado y es requerido (Figura 38).
56
Figura 37. Creación de la interfaz Serializable para el registro del usuario
Figura 38. Parámetros para el registro del usuario
Para el registro de nuevos usuarios se realizó la comunicación entre el controlador UserLoginController.java con la vista registro.xhtml, se utilizó try-catch para no presentar errores en la pantalla del cliente, hasta el momento no está creado el usuario en la base de datos, solo se creó un objeto que deberá ser llenado y después enviado a la base de datos (Figura 39).
Figura 39. Conexión del controlador con el registro.xhtml
Dentro del controlador UserLoginController.java se realizó el método public void create que permite mostrar un mensaje de confirmación “Usuario creado con éxito” una vez creada la cuenta del usuario, para luego direccionar a la vista login.xhtml que corresponde al inicio de sesión, como se observa en la figura 40.
Figura 40. Creación de usuario exitoso y direccionamiento a la vista login.xhtml
El trigger se ejecuta cuando sucede un evento en las tablas a las que se encuentra asociado, almacenando un dato por defecto para prevenir errores en la base de datos al
57 momento de modificar valores, sincronizar tablas, etc. Para ello se creó uno llamado TGUSUARIOSBEFORE para definir por defecto el rol del usuario y país en caso de no ser seleccionado al momento de realizar el registro del usuario (Figura 41).
Figura 41. Trigger TGUSUARIOBEFORE para país y usuario
4.3.3.2.3.
Historia de usuario 3: Contacto
En el modelo contacto.java se creó la clase contactos con la interfaz Serializable, donde se encuentran los campos de la tabla contactos que son el alias (usuusuario), nombre del usuario (conmombres), numero de celular (concelular), además el campo consuapp para verificar si el usuario posee la aplicación, como se muestra en la figura 42.
Figura 42. Creación del modelo Contactos.java con la interfaz Serializable
Se crearon las vistas contacto.xhtml, contacto-edit.xhtml, contacto-form.xhtml para la vista, edición y creación de los mismos respectivamente. En la figura 43, se observa la vista contacto-form.xhtml donde se tiene los parámetros: nombres y celular, en caso de no ingresarlos se cancelará el registro. Además, posee un botón para guardar el contacto y un botón para regresar sin realizar registros.
58 En la vista contacto-edit.xhtml se puede editar los campos almacenados como nombre del contacto y número de teléfono, campos necesarios al momento de registrar un contacto. Además, se muestra un mensaje de ingreso obligatorio de información en caso de querer dejar vacío uno de los campos, como se observa en la figura 44.
Figura 43. Creación de contacto
Figura 44. Edición de contacto registrado
Para la creación de contactos en la cuenta de un usuario se tiene el método create en el controlador ContactoController.java, una vez creado el contacto con éxito se almacena en la base de datos y se direcciona a la vista contacto.xhtml que muestra al usuario el contacto creado (Figura 45).
Figura 45. Creación de contacto y vista del mismo
La secuencia es un objeto que se emplea para la generación de valores únicos-enteros para luego asignarlos a campos numéricos. SEQCONCODIGO permite crear un código incremental desde 1 hasta 99999999 al momento de generar un nuevo contacto, con aumento de 1 en 1 y con un registro inicial de 4, si la tabla contacto llega al máximo valor se bloquea el inicio de la secuencia, además no almacena datos de secuencia en memoria (Figura 46).
Figura 46. Secuencia para la generación de valores únicos
Para generar la secuencia del código primario de la tabla contacto se creó el trigger TGCONCTACTOSBEFORE, se dispara antes de hacer una inserción en la tabla mencionada,
59 ocurre cuando el código es nulo y se selecciona la siguiente secuencia con la sentencia SEQCONCODIGO.NEXTVAL, se inserta en el nuevo campo CONCODIGO como se muestra en la figura 47.
Figura 47. Trigger para la inserción del campo concodigo
4.3.3.2.4.
Gráfico de trabajo pendiente del Sprint 1
En la figura 48, se muestra el trabajo pendiente durante el desarrollo de las tareas del sprint 1, en el tercer día se añadieron dos historias nuevas que generaron un cambio de alcance, además ciertas sub-tareas de las dos primeras historias fueron finalizadas el último día debido a que eran dependientes unas de otras.
Figura 48. Gráfico de Sprint 1
4.3.3.3.
Revisión del Sprint 1 Una vez finalizado el primer sprint, se mantuvo una reunión entre el equipo de
desarrollo y el Product Owner con la finalidad de revisar las historias de usuarios correspondiente a esta etapa de desarrollo y comprobar el avance de la aplicación móvil. La reunión tuvo una duración de dos horas. El propósito general fue la retroalimentación de los avances y el trabajo en conjunto de las partes interesadas. Además, se analizó el product backlog para estimar las fechas de las tareas pendientes hasta ese instante. La actividad está evidenciada por medio de las pruebas de aceptación que se realizó con la técnica de caja negra y se aplicó por cada historia de usuario (Anexo VIII).
60 4.3.3.4.
Retrospectiva del Sprint 1 Como punto relevante del sprint, el equipo de desarrollo determinó una autoevaluación
para crear un plan de acciones y poderlo ejecutar en el siguiente sprint. Se consideró la estimación asignada a cada tarea y se trató de asignar de manera uniforme la carga de trabajo. Se desarrollaron las tres primeras historias, la reestructura de la base de datos y toda la base que involucra el ingreso a la app. Además, se realizaron pruebas unitarias que permiten organizar, actuar y afirmar que se valide el código y avanzar, caso contrario se debe corregir los errores hasta que desaparezcan. Se recomienda la retroalimentación constante entre el equipo Scrum y todas las partes involucradas en el desarrollo de la aplicación, pues de esto depende que se logre un producto 100% funcional y operativo con todas las necesidades cubiertas de la comunidad con discapacidad auditiva. 4.3.4. Sprint 2 4.3.4.1.
Planificación del sprint 2 – Sprint Planning En relación al sprint 2, se consideraron las historias de usuario cuatro, cinco, ocho y
nueve; donde se asignó la estimación que le corresponde a cada uno, obteniendo un puntaje de 39 puntos. Por otra parte, se realizó el sprint backlog, teniendo como objetivo desarrollar la funcionalidad correspondiente al chat para el envío y recepción de mensajes o pictogramas, los cuales pueden ser destacados y reenviados, como se observa en la tabla 12. Tabla 12. Sprint Backlog del Sprint 2 Sprint Backlog Objetivo: Desarrollar la funcionalidad correspondiente al chat para el envío y recepción de mensajes o pictogramas, los cuales pueden ser destacados y reenviados
SPRINT
HISTORIA
EST
CATEGORÍA
Desarrollo Desarrollo
2
HU4-Chat
13
Desarrollo Desarrollo Desarrollo
TAREA
Creación del modelo Chat.java y la clase chat con la interfaz Serializable. Creación de la vista chat.xhtml para visualizar u obtener un listado de chat entre el usuario logueado y el contacto seleccionado Creación del estilo de tipo CSS para poder alinear los textos en los objetos datatable-header, definir el color del texto y fondo delimitado por el código RGB. Creación del método getLazyModel para la verificación de contacto con la aplicación para el inicio del chat. Creación de los métodos públicos setGlobalMessage, getGlobalMessage y sendGlobal para modificar, obtener datos y enviar el mensaje creado respectivamente.
EST
2 2 2 2 2
61 Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo HU5-Categorías
13 Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo
HU8-Destacar
8
Desarrollo
Desarrollo Desarrollo Desarrollo Desarrollo HU9-Reenviar
5
Desarrollo Desarrollo
Creación del controlador ChatController.java para enlazar con los modelos Usuarios, Contactos y Chat. Trigger TGCHATBEFORE y la secuencia SEQCHACODIGO Creación del modelo Categorias.java para definir las propiedades de la tabla categorías Creación del formulario en la vista Categorias.xhtml para crear, editar y listar los pictogramas pertenecientes a la categoría creada. Creación del objeto datalist para listar todas las categorías en la base de datos. Creación del controlador CategoríaController.java junto con el método create para crear una nueva categoría y definirla para que se mantenga activa. Creación del método update en el controlador CategoríaController.java para la actualización de las categorías creadas. Creación del método List dentro del controlador para obtener un listado de las categorías creadas. Creación del método getTotalCategorias para obtener todos los registros almacenados en la BD. Trigger TGCATEGORIASBEFORE y la secuencia SEQCATCODIGO Creación del modelo destacados.java junto con la interfaz Serializable. Creación del objeto ViewChat dentro de la vista chat.xhtml para crear el submenú de destacar o eliminar un mensaje. Creación del objeto ViewDestacados para visualizar datos de tipo char del usuario logueado. Creación del controlador destacadosController, junto con el ejbFacadedes para acceder a los mensajes destacados almacenados en la base de datos Creación del método List dentro del controlador para obtener un listado de mensajes destacados que recibe como parámetro el usuario logueado Creación del método removeDestacados que no retorna valores y se activa cuándo se quiere remover un mensaje destacado. Creación del modelo chat.java para el reenvío de mensajes Creación de la vista chat.xhtml y chat-movie.xhtml para mostrar los mensajes reenviados. Creación del controlador destacadosController, junto con el método onRowSelect para reenviar el mensaje al usuario deseado. Creación del objeto chat para almacenar el mensaje reenviado en la base de datos.
2 1 2 2 1 2
2 2 1 1 1 1 2 2
1 1 1 2 1 1
Nota: Elaboración propia. HU: Historia de usuario.
4.3.4.2.
Reuniones diarias del Sprint 2 –Daily Scrum Todos los días el equipo se reunió 15 minutos para realizar la planeación diaria en
relación a las tareas de cada historia, dichas reuniones permitieron evaluar el proceso del sprint 2. 4.3.4.2.1.
Historia de usuario 4: Chat
En el modelo chat.java se creó la clase chat con la interfaz Serializable, donde se encuentran los campos comunes de la tabla chat que se relacionan con la base de datos y su respectivo tamaño, además chacodigo se adiciona como foreign key en la tabla destacados, como se muestra en la figura 49.
62 La vista chat.xhtml permite visualizar u obtener un listado de chat entre el usuario logueado y el contacto seleccionado, en el value se obtiene del controlador una lista de chat como filtro, se envía el usuario y celular del contacto. Tiene una clase de CSS original para que el texto del usuario se alinea a la derecha y del receptor se alinee a la izquierda del chat. Además, se visualiza el chat con su fecha y hora, usuario y el mensaje como tal (Figura 50).
Figura 49. Clase Chat para el ingreso de campos
Figura 50. Vista chat para obtener un listado del chat
Para que la pantalla sea responsive se creó un objeto de organización, haciendo que ocupe el 100% de ancho de la pantalla, para lo cual consta de una fila con 2 columnas, en la primera columna se tiene un ancho del 85% y es adaptativa con la clase ui-fluid y p-field para poder ingresar el texto a escribir. Además, posee un control en el límite de ingreso de palabras de 500 bytes. Para enviar el mensaje se tiene un botón que al ser presionado envía el mensaje al remitente y se actualiza la vista de datos, como se muestra en la figura 51. A continuación, se creó un apartado de tipo CSS para poder alinear los textos en los objetos datatable-header, además en el CSS original se definió el color del texto y fondo delimitado por el código RGB. La funcionalidad del color es identificar en el chat la persona que origina el mensaje con un fondo turquesa, mientras que el receptor tendrá un color blanco, como se observa en la figura 52.
63
Figura 51. Creación de la clase ui-fuild y p-field para el ingreso de texto en el chat
Figura 52. Estilo CSS del Chat
Se creó un método público para devolver una lista de objetos de tipo char, a través del método getLazyModel se recibe dos string el usuario original y de destino. El usuario destino se identifica mediante el número telefónico que está almacenado en usununcelular, luego se hace una búsqueda para verificar si dicho usuario posee una cuenta en la aplicación. Se selecciona los parámetros del usuario original y destino con el ejbFacadecha, si se encuentra una coincidencia devuelve la lista de datos, caso contrario devuelve un NULL (Figura 53).
Figura 53. Verificación de contacto con la aplicación para el inicio del chat
Para poder enviar un mensaje se usó la variable global GlobalMessage que permite almacenar el mensaje a enviar. Por medio de los métodos públicos setGlobalMessage y getGlobalMessage se puede modificar y obtener datos respectivamente, además para enviar el mensaje se creó el método público sendGlobal que recibe como parámetro el usuario logueado del contacto, y mediante el contacto se obtiene el número telefónico del usuario al que quiere enviar el mensaje. Adicional, se usó el ejbFacadecha.create para registrar en la BDD el mensaje, una vez enviado se libera la variable GlobalMessage para no llenar la memoria del servidor y se resetea el chat como se muestra en la figura 54. Finalmente, se creó una secuencia SEQCHACODIGO para el incremento de valor en el código y adicional un trigger TGCHATBEFORE, se dispara antes de la inserción de datos en la tabla chat, en caso de que el código SEQCHACODIGO sea nulo se inserta la siguiente secuencia. La vista chat-img permite visualizar un listado de categorías, es decir recorrer todas las categorías que tenga la aplicación y crear paneles conformados por columnas parar mostrar los pictogramas que forman parte de una categoría. Adicionalmente se muestra la imagen subida a la librería de imágenes con un tamaño de 100 pixeles, dicho tamaño es adaptable (Figura 55).
64
Figura 54. Almacenar y enviar el mensaje
4.3.4.2.2.
Figura 55. Visualización de categorías
Historia de usuario 5: Categorías
En el modelo categorias.java, se declaró una clase publica que permite definir las propiedades de la tabla categorías cuyos campos son: código, nombre, descripción y estado. Por cada una de las categorías se obtuvo un listado de pictogramas, como se observa en la figura 56. Se creó un formulario en la vista categorias.xhtml, por medio de botones se crea y edita las categorías. El botón pictogramas permite ver el listado de los GIF que pertenecen a una categoría seleccionada, el botón editar y pictogramas se activan cuando se ha seleccionado una categoría. Mientras que el objeto dataTable llamado datalist permite obtener un listado de todas las categorías que se encuentran creadas en la base de datos. El botón imágenes permite ver el listado de las imágenes que se suben como pictogramas de cada categoría, además redirecciona a la vista pictogramas-list-img, como se observa en la figura 57.
Figura 56. Modelo para definir los campos de la tabla categorías
Figura 57. Creación de botones para crear, editar y listar pictogramas de categorías
La vista pictogramas-list-img permite visualizar una galería de imágenes en tipo slider, de manera secuencial se muestran las imágenes que pertenecen a una categoría seleccionada,
65 donde se muestra detalles como el nombre y la extensión. Además, se tiene el comando regresar para poder elegir otra categoría, como se muestra en la figura 58. En el controlador categoríaController.java se encuentra el método create que permite crear una nueva categoría y definirla para que se mantenga activa, una vez creada la misma, se regresa al listado de categorías general. En el método update se actualiza la información de la categoría y si es satisfactoria la actualización se almacena en la base de datos, se observa el cambio por medio de la vista categorias.xhtml, como se muestra en la figura 59.
Figura 58. Visualización de las imágenes en tipo Slider
Figura 59. categorías
Creación y
actualización de
En el mismo controlador se tiene el método public List para obtener todo el listado de las categorías, sino se encuentra una en el aplicativo va a devolver una excepción solicitándola. El método public Integer getTotalCategorias obtiene todos los registros almacenados en la base de datos a través de ejbFacadecat.finAll().size(), ver la figura 60.
Figura 60. Método para listar todas las categorías
Finalmente, se creó una secuencia SEQCATCODIGO para el incremento de valor en el código y adicional un trigger TGCATEGORIASBEFORE el cual se dispara antes de la inserción de datos en la tabla chat, en caso de que el código SEQCATCODIGO sea nulo se inserta la secuencia.
66 4.3.4.2.3.
Historia de usuario 8: Destacar
Dentro del modelo destacados se tiene la interfaz Serializable, tiene como identificador primario @Id el descodigo. Este modelo tiene relación con la tabla chat y usuarios, esto se debe a que un usuario puede tener varios chats destacados y ese chat puede estar en dos usuarios. El campo CHACODIGO y USUUSUARIO se toma como modelo la tabla chat y usuario respectivamente (ver figura 61). Para poder destacar o eliminar un mensaje enviado o recibido se debe presionar el mensaje en el dispositivo móvil o al dar clic derecho sobre el mismo, para lo cual se creó el objeto viewchat de tipo contextMenu dentro de la vista chat.xhtml, como se muestra en la figura 62.
Figura 61. Relación del modelo Destacados con la tabla Chat y Usuarios
Figura 62. Creación del submenú destacar o eliminar mensaje
El objeto viewDestacados permite visualizar datos de tipo char del usuario logueado, es decir que el valor que recibe el dataTable es una lista de mensajes que haya destacado el usuario, además permite seleccionar un chat destacado para poderlo eliminar. Adicional se aplica un estilo de color de fondo diferente para la persona que envía y la que recibe el mensaje. Además, contiene una columna que alinea automáticamente la ubicación del mensaje a la izquierda o derecha, contiene los datos de la hora y fecha del mensaje, nombre de usuario y contenido, como se observa en la figura 63. El controlador destacadosController es una clase pública de tipo @SessionSoped que permite mantener la sesión de los datos. Mediante el ejbFacadedes se puede acceder al Facade de destacados, es decir a los mensajes destacados almacenados en la base de datos como se puede observar en la figura 64.
67
Figura 63. Visualización de los datos del usuario logueado
Figura 64. Controlador Destacados para mantener la sesión de los datos
En la figura 65, se tiene el método List dentro del controlador que permite obtener un listado de mensajes destacados, recibe como parámetro el usuario logueado, mediante el acceso a ejbFacadedes se puede hacer una búsqueda y en el caso de encontrar valores retornan, caso contrario es nulo. El método removeDestacados no retorna valores y se activa cuándo se quiere remover un destacado. A través de ejbFacadedes y mediante el método remove del objeto seleccionado, remueve el mismo de la vista destacados.xhtml. Automáticamente de forma interna se accede a la base de datos, se elimina el objeto enviado y se actualiza (Figura 66).
Figura 65. Método List para obtener el listado de mensajes destacados
4.3.4.2.4.
Figura 66. Método para remover mensajes destacados
Historia de usuario 9: Reenviar
El modelo utilizado para reenviar mensajes es chat.java, el fin de la historia es poder reenviar un mensaje ya sea a la misma persona o a otra dentro de sus contactos. Para lo cual se debe dar click derecho al mensaje y seleccionar la opción reenviar. Dentro de la vista chat.xhtml al momento de completar el reenvío abre un cuadro de dialogo con el id selectedChat y se muestra mediante la propiedad show, como se muestra en la figura 67. La vista chat-move.xhtml es de tipo dialogo la cual aparece como pop-up en una vista normal, contiene propiedades como el id que es necesario para que una vez desembocado pueda mostrarse u ocultarse. La variable widgetVar es de tipo global que puede ser invocada desde cualquier otra vista, permite la asignación de ventanas emergentes de PrimeFaces. La vista datalist es un contenedor de tipo dataTable donde se obtiene el listado de contactos del usuario logueado (Figura 68).
68
Figura 67. Método para reenviar mensajes
Figura 68. Vista chat-move para el reenvio de mensaje
Dentro del controlador ChatController se creó el método onRowSelect que envía como parámetro el usuario logueado, el usuario destino y el mensaje que deseo reenviar. Luego se creó un objeto chat donde se coloca el nuevo mensaje, el usuario original y destino, finalmente se realizó un create (chat) para almacenar el mensaje enviado en la base de datos, como se observa en la figura 69.
Figura 69. Método para almacenar el mensaje enviado en la base de datos
4.3.4.2.5.
Gráfico de trabajo pendiente del Sprint 2
En la figura 70, se muestra el trabajo pendiente durante el desarrollo de las tareas del sprint 2, para el presente avance no se presentaron dificultades en el cumplimiento de cada una de las actividades, se dio por finalizada cada una de las sub-tereas asignadas por parte de los desarrolladores.
Figura 70. Gráfico del Sprint 2
4.3.4.3.
Revisión del Sprint 2 Para el sprint 2, el Product Owner hizo la verificación del avance de la app móvil, quien
notó mejoras positivas en el progreso de la misma. La reunión en esta ocasión tuvo una duración de dos horas en las cuales se revisaron las historias de usuario pertenecientes a este sprint. Posteriormente se firmaron las pruebas de aceptación por parte de la intérprete de lengua de señas de la carrera de Gastronomía, quién las aprobó (Anexo IX).
69 4.3.4.4.
Retrospectiva del Sprint 2 En la tabla 13 se muestra la retrospectiva formada del sprint 2, marcando 3 preguntas
relevantes, que logran una mejor representación del mismo. Tabla 13. Retrospectiva del Sprint 2 Formulario de reunión retrospectiva ¿Qué salió mal en el sprint ¿Qué mejoras vamos a implementar en el (errores)? próximo sprint? (recomendaciones de mejora continua)
¿Qué salió bien en el sprint?
En el segundo sprint desarrollado se logró completar las tareas correspondientes a cada una de las historias de usuario asignadas como son: chat, categoría, destacados y reenviar. El chat solo se permite entre usuarios registrados como método de seguridad a la privacidad; se logró la posibilidad de crear categorías colaborativas de tal forma que se adapte a las necesidades de cada usuario; se permite marcar y guardar los mensajes destacados ya sean textos o pictogramas y finalmente se permite realizar el reenvió de mensajes entre usuarios del aplicativo.
Una de las grandes dificultades en esta etapa del desarrollo fue la creación de categorías por parte de los usuarios en donde las crean para que otros también puedan usarlas en tiempo real.
Las pruebas constantes con el Product Owner son importantes para lograr mejores resultados ya que es quien sugiere los cambios, todo en beneficio de las personas con discapacidad auditiva, ya que al ser la persona que interpreta conoce más a fondo sus necesidades. La mejora siguiente será la implementación de machine learning dentro de la aplicación, de acuerdo a la coincidencia de caracteres se envía el GIF correspondiente.
4.3.5. Sprint 3 4.3.5.1.
Planificación del sprint 3 – Sprint Planning En relación al sprint 3, se consideró a las historias de usuario seis, siete, diez y dos
historias técnicas; se asignó la estimación que le corresponde a cada uno, obteniendo un puntaje de 41 puntos. Por otra parte, se realizó el Sprint Backlog, teniendo como objetivo desarrollar la funcionalidad correspondiente al ingreso de pictogramas, cambio en el perfil de usuario y machine learning, además de pruebas de disponibilidad y rendimiento, como se observa en la tabla 14. Tabla 14. Sprint Backlog del Sprint 3 Sprint Backlog Objetivo: Desarrollar la funcionalidad correspondiente al ingreso de pictogramas, cambio en el perfil de usuario y machine learning, además de pruebas de disponibilidad y rendimiento.
SPRINT
HISTORIA
EST CATEGORÍA
Desarrollo 3
HU6-Pictogramas
13
Desarrollo Desarrollo
TAREA
Creación del modelo Pictogramas.java y la clase pictogramas con la interfaz Serializable. Creación de la vista pictogramas-list.xhtml para visualizar y de los pictogramas dentro de una categoría. Creación de la vista pictogramas-form.xhtml para crear nuevos pictogramas.
EST
2 2 2
70 Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo HU7-Machine Learning
Desarrollo
13
Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo HU10-Perfil usuario
de
Desarrollo
5
Desarrollo
Creación de la vista pictogramas-edit.xhtml para editar los campos de un pictograma. Creación del controlador PictogramasController con los métodos públicos created para la creación y almacenamiento del pictograma en la base de datos. Creación del controlador ChatController.java para enlazar con los modelos Usuarios, Contactos y Chat. Trigger TGCHATBEFORE y la secuencia SEQCHACODIGO Creación de un objeto tipo Agente para definir las palabras que se escriben en el chat, junto con un método spellWord que separe lo escrito con el patrón (*). Creación de un bucle while para relacionar las palabras claves con los pictogramas de la BDD, hasta encontrar todos. Creación de la clase genérica agente.java para determinar algunas palabras que son de unión de forma general. Creación del método SpellWord de tipo List String para crear una lista de palabras tipo ArrayList. Creación de la vista chat-recognitions.xhtml y del formulario VozForm para mostrar el texto luego del reconocimiento de voz. Creación de una variable auxiliar tipo Listener y tipo SpeechRecognition para el reconocimiento de voz. Creación de la ventana emergente AudioViewForm para grabar el audio, mediante el método SendAudio. Creación de la función copyFile para almacenar el audio en el servidor. Creación de la vista micuenta.xhtml y el formulario frmMiCuenta para crear los objetos de la vista. Creación de la vista CambiarMiClave para enviar al formulario los datos para actualizar contraseña. Creación del método changepassword para cambiar la clave, gomicuenta para actualizar datos de usuario, update actualizar contraseñas y micuenta para dirigir a los datos del usuario logueado.
2 2 2 1 2 2 2 2 2 1 1 1 1 2 2
Historias Técnicas HT1-Disponibilidad
5
HT2-Rendimiento
5
La App estará disponible todo el tiempo, para esto es necesario que los usuarios instalen la aplicación en su dispositivo móvil. La aplicación tendrá un nivel de respuesta en tiempo real, no superando los 3 segundos.
Nota: Elaboración propia. HU: Historia de usuario. HT: Historia Técnica
4.3.5.2.
Reuniones diarias del Sprint 3 –Daily Scrum Todos los días el equipo se reunió 15 minutos para realizar la planeación diaria en
relación a las tareas de cada historia, dichas reuniones permitieron evaluar el proceso del sprint 3. 4.3.5.2.1.
Historia de usuario 7: Machine learning
El algoritmo Predicate Learning es una arquitectura neuronal que describe o crea un objeto a partir de características semánticas, dichas características se comparan y contrastan, luego se construyen relaciones significativas entre los objetos creados. El algoritmo coloca en un predicate el objeto que representa la imagen y en otro la posición relativa de cada característica, de esta manera al final tendrá la imagen y las características que lo representan. Después de la creación de varias imágenes con el algoritmo predicate se pueden comparar e
71 identificar entre ellas, para lo cual se comparan los predicate finales de las imágenes y se obtienen las similitudes entre ellas. Speed Recognition o reconocimiento de voz permite procesar la voz humana a formato textual, por medio de un agente de Predicate Learning se puede detectar hasta 16 idiomas por medio de una biblioteca de Google, es decir, realiza la traducción del habla de un formato verbal a uno de texto. En la vista chat.xhtml se creó una caja de texto para la entrada de mensaje, lo que se escribe se almacena en la variable globalMessage de tipo string en el ChatController, permite almacenar máximo 500 palabras. Antes de escribir se muestra un mensaje de texto “Escribir un mensaje a su contacto”. Para capturar el evento se utilizó el onkeyup, si el código leído es igual a 13 (Enter en ASCII) acciona el envío del mensaje, después de enviar se limpia la caja de texto con this.value= ' '. Para enviar el mensaje al contacto seleccionado, en la etiqueta commandButton se realizó un actionListener que busca en el ChatController el usuario logueado y el contacto del usuario con el que se está interactuando, realizada la acción se actualiza la lista de mensajes para que llegue al emisor y al receptor, como se observa en la figura 71.
Figura 71. Ingresar y enviar texto a un contacto
En la figura 72, el método público sendGlobal sigue como parámetros el usuario logueado y destino, si existe algún inconveniente en el método se realiza un IOException, realiza un if para saber si la variable globalMessage es diferente de Null, si es igual a Null se va por else y advierte con un mensaje que debe haber texto antes de enviar, si encuentra texto hace una consulta si existe asterisco (*), carácter que activa el machine learning. Si ingresa por la condición se crea un objeto tipo agente que define las palabras que se están escribiendo en el chat, tiene un método spellWord que hace que separe lo escrito con el patrón (*). Se crea una lista de imágenes tipo string que va buscando en los pictogramas las
72 palabras relacionadas con el patrón que creó el agente. Se creó un while que va relacionando las palabras claves con los pictogramas disponibles en la BDD, hasta que haya encontrado todos. Estos datos se envían en formato gll que está relacionada a galería. Para no sobrecargar el servidor se limpia la variable globalMessage a Null.
Figura 72. Activación de Machine Learning
La función public void onRowSelect recepta como parámetro el usuario origen, destino, mensaje a enviar, tipo de mensaje y si es o no compatible. Primero detecta si el usuario destino está dentro de la plataforma, sino es así se presenta el mensaje "Su usuario aún no está usando SignIES", caso contrario se crea un objeto de chat, se setea (configura) el parámetro receptado y se crea el objeto ejbFacadeCha en la base de datos, ver figura 73.
Figura 73. Detección de contactos en la plataforma para enviar mensaje
En la figura 74, la clase genérica agente.java usa los paquetes ArrayList, Arrays y List, se creó un array donde se determinaron algunas palabras que son de unión de forma general, se creó un constructor vacío para instanciar a la clase y no estar enviando parámetros. Además, se creó el método spellWord que es de tipo List String (devuelve lista de String), crea una lista de palabras de tipo arrayList. Si la cadena de texto no es nula y tiene tamaño mayor a cero va separando la misma con la función word.split mediante un for con la condición de que cuando encuentra un espacio ingrese a la sentencia; esto es importante para separar machine learning
73 del resto de palabras y no saturar el servidor, se creó una línea de predicado (dentro del contexto de machine learning se lo denomina al atributo).
Figura 74. Machine Learning concatenado
En la vista chat-recognitions.xhtml se creó un formulario VozForm que contiene un botón para enviar, regresar y un campo de contenido donde se muestra el texto que fue detectado en el reconocimiento de voz antes de enviarlo. Se colocó un botón que dice “Iniciar Reconocimiento de voz”, al momento de dar click se activará. El reconocimiento de voz es netamente una plataforma de Google, por ende, algunos buscadores no soportan el reconocimiento, en este caso se mostrará un mensaje y no se activará la acción (Figura 75).
Figura 75. Reconocimiento de voz
74 Este script fue creado con JavaScript que es multiplataforma, se creó un evento en la ventana de Windows tipo DOMContentLoaded (permite la creación de contenido multimedia), tiene 3 constantes tipo button para capturar el botón, crear el result y main. Main como no tiene Id por ser HTML5 se lo ubicó con getElementById con array cero (0); se creó una variable auxiliar tipo Listener y tipo SpeechRecognition para el reconocimiento de voz. Constante stop es para detener el proceso de reconocimiento y volver a iniciar. El evento OnResult limpia el Canvas a lo que el usuario empieza a hablar y por cada palabra dicha crea un nodo con createTextNode, dicho nodo crea un párrafo con createElement("p"), como se observa en la figura 76. Es importante mencionar que el botón para reconocimiento de voz es removido si el portal dónde se aloja la aplicación no tiene certificado SSL (Seguridad de la capa de transporte) y también HTTPS (Protocolo seguro de transferencia de hipertexto), el SSL no puede ser auto firmado, solo bajo los estándares internacionales con empresas certificadoras. Adicional se sugiere un dominio y no una IP pública ya que son dinámicas. La grabación de audio y el reconocimiento de voz no son permitidos mediante IP dinámicas, se detecta como Phishing y debe estar configurado en el servidor web de Payara.
75
Figura 76. Script creado para el proceso de Reconocimiento de Voz
En la vista chat.xhtml existe un botón de color rojo para que el usuario identifique que ya puede realizar la grabación del audio. Una vez completado todo mediante una función PrimeFaces, se habilita una ventana emergente donde se muestra el audio grabado, como se observa en la figura 77.
Figura 77. Creación del botón para grabar el audio
76 En la vista chat-audio.xhtml se creó una ventana emergente AudioViewForm, donde se visualiza un botón “Audio” una vez terminada la grabación de sonido, se usó el método SendAudio para enviar el audio desde el usuario de origen al destino. Además, se colocó un botón de cancelar para regresar a la ventana de chat principal (Figura 78).
Figura 78. Guardar el audio en la ruta del servidor
En la figura 79, canvas permite capturar audio mediante código HTML5 en cualquier explorador, se creó una división de controlador dónde se tiene un botón para micrófono y otro para poder grabar. En el script se creó el objeto DOMContentLoaded para la creación de objetos de reconocimiento de audio. Si el aplicativo o navegador no tiene acceso al micrófono se fuerza al uso del mismo para dispositivos móviles con navigator.mediaDevices. Para poder usar el micrófono con Android 6.0 o inferior se usa navigator.getUserMedia. Una vez grabado el audio y que el usuario ha seleccionado parar audio se crea una URL (Localizador uniforme de recursos) de tipo blog, hace que se recupere todo el audio del usuario y se almacene en la variable blobUrl, luego es pasado a un enlace y antes de enviar aparece un objeto de tipo audio en formato wav, de esa manera se puede descargar. El audio generado es enviado al servidor, al dar click en el botón enviar, se creó un objeto fd para obtener los datos del audioForm, como se muestra en la figura 80.
77
Figura 79. Capturar audio en el navegador y Android
78
Figura 80. Almacenar audio en una variable para poder descargarlo
Cuando se creó un servelet, automáticamente se va a la configuración global de la aplicación que es el archivo web.xml, en caso que no se realice es necesario que se publique el serverlet con la etiqueta servlet-mapping, el nombre del servelet y el url-pattern, como se muestra en la figura 81.
Figura 81. Configuración del servelet
La clase audiosrv.java es una herencia de HttpServlet creado como extends, recibe como parámetros un multipartConfig, el tamaño para un archivo es de 10 MB y máximo de 50 MB y para las peticiones de 100MB. Se creó la variable final de tipo string para almacenar el audio en la ruta de la aplicación, adicional se sacó un backup de los audios enviados al servidor
79 con la finalidad de que cuando se realice una actualización no se borre los archivos de pathaudio y se puedan recuperar desde la ruta path _backup_audio, para poder procesar dicha petición siempre va a llegar una petición processRequest donde se acciona el reconocimiento de audio, recibe el nombre del InputStream y el nombre del archivo, como se observa en la figura 82.
Figura 82. Configurar el máximo almacenamiento para audio
Se usó una función copyFile para almacenar el audio en el servidor con el nombre y el objeto del archivo. La variable dir y dir2 revisa si la ruta está creada en el servidor o no, el dir.mkdir crea la ruta en el servidor en caso que no exista. El audio es pasado al servidor por medio de la variable temporal OutputStream y luego se copia en tipo binario con la variable out1.write, finalmente se limpian esas variables y se cierra, de esa manera el audio es almacenado y una vez disponible en el servidor ya se puede reproducir en los chats (Figura 83).
80
Figura 83. Respaldo de los audios en el servidor
4.3.5.2.2.
Historia de usuario 6: Pictogramas
El modelo pictograma contiene los campos: piccodigo, picnombre y picimagen. El campo picpatron almacena el nombre del pictograma y se determina un campo llamado picumbral para identificar si una palabra cumple las similitudes de un patrón con un porcentaje y de acuerdo a ese valor reemplaza la palabra que se esté digitando por el pictograma aplicando machine learning, como se muestra en la figura 84. La vista pictogramas-list.xhtml contiene un objeto dataTable que tiene todos los pictogramas de las categorías seleccionadas y las mismas se encuentran relacionadas con los comandos de crear y editar. Adicional, se muestra un comando para regresar a la lista general de todas las categorías, como se observa en la figura 85.
Figura 84. Modelo pictograma
Figura 85. Vista para observar los pictogramas de las categorías
En la vista pictogramas-form se tienen todos los campos necesarios para crear un nuevo pictograma a través del campo nombre, patrón, imagen y umbral. El objeto fileUpload permite
81 al usuario abrir el explorador de archivos y seleccionar los archivos de tipo GIF, PNG y JPG. Finalmente se valida el archivo cargado (Figura 86). La vista pictogramas-edit permite editar un pictograma, similar a cuando se crea uno, en donde se ubica el nombre, patrón y umbral, solo permite editar los campos, más no la imagen. Además, se tiene el botón guardar para almacenar en la base de datos el cambio y el botón regresar (Figura 87).
Figura 86. Vista para crear nuevo pictograma
Figura 87. Vista para editar un pictograma
Dentro de PictogramasController se encuentra el método public void create, recibe como parámetro la categoría que se encuentra definida en una variable selected del pictograma. En el momento que se selecciona un archivo en la vista se setea la ruta del archivo dentro de la carpeta donde se va a almacenar. Finalmente se crea el pictograma y se almacena en la base de datos, como se observa en la figura 88. El método copyFile recibe como parámetros: el id de la categoría, el nombre del archivo y el archivo en sí, permite al usuario subir sus propios pictogramas en formato GIF desde una computadora o un dispositivo móvil y cargarlo en una categoría compartida de pictogramas que se aloja en el servidor (creará una ruta local y un path paralelo para poder generar el backup de las imágenes), para que el resto de usuarios también tengan acceso a dicho contenido (Figura 89).
82
Figura 88. Vista para editar un pictograma
Figura 89. Creación de categorías colaborativas
Dentro de PictogramasController se encuentra el método public void update que permitir actualizar el pictograma cuando se edita sus parámetros como el nombre, patrón y umbral, si es satisfactoria la actualización se muestra un mensaje “Pictograma actualizado con éxito” y en caso de faltar un parámetro se muestra “No se actualizó el pictograma”, como se observa en la figura 90. En la figura 91 se muestra el código del método public List <Pictogramas> para obtener el listado de pictogramas dado el código de las categorías, además el método public List<String> devuelve una lista de datos de tipo string que recibe como parámetro el Id de la categoría, crea una lista de imágenes y dicha lista realiza la consulta para poder enlazar el pictograma correspondiente.
Figura 90. Método para actualizar los pictogramas
4.3.5.2.3.
Figura 91. Método para listar las imágenes y los pictogramas
Historia de usuario 10: Perfil de Usuario
La clase pública Usuarios posee todos los componentes o campos: nombre de usuario, clave, correo y número de teléfono. Además, se verifica si acepta todos los términos o no y se relaciona o se vincula con los mensajes destacados y contactos. Adicionalmente, un usuario debe contener la relación con roles para saber si es administrador o usuario, como se observa en la figura 92. La vista micuenta.xhtml contiene un formulario frmMiCuenta donde se van creando los objetos de la vista como el toolbar, además se encuentran los botones para actualizar datos de
83 la cuenta. El usuario para poder loguearse debe registrarse primero en la app, luego de eso solo tiene la opción de actualizar sus datos como por ejemplo sus nombres, correo y teléfono, todos los campos son obligatorios y validados, como se muestra en la figura 93.
Figura 92. Método para listar las imágenes y los pictogramas
Figura 93. Actualización de los datos de una cuenta
En la vista CambiarMiClave se envían al formulario los datos para actualizar la clave y se visualiza que usuario va a realizar el cambio. Además, se valida los campos para que confirme la nueva clave a ingresar, permitiendo el ingreso de minúsculas, mayúsculas, números y caracteres especiales, dependiendo de la seguridad que posea la contraseña el toolbar se pone de color rojo, naranja o verde, como se observa en la figura 94. En el controlador UserloginController se tiene el método público String Logout donde se validan las sesiones de los controladores y se redirecciona a la página de Login. Permite el cambio de clave mediante el método público changepassword, actualizar datos de usuario a través de gomicuenta, el método update para actualizar claves y finalmente en el método micuenta dirige a los datos del usuario que tiene iniciada la sesión (Figura 95).
84
Figura 94. Cambio de clave en una cuenta
4.3.5.2.4.
Figura 95. Validación de las sesiones
Historia técnica 1: Disponibilidad
La aplicación dispone de una conexión al servidor del 100% del tiempo, lo que garantiza el acceso a la misma; para ello se debe descargar e instalar la app en el dispositivo móvil. La herramienta DomainTools Whois Lookup se utilizó para verificar que el dominio se encuentra disponible y en uso, como se observa en la figura 96. Además, se verificó la misma haciendo ping al dominio del servidor, como se muestra en la figura 97.
Figura 96. Verificación en DomainTools Whois Lookup
4.3.5.2.5.
Figura 97. Verificación en cmd
Historia técnica 2: Rendimiento
Google Cloud permite medir el rendimiento en la construcción, ejecución, y análisis de aplicaciones montadas en el servicio. Por medio de la supervisión de la máquina virtual ejecutada, se midió la capacidad de procesamiento y operaciones en el rendimiento del disco ante la ejecución en tiempo real del aplicativo. Se observó un procesamiento óptimo de la aplicación, lo cual garantiza en todo momento el correcto funcionamiento de las instancias; de tal manera que es fácil identificar una anomalía y permite la corrección de inconvenientes en el menor tiempo posible (Figura 98).
85
Figura 98. Rendimiento del disco
4.3.5.2.6.
Gráfico de trabajo pendiente del Sprint 3
En la figura 99, se muestra el gráfico del trabajo pendiente durante el desarrollo de las tareas del sprint 3, para el presente avance se presentaron novedades puesto que algunas actividades necesitaron más tiempo del estimado para su cumplimiento, finalmente se concluyeron cada una de las sub-tereas asignadas por parte de los desarrolladores.
Figura 99. Gráfico de trabajo pendiente del Sprint 3
4.3.5.3.
Revisión del Sprint 3 Para el sprint 3, el Product Owner hizo la verificación del avance de la aplicación
móvil, quien notó mejoras significativas en la etapa final de la misma. La reunión en esta ocasión se dio bajo la modalidad virtual con una duración de tres horas, en las cuales se revisaron las historias de usuario pertenecientes a este sprint. Posteriormente se firmaron las pruebas de aceptación por parte de la intérprete de lengua de señas de la carrera de Gastronomía, quién determinó que todas fueron presentadas con éxito (Anexo X). 4.3.5.4.
Retrospectiva del Sprint 3
En la tabla 15 se muestra la retrospectiva formada del sprint 3, marcando tres preguntas relevantes, que logran una mejor representación del mismo.
86 Tabla 15. Retrospectiva del Sprint 3 ¿Qué salió bien en el sprint?
En el tercer sprint desarrollado se logró completar las tareas correspondientes a cada una de las historias de usuario asignadas como son: pictogramas, machine learning y perfil de usuario. Además de las historias técnicas como disponibilidad y rendimiento. Los pictogramas se pueden cargar mediante categorías y de manera colaborativa, así como editarlos de manera individual; se logró que mediante el uso de un carácter (*) el aplicativo identifique pictogramas almacenados en la base de datos y los presente en formato GIF; se permite la edición de datos de usuario como el nombre, número de teléfono y correo electrónico, así como el cambio de contraseña.
Formulario de reunión retrospectiva ¿Qué salió mal en el ¿Qué mejoras vamos a implementar en el sprint(errores)? próximo sprint? (recomendaciones de mejora continua) Una de las grandes dificultades en esta etapa del desarrollo fue la implementación del algoritmo Predicate Learning para la carga automática de pictograma de acuerdo a la coincidencia de palabras colocada en la caja de texto mediante el caracter (*), además Speech recognition para el proceso de transcripción de voz a texto.
Las observaciones constantes con el Product Owner son importantes para lograr resultados óptimos, ya que es la persona que conoce las necesidades a profundidad de las personas con discapacidad auditiva. La implementación de mejoras queda para futuras investigaciones en base a un nuevo levantamiento de información, en relación a todo lo expuesto en la presente investigación, dado que una aplicación de esta altura puede ser mejorada para otros propósitos, buscando incluir a personas con otro tipo de discapacidad o a su vez aumentando funcionalidades.
Para la disponibilidad se usó la herramienta DomainTools Whois Lookup que permitió conocer la disponibilidad y demás información sobre el dominio; finalmente para medir el rendimiento dentro de Google Cloud se usó las herramientas incluidas de supervisión de la máquina virtual para garantizar la capacidad relacionado al procesamiento y las operaciones del disco.
4.4. Validación de Hipótesis Una vez realizado el análisis exploratorio, se procedió a realizar un análisis cruzado de Chi cuadrado, para los indicadores de las variables de estudio de la aplicación móvil con machine learning (Tabla 16). Este análisis bivariado permite visualizar la correlación entre los indicadores, en la cual se observó: frecuencia de uso de aplicaciones, probabilidad de comunicarse en tiempo real, frecuencia de predicciones de pictogramas, probabilidad de transmitir una idea, el número de aplicaciones y aplicaciones de mensajería en tiempo real ayudan a personas con discapacidad (p<0.05). Por lo tanto, se validó la hipótesis alternativa (H1): el aplicativo móvil con machine learning influye significativamente en la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón.
87 Tabla 16. Análisis cruzado de los indicadores en función de la aplicación ¿Con qué frecuencia usa aplicaciones de mensajería que guarden emoticones o GIF relacionados a la lengua de señas y los vuelva a sugerir automáticamente? ¿Qué tan probable es que logre comunicarse en tiempo real a través de lengua de señas con una persona sorda? ¿Con qué frecuencia usa aplicaciones que sugieran predicciones de palabras o pictogramas (emoticones o GIF) usados con anterioridad? ¿Cuál es la probabilidad de poder transmitir una idea a un estudiante con discapacidad auditiva si no se encuentra el intérprete de lengua de señas y/o la utilización de una aplicación educativa? ¿Cuántas aplicaciones en su celular permiten a personas con discapacidad auditiva tener total acceso a sus funcionalidades? ¿Considera que las aplicaciones de mensajería en su smartphone ayudan a personas con discapacidad auditiva a comunicarse mediante lengua de señas?
X2 183,213
gl 1
p 0,000
249,224
1
0,000
154,703
1
0,000
219,195
1
0,000
4,371
1
0,037
176,340
1
0,000
88
5.
DISCUSIÓN
De acuerdo a la información obtenida de la encuesta a toda la comunidad educativa de la carrera de Gastronomía del ISTC, además de una entrevista realizada a la intérprete y a los docentes que imparten clases a estudiantes con DA, se conocieron las necesidades comunicativas de los estudiantes con discapacidad auditiva para lograr una mejor interacción con sus compañeros, docentes y autoridades. Los encuestados consideraron que el desarrollo de una aplicación de mensajería mediante texto, voz y pictogramas permitiría mejorar la comunicación de las personas con discapacidad auditiva con los demás actores de la comunidad educativa. Lo antes mencionado se alinea a lo manifestado por Mendoza et al (2018), quienes consideran que los dispositivos móviles son el canal de acceso más usado hoy en día para propósitos educativos, por lo cual desarrollaron una herramienta que promueva la inclusión y facilite la interacción entre oyentes y personas con discapacidad auditiva. Dentro del diccionario de lengua de señas ecuatoriana “Gabriel Román” no existen señas del área técnica de la carrera de Gastronomía, así como también términos básicos dentro del aula clase. Por lo cual se empleó el sistema pictográfico para estudiantes con discapacidad auditiva dentro de las áreas técnicas de bares y restaurantes, cocina de alto volumen y ecuatoriana. Para este proceso los estudiantes con DA junto a la intérprete pactaron las señas inexistentes y fueron generadas en formato GIF. Lo manifestado anteriormente se alinea con lo expuesto por Parra (2018), quien menciona que el sistema pictográfico es un recurso educativo para desarrollar el aprendizaje y mejorar la interacción comunicativa, también es adaptable a nuevas tecnologías. De manera similar Cano (2015) afirma que, los pictogramas sirven de apoyo para desarrollar el aprendizaje en personas con discapacidad auditiva, puesto que tienen mayor desarrollo de su capacidad visual, además su canal de comunicación va acompañado de imágenes y texto para transmitir una idea o palabra. Se desarrolló la aplicación “SignIES” con las funcionalidades que responden a las necesidades de todos los actores de la comunidad educativa, se empleó machine learning no supervisado, mediante el algoritmo Predicate Learning para el reconocimiento de voz y el envío de GIF de acuerdo a la coincidencia de caracteres almacenados en la base de datos del aplicativo. El algoritmo coloca en un predicate el objeto que representa la imagen y en otro la posición relativa de cada caracter, de esta manera al final tendrá la imagen y los caracteres que lo representa. Lo expuesto se alinea con Murphy (2012), quien menciona que el aprendizaje no supervisado realiza un descubrimiento sin ningún tipo de entrada y los datos de entrenamiento
89 no están clasificados. El algoritmo Predicate Learning permite describir o crear un objeto a partir de características semánticas, las mismas se comparan, contrastan y finalmente se construyen relaciones significativas entre los objetos creados. En la encuesta realizada a toda la comunidad educativa de la carrera de Gastronomía del ISTC, se aprovecharon las preguntas para capturar las historias técnicas en la ingeniería de requerimientos con enfoque ágil, de esta manera se identificó que algunas personas poseen un móvil con sistema operativo Android y otros iOS. Se desarrolló una aplicación hibrida para que la app sea ejecutada desde el sistema o desde un navegador web. Lo expuesto se alinea con Cuello et al (2013), quienes mencionan que las apps hibridas engloban elementos de apps nativas y web, las cuales permiten acceder a las funcionalidades del dispositivo móvil tal como lo haría una app nativa y puede ser ejecutada en Android, iOS, etc. Para el desarrollo del aplicativo móvil se utilizó el lenguaje de programación Java que está orientado a objetos, permitió la continuidad y actualización del proyecto sin tener que empezar desde cero, esto se debe a que los objetos mantienen el código ordenado y fácil de modificar cuando es necesario. Lo antes mencionado concuerda con Durán et al (2007), quienes enfatizan que Java es un lenguaje sencillo, potente y adaptado para la programación de aplicaciones en la red. De manera similar Garrido (2015) menciona que Java es muy flexible pues facilita el ciclo de vida del software, desde el análisis, diseño, implementación hasta el mantenimiento.
90
6.
CONCLUSIONES Y RECOMENDACIONES
6.1. Conclusiones En conclusión, se logró conocer las necesidades comunicativas de los estudiantes con discapacidad auditiva por medio de las encuestas y entrevistas realizadas, además del diagrama de actividades de una clase regular. En el proceso de necesidades comunicativas en el aula de clases, se denotó inconvenientes al momento de desarrollarse la misma ya que los estudiantes con discapacidad auditiva no logran receptar al 100% la información; existen términos técnicos o frases que no se encuentran dentro del diccionario de lengua de señas ecuatoriana “Gabriel Román”. El sistema pictográfico que se empleó es de gran importancia dado que mediante representaciones gráficas se transmite algo concreto, el principio fundamental de este recurso permitió desarrollar la idea y posteriormente plasmarla en archivos GIF para representar los términos que se usan en clase, en las áreas técnicas de bares y restaurante, cocina de alto volumen y ecuatoriana de la carrera de Gastronomía; estos recursos fueron creados por los estudiantes con discapacidad auditiva junto a la intérprete de lengua de señas ecuatoriana. Finalmente, la implementación del aplicativo móvil “SignIES” tuvo una gran recepción por parte de toda la comunidad educativa, permitiendo a los estudiantes con discapacidad auditiva fortalecer la comunicación con los demás y viceversa. Entre sus ventajas se encuentra su interfaz adaptable y amigable con los usuarios, dentro de sus módulos posee el apartado de pictogramas que son categorizados de manera colaborativa, permitiendo subir nuevos recursos y que estén disponibles para todos los usuarios de la aplicación. Además, el propósito del algoritmo Predicate Learning es enviar el GIF asociado a la palabra colocada con el caracter especial (*) después de realizar una búsqueda de coincidencias de caracteres. Para concluir, se demostró con los datos recolectados en el pre y post test que el aplicativo con machine learning influye significativamente en la comunicación de lengua de señas ecuatoriana, en la carrera de Gastronomía del Instituto Superior Tecnológico Calazacón.
91
6.2. Recomendaciones Es fundamental que se siga conociendo las necesidades comunicativas de las personas con discapacidad auditiva, para buscar sistemas o herramientas que permitan fortalecer la comunicación no solo dentro del área académica, sino también que les permita desenvolverse a nivel social y laboral. Dentro del proceso de comunicación es importante el pacto de señas entre el intérprete y la persona con discapacidad auditiva, ya que permite la creación de señas que no están en el diccionario de LSEC “Gabriel Román”, permitiendo enfatizar en aquellas áreas técnicas que por lo general carecen de símbolos dactilológicos. Es importante conocer sobre los recursos y tecnologías a usar dentro de un proyecto debido a su gran variedad, además se debe analizar las características, complejidad, compatibilidad, licencias, etc., de esto depende el desarrollo del aplicativo. Además, se debe tener en cuenta que el uso de herramientas libres para el desarrollo de una aplicación a veces resultado algo limitada porque para ciertas funciones se requieren licencia para desbloquear funciones avanzadas.
92
7.
REFERENCIAS BIBLIOGRÁFICAS
Aguado, J., & Estrada, F. (2017). Guía de accesibilidad de aplicaciones móviles (APPS). Madrid,
España.
Obtenido
de
https://sid-inico.usal.es/documentacion/guia-de-
accesibilidad-de-aplicaciones-moviles-apps-2/ Aguilar, S. (2005). Fórmulas para el cálculo de la muestra en investigaciones de salud. Obtenido de https://www.redalyc.org/pdf/487/48711206.pdf Alpaydin, E. (2014). Introduction to Machine Learning. MIT Press. Asamblea Nacional Constituyente. (2008). Constitución de la Republica del Ecuador. Obtenido de OAS: https://www.oas.org/juridico/pdfs/mesicic4_ecu_const.pdf Asteroid Technologies. (2020). Hablalo. Obtenido de https://hablaloapp.com/index.html_# Atlassian. (2021). Atlassian. Recuperado el Febrero de 2021, de Jira Software: https://www.atlassian.com/es/software/jira/free Aymerich, M. (2009). Simbolos, pictogramas y siluetas. Index Book. Behar, D. (2008). Metodología de la Investigación. Shalom. Cano, S., Muñoz, J., Collazos, C., & Bustos, V. (2015). Aplicación móvil para el aprendizaje de la lectoescritura con FitzGerald para Niños con Discapacidad Auditiva. Revista brasileira de informática na educaçâ0, 1. doi:dx.doi.org/10.5753/cbie.wcbie.2015.240 Castro, J. (2018). Introducción a la lingüística clínica: Aproximaciones a los trastornos de la . Lima: Editorial PUCP. Consejo Nacional para la Igualdad de Discapacidades (CONADIS). (2020). Consejo Nacional para la Igualdad de Discapacidades. Obtenido de Consejo Nacional para la Igualdad
93 de
Discapacidades:
https://www.consejodiscapacidades.gob.ec/estadisticas-de-
discapacidad/ Consejo Nacional para la Igualdad de Discapacidades (CONADIS), Consejo de Regulación y Desarrollo de Información y Comunicación (CORDICOM), Federación Nacional de Personas Sordas del Ecuador (FENASEC). (2020). Manual Práctico para Intérpretes en la Lengua de Señas Ecuatoriana. Quito. Cuello, J., & Vittone, J. (2013). Diseñando apps para móviles. Barcelona: Catalina Duque Giraldo. Duran, F., Gutierrez, F., & Pimentel, E. (2007). Programación orientada a objetos con Java. Ediciones Paraninfo. Escandel, M., Marrero, V., & Casado, C. (2014). Claves del Lenguaje Humano . Centro de Estudios Ramón Areces. Flach, P. (2012). Machine Learning. Cambridge University. Garrido, P. (2015). Comenzando a programar con JAVA. Universidad Miguel Hernández de Elche. Guimerá, A. (2018). Iniciación a android en kotlin. Casos prácticos. Madrid: Ediciones Paraninfo. Hernández, R., & Mendoza, C. (2018). Metodología de la Investigación. Las rutas cuantitativa, cualitativa y mixta. México: Mc Graw Hill Education. Luna,
M.
(2013).
Revista
digital
http://www.revista.unam.mx/vol.14/num12/art53/
universitaria.
Obtenido
de
94 Martí, J., & Muñoz, A. (2012). Estudios de traducción e interpretación. Entornos de especialidad.
Universitat
Jaume
I.
Obtenido
de
https://books.google.com.ec/books?id=Ov7PCgAAQBAJ&pg=PA311&dq=interpreta cion+bilateral+o+de+contacto&hl=es419&sa=X&ved=2ahUKEwiz0seildPrAhVyuVkKHZy2AUQQ6AEwAHoECAIQAg #v=onepage&q=interpretacion%20bilateral%20o%20de%20contacto&f=false Mendoza, L., Salazar, H., Del Carmen, Y., & Herrera, S. (2018). Aplicaciones móviles alternativas para mejorar la comunicación de personas con discapacidades auditivas y del habla. Tecnologías de la Información ECORFAN, 5(15), 29. Obtenido de https://docplayer.es/109927433-Issn-volumen-5-numero-15-abril-junio-ecorfan.html Murphy, K. (2012). Machine learning : A probabilistic perspective. Cambridge. Obtenido de https://ebookcentral.puce.elogim.com Naranjo, J. (2017). Aplicación de técnicas pictográficas para incentivar el gusto por la lectura en estudiantes . Organización Mundial de la Salud (OMS). (2020). Organización Mundial de la Salud. Obtenido de Organización Mundial de la Salud: https://www.who.int/es/newsroom/fact-sheets/detail/deafness-and-hearing-loss Parra, M. (2018). Estrategias Metodologícas el Pictogramas para el Aprendizaje del Lenguaje en los niños de 3 a 4 años. Obtenido de http://dspace.unach.edu.ec/handle/51000/5087 Santiago, R., Trabaldo, S., Kamijo, M., & Fernández, Á. (2015). Mobile Learning: Nuevas realidades
en
el
aula.
Barcelona:
Océano.
Obtenido
de
https://www.researchgate.net/publication/299584978_Mobile_Learning_Nuevas_reali dades_en_el_aula
95 Schwaber, K., & Sutherland, J. (2020). La Guía de Scrum. Recuperado el Febrero de 2021, de https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-LatinSouth-American.pdf Secretaria Nacional de Planificación y Desarrollo (SENPLADES). (2017). Plan Nacional de Desarrollo "Toda una vida". Serna, S., & Pardo, C. (2016). Diseño de interfaces en aplicaciones móviles. Madrid: Grupo Editorial RA-MA. Sosa, L. (2012). Reflexiones sobre la Discapacidad. Dialógica de la Inclusión y Exclusión en las prácticas. Ágora, 58. Zamora, L., Salamanca, O., & Cañon, V. (2013). Manos Que Hablan. Prototipo de Aplicación en Android Para el Aprendizaje del Alfabeto Dactilológico Para Colombia. Researchgate,
1.
Obtenido
de
https://www.researchgate.net/publication/275581354_Manos_Que_Hablan_Prototipo _de_Aplicacion_en_Android_Para_el_Aprendizaje_del_Alfabeto_Dactilologico_Para _Colombia
96
8.
ANEXOS
Anexo I. Carta de aprobación, tabla de recursos, cronograma y acta de entrega
97
Anexo II. Carta de impacto, consentimiento informado, árbol del problema
98
Anexo III. Validación de los instrumentos por el experto en investigación
99
100
101
Anexo IV. Validación de los instrumentos por el experto en estadística
102
103
104
Anexo V. Validación de los instrumentos por el experto en Lengua de Señas Ecuatoriana
105
106
107
Anexo VI. Evidencia de las encuestas y entrevistas
108
Anexo VII. Historias de usuario y escenarios de prueba
109
110
111
Anexo VIII. Pruebas de aceptación del primer Sprint
112
Anexo IX. Pruebas de aceptación del segundo Sprint
113
Anexo X. Pruebas de aceptación del tercer Sprint
114
Anexo XI. Manual de Usuario
115
116
117
118
119
120
121
Anexo XII. Manual Técnico
122
123
124
