Aplicación móvil para el aprendizaje de habilidades en...

Escu

ela

Po

lité

cn

ica

Su

peri

or

de J

aén

Aplicación móvil para

el aprendizaje de

habilidades en niños

con síndrome de Down

Alumno: Cristina Lechuga Chica

Tutor: Prof. D. Juan José Jiménez Delgado

Dpto: Ingeniería Informática

Septiembre, 2016

Septiembre, 2016

Cristina Lechuga Chica Aplicación móvil para el aprendizaje de habilidades en niños con síndrome de Down

Escuela Politécnica Superior de Jaén 1

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Juan José Jiménez Delgado , tutor del Trabajo Fin de Grado titulado:

Aplicación móvil para el aprendizaje de habilidades en niños con síndrome de

Down, que presenta Cristina Lechuga Chica, autoriza su presentación para

defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, Septiembre de 2016

El alumno: Los tutores:

Cristina Lechuga Chica Juan José Jiménez Delgado



AGRADECIMIENTOS

Me gustaría dar las gracias a todas las personas que me han acompañado en

estos cuatro años de carrera, apoyándome en todo momento.

A la Escuela Politécnica Superior y a sus profesores, por su dedicación y

enseñarme la Ingeniería Informática.

A mi familia, principalmente a mi hermano por introducirme en este mundo, a

mis padres, por permitirme esta oportunidad y apoyarme incluso en los momentos más

difíciles y a Edu, por su paciencia y apoyo en todo momento.

A mis compañeros y amigos de clase, especialmente a Joseda y Paco, por

acompañarme en este recorrido, ayudarnos siempre que lo hemos necesitado y vivir

juntos momentos inolvidables.

A Mari, mi amiga y punto de apoyo que me ha ayudado en todo lo posible.

También agradecer a la Asociación Down Jaén permitirme conocer a sus niños y

a todo el equipo de investigación de la conciencia fonológica de la Universidad de

Málaga, principalmente a Miguel y Helena, por toda su ayuda y cercanía.



ÍNDICE

1. INTRODUCCIÓN ................................................................................................. 9

1.1. Propósito general ............................................................................................... 9

1.2. Objetivos ......................................................................................................... 10

1.2.1. Objetivos del proyecto ............................................................................. 10

1.2.2. Objetivos de la aplicación ......................................................................... 10

1.3. Motivación ....................................................................................................... 10

1.4. Estructura de la memoria ................................................................................ 11

2. ESTUDIO PREVIO................................................................................................. 14

2.1. Síndrome de Down ............................................................................................... 14

2.2. Conciencia fonológica .......................................................................................... 14

2.3. Conciencia fonológica y Serious Games ............................................................... 15

3. PLANIFICACIÓN DEL PROYECTO ........................................................................... 18

3.1. Metodología ......................................................................................................... 18

3.2. Tareas ................................................................................................................... 21

3.2.1. Investigación .................................................................................................. 21

3.2.2. Desarrollo ...................................................................................................... 21

3.2.3. Documentación ............................................................................................. 22

3.3. Estimación de tiempo y costes............................................................................. 22

3.4. Tecnologías utilizadas .......................................................................................... 24

3.4.1. Android Studio ............................................................................................... 24

3.4.2. SQLite ............................................................................................................. 25

3.4.3. SmartGit ......................................................................................................... 25

3.4.4. HockeyApp ..................................................................................................... 26

3.4.5. GIMP .............................................................................................................. 27

4. DESARROLLO ...................................................................................................... 29



4.1. Sprint 0 ................................................................................................................. 29

4.1.1. Historias de usuario ....................................................................................... 29

4.2. Sprint 1 ................................................................................................................. 32

4.2.1. Pila de producto ............................................................................................ 32

4.2.2. Pila del sprint ................................................................................................. 33

4.2.3. Solución adoptada ......................................................................................... 33

4.3. Sprint 2 ................................................................................................................. 35

4.3.1. Pila de producto ............................................................................................ 35

4.3.2. Pila del sprint ................................................................................................. 36


4.3.4. Revisión del sprint ......................................................................................... 43

4.4. Sprint 3 ................................................................................................................. 44

4.4.1. Pila de producto ............................................................................................ 44

4.4.2. Pila del sprint ................................................................................................. 45


4.5. Sprint 4 ................................................................................................................. 49

4.5.1. Pila de producto ............................................................................................ 49

4.5.2. Pila del sprint ................................................................................................. 50



4.6. Sprint 5 ................................................................................................................. 55

4.6.1. Pila de producto ............................................................................................ 55

4.6.2. Pila del sprint ................................................................................................. 56


4.7. Sprint 6 ................................................................................................................. 58

4.7.1. Pila de producto ............................................................................................ 58



4.7.2. Pila del sprint ................................................................................................. 59



4.8. Sprint 7 ................................................................................................................. 61

4.8.1. Pila de producto ............................................................................................ 61

4.8.2. Pila del sprint ................................................................................................. 62


5. PRUEBAS REALIZADAS Y VALIDACIÓN ................................................................. 69

6. CONCLUSIONES Y TRABAJOS FUTUROS ............................................................... 72

6.1. Conclusiones ........................................................................................................ 72

6.2. Trabajos futuros ................................................................................................... 73

7. BIBLIOGRAFÍA ..................................................................................................... 75

7.1. Libros .................................................................................................................... 75

7.2. Artículos de revista .............................................................................................. 75

7.3. Material de internet ............................................................................................. 75

7.4. Bibliografía consultada ......................................................................................... 76

ANEXO I. MANUAL DE USUARIO ............................................................................. 78

ANEXO II. DIAGRAMA DE CLASES ............................................................................ 90

ANEXO III. COMPONENTES ANDROID ...................................................................... 93



ÍNDICE DE ILUSTRACIONES

Ilustración 1. Proceso de desarrollo Scrum .................................................................... 19

Ilustración 2. Diagrama de Gantt.................................................................................... 22

Ilustración 3. Diagrama de Gantt detallado ................................................................... 23

Ilustración 4. Tabla Usuario ............................................................................................ 34

Ilustración 5. Vista añadir usuario .................................................................................. 34

Ilustración 6. Pantalla inicial de la aplicación ................................................................. 35

Ilustración 7. Diagrama de secuencia sprint 1................................................................ 38

Ilustración 8. Interfaz “El cohete de las sílabas” ............................................................ 39

Ilustración 9. Tabla Cohete Sílabas ................................................................................. 40

Ilustración 10. Diagrama del ciclo de vida de un objeto MediaPlayer ........................... 42

Ilustración 11. Imagen tras fallar un nivel ...................................................................... 42

Ilustración 12. Modelo Entidad-Relación ....................................................................... 47

Ilustración 13. Vista usuario seleccionado ..................................................................... 48

Ilustración 14. Vista de “El Gnomo de la Rima” ............................................................. 51

Ilustración 15. Sistema de gamificación ......................................................................... 55

Ilustración 16. Modelo entidad relación con gamificación ............................................ 60

Ilustración 17. Diseño botón .......................................................................................... 63

Ilustración 18. Logo de la aplicación............................................................................... 64

Ilustración 19. Fondo básico ........................................................................................... 65

Ilustración 20. Fondo principal ...................................................................................... 66

Ilustración 21. Vista selección de juego ......................................................................... 67

Ilustración 22. Manual de usuario. Vista principal ......................................................... 78

Ilustración 23. Manual de usuario. Vista añadir usuario……………………………….………………80

Ilustración 24. Manual de usuario. Aviso completar campos….. ................................... 79

Ilustración 25. Manual de usuario. Vista de jugador...................................................... 80

Ilustración 26. Manual de usuario. Confirmación de borrado ....................................... 81

Ilustración 27. Manual de usuario. Vista selección de juegos........................................ 82

Ilustración 28. Manual de usuario. Configurador de número de ejemplos ................... 83

Ilustración 29. Manual de usuario. Vista “El cohete de las sílabas” ............................... 84

Ilustración 30. Manual de usuario. Vista de finalización de nivel del cohete ............... 85



Ilustración 31. Manual usuario. Vista “El gnomo de la rima” ........................................ 86

Ilustración 32. Manual de usuario. Vista de finalización de nivel del gnomo ............... 87

Ilustración 33. Manual de usuario. Vista final de juego ................................................. 88

Ilustración 34. Manual de usuario. Dialogo de confirmación. ....................................... 89

Ilustración 35. Diagrama de clases ................................................................................. 90

Ilustración 36. Ciclo de vida de una activity ................................................................... 94

ÍNDICE DE TABLAS

Tabla 1. Comparativa metodología tradicional y ágil ..................................................... 18

Tabla 2. Estimación de presupuesto............................................................................... 24

Tabla 3. Pila de producto del sprint 1 ............................................................................. 32

Tabla 4. Pila de sprint 1 .................................................................................................. 33





Tabla 9. Pila de producto sprint 4 ................................................................................... 50

Tabla 10. Pila de sprint 4 ................................................................................................ 50

Tabla 11. Pila de producto del sprint 5 ........................................................................... 56








CAPÍTULO 1.

INTRODUCCIÓN



1. INTRODUCCIÓN

1.1. Propósito general

Tras estudiar de manera general la accesibilidad de personas con

discapacidad a la tecnología, y conociendo la escasez de opciones de las que

se dispone en el ámbito educativo en cuanto a aplicaciones se refiere, surge la

idea de ayudar a los niños que presentan un desarrollo cognitivo diferente, como

son los niños con síndrome de Down, en los que es necesario aplicar una

metodología distinta de aprendizaje.

El objetivo principal de la aplicación consistirá en el aprendizaje de

habilidades por parte de sus usuarios, así como motivarles y proporcionarles un

acercamiento a la tecnología.

Debido al público al que será destinada la aplicación y su objetivo, se

considera que debe ser un conjunto de “Serious Games”, es decir, juegos que

permitan al usuario divertirse a la vez que educar en algún área o materia

específica, en nuestro caso, la mejora de habilidades, como la conciencia

fonológica.

Para el diseño de la aplicación, es necesario un estudio previo de las

actividades realizadas por profesionales en clase con los niños, determinando

sus carencias. Para ello, y para conocer mejor a los niños con síndrome de

Down, se ha contactado con la asociación “Down Jaén”, la cual ha permitido la

asistencia a clases de logopedia especializada con diferentes niños, para

conocer de primera mano sus limitaciones y los procesos de aprendizaje que

utilizan.

A través de dicha asociación, se facilitó el contacto con un profesor de

psicología y su equipo de investigación de la Universidad de Málaga, los cuales

estudian la conciencia fonológica en niños con síndrome de Down en el proyecto

“Aprendizaje de la lectura y desarrollo del lenguaje oral en niños y adolescentes

con síndrome de Down”, y proponen diferentes juegos para la intervención de

esta habilidad, convirtiéndose dicho equipo en el cliente de este proyecto.

Tras el contacto con este, se acuerda el propósito general de la aplicación,

destinada a dispositivos Android, la cual será utilizada bajo supervisión de



terapeutas en diferentes centros de atención temprana y asociaciones situados

principalmente en Andalucía y que constará de dos “Serious Games” orientados

a la mejora de la conciencia fonológica en niños que se encuentren cursando

tercer curso de Educación Infantil y primer ciclo de Primaria.

1.2. Objetivos

1.2.1. Objetivos del proyecto

Estudiar y analizar las necesidades y carencias de los profesores y

monitores que ayudan a los niños con síndrome de Down en relación a la

incentivación de habilidades.

Analizar las posibilidades de “Serious Games” y su aplicación a la hora de

incentivar a los niños en determinadas habilidades.

Diseñar una aplicación que permita o facilite el aprendizaje de habilidades

en niños con síndrome de Down.

Implementación de la aplicación.

Estudiar la usabilidad de la aplicación y realizar pruebas de uso con niños.

Redactar una memoria con todos los aspectos de análisis, diseño,

implementación y pruebas realizadas.

1.2.2. Objetivos de la aplicación

Facilitar el aprendizaje y la intervención de la conciencia fonológica en

niños con síndrome de Down.

Motivar a los niños en su aprendizaje.

Acercar la tecnología a personas con discapacidad.

Proponer una herramienta diferente que pueda ser utilizada en el ámbito

educativo.

1.3. Motivación

Entendiendo la informática como herramienta para satisfacer y mejorar las

necesidades de la población, como hemos dicho anteriormente, nos centraremos

en una parte de ella como son los niños con síndrome de Down.

Esta idea parte gracias a amigos cuyos familiares padecen síndrome de

Down, que me manifestaron la falta de aplicaciones en centros de atención

temprana que puedan ayudar a los monitores a mejorar el aprendizaje de los



niños con problemas, decidí comenzar a investigar y dedicar mi proyecto de final

de grado a dicho ámbito.

La población residente en España a mediados de 2015, según datos

publicados en el INE (Instituto Nacional de Estadística), es de un total de

46.423.064 de personas, de las cuales aproximadamente unas 35.000 personas

padecen síndrome de Down, lo cual se corresponde a un porcentaje del 0,075%.

Aunque pueda parecer un bajo porcentaje de población, considero que es

necesario y esencial facilitar la inclusión educativa e integración social de estas

personas.

Estudiando distintas aplicaciones especializadas para niños que padecen

esta discapacidad, podemos apreciar que se basan en el aprendizaje de

palabras, números, facilitación de la lectura, atención visual o incluso hábitos

saludables y habilidades sociales.

Investigando el material tecnológico que utilizan las asociaciones

dedicadas a la educación e integración de estas personas, se comprueba que

en ellas actualmente no se utilizan aplicaciones para dispositivos móviles. Las

aplicaciones existentes no se consideran apropiadas para ser utilizadas en este

ámbito, lo que no significa que no se recomienden utilizar en casa o como

material de apoyo y diversión.

1.4. Estructura de la memoria

La estructura de esta memoria está dividida en seis capítulos. A lo largo de

estos se describirá el proceso de realización de la aplicación móvil, detallando

desde la concepción de la idea hasta la finalización del producto.

A continuación podemos ver una descripción del contenido de cada uno de

los diferentes capítulos:

Capítulo 1.

En este primer capítulo se detalla el propósito general del proyecto, así

como la definición de los objetivos propuestos y la motivación para la realización

del mismo.



Capítulo 2.

Este capítulo está dedicado la investigación previa realizada antes de

comenzar el desarrollo e implementación de la aplicación. Se describe lo que es

el síndrome de Down y se detallan las particularidades con las que cuentan las

personas que lo padecen, concretamente las que aparecen en niños durante su

aprendizaje. Se define la conciencia fonológica y se relaciona la mejora de esta

con la aplicación de “Serious Games”.

Capítulo 3.

La planificación del proyecto es un tema clave para la consecución de los

objetivos propuestos. En este apartado se detalla la metodología software

escogida, las distintas tareas principales, una estimación del tiempo y del coste

que supondrá su realización, y una descripción de las tecnologías utilizadas a la

hora del desarrollo de la aplicación junto a una breve justificación de su uso.

Capítulo 4.

Este capítulo está dedicado a la descripción del desarrollo e

implementación de la aplicación. Debido a la metodología escogida, se

especifican los distintos sprints que han tenido lugar y sus elementos más

característicos: la pila del producto, la pila del sprint, la solución aplicada y, en

caso de haber realizado una reunión de revisión de sprint con el cliente, un

resumen de esta.

Capítulo 5.

El capítulo cinco detalla la última reunión realizada con el cliente,

describiendo las distintas pruebas que se realizan y la validación del proyecto

por parte del cliente.

Capítulo 6.

En este último capítulo se describen las conclusiones a las que se ha

llegado una vez concluido el proyecto y distintos proyectos que surgen a partir

de este.



CAPÍTULO 2.

ESTUDIO PREVIO



2. ESTUDIO PREVIO

2.1. Síndrome de Down

El síndrome de Down es el trastorno de origen genético más común que

provoca retraso mental (Roberts, Price y Malkin, 2007). Es una alteración

genética que se produce por la presencia de un cromosoma extra o una parte de

él. Se produce en todas las etnias, en todos los países, con una incidencia de

una por cada 600-700 concepciones en el mundo.

Aunque hay un gran grado de variabilidad en función de los sujetos, el

fenotipo característico del síndrome de Down afecta al desarrollo y la adquisición

del lenguaje (Roberts et al., 2007).

Muchos de los niños que padecen síndrome de Down tienen limitaciones

físicas y mentales, pero estos pueden llevar vidas independientes y productivas.

En cuanto al aprendizaje de habilidades le llevará un tiempo asimilar lo que

se le quiere enseñar y olvidará lo aprendido más fácilmente que un niño sin

discapacidad, lo que supondrá repetir más veces cada cosa. Establecer rutinas

y hacer las cosas siempre de la misma manera le ayudará a asimilar la

información.

Estos niños a los que nos referimos, tienen un mejor aprendizaje visual que

oral, por ello le será más sencillo aprender palabras si se le enseñan los objetos

a la vez que se pronuncian sus nombres. En general, entienden más de lo que

ellos mismos pueden expresar.

2.2. Conciencia fonológica

La conciencia fonológica se define como la habilidad para manipular

explícitamente los sonidos del habla (Roch y Jarrold, 2012), es decir, es la

capacidad o habilidad que le posibilita a los niños reconocer, identificar,

manipular deliberadamente y obrar con los sonidos (fonemas) que componen

las palabras.

Se consideran cuatro tipos de unidades fonológicas dentro de una palabra.

(Goswami y Bryant, 1990), que son las siguientes: la sílaba; la unidad



intrasilábica de onset, que es la consonante inicial de una sílaba si la hubiera

(por ejemplo, la c en la sílaba ‘car’); la unidad intrasilábica de rima, la cual incluye

el núcleo, vocal, y la consonante final si la hubiera (como ‘ar’ en ‘car’); y, por

último, los fonemas, sonidos individuales que constituyen las palabras.

La conciencia fonológica se desarrolla desde una conciencia explícita de

las unidades mayores (sílabas) a una conciencia de onsets y rimas y, por último,

la conciencia de las unidades más pequeñas (fonemas).

Existen distintos estudios que demuestran que las personas con síndrome

de Down siguen un proceso evolutivo que generalmente presenta problemas con

la identificación de la rima, como se señala a continuación.

Según Gombert (2002), los niños franceses con síndrome de Down tienen

más problemas en tareas de encontrar la rima diferente (encontrar la palabra que

no rima con otras), con los juicios de rima (decidir qué palabras riman) y síntesis

de fonemas (unir fonemas para formar palabras) que con tareas de conciencia

de fonemas, tales como contar fonemas, deletreo de fonemas y supresión de

fonemas.

Otros autores señalan que los niños con síndrome de Down tienen más

dificultades con la identificación de rimas que con identificar los sonidos iniciales

de las palabras (Snowling, Hulme y Mercer, 2002). En 2008, Rosch y Jarrold

destacan que la conciencia fonológica es un área difícil para estos niños,

especialmente en detección de rima (estos últimos evaluaron además la

detección y supresión del fonema inicial).

2.3. Conciencia fonológica y Serious Games

Existen varios artículos sobre el desarrollo de las habilidades de conciencia

fonológica de los niños con síndrome de Down y su relación con la lectura, pero

pocos sobre intervenciones para mejorar estas habilidades.

Cleave, Kay-Raining Bird Bourassa (2011), realizaron un programa de

intervención en conciencia fonológica en niños con síndrome de Down,

encontrando una mejora en las habilidades entrenadas.

El uso de las nuevas metodologías activas de aprendizaje, como los

“Serious Games”, pueden ser de interés en el desarrollo de competencias. Los



juegos permiten a los jugadores-aprendices adquirir competencias mediante

actividades basadas en el juego, dado su carácter lúdico e interactivo. Asimismo,

propician que el participante se motive para aprender, mediante la mejora en el

desempeño y así experimentar en la realidad virtual una situación simulada

(Kirriemuir y McFarlane, 2004).

Basándome en el estudio anterior, en el que se encuentran mejoras tras

realizar programas de intervención y conociendo la escasez de estos, considero

que mi proyecto de aplicación móvil se basará en actividades de intervención

para la mejora de la conciencia fonológica en niños con síndrome de Down,

haciendo uso de metodologías como los “Serious Games”, como se ha dicho

anteriormente, para motivar su aprendizaje utilizando la tecnología.

Como hemos visto en el apartado 2.2., los niños presentan más problemas

con la identificación de rimas, por lo que los juegos propuestos se centran en la

mejora de distintas tareas, incluyendo la misma.

“El gnomo de la rima”, para la identificación de rimas.

“El Cohete de las sílabas”, para la identificación de la sílaba inicial.



CAPÍTULO 3.

PLANIFICACIÓN DEL

PROYECTO



3. PLANIFICACIÓN DEL PROYECTO

La planificación de cualquier proyecto es clave para su posterior desarrollo.

Marcará los plazos de tiempo establecidos en los que deberemos cumplir los

objetivos propuestos.

3.1. Metodología

En primer lugar, estudiaremos las principales y más generalizadas

diferencias que existen entre las metodologías ágiles y las metodologías

tradicionales, las cuales se muestran en la tabla 1.:

Tradicional Ágil

Cierta resistencia a los cambios Especialmente preparados para

cambios durante el proyecto

El cliente delega su responsabilidad El cliente es parte del equipo

Se prioriza en base a la visión propia Se prioriza en base a las necesidades

del cliente

Modelo de desarrollo en cascada Entregas incrementales e integración

continua

Control centralizado Auto-organización

Proceso mucho más controlado, con

numerosas políticas/normas

Proceso menos controlado, con pocos

principios

Grupos grandes y posiblemente

distribuidos

Grupos pequeños y trabajando en el

mismo sitio

Tabla 1. Comparativa metodología tradicional y ágil

Debido a las características del proyecto, el cual no tiene unos requisitos

definidos y estará constantemente afectado por los cambios y la implicación del

cliente en él, se decide que la metodología ágil empleada para trabajar en

entornos de incertidumbre e inestabilidad de requisitos, es la que mejor se

adapta a este.

Entre las diferentes metodologías ágiles se escoge Scrum, una

metodología de desarrollo muy simple que se ha utilizado con éxito los últimos

diez años, basándose en adaptación continua a las circunstancias de la

evolución del proyecto.



El modelo Scrum, aplicado al desarrollo de software, emplea el principio

ágil: "desarrollo iterativo e incremental", denominando sprint a cada iteración de

desarrollo que, según sus circunstancias, puede determinarse una duración

desde quince días a dos meses, aunque no suele ser recomendable hacerlos de

más de un mes.

Las prácticas empleadas por Scrum para mantener un control ágil en el

proyecto son:

Revisión de las iteraciones: al finalizar cada iteración (sprint) se lleva a

cabo una revisión con todas las personas implicadas en el proyecto.

Desarrollo incremental: implica que al final de cada iteración se dispone

de una parte de producto operativa, que se puede inspeccionar y evaluar.

Desarrollo evolutivo: durante el desarrollo se genera el diseño y la

arquitectura final de forma evolutiva.

Auto-organización del equipo: en Scrum los equipos son auto-

organizados (no auto-dirigidos), con margen de decisión suficiente para

tomar las decisiones que consideren oportunas.

Colaboración: para que funcione la auto-organización como un control

eficaz cada miembro del equipo debe colaborar de forma abierta con los

demás, según sus capacidades y no según su rol o su puesto.

La ilustración 1., muestra una visión general del proceso descrito hasta el

momento:

Ilustración 1. Proceso de desarrollo Scrum



Los distintos componentes que conforman el desarrollo Scrum son:

Elementos:

o Pila del producto o product backlog: lista de requisitos de usuario

que a partir de la visión inicial del producto crece y evoluciona

durante el desarrollo.

o Pila del sprint o sprint backlog: lista de los trabajos que debe

realizar el equipo durante el sprint para generar el incremento

previsto.

o Incremento: resultado de cada sprint.

Roles:

Como principales roles en SCRUM se identifican el propietario del producto,

el Scrum manager y el equipo.

En el caso de este proyecto, el propietario del producto, el cual se considera

la persona responsable de lograr el mayor valor de producto para los clientes,

usuarios y resto de implicados, corresponde con la autora de este trabajo fin de

grado.

El equipo, definido por el grupo de trabajo que desarrolla el producto, sería

asumido por una sola persona, que al igual que en caso anterior, corresponde

con la autora del trabajo fin de grado.

El cargo de Scrum Manager se otorga al tutor del proyecto, responsable del

funcionamiento de la metodología Scrum en la organización.

Reuniones:

o Planificación del sprint: en esta reunión se toman como base las

prioridades y necesidades de negocio del cliente, y se determina

cuáles y cómo van a ser las funcionalidades que incorporará el

producto tras el siguiente sprint.

o Seguimiento del sprint: reunión diaria breve, de no más de 15

minutos, en la que cada miembro del equipo dice las tareas en las

que está trabajando, si se ha encontrado o prevé encontrarse con



algún impedimento, y actualiza sobre la pila del sprint las ya

terminadas, o los tiempos de trabajo que les quedan. Debido a las

características del proyecto en el cual solo existe un desarrollador,

el seguimiento del sprint no se establecerá como una reunión.

o Revisión del sprint: reunión realizada al final del sprint en la que, el

equipo presenta al propietario del producto, clientes, usuarios,

gestores… el incremento construido en el sprint. Esta reunión se

realizará con los responsables del proyecto de investigación sobre

la adquisición del lenguaje en niños con síndrome de Down de la

Universidad de Málaga, además de con el tutor del proyecto.

3.2. Tareas

El proyecto se basará en tres tareas principales, investigación, desarrollo y

documentación, detalladas a continuación.

3.2.1. Investigación

La tarea de investigación, consiste en estudiar y analizar las necesidades

y carencias de los profesores y monitores que ayudan a los niños con síndrome

de Down, así como conocer cómo se desenvuelven los niños, sus principales

limitaciones y las actividades realizadas en los centros de atención temprana.

Para ello, se contacta con la asociación “Down Jaén” la cual abre sus

puertas y ofrece asistir a clases de logopedia con diferentes niños.

Una vez establecido que la aplicación tratará la conciencia fonológica se

inicia un estudio de esta habilidad y su implicación en los niños con síndrome de

Down.

Paralelamente, se realiza un estudio sobre la utilización de Serious Games.

3.2.2. Desarrollo

El desarrollo del proyecto, incluirá un diseño y recogida de requisitos inicial

tras la primera reunión con el cliente.

Debido a la metodología escogida (Scrum), en cada iteración se recogerán

los nuevos requisitos o modificaciones, se realizará la implementación del código

correspondiente y se realizarán las pruebas que se consideren oportunas,



finalizando algunas de estas iteraciones con una reunión con el cliente, validando

el incremento producido y recogiendo los nuevos requisitos para la siguiente

iteración.

3.2.3. Documentación

La redacción de la documentación se hará de forma paralela a la

investigación y desarrollo, así como el manual de usuario (véase anexo I) y se

estima concluirlo una vez terminado el desarrollo.

3.3. Estimación de tiempo y costes

Para hacer una estimación del tiempo de desarrollo y de su planificación,

se utiliza un diagrama de Gantt (ilustración 2.), en el cual podemos ver la

representación gráfica del tiempo que se estima dedicar a cada una de las tareas

principales del proyecto.

Ilustración 2. Diagrama de Gantt

Una vez contactado con el cliente, se concretarán las fechas de las

reuniones para revisar los diferentes sprint que, debido a la dificultad de

establecer reuniones con ellos, estas se establecerán aproximadamente cada

mes y medio por lo que se puede realizar una nueva planificación más detallada,

como la que se observa en la ilustración 3.

Teniendo en cuenta que no se recomienda realizar sprints de más de un

mes de duración, se considera necesario realizar varios sprints entre las distintas

reuniones donde, al finalizar cada uno de ellos, debe existir un incremento

funcional de la aplicación, a pesar de que no se realice ningún encuentro con el

cliente.



Ilustración 3. Diagrama de Gantt detallado

La estimación del presupuesto se calculará teniendo en cuenta el personal

y el material utilizado para el desarrollo de la aplicación, así como el tiempo de

trabajo dedicado a este que, como hemos visto en la planificación anterior,

corresponde a nueve meses desarrollando a tiempo parcial.

El personal está compuesto por una sola persona, la cual debe de asumir

varios perfiles como el de jefe de proyecto, diseñador o programador.

El salario estará basado en el XVI convenio colectivo estatal de empresas

de consultoría y estudios de mercados y de la opinión pública, el cual establece

un salario base para titulado de grado medio de 1.133,46 € al mes, más un plus

salarial de 80,02 €, teniendo en cuenta un horario laboral del ocho horas diarias.

El total de horas de trabajo autónomo correspondiente al trabajo fin de

grado son de 300 horas, por lo que correspondería a dos meses de trabajo a

jornada completa.

El material necesario para el desarrollo se basa en un equipo de desarrollo

de clase media, valorado aproximadamente en 500 € con una vida útil de cuatro

años, y para las diferentes pruebas será necesaria una Tablet de 10’’ valorada

actualmente en 200 € con una vida útil de cuatro años.

Con estas cifras, la amortización por uso en nueve meses del equipo

informático es de 93,75 € para el ordenador y 37,50 € para la Tablet.

En resumen, como podemos observar en la tabla 2., el presupuesto se

estima en 2.558,21 € teniendo en cuenta el personal y el equipo necesario para

un desarrollo de la aplicación de nueve meses.



Recurso €/mes Coste Total

Personal 1.213,48 € 2.426,96 €

Ordenador - 93,75 €

Tablet - 37,50 €

Total - 2.558,21 €

Tabla 2. Estimación de presupuesto

3.4. Tecnologías utilizadas

A continuación se mostrarán las tecnologías utilizadas en la construcción y

desarrollo del producto, así como una breve descripción y su motivo de uso.

3.4.1. Android Studio

Android Studio es IDE oficial de Android. Está diseñado para acelerar su

desarrollo y ayudar a construir las aplicaciones de alta calidad para todos los

dispositivos Android.

Se ofrecen herramientas adaptadas a las necesidades de los

desarrolladores de Android, incluyendo la edición rica de código, depuración,

pruebas y herramientas de perfilado.

La estructura de los proyectos de Android Studio y la construcción basada

en Gradle proporciona la flexibilidad necesaria para generar APKs para todos los

tipos de dispositivos.

Al desarrollar un Serious Game este podría haber sido implementado con

un motor de video juegos, estos normalmente proporcionan un motor

de renderizado para gráficos 2D y 3D, un motor que detecte la colisión física de

objetos y la respuesta a dicha colisión, sonidos y música, animación, inteligencia

artificial, comunicación con la red para juegos multijugador, posibilidad de

ejecución en hilos, gestión de memoria o soporte para localización (traducción

de los textos y audios del juego según idioma).

Una vez conocido el diseño general de los juegos que se implementarán,

se considera que, debido a su sencillo mecanismo basado en arrastrar

imágenes, no es necesario utilizar un motor de video juegos. Además, la mayor

parte de dispositivos con los que cuentan las Asociaciones de Síndrome de



Down en los que se utilizará la aplicación son dispositivos Android, por lo que no

ha sido necesario exportarlo a otras plataformas.

En el anexo III, se puede encontrar una descripción de los componentes

básicos utilizados en el desarrollo Android.

3.4.2. SQLite

SQLite es una biblioteca que implementa un motor transaccional de base

de datos, siendo este autónomo, sin necesidad de la utilización de un servidor ni

configuración previa. El código para su uso está en dominio público y, por lo

tanto, es libre para cualquier propósito, ya sea comercial o privado. SQLite es

el mayor despliegue de bases de datos del mundo con numerosas aplicaciones,

incluyendo proyectos de alto perfil.

A diferencia de los sistemas de gestión de bases de datos cliente-servidor,

el motor de SQLite no es un proceso independiente con el que el programa

principal se comunica. En lugar de eso, la biblioteca SQLite se enlaza con el

programa pasando a ser parte integral del mismo. El programa utiliza la

funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones.

Esto reduce la latencia en el acceso a la base de datos, debido a que las

llamadas a funciones son más eficientes que la comunicación entre procesos. El

conjunto de la base de datos (definiciones, tablas, índices, y los propios datos),

son guardados como un sólo fichero estándar en la máquina host. Este diseño

simple se logra bloqueando todo el fichero de base de datos al principio de cada

transacción.

Se decide el uso de SQLite debido a la variedad de ventajas que ofrece,

como su sencillo uso gracias a llamadas simples a subrutinas y funciones, y

pudiendo prescindir de un servidor y de configuración previa, además de la

extensa documentación que existe sobre esta biblioteca.

3.4.3. SmartGit

SmartGit es un cliente gráfico Git y Mercurial que también se puede conectar

a repositorios SVN.

https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos



Git es un software de control de versiones diseñado pensando en la eficiencia

y la confiabilidad del mantenimiento de versiones de aplicaciones. Entre las

características más relevantes se encuentran:

Fuerte apoyo al desarrollo no lineal, por rapidez en la gestión de ramas y

mezclado de diferentes versiones. Git incluye herramientas específicas para

navegar y visualizar un historial de desarrollo no lineal. Una presunción

fundamental en Git es que un cambio será fusionado mucho más

frecuentemente de lo que se escribe originalmente, conforme se pasa entre

varios programadores que lo revisan.

Gestión distribuida. Git le da a cada programador una copia local del historial

del desarrollo entero, y los cambios se propagan entre los repositorios

locales. Los cambios se importan como ramas adicionales y pueden ser

fusionados en la misma manera que se hace con la rama local.

Gestión eficiente de proyectos grandes, dada la rapidez de gestión de

diferencias entre archivos, entre otras mejoras de optimización de velocidad

de ejecución.

A pesar de trabajar una sola persona en el proyecto, se considera que

contar con un control de versiones como Git es imprescindible para llevar un

control del desarrollo de la aplicación y disponer de las distintas versiones de

ella, el uso de la herramienta SmartGit, proporciona un sistema gráfico con el

que el desarrollador ya posee experiencia previa, resultando así más sencilla su

utilización.

3.4.4. HockeyApp

HockeyApp es una herramienta que facilita las tareas distribuir, recoger

feedback o los informes de fallos que produzca la aplicación. Permite instalar y

actualizar de forma sencilla la aplicación en los terminales de los betatester que

hayan sido registrados.

Una de las ventajas respecto a otras herramientas como TestFlight es que

es multiplataforma, por lo que podremos usarla tanto para Android, iOS, Mac OS

X y Windows Phone. Dispone de SDKs para la recolección de crash report para

las distintas tecnologías, así como una aplicación cliente que deberán instalarse

los betatester para recibir las actualizaciones de la aplicación en desarrollo.



La distribución de aplicaciones se realiza de forma sencilla. Subimos la

versión beta que deseamos y HockeyApp la distribuirá automáticamente a los

usuarios. Al integrar la SDK en la propia aplicación automáticamente detectará

que hay una nueva actualización y la instalará mostrando un mensaje con los

cambios realizados.

La interfaz de HockeyApp permite crear distintos roles como desarrollador

o tester. En el panel podemos ver las aplicaciones que estamos usando y a las

que tenemos acceso.

También nos ofrece analíticas de uso, como el porcentaje de uso

correspondiente a cada tester y dispositivo, versiones de sistema operativo lo ha

usado. Quizás lo más importante, es poder centralizar todo el feedback de la

aplicación por un canal único a través de la aplicación, ya sea desde la misma

aplicación o en la web. Eso le llegará a los desarrolladores junto con el reporte

de error.

Esta herramienta se utilizará para que el tutor del proyecto pueda ir

probando y testeando la aplicación, y para distribuirla en los diferentes

dispositivos que la utilizarán.

3.4.5. GIMP

GIMP (GNU Image Manipulation Program) es un programa de edición de

imágenes digitales en forma de mapa de bits, tanto dibujos como fotografías,

disponible para las principales plataformas de escritorio. Es un programa libre y

gratuito. Está englobado en el proyecto GNU y disponible bajo la licencia pública

general de GNU.

El uso de esta herramienta es necesario para la creación de los distintos

fondos de la aplicación así como del montaje de los diferentes botones y el logo.

Se ha elegido GIMP frente a herramientas como Adobe PhotoShop debido

a su licencia y a la experiencia del desarrollador con la misma.



CAPÍTULO 4.

DESARROLLO



4. DESARROLLO

Como se ha indicado anteriormente, el desarrollo se realizará siguiendo

una metodología basada en iteraciones. En cada uno de los sprints realizados

(excepto en el sprint 0), se detallará la pila de producto, la pila del sprint, la

solución adoptada para cada una de las historias de usuario dividida en tareas y

un resumen de la reunión de revisión del sprint en aquellos en los que se ha

producido.

En el anexo II, diagrama de clases, se puede observar el diagrama y una

breve descripción de las clases implementadas una vez acabado el desarrollo

de la aplicación.

4.1. Sprint 0

Este sprint realmente no tiene ítems de producto, si no que corresponde a

todas las actividades preparatorias para poder comenzar a ejecutar el proyecto

tras la primera reunión con el cliente.

Se especifican los requisitos no funcionales de la aplicación:

Utilización en dispositivos Android mínimo de 7 pulgadas.

Prescindir de un servidor.

No necesitar conexión a Internet.

Gestión de usuarios: creación y borrado.

Implementación de dos Serious Games, basados en drag and drop

y audio guía.

Interfaz sencilla y básica.

4.1.1. Historias de usuario

Se definirán historias de usuario, un instrumento muy utilizado en las

metodologías ágiles para obtener los requerimientos de la aplicación a partir de

la información obtenida de los usuarios. Se define, únicamente, lo que el usuario

necesita saber basado en sus necesidades pero sin detallar el cómo se va a

realizar.

A veces, las historias de usuario son demasiado amplias, por lo que a su

vez hay que desglosarlas en otras historias de usuario más pequeñas. Aquellas

que describen un requisito funcional de gran amplitud se las conoce como epics.



A su vez, cada historia de usuario se compone de tasks (tareas), que son cada

uno de los elementos que conforman una historia.

Se detectan dos epics principales (mostrados a continuación), los cuales

posteriormente dividiremos en historias de usuario, teniendo en cuenta que la

aplicación tendrá dos principales usuarios: el terapeuta y el jugador. El terapeuta

será el encargado de gestionar los usuarios, además de guiar y supervisar al

jugador, evaluando la mejora producida y seleccionando el juego

correspondiente. Por otro lado, el rol de jugador corresponde al niño que asiste

al centro para mejorar sus habilidades.

Gestión de usuarios EPIC 1

Como terapeuta quiero tener un listado actualizado de los jugadores para

poder tener cuentas diferentes e identificarlos.

Jugar a “Serious Games” EPIC 2

Como jugador quiero jugar a varios juegos.

A continuación se desglosan los epics citados anteriormente en las

diferentes historias de usuario que se han contemplado, realizando una

estimación de tiempo basada en puntos de historia, una medida de la

complejidad y/o el tamaño de un requerimiento comparado con la duración

necesaria para completar ese requerimiento expresado, utilizando valores

relativos.

Añadir usuarios US 1.1

Como terapeuta quiero añadir un nuevo jugador para crear un perfil del jugador

con su nombre, el centro en el que se encuentran y su terapeuta.

Estimación: 8



Eliminar usuarios US 1.2

Como terapeuta quiero eliminar un jugador para mantener el listado de

jugadores actualizado.

Estimación: 3

Listado de usuarios US 1.3

Como terapeuta quiero ver el listado de los jugadores para elegir cual es el

que va a jugar.

Estimación: 3

El cohete de las sílabas US 2.1

Como jugador quiero jugar a “El cohete de las sílabas”.

Estimación: 13

El gnomo de la rima US 2.2

Como jugador quiero jugar a “El gnomo de la rima”,

Estimación: 13

Se estima una velocidad de cuatro puntos de historia por semana

basándonos en que la implementación de la historia de usuario “Añadir usuarios”

(ocho puntos de historia) se estima en un periodo de tiempo de dos semanas.

Por lo tanto, cada sprint se compondrá de las diferentes tareas que sus puntos



de historia sumen aproximadamente doce puntos de historia, ya que los sprints

son de tres semanas de duración.

Los diferentes juegos contarán con un margen de dos o tres elecciones, ya

que, como dicen Van Bysterveldt, Gillon y Foster-Cohen (2014), su amplitud de

memoria fonológica es de dos-tres elementos y muchos ítems pueden ocultar

sus habilidades en este campo.

4.2. Sprint 1

4.2.1. Pila de producto

En la pila del producto (tabla 3.) podemos ver las historias de usuario

ordenadas por prioridad del cliente. Estas historias se dividen en distintas tareas

para su mejor implementación.

Historia de usuario Tarea Estado Estimación

Añadir usuarios

Creación de la base de datos Abierto

8 Diseño e implementación de la

vista “Añadir Usuario”

Abierto

Listado de usuarios Diseño de la pantalla inicial Abierto 3

El cohete de las

sílabas

Actualización de la base de datos Abierto

13 Implementación drag and drop Abierto

Reproducción de audio guías Abierto

Resultado de nivel Abierto

Eliminar usuarios Abierto 3

El gnomo de la rima





Tabla 3. Pila de producto del sprint 1



4.2.2. Pila del sprint

En la pila del sprint (tabla 4.) podemos ver las tareas que se realizarán el

primer sprint.

Historia de Usuario Tarea Estimación

Añadir usuarios

Creación de la base de datos

8 Diseño e implementación de la vista

“Añadir Usuario”

Listado de usuarios Diseño de la pantalla inicial 3

Tabla 4. Pila de sprint 1

4.2.3. Solución adoptada

Añadir usuarios

Creación de la base de datos

Para poder añadir usuarios, en primer lugar es necesaria la implementación

de la base de datos. Para ello se utiliza la tecnología SQLitle, una base de datos

local alojada en el terminal para satisfacer las necesidades del cliente, el cual no

quiere utilizar servidores externos ni servicios en la nube para el almacenaje de

los datos.

Para acceder al archivo SQLite que representa la base de datos se requiere

de una clase que extienda de SQLiteOpenHelper. En ella se sobrescriben los

controladores onCreate() y onUpgrade() para crear y actualizar la base de datos.

Además, en esta clase se debe definir el nombre de la base de datos y su versión

actual.

Las operaciones de lectura, inserción, modificación y eliminación de las

tablas que se crearán, serán ejecutadas desde clases auxiliares, y estas se

definirán bajo un patrón singleton que permita propagar el uso de los métodos a

través de una sola instancia a lo largo de la aplicación.

En esta primera iteración, únicamente es necesario la implementación de

la tabla Usuario (ilustración 4.) para almacenar los usuarios que utilizarán la

aplicación.



Ilustración 4. Tabla Usuario

Vista “añadir usuario”

En la pantalla principal se dará la opción de añadir un nuevo usuario. En

esta vista el terapeuta deberá rellenar los siguientes campos de texto con la

información del alumno:

Nombre y apellidos del niño

Nombre y apellidos del terapeuta

Centro

Para rellenar el centro en el que se encuentra el niño, aparecerá un

desplegable con los diferentes nombres de las asociaciones, de modo que el

terapeuta marcará el que le corresponda.

Una vez rellenados todos los datos, al pulsar sobre el botón “Guardar”,

estos pasan a guardarse a la tabla de la base de datos “Usuario”.

La ilustración 5. muestra dicha vista.

Ilustración 5. Vista añadir usuario



Listado de usuarios

En la pantalla inicial de la aplicación se podrá ver un listado de los usuarios

guardados en la base de datos y un icono para añadir un nuevo usuario

(ilustración 6.).

Ilustración 6. Pantalla inicial de la aplicación

Para implementar el listado de usuarios es necesario acceder a la base de

datos para obtener dicho listado. Una vez recuperado, se muestra en la vista

utilizando un adaptador personalizado.

Al pulsar sobre cualquiera de los usuarios, empezará el juego “El cohete de

las sílabas”.

4.3. Sprint 2


Tras finalizar el sprint 1, no ha sido posible una reunión con el cliente, por

lo que la pila de producto continúa con las mismas tareas en cada una de las

historias de usuario (tabla 5.).



Historia de Usuario Tarea Estado Estimación

Añadir usuarios

Creación de la base de datos Cerrado



Cerrado

Listado de usuarios Diseño de la pantalla inicial Cerrado 3

El cohete de las

sílabas






El gnomo de la rima







A continuación se muestran las tareas seleccionadas para su realización

en este sprint (tabla 6.).

Historia de Usuario Tarea Tamaño

El cohete de las

sílabas

Actualización de la base de datos

13 Implementación drag and drop

Reproducción de audio guías

Resultado de nivel





El cohete de las sílabas

“El cohete de las sílabas” es el primer juego educativo que se implementará

en la aplicación. Este está destinado a la intervención de la identificación de la

sílaba inicial.

El juego contiene tres imágenes que deberán ser arrastradas por el niño

una por una hacia un cohete o un cubo de basura. Esto dependerá del sonido de

la sílaba inicial. Si el sonido de la sílaba inicial coincide con el de un objeto

ejemplo, la imagen debe ser llevada al cohete. Si por el contrario la sílaba inicial

de la opción no coincide con la del ejemplo, esta se tirará a la basura.

Tras haber arrastrado las tres imágenes, se mostrará una pantalla

felicitando al usuario junto a una animación en la imagen del cohete en caso de

que haya colocado de manera correcta las tres imágenes, en otro caso,

reproducirá un mensaje de ánimo. En esta misma pantalla aparecerá un botón

“continuar”, el cual debe ser pulsado por el terapeuta para pasar al siguiente

nivel. En caso de que el niño haya fallado, se mostrará el mismo nivel.

Para facilitar y explicar el juego al niño, se utilizará audio guía en cada nivel,

además de que al pulsar cada una de las imágenes sonará su nombre para evitar

confusiones. Al iniciar una pregunta, una voz explicará de manera cercana y

expresiva lo que el niño debe hacer, cuyo diálogo es el siguiente:

- ¡Vamos a jugar con el cohete de la sílaba inicial CA! En el cohete de la sílaba

inicial CA, vamos a llevar todas las imágenes que empiezan por CA, como

caja. Si toco en la caja, suena su nombre.

- Y no lo olvides, la imagen que no empieza por la sílaba inicial CA se tira a la

basura

Para comprender mejor la dinámica de juego se muestra a continuación un

diagrama de secuencia (ilustración 7.).



Ilustración 7. Diagrama de secuencia sprint 1



La interfaz del juego debe ser muy sencilla. Constará, como muestra la

ilustración 8., de un fondo en un color plano y poco llamativo para evitar

distracciones por parte del usuario, de la imagen de un cohete junto con el objeto

ejemplo, de un cubo de basura situado debajo de este, y de las tres opciones

colocadas a la izquierda de la pantalla.

Ilustración 8. Interfaz “El cohete de las sílabas”

Actualización base de datos

La base de datos se actualizará para añadir una nueva tabla (ilustración 9.)

que almacene las preguntas que utilizará el juego “El cohete de las sílabas”, las

cuales serán estáticas, es decir, ningún terapeuta podrá modificarlas, eliminar o

añadir alguna pregunta nueva.



Ilustración 9. Tabla Cohete Sílabas

La tabla contendrá el número de pregunta (_id), una descripción de la

pregunta (Pregunta), la palabra utilizada como ejemplo (Ejemplo), y las tres

opciones (Respuesta 1, Respuesta 2, Respuesta 3).

Implementación drag and drop

La clase “CoheteSilabas”, se implementará como una actividad y contendrá

todo el contenido relacionado con este juego.

Para la implementación del arrastre de elementos, como es el caso de las

imágenes, se utilizará el evento OnTouchListener() de Android. Indicando que al

pulsar uno de los elementos se activará una función con distintos eventos.

o ACTION_DOWN: este evento se lanza cuando tocamos el

elemento. Guarda la posición inicial y actualiza variables de la

clase.

o ACTION_MOVE: después de haber tocado el elemento, movemos

el dedo por la pantalla. Obteniendo la posición actual del dedo, se

calcula el desplazamiento que es el resultado de en cada

coordenada hacer el cálculo de la posición actual menos la inicial

asignada en el evento ACTION_DOWN. Posteriormente,

asignamos la nueva posición al elemento, que es el resultado de

sumar la posición actual del elemento más el movimiento calculado

con respecto a la posición inicial.

o ACTION_UP: cuando levantamos el dedo del elemento. En este

punto se obtienen las coordenadas en el que se ha soltado el

elemento y se comprueba con las coordenadas de las imágenes



del cohete y la basura si ha sido arrastrado hacia uno de ellos. En

tal caso, se comprueba si la sílaba inicial del elemento movido

coincide o no con la sílaba inicial del ejemplo, determinando así si

el movimiento se ha realizado de forma correcta o, en otro caso, se

ha producido un error, reproduciendo el audio correspondiente en

cada caso.


Se decide la reproducción de audios grabados anteriormente por el cliente

en formato WMA en lugar de utilizar un sintetizador de voz “text-to-speech”, que

convierte un texto escrito en audio, debido a que la voz artificial es menos

familiar y cercana para un niño. Además, es necesario que la voz sea expresiva

y enfatice las sílabas iniciales de las palabras.

La clase de Android MediaPlayer se utiliza para controlar la reproducción de

archivos de audio/vídeo, en nuestro caso, para la reproducción de los audios de

la aplicación.

El control de reproducción de archivos de audio se gestiona como una

máquina de estados. El siguiente diagrama (ilustración 10.) muestra el ciclo de

vida y los estados de un objeto MediaPlayer impulsado por las operaciones de

control de reproducción compatibles. Los círculos representan los estados en los

que puede estar el objeto MediaPlayer, mientras que las flechas representan las

operaciones de control de reproducción que impulsan la transición entre los

distintos estados del objeto. Hay dos tipos de flechas: los flechas con una sola

cabeza representan las llamadas a métodos síncronos, mientras que aquellas

con doble cabeza representan las llamadas a métodos asíncronos.



Ilustración 10. Diagrama del ciclo de vida de un objeto MediaPlayer

Resultado de nivel

Una vez movidas las tres imágenes y comprobado si se ha hecho de forma

correcta o no, se mostrará una ventana emergente con este resultado.

En caso de haber cometido uno o más errores en el juego, se mostrará una

imagen expresando tristeza, mostrada en la ilustración 11., y un audio de ánimo

para volver a intentarlo.

Ilustración 11. Imagen tras fallar un nivel



En caso de que el niño haya movido las tres imágenes a su lugar

correspondiente, de manera correcta, se mostrará una animación del cohete.

La animación se define en un archivo XML que realizará transiciones del

objeto, tales como la rotación, la translación, el zoom o la modificación del valor

alfa, durante un período de tiempo determinado.

Este archivo será leído por un objeto de la clase Animation encargado de

realizar la animación a la imagen del cohete.

4.3.4. Revisión del sprint

Para la revisión del sprint se establece una reunión con el cliente y con el

tutor del proyecto.

En esa reunión se presenta el progreso de la aplicación desde un

dispositivo real que, tras lo desarrollado durante el sprint, se puede comprobar

la creación y listado de usuarios, así como el juego “El cohete de las sílabas”.

Tras dicha comprobación, se acuerda hacer distintas modificaciones en el

juego:

Cambiar algunos audios del juego para hacerlo más dinámico.

Incluir tres preguntas con audios más guiados para introducir al

usuario en el juego. El terapeuta debe decidir cada vez que abra

el juego si el niño necesita de estas preguntas o no.

Guardar el proceso del jugador para que, cuando se vuelva a abrir

la aplicación, continúe por el último nivel jugado.

Informar al jugador tras el movimiento de cada imagen si este es

correcto o no de manera auditiva. En caso de fallo, se le explicará

el motivo correspondiente. Actualmente la corrección se ha estado

realizando una vez movidas las tres imágenes, pero de esta

manera el niño no es consciente de su fallo.

Modificar tamaños de imágenes y algunos aspectos de la interfaz,

como es el fondo o el color.



Una vez revisadas y anotadas las mejoras que se establecerán en la

aplicación, se determina el diseño del siguiente juego, “El gnomo de la rima”, con

una dinámica parecida a la del juego anterior.

En esta reunión, también se considera necesaria la introducción de un

mecanismo de gamificación para incentivar al niño premiándole de alguna forma,

aunque no se especifica la metodología y se acuerda investigar y proponer

distintos métodos en la próxima reunión.

4.4. Sprint 3


La pila de producto es actualizada tras la reunión con el cliente,

añadiéndole las modificaciones oportunas y quedando como se observa en la

tabla 7.


Añadir usuarios Creación de la base de datos Cerrado 8

Diseño e implementación de la


Cerrado


El cohete de las

sílabas

Actualización de la base de datos Cerrado 21

Implementación drag and drop Cerrado

Reproducción de audio guías Cerrado

Resultado de nivel En progreso

Progreso del jugador Abierto

Preguntas ejemplo Abierto

Modificación de interfaz Abierto




El gnomo de la rima


21

Implementación drag and drop Abierto










El cohete de las

sílabas

Resultado de nivel 8

Progreso del jugador

Preguntas ejemplo

Eliminar usuarios 3

El gnomo de la rima

Actualización de la base de datos 3




A continuación se detallarán las modificaciones y nuevas tareas incluidas

referentes a “El cohete de las sílabas” en la reunión de revisión del sprint anterior.

Resultado de nivel

La modificación del resultado de nivel se considera oportuna con motivo de

que, en la versión previa del juego, el jugador debía mover las tres imágenes al



cohete o a la basura según correspondiese antes de conocer el resultado de sus

movimientos, por lo que, de esta manera, el alumno no es consciente de su fallo

y no puede aprender del error, ya que podría a ver fallado en cualquiera de los

tres movimientos.

Para solucionar esto, se comunicará mediante un audio el resultado de

cada uno de los movimientos, indicando si se ha realizado de manera correcta o

si se ha cometido un error, explicando en ambos casos el motivo del mismo.

Una vez movidas las tres imágenes de manera correcta, se mostrará la

animación del cohete implementada en la versión anterior para motivar y atraer

al niño.

La modificación de esta tarea requiere la eliminación de una parte de código

de la versión anterior, así como la implementación de nuevo código y audios para

cada uno de los movimientos que se pueden realizar.


Como se ha considerado en la reunión previa, también es necesario

almacenar el progreso del jugador. Así, en cada sesión, el usuario podrá

continuar por el nivel en el que se quedó en la sesión anterior y no volver a

comenzar desde el primer nivel.

Previendo la implementación inmediata de otro juego y otros juegos futuros,

se creará la tabla “Juego”, la cual almacenará los diferentes juegos con un

identificador asociado.

El diagrama entidad-relación correspondiente a la base de datos de la

aplicación (ilustración 12.) quedará de la siguiente manera:



Ilustración 12. Modelo Entidad-Relación

Esto requiere una modificación en la base de datos, añadiendo una tabla

“Progreso”, la cual almacenará para cada usuario el número de pregunta que le

corresponde (Nivel).

De esta manera, en dicha tabla se almacenará el identificador del jugador,

el del juego y su progreso en él, ya que cada jugador tendrá un progreso diferente

en los distintos juegos.

Una vez modificada la base de datos para poder almacenar el nivel, es

necesaria la implementación de código en la aplicación tanto para guardar el

nivel como para recuperarlo.

El nivel se guardará automáticamente en la tabla correspondiente cada vez

que el jugador o el terapeuta seleccionen “Continuar” en la vista que aparece

tras haber movido las tres imágenes de manera correcta.

Cada vez que el terapeuta abra el juego, se recuperará el nivel de la base

de datos.

Preguntas ejemplo

En cuanto a la tarea de “preguntas ejemplo”, el cliente propone incluir tres

preguntas totalmente guiadas. De esta manera, el niño aprenderá o recordará la

mecánica del juego y no necesitará la ayuda de su terapeuta.

La aplicación se utilizará en los centros solamente una vez a la semana,

por lo que es recomendable que cada vez que el niño vaya a empezar a jugar,

se recuerde la dinámica de juego con una o varias de estas preguntas guiadas.

El terapeuta tendrá la opción de seleccionar si el alumno necesita la

reproducción de este tipo de preguntas teniendo en cuenta factores como el

tiempo entre sesiones, la edad del niño, su memoria o su desarrollo. Para ello se

implementa un configurador de ejemplos en los que, cada vez que se vaya a

iniciar alguno de los distintos juegos, el terapeuta decidirá el número de

preguntas guiadas que aparecerán (0, 1, 2, o 3).



Eliminar jugador

Es necesario incluir un botón para la eliminación de usuarios. Este se

colocará en una vista (ilustración 13.) que aparecerá cuando el terapeuta escoja

un jugador de la lista de la vista principal. Además de este botón, se verá el

nombre del jugador y el de su terapeuta.

El botón de “eliminar jugador”, se corresponderá con el icono de una

papelera y, una vez se pulse, se mostrará una ventana emergente con la

confirmación de la eliminación, para evitar confusiones y borrados no deseados.

Ilustración 13. Vista usuario seleccionado

El gnomo de la rima

El segundo juego educativo que se implementa en la aplicación será “El

gnomo de la rima”. Su principal objetivo es el de la identificación (discriminación)

de la rima.

La dinámica de este juego es similar a la de “El cohete de las sílabas”, con

unas pequeñas modificaciones que se especificarán en el sprint 4.

Actualización de la base de datos



En el sprint actual se comenzará la implementación del juego actualizando

la base de datos con la creación de una tabla para almacenar sus preguntas que,

al igual que en el juego anterior estas serán estáticas, por lo cual ningún

terapeuta podrá modificarlas, añadir nuevas o eliminar alguna de ellas.

La tabla “GnomoRima” contendrá el número de pregunta (_id), una

descripción de la pregunta (Pregunta), el sonido de la rima de ejemplo (Ejemplo),

y dos opciones (Respuesta 1, Respuesta 2).

También se añadirá “El gnomo de la rima” en la tabla “Juego” para poder

registrar el progreso de sus jugadores.

4.5. Sprint 4


La pila de producto es idéntica a la del sprint anterior, ya que no ha tenido

lugar ninguna reunión con el cliente (tabla 9.).


Añadir usuarios




Cerrado


El cohete de las

sílabas




Resultado de nivel Cerrado

Progreso del jugador Cerrado

Preguntas ejemplo Cerrado

Eliminar usuarios Cerrado 3

Actualización de la base de datos Cerrado



El gnomo de la rima

Implementación drag and drop Abierto

21





Tabla 9. Pila de producto sprint 4





El gnomo de la Rima


13 Reproducción de audio guías

Resultado de nivel




El gnomo de la rima

Como hemos indicado anteriormente, el objetivo principal de “El gnomo de

la rima” es el de la identificación de la rima.

Una vez actualizada la base de datos para poder desarrollar el juego y la

creación de una sencilla pantalla de selección de juego, se comienza la

implementación de este, cuya dinámica es similar al de “El cohete de las sílabas”.

En este juego, es el gnomo quien quiere llevar a su seta la palabra que

acabe con el mismo sonido que una palabra ejemplo. El niño tendrá dos opciones



para elegir: una de ellas será la correcta, que debe ser entregada al gnomo para

que este la lleve a su seta, y la otra, la incorrecta, debe ser arrastrada hasta la

basura. El gnomo contará con animación de movimiento para llevar los objetos

a su seta.

Todo esto, al igual que en el otro juego, será guiado con audios que

explican el juego y ayudan al niño de manera familiar y expresiva, como el audio

descrito a continuación:

- “El gnomo va a llevar una mesa a su casa porque le gustan las palabras que

acaban en esa.”

- “¡Mira lo que hay aquí! Una fresa y una casa, el gnomo tiene que llevar a su

casita la palabra que acaba en esa, como mesa, ¿cuál de damos y cuál

tiramos a la basura?”

La interfaz del juego debe ser sencilla y clara, con la utilización de fondos

lisos para resaltar las diferentes opciones y no sobrecargar ni distraer al jugador.

Los distintos elementos se situarán en la pantalla como podemos observar

en la ilustración 14.

Ilustración 14. Vista de “El Gnomo de la Rima”

A continuación se detalla cómo se desarrollan las distintas tareas

seleccionadas para este sprint.




Este juego se implementará como una actividad en la clase “GnomoRima”.

El drag and drop se implementa de la misma manera que en el juego anterior,

donde se utilizan distintos métodos para controlar el movimiento de los

elementos de la vista.

Al detectar que una de las opciones es movida hacia el gnomo, comenzará

una animación donde el gnomo lleva la imagen hasta la seta. La animación se

define en un archivo XML con la translación del elemento, la cual es leída por un

objeto de la clase de Android Animation.


Al igual que en el juego “El cohete de las sílabas”, los audios estarán

grabados por el cliente en formato WMA, ya que permite enfatizar en el sonido

final de las palabras y proporciona una voz familiar para el niño.

La reproducción de audios se realiza utilizando el objeto MediaPlayer que,

como hemos explicado en el apartado 4.3.3., incorpora los métodos propios para

el control del mismo.

Resultado de nivel

Tras el movimiento de cada una de las imágenes, se conocerá el resultado

de dicho movimiento mediante la reproducción de un audio, indicando si el

jugador lo ha realizado de manera correcta o, si por el contrario, ha cometido un

error.

En caso de cometer un error, la imagen volverá a su posición inicial para

que el jugador pueda volver a mover la imagen hasta colocarla en su lugar

correspondiente.

Una vez haya colocado las dos imágenes de manera correcta, se mostrará

una pantalla con la imagen del gnomo y la seta, y se reproducirá un audio

felicitando al jugador.

El terapeuta podrá pulsar el botón “Continuar” para comenzar el siguiente

nivel.




Para continuar el juego por el mismo nivel en el que el jugador se quedó la

última vez, se implementa el “progreso del jugador”, comenzando así por la

pregunta en la que dejó la partida anterior.

Para almacenar el progreso del jugador, lo único necesario es añadir este

juego a la tabla “Juego” de la base de datos, así, cuando el usuario lo abra por

primera vez, se creará un nuevo registro de manera automática en la tabla

“Progreso”, almacenando su identificador, el identificador del usuario y el nivel.

Cada vez que el usuario seleccione este juego, se recuperará de la base

de datos el número de pregunta por el cual el jugador acabó el juego, para

continuar así con su progreso. El almacenamiento de este número se realiza

cada vez que el usuario supera un nivel.


El objetivo de esta reunión con el cliente es revisar el incremento de la

aplicación mediante el uso de un dispositivo real y especificar las nuevas

incorporaciones o modificaciones de la aplicación.

En la primera parte de la reunión se validan las modificaciones que se

acordaron en la última y que han sido efectuadas en el “El cohete de las sílabas”.

Además, se comprueba el funcionamiento y avance del “El gnomo de la rima”.

El cliente considera adecuados ambos juegos, a falta de modificar

ligeramente el estilo y teniendo en cuenta la falta de la implementación de las

preguntas guiadas en el “El gnomo de la rima”.

La segunda parte de la reunión se destina a detallar las nuevas

funcionalidades.

En la versión actual de la aplicación, cuando el jugador termina todas las

preguntas de cualquiera de los dos juegos implementados, puede continuar el

juego comenzando de nuevo desde la primera pregunta. El cliente propone

modificar esta mecánica e incorporar un sistema en el que el terapeuta afirme

que desea comenzar de nuevo desde la primera pregunta, y no se continúe por

error o por motivo de que el niño pulse. Para ello se creará una vista especial



donde se indique que el juego ha terminado y, para continuar y comenzar desde

el primer nivel, se mostrará una ventana emergente de confirmación.

Por otro lado, en la reunión anterior se acordó investigar distintos elementos

que introduce la gamificación, para decidir cuál será la más recomendable de

implementar con el objetivo de motivar y premiar al jugador.

La gamificación es el uso de técnicas, elementos y dinámicas propias de

los juegos y el ocio en actividades no recreativas, cuyo fin es potenciar la

motivación, así como reforzar la conducta para solucionar un problema u obtener

un objetivo. Generalmente se dividen en:

Reglas o mecánicas: ejemplo de ellas son el sistema de puntos, niveles,

ránkings, etc.

Dinámicas de juego: como las recompensas, competencias o estatus.

Una vez estudiados otros juegos educativos similares y sus sistemas de

gamificación se proponen los siguientes:

Implementación de un ranking:

o Ranking de los jugadores en cuanto a número de preguntas

contestadas.

o Ranking de los jugadores en cuando a menos fallos cometidos.

Sistema de recompensas:

o Creación de un álbum de cromos en el que el jugador, cada vez

que supere el nivel, obtendrá un cromo nuevo y podrá colocarlo en

el álbum.

o Obtención de una estrella de nivel cada vez que el jugador supere

una pregunta sin cometer ningún fallo.

o Recreación de un espacio (por ejemplo un salón o un parque) en

el que el jugador podrá colocar juguetes u otros objetos una vez

superado el nivel correspondiente.



Tras estudiar con el cliente las ventajas e inconvenientes de cada una de

estas propuestas y teniendo en cuenta el público objetivo al que va dedicada la

aplicación y la dinámica de los juegos, se estima que, el sistema en el que el

jugador obtiene una estrella cada vez que supera el nivel correspondiente sin

cometer ningún fallo, como muestra la ilustración 15., es la opción más

adecuada. Esta opción es un método sencillo de visualizar por el niño y no

sobrecarga la aplicación con otras funcionalidades como ocurriría el caso de

implementar un álbum de cromos o recrear un espacio.

Ilustración 15. Sistema de gamificación

4.6. Sprint 5


La pila de producto (tabla 11.) es modificada según lo acordado en la última

reunión con el cliente.


Añadir usuarios


8



Cerrado


El cohete de las

sílabas


29








Modificación de interfaz Abierto

Pantalla final Abierto

Implementación gamificación Abierto


El gnomo de la rima


29






Pantalla final Abierto







El gnomo de la rima Preguntas ejemplo 8

Pantalla final

El cohete de las

sílabas

Pantalla final 3





El gnomo de la rima

Preguntas ejemplo

En primer lugar, teniendo en cuenta la prioridad de acabar “El gnomo de la

rima”, se comienza la implementación de las tres preguntas guiadas para

introducir al jugador en la dinámica de este.

Al igual que en el otro juego, el terapeuta tiene la posibilidad de seleccionar

cuántas de estas preguntas quiere que aparezcan antes de comenzar el nivel

correspondiente.

Se utilizará la misma y ya implementada selección de las preguntas de

ejemplo, por lo que solo es necesaria la implementación de código

correspondiente a la reproducción de este tipo de preguntas en dicho juego.

Por defecto no se muestra ninguna de estas preguntas, por lo que, al

seleccionar el terapeuta el número de preguntas guiadas que considera que

deben aparecer, este número se pasa a la actividad correspondiente al juego al

iniciarlo. Según el número seleccionado, se recuperará de la base de datos la

pregunta correspondiente.

Pantalla final

Una vez que el jugador ha terminado de completar todos los niveles,

aparecerá una pantalla final felicitando al jugador y preguntando al terapeuta si

quiere volver a comenzar desde el primer nivel. Esta pantalla aparecerá cuando

el código detecte que es la última pregunta.

Aparecerá un mensaje de confirmación en caso de querer volver a empezar

el juego, para evitar así confusiones o que el niño pulse “Continuar” por

equivocación.

En caso de no querer comenzar de nuevo, te redirigirá a la pantalla de

selección de los distintos juegos. Al seleccionar el juego ya finalizado, volverá a

aparecer el mensaje de confirmación.




Pantalla final

La pantalla final de este juego, es idéntica que en el caso anterior.

Al detectar que se completa la última pregunta del juego, aparecerá esta

pantalla, con un mensaje de confirmación para comenzar el juego desde el

primer nivel, o en caso contrario, redirigirá a la pantalla de selección de los

distintos juegos.

Al volver a seleccionar el juego ya finalizado, aparecerá nuevamente el

mensaje de confirmación para comenzar el juego desde la primera pregunta.

4.7. Sprint 6


La pila de producto (tabla 13.) es idéntica a la del sprint anterior, ya que no

ha tenido lugar ninguna reunión con el cliente.

Historia de usuario Tarea Estado Estimación

Añadir usuarios


8



Cerrado


El cohete de las

sílabas


29






Pantalla final Cerrado





El gnomo de la rima


29













El gnomo de la rima Implementación gamificación 5

El cohete de las

sílabas

Implementación gamificación 5



El gnomo de la rima

Implementación gamificación

Para implementar el sistema de gamificación en el juego, la primera tarea

necesaria consiste en realizar una pequeña modificación en la base de datos,

para almacenar el número de preguntas correctas de cada uno de los jugadores

en los distintos juegos.



Para esto, se considera almacenar el este número a la vez que su progreso,

por lo que el modelo entidad-relación quedaría como podemos observar en la

ilustración 16.

Ilustración 16. Modelo entidad relación con gamificación

Su implementación consiste en añadir un nuevo campo en la tabla

“Progreso” el cuál se denominará “Gamificación”.

Al iniciar el juego, se consulta en la tabla cuántas preguntas correctas lleva

el jugador en el juego seleccionado, y se mostrará de color amarillo el número

de estrellas que se recupere de la base de datos.

Para actualizar este número se desarrollará el código correspondiente, el

cual al terminar el movimiento de las diferentes opciones de manera correcta y

se muestre la pantalla para continuar, comprueba si se ha producido algún error

previo, a pesar de haber sido corregido. De ser así este número no se modificará,

pero si no se ha cometido ningún error en el nivel, se actualizará incrementándolo

en uno, por lo que en el siguiente nivel, aparecerá una estrella más.


Implementación gamificación

La implementación del sistema de gamificación en este juego se realiza de

la misma forma que en el juego “El gnomo de la rima”, especificado en el

apartado anterior.


En esta reunión realizada con el cliente y el tutor del proyecto, se

comprueba en dispositivo real el funcionamiento de la aplicación, así como los

distintos juegos implementados.



Una vez revisado el funcionamiento de esta, se acordará los detalles finales

de la aplicación, así como modificaciones en la interfaz, modificaciones en los

tamaños de las imágenes o su posición.

También se modificará el estilo de los botones, fondos utilizados u otros

elementos.

Por otro lado, se considera oportuno completar la pantalla de selección de

los distintos juegos, con información adicional como el número de pregunta por

el que el jugador va o el número de preguntas que ha acertado sin cometer

ningún fallo, de esta manera, el terapeuta podrá ver el progreso de cada usuario.

4.8. Sprint 7


En la última reunión se valida la funcionalidad general de la aplicación, por

lo tanto las correcciones que se incorporarán en esta serán pequeños detalles y

modificaciones de estilo, por lo que se considera que no es necesaria la

ampliación de la pila de producto (tabla 15.).


Añadir usuarios


8



Cerrado


El cohete de las

sílabas


29









Implementación gamificación Cerrado


El gnomo de la rima








Implementación gamificación Cerrado



A continuación se muestran las tareas que se consideran oportunas para

su realización en este sprint (tabla 16.).

Tarea Estado Estimación

Modificaciones de interfaz Abierto

8

Diseño fondos de la aplicación Abierto

Diseño nombre y logo de la

aplicación

Abierto

Añadir información Abierto 3





El estilo de la aplicación y de sus juegos es un tema primordial para su

utilización debido al público al que está destinada. La elección de este ha sido

un tema personal a pesar de tener en cuenta los consejos y ayuda del cliente.

Se ha utilizado la herramienta GIMP de código abierto para el diseño y

creación de las imágenes que veremos a continuación.

Modificaciones de interfaz

Se realizan pequeñas modificaciones tanto en la interfaz general de la

aplicación como en los distintos juegos.

Se modifica el estilo de los botones, creando un diseño con una temática

infantil, el cual podemos ver en la ilustración 17.

Ilustración 17. Diseño botón

Además se reestructuran algunos elementos y se modifica el tipo de fuente

de la aplicación.

En cuanto a los distintos juegos, se adecua el tamaño de las imágenes,

buscado mejor visibilidad por parte del jugador y una relación proporcionada

entre estas.

Diseño nombre y logo de la aplicación

Para el nombre de la aplicación se busca uno que sea concorde con la

finalidad de la aplicación, es decir, con la conciencia fonológica. Además se

intenta que se este se pueda asociar fácilmente con juegos y que quede un

nombre corto y sencillo de aprender.

Tras pensar y dudar entre distintas opciones, se decide “FonePlay” como

nombre de la aplicación, correspondiente al conjunto de palabras fone

(fonología) y Play (juego).



El logo de la aplicación se diseña pensando en un dibujo llamativo para los

niños, y que incluya una imagen identificadora de cada uno de los juegos, como

es el gnomo y el cohete.

Se decide el diseño de una caja de juguetes, la cual contiene distintas

imágenes, entre ellas el cohete y el gnomo. A continuación se puede observar el

logo diseñado en la ilustración 18.

Ilustración 18. Logo de la aplicación

Diseño fondos de la aplicación

Según la investigación previa realizada, y los consejos del cliente, los niños

con síndrome de Down se distraen con mucha facilidad, por lo que para los

juegos, es imprescindible un fondo liso y con un color claro, mientras que los

objetos de las diferentes opciones, deben ser de colores llamativos y resaltar

sobre el fondo.

Para este, se selecciona un color azul, ya que se considera que este color

transmite calma y tranquilidad (ilustración 19.).



Ilustración 19. Fondo básico

Para la vista principal de la aplicación, se considera modificar el fondo

añadiéndole imágenes identificativas de los juegos que esta contiene, de manera

que podremos identificar el cohete y el gnomo utilizados en los distintos juegos.

A continuación, en la ilustración 20.., se muestra el fondo diseñado para la vista

principal.



Ilustración 20. Fondo principal

Añadir información

Se decide añadir información adicional en la vista de elección de juego,

para facilitar y ayudar a los terapeutas encargados de seguir la mejora de los

niños del centro y realizar el seguimiento oportuno.

Para ello en la vista de selección de juego (ilustración 21.), se especifica en

cada uno de ellos el número de pregunta correspondiente y el número de

preguntas que se han realizado de manera correcta, sin cometer ningún error.



Ilustración 21. Vista selección de juego



CAPÍTULO 5.

PRUEBAS REALIZADAS

Y VALIDACIÓN



5. PRUEBAS REALIZADAS Y VALIDACIÓN

En la última reunión realizada con el cliente se lleva a cabo la valoración y

revisión final de la aplicación.

Se comprueba la funcionalidad general de la aplicación, como es la gestión

de los usuarios (creación, eliminación y listado) y los diferentes juegos. Tras

comprobar y validar el funcionamiento general por parte de los especialistas, se

realizan distintas pruebas para comprobar detalles más específicos descritos a

continuación.

Arrastrar una imagen fuera de la pantalla.

En los distintos juegos, el usuario puede arrastrar las imágenes por toda la

pantalla. En caso de que suelte el arrastre de alguna de ellas fuera de los límites

de la pantalla, esta se recolocará dentro de la pantalla para no perder en ningún

momento ninguna de las imágenes.

Guardar un usuario sin rellenar todos los datos.

Al pulsar el botón “Guardar” de la vista de creación de un nuevo usuario, se

comprueba si todos los datos han sido rellenados y se ha seleccionado un centro.

En caso de que alguno de ellos no se haya completado, aparece un mensaje de

aviso y devuelve la vista para que el usuario pueda completar la información

antes de volver a pulsar el botón.

Eliminación de usuario.

Se comprueba que el usuario se elimina realmente de la base de datos y

que aparece un mensaje de alerta para confirmar la eliminación, evitando así

borrados por equivocación.

Progreso con preguntas guiadas.

El progreso del jugador en el juego, no debe modificarse tras la

reproducción de una o varias preguntas guiadas. Estas únicamente introducen

al jugador y tras ellas debe continuar por el último nivel jugado.



Selección de preguntas guiadas.

Se comprueba que el número de preguntas guiadas seleccionado por el

terapeuta se corresponde con las que se reproducen al comenzar el juego.

Tras la revisión de la aplicación completa por parte del cliente, este muestra

su conformidad con el resultado final del proyecto, validando la funcionalidad de

los distintos juegos y resaltando la simplicidad y usabilidad del mismo, teniendo

en cuenta que los juegos cumplen con su objetivo principal, intervenir en la

mejora de la conciencia fonológica de los niños.

Como se acordó desde el primer momento, la aplicación será utilizada en

centros de atención temprana y asociaciones, donde los niños con síndrome de

Down acuden para mejorar sus habilidades. Los terapeutas serán los

encargados de identificar, supervisar y evaluar la mejora del niño.

En el próximo curso académico, se realizarán varias pruebas de la

aplicación con distintos niños, para valorar la aceptación a la aplicación, su

usabilidad y la reacción de los usuarios principales, abriendo la posibilidad de

incorporar pequeños cambios a la interfaz u otros factores que se consideren

necesarios.



CAPÍTULO 6.

CONCLUSIONES Y

TRABAJOS FUTUROS



6. CONCLUSIONES Y TRABAJOS FUTUROS

6.1. Conclusiones

Con la realización de este proyecto, destinado a favorecer la integración y

ayuda a personas que padecen síndrome de Down, me he enfrentado

principalmente a trabajar de forma autónoma en algo nuevo y desconocido para

mí, como es el desarrollo de un proyecto real, además de haber avanzado y

profundizado en el aprendizaje de distintas metodologías y aspectos clave en la

ejecución de un proyecto, así como la adquisición de experiencia a nivel tanto

profesional como personal.

Con respecto a los objetivos planteados al principio, puedo afirmar que la

mayoría de ellos han sido alcanzados satisfactoriamente, como explico a

continuación.

En cuanto a la investigación y análisis de las metodologías empleadas para

ayudar a niños con síndrome de Down en el aprendizaje de diferentes destrezas

y habilidades, he de decir que no abunda el uso de nuevas tecnologías en dichos

métodos, resultando repetitivo y monótono el empleo de fichas tradicionales. Es

por ello que se propone una herramienta diferente que pueda ser utilizada en el

ámbito educativo, dando por cumplido dicho objetivo. A su vez, se contribuye a

acercar la tecnología a personas con discapacidad, consiguiendo así otro de los

propósitos planteados.

Para la implementación de la aplicación ha sido necesario el estudio de

tecnologías como Android, cuyo aprendizaje no ha sido tan difícil como me

esperaba, ya que existe una extensa documentación sobre este lenguaje,

aunque, personalmente, opino que lo que más ha facilitado su aprendizaje han

sido los conocimientos adquiridos durante estos años de carrera. Además, ha

sido de gran utilidad el uso de otras herramientas como SmartGit o HockeyApp,

cuyo empleo, a su vez, ha ampliado mis conocimientos acerca de estas.

Y, por último, como he indicado en el apartado 5, aún no se han llevado a

cabo pruebas con usuarios reales, por lo que, el objetivo referente al estudio de

la usabilidad de la aplicación y la realización de pruebas de uso con niños no

podrá ser constatado hasta su ejecución por parte de las personas a las que se

destina.



Por otro lado, he adquirido experiencia en cuanto al trato con el cliente se

refiere. La relación y comunicación entre ambos ha sido realmente favorable, a

pesar de los inconvenientes que en ocasiones conlleva el trato con clientes,

como pueden ser retrasos en entregas, los cuales pueden dar lugar a

modificaciones en la planificación inicial. Considero que, en un futuro, esta

experiencia adquirida a nivel profesional me será de gran ayuda a la hora de

llevar a cabo proyectos como este.

En cuanto a experiencia personal conseguida, resaltar el trato con los

profesores de la Asociación Down Jaén, cuya ayuda para este proyecto ha sido

imprescindible, aportando conocimientos esenciales en mi etapa de

investigación. De igual importancia ha sido la oportunidad que he tenido de

trabajar con los niños con síndrome de Down en su día a día, ya que ha sido así

como he podido tomar conciencia de cómo trabajan, cuáles son sus necesidades

y qué es necesario para mejorar sus habilidades.

Para finalizar, la realización del trabajo fin de grado ha sido más que

satisfactoria, contando con la validación por parte del cliente y cumpliendo con

creces mis expectativas, ya que esta aplicación va a ser utilizada realmente en

centros de atención temprana y logrará ayudar a los profesores en su tarea

diaria, facilitando el seguimiento de cada alumno, y cumpliendo su objetivo

principal, mejorar la conciencia fonológica en niños con síndrome de Down

aplicando una metodología diferente a la tradicional como es la utilización de

aplicaciones móviles.

6.2. Trabajos futuros

El número de aplicaciones para personas con algún tipo de discapacidad

es notablemente menor que el de aplicaciones que no tienen en cuenta este tipo

de problemas.

Conociendo la existencia de la gran variedad y diferencia entre los distintos

tipos de discapacidad y la cantidad de diferentes ámbitos en los que se puede

utilizar una aplicación, se considera que existe un gran nicho de oportunidad en

el desarrollo de aplicaciones móviles para personas que padecen alguna

discapacidad. Personalmente, considero que el ámbito educativo es esencial



para la integración de personas con cualquier tipo de problema y su participación

plena en la sociedad.

Tras el desarrollo de esta aplicación y, como he indicado en el apartado 5,

dejando abierta la posibilidad de introducir pequeños cambios, e incorporar

nuevos juegos en esta, el cliente propone la creación de nuevas aplicaciones

para la utilización en los centros de atención temprana, al igual que FonePlay.

Las aplicaciones propuestas tratan de solucionar diferentes problemas como

expongo a continuación.

Por un lado, se pretende crear una aplicación para evaluar la conciencia

fonológica y, de esta manera, observar la mejora producida tras el empleo de la

aplicación desarrollada en este trabajo fin de grado, y validar de manera más

fiable su funcionalidad.

Por otro lado, se propone la creación de una aplicación que potencie la

mejora y facilitación de la lectura de los niños con síndrome de Down.

Para finalizar y como se señala anteriormente, existe una gran oportunidad

para ese tipo de aplicaciones, ya que numerosos centros y asociaciones buscan

métodos actuales para el apoyo del aprendizaje o mejora en distintas

habilidades.



7. BIBLIOGRAFÍA

7.1. Libros

Goswami, U., & Bryant, P. (1990). Phonological skills and learning to read. London:

Erlbaum.

Kirriemuir, J. y McFarlane, A. (2004). Literature Review in Games and Learning. Bristol:

Nesta Futurelab series, report 8.

7.2. Artículos de revista

Cleave, P.L., Kay-Raining Bird, E. & Bourassa, D. (2011). Developing phonological

awareness skills in children with Down syndrome. Canadian Journal of Speech-

Language Pathology and Audiology, 35, 332-343.

Gombert, J.E. (2002). Children with Down syndrome use phonological knowledge in

reading. Reading and Writing, 15, 455-469.

Roberts, J., Martin, G. E., Moskowitz, L., Harris, A. A., Foreman, J. & Nelson, L. (2007).

Discourse Skills of Boys With Fragile X Syndrome in Comparison to Boys With Down

Syndrome. Journal of Speech, Language, and Hearing Research, 50(2), 475-492.

Roberts, J. E., Price, J. & Malkin, C. (2007). Language and Communication Development

in Down Syndrome. Mental Retardation and Developmental Disabilities, 13(1), 26-35.

Roch, M. &Jarrold, C. (2008). A comparison between word and nonword reading in Down

Syndrome: The role of phonological awareness. Journal of Communication Disorders,

41, 305–18.

Roch, M. & Jarrold, C. (2012). A follow-up studyonword and non-wordreadingskills in

Down syndrome. Journal of CommunicationDisorders, v. 45, p. 121-128.

Snowling, M.J., Hulme, C. &Mercer, R. (2002). A deficit in rime awareness in childrenwith

Down syndrome. Reading and Writing, 15, 471–495.

Van Bysterveldt, A., Gillon, G. and Foster-Cohen, S. (2014). A phonological awareness

intervention case study of a child with Down syndrome. Speech, Language and Hearing

17 (1): 25-36.

7.3. Material de internet

Android Studio, 27 de enero de 2016

https://developer.android.com/studio/index.html

Boletín Oficial del Estado

https://www.boe.es/boe/dias/2009/04/04/pdfs/BOE-A-2009-5688.pdf

Down España, 10 de octubre de 2015

http://www.sindromedown.net/

Fundación Iberoamericana Down 21, 6 de octubre de 2015

http://www.down21.org/informacion-basica/40-el-sindrome-de-down-una-vision-

globalizadora/2898-datos-estadisticos-en-el-sindrome-de-down.html

https://developer.android.com/studio/index.html

https://www.boe.es/boe/dias/2009/04/04/pdfs/BOE-A-2009-5688.pdf

http://www.sindromedown.net/

http://www.down21.org/informacion-basica/40-el-sindrome-de-down-una-vision-globalizadora/2898-datos-estadisticos-en-el-sindrome-de-down.html

http://www.down21.org/informacion-basica/40-el-sindrome-de-down-una-vision-globalizadora/2898-datos-estadisticos-en-el-sindrome-de-down.html



Hipertextual. Gamificación

https://hipertextual.com/2015/02/gamificar-la-educacion

HockeyApp

https://hockeyapp.net/

Genbetadev

http://www.genbetadev.com/desarrollo-aplicaciones-moviles/hockeyapp-herramienta-

para-distribuir-aplicaciones-moviles-a-los-betatester-y-recoger-feedback

GIMP

https://www.gimp.org/

Instituto Nacional de Estadística, 6 de octubre de 2015

http://www.ine.es/

Scrum Manager, 15 de diciembre de 2015

http://www.scrummanager.net/oks/

SmartGit

http://www.syntevo.com/smartgit/

SQLite

https://sqlite.org

7.4. Bibliografía consultada

Cardoso-Martins, C., Michalick, M.F. &Pollo, T.C. (2002). Is sensitivity to rhyme a

developmental precursor to sensitivity to phoneme?: Evidence from individuals with

Down syndrome. Reading and Writing: An interdisciplinary Journal, 15, 439-454.

Developers

https://developer.android.com/index.html

Nash, H.M. (2007). Semantic and phonological processing in Down syndrome.

University of York

Stack Overflow

http://stackoverflow.com/

https://hipertextual.com/2015/02/gamificar-la-educacion

https://hockeyapp.net/

http://www.genbetadev.com/desarrollo-aplicaciones-moviles/hockeyapp-herramienta-para-distribuir-aplicaciones-moviles-a-los-betatester-y-recoger-feedback

http://www.genbetadev.com/desarrollo-aplicaciones-moviles/hockeyapp-herramienta-para-distribuir-aplicaciones-moviles-a-los-betatester-y-recoger-feedback

https://www.gimp.org/

http://www.ine.es/

http://www.scrummanager.net/oks/

https://sqlite.org/

https://developer.android.com/index.html

http://stackoverflow.com/



ANEXOS



ANEXO I. MANUAL DE USUARIO

Este manual de usuario describe las funciones principales de la aplicación

FonePlay.

Al iniciar la aplicación, aparecerá la pantalla principal, donde podremos ver

el logo y el listado de usuarios registrados previamente por su terapeuta. Se

podrá ver el nombre de usuario con un tamaño notablemente mayor que el

nombre del terapeuta responsable de su supervisión y evaluación.

En esta pantalla (ilustración 22.) también se puede observar el botón para

añadir un nuevo jugador. Este botón se identifica con el símbolo ‘+’ situado sobre

el listado de usuarios.

Ilustración 22. Manual de usuario. Vista principal



Si lo que deseamos es añadir un nuevo usuario, como se acaba de

comentar, pulsaremos el botón ‘+’ y se abrirá una nueva vista, la cual podemos

ver en la ilustración 23. Es necesario que el terapeuta rellene todos los campos

para que el registro quede almacenado en la base de datos, si por el contrario

alguno de estos no se ha completado, aparecerá una alerta comunicándolo

(ilustración 24).

El terapeuta debe rellenar el nombre del niño “nombre”, su propio nombre

“terapeuta” y seleccionar del desplegable el centro en el que se encuentran.

Tras pulsar sobre el botón “Guardar”, estos datos quedarán almacenados,

y volverá a aparecer la pantalla inicial, con el usuario ya añadido.

Ilustración 23. Manual de usuario. Ilustración 24. Manual de usuario.

Vista añadir usuario Aviso completar campos



Una vez el terapeuta selecciona de la lista principal el alumno con el cual

está trabajando, se verá una dialogo para la confirmación de este, en la cual se

muestra el nombre del alumno, el del terapeuta y el centro o asociación en el que

se encuentran. Además, desde esta vista se podrá realizar la eliminación del

usuario, cuyo botón se identifica con el icono de una papelera (ilustración 25.).

Si se pulsa sobre el botón “Jugar”, aparecerá una pantalla para la selección

de juego.

Ilustración 25. Manual de usuario. Vista de jugador



Si el terapeuta considera necesario el borrado de algún alumno, es

necesario pulsar sobre la papelera comentada anteriormente. Al pulsar sobre ella

aparecerá un dialogo de confirmación, el cual podemos ver en la ilustración 26.,

para evitar fallos y borrados no deseados.

Ilustración 26. Manual de usuario. Confirmación de borrado



Una vez hemos llegado a la vista de selección de juego, (ilustración 27.)

podemos ver en la parte superior, el nombre completo del usuario, a continuación

el botón “Número de ejemplos” y debajo de este, la imagen característica de

cada uno de los diferentes juegos que, al pulsar sobre cualquiera de ellas, se

abre el juego correspondiente.

Ilustración 27. Manual de usuario. Vista selección de juegos

Justo debajo del botón imagen de cada juego, el terapeuta puede

comprobar el número de pregunta por la que el usuario va y el número de

preguntas que este ha respondido sin cometer ningún error.



El botón “Número de ejemplos” de dicha vista, abre un configurador que

podemos observar en la ilustración 28., para que el terapeuta seleccione el

número de preguntas totalmente guiadas que considera oportuno que se

reproduzcan al iniciar cualquiera de los distintos juegos.

Por defecto y en caso de seleccionar “0 Ejemplos”, no se reproduce

ninguna de estas preguntas ejemplo.

Ilustración 28. Manual de usuario. Configurador de número de ejemplos



En el caso de que el terapeuta seleccione “El cohete de las sílabas”,

comenzará el juego con su correspondiente audio. Como podemos ver en la

ilustración 29., la interfaz es muy sencilla. Esta consta de la imagen de un cohete

junto con el objeto ejemplo, de un cubo de basura situado debajo de este, y de

las tres opciones colocadas a la izquierda de la pantalla. En la parte superior,

podemos ver el sistema de gamificación, nueve estrellas (ya que el juego consta

de nueve preguntas), las cuales se irán coloreando de amarillo según el jugador

responda distintos niveles sin cometer ningún error.

Al pulsar sobre las distintas opciones o la imagen de ejemplo, se

reproducirá su nombre.

El jugador debe arrastrar hacia el cohete las dos imágenes que identifique

con la misma sílaba inicial que la de la imagen de ejemplo. La que no comience

con la misma sílaba que esta, el jugador deberá arrastrarla hacia la imagen de

la basura.

Ilustración 29. Manual de usuario. Vista “El cohete de las sílabas”



Cuando el jugador mueve una de las imágenes, la aplicación comprueba si

esto se ha realizado de manera correcta o no. Si el alumno ha cometido un fallo,

la imagen movida volverá a situarse en su posición inicial, a la vez que se

reproduce un audio explicando el motivo del fallo.

Una vez se hayan colocado las tres opciones, aparecerá una vista donde

se verá el cohete con una animación (ilustración 30.).

El terapeuta debe pulsar sobre el botón continuar para empezar el siguiente

nivel.

Ilustración 30. Manual de usuario. Vista de finalización de nivel del cohete



En el caso en que el terapeuta seleccione “El gnomo de la rima”, comenzará

este juego.

En la vista (ilustración 31.), podremos ver en la parte superior el sistema de

gamificación: diez estrellas (ya que el juego consta de diez preguntas), las cuales

se irán coloreando de amarillo según el jugador responda distintos niveles sin

cometer ningún error. A continuación se observan las imágenes de las dos

opciones que el jugador debe mover. En la esquina inferior izquierda, podemos

ver la seta, con el objeto ejemplo sobrepuesto, a su derecha, el gnomo y para

finalizar, la imagen de la papelera.

Al pulsar sobre las distintas opciones o la imagen de ejemplo, se

reproducirá su nombre.

El jugador debe llevar al gnomo la opción que identifique con la misma rima

que la palabra de ejemplo. La otra opción debe ser arrastrada hacia la papelera.

Ilustración 31. Manual usuario. Vista “El gnomo de la rima”



Cuando el jugador mueve una de las imágenes, la aplicación comprueba si

esto se ha realizado de manera correcta o no. Si el alumno ha cometido un fallo,

la imagen movida volverá a situarse en su posición inicial, a la vez que se

reproduce un audio explicando el motivo del fallo. Cuando se arrastra una de las

opciones hasta el gnomo, comenzará una animación de movimiento.

Una vez se hayan colocado las dos opciones, aparecerá una vista

mostrando la seta (ilustración 32.).

El terapeuta debe pulsar sobre el botón continuar para empezar el siguiente

nivel.

Ilustración 32. Manual de usuario. Vista de finalización de nivel del gnomo



Una vez el jugador haya acabado todos los niveles disponibles en

cualquiera de los dos juegos propuestos, se mostrará una vista comunicando la

finalización del juego como podemos ver a continuación en la ilustración 33.

Para volver a comenzar de nuevo el juego finalizado, se debe pulsar sobre

el botón continuar.

Ilustración 33. Manual de usuario. Vista final de juego



Si el terapeuta o jugador pulsa sobre continuar, aparecerá un dialogo, el

cual se muestra en la siguiente ilustración 27., para confirmar la acción, ya que

posible que se pulse por equivocación.

Si la opción pulsada es “SI”, el juego volverá a comenzar. En caso contrario,

volverá a aparecer la vista de selección de juego (ilustración 34)

Cuando el terapeuta vuelve a seleccionar el juego ya acabado, volverá a

aparecer el dialogo de confirmación.

Ilustración 34. Manual de usuario. Dialogo de confirmación.



ANEXO II. DIAGRAMA DE CLASES

Una vez finalizada la aplicación, se muestra un diagrama de clases

(ilustración 35) creadas para su desarrollo y una breve descripción de las

funciones básicas de cada una de ellas.

Ilustración 35. Diagrama de clases

MainActivity

Actividad principal que se ejecuta al iniciar la aplicación. Corresponde con

la vista de los distintos usuarios registrados.

DBConst

Contiene la definición de los nombres de las tablas y las columnas de la

base de datos para un uso global.



DbHelper

Clase que permitirá comunicar nuestra aplicación con la base de datos. Se

trata de una clase abstracta que nos provee los mecanismos básicos para la

relación entre la aplicación Android y la información.

DAOCoheteSílabas

Clase que permite el acceso a la tabla almacenada en la base de datos

“Cohete de las sílabas” facilitando así las operaciones de lectura, insertado,

actualización o eliminado de dicha tabla.

DAOGnomoRima


“Gnomo de la rima” facilitando así las operaciones de lectura, insertado,


DAOUsuario


“Usuario” facilitando así las operaciones de lectura, insertado, actualización o

eliminado de dicha tabla.

DAOJuego


“Juego” facilitando así las operaciones de lectura, insertado, actualización o

eliminado de dicha tabla.

DAOProgreso


“Cohete de las sílabas” facilitando así las operaciones de lectura, insertado,


CoheteSílabas

Clase que contiene todo el código correspondiente a la ejecución del juego

“El cohete de las sílabas”.



GnomoRima

Clase que contiene todo el código correspondiente a la ejecución del juego

“El gnomo de la rima”.

Pregunta

Representa la estructura para el almacenamiento de las preguntas

utilizadas en los distintos juegos.

Usuario

Modelo que define el conjunto de variables que representa a un usuario de

la aplicación.

NuevoUsuario

Clase con el código correspondiente a la interacción de la aplicación con el

usuario para añadir un nuevo jugador a esta.



ANEXO III. COMPONENTES ANDROID

A continuación se detallan los componentes básicos de Android utilizados

en el desarrollo de la aplicación.

Activity

Una actividad o activity permite la creación de componentes que

interaccionan con el usuario. Cada actividad está conformada por dos partes: la

parte lógica y la parte gráfica.

La parte lógica es un archivo .java que es la clase que se crea para poder

manipular, interactuar y colocar el código de esa actividad, la cual debe heredar

de la clase Activity. La parte gráfica se define mediante un archivo XML llamado

vista o view, el cual constituye el conjunto de elementos gráficos que se

presentan al usuario para que interaccione con el sistema. Por ejemplo los

botones o las cajas de texto entre otros.

La clase Activity proporciona un conjunto de métodos que se ejecutan como

consecuencia de la generación de diversos eventos. Atendiendo a estos

eventos, una actividad pasa por diferentes estados de su ciclo de vida (ver

ilustración 36.): Created, Started, Resumed, Running, Paused, Stopped,

Restarted y Destroyed. Los métodos asociados a estos eventos son,

respectivamente: onCreate(), onStart(), onResume(), onPause(), onStop(),

onRestart() y, por último, onDestroy(), teniendo en cuenta que el estado Running

no está asociado a ningún evento.



Ilustración 36. Ciclo de vida de una activity

Intent

Una intención o intent es un componente básico de Android que permite el

envío de mensajes entre componentes. El paso de mensajes a través de intents

puede considerarse una facilidad para asociar componentes de forma tardía y

en tiempo de ejecución en la misma aplicación o entre diferentes aplicaciones.

Los objetos de la clase Intent se utilizan para especificar acciones que se

desean llevar a cabo. Por ejemplo, iniciar una nueva actividad desde otra

actividad es una acción que se debe realizar mediante un Intent. En este caso

hablamos de Intent explícito, ya que especificamos qué componente debe

ejecutarse.



En cada Intent es posible incluir datos extras en pares clave/valor,

permitiendo así la transferencia de dichos datos entre distintos componentes.

Aplicación móvil para el aprendizaje de habilidades en...

Documents

Transcript of Aplicación móvil para el aprendizaje de habilidades en...