Universidad ORT Uruguay

Facultad de Ingeniería

EduGames: juego educativo enfocado en la

lectura utilizando la metodología global

Entregado como requisito para la obtención del título de Licenciatura en Sistemas

Mónica Carle – 4039

Rodolfo Olivera – 154985

Tutores:
Luis Calabria
Rafael Cohen

2013
Declaración de Autoría

Nosotros, Mónica Carle y Rodolfo Olivera, declaramos que el trabajo que se presenta en esa
obra es de nuestra propia mano. Podemos asegurar que:

- La obra fue producida en su totalidad mientras realizábamos el proyecto de grado;

- Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;

- Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas
citas, la obra es enteramente nuestra;

- En la obra, hemos acusado recibo de las ayudas recibidas;

- Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado
claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;

- Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se
han realizado las aclaraciones correspondientes.

Mónica Carle Rodolfo Olivera

12/09/2013 12/09/2013

2
Agradecimientos

En primer lugar queremos agradecer a nuestros tutores, Luis Calabria y Rafael Cohen, por el
apoyo incondicional brindado a lo largo del proyecto.

A Rosario Castro, subdirectora del instituto CEI (Centro de Educación Individualizada), quien
fue nuestro cliente principal para lograr el éxito del proyecto. En este centro de enseñanza
tuvimos la ayuda de Yanin Rosales, encargada de la parte de informática, que fue de mucha
ayuda para poder hacer pruebas con niños especiales.

A las maestras que ayudaron con ideas que fueron implementadas en su momento. Ellas son:
Virginia Gagliardini, Virginia De Tomas y Mónica Verdún.

Además queremos agradecer a las maestras de una institución privada que ayudó con las
pruebas finales. Ellas son: María José Moyano, Elisa Durán y Carolina García.

A Sebastián Villar, estudiante de la carrera de Diseño Grafico, quien trabajó realizando

gráficos para el proyecto.

Por último, y no menos importante, a nuestras familias que nos dieron el apoyo necesario para
llevar adelante este proyecto.

3
Abstract

EduGames es un juego compuesto de varios mini-juegos que tienen como objetivo principal
favorecer el aprendizaje de la lectura de los niños, dando apoyo al docente al impartir los
contenidos curriculares del Programa de Educación Inicial y Primaria, en el Área de Lengua,
en la disciplina de Lectura para cuatro y cinco años, primer y segundo grado.

Los juegos tienen intervenciones basadas en estrategias globales de lectura. Se aplicaron

técnicas de Gamification para generar motivación de ingreso a la aplicación de forma asidua.

En el equipo de trabajo surgió un especial interés en los videojuegos y en la educación en las

etapas iniciales. Movidos por este interés se creó un producto que fusiona el aprendizaje de la
lectura con un videojuego.

Para crear este producto se realizó una investigación muy fuerte en la etapa inicial del
proyecto para generar conocimientos y poder definir con mayor precisión el alcance.

Terminada esta etapa se pasó a la construcción del videojuego, que se planificó utilizando
algunas prácticas de metodologías ágiles. El proceso principal de la construcción del software
fue apoyado por procesos de soporte para asegurar la calidad del producto y gestionar
correctamente todos los aspectos del proyecto.

El resultado del proyecto fue exitoso ya que se creó el producto con las características
planteadas en la etapa de definición de requerimientos, y logrando los atributos de calidad
deseados.

4
Palabras Clave

 Gamification
 AndEngine
 Videojuego
 Android
 Tablet
 Lectura
 Método global

5
Índice

1. GLOSARIO ...................................................................................................................... 9
2. DESCRIPCIÓN DEL PROYECTO ............................................................................. 11
2.1. INTRODUCCIÓN ................................................................................................................................... 11
2.2. OBJETIVO DEL PROYECTO ................................................................................................................... 12
2.3. OBJETIVO DEL PRODUCTO .................................................................................................................. 12
2.4. DESCRIPCIÓN DEL EQUIPO................................................................................................................... 13
2.5. ALCANCE DEL PROYECTO ................................................................................................................... 14
2.6. DESCRIPCIÓN DEL PROCESO ................................................................................................................ 14
3. INGENIERÍA DE REQUERIMIENTOS .................................................................... 17
3.1. INTRODUCCIÓN ................................................................................................................................... 17
3.2. DESCRIPCIÓN DEL PROBLEMA ............................................................................................................. 17
3.3. CLIENTE Y USUARIOS .......................................................................................................................... 17
3.4. REQUERIMIENTOS FUNCIONALES ........................................................................................................ 18
3.5. REQUERIMIENTOS NO FUNCIONALES ................................................................................................... 23
3.6. ESTRATEGIA DE RELEVAMIENTO......................................................................................................... 24
3.7. IMPORTANCIA DE LOS RECURSOS MULTIMEDIA ................................................................................... 25
3.8. GDD Y TDD ....................................................................................................................................... 26
3.9. PROTOTIPOS ........................................................................................................................................ 27
3.10. CONCLUSIONES ................................................................................................................................... 27
4. DISEÑO ARQUITECTÓNICO .................................................................................... 28
4.1. INTRODUCCIÓN ................................................................................................................................... 28
4.2. COMPONENTES DEL DESARROLLO....................................................................................................... 28
4.2.1. Elección de la herramienta de desarrollo....................................................................................... 29
4.2.2. Elección de la plataforma .............................................................................................................. 30
4.3. VISTAS ................................................................................................................................................ 31
4.3.1. Vista de despliegue ....................................................................................................................... 31
4.3.2. Vista lógica.................................................................................................................................... 32
4.3.3. Vista de comportamiento .............................................................................................................. 33
4.4. DECISIONES DE DISEÑO ....................................................................................................................... 34
4.4.1. Estructura ...................................................................................................................................... 35
4.4.2. Acelerómetro ................................................................................................................................. 35
4.4.3. Intercambio de información .......................................................................................................... 36
4.4.4. Elección del Motor ........................................................................................................................ 36
4.5. CONCLUSIONES ................................................................................................................................... 37
5. GESTIÓN DE LOS ELEMENTOS DE LA CONFIGURACIÓN............................. 38
5.1. RESPONSABILIDADES DEL RSCM ....................................................................................................... 38

6
 5.2. ECS IDENTIFICADOS ........................................................................................................................... 38
5.2.1. Documentos................................................................................................................................... 38
5.2.2. Código fuente ................................................................................................................................ 39
5.2.3. Recursos multimedia ..................................................................................................................... 39
5.3. HERRAMIENTAS .................................................................................................................................. 39
5.4. METODOLOGÍAS UTILIZADAS PARA EL VERSIONADO .......................................................................... 40
5.5. RESPALDOS ......................................................................................................................................... 40
5.5.1. Problemas enfrentados .................................................................................................................. 40
5.6. CONCLUSIONES ................................................................................................................................... 41
6. GESTIÓN DE LA CALIDAD ....................................................................................... 42
6.1. INTRODUCCIÓN ................................................................................................................................... 42
6.2. PROCESO DE ASEGURAMIENTO DE LA CALIDAD .................................................................................. 42
6.2.1. Actividades del proceso ................................................................................................................ 42
6.2.2. Definición de estándares ............................................................................................................... 43
6.3. MÉTRICAS........................................................................................................................................... 45
6.3.1. Métricas del proceso...................................................................................................................... 45
6.3.2. Métricas del producto .................................................................................................................... 46
6.4. DATOS OBTENIDOS ............................................................................................................................. 47
6.5. CONCLUSIONES ................................................................................................................................... 48
7. GESTIÓN DEL PROYECTO ....................................................................................... 50
7.1. CICLO DE VIDA.................................................................................................................................... 50
7.1.1. Preproducción ............................................................................................................................... 51
7.1.2. Producción .................................................................................................................................... 52
7.1.3. Liberación ..................................................................................................................................... 53
7.2. CRONOGRAMA .................................................................................................................................... 54
7.3. CRONOGRAMA DE RECURSOS GRÁFICOS ............................................................................................. 55
7.4. CRONOGRAMA DE RECURSOS DE SONIDO ............................................................................................ 56
7.5. ENTREGABLES POR FASE ..................................................................................................................... 56
7.5.1. Preproducción ............................................................................................................................... 56
7.5.2. Producción .................................................................................................................................... 57
7.5.3. Liberación ..................................................................................................................................... 57
7.6. ESFUERZO ........................................................................................................................................... 57
7.7. RIESGOS.............................................................................................................................................. 59
7.7.1. Riesgos encontrados ...................................................................................................................... 60
7.7.2. Evolución y reevaluación de riesgos ............................................................................................. 65
7.7.2.1. Evaluación abril/2013 ............................................................................................................... 65
7.7.2.2. Evaluación mayo/2013 ............................................................................................................. 65
7.7.2.3. Evaluación junio/2013 .............................................................................................................. 66
7.7.2.4. Evaluación julio/2013 ............................................................................................................... 66
7.7.2.5. Evaluación agosto/2013............................................................................................................ 67
7
 7.8. EVOLUCIÓN DE LOS PRINCIPALES RIESGOS ......................................................................................... 69
7.9. CONCLUSIONES ................................................................................................................................... 70
8. INVESTIGACIÓN EDUCATIVA ................................................................................ 71
8.1. OBJETIVO GENERAL ............................................................................................................................ 71
8.2. OBJETIVO ESPECÍFICO ......................................................................................................................... 71
8.3. MARCO TEÓRICO ................................................................................................................................ 71
8.4. FORMULACIÓN DEL PROBLEMA CON TÉRMINOS OPERATIVOS ............................................................. 74
8.5. PROCEDIMIENTO PARA EL RELEVAMIENTO DE DATOS ......................................................................... 74
8.6. DATOS OBTENIDOS ............................................................................................................................. 74
8.6.1. Observación directa ....................................................................................................................... 75
8.6.1. Encuesta a docentes ....................................................................................................................... 75
8.6.1. Datos provenientes de la aplicación .............................................................................................. 76
8.7. CONCLUSIONES ................................................................................................................................... 78
9. CONCLUSIONES .......................................................................................................... 79
9.1. LOGROS OBTENIDOS ........................................................................................................................... 79
9.2. LECCIONES APRENDIDAS .................................................................................................................... 80
9.3. CONCLUSIONES GENERALES ............................................................................................................... 81
10. REFERENCIAS BIBLIOGRÁFICAS ..................................................................... 82
ANEXOS ................................................................................................................................. 83
ANEXO 1 - GAME CONCEPT............................................................................................................................... 83
ANEXO 2 - GAME DESIGN DOCUMENT .............................................................................................................. 90
ANEXO 3 - TECHNICAL DESIGN DOCUMENT ................................................................................................... 109
ANEXO 4 - PLAN DE PROYECTO ....................................................................................................................... 135
ANEXO 5 - PLAN DE CALIDAD ......................................................................................................................... 175
ANEXO 6 - PLAN DE SCM ............................................................................................................................... 202
ANEXO 7 – GAMIFICATION .............................................................................................................................. 207
ANEXO 8 - MÉTODO GLOBAL DE LECTURA ...................................................................................................... 216
ANEXO 9 - INVESTIGACIÓN SOBRE APLICACIÓN EDUCATIVA ........................................................................... 224
ANEXO 10 - GRÁFICOS Y FIGURAS................................................................................................................... 255

8
1. Glosario

ANDROID: Es un sistema operativo basado en Linux diseñando principalmente para

dispositivos móviles con pantalla táctil como teléfonos inteligentes o tablets desarrollado por
Google.

ANDENGINE: Es un motor para el desarrollo de videojuegos, creado por Nicolas Gramlich.

FODA: El análisis FODA es una metodología de estudio de la situación de una empresa o

proyecto, analizando sus características internas (Debilidades y Fortalezas) y su situación
externa (Amenazas y Oportunidades).

GAMELAB: Laboratorio de Simulación y Juegos de la Universidad ORT Uruguay.

GAMIFICATION: Gamificación se refiere al uso de atributos del juego para encauzar el

comportamiento lúdico, en ambientes no lúdicos con el fin de hacer las actividades más
atractivas, convincentes y conseguir un mayor compromiso de los participantes.

Dr. GLENN DOMAN: Médico estadounidense, comenzó a dedicarse al tratamiento de los

niños con lesiones cerebrales con el neurólogo Temple Fay. Utilizaba sus métodos, basadas
en movimientos progresivos, muy eficaces tanto en áreas motrices como en áreas más
intelectuales. Se centraban en el trabajo con los reflejos, fundamentalmente con niños con
parálisis cerebral. Al observar los progresos que se conseguían en estos niños, Doman decide
trasladar sus conocimientos al resto de los niños, de manera que se potenciara su capacidad de
aprendizaje. Elabora su teoría acerca del desarrollo cerebral, un Perfil del Desarrollo
Neurológico y sistematiza una labor educativa, estructurada mediante programas
secuenciados, con métodos precisos y eficaces. Funda a finales de los años 50 los Institutos
para el Desarrollo del Potencial Humano en Filadelfia (EEUU), iniciando lo que Doman y sus
discípulos han llamado, una “Revolución Pacífica”.

JAVA: Lenguaje de programación. Las aplicaciones de Java son generalmente compiladas a

bytecode (clase Java) que puede ejecutarse en cualquier máquina virtual Java (JVM) sin
importar la arquitectura de la computadora subyacente. Java es un lenguaje de programación
9
de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado
específicamente para tener tan pocas dependencias de implementación como fuera posible.
OPEN-DISLEXIC: Fuente de texto creada con el fin de aumentar la legibilidad para los
lectores con dislexia.

PLAN CEIBAL: Programa para la Conectividad Educativa de Informática Básica para el

Aprendizaje en Línea, tendiente a promover la inclusión digital para un mayor y mejor acceso
a la educación y a la cultura. Con el Plan Ceibal cada alumno y cada maestro de las escuelas
públicas de todo el país reciben de forma gratuita una computadora portátil. Busca promover
la inclusión digital, con el fin de disminuir la brecha digital tanto respecto a otros países,
como entre los ciudadanos de Uruguay, de manera de posibilitar un mayor y mejor acceso a la
educación y a la cultura.

QLIKVIEW: Es el producto líder en cuanto a análisis en memoria y la plataforma BI que

observa un mayor crecimiento a nivel mundial. QlikView está liderando un nuevo tipo de
soluciones de Análisis Empresarial rápidas y flexibles, de fácil manejo, que permiten a los
individuos mejorar el rendimiento empresarial y aportar innovación. Emplea tecnología
asociativa patentada de última generación para un análisis y una cobertura sofisticados,
considerablemente mucho más fáciles de implementar, mantener y utilizar.

PYTHON: Es un lenguaje de programación multiparadigma, ya que soporta orientación a

objetos, programación imperativa y, en menor medida, programación funcional. Es
un lenguaje interpretado, usa tipado dinámico y es multiplataforma. La mayor parte del
software para las XO está escrito en Python porque su plataforma Sugar (basada en Linux
como sistema operativo) también es escrita en Python.

STORY BOARD: Conjunto de ilustraciones que muestran la secuencia de todas las pantallas
del juego con el objetivo de servir de guía para entender su historia.

TABLET: Es una computadora portátil de mayor tamaño que un teléfono inteligente

integrado en una pantalla táctil con la que se interactúa primariamente con los dedos, sin
necesidad de un teclado físico ni ratón.

10
2. Descripción del Proyecto
2.1. Introducción

El proyecto tiene su origen en la experiencia de trabajo de uno de los integrantes del equipo,
en la escuela especial de Montevideo Nº 206, donde se utilizaron metodologías globales de
lectura. Allí se trabajó siguiendo lineamientos del método del Dr. Glenn Doman donde
básicamente se trata de mostrar al niño series de tarjetas con palabras de una categoría,
escritas con letras grandes, de forma rápida varias veces al día. De a poco se van incluyendo
otras categorías. Esta forma de trabajo está dentro de lo que se llaman las metodologías de
lectura global, las cuales parten del reconocimiento de unidades complejas con significado:
palabras o frases, para que luego en una etapa posterior se discriminen las unidades más
simples que la componen: sílabas o letras.

Por otra parte el plan Ceibal logró la universalización del acceso a la informática otorgando a
cada niño de las escuelas públicas, una computadora. Con este suceso en las escuelas
públicas, la informática ya no es una materia aparte, sino que pasó a ser un área transversal
empleándose como una herramienta para impartir otras asignaturas.

Como respuesta a los hechos antes mencionados, nos interesó integrar aspectos de la
metodología de enseñanza de la lectura global a un videojuego, con lo cual estaremos
ampliando el uso de las herramientas tecnológicas en la educación.
Si bien pensábamos que nuestra idea era valiosa, necesitábamos el aval de otras profesionales
para plantear con mayor fundamento nuestra propuesta. Es así que nos comunicamos con
Rosario Castro, maestra especializada en el área de discapacidad y dificultades de aprendizaje
y quien usa en su labor docente herramientas tecnológicas (XO, PC, Teléfonos móviles). Le
explicamos nuestra idea y aceptó ser asesora experta para la realización del Proyecto.

Inicialmente nos planteamos el desarrollo del videojuego para las computadoras del Plan
Ceibal llamadas XO, usando el lenguaje Python, por ser el lenguaje que mejor se adapta a
estos equipos. Posteriormente al recibir la noticia de que el Plan Ceibal lanzaría un plan piloto
entregando 10.000 tablets, decidimos cambiar de plataforma pasando a desarrollar en Android
para dispositivos móviles.

11
Para poder aplicar la estrategia de lectura planificada es necesario que los niños se interesen
por el videojuego e ingresen en forma asidua a la aplicación. Con el fin de lograr este objetivo
se aplicaron técnicas de Gamification.

En este marco de trabajo consideramos que tiene fundamental importancia realizar un análisis
de los resultados del videojuego en cuanto a la incidencia en el aprendizaje de la lectura.
También interesa investigar cómo responden los niños de diferentes contextos escolares a una
aplicación educativa de este tipo. Para este motivo se ha planteado una investigación que
indague sobre ambos aspectos.

2.2. Objetivo del proyecto

El objetivo del proyecto es el de realizar un videojuego en dos dimensiones para dispositivos

móviles, el cual favorezca el aprendizaje de la lectura de los niños, dando apoyo al docente al
impartir los contenidos curriculares del Programa de Educación Inicial y Primaria, en el Área
de Lengua, en la disciplina de Lectura para cuatro y cinco años, primer y segundo grado.

2.3. Objetivo del Producto

El objetivo principal es hacer un videojuego 2D para dispositivos móviles con Sistema

Operativo Android, en especial las Tablets utilizadas dentro del denominado Plan Ceibal.

Otro objetivo es que la aplicación proporcione datos sobre la forma en que se usa el juego,
con el fin de realizar estadísticas usando dicha información.

12
 2.4. Descripción del equipo

Este proyecto fue realizado como requisito para la obtención del título de Licenciado en
Sistemas de la Universidad ORT Uruguay. Los integrantes del equipo son los encargados de
llevar a cabo el proyecto, la construcción del videojuego, la realización de pruebas y la
entrega final de la tesis. Los estudiantes que formamos el equipo son: Mónica Carle y Rodolfo
Olivera compañeros de generación desde que comenzaron la carrera.

Para poder gestionar mejor el proyecto, se identificaron roles de trabajo los cuales se fueron
rotando entre ambos integrantes del equipo. Estos roles no significan que los integrantes
realizaron exclusivamente tareas relacionadas a su rol, pero por la experiencia, el gusto
personal y habilidades particulares tomaron la dirección en el área correspondiente al rol.

 Gerente de proyecto – Rodolfo Olivera

 Game Designer – Mónica Carle
 Arquitecto – Rodolfo Olivera
 Responsable SQA – Mónica Carle
 Responsable SCM – Rodolfo Olivera
 Desarrollador de Interfaz – Mónica Carle
 Desarrollador de Dominio – Rodolfo Olivera

Luis Calabria y Rafael Cohen fueron los tutores asignados. L. Calabria es docente y
coordinador del GameLab de la Universidad ORT Uruguay.

R. Cohen es Master en Gestión Educativa de la Universidad ORT Uruguay, tiene además el

Diploma en Planificación y Gestión de Centros Educativos en la misma universidad.

El cliente principal del proyecto es Rosario Castro, maestra especializada en el área de

discapacidad y dificultades de aprendizaje. Actualmente trabaja como subdirectora en el
Centro de Educación Individualizada (CEI) y como maestra de apoyo en el equipo
multidisciplinario de la misma institución. Además trabajo en el Instituto Psicopedagógico del
Uruguay (IPPU) como maestra de apoyo en la Clínica de diagnóstico y tratamiento de las
dificultades de aprendizaje. Ella utiliza con frecuencia en su labor docente herramientas tales
13
como videojuegos y aplicaciones de celulares. En las reuniones de trabajo también contamos
con el apoyo de maestras de la escuela especial Nº 206: Virginia de Tomas, Mónica Verdún y
Virginia Gagliardini.

2.5. Alcance del proyecto

El producto principal del proyecto es el videojuego didáctico. Para definir la idea fuerza del
mismo se elaborará el documento Game Concept. En éste documento se presentarán las
características principales del juego, los objetivos que se plantea, el soporte tecnológico que
usará con el fin de realizar un primer acercamiento al juego. Por otra parte se elaborará el
documento llamado Game Design Document en el cual se especifican los requerimientos
funcionales, recursos y los elementos necesarios para la construcción del videojuego.

2.6. Descripción del proceso

En la definición del proceso de desarrollo se utilizó un proceso previamente definido para el

desarrollo de videojuegos por el GameLab. Este proceso está dividió en 3 etapas:
preproducción, producción y liberación.

El equipo acordó trabajar en ciclos de dos semanas planteándose objetivos, planificando y

estimando las tareas para ese período, en base a la disponibilidad de trabajo de los integrantes
del equipo. No necesariamente se generaron entregables para cada ciclo.

Las reuniones con el cliente se realizaron con mayor frecuencia al inicio del proyecto
(quincenal), donde se definieron los requerimientos para el videojuego. Luego se realizaron
reuniones para mostrar los avances realizados y realizar una validación del trabajo presentado,
disminuyendo la frecuencia (mensual) de las reuniones.

Durante todo el proyecto el equipo se reunió una vez por semana con el tutor, para ir
mostrando el avance realizado y obtener el asesoramiento de manera constante.

La etapa de preproducción ocupó un extenso proceso de investigación y desarrollo de

prototipos. Al inicio de la misma se investigó la plataforma Sugar pensando en desarrollar el
juego para las XO. Posteriormente se tuvo la noticia de que el Plan Ceibal lanzaría un plan
14
piloto para tablets con Android [1], esto generó la realización de un análisis FODA sobre
ambas plataformas: Sugar y Android. A partir de este análisis se optó por cambiar a Android.
Ver Anexo Nº 3 Technical Design Document.

Además de la decisión sobre plataforma a usar, se abarcaron temas como: técnicas de

Gamification, selección de motor para desarrollar el videojuego, estándares a aplicar,
herramientas de gestión, entre otros.

También se realizó la definición de los requerimientos, para ello se creó un blog el cual
facilitó la comunicación con las maestras que trabajaron en el proyecto. A partir de esta
definición se crearon los documentos: Game Design Document (GDD) y Technical Design
Document (TDD). En el GDD se especificaron los requerimientos funcionales del juego y en
el TDD describe los atributos de calidad y la arquitectura del videojuego. Se seleccionaron las
herramientas que según las características del proyecto serían las más adecuadas. Ver Anexo
Nº 6 Plan de SCM.

Posteriormente se trabajó para obtener los recursos gráficos, para lo cual nos contactamos con
Sebastián Villar, estudiante de la carrera de Diseño Gráfico de la Universidad ORT Uruguay,
quien trabajó en forma voluntaria para el proyecto. Se realizaron reuniones para explicar la
idea del proyecto y se obtuvieron los primeros gráficos marcando ya el diseño que se iba a
seguir. Se desarrollaron los primeros prototipos que permitieron constatar las posibilidades
que ofrecía el motor elegido. Paralelamente a esta etapa se cursó la materia electiva
Programación de Videojuegos, esto permitió profundizar el conocimiento sobre desarrollo de
videojuegos.

En la etapa de la producción, se realizaron los primeros prototipos, en los cuales se

implementó la en primer lugar la estructura de navegación principal y todas las escenas
referidas a la intervención didáctica. Se presentó el prototipo al cliente para validarlo
obteniendo un conjunto de correcciones y ajustes que fue traducido en tareas. Se continuó
trabajando con el diseñador gráfico en la producción de las imágenes para el juego. Con
respecto a los recursos de sonido se realizó el taller “Audio para videojuegos”, el cual sirvió
para tener los fundamentos básicos que permitieron seleccionar y adaptar recursos para el
videojuego. Posteriormente se realizaron prototipos más completos incluyendo los ajustes

15
solicitados por el cliente. Además de comenzó a desarrollar una investigación educativa para
ver la incidencia del videojuego en el aprendizaje de la lectura.

La última etapa fue la liberación. En esta etapa se realizaron pruebas de campo en diversas
instituciones educativas. También se realizaron las actividades de cierre del proyecto, como
por ejemplo el registro de errores encontrados, el análisis de los resultados obtenidos y la
finalización de la documentación.

16
3. Ingeniería de requerimientos

3.1. Introducción

En esta sección se describe el proceso utilizado por el equipo para definir los requerimientos
del proyecto. Se introducirá al cliente, se detallarán los requerimientos funcionales así como
también los no funcionales. Se mencionarán cuáles fueron las técnicas de relevamiento.

3.2. Descripción del problema

El problema que se presenta en este proyecto es el de la construcción de un videojuego de

aventura, acción, estrategia y colaboración, en un mundo 2D didáctico que propone
experimentar diferentes experiencias en un viaje de aventura. A medida que el juego avanza y
al finalizar cada sesión de juego aparecerán intervenciones usando metodologías globales de
lectura. Esta intervención mostrará una palabra con su respectiva imagen y sonido. La palabra
pertenece a un conjunto de categorías, entre ellas se encuentran animales, comidas, cuerpo
humano, etc.

3.3. Cliente y usuarios

Como se explicó en la sección 2.4, el cliente fue la maestra subdirectora del CEI Rosario
Castro. Como la idea surgió por parte de los integrantes del equipo, el cliente oficializó como
asesora técnica, que ayudó al equipo a definir los principales requerimientos didácticos del
videojuego. Con la ayuda de Rosario y la idea que impulsó este proyecto, se definieron la
mayoría de los requerimientos que se listan en esta sección.

Como se definió en el Game Concept (Anexo 1 - Game Concept), los potenciales usuarios
serán niños de edad comprendida entre 4 y 7 años quienes están incorporando conceptos de
lectura o niños con discapacidad intelectual de cualquier edad, para quienes los métodos
globales de aprendizaje de la lectura son muy favorables.

17
 3.4. Requerimientos funcionales

En esta sección se detallan los principales requerimientos funcionales. Para ver el detalle de
cada uno de ellos y la totalidad de los requerimientos definidos véase el GDD (Anexo 2 -
Game Design Document).

Desde el área de videojuegos aprendimos una técnica que se basa en crear una historia que
contextualiza al jugador y permite enfocar a los involucrados (programadores, diseñadores,
etc.) en realizar lo necesario para que tenga éxito el videojuego (ver figura 1). La historia de
EduGames presentada en la pantalla inicial introduce al juego con una propuesta de participar
de diferentes experiencias en un viaje de aventuras.

Figura 1. Historia del videojuego.

Como se describió anteriormente el videojuego surgió como la fusión entre varios mini juegos
y la las estrategias globales de lectura. La forma de lograr esta unión fue mediante la
aplicación de Gamification (Anexo 7 - Gamification). Utilizando estas herramientas vimos la
motivación de terminar estos mini juegos asociada al aprendizaje de las palabras. Mostrando
distintos premios es que el jugador va logrando el avance deseado en la lectura. El cliente

18
solicitó un fácil acceso a todas las funcionalidades del juego. Esto se refleja en el menú
principal (ver figura 2).

Figura 2. Menú Principal.

El gameplay de uno de los juegos, las naves (ver figura 3), se enfoca en la destreza del
jugador para realizar los diversos desafíos que se presentan, mientras que en el laberinto (ver
figura 4) se enfoca más a la exploración y la estrategia. Por último, el juego de memoria
apunta a la colaboración, permitiendo su mecánica la participación de más de un jugador.

19
 Figura 3. Juego de naves.

Figura 4. Juego laberinto.

Existirán tres modalidades de juego: individual, invitado y maestra. La modalidad individual,

donde el jugador competirá consigo mismo avanza por los distintos niveles del videojuego. A
medida que avanza se van registrando sus logros en una mochila, la cual puede consultar en el

20
menú principal. El modo invitado es utilizado para que el niño pueda prestar la Tablet para
que otro niño juegue pero que no avance en sus logros. Para que las maestras utilicen la
aplicación en clase y que todos los niños jueguen sobre una categoría común se debe realizar
la modalidad maestra. Esta modalidad utilizará un juego de realización compartida como es el
de memoria.

Para el personaje de todo el videojuego se va a tener en cuenta las preferencias del jugador
con respecto al sexo y al color preferido. Para recabar estos datos debe haber una pantalla que
permita recoger estos datos y un apodo y su edad (ver figura 5).

Figura 5. Ingreso de datos.

Uno de los requerimientos más importantes del juego es la intervención didáctica (ver figura
6). Esta intervención se muestra a partir del objeto descubierto en alguno de los juegos. Se
muestra la palabra, en los primeros niveles se repite dos veces con el sonido correspondiente.
En niveles superiores también se muestra una frase que emplea la palabra. Todas las palabras
fueron previamente seleccionadas con criterios didácticos por las docentes que trabajaron en
el proyecto.

21
 Figura 6. Intervención didáctica.

Otro de los requerimientos solicitados por el cliente es la pantalla de evaluación, la cual tuvo
mucho éxito ya que fue elogiada por los docentes y bien recibida por los niños. Básicamente
se trata de asociar las palabras vistas con la imagen correspondiente (ver figura 7).

Figura 7. Evaluación.

22
 3.5. Requerimientos no funcionales

Para ver la totalidad de los mismos véase el TDD (Anexo 3 - Technical Design Document).
Sobre los principales requerimientos no funcionales cabe destacar los siguientes:

 Hardware y software: La versión mínima de Android que deben tener instalada los
dispositivos es la 4.1.2 (API Level 16). El dispositivo debe tener una pantalla táctil.
Para ejecutar el videojuego correctamente, se recomienda las siguientes características
del dispositivo:
o Memoria RAM: 512 GB
o Procesador: dual core 1.0 GHz
o GPU: cuatro núcleos 267-400 Mhz
o Resolución 800 x 600 (WSVGA)

 Performance: Para dar sensación de suavidad, el juego debe correr como mínimo a 24
FPS. Al iniciar el juego, el tiempo de carga deberá ser menor a 7 segundos. Al
finalizar el juego, el tiempo de grabación de datos deberá ser menor a 4 segundos.

 Jugabilidad: Los comandos necesarios para dar las órdenes a las unidades tuvieron que
ser pensados para ser intuitivos. Además que el juego tuvo que evitar la linealidad
entre los distintos rounds de forma de evitar que siempre se encuentren con el mismo
desafío. Otra característica importante relativa a la jugabilidad que se debió cumplir es
que el jugador aprenda a jugar en poco tiempo (no más de 3 minutos).

 Robustez: Por cada corrida de un round, se espera alcanzar un valor menor a 0,1 fallas.
Esto se traduce a una falla cada 10 corridas.

 Modificabilidad: El juego debe quedar abierto a futuros cambios, como por ejemplo el
agregado de palabras, niveles y categorías, así como la incorporación de nuevos mini
juegos.

 Idioma: Todos los textos de la interfaz son en español. El código fuente deberá ser
escrito en inglés.
23
 3.6. Estrategia de relevamiento

El proceso que eligió el equipo para llevar adelante el proyecto tiene como foco en su primera
etapa, el relevamiento de requerimientos.

Al principio, el proyecto se iba a realizar para utilizar con los niños de las escuelas, utilizando
el Plan Ceibal y las XO, como hardware para implementar este videojuego [2]. Debido a la
investigación previa, vimos que se podía aproximar una segunda etapa en el Plan Ceibal,
donde se iba a impulsar el uso de Tablets para los niños de edad de aprendizaje de la lectura.
Luego de investigar, resolvimos volcarnos a Android y a Tablets para impulsar este proyecto.
Esto fue validado por el cliente, ya que es usuario de Tablet y por ende, contaba con
experiencia en este tipo de tecnología.

A partir de la idea que propulsó el proyecto, el equipo y el cliente comenzaron a pensar en

posibles requerimientos del juego. Estos requerimientos potenciales eran investigados por el
equipo. En algunos casos sucedió que luego de realizar el prototipo se optó por no incluir al
requerimiento debido a que no colmaba las expectativas del cliente ni del equipo.

Primero se realizaba una investigación, luego se producía el prototipo. Con el prototipo

funcional, el equipo y el cliente definían si ese requerimiento sería incluido al grupo de
requerimientos del producto.

24
 3.7. Importancia de los recursos multimedia

Los recursos gráficos en un videojuego son un factor importante en la satisfacción del

usuario. Uno de los primeros detalles que un usuario nota al jugar un videojuego es el
atractivo visual del mismo, y puede llegar a abandonarlo en caso de que no alcance sus
expectativas. También influye en la jugabilidad y el grado de interacción del usuario con la
aplicación, ya que un menú que utiliza imágenes explicativas y agradables hace que sea más
fácil de utilizar. Como muestra la siguiente figura (ver figura 8), no todos los diseños se
utilizaron, por ejemplo, el menú de la figura fue descartado.

Figura 8. Prototipo de menú descartado.

Los recursos de sonido también son muy importantes debido a que ayuda a ambientar al
usuario en el escenario del juego. También ayudan en la interacción con la aplicación, por
ejemplo, si se emite un sonido al recibir una orden por parte del usuario, el mismo sabrá que
sus acciones fueron interpretadas correctamente.

25
Debido a que el equipo no domina el área de edición de imágenes ni de sonido, se optó por
conseguir estos recursos a través de terceros. Por la parte gráfica, Sebastián Villar es quien
nos proporcionó todas las imágenes. En cuanto al sonido, un integrante del equipo realizó un
taller de sonidos para videojuegos que aportó mucho para la sonorización de todo el
videojuego. También hay que tener en cuenta que para las palabras se grabó la voz de Juan
Manuel Pacheco, un niño de 5 años. Él colaboró de gran manera con la grabación de todas las
palabras.

3.8. GDD y TDD

El objetivo primario del proyecto es la realización de un videojuego didáctico 2D, cuya

especificación se encuentra en los documentos GDD (Anexo 2) y TDD (Anexo 3).

Previo a la realización de estos documentos se redactó otro documento, el cual tiene como
objetivo presentar la idea fuerza del proyecto, brindando un primer acercamiento al juego y
sus principales características. Este documento es el Game Concept (Anexo 1).

En el GDD se presentan los requerimientos funcionales del juego, es decir la funcionalidad

del mismo, describiendo su jugabilidad. Este documento sirve como referencia al equipo de
desarrollo e integrantes de áreas involucradas (gráficos y audio) para presentar el videojuego,
ayudando en la estimación de tiempo y costo. En el GDD se especifican los mecanismos del
videojuego, determinando lo que puede llegar a hacer el jugador y de qué manera.

El TDD presenta los requerimientos técnicos y características de calidad. Describe además el

diseño arquitectónico y detallado a utilizar con el objetivo de alcanzar estos requerimientos,
junto con otros aspectos técnicos del videojuego. El GDD representa una versión parcial de
un ESRE tradicional que, con la suma del TDD, forman un documento completo, el cual
detalla lo que se debe hacer y cómo realizarlo.

26
 3.9. Prototipos

Durante la preproducción se realizaron varios prototipos para tener una idea más sólida acerca
de las capacidades de las herramientas utilizadas. De esta manera, se pudo definir con más
precisión un alcance acorde al esfuerzo estimado que se dedicaría al proyecto. Cuando surgía
un nuevo requerimiento, y el equipo no estaba seguro de que se pudiera implementar, se
realizaba un pequeño prototipo en el cual se probaba esa funcionalidad en particular.

Los principales prototipos se realizaron para evaluar colisiones y sobre el motor de juego que
elegimos. Como el motor era la primera vez que lo utilizábamos fue donde realizamos la
mayor cantidad de pruebas para asegurarnos que no íbamos a encontrar inconvenientes a la
hora de implementar los requerimientos del cliente.

3.10. Conclusiones

Partiendo de una idea, se comenzó a investigar si la misma se podía llevar a cabo teniendo en
cuenta el capital humano, las herramientas existentes y las restricciones de tiempo
establecidas. En un principio no se tenía muy claro lo que se podía lograr con las herramientas
utilizadas, por lo que se realizaron una variedad de prototipos para ayudar a definir más
precisamente los requerimientos, así como estimar las tareas que habría que hacer durante el
transcurso del proyecto.

A medida que se iban realizando los prototipos, se descartaron ideas y se agregaron nuevas.
El equipo conoció las capacidades de las diferentes herramientas y ganó experiencia en la
estimación de tareas. Poco a poco se llegó a un conjunto de requerimientos estable, que
fueron los que el equipo planificó implementar para la etapa de construcción del producto.

27
4. Diseño arquitectónico

4.1. Introducción

En esta sección se describen y justifican las principales decisiones tomadas para determinar el
diseño arquitectónico del juego, el cual se especificó de manera tal de poder alcanzar los
diferentes atributos de calidad establecidos.

4.2. Componentes del desarrollo

Figura 9. Componentes necesarios para el desarrollo.

Los componentes necesarios para el desarrollo son:

 SDK Android API Level 15 o superior
 AndEngine GLES 2 como motor del videojuego
 Eclipse Juno
 Dispositivo móvil con la versión adecuada del sistema operativo

Otros componentes utilizados fueron:

 Assembla como repositorio
28
  Google Drive para gestionar tareas
 Gamification para motivar el uso del videojuego
 Blogger para publicitar y comunicarnos con el cliente

En la figura anterior se muestran todos los componentes que se utilizaron para la realización
del videojuego. Este será compilado en Eclipse, generándose así un archivo de extensión .apk
que se instala en el dispositivo móvil.

4.2.1. Elección de la herramienta de desarrollo

Desde un principio se había decidido hacer un videojuego en 2D. Cuando comenzó el

proyecto se utilizó Python para realizar prototipos de los mini juegos. Como se mencionó
anteriormente, al recibir noticias de la incorporación de Tablets al Plan Ceibal y al ver que
Android iba a ser la plataforma elegida, se decidió el cambio en las herramientas de
desarrollo.

Para poder desarrollar aplicaciones para Android, es imprescindible poseer el kit de desarrollo
de software (SDK) provisto por Google, el cual se puede descargar gratuitamente. Todas las
aplicaciones desarrolladas están comprimidas en formato apk, y se pueden instalar sin
dificultad en la mayoría de los dispositivos.

Por un lado, se iba a desarrollar en Eclipse, herramienta conocida por el equipo, y se iba a
relevar distintos frameworks para el videojuego (motores, Ver Anexo 3 - TDD). Al realizarse
prototipos varios, el equipo se decidió por AndEngine por motivos de facilidad, buena
documentación y el haber encontrado varios ejemplos que ayudaron a la rápida
implementación de los mini juegos.

Para el resguardo del código realizado se utilizó Assembla como herramienta de colaboración
y seguimiento de tareas. También utilizamos Google Drive y archivos de Google para
ayudarnos con la organización y registro de las tareas. Hablando de Google, Blogger es una
herramienta que te permite publicar contenidos sin tener que escribir código o instalar
programas de servidor o de scripting. Nosotros utilizamos Blogger para la comunicación con
el cliente y para documentar todos los requerimientos del videojuego.
29
Por último, consideramos Gamification como herramienta de unificación entre los mini
juegos y la parte didáctica del videojuego. Esto hace que el jugador quiera conseguir las
distintas palabras y así ir aprendiendo como se pronuncia y asociarla con una imagen.

4.2.2. Elección de la plataforma

En cuanto a la plataforma, se investigó e hicieron prototipos sobre Sugar, la plataforma de las

XO. Estas pruebas arrojaron que podíamos utilizarla pero el mercado parecía reducido a los
niños de más de 6 años donde la mayoría ya sabía leer.

La notica de la inclusión de Tablets con Android para niños de 4 y 5 años en el Plan Ceibal
abrió una nueva pregunta: ¿Podemos hacer el videojuego para Android?

Un integrante del equipo había realizado una materia basada en Android (Desarrollo para
dispositivos móviles) y sabía que no iba a ser un obstáculo a la hora de programar. Se utiliza
Android, un lenguaje basado en Java, lenguaje utilizado durante la carrera, y sabíamos que
hay muy buena documentación por parte de Google.

Para respaldar nuestra decisión se realizó un análisis FODA sobre ambas plataformas. La
definición del sector es: Videojuegos didácticos para niños de entre 4 y 7 años.

FODA XO-Sugar Tablet-Android

 Entorno educativo.  Mayor usabilidad a través del
 Desarrollo menos exigente. acelerómetro, teclado, touch.
 S.O. con versión estable.  Gráficos de mayor calidad.
Fortalezas

 Portable (xo similares)  Entorno de desarrollo: Java, Eclipse

 Instalación desatendida

30
FODA XO-Sugar Tablet-Android
 Canal de distribución accesible.  Mercado tiene potencialidad para
 Testeable. ampliarse.
Oportunidades

 Extender a las Tablet 3.0 del plan  Fácil acceso a estadísticas y

Ceibal feedback de usuarios.
 Se puede extender a Celulares
 Sólo usa mouse y flechas.  Entono comercial.
 Gráficos de baja calidad.  Recursos limitados
 Hardware puede quedar obsoleto.  Programación más exigente.
 
Debilidades

Entorno de desarrollo: Python- Encontrar gráficos de calidad

IDLE poco amigable. adecuada
 Recursos muy limitados  Plataforma en crecimiento, inmadura
 Asociado al plan Ceibal  Sector altamente competitivo.
 Mercado limitado.  Acceder al mercado requiere otras
Amenazas

 Política estatal pase de XO -> herramientas (e-marketing).

Tablet (reprogramación)  Poca visibilidad entre los juegos.
Figura 10. Análisis FODA.

Lo que también ayudó a la elección es que Android es gratuito, y nos fue fácil acceder a las
Tablets con Android que utilizamos como hardware para implementar el proyecto.

4.3. Vistas

La especificación del diseño se realizó en distintas vistas, las cuales ayudan a la comprensión
del mismo, presentadas de mayor a menor nivel de abstracción.

4.3.1. Vista de despliegue

En esta vista se muestra cómo está distribuida la aplicación. Un dispositivo móvil tendrá la
posibilidad de bajar la aplicación desde play.google.com para ser instalada de forma local.

31
 Figura 11. Despliegue de la aplicación.

4.3.2. Vista lógica

El siguiente diagrama muestra los principales módulos que involucran a nuestra aplicación.

Figura 12. Diagrama de Módulos / Paquetes.

En la descripción del diseño del TDD (Anexo 3) se muestran en detalle distintas vistas que
detallan la aplicación.

32
 4.3.3. Vista de comportamiento

En esta vista veremos cómo es el comportamiento de los mini juegos.

Figura 13. Diagrama de Secuencia de Naves

Al finalizar cada juego se ejecuta la parte didáctica donde se muestra una palabra, su imagen y
sonido. Al finalizar de mostrar las palabras correspondientes de las distintas categorías se
muestra una escena de evaluación del conocimiento adquirido.

33
 4.4. Decisiones de diseño

En esta sección se busca justificar las principales decisiones tomadas al momento de

especificar el diseño arquitectónico. En el TDD (Anexo 3) se describen más en detalle las
resoluciones tomadas, ofreciendo un panorama más completo del diseño del videojuego.

Al momento de diseñar la solución, una de las primeras cosas que se tuvo en cuenta fue
cumplir con los principios de diseño que apliquen a este proyecto, para poder alcanzar los
distintos atributos de calidad.

Se tuvieron en cuenta los principios de clausura común, donde las clases se agruparon según
un mismo motivo. Es así que tenemos un paquete referente a los datos, otro referente al
dominio, otro que refiere a métodos comunes y otro a todo lo referente a la interacción con el
usuario y los videojuegos. También se tuvo en cuenta el principio de dependencias acíclicas
donde la dependencia de los paquetes forma un grafo dirigido y acíclico.

Se tomaron muy en cuenta los principios concernientes al diseño de clases. Para poder
cumplir con el principio de cohesión, el cual plantea que debe existir una fuerte relación de
responsabilidades dentro de una clase, se buscó siempre encapsular responsabilidades
comunes dentro de cada clase. Al programar de esta manera, se cumple también con el
principio de acoplamiento, ya que al envolver funcionalidades de responsabilidades
relacionadas en una misma clase, se está desacoplando a los demás objetos que dependen de
él, de los objetos que utiliza la clase en cuestión.

También se tuvo en cuenta el principio de abierto-cerrado, el cual plantea que un sistema debe
quedar abierto a la extensión, pero cerrado a la modificación. Este principio asegura el
cumplimiento del requerimiento no funcional de modificabilidad, el cual determina que el
videojuego debe quedar abierto al agregado de distintos mini juegos, la inclusión de nuevas
palabras, la posibilidad de elegir entre nuevas categorías y niveles y la incorporación de
nuevas modalidades de juego, pero sin modificar lo ya existente.

34
 4.4.1. Estructura

Al momento de determinar cómo estarán estructurados los distintos elementos del videojuego,
se decidió que habrá un administrador de escenas, llamado SceneManager, el cuál conocerá
todas las escenas involucradas y será el responsable de las llamadas a las distintas escenas.
Además, habrá un administrador de recursos, llamado ResourcesManager, quien será el
responsable de todos los recursos comunes a las distintas escenas.

Para los datos externos se utiliza un administrador llamado DataManager. Este es el

responsable de leer toda la información necesaria para empezar el videojuego como es el
diccionario con todas las palabras y los distintos niveles para los mini juegos. Y también es
responsable a la hora de guardar los datos generados por el videojuego.

4.4.2. Acelerómetro

El acelerómetro es una innovadora herramienta que le permite identificar al dispositivo cual

es la posición del mismo con respecto al mundo. Tanto los teléfonos inteligentes como las
tablets poseen un acelerómetro de tres ejes que detecta la orientación del teléfono.

Figura 14. Ejes del acelerómetro.

35
Esta tecnología permite a las aplicaciones reaccionar frente al movimiento del dispositivo
proporcionando una atractiva entrada de información. Es así que decidimos incluirla para el
ingreso de información de movimiento en los dos mini juegos.

4.4.3. Intercambio de información

Para el intercambio de información hacia y desde el exterior utilizamos XML. Para controlar
la información y estructura de los documentos XML se utilizó DTD. Su función básica es la
descripción de la estructura de datos, para utilizar una estructura común y mantener la
consistencia entre todos los documentos que utilicen la misma DTD.

4.4.4. Elección del Motor

El uso de un motor o engine para el desarrollo de video juegos consiste en el uso de librerías
ya probadas las cuales facilitan el acceso a funciones de bajo nivel. Esto permite al
programador enfocarse en tareas más concernientes al videojuego pudiendo de esta manera
lograr productos de mayor calidad.

A la hora de elegir un motor se buscó información sobre los disponibles en la modalidad

“Open Source” obteniendo una lista con varios motores diferentes. De esta lista se eligieron
dos, teniendo en cuenta la existencia de comentarios positivos de los usuarios y que haya
suficiente información para el aprendizaje de uso del motor. Estos fueron LibGDX y
AndEngine.

Posteriormente se crearon prototipos para asegurar la mejor opción entre estos dos motores.
Finalmente elegimos AndEngine por las siguientes razones:
 Buena performance comprobada por los prototipos.
 Se encuentran mayor cantidad de ejemplos de los cuales aprender su funcionamiento.
 Existe un foro atendido donde evacuar dudas o consultas.
 Mejor documentación para aprender rápidamente el uso.

36
 4.5. Conclusiones

A partir de la solución de diseño planteada se logró desarrollar un videojuego que cumple con
los requerimientos funcionales especificados. Además se logró alcanzar los distintos atributos
de calidad establecidos, como por ejemplo la modificabilidad ya que el juego quedó abierto a
la posibilidad de agregar nuevas palabras, categorías y niveles.

37
5. Gestión de los elementos de la configuración

En este capítulo se describe el plan utilizado para la gestión de los diferentes elementos de
configuración del software (ECS). Luego se hará un repaso de lo que fue la ejecución de este
proceso a lo largo del ciclo de vida.

5.1. Responsabilidades del RSCM

Durante el proceso, el responsable de SCM fue el responsable de las siguientes actividades:

 Definición de las herramientas a utilizar para dar soporte al proceso.
 Definición de la estructura del repositorio y mantenimiento del mismo.
 Identificación de los ECS y definición de la metodología para el versionado de cada
uno.
 Definición de la periodicidad de respaldos y ejecución de los mismos.

Estas actividades fueron realizadas con el objetivo de garantizar que en cualquier momento
del proyecto se pudiera obtener correctamente un ECS. Además, la obtención de un elemento
debía estar acompañada de la información correspondiente para saber en qué estado se
encuentra el mismo.

5.2. ECS identificados

5.2.1. Documentos

Los documentos identificados que forman parte del proyecto son los siguientes:

 Game Concept
 GDD
 TDD
 Plan de proyecto
 Plan de SQA

38
  Plan de SCM
 Gamification
 Método global de lectura
 Documentos de investigación

5.2.2. Código fuente

Con código fuente nos referimos a los diferentes archivos de código que el equipo va
desarrollando, y a los archivos que SVN genera automáticamente para guardar información y
configuraciones que se establecen en el editor gráfico de la herramienta.

5.2.3. Recursos multimedia

Los recursos del juego son los diferentes recursos multimedia necesarios para el producto.
Esto incluye:
 Texturas
 Sonidos
 Archivos XML

5.3. Herramientas

Las principales herramientas utilizadas para el control de la configuración fueron Dropbox,

Assembla y Google Drive.

Dropbox: es un sistema de almacenamiento en la nube. Este espacio de almacenamiento será

utilizado como repositorio. Ofrece un cliente Windows con el cual cada usuario puede
acceder a un espacio de almacenamiento privado. También permite compartir carpetas entre
diferentes usuarios, esta funcionalidad es la que el equipo utilizó para que todos puedan
acceder a los diferentes ECS en un espacio común. Además Dropbox mantiene copias de
versiones anteriores de cada archivo, que puede ser de utilidad en caso de eliminar un archivo
involuntariamente o hacer un cambio accidental en ellos.

39
SVN (Subversion) y Assembla se utilizarán para el versionado y como repositorio de todo el
código desarrollado durante el proyecto a través de Eclipse. SVN utiliza un único número de
versión que identifica un estado común de todos los archivos del repositorio en un instante
determinado que se está trabajando. Assembla provee una herramienta de colaboración y de
seguimiento de tareas basadas en la nube para organizar y administrar proyectos de desarrollo,
la cual es utilizada como repositorio del código generado.

Google Drive es un servicio de alojamiento de archivos, Google Docs. Estos archivos fueron
utilizados para la gestión del proyecto y algunos documentos importantes. Al igual que
Dropbox, se almacena en la nube y puede ser accedido por distintos usuarios a la misma
información.

5.4. Metodologías utilizadas para el versionado

Tanto el código fuente como los recursos se encuentran ubicados en directorios creados para
el proyecto EduGames. Para almacenar una versión en el repositorio, se subirá a Assembla los
archivos modificados hasta el momento.

Para el caso de los documentos, se grabarán utilizando la fecha de modificación como parte
del nombre del mismo. De esta manera se obtiene una versión conteniendo los ECS
mencionados.

5.5. Respaldos

Cada mes se realizó un respaldo a un disco duro externo a cargo del responsable de SCM. El
respaldo fue de todos los ECS descriptos anteriormente. Además, se conformó la última
versión del producto con las últimas versiones estables de cada ECS.

5.5.1. Problemas enfrentados

Al momento de decidirnos por utilizar Tablet y Android como plataformas para nuestro
proyecto, se instaló una versión inicial de Android. También se instalaron las APIs necesarias

40
para SVN, AndEngine y de Android (SDK). Una vez que teníamos una versión funcional del
proyecto, se hizo una copia externa del proyecto.

Esto fue fundamental a la hora de los prototipos. Nos sucedió que una instalación se rompió
debido a la actualización de una aplicación del sistema operativo. Por haber tenido todo en un
repositorio externo, pudimos volver a la instalación funcional en cuestión de horas. Esto nos
ahorró dos o tres días de trabajo.

Durante el resto del proyecto, por suerte no tuvimos más inconvenientes, y no necesitamos del
uso de los repositorios construidos.

5.6. Conclusiones

Se logró versionar todos los ECS que se identificaron al principio del proyecto según lo
planificado.

Se cumplió con los respaldos del repositorio planificados y aunque sólo fueron utilizados una
vez, el equipo tuvo la tranquilidad de haber hecho lo correcto. Al poder probarlos en el inicio
del proyecto, no tuvimos la necesidad de depender de terceros.

41
6. Gestión de la calidad

6.1. Introducción

En esta sección del documento se describe el proceso de aseguramiento de la calidad definido

y utilizado en el proyecto.

6.2. Proceso de aseguramiento de la calidad

El proceso de aseguramiento de la calidad es el conjunto de las actividades que determinan las

políticas, objetivos y responsabilidades relativos a la calidad de modo que el proyecto y
producto satisfagan las necesidades por las cuales fue creado.

6.2.1. Actividades del proceso

Se identificaron las actividades específicas del proceso de SQA a llevarse a cabo para
asegurar la calidad del videojuego. A continuación se explica en forma sintética cada una de
ellas, puede verse un diagrama y las actividades en detalle en el Anexo 5 Plan de Calidad.

Validación de GDD y TDD: El documento GDD será validado por el cliente, donde uno de
los aspectos principales a revisar es la intervención didáctica. El documento TDD será
aprobado por el tutor, ya que en nuestro grupo de trabajo es quién puede validar los aspectos
que éste documento trata.

Validación de recursos: Se solicitará al cliente la aprobación de los recursos. Entre ellos se

cuenta con sonidos, fuente, recursos gráficos y diagramación de los mismos. Esta validación
tiene una importancia estratégica ya que la presentación de la información incide en la
viabilidad de la propuesta pedagógica.

Validación de prototipos: Se mostrarán al cliente los prototipos realizados con el fin de que
tenga una idea más del producto final y se realizarán ajustes corrigiendo detalles de los
requerimientos que considere necesarios.
42
Inspección de código: Se inspeccionará el apego a los estándares de codificación definidos,
así como también se realizará una revisión de las tareas pendientes (//TODO).

Testing: Se define un plan de pruebas que será utilizado desde la etapa de producción. Se
debe obtener un listado de los errores conocidos ponderado según la gravedad.

Refactoreo: Se realizarán mejoras en los atributos de calidad como mantenibilidad y

performance. Esta tarea se realizará especialmente luego de finalizada cada iteración de la
producción y una instancia en la liberación.

Pruebas: Se realizarán pruebas de sistema, pruebas de aceptación y pruebas de campo. En las

pruebas de aceptación se relevará la aprobación del cliente y por ende será un reflejo del éxito
del proyecto. Las pruebas de campo se realizarán con niños pertenecientes al público objetivo.

6.2.2. Definición de estándares

Se definieron distintos estándares de aceptación para los principales ECS, documentación,

codificación, registro de horas, repositorio y registro de tareas.

Documentación: Se definió utilizar la herramienta ofimática Microsoft Office 2010 y 2007.

Además, se incorporó como parte del estándar los estándares requeridos por la universidad,
documento 302 y 303. Para facilitar el cumplimiento de lo anterior, se crearon plantillas Word
con el formato correspondiente, para elaborar los documentos del proyecto a partir de ellas.
Se acordó un sistema de versionado para los documentos y se definió la forma de realizar las
citas bibliográficas.

Codificación: Se definió un estándar para la codificación, basado en un conjunto de buenas

prácticas y recomendaciones agrupadas en un documento. Algunas de estas se automatizaron
mediante la configuración de la IDE Eclipse. Véase en el Anexo A del Anexo 5 Plan de
calidad.

43
Registro de horas: Se utilizó una planilla de cálculo de Google Docs a la cual denominamos
“Hoja de Ruta”. Se automatizaron en esta planilla reportes para el registro de esfuerzo
discriminado por categorías y reportes sobre el total de horas que se realiza en cada semana
comparándolo con el promedio de horas semanales que se ha realizado durante lo que va del
desarrollo del proyecto.

Repositorio: Como repositorio para el código del programa se utilizará el sistema de

versionado SVN y para realizar el hosting en la nube se usará la herramienta Assembla. Se
configurará el sistema de versionado de forma tal que se deba solicitar el bloqueo (Lock) de
un archivo para editarlo con el fin de evitar conflictos en las actualizaciones del código.

Registro de tareas: Se seleccionaron dos herramientas: Pizarrón Kanban, implementado

mediante la herramienta LeanKit y Planilla de datos usando una planilla de cálculo de Google
Docs. Con el pizarrón Kanban se tiene un recurso gráfico en el cual visualizar las tareas
pendientes y hacer un mapa mental del progreso del proyecto. La planilla se usará para llevar
un control del tiempo que lleva cada tarea. Además se determinó una agenda o rutina para
gestionar las tareas.

44
 6.3. Métricas

Se definirá un plan de métricas con el fin de obtener información cuantitativa de los

principales atributos de calidad del videojuego y del proceso de elaboración del mismo.

Se realizarán diversas mediciones en distintas etapas del proyecto, de manera de detectar

tempranamente posibles obstáculos que tenga que enfrentarse el equipo.

6.3.1. Métricas del proceso

Métrica Objetivo Procedimiento

Esfuerzo El objetivo de esta métrica es Para calcular estas métricas se
según tipo obtener datos históricos que obtendrán datos del registro de
de tarea servirán para realizar en forma más horas en la Hoja de ruta. Se
acertada las futuras planificaciones, acumularán las horas según el tipo
en etapas avanzadas de este mismo de tarea realizado.
proyecto o en otros proyectos que
se puedan realizar.
Desviación La desviación en la estimación nos Se registra para cada tarea, la
en la permitirá saber el grado de acierto cantidad de horas que se estimó
estimación que se está teniendo en las llevaría cumplirla y las horas que
actividades de estimación y como realmente llevó. Luego se calcula
resultado de esto se tendrá una la desviación, que resulta de la
gestión más adecuada a la realidad diferencia de las dos anteriores, y
del proyecto. el porcentaje de error dividiendo la
desviación entre la cantidad de
horas real.
Figura 15. Métricas del proceso.

45
 6.3.2. Métricas del producto

Métrica Objetivo Procedimiento

Avance del Monitorear riesgos como: Se valúa para cada etapa del
producto Retrasos en el proyecto debido a proyecto el avance realizado para
mala estimación y por ende la cada requerimiento del proyecto.
insatisfacción del cliente. Por este
motivo es importante tener
información sobre los
requerimientos del producto
cumplidos.
Tiempo de Monitorear el tiempo de carga Se calcula la diferencia entre el
Carga permitirá evitar situaciones de instante de tiempo en el que se
inseguridad sobre el correcto solicitó el juego y el instante de
funcionamiento del producto. tiempo en el que se muestra el
juego. Mediremos la carga inicial
del juego y la carga de cada mini-
juego: Laberinto y Naves. Este
valor no debe ser superior a 5
segundos.
Cantidad de Determinar el número de fallas del Se toma el número de fallas
fallas juego en un número determinado encontradas en un ciclo, es decir,
de corridas. desde que se abre la aplicación, se
juega y se cierra. Las fallas se
dividirán según su tipo en: leve,
grave y fatal. Es deseable que la
cantidad de fallas fatales sea nula.
Figura 16. Métricas del producto.

46
 6.4. Datos obtenidos

La gráfica siguiente muestra las métricas obtenidas al medir el total de horas destinadas a cada
tipo de tarea.

Figura 17. Gráfica de esfuerzo según tipo de tarea del total del proyecto.

La información recabada puede verse en la siguiente figura, donde se detalla la desviación en

la estimación para las distintas etapas del proyecto.

Figura 18. Desviación de la estimación.

47
 6.5. Conclusiones

Al evaluar el esfuerzo según el tipo de tarea se constató que la mayor cantidad de horas se
realizaron en la categoría Desarrollo. Esto se explica por el tipo de producto a elaborar,
además al incursionar en un área de desarrollo nueva para los integrantes del equipo como lo
es videojuegos, se incrementó el esfuerzo dedicado a programar. Agregando las horas de
Desarrollo, Prototipos y Testing vemos que éstas abarcan más del 50% del esfuerzo del
proyecto. El esfuerzo de Investigación ocupó casi el 12% del total y fue dedicado al tema de
Gamification, al análisis de motores para desarrollar el videojuego y la investigación
educativa que permitirá justificar la propuesta de juego. El esfuerzo dedicado a las reuniones
es del 9%, ésta valor responde a la cantidad de actores involucrados en la realización del
proyecto: Cliente Rosario Castro, maestras de la escuela 206, maestras de los colegios donde
realizamos las pruebas, el diseñador y los tutores.

Con respecto a las desviaciones en la estimación pudo constatarse que éstas fueron siempre en
sentido negativo, es decir que estimamos menos del tiempo que realmente llevó. La
estimación correspondiente a la primera etapa fue la que se realizó mejor, lo cual se debe al
tipo de tareas realizadas en esta etapa, las cuales corresponden en su mayor parte a
Documentación y Reuniones e Investigación. Las estimaciones realizadas durante las etapas
de producción se desviaron en un mayor rango pero se observó una notoria mejoría al
finalizar esta etapa.

Las mediciones del avance del proyecto sirvieron para monitorear el avance en cada etapa. En
esta métrica se destaca el grán esfuerzo realizado en la etapa de preproducción el cual
permitió realizar avances importantes en la mayoría de los requerimientos. La duración de
esta etapa fue de 8 semanas.

Con respeto a las métricas referidas al producto, el tiempo de carga de los mini-juegos fue
aceptable desde la etapa de producción. Sin embargo para el tiempo de carga inicial fue
necesario corregir errores en la carga del Diccionario, realizando una carga más simplificada
del mismo. Luego de las correcciones se llegó a valores aceptables.

48
Las pruebas que se hicieron permitieron obtener un reporte de correcciones a realizar. Los
resultados obtenidos se muestran en el cuadro siguiente:

Figura 19. Resumen de Pruebas realizadas

Consideramos que los resultados fueron satisfactorios porque las fallas leves que
corresponden al 63% de las pruebas son de origen conocido, habiendo registrado ya el
incidente para su corrección. Entre estas fallas se tiene: recargar la fuente para evitar la
alteración del color y mostrar el premio de la categoría que corresponde.

49
7. Gestión del proyecto

7.1. Ciclo de vida

Para la realización de este proyecto se utilizó un ciclo de vida iterativo-incremental debido a

que en el desarrollo de un videojuego, se definen al principio los requerimientos con un
diseño de alto nivel del mismo y luego se avanza mediante incrementos hasta llegar a la
versión final.

Como se mencionó en anteriormente el proyecto consta de tres grandes etapas:

preproducción, producción y liberación.

Figura 20. Macroproceso del proyecto.

50
 7.1.1. Preproducción

El proceso de preproducción se compondrá de otros subprocesos: investigación, definición de

requerimientos, elaboración de prototipos de ensayo y diseño de alto nivel del sistema

Figura 21. Subproceso preproducción.

El subproceso de investigación se desarrolló durante toda la etapa de preproducción

abarcando temas como: plataforma para desarrollar el videojuego, estándares a aplicar,
herramientas a utilizar y técnicas de Gamification. Se realizó una capacitación sobre
videojuegos cursando la materia electiva Programación de Videojuegos.

Paralelamente se trabajó realizando prototipos con el fin de probar las herramientas de

desarrollo investigadas. Se construyeron prototipos que permitieron determinar el costo
beneficio de cada tecnología o herramienta analizada. Este análisis permitió seleccionar el
motor AndEngine como la herramienta más adecuada para las necesidades del proyecto.

La construcción de los prototipos se realizó teniendo en cuenta la definición de

requerimientos. Por ejemplo se elaboraron prototipos que pudieran mostrar la palabra junto a
su imagen y sonido. Otro ejemplo fue un laberinto sencillo que permitió ganar experiencia en

51
la lógica utilizada para mostrar las paredes y elementos del mismo usando una matriz para
estructurar la información que se debe mostrar en pantalla.

7.1.2. Producción

Esta etapa estuvo compuesta por 3 iteraciones sobre las actividades de diseño detallado,
desarrollo y pruebas, como se muestra en el siguiente diagrama:

Figura 22. Subproceso de producción.

En la primera iteración se realizó un prototipo que desarrolló la estructura de navegación

principal y las escenas referidas a la intervención didáctica sin incluir los juegos. Se obtuvo
una validación temprana de este prototipo, la cual consideramos decisiva, ya que la
intervención didáctica es un aspecto fundamental para el videojuego desarrollado.

En la segunda iteración se realizaron las modificaciones que el cliente solicitó. Algunas de

ellas comprendieron la realización de una animación cuando se muestra la palabra, aumentar
el tamaño de la fuente de la palabra. Se realizó una secuenciación de la forma en que se
muestra la intervención didáctica de acuerdo al nivel que haya logrado en el juego: para el
nivel 1 se muestra la palabra dos veces, para el 2, 3 y 4 se muestra la palabra y una oración
que la emplea. La cantidad de veces que se muestra la palabra y la oración quedo configurable
52
para futuras modificaciones. Se integró la fuente Open-Dislexic la cual aumenta la legibilidad
para lectores con dislexia. Además de se integraron al videojuego el juego del laberinto no
pudiendo integrar aún el juego de naves.

En la tercera iteración sí se puedo incluir el juego de naves. Se decidió en acuerdo con el

cliente no incluir el tercer juego. Se incluyeron los requerimientos referidos a Gamification,
estos incluyen un premio por haber finalizado todas las palabras de una determinada categoría
del nivel que está jugando; otro premio por usar la aplicación x cantidad de días seguidos (el
valor x se va incrementando y es configurable) otro premio por usar la aplicación determinada
cantidad de veces sin importar el día (también configurable) y un premio sorpresa cuando
aparece una palabra especial.

7.1.3. Liberación

Para la etapa de liberación se diseñó un proceso que se esquematiza en la siguiente figura:

Figura 23. Subproceso de liberación.

Se realizaron las actividades de testing con pruebas de sistema y pruebas de campo. Las
pruebas de sistema permitieron solucionar errores en la aplicación, obteniendo una versión
más estable. Además se solucionaron problemas en la escritura de los archivos XML,

53
problema que se dio solo con las tablets que usaban la versión de Android 4.0, pero no se
había dado con las tablets que usamos durante la etapa de producción.

Las pruebas de campo se realizaron en instituciones educativas con niños pertenecientes al

público objetivo. Permitieron continuar relevando oportunidades de mejora, así como también
la opinión de las maestras respecto al prototipo desarrollado.

7.2. Cronograma

En la figura siguiente se puede observar el cronograma que se aplicó en el proyecto.

Figura 24. Cronograma desarrollado.

En la etapa de preproducción, las actividades se agruparon en ciclos de dos semanas de

duración. La etapa de la producción se desarrollará en 3 iteraciones. Las dos primeras
iteraciones tendrían una duración de cuatro semanas y la última sería de dos semanas. Pero al
finalizar la etapa de preproducción se decidió prolongar esta etapa debido a que no se
cumplieron los cometidos para la misma. Dificultades en la investigación del motor para
desarrollar el videojuego ocasionaron este retraso. El cronograma para esta etapa quedó con 3
iteraciones de 2 semanas cada una.

54
 7.3. Cronograma de recursos gráficos

Los recursos gráficos tienen un rol de importancia en el videojuego ya que el atractivo del
juego se verá influenciado por los mismos. Para ello se buscó un diseñador que pudiera
colaborar con el proyecto en forma profesional aportando los conceptos del área de diseño
gráfico.

El diseñador trabajó en forma voluntaria realizando las entregas que se detallan a

continuación:

2013-06-02: Logo de EduGames para el ícono de la aplicación y banner para el blog. Primera
versión de palabras para 3 categorías.

2013-06-09: Abecedario con la fuente solicitada por el cliente y palabras para el primer nivel.

2013-06-11: Palabras para el primer nivel en dos versiones para elegir.

2013-08-06: Ajustes solicitados para las palabras del primer nivel corrigiendo errores que se
producían al dividir las imágenes.

2013-08-23: 2 opciones para el menú principal.

2013-09-01: Logo de mayor tamaño el cual fue requerido para subir la aplicación a Google
Play.

Durante la etapa de producción se trabajaron con gráficos provisorios para el menú debido a
que el diseñador no tuvo éstos gráficos hechos cuando se comenzó a implementarlo.

55
 7.4. Cronograma de recursos de sonido

Los sonidos del juego al igual que los gráficos también tienen cumplen un rol importante
dentro del proyecto. Fueron diseñados y obtenidos por parte del equipo. Para elevar la calidad
de los recursos de sonido que se usarán en el videojuego se asistió al taller: “Audio para
videojuegos”.

Para los recursos de música se buscó en sitios online que ofrecen este tipo de recursos en
forma gratuita. Los sitios visitados fueron diseñados para realizar una rápida selección debido
a que proveen buscadores y una rápida interfaz de prueba de sonidos.

Los sonidos de las palabras y la historia del juego se grabaron con voces de personas que
colaboraron voluntariamente. Consideramos que resultaría un atractivo para el juego que las
palabras fueran relatadas por un niño, esto fue valorado como muy positivo por parte de las
maestras que visitamos en uno de los colegios.

7.5. Entregables por fase

A continuación se detallan los entregables que nos propusimos realizar en cada fase.

7.5.1. Preproducción

 Game Concept
 GDD
 TDD
 Plan de proyecto
 Plan de Calidad
 Prototipos

56
 7.5.2. Producción

 Versión final del juego con las correcciones relevadas en las pruebas.
 Listado de errores conocidos.
 Reportes de métricas determinadas por el plan de calidad.

7.5.3. Liberación

 Versión final del juego con las correcciones relevadas en las pruebas.
 Listado de errores conocidos.
 Reportes de métricas determinadas por el plan de calidad.

7.6. Esfuerzo

Para la realización del proyecto, se decidió medir el esfuerzo en base a las horas de trabajo
realizadas. Se creó un calendario semanal con el fin de fijar días de trabajo para el proyecto,
vimos que la disponibilidad en horas es de 25 horas por cada integrante.

El registro de horas trabajadas se realizará utilizando una planilla de cálculo de Google Docs a
la cual denominamos “Hoja de Ruta”. Se registran datos de: Nº de semana, fecha de la tarea,
título, descripción, categoría, etapa, cantidad de horas realizadas e integrantes que participan.
Ésta planilla se configuró para que en forma automática se obtenga un reporte del registro de
esfuerzo discriminado por categorías. Al finalizar cada etapa, se tomarán mediciones de la
cantidad de horas realizadas por tipo de tarea.

En otra planilla de cálculo de Google Docs a la cual denominamos “Pendientes” se llevará el

registro de tareas incluyendo la estimación y horas dedicadas a cada tarea.

Se estableció una agenda quincenal que incluye varias tareas de rutina, con la finalidad de
gestionar el esfuerzo dedicado a las tareas del proyecto:

Lunes 1: Planificación de las tareas para el ciclo de trabajo.

57
Martes 1: Revisión de cronograma junto con los tutores.
Miércoles 1: Investigación o revisión de documentos.
Jueves 1: Investigación, desarrollo y/o documentación.
Viernes 1: Libre o desarrollo.
Sábado 1: Reunión de equipo, investigación, desarrollo y/o documentación.
Domingo 1: Documentación. Respaldos.
Lunes 2: Actualización del pizarrón Kanban.
Martes 2: Revisión de cronograma junto con los tutores.
Miércoles 2: Investigación o revisión de documentos.
Jueves 2: Investigación, desarrollo y/o documentación. Análisis de riesgos.
Viernes 2: Libre o desarrollo.
Sábado 2: Reunión de equipo, investigación, desarrollo y/o documentación.
Domingo 2: Documentación. Respaldos

Observaciones: Los miércoles el equipo estuvo abocado a cursos de videojuegos y de sonidos

para videojuegos durante un período considerable del proyecto. Más allá de que el ciclo es
quincenal hay actividades que se repiten, fundamentalmente las de investigación, desarrollo y
documentación.

Planificación de las tareas para el ciclo de trabajo: se elabora un listado de tareas a realizar
teniendo en cuenta los requerimientos pendientes. Se estiman las tareas y se priorizan. Se
seleccionan las tareas que se realizarán en el próximo ciclo.

Revisión de cronograma junto con los tutores: se analizan los aciertos en la estimación
anterior y se revisa la adecuación en la estimación realizada. Se revisa la priorización de las
tareas.

Investigación, desarrollo y/o documentación: de acuerdo a la priorización anterior es el tipo

de tipo de tareas a realizar.

Análisis de riesgos: se realiza en forma mensual el segundo jueves del mes.

58
Respaldos: incluyen una copia del proyecto hacia una carpeta externa para facilitar la
recuperación. También se utiliza herramientas que permitan la automatización de esta tarea,
como por ejemplo Dropbox, Assembla y Google Drive.

7.7. Riesgos

El objetivo en esta área es asegurar que la gestión de riesgos se realiza de forma correcta. Para
ello se realizarán actividades de Identificación de riesgos, definición de estrategias de
Mitigación y Contingencia para los riesgos encontrados. En forma mensual, se realizará un
análisis de los riesgos para evaluar los cambios ocurridos y, si es necesario, tomar alguna
acción correctiva. Ésta evaluación de riesgos en el proyecto se realizará a mediados de cada
mes en las siguientes fechas:

 Lunes, 15 de abril de 2013

 Jueves, 16 de mayo de 2013
 Jueves, 20 de junio de 2013
 Jueves, 18 de julio de 2013
 Jueves, 15 de agosto de 2013

A continuación se presentan los riesgos encontrados y se realiza un resumen sobre la

evolución de los mismos. Puede verse un análisis más detallado en el Anexo 4 Plan de
Proyecto. Página 22.

59
 7.7.1. Riesgos encontrados

R1. No tener disponible el hardware para correr la aplicación

El proyecto surge a partir de la inquietud de brindar herramientas que ayuden a los niños en el
aprendizaje de la lectura. En Uruguay se implementó el Plan Ceibal que tiene como
beneficiarios a la mayoría de los niños del país. Este proyecto se basa en entregar una
computadora a cada niño en edad escolar de las escuelas públicas. Partiendo de esta realidad,
nuestro proyecto se pensaba implementar utilizando las computadoras entregadas (XO).

Durante la definición del proyecto acontecieron cambios en el Plan Ceibal, entre los cuales se
lanzará un plan piloto que pretende entregar 10.000 tablets a niños de 4 y 5 años de educación
inicial, y primer y segundo grado de escuela primaria. Estas edades son perfectas para aplicar
el método global de lectura. Suponiendo que el plan piloto tenga éxito y abarcando los niños
destinatarios del plan, es que decidimos realizar el proyecto para tablets con sistema operativo
Android.

El riesgo de no encontrar hardware disponible al inicio del proyecto es elevado, pero

confiamos poder conseguir suficientes tablets para realizar con éxito todo el proyecto.

R2. Retrasos en el cronograma debido a una mala elección del Lenguaje de

Programación (Motor del juego)

Las XO utilizan Sugar como plataforma, a la cual Python se adecua perfectamente. Por esta
razón comenzamos programando en el lenguaje Python intentando que el lenguaje de
programación no sea un obstáculo para el proyecto.

Al haber elegido tablets para trabajar y teniendo en cuenta que existe una probabilidad muy
alta de utilizar Android como sistema operativo en el Plan Ceibal, es que cambiamos y
decidimos utilizar esta plataforma para desarrollar el proyecto.

60
Para desarrollar videojuegos se necesita utilizar motores que sean eficientes a la hora de
utilizar el hardware disponible, sobre todo en el caso de las tablets por tener disponibilidad
limitada de recursos.

Debido a nuestra experiencia en Java nos encontramos confiados en poder resolver el

proyecto utilizando Android (basado en Java) y AndEngine como motor de videojuegos. De
todas formas, al no tener mucha experiencia en videojuegos el riesgo al inicio del proyecto es
elevado. Por otra parte en Python no teníamos experiencia previa.

R3. Retrasos en el proyecto debido a mala estimación.

Al comenzar programando en Python y no contar con experiencia en este lenguaje, realizamos

varios prototipos. Éstos nos proporcionarían información para realizar una estimación más
adecuada del tiempo que requiere la realizar un videojuego.

Al cambiar de plataforma, nuestra experiencia en Java nos permite poder pronosticar mejor
los tiempos requeridos para programar. Igualmente realizamos prototipos y evaluamos la
estimación en forma constante con el fin de disminuir el riesgo de fallar en la estimación.

R4. Mala comunicación entre los actores del proyecto

Los actores que participan en la definición del proyecto son: el cliente y las maestras que
aportan desde su conocimiento y experiencia, los tutores, el diseñador y nosotros que lo
llevaremos a cabo.

La cantidad de personas involucradas en el proyecto no es menor, además encontramos que la

disponibilidad horaria de todos los participantes es limitada. Este motivo podría llevar a un
desencuentro o malentendido en la comunicación. Por este motivo es que vamos a utilizar
todos los medios tecnológicos disponibles para minimizar este riesgo.

61
R5. Retrasos en el cronograma por la búsqueda y utilización de gráficos.

Para tener éxito en el proyecto, es de fundamental importancia contar con gráficos de calidad
adecuados a las necesidades del proyecto. Debido a la trascendencia de este factor es que
solicitamos el apoyo de expertos en el área. Es así que se integra al proyecto un estudiante
avanzado de la carrera de Diseño Gráfico de la Universidad ORT Uruguay. Su aporte con
gráficos elaborados por su cuenta, será en forma voluntaria.
Dado que no existe ningún compromiso laboral con el diseñador y a su vez él debe dedicar
tiempo a sus estudios, el riesgo de no contar con los recursos gráficos al inicio del proyecto es
alto.

R6. Retrasos en el cronograma por la búsqueda y utilización de sonidos

De manera similar a los gráficos, los recursos de sonido adecuados al proyecto forman parte
del atractivo del juego, lo cual redundará en el éxito del proyecto.

Los recursos de sonido se pueden dividir en dos grandes grupos: los sonidos de las palabras o
frases y los sonidos de ambiente o de fondo. Para cubrir esta necesidad del primer grupo se
prevé grabar los mismos con voces de niños. Para el segundo grupo se buscará la ayuda de
personas que ya tienen vasta experiencia en videojuegos o se bajaran recursos gratuitos de
internet.

Estas dos fuentes de recursos no son dependientes de nosotros quienes estamos elaborando el
proyecto, por lo cual el riesgo de no contar con los recursos de sonido al inicio del proyecto es
alto.

R7. No cumplir con los requerimientos por dificultades en la obtención de datos

estadísticos

Entre los requerimientos (deseables) del proyecto se propuso la obtención de información que
puede generase a medida que los jugadores participan, por ejemplo: datos personales de los
participantes, pantallas a las que ingresa, tiempo que permanece en cada pantalla, palabras
que logra reconocer, etc.

62
Para realizar la obtención de los datos mencionados se usarán los recursos tecnológicos
disponibles a tales efectos, ellos son: “Shared Preferences” para datos simples y documentos
XML para datos complejos.

Dado que no se tiene experiencia en la implementación de este tipo de funciones, puede haber
problemas en la generación de los datos debido al desconocimiento de cómo implementar el
requerimiento. A su vez existe el riesgo de que los datos que nos proponemos relevar no sean
los adecuados.

R8. Cambios en los requerimientos por insatisfacción del cliente (maestros)

Si bien la idea del proyecto surge por parte de nosotros quienes elaboramos el proyecto, se
consideró muy oportuno contar con la presencia de un cliente, a quien le interesara el
producto a elaborar y, quien nos pudiera asesorar durante la construcción del mismo para
realizar mejoras. Es así que nos contactamos con el cliente y otras maestras que brindarán
apoyo y asesoramiento desde el punto de vista didáctico.

Se prevé realizar reuniones periódicas con las docentes a medida que se realizan avances,
tanto en el diseño del juego como en la implementación del mismo. Teniendo en cuenta que
pueden surgir cambios en ambas etapas, se realizará una implementación de la solución
abierta al cambio. De todas formas existe el riesgo de que el cliente solicite cambios que
impacten en forma grave en etapas avanzadas del proyecto, teniendo como consecuencia una
productividad baja debido al retrabajo.

R9. Los juegos resulten poco atractivos para los niños

El objetivo principal del proyecto es ayudar a los niños en su proceso de aprendizaje de la

lectura, para cumplir con el mismo es necesario que ingresen asiduamente a la aplicación de
juegos para interactuar con la propuesta didáctica que se ofrece junto a los juegos. Si los
juegos carecen de interés para los niños del entorno etario previsto, no habrá posibilidades de
que se realice la interacción antes mencionada.

63
Para mitigar este riesgo, se cuenta con el apoyo del tutor quien está a cargo del gamelab de la
Universidad ORT Uruguay y en base a su experiencia en videojuegos nos guiará en el proceso
de construcción de la aplicación.

Un hecho que aumenta el impacto de este riesgo es la duración del proyecto, la cual es de 6
meses. La cantidad de iteraciones que este tiempo permite realizar es limitada. Esto nos obliga
a trabajar con prototipos de la aplicación desde etapas tempranas del proyecto, con el fin de
realizar las correcciones necesarias a tiempo.

R10. Aplicación incorrecta de conceptos de Gamification

Como se mencionó en el riesgo anterior, es de fundamental importancia el ingreso en forma
asidua de los niños a la aplicación. Por este motivo, se buscó apoyo en Gamification, un área
de conocimiento nueva que se viene implementando en diversos contextos. Ésta área tiene
como objetivo principal la aplicación de elementos lúdicos para generar motivación en los
participantes en el contexto donde se aplique.

Se realizará una vasta investigación sobre el tema, realizando cursos on-line y analizando
ejemplos de aplicación de las técnicas que ofrece Gamification. Sin embargo no se ha ejercido
anteriormente la aplicación de estas técnicas, por lo cual existe riesgo de no aplicarlas en
forma correcta.

64
 7.7.2. Evolución y reevaluación de riesgos

En el análisis de los riesgos se decidió registrar un contexto que luego ayudaría a comprender
y explicar los cambios en los riesgos para cada etapa.

7.7.2.1. Evaluación abril/2013

Contexto: Se comienza a programar para XO en Python por ser este el lenguaje que mejor se
adapta a la plataforma. Se comienza con un curso sobre Gamification. Se inicia la
comunicación con todos los interesados. Se obtienen XO para realizar pruebas.

7.7.2.2. Evaluación mayo/2013

Contexto: Se cambió de plataforma de Python para XO a Android en dispositivos móviles.

Como consecuencia se cambió el lenguaje de programación de Python a Android (basado en
Java). Al pasarnos a Android, nos permite utilizar nuestra experiencia en java.

Para mejorar la comunicación con los interesados se inició el Blog donde se publicaran las
decisiones importantes referidas al video juego. Con esto también se pretende recibir
comentarios y sugerencias. Se estableció contacto con el diseñador para generar los gráficos
necesarios.

Explicación de los cambios registrados:

Riesgo Nº4: Al desarrollar el proyecto para tablet aumenta la probabilidad de ocurrencia por
no disponer de este dispositivo aún.

Riesgo Nº2: Con el cambio de plataforma se disminuyó la probabilidad de ocurrencia ya que

se tiene más experiencia en Java.

Riesgo Nº6: Al contactar a un diseñador se disminuye la probabilidad de ocurrencia de

retrasarnos debido al conocimiento de gráficos de esta persona.

65
Riesgo Nº7: Se realizaron reuniones con el cliente donde el mismo formuló la satisfacción
sobre la idea del producto.

Riesgo Nº9: El establecimiento de una nueva forma de comunicación permite tener un

diálogo más efectivo con el cliente.

7.7.2.3. Evaluación junio/2013

Contexto: Se analizan motores para ser utilizados. Se avanzó en diseño del videojuego
definiendo Story board. Se eligieron todas las palabras a utilizar definiendo categorías y
niveles por medio del blog y reuniones presenciales. Se adquirieron tablets. Se aprobaron
algunos gráficos. Finalizamos un curso MOOC (Massive Online Open Course) sobre
Gamification.

Explicación de los cambios registrados:

Riesgo Nº4: Se adquirieron tablets lo que permite disminuir la probabilidad de este riesgo.

Riesgo Nº2: Se evaluaron varios motores y esto permitió lograr una buena aceptación del
motor elegido. Se pudieron realizar algunas pruebas de concepto.

Riesgo Nº6: Se aprobaron algunos gráficos permitiendo definir el estilo del videojuego.

Riesgo Nº10: Se tiene un mayor conocimiento sobre Gamification.

7.7.2.4. Evaluación julio/2013

Contexto: Se realizaron los primeros prototipos utilizando AndEngine como motor de

videojuego. Se aprobaron los gráficos del primer nivel para todas las categorías. Se
encontraron dificultades para programar con AndEngine lo que retrasó la etapa de
preproducción. Se comenzó a grabar las palabras que se utilizarán. Se consiguieron dos
tablets más. Se investigó sobre metodologías de evaluación con respecto al videojuego y se
plantea hacer un estudio sobre: "Evaluación de resultados del uso de un videojuego con
66
intervenciones didácticas en diferentes poblaciones educativas utilizando metodología
cuantitativa".

Explicación de los cambios registrados:

Riesgo Nº3: Se inician las primeras grabaciones de sonidos.

Riesgo Nº4: Se consiguieron 2 tablets más.

Riesgo Nº7: Aumentó debido a las pocas reuniones con el cliente ya que se estaba evaluando
el motor con prototipos.

Riesgo Nº1: Al realizar los primeros prototipos hechos con AndEngine la estimación no fue
buena. Esto lleva a mantener alta la probabilidad de ocurrencia en este riesgo. Se realizará una
reunión con el cliente para reestimar y negociar el alcance del proyecto.

7.7.2.5. Evaluación agosto/2013

Contexto: Se terminaron de implementar los juegos. Se realizaron las pruebas de sistema

realizando correcciones al prototipo implementado. Se obtuvieron gráficos para el menú,
faltan los gráficos para las palabras de los niveles 2, 3 y 4. Se realizaron reuniones con las
docentes para presentar el prototipo y coordinar las jornadas de trabajo para realizar pruebas
de campo. Se asistió al taller "Audio para videojuegos" pudiendo preparar todos los sonidos
necesarios para el videojuego.

Explicación de los cambios registrados:

Riesgo Nº1: Al terminar de implementar los juegos quedan sólo tareas de pruebas, análisis y
documentación.

Riesgo Nº6: Aumentó debido a que el diseñador no entregó los gráficos de las palabras de los
niveles 2, 3 y 4.

67
Riesgo Nº7: Se realizaron reuniones con las docentes y se obtuvo buena respuesta.

Riesgo Nº3: Ya se cuenta con la mayoría de los sonidos necesarios.

Riesgo Nº2: Bajó debido a que se terminó de implementar los juegos y las métricas de calidad
fueron satisfactorias.

Riesgo Nº9: La muestra de prototipos avanzados fortaleció la confianza del cliente hacia el
equipo.

68
 7.8. Evolución de los Principales Riesgos

A continuación se muestra la evolución de los principales riesgos.

Figura 25. Evolución de Riesgos.

Los principales riesgos son:

 Riesgo 1 - Retrasos en el proyecto debido a mala estimación.
 Riesgo 2 - Retrasos en el cronograma debido a una mala elección del Lenguaje de
Programación (Motor del juego).
 Riesgo 5 - Los juegos resulten poco atractivos para los niños.
 Riesgo 6 - Retrasos en el cronograma por la búsqueda y utilización de gráficos.
 Riesgo 10 - Aplicación incorrecta de conceptos de Gamification.

69
 7.9. Conclusiones

El análisis de riesgos fue correcto ya que no aparecieron riesgos nuevos que hayan incidido
negativamente en el proyecto.

El no haber tenido un contrato formal de trabajo con el diseñador ocasionó que el riesgo Nº 6
referido a los gráficos aumente su impacto. Fue necesario usar las estrategias de mitigación y
contingencia previstas las cuales indicaban usar gráficos provisorios.

Haber asistido al taller de sonidos permitió la realización de recursos de este tipo en forma
satisfactoria.

El curso de Gamification realizado permitió aplicar exitosamente técnicas de premiación

implementando 4 mecanismos diferentes que atendiendo a público diverso.

La utilización de una herramienta como Blogger a la cual las maestras estaban habituadas,
permitió desarrollar la comunicación con ellas en forma fluida. Esto redundó en la realización
de un producto adecuado a las necesidades del cliente.

70
8. Investigación educativa

Con el fin de agregar valor al videojuego iniciamos una investigación educativa. A

continuación se muestra el objetivo que nos planteamos y los aspectos principales de la
investigación. En el Anexo 9 Investigación sobre aplicación educativa, se puede ver en detalle
la documentación de la misma.

8.1. Objetivo general

Queremos estudiar los resultados del uso de una aplicación de tipo videojuego con
intervenciones didácticas en diferentes poblaciones educativas.

Evaluaremos la respuesta de los niños de diferentes contextos frente al videojuego en cuanto

a:
 Experiencias de uso del videojuego implementado en las tablets.
 Incidencia en el proceso de aprendizaje de lectura por el uso de la aplicación.

8.2. Objetivo específico

Dadas las limitaciones de tiempo, en la presente investigación se evaluarán aspectos referidos

a las experiencias de uso del videojuego.

Se dejará planteada la investigación para evaluar la incidencia en el aprendizaje de la lectura

de los niños al usar el videojuego.

8.3. Marco teórico

Como antecedentes que analicen el uso de la metodología global en Uruguay hemos relevado
el estudio comparativo de los métodos Analítico-Sintético y Global en el aprendizaje de la
lectura de la Profesora María Carbonell [3] y la experiencia de la Maestra Renée Behar [4] en
la escuela especial Nº 205 “Obra Morquio”.

71
El estudio de la Prof. María Angélica Carbonell desarrollado en doce escuelas públicas de
Montevideo, obtuvo las siguientes conclusiones:

- Luego de un segundo año de entrenamiento escolar, los alumnos que aprendieron a leer por
el método global se emparejaron con los otros, por tanto, los alumnos que aprendieron a leer
por este método hacen un muy marcado progreso durante el segundo año lectivo.

- En materia de ortografía se mantiene una ligera ventaja a favor del método analítico.

- Los alumnos que aprendieron a leer por el método global han conseguido una mejor
ortografía en la copia.

Esta última afirmación da cuenta de los avances realizados en los niños que usaron el método
global, en cuanto a la memorización de la palabra asociada a su imagen como un conjunto de
letras que tiene una forma particular, la cual logran copiar con menos errores que el grupo de
alumnos que no utilizó el método global.

Estas habilidades favorecen dos importantes procesos mentales que según Renée Behar se
ponen en juego en la lectura:

- la memoria, “que durante varios años fue desvalorizada y dejada de lado frente a la tremenda
importancia y jerarquía que se le daba a la capacidad de razonar, como si pensar y recordar
fueran funciones contradictorias”.

- la capacidad de anticipar, “que resulta del análisis del contexto y permite encontrar sentido
a las palabras que vendrán”. [4] Página 27.

En la publicación de Renée Behar “La hora de aprender a leer” se expone una investigación
realizada en la Escuela Especial Nº 205 “Obra Morquio” y un proyecto realizado en un Jardín
de Infantes privado. [4] Páginas 58-82.

En la escuela especial se trabajó con una muestra de niños, muy heterogénea respecto a
edades cronológicas, mentales y tipos de síndromes. Pero todos tenían un elemento común

72
pertenecían a los niveles de funcionamiento más bajos. El método usado consiste en presentar
al niño series de palabras escritas en letras de imprenta minúscula con tinta roja sobre la
cartulina blanca, sin imágenes. El tamaño de los carteles y el color de la tinta empleada se
modifican a medida que se avanza en el aprendizaje. En las conclusiones se expresa que:

- “Un alto porcentaje de los niños con bajo nivel de funcionamiento, si se les enseña logran
aprender a leer”;

- “Este método es de gran utilidad en los alumnos que han fracasado por métodos
tradicionales”. [4] Páginas 71-72.

En el proyecto desarrollado en el jardín, se trabaja con niños a partir de los 2 años, en una
propuesta totalmente apartada de la metodología tradicional. Por el contrario se emplea un
método sencillo, vinculado a lo lúdico y basado en la capacidad para imitar y memorizar que
tiene el preescolar. Luego de varios años de labor se pudo constatar que: “egresan del Jardín
alrededor de un 78% de lectores. Del 22% restante un 10% termina su proceso de
aprendizaje de la lectura durante las vacaciones y en forma espontánea y al comenzar el 1er.
año escolar. El 12% restante de los niños tuvieron alguna de las siguientes causas en el
fracaso: mala asistencia al jardín, ingreso tardío, dificultades globales o dificultades
específicas de aprendizaje”. [4] Páginas 59.

Basándonos en estas experiencias pensamos que la aplicación de la metodología global de

lectura mediante el videojuego en forma complementaria a otras formas de aprendizaje que
usa el docente, favorece la formación de lectores potenciando las habilidades que le
permitirán realizar un proceso de lectura más eficiente.

Pensamos que el videojuego es una herramienta muy eficaz a la hora de usar un mediador
para impartir cualquier aprendizaje ya que el entusiasmo que genera, si el juego está bien
realizado permite la intervención frecuente y atenta.

73
 8.4. Formulación del problema con términos operativos

Cuando hablamos de: “Experiencias de uso del videojuego implementado en las tablets”, nos
referimos a la facilidad con que logra interactuar con la aplicación. En este sentido importa
saber el tiempo en que demora en resolver las situaciones planteadas, si se adaptan bien a la
interfaz “Touch”, también interesa saber la aceptación que se logra con la presentación de una
intervención didáctica con el formato de videojuego.

La investigación se desarrollará en diferentes contextos, nos estamos refiriendo concretamente

a niños de escuela común y niños con discapacidad intelectual en escuela especial.

La forma de evaluar la incidencia en el proceso de aprendizaje de lectura se basará en el

reconocimiento de las palabras mostradas en el juego. Se realizará por medio de la aplicación
misma, en una actividad de asociación de palabras con imágenes. Esta evaluación debe
complementarse con una evaluación realizada por el docente, donde se solicitará a los niños el
reconocimiento de las palabras mencionadas.

8.5. Procedimiento para el relevamiento de datos

Para llevar a cabo la investigación se utilizará una metodología mixta que combina técnicas
cualitativas y cuantitativas. Consideramos que ambas técnicas son complementarias, no
excluyentes. Los dispositivos que se enumeran a continuación serán detallados más adelante
en este mismo capítulo.

- Se aplicarán entrevistas semi-estructuradas a las docentes.

- Se realizarán observaciones directas durante la utilización del videojuego.
- Se obtendrán datos provenientes de la aplicación.

8.6. Datos obtenidos

Para la realización de las pruebas se visitaron dos instituciones privadas, una perteneciente al
contexto de educación común y otra al contexto de educación especial. En la primera se

74
trabajó con tres grupos de educación inicial nivel 5, realizando pruebas con 50 niños
aproximadamente. En la segunda se trabajó con niños de diversas edades entre 7 y 12 años,
realizando pruebas con 20 niños aproximadamente.

En las pruebas realizadas se usaron 4 tablets con pantalla de 7 pulgadas. Dos de marca
Samsung y otras dos de marca AOC.

8.6.1. Observación directa

En general la mayoría de los niños provenientes de ambos contextos resolvieron bien todas las
pantallas (configuración de datos, menú principal, juego de naves, juego del castillo,
evaluación) luego de que se les explicó una vez el funcionamiento. En ocasiones hubo que
enseñar la tecla de retroceso del aparato para volver al menú principal.

El grado de dificultad se percibió entre fácil y adecuado, se escucharon algunos comentarios

como “es re-papa” y se observó que todos los niños pudieron terminar varias partidas de
ambos juegos, llegando incluso a la pantalla de evaluación.

Se percibió en esta primer instancia de juego que los niños estuvieron muy entusiasmados.
Para que dejaran de jugar había que pedirles si podían prestar el juego a otro compañero. Se
escucharon comentarios como “¿Me puedo llevar la tablet?”.

8.6.1. Encuesta a docentes

Pudimos constatar según la encuesta a las docentes que todos los niños querían volver a jugar
mostrando actitudes de interés (25%), entusiasmo (42%) y diversión (33%) al probar el juego.

Los temas que más comentaron los niños relativos a la experiencia de juego fueron: la tablet,
el videojuego en general, los premios, el juego del castillo y el juego del laberinto. No
comentaron sobre las palabras vistas en el juego, la música y los datos ingresados.

Todas las maestras consultadas la usarían como herramienta didáctica.

75
Al consultar las desventajas observadas se registraron las siguientes:
 Los dibujos a veces son confusos
 Debería implementarse en otros equipos por ejemplo XO
 Está inconcluso faltan completar los niveles
 El color de las palabras debería ser negro o azul
 Fallas de sonido

A continuación se muestra en forma resumida las mejoras propuestas por las docentes:
 Más juegos que se puedan resolver en clase usando las palabras
 Agregar puntaje a los juegos
 Que se vea todo el animal, usar fotos
 Usar las frases

Las principales características del videojuego que consideraron acertadas fueron:

 El tipo de juego: los contextos de naves y castillo fue un éxito
 Las palabras
 Plantear el juego con distintos niveles en el que los niños tienen que acceder según los logros
obtenidos
 Es interesante pues se trata de un tipo de competencia no frente a otros, sino frente a sí
mismos. Es un desafío para el logro de premios
 Los gráficos del juego

El resumen de las respuestas obtenidas en la encuesta puede verse en el siguiente link:

https://docs.google.com/forms/d/1EE13sO5_R0Jn51zO3vSqVbdFWu3ERgr5OOAMGgLoX
EQ/viewanalytics

8.6.1. Datos provenientes de la aplicación

Los datos obtenidos de la aplicación en formato XML se analizaron mediante la herramienta

QlikView. A continuación se muestran los resultados obtenidos al evaluar la duración de
tiempo que permaneció en cada pantalla.

76
 Figura 26. Duración por pantalla. Contexto: niños de escuela común.

Figura 27. Duración por pantalla. Contexto: niños de escuela especial.

Observamos que la pantalla Evaluación es la que muestra mayores diferencias. En ésta los
niños de contexto especial tomaron más tiempo para resolverla.

Con respecto a la duración de los juegos de Laberinto (Maze) y Naves (Ship) los niños de
contexto especial demoraron menos. Hay que tener en cuenta que la duración total de los
niños de contexto común fue mayor, llegando a niveles de mayor dificultad y de mayor
tiempo de resolución.

77
 8.7. Conclusiones

Se observaron diferencias en la aplicación del videojuego en ambos contextos:

 El tiempo de atención al juego fue levemente más breve en niños de escuela especial.
 Los niños de contexto especial necesitaron mayor tiempo para resolver la propuesta de
evaluación.
 No hubo diferencias significativas en los tiempos de resolución de los juegos
Laberinto y Naves.

Las maestras consideraron al videojuego como una herramienta válida para usar en su labor y
realizaron aportes para mejorar la propuesta realizada.

Se pudo constatar que el video juego es una propuesta viable para aplicar en las escuelas ya
que se aplicó en forma satisfactoria en ambos contextos.

78
9. Conclusiones
9.1. Logros obtenidos

Como resultado principal, se logró la construcción de un prototipo funcional que pudo ser
puesto en práctica durante las pruebas de campo. Se obtuvo un feedback positivo por parte del
cliente y de las maestras que trabajaron en las pruebas.

Se inició una investigación educativa para evaluar los resultados del videojuego, basada en
otros autores que promovieron el método global de lectura. El resultado primario de la
investigación realizada concluyó que el videojuego es una propuesta viable para aplicar en las
escuelas ya que se aplicó en forma satisfactoria en ambos contextos. Las restricciones de
tiempo del proyecto no permitieron la finalización de una segunda etapa de investigación. En
esta se indaga sobre la incidencia del juego realizado en el aprendizaje de la lectura. Se dejan
planteada la investigación junto a los dispositivos elaborados para el desarrollo de la misma.

Gamification es una técnica de motivación y fue aplicada en el videojuego con el fin de que
los niños se interesen por el videojuego. Cuando hicimos las pruebas de campo, se pudo
constatar que los niños estaban interesados en obtener más premios y así lograron visualizar
más palabras. Por esto consideramos que hemos logrado aplicar estas técnicas con éxito.

79
 9.2. Lecciones aprendidas

El proyecto buscó desarrollar un producto innovador integrando una metodología de

enseñanza tradicional a un videojuego. Debido a esto fue muy importante en la primera etapa,
realizar actividades de investigación y prototipación lo que permitió definir con mayor
precisión la viabilidad y el alcance del proyecto. Ante la incertidumbre que presenta un
proyecto innovador el plan de riesgos fue una herramienta indispensable para controlar los
factores de incertidumbre que pudieran surgir.

La aplicación del plan de calidad permitió en primer lugar definir los objetivos de calidad que
nos planteamos alcanzar para el proyecto y el producto, así como también las actividades
necesarias para lograrlo. Durante el desarrollo del proyecto se controlaron aspectos tales
como: esfuerzo según tipo de tarea y desviación en la estimación para el proceso; avance del
producto, tiempo de carga y cantidad de fallas para el producto. Finalmente se obtuvieron
datos estadísticos sobre el desarrollo del proyecto que servirán de antecedentes para futuros
proyectos. También logramos alcanzar los objetivos de calidad que nos planteamos con
respecto al producto.

Debido a la elección de Android como plataforma para el proyecto, notamos que hemos
ganado experiencia en otra plataforma y esto nos va a dar más armas para poder insertarnos
en otros mercados dentro del área informática.

80
 9.3. Conclusiones generales

Una de las principales decisiones que tomó el equipo fue la elección de la plataforma, al
finalizar el proyecto consideramos que la opción realizada por Android fue acertada por dos
razones fundamentales:
 El entusiasmo con el cual los niños recibieron el juego. A pesar de ser un prototipo
con sus detalles a mejorar, las primeras pruebas del juego fueron un éxito. La buena
presentación de los gráficos y la interacción con el acelerómetro que permite la tablet,
contribuyeron a generar la aceptación de los niños.

 Observamos que la cantidad de tablets en la población del Uruguay va en aumento,

esta observación se realiza en base a las promociones comerciales que la ofrecen como regalo
ideal para los niños. “falta poco para que sean un commodity”

A pesar de ser el proyecto un desafío importante, se cumplió con los objetivos planteados. Se
culminó el proyecto con un videojuego que permitió al equipo aprender acerca de tecnologías
emergentes y que puede servir como base para la realización de productos similares. Además
se cumplieron los requerimientos funcionales y no funcionales del producto.

Para lograr lo anterior el equipo utilizó un proceso que se adecuó perfectamente a las
necesidades del proyecto. Durante la realización del mismo, se superaron problemas como la
pérdida de la instalación en etapas tempranas del prototipo, y se fueron mejorando algunos
aspectos tanto a nivel técnico como de gestión.

Vale la pena destacar que durante el transcurso de todo el proyecto se mantuvo el buen
ambiente de trabajo y esto se vio reflejado en los resultados del proyecto.

Debido a las características del proyecto, fue muy importante en la primera etapa, realizar
actividades de investigación, cursos y prototipación lo que permitió definir con mayor
precisión el alcance.

81
10. Referencias bibliográficas

[1] Novaresse, C. “Plan Ceibal estrena 10.000 tabletas XO con Android.”. (2013, Abr 20).
[Online]. Disponible: http://www.cromo.com.uy/2013/04/plan-ceibal-estrena-10-000-tabletas-
xo-con-android/.

[2] Centro Ceibal. “Historia”. (2010). [Online]. Disponible:

http://www.ceibal.org.uy/index.php?option=com_content&view=article&id=45&Itemid=64.

[3] Carbonell M., Tuana E. y Behar R., Estudio comparativo de los métodos analítico-
sintético y global en el aprendizaje de la lectura. 1ra. ed. Montevideo: Sociedad de Dislexia
del Uruguay. 1967.

[4] Behar, R., La hora de aprender a leer. 1ra. ed. Montevideo: Ediciones Rosgal. 1997.

82
Anexos

Anexo 1 - Game Concept

1. Objetivo del documento

Este documento explica la idea fuerza o concepto del juego EduGames. Se presentan las
características principales del juego, los objetivos que se plantea y el soporte tecnológico que
usará con el fin de realizar un primer acercamiento al juego.

2. Alcance del documento

Este documento describe el videojuego EduGames, explicando la Idea Fuerza, el Género y la

Jugabilidad que desarrolla, conceptos de la estrategia de enseñanza aplicada, se especifica el
público al cual está dirigido, así como también el hardware necesario. Por último se realiza un
análisis de la competencia y los riesgos enfrentados.

3. Idea de Fuerza

Realizar un juego didáctico en 2D, para ser usado en dispositivos móviles. Se pretende
realizar un juego entretenido y atractivo que tenga intervenciones basadas en estrategias
globales de lectura para favorecer su aprendizaje.

La estructura del juego estará basada en un menú con varios mini-juegos.

La unidad temática que engloba a los videos juegos presentados se plantea como un viaje de
exploradores.

Entre los mini-juegos estará un juego de Naves el cual se desarrollará en un paisaje que
represente el espacio sideral. Se propondrá un juego de batalla con disparos donde se deben
destruir elementos amenazantes como asteroides y naves de enemigos. El objetivo es alcanzar
83
un objeto más de los que se recolectan como exploradores. Luego se pasa a la pantalla de
intervención didáctica donde se trabaja con el objeto encontrado.

Otro de los mini-juegos será un Laberinto donde aparecerá un cofre cerrado. El objetivo es
alcanzar el cofre sorteando las dificultades encontradas. Estas dificultades consistirán en
esquivar pozos y objetos que obstaculizan el camino. Al alcanzar el cofre se podrá ver el
contenido accediendo a la siguiente pantalla donde se propone la intervención didáctica.

En la pantalla de intervención didáctica se usa la metodología de lectura global, para ello se

muestra una imagen con el objeto que se está trabajando y luego aparece la palabra que
menciona al objeto junto con el audio correspondiente. A continuación aparecerá una frase
usando esta palabra. La idea es fomentar la memoria visual del niño en cuanto a la forma de la
palabra apoyándonos con el audio, sin realizar el análisis fonético de la palabra.

Para fomentar el interés por el juego se realizará un sistema de niveles, puntajes y premios.
Para visualizar los avances en el juego se usará la imagen de una mochila a la cual se le
encenderán gráficos circulares de colores representando los objetos encontrados clasificados
por categorías.

Quedará proyectado un juego de Memoria el cuál se jugará en la modalidad “maestra”. Esta

es una modalidad de juego pensada para desarrollarse en forma grupal en la clase. Este juego
es más adecuado para realizar en forma colaborativa en un grupo de niños.

También se proyectarán una serie de actividades a resolver en forma de juego, del tipo
“encuentra la correcta”, usando las mismas palabras vistas en los mini-juegos, en donde se irá
incrementando la dificultad requerida para encontrar la solución.

84
4. Género

Cada uno de los mini-juegos tendrá su género particular atendiendo distintos intereses de los
niños.
En forma general para todos los mini-juegos se presentarán gráficos sencillos y coloridos que
faciliten la discriminación visual del público objetivo.

• Naves - Acción
El juego de Naves es un juego de acción, donde el jugador tendrá que disparar desde una nave
para defenderse de los enemigos y objetos que aparecen y pueden destruirlo.

• Laberinto – Estrategia
El juego del Laberinto es un juego de estrategia donde el niño deberá descubrir el recorrido
que lo lleve a alcanzar el cofre sorteando los obstáculos que aparecen.

• Memoria – Puzzle
El juego de memoria hace uso de la capacidad de memorizar del jugador, poniendo en
práctica distintas estrategias para no olvidarse de la posición de una palabra.

5. Jugabilidad y Funcionalidad

El videojuego potencia su jugabilidad mediante la utilización de gráficos y efectos de audio

atractivos para los niños. La estimulación visual y sonora, a su vez es uno de los elementos
fundamentales de la metodología de aprendizaje usada.

Otra de las características de la jugabilidad que hay que destacar, es que se apunta a
desarrollar un videojuego rápido y ágil, donde el jugador pueda terminar los niveles en pocos
minutos.

Se incentivará el atractivo del juego mediante un sistema de puntajes e insignias. El puntaje se

mostrará en la pantalla a medida que avanza en las diferentes etapas y niveles del juego. Las

85
insignias se obtendrán en base a logros individuales de uso, por ejemplo: en base a una
cantidad días seguidos jugó con el videojuego, a una cantidad de palabras encontradas,
cuando finaliza un nivel o cuando aparece una palabra especial.

Cuando el jugador lo desee podrá acceder a una pantalla donde aparecerán todas las Insignias
otorgadas en color y las insignias por ganar con la imagen sombreada o gris.

6. Público Objetivo

El juego está dirigido a niños de edad comprendida entre 4 y 7 años quienes están
incorporando conceptos de lectura o niños con discapacidad intelectual de cualquier edad,
para quienes los métodos globales de aprendizaje de la lectura son muy favorables.

86
7. Hardware Requerido

El video juego se desarrollara para ser usado en dispositivos móviles, con el sistema operativo
Android 4.0 en adelante.

Se desarrollará en el lenguaje Java usando Eclipse como entorno de desarrollo con una SDK
que permite desarrollar para Android.

Figura 1 Dispositivos móviles [1].

8. Análisis de Competencia

Se han encontrado una amplia oferta diversos juegos para las XO similares a los que vamos a
desarrollar, pero sin el complemento que utiliza la metodología global de aprendizaje de la
lectura.

87
9. Análisis de Riesgos

A continuación se detallaran los principales problemas que consideramos inicialmente pueden

representar algún riesgo para el desarrollo del proyecto:

Id Riesgo Probabilidad Impacto Magnitud

Retrasos en el proyecto debido a mala

1 estimación 0,8 5 4
Retrasos en el cronograma debido a una
mala elección del Lenguaje de
2 Programación (Motor del juego) 0,9 4 3,6
Retrasos en el cronograma por la
3 búsqueda y utilización de sonidos 0,9 4 3,6
No tener disponible el hardware para
4 correr la aplicación 0,7 5 3,5
Los juegos resulten poco atractivos para
5 los niños 0,7 5 3,5
Retrasos en el cronograma por la
6 búsqueda y utilización de gráficos 0,8 4 3,2
Cambios en los requerimientos por
7 insatisfacción del cliente (maestros) 0,6 5 3
No cumplir con los requerimientos por
dificultades en la obtención de datos
8 estadísticos 0,6 5 3
Mala comunicación entre los actores del
9 proyecto 0,6 4 2,4
Aplicación incorrecta de conceptos de
10 Gamification 0,6 3 1,8

Figura 1. Tabla de Riesgos

88
10. Resumen

Se plantea un juego que contiene varios mini-juegos con características ya conocidas

(laberintos, naves) y los vincula con una metodología de aprendizaje para la lectura.

El juego planteado es una innovación en cuanto que no hay juegos similares, que combinen
los juegos tradicionales ya existentes con metodologías de lectura globales. Como toda
innovación estamos expuestos a los riesgos de fracaso que toda propuesta de este tipo tiene
asociada.

Es un desafío realizar un producto de calidad para disminuir los factores de riesgo del
proyecto.

11. Referencias bibliográficas

[1] Android Blog (2012, Nov. 11) [Online]. Disponible:

http://www.androidblog.es/2012/11/google-confirma-que-empezara-a-vender-nexus-4-y-
nexus-10-el-13-de-noviembre/

89
Anexo 2 - Game Design Document

1. Objetivo del documento

Este documento en conjunto con el Technical Design Document especifican los

requerimientos para el desarrollo del videojuego: “EduGames”. Su objetivo es proveer al
equipo de desarrolladores y a miembros de áreas involucradas (gráficos y clientes) la
información necesaria para la construcción del videojuego.

2. Alcance del documento

Este documento abarca los requerimientos funcionales, recursos y los elementos necesarios
para la construcción del videojuego.

3. Glosario

Gameplay: Grado de interacción entre el jugador y el juego.

UI: (User Interface) Interfaz de usuario.

90
4. Introducción

“EduGames” es un juego didáctico que te propone experimentar diferentes experiencias en un

viaje de aventura. A medida que el juego avanza y al finalizar cada sesión de juego aparecerán
intervenciones usando metodologías globales de lectura. Esta intervención mostrará una
palabra con su respectiva imagen y sonido. La palabra se selecciona de un conjunto de
categorías, entre ellas se encuentran animales, comidas, cuerpo humano, etc. Todas las
palabras fueron previamente elegidas con criterios didácticos.

Los jugadores que emprendan el viaje recorrerán terrenos muy diversos: el espacio sideral
donde no existe la gravedad, un viejo castillo de madera con laberintos que dan mil vueltas, a
su vez deberán resolver desafíos para continuar su viaje.

Durante el juego se deberán recolectar tesoros y objetos encontrados que se irán guardando en
una mochila. Al llenarla se podrá acceder a un nuevo nivel con otros retos, donde se
recolectarán más sorpresas.

Se concederán diferentes premios a medida que se avanza en el juego por diferentes motivos
que el jugador irá descubriendo. Los premios se otorgarían por: cantidad de palabras
encontradas, cantidad de días seguidos que descubrió una palabra, palabras mágicas y al
completar cada nivel.

91
5. Descripción de la Historia

Como en todo juego existe una historia a partir de la cual el juego nace o se crea:

"Los protagonistas de este juego son exploradores que emprenderán un viaje de aventura por
tierras desconocidas. Recorrerán terrenos muy diversos: el espacio sideral donde no existe la
gravedad, un viejo castillo de madera con laberintos que dan mil vueltas; a su vez deberán
resolver desafíos para continuar su viaje. Llevarán una mochila donde guardaran los tesoros y
objetos encontrados. Para su supervivencia también llevarán una cantimplora con agua, una
linterna que funciona con pilas, un mapa que les indicará el camino por recorrer y un celular
para mandar mensajes a sus amigos. Durante todo el recorrido deben estar atentos a los
obstáculos que puedan aparecer: pozos de agua y pasadizos que se desbarrancan en el
laberinto, asteroides explosivos y agujeros negros en el espacio sideral...

Ven a experimentar nuevas experiencias y únete a este viaje de aventura."

5.1. Gameplay

“EduGames” es un juego que reúne varios mini juegos, con gráficos en 2D, en el cual se
mezclan los géneros de aventura, acción, estrategia y colaboración.

El gameplay de uno de los juegos, las naves, se enfoca en la destreza del jugador para realizar
los diversos desafíos que se presentan, mientras que en el laberinto se enfoca más a la
exploración y la estrategia. Por último, el juego de memoria apunta a la colaboración,
permitiendo su mecánica la participación de más de un jugador.

92
6. Modos de Juego

Existen tres modalidades de juego: la primera llamada “Individual”, otra como “Invitado” y la
tercera “Maestra”.

6.1. Individual

El jugador competirá consigo mismo avanzando en los distintos niveles que ofrece el juego.
Desde un nivel muy básico donde se indica todo lo que debe hacer, de forma que conozca la
mecánica de los juegos; a niveles más avanzados con dificultades incorporadas de forma
gradual.

A medida que avanza se van registrando sus logros en una mochila. Esta “Mochila” funciona
como un tablero de avance en cada categoría de palabras trabajadas.

6.2. Invitado

Modo usado para que un niño preste su equipo a un amigo. Esta modalidad se inicia en el
nivel inicial. Los logros obtenidos no se registran en la “Mochila”.

6.3. Maestra

Esta modalidad está diseñada para trabajar en el ámbito escolar. Pueden participar varios
jugadores colaborando entre ellos. Se accede a un juego colaborativo llamado memoria. Los
logros obtenidos no se registran en la “Mochila”.

Las palabras que aparecerán en el transcurso de este juego serán de una sola categoría, la cual
va a ir tomando temáticas que las docentes seleccionaron para este juego.

93
7. Personajes

Habrá solo un personaje principal en el juego, el cual podrá ser caracterizado por el jugador
eligiendo:
 Color de la camiseta.
 Sexo.

Este personaje aparecerá en la pantalla principal y se desplazará hasta las distintas opciones
del menú.

En el juego del laberinto se mostrará una versión más reducida del mismo personaje.

7.1. Aspecto

Es un niño de unos 5 años, vistiendo ropa casual.

7.2. Animación

El personaje tiene la habilidad de caminar.

7.3. Sonido

El personaje emite un sonido de festejo al descubrir algún nuevo objeto en el desarrollo del
juego.

94
8. Escenarios

Los juegos de “EduGames” se desarrollan en dos escenarios que se detallan a continuación:

 El espacio sideral.
 Un viejo castillo de madera.

Existen otros escenarios o pantallas importantes a tener en cuenta que serán descriptos en la
sección de Interfaz de Usuario:
 Escenario de Presentación
 Menú principal del juego
 Intervención didáctica
 Carga de datos personales
 Premios (Badges)
 Evaluación didáctica

Al iniciar el juego se accede en primer lugar a la pantalla de Presentación, luego aparece el

Menú principal que permite acceder a las diferentes opciones que brinda el juego, entre ellas
tenemos: los distintos tipos de juego, los diferentes modos de juego, configuración de datos y
vista de premios.

La Intervención didáctica se realizará una vez finalizado el juego partiendo de los objetos
encontrados en desarrollo del mismo. Se usará la metodología de lectura global mostrando la
palabra con el audio correspondiente en primer lugar y una frase que haga uso de la palabra a
continuación.

En la pantalla de Datos se podrán configurar datos referidos al jugador: Nombre o apodo,

edad, sexo y color preferido.

En la sección de premios (Badges) se podrán ver todos los Badges del juego. Los ya ganados
aparecerán con su imagen correspondiente a color. Los que restan por ganar aparecerán con
otra imagen en gris o con una imagen de una llave.

95
Al finalizar cada categoría de palabras lo cual ocurre al completar la cantidad necesaria de
palabras (entre 3 y 5 palabras) se accederá a una pantalla donde se realizara la Evaluación del
aprendizaje logrado. Consistirá en reconocer la escritura de las palabras que aparecieron en
las intervenciones didácticas.

8.1. Viejo castillo de madera

8.1.1. Descripción

En este escenario se desarrollará el juego del laberinto. Este juego consiste en alcanzar el
cofre donde se esconden las imágenes de las palabras que irán aprendiendo.

8.1.2. Boceto

Figura 1 Boceto Laberinto.

8.1.3. Objetos

Los objetos son:

 Background
 Personaje
 Paredes del laberinto
 Baúl con elemento a recolectar

96
 8.1.4. Audio

Música de fondo durante el desarrollo del juego.

Sonido de festejo al llegar al baúl.

8.2. El espacio sideral

8.2.1. Descripción

En este escenario se desarrollará el juego de las naves.

8.2.2. Boceto

Figura 2 Boceto del juego de Naves.

8.2.3. Objetos

Los objetos son:

 Nave
 Background estelar
 Asteroides
 Otros planetas
 Estación espacial

97
 8.2.4. Audio

Música de fondo durante el desarrollo del juego.

Sonido de festejo al llegar a la estación espacial.

98
9. Interfaz gráfica de usuario / GUI

En esta sección se detallan todas las interfaces gráficas de usuario desplegadas a lo largo del
videojuego. Estas interfaces se organizan en: las involucradas en el menú principal, las que
pertenecen al menú del videojuego, aquellas ya descriptas como escenarios y las pantallas de
intervención didáctica.

9.1. Presentación

9.1.1. Descripción

Al iniciar el juego se accede en primer lugar a la pantalla de Presentación, en ella se podrá

leer y escuchar la historia del juego. La versión escrita de la historia se mostrará gradualmente
a medida que el audio avanza.

Así mismo, mientras la presentación del juego avanza, dará tiempo a cargar los recursos
necesarios para iniciar el juego.

9.1.2. Boceto

Figura 3 Boceto de la Presentación.

99
 9.1.3. Objetos

Los objetos son:

 El logo del videojuego
 El texto de la historia

9.1.4. Audio

La lectura de la historia a medida que va apareciendo el texto.

9.2. Menú Principal

9.2.1. Descripción

Luego de la presentación se visualiza el menú principal, en esta pantalla se podrán elegir

distintos elementos que nos llevarán a los mini juegos u otras pantallas del videojuego.

9.2.2. Boceto

Figura 4 Boceto del Menú Principal.

100
 9.2.3. Objetos

Los objetos son:

 Acceso al mini juego de las naves
 Acceso al mini juego del laberinto
 Acceso a los datos
 Acceso a los premios
 Acceso a la modalidad maestra
 Acceso a la carga de datos del invitado
 Estado del nivel actual

9.2.4. Audio

Se escuchara una música de fondo mientras se esté en esta pantalla.

9.3. Intervención didáctica

9.3.1. Descripción

Al finalizar cada mini juego se mostrará una pantalla con una imagen y su palabra asociada.
También se mostrará una frase que incluya esta palabra dando un ejemplo de uso.

101
 9.3.2. Boceto

Figura 5 Boceto de la Intervención didáctica.

9.3.3. Objetos

Los objetos son:

 La palabra en mayúscula
 La imagen que representa la palabra
 La frase asociada a la palabra

9.3.4. Audio

Se escuchará a la palabra, también se escucha la frase.

102
 9.4. Carga de datos personales

9.4.1. Descripción

A los efectos de identificar al jugador, y a su vez él se identifique con el personaje del

videojuego.

9.4.2. Boceto

Figura 6 Boceto de la Carga de datos.

9.4.3. Objetos

Los objetos son:

 Apodo
 Edad
 Sexo
 Color

9.4.4. Audio

Se escuchara una música de fondo.

9.5. Premios
103
 9.5.1. Descripción

Esta pantalla va a incluir todos los premios obtenidos hasta el momento. Además deberá
incluir una breve descripción de cada uno de ellos para que el usuario sepa cómo obtenerlo.

9.5.2. Boceto

Figura 7 Boceto de la Pantalla de premios.

9.5.3. Objetos

Los objetos son:

 Badges (premios)
 Descripción del premio

9.5.4. Audio

Se escuchará una música de fondo.

104
 9.6. Evaluación didáctica

9.6.1. Descripción

La pantalla de evaluación nos va a ayudar a saber cuánto se aprendió. La idea principal es que
el jugador sepa relacionar la palabra con su imagen.

9.6.2. Boceto

Figura 8 Boceto de la Evaluación didáctica.

9.6.3. Objetos

Los objetos son:

 Las palabras
 Las imágenes correspondientes a las palabras

9.6.4. Audio

Se escuchara una música de fondo y al completar correctamente el ejercicio una música que
refleje el resultado del ejercicio. Si se toca una palabra, se escucha la palabra para
identificarla.
105
10. Diagrama de interacción de pantallas (Story Board)

En el siguiente boceto se pueden observar los distintos bocetos de las pantallas y la

interacción entre ellas:

Figura 9 Boceto de la Interacción.

El flujo de las pantallas está marcado con rojo y sería el siguiente:

1. Se muestra la pantalla de presentación

2. Depende del estado de los datos

a. Si no hay datos ingresados, se muestra la pantalla de datos
b. Si ya hay datos, se muestra el menú principal

3. Desde el menú el jugador puede elegir varios caminos

a. Elige jugar al laberinto
b. Elige jugar a las naves
c. Elige ver los premios
d. Elige actualizar los datos

106
4. Según lo elegido anteriormente
a. Luego de jugar el laberinto, aparece la pantalla didáctica de la palabra
b. Luego de jugar a las naves, aparece la pantalla didáctica de la palabra
c. En los demás casos vuelve al menú principal

5. Según la cantidad de veces que jugó

a. Si finalizó una categoría, se muestra la pantalla de evaluación
b. Desde la pantalla didáctica puede elegir jugar de nuevo, o
c. Puede elegir ir hacia atrás, o sea, volver al menú

6. Se muestra la pantalla de premios al conseguir finalizar la evaluación correctamente

7. Vuelve al paso 3.

107
11. Listado de requerimientos completados

# Requerimiento Etapa
1 Mostrar la historia del juego Preproducción
2 Menú de opciones Preproducción
3 Mini juego 1 Producción – 2
4 Mini juego 2 Liberación
5 Juego para la clase No se realizó
6 Intervención didáctica Producción – 1
7 Evaluación de conocimientos adquiridos Liberación
8 Premiación Producción – 1
9 Muestra de avance Producción – 1
10 Registro de datos del jugador Producción – 1
11 Saludo de despedida Producción – 2
12 Música Producción – 3
13 Dibujos de las palabras No se finalizó
14 Datos para analizar Producción – 3
15 Documentación Liberación
Figura 9 Boceto de la Interacción.

Existieron dos requerimientos que no fueron completados. El juego para las maestras no fue
hecho debido a un ajuste en el alcance del proyecto. Los dibujos de las palabras no se
completaron, se alcanzó finalizar todo el nivel 1 para las seis categorías.

108
Anexo 3 - Technical Design Document

1. Objetivo del documento

El presente documento, en conjunto con el Game Design Document (GDD), especifica los
requerimientos para el desarrollo del videojuego. Su objetivo principal es proveer al equipo de
desarrolladores y a miembros de otras áreas involucradas, como ser el cliente, la información
necesaria sobre los principales aspectos técnicos y el diseño de la arquitectura del videojuego.

2. Alcance del documento

Este documento en particular especifica los requerimientos no funcionales, y además presenta

una solución a alto nivel del diseño del videojuego. También abarca los principales aspectos
técnicos involucrados en el desarrollo del mismo.

3. Glosario

ANDROID: es un sistema operativo basado en Linux diseñando principalmente para

dispositivos móviles con pantalla táctil como teléfonos inteligentes o tablets desarrollado por
Google.

ANDENGINE: es un motor para el desarrollo de videojuegos, creado por Nicolas Gramlich.

DTD: Document Type Definition, definición del tipo de documento es un descripción de

estructura y sintaxis de un documento XML.

FILESYSTEM: Estructuran la información guardada en una unidad de almacenamiento

(normalmente un disco duro de una computadora), que luego será representada ya sea textual
o gráficamente utilizando un gestor de archivos.

109
FPS: Imágenes por segundo (frames per second) es la medida de la frecuencia a la cual un
reproductor de imágenes genera distintos fotogramas (frames).

FRAMEWORK: Arquitectura de software que modela las relaciones generales de las

entidades del dominio.

FROZEN SPOT: Consiste en definir la arquitectura general de un sistema de software, es

decir, sus componentes básicos y las relaciones entre ellos. Estas entidades permanecen sin
cambios (congelados) en cualquier instancia de la aplicación.

GNU: General public license, es la licencia más ampliamente usada en el mundo del software
y garantiza a los usuarios finales la libertad de usar, estudiar, compartir y modificar el
software.

GPU: Graphics processing unit, unidad de procesamiento gráfico es un coprocesador

dedicado al procesamiento de gráficos u operaciones del procesador central en aplicaciones
como los videojuegos.

HUD: Head-Up Display. En videojuegos es la manera con la cual se muestra al usuario la

información de la partida.

HOT SPOT: En la arquitectura de software, los hot spots representan aquellas partes donde
los programadores añaden su propio código para agregar la funcionalidad específica para su
proyecto.

IDE: Entorno de desarrollo integrado.

IHC: Interacción Humano Computadora.

JAVA: Lenguaje de programación. Las aplicaciones de Java son generalmente compiladas a

bytecode (clase Java) que puede ejecutarse en cualquier máquina virtual Java (JVM) sin
importar la arquitectura de la computadora subyacente. Java es un lenguaje de programación

110
de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado
específicamente para tener tan pocas dependencias de implementación como fuera posible.

KERNEL: Es el encargado de gestionar recursos, facilitando y permitiendo a las aplicaciones

el acceso seguro al hardware.

LAYERS: Capa de la pantalla que contiene sprites.

LINUX: es un kernel de sistema operativo basado en Unix desarrollado por colaboradores de

todo el mundo.

MB: Es una unidad de medida de cantidad de datos informáticos. Es un múltiplo del byte u
octeto, que equivale a 106 bytes.

MEMORIA VIRTUAL: Es una técnica de administración de la memoria real que permite al

sistema operativo brindarle al software de usuario y a sí mismo un espacio de direcciones
mayor que la memoria real o física.

RAM: la memoria de acceso aleatorio (Random Access Memory) se utiliza como memoria de
trabajo para el sistema operativo, los programas y la mayoría del software. Es allí donde se
cargan todas las instrucciones que ejecutan el procesador y otras unidades de cómputo.

PLAN DE SQA: Este documento tiene como objetivo establecer el plan de aseguramiento de
calidad a ser utilizado por el grupo de desarrollo del proyecto.

SDK: Kit de desarrollo de software.

SPRITE: Mapa de bits dibujados en la pantalla de ordenador por hardware gráfico

especializado.

TABLET: es una computadora portátil de mayor tamaño que un teléfono inteligente

integrado en una pantalla táctil con la que se interactúa primariamente con los dedos, sin
necesidad de un teclado físico ni ratón.

111
THREADS: Los también conocidos como hilo de ejecución o subproceso, son una
característica que permite a una aplicación realizar varias tareas a la vez (concurrentemente).
Los distintos hilos de ejecución comparten una serie de recursos tales como el espacio de
memoria, los archivos abiertos, situación de autenticación, etc. Esta técnica permite
simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones
simultáneamente.

UNIX: es un sistema operativo portable, multitarea y multiusuario, desarrollado por un grupo

de empleados de los laboratorios Bell de AT&T en 1969.

XML: eXtensible Markup Language, es un metalenguaje extensible de etiquetas desarrollado

por el World Wide Web Consortium (W3C).

112
4. Requerimientos no funcionales
4.1. Hardware y Software

Se requerirá de un dispositivo móvil, en especial una Tablet de 7 pulgadas, el cual posea el

sistema operativo Android, de versión igual o superior a 4.1.2 (API Level 16). El dispositivo
deberá poseer pantalla táctil.

Para poder ejecutar el juego correctamente, se recomienda que el dispositivo tenga

características similares o superiores a las siguientes:

 Memoria RAM: 512 GB

 Procesador: dual core 1.0 GHz
 GPU: cuatro núcleos 267-400 Mhz
 Resolución 800 x 600 (WSVGA)

4.2. Performance

Para dar sensación de suavidad, el juego debe correr como mínimo a 24 FPS. Al iniciar el
juego, el tiempo de carga deberá ser menor a 7 segundos. Al finalizar el juego, el tiempo de
grabación de datos deberá ser menor a 4 segundos.

4.3. Jugabilidad

La jugabilidad se definió como el grado de interacción entre el jugador y el juego. Para lograr
una buena interacción se va a dividir la jugabilidad en los siguientes sub atributos:

 Comandos intuitivos: El juego tendrá comandos que sean habituales para usuarios
frecuentes de este tipo de dispositivos móviles. Además, para una misma acción habrá
más de un comando para facilitar la interacción y el aprendizaje del juego.
 No linealidad: Para que el juego no sea lineal y no aburra al jugador, se deberá
asegurar de que cada round se pueda resolver de más de una forma posible sin que
haya estrategias dominantes.
113
  Enseñar al jugador: Se especifica como deseable definir una serie de tutoriales que
permitan, en poco tiempo (no más de 3 minutos), enseñar al jugador los comandos
básicos del juego.

4.4. Robustez

Por cada corrida de un round, se espera alcanzar un valor de 0.1 fallas. Esto se traduce a una
falla cada 10 corridas.

4.5. Modificabilidad

El juego debe quedar abierto a futuros cambios, como por ejemplo el agregado de palabras,
niveles y categorías, así como la incorporación de nuevos mini juegos.

4.6. Idioma

Todos los textos de la interfaz son en español. El código fuente deberá ser escrito en inglés.

114
5. Componentes necesarios para el desarrollo

Figura 1. Componentes necesarios para el desarrollo.

Los componentes necesarios para el desarrollo son:

 SDK Android API Level 15 o superior

 AndEngine GLES 2 como motor del videojuego
 Eclipse Juno
 Dispositivo móvil con la versión adecuada del sistema operativo

Otros componentes utilizados fueron:

 Assembla como repositorio

 Google Drive para gestionar tareas
 Gamification para motivar el uso del videojuego
 Blogger para publicitar y comunicarnos con el cliente

115
La figura anterior muestra que con la suma de estos componentes se programará el
videojuego, el cual será compilado por Eclipse, generándose un archivo de extensión apk, que
será instalado en el dispositivo móvil.

A continuación se pasarán a describir los distintos componentes.

5.1. Android

Android es el sistema operativo enfocado para ser utilizado en dispositivos móviles. Este
sistema operativo fue desarrollado por la Open Handset Alliance, la cual es liderada por
Google.

Para poder desarrollar aplicaciones para Android, es imprescindible poseer el kit de desarrollo
de software (SDK) provisto por Google, el cual se puede descargar gratuitamente. Todas las
aplicaciones desarrolladas están comprimidas en formato apk, y se pueden instalar sin
dificultad en la mayoría de los dispositivos.

5.2. SDK Android

El kit de desarrollo de Android incluye todas las herramientas necesarias para poder realizar
las aplicaciones que exploten al máximo todas las virtudes del dispositivo.

5.3. AndEngine

AndEngine es un motor para el desarrollo de videojuegos, creado por Nicolas Gramlich, es un

excelente marco 2D, completamente equipado, libre y de código abierto para la plataforma
Android. Es uno de los pocos marcos en 2D para la plataforma Android, que constantemente
se está utilizando para crear juegos con estilo y diversión tanto por desarrolladores
independientes y profesionales por igual, e incluso se ha utilizado en algunos de los juegos
más exitosos en el mercado para la fecha.

116
El aspecto más atractivo de AndEngine es la increíble facilidad de creación de juegos. La
posibilidad de que el diseño y la codificación de un juego en cuestión de semanas después del
primer uso de AndEngine no es demasiado descabellado, aunque esto no quiera decir que será
un juego perfecto.

5.4. Eclipse Juno

Eclipse es una plataforma de desarrollo compuesta por un conjunto de herramientas de

programación de código abierto para desarrollar aplicaciones. El entorno de desarrollo
integrado (IDE) de Eclipse emplea módulos (en inglés plug-in) para proporcionar toda su
funcionalidad al frente de la plataforma de cliente enriquecido, a diferencia de otros entornos
monolíticos donde las funcionalidades están todas incluidas, las necesite el usuario o no.
Con el fin de mantenerse al día, cada lanzamiento del proyecto Eclipse se dirige a entornos de
funcionamiento razonablemente actuales. Eclipse Juno es la versión de Eclipse del 27 de
Junio de 2012 (Versión 4.2) desarrollada en Java SE 6.

117
 5.5. Otras herramientas

5.5.1. Assembla

Assembla provee una herramienta de colaboración y de seguimiento de tareas basadas en la

nube para organizar y administrar proyectos de desarrollo, la cual será utilizada como
repositorio del código generado.

5.5.2. Google Drive

Google Drive es un servicio de alojamiento de archivos. Es accesible por su página web desde
ordenadores y disponible para Android que permite editar documentos y hojas de cálculo.

5.5.3. Gamification

Gamification sirve para hacer el ámbito de aplicación más atractivo mediante el fomento de
los comportamientos deseados, aprovechándose de la predisposición psicológica de los seres
humanos para participar en juegos.

5.5.4. Blogger

Es un servicio de Google que permite publicar contenidos sin tener que escribir código o
instalar programas de servidor o de scripting. Los blogs alojados en Blogger generalmente
están alojados en los servidores de Google dentro del dominio blogspot.com. Nuestro equipo
lo utilizará como herramienta de comunicación entre el Cliente y nosotros. Esto servirá para
poder tener una comunicación a toda hora y permitirá registrar los cambios.

118
6. Diseño

6.1. Vistas

A continuación se especificará el diseño de la solución, en función de los distintos

requerimientos funcionales especificados en el GDD, y los requerimientos no funcionales
especificados en el presente documento. La especificación del diseño se realizará en distintas
vistas, las cuales ayudan a la comprensión del mismo, presentadas de mayor a menor nivel de
abstracción.

6.1.1. Vistas de despliegue

En el siguiente diagrama se puede ver cómo estará distribuida la aplicación. Un dispositivo

móvil tendrá la posibilidad de bajar la aplicación desde play.google.com para ser instalada de
forma local.

Figura 2. Despliegue de la aplicación.

119
 6.1.2. Vista lógica

Mediante esta vista se buscará especificar el modelo de objetos del sistema. Para ello se
utilizan los siguientes diagramas de UML:

 Diagramas de Módulos / Paquetes

 Diagrama de Clases
 Diagramas de Interacción

Diagrama de Módulos / Paquetes

El siguiente diagrama muestra los principales módulos que involucran a nuestra aplicación.

Figura 3. Diagrama de Módulos / Paquetes.

Las interfaces que permiten la comunicación entre EduGames y AndEngine son las clases que
provee el motor de juegos AndEngine. Estas permiten al desarrollador utilizar y/o extender
cualquiera de las entidades o funcionalidades contenidas en el framework.

La comunicación entre EduGames y el dominio, se realiza a través de las clases expuestas por
el dominio. Esto permite desacoplar a EduGames de los archivos generados y de los archivos
necesarios para levantar los distintos juegos.
120
El dominio, una de sus funciones es encargase de intercambiar información con Data, quien a
su vez se encarga de grabar la información generada por los distintos juegos. También Data es
responsable de interpretar los archivos necesarios para levantar la información inicial del
videojuego.

El paquete Utils nos permite acceder a funciones y métodos comunes para todos los paquetes
involucrados en la solución del videojuego.

Diagrama de Clases

Figura 4. Diagrama de Clases de EduGames

Este diagrama muestra todas las escenas del videojuego. Es la capa de presentación donde
tiene la responsabilidad de ser la interfaz con el usuario. Interactúa con el dominio y con
AndEngine.

121
 Figura 5. Diagrama de Clases del Dominio

El dominio es responsable de implementar las clases necesarias para poder instanciar los
datos generados por el videojuego. Lleva la lógica del videojuego, esta información se
muestra como la mochila, quien va a mostrar el avance del jugador.

Figura 6. Diagrama de Clases de Data

122
El paquete data contiene todo el conjunto de clases que se encargan del repositorio de datos
del videojuego.

Figura 7. Diagrama de Clases de Utils

Utils contiene las clases y procedimientos comunes que se utilizan en los distintos paquetes.

123
Detalle de las clases

Clase Paquete Descripción

BadgesScene com.edugames Responsable de mostrar los premios que el
jugador ganó.
BaseScene com.edugames Responsable de definir las características
de todas las escenas.
DataScene com.edugames Responsable de mostrar las preferencias
del jugador. También es quien se encarga
de enviar los datos para ser persistidos.
EduGamesActivity com.edugames Es la clase por donde comienza la
aplicación. Carga la configuración inicial
y llama a la escena de lanzamiento.
EvaluationScene com.edugames Responsable de mostrar la evaluación de
las palabras aprendidas. Muestra varias
palabras e imágenes que deben ser
asociadas.
GameOverScene com.edugames Responsable de mostrar un mensaje
cuando el jugador cierra la aplicación.
GameScene com.edugames Responsable de definir las características
de todos los juegos.
GuestScene com.edugames Responsable de mostrar la carga de datos
para el invitado.
LoadingScene com.edugames Responsable de mostrar el mensaje
"Cargando ...".
MainMenuScene com.edugames Responsable de mostrar las opciones del
menú principal del juego.
MazeGame com.edugames Responsable del juego laberinto.
MazeScene com.edugames Responsable de mostrar la interfaz del
juego laberinto.
PrizeScene com.edugames Responsable de mostrar la animación
cuando un jugador gana un premio.

124
Clase Paquete Descripción
ResourcesManager com.edugames Responsable por manejar los recursos de
todas las escenas.
SceneManager com.edugames Responsable por manejar la navegación
por todas las escenas.
Ship com.edugames Responsable por manejar el juego de
naves.
ShipGame com.edugames Responsable del juego de naves.
ShipScene com.edugames Responsable de mostrar la interfaz del
juego de naves.
SplashScene com.edugames Responsable de mostrar la historia del
juego mientras se cargan los recursos.
TeacherScene com.edugames Responsable de mostrar el juego utilizado
por las maestras.
WordsScene com.edugames Responsable de mostrar la intervención
educacional.
BackpackLoader com.edugames.data Responsable de levantar la información de
la mochila desde un XML.
DataManager com.edugames.data Responsable de las instancias de los
campos que contienen la lógica del
videojuego.
DictionaryLoader com.edugames.data Responsable de levantar la información
del diccionario, o sea todas las palabras y
frases utilizadas.
HistoryXMLGenerator com.edugames.data Responsable de generar un archivo XML
con la información de las escenas.
MazeLoader com.edugames.data Responsable de leer un nivel para el juego
laberinto.
PlayXMLGenerator com.edugames.data Responsable de generar un archivo XML
con la información de las partidas.
Preferences com.edugames.data Responsable de manejar y persistir los
datos de preferencias.

125
Clase Paquete Descripción
XMLParser com.edugames.data Responsable de parsear los datos XML
XMLRecorder com.edugames.data Graba los archivos XML en el almacén
externo.
Backpack com.edugames.domain Responsable de la información de todas
las partidas (jugador, partida, premios,
etc.)
Badge com.edugames.domain Responsable de la información del Premio
Game com.edugames.domain Responsable de la información del Juego.
Gamer com.edugames.domain Responsable de la información del
Jugador.
Gamification com.edugames.domain Responsable de la información de
Gamification.
History com.edugames.domain Responsable de la información de
tiempos.
Milestone com.edugames.domain Responsable de la información de los
intervalos del Juego.
Play com.edugames.domain Responsable de la información de la
Partida.
Tree com.edugames.domain Árbol.
TreeNode com.edugames.domain Nodo del árbol.
Word com.edugames.domain Palabra para los juegos.
Color com.edugames.utils Responsable de la información de Color.
Size com.edugames.utils Tamaño utilizado por ejemplo en
imágenes.
Utility com.edugames.utils Utilizada para métodos comunes.
XMLParser com.edugames.data Responsable de parsear los datos XML.
XMLRecorder com.edugames.data Graba los archivos XML en el almacén
externo.
Figura 8. Detalle de clases

126
Diagramas de Interacción

El siguiente diagrama busca mostrar cómo funciona el flujo principal del juego desde que se
comienza la aplicación y se cargan los distintos objetos hasta que se termina de jugar una
partida.

Figura 9. Diagrama de Secuencia

127
 6.1.3. Vista de comportamiento

Juegos

En esta vista veremos cómo es el comportamiento de los juegos. Al finalizar cada juego se
ejecuta la parte didáctica donde se muestra una palabra, su imagen y sonido. Al finalizar de
mostrar las palabras correspondientes de las distintas categorías se muestra una escena de
evaluación del conocimiento adquirido. En esta vista se ve el juego de Naves, al igual que el
de Laberinto la mecánica es la misma.

Figura 10. Diagrama de Secuencia de Naves

128
 6.2. Decisiones de diseño

Al momento de diseñar la solución, una de las primeras cosas que se tuvo en cuenta fue
cumplir con los principios de diseño que apliquen a este proyecto, para poder alcanzar los
distintos atributos de calidad.

Se tuvieron en cuenta los principios de clausura común, donde las clases se agruparon según
un mismo motivo. Es así que tenemos un paquete referente a los datos, otro referente al
dominio, otro que refiere a métodos comunes y otro a todo lo referente a la interacción con el
usuario y los videojuegos. También se tuvo en cuenta el principio de dependencias acíclicas
donde la dependencia de los paquetes forma un grafo dirigido y acíclico.

Se tomaron muy en cuenta los principios concernientes al diseño de clases. Para poder
cumplir con el principio de cohesión, el cual plantea que debe existir una fuerte relación de
responsabilidades dentro de una clase, se buscó siempre encapsular responsabilidades
comunes dentro de cada clase. Al programar de esta manera, se cumple también con el
principio de acoplamiento, ya que al envolver funcionalidades de responsabilidades
relacionadas en una misma clase, se está desacoplando a los demás objetos que dependen de
él, de los objetos que utiliza la clase en cuestión.

También se tuvo en cuenta el principio de abierto-cerrado, el cual plantea que un sistema debe
quedar abierto a la extensión, pero cerrado a la modificación. Este principio asegura el
cumplimiento del requerimiento no funcional de modificabilidad, el cual determina que el
videojuego debe quedar abierto al agregado de distintos mini juegos, la inclusión de nuevas
palabras, la posibilidad de elegir entre nuevas categorías y niveles y la incorporación de
nuevas modalidades de juego, pero sin modificar lo ya existente.

129
 6.2.1. Estructura

Al momento de determinar cómo estarán estructurados los distintos elementos del videojuego,
se decidió que habrá un administrador de escenas, llamado SceneManager, el cuál conocerá
todas las escenas involucradas y será el responsable de las llamadas a las distintas escenas.
Además, habrá un administrador de recursos, llamado ResourcesManager, quien será el
responsable de todos los recursos comunes a las distintas escenas.

Para los datos externos se utiliza un administrador llamado DataManager. Este es el

responsable de leer toda la información necesaria para empezar el videojuego como es el
diccionario con todas las palabras y los distintos niveles para los mini juegos. Y también es
responsable a la hora de guardar los datos generados por el videojuego.

6.2.2. Acelerómetro

El acelerómetro es una innovadora herramienta que le permite identificar al dispositivo cual

es la posición del mismo con respecto al mundo. Tanto los teléfonos inteligentes como las
tablets poseen un acelerómetro de tres ejes que detecta la orientación del teléfono.

Figura 11. Ejes del acelerómetro.

Esta tecnología permite a las aplicaciones reaccionar frente al movimiento del dispositivo
proporcionando una atractiva entrada de información. Es así que decidimos incluirla para el
ingreso de información de movimiento en los dos mini juegos.
130
 6.2.3. Intercambio de información

Para el intercambio de información hacia y desde el exterior utilizamos XML. Esto se debe a
porque a cinco razones principales:

 Simplicidad, es fácil de entender. Se crean las etiquetas y en general un diseño del

documento.

 Organización, XML permite que se cree una plataforma segmentando el proceso de

diseño. Al inicio del archivo se codifica las reglas del documento y abajo se ingresan
los datos.

 Accesibilidad, con XML el trabajo se puede compartir. La separación de los datos

hace que sea accesible cuando se necesitan cambios.

 Estandarización, XML es un estándar internacional.

 Aplicaciones múltiples, se puede hacer una página de datos y usarla una y otra vez con
diferentes herramientas.

Para controlar la información y estructura de los documentos XML se utilizó DTD. Su

función básica es la descripción de la estructura de datos, para utilizar una estructura común y
mantener la consistencia entre todos los documentos que utilicen la misma DTD.

131
 6.2.4. Elección del Motor

El uso de un motor o engine para el desarrollo de video juegos consiste en el uso de librerías
ya probadas las cuales facilitan el acceso a funciones de bajo nivel. Esto permite al
programador enfocarse en tareas más concernientes al videojuego pudiendo de esta manera
lograr productos de mayor calidad.

A la hora de elegir un motor se buscó información sobre los disponibles en la modalidad

“Open Source” obteniendo una lista con varios motores diferentes. De esta lista se eligieron
dos, teniendo en cuenta la existencia de comentarios positivos de los usuarios y que haya
suficiente información para el aprendizaje de uso del motor. Estos fueron LibGDX y
AndEngine.

Posteriormente se crearon prototipos para asegurar la mejor opción entre estos dos motores.
Orientados por el tutor se definieron prototipos que cumplieran las siguientes evaluaciones:

 Carga masiva de imágenes y su impresión en pantalla, medir el tiempo de FPS.

 Calidad en la resolución de colisiones
 Calidad en la resolución de colisiones con transparencia.

El desarrollo y la evaluación de los mencionados prototipos arrojaron los siguientes

resultados:

Pruebas Motor libGDX Motor AndEngine

Performance en FPS Baja Configurable
Colisiones Resuelve satisfactoriamente Resuelve satisfactoriamente
Colisiones con transparencia Resuelve satisfactoriamente Resuelve satisfactoriamente
Figura 12. Evaluación de Motores

Finalmente elegimos AndEngine por las siguientes razones:

 Buena performance comprobada por los prototipos.

 Se encuentran mayor cantidad de ejemplos de los cuales aprender su funcionamiento.
132
 Existe un foro atendido donde evacuar dudas o consultas.
 Mejor documentación para aprender rápidamente el uso.

133
7. Referencias bibliográficas

Ferrara, D. “Why should you use XML – Five Basic Reasons.”. [Online]. Disponible:
http://webdesign.about.com/od/xml/a/why-you-should-use-xml.htm

Eclipse Juno. “Eclipse SDK 4.2”. [Online]. Disponible: http://www.eclipse.org/eclipse4/

Eclipse. “Eclipse Project Release Notes”. (2012, Jun 8). [Online]. Disponible:
http://www.eclipse.org/eclipse/development/readme_eclipse_4.2.php

134
Anexo 4 - Plan de proyecto

1. Objetivo del documento

Este documento será una herramienta de apoyo para mejorar la gestión del proyecto. En este
se registrará periódicamente la situación actual y la planificación futura del proyecto usando
los recursos que se tienen con el fin de llegar a la calidad del producto desarrollado requerida.

2. Alcance del documento

Este documento describe el objetivo del proyecto, los criterios de éxito, y los planes
necesarios para cumplir los mismos.

En el documento se encuentra información detallada sobre el cronograma del proyecto, se

describen las distintas etapas del mismo y los resultados obtenidos de cada una de estas.
También se realiza un análisis del esfuerzo dedicado al proyecto y a cada una de las etapas del
mismo, así como también un análisis y seguimiento de los riesgos identificados.

Por otro lado, este documento incluye las distintas actualizaciones que se consideraron
necesarias en las diferentes etapas del proyecto, debido a desviaciones u obstáculos
encontrados. Además, se expone información recolectada u obtenida durante el transcurso del
proyecto, como el esfuerzo real dedicado a las diferentes actividades planeadas. Es por esto,
que parte del documento está redactado en etapas finales del proyecto.

135
3. Glosario

ANDROID: es un sistema operativo basado en Linux diseñando principalmente para

dispositivos móviles con pantalla táctil como teléfonos inteligentes o tablets desarrollado por
Google.

GAMELAB: Laboratorio de Simulación y Juegos de la Universidad ORT.

GAMIFICATION: Gamificación se refiere al uso de atributos del juego para encauzar el

comportamiento lúdico, en ambientes no lúdicos con el fin de hacer las actividades más
atractivas, convincentes y conseguir un mayor compromiso de los participantes.

MOOC: Massive Open Online Course, es una modalidad de educación abierta, la cual se
observa en cursos de pre grado ofrecidos gratuitamente a través de plataformas educativas en
Internet (En particular se utilizó www.coursera.com).

PLAN CEIBAL: Programa para la Conectividad Educativa de Informática Básica para el

Aprendizaje en Línea, tendiente a promover la inclusión digital para un mayor y mejor acceso
a la educación y a la cultura. Con el Plan Ceibal cada alumno y cada maestro de las escuelas
públicas de todo el país reciben de forma gratuita una computadora portátil. Busca promover
la inclusión digital, con el fin de disminuir la brecha digital tanto respecto a otros países,
como entre los ciudadanos de Uruguay, de manera de posibilitar un mayor y mejor acceso a la
educación y a la cultura.

PYTHON: Es un lenguaje de programación multiparadigma, ya que soporta orientación a

objetos, programación imperativa y, en menor medida, programación funcional. Es
un lenguaje interpretado, usa tipado dinámico y es multiplataforma. La mayor parte del
software para las XO está escrito en Python porque su plataforma Sugar (basada en Linux
como sistema operativo) también es escrita en Python.

TABLET: es una computadora portátil de mayor tamaño que un teléfono inteligente

integrado en una pantalla táctil con la que se interactúa primariamente con los dedos, sin
necesidad de un teclado físico ni ratón.
136
4. Introducción

4.1. Descripción del proyecto

El proyecto surge con la idea de aplicar técnicas de enseñanza de la lectura a un videojuego.

Se trata de la construcción de un videojuego didáctico en 2D para dispositivos móviles. Para
la realización del mismo se aplicarán elementos de las metodologías globales de lectura, así
como también conceptos de Gamification.

Los juegos elaborados tendrán intervenciones basadas en metodologías globales de lectura,

las cuales parten del reconocimiento de unidades complejas con significado: palabras o frases,
para que luego en una etapa posterior se discriminen las unidades más simples que la
componen: sílabas o letras. Con el fin de obtener éxito en la intervención didáctica se
pretende que los juegos sean entretenidos y atractivos para el niño, de acuerdo al grado
curricular en que se encuentre.

Gamification es un área de investigación reciente que se ha expandido a múltiples contextos

con el fin de lograr la motivación de los participantes. Se aplicarán las técnicas de
Gamification para generar motivación de ingreso a la aplicación de forma asidua.

4.2. Objetivo del proyecto

El objetivo del proyecto es el de realizar un videojuego en dos dimensiones para dispositivos

móviles (tablets y/o teléfonos celulares), el cual favorezca el aprendizaje de la lectura de los
niños, dando apoyo al docente al impartir los contenidos curriculares del Programa de
Educación Inicial y Primaria, en el área de lengua, en la disciplina de lectura para cuatro y
cinco años, primer y segundo grado.

Otro objetivo del proyecto es aprender todo lo relacionado a programación de videojuegos en

dos dimensiones aplicados en dispositivos móviles.

137
También como objetivo nos planteamos poder aplicar técnicas de Gamification con el fin de
motivar a los jugadores que continúen jugando en los niveles siguientes.

Como último objetivo, se quiere aplicar conceptos de las metodologías globales de lectura
para elaborar intervenciones didácticas que favorezcan el aprendizaje de la lectura de los
niños que usen el juego.

4.3. Objetivo del producto

El primer objetivo es hacer un videojuego 2D para dispositivos móviles con sistema operativo
Android (en especial para Tablet), para niños de 3 a 7 años de edad con o sin problemas de
aprendizaje o discapacidad intelectual.

Otro objetivo es que la aplicación proporcione datos sobre la forma en que se usa el juego,
con el fin de realizar estadísticas usando dicha información.

4.4. Etapas del proyecto

Este proyecto será dividido en tres grandes etapas: preproducción, producción y liberación.

En la etapa de preproducción, se hará una investigación sobre las diferentes herramientas de

desarrollo y se obtendrán los requerimientos con el cliente. Como parte de esta investigación,
se realizarán varios prototipos que atacarán funcionalidades particulares, de modo de definir
el alcance del producto con más detalle y con la seguridad de que todo sea posible de realizar.

Además, se elaborará el Game Design Document (GDD) en el que se especificarán los

requerimientos funcionales del videojuego, el Technical Design Document (TDD) y los
planes necesarios para la ejecución del proyecto.

Una vez establecidos los requerimientos se pasará a la etapa de producción. En esta se

procurará la obtención de la mayoría de los recursos gráficos, de sonido y la construcción del
videojuego. La construcción del videojuego, se realizará en base a iteraciones como se
describe más adelante.
138
Por último, se pasará a la etapa de liberación. En esta etapa, se realizarán pruebas del producto
en instituciones educativas, se solucionarán los errores que el juego pueda contener y se irán
sustituyendo los nuevos modelos gráficos a medida que sean obtenidos.

También, se realizarán las actividades de cierre del proyecto, como por ejemplo, la
documentación, el análisis de los datos obtenidos en las pruebas y el registro de errores
encontrados.

139
5. Alcance

5.1. Alcance del juego

El producto principal del proyecto es el videojuego didáctico. Para definir la idea fuerza del
mismo se elaborará el documento Game Concept. En éste documento se presentarán las
características principales del juego, los objetivos que se plantea, el soporte tecnológico que
usará con el fin de realizar un primer acercamiento al juego. Por otra parte se elaborará el
documento llamado Game Design Document en el cual se especifican los requerimientos
funcionales, recursos y los elementos necesarios para la construcción del videojuego.

5.2. Interesados

El cliente principal del proyecto es Rosario Castro, maestra jubilada de ANEP, actualmente
trabaja en CEI (Centro de Educación Individualizada), asociación civil autorizada por el
Consejo de Educación Primaria como Colegio Especial Nº 8. En su labor docente utiliza
videojuegos y aplicaciones educativas como herramientas de uso didáctico. Rosario realizará
aportes para mejorar el producto principalmente desde el punto de vista didáctico.

5.3. Criterios de éxito del proyecto

Como se plantea en el objetivo principal, el fin del proyecto es realizar un videojuego con las
características mencionadas anteriormente, para favorecer el aprendizaje de la lectura de los
niños. Daremos como exitoso el proyecto si se cumplen los requerimientos obligatorios para
la realización del videojuego. Estos requerimientos se especifican en el GDD. Ver anexo 2.

5.4. Criterios de éxito del producto

Los criterios de éxito del producto están directamente relacionados con las métricas de calidad
del mismo definidas en el Plan de Calidad y con la satisfacción del cliente.

140
Éstas métricas serán definidas para controlar distintos aspectos del juego. Los aspectos que
equipo decidió medir y controlar son: el avance logrado del producto, tiempo de carga y
cantidad de fallas para el producto. Para ver estas métricas véase el Anexo 5 Plan de Calidad.
Para cada una de estas métricas se definirán valores mínimos que el producto debe alcanzar
para considerarlo exitoso.

141
6. Calendario

6.1. Ciclo de vida

Para la realización de este proyecto se utilizará un ciclo de vida iterativo-incremental debido

a que en el desarrollo de un videojuego, se definen al principio los requerimientos con un
diseño de alto nivel del mismo y luego se avanza mediante incrementos hasta llegar a la
versión final.

Como se mencionó en anteriormente, el proyecto consta de tres grandes etapas:

preproducción, producción y liberación.

Figura1. Macroproceso del proyecto.

6.1.1. Preproducción

El proceso de preproducción se compondrá de otros subprocesos: investigación, definición de

requerimientos, elaboración de prototipos de ensayo y diseño de alto nivel del sistema.

142
 Figura 2. Subproceso preproducción.

El subproceso de investigación se desarrollará durante toda la etapa de preproducción. Se

abarcarán los temas: plataforma para desarrollar el videojuego, estándares a aplicar,
herramientas a utilizar y técnicas de Gamification. Se cursará la materia electiva
Programación de Videojuegos para profundizar el conocimiento sobre desarrollo de
videojuegos.

Paralelamente, se trabaja realizando prototipos con el fin de probar las herramientas de

desarrollo investigadas, se buscará poner en práctica las diferentes opciones resultantes. Se
construirán prototipos para determinar el costo beneficio de cada tecnología o herramienta
analizada, para luego seleccionar la más adecuada para las necesidades. Se usarán recursos
gráficos provisorios pero se comenzará el trabajo con el diseñador.

La definición de requerimientos comenzará desde el inicio de la etapa de preproducción, para

ello se creó un blog con el fin de facilitar la comunicación con las maestras. A partir de esta
definición se creará el documento: Game Design Document (GDD) donde se especificaron los
requerimientos funcionales del juego.

Luego de completar la definición de requerimientos se pasará al diseño de alto nivel del

sistema. Este proceso tendrá como entrada los requerimientos especificados en el proceso
anterior y su resultado será una primera versión del TDD. La culminación del TDD se
realizará en la etapa de producción.

6.1.2. Producción

Esta etapa se compone de 3 iteraciones sobre las actividades de diseño detallado, desarrollo y
pruebas, como se muestra en el siguiente diagrama:

143
 Figura 3. Subproceso de producción.

En la primera iteración, se realizará un prototipo que comprenda la estructura de navegación

principal y todas las escenas referidas a la intervención didáctica. No se incluirán los juegos
aún. Es importante validar rápidamente este prototipo, ya que la intervención didáctica es
fundamental para el videojuego.

En la segunda iteración, se realizarán las modificaciones que el cliente haya solicitado.

Además se integrarán al videojuego los juegos de laberinto y naves.

En la tercera iteración, además de hacer las correcciones que el cliente haya solicitado, se
incluirá el desarrollo de los requerimientos referidos a Gamification y el tercer juego diseñado
específicamente para usar en el salón de clase.

Esta última versión será la que se usará para realizar las pruebas en la etapa de liberación.

6.1.3. Liberación

En la etapa de liberación, se realizarán las actividades de testing con pruebas de sistema y

pruebas de campo. Se realizarán actividades de corrección a partir de los errores encontrados
y de las oportunidades de mejora observadas. En las pruebas de aceptación se relevarán

144
mejoras solicitadas por el cliente. Paralelamente se desarrollaran actividades del cierre del
proyecto como la documentación y análisis de datos de la investigación educativa.

Figura 4. Subproceso de liberación.

Las pruebas de sistema, las realizará el equipo con las tablet adquiridas para este propósito.
Las pruebas de campo, se realizarán en instituciones educativas con niños pertenecientes al
público objetivo. Se usarán las tablet del equipo y si fuera posible otras proporcionadas por la
institución educativa.

145
 6.2. Cronograma

La etapa de preproducción comenzará el lunes 20 de mayo y finalizará el viernes 14 de junio.

Luego, se comenzará con la producción el lunes 17 de junio finalizando el viernes 23 de
agosto. Por último, la liberación se realizará entre el lunes 26 de agosto y el jueves 12 de
setiembre del año 2013.

En la etapa de preproducción, las actividades se agruparán en ciclos de dos semanas de

duración. Al finalizar cada ciclo, se compartirán las tareas realizadas y se analizarán los
resultados obtenidos. Luego, se planificarán las actividades para el próximo ciclo.
Como ya se mencionó, en la etapa de la producción se iterará 3 veces. Las dos primeras
iteraciones tendrán una duración de cuatro semanas y la última será de dos semanas.

Figura 5. Cronograma.

6.2.1. Ajustes al cronograma

Al finalizar la etapa de preproducción, se decidió prolongar esta etapa debido a que no se

cumplieron los cometidos para la misma. Dificultades en la investigación del motor para
desarrollar el videojuego ocasionaron este retraso.

146
 Figura 6. Cronograma ajustado.

6.2.2. Cronograma de recursos gráficos

Los recursos gráficos tienen un rol de importancia en el videojuego ya que el atractivo del
juego se verá influenciado por los mismos. Para ello se buscó un diseñador que pudiera
colaborar con el proyecto en forma profesional aportando los conceptos del área de diseño
gráfico.

El diseñador trabaja en forma voluntaria, es decir que no se ha realizado un contrato de

trabajo, por este motivo las entregas pueden demorarse. En este caso se trabajará con gráficos
provisorios que luego serán sustituidos por los gráficos definitivos.

6.2.3. Cronograma de recursos de sonido

Los sonidos del juego al igual que los gráficos también tienen cumplen un rol importante
dentro del proyecto. Serán diseñados y obtenidos por parte del equipo y serán incluidos en el
mismo a medida que sean necesarios. Para elevar la calidad de los recursos de sonido que se
usarán en el videojuego se asistió al taller: “Audio para videojuegos”.

147
 6.3. Entregables por fase

Cada una de las fases del proyecto tendrá sus entregables. A continuación se enumeran los
entregables por fase.

6.3.1. Entregables de preproducción

 Game Concept

 GDD

 TDD

 Plan de proyecto

 Plan de Calidad

 Prototipos

148
 6.3.2. Entregables de producción

Para cada ciclo de las etapas de producción se genera un prototipo que irá incrementando las
funcionalidades implementadas.

 Primer ciclo: Prototipo con la navegación entre las diferentes escenas incluyendo la
intervención didáctica.

 Segundo ciclo: Prototipo con juegos de naves y castillo.

 Tercer ciclo: Prototipo con funciones de Gamification y tercer juego.

6.3.3. Entregables de liberación

 Versión final del juego con las correcciones relevadas en las pruebas.

 Listado de errores conocidos.

 Reportes de métricas determinadas por el plan de calidad.

149
7. Esfuerzo

Para la realización del proyecto, se decidió medir el esfuerzo en base a las horas de trabajo
realizadas. Se creó un calendario semanal con el fin de fijar días de trabajo para el proyecto,
vimos que la disponibilidad en horas es de 25 horas por cada integrante.

El registro de horas trabajadas se realizará utilizando una planilla de cálculo de Google Docs a
la cual denominamos “Hoja de Ruta”. Se registran datos de: Nº de semana, fecha de la tarea,
título, descripción, categoría, etapa, cantidad de horas realizadas e integrantes que participan.
Ésta planilla se configuró para que en forma automática se obtenga un reporte del registro de
esfuerzo discriminado por categorías. Al finalizar cada etapa, se tomarán mediciones de la
cantidad de horas realizadas por tipo de tarea.

En otra planilla de cálculo de Google Docs a la cual denominamos “Pendientes” se llevará el

registro de tareas incluyendo la estimación y horas dedicadas a cada tarea.
Se estableció una agenda quincenal que incluye varias tareas de rutina, con la finalidad de
gestionar el esfuerzo dedicado a las tareas del proyecto:

Lunes 1: Planificación de las tareas para el ciclo de trabajo.

Martes 1: Revisión de cronograma junto con los tutores.

Miércoles 1: Investigación o revisión de documentos.

Jueves 1: Investigación, desarrollo y/o documentación.

Viernes 1: Libre o desarrollo

Sábado 1: Reunión de equipo, investigación, desarrollo y/o documentación.

Domingo 1: Documentación. Respaldos

Lunes 2: Actualización del pizarrón Kanban.

150
Martes 2: Revisión de cronograma junto con los tutores.

Miércoles 2: Investigación o revisión de documentos.

Jueves 2: Investigación, desarrollo y/o documentación. Análisis de riesgos.

Viernes 2: Libre o desarrollo.

Sábado 2: Reunión de equipo, investigación, desarrollo y/o documentación.

Domingo 2: Documentación. Respaldos.

Observaciones: Los miércoles el equipo estuvo abocado a cursos de videojuegos y de sonidos

para videojuegos durante un período considerable del proyecto. Más allá de que el ciclo es
quincenal hay actividades que se repiten, fundamentalmente las de investigación, desarrollo y
documentación.

Planificación de las tareas para el ciclo de trabajo: se elabora un listado de tareas a realizar
teniendo en cuenta los requerimientos pendientes. Se estiman las tareas y se priorizan. Se
seleccionan las tareas que se realizarán en el próximo ciclo.

Revisión de cronograma junto con los tutores: se analizan los aciertos en la estimación
anterior y se revisa la adecuación en la estimación realizada. Se revisa la priorización de las
tareas.

Investigación, desarrollo y/o documentación: de acuerdo a la priorización anterior es el tipo

de tipo de tareas a realizar.

Análisis de riesgos: se realiza en forma mensual el segundo jueves del mes.

151
Respaldos: incluyen una copia del proyecto hacia una carpeta externa para facilitar la
recuperación. También se utiliza herramientas que permitan la automatización de esta tarea,
como por ejemplo Dropbox, Assembla y Google Drive.

152
8. Análisis primario de riesgos

El objetivo en esta área es asegurar que la gestión de riesgos se realiza de forma correcta. Para
ello se realizarán actividades de Identificación de riesgos, definición de estrategias de
Mitigación y Contingencia para los riesgos encontrados. En forma mensual, se realizará un
análisis de los riesgos para evaluar los cambios ocurridos y, si es necesario, tomar alguna
acción correctiva. Ésta evaluación de riesgos en el proyecto se realizará a mediados de cada
mes en las siguientes fechas:

 Lunes, 15 de abril de 2013

 Jueves, 16 de mayo de 2013

 Jueves, 20 de junio de 2013

 Jueves, 18 de julio de 2013

 Jueves, 15 de agosto de 2013

Realizar la evaluación de riesgos en forma correcta implica evaluar los riesgos en todas las
áreas del proyecto y por personas diferentes. La evaluación de riesgos debe hacerse primero
en forma individual y luego se analizan los riesgos detectados para determinar el impacto de
cada riesgo, con todos los integrantes del equipo de trabajo. Los riesgos deben ser priorizados
otra vez en cada evaluación. Debe planificarse la eliminación, mitigación y/o contingencia si
el impacto es alto.

8.1. Identificación de riesgos

Definimos el riesgo como un evento o condición incierta que si se produce tiene un efecto
positivo o negativo en el proyecto. El análisis y administración de los riesgos en forma
sistemática planificando la contingencia y/o mitigación de los efectos negativos, contribuirá
en el aumento de la probabilidad de lograr los objetivos del proyecto. Para realizar la
identificación de los riesgos se tienen en cuenta tanto factores internos como externos.
153
 8.1.1. Descripción de los riesgos encontrados

1. No tener disponible el hardware para correr la aplicación

El proyecto surge a partir de la inquietud de brindar herramientas que ayuden a los niños en el
aprendizaje de la lectura. En Uruguay se implementó el Plan Ceibal que tiene como
beneficiarios a la mayoría de los niños del país. Este proyecto se basa en entregar una
computadora a cada niño en edad escolar de las escuelas públicas. Partiendo de esta realidad,
nuestro proyecto se pensaba implementar utilizando las computadoras entregadas (XO).

Durante la definición del proyecto acontecieron cambios en el Plan Ceibal, entre los cuales se
lanzará un plan piloto que pretende entregar 10.000 tablets a niños de 4 y 5 años de educación
inicial, y primer y segundo grado de escuela primaria. Estas edades son perfectas para aplicar
el método global de lectura. Suponiendo que el plan piloto tenga éxito y abarcando los niños
destinatarios del plan, es que decidimos realizar el proyecto para tablets con sistema operativo
Android.

El riesgo de no encontrar hardware disponible al inicio del proyecto es elevado, pero

confiamos poder conseguir suficientes tablets para realizar con éxito todo el proyecto.

2. Retrasos en el cronograma debido a una mala elección del Lenguaje de

Programación (Motor del juego)

Las XO utilizan Sugar como plataforma, a la cual Python se adecua perfectamente. Por esta
razón comenzamos programando en el lenguaje Python intentando que el lenguaje de
programación no sea un obstáculo para el proyecto.

Al haber elegido tablets para trabajar y teniendo en cuenta que existe una probabilidad muy
alta de utilizar Android como sistema operativo en el Plan Ceibal, es que cambiamos y
decidimos utilizar esta plataforma para desarrollar el proyecto.

154
Para desarrollar videojuegos se necesita utilizar motores que sean eficientes a la hora de
utilizar el hardware disponible, sobre todo en el caso de las tablets por tener disponibilidad
limitada de recursos.

Debido a nuestra experiencia en Java nos encontramos confiados en poder resolver el

proyecto utilizando Android (basado en Java) y AndEngine como motor de videojuegos. De
todas formas, al no tener mucha experiencia en videojuegos el riesgo al inicio del proyecto es
elevado. Por otra parte en Python no teníamos experiencia previa.

3. Retrasos en el proyecto debido a mala estimación.

Al comenzar programando en Python y no contar con experiencia en este lenguaje, realizamos

varios prototipos. Éstos nos proporcionarían información para realizar una estimación más
adecuada del tiempo que requiere la realizar un videojuego.

Al cambiar de plataforma, nuestra experiencia en Java nos permite poder pronosticar mejor
los tiempos requeridos para programar. Igualmente realizamos prototipos y evaluamos la
estimación en forma constante con el fin de disminuir el riesgo de fallar en la estimación.

4. Mala comunicación entre los actores del proyecto

Los actores que participan en la definición del proyecto son: el cliente y las maestras que
aportan desde su conocimiento y experiencia, los tutores, el diseñador y nosotros que lo
llevaremos a cabo.

La cantidad de personas involucradas en el proyecto no es menor, además encontramos que la

disponibilidad horaria de todos los participantes es limitada. Este motivo podría llevar a un
desencuentro o malentendido en la comunicación. Por este motivo es que vamos a utilizar
todos los medios tecnológicos disponibles para minimizar este riesgo.

155
5. Retrasos en el cronograma por la búsqueda y utilización de gráficos.

Para tener éxito en el proyecto, es de fundamental importancia contar con gráficos de calidad
adecuados a las necesidades del proyecto. Debido a la trascendencia de este factor es que
solicitamos el apoyo de expertos en el área. Es así que se integra al proyecto un estudiante
avanzado de la carrera de Diseño Gráfico de la Universidad ORT Uruguay. Su aporte con
gráficos elaborados por su cuenta, será en forma voluntaria.

Dado que no existe ningún compromiso laboral con el diseñador y a su vez él debe dedicar
tiempo a sus estudios, el riesgo de no contar con los recursos gráficos al inicio del proyecto es
alto.

6. Retrasos en el cronograma por la búsqueda y utilización de sonidos

De manera similar a los gráficos, los recursos de sonido adecuados al proyecto forman parte
del atractivo del juego, lo cual redundará en el éxito del proyecto.

Los recursos de sonido se pueden dividir en dos grandes grupos: los sonidos de las palabras o
frases y los sonidos de ambiente o de fondo. Para cubrir esta necesidad del primer grupo se
prevé grabar los mismos con voces de niños. Para el segundo grupo se buscará la ayuda de
personas que ya tienen vasta experiencia en videojuegos o se bajaran recursos gratuitos de
internet.

Estas dos fuentes de recursos no son dependientes de nosotros quienes estamos elaborando el
proyecto, por lo cual el riesgo de no contar con los recursos de sonido al inicio del proyecto es
alto.

7. No cumplir con los requerimientos por dificultades en la obtención de datos

estadísticos

Entre los requerimientos (deseables) del proyecto se propuso la obtención de información que
puede generase a medida que los jugadores participan, por ejemplo: datos personales de los

156
participantes, pantallas a las que ingresa, tiempo que permanece en cada pantalla, palabras
que logra reconocer, etc.

Para realizar la obtención de los datos mencionados se usarán los recursos tecnológicos
disponibles a tales efectos, ellos son: “Shared Preferences” para datos simples y documentos
XML para datos complejos.

Dado que no se tiene experiencia en la implementación de este tipo de funciones, puede haber
problemas en la generación de los datos debido al desconocimiento de cómo implementar el
requerimiento. A su vez existe el riesgo de que los datos que nos proponemos relevar no sean
los adecuados.

8. Cambios en los requerimientos por insatisfacción del cliente (maestros)

Si bien la idea del proyecto surge por parte de nosotros quienes elaboramos el proyecto, se
consideró muy oportuno contar con la presencia de un cliente, a quien le interesara el
producto a elaborar y, quien nos pudiera asesorar durante la construcción del mismo para
realizar mejoras. Es así que nos contactamos con el cliente y otras maestras que brindarán
apoyo y asesoramiento desde el punto de vista didáctico.

Se prevé realizar reuniones periódicas con las docentes a medida que se realizan avances,
tanto en el diseño del juego como en la implementación del mismo. Teniendo en cuenta que
pueden surgir cambios en ambas etapas, se realizará una implementación de la solución
abierta al cambio. De todas formas existe el riesgo de que el cliente solicite cambios que
impacten en forma grave en etapas avanzadas del proyecto, teniendo como consecuencia una
productividad baja debido al retrabajo.

9. Los juegos resulten poco atractivos para los niños

El objetivo principal del proyecto es ayudar a los niños en su proceso de aprendizaje de la

lectura, para cumplir con el mismo es necesario que ingresen asiduamente a la aplicación de
juegos para interactuar con la propuesta didáctica que se ofrece junto a los juegos. Si los

157
juegos carecen de interés para los niños del entorno etario previsto, no habrá posibilidades de
que se realice la interacción antes mencionada.
Para mitigar este riesgo, se cuenta con el apoyo del tutor quien está a cargo del gamelab de la
Universidad ORT Uruguay y en base a su experiencia en videojuegos nos guiará en el proceso
de construcción de la aplicación.

Un hecho que aumenta el impacto de este riesgo es la duración del proyecto, la cual es de 6
meses. La cantidad de iteraciones que este tiempo permite realizar es limitada. Esto nos obliga
a trabajar con prototipos de la aplicación desde etapas tempranas del proyecto, con el fin de
realizar las correcciones necesarias a tiempo.

10. Aplicación incorrecta de conceptos de Gamification

Como se mencionó en el riesgo anterior, es de fundamental importancia el ingreso en forma

asidua de los niños a la aplicación. Por este motivo, se buscó apoyo en Gamification, un área
de conocimiento nueva que se viene implementando en diversos contextos. Ésta área tiene
como objetivo principal la aplicación de elementos lúdicos para generar motivación en los
participantes en el contexto donde se aplique.

Se realizará una vasta investigación sobre el tema, realizando cursos on-line y analizando
ejemplos de aplicación de las técnicas que ofrece Gamification. Sin embargo no se ha ejercido
anteriormente la aplicación de estas técnicas, por lo cual existe riesgo de no aplicarlas en
forma correcta.

158
 8.1.2. Estrategias aplicadas a los riesgos encontrados

8.1.2.1. Disparador

Antes de definir las estrategias que se aplicarán a los riesgos, fue necesario definir un
disparador para cada riesgo, el cual va a funcionar como alarma para aplicar las estrategias de
mitigación y de contingencia. A continuación se muestra el disparador definido para cada
riesgo.

Id Riesgo Disparador
1 Retrasos en el proyecto debido a No cumplir con los hitos del cronograma
mala estimación (Documentación, Prototipos).
2 Retrasos en el cronograma debido a Retrasos en los prototipos por inexperiencia
una mala elección del Lenguaje de en el lenguaje.
Programación (Motor del juego)
3 Retrasos en el cronograma por la No se encuentran los sonidos adecuados a la
búsqueda y utilización de sonidos aplicación.
4 No tener disponible el hardware para No disponer de una cantidad mínima de
correr la aplicación hardware para correr los prototipos con los
niños.
5 Los juegos resulten poco atractivos Malos resultados en pruebas durante la
para los niños evaluación de los prototipos.
6 Retrasos en el cronograma por la No se encuentran los gráficos adecuados a la
búsqueda y utilización de gráficos aplicación.
7 Cambios en los requerimientos por Malos resultados en pruebas durante la
insatisfacción del cliente (maestros) evaluación de los prototipos.
8 No cumplir con los requerimientos No se obtienen los datos necesarios que
por dificultades en la obtención de permiten medir la aplicación.
datos estadísticos
9 Mala comunicación entre los actores Retrasos en las reuniones o pruebas de
del proyecto prototipos.

159
 Id Riesgo Disparador
10 Aplicación incorrecta de conceptos Utilizar Gamification no motiva a los niños
de Gamification durante las pruebas de prototipos.
Figura 7. Definición de disparadores para aplicar estrategias para los riesgos

8.1.2.2. Estrategias de mitigación

En la tabla que se muestra a continuación se definen las estrategias de mitigación y servirán

para disminuir la probabilidad de que el riesgo suceda.

Id Riesgo Mitigación
1 Retrasos en el proyecto debido a Revisiones periódicas del cronograma.
mala estimación Armado de Iteraciones de dos semanas.
2 Retrasos en el cronograma debido a Prototipos funcionales e investigación de los
una mala elección del Lenguaje de distintos motores
Programación (Motor del juego)
3 Retrasos en el cronograma por la Comenzar con la búsqueda de sonidos al
búsqueda y utilización de sonidos mismo tiempo que el desarrollo de los
prototipos
4 No tener disponible el hardware para Adquirir equipos prestados, investigar sobre
correr la aplicación emuladores para PC
5 Los juegos resulten poco atractivos Programar pruebas de satisfacción para los
para los niños niños
6 Retrasos en el cronograma por la Comenzar con la búsqueda de gráficos al
búsqueda y utilización de gráficos mismo tiempo que el desarrollo de los
prototipos
7 Cambios en los requerimientos por Programar reuniones de satisfacción para las
insatisfacción del cliente (maestros) maestras
8 No cumplir con los requerimientos Prototipos de análisis de datos y evaluación
por dificultades en la obtención de de resultados.
datos estadísticos

160
 Id Riesgo Mitigación
9 Mala comunicación entre los actores Crear comunicación por web, preparar las
del proyecto reuniones para que sean más efectivas
10 Aplicación incorrecta de conceptos Proponer más herramientas de Gamification,
de Gamification o excluir las que no sean adecuadas.
Figura 8. Estrategias de mitigación de riesgos

8.1.2.3. Estrategias de contingencia

A continuación se muestran las estrategias de contingencia que se aplicarán en caso de que el

riesgo suceda.

Id Riesgo Contingencia
1 Retrasos en el proyecto debido a Reestimar y negociar el alcance del proyecto.
mala estimación
2 Retrasos en el cronograma debido a Consultar expertos
una mala elección del Lenguaje de
Programación (Motor del juego)
3 Retrasos en el cronograma por la Utilizar los sonidos mínimos necesarios.
búsqueda y utilización de sonidos
4 No tener disponible el hardware para Utilizar emuladores para PC.
correr la aplicación
5 Los juegos resulten poco atractivos Revaluar los juegos, evaluar dificultad vs
para los niños motivación, búsqueda de imágenes y sonidos.
6 Retrasos en el cronograma por la Utilizar gráficos alternativos para sustituir
búsqueda y utilización de gráficos luego.
7 Cambios en los requerimientos por Re-priorizar los requerimientos, y llegar a un
insatisfacción del cliente (maestros) acuerdo con el cliente.
8 No cumplir con los requerimientos Revaluar los indicadores, o utilizar pruebas
por dificultades en la obtención de de satisfacción para obtener el indicador en
datos estadísticos base a la opinión de la maestra.

161
 Id Riesgo Contingencia
9 Mala comunicación entre los actores Establecer reuniones individuales, organizar
del proyecto pruebas en otros institutos.
10 Aplicación incorrecta de conceptos No utilizar Gamification.
de Gamification
Figura 9. Estrategias de contingencia de riesgos

8.2. Seguimiento de los riesgos

El equipo de proyecto acordó realizar un análisis sistemático de los riesgos, de esta forma
podremos saber si es necesario aplicar alguna de las estrategias elaboradas. Para cada análisis
se realiza una descripción en forma breve del contexto, con el fin de comprender y valorar los
cambios en cada riesgo. A continuación se muestra las evaluaciones mensuales que se
hicieron destacando en color cuando hubo variaciones en la probabilidad de ocurrencia.

162
 8.2.1. Evaluación abril/2013

Contexto: Se comienza a programar para XO en Python por ser este el lenguaje que mejor se
adapta a la plataforma. Se comienza con un curso sobre Gamification. Se inicia la
comunicación con todos los interesados. Se obtienen XO para realizar pruebas.

Riesgo Probabilidad Impacto Magnitud

Retrasos en el proyecto debido a mala estimación 0,8 5 4
Retrasos en el cronograma debido a una mala 0,9 4 3,6
elección del Lenguaje de Programación (Motor del
juego)
Retrasos en el cronograma por la búsqueda y 0,9 4 3,6
utilización de sonidos
No tener disponible el hardware para correr la 0,7 5 3,5
aplicación
Los juegos resulten poco atractivos para los niños 0,7 5 3,5
Retrasos en el cronograma por la búsqueda y 0,8 4 3,2
utilización de gráficos
Cambios en los requerimientos por insatisfacción del 0,6 5 3
cliente (maestros)
No cumplir con los requerimientos por dificultades 0,6 5 3
en la obtención de datos estadísticos
Mala comunicación entre los actores del proyecto 0,6 4 2,4
Aplicación incorrecta de conceptos de Gamification 0,6 3 1,8
Figura 10. Lista de Riesgos. Versión 1. Fecha: lunes, 15 de abril de 2013

163
 8.2.2. Evaluación mayo/2013

Contexto: Se cambió de plataforma de Python para XO a Android en dispositivos móviles.

Como consecuencia se cambió el lenguaje de programación de Python a Android (basado en
Java). Al pasarnos a Android, nos permite utilizar nuestra experiencia en java.

Para mejorar la comunicación con los interesados se inició el Blog donde se publicaran las
decisiones importantes referidas al video juego. Con esto también se pretende recibir
comentarios y sugerencias. Se estableció contacto con el diseñador para generar los gráficos
necesarios.

Id Riesgo Probabilidad Impacto Magnitud

1 Retrasos en el proyecto debido a mala 0,8 5 4
estimación
4 No tener disponible el hardware para correr 0,8 5 4
la aplicación
3 Retrasos en el cronograma por la búsqueda y 0,9 4 3,6
utilización de sonidos
5 Los juegos resulten poco atractivos para los 0,7 5 3,5
niños
2 Retrasos en el cronograma debido a una mala 0,8 4 3,2
elección del Lenguaje de Programación
(Motor del juego)
8 No cumplir con los requerimientos por 0,6 5 3
dificultades en la obtención de datos
estadísticos
6 Retrasos en el cronograma por la búsqueda y 0,7 4 2,8
utilización de gráficos
7 Cambios en los requerimientos por 0,5 5 2,5
insatisfacción del cliente (maestros)
9 Mala comunicación entre los actores del 0,5 4 2
proyecto

164
 Id Riesgo Probabilidad Impacto Magnitud
10 Aplicación incorrecta de conceptos de 0,6 3 1,8
Gamification
Figura 11. Lista de Riesgos. Versión 2. Fecha: jueves, 16 de mayo de 2013

Explicación de los cambios:

Riesgo Nº4: Al desarrollar el proyecto para Tablet aumenta la probabilidad de ocurrencia por
no disponer de este dispositivo aún.

Riesgo Nº2: Con el cambio de plataforma se disminuyó la probabilidad de ocurrencia ya que

se tiene más experiencia en Java.

Riesgo Nº6: Al contactar a un diseñador se disminuye la probabilidad de ocurrencia de

retrasarnos debido al conocimiento de gráficos de esta persona.

Riesgo Nº7: Se realizaron reuniones con el cliente donde el mismo formuló la satisfacción
sobre la idea del producto.

Riesgo Nº9: El establecimiento de una nueva forma de comunicación permite tener un

diálogo más efectivo con el cliente.

165
 8.2.3. Evaluación junio/2013

Contexto: Se analizan motores para ser utilizados. Se avanzó en diseño del videojuego
definiendo Story board. Se eligieron todas las palabras a utilizar definiendo categorías y
niveles por medio del blog y reuniones presenciales. Se adquirieron tablets. Se aprobaron
algunos gráficos. Finalizamos un curso MOOC (Massive Online Open Course) sobre
Gamification.

Id Riesgo Probabilidad Impacto Magnitud

1 Retrasos en el proyecto debido a mala 0,8 5 4
estimación
3 Retrasos en el cronograma por la búsqueda y 0,9 4 3,6
utilización de sonidos
4 No tener disponible el hardware para correr 0,7 5 3,5
la aplicación
5 Los juegos resulten poco atractivos para los 0,7 5 3,5
niños
8 No cumplir con los requerimientos por 0,6 5 3
dificultades en la obtención de datos
estadísticos
7 Cambios en los requerimientos por 0,5 5 2,5
insatisfacción del cliente (maestros)
2 Retrasos en el cronograma debido a una mala 0,6 4 2,4
elección del Lenguaje de Programación
(Motor del juego)
6 Retrasos en el cronograma por la búsqueda y 0,5 4 2
utilización de gráficos
9 Mala comunicación entre los actores del 0,5 4 2
proyecto
10 Aplicación incorrecta de conceptos de 0,3 3 0,9
Gamification
Figura 12. Lista de Riesgos. Versión 4. Fecha: jueves, 20 de junio de 2013
Explicación de los cambios:
166
Riesgo Nº4: Se adquirieron tablets lo que permite disminuir la probabilidad de este riesgo.

Riesgo Nº2: Se evaluaron varios motores y esto permitió lograr una buena aceptación del
motor elegido. Se pudieron realizar algunas pruebas de concepto.

Riesgo Nº6: Se aprobaron algunos gráficos permitiendo definir el estilo del videojuego.

Riesgo Nº10: Se tiene un mayor conocimiento sobre Gamification.

167
 8.2.4. Evaluación julio/2013

Contexto: Se realizaron los primeros prototipos utilizando AndEngine como motor de

videojuego. Se aprobaron los gráficos del primer nivel para todas las categorías. Se
encontraron dificultades para programar con AndEngine lo que retrasó la etapa de
preproducción. Se comenzó a grabar las palabras que se utilizarán. Se consiguieron dos
tablets más. Se investigó sobre metodologías de evaluación con respecto al videojuego y se
plantea hacer un estudio sobre: "Evaluación de resultados del uso de un videojuego con
intervenciones didácticas en diferentes poblaciones educativas utilizando metodología
cuantitativa".

Id Riesgo Probabilidad Impacto Magnitud

1 Retrasos en el proyecto debido a mala 0,8 5 4
estimación
5 Los juegos resulten poco atractivos para los 0,7 5 3,5
niños
7 Cambios en los requerimientos por 0,7 5 3,5
insatisfacción del cliente (maestros)
8 No cumplir con los requerimientos por 0,6 5 3
dificultades en la obtención de datos
estadísticos
3 Retrasos en el cronograma por la búsqueda y 0,7 4 2,8
utilización de sonidos
4 No tener disponible el hardware para correr 0,5 5 2,5
la aplicación
2 Retrasos en el cronograma debido a una mala 0,6 4 2,4
elección del Lenguaje de Programación
(Motor del juego)
6 Retrasos en el cronograma por la búsqueda y 0,5 4 2
utilización de gráficos
9 Mala comunicación entre los actores del 0,5 4 2
proyecto

168
Id Riesgo Probabilidad Impacto Magnitud
10 Aplicación incorrecta de conceptos de 0,3 3 0,9
Gamification
Figura 13. Lista de Riesgos. Versión 4. Fecha: jueves, 18 de julio de 2013

Explicación de los cambios:

Riesgo Nº3: Se inician las primeras grabaciones de sonidos.

Riesgo Nº4: Se consiguieron 2 tablets más.

Riesgo Nº7: Aumentó debido a las pocas reuniones con el cliente ya que se estaba evaluando
el motor con prototipos.

Riesgo Nº1: Al realizar los primeros prototipos hechos con AndEngine la estimación no fue
buena. Esto lleva a mantener alta la probabilidad de ocurrencia en este riesgo. Se realizará una
reunión con el cliente para reestimar y negociar el alcance del proyecto.

169
 8.2.5. Evaluación agosto/2013

Contexto: Se terminaron de implementar los juegos. Se realizaron las pruebas de sistema

realizando correcciones al prototipo implementado. Se obtuvieron gráficos para el menú,
faltan los gráficos para las palabras de los niveles 2, 3 y 4. Se realizaron reuniones con las
docentes para presentar el prototipo y coordinar las jornadas de trabajo para realizar pruebas
de campo. Se asistió al taller "Audio para videojuegos" pudiendo preparar todos los sonidos
necesarios para el videojuego.

Id Riesgo Probabilidad Impacto Magnitud

5 Los juegos resulten poco atractivos para los 0,7 5 3,5
niños
1 Retrasos en el proyecto debido a mala 0,6 5 3
estimación
8 No cumplir con los requerimientos por 0,6 5 3
dificultades en la obtención de datos
estadísticos
6 Retrasos en el cronograma por la búsqueda y 0,7 4 2,8
utilización de gráficos
4 No tener disponible el hardware para correr la 0,5 5 2,5
aplicación
7 Cambios en los requerimientos por 0,4 5 2
insatisfacción del cliente (maestros)
3 Retrasos en el cronograma por la búsqueda y 0,3 4 1,2
utilización de sonidos
2 Retrasos en el cronograma debido a una mala 0,3 4 1,2
elección del Lenguaje de Programación
(Motor del juego)
10 Aplicación incorrecta de conceptos de 0,3 3 0,9
Gamification
9 Mala comunicación entre los actores del 0,2 4 0,8
proyecto
Figura 14. Lista de Riesgos. Versión 4. Fecha: jueves, 15 de agosto de 2013
170
Explicación de los cambios:

Riesgo Nº1: Al terminar de implementar los juegos quedan sólo tareas de pruebas, análisis y
documentación.

Riesgo Nº6: Aumentó debido a que el diseñador no entregó los gráficos de las palabras de los
niveles 2, 3 y 4.

Riesgo Nº7: Se realizaron reuniones con las docentes y se obtuvo buena respuesta.

Riesgo Nº3: Ya se cuenta con la mayoría de los sonidos necesarios.

Riesgo Nº2: Bajó debido a que se terminó de implementar los juegos y las métricas de calidad
fueron satisfactorias.

Riesgo Nº9: La muestra de prototipos avanzados fortaleció la confianza del cliente hacia el
equipo.

171
9. Comunicación

9.1. Comunicación interna

Los integrantes del equipo acordamos realizar reuniones frecuentes de trabajo ya que al ser
sólo dos integrantes se facilita la coordinación de horarios. Las reuniones se realizarán como
mínimo tres veces por semana aumentando esta frecuencia en períodos de trabajo más
intenso.

9.2. Comunicación externa

Los actores involucrados en el proyecto además de los autores son: los tutores, las maestras
que dan el asesoramiento pedagógico y el diseñador. A continuación se detalla las formas de
comunicación acordadas con cada uno de ellos:

 Tutores: Se realizan reuniones semanales con Luis Calabria y/o Rafael Cohen los días
martes de 18:30 a 20:30 en el Laboratorio de Simulación y Juegos de la universidad para
informarle del estado del proyecto y discutir las próximas actividades a realizar. También
manejamos comunicación informal mediante correo electrónico para consultas que se
presenten en el tiempo intermedio.

 Cliente: Se realizan reuniones de trabajo en el domicilio de alguno de los asistentes. Allí

se coordina el trabajo que las maestras realizarán, así como también la fecha de la próxima
reunión. Para facilitar la comunicación entre las maestras y tener una forma adecuada de
compartir los aportes realizados se creó un blog. Las maestras participan desde sus
hogares realizando sus aportes y comentando los aportes realizados por el resto del grupo.
De esta forma estamos contemplando las limitaciones de tiempo presentadas. Se utiliza la
comunicación por correo electrónico para recordar fechas acordadas y confirmar
asistencia a las reuniones.

172
 Diseñador: Se realizan reuniones de trabajo en el domicilio de alguno de los asistentes
para explicar las necesidades del proyecto y se utiliza el correo electrónico para realizar
las entregas y el intercambio de opiniones sobre los gráficos entregados.

173
10. Bitácora

Pensamos que el registro de las actividades serviría para realizar una mejor gestión del
proyecto; haciendo anotaciones sobre los principales eventos de cada reunión podríamos ver
el camino recorrido y proyectar de mejor manera las acciones a seguir. Por este motivo
decidimos hacer una bitácora en la cual anotamos en forma descriptiva todas las tareas
realizadas, ya sea reuniones con los distintos actores del proyecto, avances en el desarrollo,
jornadas de investigación etc. Google Docs nos proporcionó una herramienta adecuada por su
actualización online, ya que la construcción de la bitácora es responsabilidad de ambos
integrantes del equipo. A continuación se proporciona un link de acceso a este documento.

https://docs.google.com/document/d/1MCarC1ulK9gJhV952RgVlD9dyt4GSkipSeG4EMsQ6
-8/edit?usp=sharing

174
Anexo 5 - Plan de calidad

1. Objetivo del documento

El objetivo de este documento es establecer un plan de aseguramiento de la calidad. Para ello

se van a definir las tareas a realizar, proveer los documentos, guías y herramientas necesarias
para llevar a cabo el plan. Será empleado por los distintos interesados en el desarrollo del
proyecto con el propósito de cumplir con los objetivos de calidad definidos en este mismo
documento.

2. Alcance del documento

En este plan se establecerán todas las actividades de aseguramiento de la calidad que serán
realizadas durante el desarrollo del videojuego. Se incluirán la definición de los estándares a
aplicar, las evaluaciones a realizar y los procedimientos a seguir con el fin de alcanzar los
requerimientos técnicos establecidos.

3. Gestión de SQA

El aseguramiento de la calidad está presente en todo el proceso de desarrollo del software,

desde su planificación, durante el desarrollo, y luego que finaliza la entrega del producto,
analizando el proceso realizado con el fin de establecer una mejora continua.

La gestión definida para el proyecto incluirá los siguientes tres sub-procesos: planificación de
la calidad, aseguramiento de la calidad y control de la calidad.

3.1. Planificación de la calidad

Se establecen las normas de calidad son relevantes para el proyecto y se determina cómo
satisfacerlas.

Entradas: Enunciado de alcance del proyecto, plan de gestión del proyecto.

175
Salidas: Plan de SQA (presente documento), métricas de calidad, plan de gestión de proyecto
actualizado.

Factores ambientales encontrados: Regulaciones impuestas por Universidad ORT para el

desarrollo del producto, ejemplo de esto son el Documento 302 y Documento 303.

3.2. Aseguramiento de la calidad

Consistirá en aplicar las actividades planificadas y sistemáticas a la calidad, para asegurar que
el proyecto utilice todos los procesos necesarios para cumplir con los requisitos.

Entradas: Plan de gestión de calidad (presente documento), métricas, información de

rendimiento del trabajo, mediciones del control de calidad.

Salidas: Acciones correctivas recomendadas y plan de gestión de proyecto actualizado.

3.3. Control de la calidad

Consistirá en supervisar los resultados específicos del proyecto, para determinar si cumplen
con las normas de calidad relevantes e identificar modos de eliminar las causas de un
rendimiento insatisfactorio.

Entradas: Plan de gestión de la calidad (presente documento), métricas de calidad, lista de

control, información del rendimiento del trabajo y entregables.

Salidas: Mediciones de control de la calidad, reparación de defectos (según prioridad),

recomendación de reparación de defectos, acciones correctivas recomendadas, acciones
preventivas recomendadas, productos entregables validados y plan de gestión de proyecto
actualizado.

3.4. Roles

176
Se definen los roles para lograr una mejor definición del plan de calidad. Éstos se rotarán
entre ambos integrantes del equipo de proyecto.

Responsable de SQA: Se encargará de definir, hacer cumplir y realizar un seguimiento del

presente plan. Éste tendrá la responsabilidad de reportar los avances del proceso de SQA y
cualquier dificultad encontrada que pueda afectar el desarrollo previsto del proyecto.

Tester: Será el miembro del equipo responsable de ejecutar las pruebas programadas en el
plan, además de reportar cualquier tipo de incidencia. Se acuerda que las tareas realizadas por
un integrante del equipo serán testeadas por el otro integrante. A tales efectos se diseña un
espacio en el Pizarrón Kanban para ubicar las actividades pendientes de testeo.

Alpha-Tester: Será el responsable de realizar pruebas de sistema y las pruebas de campo de

la aplicación, además de reportar las incidencias detectadas.

177
4. Definición de estándares

En la presente sección del documento se pasarán a listar los distintos estándares que se
utilizarán durante el desarrollo del proyecto, con el objetivo de reducir los riesgos en la mala
interpretación de los distintos elementos de la configuración (ECS). Los mismos abarcarán
distintos aspectos, como son estándares para la codificación, estándares para la
documentación, estándares para versionados y estándares para el uso de herramientas.

4.1. Documentación

Para la elaboración de los documentos del proyecto se usará la herramienta ofimática

Microsoft Office versión 2007 y 2010. Todo documento deberá respetar los estándares
requeridos por la universidad (documento 302 y 303). Con tal objetivo se crean dos plantillas,
una para el documento principal y otra para los anexos con formato .dotx. Ésta deberá ser
utilizada para la creación de los documentos del proyecto.

Las citas bibliográficas se realizarán usando el sistema: Apellido, Nombre de Autor y Año de
publicación y se listan ordenadas alfabéticamente por apellido del autor.

Para realizar un versionado de los documentos elaborados se acordó grabarlos con un nombre
que incluya la fecha. Ejemplo: NombreArchivo_2013-08-25.

El respaldo de los documentos se realizará usando la herramienta Dropbox. En el caso de los

documentos de gestión, los cuales se acceden en forma frecuente se usará Google Doc.

4.2. Codificación

Se estableció un conjunto de buenas prácticas con el fin de lograr un mayor entendimiento del
trabajo de codificación realizado entre los integrantes del equipo. Para lograr este estándar
con mayor eficiencia, se configuró la IDE usada (Eclipse) para que genere automáticamente
los comentarios iniciales. Véase Anexo A de este documento - Estándar de codificación.

178
 4.3. Registro de horas

Para el registro de horas se utiliza una planilla de cálculo de Google Docs a la cual
denominamos “Hoja de Ruta”. Se registran datos de: Nº de semana, fecha de la tarea, título,
descripción, categoría, etapa, cantidad de horas realizadas, integrantes que participan. Ésta
planilla se configuró para que en forma automática se obtenga un reporte del registro de
esfuerzo discriminado por categorías. Ver figura 1.

Figura 1. Fragmento de Hoja de Ruta correspondiente a la semana 35.

En dicha configuración también se tiene información sobre el total de horas que se realiza en
cada semana y se compara con el promedio de horas semanales que se ha realizado durante lo
que va del desarrollo del proyecto. Con esto se pretende mostrar una alerta si sucede una
disminución del esfuerzo. Ver figura 2.

179
 Figura 2. Horas semanales comparadas con el promedio.

4.4. Repositorio

Como repositorio para el código del programa se utilizará el sistema de versionado SVN y
para realizar el hosting en la nube se usará la herramienta Assembla. Se configurará el sistema
de versionado de forma tal que se deba solicitar el bloqueo (Lock) de un archivo para editarlo
con el fin de evitar conflictos en las actualizaciones del código.

4.5. Registro de tareas

Para planificar y administrar las tareas del proyecto se usarán dos herramientas:

 Pizarrón Kanban implementado mediante la herramienta LeanKit.

 Planilla de datos usando una planilla de cálculo de Google Docs.

Con el pizarrón Kanban se tiene un recurso gráfico en el cual visualizar las tareas pendientes
y hacer un mapa mental del progreso del proyecto.

La planilla se usará para llevar un control del tiempo que lleva cada tarea, esta información
servirá para llevar un registro del tiempo dedicado a cada tarea y luego para mejorar la

180
estimación de las tareas futuras. Se configuró para que una vez que se finalizó la tarea, se
muestre el porcentaje de la desviación en la estimación.

Se determinó una agenda para gestionar las tareas:

 Lunes: planificación de la semana detallando las tareas que vamos a hacer con un
máximo de 30 hs por persona. Las tareas registradas deben ser cortas no superando las
4 horas. Si la tarea excede esta carga horaria debe dividirse en dos o más.

 Martes: revisión con el tutor de tareas realizadas y del plan semanal realizado el día
anterior.

181
5. Actividades de control de calidad

En este capítulo se identificarán las actividades específicas del proceso de SQA a llevarse a
cabo para asegurar la calidad del videojuego.

5.1. Diagrama de actividades de SQA

Figura 3. Diagrama de actividades de SQA

182
 5.2. Definición de actividades de SQA

5.2.1. Validación de GDD y TDD

El documento GDD será validado por el cliente. Uno de los ítems más importantes a analizar
de éste documento es la intervención didáctica. El Story Board (conjunto de ilustraciones que
muestran la secuencia de todas las pantallas del juego), incluido en este documento, se uso
como base para la evolución del videojuego.

El documento TDD será aprobado por el tutor, ya que en nuestro grupo de trabajo es quién
puede asesorarnos en los aspectos que éste documento trata.

5.2.2. Validación de recursos

Se solicitará al cliente la aprobación de los recursos. Entre ellos se cuenta con sonidos, fuente,
recursos gráficos y diagramación de los mismos. Esta validación tiene una importancia
estratégica ya que la presentación de la información incide en la viabilidad de la propuesta
pedagógica.

5.2.3. Validación de prototipos

Al finalizar la etapa de pre-producción se mostrarán los prototipos realizados. De esta manera

el cliente tendrá una idea más cercana del producto final. Se realizarán ajustes corrigiendo los
detalles de los requerimientos expresados en el documento TDD. Estos se registrarán en las
minutas de reunión con el cliente.

5.2.4. Inspección de código

Al final de cada iteración de la producción, se inspeccionará el apego a los estándares de

codificación definidos. También se realizará una revisión de las tareas pendientes (//TODO)
verificando de no exista una cantidad excesiva. Si las hubiera se destinarán horas de
producción a solucionar parte de éstas.
183
 5.2.5. Testing

Se define un plan de pruebas (Ver sección 7) que será utilizado desde la etapa de producción.
Se debe obtener un listado de los errores conocidos ponderado según la gravedad.

5.2.6. Refactoreo

Se entiende como refactoreo a la técnica de modificación del código fuente sin cambiar su
comportamiento con el fin de mejorar atributos de calidad como mantenibilidad y
performance. Esta tarea se realizará especialmente luego de finalizada cada iteración de la
producción y una instancia en la liberación.

5.2.7. Pruebas

Se realizarán pruebas de sistema, pruebas de aceptación y pruebas de campo. En las pruebas

de aceptación se relevará la aprobación del cliente y por ende será un reflejo del éxito del
proyecto. Las pruebas de campo se realizarán con niños pertenecientes al público objetivo en
alguno de los contextos que se quiere trabajar. El registro de los resultados obtenidos deberá
realizarse en forma ordenada y sistemática con el fin de hacer uso eficiente de los mismos. Se
elaboraran planillas de relevamiento. (Ver sección 7)

184
6. Medidas y métricas

Se definirá un plan de métricas con el fin de obtener información cuantitativa de los

principales atributos de calidad del videojuego y del proceso de elaboración del mismo.

Se realizarán diversas mediciones en distintas etapas del proyecto, de manera de detectar

tempranamente posibles obstáculos que tenga que enfrentarse el equipo.

El equipo decidió medir y controlar aspectos como: esfuerzo según tipo de tarea y desviación
en la estimación para el proceso. Avance del producto, tiempo de carga y cantidad de fallas
para el producto.

6.1. Métricas del proceso

6.1.1. Esfuerzo según tipo de tarea

El objetivo de esta métrica es obtener datos históricos que servirán para realizar en forma más
acertada las futuras planificaciones, en etapas avanzadas de este mismo proyecto o en otros
proyectos que se puedan realizar.

Para calcular estas métricas se obtendrán datos del registro de horas en la Hoja de ruta. Se
acumularán las horas según el tipo de tarea realizado.

6.1.2. Desviación en la estimación

Según Steve McConnell [1] “una buena estimación es aquella que provee una visión clara de
la realidad del proyecto y permite tomar buenas decisiones de cómo controlar el proyecto para
alcanzar sus objetivos”. La desviación en la estimación nos permitirá saber el grado de acierto
que se está teniendo en las actividades de estimación y como resultado de esto se tendrá una
gestión más adecuada a la realidad del proyecto.

185
Para relevar esta métrica se registrará para cada tarea, la cantidad de horas que se estimó
llevaría cumplirla y las horas que realmente llevó. Luego se calcula la desviación, que resulta
de la diferencia de las dos anteriores, y el porcentaje de error dividiendo la desviación entre la
cantidad de horas real.

6.2. Métricas del producto

6.2.1. Avance del producto

La medición del avance del producto nos permitirá monitorear riesgos tales como: Retrasos
en el proyecto debido a mala estimación y por ende la insatisfacción del cliente. Por este
motivo es importante tener información sobre los requerimientos del producto cumplidos.
Esta métrica será calculada en todas las etapas del proyecto, teniendo en cuenta las
actividades realizadas en cada etapa.

6.2.2. Tiempo de carga

Es importante poder determinar el tiempo de carga del juego ya que si este tiempo es grande,
genera inseguridad sobre el correcto funcionamiento del producto y por lo tanto una mala
experiencia. El tiempo de carga se medirá al final de la etapa de producción y durante la
liberación. Se calcula como la diferencia entre el instante de tiempo en el que se solicitó el
juego y el instante de tiempo en el que se muestra el juego. Mediremos la carga inicial del
juego y la carga de cada mini-juego: Laberinto y Naves. Este valor no debe ser superior a 5
segundos.

6.2.3. Cantidad de fallas

El objetivo de esta métrica es determinar el número de fallas del juego en un número

determinado de corridas. Las medidas a tomar son el número de fallas encontradas en un
ciclo, es decir, desde que se abre la aplicación, se juega y se cierra. Las fallas se dividirán
según su tipo en: leve, grave y fatal. Es deseable que la cantidad de fallas fatales sea nula.

186
 6.3. Datos obtenidos y análisis

6.3.1. Esfuerzo según tipo de tarea y etapas

El cuadro siguiente muestra las métricas obtenidas al medir el total de horas destinadas a cada
tipo de tarea.

Figura 4. Esfuerzo según tipo de tarea del total del proyecto.

Figura 5. Gráfica de esfuerzo según tipo de tarea del total del proyecto.

La mayor cantidad de horas se registró en la categoría Desarrollo. Esto se explica por el tipo
de producto a elaborar, además al incursionar en un área de desarrollo nueva para los
integrantes del equipo como lo es videojuegos se incrementó el esfuerzo dedicado a
programar. Si agregamos las horas de Desarrollo, Prototipos y Testing vemos que abarcan

187
más del 50% del esfuerzo del proyecto. Luego están las horas correspondientes a tareas de
documentación que abarcan algo más de la quinta parte del esfuerzo total. El esfuerzo
correspondiente a Investigación está dedicado al tema de Gamification, al análisis de motores
para desarrollar el videojuego y la investigación educativa que permitirá justificar la
propuesta de juego.

El esfuerzo dedicado a las reuniones responde a la cantidad de actores involucrados en la

realización del proyecto: Cliente Rosario Castro, maestras de la escuela 206, maestras de los
colegios donde realizamos las pruebas, el diseñador y los tutores.

6.3.2. Desviación en la estimación

La información recabada puede verse en la siguiente figura, donde se detalla la desviación en

la estimación para las distintas etapas del proyecto.

Figura 6. Desviación de la estimación.

Es importante mencionar que las desviaciones fueron siempre en sentido negativo, es decir
que estimamos menos del tiempo que realmente llevó. La estimación correspondiente a la
primera etapa está dentro de los valores más aceptables que se obtuvieron. Aunque esto es
contradictorio a la regla de que con experiencia se logran mejores resultados, este valor se
explica por el tipo de tareas realizadas en esta etapa, las cuales corresponden en su mayor
parte a Documentación y Reuniones e Investigación. Para estas tareas es más fácil estimar el
esfuerzo necesario. En las estimaciones realizadas durante las etapas de producción se ve una
notoria mejoría. Finalmente en la etapa de liberación la desviación en la estimación aumentó
considerablemente. Pensamos que este hecho se debe a que no habíamos realizado
estimaciones de documentación, tarea que insumió más esfuerzo en la etapa de liberación.

188
Además en esta etapa se finalizaron tareas que no pudieron terminarse en etapas anteriores y
fueron contempladas en esta etapa.

6.3.3. Avance del producto

El siguiente gráfico muestra el avance de cada requerimiento en cada etapa del proyecto.

Figura 7. Registro del avance del producto.

Para elaborar el gráfico se tuvo en cuenta el listado inicial de los requerimientos impreso a la
derecha del gráfico. Al finalizar cada etapa se resume el grado de avance en cada
requerimiento. Puede observarse que el mayor avance está en la etapa de Preproducción por
ser ésta la etapa de mayor duración (8 semanas).

189
 6.3.4. Tiempo de carga

Las siguientes figuras muestran las mediciones obtenidas de los tiempos de carga en las
etapas de producción y liberación.

Figura 8. Tiempo de carga.

Figura 9. Gráfica de tiempo de carga.

El tiempo de carga de los juegos fue aceptable desde la etapa de producción. Sin embargo
para el tiempo de carga inicial fue necesario corregir errores en la carga del Diccionario,
realizando una carga más simplificada del mismo. Luego de las correcciones se llegó a
valores aceptables.

6.3.5. Cantidad de fallas

Las pruebas se hicieron realizando una categorización del resultado de cada una con los
siguientes ítems: “Ok” cuando la prueba transcurrió correctamente, “Leve” si se encontraron

190
detalles a corregir, “Grave” si altera la partida del juego y “Fatal” si no se puede seguir
jugando. En la figura siguiente se muestra un resumen de los resultados obtenidos.

Figura 10. Resumen de Pruebas realizadas

A pesar de que sólo un la cuarta parte de las pruebas salieron correctamente, los resultados
fueron satisfactorios porque las fallas leves que corresponden al 63% de las pruebas son de
origen conocido, habiendo registrado ya el incidente para su corrección. Entre estas fallas se
tiene: recargar la fuente para evitar la alteración del color y mostrar el premio de la categoría
que corresponde.

191
7. Plan de Pruebas

El objetivo de estas pruebas será el de llegar a una versión estable del videojuego la cual
implemente la mayor cantidad posible de los requerimientos solicitados por el cliente. Dadas
las limitaciones de recursos en cuanto a la duración del proyecto y a la cantidad de integrantes
en el equipo se realizarán solo pruebas de sistema, de aceptación y de campo.

7.1. Pruebas del sistema

Las pruebas de sistema del videojuego durante la etapa de implementación se realizarán

corriendo el programa directamente sobre el dispositivo. De esta forma ya se ven los
resultados directamente sobre la tablet evitando problemas de despliegue de los recursos
gráficos. A tales efectos se compraron dos tablet con Android y pantalla de 7 pulgadas,
características similares a las solicitadas en la licitación del Plan Ceibal [2] Licitación de
tablets.

7.2. Pruebas de aceptación

Se realizarán al finalizar los primeros prototipos citando al cliente Rosario Castro y a las
maestras que ofrecieron dar apoyo técnico.

Se relevará un listado de las correcciones y nuevos requerimientos solicitados ordenadas

según la prioridad de las mismas. La salida de estas pruebas se registra en la minuta de la
reunión con las maestras y servirá para crear las tareas que den cumplimiento a los
requerimientos del cliente. Ver Anexo B de este documento.

7.3. Pruebas en campo

El primer objetivo de las pruebas de campo es realizar una observación directa con el fin de
relevar datos para la investigación, ver el manejo que realizan los niños del juego, verificar si
el grado de dificultad propuesto es el adecuado, saber si se logra la motivar y entusiasmar a

192
los chicos. El relevamiento de esta información se incluye en el Anexo de Investigación
Educativa.

En segundo lugar se quiere detectar errores existentes en esta primera versión del juego. Se
obtendrá un listado de errores conocidos para ser corregidos en etapas posteriores a la entrega
del presente proyecto.

Las pruebas se realizarán con niños pertenecientes al público objetivo en alguno de los
contextos escolares que se quiere investigar. Particularmente se han realizado contactos para
trabajar en colegios privados y en el instituto C.E.I. de Montevideo que atiende a niños
discapacitados a través del cliente Rosario Castro.

7.4. Errores conocidos pendientes de corrección

Las pruebas de sistema realizadas permitieron detectar un conjunto de errores que se detallan
en la Figura Nº 5. Los errores conocidos serán clasificados por su tipo: Leve, Grave y Fatal; y
por su estado: Pendiente, En proceso, Para testear, Finalizado. El listado que se muestra a
continuación informa los errores encontrados en las pruebas realizadas en la etapa de
liberación.

193
Figura 11. Lista de errores conocidos al 4 sep. 2013.

194
8. Referencias bibliográficas

[1] McConnel, S. Desarrollo y Gestión de Proyectos Informáticos. Como dominar

planificaciones ajustadas de software. McGraw Hill. 1996.

[2] Plan Ceibal. Licitación de Tablets. (2012, Dec. 31). [Online]. Disponible:
http://www.ceibal.org.uy/index.php?option=com_content&view=article&id=884:lpi-1021-
2012-10000-tablets&catid=51:convocatorias-vigentes&Itemid=82

195
9. Anexos

9.1. Anexo A. Estándar de codificación.

1) Comentario Inicial de cada archivo:

/**
* @name: ${file_name}
* @owner: ${user}
* @date: ${date}
* @description:
* ${todo}
*
* @changes:
* - ${date} / ${user} / First Version
* - Date/Author/Change
*/

2) Comentario inicial de cada clase:

/**
* @author ${user}
* @date: ${date}
* @description:
* ${todo}
*
* ${tags}
*/

3) Comentario inicial de cada método

/**
* @author ${user}
* @date: ${date}
* @description:
* ${todo}
*
* ${tags}
*/

196
4) Declaraciones:
El orden que se va a seguir es:
a. Declaración de paquetes.
b. Declaración de importaciones.

5) Declaración de clases e interfase

El orden en que deben aparecer las partes es el siguiente:
a. Comentarios de documentación de clase o interfase.
b. Declaración de clases o interfase.
c. Si es necesario, comentarios de implementación.
d. Variables de clase (static): primero públicas, luego protegidas y por último
privadas.
e. Variables de instancia: primero públicas, luego protegidas y por último
privadas.
f. Constructores.
g. Métodos: agrupados por funcionalidad y no por alcance o accesibilidad.

6) Indentación:
La unidad de indentación será de 8 espacios
Se evitarán las líneas de más de 80 caracteres. Las líneas se romperán de acuerdo a los
siguientes principios:
a. Después de una coma.
b. Antes de un operador.
c. Preferir roturas de alto nivel (más a la derecha que el "padre") que de bajo nivel
(más a la izquierda que el "padre").
a. Alinear la nueva línea con el comienzo de la expresión al mismo nivel de la línea
anterior.

7) Nombres de Variables

Para nombrar las variables locales se usará la nomeclatura “lNombreVariable”.

Para las variables que se usan como parámetro: “pNombreVarible”.
Los atributos se nombrarán con “_” como prefijo.

197
8) Comentarios generales

Se usarán los siguientes separadores para señalar grupos de atributos o métodos:

//====================================================
// CONSTANTS
//====================================================

//====================================================
// VARIABLES
//====================================================

//====================================================
// CONSTRUCTOR
//====================================================

//====================================================
// GETTERS & SETTERS
//====================================================

// ====================================================
// OTHER GROUP OF FEATURES
// ====================================================

198
 9.2. Anexo B. Reunión de validación.

Minuta de la reunión 29/07/2013

1. Se muestra el prototipo de EduGames

2. Se pregunta sobre el videojuego ¿qué cosas no les gustó de la aplicación? ¿Qué cosas si les
parecieron acertadas?

Con los juegos se facilita el entendimiento de la aplicación.

¿Qué es el sexo desconocido? habría que quitar este ítem.

Les gustó la pantalla del premio, el apoyo sonoro. En general faltaría más acompañamiento
sonoro en todo. Ejemplo: en pantalla de evaluación: aplausos (logros), uuuu (error).

Cambiaría:

1. Pantalla configuración: apodos y género con apoyo visual, caracterizar el apodo según
el sexo: curioso-curiosa, etc. Poner velitas en vez de asterisco.

2. Sonido en los Badges que relate la descripción del premio. Descripciones cortas

3. Palabras más grandes, principalmente para el nivel 1. Nombrar dos veces la palabra en
este nivel

3. ¿La intervención didáctica, cuando aparecen las palabras y luego la frase, la hacemos igual
para todos los niveles o cambiamos algo? (las frases y las palabras ya son distintas)

Nivel 1: la palabra se nombra 2 veces sin la frase, con animación

Nivel 2: palabra y frase, la palabra resaltada en la frase en otro color. Todo con mayúscula.

199
Nivel 3: palabra y frase, con la frase que aparece de a poco, todo en mayúscula.

Nivel 4: palabra y frase en script (negro).

Color uniforme: negro para frases y rojo para las palabras.

4. ¿Cómo manejamos los tiempos de exposición de la palabra y la frase en esta pantalla, el

método doman recomendaba tipo flash, que tiempo será el adecuado?

Los tiempos que se implementaron están bien.

Hacer una animación a las palabras antes de que aparezcan y que se repita la animación.

5. Para la aplicación en modo maestra, en vez del juego de la memoria uno de los tutores
propuso hacer un juego donde aparece una frase con imágenes y más arriba las palabras
sueltas de esas imágenes hay que asociar la palabra con la imagen (juego + escolarizado).
¿Cuál les parece mejor?

6. ¿Alguna otra idea de juego para el modo maestra?

- Se muestra la palabra y las letras sueltas, hay que unir las letras sueltas con la palabra.

- Mostrar varios textos con las letras en desorden y una bien, encontrar la correcta.
SOFA - FASO - SOAF (mayúscula)

- Se muestra una guía para la ubicación de las letras y las letras sueltas.

- Unir sílabas para formar palabras.

- Frase con dibujos se sustituye por dibujos.

- Armar la frase.

El juego de la memoria también podría estar, se propone la siguiente secuencia:

200
 - dibujo con dibujo.

- con palabra y dibujo.

- palabra y palabra.

- aumentando la cantidad de cuadritos.

7. Como docentes, ¿qué datos sería útil recolectar?

Ejemplos:

 tiempo en cada pantalla

 veces que repiten una prueba (categoría)

 tiempo total de juego

No es necesario para las actividades de enseñanza, sería útil si se realizara una investigación.

Para complementar la evaluación sería útil saber que palabras acierta y qué palabras se
equivoca en la pantalla de evaluación

8. ¿Las frases tienen que ir con sonido? ¿Las podemos grabar con su voz?

Si, con sonido. Se sacaron las del primer nivel.

9. ¿Tienen alguna canción de fondo que pueda ir?

No hay sugerencias

201
Anexo 6 - Plan de SCM

1. Objetivo

El objetivo del plan de gestión de la configuración de software para el Proyecto EduGames es

identificar y controlar los elementos de configuración de software. Estos elementos pueden
ser tanto el código desarrollado, documento entregables, entre otros.

De los elementos de configuración es importante mantener versiones, historial de cambios,

responsable de los mismos y líneas base de los elementos.

Se utiliza SCM por la necesidad de mantener y controlar el desarrollo del proyecto al tener
más de un recurso trabajando concurrentemente. De esta forma se evitan inconvenientes que
puedan surgir por falta de comunicación, facilitando el seguimiento de los elementos de
configuración y la disponibilidad y consistencia de los mismos.

2. Alcance del documento

Este documento describe el plan de gestión de la configuración de software.

En el documento se encuentra información detallada sobre los elementos a gestionar, así

como también las herramientas a utilizar para realizar el versionado de dichos elementos.

3. Herramientas

Las principales herramientas que se utilizan para el control de la configuración serán

Dropbox, SVN, Assembla y Google Drive.

Dropbox es un sistema de almacenamiento en la nube. Este espacio de almacenamiento será

utilizado como repositorio. Dropbox ofrece un cliente Windows con el cual cada usuario
puede acceder a un espacio de almacenamiento privado. También permite compartir carpetas

202
entre diferentes usuarios, esta funcionalidad es la que el equipo utilizará para que todos
puedan acceder a los diferentes ECS en un espacio común.

SVN (Subversion) y Assembla se utilizarán para el versionado y como repositorio de todo el

código desarrollado durante el proyecto a través de Eclipse. SVN utiliza un único número de
versión que identifica un estado común de todos los archivos del repositorio en un instante
determinado que se está trabajando. Assembla provee una herramienta de colaboración y de
seguimiento de tareas basadas en la nube para organizar y administrar proyectos de desarrollo,
la cual es utilizada como repositorio del código generado.

Google Drive es un servicio de alojamiento de archivos, Google Docs. Estos archivos fueron
utilizados para la gestión del proyecto y algunos documentos importantes. Al igual que
Dropbox, se almacena en la nube y puede ser accedido por distintos usuarios a la misma
información.

203
4. Elementos de configuración (ECS) identificados

4.1. Documentos

Los documentos identificados que forman parte del proyecto son los siguientes:

 Game Concept

 GDD

 TDD

 Plan de proyecto

 Plan de SQA

 Plan de SCM

 Gamification

 Método global de lectura

 Documentos de investigación

Los documentos se versionarán en Dropbox. El identificador de los documentos será la fecha

de la última modificación.

204
 4.2. Código fuente y recursos del videojuego

Con código fuente nos referimos a los diferentes archivos de código que el equipo va
desarrollando, y a los archivos que SVN genera automáticamente para guardar información y
configuraciones que se establecen en el editor gráfico de la herramienta.

Los recursos del juego son los diferentes recursos multimedia necesarios para el producto.
Esto incluye:

 Texturas

 Sonidos

 Archivos XML

Ambos ECS se versionarán en Dropbox. Tanto el código fuente como los recursos se
encuentran ubicados en directorios creados para el proyecto EduGames. Para almacenar una
versión en el repositorio, se subirá a Assembla los archivos modificados hasta el momento.
Para el caso de los documentos, se grabarán utilizando la fecha de modificación como parte
del nombre del mismo. De esta manera se obtiene una versión conteniendo los ECS
mencionados.

205
5. Respaldos

Cada mes se realizará un respaldo a un disco duro externo a cargo del responsable de SCM.
Este respaldo es obligatorio, y puede hacerse más de una vez al mes en caso de que el equipo
de proyecto considere que es importante respaldar los últimos avances. Otra razón para hacer
un respaldo puede ser que el espacio disponible en Dropbox sea muy pequeño y sea necesario
liberarlo.

El respaldo será de todos los ECS descriptos anteriormente. Además, se conformará la última
versión del producto con las últimas versiones estables de cada ECS.

206
Anexo 7 – Gamification

1. Abstract

En el presente documento se desarrolla la temática de Gamification como forma de

motivación.

En el desarrollo del trabajo se tratan conceptos de esta nueva área de estudio y luego se realiza
un enfoque para usar esta metodología en ambientes de Desarrollo de Software.

Debido a que no existe una traducción de la palabra en inglés Gamification, en el desarrollo

de este trabajo se usará el término inventado: Gamificación, ya que este se adapta mejor al
contexto del idioma español.

Corresponde a la entrega del trabajo como Proyecto Final de la carrera de Licenciatura en

Sistemas de la Universidad ORT del año 2013 por la alumna Mónica Carle (4039) y el
alumno Rodolfo Olivera (154985).

207
2. Objetivo del documento

Este documento explica el concepto Gamification como forma de motivación. El objetivo es

definir Gamification para utilizarlo como herramienta de atracción hacia el videojuego.

3. Alcance del documento

En el desarrollo del trabajo se tratan conceptos de esta nueva área de estudio y luego se realiza
un enfoque para usar esta metodología en ambientes de Desarrollo de Software.

208
4. Definición

Gamificación se refiere al uso de atributos del juego para encauzar el comportamiento lúdico,
en ambientes no lúdicos con el fin de hacer las actividades más atractivas, convincentes y
conseguir un mayor compromiso de los participantes. Esto hace que las tareas se perciban
como algo diferente a estar trabajando.-

Esta definición tiene tres componentes:

1- “El uso de atributos de juego” incluye dinámicas y mecánicas de juego.

Dinámicas de juego: Estrategias comúnmente usadas en el diseño de juegos basadas en

motivaciones psicológicas para guiar el comportamiento. Las dinámicas del juego se
relacionan con las necesidades humanas y se pueden satisfacer a través de las técnicas del
juego. Algunas de las necesidades características de las dinámicas del juego son el deseo de
logro, de recompensa, de competición, de altruismo, etc.

Mecánicas de juego: Se refiere al conjunto de reglas del juego que constituyen los
fundamentos de la jugabilidad y el sistema mediante el cual progresa. Incluyen puntos, tablas
de posiciones, suerte, recompensas, recolección de objetos, desafíos, sorpresas, carreras y
otras. Son usadas en los juegos para entusiasmar a los participantes. Se pueden incluir varias
en un mismo juego.

Como atributos de juego puede incluirse también: principios de diseño de juegos, psicología
del juego, narración de historias y otros.

2- “Comportamiento lúdico” se refiere a compromiso, interacción, adicción,

competición, colaboración, conciencia, aprendizaje y otros observados el desarrollo de juegos.

3- “En ambientes no lúdicos” lo cual puede ser cualquiera excepto el juego, por
ejemplo: educación, trabajo, actividad física, compromiso ciudadano, etc. Gamificación no es
un juego. Los participantes no saben que en realidad están jugando” afirma Michael Wu [2].

209
El uso de premios o incentivos no es Gamificación sino simplemente un sistema de
incentivos. A pesar de que los incentivos a menudo pueden ser usados como una técnica de
juego no son una forma de Gamificación por sí mismos. No son considerados como atributos
de juego porque no fueron creados pensando con los principios de juego, lo cual lo hace
aburridos.

La Gamificación se basa en la predisposición de los seres humanos a participar en juegos.

4.1. Definición del Juego

Debido a que la Gamificación utiliza atributos del juego es pertinente partir de una buena base
definiendo lo que es el Juego. Para ello se puede encontrar una amplia gama de conceptos.
Según Johan Huizinga [3] el juego se define en base a ciertos rasgos:

 Actividad Libre. El sujeto la elige y se siente libre de hacerla en el tiempo y

forma que más le plazca.

 Es una situación ficticia que puede repetirse. Se diferencia de la vida común, es

imaginaria, tiene ciertos límites espacio-temporales "irreales".

 Está regulada por reglas específicas. Existen convenciones respecto a las

normas o reglas que delimitan los límites espacio temporales en que se realiza
la actividad.

 Tiene una motivación intrínseca y fin en sí misma. Es el sujeto el que decide

jugar por jugar y no para lograr un objetivo ajeno al juego en sí.

 Genera cierto orden y tensión en el jugador. El juego exige cierto orden para su
desarrollo y si ese orden se rompe se deshace el mundo que se ha creado para el juego.

210
 4.2. Cómo funciona

El juego es común a todos los grupos demográficos y socioeconómicos, ya que aborda los
deseos humanos básicos para la obtención de cosas como las recompensas, el estado, los
logros, la competencia, la libre expresión, y el altruismo.

La acción de la Gamificación consiste en aprovechar nuestros comportamientos y tendencias

arraigados en por la evolución de la especie, fundamentalmente el “secuestro del cerebro”
que se genera pulsando los botones de la sensación y la recompensa. La Gamificación se nutre
de las profundas tendencias primitivas y los comportamientos que han sido esculpidas por la
evolución en el tiempo para maximizar nuestras posibilidades de supervivencia. Hace 10.000
años, hemos utilizado estos comportamientos profundamente arraigados para manejar con
eficacia nuestro entorno natural.

Hoy en día, los juegos se han convertido en expertos en impulsar estos mismos botones para
crear sensaciones de placer y recompensa. Tom Chatfield [1] identifica varias formas en la
que el juego acciona estos botones.

Los sistemas de experiencia nos dan un sentido de logro de los hitos que llegan y nos
mantienen trabajando para ellos. Por ejemplo, la barra de progreso LinkedIn muestra la
cantidad de información sobre el perfil que falta completar y esboza los pasos que debes
seguir para lograr ese objetivo.

Recompensas por el esfuerzo (es decir, el refuerzo positivo) es una forma de activación de
productos químicos en nuestro cerebro, que nos hacen sentir bien y nos trae hacia el
comportamiento deseado. Por ejemplo, Foursquare premia a los usuarios con tarjetas para el
control de la mayoría de las veces en un lugar específico (insignia de alcalde).

Rápido, retroalimentación frecuente y evidente en respuesta a acciones de un usuario que

también se establece fuera de los centros de recompensa en nuestro cerebro. Por ejemplo,
Facebook es adictiva en parte porque permite a sus usuarios recibir información en tiempo
real en respuesta a sus comentarios y al “le gusta”.

211
Un elemento de incertidumbre es crucial para un sistema de incentivos eficaz. Los jugadores
se vuelven adictos a las máquinas tragamonedas, debido a la naturaleza impredecible de los
premios. Es el elemento de incertidumbre lo que tiene la gente en constante atención para ver
si un correo electrónico ha llegado a su bandeja de entrada o si alguien ha comentado su
estado en Facebook.

Otras personas (es decir, los elementos sociales), probablemente ofrecen a nuestros cerebros
las mayores recompensas. Los seres humanos son criaturas sociales por naturaleza. La
adicción a tener noticias de otras personas es una obviedad como lo demuestra el auge de los
medios sociales: Facebook, Twitter, etc. Según Gavin Marshall, Director de Innovación de
MXit, la red social más grande de Sudáfrica, las recompensas de los usuarios MXit son en su
mayoría de naturaleza social.

212
5. A tener en cuenta

Al igual que con cualquier sistema de Gamificación implementado dentro de un negocio, hay
cuestiones a tener en cuenta.

5.1. Consenso

Cuando se aplica un modelo de Gamificación es necesario que el grupo esté de acuerdo a

aplicarlo. Si se proponen actividades que son rechazadas por el grupo la propuesta puede ser
contraproducente.

5.2. Graduando la dificultad

Como en el juego es necesario mantener el equilibrio entre habilidades y dificultades para las
actividades que se plantean.
Una actividad que ofrece mucha dificultad será frustrante y otra que es muy fácil resultará
aburrida.

5.3. Equitativo

Si se usa un sistema de puntos debe asegurarse de que es equitativo. Un sistema en el cual se

usa un cálculo de puntos que no refleja el esfuerzo correctamente, puede hacer que algunas
personas sientan que no reciben el crédito que merecen por las tareas realizadas. Aunque tome
más trabajo se debe ajustar para que sea justo para todos.

5.4. Premios

Si se elige un sistema de recompensas tangibles se deben elegir premios que la mayoría desee.
Esto requerirá un poco más de investigación sobre los gustos del grupo de personas pero dará
mejores resultados.

213
6. Ejemplos

A continuación veremos como algunas marcas conocidas hicieron uso de la Gamificación

para cumplir algunos de sus objetivos:

 Dropbox le da la oportunidad al usuario de ganar más espacio de

almacenamiento completando alguna de las siguientes tareas: empezar en
Dropbox: hacer un tour por la web: 250 megas, conectar Dropbox con Twitter
y Facebook: 768 megas o recomendar a otros usuarios: 500 megas. Mecánica
usada: recolección (de megas)

 Cuando nos suscribimos en LinkedIn, el objetivo es aportar la máxima

información posible sobre nosotros mismos. Para mostrar los avances del
usuario en esta red social, LinkedIn se vale de una sencilla barra de progresión,
que trata de motivar al usuario para alcanzar el 100%. Mecánica usada:
sistemas de puntos.

 Con la tarjeta de cliente de Starbucks, el cliente de la famosa cadena de

cafeterías tiene la posibilidad de alcanzar varios niveles. Cuanto más alto es el
nivel, mayores son los beneficios para el cliente. Mecánica usada: niveles.

214
7. Referencias bibliográficas

[1] Chatfield, T. My TED talk: 7 ways games reward the brain. (2010, Jul 16) [Online].
Disponible:
http://tomchatfield.net/2010/07/16/tom_chatfield_7_ways_games_reward_the_brain/

[2] Wu, M. What is Gamification, Really? (2011, Jul 09) [Online]. Disponible:
http://lithosphere.lithium.com/t5/science-of-social-blog/What-is-Gamification-Really/ba-
p/30447

[3] Huisinga, J. Homo ludens. Madrid: Alianza / Emecé.1972. pag. 6.

215
Anexo 8 - Método global de lectura

1. Objetivo del documento

El objetivo del presente documento es explicar que es la metodología de lectura global con el
fin de entender la propuesta pedagógica aplicada en el proyecto.

2. Alcance del documento

Se presentará una clasificación de los métodos de enseñanza de la lectura y una breve
explicación de sus principales características. Finalmente se hará referencia a los argumentos
en favor del método global.

3. Introducción

Al hablar de los métodos de enseñanza de la lectura, están por un lado los que fundamentan la
mayor legitimidad del método global y por otra parte los que aluden a la mayor eficacia del
método alfabético, también llamado fonético. Para entender mejor la metodología global
consideramos necesario partir de una definición del proceso de adquisición de la lectura para
luego definir también las otras metodologías.

216
4. Proceso de adquisición de la lectura

La publicación de la OEA [1] sobre metodologías de lectura nos explica que el proceso de
adquisición de la lectura puede describirse como el desarrollo en el niño de una estrategia
correcta de aprendizaje consistente en reconocer patrones y secuencias de letras como
palabras, interpretándolas e integrándolas en la memoria.

“Cuando el sujeto se enfrenta a una palabra escrita y la reconoce visualmente se activa en su

mente una entrada lexical que está asociada a información visual-ortográfica pero también a
información fonológica, ya que las palabras escritas se aprendieron asociándolas con su
sonido en el aprendizaje del habla. La ejecución lectora depende básicamente de la
integración e interpretación correcta de la entrada léxica correspondiente al patrón de letras.
El sujeto debe identificar la palabra y emparejarla con la entrada léxica previamente
almacenada en su memoria recuperándola a partir de un conjunto de claves informativas que
proceden tanto del propio nivel lexical (morfema) como del análisis de las estructuras
componentes (letras o segmentos). La entrada lexical siempre está asociada a información
fonológica” [1]. Ver Figura 1

(1) “caballo”

(2) caballo

(3) /caballo/ (4) //kaa/-/o/ (5) /k/ /a/ // /a/ // /o/

Figura 1. Proceso de ejecución lectora.

217
Cuando se ve una palabra escrita (1), tras reconocerla visualmente (2) se activa su
representación visual-ortográfica (3) que está conectada con su representación fonológica (4).
Ambas activan el significado. Alternativamente se puede acceder a la representación
fonológica a través de la conversión grafema-fonema (5).

218
5. Métodos para la enseñanza de la lectura

A continuación se expondrá una clasificación de los métodos junto a una breve explicación.

Tomaremos la clasificación de Braslavsky [2] quien al referirse a los métodos de lectura los
divide entre los métodos de marcha sintética y los de marcha analítica. Fundamenta esta
clasificación mencionando que no existen más que estos dos métodos de lectura y que ambos
tratan de hacer comprender al niño que existe cierta correspondencia entre los signos de la
lengua escrita y los sonidos de la lengua hablada. Para ello uno de esos métodos comienza por
el estudio de los signos o por el de los sonidos elementales, el otro método busca por el
contrario obtener el mismo resultado colocando de repente al niño frente a nuestro lenguaje
escrito. El primero es generalmente conocido con el nombre de método sintético. Esta
denominación responde a que una vez que aprendió las letras debe realizar la síntesis, es
decir la unión entre las letras para formar la sílaba y luego realizar la síntesis entre las sílabas.
El segundo método mencionado parte de los agrupamientos mismos, de las palabras. Se le
llama analítico haciendo referencia al proceso que se le exige al niño para aprender las
denominaciones de sus partes, las sílabas o letras.

1. Métodos de marcha sintética.

a. “Alfabético”, “de la letra”, “literal” o grafemático: parte de signos simples,

letras o grafemas.

b. “Fonético”: parte de los sonidos simples o fonemas. A veces parte también del
sonido más complejo de la sílaba.

2. Métodos de marcha analítica.

a. “Global analítico”: parte de signos escritos complejos, que pueden ser la

palabra, la frase o el cuento. El maestro dirige el análisis.

b. “Global”: parte de la palabra, la frase o el cuento. El maestro no debe dirigir el

análisis. En todo caso el niño debe llegar espontáneamente a él.
219
Los métodos de marcha sintética no tienen en cuenta la significación en el punto de partida y
no llegan necesariamente a ella.

Los métodos de marcha analítica parten siempre de la significación. No parten nunca del
elemento y en algunos casos como en el “global” puro tampoco deben llegar necesariamente
al elemento.

Braslavsky [2] nos menciona que “se puede creer con toda verosimilitud que el primer
método empleado espontáneamente para leer en el origen de la cultura humana fuera el
método global, ya que no se puede concebir otra manera de leer los jeroglíficos, primera
forma de escritura.”

220
6. Argumentos a favor del método global

6.1. El interés

El interés define una necesidad, que orienta la actividad hacia lo que puede satisfacerla. La
actividad que el niño despliega para satisfacer esa necesidad, el esfuerzo que realiza para
alcanzar su objeto, suscitan en el mismo un sentimiento de alegría y placer. Braslavsky [2]
explica que el esfuerzo por hacer interesante la lectura dio lugar a toda la historia de los
métodos, recorriendo cinco jalones principales: alfabético, fonético, método silábico y método
de las palabras normales que inicia la época de los métodos analíticos.

Los defensores del método global fueron quienes proclamaron el principio del interés para
rechazar el manejo de los símbolos abstractos, vacíos de sentido. Proponen que la visión de
los símbolos se transforme en representación de ideas, ya que solamente la representación
concreta de las ideas mediante las cosas o las figuras podría despertar el interés.

6.2. La globalización

Según Decroly [3] el niño percibe mejor la totalidad de la frase debido a la percepción
sincrética, una característica psicológica y cognitiva propia de estas edades, no ve las partes
del todo sino una visión de conjunto. Postula que la visión de conjunto precede al análisis en
el espíritu infantil. Si hacemos ver al niño la frase y la palabra antes que los fonemas,
seguiremos un orden natural de acuerdo a las características psico-evolutivas del niño.

6.3. La percepción visual significativa

“El hecho de adoptar la palabra o frase como unidad de partida favorece el proceso de
aprendizaje al estar el niño siempre expuesto a estímulos completos y significativos
maximizando la fuerza de la asociación entre el patrón gráfico (la palabra escrita) y la entrada
lexical en la mente del niño (representación fono-ortográfica) y más tarde semántica. El hecho
de presentar información parcial y fragmentaria (letras o sílabas aisladas) reduce el número de
estas oportunidades de aprendizaje. Los profesionales que trabajan con niños con dificultades
221
lectoras saben bien que en estos casos la exposición del niño a estímulos fragmentarios: letras
o sílabas, no ya resulta poco útil sino hasta contraproducente. El principio es aprovechar cada
experiencia lectora como una oportunidad de aprendizaje. Los estudios sobre los movimientos
oculares en la lectura avalan también esta posición. El registro de los movimientos oculares
en la lectura pone de manifiesto que las fijaciones oculares se centran sobre las palabras y
especialmente sobre las palabras de contenido con significado (80%) frente a las palabras
funcionales que reciben un número considerablemente inferior de fijaciones”. [1]

6.4. Afectividad

Otro aspecto importante a destacar en el método global-natural es el afectivo. Partiendo del

lenguaje propio del niño se establece una relación afectiva con la lectura y la escritura. De
esta forma, el lenguaje actúa como equilibrador de la personalidad ejerciendo a la vez una
función terapéutica.

222
7. Referencias bibliográficas

[1] OEA. Desarrollo Infantil Temprano. Aproximación histórico-conceptual a la metodología

de enseñanza de la lectura. [Online]. Disponible: www.oas.org/udse/dit/Mitodoslec_.doc

[2] Braslavsky, B. La querella de los métodos en la enseñanza de la lectura. Buenos Aires:

Kapeluz. 1962

[3] Decroly, O. Problemas de psicología y de pedagogía. Madrid: Morata. 1929.

223
Anexo 9 - Investigación sobre aplicación educativa

1. Objetivo del documento

Documentar la realización de una investigación educativa sobre videojuego educativo

enfocado en la lectura utilizando la metodología global.

2. Alcance del documento

El presente documento explica cómo surge la propuesta del videojuego y la técnica que
utiliza. Se exponen antecedentes de trabajos similares y se plantea una propuesta de
investigación con respecto al videojuego. Finalmente se exponen conclusiones parciales de
dicha investigación.

3. Introducción

El presente trabajo tiene su origen en la experiencia de trabajo de uno de los integrantes del
equipo, en la escuela especial de Montevideo Nº 206, donde se utilizaron metodologías
globales de lectura. (Ver Anexo 8 Metodología de lectura global). En la experiencia
mencionada se trabajó siguiendo lineamientos del método del Dr. Glenn Doman. Básicamente
se trata de mostrar al niño series tarjetas con palabras, escritas con letras grandes y que
correspondan a una misma categoría (por ejemplo: partes del cuerpo humano, colores,
animales…), de forma rápida, varias veces al día. Debe hacerse como si fuera un juego, y
recitar al niño cada palabra con entusiasmo, en voz alta y clara; poco a poco se irán añadiendo
nuevas categorías. En otras fases, y también escritas con letras grandes pero que van
disminuyendo algo de tamaño, se enseñan al niño tarjetas con dos palabras, frases cortas y
sencillas, frases un poco más largas y, finalmente cuentos que le resulten interesantes (una
sola oración en cada página y con el texto separado de las ilustraciones).

224
Nos interesó integrar aspectos de esta metodología de enseñanza de la lectura a un
videojuego. De esta forma estamos ampliando el uso de las herramientas tecnológicas en la
educación.
El Plan Flor de Ceibo 1989, el Proyecto INFED 2000 (Informática Educativa para el año
2000) y el Programa de Conectividad Educativa (PCE) proporcionaron importantes avances
en el área de la informática en la educación, pero sin llegar a toda la población educativa.
Posteriormente se creó el Plan Ceibal que comenzó a ejecutarse a mediados del 2007 con una
experiencia piloto en la escuela del poblado de Cardal, Florida, para luego continuar con el
resto del departamento y a posteriori en el resto del país. En el 2008, principio del 2009 se
completó a nivel Interior de la República y en el 2010, la totalidad de Montevideo y su Área
Metropolitana. Con este plan se logró la universalización del acceso a la informática
otorgando a cada niño de las escuelas públicas, una computadora.

Con los cambios que se presentaron, la informática en la educación pública ya no es una

materia aparte, sino que pasó a ser un área transversal empleándose como una herramienta
para impartir otras asignaturas.

En este marco de trabajo para promocionar el videojuego consideramos de fundamental

importancia investigar los resultados del videojuego en cuanto a su incidencia en el
aprendizaje de la lectura. Otro aspecto que nos interesa investigar es cómo responden los
niños de diferentes contextos escolares a una aplicación educativa implementada en tablets.

225
4. Definición del objetivo de la investigación

4.1. Objetivo general

Queremos estudiar los resultados del uso de una aplicación de tipo videojuego con
intervenciones didácticas en diferentes poblaciones educativas.

Evaluaremos la respuesta de los niños de diferentes contextos frente al videojuego en cuanto

a:

 Experiencias de uso del videojuego implementado en las tablets.

 Incidencia en el proceso de aprendizaje de lectura por el uso de la aplicación.

4.2. Objetivo específico

Dadas las limitaciones de tiempo, en la presente investigación se evaluarán aspectos referidos

a las experiencias de uso del videojuego.

Se dejará planteada la investigación para evaluar la incidencia en el aprendizaje de la lectura

de los niños al usar el videojuego.

4.3. Formulación del problema con términos operativos

Cuando hablamos de: “Experiencias de uso del videojuego implementado en las tablets”, nos
referimos a la facilidad con que logra interactuar con la aplicación. En este sentido importa
saber el tiempo en que demora en resolver las situaciones planteadas, si se adaptan bien a la
interfaz “Touch”, también interesa saber la aceptación que se logra con la presentación de
una intervención didáctica con el formato de videojuego.

La investigación se desarrollará en diferentes contextos, nos estamos refiriendo concretamente

a niños de escuela común y niños con discapacidad intelectual en escuela especial.
226
La forma de evaluar la incidencia en el proceso de aprendizaje de lectura se basará en el
reconocimiento de las palabras mostradas en el juego. Se realizará por medio de la aplicación
misma, en una actividad de asociación de palabras con imágenes. Esta evaluación debe
complementarse con una evaluación realizada por el docente, donde se solicitará a los niños el
reconocimiento de las palabras mencionadas.

227
5. Marco teórico

Como antecedentes que analicen el uso de la metodología global en Uruguay hemos relevado
el estudio comparativo de los métodos Analítico-Sintético y Global en el aprendizaje de la
lectura de la Profesora María Carbonell [1] y la experiencia de la Maestra Renée Behar [2] en
la escuela especial Nº 205 “Obra Morquio”.

5.1. Estudio comparativo de los métodos Analítico-Sintético y

Global

El estudio de la Prof. María Angélica Carbonell se llevó a cabo en doce escuelas públicas de
Montevideo, las cuales se seleccionaron en función de la excelencia de los maestros, el
método de enseñanza utilizado y el nivel socio-cultural de los alumnos.

Se evaluaron los resultados del aprendizaje a principios de agosto y en la última quincena de

noviembre. Al año siguiente se aplicaron pruebas de lectura, dictado, copia y redacción. Se
obtuvieron las siguientes conclusiones:

- Luego de un segundo año de entrenamiento escolar, los alumnos que aprendieron a leer por
el método global se emparejaron con los otros, por tanto, los alumnos que aprendieron a leer
por este método hacen un muy marcado progreso durante el segundo año lectivo.

- En materia de ortografía se mantiene una ligera ventaja a favor del método analítico.

- Los alumnos que aprendieron a leer por el método global han conseguido una mejor
ortografía en la copia.

Esta última afirmación da cuenta de los avances realizados en los niños que usaron el método
global, en cuanto a la memorización de la palabra asociada a su imagen como un conjunto de
letras que tiene una forma particular, la cual logran copiar con menos errores que el grupo de
alumnos que no utilizó el método global.

228
Estas habilidades favorecen dos importantes procesos mentales que según Renée Behar se
ponen en juego en la lectura:

- la memoria, “que durante varios años fue desvalorizada y dejada de lado frente a la
tremenda importancia y jerarquía que se le daba a la capacidad de razonar, como si pensar y
recordar fueran funciones contradictorias”.

- la capacidad de anticipar, “que resulta del análisis del contexto y permite encontrar sentido
a las palabras que vendrán”. [2] Página 27.

5.2. Experiencia en la escuela especial Nº 205 “Obra Morquio”.

En la publicación de Renée Behar “La hora de aprender a leer” se expone una investigación
realizada en la Escuela Especial Nº 205 “Obra Morquio” y un proyecto realizado en un Jardín
de Infantes privado. [2] Páginas 58-82.

En la escuela especial se trabajó con una muestra de niños, muy heterogénea respecto a
edades cronológicas, mentales y tipos de síndromes. Pero todos tenían un elemento común
pertenecían a los niveles de funcionamiento más bajos. El método usado consiste en presentar
al niño series de palabras escritas en letras de imprenta minúscula con tinta roja sobre la
cartulina blanca, sin imágenes. El tamaño de los carteles y el color de la tinta empleada se
modifican a medida que se avanza en el aprendizaje. En las conclusiones se expresa que:

- “Un alto porcentaje de los niños con bajo nivel de funcionamiento, si se les enseña logran
aprender a leer”;

- “Este método es de gran utilidad en los alumnos que han fracasado por métodos
tradicionales”. [2] Páginas 71-72.

En el proyecto desarrollado en el jardín, se trabaja con niños a partir de los 2 años, en una
propuesta totalmente apartada de la metodología tradicional. Por el contrario se emplea un
método sencillo, vinculado a lo lúdico y basado en la capacidad para imitar y memorizar que
tiene el preescolar. Luego de varios años de labor se pudo constatar que: “egresan del Jardín

229
alrededor de un 78% de lectores. Del 22% restante un 10% termina su proceso de
aprendizaje de la lectura durante las vacaciones y en forma espontánea y al comenzar el 1er.
año escolar. El 12% restante de los niños tuvieron alguna de las siguientes causas en el
fracaso: mala asistencia al jardín, ingreso tardío, dificultades globales o dificultades
específicas de aprendizaje”. [2] Páginas 59.

5.3. Nuestra propuesta

Basándonos en estas experiencias pensamos que la aplicación de la metodología global de

lectura mediante el videojuego en forma complementaria a otras formas de aprendizaje que
usa el docente, favorece la formación de lectores potenciando las habilidades que le
permitirán realizar un proceso de lectura más eficiente.

Pensamos que el videojuego es una herramienta muy eficaz a la hora de usar un mediador
para impartir cualquier aprendizaje ya que el entusiasmo que genera, si el juego está bien
realizado permite la intervención frecuente y atenta.

230
6. Proposición de hipótesis

A- ¿Cuáles son las características de las experiencias de uso del videojuego

implementado en las tablets, en niños de diferentes contextos?

B- ¿El uso del videojuego que tiene intervenciones didácticas usando la metodología
global de lectura, incide en el aprendizaje de los niños?

231
7. Procedimiento de muestreo

Para llevar a cabo la investigación se utilizará una metodología mixta que combina técnicas
cualitativas y cuantitativas. Consideramos que ambas técnicas son complementarias, no
excluyentes. Los dispositivos que se enumeran a continuación serán detallados más adelante
en este mismo capítulo.

- Se aplicarán entrevistas semi-estructuradas a las docentes.

- Se realizarán observaciones directas durante la utilización del videojuego.

- Se obtendrán datos provenientes de la aplicación.

Al desarrollar la investigación se debe repetir la observación para evitar la alta probabilidad

de error que se tendría si se realizara una sola observación. Para llegar al tamaño de la
muestra se siguieron los lineamientos de F. Pardiñas [3].

7.1. Tamaño de la muestra:

Para conformar la unidad de muestreo se releva información de la cantidad de niños que viven
en el Uruguay usando la publicación del Instituto Nacional de Estadística denominada
Uruguay en Cifras [4]. Se obtienen los siguientes datos:

220.345 niños de 0 a 4 años

238.068 niños de 5 a 9 años

Como el público objetivo del videojuego comprende las edades de 4 a 7 años realizamos un
prorrateo de las cifras anteriores para obtener el rango que necesitamos:

220.345 / 5 = 44069 de 5 años

238.068 / 5 * 3 = 142840,8 de 5 a 7 años

232
 Total 186.910 de niños

La fórmula para el cálculo del tamaño de la muestra es la siguiente:

Dónde:
n = Tamaño de la muestra.

N = Tamaño de la población.

Desviación estándar de la población que, generalmente cuando no se tiene su valor, suele

utilizarse un valor constante de 0,5.

Z = Valor obtenido mediante niveles de confianza. Es un valor constante que, si no se tiene su

valor, se lo toma en relación al 95% de confianza equivale a 1,96 (como más usual) o en
relación al 99% de confianza equivale 2,58, valor que queda a criterio del investigador.

e = Límite aceptable del error de la muestra que, generalmente cuando no se tiene su valor,
suele utilizarse un valor que varía entre el 1% (0,01) y 9% (0,09), valor que queda a criterio
del encuestador.

233
Realizamos los cálculos en base al tamaño de nuestra población y para ambos valores
extremos del límite aceptable de error:

e = 0,01
186910 * (0,5)2 *1,962 = 179508,364 / 1795,074036 = 100.000535
(186910 -1)*(0,01)2 + (0,5)2 *1,962

e= 0,09
186910 * (0,5)2 *1,962 _= 179508,364/ 16822,7704 = 10.67055
(186910 -1)*(0,09)2 + (0,5)2 *1,962

Dados los recursos de tiempo para desarrollar la investigación vemos que es posible superar el
valor mínimo para el límite aceptable de error, para el cual sería necesaria una muestra de 10
niños. Resolvemos ampliar esta cantidad a 30 niños como base.

7.2. Procedimiento para el relevamiento de datos

Se visitarán clases que representen los diferentes contextos que se quieren estudiar:

- Clase de escuela común o jardín de infantes.

- Clase de escuela especial.

7.2.1. Hipótesis A

Se concurre a las diferentes instituciones educativas para invitar a los niños a usar el juego y
relevar datos sobre el primer acercamiento al mismo. Se explica a los niños que hemos
preparado un juego para ellos y queremos saber si les gusta. Se proporcionan tablets en forma
individual.

234
 7.2.1.1. Datos generados por el videojuego

Al inicio del juego se invita a los niños a configurar los datos personales incluyendo: un
apodo, un color, el género y la edad. Por intermedio de la aplicación se obtendrán éstos datos
y otros referidos al tiempo y la forma en que usan el videojuego. Se registran datos sobre la
navegación que realizan los niños registrando el tiempo que permanecen en las distintas
pantallas. Con esta información podremos tener una idea del tiempo que les toma resolver la
situación que se presenta en cada pantalla para los niños de cada contexto estudiado.

Los datos son grabados en formato XML. La estructura del documento XML puede verse en
el Anexo A. Se interpretará la información obtenida con la herramienta QlikView, en el
capítulo 8 se explican las razones que fundamentaron la elección de esta herramienta.

7.2.1.2. Observación directa

Por otra parte se realiza una observación directa en la cual registramos nuestra percepción
sobre las experiencias de juego de los niños, se focalizarán los siguientes aspectos:

- Ver el grado de dificultad que representan los juegos para los niños, si los pueden
resolver con facilidad o no.

- Expresiones sobre el juego que denoten diferentes experiencias: si es fácil o difícil, si

es entretenido o aburrido, otras observaciones.

- Entusiasmo por jugar otra vez.

7.2.1.3. Encuesta a docentes

También se solicitará a las docentes de los grupos donde se realizarán las pruebas, que
respondan una encuesta donde relevamos los aspectos antes mencionados y su opinión desde
el punto de vista didáctico. A continuación se muestran las preguntas formuladas:

235
¿Los niños demostraron interés en volver a jugar?

1. Si
2. No
3. No lo sabe.

¿Cómo perciben que se sintieron los niños con la propuesta del videojuego?

1. Indiferentes (No prestaron mucho interés en el videojuego).

2. Frustrados (Por no poder resolver el videojuego).
3. Interesados (Mostrando interés en el videojuego).
4. Entusiasmados (Mostrando mucho interés en jugar otra vez).
5. Divertidos (Expresando alegría de haber jugado).

Luego al volver a la clase los comentarios realizados se refirieron a…

1. La tablet.
2. El videojuego en general.
3. Las palabras.
4. La música del juego.
5. Los premios.
6. El juego del castillo.
7. El juego de las naves.
8. Los datos ingresados.
9. No comentaron el videojuego.

¿La usarían como herramienta didáctica?

1. Si.
2. No.

236
¿Qué desventajas le viste?

¿Qué mejoras se le pueden hacer?

¿Qué características del videojuego fueron acertadas?

7.2.2. Hipótesis B

Para relevar datos que permitan investigar esta hipótesis se trabajará con la misma muestra de
la población calculada o una cantidad mayor.

7.2.2.1. Trabajo de campo

Se tomarán dos grupos de cada contexto a estudiar: un grupo que se dejará como testigo y en
el otro grupo se realizará la propuesta de juego con las tablets.
La extensión temporal de la investigación debe permitir evaluar la incidencia en el
aprendizaje de lectura por parte de los niños. Para determinar la duración tomamos como
referencia el trabajo de investigación de R. Behar antes mencionado el cual se inicia en mayo
y termina al finalizar el año lectivo en donde la propuesta de intervención con la metodología
global de lectura se realiza en forma diaria. Behar (1997) Página 70. Proponemos una
duración similar para la desarrollar la investigación ofreciéndoles el juego a los niños todos
los días.

7.2.2.2. Evaluación de aprendizajes

Una vez finalizado el experimento se procederá a recabar información sobre los aprendizajes
construidos por ambos grupos. Para ello se solicitará a las docentes del grupo la realización de
una evaluación donde se solicita a los niños el reconocimiento de palabras. Se emplearán
palabras mostradas en la aplicación y otras que no fueron mostradas. Se proporciona planilla
para registrar la información recabada. Ver soporte digital el documento:
“planilla_evaluacion.xlsx”

237
 7.2.2.3. Datos provenientes de la aplicación

Además de esta información se usarán datos generados por la aplicación obtenidos en la

pantalla de “Evaluación” Ver Anexo Game Design Concept Página 19. En esta pantalla se
proponen una lista de palabras que deben asociarse con el ícono correspondiente. Se registran
las palabras que se asociaron a su imagen en forma correcta y en forma errónea. Estos datos
se podrán evaluar en forma histórica, ya que se generarán durante todo el experimento a
medida que en niño juega.

Los datos son grabados en formato XML. La estructura del documento XML puede verse en
el Anexo A. Se interpretará la información obtenida con la herramienta QlikView, en el
capítulo 8 se explican las razones que fundamentaron la elección de esta herramienta.

7.2.2.4. Encuesta a Docentes

Los datos anteriores se complementarán con otro relevamiento que usa técnicas cualitativas,
se realizarán entrevistas a los docentes de los grupos que usaron el videojuego interrogando
sobre la utilidad del mismo:

1- ¿Cuál fue el grado de dificultad al usar el videojuego?

a. Muy difícil.
b. Algo difícil.
c. Adecuado.
d. Muy fácil.

2- ¿Qué dificultades encontró a la hora de integrar el videojuego a las actividades de la

clase?

238
3- ¿Los niños se mostraron interesados en jugar?

a. No demostraron interés por el juego o demostraron poco interés.

b. Estuvieron interesados.
c. Demostraron mucho interés y entusiasmo.

4- ¿Durante cuánto tiempo permaneció el interés en el juego?

a. Una semana.
b. Un mes.
c. Dos meses.
d. Varios meses.
e. Durante todo el experimento.

5- ¿Considera que el uso del videojuego incidió positivamente en el aprendizaje de los

niños?

a. No incidió en absoluto.
b. Tuvo una incidencia muy leve.
c. Incidió positivamente en algunos alumnos.
d. Tuvo una incidencia importante para muchos alumnos.

6- ¿Qué aspectos del videojuego cambiaría?

7- ¿Qué aspectos considera acertados para una aplicación educativa?

239
8. Fundamentación de la elección de la herramienta para el
análisis de la información

Durante años las organizaciones se han centrado en la automatización de los procesos

empresariales y la implementación de tecnologías tradicionales de Business Intelligence (BI)
a fin de poder recuperar y transmitir los datos que se hallan ocultos en los sistemas
operacionales subyacentes a las empresas.

Pero la industria de la Inteligencia de Negocio o Business Intelligence (BI) está

experimentando un cambio fundamental gracias a unas cuantas organizaciones visionarias que
han sabido conjugar el análisis en memoria, que ha supuesto el mayor avance, con una buena
capacidad de análisis, que aporta simplicidad, flexibilidad y escalabilidad a implementaciones
BI a gran escala dentro de la empresa, dando como resultado un despliegue más rápido de
soluciones altamente escalables a un precio mucho más bajo en relación al coste que
ostentaban las anteriores soluciones BI.

QlikView [5] es el producto líder en cuanto a análisis en memoria y la plataforma BI que

observa un mayor crecimiento a nivel mundial. QlikView está liderando un nuevo tipo de
soluciones de Análisis Empresarial rápidas y flexibles, de fácil manejo, que permiten a los
individuos mejorar el rendimiento empresarial y aportar innovación. QlikView emplea
tecnología asociativa patentada de última generación para un análisis y una cobertura
sofisticados, considerablemente mucho más fáciles de implementar, mantener y utilizar.

QlikView simplifica la implementación de un análisis potente. QlikView aprovecha

plenamente la funcionalidad de las plataformas multinúcleo de 64 bits, permitiendo a miles de
usuarios el acceso a billones de registros de datos. El modelo de datos en memoria de
QlikView permite una visión integrada de la información a través de cuadros de mando,
análisis in situ e informes, todo ello desde una única plataforma.

240
 8.1. Análisis e Informes en memoria aportan simplicidad y un
mejor rendimiento

Con un modelo de datos residente en memoria, QlikView permite que los datos se analicen
tanto a un nivel de agregación como a un nivel más detallado, sin el consumo de tiempo y el
coste habitual que supone la construcción de cubos OLAP multidimensionales. Además, las
asociaciones entre los datos se relacionan de manera automática en QlikView, respondiendo
al instante a las selecciones efectuadas por el usuario. Como los datos se guardan en memoria,
los tiempos de respuesta de cualquiera de los cálculos se realizan de manera instantánea,
incluso con conjuntos de datos extremadamente amplios, analizados por múltiples usuarios
concurrentes.

8.2. Arquitectura única para cuadros de mando, análisis e

informes

QlikView se define en primer lugar por su simplicidad. Suministra todas las herramientas BI
tradicionales en una única arquitectura. QlikView posee funciones ETL para extraer,
transformar y cargar datos procedentes de una o diversas fuentes combinadas (datos de ERP,
de texto, de Excel, de XML, etc.). El desarrollo en QlikView se ve facilitado por la inclusión
de asistentes, muy ricos en funcionalidad. QlikView va guiado mediante simples clics de
ratón y suministra las capacidades de visualización tecnológicamente más avanzadas,
haciendo uso de indicadores al estilo de cuadros de mando, gráficos y tablas. Con QlikView
los usuarios encuentran rápidamente la información que buscan, teniéndola a su disposición y
pudiendo compartirla con otros colegas a través de las capacidades integradas de informes,
impresión, o la plena integración con Microsoft Office.

8.3. Flexibilidad en el análisis

QlikView da cabida a miles de dimensiones, y cualquier valor, de cualquier dimensión o

medida, puede ser el punto de partida para un nuevo análisis. Las modificaciones a las
dimensiones o medidas de la aplicación se realizan en segundos, lo cual facilita la provisión
de respuestas rápidas a unas necesidades BI cambiantes dentro de una organización. Los
241
usuarios finales se benefician de la libertad de no estar atrapados en estructuras jerárquicas
precalculadas, ya que todos los datos residen en memoria y los cálculos se realizan en el
momento en que se solicitan y no antes. Al no tener que agregarse los datos, los usuarios
pueden analizar el volumen completo de datos al nivel de transacción que deseen.

8.4. Rápida implementación

La plataforma QlikView se integra sin fisuras en la infraestructura existente de una

organización, convirtiendo a QlikView en una herramienta extremadamente rápida de
implementar. Las implementaciones se pueden realizar en semanas y los usuarios pueden
estar formados en cuestión de minutos. QlikView se adapta a las necesidades técnicas de la
organización. El análisis más sofisticado se vuelve sencillo gracias a las técnicas web más
avanzadas que suministran la interactividad, flexibilidad y velocidad

242
9. Datos obtenidos

Para la realización de las pruebas se visitaron dos instituciones privadas, una perteneciente al
contexto de educación común y otra al contexto de educación especial. En la primera se
trabajó con tres grupos de educación inicial nivel 5, realizando pruebas con 50 niños
aproximadamente. En la segunda se trabajo con niños de diversas edades entre 7 y 12 años,
realizando pruebas con 20 niños aproximadamente.

En las pruebas realizadas se usaron 4 tablets con pantalla de 7 pulgadas. Dos de marca
Samsung y otras dos de marca Aoc.

9.1. Observación directa

A continuación se presentarán los aspectos en los cuales se enfocó la observación y la

información relevada sobre el mismo.

 Ver el grado de dificultad que representan los juegos para los niños, si los pueden
resolver con facilidad o no.

En general la mayoría de los niños provenientes de ambos contextos resolvieron bien todas las
pantallas (configuración de datos, menú principal, juego de naves, juego del castillo,
evaluación) luego de que se les explicó una vez el funcionamiento. En ocasiones hubo que
enseñar la tecla de retroceso del aparato para volver al menú principal.

 Expresiones sobre el juego que denoten diferentes experiencias: si es fácil o difícil, si

es entretenido o aburrido, otras observaciones.

El grado de dificultad se percibió entre fácil y adecuado, se escucharon algunos comentarios

como “es re-papa” y se observó que todos los niños pudieron terminar varias partidas de
ambos juegos, llegando incluso a la pantalla de evaluación.
 Entusiasmo por jugar otra vez.

243
Se percibió en esta primer instancia de juego que los niños estuvieron muy entusiasmados.
Para que dejaran de jugar había que pedirles si podían prestar el juego a otro compañero. Se
escucharon comentarios como “¿Me puedo llevar la tablet?”.

9.2. Encuesta a docentes

Pudimos constatar según la encuesta a las docentes que todos los niños querían volver a jugar
mostrando actitudes de interés (25%), entusiasmo (42%) y diversión (33%) al probar el juego.

Los temas que más comentaron los niños relativos a la experiencia de juego fueron: la tablet,
el videojuego en general, los premios, el juego del castillo y el juego del laberinto. No
comentaron sobre las palabras vistas en el juego, la música y los datos ingresados.

Todas las maestras consultadas la usarían como herramienta didáctica.

Al consultar las desventajas observadas se registraron las siguientes:

 Los dibujos a veces son confusos

 Debería implementarse en otros equipos por ejemplo XO

 Está inconcluso faltan completar los niveles

 El color de las palabras debería ser negro o azul

 Fallas de sonido

A continuación se muestra en forma resumida las mejoras propuestas por las docentes:

 Más juegos que se puedan resolver en clase usando las palabras

 Agregar puntaje a los juegos

 Que se vea todo el animal, usar fotos

244
  Usar las frases

Las principales características del videojuego que consideraron acertadas fueron:

 El tipo de juego: los contextos de naves y castillo fue un éxito

 Las palabras

 Plantear el juego con distintos niveles en el que los niños tienen que acceder según los logros
obtenidos

 Es interesante pues se trata de un tipo de competencia no frente a otros, sino frente a sí

mismos. Es un desafío para el logro de premios

 Los gráficos del juego

El resumen de las respuestas obtenidas en la encuesta puede verse en el siguiente link:

https://docs.google.com/forms/d/1EE13sO5_R0Jn51zO3vSqVbdFWu3ERgr5OOAMGgLoX
EQ/viewanalytics

245
 9.3. Datos provenientes de la aplicación

9.3.1. Cantidad total por género

Figura 1. Cantidad total por género. Contexto: niños de escuela común.

Figura 2. Cantidad total por género. Contexto: niños de escuela especial.

Participaron de la prueba tanto niñas como varones en ambas instituciones, habiendo más
niñas en el contexto especial y más varones en el contexto de escuela común.

246
 9.3.2. Duración promedio por género

Figura 3. Duración promedio por género. Contexto: niños de escuela común.

Figura 4. Duración promedio por género. Contexto: niños de escuela especial

En general las niñas jugaron menos tiempo que los varones en ambos contextos. El tiempo de
atención al juego fue levemente menor en niños de escuela especial.

247
 9.3.3. Duración por pantalla

Figura 5. Duración por pantalla. Contexto: niños de escuela común.

Figura 6. Duración por pantalla. Contexto: niños de escuela especial.

La pantalla Evaluación es la que muestra mayores diferencias en la cual los niños de contexto
especial tomaron más tiempo para resolverla.

248
 9.3.4. Duración por juego

Figura 7. Duración por juego. Contexto: niños de escuela común.

Figura 8. Duración por juego. Contexto: niños de escuela especial.

Con respecto a los juegos de Laberinto (Maze) y Naves (Ship) los niños de contexto especial
demoraron menos. Hay que tener en cuenta que la duración total de los niños de contexto
común fue mayor, llegando a niveles de mayor dificultad y de mayor tiempo de resolución.

249
10. Conclusiones

Se observaron diferencias en la aplicación del videojuego en ambos contextos:

 El tiempo de atención al juego fue levemente más breve en niños de escuela especial

 Los niños de contexto especial necesitaron mayor tiempo para resolver la propuesta de
evaluación.

 No hubo diferencias significativas en los tiempos de resolución de los juegos

Laberinto y Naves.

Las maestras consideraron al videojuego como una herramienta válida para usar en su labor y
realizaron aportes para mejorar la propuesta realizada.

Se pudo constatar que el video juego es una propuesta viable para aplicar en las escuelas ya
que se aplicó en forma satisfactoria en ambos contextos.

250
11. Referencias bibliográficas

[1] Carbonell M., Tuana E. y Behar R., Estudio comparativo de los métodos analítico-
sintético y global en el aprendizaje de la lectura. Montevideo: Sociedad de Dislexia del
Uruguay. 1967.

[2] Behar, R. La hora de aprender a leer. Montevideo: Ediciones Rosgal. 1997.

[3] Pardiñas, F. Metodología y técnicas de investigación en Ciencias Sociales. Buenos Aires:

Siglo XXI. 1993.

[4] Instituto Nacional de Estadística. Uruguay en Cifras. (2012). [Online]. Disponible:

http://www.ine.gub.uy/biblioteca/uruguayencifras2012/cap%C3%ADtulos/Poblaci%C3%B3n
.pdf

[5] QlikView. Informes y Análisis en Memoria" [Online] Disponible:

http://www.mgssoft.com/MGS-Business-Intelligence-Cuadro-de-mando-QlikView.asp

251
12. Anexos

12.1. Documentos XML

Para relevar los datos de la aplicación se utilizan dos tipos de documentos:

 History: registra datos del niño, y datos de la navegación que realiza el jugador desde
que ingresa al juego hasta que finaliza en la pantalla de despedida, registrando el
tiempo que permanece en cada pantalla y las palabras mostradas en la intervención
didáctica y en la pantalla evaluación asociadas en forma correcta o errónea.

 Play: registra la partida de juego incluyendo datos de: palabra mostrada, nivel,
dificultad, categoría

A continuación se muestran ejemplos de estos documentos a fin de mostrar la estructura de

los documentos mencionados.

252
12.1.1. History

253
12.1.2. Play

254
Anexo 10 - Gráficos y figuras

1. Bosquejo de Story Board

255
2. Componentes necesarios para el desarrollo

3. Despliegue de la aplicación

256
4. Estadísticas de la aplicación

Cantidad por Género – Escuela común – Escuela especial

Duración promedio por Género – Escuela común – Escuela especial

257
Niños de escuela común

Niños de escuela especial

258
5. Esfuerzo por tipo de tarea

6. Avance del producto

259
7. Tiempo de carga

260