Capitulo 4: Pruebas Funcionales y de Campo

En el capítulo 2 se establece que el modelo de desarrollo e ingeniería de software que

este proyecto sigue es el Modelo Lineal Secuencial, complementado por la metodología
ISE (Ingeniería de Software Educativo) de Galvis. Ambos ciclos de trabajo establecen
un periodo de pruebas en el cual se pone en tela de juicio la funcionalidad global de un
sistema de software.

La prueba del software es un elemento crítico para la garantía de calidad del software y
representa una revisión final de las especificaciones, del diseño, y de la codificación de
los elementos que juntos componen la aplicación computacional.

En este capítulo se discuten las generalidades del proceso de pruebas que se incluye en
el ciclo de vida de un proyecto de software, así como las pruebas especificas bajo las
cuales se prueba la herramienta de software basada en ambientes virtuales que pretende
ser utilizada como auxiliar en el tratamiento del trastorno de lateralidad y ubicación
espacial.

1.1. Pruebas del Software

De acuerdo con Deutsch, el desarrollo de sistemas de software implica una serie de

actividades de producción en las que las posibilidades de que aparezca el fallo humano
son enormes. Los errores pueden empezar a darse desde el primer momento del proceso,
en el que los objetivos pueden estar especificados de forma errónea o imperfecta.
Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el
desarrollo de software ha de ir acompañado de una actividad que garantice la calidad
[DEU79].

De acuerdo con Pressman [PRR98], a nivel general la etapa de pruebas del software
consiste en que el ingeniero de software crea una serie de casos de prueba que pretenden
“demoler” el software construido. De hecho, la prueba es uno de los pasos de la
ingeniería del software que se puede ver como destructivo en lugar de constructivo.
Myers [MYE79] establece tres normas que en un momento dado pueden servir
atinadamente como objetivos de la prueba:

1. La prueba es un proceso de ejecución de un programa con la intención de

descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un
error no descubierto hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Es importante recalcar que de acuerdo a los tres objetivos anteriores, una prueba tiene
éxito no cuando no descubre errores, sino cuando lo hace. El objetivo de un esquema de
pruebas es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de
errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. Si la prueba se lleva a
cabo con éxito, descubrirá errores en el software; la prueba demuestra hasta que punto
las funciones del software parecen funcionar de acuerdo con las especificaciones y
parecen alcanzarse los requisitos de rendimiento [PRR98].

Los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan
una buena indicación de la fiabilidad del software y, de alguna manera, indican la
calidad del software como un todo. Sin embargo, y citando a Pressman, hay una cosa
fundamental que una prueba no puede hacer:

“La prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que
existen defectos en el software.”

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, se deben

entender los principios básicos que guían las pruebas del software. De acuerdo con
Davis [DAV95] hay una serie de principios fundamentales de prueba. A continuación se
enlistan algunos de estos principios, pero por fines prácticos solo se elabora en aquellos
principios que se aplican al esquema de pruebas que se sigue para probar la aplicación
de software basada en ambientes virtuales que este proyecto propone. Los principios de
Davis son los siguientes:
 • A todas las pruebas se les debe poder hacer un seguimiento hasta los
requisitos del cliente. En el caso del proyecto propuesto por este estudio, la
herramienta de software que pretende desarrollarse esta completamente
aterrizada a un universo de aplicación muy específico, y es por esto que una
parte sumamente importante del desarrollo de esta herramienta es estructurarla
en base a los requerimientos funcionales y no funcionales que se obtienen a
través de la colaboración y discusión con los usuarios finales. Como ya se
mencionó anteriormente, este estudio cuenta con la participación de un terapeuta
que proporciona estos requerimientos. Los requerimientos que fueron
establecidos ya fueron previamente discutidos en el capítulo 2. Entonces, es
importante realizar pruebas basadas en la lista de requerimientos con el fin de
comprobar que la herramienta de software realmente satisface las
especificaciones.
• Las pruebas deben planificarse antes de realizarse. La planificación de las
pruebas puede empezarse tan pronto como esté completo el modelo de
requerimientos. Desde el punto de vista de este proyecto, desde la parte de
análisis y diseño se puede inferir que es necesario realizar pruebas tanto
funcionales como de campo. Las pruebas funcionales pueden planearse en base a
la premisa de desarrollo (ver sección 3.1.3.2), es decir, verificar el modelado de
los mundos virtuales en VRML 2.0, probar las funcionalidad de los scripts de
comportamiento programados ya sea en Java o JavaScript, y probar que las
interfaces que se proponen puedan ser presentadas eficientemente a través de la
plataforma del Web. Las pruebas de campo se realizan probando prototipos de la
herramienta de software con grupos formados por los identificados como
usuarios finales para obtener retroalimentación, y donde sea necesario, realizar
correcciones y mejoras a la herramienta de software basada en ambientes
virtuales.

Más adelante dentro de este capítulo se discuten más a detalle los procesos de pruebas
funcionales y de campo que llevaron a cabo dentro de este proyecto.

1.1.1. Facilidad de prueba

Es importante que cuando se desarrolla o diseña un sistema de software se tenga en
cuenta lo fácil o difícil que será probar el sistema. La facilidad de prueba del software es
simplemente lo fácil que se puede probar un programa de computadora [PRR98].

En el caso de la herramienta computacional basada en ambientes virtuales que se

desarrolla en el proyecto Realidad Virtual Aplicada al Tratamiento del Trastorno de
Lateralidad y Ubicación Espacial, las pruebas pueden realizarse fácilmente en base a los
tres siguientes aspectos propuestos por Pressman [PRR98]:

• Observabilidad. Lo que se ve, es lo que se prueba. En el caso de ambientes

virtuales, pueden probarse las rutas de animación de ciertos objetos, los estados
y transiciones de estados que pueden manifestarse dentro de los ambientes, si
todos los factores que afectan un estado o resultado están visibles, y si un
resultado incorrecto se identifica fácilmente.
• Controlabilidad. ¿Qué tan bien puede un usuario interactuar con el software?
En vista de que los ambientes virtuales son sensibles a las acciones de los
usuarios, es importante que los usuarios sean capaces de generar acciones
fácilmente dentro de los mundos, y sin tener que operar una interfaz complicada.
Puede probarse a través de las pruebas de campo la reacción de los usuarios
finales con respecto a su desempeño dentro de los ambientes virtuales.
• Capacidad de descomposición. Se refiere a la modularidad de la herramienta
de software. Como ya se mencionó anteriormente en el capítulo 3, a través del
nodo Inline de la especificación de VRML 2.0, pueden modelarse los
componentes por separado y luego invocarse desde un ambiente virtual que
puede funcionar como contenedor. Si el sistema de software está construido por
módulos independientes, entonces cada módulo puede modificarse y probarse
independientemente, y de esta manera se reduce la complejidad de las pruebas al
sistema completo.

1.2. Pruebas Funcionales

Dentro del campo de estudio de la Ingeniería de Software, se sugieren diversas
metodologías de prueba que pueden incorporarse el ciclo de vida de un proyecto de
desarrollo computacional.

De acuerdo con Pressman, las pruebas funcionales pueden realizare en base a 2

enfoques principales [PRR98]:

• Prueba de caja blanca

• Prueba de caja negra

La prueba de caja blanca del software se basa en el minucioso examen de los detalles
procedimentales. Se comprueban los caminos lógicos del software proponiendo casos
de prueba que ejerciten conjuntos específicos de condiciones. Se puede examinar el
estado del programa en varios puntos para determinar si el estado real coincide con el
estado deseado o esperado. La prueba de caja blanca es un método de diseño de casos
de prueba que usa la estructura de control del diseño procedimental para obtener los
casos de prueba [PRR98].

Las pruebas de caja negra se centran en los requisitos funcionales del software, es
decir, la prueba de caja negra permite obtener conjuntos de condiciones de entrada que
ejerciten completamente todos los requisitos funcionales de un programa. La prueba de
caja negra intenta encontrar errores de las siguientes categorías [PRR98]:

• Funciones incorrectas o ausentes

• Errores de interfaz
• Errores en estructuras de datos
• Errores de rendimiento
• Errores de inicialización y de terminación

A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso

de prueba, las pruebas de caja negra tienden a aplicarse durante fases posteriores del
proceso de pruebas.
Dentro de este proyecto, los scripts que se programan para añadir comportamiento a los
ambientes virtuales, realizan acciones muy directas y especificas que no generan árboles
de decisión o un gran número de caminos lógicos posibles. El código se programa y
compila con el fin de efectuar alguna animación o algún comportamiento que se aplica
posteriormente a algún objeto localizado dentro del ambiente virtual. Debido a que las
acciones son directas, y la computadora no tiene que generar varios estados de
transición para ejecutar un script, puede decirse que las pruebas funcionales que se
realizan dentro de este estudio no se requiere, estrictamente hablando, que sean pruebas
complejas de caja blanca. Las pruebas caen sobre la clasificación de pruebas de caja
negra dado que este tipo de pruebas se basan completamente en los requerimientos del
sistema y, en vista de que este proyecto propone una herramienta computacional de
aplicación, se debe tener completa certeza de que los requerimientos se satisfacen.

Tal y como se estableció previamente, las pruebas que conciernen a los aspectos
funcionales de una herramienta de software basada en ambientes virtuales que puede
utilizarse como auxiliar al tratamiento de lateralidad y ubicación espacial, pueden
hacerse basadas en cuanto a la premisa de desarrollo que este proyecto propone.

1.2.1. Pruebas al Modelado de Ambientes Virtuales

Este proyecto utiliza VRML 2.0 para modelar objetos tridimensionales que se juntan
para formar ambientes virtuales. Desde un punto de vista gráfico, VRML es un
lenguaje de programación cuya función principal es la de proporcionar a un VRML
browser los detalles descriptivos, del estado y comportamiento, de un objeto.

Es solamente lógico que las pruebas a los aspectos referentes al modelado de objetos y
mundos virtuales en VRML 2.0 se hagan durante el mismo proceso de desarrollo, es
decir, se describe un objeto, y se ve su resultado en el VRML browser. Si la apariencia
o comportamiento del objeto no es el esperado, entonces se presenta un error que puede
corregirse inmediatamente. Por medio de repetir este procedimiento se obtiene un ciclo
constante de pruebas en el cual se llega al resultado esperado a través de codificación
inicial, pruebas, y codificación correctiva.
En párrafos anteriores se comentó que la facilidad con la que puede probarse un sistema
o aplicación de software es un aspecto muy importante que no debe pasarse por alto al
momento de llevar a cabo las actividades de diseño del mismo. Es precisamente en la
etapa de pruebas al modelado y descripción de objetos tridimensionales que se
manifiestan los beneficios de programar modularmente y por separado los objetos, ya
que de esta manera se pueden probar independientemente para que, una vez obtenido el
resultado deseado, puedan incluirse o incorporarse a otros objetos para construir un
mundo o escena virtual completo.

1.2.2. Pruebas a los Scripts de Comportamiento

El codificar un program script para VRML en algún lenguaje de programación de alto

nivel implica que pueden generarse errores en la codificación del script, en el
funcionamiento del script, y en la creación de circuitos (routing).

Los errores en la codificación del script pueden detectarse a través del compilador que
se utiliza para traducir las instrucciones que el programador emplea por medio de un
lenguaje de alto nivel, a lenguaje máquina. Las pruebas en esta etapa del desarrollado de
un program script se hacen durante la codificación del mismo, ya que se compila una y
otra vez hasta que no se presenten errores en la traducción al lenguaje que entiende la
computadora. Es importante decir que el compilar exitosamente no quiere decir que no
existen errores en el script, sino que simplemente se ha podido hacer una interpretación
exitosa.
Cuando se programa un script en Java, por ejemplo, los errores de código los detecta el
compilador que se utilice para convertir los archivos *.java a archivos *.class. En el
caso de que se esté utilizando JavaScript para codificar un program script, entonces los
errores de código los detectará el VRML browser, y los reportará al programador a
través de la consola de comunicación con el usuario.

La funcionalidad de un program script puede probarse comparando el resultado que

realmente se obtiene de aplicar el script a un objeto, con el resultado esperado. Si existe
una diferencia entre el resultado real, y el resultado esperado, entonces existe un error
de funcionalidad. En caso de existir un error, entonces es necesario ajustar el script y
probarlo nuevamente hasta que no exista ninguna diferencia entre el resultado real y el
resultado esperado.

Todo programador conoce las ventajas que vienen con trabajar con un ambiente de
desarrollo que facilite el proceso de generación de código. Estos ambientes o
plataformas generalmente son editores que cuentan con herramientas funcionales que
proporcionan al programador una interfaz amigable para realizar tareas específicas. En
el caso de este proyecto, las plataformas o herramientas de desarrollo principales son:

• VrmlPad 2.0, software desarrollado por Parallel Graphics

• Java SDK 1.4, elaborado por Sun Microsystems.

El software VrmlPad 2.0 es un editor de VRML que permite estructurar la sintáxis de

un archivo .wrl a través de ciertas herramientas que optimizan el proceso de
programación. También cuenta con un depurador de scripts, que puede utilizarse para
probar la funcionalidad de scripts desarrollados en VrmlScript y JavaScript. Este
depurador no puede utilizarse para depurar scripts descritos en lenguajes más robustos
como Java, o Delphi.

Java Software Development Kit, o Java SDK, es la plataforma tradicional que Sun
Microsystems proporciona gratuitamente a los desarrolladores interesados para generar
aplicaciones computacionales basadas en Java. En el Apéndice A anexado a este
documento puede encontrarse el URL desde el cual puede obtenerse esta plataforma de
desarrollo.

Al igual que las pruebas de funcionalidad de un program script, las pruebas en la

generación de routes o circuitos se realizan paralelamente al proceso de desarrollo. Un
error al crear un circuito puede darse ya sea por tratar de formar enlaces entre un
eventOut y eventIn (ver capítulo 3) que manejan tipos de datos diferentes, o por tratar
de formar una ruta entre 2 elementos del archivo .wrl de los cuales uno de los 2 (o los
dos) no existe o no es reconocido por el VRML browser. Es importante que cada
circuito se pruebe individualmente sobre el objeto que debe modificar el circuito, de
esta manera se facilita el proceso de pruebas y se respeta el aspecto de modularidad del
desarrollo del software. Una vez que se tiene certeza de que el circuito funciona tal y
como se desea, entonces el objeto al cual el script afecta puede incluirse dentro de una
escena virtual contenedora.

La ventaja de utilizar VrmlPad 2.0 como ambiente de desarrollo para el Virtual Reality
Modeling Language es que esta plataforma detecta cuando se presenta alguna
incoherencia o anomalía en la declaración de un circuito, permitiendo así al programar
el identificar los posibles errores sin la necesidad de planear casos de prueba extensos y
complicados.

Una particularidad de un programa es el hecho de que tiene que operar con diferentes
inputs (entradas) para producir alguna salida (outputs). Es dogmático que el software
sea probado con una variedad de inputs diferentes para observar el comportamiento del
software ante cada una de las entradas que pueda obtener, ya sea de un usuario, o de la
interacción con alguna otra aplicación computacional. Cuando éste es el caso, se
generan diversos caminos lógicos (o no tan lógicos) que crean una gran cantidad de
estados posibles por los que puede pasar el software durante un ciclo de ejecución. Una
vez que el ciclo de vida del proyecto llega a los desarrolladores en la etapa de pruebas,
es imprescindible desarrollar los suficientes casos de prueba para que pueda evaluarse el
desempeño del software en cada una de sus transiciones entre estados. En proyectos de
software muy grandes, los estados y transiciones pueden ser muchas, lo que hace que la
etapa de pruebas tenga que ser muy larga y exhaustiva. En el caso del estudio Realidad
Virtual Aplicada al Tratamiento del Trastorno de Lateralidad y Ubicación espacial, los
program scripts solo tienen una entrada posible, y solamente hay una salida correcta. Es
por esto que no es necesario realizar pruebas que vayan más allá de proporcionar la
entrada definida, esperando que el impacto de la entrada sobre la escena virtual sea el
esperado. En ningún momento se generan árboles de decisión complejos ya que, a
través del routing o creación de circuitos, se define solamente un camino que el VRML
browser debe seguir.

En vista de que este estudio pretende desarrollar una aplicación computacional que
busca tener aplicación inmediata, es sumamente importante el no solo hacer pruebas
funcionales, sino también pruebas de campo que requieran de interacción directa entre
los ambientes virtuales y la población objetivo o usuarios finales. Las pruebas de campo
que se llevaron a cabo se discuten en la siguiente sección.

1.3. Pruebas de Campo y Aplicativas

En el capítulo 2 se discuten las generalidades de la disciplina de la Ingeniería de

Software y de los pasos necesarios que tienen que seguirse al apegarse a una de la tantas
metodologías propuestas por diversos autores y analistas para garantizar el desarrollo de
aplicaciones de software de calidad y con un tiempo de usabilidad largo.

A pesar de que existen varios modelos de trabajo a los cuales los desarrolladores de
software pueden apegarse para generar aplicaciones computacionales, todos estos
modelos tienen como una etapa común una pesquisa de requerimientos que sirven como
lineamientos de lo que el software debe poder hacer, lo que no debe hacer, y de las
restricciones globales a las que debe apegarse el proyecto de software [KII02].
Generalmente estos requerimientos se obtienen por medio de un trabajo conjunto entre
los involucrados en el desarrollo del proyecto de software, y los interesados (usuarios
finales) en el software mismo. Sin embargo, no debe de caerse en el error de obtener la
lista inicial de requerimientos y después perder el contacto con los clientes o usuarios
finales; por el contrario, es necesario que durante el ciclo de vida de un proceso de
desarrollo de software se mantengan abiertas las vías de comunicación entre quienes
desarrollan el software y quienes solicitan el desarrollo del mismo. Esto con el fin de
tener una retroalimentación constante que impida que se pierdan de vista los objetivos
iniciales que se fijan para el proyecto.

El proyecto Realidad Virtual Aplicada al Tratamiento del Trastorno de Lateralidad y

Ubicación espacial contó desde un principio con apoyo externo proveniente de un
terapeuta con experiencia en el tratamiento del trastorno en cuestión. Durante el ciclo de
vida del desarrollo de este proyecto, se llevaron a cabo reuniones frecuentes con la
Psicóloga Norma Rodríguez con el fin de ir mostrando prototipos sobre los cuales se
determinaban posibles mejoras a elementos ya programados. Esta retroalimentación fue
constante, y de esta manera se tuvo la certeza de que los objetivos generales y
específicos se fueran cumpliendo paulatinamente.
En el capítulo 1, sección 1.2.3.1, se identifican lo usuarios que interactuarán con la
herramienta de software propuesta de este estudio. Se hace notar que los usuarios de
esta herramienta no son solo terapeutas, sino también pacientes que padecen de
alteraciones en la percepción de sus nociones básicas. Es por esto último que se vuelve
sumamente necesario el exponer a los pacientes a los ambientes virtuales dentro de los
cuales se encuentra modelado el tratamiento a su padecimiento con el fin de obtener
retroalimentación proveniente de la interacción entre el sistema y quienes realmente
serán los beneficiados de los resultados que este proyecto de tesis produce. Esta
retroalimentación se llevo a cabo por medio de pruebas de campo, que consistieron en
seleccionar muestras poblacionales de usuarios potenciales para que interactuaran y,
hasta cierto punto jugaran, con los ambientes virtuales.

Las pruebas de campo se llevaron a cabo con dos muestras poblacionales, la población 1
estuvo constituida por un grupo de niños sin trastornos neurofisiológicos, y la población
2 se conformó por niños que sí son padecientes del trastorno de lateralidad y ubicación
espacial y que actualmente se encuentran bajo tratamiento tradicional impartido por la
psicóloga Norma Rodríguez y sus colegas. Los resultados de las pruebas de campo con
cada una de las poblaciones se presentan en la tabla 4.1 y en los reportes de prueba que
presentan posteriormente dentro de esta sección.

La tabla 4.1 muestra los resultados e interpretaciones de las pruebas de campo que se
llevaron a cabo con la primera población de sujetos que, como ya se mencionó antes, se
conformó por niños no padecientes del trastorno de lateralidad y ubicación espacial. A
cada uno de los sujetos de la población 1 les tomó 20 minutos promedio el completar las
4 actividades presentadas.

La tabla 4.1 presenta las observaciones generarles que se obtuvieron de la interacción

entre los sujetos de la población 1, y los ambientes virtuales dentro los cuales se modela
un tratamiento al trastorno de lateralidad y ubicación espacial. La columna de
Experiencia Previa se refiere a si el sujeto tiene o ha tenido contacto con computadoras
o videojuegos, esto con el fin de determinar la facilidad (a nivel control) con la que un
niño puede operar la computada donde se le presenten los mundos virtuales. Como se
menciona anteriormente dentro de este estudio, el control de los mundos virtuales se
hace a través de la flechas de izquierda, derecha, arriba, o abajo que se encuentran en el
teclado, y del mouse o ratón. Se asume que un niño que tiene experiencia utilizando
computadoras o jugando videojuegos, cuyos controles son mucho más complejos que
los necesarios para operar los ambientes virtuales propuestos por este proyecto,
entonces no tendrá problema alguno para desenvolverse dentro de los ambientes
virtuales. La columna de resultados se refiere a si el sujeto pudo (+) o no (-) resolver las
actividades contenidas dentro de los ambientes virtuales.

En vista de que los sujetos de la población 1 son sujetos sin ninguna alteración
neurofisiológica, a todos les resulto fácil resolver las actividades de tratamiento que se
encuentran modeladas dentro de los ambientes virtuales; como puede verse en la tabla
4.1, los niños comentaron que les resultaba relativamente sencillo resolver los acertijos.
La mayoría de los sujetos prefieren recibir las instrucciones en voz que por escrito, y se
comprobó que a los niños les gusta interactuar con este tipo de aplicaciones
computacionales.

Tabla 4.1 Pruebas de campo con la población 1

Nombre Edad Escolaridad Exp. Previa Resultados Comentarios
José Miguel 11 4to de Primaria Si + -Instrucciones en voz
Aguilera -Más dificultad
-Le gustan los
ambientes virtuales
- Más movimiento y
actividad dentro de la
ciudad
Samuel Vallejo 10 5to Primaria Si + -Instrucciones en voz
Cáliz -Le gusta la música de
fondo
-Más dificultad
-Más ambientación
orientada a niños
Luciano Pérez 9 3ro Primaria Si + -Instrucciones por
escrito
-Más actividades
-Le gustan los
ambientes tal y como
están
Alberto Argaiz 12 6to Primaria Media + - Instrucciones en voz
-Le gustan los
ambientes
 -Le gusta música de
fondo
-Más dificultad
Carlos Alberto 10 3ro Primaria No - -Instrucciones en voz
Bojalil -Le gusta la música
-Se le hace muy difícil
Rafael Espinosa 10 4to Primaria SI + -Instrucciones en voz
Castañeda -Le gusta la música
-Le gustaría recibir
menos ayuda
-Le agradan los
ambientes, pero le
gustaría ver más
movimiento.

Los resultados que se obtuvieron a través de las pruebas con la población 1 fueron
tomados en cuenta para realizar modificaciones a la interfaz o apariencia de la
herramienta de software en base a los comentarios que los niños hicieron. Estas pruebas
fueron importantes para ver la respuesta de un niño ante mundos modelados en realidad
virtual, esto con el fin de verificar si desde el punto de vista de la disposición y apertura
por parte del usuario es viable utilizar la terapia de exposición utilizando realidad virtual
para modelar dentro de entornos virtuales los tratamientos a los diferentes trastornos
neurofisiológicos. Por lo determinado por estas pruebas, los resultados son favorables y
positivos dentro de los fines del proyecto Realidad Virtual Aplicada al Trastorno de
Lateralidad y Ubicación Espacial.

La tabla 4.2 presenta resultados porcentuales obtenidos de las pruebas de campo que se
llevaron a cabo con la población 1. Estos valores fueron obtenidos en base a los
comentarios que los usuarios hicieron con respecto a la herramienta de software que se
les presentó.

Tabla 4.2 Resultados porcentuales de las pruebas de campo con la población 1

Bien Mal
Diseño Visual 83% 17%
Música 100% 0%
Control y desempeño 83% 17%
Calificación global 100% 0%
A pesar de que la muestra poblacional fue pequeña, es lo suficientemente válida como
para mostrar las tendencias de los niños. En general todos se sintieron muy contentos
con la herramienta de software basada en ambientes virtuales, e hicieron comentarios
favorables con respecto a la interfaz con el usuario. El 100% de los niños con los que se
formó la muestra 1 no han sido diagnosticados con algún trastorno neurofisiológico,
pero en los resultados obtenidos en las pruebas de campo se observa que un 83% de los
sujetos (5 de 6) pudieron resolver las pruebas sin problemas. Sin embargo, se dio el caso
de un sujeto que manifestó serios problemas de orientación y de comprensión en cuanto
a lo que tenía que hacer. Esto podría sugerir que en un momento dado la herramienta
propuesta por el proyecto Realidad Virtual Aplicada al Trastorno de Lateralidad y
Ubicación Espacial puede llegar a ser utilizada como auxiliar en el diagnóstico del
trastorno de lateralidad, más esto no se discute ya que la herramienta propuesta por este
estudio no pretende ser utilizada como metodología de diagnóstico.

Posteriormente, se realizaron pruebas de campo con la población 2, formada por niños

que han sido diagnosticados como padecientes del trastorno de lateralidad y ubicación
espacial, y que actualmente se encuentran bajo tratamiento tradicional de sus trastornos.
Esta muestra poblacional fue proporcionada por la psicóloga Norma Rodríguez. Las
pruebas de campo con la población 2 se llevaron a cabo en las instalaciones de la
escuela en donde la psicóloga Rodríguez trabaja e imparte tratamiento a sus pacientes.
A cada uno de los niños se le dio una breve explicación acerca de cómo controlar la
computadora y los ambientes virtuales que se les presentaron, y posteriormente se les
dejó que jugaran con el ambiente principal IntroCity para de esta manera fueran
accediendo 4 actividades de tratamiento modeladas en VRML y complementadas por
Java y JavaScript. Los resultados de las pruebas de campo con la población se
presentan a continuación.
Tabla 4.3 Pruebas de campo con la población 2
Nombre Pedro Santiago Parra
Edad 6 años
Escolaridad 1ro de Primaria
Tiempo 40 minutos
Comentarios No ha tenido experiencia con computadoras, pero sin con
videojuegos. Prefiere recibir las instrucciones en voz que por
escrito. Al principio requirió de mucho ayuda pero fue
mejorando su rendimiento conforme pasaba el tiempo. Algunas
veces intentaba resolver las actividades al azar. Cree haber
aprendido algo por medio de la interacción con los ambientes
 virtuales. Le agrada la apariencia de los entornos virtuales, y le
gustaría mucho tener más contacto con el software en el futuro.
Prefiere el tratamiento a través de ambientes virtuales que en
libros e impresos.

Nombre Uriel Pérez

Edad 7 años
Escolaridad 2do de Primaria
Tiempo 25 minutos
Comentarios No ha tenido experiencia con computadoras y no sabe leer, por
lo que se apoya totalmente en las instrucciones de voz. Puede
distinguir bien entre derecha e izquierda, pero presenta
problemas con arriba, abajo, y frente y fondo de la pantalla.
Manifiesta mucho entusiasmo hacia los ambientes con los que
esta interactuando y actividades que esta resolviendo. No le
gusta la música de fondo, y le gustaría ver más objetos de color
rojo. Le gustaría ver más animales dentro de los mundos. Siente
que aprendió algo nuevo, y preferiría trabajar con los ambientes
virtuales en el futuro en lugar de con los libros.

Nombre Luis Gabriel

Edad 10 años
Escolaridad 5to de Primaria
Tiempo 20 minutos
Comentarios No ha tenido experiencia con computadoras, sabe leer pero
prefiere recibir las instrucciones por medio de voz que por
escrito. Las actividades más básicas le resultan relativamente
fáciles, y puede resolverlas sin problemas. Le gustan mucho los
ambientes virtuales y la música de fondo. Tiene mucho sentido
de la ubicación, y después de cierto tiempo pudo moverse dentro
de los ambientes sin ningún problema. Cree que podría aprender
mucho de este tipo de juego, y prefiere trabajar con ambientes
virtuales que con libros y actividades plasmadas en papel.

Nombre Joel Aguilar Domínguez

Edad 8 años
Escolaridad 1ro de Primaria
Tiempo 35 minutos
Comentarios No ha tenido experiencia previa con computadoras. Sabe leer
pero prefiere las instrucciones habladas. En general comenta que
 le gusta mucho lo que ve, y que le gusta completar las
actividades que se le presentan, pero que le gustaría que los
entornos virtuales fueran más perecidos a los videojuegos a los
que se encuentra acostumbrado. Al principio requiere de guía e
instrucción, pero poco a poco encuentra confianza por si mismo.
No esta seguro de si realmente aprendería algo a través de
interactuar con los ambientes virtuales, más prefiere trabajar en
la computadora que con los impresos tradicionales.

Nombre Analí Rodríguez

Edad 8 años
Escolaridad 2do de Primaria
Tiempo 40 minutos
Comentarios No tiene experiencia con computadoras. Presenta problemas
visuales y no entiende muy bien como operar el mouse.
Manifiesta mucha desorientación con respecto al manejo de la
computadora. No puede distinguir localizaciones especiales
dentro de la pantalla de la computadora. Requiere de mucha
ayuda para completar las cuatro actividades. Le gusta
visualmente lo que, y le agrada la música. Siente que podría
aprender mucho a través de operar los ambientes virtuales, y
prefiere la metodología virtual sobre el tratamiento tradicional.
Le gustaría ver algunas actividades que presentaran dinosaurios.

Nombre Gilberto Hernández

Edad 12 años
Escolaridad 6to Primaria
Tiempo 20 minutos
Comentarios No tiene experiencia con computadoras, pero si con los
videojuegos. Prefiere las instrucciones escritas sobre las de voz.
Le resulta fácil resolver las actividades. Visualmente le gusta el
ambiente principal, pero le gustaría un poco mas de actividad y
moviendo dentro la ciudad. Le gusta la música, y le gustarían
mas actividades con animales dentro de los ambientes. Prefiere
trabajar con ambientes virtuales que con impresos y libros. Cree
que puede aprender muchas cosas a través de los ambientes y de
las computadoras.

Nombre Maria Elena Arredondo

Edad 9 años
Escolaridad 4to Primaria
Tiempo 30 minutos
Comentarios No tiene experiencia con computadoras o con videojuegos.
Prefiere las instrucciones en voz sobre las escritas. Le gustaría
ver más actividades con animales, y que los cambios de colores
de los objetos no solo fueran a verde. Al principio intenta
resolver las actividades por medio de prueba y error, pero
conforme pasa el tiempo empieza a seguir instrucciones y a
trabajar en base a lo que se le pide. Le gustan los ambientes y la
 música, pero le gustaría que hubiera más señales dentro de la
ciudad. Cree que aprende muchas cosas de los ambientes
virtuales, y prefiere el tratamiento modelando en computadora
sobre la metodología tradicional.

En lo que se reporta en las pruebas de campo que se llevaron a cabo con la población 2,
puede observarse que a pesar de que los pacientes no tenían experiencia previa
operando o trabajando con computadoras, todos coinciden en que prefieren trabajar con
ambientes virtuales y con computadoras que con actividades presentadas en libros y
otros impresos. El hecho de que el 100% de los pacientes no tengan experiencia
operando ambientes virtuales o computadoras no es algo negativo; por el contrario, a los
pacientes y terapeutas no solo se les proporciona una metodología de tratamiento que
acarrea los beneficios de la Terapia de Exposición Utilizando Realidad Virtual, sino
también se les de la oportunidad de empezar a formar un poco de cultura computacional
que en estos tiempos se ha vuelto una necesidad para la formación educativa de todas
las personas. La falta de experiencia computacional solamente implica que el periodo de
adaptación es un poco más largo, pero nadie nace sabiendo y siempre es un buen
momento para aprender.

El tiempo promedio que le tomó a cada sujeto de la población 2 completar las

actividades que les fueron presentadas dentro de los ambientes virtuales es de 30
minutos, cantidad de tiempo que es en promedio 10 minutos más que a los sujetos de la
población 1. Es importante ser reiterativo en el hecho de que los sujetos de la población
1 fueron niños que no han sido diagnosticados con ninguna clase de padecimiento
neurofisiológico, y que los sujetos de la población 2 reciben tratamientos especiales.
Otros factores, como posición socioeconómica, exposición a tecnología, y entorno
social puede ser determinantes en los resultados de las pruebas, más el profundizar en
alguno de estos aspectos está fuera del alcance de este proyecto.

Los niños mostraron mucha alegría y curiosidad hacia el nuevo prospecto de tratamiento
que se les estaba presentando. El 100% de los niños establecieron que prefieren trabajar
la computadora y con ambientes virtuales, que con la metodología tradicional a la que
ha estado sujetos. La gran ventaja de esto es que los pacientes, al mostrar entusiasmo
por interactuar con los ambientes virtuales, aumentan su apertura mental hacia recibir
un tratamiento correctivo de sus padecimientos, y con esto se agiliza el tratamiento en
si.

A los sujetos les gusta mucho la apariencia de los ambientes virtuales, más cabe
mencionar que la imaginación de un niño no tiene límites, y por eso mismo hacen
comentarios referentes a cosas que han visto en videojuegos o en la televisión y que les
gustaría ver dentro de las escenas modeladas en VRML. Más muchas de estas
sugerencias no son viables, o en un momento dado adecuadas para los fines de la
herramienta de software que este proyecto propone.

También pudo observarse de las pruebas de campo que lo más cercano que los sujetos
han visto a mundos virtuales son los tan populares videojuegos, que inmediatamente se
relacionan con entretenimiento. Esto es muy positivo para los fines de este proyecto, ya
que el tratamiento deja de ser una actividad molesta o monótona y se vuelve mucho más
amigable y atractiva para los usuarios.

En el Apéndice D de este documento se presentan algunas fotografías de las pruebas de

campo que se llevaron a cabo para el proyecto Realidad Virtual Aplicada al Tratamiento
del Trastorno de Lateralidad y Ubicación Espacial.

Tanto las pruebas funcionales como de campo que se efectuaron dentro de este proyecto
dieron buenos resultados. El haber mantenido un contacto con un terapeuta profesional
sirvió como elemento de retroalimentación sobre el proceso de desarrollo de la
herramienta de software propuesta por este estudio. Las pruebas de campo sacaron a la
luz detalles funcionales que pueden ser mejorados en versiones posteriores del software
desarrollado por este proyecto.

Las muestras poblacionales con las que se realizaron las pruebas son pequeñas, y por
esto mismo no es apropiado sacar conclusiones precisas y exactas respecto al rango de
aplicación que puede llegar a tener este proyecto. Si embargo, las pruebas de campo que
se llevaron a cabo son suficientes para comprobar empíricamente que los objetivos de
este proyecto se cumplen, y que los resultados de llevarlo a la práctica pueden ser
realmente positivos. Además, las pruebas ilustraron reacciones y tendencias positivas
provenientes de los mismos usuarios para los cuales se realizó este proyecto en primer
lugar, lo cual puede tomarse en cuenta como argumento a favor para futuras
expansiones a este proyecto, o para otros proyectos que pretendan utilizar la Realidad
Virtual como medio de tratamiento y enseñanza.

Tomando en cuenta la premisa de desarrollo tecnológico, la disponibilidad de las

plataformas de desarrollo, las ventajas que ofrece la denominada Terapia de Exposición
Utilizando Realidad Virtual, y después de realizar pruebas de campo en las que se
observaron las reacciones de los usuarios identificados dentro de la población objetivo,
puede concluirse que es viable y conveniente modelar el tratamiento al trastorno de
lateralidad y ubicación espacial dentro de ambientes virtuales de aprendizaje.