scieee AI-readable full text Open interactive document viewer

AdaptaMaterialEscolar: Herramienta para la adaptación de asignaturas a necesidades educativas especiales

Miranda Torres, Pablo; Rodríguez-Peral Valiente, Natalia; Velasco Conde, Jorge

Abstract

Por ley, el currículum educativo trata de garantizar que el proceso de formación del alumnado cuente con los materiales, recursos y contenidos necesarios durante su recorrido académico, en igualdad de condiciones. Sin embargo, debido a que no todos los estudiantes cuentan con las mismas herramientas de aprendizaje, existe la posibilidad de realizar adaptaciones curriculares. Actualmente no existen herramientas gratuitas para realizar adaptaciones curriculares, y los docentes dedican demasiado tiempo en crear material académico para estudiantes que lo necesiten: tienen que ajustar la fuente de texto, el tamaño, buscar imágenes en Internet o escanearlas de libros, etc., e incluso algunos tienen que hacerlo a mano. Este proyecto consiste en el desarrollo de una aplicación web, AdaptaMaterialEscolar, creada específicamente para facilitar a los docentes la adaptación curricular no significativa de exámenes, actividades y unidades didácticas personalizadas para cada alumno. Para ello, hemos implementado un editor de texto que cuenta con los formatos y las funcionalidades más utilizadas por los profesores, con el fin de que puedan realizar las adaptaciones de manera más rápida, siguiendo un Diseño Centrado en el Usuario. Las funcionalidades que se han implementado en AdaptaMaterialEscolar son: un buscador de pictogramas, ejercicios de completar huecos en blanco, de generación de sopas de letras, de verdadero o falso, de definir conceptos, y de pregunta para desarrollar con un espacio limitado. La aplicación web ha sido probada y evaluada por usuarios finales que pretenden usarla en el período escolar. Los resultados obtenidos demuestran que se cubre una necesidad real del profesorado y su interés por seguir desarrollando y mejorando AdaptaMaterialEscolar.

Full text

AdaptaMaterialEscolar: Herramienta para la adaptación de asignaturas a necesidades educativas especiales AdaptaMaterialEscolar: Tool for adapting subjects to special educational needs Trabajo de Fin de Grado Pablo Miranda Torres Natalia Rodríguez-Peral Valiente Jorge Velasco Conde Directoras Virginia Francisco Gilmartín Raquel Hervás Ballesteros Trabajo de Fin de Grado en Ingeniería del Software Facultad de Informática Universidad Complutense de Madrid Junio 2021 Documento maquetado con T EXiS v.1.0+. Este documento está preparado para ser imprimido a doble cara. AdaptaMaterialEscolar: Herramienta para la adaptación de asignaturas a necesidades educativas especiales AdaptaMaterialEscolar: Tool for adapting subjects to special educational needs Memoria que presentan para optar al título de Grado en Ingeniería del Software Pablo Miranda Torres Natalia Rodríguez-Peral Valiente Jorge Velasco Conde Dirigida por las Doctoras Virginia Francisco Gilmartín Raquel Hervás Ballesteros Versión 1.0+ Trabajo de Fin de Grado en Ingeniería del Software Facultad de Informática Universidad Complutense de Madrid Junio 2021 Agradecimientos En primer lugar, queremos agradecer a nuestras directoras Virginia y Raquel por toda la dedicación y apoyo brindados en el proyecto, así como todos los consejos aportados para el desarrollo de AdaptaMaterialEscolar. En segundo lugar queremos agradecer a nuestros familiares y amigos por todo el ánimo y ayuda que nos han proporcionado en esta etapa. Por último, también queremos agradecer a todos los docentes del Aula TEA del Instituto Juan de Ávila por confiar en nosotros y darnos la oportunidad de crear de esta herramienta. v Resumen Por ley, el currículum educativo trata de garantizar que el proceso de formación del alumnado cuente con los materiales, recursos y contenidos necesarios durante su recorrido académico, en igualdad de condiciones. Sin embargo, debido a que no todos los estudiantes cuentan con las mismas herramientas de aprendizaje, existe la posibilidad de realizar adaptaciones curriculares. Actualmente no existen herramientas gratuitas para realizar adaptaciones curriculares, y los docentes dedican demasiado tiempo en crear material académico para estudiantes que lo necesiten: tienen que ajustar la fuente de texto, el tamaño, buscar imágenes en Internet o escanearlas de libros, etc., e incluso algunos tienen que hacerlo a mano. Este proyecto consiste en el desarrollo de una aplicación web, AdaptaMaterialEscolar, creada específicamente para facilitar a los docentes la adaptación curricular no significativa de exámenes, actividades y unidades didácticas personalizadas para cada alumno. Para ello, hemos implementado un editor de texto que cuenta con los formatos y las funcionalidades más utilizadas por los profesores, con el fin de que puedan realizar las adaptaciones de manera más rápida, siguiendo un Diseño Centrado en el Usuario. Las funcionalidades que se han implementado en AdaptaMaterialEscolar son: un buscador de pictogramas, ejercicios de completar huecos en blanco, de generación de sopas de letras, de verdadero o falso, de definir conceptos, y de pregunta para desarrollar con un espacio limitado. La aplicación web ha sido probada y evaluada por usuarios finales que pretenden usarla en el período escolar. Los resultados obtenidos demuestran que se cubre una necesidad real del profesorado y su interés por seguir desarrollando y mejorando AdaptaMaterialEscolar. vii Palabras Clave Adaptación curricular no significativa Accesibilidad Pictogramas Herramienta docente Editor de texto Aplicación web Material académico ix xvi Índice 4.3. APIdeARASAAC........................ 27 4.4. Jest ................................ 28 4.5. CKEditor ............................. 31 4.6. Word-search............................ 32 5. Metodología de desarrollo 37 5.1. Introducción............................ 37 5.2. Kanban .............................. 38 5.3. Tiposdepruebas......................... 41 5.3.1. Pruebas de memoria . . . . . . . . . . . . . . . . . . . 41 5.3.2. Pruebas de implementación . . . . . . . . . . . . . . . 41 6. AdaptaMaterialEscolar 45 6.1. Requisitos de la aplicación . . . . . . . . . . . . . . . . . . . . 45 6.1.1. Captura de requisitos . . . . . . . . . . . . . . . . . . 46 6.1.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . 48 6.1.3. Requisitos adicionales . . . . . . . . . . . . . . . . . . 52 6.2. Diseño de la aplicación . . . . . . . . . . . . . . . . . . . . . . 52 6.2.1. Primera iteración: boceto inicial . . . . . . . . . . . . . 53 6.2.2. Segunda iteración: versión 1.0 del prototipo . . . . . . 53 6.2.3. Tercera iteración: iteración competitiva . . . . . . . . . 56 6.2.4. Cuarta iteración: diseño final . . . . . . . . . . . . . . 62 6.3. Implementación.......................... 62 6.3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . 68 6.3.2. Funcionalidades . . . . . . . . . . . . . . . . . . . . . . 72 6.3.3. Estructura del código . . . . . . . . . . . . . . . . . . 97 7. Evaluación de AdaptaMaterialEscolar 101 7.1. Introducción............................101 7.2. Diseño de la evaluación . . . . . . . . . . . . . . . . . . . . . . 102 7.3. Desarrollo de la evaluación . . . . . . . . . . . . . . . . . . . . 104 7.4. Resultado de la evaluación . . . . . . . . . . . . . . . . . . . . 105 7.5. Conclusión de la evaluación . . . . . . . . . . . . . . . . . . . 108 8. Conclusiones y Trabajo futuro 109 8.1. Conclusiones ...........................109 8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 111 9. Conclusions and Future Work 115 9.1. Conclusions............................115 9.2. Futurework............................117 Índice xvii 10.Trabajo Individual 121 10.1.Natalia...............................121 10.2.Jorge................................123 10.3.Pablo ...............................124 A. Tabla de puntuaciones individuales y examen de prueba 127 Bibliografía 131 Índice de figuras 3.1. Ejemplo de documento adaptado a lectura fácil. En este caso, un documento jurídico . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Ejemplo de pictograma de una rosa . . . . . . . . . . . . . . . 13 3.3. Ejemplo de pictograma que representa la acción de comer . . 13 3.4. Ejemplo de pictogramas del Sistema Pictográfico de Comunicación(SPC) ........................... 14 3.5. Ejemplo de sistema pictográfico Minspeak . . . . . . . . . . . 15 3.6. Interfaz de ARAWORD . . . . . . . . . . . . . . . . . . . . . 16 3.7. Ventana de generación de ejercicio de asociar conceptos con EasyTestMaker.......................... 17 3.8. Ejemplo de examen generado con EasyTestMaker . . . . . . . 17 3.9. Interfaz de Resoomer . . . . . . . . . . . . . . . . . . . . . . . 18 3.10. Interfaz de Canva para la creación de un esquema usando una plantilla .............................. 18 3.11. Ejemplo de guión gráfico . . . . . . . . . . . . . . . . . . . . . 20 3.12. Ejemplo de boceto en papel . . . . . . . . . . . . . . . . . . . 21 3.13. Ejemplo de prototipo en papel interactivo . . . . . . . . . . . 22 4.1. Interfaz de Moqups . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Menúsuperior........................... 24 4.3. Menú lateral izquierda . . . . . . . . . . . . . . . . . . . . . . 25 4.4. Menú lateral derecha (formato) . . . . . . . . . . . . . . . . . 25 4.5. Menú lateral derecha (interacciones) . . . . . . . . . . . . . . 25 4.6. Funcionalidad sin usar JSX . . . . . . . . . . . . . . . . . . . 26 4.7. Funcionalidad empleando JSX . . . . . . . . . . . . . . . . . . 26 4.8. Test pasado correctamente . . . . . . . . . . . . . . . . . . . . 30 4.9. Test no pasado correctamente . . . . . . . . . . . . . . . . . . 30 4.10. Ejemplo de CKEditor 5 . . . . . . . . . . . . . . . . . . . . . 32 4.11. Ejemplo de resultado de sopa de letras usando grid() . . . . . 34 4.12. Ejemplo de resultado de sopa de letras usando toString() . . . 35 4.13. Ejemplo de las palabras insertadas al usar words() . . . . . . 35 xix xx Índice de figuras 4.14. Ejemplo del objeto resultante al usar dump() . . . . . . . . . 36 4.15. Ejemplo de llamada a la función read() . . . . . . . . . . . . . 36 4.16. Ejemplo del string formado cuando se usan los parámetros de laFigura4.15........................... 36 5.1. Tablero Kanban ......................... 40 6.1. Boceto inicial de la aplicación . . . . . . . . . . . . . . . . . . 53 6.2. Versión 1.0 de la página principal . . . . . . . . . . . . . . . . 54 6.3. Versión 1.0 del editor . . . . . . . . . . . . . . . . . . . . . . . 55 6.4. Versión 1.0 de la búsqueda de pictogramas . . . . . . . . . . . 56 6.5. Versión 1.0 de la adaptación de actividades . . . . . . . . . . 56 6.6. Versión 1.0 de la adaptación de temario . . . . . . . . . . . . 57 6.7. Prototipo de la página principal (Jorge) . . . . . . . . . . . . 58 6.8. Prototipo de la página principal (Natalia) . . . . . . . . . . . 58 6.9. Prototipo de la página principal (Pablo) . . . . . . . . . . . . 59 6.10. Prototipo del editor (Jorge) . . . . . . . . . . . . . . . . . . . 59 6.11. Prototipo del editor con un desplegable en uno de los menús (Jorge)............................... 60 6.12. Prototipo de la vista previa (Jorge) . . . . . . . . . . . . . . . 61 6.13. Prototipo del editor (Natalia) . . . . . . . . . . . . . . . . . . 61 6.14. Prototipo del editor (Pablo) . . . . . . . . . . . . . . . . . . . 62 6.15. Página principal de AdaptaMaterialEscolar . . . . . . . . . . 63 6.16. Página principal de AdaptaMaterialEscolar tras subir un documento.............................. 64 6.17. Interfaz de AdaptaMaterialEscolar al seleccionar Pictogramas 64 6.18. Interfaz de AdaptaMaterialEscolar al seleccionar Completar huecos............................... 65 6.19. Interfaz de AdaptaMaterialEscolar al seleccionar Definiciones 65 6.20. Interfaz de AdaptaMaterialEscolar al seleccionar Desarrollo . 66 6.21. Interfaz de AdaptaMaterialEscolar al seleccionar Sopa de letras 66 6.22. Interfaz de AdaptaMaterialEscolar al seleccionar V/F . . . . . 67 6.23. Ejemplo de ventana movible . . . . . . . . . . . . . . . . . . . 67 6.24. Diagrama de flujo en Redux . . . . . . . . . . . . . . . . . . . 68 6.25. Comparación de flujo de información de componentes sin y con Redux. Fuente: https://blog.codecentric.de/en/2017/12/developingmodern-offline-apps-reactjs-redux-electron-part-3-reactjs-reduxbasics/............................... 70 6.26. Diagrama de secuencia de subir un documento . . . . . . . . . 73 6.27. Diagrama de flujo de subir un documento . . . . . . . . . . . 73 6.28. Diagrama de secuencia del proceso de inicialización del editor y la ejecución de la función execute() . . . . . . . . . . . . . . 78 Índice de figuras xxi 6.29. Resultados del buscador de pictogramas . . . . . . . . . . . . 79 6.30. Pictograma introducido en el editor . . . . . . . . . . . . . . . 79 6.31. Diagrama de clases del buscador de pictogramas . . . . . . . . 80 6.32. Diagrama de secuencia del buscador de pictogramas . . . . . 80 6.33. Vista previa de la sopa de letras . . . . . . . . . . . . . . . . . 81 6.34. Diagrama de flujo de la generación de la sopa de letras . . . . 83 6.35. Diagrama de secuencia de la generación de la sopa de letras . 84 6.36. Resultado de la generación de la sopa de letras . . . . . . . . 85 6.37. Diagrama de flujo cuando se modifica el texto de una definición 86 6.38. Diagrama de secuencia cuando se modifica el texto de una definición ............................. 86 6.39. Ejemplo I de opciones del ejercicio de definiciones . . . . . . . 87 6.40. Resultado del ejercicio de definiciones . . . . . . . . . . . . . . 88 6.41. Diagrama de flujo cuando se modifica el enunciado del ejercicio pregunta para desarrollar . . . . . . . . . . . . . . . . . . 89 6.42. Diagrama de secuencia cuando se modifica el enunciado del ejercicio pregunta para desarrollar . . . . . . . . . . . . . . . 89 6.43. Ejemplo de opciones del ejercicio pregunta para desarrollar . . 90 6.44. Resultado de ejercicio pregunta para desarrollar . . . . . . . . 90 6.45. Diagrama de flujo cuando añaden más filas al ejercicio de verdaderoofalso........................... 91 6.46. Diagrama de secuencia cuando añaden más filas al ejercicio de verdadero o falso . . . . . . . . . . . . . . . . . . . . . . . 92 6.47. Ejemplo de opciones del ejercicio verdadero o falso . . . . . . 92 6.48. Resultado de ejercicio verdadero o falso . . . . . . . . . . . . 93 6.49. Ejemplo de edición del texto del ejercicio completar huecos . . 93 6.50. Ejemplo de selección de palabras del ejercicio completar huecos 94 6.51. Diagrama de secuencia cuando se hace clic sobre Seleccionar palabras en el ejercicio completar huecos . . . . . . . . . . . . 95 6.52. Diagrama de flujo al seleccionar una palabra del ejercicio completarhuecos ........................... 95 6.53. Diagrama de secuencia cuando se hace clic en una palabra en el ejercicio completar huecos . . . . . . . . . . . . . . . . . . . 96 6.54. Resultado del ejercicio de completar huecos . . . . . . . . . . 97 6.55. Ejemplo de organización de Components . . . . . . . . . . . . 98 6.56. Ejemplo de organización de Pages . . . . . . . . . . . . . . . . 99 6.57. Ejemplo de organización de Redux . . . . . . . . . . . . . . . 99 6.58. Ejemplo de organización de CKEditor . . . . . . . . . . . . . 100 7.1. Gráfica de resultados de la Escala de Usabilidad de un Sistema106 7.2. Gráfica de resultados de Diseño, Funcionalidades y Utilidad real107 Índice de Tablas 6.1. Puntuación por importancia (Imp.) y dificultad (Dif.) de todos los requisitos de la aplicación . . . . . . . . . . . . . . . . . . 50 6.2. Lista de funcionalidades relacionadas con adaptaciones de temario (T) y ejercicios (E), ordenada por prioridad . . . . . . 51 6.3. Lista de funcionalidades de adaptación de formato, ordenada porprioridad ........................... 51 7.1. Cálculo del resultado del cuestionario de SUS . . . . . . . . . 106 A.1. Puntuación individual de cada miembro del equipo de desarrollo para cada requisito . . . . . . . . . . . . . . . . . . . . . 128 xxiii Capítulo 1 Introducción Resumen: En este capítulo se realiza la introducción del Trabajo de Fin de Grado que va a ser presentado en este documento. Primero, en la Sección 1.1, se explicará la motivación que ha dado lugar al trabajo. A continuación, en la Sección 1.2, el objetivo que se pretende alcanzar. Por último, la estructura del proyecto final, en la Sección 1.3. 1.1. Motivación La educación escolar tiene como finalidad promover el desarrollo de ciertas capacidades y el aprendizaje de determinados contenidos necesarios para que los alumnos puedan ser miembros activos de la sociedad. Para ello, la escuela debe ofrecer una respuesta educativa que evite la discriminación y asegure la igualdad de oportunidades. El sistema educativo español, en la actualidad, está organizado en ocho etapas o niveles que garantizan el derecho a una educación inclusiva para el alumnado en cada fase de su desarrollo cognitivo y emocional (González, 2020): Educación infantil, Educación primaria, ESO, Bachillerato, Formación profesional, Carrera universitaria, Másteres y postgrados y Doctorado. De éstas, únicamente dos son obligatorias: Educación Primaria (EP) y Educación Secundaria Obligatoria (ESO). En España hay aproximadamente unos 2 millones de alumnos con necesidades educativas especiales (NEE), aunque no todos ellos presentan algún tipo de discapacidad, frente a los 8 millones de estudiantes que hay en enseñanzas de régimen general no universitarias. Los materiales, recursos y contenidos que se presentan y usan en los centros educativos están regulados por ley en el currículum educativo o escolar. El currículum educativo trata de garantizar que todos los alumnos terminan cada curso igual de preparados y regula los elementos que determinan los 1 Capítulo 3 Estado del Arte Resumen: En este capítulo nos centraremos en explicar el dominio en el que se enmarca nuestro proyecto. En la sección 3.1 explicaremos en detalle las necesidades de las personas con necesidades especiales, y cómo se tratan de satisfacer mediante adaptaciones curriculares. Además, en la sección 3.2, mencionaremos algunas de las herramientas actuales para realizar adaptaciones curriculares orientadas a nuestro objetivo. Por otra parte, se explicarán en la sección 3.3 las bases del Diseño Centrado en el Usuario de cara a ofrecer una experiencia de usuario satisfactoria. 3.1. Adaptación Curricular Los materiales, recursos y contenidos que se presentan y usan en los centros educativos están regulados por ley en el currículo educativo o escolar. El currículo educativo trata de garantizar que todos los alumnos terminan cada curso igual de preparados, e incluye todos los recursos académicos, materiales y humanos necesarios para llevar a cabo el proyecto educativo marcado por la legislación. Las principales funciones del currículo educativo son: determinar las asignaturas, contenidos y temáticas comunes a todos los alumnos, determinar los criterios de evaluación y logros que debe superar el alumnado y formalizar los estándares educativos que permitan cumplir unos objetivos establecidos. En el currículo escolar existen unas necesidades educativas comunes, com9 10 Capítulo 3. Estado del Arte partidas por todos los alumnos. Sin embargo, no todos los estudiantes se enfrentan con las mismas herramientas al aprendizaje, cada estudiante tiene una necesidad individual. La mayoría de las necesidades individuales de los estudiantes son resueltas a través de actuaciones “sencillas”: dar más tiempo al alumno para el aprendizaje de determinados contenidos, diseñar actividades complementarias... Sin embargo, existen necesidades individuales que no pueden ser resueltas por estos medios, siendo necesarias una serie de medidas pedagógicas especiales distintas de las que requieren habitualmente la mayoría de los alumnos. En este caso se habla de necesidades educativas especiales. Para atender estas necesidades son necesarias adaptaciones curriculares. La adaptación curricular (o adecuación curricular) es la modificación de elementos del currículo a fin de dar respuesta a las necesidades especiales del alumnado. Las adaptaciones curriculares se clasifican en (CADAH, 2012): Adaptaciones Curriculares de Acceso al Currículo. Responden a las necesidades de un grupo de personas. Estos pueden ser: •De Acceso Físico. Representa a los recursos materiales y espaciales. Ejemplos de estos son mobiliario adaptado, iluminación y sonoridad adaptada, o profesorado de apoyo especializado en metodologías que faciliten el aprendizaje de los alumnos. •De Acceso a la Comunicación. Incluye materiales específicos de enseñanza tales como: aprendizaje, ayudas tecnológicas o sistemas de computación complementarios. Algunos ejemplos son el braille, la lengua de signos o la comunicación a través del ordenador. Adaptaciones Curriculares Individualizadas. Se realizan para un único alumno con el fin de responder a necesidades educativas especiales que no pueden ser compartidas por el resto de los compañeros. Pueden ser: •No Significativas. Adaptan materiales, tiempos, actividades, metodologías, técnicas e instrumentos de evaluación sin modificar los contenidos curriculares de las asignaturas. Es la estrategia principal para conseguir la individualización de la enseñanza y por tanto, tienen un carácter preventivo y compensador. •Significativas. Modificaciones que se realizan desde la programación, previa evaluación psicopedagógica, y que afectan a los elementos prescriptivos del currículo oficial a modificar e incluso eliminar objetivos generales de la etapa, contenidos básicos y nucleares de las diferentes áreas curriculares y criterios de evaluación. 3.1. Adaptación Curricular 11 Aunque la adaptación curricular incluye un amplio número de posibilidades y técnicas, en general es necesario simplificar el lenguaje que se utiliza, e incluso ofrecer alternativas al mismo. De ambas cuestiones se encargan, entre otros, la lectura fácil y los pictogramas, que se explicarán a continuación. 3.1.1. Lectura fácil para adaptación curricular No todas las personas tienen la misma capacidad de entender el lenguaje natural, ya que esta capacidad puede estar limitada por diferentes causas. Según el manual “Lectura fácil: Métodos de redacción y evaluación” (Óscar García Muñoz, 2012), las personas más afectadas por este problema son las personas con discapacidad intelectual. Algunos ejemplos son las personas con Síndrome de Down o las personas con enfermedades y trastornos mentales y del comportamiento, como las personas con Trastorno del Espectro Autista (TEA). También se ven afectadas las personas con dificultad para el desarrollo del lenguaje por discapacidad auditiva y las personas con circunstancias transitorias de dificultad en la comprensión lectora. Por ello, las adaptaciones a lectura fácil pueden suponer un gran beneficio para estos usuarios. Las adaptaciones curriculares para estos casos requieren documentos con un lenguaje más claro y comprensible, y una estructura más simple y esquemática. Las directrices de Lectura Fácil establecen un gran número de reglas, tanto estéticas como de redacción, para poder facilitar estas adaptaciones y garantizar un texto de fácil lectura. Algunas de las medidas que resultan de interés para este trabajo son: Gramática. Evitar ciertos tiempos verbales, como el futuro o el subjuntivo, o usar oraciones simples y cortas, son algunas de las medidas gramaticales que propone el manual. Ortografía. Tener en cuenta ciertas pautas para evitar el uso de signos ortográficos que puedan dificultar la comprensión lectora. Se recomienda evitar el punto y seguido, y usar el punto y aparte para así dejar bien diferenciadas las frases. También se aconseja evitar el punto y coma y los puntos suspensivos. En cuanto a los números, es preferible que se escriban en formato cifra. Léxico. Tratar de usar un vocabulario que no sea complejo. Se aconseja utilizar palabras sencillas expresadas de forma simple y que, en la medida de lo posible, no sean largas. También se recomienda utilizar siempre el mismo sinónimo y evitar abreviaturas y siglas. Tipografía. El tamaño de letra debe de ser lo suficientemente grande, entre 12 y 16 puntos, y se deben utilizar tipografías sin remate como 12 Capítulo 3. Estado del Arte Arial o Helvetica y reforzar la nitidez de los números. Composición del texto. Para las líneas, recomienda que cada una esté compuesta de una sola oración y que no superen los 60 caracteres. Contendrán un mínimo de 5 palabras y un máximo de 15 a 20, de modo que no queden ni muy cortas ni muy largas. En cuanto a los párrafos, aconseja alinear el texto a la izquierda, en párrafos y capítulos cortos, de forma que se favorezcan las pausas frecuentes. Recomienda que se mantenga un ritmo regular en la composición de párrafos para que así se muestre de una forma más nítida y organizada visualmente. Respecto a la distribución del espacio, recomienda una distribución ordenada y poco densa, cuanto más blanco mejor, y evitar un diseño en columnas. Imágenes. Se recomienda utilizar imágenes de apoyo al texto que estén bien referenciadas y utilizar símbolos o dibujos para ideas, conceptos o temas abstractos. Uno de los principales tipos de imágenes de apoyo son los pictogramas, que se explicarán en el siguiente apartado. Figura 3.1: Ejemplo de documento adaptado a lectura fácil. En este caso, un documento jurídico En la Figura 3.1 se muestra un ejemplo de un texto adaptado a lectura fácil. En este texto se puede ver un documento jurídico adaptado, en el que se aplican medidas mencionadas previamente, como la mayor separación entre líneas y el uso de pictogramas, además de usar un lenguaje más sencillo, con frases más cortas y simples. 3.1. Adaptación Curricular 13 3.1.2. Pictogramas para adaptación curricular Las personas con carencias sensoriales, cognitivas o con un conocimiento insuficiente de la lengua pueden presentar problemas a la hora de comunicarse. Por ello, los Sistemas Aumentativos y Alternativos de Comunicación (SAACs) (Basil, 2017), que se encargan de proporcionar información en medios alternativos, o aumentando éste, se presentan como una gran opción para la comunicación de estas personas. Uno de los SAACs más comunes son los pictogramas. Un pictograma (Logopedia, 2012) es un signo claro y esquemático que representa un objeto real, figura o concepto, sintetizando un mensaje que puede señalar o informar sobrepasando la barrera de las lenguas. Es un recurso comunicativo de carácter visual que podemos encontrar en diversos contextos de nuestra vida diaria y nos aporta información útil conocida por todos. Los pictogramas son: Universales. Pueden ser entendidos por cualquier persona, independientemente de su idioma. Visuales. Muestran con claridad y sencillez al objeto/acción que representan. Inmediatos. La comunicación se establece entre el emisor y el receptor tan solo señalando sobre el pictograma adecuado. Las Figuras 3.2 y 3.3 son ejemplos de pictogramas. En el primero se muestra un objeto físico, en este caso una rosa, y en el segundo se representa la acción de comer. Figura 3.2: Ejemplo de pictograma de una rosa Figura 3.3: Ejemplo de pictograma que representa la acción de comer Los sistemas pictográficos son sistemas que representan la realidad mediante pictogramas. Algunos ejemplos de sistemas pictográficos son: 14 Capítulo 3. Estado del Arte Sistema Pictográfico de Comunicación (SPC) (Belloch, 2014). Sus iconos representan de forma clara el concepto que pretenden transmitir. Son dibujos fácilmente diferenciables entre sí y de sencilla comprensión. La Figura 3.4 muestra un ejemplo de SPC, donde se ve una serie de pictogramas diferenciados por colores, junto con el significado de cada pictograma. Cada color representa una categoría diferente: •Amarillo: Se refiere a personas, incluyendo pronombres personales y posesivos. •Verde: Se refiere a verbos. •Azul: Se refiere a descripciones, principalmente adjetivos y adverbios. •Rosa: Se refiere a palabras de uso en interacciones sociales. •Blanco: Se refiere a la parte miscelánea, es decir, artículos, preposiciones, conjunciones..., todo lo que no pertenece a las anteriores categorías. Figura 3.4: Ejemplo de pictogramas del Sistema Pictográfico de Comunicación (SPC) Minspeak (Belloch, 2014). En este sistema los pictogramas no tienen un significado concreto preestablecido, sino que se fija por el logopeda y usuario, lo que permite personalizar los mensajes. La Figura 3.2. Herramientas existentes para adaptaciones curriculares 15 Figura 3.5: Ejemplo de sistema pictográfico Minspeak 3.5 muestra un ejemplo de un sistema Minspeak, donde se define el significado de los pictogramas a través de una combinación de estos. ARASAAC1. El Portal Aragonés de Comunicación Aumentativa y Alternativa (ARASAAC), creado en 2007, ofrece un amplio catálogo de pictogramas de libre acceso. Dichos pictogramas se encuentran divididos en categorías: Alimentación, Ocio, Lugar, Ser vivo, Educación, Tiempo, Miscelánea, Desplazamiento, Religión, Trabajo, Comunicación, Documento, Conocimiento y Objeto. Es uno de los sistemas pictográficos más usados en España, ya que incluye un amplio número de herramientas dedicadas a pictogramas, como buscadores o generador de documentos con pictogramas, como pueden ser calendarios u horarios. El catálogo de ARASAAC ofrece pictogramas tanto en color, como con blanco y negro, y fondos de colores. Los pictogramas de las Figuras 3.2 y 3.3 pertenecen a ARASAAC. 3.2. Herramientas existentes para adaptaciones curriculares La existencia de herramientas que faciliten adaptaciones curriculares es muy limitada. Existen herramientas enfocadas a realizar solo alguna de las adaptaciones que se pueden necesitar, pero de manera individualizada. ARAWORD2es una herramienta de procesado de textos que combina la escritura de texto con pictogramas y facilita la elaboración de materiales. También resulta una herramienta muy útil para ser usada por usuarios que están adquiriendo el proceso de la lectoescritura, ya que la aparición del pictograma, a la vez que se escribe, es un refuerzo muy positivo para reconocer y evaluar que la palabra o la frase escrita es correcta. En la Figura 3.6 se 1https://arasaac.org/ 2http://aulaabierta.arasaac.org/araword_inicio 16 Capítulo 3. Estado del Arte muestra un ejemplo de la interfaz de ARAWORD, donde se traducen las oraciones a pictogramas. Figura 3.6: Interfaz de ARAWORD EasyTestMaker3es una web de creación de exámenes online. Dicha herramienta incluye opciones de generación de ejercicios sencillos para exámenes, como ejercicios de verdadero/falso, asociación de conceptos, rellenar espacios en blanco y respuestas cortas. La Figura 3.7 muestra un ejemplo de cómo se genera un ejercicio de asociar conceptos, mientras que la Figura 3.8 muestra el resultado con otros tipos de ejercicios. EasyTestMaker ofrece un plan gratuito que permite crear hasta 25 tests, mientras que la versión de pago ofrece más opciones como insertar imágenes, exportar a PDF y personalización del texto. Por otra parte, existen herramientas que ayudan a la creación de esquemas y resúmenes. Una herramienta para realizar resúmenes es Resoomer4, la cual devuelve un texto resumido a través de un texto introducido. En la Figura 3.9 se muestra un ejemplo de la interfaz de Resoomer. Para la generación de esquemas, habitualmente se usan herramientas de diseño como Canva5. Canva ofrece plantillas prediseñadas donde el usuario puede introducir las palabras a organizar. La Figura 3.10 muestra un ejemplo de cómo se hace un esquema con Canva. 3https://www.easytestmaker.com/ 4https://resoomer.com/es/ 5https://www.canva.com/ 3.3. Diseño Centrado en el Usuario 17 Figura 3.7: Ventana de generación de ejercicio de asociar conceptos con EasyTestMaker Figura 3.8: Ejemplo de examen generado con EasyTestMaker 3.3. Diseño Centrado en el Usuario El Diseño Centrado en el Usuario (DCU) (Moreno, Jiménez y Sánchez, 2019) consiste en un enfoque de diseño de interfaces cuyo objetivo es crear un producto que resuelva las necesidades de los usuarios finales, consiguiendo así una mayor calidad de producto y, por tanto, una mayor satisfacción 24 Capítulo 4. Herramientas empleadas haciendo que un botón realice una función específica). También es colaborativo y permite la gestión de roles. En la Figura 4.1 se puede ver la interfaz de un proyecto en blanco. En la parte superior de la página, se encuentran las opciones para crear figuras geométricas y añadir notas, así como agregar a otros usuarios, y exportar el proyecto como una serie de imágenes en formato PNG o PDF y a formato HTML (Figura 4.2). Se observa que en el menú lateral de la izquierda se encuentran los apartados para la creación del prototipo (plantillas, páginas que tiene el proyecto, comentarios, imágenes, iconos, etc.), como se puede ver en la Figura 4.3. Por último, en el menú lateral de la derecha, podemos encontrar el formato de las diferentes páginas (o componentes) (Figura 4.4), y las interacciones disponibles (Figura 4.5). Figura 4.1: Interfaz de Moqups Figura 4.2: Menú superior En este proyecto se ha usado Moqups para la creación de la versión 1.0 del prototipo de la aplicación web (en la sección 6.2.2 se puede leer una explicación detallada de cómo se ha creado este prototipo y de las diferentes vistas del mismo). 4.2. React 25 Figura 4.3: Menú lateral izquierda Figura 4.4: Menú lateral derecha (formato) Figura 4.5: Menú lateral derecha (interacciones) 4.2. React React2es una librería de JavaScript, creada por Facebook y de código abierto3, que permite crear interfaces de usuario interactivas de forma sencilla. Está basada en la programación orientada a componentes, donde cada componente se puede ver como una funcionalidad distinta, es decir, como una pieza de un puzle. La ventaja de usar componentes es que, al ser independientes unos de otros, si en la carga de una página web falla uno, no afectaría al resto de componentes, por lo que dicha página quedaría cargada sin ese componente. Así mismo, al usar un DOM (Modelo de Objetos del Documento) virtual, deja que la propia librería actualice las partes que han cambiado, en lugar de actualizar todos los componentes. La sintaxis que emplea React es muy parecida a la sintaxis HTML. Para definir los componentes, se emplean etiquetas definidas por el usuario dentro de código Javascript. Esta sintaxis se llama JSX. No es obligatorio su uso, pero facilita tanto la codificación como la lectura del código. En la Figura 4.6 se puede ver un ejemplo de una funcionalidad sin emplear el formato JSX y en la Figura 4.7 la misma funcionalidad, pero usando JSX. 2https://es.reactjs.org/ 3https://github.com/facebook/react 26 Capítulo 4. Herramientas empleadas Figura 4.6: Funcionalidad sin usar JSX Figura 4.7: Funcionalidad empleando JSX React aporta rendimiento, flexibilidad y organización de código, frente a la creación de una página web de forma clásica, es decir, sin usar ninguna librería o framework. Tiene una documentación bastante completa4, junto con un tutorial para aprender desde cero5. 4https://es.reactjs.org/docs/getting-started.html 5https://es.reactjs.org/tutorial/tutorial.html 4.3. API de ARASAAC 27 Esta librería la hemos usado en el proyecto para implementar los distintos tipos de adaptaciones en la aplicación web (ver sección 6.1.1). 4.3. API de ARASAAC El Centro Aragonés para la Comunicación Aumentativa y Alternativa (ARASAAC) proporciona una API pública6, cuyo uso es gratuito siempre y cuando la aplicación a desarrollar sea no comercial7es, debido a que está bajo la licencia de Creative Commons BY-NC-SA, es decir, “ReconocimientoNoComercial-CompartirIgual”8en el que se debe dar crédito a los/as autores/as originales. No se puede usar para fines comerciales y en el caso de que se modifique o transforme ese material se debe distribuir bajo la misma licencia. La API de ARASAAC consta de cuatro apartados, cada uno de los cuales tiene una ruta web dependiendo de lo que se quiera consultar: materiales, pictogramas, palabras clave y usuarios. Como en este proyecto usaremos solo la búsqueda de pictogramas, nos centraremos en el apartado de pictogramas. La API de ARASAAC proporciona ocho servicios web para pictogramas. Todos ellos se usan con el método de petición GET y con formato de salida en JSON. De los ocho servicios web proporcionados, en este TFG se usarán los siguientes: /pictograms/{idPictogram}: Devuelve el pictograma en formato imagen dado su identificador {idPictogram}. Si tiene éxito, devolverá la imagen del pictograma en formato png. En caso contrario, devolverá un mensaje de error. /pictograms/{locale}/{idPictogram}: Devuelve los datos de un pictograma dado su identificador {idPictogram} e idioma {locale}9. Si tiene éxito devolverá una lista en formato JSON con los datos de cada pictograma. En caso contrario, devolverá un error 404. /pictograms/{idPictogram}/languages/{languages}: Devuelve los datos de un pictograma dado su identificador {idPictogram} en uno o más idiomas9especificados en {languages}. Si tiene éxito devolverá 6https://arasaac.org/developers/api 7https://arasaac.org/developers/ 8https://creativecommons.org/licenses/by-nc-sa/4.0/ 9Idiomas disponibles: an, ar, bg, br, ca, de, el, en, es, et, eu, fa, fr, gl, he, hr, hu, it, mk, nl, pl, pt, ro, ru, sk, sq, sv, sr, val, zh 28 Capítulo 4. Herramientas empleadas los datos del pictograma en formato JSON en los idiomas proporcionados. En caso contrario, devolverá un mensaje de error. /pictograms/{locale}/search/{searchText}: Devuelve en una lista los datos de los pictogramas en el idioma {locale}9que contenga la cadena de caracteres {searchText} pasada como parámetro. Si tiene éxito devolverá dicha lista en formato JSON con los datos de cada pictograma encontrado. En caso contrario, no devolverá nada. /pictograms/{locale}/bestsearch/{searchText}: Devuelve en una lista los datos de los pictogramas en el idioma {locale}9que contenga exactamente la cadena de caracteres {searchText} pasada como parámetro. Si tiene éxito devolverá dicha lista en formato JSON con los datos de cada pictograma encontrado. En caso contrario, no devolverá nada. 4.4. Jest Jest10 es una librería para Javascript, creada por Facebook, que permite realizar pruebas unitarias y de integración y es compatible con muchos frameworks incluyendo el que hemos elegido (React). Jest tiene una instalación muy sencilla, de pocos pasos, y su configuración es mínima. La documentación11 es completa, y contiene lo necesario para poder desarrollar estos tipos de pruebas, junto con una serie de ejemplos realizados paso a paso. El uso de esta librería proporciona ventajas frente a no usarla o hacer tests de forma tradicional: Compatiblidad. Es compatible con la mayoría de frameworks que existen, tales como Angular, React, NodeJS, Babel, etc. Rapidez. Cuando las pruebas están vinculadas a la CPU, se ahorra muchísimo tiempo en la ejecución de las pruebas. Esta rapidez se consigue gracias a la combinación de varios factores: 1. Paralelización. Gracias a la paralelización, se produce una gran ganancia en el rendimiento. 2. Ejecuta primero las pruebas más lentas. Aprovecha al máximo su capacidad de procesamiento al ejecutar primero las pruebas más lentas. 10https://jestjs.io/es-ES/ 11https://jestjs.io/es-ES/docs/getting-started 4.4. Jest 29 3. Tiene una caché de transformaciones babel incorporada. Aplicar transformaciones al código requiere un uso intensivo de CPU. Gracias al uso de una caché que se comparte entre procesos, se reduce mucho tiempo al ejecutar las pruebas. Instantáneas. Las pruebas de instantáneas son de gran utilidad para garantizar que la interfaz no cambia de forma inesperada. Una vez que se ha instalado Jest, para realizar un test hay que seguir estos pasos: 1. Crear un fichero Javascript donde estará la función a probar (por ejemplo, suma.js): function suma(a,b){ return a + b; } module . exports = suma ; Listing 4.1: Ejemplo de función a probar, en este caso, suma de dos números 2. Crear un fichero Javascript que contendrá la prueba (por ejemplo suma.test.js). Para escribir la prueba, tiene que seguir el siguiente esquema: test( título , () =>{ expect ( valor , función , expresión ...) . comparador ( resultadoEsperado); }); Listing 4.2: Esquema del test donde “comparador” puede ser .toBe(),.toEqual(),.toBeNull(), etc., una de las funciones comparadoras que más se ajuste a lo que se quiere probar. En la documentación oficial12, hay un apartado llamado “Utilizando Comparadores”, donde enseñan algunas funciones comparador. Si se quiere ver todas las funciones que ofrece es mejor visitar la API13. En el caso de la prueba que queremos escribir: const suma = require ("./ suma "); test(" Prueba de suma : 1 + 2 = 3", () = >{ expect ( suma (1 ,2) ). toBe (3) ; }); 12https://jestjs.io/es-ES/docs/using-matchers 13https://jestjs.io/es-ES/docs/api 30 Capítulo 4. Herramientas empleadas test(" Prueba de suma incorrecta : 1 + 2 = 4", () =>{ expect ( suma (1 ,2) ). toBe (4) ; }); Listing 4.3: Ejemplo de test para la función suma Si ejecutamos solo la primera función, nos saldrá que hemos pasado el test (Figura 4.8). En cambio, si ejecutamos ambos tests, vemos que el primero sí lo ha pasado, pero el segundo ha fallado, y nos da más información sobre lo que debería haber dado y la línea de código donde ha fallado (Figura 4.9). Figura 4.8: Test pasado correctamente Figura 4.9: Test no pasado correctamente Esta librería la hemos usado en el proyecto para realizar las pruebas unitarias y de integración de las distintas partes de la aplicación. 4.5. CKEditor 31 4.5. CKEditor CKEditor14 es un editor de código abierto de tipo “WYSIWYG”15 y es totalmente personalizable. CKEditor tiene dos versiones diferentes: CKEditor 4: Es la versión antigua compatible con la mayoría de los navegadores. Con ella se puede tener tres tipos de editor: Article Editor (editor para artículos), Document Editor (editor para documentos) e Inline Editor (editor en línea). La documentación16 es muy completa: contiene una guía de instalación paso a paso, además de bastantes ejemplos para diferentes propósitos (insertar contenido, personalizar la interfaz de usuario...). También tiene una demo online17 que muestra los diferentes editores para esta versión. Gracias al programa LTS (Long Term Support) tanto el desarrollo como el soporte de esta versión están garantizados hasta 2023. CKEditor 5: Es la versión más moderna con un rediseño y mejora de la interfaz y la introducción de un nuevo modelo de datos. A diferencia de la versión anterior, esta versión tiene más tipos de editor: Classic (el editor clásico), Balloon (editor de globo, que permite insertar contenido directamente en la ubicación que se esta señalando), Balloon Block (el mismo que el anterior pero se edita por bloques), Inline (el mismo que en CKEditor 4), Document (el mismo que en CKEditor 4) y Pagination (el editor de paginación, que permite ver las líneas de salto de página que coincidirían con los límites de la página cuando el documento se exporta a PDF o Word). También tiene una demo online18 de los diferentes tipos de editor para esta versión, y un constructor online19 donde se puede elegir el tipo de editor y los complementos que tendrá. La documentación20 en esta versión también es bastante completa: tiene una guía de instalación paso a paso, ejemplos de los editores, además de una guía de cómo trabajar con el framework de este editor. 14https://ckeditor.com/ 15WYSIWYG, acrónimo de What You See Is What You Get (en español, “lo que ves es lo que obtienes”). Es una frase aplicada a los procesadores de texto y otros editores con formato, que permiten escribir un documento mostrando directamente el resultado final, frecuentemente el resultado impreso. https://es.wikipedia.org/wiki/WYSIWYG 16https://ckeditor.com/docs/ckeditor4/latest/ 17https://ckeditor.com/ckeditor-4/demo/ 18https://ckeditor.com/ckeditor-5/demo/ 19https://ckeditor.com/ckeditor-5/online-builder/ 20https://ckeditor.com/docs/ckeditor5/latest/ 32 Capítulo 4. Herramientas empleadas Figura 4.10: Ejemplo de CKEditor 5 En este proyecto hemos usado la versión CKEditor 5 para crear un documento editable, en el que el usuario puede realizar los diferentes tipos de adaptaciones que ofrece la aplicación, y poder descargar el resultado final en formato PDF. En la Figura 4.10 se puede ver un ejemplo de la versión CKEditor 521. En la parte superior se muestra una barra de navegación con los diferentes ejemplos de tipos de editor mencionados anteriormente, y en la inferior, el editor junto con su barra de herramientas (donde el primer elemento de ésta barra es la exportación a formato PDF). 4.6. Word-search Para la creación de los ejercicios de sopas de letras empleamos el paquete NPM (Node Package Manager)word-search22. Para crear una sopa de letras con este paquete, se necesitan unas opciones de configuración que están encapsuladas en un objeto, y devuelve la sopa de letras en un array. Las opciones de configuración son las siguientes: 21Fuente: https://ckeditor.com/ckeditor-5/demo/#document 22https://www.npmjs.com/package/@blex41/word-search 4.6. Word-search 33 cols: Es un número entero que representa el número de columnas que tendrá la sopa de letras. Por defecto tiene un valor de 10. rows: Es un número entero que representa el número de filas que tendrá la sopa de letras. Por defecto tiene un valor de 10. disabledDirections: Es un array de strings que representa las direcciones cardinales (“N”, “S”, “E”, “W”, “NE”, “NW”, “SE”, “SW”) no válidas para colocar las palabras en la sopa de letras. Por defecto tiene un valor vacío, es decir, todas las direcciones están permitidas. dictionary: Es un array de strings que contiene las palabras que debe contener la sopa de letras. Por defecto tiene un valor vacío. maxWords: Es un número entero que representa el número de palabras máximo que se insertarán en la sopa de letras. Por defecto tiene un valor de 20. Aunque la longitud del array dictionary supere este valor, solo se insertará ese número de palabras en la sopa de letras. backwardsProbability: Es un número decimal entre 0 y 1 que representa la probabilidad que tiene cada palabra de escribirse al revés. Solo funciona si no se deshabilita, en una dirección cardinal, uno de los extremos. Por ejemplo, para poder escribir una palabra al revés en vertical, se deben tener las direcciones cardinales “N” y “S” habilitadas, no solo una de ellas. Por defecto tiene un valor de 0.3. upperCase: Es un booleano que indica si las letras de la sopa de letras se quieren en mayúscula (true) o no (false). Por defecto tiene el valor true. diacritics: Es un booleano que indica si las letras deberían mantener las tildes en la sopa de letras. Por defecto tiene el valor false, es decir, no mantener las tildes en la sopa de letras. En el caso de que alguna de estas opciones no se modificasen, no daría ningún error, sino que cogería el valor por defecto que tuvieran. Para crear la sopa de letras, es necesario hacer una llamada a Wordsearch pasándole como parámetro las opciones de configuración. En el siguiente ejemplo se ha establecido un tablero de 8x9, se han habilitado todas las direcciones, la probabilidad que tiene cada palabra de escribirse al revés se ha fijado a 0.5 (cada palabra tiene un 50 % de probabilidad de escribirse al revés), el número máximo de palabras que se insertarán es 20, se quieren mantener las tildes, las letras se quieren en mayúsculas y hay que buscar las palabras perro, gata, flamenco y avestruz. 40 Capítulo 5. Metodología de desarrollo Tareas de implementación: Son tareas de diseño y/o desarrollo de código. En la Figura 5.1 se puede ver nuestro tablero Kanban . Este tablero tiene un total de seis columnas: Figura 5.1: Tablero Kanban To Do: Se corresponden con las tareas que todavía no se han realizado. In Progress: Son tareas en las que el equipo de desarrollo ha comenzado a trabajar. Ready for Testing: Son tareas listas para ser probadas. Testing: Son tareas que se están probando. Dependiendo del tipo de tarea se probará de una forma u otra. En la sección 5.3 se dan más detalles de cómo se prueban las tareas de memoria y las de implementación. Needs approval: En esta lista se encuentran las tareas que necesitan ser aprobadas por las tutoras antes de darlas por finalizadas. Una vez que se ha terminado de trabajar en una tarea y se ha acabado de hacerle las pruebas, habrá que moverla de Testing a esta columna. Done: Son tareas que se han dado por terminadas, validadas y aprobadas. Cuando las tutoras le han dado el visto bueno, se podrá mover de Needs Approval aDone. 5.3. Tipos de pruebas 41 Así mismo, en la Figura 5.1 se observa que las tareas tienen asignadas unas etiquetas de colores: 123 Tareas relacionadas con la memoria. 123 Tareas correspondientes con diseño y desarrollo de código (implementación). 123 Tareas que requieren investigación por parte del equipo, antes de empezar a codificar o realizar cualquier otro tipo de tarea. 123 Tareas que no corresponden con ninguna de las anteriores. El WIP será de dos tareas por persona en cada columna (In Progress y Testing), lo que hace un total de seis tareas en cada columna. 5.3. Tipos de pruebas Como tenemos dos tipos de tareas, de memoria y de implementación, cada una se tratará de una forma diferente a la hora de realizar las pruebas. 5.3.1. Pruebas de memoria Las pruebas de memoria consisten en buscar errores léxicos y gramaticales en la memoria, y corregirlos antes de su entrega, además de completarla con más información en el caso de que sea posible, y comprobar que todo se entiende. Estas pruebas las harán todos los miembros del equipo de la siguiente forma: cuando haya alguna tarea de memoria en Ready for testing, el usuario que vaya a revisarla, se la asignará y la llevará a Testing. Una vez que haya terminado, y no sea la última persona en haberla revisado, la volverá a llevar a Ready for testing. En caso contrario, la llevará a Needs approval. Con este sistema tratamos de asegurarnos de que todo esté correctamente escrito. 5.3.2. Pruebas de implementación Para las pruebas de implementación, se contemplan dos tipos de pruebas: pruebas unitarias y pruebas de integración. Todas estas pruebas las haremos 42 Capítulo 5. Metodología de desarrollo con Jest (ver sección 4.4). Estas pruebas las desarrollará y realizará alguno de los miembros que no haya implementado esa parte del código, y las hará cuando la tarea correspondiente de prueba esté en la columna Ready for Testing. La razón de esto es porque las personas que no han escrito el código pueden sacar más casos de prueba que las personas que lo han escrito. 5.3.2.1. Pruebas unitarias Una prueba unitaria se utiliza para comprobar que un método implementado funciona como se esperaba. Debe cumplir una serie de características: Deben ser automáticas: se deben poder ejecutar sin que haya una intervención manual. Deben ser completas: es decir, deben cubrir la totalidad del código. Deben ser independientes: debido a que se han creado para comprobar una parte concreta del código, no deberían interferir con otras partes, y se deben poder ejecutar en cualquier entorno. Deben ser repetibles: se deben repetir todas las veces que queramos, y el resultado debe ser el mismo en todas las repeticiones. El uso de pruebas unitarias proporciona una serie de ventajas: Aumento de la calidad del código: debido a que estas pruebas se ejecutan de forma regular, permiten detectar errores a tiempo y poder corregirlos antes de completar el código y liberar la aplicación. Facilitan los cambios: si se considera que el código es mejorable se pueden aplicar cambios sin problemas, ya que la prueba unitaria nos avisaría de los errores que pudieran surgir. Reduce los tiempos de integración, ya que podemos probar partes del código sin disponer del código completo. Reduce el coste: teniendo en cuenta que permite detectar errores en fases tempranas, evitan el paso de los errores a fases posteriores y, además, el cambio de corregirlos en fases tempranas es menos costoso y más fácil que si se corrigieran en fases más tardías, ya que en este último caso el error suele ser producido a causa de muchos cambios. Por ello, las pruebas unitarias ayudan a reducir los costes de corrección de errores y a optimizar las entregas, ahorrando tiempo y recursos. 5.3. Tipos de pruebas 43 5.3.2.2. Pruebas de integración Una prueba de integración se utiliza para comprobar que dos o más componentes, ya validados por las pruebas unitarias, son compatibles entre sí y funcionan correctamente. Hay varios tipos de pruebas de integración (Rodríguez, 2015): Top-Down: Es una estrategia de “arriba a abajo”, donde se va probando los componentes que no son llamados por ningún otro, y se integran los componentes que son llamados desde la parte integrada. Bottom-Up: Es una estrategia de “abajo a arriba”, donde se prueban los componentes que no llaman a otras partes de la aplicación, y se continua por componentes que solo llaman a la parte integrada. End-to-End: Es una estrategia orientada al proceso de negocio, en la cual integran los componentes necesarios por parte de un proceso de negocio para ver si el flujo de la aplicación funciona tal y como fue diseñado. Funciones: Este tipo de integración está orientada a una función del sistema. Se van integrando cada uno de los componentes que necesita esa función. Ad-Hoc: En esta estrategia el software se ve como módulos independientes, y una vez que se han implementado y validado por parte del equipo de desarrollo, se integran. Big-Bang: Esta estrategia solo es válida cuando se dispone de todos los componentes, es decir, no se integra hasta que el software no esté completo. Este proyecto seguirá la estrategia Bottom-up. Capítulo 6 AdaptaMaterialEscolar Resumen: En este capítulo se explicará, en la sección 6.1, para quién va a desarrollarse el proyecto de AdaptaMaterialEscolar y el proceso de captura de requisitos. En la sección 6.2, se explicará cómo se diseñó la aplicación a partir de los requisitos. Por último, en la sección 6.3, se mostrará cómo se ha implementado la aplicación. 6.1. Requisitos de la aplicación El Trabajo de Fin de Grado de AdaptaMaterialEscolar es un proyecto sin ánimo de lucro que ha sido desarrollado con la colaboración de las profesoras del Aula TEA del IES Maestro Juan de Ávila de Ciudad Real. Para su implementación, debido a que se pretende que el proyecto sea realmente útil para los docentes, se hizo una amplia captura de requisitos con los usuarios finales, de forma que se pudieron conocer las necesidades reales de un centro educativo, siguiendo un Diseño Centrado en el Usuario. Se realizaron una serie de reuniones con los usuarios finales, tanto presenciales como online, para obtener los requisitos de la aplicación; además, se mantuvo el contacto con ellos durante todo el proceso de diseño e implementación, para irles enseñando la evolución de la aplicación. 45 46 Capítulo 6. AdaptaMaterialEscolar 6.1.1. Captura de requisitos El 25 de julio de 2019 se organizó una primera reunión presencial con las dos profesoras que forman parte del Aula TEA en el IES Maestro Juan de Ávila: Ana María Alonso Frades, especialista en Pedagogía Terapéutica y Ana María Díaz Valle, especialista en Audición y Lenguaje. Las profesoras nos hablaron sobre los diferentes perfiles de alumnos TEA con los que trabajaban en el centro y explicaron la importancia de contar con una aplicación especializada en adaptaciones curriculares, que fuera flexible y permitiera generar diferentes modelos de temario, actividades y exámenes con el menor esfuerzo posible. El proyecto debía poder convertir un mismo párrafo o ejercicio en otro más sencillo de comprender, asimilar o resolver, de forma que pudiera personalizarse para cada alumno de acuerdo a su capacidad cognitiva y así facilitarles el aprendizaje sin excluir temario. A pesar de que hay unas pautas a seguir para adaptar el temario, las actividades y los exámenes (por ejemplo usar letra grande e imágenes), no hay un estándar definido que sigan todos los profesores, y a algunos alumnos les resulta confuso el cambio de una asignatura a otra. Después de hablar con las profesoras y conocer a un alumno TEA que nos explicó su rutina en el instituto, vimos un ejemplo de tema y examen adaptado de Ciencias Naturales. En este punto, a partir de la información proporcionada por los usuarios finales, se tomaron las siguientes decisiones: Tipo de aplicación: Inicialmente las profesoras plantearon desarrollar una aplicación de escritorio que pudieran instalar tanto en los ordenadores del centro, como en los suyos propios, pero se tuvo en cuenta que probablemente no todo el profesorado contaría con un ordenador personal con el que poder trabajar desde casa. Por ello, se tomó la decisión de desarrollar el proyecto como aplicación web, de manera que se pudiera utilizar desde cualquier dispositivo con acceso a Internet. Registro: Las profesoras indicaron que era mejor no tener que registrarse en la aplicación para poder trabajar con ella, ya que se consideró que no era conveniente almacenar usuarios ni contraseñas para evitar que los profesores tuvieran que utilizar datos personales con los que identificarse. A partir de ahí, como resultado de la reunión, obtuvimos las funcionali- 6.1. Requisitos de la aplicación 47 dades de la aplicación. A continuación, presentamos estas funcionalidades: Adaptaciones de temario: La motivación de las adaptaciones de temario es conseguir, en el menor tiempo posible, una unidad didáctica teórica adaptada al alumno de forma casi inmediata y automática, seleccionando el texto a convertir. En este sentido, la aplicación debe ofrecer al usuario la posibilidad de: •Generar un resumen a partir de un texto. •Crear esquemas que faciliten la visualización del temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero. •Crear tablas que organicen el temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiéndolo desde cero. Creación de ejercicios: La motivación de la creación de ejercicios es crear ejercicios de forma fácil, seleccionando texto o un ejercicio ya redactado y adaptándolo de forma automática al tipo de ejercicio que se quiere obtener. La aplicación debe permitir crear los siguientes tipos de ejercicios: •Relacionar contenido mediante flechas. •Sopa de letras. •Completar espacios en blanco en un texto, tabla o esquema. •Pregunta de desarrollo con un espacio limitado para escribir la respuesta. •Verdadero o falso. Además, todos los ejercicios que se creen deben permitir añadir un enunciado y ejemplos (con o sin pictogramas) explicando cómo debe resolverse el ejercicio. Adaptaciones de formato: Las adaptaciones de formato deben permitir estandarizar cualquier documento que se vaya a entregar al alumno, de manera que el cambio de una asignatura a otra no suponga un cambio visual y el aprendizaje sea menos costoso. Nuestra aplicación debe permitir al usuario final que, dado un texto, pueda: •Sustituir una palabra por un pictograma. •Sustituir una palabra por una imagen. •Resaltar una palabra con un color, para que los alumnos visualicen cada una de las palabras resaltadas en el texto con mayor facilidad. 48 Capítulo 6. AdaptaMaterialEscolar •Añadir una leyenda de colores con la categoría de cada tipo de palabra resaltada, para que los alumnos puedan identificar el significado de cada una de las palabras resaltadas en el texto. •Añadir una leyenda de colores para el tema de cada asignatura, para que los alumnos las distingan con mayor facilidad. •Estandarizar el formato en textos, estableciendo una fuente de texto determinada y un tamaño acorde para cada alumno. •Estandarizar el formato para títulos e índices del temario, generando de forma automática una plantilla del color de la asignatura. •Aumentar el tamaño de la fuente de una parte del texto. •Subrayar una parte del texto. •Poner en negrita una parte del texto. •Añadir imágenes buscando una palabra en bases de datos de imágenes libres. 6.1.2. Análisis de requisitos Una vez recopilados los requisitos del proyecto, redactamos una lista con éstos para que pudiéramos, tanto las profesoras del Aula TEA como el equipo de desarrollo, analizarlos de forma independiente, para no influir en la toma de decisiones sobre la importancia y dificultad de cada funcionalidad. Enviamos el listado de requisitos a las profesoras por correo electrónico, con la finalidad de que revisaran el contenido o añadieran nuevas funcionalidades si fuera necesario y evaluaran cada uno de ellos. Las profesoras Ana María Alonso Frades y Ana María Díaz Valle debían puntuar los requisitos según la utilidad que pudieran aportar cada uno de ellos a su trabajo. Las posibles puntuaciones debían ir de uno a tres, siendo el uno poco importante, el dos importante y el tres imprescindible. Prácticamente todos los requisitos fueron puntuados como imprescindibles, por lo que quedó claro que el proyecto cubre una necesidad real y no añadieron ningún requisito más. Por otro lado, cada miembro del equipo de desarrollo puntuó los requisitos de manera individual, para no influir en la decisión de los compañeros, según la dificultad que consideraban que tendría la implementación de cada requisito a nivel técnico (en el Anexo A.1 se encuentra la tabla con las puntuaciones individuales para cada requisito de cada miembro del equipo de desarrollo). Las posibles puntuaciones debían ir de uno a tres, siendo el uno difícil, el dos intermedio y el tres fácil. 6.1. Requisitos de la aplicación 49 La finalidad de este análisis de los requisitos era obtener un listado con las funcionalidades ordenadas por dificultad e importancia. Con la puntuación que asignaron las profesoras de forma conjunta, se obtuvo el indicador de importancia de cada tarea y, con la media de las puntuaciones del equipo de desarrollo, el indicador de dificultad. En la Tabla 6.1 se muestra el listado final de las funcionalidades, agrupadas por tipo de adaptación, con la media de las puntuaciones obtenidas en importancia y dificultad. ADAPTACIONES DE TEMARIO (T) Requisito Evaluación Imp. Dif. Generar un resumen a partir de un texto 3 2 Crear esquemas que faciliten la visualización del temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero 3 1.7 Crear tablas que organicen el temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero 2 1.7 ADAPTACIONES DE EJERCICIOS (E) Requisito Evaluación Imp. Dif. Ejercicios de relacionar contenido mediante flechas 3 2 Ejercicios de sopa de letras 2 3 Ejercicios de completar espacios en un texto 3 2.7 Ejercicios de pregunta de desarrollo con un espacio limitado para escribir la respuesta 3 2.7 Ejercicios de verdadero o falso 3 3 Ejercicios de completar los espacios en blanco en tablas 3 2 Ejercicios de completar los espacios en blanco en esquemas 3 1 Añadir enunciados y ejemplos (con o sin pictogramas), donde se explique cómo debe resolverse el ejercicio 2 3 ADAPTACIONES DE FORMATO (F) Requisito Evaluación Imp. Dif. Sustituir una palabra por un pictograma 2 2.7 Sustituir una palabra por una imagen 2 2.3 Resaltar una palabra con un color 3 3 Añadir una leyenda de colores con la categoría de cada tipo de palabra resaltada, para que los alumnos puedan identificar el significado de cada una de las palabras resaltadas en el texto 1 3 56 Capítulo 6. AdaptaMaterialEscolar Figura 6.4: Versión 1.0 de la búsqueda de pictogramas Figura 6.5: Versión 1.0 de la adaptación de actividades 6.2.3. Tercera iteración: iteración competitiva Una vez que se hizo la versión 1.0 del prototipo, se propuso hacer una iteración competitiva para ver si este prototipo se podía mejorar. Cada miem- 6.2. Diseño de la aplicación 57 Figura 6.6: Versión 1.0 de la adaptación de temario bro del equipo realizó, de forma individual y sin influir los unos en los otros, un prototipo propio partiendo del inicial. Con esto se consigue tener diferentes puntos de vista sobre una misma funcionalidad. Una vez que todos los prototipos fueron diseñados (dos de forma digital y otro en papel) se realizó una puesta en común para analizar las distintas propuestas. Los resultados fueron los siguientes: Página principal: En las Figuras 6.7, 6.8 y 6.9 se puede observar los resultados de los tres prototipos para la página principal. En el caso del prototipo de Jorge (Figura 6.7), en la parte inferior están los créditos y los logotipos de ARASAAC3, la Universidad Complutense de Madrid4 y la licencia de Creative Commons5. También se observa que en la parte de la derecha de la barra de navegación se propuso hacer un sistema de login para poder guardar el trabajo realizado. Ésto último no resultó debido a que los usuarios finales que usen la aplicación especificaron que no querían recordar ningún nombre de usuario y contraseña. También, en la parte superior de dicha figura coincidimos que sería buena idea establecer algún botón, tal y como ocurre en las Figuras 6.8 y 6.9. En el primer caso, el prototipo de Natalia, se observa que hay dos botones: Créditos, donde estarían los logotipos de ARASAAC3, la Uni3https://arasaac.org/ 4https://www.ucm.es 5https://creativecommons.org/ 58 Capítulo 6. AdaptaMaterialEscolar Figura 6.7: Prototipo de la página principal (Jorge) Figura 6.8: Prototipo de la página principal (Natalia) versidad Complutense de Madrid4y la licencia de Creative Commons5 y las personas que han creado el proyecto, junto con las directoras; y Ayuda, por si el usuario necesita algún tipo de ayuda con la aplicación. En el segundo caso, el prototipo de Pablo, se ven tres botones en forma de enlaces: Inicio, donde te llevaría a la página principal; Ayuda, donde se incluiría la parte de créditos y los logotipos; y Contacto, por si el 6.2. Diseño de la aplicación 59 Figura 6.9: Prototipo de la página principal (Pablo) usuario tiene algún problema y/o sugerencia pueda contactar con los desarrolladores y proporcionarle una respuesta. Figura 6.10: Prototipo del editor (Jorge) Editor: En las Figuras 6.10, 6.13 y 6.14 se pueden ver los resultados de la página del editor. En el caso del prototipo de Jorge (Figura 6.10), observamos una barra de navegación con diferentes menús, que representa los tipos de adaptaciones que tendrá en la aplicación (véase sección 6.1.1), junto con la búsqueda de imágenes y pictogramas. Si se 60 Capítulo 6. AdaptaMaterialEscolar pasa el ratón por encima de uno de estos menús saldrá un desplegable con los distintos tipos de actividades, temario y formato que hay, tal y como se puede ver en la Figura 6.11. Figura 6.11: Prototipo del editor con un desplegable en uno de los menús (Jorge) Así mismo, se ven dos elementos separados por un hueco: el elemento de la izquierda representa el fichero subido, y el de la derecha, el editor. Debajo de éste se encuentra un panel con unos botones para poder descargar, guardar y ver el documento editado, así como la posibilidad de poder borrar todo lo escrito en el editor. En el prototipo de Natalia (Figura 6.13), también existe una barra de navegación con los mismos menús, aunque se cambia el logo de AdaptaMaterialEscolar por dichos menús, añadiendo el de Archivo y Formato. También tiene los dos elementos mencionados anteriormente: en la parte de la izquierda el documento subido, y en el de la derecha, el editor. En éste, se encuentra una barra de herramientas con la posibilidad de cambiar el formato de la letra, la posición del texto, y dos botones para descargar y borrar todo, respectivamente. En cambio, en el prototipo de Pablo (Figura 6.14), se observa que la barra de navegación descrita en los prototipos de Jorge y Natalia no está, sino que se encuentra incluida en el propio editor (el elemento que se encuentra en la parte de la izquierda). En esta barra de herramientas se podrá dar formato al texto (ponerle forma de título, párrafo, color, negrita, cursiva, etc), así como deshacer y rehacer lo escrito, crear 6.2. Diseño de la aplicación 61 Figura 6.12: Prototipo de la vista previa (Jorge) Figura 6.13: Prototipo del editor (Natalia) tablas, y unos botones con los distintos tipos de adaptaciones que hay. 62 Capítulo 6. AdaptaMaterialEscolar Figura 6.14: Prototipo del editor (Pablo) 6.2.4. Cuarta iteración: diseño final Una vez hecha la puesta en común de los diseños realizados por cada miembro del equipo se procedió a hacer el diseño final. Este diseño tomaba como base el prototipo de Pablo (Figura 6.14), debido a que estaba todo más limpio y claro visualmente. A este prototipo se añadió una barra de navegación en la parte superior (como las que aparecen en los prototipos de las Figuras 6.10 y 6.13) para los tipos de adaptaciones que habrá en la aplicación. Esta barra de navegación surge porque algunas adaptaciones tienen un estilo de implementación distinto (algunas se podrán hacer sobre el propio editor pero otras abrirán nuevas ventanas para poder realizar la adaptación, sobre todo en las adaptaciones de actividades). Tras realizar este diseño, se envió un email a las profesoras del Aula TEA para que nos dieran feedback sobre él. La respuesta fue positiva: tanto la distribución de los elementos como los colores usados eran adecuados. 6.3. Implementación AdaptaMaterialEscolar es una aplicación web creada con React (explicado en la sección 4.2), cuyo código se puede encontrar en el repositorio del grupo NIL en GitHub6. Es accesible a través de la siguiente url: https://holstein.fdi.ucm.es/tfg/2021/adapta/. 6https://github.com/NILGroup/TFG-AdaptaMaterialEscolar/tree/master/Codigo 6.3. Implementación 63 En la Figura 6.15 se muestra la página principal de la aplicación. En ella se puede ver el header en la parte superior, con el logo de la aplicación en la parte de la izquierda, y los botones de Inicio, Ayuda y Contacto en la parte de la derecha; y en el centro de la página una zona para poder subir un fichero .pdf que servirá como base a las adaptaciones y/o a la creación de ejercicios. Figura 6.15: Página principal de AdaptaMaterialEscolar Cuando el fichero se haya subido, aparecerán dos zonas diferenciadas (ver Figura 6.16): la zona de la izquierda contendrá el documento subido y la zona de la derecha es la zona de edición, donde se irá creando el nuevo documento con las adaptaciones y/o ejercicios. Las funcionalidades implementadas se darán con más detalle en la sección 6.3.2 y son las siguientes: Subir un documento fuente. Permite subir un documento en formato .pdf que podrá servir de texto base para realizar las adaptaciones y/o para la creación de ejercicios. En la Figura 6.15 se puede ver la página de subir un documento fuente. Editor. Permite escribir, modificar las adaptaciones y/o ejercicios ya escritos, cambiar el formato (tipo, tamaño, color de letra, posicionamiento del texto...), etc. En la Figura 6.16 se puede ver el editor y la barra de herramientas que contiene las opciones de formato. Pictogramas. Permite buscar pictogramas a partir de una palabra. La búsqueda devolverá varios pictogramas y haciendo clic en un pictogra- 64 Capítulo 6. AdaptaMaterialEscolar Figura 6.16: Página principal de AdaptaMaterialEscolar tras subir un documento ma éste será llevado al editor. En la Figura 6.17 se puede ver la interfaz del buscador de pictogramas cuando se ha buscado la palabra flor. Figura 6.17: Interfaz de AdaptaMaterialEscolar al seleccionar Pictogramas Completar huecos. Permite crear un ejercicio de completar huecos. Primero habrá que introducir el texto base del ejercicio y posteriormente seleccionar las palabras en las que se quiera dejar el hueco. En la Figura 6.18 se muestra la interfaz la aplicación al seleccionar Completar huecos. Definiciones. Permite crear una lista de conceptos a definir en un número máximo de líneas. Incluye una opción para añadir espaciado extra 6.3. Implementación 65 Figura 6.18: Interfaz de AdaptaMaterialEscolar al seleccionar Completar huecos entre líneas para estudiantes que tengan una letra más grande. En la Figura 6.19 se puede ver la interfaz de la aplicación cuando se ha seleccionado Definiciones. Figura 6.19: Interfaz de AdaptaMaterialEscolar al seleccionar Definiciones Desarrollo. Permite crear un ejercicio de desarrollo insertando el enunciado y el número de líneas máximo para responder. También tiene una opción para añadir espaciado extra entre líneas para estudiantes que tengan una letra más grande. En la Figura 6.20 se puede ver la interfaz de la aplicación cuando se ha seleccionado Desarrollo. Sopa de letras. Permite crear una sopa de letras estableciendo el número 72 Capítulo 6. AdaptaMaterialEscolar actualizará los datos en base a ella. Los selectores detectarán el cambio y actualizarán las vistas. Redux lo hemos usado en el proyecto para reducir la interacción entre los distintos componentes de la aplicación, simplificando así la complejidad y facilitando el mantenimiento y depuración. 6.3.2. Funcionalidades En esta sección se explicarán con detalle la implementación de cada una de las funcionalidades. 6.3.2.1. Subir un documento fuente En la Figura 6.15 se puede ver el aspecto de AdaptaMaterialEscolar cuando se tiene que subir un documento fuente. El documento a subir debe ser en formato .pdf. En el caso de que no se suba en dicho formato, el fichero no se renderizará correctamente. Una vez que se ha seleccionado el fichero .pdf, para que se cargue en la aplicación, ocurre lo siguiente (en la Figura 6.26 se muestra el diagrama de secuencia de esta funcionalidad): 1. La función uploadFile() hace una llamada al despachador pasándole como parámetro loadDocument(document), donde document es el objeto que contiene el documento a subir. 2. El despachador buscará en Actions el tipo de acción que es (en este caso, LOAD_FILE), junto con su payload (el documento a subir) y lo devolverá. Posteriormente, llamará al reductor a través de documentReducer() pasándole como parámetros el estado (state) del componente y la acción devuelta anteriormente. A continuación, buscará en el switch el tipo de acción y procederá a modificar el estado del componente, actualizando los campos fileL (el documento subido) y fileIsLoaded (indica si hay un documento cargado, y sirve para cambiar entre las páginas de subir un documento si su valor es false, y del editor, si su valor es true). Tras actualizarlos, devolverá el estado modificado. 3. Por último, tras realizar este proceso, el documento se habrá cargado en la aplicación, como se puede ver en la Figura 6.16. El texto del 6.3. Implementación 73 fichero subido se podrá usar de base y se podrá utilizar el editor para realizar adaptaciones de temario y crear ejercicios. Figura 6.26: Diagrama de secuencia de subir un documento En la Figura 6.27 se puede ver un diagrama con el flujo de acción, reductor, etc. concretos para esta función. Figura 6.27: Diagrama de flujo de subir un documento 74 Capítulo 6. AdaptaMaterialEscolar 6.3.2.2. Editor El editor de texto que hemos usado es CKEditor 5 (ver sección 4.5). En la Figura 6.16 se puede ver, en la parte de la derecha, el editor. Para añadir funcionalidad al éste, se necesitan incluir plugins9. Estos plugins pueden ser del propio editor o creados por un usuario y la mayoría tienen configuración personalizable. El editor consta de dos partes: la barra de herramientas y la zona de escritura. La barra de herramientas consta de los siguientes elementos: Exportar a PDF: permite exportar a un documento .pdf el contenido del editor. Es posible gracias al plugin ExportPdf. Deshacer y rehacer: permite deshacer/rehacer la última acción realizada en el editor. Es posible gracias al plugin Essentials. Estilos de párrafo: permite cambiar el estilo del párrafo. Es posible gracias al plugin Heading. Se pueden definir nuevos estilos y añadirlos a la configuración del plugin. Fuente de la letra: permite cambiar la fuente de la letra. Es posible gracias al plugin FontFamily. Cada familia de fuente de texto que se quiera incluir debe ser añadida a las opciones de configuración del plugin. Tamaño de la letra: permite cambiar el tamaño de la letra. Es posible gracias al plugin FontSize. Se pueden definir tamaños de letra personalizados añadiéndolos a las opciones de configuración del plugin. Color de la letra: permite cambiar el color de la letra. Es posible gracias al plugin FontColor. Se pueden definir colores personalizados y añadirlos a las opciones de configuración del plugin, así como el número de columnas a mostrar. Color de resaltado: permite resaltar una palabra con un color. Es posible gracias al plugin FontBackgroundColor. Se pueden definir colores personalizados y añadirlos a las opciones de configuración del plugin, así como el número de columnas a mostrar. Negrita, cursiva y subrayado: permite cambiar el formato de texto a negrita, cursiva y/o subrayado gracias a los plugins Bold, Italic yUnderline, respectivamente. 9https://ckeditor.com/docs/ckeditor5/latest/builds/guides/development/plu gins.html 6.3. Implementación 75 Alineamiento del texto: permite alinear el texto a la izquierda, centrarlo, alinearlo a la derecha o justificarlo. Es posible gracias al plugin Alignment. Sangría: permite disminuir o aumentar la sangría de un párrafo. Es posible gracias al plugin Indent eIndentBlock. Listas: permite crear listas no numeradas, listas numeradas y listas de tareas. Es posible gracias a los plugins ListStyle, para las listas numeradas y no numeradas, y TodoList para las listas de tareas. Cita en bloque: permite insertar citas en bloque. Es posible gracias al plugin BlockQuote. Tablas: permite insertar tablas y modificar el diseño de las mismas (mezclar celdas, añadir o eliminar filas y columnas, cambiar de color la tabla y celdas, etc.). Es posible gracias a los plugins Table, TableToolbar, TableProperties yTableCellProperties. Imágenes: permite insertar imágenes a través de una URL y redimensionarlas. Es posible gracias a los plugins Image, ImageInsert, ImageToolbar, ImageStyle eImageResize. El editor está configurado por defecto con la fuente de letra Arial, un tamaño de letra de 16px y el texto alineado a la izquierda, siguiendo las recomendaciones de Lectura Fácil ya comentadas en la sección 3.1.1. Para que un ejercicio se pueda escribir en el editor, es necesario crear el plugin del ejercicio correspondiente. Éste debe tener dos ficheros: insertComponenteCommand, el fichero que contiene la ejecución del comando, y componentePlugin, el fichero que contiene la creación del comando y su adición a la lista de comandos del editor. En el primer fichero se debe definir la función execute(), cuyo parámetro son los datos que se necesiten para visualizar el ejercicio (puede ser un objeto, una sola variable, etc.). En el segundo fichero se debe definir el comando de inserción y añadirlo a la lista de comandos del editor. En el siguiente fragmento de código se muestra un ejemplo del fichero plugin del ejercicio de completar huecos, donde se define el comando y se añade a la lista de comandos del editor. init () { this. editor . commands . add (’insertFillGaps’,new InsertFillGapsCommand(this. editor )); } Listing 6.7: Ejemplo del fichero plugin del ejercicio de completar huecos donde se define y añade el comando 76 Capítulo 6. AdaptaMaterialEscolar En el siguiente fragmento de código se muestra un ejemplo de la función execute() del fichero inserción del comando del ejercicio de completar huecos. execute ( data ){ this. editor . model . change ( writer => { let text = ""; data .text . forEach (t = >{ text += t + " "; }) let insertPosition = this. editor . model . document . selection . getFirstPosition (); const enunciado = writer . createElement ( ’paragraph ’, insertPosition); writer . insertText ( text , enunciado ); this. editor . model . insertContent ( enunciado ); if( data . addHowToSolve ){ const howTo = writer . createElement (’ paragraph ’); writer . insertText (" Cómo resolver el ejercicio : ... ", howTo, " end "); } this. editor . execute (" shiftEnter "); }); } Listing 6.8: Ejemplo del fichero inserción del comando del ejercicio de completar huecos donde se define la función execute() La Figura 6.28 muestra un diagrama de secuencia de cómo se inicializa el editor y cómo se ejecuta la función execute() al ser llamado por un componente cualquiera. Para ello, hay dos fases a ejecutar. En la primera fase se inicializa el editor y nos centraremos en la inicialización de cada plugin y comando: 1. Cuando se crea el editor se llama a la función create() pasándole como parámetros sourceElementOrData, el componente HTML donde estará montado el editor; y config, el objeto de configuración del editor en el que se encuentra el idioma del editor, los plugins y algunas configuraciones de éstos. Dentro de esta función, se crea el editor haciendo un new this() y pasándole como parámetros los mismos que en el create, y asignará este editor a una variable. Posteriormente, se llama a la función initPlugins() del editor, pasándole como parámetro los plugins del objeto config. 2. La llamada a initPlugins() iterará sobre cada plugin que haya en plugins. Para ello, se hace una llamada a init() pasándole como parámetros los plugins. 3. La llamada a init() se ejecuta en la clase PluginsCollection, una clase 6.3. Implementación 77 de CKEditor 5 para gestionar los plugins. A continuación se ejecuta un bucle forEach en el que, para cada plugin de plugins, se hará una llamada a init(). Esta llamada a init() la tiene cada clase ComponentePlugin obligatoriamente. 4. La función init() de cada clase ComponentePlugin insertará, en la lista de comandos del editor, el comando correspondiente a esa clase. Se hace una llamada a add() pasándole como parámetros el nombre del comando y un objeto de la clase InsertComponentCommand() donde se encuentra la función execute(). La llamada a new InsertComponentCommand() necesita como parámetro el editor. 5. Una vez hecho todo este proceso, devolverá el editor inicializado. Hay que tener en cuenta que en todo este proceso se llaman a más funciones y se asignan más variables, ya que lo hace internamente y no son funciones que nosotros hayamos creado. En la segunda fase nos centraremos en la ejecución de la función execute() de un componente cualquiera: 1. Un componente hace una llamada a la función execute() del editor pasándole como parámetros el nombre del comando “insertComponente” y el objeto con los datos necesarios para la visualización del componente en el editor, options. 2. La función execute() del editor ejecuta un bloque try-catch: a) Try: se hace una llamada a execute() de la clase CommandCollection, una clase de CKEditor para gestionar los comandos, pasándole como parámetros el nombre del comando y el objeto de datos. Si todo va bien, se obtendrá el comando y se llamará a la función execute() de la clase InsertComponentCommand pasándole como parámetro el objeto de datos. En el caso de que el comando no exista se lanzará una excepción. b) Catch: si ha habido alguna excepción y no se ha conseguido ejecutar el comando, se capturará la excepción y se relanzará otra excepción llamando a la función rethrowUnexpectedError() pasándole como argumentos el error y el editor. 3. Si todo ha ido bien, se visualizará en el editor el componente. 78 Capítulo 6. AdaptaMaterialEscolar Figura 6.28: Diagrama de secuencia del proceso de inicialización del editor y la ejecución de la función execute() 6.3.2.3. Buscador de pictogramas La Figura 6.17 muestra la apariencia de la aplicación cuando se selecciona el buscador de pictogramas. En él, se muestra un único input donde se introduce el texto a buscar. La aplicación reaccionará automáticamente y mostrará los resultados conforme se vaya actualizando el texto a buscar. En la Figura 6.29 se puede ver cómo se muestran los resultados una vez se ha introducido un texto de búsqueda. Una vez se ha introducido el texto, se selecciona el pictograma deseado y se hace clic sobre él para insertarlo donde esté el cursor en el editor. La Figura 6.30 contiene el aspecto del editor una vez se ha introducido un pictograma. 6.3. Implementación 79 Figura 6.29: Resultados del buscador de pictogramas Figura 6.30: Pictograma introducido en el editor Las Figuras 6.31 y 6.32 muestran el diagrama de clase y secuencia asociados a este caso de uso. Internamente, este módulo contiene tres valores: searchResults, inputText y errorText. El inputText contiene el texto del formulario de búsqueda. Cada vez que se actualice la vista PictogramSearchModal se ejecutará una acción FetchPictogramsAction, la cual realizará la llamada a la API externa de ARASAAC y obtendrá los pictogramas. Como esta acción ejecuta una llamada a una API externa, tiene un carácter asíncrono y actúa como middleware entre acciones. En la acción se ejecutará un fetch a la url de ARASAAC. Si todo va bien se obtendrán los datos y se ejecutará otra acción llamada FetchPictogramsSuccess que actualizará el Store con los datos obtenidos y automáticamente actualizará la interfaz con los resultados. Si se ha producido cualquier error de conexión se ejecutará 80 Capítulo 6. AdaptaMaterialEscolar una acción llamada FetchPictogramsFailure donde se almacenará el error y se comunicará en la vista. Figura 6.31: Diagrama de clases del buscador de pictogramas Figura 6.32: Diagrama de secuencia del buscador de pictogramas 6.3.2.4. Sopa de letras En la Figura 6.21 se puede ver el aspecto de la aplicación al seleccionar sopa de letras. La creación del ejercicio de sopa de letras solicita los siguientes parámetros: 6.3. Implementación 81 Filas: El número de filas que tendrá la sopa de letras. Columnas: El número de columnas que tendrá la sopa de letras. Palabras: Las palabras que se insertarán en la sopa de letras. Dirección: Las direcciones en las que se quiere insertar la palabra (vertical, horizontal y/o diagonal). Como mínimo se debe activar una dirección para poder generar la sopa de letras. Palabras máximas: El número de palabras máximas que se insertarán en la sopa de letras. Activar escritura al revés: Activa la probabilidad de escribir cada palabra al revés. En el caso de que esta opción no se active, la probabilidad será cero. Si se activa, aparecerá una barra deslizante para establecer dicha probabilidad. Los parámetros obligatorios para poder generar la sopa de letras son las filas, las columnas, las palabras y la/s dirección/es. Así mismo, existe otra opción de carácter opcional y es la posibilidad de mostrar en el editor las palabras a buscar junto al enunciado. Figura 6.33: Vista previa de la sopa de letras Una vez que se han rellenado los campos obligatorios se activarán los botones de Vista previa y Aceptar. El botón Vista previa genera primero la sopa de letras y la muestra al usuario antes de escribirla en el editor (en la Figura 6.33 se muestra la vista previa de la sopa de letras generada). En cambio, el botón Aceptar genera la sopa de letras y la escribe directamente en el editor, sin mostrarla antes al usuario. En ambos casos, si ocurre algún 88 Capítulo 6. AdaptaMaterialEscolar Figura 6.40: Resultado del ejercicio de definiciones 1. Se llama al despachador pasándole como parámetro updateDevelopText(e.target.value), donde e.target.value es el valor del campo del input que lo ha llamado (el enunciado modificado). 2. El despachador buscará en Actions el tipo de acción que es (UPDATE_DEVELOP_TEXT) junto con su payload (el enunciado modificado). Posteriormente llamará al reductor a través de developReducer() pasándole como parámetros el estado (state) del componente y la acción devuelta anteriormente. A continuación buscará en el switch el tipo de acción y procederá a actualizar el estado del componente, concretamente la variable text, un string donde se almacena el enunciado. Tras actualizarlo, devolverá el estado modificado. 3. Por último, tras realizar este proceso, se actualizará la interfaz con el nuevo estado devuelto por el reductor. Una vez que se han rellenado los campos obligatorios, el botón Aceptar se habilitará. Al hacer clic en él se procederá a escribir, en el editor, el enunciado del ejercicio y en los siguientes renglones el número de líneas especificado por el usuario. Para ello, se llama a la función execute() del editor, pasándole como parámetros el nombre del comando (insertDevelop), y el objeto de datos con el enunciado, el número de líneas y las opciones para añadir espacio extra entre líneas y para añadir un ejemplo de cómo resolver el ejercicio. En la Figura 6.44 se muestra el resultado de este ejercicio. En la parte superior se muestra dicho resultado usando las opciones de la Figura 6.43. En la parte inferior, el mismo ejercicio pero quitando la opción de añadir el ejemplo de cómo resolver el ejercicio, y añadiendo espacio extra entre líneas. 6.3. Implementación 89 Figura 6.41: Diagrama de flujo cuando se modifica el enunciado del ejercicio pregunta para desarrollar Figura 6.42: Diagrama de secuencia cuando se modifica el enunciado del ejercicio pregunta para desarrollar 6.3.2.7. Verdadero o Falso Al seleccionar esta opción en nuestra aplicación, se muestra la interfaz de la Figura 6.22. Para crear un ejercicio de verdadero y falso se necesitan rellenar los siguientes campos: Frases: Contendrá las frases del ejercicio. Hay que escribir una frase en cada input de texto. Para añadir más inputs, se puede pulsar la tecla Enter dentro de uno de los inputs, o pulsar el botón “más”. Para quitarlos, se tendrá que hacer clic en el “menos”. Ambos botones se 90 Capítulo 6. AdaptaMaterialEscolar Figura 6.43: Ejemplo de opciones del ejercicio pregunta para desarrollar Figura 6.44: Resultado de ejercicio pregunta para desarrollar encuentran ubicados en la derecha de cada input. La forma en la que se muestran las frases: puede ser como una lista no ordenada o una lista ordenada. Por defecto está seleccionada la lista no ordenada. En la Figura 6.45 se muestra un diagrama con el flujo de acción, reductor, etc., cuando se añaden más inputs y en la Figura 6.46, un diagrama de secuencia de la misma funcionalidad. Tal y como se puede ver en el diagrama de secuencia ocurre lo siguiente: 1. Se llama al despachador pasándole como parámetro addMoreTrueFal- 6.3. Implementación 91 se(). 2. El despachador buscará en Actions el tipo de acción que es (en este caso, ADD_MORE_TRUEFALSE). Posteriormente llamará al reductor a través de trueFalseReducer() pasándole como parámetros el estado (state) del componente y la acción devuelta anteriormente. A continuación buscará en el switch el tipo de acción y procederá a actualizar el estado del componente, concretamente la variable text, un array que almacena cada frase de verdadero o falso. Esta actualización añade al final del array una cadena de texto vacía. Tras actualizarlo, devolverá el estado modificado. 3. Por último, tras realizar este proceso, se actualizará la interfaz con el nuevo estado devuelto por el reductor, en el que se mostrará otro input para escribir otra frase de verdadero o falso, junto con los botones de añadir más filas y quitar fila. Figura 6.45: Diagrama de flujo cuando añaden más filas al ejercicio de verdadero o falso Una vez que se han rellenado los campos obligatorios mencionados anteriormente, el botón Aceptar se habilitará. Al hacer clic en él se procederá a escribir en el editor cada frase, seguido de un recuadro para escribir V si es verdadero o F si es falso. Para ello, se llama a la función execute() del editor, pasándole como parámetros el nombre del comando (insertTrueFalse) y un objeto de datos con la lista de oraciones, el tipo de lista y la opción para añadir un ejemplo de cómo resolver el ejercicio. En la Figura 6.48 se muestra el resultado del ejercicio usando las opciones de la Figura 6.47. 92 Capítulo 6. AdaptaMaterialEscolar Figura 6.46: Diagrama de secuencia cuando añaden más filas al ejercicio de verdadero o falso Figura 6.47: Ejemplo de opciones del ejercicio verdadero o falso 6.3.2.8. Completar huecos El ejercicio de completar huecos tiene como finalidad escribir las palabras faltantes en los espacios en los que haya una línea. Al seleccionar esta opción en nuestra aplicación se muestra la interfaz de la Figura 6.18. Este ejercicio consta de dos fases: En la primera fase hay que insertar el texto del que se quiera quitar palabras. Una vez que se ha insertado, el botón Seleccionar palabras se habilitará. El texto se puede seleccionar y copiar del documento fuente y pegarlo en el textarea. En la Figura 6.49 se muestra un ejemplo de la 6.3. Implementación 93 Figura 6.48: Resultado de ejercicio verdadero o falso interfaz de edición en la que se debe insertar el texto, y en el que una vez insertado, el botón Seleccionar palabras se habilitará. Figura 6.49: Ejemplo de edición del texto del ejercicio completar huecos La segunda fase se alcanza cuando se hace clic en el botón de Seleccionar palabras. Para quitar una palabra basta con hacer clic en ella. Si se quiere volver a ver la palabra, hay que volver a hacer clic en ella. Para volver a editar el texto (volver a la fase uno), simplemente hay que hacer clic en el botón Editar texto. En la Figura 6.50 se puede ver la interfaz de selección de las palabras. En ésta, se han seleccionado las palabras vivos, animales, plantas y orgánicas. En la Figura 6.51 se muestra un diagrama de secuencia cuando se hace 94 Capítulo 6. AdaptaMaterialEscolar Figura 6.50: Ejemplo de selección de palabras del ejercicio completar huecos clic en el botón Seleccionar palabras. Tal y como se puede ver en el diagrama de secuencia ocurre lo siguiente: 1. Se hace una llamada a la función changeToSelection(). Esta función consta de dos partes: a) Se hace una llamada al despachador pasándole como parámetro updateMode(mode), donde mode puede ser o edition oselection. En este caso es selection. El despachador buscará en Actions el tipo de acción que es (UPDATE_FILLGAPS_MODE), junto con su payload. Después llamará al reductor a través de fillGapsReducer() pasándole como parámetros el estado (state) del componente y la acción devuelta anteriormente, buscará el tipo de acción en el switch y actualizará el modo a selection. Después devolverá el estado actualizado. b) Se hace una llamada al despachador pasándole como parámetro updateTextSelection(). El despachador buscará en Actions el tipo de acción que es (UPDATE_FILLGAPS_TEXTSELECTION). Posteriormente llamará al reductor a través de fillGapsReducer() pasándole como parámetros el estado (state) del componente y la acción devuelta anteriormente, buscará el tipo de acción en el switch y actualizará la variable textSelection. Esta variable contiene las palabras del texto separadas por espacios. Después devolverá el estado actualizado. Una vez finalizado este proceso, se cambiará a la interfaz de selección de palabras (Figura 6.50). 2. Al seleccionar una palabra se llama a la función handleOnClick(e,i) pasándole como parámetros el evento que lo ha llamado (e) y la po- 6.3. Implementación 95 Figura 6.51: Diagrama de secuencia cuando se hace clic sobre Seleccionar palabras en el ejercicio completar huecos sición en el array de textSelection (i). En la Figura 6.53 se muestra un diagrama de secuencia cuando se hace clic en una palabra, y en la Figura 6.52, un diagrama de flujo de esta funcionalidad. Al seleccionar una palabra pueden ocurrir dos situaciones: Figura 6.52: Diagrama de flujo al seleccionar una palabra del ejercicio completar huecos a) Si la palabra comienza con una guión bajo, se llama al despachador pasándole como parámetro updateDeleteSelectedWord(i), 96 Capítulo 6. AdaptaMaterialEscolar Figura 6.53: Diagrama de secuencia cuando se hace clic en una palabra en el ejercicio completar huecos donde ies la posición de la palabra en el array textSelection. El despachador buscará en Actions el tipo de acción que es (UPDATE_FILLGAPS_DELETESELECTED) junto con su payload (i). Posteriormente se llamará al reductor a través de fillGapsReducer() pasándole como parámetros el estado (state) del componente y la acción, buscará el tipo de acción en el switch y procederá a actualizar dos variables: textSelection, donde se recupera la palabra que se ha ocultado, y wordSelected, donde se busca el índice de la palabra que se ha ocultado en el array wordsSelected, y se elimina la palabra de éste. Después devolverá el estado modificado. b) Si la palabra no comienza con guión bajo, se llama al despachador pasándole como parámetro updateAddSelectedWord(textContent, i), donde textContent es la palabra e ies la posición en el array textContent. El despachador buscará en Actions el tipo de acción que es (UPDATE_FILLGAPS_ADDSELECTED) junto con su payload (i). Posteriormente se llamará al reductor a través de fill- 6.3. Implementación 97 GapsReducer() pasándole como parámetros el estado (state) del componente y la acción, buscará el tipo de acción en el switch y procederá a actualizar dos variables: textSelection, donde se sustituye la palabra por guiones bajos, y wordsSelected, donde se añade un objeto con la palabra y la posición en el array textSelection para poder recuperarla después. Por último devolverá el estado modificado. Una vez que se ha seleccionado al menos una palabra, el botón Aceptar se habilitará. Al hacer clic en éste se escribirá el texto modificado en el editor. Para ello, se llamará a la función execute() del editor, pasándole como parámetros el nombre del comando (insertFillGaps) y el objeto de datos con el texto modificado, las palabras escondidas y la opción para añadir un ejemplo de cómo resolver el ejercicio. En la Figura 6.54 se ve el resultado del ejercicio al usar las opciones de las Figuras 6.49 y 6.50. Figura 6.54: Resultado del ejercicio de completar huecos 6.3.3. Estructura del código La organización de directorios del proyecto gira en torno al patrón de diseño Redux. El código de la funcionalidad de la aplicación se estructura principalmente en cuatro carpetas: components, pages, ckeditor y redux. Además, contamos con el fichero App, que supone el punto de inicio del programa. El contenido de cada carpeta es el siguiente: Components: Representado en la Figura 6.55, contiene cada componente que representa una funcionalidad para la aplicación, o parte de 104 Capítulo 7. Evaluación de AdaptaMaterialEscolar •¿Te gustaría que la aplicación siguiera en desarrollo para mejorarla? •¿Qué mejorarías en la aplicación? (Pregunta no obligatoria). En las preguntas donde se debía establecer como respuesta una puntuación utilizamos una escala Likert de 5 puntos, donde las puntuaciones iban del 1 al 5, significando la valoración más baja que el usuario está “Muy en desacuerdo” con la afirmación de la pregunta y, en la más alta, “Muy de acuerdo”. Todos los apartados de la encuesta, a excepción del de usabilidad, fueron planificados por nosotros específicamente para obtener información que considerábamos relevante para el proyecto. El cuestionario se encuentra en la dirección web: https://docs.googl e.com/forms/d/e/1FAIpQLSfZKu_D1C2T3UMi7gQf1qzV7Ne0MbsNigVGhcOk aZ5xez7COw/viewform?usp=sf_link 7.3. Desarrollo de la evaluación El viernes 28 de mayo planificamos una reunión presencial en el IES Maestro Juan de Ávila, de Ciudad Real, con las profesoras del Aula TEA, quienes han colaborado con nosotros durante todo el proyecto. Una vez allí, la orientadora del centro, María José Morales Rubio, se unió a la demostración que realizamos por su propia iniciativa e interés en nuestro proyecto. Realizamos una prueba de aproximadamente una hora de duración, en la que se les mostró cómo utilizar AdaptaMaterialEscolar y replicamos con ellas el examen que habíamos preparado. Ese mismo día se realizó la misma demostración de la aplicación, también de forma presencial, con otra profesora del mismo instituto, Esther Valiente Moreno, que imparte las asignaturas de Emprendimiento Empresarial y Economía en el centro y cuenta con un alumno TEA en una de las clases. Por falta de tiempo no se pudo mostrar el proyecto a más profesores ni se recogieron más evaluaciones, aunque contactaron con nosotros tres docentes más que se habían interesado en AdaptaMaterialEscolar y tenían intención de aprender a utilizarlo para el curso siguiente. Uno de ellos imparte Biología y los otros dos, Historia y Geografía. El día 1 de junio, la Jefa de Estudios y profesora del IES Pedro Álvarez de Sotomayor, de Manzanares, María de las Cruces Valiente Moreno, que imparte la asignatura de Tecnología Industrial, también contactó con 7.4. Resultado de la evaluación 105 nosotros para conocer el proyecto, debido a que se interesó por los comentarios que le llegaron del IES Maestro Juan de Ávila. Nos comentó que en su centro había un alumno con sordera total a quien debían adaptar el material y organizamos una reunión por videollamada para realizar la misma demostración que al resto de profesores, para mostrarle el funcionamiento de AdaptaMaterialEscolar. Durante las reuniones con todos los profesores de los distintos centros educativos, surgieron requisitos nuevos que se pretenden plantear como trabajo futuro en caso de que AdaptaMaterialEscolar pudiera seguir en desarrollo en los próximos años. Incluso se nos llegó a ofrecer la oportunidad de realizar un curso de formación a nuevos profesores y alumnos de máster el curso que viene, en el IES Maestro Juan de Ávila, para presentarlo como herramienta de adaptabilidad para el profesorado, independientemente de si llegábamos a cumplir con los nuevos requisitos o si manteníamos el proyecto tal y como lo vieron. 7.4. Resultado de la evaluación Finalmente, el número de usuarios finales que participaron en la evaluación de la aplicación web y contestaron la encuesta fueron 5, todas mujeres y docentes de Educación Secundaria y/o Bachillerato, aunque de haber dispuesto de más tiempo habríamos llegado a tener 9 en total, por el interés de otros profesores. Los centros de estudios participantes fueron el IES Maestro Juan de Ávila, de Ciudad Real, y el IES Pedro Álvarez de Sotomayor, de Manzanares. El resultado a las preguntas de usabilidad del SUS fue realmente positivo, ya que obtuvimos una puntuación final de 99, siendo 100 la máxima puntuación, por lo que se puede concluir que el sistema es fácilmente manejable por los usuarios con una formación mínima. La gráfica con la media de las puntuaciones de cada pregunta se puede ver en la Figura 7.1 y los cálculos del resultado en la Tabla 7.1. Pregunta 1 5−1 = 4 Pregunta 2 5−1,2 = 3,8 Pregunta 3 5−1 = 4 Pregunta 4 5−1 = 4 Pregunta 5 5−1 = 4 Pregunta 6 5−1 = 4 Pregunta 7 5−1 = 4 106 Capítulo 7. Evaluación de AdaptaMaterialEscolar Tabla 7.1 continuada de la página anterior Pregunta 8 5−1=4 Pregunta 9 4,8−1=3,8 Pregunta 10 5−1=4 Resultado ((4 ·8) + (3,8·2) ·2,5) = 99 Tabla 7.1: Cálculo del resultado del cuestionario de SUS Figura 7.1: Gráfica de resultados de la Escala de Usabilidad de un Sistema En cuanto a las preguntas sobre Diseño, Funcionalidades individuales y Utilidad real de la aplicación, los resultados fueron muy positivos. El diseño de la aplicación se consideró adecuado y únicamente se sugirió dar colores diferentes a cada una de las pestañas de las funcionalidades, para diferenciarlas mejor. En cuanto a las funcionalidades, la consideración fue, en general, que resultaban fáciles de comprender y utilizar, aunque el tamaño de los pictogramas era algo pequeño y se prefería que pudiera aumentarse. Sobre la utilidad real del proyecto, todas las respuestas apuntaron a que el proyecto era muy útil para el profesorado y expresaron su interés en que siguiera en desarrollo en el futuro. El resultado de la media de cada pregunta en cada apartado se puede consultar en la Figura 7.2. 7.4. Resultado de la evaluación 107 Figura 7.2: Gráfica de resultados de Diseño, Funcionalidades y Utilidad real Además de reiterar la necesidad de continuar desarrollando los requisitos de la captación inicial, se recopilaron entre las reuniones y en la encuesta nuevas funcionalidades para asignaturas que no se tuvieron en cuenta al principio, y mejoras adicionales para AdaptaMaterialEscolar. Los requisitos fueron los siguientes: Añadir una herramienta de pictotraductor como funcionalidad, para traducir de pictogramas a lenguaje natural y viceversa. Añadir cuadrícula para ejercicios de matemáticas, para que los alumnos puedan escribir los números en ella. Añadir la alternativa de añadir doble pauta, en vez de renglones de una única línea, para determinar el tamaño de la letra del alumno. Crear una herramienta de recorte de imágenes para el texto original. Añadir encabezado al texto con, al menos, nombre del centro educativo, nombre del alumno y asignatura. Añadir ejercicios con espacio para dibujar. 108 Capítulo 7. Evaluación de AdaptaMaterialEscolar Añadir ejercicios para ejercicios de cálculo con fórmulas con huecos a rellenar por el alumno. Enumerar ejercicios de forma automática. Añadir doble pauta en lugar de renglones sencillos, para delimitar el tamaño de la letra del alumno. Añadir algún tipo de fuente de letra escolar. 7.5. Conclusión de la evaluación Con respecto a la evaluación de la aplicación web AdaptaMaterialEscolar, podemos determinar que la acogida por parte de los usuarios finales fue mejor de la esperada y que se ha conseguido desarrollar una herramienta para docentes que tiene una utilidad real que cumple con sus necesidades en el momento de facilitar la adaptación de material escolar. La usabilidad del sistema, con una puntuación de 99 sobre 100, y la estética de la aplicación, con una puntuación de 4,6 sobre 5, requieren poca mejora futura, aunque siempre se podrá perfeccionar si se continua colaborando con nuevos usuarios. La conclusión que podemos sacar después de haber realizado la evaluación es que el proyecto ha sido un acierto y hay una necesidad real de que se continúe desarrollándolo y mejorándolo, para así cubrir el amplio espectro de peticiones de los docentes y las diversas asignaturas de los centros académicos que podrían beneficiarse del uso de la aplicación. Aún así, aunque el proyecto generó interés en el profesorado del esperados, el número de evaluaciones que obtuvimos fue muy reducido, por lo que para conseguir una conclusión más significativa se debería contactar con más docentes, para recoger también sus evaluaciones y propuestas de mejora futura para la aplicación. Capítulo 8 Conclusiones y Trabajo futuro Resumen: En este capítulo se abordarán, en la sección 8.1 las conclusiones de este proyecto, y en la sección 8.2, las posibles modificaciones y mejoras que podrían llevarse a cabo durante los próximos años en la aplicación de AdaptaMaterialEscolar. 8.1. Conclusiones Actualmente existen carencias en cuanto a la existencia de herramientas de código abierto pensadas para ser utilizadas por el profesorado y facilitar su labor docente durante la adaptación de temario, actividades y exámenes, para aquellos alumnos que necesiten una adaptación curricular a lo largo de su etapa académica. Además, es aún más complicado encontrar aplicaciones que personalicen y sigan un estándar apropiado para los estudiantes con dificultades de aprendizaje. El objetivo principal de este proyecto era desarrollar una aplicación web que permitiera a los docentes adaptar recursos de las asignaturas de una forma fácil, sencilla y rápida, y crear material personalizado que se ajuste a las necesidades de cada estudiante. Tras ver los problemas que presentaban algunos usuarios finales, fuimos capaces de identificar un problema real y pudimos desarrollar una solución eficiente para esos usuarios. Por un lado integramos un editor de texto de código abierto, CKEditor, con el que cumplíamos con la mayoría de los requisitos de formato que nos pedían, tales como tamaño de la letra, color de la letra, subrayados, etc.; y por el otro, implementamos la mayor parte de los ejercicios y herramientas propuestos 109 110 Capítulo 8. Conclusiones y Trabajo futuro que se habían calificado como prioritarios, como el buscador de pictogramas, ejercicios de verdadero/falso, ejercicio de sopa de letras, ejercicio de completar huecos, ejercicio de pregunta para desarrollar y ejercicio de definir un concepto. Gracias también a CKEditor, todo el documento adaptado se podía descargar en formato .pdf. Así mismo, la aplicación ha seguido un Diseño Centrado en el Usuario (DCU), enseñando a los usuarios finales el diseño del mismo, y dándonos feedback para mejorarlo. También participaron en la evaluación los usuarios finales, por lo que pudieron probar la aplicación y así ver la usabilidad y utilidad de la misma. Otro de los objetivos que tenía este proyecto era aplicar los conocimientos adquiridos durante el Grado de Ingeniería del Software. Consideramos que este objetivo también lo hemos cumplido destacando la aplicación de las siguientes asignaturas: Fundamentos de la Programación y Tecnología de la Programación: donde adquirimos los conocimientos básicos necesarios para empezar a programar en C++ y Java respectivamente. Estos conocimientos los hemos adaptado al lenguaje de programación utilizado en el del proyecto, Javascript. Estructura de Datos y Algoritmos y Técnicas algorítmicas en ingeniería del software: donde aprendimos a pensar cómo estructurar y optimizar nuestro código. Esta asignatura nos ha permitido valorar qué estructura de datos es la más adecuada para nuestro proyecto y qué algoritmos son los mejores para tratar con ésta. Ingeniería del Software, Modelado de Software y Gestión de proyectos Software: donde aprendimos distintos patrones de diseño a la hora de desarrollar código y cómo gestionar y trabajar en equipo de forma correcta en un proyecto software. Esto nos permitió saber elegir una metodología de trabajo adecuada a nuestro proyecto, Kanban, y una arquitectura Redux para la implementación de éste. Aplicaciones web: donde adquirimos los conocimientos necesarios sobre HTML, CSS y Javascript para desarrollar páginas web. Esta asignatura ha sido fundamental a la hora de diseñar nuestra web y poder desarrollar su comportamiento dinámico. Ética, legislación y profesión: donde aprendimos, sobre todo, a proteger nuestro código y a cómo usar las licencias y software libre de terceros. Por ello, hemos recurrido a implementar librerías de código abierto en nuestro proyecto, además de decidir que nuestra aplicación sea del mismo tipo. 8.2. Trabajo futuro 111 Durante el desarrollo de la aplicación AdaptaMaterialEscolar hemos adquirido conocimientos nuevos sobre el uso de nuevas tecnologías, como React, muy utilizada actualmente en el mundo laboral. Además, hemos llegado a trabajar con usuarios finales que tenían una necesidad real y hemos conseguido resolverla, incluso llegando a superar sus expectativas. El resultado del proyecto ha tenido una acogida muy positiva por parte de los usuarios finales y se pretende que la aplicación siga en desarrollo durante los próximos años para mejorar su funcionalidad y llegar a un mayor número de docentes, centros educativos o asociaciones que lo pueda necesitar. 8.2. Trabajo futuro Después de todo el proceso de desarrollo del proyecto, a pesar de que se ha cumplido con la mayoría de los requisitos prioritarios capturados, quedan por completar aún algunas de las tareas que se propusieron inicialmente para considerar que AdaptaMaterialEscolar ha sido completado. Aunque actualmente nuestra propuesta de Trabajo de Fin de Grado es apta para ser utilizada por los centros educativos, sigue siendo mejorable y hay bastante trabajo futuro a desarrollar, incluso puede que para varios años. De todos los requisitos iniciales que se obtuvieron, queda pendiente la implementación de los siguientes: Adaptaciones de temario •Generar un resumen a partir de un texto. •Crear esquemas que faciliten la visualización del temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero. •Crear tablas que organicen el temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero. Adaptaciones de actividades y/o exámenes: •Ejercicios de relacionar contenido mediante flechas. •Ejercicios de completar los espacios en blanco en tablas y esquemas. 112 Capítulo 8. Conclusiones y Trabajo futuro Adaptaciones de formato: •Sustituir una palabra por una imagen. •Añadir una leyenda de colores con la categoría de cada tipo de palabra resaltada, para que los alumnos puedan identificar el significado de cada una de las palabras resaltadas en el texto. •Añadir leyenda de colores para el tema de cada asignatura, para que los alumnos las distingan con mayor facilidad. •Estandarizar formato para títulos e índices del temario, generando de forma automática una plantilla del color de la asignatura. •Añadir imágenes buscando una palabra en bases de datos de imágenes libres. También contábamos con que a partir de la evaluación de la aplicación surgirían nuevas ideas y requisitos para realizar mejoras y, de hecho, ha sido tal la aceptación de AdaptaMaterialEscolar que hemos conseguido más de los esperados. Las peticiones y propuestas de mejora de los docentes que han llegado a evaluar el sistema son: Añadir un pictotraductor como funcionalidad. Añadir la alternativa de añadir doble pauta, en vez de renglones de una única línea, para determinar el tamaño de la letra del alumno. Añadir un tipo de fuente escolar. Crear una herramienta de recorte de imágenes para el texto original. Añadir encabezado al texto con, al menos, nombre del centro educativo, nombre del alumno y asignatura. Añadir ejercicios con espacio para dibujar. Añadir ejercicios para ejercicios de cálculo con fórmulas con huecos a rellenar por el alumno. Enumerar ejercicios de forma automática. Exportar el documento a formato Word para hacer modificaciones. Añadir ejercicios de matemáticas con cuadrícula para escribir los números. Añadir ejercicios con fórmulas predefinidas con espacio para que el alumno rellene ciertos datos y realice cálculos. 8.2. Trabajo futuro 113 En caso de que se continuara desarrollando el proyecto, sería necesario volver a reevaluar cada requisito, para establecer de nuevo una tabla de prioridades basándose en la importancia y dificultad de cada tarea. Además, cabe la posibilidad de que incluso se nos invite a colaborar en la formación de nuevo profesorado y alumnos de máster en el IES Maestro Juan de Ávila en los próximos cursos escolares, para enseñarles a utilizar AdaptaMaterialEscolar, de manera que puedan incluirlo como herramienta de trabajo de uso diario en los diferentes departamentos del centro. También sería necesario desarrollar las páginas de Ayuda, con vídeos mostrando cada tipo de funcionalidad a modo de guía, y Contacto de la aplicación web, para ofrecer soporte a cualquier usuario que quiera aprender a utilizarla. Capítulo 10 Trabajo Individual Resumen: En este capítulo se habla del trabajo individual que ha realizado cada miembro del equipo en el proyecto. 10.1. Natalia Una de las tareas que he realizado durante todo el proyecto ha sido la de actuar como punto de comunicación entre nuestro equipo y las profesoras del Aula TEA del IES Maestro Juan de Ávila de Ciudad Real. Contacté con ellas para realizar una entrevista presencial, donde se les pidió colaboración en el proyecto, de forma que pudieran aportar su punto de vista profesional y experiencia trabajando con alumnos con necesidades especiales. Realicé la captación de requisitos inicial del proyecto en base a las necesidades que para las profesoras del Aula TEA aún no estaban cubiertas por ninguna herramienta de trabajo que pudiera facilitar la adaptación de material escolar, aunque tampoco para ningún otro docente de ese centro. Evalué los requisitos que se habían obtenido como resultado de la captación de requisitos de forma individual, según los conocimientos adquiridos durante el grado, y calculé la prioridad final de cada tarea con la puntuación que habían asignado las profesoras y todos los componentes del equipo de desarrollo. Realicé junto con mis compañeros de equipo un diseño para la interfaz gráfica de la aplicación web para conseguir un prototipo inicial, de forma que vimos las diferentes herramientas que podíamos añadir al trabajo para aportar valor, como por ejemplo, un editor de código abierto de tipo WY121 122 Capítulo 10. Trabajo Individual SIWYG1. También realicé un diseño distinto al prototipo inicial del proyecto de forma individual, para que no hubiera influencia entre el equipo y se pudiera debatir luego sobre los cambios que cada uno consideraba importantes, de manera que fuera posible mejorar el diseño inicial añadiendo los cambios que a todos nos habían parecido necesarios y relevantes. Investigué sobre cómo subir un fichero de texto que estuviera almacenado en una ubicación local del ordenador y sobre el editor de texto CKEditor 5, para poder añadirlo al prototipo individual y comprobar la dificultad inicial de implementar los requisitos necesarios para el proyecto. Una vez que se consiguió añadir el editor de texto y escogimos la interfaz definitiva, comencé a desarrollar la adaptación de formato del generador de resúmenes y tres actividades: ejercicio de verdadero o falso, de definiciones y de desarrollo. Cuando tuvimos una versión suficientemente desarrollada de AdaptaMaterialEscolar, me encargué de preparar la evaluación del proyecto y redacté las preguntas que haríamos a los usuarios que probaron el sistema, para poder obtener información real sobre la utilidad de la aplicación y las posibles mejoras que podrían hacerse en un futuro cercano. Contacté de nuevo con los usuarios finales para realizar una reunión presencial en la que pudiera mostrarles el avance del proyecto, cómo se utilizaba la aplicación y darles la opción de que la evaluaran. Por último, realicé más demostraciones de AdaptaMaterialEscolar a otros profesores que se interesaron y analicé los resultados obtenidos después de la reunión presencial con las profesoras. En cuanto a la redacción de la memoria del Trabajo Final de Grado, me encargué del Capítulo 1, con la introducción, motivación y objetivos del proyecto, del Capítulo 6 el apartado 6.1 de Requisitos y el apartado 6.3 de Estructura del código, el Capítulo 7 con la evaluación y el Capítulo 8 con las conclusiones y el trabajo futuro. 1WYSIWYG, acrónimo de What You See Is What You Get (en español, “lo que ves es lo que obtienes”). Es una frase aplicada a los procesadores de texto y otros editores con formato, que permiten escribir un documento mostrando directamente el resultado final, frecuentemente el resultado impreso. https://es.wikipedia.org/wiki/WYSIWYG 10.2. Jorge 123 10.2. Jorge El 4 de diciembre de 2019 el grupo de investigación NIL organizó un workshop en la Facultad con docentes de otros centros y asociaciones, en el que se mostraban herramientas tecnológicas inclusivas que se habían desarrollado o estaban en desarrollo. Presenté, en ese workshop, AdaptaMaterialEscolar, donde expliqué el funcionamiento y finalidad de este proyecto, con ejemplos visuales sobre posibles adaptaciones que podrían llegar a realizarse. Una vez que Natalia consiguió recabar los requisitos junto con las profesoras del Aula TEA, lo primero de todo fue evaluar esos requisitos por ambas partes; las profesoras debían puntuarlos según la importancia que tuviera ese requisito y nosotros lo tuvimos que puntuar por la dificultad de implementación de forma individual y sin influir los unos con los otros. Una vez realizado esto, se hizo la media de dificultad entre los tres integrantes. A continuación, creamos en conjunto un prototipo inicial a través de la herramienta online Moqups, donde surgieron varias vistas de la aplicación, descritas en la sección 6.2.2. Así mismo, diseñé un prototipo individual, al igual que mis compañeros, para poder mejorar ese diseño en conjunto, el cual se puede ver en las figuras 6.7, 6.10, 6.11 y 6.12. Me encargué de gestionar y reorganizar el tablero Kanban, y de que estuviera lo más actualizado posible tras las reuniones con las tutoras. Así mismo, y como la esencia de este proyecto es realizar adaptaciones, investigamos distintos editores de código abierto de tipo “WYSIWYG”1, aunque al final uno de mis compañeros localizó uno que cumplía las características que buscábamos, CKEditor. Una vez implementado este editor por parte de mi compañero Pablo, cada uno de nosotros se encargó de buscar herramientas y librerías que pudieran facilitar la implementación de los requisitos. En mi caso investigué si había algún paquete NPM (Node Package Manager) sobre generación de sopas de letras, y ver si con nuestra tecnología era posible integrarlo. En la aplicación fui el encargado de implementar el ejercicio de generación de sopas de letras y de completar huecos, y ayudé a Natalia con los ejercicios de pregunta para desarrollar, verdadero o falso y definiciones. Posteriormente rediseñé la mayoría de la interfaz de usuario de nuestra aplicación, en concreto, la barra de herramientas de los ejercicios (toolbar) y las ventanas modales de éstos. 124 Capítulo 10. Trabajo Individual También investigué la API de Google Docs para ver si se podía implementar en el proyecto y así poder subir ficheros en formatos que no sean solo .pdf de forma sencilla. Esta funcionalidad no se integró finalmente en la aplicación final. Con respecto a la redacción de la memoria de este proyecto, me encargué de redactar el Capítulo 4 (Herramientas empleadas), Capítulo 5 (Metodología de desarrollo), del Capítulo 6 (AdaptaMaterialEscolar) los apartados 6.2 (Diseño) y del 6.3 (Implementación) el párrafo de introducción, del 6.3.2 (Funcionalidades) los subapartados 6.3.2.1 (Subir un documento fuente), 6.3.2.2 (Editor), 6.3.2.4 (Sopa de letras), 6.3.2.5 (Definiciones), 6.3.2.6 (Pregunta para desarrollar), 6.3.2.7 (Verdadero o falso) y 6.3.2.8 (Completar huecos) y del Capítulo 8 el apartado 8.2 junto con Natalia. 10.3. Pablo Aporté mi puntuación de 1 a 3 de dificultad a los requisitos propuestos por las profesoras. Una vez decidido que el proyecto iba a ser web, había que decidir qué tecnologías FrontEnd usar. Por ello propuse usar React en el proyecto dada su comodidad, sencillez y adecuación para el proyecto. Además, mi previa experiencia usándolo serviría de ayuda para mis compañeros. La propuesta fue aceptada e implementada. Investigué sobre librerías aptas para poder integrar un editor WYSIWYG1 en la web. Finalmente propuse CKEditor por su gran cantidad de funciones, soporte y personalización, y fue aceptado por el equipo. Exploré la documentación de CKEditor en profundidad, procurando encontrar qué funcionalidades del framework eran útiles y necesarias para nuestro proyecto. Posteriormente, realicé un prototipo web usando las tecnologías y librerías web propuestas. Este prototipo estaba realizado con React y CKEditor y mostraba un editor de texto que contenía un buscador de pictogramas integrado. De esta manera podía comprobar la viabilidad del proyecto con las tecnologías propuestas y servir como referencia en la estructura y avance del proyecto. Además, facilitaría el aprendizaje de su uso a mis compañeros. Este prototipo conllevó la investigación por mi parte de la API de ARASAAC, pues fueron sus pictogramas los que se implementaron en el buscador. Inicialicé un repositorio en GitHub para poder almacenar nuestra plan- 10.3. Pablo 125 tilla de la memoria, gestionarlo de manera más ordenada y no recurrir a otras herramientas de edición de texto. Este repositorio posteriormente se transfirió al repositorio final del proyecto. Además, propuse la metodología de trabajo en Git, sugiriendo que cada integrante del equipo trabajase en una rama propia y, una vez implementasen una funcionalidad estable, se fusionasen los cambios con la rama master, donde se encuentra la versión final. Realicé investigaciones sobre patrones de diseño Front-End, hasta finalmente proponer Redux. Tras la aceptación de este por parte de mis compañeros, realicé una amplia investigación sobre el funcionamiento de la arquitectura y realicé la adaptación del proyecto con el patrón, creando un proyecto desde cero, refactorizando y clasificando las clases, creando el Store, los reductores, acciones e importando paquetes necesarios para ello como react-redux, reselect, y redux-thunk. Además, integré las funcionalidades que realizaron mis compañeros en sus respectivos prototipos en este nuevo proyecto, para así tener un proyecto en común en el que trabajar. Posteriormente, expliqué los cambios y el funcionamiento a mis compañeros para que comprendiesen la nueva arquitectura y pudieran continuar con sus nuevas tareas en el nuevo proyecto. Realicé amplias configuraciones en el proyecto de CKEditor, integrándolo con Redux, permitiendo que el editor internamente reconociese nuestro modelo de datos y poder configurar la exportación a PDF de la manera más rigurosa posible. Realicé investigaciones sobre cómo poder desplegar la aplicación en el servidor cedido por la universidad hasta conseguirlo. Configuré el servidor instalando node y las librerías necesarias para desplegar una aplicación React. Una vez conseguido, generé un documento explicando las herramientas y comandos necesarios para poder subir la aplicación al servidor y que sirviese de soporte tanto para mis compañeros como para mí. Por último, contacté por escrito con el equipo de CKEditor para pedir una licencia del editor y solicitar una licencia de la funcionalidad de pago exportar a PDF, las cuales aceptaron a cedérnosla gratuitamente dada la naturaleza solidaria y de código abierto de nuestro proyecto. En cuanto a la redacción de la memoria, me encargué de redactar el Capítulo 3 con el Estado del arte, del Capítulo 6, el apartado 6.2 con la Arquitectura y el subapartado 6.2.2.3 con la funcionalidad del Buscador de pictogramas y traduje a inglés el Capítulo 1 de Introducción y el Capítulo 8 de Conclusiones y Trabajo futuro. Apéndice A Tabla de puntuaciones individuales y examen de prueba Resumen: En este anexo se recoge la tabla de puntuaciones individuales para cada requisito de cada miembro del equipo de desarrollo, así como el examen de prueba proporcionado en la evaluación de la aplicación. Requisito Puntuación Jorge Natalia Pablo Generar un resumen a partir de un texto 3 2 2 Crear esquemas que faciliten la visualización del temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiendo desde cero 2 1 2 Crear tablas que organicen el temario y/o las actividades, seleccionando contenido de un texto ya redactado o escribiéndolo desde cero 2 1 2 Ejercicios de relacionar contenido mediante flechas 2 2 2 Ejercicios de sopa de letras 3 3 3 Ejercicios de completar espacios en un texto 2 2 3 Ejercicios de pregunta de desarrollo con un espacio limitado para escribir la respuesta 2 2 3 127 128 Apéndice A. Tabla de puntuaciones individuales y examen de prueba Tabla A.1 continuada de la página anterior Ejercicios de verdadero o falso 3 3 3 Ejercicios de completar los espacios en blanco en tablas 2 2 2 Ejercicios de completar los espacios en blanco en esquemas 1 1 1 Añadir enunciados y ejemplos (con o sin pictogramas), donde se explique cómo debe resolverse el ejercicio 3 3 3 Sustituir una palabra por un pictograma 3 2 3 Sustituir una palabra por una imagen 2 2 3 Resaltar una palabra con un color 3 3 3 Añadir una leyenda de colores con la categoría de cada tipo de palabra resaltada, para que los alumnos puedan identificar el significado de cada una de las palabras resaltadas en el texto 3 3 3 Añadir una leyenda de colores para el tema de cada asignatura, para que los alumnos las distingan con mayor facilidad 3 3 3 Estandarizar formato en textos, estableciendo una fuente de texto determinada y un tamaño acorde para cada alumno 3 1 2 Estandarizar formato para títulos e índices del temario, generando de forma automática una plantilla del color de la asignatura 3 1 2 Aumentar el tamaño de la fuente de una parte del texto 3 2 3 Subrayar una parte del texto 3 2 3 Poner en negrita una parte del texto 3 2 3 Añadir imágenes buscando una palabra en bases de datos de imágenes libres 2 3 2 Añadir espacio extra entre líneas para escribir 2 2 2 Tabla A.1: Puntuación individual de cada miembro del equipo de desarrollo para cada requisito Examen de prueba para la evaluación Creado a partir de un tema de Ana Alonso Frades y redactado por los desarrolladores de AdaptaMaterialEscolar con la aplicación web. 1. Define los siguientes conceptos: ser vivo ser inerte 2. Encuentra 3 palabras escondidas en la sopa de letras. Z N Y N B K A U Y K Z P B Y O U H R B A F A B L Z B G T L Z R X L I R H R M N R X X U X Y Q U R B P D I Q I D K G N Q Q C V F C I Q D L W L P G W C A I S Q Y L A N H T O C W Ó L K V J H W R T K E Z N Z M F F I A A E R E P R O D U C C I Ó N M R E L A C I Ó N P V N 129