Katia Fabiola Cánepa Vega TREG: Un juego de entrenamiento...

Katia Fabiola Cánepa Vega

TREG: Un juego de entrenamiento

en Ingeniería de Requisitos

Tesis de Maestría

Tesis presentada como requisito parcial para obtener el título de Magíster por el programa de Pos-Graduación en Informática de la PUC-Rio.

Orientador: Hugo Fuks

Co-Orientador: Gustavo Robichez de Carvalho

Río de Janeiro, Febrero de 2010


TREG: Un juego de entrenamiento en Ingeniería de

Requisitos

Tesis presentada como requisito parcial para obtener el título de Magíster por el programa de Pos-Graduación en Informática de la PUC-Rio. Aprobada por la Comisión Examinadora que suscribe a continuación.

Hugo Fuks Orientador

PUC-Rio

Gustavo Robichez de Carvalho Co-orientador

PUC-Rio

Alberto Barbosa Raposo PUC-Rio

Mariano Pimentel UNIRIO

José Eugenio Leal Coordinador(a) Sectorial del Centro Técnico Científico - PUC-Rio

Río de Janeiro, 26 de Febrero de 2010

Todos los derechos reservados. Se prohíbe la reproducción total o parcial del trabajo sin autorización de la universidad, de la autora y del orientador.


Graduada en Ingeniería de Sistemas e Informática por la Universidad Nacional Mayor de San Marcos (UNMSM), Perú. Su área de investigación actual es mundos virtuales, juegos y colaboración. Trabajó como consultora de procesos de desarrollo de software y de las herramientas de IBM Rational.

Desarrolló, como proyecto de maestría, un juego para el entrenamiento en ingeniería de requisitos.

Ficha Catalográfica

Cánepa Vega, Katia Fabiola

Un juego de entrenamiento en Ingeniería de Requisitos prototipado en Second Life

v., 132 f: il. ; 30 cm

Dissertación (maestría) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática

Incluí referências bibliográficas.

Informática, TREG, Ingeniería de Requisitos, Mundos Virtuales, Second Life, Prototipación

A mis padres, Carlos y Lida,

por su amor infinito

Agradecimientos

A mi asesor, Profesor Hugo Fuks, por confiar en mí, por ser un ejemplo

constante de investigador y por, entre muchas otras palabras, enseñarme el

significado de osadía.

A mi co-asesor, Gustavo Robichez, por su dedicación y siempre valiosas

sugerencias que me ayudaron a analizar las cosas desde varias perspectivas.

A la banca examinadora por sus importantes contribuciones en el refinamiento

de este trabajo.

A mis colegas de Groupware del LES, por su compañerismo a lo largo de estos

dos años; en especial a Bruno y Andreia por sus demostraciones de

colaboración y amistad.

A mis padres Lida y Carlos, por todo su esfuerzo en hacerme crecer y por su

amor infinito y sin fronteras. A mis hermanos Renatto y Carlos, y a mi tía Mary

por sus demostraciones de cariño e incentivo en seguir adelante.

A Paola, Cris, Ugo, Silvinha y Elizabeth por convertirse en mi familia en este otro

lado del continente. A mis amigos, Diego, Maribel, Maju, Geraldine, Mila, por

enseñarme lo que es la amistad verdadera.

A la PUC-Rio por acogerme en esta mi nueva casa de estudios y a la agencia

CAPES por el apoyo financiero para la realización de este proyecto.

Resumen

Cánepa Vega, Katia Fabiola. TREG: Un juego de entrenamiento en Ingeniería de Requisitos. Rio de Janeiro, 2010. 132p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

TREG es un juego para el entrenamiento en Ingeniería de Requisitos

específicamente en la técnica de Workshops. Fue creado en Second Life,

usando sus posibilidades de modelamiento 3D y programación. Este trabajo

presenta una experiencia de exploración en un proceso de prototipación y

técnicas para desarrollar el juego. El ciclo de desarrollo de TREG utiliza el

proceso de prototipación basado en el libro “Effective Prototyping for Software

Makers”, este es un proceso iterativo que fue personalizado para la creación del

juego educacional en este mundo virtual. Branching Stories es un género de

simulaciones que da una visión global de todos los caminos posibles del jugador

en TREG. La técnica de Escenarios es usada para la especificación de las

simulaciones modeladas en el grafo de Branching Stories. El diseño de TREG

utiliza las especificaciones realizadas con la técnica de escenarios para modelar

diversas perspectivas del software. Las Maquinas de Estados modelan el

comportamiento dinámico de los elementos del software, el diagrama de clases

representa los objetos creados en Second Life y el diagrama de comunicación

muestra las relaciones y paso de mensajes entre los objetos. Además, este

trabajo muestra los resultados de la evaluación realizada así como las

dificultades presentadas por los participantes al utilizar esta herramienta.

Palabras clave Juego, prototipación, CSCL, Second Life, Ingeniería de Requisitos.

Abstract

Cánepa Vega, Katia Fabiola. TREG: A game for training in Requirements Engineering. Rio de Janeiro, 2010. 130p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

TREG is a game for training in Requirements Engineering, specifically in

the Workshops technique. It was created in Second Life using its building and

scripting possibilities. This works presents an exploration in the use of a

prototyping process and techniques for developing the game. The prototyping

process of the book “Effective Prototyping for Software Makers” is an iterative

process which was customized for the development of the game in this virtual

world. Branching Stories is a simulation genre that gives an overview of all the

possible paths the player can take in TREG. Scenario is a Requirements

Engineering technique used for the specification of the simulations modeled in

the Branching Stories graph. The design of TREG used the Scenarios

specifications for modeling the software perspectives. The state machine

diagrams shows the dynamic behavior of the TREG objects, a class diagram

represents the objects created in Second Life and the communication diagrams

shows the relationships and the flow of messages between objects. This work

also shows the results of the evaluation made and the difficulties presented by

the participants whereas TREG was used.

Keywords Game, prototyping, CSCL, Second Life, Requirements Engineering.

Tabla de contenido

1 Introducción 13

1.1. Motivación 13

1.2. Definición del proyecto 15

1.2.1. Objetivos 15

1.2.2. Alcance 15

1.2.3. Cronograma del proyecto 16

2 Marco teórico 17

2.1. Mundos Virtuales 17

2.1.1. Second Life 18

2.1.2. Machinima 18

2.2. Workshops: Técnicas en Ingeniería de Requisitos 19

2.3. Técnicas para el desarrollo del juego 20

2.3.1. Proceso de prototipación 21

2.3.2. Branching Stories 21

2.3.3. Escenarios 22

2.3.4. Diagramas de clases 23

2.3.5. Diagramas de comunicación 24

2.3.6. Maquinas de estados 24

2.4. Trabajos relacionados 25

3 Características y aspectos del desarrollo de TREG 27

3.1. Características del juego 27

3.2. Contenido Educacional 30

3.2.1. Personas Adecuadas 31

3.2.2. Propósito Compartido 32

3.2.3. Trabajo Previo 33

3.2.4. Espacio Compartido 35

3.3. Diseño de TREG 36

3.3.1. Branching Stories en TREG 37

3.3.2. Escenarios de TREG 38

3.3.3. Modelamiento de TREG 41

4 Prototipos 48

4.1. Proceso de prototipación 48

4.1.1. Fase 1. Planificar 48

4.1.2. Fase 2: Especificar 49

4.1.3. Fase 3. Diseñar 49

4.1.4. Fase 4. Resultados 50

4.2. Características de los prototipos de TREG 51

4.3. Criterios de Diseño 53

4.4. Iteraciones 56

4.4.1. Iteración 1. 57





5 Pruebas y análisis de resultados 62

5.1. Propósito 62

5.1.1. Aspectos de la evaluación 62

5.1.2. Participantes 64

5.2. Desarrollo de las pruebas 64

5.2.1. Localización y condiciones técnicas 65

5.2.2. Acuerdos 65

5.2.3. Perfil de los participantes 66

5.2.4. Entrenamiento en Second Life 66

5.2.5. Durante las pruebas 67

5.2.6. Después de las pruebas 67

5.3. Resultados 73

5.3.1. Interfaz 74

5.3.2. Mecanismos 76

5.3.3. Jugabilidad 78

6 Conclusiones y trabajos futuros 81

6.1. Conclusiones 81

6.2. Trabajos futuros 84

7 Referencias Bibliográficas 86

Apéndice A – Diseño del software 89

A.1. Escenario: Personas Adecuadas. Excepción opción A 89

A.2. Escenario: Personas Adecuadas. Excepción opción B 90

A.3. Escenario: Personas Adecuadas. Excepción opción D 91

A.4. Canales de comunicación de TREG 92

A.5. Ejemplos de diagramas de comunicación en TREG 95

A.6. Ejemplos de diagramas de estados en TREG 96

Apéndice B - Documentos usados en las pruebas de usabilidad 97

B.1. Término de Consentimiento 97

B.2. Cuestionario del Perfil y Experiencia del Participante 99

B.3. Entrenamiento en Second Life para el uso de TREG 100

B.4 Entrevista 104

B5 Cuestionario IPQ 106

B6. Detalle del entrenamiento en Second Life 108

B7. Resultados del Cuestionario IP 109

B8. Resultados del Cuestionario IPQ 110

Apéndice C. Observación del uso de TREG 111

C1. Reporte de las Pruebas de Usabilidad de TREG (P2) 112



Apéndice D. Capturas de pantallas 127

D.1. Áreas de TREG 127

D.2. Panel de Simulación 128

D.3. Ingrediente de Personas Adecuadas 129

D.4. Ingrediente de Propósito Compartido 130

D.5. Ingrediente de Trabajo Previo 131

D.6. Ingrediente de Espacio Compartido 132

Lista de figuras

Figura 1 Cronograma de actividades de TREG 16

Figura 2 The Effective Prototyping Process de [9]. 21

Figura 3 Estructura de Branching Stories de [5]. 22

Figura 4 Escenario del Ingrediente Personas adecuadas. 23

Figura 5 Diagrama de estados de uno de los elementos de TREG 25

Figura 6 A Groupthink game (A). Hospital Scenario en Play2Train (B) 26

Figura 7 La metáfora de la cocina y el cuarto de simulaciones de Workshops. 28

Figura 8 Miss Workshop, el NPC guía. 29

Figura 9 Funcionamiento de TREG desde la perspectiva del jugador. 29

Figura 10 Distribución de los ingredientes en el proceso de Workshops 30

Figura 11. Iteraciones de un Workshops. Trabajo Previo de [8] 34

Figura 12. Dimensiones de espacio y tiempo en las reuniones [8]. 35

Figura 13 Proceso de Diseño de TREG 36

Figura 14. Grafo de Branching Stories de TREG. 37

Figura 15. Escenario WS03 del ingrediente de Personas Adecuadas 39

Figura 16. Diagrama de clases para representar los elementos de TREG 42

Figura 17. Diagrama de Comunicación del Escenario WS03 44

Figura 18. Maquinas de estados de un NPC en Personas Adecuadas 46

Figura 19. Implementación de estados de NPC de Personas Adecuadas 46

Figura 20. Prototipos desarrollados en TREG 57

Figura 21. Prototipo de la Iteración 1. 58





Figura 26. Respuestas al cuestionario IPQ 80

Figura A.1. Escenario de Personas Adecuadas. Excepción opción A 89

Figura A.2. Escenario de Personas Adecuadas. Excepción opción B 90

Figura A.3. Escenario de Personas Adecuadas. Excepción opción D 91

Figura A.4. Diagrama de comunicación del Escenario WS04 95

Figura A.5. Diagrama de comunicación del Escenario WS04 95

Lista de tablas

Tabla 1. Pros y contras de los posibles participantes al workshop 32

Tabla 2. Participantes al workshop y sus características 40

Tabla 3. Iteraciones y sus características 51

Tabla 4. Funciones con mayor retraso (en segundos) 56

Tabla 5. Aspectos a evaluar del juego 63

Tabla 6. Perfil de los participantes en las pruebas. 66

Tabla 7 Uso de Second Life 68

Tabla 8 Facilidad de uso de los ambientes en TREG 68

Tabla 9 Interacción con los elementos del juego (Panel de Simulación) 69

Tabla 10 Facilidad de uso de los ingredientes 70

Tabla 11 Entendimiento del objetivo del juego. (Personas Adecuadas) 71

Tabla 12. Elementos del cuestionario IPQ. 72

Tabla 13 Tiempo empleado en el juego 73

Tabla 14 Número de Intentos empleados en cada tarea de TREG 74

Tabla 15 Resultados de la entrevista. Interacción con los elementos del juego 74

Tabla 16. Observaciones más comunes en la interacción con Second Life 75

Tabla 17. Observaciones más comunes en la interacción con los elementos de

TREG 75

Tabla 18 Resultados de la entrevista. 76

Tabla 19 Reincidencias en la facilidad de Uso 77

Tabla 20 Reincidencias en el entendimiento del objetivo del juego 78

Tabla 21. Conversión de resultados del cuestionario IPQ 79

Tabla 22. Promedio de los factores de Presencia del cuestionario IPQ 80

Tabla A.1. Canales de comunicación de TREG 92

Tabla B.1. Respuestas al cuestionario IPQ 108

Tabla B.2. Detalle de intentos de los participantes 109

Tabla B.3. Detalle del tiempo empleado por los participantes 109

Tabla B.4. Respuestas al cuestionario IPQ 110

1 Introducción 13

1 Introducción

El objetivo de este capítulo es presentar una visión general de la

investigación realizada en el proyecto. Se discute la motivación para la creación

de TREG, se definen los objetivos, el alcance y el cronograma del proyecto.

La organización de este documento fue dividida en seis capítulos. El

capítulo 2 define el estado de arte del trabajo en el contexto actual, describiendo

los principales conceptos a ser usados en la tesis: Second Life, Workshops y las

técnicas de implementación del juego. El capítulo 3 describe las características

de TREG y la combinación de técnicas para el desarrollo del juego y el contenido

educacional. El capítulo 4 muestra el proceso de prototipación utilizado y los

métodos y características de cada iteración. El capítulo 5 presenta las pruebas

de usabilidad realizadas y los resultados obtenidos. El capítulo 6 expone las

conclusiones del trabajo resaltando las principales contribuciones y limitaciones,

y los posibles trabajos futuros.

1.1.Motivación

Según Gartner [1], el 80% de los usuarios activos de Internet tendrán una

“segunda vida” en algún mundo virtual para fines del 2011. Second Life es un

mundo virtual 3D abierto desde el 2003 donde son los mismos usuarios los que

crean el mundo e interactúan y se comunican usando un avatar [2]. Actualmente,

son más de 100 las instituciones educativas en más de 18 países que tienen

presencia en Second Life. [3]. Este mundo inmersivo ofrece a los educadores

nuevos retos y oportunidades de creación de ambientes en 3D donde los

alumnos puedan colaborar y aprender. [4].

Estudios actuales indican que los estudiantes son cada vez más

pragmáticos, aprenden visualmente y cuentan con un mayor dominio del

computador [5]. El informe del proyecto Horizon 2009 [6] identificó a los juegos

como una de las principales tendencias que impactará en la enseñanza en los

próximos 5 años. Este informe muestra que las personas involucradas a la

enseñanza superior y al mundo laboral tienen experiencia y afinidad a los juegos

lo cual da la posibilidad que sean usados como herramientas de aprendizaje.

1 Introducción 14

Pew Internet y el Proyecto American Life realizaron un estudio que muestra que

la participación activa y experiencias interactivas son la clave para el éxito de las

estrategias de aprendizaje basadas en juegos, e indica que los métodos de

enseñanza actuales no atraen lo suficiente a los estudiantes [7]. Los juegos

serios (serious games) van más allá del entretenimiento. Se tornan como un

desafío para la educación donde estos nuevos estudiantes puedan aprender de

una forma entretenida, manteniendo siempre un vínculo directo con la realidad.

Las simulaciones se muestran como un paradigma en la educación para la

transferencia de conocimiento y mantener a los alumnos inmersos en un

determinado tópico.

Este trabajo presenta un caso exploratorio del proceso de prototipación y

técnicas para desarrollar TREG. TREG (Training in Requirements Engineering

Game) es un juego serio para el entrenamiento en Ingeniería de Requisitos

creado en Second Life. El desarrollo del juego fue implementado bajo 2

aspectos: el contenido educacional y el desarrollo del software.

El contenido educacional de TREG se basa en los conceptos presentados

por Gottesdiener en su libro Requirements by Collaboration [8]. Esta técnica

consiste en una sesión de trabajo conducida por un facilitador en la que

participan los principales involucrados de un proyecto para identificar o revisar

los requisitos del software. TREG transforma a simulaciones, 4 de los

“ingredientes” propuestos por Gottesdiener para planificar Workshops.

Este trabajo propone la combinación de técnicas para la creación un juego

educacional en un mundo virtual. Dichas técnicas son: un proceso de

prototipación, un género de simulaciones de juegos, una técnica de

especificación de requisitos y diagramas para el modelamiento del software. La

combinación de estas técnicas posibilitó una anticipada retroalimentación en

cada una de las iteraciones y tener una visión de diversas perspectivas del

software.

El ciclo de desarrollo utiliza un proceso iterativo de prototipación basado en

el libro Effective Prototyping for Software Makers [9]. El diseño del software

utiliza Branching Stories como estrategia de simulación del juego, donde un

grafo modela todos los posibles caminos del jugador en TREG. La técnica de

Escenarios es usada para la especificación de cada uno de los nodos del grafo

de Branching Stories y además guía el modelamiento a través de diagramas que

fueron adaptados para este proyecto. El modelamiento del software es dado a

través de diagramas de clases que representan a los objetos en Second Life,

Maquinas de Estados para el modelamiento del comportamiento de los

1 Introducción 15

elementos del software y diagramas de comunicación que muestran los canales

de comunicación y el paso de mensajes entre objetos.

1.2. Definición del proyecto

En esta sección se define los objetivos, el alcance y el cronograma del

proyecto.

1.2.1.Objetivos

Se definieron el objetivo general y los específicos del proyecto.

Objetivo general

Realizar un caso exploratorio del proceso de prototipación y la

combinación de técnicas para el desarrollo de un juego educacional que

posibilita el entrenamiento en Ingeniería de Requisitos a través de simulaciones

de diversas situaciones basadas en la técnica de Workshops.

Objetivos específicos

• Mostrar la combinación de diversas técnicas utilizadas que facilitaron

nuestra experiencia en el desarrollo del juego.

• Adaptar un proceso de prototipación para crear este juego

educacional en un ambiente 3D.

• Crear contenido del curso de Ingeniería de Requisitos en el tópico de

Planificación de workshops basado en simulaciones.

• Ofrecer un ambiente de entrenamiento en Second Life que sea

persistente para los involucrados en ingeniería de requisitos.

• Reforzar el proceso de aprendizaje en la técnica de Workshops a

través de la experimentación en el juego.

1.2.2.Alcance

A continuación se mencionan los puntos tomados en cuenta para delimitar

el alcance del proyecto:

• El contenido educacional será basado en los ingredientes de

planificación de la técnica de Workshops descritos en el libro

Requirements by Collaboration [8].

• El juego soportará solamente a un jugador por vez.

1 Introducción 16

• Se parte bajo el supuesto que el usuario dispondrá de un computador

con los requisitos mínimos para el uso de Second Life.

• Este proyecto no se hace responsable de problemas de disponibilidad

de Second Life o errores con el cliente.

• Este trabajo no provee una guía para el desarrollo de juegos

educativos.

1.2.3.Cronograma del proyecto

A continuación se muestran las actividades para el desarrollo de la tesis de

maestría. Así como la duración de cada una de ellas. La Figura 1 muestra las

actividades a un alto nivel. El trabajo se dividió en 3 principales actividades: El

estudio del marco conceptual, los 4 “ingredientes” para llevar a cabo la

planificación de workshops y el desarrollo del documento.

Figura 1 Cronograma de actividades de TREG

Las tres primeras iteraciones del proceso de prototipación de TREG fueron

realizadas mientras se elaboraba el ingrediente de Personas Adecuadas y pasa

por las fases de planificación, especificación, diseño y resultados. Este

documento detalla el proceso de prototipación seguido para desarrollar esta

implementación en el juego.

2 Marco teórico 17

2 Marco teórico

En esta sección se definen los conceptos principales a ser utilizados en

este documento: mundos virtuales, la técnica de Workshops para la Elicitación

de Requisitos y diagramas para el modelamiento del juego. Se hace una

descripción del mundo virtual Second Life que será usado como plataforma de

desarrollo de TREG. El contenido del juego utiliza la técnica de Workshops como

base para la simulación. Además, se da una visión general de las técnicas a ser

utilizadas en el desarrollo del software.

2.1. Mundos Virtuales

Un mundo virtual es un ambiente interactivo multiusuario simulado por una

computadora y presenta las siguientes características [10]:

1. Ambiente compartido: Los usuarios comparten simultáneamente el

mismo mundo;

2. Interfaz de usuario gráfica: Ambiente gráfico que puede variar desde un

ambiente en 2D o 3D;

3. Inmediato: La interacción con el mundo ocurre en tiempo real;

4. Interactividad: El mundo permite a los usuarios a realizar cambios,

construir o personalizar su contenido;

5. Persistencia: El ambiente deberá existir continuamente; y

6. Socialización/Comunidad: Estos mundos promueven la formación de

grupos como equipos, clubes, vecinos, gremios, etc.

Los mundos virtuales son creados con diversos propósitos [10] como

juegos comerciales donde la gran mayoría cae en esta categoría también

conocida como de MMPORG (Massively Multiplayer Online Role Playing Game).

También hay aquellos orientados a la educación como Active Worlds o

Mokitown. Los mundos virtuales también pueden tener propósitos especializados

como American’s Army para el entrenamiento militar y AgoraXhange para la

expresión política. Finalmente, están los mundos virtuales que no tienen ningún

propósito específico como por ejemplo Second Life, The Sims, Kaneva y There.

2 Marco teórico 18

En ellos, los usuarios sociabilizan, y construyen o decoran un espacio. En este

proyecto, se explora Second Life debido a la libertad que ofrece en la creación y

programación del mundo virtual.

2.1.1. Second Life

El mundo virtual Second Life fue creado por Linden Labs en el 2003 [2]. En

él, los usuarios, también llamados residentes, representados como avatares

interactúan, crean y realizan negocios. Los avatares, que pueden ser

configurables a cualquier forma física, interactúan con otros avatares de muchas

formas, pudiendo explorar, sociabilizar, participar de conferencias, entre otras

cosas. Además de esto, los residentes pueden realizar negocios intercambiando

productos o servicios, comprando y vendiendo con la moneda virtual Linden

Dollars. Los residentes son quienes crean el contenido en Second Life,

construyendo su propio mundo o elementos del mundo.

El contenido de Second Life puede ser creado a través de sus editores de

terreno, de objetos y de scripts. La construcción de objetos es posible por medio

de un editor propio de Second Life que permite crear, modelar y vincular los

objetos creados a partir objetos 3D básicos llamados primitivos (prims) como

cajas, esferas o cilindros. Los objetos pueden contener hasta 255 prims y

pueden ser editados de diversas formas al aplicarle texturas, rotarlos,

redimensionarlos, cambiar la física de los objetos, entre otras propiedades.

El comportamiento de estos objetos y su comunicación con avatares y

otros objetos es incluido por medio de scripts. Los scripts son programados

usando un editor propio del lenguaje orientado a eventos LSL (Linden Scripting

Language) y son interpretados y ejecutados por el servidor de Second Life. Los

scripts en LSL deben tener por lo menos el estado por defecto con algún evento.

El cambio de eventos desencadena a que los objetos se muevan, escuchen,

hablen, funcionen como un vehículo o cambien sus parámetros como color,

tamaño o posición.

2.1.2. Machinima

Machinima es una técnica que utiliza mundos virtuales para crear piezas

audiovisuales en tiempo real y con técnicas de grabación efectuadas en el

mismo mundo donde los actores o eventos son controlados por humanos, scripts

2 Marco teórico 19

o elementos con inteligencia artificial. [11]. Esta técnica captura cierto punto de

vista de un mundo virtual, la graba, edita y exhibe.

2.2. Workshops: Técnicas en Ingeniería de Requisitos

Este trabajo utiliza los conceptos de la técnica de Workshops ofrecidos por

el libro by Requirements by Collaboration [8] que define un workshop como “una

reunión estructurada donde un grupo de involucrados con el proyecto y expertos

en determinado dominio fue cuidadosamente seleccionado para definir, crear,

redefinir y concordar en entregables que representen los requisitos de los

usuarios”.

Workshops para la captura de requisitos, es un variante de la técnica de

IBM denominada Joint Application Design (JAD), también conocida como Joint

Application Development [12]. La propuesta del libro [8] es ofrecer una guía para

planificar, diseñar y ejecutar workshops colaborativamente.

En este texto aparecerá la palabra Workshops con la primera letra en

mayúscula cada vez que se haga referencia a esta técnica y en minúscula

cuando puede ser aplicado a cualquier tipo de workshop.

Los ingredientes de un workshop

Para realizar un workshop, Gottesdiener [8] ofrece los siguientes

“ingredientes” (propuesta de mejores prácticas en Workshops) para manejar los

aspectos impredecibles de este tipo de reuniones para los participantes.

1. Propósito compartido. –El propósito del workshop debe ser definido y

comunicado a los participantes desde el inicio.

2. Personas adecuadas. –Las personas adecuadas y en el momento

correcto deben ser reunidas para realizar el workshop.

3. Ambiente común. – Los participantes podrían estar en el mismo

ambiente o en ambientes distribuidos. Debe crearse un ambiente apropiado con

todas las herramientas necesarias para realizar las actividades del workshop.

4. Grupos variados. - Se debe considerar la diferencia de conocimiento,

experiencia y personalidad que existen en los grupos de clientes, usuarios y

desarrolladores de software. Los facilitadores deberán reconocer las fortalezas y

debilidades de cada uno de ellos.

5. Trabajo Previo. – Un workshop es un proceso que requiere de entradas.

Este material debe ser preparado con anticipación para que el workshop no

tenga retrasos y las actividades programadas ocurran adecuadamente.

2 Marco teórico 20

6. Preguntas dirigidas. – El flujo de trabajo del grupo es dirigido por las

preguntas. Deberán definirse las preguntas adecuadas para el momento

adecuado.

7. Juego serio. – Se podrán programar actividades recreacionales para

que los participantes contribuyan a encontrar requisitos incompletos o

incorrectos.

8. Confianza. – Se deberá reforzar la seguridad entre los participantes y la

confianza mutua.

9. Proceso variado. – Dependiendo de las actividades a realizar, éstas

podrán ser distribuidas individualmente, en subgrupos o para todo el grupo.

10. Prueba de aceptación. – Un grupo de criterios establecidos para

aceptar el entregable.

11. Cierre colaborativo. – Se deberá seleccionar el tipo de participación

para tomar decisiones que sean congruentes con el objetivo del workshop y que

satisfagan las ideas de los participantes.

12. Estructura flexible. – Se debe tomar en cuenta que las actividades

planeadas pueden cambiar o pueden ser ajustadas.

13. Dos lados del cerebro. – Se debe tomar en cuenta que los participantes

son todos diferentes y las capacidades deben ser explotadas. El lado derecho de

los cerebros es mas visual lo que contribuye con la intuición mientras que el lado

izquierdo es más linear y analítico lo que contribuye con la exactitud.

14. Retroalimentación frecuente. – Si algún punto en el workshop no fue

claro o si ocurre algún problema, la estructura del workshop deberá ser lo más

flexible posible para retroceder y revisar este punto.

2.3.Técnicas para el desarrollo del juego

El desarrollo del juego combina técnicas de desarrollo de software y

juegos. Estas técnicas son: Proceso de prototipación para definir la metodología

a seguir, técnicas para el diseño del juego (Branching Stories, escenarios y

maquinas de estados). Este proceso está orientado a desarrolladores de

software y es independiente a la plataforma de desarrollo utilizada.

2 Marco teórico 21

2.3.1. Proceso de prototipación

La creación de este juego utilizará un proceso iterativo e incremental. La

Figura 2 muestra el proceso utilizado basado en el libro Effective Prototyping for

Software Makers [9].

Paso 1. Verificar los requisitos Paso 2. Desarrollar el flujo de tareas

Fas

e 1

Paso 3. Definir el contenido y la fidelidad

Paso 4. Determinar las características Paso 5. Escoger un método

Fas

e 2

Paso 6. Escoger las herramientas

Paso 7. Seleccionar el criterio de diseño

Fas

e 3

Paso 8. Crear el diseño

Paso 9. Revisar el diseño Paso 10. Validar el diseño

Fas

e 4

Paso 11. Implantar el prototipo

Figura 2 The Effective Prototyping Process de [9].

Los 11 pasos del proceso de prototipación están agrupados en 4 fases:

Planificar, especificar, diseñar y resultados. En la fase de planificar se

determinan las necesidades de los prototipos y a organizar el proceso de

prototipación para luego determinar qué aspectos del software serán o no

prototipados. En la segunda fase, se especifican los elementos necesarios

(características, método y herramientas) para cubrir las decisiones tomadas en la

fase de planificación. La fase de Diseñar es la ejecución del prototipo utilizando

criterios de diseño que se deben definir. En la última fase, se obtienen los

resultados desde la revisión, validación e implantación del prototipo.

2.3.2. Branching Stories

Aldrich [5] identificó cuatro géneros tradicionales para la simulación de

juegos: Branching Stories, modelos basados en juegos, hoja de cálculo

interactiva y laboratorios/productos virtuales. Este trabajo utilizará el género de

Branching Stories para generar diversas situaciones donde el estudiante deberá

2 Marco teórico 22

seleccionar el camino a seguir. La Figura 3 muestra la topología de una

estructura de Branching Stories.

Figura 3 Estructura de Branching Stories de [5].

Los caminos de un juego en un grafo de Branching Stories son presentados en

forma de preguntas con varias alternativas de respuesta que guiarán al

estudiante a nuevos caminos o rutas cerradas, dependiendo de las decisiones

tomadas. Este género tiene un impacto en la decisión tomada lo que permitirá al

estudiante encontrar el camino correcto. Si el camino seleccionado no fue el

adecuado, no podrá completar el camino u obtendrá los resultados de sus

acciones.

2.3.3. Escenarios

Escenarios es una técnica de especificación de requisitos usada para

describir situaciones con énfasis en el comportamiento del ambiente. La Figura 4

muestra la instanciación de uno de los escenarios de TREG utilizando la plantilla

basada en [13].

La técnica de Escenarios [13] es usada para especificar el juego. Las

excepciones de la plantilla guían los caminos que puede seguir el jugador y

mantienen los caminos definidos en el grafo de Branching Stories.

2 Marco teórico 23

Scenario

ID: WS001

Title: Right People Context

Goal: Define the initial state of the Right People Ingredient in the workshop

technique. The trainee must select the Right People for the workshop.

Context: A new session will start. The trainee role plays as the Workshop

Facilitator, 3 participants are seated around the table and 5 are stand in the environment.

Resources: Boards with descriptions, table and 7 chairs.

Actors: Trainee, Non Player Characters (NPCs)

Episodes:

1. There is described the project case:

o Company Pookysoft sells computers and accessories in the country.

o Project purpose: The TREG system will administrate: the stock, the

requests (on line and at the store), the product tracking and the customer

registration.

o Workshop purpose: Identify the primary use cases focus on the sales

module.

2. The roles and NPCs characteristics are exposed:

o 3 NPCs are seated around the table. These NPCs will participate in the

meeting. The Finance Manager as an Indirect User, the Requirement

Analyst as a content participant and a Administrative Assistant as the

Recorder. There is a chair reserved for the Facilitator (trainee).

o 5 NPCs are located in the “Making Workshop” room. The characteristics of

these NPCs are presented in Table 1.

o The trainee must select 1 of the 4 arrangements of participants for sitting in

the 3 free chairs for the workshop:

a) Project Sponsor, Direct User 1, Direct User 2

b) Project Sponsor, Direct User 1, Workshop Sponsor

c) Direct User 1, Direct User 2, Direct User 3

d) Direct User 1, Direct User 2, Workshop Sponsor

3. The trainee selects the option c.

4. When 2 go to WS002

Exceptions

Go to WS003 when student selects option a.

Go to WS004 when student selects option b.

Go to WS005 when student selects option d.

Otherwise go to WS001

Figura 4 Escenario del Ingrediente Personas adecuadas.

2.3.4.Diagramas de clases

Un diagrama de Clases representa las clases que serán utilizadas dentro

del software, las relaciones que existen entre ellas, y sus operaciones y

atributos. Los diagramas de Clases por definición son estáticos, esto es,

2 Marco teórico 24

representan que partes interactúan entre sí, no lo que ocurre en un determinado

momento. Estos diagramas son comúnmente usados para [14]:

� Explorar conceptos en forma de un modelo de dominio.

� Analizar los requisitos en forma de un modelo conceptual o de

análisis.

� Describir detalladamente un diseño orientado a objetos.

2.3.5.Diagramas de comunicación

Un diagrama de comunicaciones, inicialmente llamado un diagrama de

colaboración, es un diagrama de interacción que muestra información similar a

los diagramas de secuencia pero su foco principal es en la relación de objetos.

[14]. Los diagramas de comunicación representan una combinación de

información tomada desde el diagrama de clases, secuencia, y diagrama de

casos de uso describiendo tanto la estructura estática como el comportamiento

dinámico de un sistema.

El diagrama de comunicación modela el flujo de mensajes entre los objetos

o partes de ellos en la programación orientada a objetos. Los objetos se

relacionan con conectores de asociación entre ellos. Los mensajes se agregan a

las asociaciones y se muestran como flechas cortas apuntando en la dirección

del flujo del mensaje. La secuencia de los mensajes se muestra a través de un

esquema enumerado [14].

2.3.6.Maquinas de estados

Una máquina de estados define el comportamiento dinámico de objetos,

casos de uso y sistemas completos. Un diagrama de máquinas de estados es

una representación gráfica de los posibles estados de un objeto, los eventos que

causan la transición entre uno y otro estado y las acciones desencadenadas por

el cambio de estados [14].

Un estado representa una etapa en el comportamiento patrón de un objeto.

El estado inicial del objeto, también conocido como estado de creación, ocurre

cuando es creado, por otro lado el estado final determina el fin de las

transiciones en el objeto. Una transición es un cambio de un estado a otro y es

desencadenada por un evento.

2 Marco teórico 25

Figura 5 Diagrama de estados de uno de los elementos de TREG

La Figura 5 muestra el diagrama de estados de uno de los elementos de

TREG usando la notación UML. Las fechas que llevan de un estado a otro toman

el nombre de transiciones y en la figura se muestran sus etiquetas (entre

corchetes) que son las condiciones que llevan al cambio de evento. Asimismo,

en esta figura cada estado está representado un rectángulo con los bordes

redondeados y posee el nombre del estado y las acciones que realiza el estado

cuando es invocado.

2.4.Trabajos relacionados

Los juegos son una propuesta no tradicional para el entrenamiento en

ingeniería de requisitos [15]. Hay algunos ejemplos en este campo pero ninguno

desarrollado en un mundo virtual. RE-O-Poly explora las mejores prácticas en

Ingeniería de Requisitos usando un tablero basado en el clásico juego de

Monopolio [16]. El proyecto FAB ATM desarrollado por la Universidad de Deakin,

combina simulaciones con actividades realizadas en clases para la enseñanza

de principios de IT/IS e Ingeniería de Requisitos [17].

Los mundos virtuales son un ambiente efectivo para juegos educacionales

[18]. Second Life posibilita la creación de contenidos educacionales como clases,

paneles de discusión y juegos [4]. Ohio University desarrollo dos juegos

multiusuarios en Second Life para la educación en Ingeniería de Software [19].

El primero se basó en un ejercicio denominado Groupthink Software

Specification Exercise [20] que tiene como objetivo enseñar cómo escribir

2 Marco teórico 26

especificaciones correctamente. La Figura 6-A muestra una experiencia de una

sesión de este ejercicio en Second Life. Este juego está disponible para usar en

la isla de esta universidad [21]. El otro juego fue desarrollado tomando como

base el juego SimSE donde los estudiantes simulan la gestión de un proyecto de

software [22]. Este juego se encuentra disponible en [23].

Figura 6 A Groupthink game (A). Hospital Scenario en Play2Train (B)

El entrenamiento a través de juegos se muestra como un camino para

mejorar las habilidades de las personas de una forma entretenida. Actualmente,

empresas y universidades están en nuevas formas de entrenamiento en Second

Life. De este modo, Idaho State University desarrolló juegos basados en

simulaciones para entrenamiento. Un juego para entrenamiento en larga escala

fue creado para simular los principales ejercicios del cuidado de la salud y

preparación para emergencias. [24]. La Figura 6 -B muestra el escenario de un

hospital donde el ejercicio de la pandemia de fiebre fue simulado [25]. IBM

desarrolló una serie de juegos llamada Open Encounters of z Virtual Kind for

challenging skills in IBM technologies and Open Source. Estos juegos intentan

mejorar las habilidades de los usuarios de herramientas de IBM como IBM

System z mainframe, Service Oriented Architecture (SOA), the Cell/B.E.

processor, Grid computing, Linux, Java, entre otras tecnologías [26].


3 Características y aspectos del desarrollo de TREG

En este capítulo se hace una explicación de las características del juego y

el desarrollo de los dos aspectos del juego: el contenido educacional y el

software. El contenido educacional de TREG es basado en simulaciones de 4

ingredientes para la planificación de Workshops [8]: Personas Adecuadas,

Propósito Compartido, Trabajo Previo, Espacio Compartido. El diseño del

software combina técnicas de desarrollo de juegos y software, las cuales son

adaptadas para este juego en Second Life.

3.1. Características del juego

TREG es un juego serio cuyo objetivo es entrenar en la técnica de

Workshops de Ingeniería de Requisitos usando simulaciones. La audiencia

esperada son los involucrados con el desarrollo de cualquier proyecto de

software o quien desee ser entrenado en esta técnica: estudiantes, clientes,

usuarios o desarrolladores de software. Las principales características del juego

son las siguientes:

• Dos aspectos del juego se tienen que tomar en cuenta para desarrollar

TREG. Un contenido educacional que brindará los conceptos básicos de

Workshops en forma de simulaciones y el diseño del juego.

• Para mantener a los jugadores inmersos en el juego, se utilizó una

metáfora que combina una tarea común con simulaciones de workshops.

En la metáfora de la cocina, el jugador participa con el rol del chef para

encontrar los ingredientes correctos de la receta de planificar workshops.

Dos ambientes son generados: La cocina y el cuarto de simulación de

Workshops. La Figura 7 muestra estos dos ambientes.

• Second Life es utilizado como plataforma de desarrollo del juego. El editor

de construcción y de scripts de Second Life fueron usados para modelar

objetos 3D y para dar comportamiento a estos objetos.


Figura 7 La metáfora de la cocina y el cuarto de simulaciones de Workshops.

• El editor de construcción en Second Life es utilizado para modelar todos

los objetos 3D del juego. La estructura, textura, iluminación y

características físicas de cada prim pueden ser cambiadas y además,

puede vincularse con otros prims para obtener la forma deseada. Es así

como se crearon los objetos en TREG: el área de recepción, el cuarto de

metáfora, el cuarto de simulación de Workshops, los NPCs y el head-up-

display (HUD).

• El editor de scripts de Second Life posibilitan la edición y compilación de

los scripts en el mundo. El comportamiento de los objetos es dado a través

de scripts programados en el lenguaje de Second Life: LSL (Linden Script

Language). Este es un lenguaje orientado a eventos con una estructura

que se asemeja a C o Java. Entre otros comportamientos modelados,

estos scripts son usados para teletransportar los avatares, programar el

HUD, comunicar objetos con avatares u otros objetos, mostrar videos y

efectos visuales como el fuego de una cocina.

• Los NPCs son objetos controlados por medio de scripts con apariencia de

avatares. TREG utilizará a los NPCs como guías dentro del juego y como

elementos de interacción en las simulaciones de los workshops.

• Machinima es usado para filmar a los NPCs y diversas situaciones en las

simulaciones de los workshops. Por ejemplo, cuando el jugador está

siendo entrenado en el “ingrediente” de las Personas adecuadas, un video

hecho con la técnica machinima muestra las problemática de seleccionar

personas no adecuadas para un workshop específico.

• El HUD registra la participación del jugador y controla su puntuación:

puntos y cantidad de ingredientes que el jugador va acumulando.

• El juego presenta un agente como guía de uso. Este guía es un NPC

específico que brindará, cuando sea necesario, información al usuario de

los pasos a seguir en el juego. La implementación de estos NPCs fue


utilizando agentes de software. Un agente es una entidad computacional

como un programa de software o un robot que percibe y reacciona sobre

su ambiente y tiene un comportamiento autónomo [27] Estos guías, a

través de su autonomía y conocimiento del ambiente del juego, envían

mensajes al jugador para ayudarlo a seguir en el juego [28]. La Figura 8

muestra al NPC guía, Miss Workshop.

Figura 8 Miss Workshop, el NPC guía.

Para poder entender mejor la funcionalidad de TREG desde la perspectiva

del jugador, la Figura 9 muestra un diagrama de las actividades que éste seguirá

para completar el juego. Además, el Apéndice D muestra los ambientes de

TREG y las simulaciones en cada ingrediente.

1. El jugador obtiene una receta

2. Por cada ingrediente de la receta, el jugador tendrá que seleccionaruna respuesta. Se muestra lasimulación y respuesta asociada

ActCheck

DoPlan

3. El jugador obtiene elingrediente.

Son todos los ingredientes?Si No

Mas recetas?Si

Comida lista

1. El jugador obtiene una receta

2. Por cada ingrediente de la receta, el jugador tendrá que seleccionaruna respuesta. Se muestra lasimulación y respuesta asociada

ActCheck

DoPlan

3. El jugador obtiene elingrediente.

Son todos los ingredientes?Si No

Mas recetas?Si

Comida lista Figura 9 Funcionamiento de TREG desde la perspectiva del jugador.


3.2.Contenido Educacional

El contenido educacional, como se mencionó anteriormente, está basado

en el libro “Requirements by Collaboration”. En este libro, la técnica de

Workshops es analizada y un proceso de desarrollo de workshops es propuesto.

El contenido educacional se basa en los ingredientes para realizar workshops,

los cuales fueron agrupados siguiendo este proceso y las características de cada

ingrediente. La Figura 10 muestra esta distribución realizada.

Figura 10 Distribución de los ingredientes en el proceso de Workshops

La receta Planificar se adecuó al contenido educacional del TREG. La

creación de este contenido educacional se divide en 3 actividades principales:

� Identificar los problemas que existen en cada uno de los

ingredientes para workshops exitosos descritos por el libro

“Requirements by Collaboration” [8].

� Posteriormente se elaborará los escenarios de las simulaciones del

ingrediente.

� Una o varias soluciones para los problemas de las simulaciones

serán identificadas usando la siguiente bibliografía "Facilitator’s

Guide to Participatory Decision-Making" [29] y “Requirements by

Collaboration” [8].

Receta: Planificar

1) Personas Adecuadas

2) Propósito Compartido

3) Trabajo Previo

4) Espacio Compartido

Receta: Revisar 10) Pruebas de aceptación

& Cierre colaborativo

Receta: Realizar

5) Preguntas Dirigidas

6) Juego Serio

7) Confianza & Grupos

Variados

8) Proceso Variado &

Estructura Flexible &

Retroalimentación

9) Dos lados del cerebro


Además, se puso a disposición del jugador, información adicional sobre

cada uno de los ingredientes basada en el libro [8]. Esta información se dispuso

en el objeto “Learn More” del Panel de Simulación de TREG.

� Personas Adecuadas: Información sobre el ingrediente, Roles

dentro de Workshops, el Facilitador y tips sobre el ingrediente.

� Propósito compartido: Información sobre el ingrediente, declaración

del propósito del workshop, estrategias de navegación y tips sobre

el ingrediente.

� Trabajo Previo: Información sobre el ingrediente, documentos de

salida de un workshop, documentos de entrada de un workshop y

tips sobre el ingrediente.

� Espacio compartido: Información sobre el ingrediente, workshops

en síncronos/asíncronos y distribuidos/en el mismo lugar, logística

para un workshop y tips sobre el ingrediente.

La especificación de cada uno de los ingredientes se realizó utilizando una

plantilla de Escenarios, tal como se detalla en la sección 3.3. Los apéndices D3,

D4, D5 y D6 muestran las capturas de pantalla de un participante jugando los

cuatro ingredientes. A continuación se detalla la información que utilizó el juego

para crear el contenido educacional.

3.2.1. Personas Adecuadas

El ingrediente de Personas Adecuadas acelera el desarrollo del workshop

al reunir a las personas adecuadas para un determinado workshop, en el

momento y lugar adecuado. Los riesgos relacionados a encontrar estas

personas son [8]:

• Tener que recurrir a usuarios sustitutos en lugar de usuarios directos.

• Gastos relacionados a las despensas de viaje, cuando es el caso.

• No contar con personas que tomen decisiones en el workshop.

• Involucrar personas que no tengan interés en trabajar por los

productos del workshop.

Se decidió prototipar un ambiente que simule un workshop para mostrar

los roles de un Workshop, la función del Facilitador y la importancia de

seleccionar a las personas adecuadas. En este ambiente, el objetivo del

ingrediente es seleccionar 3 de 5 participantes para un determinado workshop.


El propósito del workshop será: Identificar los casos de uso primarios del módulo

de ventas de la empresa Pookysoft. La Tabla 1 muestra los problemas que el

jugador deberá afrontar para poder decidir por uno u otro participante.

Se proponen 4 alternativas de selección:

1. Project Sponsor, Usuario Directo 2, Usuario Directo 3

2. Project Sponsor, Usuario Directo 3, Workshop Sponsor

3. Usuario Directo 1, Usuario Directo 2, Usuario Directo 3

4. Usuario Directo 1, Usuario Directo 2, Workshop Sponsor

Tabla 1. Pros y contras de los posibles participantes al workshop

Rol Cargo Pros Cons

Project Sponsor

Vice-presidente

- Entiende el propósito del proyecto y como este ayudará a la organización.

- Tiene autoridad financiera e influencia organizacional.

- No es un experto en el área lo que es necesario para este workshop.

- Suele hablar mucho y es muy persuasivo.

Usuario Directo 1 (Content Participant)

Jefe de Recursos Humanos

- Trabajo como usuario principal por 3 años

- Es uno de los que más sabe sobre el sistema.

- Su día a día puede ser complejo.


Asistente de ventas

- Tiene buen conocimiento y experiencia en el negocio.

- Es nueva en la organización.

- Es inteligente pero tímida.


Director de Producción

- Tiene total disponibilidad para los workshops.

- Algunas veces sus respuestas son influenciadas por el Project Sponsor.

Workshop Sponsor

Analista del Negocio

- Tiene una buena relación con el Project Sponsor.

- Tiene experiencia como workshop sponsor.

- Sólo puede estar presente en el kick off y el cierre.

Se utilizó la técnica de Escenarios para especificar los problemas y

soluciones de cada selección en este ingrediente en los nodos WS03, WS04,

WS05 y WS06 del grafo de Branching Stories (ver en la sección 3.3.2).

3.2.2. Propósito Compartido

La técnica de elicitación de requisitos con Workshops propone comenzar el

workshop teniendo en claro cuál es el propósito del mismo definiendo quien,

como, que, donde y cuando. Esta técnica aclara que la definición del propósito


del workshop puede parecer muy obvia para muchas personas pero preguntando

a los stakeholders sobre el propósito puede implicar en una redefinición del

mismo o puede involucrar supuestos [8].

En este ingrediente, al igual que en el de Personas Adecuadas, se propuso

utilizar la interacción con los participantes de un workshop. Para este fin, se dio

el propósito del workshop y el jugador tenía que compararlo con las respuestas

de los participantes. Se definió como el propósito del workshop: Validar el

alcance del proyecto y los requisitos de alto nivel.

Tomando como referencia un ejemplo del libro donde expone diversas

historias que los participantes dan sobre el propósito del workshop, se creó el

siguiente diálogo con los participantes en TREG:

� Sara Johnson (Analista de requisitos): Estoy preocupada porque no

consigo entender los requisitos y me gustaría refinar el alcance.

� Andrea Richmond (Asistente de ventas): El propósito del workshop

es definir el alcance y crear los requisitos de alto nivel.

� Sophia Amat (Jefe de Finanzas): Vamos a revisar la visión y los

requisitos de alto nivel.

� Bob Miles (Programador): No me gustan las solicitudes de cambio.

Debemos confirmar la validez de los requisitos que ya fueron

capturados.

El jugador deberá seleccionar cuál es el participante mas confundido. De

esta forma se intenta mostrar al jugador la importancia de tener un propósito de

workshop establecido, claro y compartido entre los involucrados del proyecto.

3.2.3. Trabajo Previo

Gottesdiener [8] define a un workshop como un proceso que tiene

entradas, salidas y transformaciones. El Trabajo Previo es utilizado para

establecer las entradas del workshop como la redacción de borradores de los

requisitos, agenda, herramientas o plantillas. Asimismo, define que los requisitos

pueden dividirse a través de iteraciones del workshop cuando existen

limitaciones de tiempo o si el grupo es relativamente nuevo.

La Figura 11 presenta un workshop dividido en iteraciones para la captura

de requisitos. En esta figura se muestran los documentos en cada una de las

iteraciones utilizados: trabajo previo (documentos de entrada en cuadrados),

trabajo posterior (documentos de salida dentro de cada círculo) y el

aseguramiento de la calidad (QA). En TREG, aparece en el cuarto de simulación,


el trabajo posterior de esta figura y desordenadamente todos los documentos del

trabajo previo necesario para los tres workshops. El jugador deberá posicionar

en cada recuadro de las entradas (Trabajo Previo), el documento que

corresponde para poder iniciar la iteración del workshop.

Figura 11. Iteraciones de un Workshops. Trabajo Previo de [8]

El objetivo de aprendizaje en este ingrediente será entender la importancia

de elaborar y esbozar documentos necesarios para poder llevar a cabo cada

workshop para la captura de requisitos.

Glosario

Tabla de eventos /

Diagrama de

Contexto

Nombre y breve

descripción

del caso de uso

Iniciando

actores

Mapa de

Actores

Mapa de Casos

de Uso

Requisitos No funcionales: Frecuencia Prioridad

Workshop 1

Políticas de Negocio

por caso de uso

Borrador del Modelo

de datos

Descripción

paso a paso del

caso de uso

Reglas del

negocio

Ventanas de

Prototipos

Paquetes de

Casos de Uso

Mapa de Casos de Uso

Plantilla de Reglas

del negocio

Escenarios

Modelo de Datos

Extensión de las

Reglas del

Negocio

Estrategia de

Implementación

Extensiones de

Casos de Uso

Workshop 3

Paquetes de Casos

de Uso

QA

QA

QA


3.2.4. Espacio Compartido

El ingrediente de Espacio Compartido no incluye simplemente la

preparación de una sala. Incluye a los espacios y herramientas que posibilitan

que el contenido sea compartido entre los participantes [8]. La técnica de

Workshops descrita en el libro [8] incluye principalmente reuniones en las cuales

los participantes están en el mismo lugar y en el mismo tiempo. Sin embargo,

también explica que es posible variar entre estas dos dimensiones (espacio y

tiempo) para proveer otros tipos de experiencias colaborativas.

Figura 12. Dimensiones de espacio y tiempo en las reuniones [8].

La Figura 12 muestra las formas de realizar workshops en función las

combinaciones de tiempo y lugar, y las herramientas que pueden ser utilizadas

en cada caso. En TREG, de manera similar al ingrediente Trabajo Previo, el

jugador deberá colocar correctamente cada una de las herramientas en la

dimensión correspondiente.

El objetivo de aprendizaje de este ingrediente es mostrar al jugador que los

workshops no siempre son realizados en el mismo tiempo y en el mismo lugar.

Es así como deben proveerse herramientas para poder llevar a cabo cualquier

tipo de workshop.


3.3. Diseño de TREG

El diseño del software combina técnicas para poder implementar las

simulaciones del contenido educacional en Second Life: El género Branching

Stories da al jugador la opción de seleccionar una respuesta a preguntas con

varias alternativas [5]. Esta respuesta tiene un impacto de decisión que

conducirá jugador hacia diferentes caminos. La técnica para especificar la

funcionalidad del software es Escenario [30] y es usada para describir las

diversas situaciones simuladas en el juego. Todos estos escenarios están

conectados formando una red de relaciones usando un grafo de Branching

Stories. Finalmente, 3 diagramas de UML fueron adaptados para este desarrollo.

Un diagrama de clases da una visión general de los objetos necesarios en TREG

y el diagrama de comunicación muestra los mensajes enviados entre los objetos

en cada uno de los escenarios. Los diagramas de máquinas de estados darán la

perspectiva del funcionamiento de cada objeto de TREG y facilitarán la

implementación en LSL, siendo posible la implementación de estados en este

lenguaje.

Figura 13 Proceso de Diseño de TREG

La Figura 13 muestra el proceso de diseño de TREG. De esta forma es

posible tener una visión general de todos los caminos posibles en el juego

(Branching Stories), la especificicación detallada de estas situaciones

(Escenarios) y el modelamiento de los objetos de TREG (diagrama de clases, de

comunicación y de máquinas de estados).

Ingredientes

de Workshops

Patrones de

Colaboración

Branching

Stories

Escenarios Diagramas


3.3.1. Branching Stories en TREG

Los primeros intentos de prototipación del juego fueron realizados con

Storyboards [31]. Desafortunadamente esta técnica no funcionó por el consumo

de tiempo que ocasionaba la elaboración dichos Storyboards. Para crear los

sketches se utilizaba Second Life y luego se pasaba las imágenes de este

producto a los Storyboards. Se consideró que era un paso innecesario pasar el

ambiente 3D a un formato 2D que perdía interacción para realizar las

validaciones. De esta forma surgió la necesidad de tener prototipos que puedan

ser validados en el mismo ambiente de producción.

Se usó un grafo de Branching Stories para conectar todos los escenarios

de TREG. Este grafo da una visión general del juego y favorece el análisis de la

secuencia de escenarios a través de las conexiones creadas.

Figura 14. Grafo de Branching Stories de TREG.

La Figura 14 muestra los escenarios de TREG y sus conexiones usando

un grafo de Branching Stories. En la figura se puede observar los 9 nodos que

corresponden a cada situación que puede ocurrir en el juego. Las flechas indican

los caminos posibles del jugador en TREG. Los nodos WS03, WS07, WS08 y

WS09 corresponden a los 4 ingredientes de Workshops. Se puede observar que

del nodo WS03 se desprende 3 caminos diferentes para WS04, WS05 y WS06.


Estos nodos corresponden a decisiones que el jugador seleccionó que conducen

a fallas en la selección de las personas adecuadas. La retroalimentación para el

jugador en este ingrediente, a diferencia de los otros, fue dada a través de las

machinimas. Cuando el jugador encuentra todos los ingredientes, el juego

finaliza.

Aldrich [5], identifica varios beneficios de aplicar Branching Stories en

simulaciones. A continuación se muestran los beneficios que fueron tomados en

cuenta para la creación de TREG.

• El jugador aprende cada vez que toma una decisión. El impacto de

estas decisiones involucra el entendimiento de la técnica de

Workshops.

• Facilita el entrenamiento dado que cada nodo tiene información sobre

donde se encuentra el jugador y que información le podría ser útil.

• La retroalimentación es dada al final de cada camino. La puntuación

expone el impacto que tiene la decisión del jugador en cada

simulación.

• Deja abierta la posibilidad de intentar y errar.

3.3.2. Escenarios de TREG

La técnica de Escenarios asegura el entendimiento y la colaboración de los

participantes en el proceso de definición de requisitos. [30]. Dado que TREG

utilizó Branching Stories para construir todos los caminos posibles del jugador, la

técnica de Escenarios permitió la especificación detallada de la interacción con

TREG desde el punto de vista del jugador y mantuvo la secuencia de los

caminos en el juego. Por medio de una plantilla de Escenarios [13] se logró

describir en cada nodo la secuencia de pasos seguidos por el jugador en TREG

y a través de su sección de excepciones, se mantienen las conexiones del grafo

y guían en la secuencia del juego

La Figura 15 muestra la plantilla utilizada e instanciada para contextualizar

el ingrediente de Personas Adecuadas. En los Apéndices A.1, A.2 y A.3 se

muestran los demás escenarios creados para la especificación del ingrediente de

Personas Adecuadas.


Escenario

ID: WS03

Título: Personas Adecuadas. Contexto inicial.

Objetivo: Define el estado inicial del ingrediente Personas

Adecuadas. El jugador deberá seleccionar las personas que van a participar en un determinado workshop.

Contexto: Una nueva sesión será iniciada. El jugador participa como

el facilitador del workshop, 3 participantes están sentados alrededor de la mesa y 5 están de pie.

Ambiente: Cuarto de simulación

Recursos: Una mesa con 7 sillas, 8 NPCs y el panel de simulación.

Actores: El jugador, Non Player Characters (NPCs)

Episodios:

Se muestra al jugador

El propósito del workshop: Identificar los casos de uso primarios del módulo de ventas.

Las 4 posibles combinaciones de participantes al workshop.

El jugador se comunica con los NPCs y obtiene sus características. Estas características se presentan en la Tabla 2.

3 NPCs se encuentran sentados en la mesa del workshop. Estos NPCs participarán del workshop. El jefe de Finanzas como usuario indirecto, el analista de requisitos como content participant y el asistente administrativo como Recorder. Existe una silla preservada para el Facilitador (el jugador).

5 NPCs se encuentran de pie en el cuarto de simulación.

El jugador deberá seleccionar 1 de las 4 combinaciones de participantes para sentar en las 3 sillas disponibles. Estas combinaciones son:

Ethan Harris, Andrea Richmond, Brianna Rosebud

Ethan Harris, Brianna Rosebud, Olivia Devoix

Elias Callisto, Andrea Richmond, Brianna Rosebud

Elias Callisto, Andrea Richmond, Olivia Devoix

El jugador selecciona la opción c.

El jugador gana el ingrediente de Personas Adecuadas.

El HUD del jugador incrementa 100 puntos y adiciona un ingrediente.

Excepciones:

Ir a WS002 cuando el jugador selecciona la opción a.

Ir a WS003 cuando el jugador selecciona la opción b.

Ir a WS004 cuando el jugador selecciona la opción d.

Figura 15. Escenario WS03 del ingrediente de Personas Adecuadas


Tabla 2. Participantes al workshop y sus características

NPC Característica

“Soy Ethan Harris, el Vice-presidente de Pookysoft

Entiendo y apoyo el propósito del proyecto pero no soy un experto en el área.”

“Un placer de conocerte. Mi nombre es Elias Callisto y soy el Jefe de Recursos Humanos.

Trabajé con el sistema anterior por 3 años y ayudé a crearlo.”

“Hola, Soy la asistente de ventas. Mi nombre es Andrea Richmond.

Tengo conocimiento y experiencia en el negocio pero soy nueva en la organización.”

“Soy Brianna Rosebud y mi puesto en PookySoft es de Analista del Negocio

Tengo total disponibilidad para participar de los workshops.

“Soy Olivia Devoix, Directora de Producción de PookySoft.

He trabajado anteriormente como Workshop Sponsor. Lamentablemente, solo podría participar del kick off y el cierre del proyecto. Tengo una buena relación con el Vice-presidente.”

“Yo soy Kate White y trabajo en PookySoft como la Jefa Regional de Finanzas.

Trabajé con todos los reportes del sistema anterior. Andrea (la nueva asistente de ventas) es muy inteligente pero debo admitir que es muy tímida.”

“Mi nombre es Sarah Johnson. Soy una Analista de Requisitos.

Desarrollé el sistema anterior. Debo admitir que el Sr. Harris (el Vice-presidente) habla demasiado y es muy persuasivo. Por otro lado, el tiene autoridad financiera en Pookysoft y una gran influencia organizacional. “

“Soy el asistente administrativo, Joshua Moore

Tengo ya un tiempo colaborando con las reuniones y estoy familiarizado con la documentación.

Brianna (Directora de producción) tiene experiencia en Workshops pero algunas veces sus respuestas están influenciadas por el vice-presidente.”


3.3.3. Modelamiento de TREG

A partir de la especificación del juego generada usando la plantilla de

Escenarios, se pudo: determinar los objetos necesarios a implementar, utilizar

diagramas de máquinas de estados para capturar la perspectiva dinámica del

sistema, estructurar la comunicación entre elementos e implementar en LSL. A

pesar de que LSL no se trata de un lenguaje orientado a objetos, se adaptó

estos diagramas para tener la visión deseada del software.

3.3.3.1.Diagrama de clases en Second Life

Se utilizó un diagrama de clases en TREG para representar los objetos

creados en el juego y tener una visión del paso de mensajes entre ellos y la

dirección de los mensajes. Esta es una adaptación del diagrama de clases para

modelar los objetos de TREG. Los objetos de TREG no pueden ser vistos de la

misma forma que las clases u objetos en UML:

� LSL no es un lenguaje orientado a objetos, sí a eventos.

� Los objetos en TREG no poseen atributos ni operaciones, estos

poseen características del objeto 3D y eventos.

� Las únicas relaciones que existen entre los objetos de TREG son

relaciones de comunicación entre objetos. Estas se realizan

abriendo un canal de chat de Second Life y enviando un mensaje a

través de dicho canal.

No se utilizó un diagrama de objetos de UML dado que en nuestra

representación, al igual que las clases de UML, los objetos de TREG pueden

tener varias instancias con el mismo comportamiento. Por ejemplo, todos los

NPCs que interactúan con el jugador en el ingrediente de Personas Adecuadas

tienen la misma funcionalidad: aparecen en el ambiente, se comunican con el

jugador y desaparecen del ambiente.

La Figura 16 muestra un diagrama de clases que representa los objetos

con comportamiento de TREG y la comunicación existente entre ellos. Las

clases presentadas en la figura presentan a los objetos de TREG que tienen un

comportamiento en el juego y además, se comunican con otros objetos. Por

ejemplo, la clase NPC representa a los Non Player Characters de los

ingredientes de Personas Adecuadas y Propósito Compartido. Se tiene una

relación desde el Panel de Simulación puesto que este es el que crea los objetos


cuando estos ingredientes son simulados. El NPC se comunicará con la clase

Notecard para mostrar la información que corresponde. Asimismo, el NPC recibe

un mensaje del PanelSimulacion_respuestas para simular la opción escogida por

el jugador.

Figura 16. Diagrama de clases para representar los elementos de TREG

A continuación se presenta un listado de estos objetos de TREG y sus

definiciones:

� Teleporter: Objeto del área de recepción que transporta al avatar

del área de recepción para la cocina y comunica que el jugador

llegó a esta área.

� Refri: Objeto ubicado en la cocina que fue modelado con el aspecto

de una refrigeradora y envía la receta al jugador. Además comunica

a Miss Workshop que fue tocada.

� Miss Workshop: Agente de ayuda del juego. Además de

comunicarse con los objetos del ambiente, mantiene comunicación

con el HUD del jugador para saber el avance del jugador.

� HUD: Head-up display que muestra al jugador el puntaje y el

número de ingredientes alcanzados. Recibe información del


ambiente cuando el jugador consigue un ingrediente y se comunica

con el Pot cada vez que se desea terminar el juego.

� Pot: Objeto ubicado en la cocina que representa a una olla.

Termina el juego si es que el jugador consiguió los ingredientes.

� Panel de Simulación: Objeto que contiene todo el control del

ambiente. Este objeto hace aparecer en el ambiente a otros objetos

dependiendo del ingrediente que se requiere simular. Para los

ingredientes de Personas Adecuadas y Propósito Compartido

simula los objetos: NPC, Notecard y MesasSillas. Para los

ingredientes de Trabajo Previo y Espacio Compartido simula los

objetos: Board, Elemento, Clock, Stop. Además, envía la

información del ingrediente simulado a los objetos:

PanelSimulacion_LearnMore y PanelSimulacion_Respuestas para

que estos actualicen la información de acuerdo a este ingrediente.

� Stop: Cuando es activado, para el reloj y envía un mensaje a los

Boards del ambiente para que éstos no reciban más respuestas.

� Clock: Objeto que fue modelado para representar un reloj. Posee la

misma funcionalidad que el objeto Stop.

� Board: Son varios Boards que representan los cuadros

correspondientes al ingrediente simulado. Recibe al elemento

seleccionado y envía información al HUD si es que el jugador

consiguió el ingrediente.

� Elemento: Varios objetos de esta clase son creados dependiendo

del ingrediente. Envían información a los Boards del elemento que

fue seleccionado.

� NPC: Tal como se mencionó anteriormente, representan a

participantes del workshop simulado.

� MesaSillas: Representa a la mesa creada para el ingrediente de

Personas Adecuadas. Contiene la información de los NPCs que

tienen que aparecer en el ambiente cuando una respuesta es

seleccionada.

� Notecard: Contiene la información que será transmitida por el Local

Chat cada vez que un NPC es tocado por el jugador.

� Machinima: Objeto que muestra un machinima de la respuesta

seleccionada.


� Room: Objeto que representa a la ventanas del Cuarto de

Simulación. Recibe un mensaje del Panel de Simulación y abre o

cierra las ventanas dependiendo del ingrediente a ser simulado.

3.3.3.2.Diagrama de comunicación

Con el fin de tener una visión general de las relaciones entre objetos y los

canales de comunicación de los objetos de TREG, se creó un diagrama de

comunicación para cada escenario especificado. La Figura 17 muestra un

ejemplo de la comunicación entre objetos usando el escenario WS03. Personas

Adecuadas – Contexto inicial. El Apéndice A.4 muestra una tabla con todas las

comunicaciones existentes entre los objetos. Otros ejemplos de los diagramas

de comunicación de TREG son mostrados en el Apéndice A.5.

Figura 17. Diagrama de Comunicación del Escenario WS03

Este diagrama muestra el paso de mensajes sólo entre objetos que no

fueron vinculados en TREG, los cuales utilizan el canal de chat para su

comunicación. En este diagrama, las transiciones muestran los eventos en

Second Life que son representados entre corches como por ejemplo touch.


Asimismo, éstas muestran la función que realiza el objeto cuando el evento es

invocado; por ejemplo llSay.

Las consideraciones que se tuvieron al modelar estos diagramas son:

� Los escenarios guiaron el proceso de creación del modelo, dado

que poseen información detallada de la interacción del juego.

� Asimismo el diagrama de clases favoreció la identificación de

objetos a usar y sus relaciones.

� Este diagrama posibilitó la visión de los canales de comunicación y

sus mensajes para no incurrir en repeticiones o confusión en la

recepción del mensaje.

� A diferencia de uso dado al diagrama de clases, en este diagrama

sí se consideran los objetos de TREG como instancias de los

objetos modelados en el diagrama de clases. Por ejemplo, en este

caso el jugador selecciona la opción C que corresponde a los NPCs

Brianna, Andrea y Elias; y estos tienen un comportamiento reactivo

a este evento.

3.3.3.3.Máquinas de estados

El comportamiento dinámico de cada una de las entidades del juego se

muestra en estos diagramas a través de los estados y sus transiciones.

Asimismo, estos diagramas facilitan la implementación en LSL, un lenguaje

basado en estados.

Para realizar la transacción maquinas de estados hacia la implementación

en Second Life, se revisaron las especificaciones de los escenarios relacionados

a cada ingrediente y se analizó el cambio de los objetos en estos documentos. El

diagrama de clases mostró la relación del objeto con otros objetos y el diagrama

de comunicación mostró los eventos que originan transiciones en cada

escenario. Finalmente se tuvo en cuenta los estados cuando se realizó la

implementación en Second Life.

La Figura 18 muestra el diagrama de estados de un objeto NPC en el

ingrediente de Personas Adecuadas. Esta máquina de estados corresponde al

NPC Andrea, posible participante del workshop. Este NPC aparece en el cuarto

de simulación cuando el ingrediente de Personas Adecuadas es seleccionado. El

jugador tendrá una interacción con este elemento al preguntar por sus

características y posteriormente decidir si participará del workshop.


Figura 18. Maquinas de estados de un NPC en Personas Adecuadas

Este diagrama de estados se inicia cuando el NPC es creado en el

ambiente (con la función llRezObject). Con este evento, se activa el estado

por defecto del objeto (selectingParticipants). Este estado pasa al estado

“selected” cuando una de las opciones es seleccionada por el jugador y el objeto

recibe el mensaje “machinima”. Además, el objeto es destruido cuando recibe un

mensaje estado en cualquiera de sus dos estados.

Figura 19. Implementación de estados de NPC de Personas Adecuadas

SelectingParticipants

{ on_rez ()

{ llListen(-71138, "", "", ""); }

listen(integer chn, string name, key id, string msg)

{if (msg = "DieObject" || msg = "rightppl")

{ llDie();}

if (message == "Machinima" )

{ state selected; } }

touch_start(integer total_number)

{ llSay(-8344, "3"); }

}

state selected

{ state_entry ()

{ llListen(-71138, "", "", ""); }

listen(integer chn, string name, key id, string msg)

{if(msg="Solution" ){ state SelectingParticipants;}

if (msg="muere" || msg="rightppl2") { llDie(); }}

touch_start(integer total_number)

{llSay (0,"The participant was selected"); }

}


La Figura 19 muestra la implementación de este diagrama en LSL. En

ésta, se puede observar la correspondencia de los métodos implementados en

LSL con lo modelado en el diagrama de estados. En él se modelaron solo los

eventos que se comunican con otros objetos y no los eventos que comunican los

objetos con el avatar como touch_start. El Apéndice A.6 muestra otros

ejemplos de diagramas de estados usados en TREG.

Como LSL es un lenguaje orientado a eventos y se basa en estados, fue

posible modelar el comportamiento dinámico de los objetos con los diagramas de

máquinas de estados.

4 Prototipos 48

4 Prototipos

El desarrollo de TREG siguió el proceso de prototipación descrito

anteriormente y utilizó la estrategia de ensayo y error para refinar los prototipos

[32]. 5 iteraciones fueron necesarias para redefinir los requisitos y prototipar los

cuatro ingredientes de la técnica de Workshops. Second Life fue utilizada como

la principal herramienta de prototipación. Esta sección relata nuestra experiencia

con el proceso de prototipación del juego, y muestra las características de cada

iteración, los criterios de diseño utilizados y la evolución del producto usando

métodos de prototipación a lo largo de las iteraciones.

4.1.Proceso de prototipación

El proceso de prototipación Effective Prototyping Process [9] fue adaptado

para el desarrollo del juego en Second Life. Los pasos de cada una de las fases

fueron realizados dependiendo del método de prototipación usado en cada

iteración.

4.1.1. Fase 1. Planificar

En esta fase, se deciden qué aspectos del software se prototipará y que

no, validando suposiciones y requisitos.

Paso 1. Verificar Requisitos

Los requisitos del juego fueron descubiertos a partir de suposiciones,

tomando en cuenta la audiencia del juego y sus objetivos. A lo largo del

desarrollo de TREG, estos requisitos fueron reunidos y priorizados usando el

grafo de Branching Stories, teniendo de esta forma una visión general de los

requisitos a verificar.

Paso 2. Desarrollar el flujo de tareas

El flujo de tareas describe los pasos que el jugador tiene que ser para

completar todas las actividades mientras navega por el juego. En este paso,

fueron definidas las tareas y la narración de los escenarios.

4 Prototipos 49

El género de Branching Stories fue usado para mapear los escenarios del

juego. El grafo de Branching Stories da una visión general del juego y guía la

interacción de los diferentes escenarios. La plantilla de Escenarios fue usada

para obtener un mayor detalle de la especificación del juego.

Paso 3. Definir el contenido y fidelidad

En cada iteración fue definido el contenido a ser prototipado, dependiendo

de la iteración desde un contenido a alto nivel que facilitó la definición del

alcance del proyecto hasta el contenido detallado con la información educacional

y con información que define el comportamiento del juego.

Se decidió que Second Life sería la principal herramienta de prototipación.

Por esta razón, la fidelidad necesaria para la mayoría de prototipos fue alta.

4.1.2. Fase 2: Especificar

Esta segunda fase cubre los resultados de las decisiones tomadas en los

tres primeros pasos, donde las decisiones favorecen la determinación de las

características, métodos y herramientas a utilizar en el desarrollo del juego.

Paso 4. Determinar las características

Arnowitz [9] propone 8 características a ser determinadas antes de

seleccionar el método de prototipación a utilizar. Estas características son:

audiencia, etapa, velocidad, duración, expresión, estilo y medio. En la sección

4.2, se detallan las características que fueron determinadas para cada iteración.

Paso 5. Seleccionar un método

Arnowitz [9] propone los siguientes métodos para prototipar: card sorting,

wireframe, storyboard, paper, digital, blank model, video, Wizard-of-Oz y code

prototype. Analizando las características, fueron definidos los prototipos para las

5 iteraciones: Quick Wireframe, Wireframe, Low-coded, High-coded.

Paso 6. Elija una herramienta de prototipación

A pesar de que fue decidido, desde el inicio del proyecto, que Second Life

sería la herramienta de prototipación, fueron necesarias otras herramientas para

aclarar conceptos o especificar funciones como herramientas de ofimática y

herramientas CASE.

4.1.3. Fase 3. Diseñar

Esta fase se centra en la ejecución del prototipo a partir de la planificación

y especificación realizadas en las fases anteriores.

4 Prototipos 50

Paso 7. Seleccionar el criterio de diseño

Si bien es cierto, Second Life promueve la libre creación de contenido, hay

restricciones que se deben tomar en cuenta para modelar objetos y para utilizar

el lenguaje de programación. El proceso de prototipación seguido ofrece guías

para el diseño de páginas webs. Al haberse utilizado un ambiente virtual, se

crearon criterios propios a seguir. La sección 4.3 muestra los criterios de diseño

utilizados en TREG.

Paso 8. Crear el diseño

En este paso fueron aplicados todos los criterios de diseño en el prototipo.

En juegos es importante priorizar los elementos a desarrollar. TREG usó una

estrategia “top-down” que primero lista los principales elementos del diseño y

luego se va profundizando en los detalles de cada uno de los elementos.

4.1.4.Fase 4. Resultados

En esta fase el prototipo es evaluado por una audiencia interna, se realiza

la validación del prototipo y se realiza la implantación o iteración.

Paso 9. Revisar el diseño

El prototipo de TREG fue revisado por una audiencia interna formada por

los investigadores involucrados en este proyecto. En este caso, uno de ellos es

un experto en el contenido de TREG, en procesos de desarrollo de software.

Paso 10. Validar el diseño

Después de la revisión del diseño es necesario validar el prototipo con

stakeholders externos. Estas validaciones se realizaban principalmente con

expertos en Second Life. En la última iteración, se realizaron pruebas de

usabilidad donde todos los participantes estaban familiarizados con el desarrollo

de software y además, correspondían a uno de estos 3 perfiles: expertos en

Second Life, participantes que conocen otro mundo virtual pero no Second Life y

participantes que nunca tuvieron contacto con mundos virtuales. En la sección 5

se muestra en detalle el proceso seguido en estas pruebas.

Paso 11. Implantar el diseño

El ambiente de desarrollo de TREG fue un sandbox localizado en la isla de

la PUC-Rio en Second Life. Sandbox responde a un término usado en Second

Life donde es creada un área especial para la creación y de difícil acceso para

un avatar (normalmente a más de 1000 metros sobre el terreno). Posteriormente,

los prototipos validados son implantados en el área de producción.

4 Prototipos 51

4.2.Características de los prototipos de TREG

La selección del método de prototipación fue dada por las características

del prototipo en cada iteración. Estas características fueron basadas en el

proceso Effective Prototyping Process [9]. La Tabla 3 muestra las características

y el prototipo seleccionado para cada iteración.

Tabla 3. Iteraciones y sus características

Iteración 1 Iteración 2 Iteración 3 Iteración 4 Iteración 5

Audiencia Interna Interna Interna Interna Externa Etapa Inicial Inicial Intermedia Última Última Velocidad Rápida Rápida Paulatina Paulatina Paulatina Duración Corta Media Media Larga Larga Expresión Conceptual Experimental Experimental Experimental Experimental Estilo Narrativo Narrativo Interactivo Interactivo Interactivo Medio Digital Digital Digital Digital Digital Fidelidad Baja Media Alta Alta Alta

Prototipo Quick

Wireframe Wireframe Low-coded High-coded

Versión del

Producto

• Audiencia: Interna/ Externa. Es importante determinar que la audiencia

que va a ver o usar el prototipo, no necesariamente es el usuario final

del software. En las iteraciones de TREG, la audiencia principalmente

fue interna, formada por los investigadores que participaron de las

revisiones de los prototipos. Excepto la última iteración, donde la

audiencia externa fue formada por potenciales usuarios del juego.

• Etapa: Inicial/Intermediaria/Última. No es suficiente que se prototipe

pensando en ahorrar los costos de crear un sistema. El acto de

prototipar debe ser realizado de forma efectiva en relación al tiempo y

costo y, principalmente, en tener un prototipo de utilidad para el

proceso de desarrollo de software. Es por esto que este proceso

puede ser realizado en cualquier etapa del ciclo de desarrollo. En

TREG, cada una de las iteraciones del proceso de prototipación

corresponden a cada iteración del ciclo de desarrollo del software.

• Velocidad: Rápida/Paulatina. Indica que tan rápido el prototipo será

producido y el nivel de detalle que contendrá. En TREG, las primeras

iteraciones se realizaron con más rápido para obtener una

retroalimentación mas continua. Las últimas iteraciones fueron más

4 Prototipos 52

paulatinas por el tiempo invertido en la codificación y en un prototipo

con mayor fidelidad y calidad de los detalles visuales.

• Duración: Corta/Media/Larga. Esta característica está referida a dos

aspectos:

o ¿Cuál es el tiempo de vida del prototipo? ¿Será un prototipo

que sólo se usará una vez para probar algún concepto? ¿o

será iterado varias veces e involucra un diseño final del

software?

o ¿Cuál es el alcance que el prototipo puede influir en el

producto? ¿Será un corto sketch para mostrar una idea o será

un punto de referencia para la creación del producto?

En TREG, la duración fue corta en el primer prototipo dado que fue

usado para clarificar el objetivo del proyecto y entender porque

algunos entornos no serían utilizados. Las siguientes iteraciones

se desarrollaron con una duración mayor y la mayoría de objetos y

scripts continuaron siendo usados en el proyecto.

• Expresión: Conceptual/Experimental. La expresión es demostrada a

través de qué tan tangible o abstracto puede ser el diseño visual del

producto y la interacción con el prototipo. Los prototipos conceptuales

se enfocan más en el en entendimiento de un concepto o de una

faceta particular del producto, como por ejemplo, la primera iteración

de TREG fue prototipada para entender el objetivo del proyecto

usando slides y una maqueta simple y no está destinada a la

interacción con los objetos como fueron las otras interacciones que

estaban más orientadas al “look and feel” del producto.

• Estilo: Narrativo/Interactivo. Esta característica define si un prototipo

es activo y pasivo. En el estilo narrativo existe un camino

predeterminado para mostrar el prototipo. A partir de los prototipos

low-coded de TREG, el estilo interactivo estaba presente, dejando a

los participantes interactuar libremente con el juego.

• Medio: Físico/Digital. Usando un medio físico (usualmente prototipos

tangibles) se logra una mayor flexibilidad en la interacción pero la

fidelidad que se tiene con el sistema es mucho menor a usar un medio

digital. En TREG se usó sólo medios digitales, principalmente

utilizando Second Life como herramienta.

• Fidelidad: Baja/Media/Alta. Esta característica está referida al

contenido del prototipo que puede ser: diseño de la información,

4 Prototipos 53

diseño de la interacción y modelo de navegación, diseño visual,

contenido editorial, expresión de la marca y desempeño y

comportamiento del sistema. Cada una de estas características

desempeña una función diferente y no todas aplican a todos los

productos. En TREG, se enfatizó en el contenido de alta fidelidad

usando Second Life (principalmente para los prototipos codificados).

4.3.Criterios de Diseño

Los criterios de diseño tienen como objetivo guiar el diseño, construcción y

presentación de los prototipos. El diseño de TREG fue realizado usando los

criterios descritos a continuación para resolver reglas contradictorias al modelar

objetos 3D o programar en Second Life.

Memoria del usuario

No sobrecargar la memoria del usuario. En este sentido, los objetos con la

misma funcionalidad deberán lucir iguales:

� Tanto Miss Workshop que se encuentra en el área de recepción

como la que se encuentra en la cocina deberán tener el mismo

aspecto para que el jugador pueda reconocerla.

� En el Panel de Simulación, las respuestas para los ingredientes de

Personas Adecuadas y Propósito Compartido deberán aparecer en

la misma posición y bajo el mismo formato de texturas.

� Asimismo, la información que aparece en “Learn More” deberá

aparecer en el mismo formato de textura para todos los

ingredientes.

� Los elementos de los ingredientes de Trabajo Previo y Espacio

Compartido deben funcionar de la misma manera. Es decir, cuando

se haga clic en uno de ellos cambie a un color diferente que sea

identificable por el jugador.

� La retroalimentación de las respuestas correctas en el ingrediente

de Trabajo Previo, deberá cambiar de al mismo color mostrando las

respuestas correctas en los tres paneles.

� Second Life facilita la visualización de objetos que tienen

funcionalidad, al hacer que el cursor cambie al pasar el mouse por

dichos objetos.

4 Prototipos 54

� La funcionalidad deberá ser la misma para abrir y cerrar las puertas

del túnel conector de la cocina al cuarto de simulación.

Patrones de diseño visual

Los patrones de diseño dan uniformidad a los objetos del prototipo al

aplicar un diseño consistente en los objetos.

� Se debe utilizar un mismo color para los nombres de las etiquetas

de los NPCs.

� Dado que las texturas a ser utilizadas en los cuadros de los

ingredientes de Trabajo Previo y Espacio Compartido son

transparentes, todo el ambiente deberá cambiar para blanco de

forma tal que haga contraste con los elementos en el ambiente y

puedan ser visualizados por el jugador sin problemas.

� Las texturas que contienen letras deberán utilizar los mismos tonos

(tener en cuenta el fondo negro, letras blancas y líneas celestes).

� Deberá utilizarse la misma textura panorámica para la visualización

externa de la cocina y del cuarto de simulación.

Uso de Second Life

Se utilizarán las funcionalidades ya incluidas en el cliente de Second Life.

Asimismo, deberá tenerse en cuenta las siguientes consideraciones de

implementación en Second Life.

� La comunicación entre los objetos de TREG y el jugador se dará

por medio del Local Chat de Second Life. Se utilizará el canal 0

para enviar mensajes públicos al jugador.

� Se utilizará la funcionalidad de enviar objetos en Second Life. Se

toma como premisa que en estos casos, el jugador guarda los

objetos en su inventario y sabe como manipularlos.

� Dado que una isla en Second Life tiene como parámetro máximo el

uso de 15 000 prims, se utilizará la función llRezObject para

hacer aparecer los objetos en el ambiente. Cuando el jugador

termina de utilizar un ingrediente, estos objetos son eliminados y

aparecen los objetos del próximo ingrediente que desea simular.

Con esta característica se reduce el número de prims en la isla,

usando sólo los prims que se necesitan por cada ingrediente.

4 Prototipos 55

� Los notecards de Second Life serán usados para enviar

información al jugador con contenido educacional de los

ingredientes de Workshops.

� Cuando sea posible, se utilizará notecards con el contenido de la

comunicación entre objetos y avatares de tal forma que permita

algún futuro cambio de idioma.

� La plataforma de desarrollo usando el sandbox se mantendrá

asilada del ambiente de producción.

Desempeño del juego

El bajo desempeño computacional que puede existir en el juego es

perjudicial para la inmersión del jugador ya que pocos segundos pueden hacer

mucha diferencia. Al tener un juego en Second Life, el desempeño depende

también de la congestión de los servidores de Linden Labs, la velocidad de

conexión del jugador y la configuración técnica de la CPU y tarjeta de video que

está usando. Para esto, se debe tomar en cuenta las siguientes

recomendaciones:

� La comunicación entre objetos vinculados utilizará la función

llMessageLinked para enviar algún mensaje a los otros objetos

vinculados. Además usará el evento link_message para recibir el

mensaje. Estas funciones trabajan más rápido que las funciones de

eventos listen que deberán ser usadas para la comunicación

sólo de objetos no vinculados.

� Se deberá minimizar los eventos listen en el canal 0. La

comunicación entre objetos no vinculados utilizará la función llSay

para enviar algún mensaje a los otros objetos del ambiente.

Además, usará el evento listen para recibir el mensaje.

� Para dar mayor seguridad a la comunicación entre objetos, el canal

de comunicación entre objetos no vinculados será un número

entero negativo de 5 dígitos generado aleatoriamente. Se deberá

tener en cuenta la performance e el retraso de los eventos en LSL.

La Tabla 4 muestra las funciones que ocasionan mayor retraso.

4 Prototipos 56

Tabla 4. Funciones con mayor retraso (en segundos)

Retraso Función

20.0 llRefreshPrimURL

20.0 llSetPrimURL

20.0 llEmail

10.0 llLoadURL

10.0 llGetSimulatorHostname

5.0 llTeleportAgentHome

3.0 llSendRemoteData

3.0 llRemoteLoadScriptPin

3.0 llRemoteLoadScript

3.0 llRemoteDataReply

3.0 llGiveInventoryList

2.0 llSetParcelMusicURL.

2.0 llParcelMediaQuery

2.0 llParcelMediaCommandList

2.0 llInstantMessage

2.0 llGetParcelPrimOwners

� El desempeño del juego se puede ver muy afectado por el uso de

muchas texturas diferentes en el ambiente puesto que cada una de

ellas deberá ser descargada al cliente del jugador. Se deberá

minimizar el uso texturas. Por ejemplo, en el panel de control, se

deberá usar sólo una textura para todas las respuestas, objetos

transparentes se posicionaron sobre las respuestas con la

funcionalidad deseada.

4.4.Iteraciones

La secuencia de pasos relatada en la Sección 4.1 se siguió en cada una de

las iteraciones del desarrollo. De esta manera, se fue refinando los requisitos,

definiendo los objetos necesarios e integrando la solución. La audiencia que

participó de las sesiones de revisión y validación del diseño de los prototipos

fueron el autor, el orientador y co-orientador de este trabajo. Adicionalmente, en

la última iteración, las pruebas de usabilidad fueron realizadas con 2 evaluadores

y 9 participantes.

4 Prototipos 57

Iteration 3

Iteration 1

Iteration 2

Iteration 4

Iteration 5

Figura 20. Prototipos desarrollados en TREG

La Figura 20 muestra la transición de la apariencia de TREG por estas

iteraciones. Se puede observar como el proceso de prototipación favoreció el

refinamiento del prototipo desde una maqueta de baja fidelidad hasta la versión

final del juego.

4.4.1.Iteración 1.

De una Idea hacia un prototipo Quick Wireframe.

Al inicio del proceso de prototipación, la idea principal fue la creación de un

ambiente para el entrenamiento en Ingeniería de Requisitos. A partir de esta idea

se creó un prototipo Quick Wireframe. Este método de prototipación da una

aproximación anticipada de la idea del software pudiendo tener una perspectiva

a alto nivel enfocada en los aspectos estructurales de la aplicación [9]. En esta

primera iteración, se utilizó este método para presentar una maqueta de baja

fidelidad creada en Second Life mostrando la idea de estructuras con los

diferentes objetivos para el entrenamiento. Se propuso tener un área de

recepción para conocer el proyecto como punto de partida para otras las áreas

del proyecto, juegos mono usuario donde exista un entrenamiento en las

principales técnicas de Ingeniería de Requisitos, un juego tipo laberinto donde el

4 Prototipos 58

jugador abriría puertas hasta llegar al punto final de un determinado

entrenamiento, salones para clases o grupos de discusión y un auditorio.

Se realizó una maqueta en Second Life donde cada una de estas áreas

representadas con un óvalo con una textura tal como se muestra en Figura 21.

En el medio de la maqueta representaba al área de recepción que unía a las

demás áreas.

Figura 21. Prototipo de la Iteración 1.

Al revisar la maqueta, ésta mostraba sólo texturas para dar una idea

general del área y no mostraba los objetos en 3D que se iban a crear pero sirvió

para formular el propósito del proyecto: un juego no tradicional para el

entrenamiento en Ingeniería de Requisitos. Este prototipo fue un instrumento

para clarificar el objetivo real del proyecto.

Se acordó que los otros prototipos que utilicen como herramienta Second

Life, se construyan los objetos 3D para poder tener una visión más próxima al

producto.

4.4.2.Iteración 2.

De un prototipo Quick Wireframe hacia un prototipo Wireframe

En esta iteración, se utilizó un prototipo Wireframe con mayor fidelidad que

el anterior construyéndose objetos 3D en Second Life. El prototipo Wireframe

mostraba el área de recepción con. 5 teleports para las áreas tentativas. En la

Figura 22, se muestra el área de recepción de la iteración 2. En esta se

construyeron teleports (objetos en verde) para las áreas del juego en cada una

de las puntas de la estrella. Estas áreas tentativas para el desarrollo del juego

4 Prototipos 59

basadas en conceptos de Ingeniería de Requisitos fueron: proceso, técnicas,

gestión, análisis y validación.


Este prototipo contribuyó a explorar la idea planteada en la iteración

anterior. De este modo, se decidió comenzar el estudio con la técnica de

Workshops. Además, se mantuvo la idea de utilizar teleports para las áreas del

juego.

4.4.3.Iteración 3.

De un prototipo Wireframe hacia un prototipo Low-coded


Los prototipos codificados muestran una alta fidelidad del producto y son

interactivos lo cual posibilita refinamientos incrementales en el diseño pero a su

4 Prototipos 60

vez están vinculados al riesgo del rechazo total o de grandes modificaciones [9].

En esta iteración se decidió comenzar por desarrollar un prototipo Low-coded,

donde existe una gran fidelidad del producto pero no involucra un alto riesgo de

codificación.

Una nueva área de recepción mostraba un edificio con elevadores para las

diversas áreas tal como se muestra en la Figura 24. Los scripts de los teleports a

las áreas fueron reutilizados en los elevadores. Se comenzó a prototipar el área

de Workshops. En el primer incremento de esta iteración, texturas que

representaban a participantes del workshop fueron mostradas y se decidió

cambiar estas texturas por objetos 3D que simulasen estos participantes (NPCs).

En el siguiente incremento, se mostraron los NPCs que formarían parte del

ingrediente de Personas Adecuadas. Inclusive se mostró un NPC que caminaba

en el ambiente pero se descartó la utilización de esta funcionalidad en los NPCs

debido a los retrasos que podría causar en computadoras con bajo rendimiento.

Se vio la posibilidad de incluir en el área de recepción información del

juego. En esta iteración se descubrió la necesidad de usar un género de

simulaciones para juegos (Branching Stories). Asimismo, se decidió usar la

técnica de Escenarios para especificar el juego tal como se mostró en el

documento [33].

4.4.4.Iteración 4.

De un prototipo Low-coded hacia un prototipo High-coded


Esta iteración fue la de mayor duración para la programación de los

elementos. En esta iteración se incluyeron los acuerdos de implementación de la

iteración anterior y se terminó de programar los ingredientes de TREG.

4 Prototipos 61

Una nueva área de recepción con mayor fidelidad fue redefinida tal como

se muestra en la Figura 24. Esta área incluyó al NPC para guiar al jugador y para

ofrecer los recursos necesarios para el juego. Asimismo, el ambiente de la

metáfora de la cocina fue modelado e programado. EL HUD que incluye la

puntuación y el número de ingredientes capturados fue integrado al ambiente de

simulación y a la cocina.

Las simulaciones fueron definidas usando Branching Stories y escenarios.

Una nueva opción atractiva surgió con la inclusión de maquinas de estados para

la implementación en LSL. Utilizando el diseño del software especificado en la

Sección 3.3, se terminó la implementación del ingrediente de Personas

Adecuadas y se prototiparon los demás ingredientes del juego.

4.4.5.Iteración 5.

De un prototipo High-coded prototype hacia la implantación de TREG.


En esta iteración, el equipo validó los conceptos utilizados en la

prototipación del producto y se realizaron refinamientos en el diseño del juego.

Posteriormente se realizaron las pruebas de usabilidad tal como se detalla en la

Sección 5. Finalmente, la versión de TREG de los ingredientes de planificación

de la técnica de Workshops fue implantada en el área de producción tal como se

muestra en la Figura 25.


5 Pruebas y análisis de resultados

De acuerdo a la definición de Usabilidad de ISO (9241-11) [34], las

métricas de usabilidad pueden ser clasificadas en efectividad, eficacia y

satisfacción. Este concepto ha sido utilizado en varias pruebas de usabilidad de

software pero algunos autores discrepan en la aplicación de esta categorización

para juegos. Es por esto que para este proyecto, se utilizará una categorización

adecuada para juegos educacionales [35], [36], [37] que agrupa las métricas de

usabilidad en interfaz, mecanismos y jugabilidad.

Esta sección describe el plan para conducir las pruebas de usabilidad del

juego TREG y su ejecución. El objetivo de las pruebas de usabilidad es analizar

el comportamiento de TREG en estas 3 métricas. A continuación se detalla el

propósito de las pruebas, sus participantes, contexto técnico, entrevistas,

cuestionarios y la forma de recolectar y analizar la información. Asimismo, se

mostrará un análisis de los resultados obtenidos.

5.1.Propósito

TREG es una herramienta para el entrenamiento en Ingeniería de

Requisitos. Esta herramienta fue creada en forma de un juego y localizada en un

mundo virtual. Fueron aplicadas técnicas de desarrollo de software y juegos para

su creación. Debido a esto, el propósito de realizar las pruebas de usabilidad de

TREG, más que evaluar el aprendizaje, es de evaluar la experiencia de los

usuarios con dicha herramienta. Dicha evaluación se realizó teniendo en cuenta

las métricas de categorización de juegos y utilizando cuestionarios, entrevistas y

la observación de la experiencia del jugador.

5.1.1.Aspectos de la evaluación

Se analizaron las pruebas de usabilidad y la funcionalidad asociada fue

agrupada de acuerdo a la categorización utilizada en la evaluación: interfaz,

mecanismos y jugabilidad.


Tabla 5. Aspectos a evaluar del juego

Tipo Aspecto a Evaluar Método

Interacción con los principales elementos.

INT Panel de simulación Entrevista

INT Miss Workshop Entrevista

INT Head Up Display (HUD) Entrevista

Tipos de Juegos

a) Personas Adecuadas y Propósito Compartido

MEC Interacción con NPCs Entrevista

MEC Responder la pregunta Entrevista

MEC Machinima Entrevista

b) Espacio Compartido y Trabajo Previo

MEC Interacción con elementos 3D Entrevista

MEC Tiempo Entrevista

Presencia

JUG La sensación de presencia de un participante usando un juego educacional en un ambiente tridimensional.

Cuestionario Pos Uso

En la Tabla 5 se muestran los aspectos que fueron evaluados en las

pruebas. Para cada uno de estos aspectos se determinó el método por el cual se

adquiriría esta información y a la categoría a la cual pertenece (INT, MEC, JUG)

� Interfaz (INT): Son los elementos con los cuales el usuario interactúa. Es

la parte encargada de interactuar directamente con el jugador, y

mantener el diálogo entre éste y el juego. Esta característica será

evaluada a través de la interacción del participante con el panel de

simulación, Miss Workshop y HUD para verificar que los elementos

propuestos en TREG cumplen la función para la cual fueron diseñados

� Mecanismos (MEC): Es la combinación de programación y animación que

posibilita que las interacciones que ocurren en el juego son fluidas y

logran el objetivo del juego. Esta categoría será evaluada a través de la

interacción del jugador a lo largo de los cuatro ingredientes y ambientes

de TREG.

� Jugabilidad (JUG): el conjunto de propiedades que describen la

experiencia del jugador ante un sistema de juego determinado, cuyo

principal objetivo es divertir y entretener “de forma satisfactoria y creíble”

ya sea solo o en compañía. El juego debe tener la capacidad para que el

jugador pueda creerse lo que se juega e integrarse en el mundo virtual

mostrado en el juego.


5.1.2.Participantes

Se seleccionaron los participantes fueron potenciales usuarios de TREG. A

continuación se detallan los requisitos generales de los participantes:

� Desarrolladores de software o profesionales familiarizados con el

desarrollo de software.

� Leer razonablemente bien en inglés.

Dado que la audiencia del proyecto no necesariamente conoce Second

Life, se realizó una clasificación de participantes agrupados en 3 grupos. Cabe

resaltar que estos grupos son sólo referenciales para definir el nivel de

entrenamiento y la recolección de resultados, y que cada una de las sesiones

será realizada de forma individual.

Grupo 1. Expertos. Con amplio dominio en Second Life.

Grupo 2. Intermedios. Familiarizados con algún mundo virtual que no sea

necesariamente Second Life.

Grupo 3. Novatos. No están familiarizados con ningún mundo virtual.

Se decidió realizar las pruebas con 3 participantes por cada grupo dado lo

expuesto por Nielsen [38] donde propone utilizar 3 usuarios para cada categoría

si las pruebas involucran 3 o más grupos. Es por esto que fueron 9 participantes

de las pruebas de usabilidad en TREG.

Los participantes que no conocían Second Life, fueron entrenados en el

uso de las funcionalidades necesarias de Second Life para usar TREG. Los

usuarios que conocían Second Life, completaron un checklist para confirmar que

las funcionalidades a usar en el juego son conocidas por ellos.

Los participantes usaron TREG en los 3 ambientes diseñados (recepción,

cuarto de simulación y cocina) para completar el juego. Además, respondieron

los cuestionarios de pre-uso y pos-uso y al final del juego, participaron de una

entrevista.

5.2.Desarrollo de las pruebas

El procedimiento para la realización de las pruebas de usabilidad se divide

en las siguientes fases:


5.2.1.Localización y condiciones técnicas

Las pruebas de usabilidad se realizaron en el Laboratorio de Ingeniería de

Software (LES), en la oficina AulaNet en el décimo piso del Edificio Padre Leonel

Franca (PUC-Rio). El participante (de ser necesario) fue capacitado en Second

Life y jugó TREG utilizando una PC que cumple con los requisitos recomendados

[39] para el uso de Second Life en un típico ambiente de oficina.

� Hardware:

2PCs con las siguientes especificaciones técnicas. Una de las

cuales fue utilizada por el instructor durante el entrenamiento

(de ser el caso) y la otra fue utilizada por el participante.

Intel ® Core ™ 2 Quad CPU

Q6600 @ 2.4 GHz

2 GB de RAM

Dispositivos: teclado, Mouse, parlantes.

Adicionalmente se contó con una cámara fotográfica y

grabadora de voz para grabar la sesión.

� Software

Second Life (Cliente en su versión: 1.23.5)

QuickTime (para la visualización de videos en Second Life)

FRAPS (para grabar la sesión del participante usando TREG)

Se creó un avatar para las pruebas de usabilidad (Tregame Gant). Para

cada sesión se cambió la apariencia del avatar (femenino o masculino)

dependiendo del sexo del jugador y se limpió el inventario.

5.2.2.Acuerdos

Una visión general del juego fue dada al participante y se le explicó que la

evaluación se realiza al juego y no a él. Asimismo, se le solicitó minimizar las

llamadas telefónicas para no interrumpir la sesión.

El participante deberá firmar el Término de Consentimiento (Véase

Apéndice B.1) que contiene los acuerdos para el desarrollo de las pruebas:

participación es voluntaria, el participante puede abandonar el juego cuando lo

desee y que la sesión será gravada pero la información personal será privada.


5.2.3.Perfil de los participantes

La Tabla 6 presenta los datos recogidos del cuestionario del perfil del

participante.

Tabla 6. Perfil de los participantes en las pruebas.

Nº Perfil Sexo Experiencia en Second Life

Experiencia en Workshops

1 Novato Femenino no no 2 Novato Femenino no otras técnicas 3 Novato Femenino no otras técnicas 4 Intermedio Masculino otros mundos virtuales no 5 Intermedio Masculino otros mundos virtuales no 6 Intermedio Masculino otros mundos virtuales si 7 Experto Masculino si otras técnicas 8 Experto Masculino si no 9 Experto Masculino si no

Los participantes completaron un cuestionario antes de iniciar las pruebas

para conocer su perfil. Se deseaba conocer la experiencia del participante en el

uso de Second Life y en la técnica de Workshops. El cuestionario realizado se

encuentra en el Apéndice B.2.

5.2.4.Entrenamiento en Second Life

Dado que Second Life es la plataforma de desarrollo e implantación de

TREG, se vio necesario que todos los participantes conozcan las funcionalidades

de Second Life necesarias para jugar TREG.

Para los participantes que son considerados como Expertos, se preparó un

checklist para verificar que conocen las funcionalidades necesarias. Mientras

que los participantes de nivel intermedio y los que nunca usaron ni Second Life

ni algún otro mundo virtual, pasaron por un entrenamiento guiadas por un

responsable del entrenamiento. El objetivo de este entrenamiento es que los

participantes entiendan los conceptos básicos del mundo virtual y puedan

desplazarse e interactuar dentro de TREG. El nivel del entrenamiento y el tiempo

destinado para el mismo, será dado de acuerdo al grupo perteneciente de cada

participante. En el Apéndice B.3 se muestra en detalle las tareas que los

participantes realizaron en el entrenamiento.

Se dispuso del equipamiento y software necesario para el entrenamiento

de los participantes. Las características principales de Second Life en las cuales

el participante será entrenado para el uso de TREG son las siguientes:


� Desplazamiento (caminar y volar)

� Interacción con objetos (touchs, pie menu para sentarse)

� Mover la cámara en diferentes direcciones

� Local Chat

� Inventario

� Ver videos en Second Life

El tiempo promedio de entrenamiento para los novatos fue de 40 minutos

mientras que para los que pertenecen al perfil intermedio fue de 21 minutos

aproximadamente. Además se debe tomar en cuenta que los expertos no

realizaron un entrenamiento en Second Life pero sí se completó un checklist con

la funcionalidad de Second Life a usar en TREG. El Apéndice B.6 muestra una

tabla más detallada con el tiempo empleado por cada participante en el

entrenamiento.

5.2.5.Durante las pruebas

Antes de iniciar el juego, se explicó el objetivo del mismo y las tareas que

el participante deberá completar. Asimismo, solicitó al participante que exprese

verbalmente sus pensamientos, sentimientos y opiniones mientras interactuaba

con el juego (Think Aloud Protocol [40]).

La sesión fue gravada y se realizaron anotaciones sobre la interacción del

participante con TREG. Las pruebas fueron observadas por 2 evaluadores. El

Apéndice C muestra los datos recolectados durante 3 sesiones de las pruebas,

cada una de un diferente perfil de participante.

5.2.6.Después de las pruebas

Después de realizar las pruebas con el juego, el participante tuvo una

entrevista con los evaluadores para conocer sus opiniones y finalmente

completará un cuestionario.

5.2.6.1.Entrevista:

Se realizó una entrevista entre los evaluadores y cada participante. En esta

entrevista se preguntó por la interacción con los objetos diseñados en TREG

(Panel de simulación, Miss Workshop y HUD). Asimismo se deseó conocer la

opinión de los participantes con relación a la facilidad de uso y el entendimiento

del objetivo del juego en cada uno de los ingredientes (Personas Adecuadas,


Propósito Compartido, Trabajo Previo y Espacio Compartido). El Apéndice B.4

muestra las preguntas que se realizaron a los participantes.

En las siguientes tablas (de 7 a 11) se mostrará las observaciones

manifestadas durante la pruebas y las recomendaciones expuestas por los

participantes después de realizadas las pruebas. La columna de reincidencias

muestra cuantos participantes tuvieron la misma dificultad. Asimismo, durante la

entrevista, los participantes realizaron sugerencias en cada uno de los aspectos

evaluados de TREG. La columna de repeticiones muestra cuantos participantes

dieron la misma recomendación.

Tabla 7 Uso de Second Life

Observaciones Reincidencias Dificultad al encontrar la opción del inventario 3 Dificultad para sentar (no recordaba el Pie Menu de Second Life 4 Dificultad en usar la cámara de Second Life 5 Problemas al mover la cámara y mantener los notecards abiertos. 1 Siente falta del movimiento horizontal y vertical que hacía con el Mouse cuando usaba juegos 3D. 1

Le incomoda el control del Local Chat cuando las instrucciones aparecen o desaparecen. 6

No pudo regresar a un determinado punto del video y tuvo que pararlo y comenzar de nuevo. 1

Recomendaciones Repeticiones Le gustaría poder realizar búsquedas en los notecards para no tener que leer todo el documento. 1

Tabla 8 Facilidad de uso de los ambientes en TREG

Recepción Observaciones Reincidencias Pensó ver un video en el televisor. 2

No se da cuenta que recibió los recursos. 1 Recomendaciones Repeticiones Mostrar un video con una introducción al juego. 2

Cocina Observaciones Reincidencias Entiende el objetivo del juego pero no sabe cómo dirigirse al cuarto de simulación. 6

No sabe como abrir la puerta. 5 Recomendaciones Repeticiones Sugiere que al final del juego, se podría mostrar alguna comida lista o algún tipo de animación. 2


Tabla 9 Interacción con los elementos del juego (Panel de Simulación)

Panel de Simulación Observaciones Reincidencias

Lee la información de los notecards del LEARN MORE pero no encuentra lo que buscaba. 9

Siente que es mucha la información que aparece en los notecards. 8

Siente que es mucha la información que aparece en el Local Chat. 4

Confusión con la textura “No Signal” (esperan videos, asocian a errores, esperan que suceda algo) 6

No se detenía a leer las instrucciones del Local Chat porque se sentía más concentrado en el ambiente 3D. 3

Recomendaciones Repeticiones La información en LEARN MORE le pareció útil pero sugirió cambiar de lugar por ser muy destacado para las simulaciones. 1

Agregar un glosario en una de las opciones del LEARN MORE. 7

Sugirió que el glosario muestre Wikipedia o algún website con la información de los términos.

1

Sugiere tener una explicación a través de un video de cada ingrediente antes de comenzar la simulación. 2

Sugiere dar tips al jugador cuando se equivoca. 1

Recomienda un manual de instrucciones para iniciar el juego. 1

Recomienda que el cuarto de simulación sea mayor para facilitar el desplazamiento del avatar y la cámara. 2

Le gustaría que hubiera una señal del Panel que le indique que voltee para ver los elementos que aparecen en el ambiente. 4

Miss Workshop Observaciones Reincidencias

No sintió la ayuda. 6

Al estar de espaldas al participante en la cocina fue difícil percibir que ella era la que estaba hablando. 1

Recomendaciones Repeticiones Sugirió ponerla en el Cuarto de Simulación para brindar ayuda cuando el jugador se sienta perdido. 1

Recomienda usar audios con lo que Miss Workshop está diciendo. 1

HUD Observaciones Reincidencias

No percibió la presencia del HUD durante el juego. 5 Recomendaciones Repeticiones

Utilizar puntuación negativa cuando el jugador se equivoca 1 Poner un dibujo de un ingrediente cada vez que va encontrando uno. 1


Tabla 10 Facilidad de uso de los ingredientes

Personas Adecuadas Observaciones Reincidencias Selecciona una de las respuestas del panel de simulación sin comunicarse con los NPCs. 6

No descubre los objetos que aparecieron cuando se inició la simulación.

4

Dificultad para entender cómo seleccionar los NPCs para sentarse. 2

No se comunicó con los NPCs sentados. 5

Cuando se sienta en la mesa espera que suceda algo. 3

Le parecieron muchos participantes para recordar todos los datos dados por cada uno de ellos. 1

Recomendaciones Repeticiones Sugirió tener una lista de las características de los NPCs en vez de tener la que hacer clic en cada uno de ellos. 1

Cuando terminó el video quería que desaparezca el monitor de Machinima para poder simular nuevamente el ingrediente. 1

Propósito Compartido

Recomendaciones Repeticiones Le pareció interesante tener los NPCs en pie y comunicarse con ellos. 1

Sugirió tener el diálogo de los NPCs en llamadas forma de balones. 1

Trabajo Previo Observaciones Reincidencias No puede retirar los objetos incorrectos una vez que verificó o acabó el tiempo (también para Espacio Compartido). 8

No puede retirar los objetos incorrectos cuando está jugando (también para Espacio Compartido). 6

Sintió dificultad al tener que leer los elementos del suelo dado que algunos caían al revés (también para Espacio Compartido). 5

Sintió la presión del tiempo. Por esta razón, intenta terminar rápidamente y la información en LEARN MORE fue leída muy rápido (también para Espacio Compartido).

4

Sintió dificultad al leer ciertos elementos que están seleccionados y cambian de color a amarillo (también para Espacio Compartido). 1

Dificultad para identificar el botón para parar el tiempo (también para Espacio Compartido). 4

Incomodidad al tener que iniciar desde cero cuando verifica que el ingrediente tiene errores (también para Espacio Compartido). 5

Siente incomodidad al no poder tener una visión de todo el ambiente. 2 Recomendaciones Repeticiones Le gustaría que el juego le avisara si se olvidó de algún elemento para no tener que comenzar desde cero (también para Espacio Compartido).

1

Le gustaría tener la opción de retirar los objetos de los cuadrados si están incorrectos (también para Espacio Compartido). 7

Sugiere que el botón para parar el tiempo y verificar la respuesta debería tener algún aviso (Ejemplo Exit)

2


Espacio Compartido Observaciones Reincidencias La lectura del feedback textual hace difícil saber cuáles son las respuestas correctas. 9

Recomendaciones Repeticiones Sugiere usar el mismo feedback usado en Trabajo Previo con las respuestas correctas en azul. 4

Sugiere utilizar un feedback que además de mostrar cuántos elementos incorrectos el jugador tuvo, que indique cuántos elementos deberían estar en el cuadro

1

Recomienda que el feedback en forma de texto muestre de una manera más fácil de asociar a los cuadros 3D (Por ejemplo, que se muestre cuál es Board 1.

1

Tabla 11 Entendimiento del objetivo del juego. (Personas Adecuadas)

Personas Adecuadas

Observaciones Reincidencias Le pareció que no quedaron claros los roles en un workshop. 1

Pensó que el objetivo era seleccionar al equipo de trabajo y no los participantes de ese workshop específico. 1

Propósito Compartido Observaciones Reincidencias No está seguro porque esa respuesta es la correcta. 2

Sintió que este ingrediente era más un juego de palabras. 2 Recomendaciones Repeticiones Siente que no se tiene un histórico en relación al workshop de Personas Adecuadas. Sugiere mostrar que número de workshop es, si es el mismo proyecto y cuáles fueron las reuniones anteriores.

1

Trabajo Previo Observaciones Reincidencias Al terminar de jugar el ingrediente sintió que no aprendió los términos de los elementos que no sabía dónde colocar 7

Recomendaciones Repeticiones Dada la forma del ciclo de workshops, el participante sugiere cambiar el nombre de “Input Products” por “Products”. 3

Como no entiende el significado de objetos desconocidos, sugiere poner una etiqueta con la definición del elemento. 1

Espacio Compartido Observaciones Reincidencias Al terminar de jugar el ingrediente sintió que no aprendió los términos de los elementos que no sabía dónde colocar 7


5.2.6.2.Cuestionario (IPQ):

El Igroup Presence Questionnaire (IPQ) [41] es una escala para medir el

sentido de presencia en un ambiente virtual. Fue construido usando una gran

cantidad de ítems y realizando dos levantamientos con más de 500 participantes.

Este cuestionario (mostrado en la Tabla 12) utiliza 3 subescalas principales para

el análisis de los principales componentes: Adicionalmente, el cuestionario

cuenta con el ítem general de Sentido de Presencia, que está ligado a las otras

subescalas.

- Presencia espacial: la sensación de estar físicamente presente en el

ambiente virtual.

- Participación: mide la atención dada al ambiente virtual

- Realismo experimentado: mide la experiencia subjetiva de realismo en

el ambiente virtual.

Tabla 12. Elementos del cuestionario IPQ.

IPQ Características Pregunta

G1 Sensación de estar ahí En el mundo virtual, tuve la sensación de

“estar ahí”

SP1 Sensación de un entorno

virtual detrás

De alguna forma me sentí que el mundo

virtual estaba a mí alrededor.

SP2 sólo figuras Sentí que sólo percibía figuras.

SP3 sin sensación de estar en un

espacio virtual

No me sentí presente en un espacio virtual

SP4 sensación de actuación en un

entorno virtual

Sentí que actuaba en el espacio virtual en

lugar de estar operando algo desde afuera.

SP5 sensación de estar presente

en el entorno virtual

Me sentí presente en el espacio virtual.

INV1 Percepción del entorno real. ¿Qué tanto se dio cuenta de su entorno real

cuando navegaba por el mundo virtual? (Ej.

sonidos, temperatura, otras personas, etc.)

INV2 No percibe el entorno real. No me di cuenta de mi entorno real.

INV3 Sin atención del entorno real. Aún presté atención al entorno real.

INV4 Atención captada por el

entorno virtual

Estaba completamente encantado por el

mundo virtual.


Para esta evaluación, no se tomó en cuenta la escala de Realismo dado

que las pruebas de usabilidad de TREG no tienen como objetivo medir el

realismo porque TREG no fue diseñado como un entorno de la vida real. [La

banca no concordó con esta posición porque entendió que el realismo debería

estar presente en este cuestionario].

El Apéndice B.5 presenta el cuestionario traducido al idioma de los

participantes [42] y adecuado según las necesidades de TREG que fue dado los

participantes. La Tabla 12 muestra las subescalas del cuestionario, las preguntas

y posibles respuestas. Donde G1 es el ítem general; SPx son los ítems

asociados a la presencia espacial; INVx, participación.

5.3.Resultados

En esta sección, se consolida los resultados obtenidos de las pruebas de

usabilidad de TREG con respecto a las 3 métricas analizadas: interfaz,

mecanismos y jugabilidad. Estos resultados fueron capturados a través de los

cuestionarios, la observación del juego y la entrevista al final de la sesión.

Fueron 9 los participantes de las pruebas. Dichos participantes pertenecían

a 3 perfiles diferentes de usuarios con relación al uso de Second Life: novatos,

intermedios y expertos. Se realizaron sesiones individuales para conocer la

experiencia de los jugadores con TREG. Las Tablas 13 y 14 muestran el tiempo

promedio y el número de intentos promedio respectivamente. El Apéndice B7

muestra en detalle el tiempo y número de intentos empleados.

Tabla 13 Tiempo empleado en el juego

Promedio total

Promedio novato

Promedio intermedio

Promedio experto

1 Recepción 2,22 4,33 1,00 1,00 2 Cocina 3,22 4,33 3,00 2,00

3 Personas Adecuadas 18,56 26,00 13,00 11,00

4 Propósito Compartido 9,11 11,33 6,33 8,00

5 Trabajo Previo 21,56 29,67 19,00 15,00

6 Espacio Compartido 21,00 26,67 21,67 12,00

7 Cocina 1,56 1,67 1,67 1,00 Total 77,22 104,00 65,67 56,00

La Tabla 13 muestra el tiempo promedio invertido total y por cada uno de

los perfiles de usuarios. Se puede observar que el tiempo para terminar el juego

en los participantes novatos fue el mayor y que no existe mucha diferencia de


tiempo entre los perfiles de intermedio y expertos. Asimismo, las tareas que

consumieron mayor tiempo fueron las de los ingredientes Trabajo Previo y

Espacio Compartido.

Tabla 14 Número de Intentos empleados en cada tarea de TREG

Promedio total

Promedio novato

Promedio intermedio

Promedio experto

1 Recepción 1 1 1 1

2 Cocina 2 2 1 2

3 Personas Adecuadas 3 4 2 2

4 Propósito Compartido 2 2 2 2

5 Trabajo Previo 4 5 4 4

6 Espacio Compartido 4 6 4 3

7 Cocina 1 1 1 1

17 21 15 15

La Tabla 14 presenta el promedio de intentos empleados por los

participantes para alcanzar el juego. A semejanza de los resultados del tiempo

empleado, el número de intentos fue mayor para las personas que no conocían

Second Life y los ingredientes de Trabajo Previo y Espacio Compartido fueron

los que tuvieron mayor número de intentos en promedio.

5.3.1.Interfaz

A pesar de que los participantes manifestaron verbalmente su agrado con

el entorno virtual, se utilizó una entrevista al final de las sesiones para conocer la

interacción del jugador con los elementos de TREG.

En esta entrevista, se les pidió a los participantes ordenar de 1 a 3 en

orden de mayor a menor importancia, la interacción que tuvieron con los

principales elementos de TREG. Tal como se muestra en la Tabla 15, las

respuestas de los participantes demostraron que interactuaron más con el Panel

de Simulación, seguida de la interacción con Miss Workshop y el HUD.

Tabla 15 Resultados de la entrevista. Interacción con los elementos del juego

Novato Intermedio Experto

Moda P1 P2 P3 P4 P5 P6 P7 P8 P9

Interacción con elementos

Panel de Simulación 1 1 1 1 1 1 1 1 1 1

Miss Workshop 2 3 2 2 2 2 2 2 3 3

HUD 3 2 3 3 3 3 3 3 2 2


Además, durante la observación de la sesión, se notó molestias con

relación al uso de Second Life. Las observaciones más comunes manifestadas

por los participantes se presentan en las Tablas 16 y 17.

Tabla 16. Observaciones más comunes en la interacción con Second Life

Uso de Second Life

Dificultad en usar la cámara de Second Life. 5

Le incomoda no tener control del Local Chat cuando las instrucciones aparecen o desaparecen. 6

Tabla 17. Observaciones más comunes en la interacción con los elementos de TREG

Panel de simulación

Lee la información de los notecards del LEARN MORE pero no encuentra lo que buscaba. 9

Siente que es mucha la información que aparece en los notecards. 8 Miss Workshop

No la relacionó a la ayuda. 6 HUD

No percibió la presencia del HUD durante el juego. 5

La Tabla 16 muestra que la dificultad con más reincidencias de los

participantes fue el uso de la cámara. Estas observaciones fueron expresadas

principalmente por usuarios que no estaban familiarizados con Second Life y

fueron manifestadas mientras jugaban en el ingrediente Trabajo Previo y Espacio

Compartido. En estos ingredientes demostraron dificultad para mover la cámara

para poder ver los elementos en el suelo y reposicionarla para poder ver los

cuadros.

En la Tabla 17, se percibe que el mayor número de observaciones fueron

dadas para el Panel de Simulación. A pesar de que el proceso de aprendizaje de

uso del panel fue rápido, existieron molestias, principalmente por la cantidad de

texto que se mostraba en el Local Chat y en los notecards del Learn More. Se

observó que el Local Chat de Second Life utilizado para mostrar los resultados y

dar las instrucciones del juego incomodaba al participante por su extensa lectura

y además, por alejar la atención del participante en el mundo 3D para leer texto.

El Learn More fue creado para mostrar información adicional del ingrediente sólo

para los participantes que desean profundizar en la teoría. En las pruebas, este

elemento fue utilizado más para buscar un término específico que desconocían

en el juego y no necesariamente para profundizar más en la teoría.


Con relación a Miss Workshop, todos los participantes leyeron la

información que fue dada por la ayuda de este NPC, aun así 6 de los

participantes manifestaron que no sintieron ayuda de ella. Mientras se observaba

las sesiones, se pudo percibir que los participantes utilizaban la ayuda que

aparecía en el Local Chat pero no la asociaban con el NPC Miss Workshop.

Finalmente, el propósito de tener el HUD era mostrar a los jugadores la

puntuación y la cantidad de ingredientes que se iban recolectando. A pesar de

estar utilizando el elemento y éste estaba mostrándose en la pantalla, 5 de los

participantes no percibieron los cambios efectuados. Esto es debido

principalmente porque no se otorgó puntajes negativos que capturen más la

atención de los participantes y además, porque leían en el Local Chat que

también mostraba la respuesta cada vez que conseguían un ingrediente.

5.3.2.Mecanismos

Se evaluaron los mecanismos del juego, esto es, la combinación de

animación y programación en los elementos que posibilitan que el juego fluya y

que el jugados alcance el objetivo sin interrupciones. Para evaluar esta

categoría, se analizó el comportamiento de los mecanismos del juego a los largo

de la experiencia del participante por los cuatro ingredientes.

Tabla 18 Resultados de la entrevista.

Novato Intermedio Avanzado

Moda P1 P2 P3 P4 P5 P6 P7 P8 P9

Facilidad de Uso

Personas Adecuadas 2 1 4 2 2 2 2 2 4 4

Propósito Compartido 1 2 1 1 1 1 1 1 3 2

Trabajo Previo 4 4 2 4 4 3 4 4 2 3

Espacio Compartido 3 3 3 3 3 4 3 3 1 1

Entendimiento del Objetivo

Personas Adecuadas 2 2 4 2 2 3 2 1 1 4

Propósito Compartido 1 1 3 1 3 1 1 2 2 2

Trabajo Previo 4 4 2 4 4 4 4 4 3 3

Espacio Compartido 3 2 1 3 1 2 3 3 4 1

En la entrevista, se pidió a los participantes que ordenaran su experiencia

con los ingredientes de TREG de 1 a 4 según la facilidad de uso (siendo 1 el

más fácil de usar) y de la misma forma, el entendimiento del objetivo del juego

(siendo 1 el más fácil de entender). Como se presenta en la Tabla 18, el orden


elegido por los participantes fue en los dos casos: Propósito Compartido,

Personas Adecuadas, Espacio Compartido y Trabajo Previo.

Dos diferentes tipos de juegos fueron elaborados cuando se prototipó

TREG. El primero de ellos fue planteado con los ingredientes de Personas

Adecuadas y Propósito Compartido e involucra la interacción con NPC,

machinimas, simulaciones de casos de Workshops y la adaptación del

participante a un rol. Al inicio de la experiencia, los participantes entraron en un

proceso de aprendizaje del ambiente de simulación pero luego de entender

cómo funcionaba el Panel de Simulación y los otros objetos del ambiente, éstos

pudieron conseguir el ingrediente. En la Tabla 19 se puede observar que el

mayor número de reincidencias en el ingrediente de Personas Adecuadas

ocurrieron en este proceso de aprendizaje. Cuando los participantes aprendieron

usar el Panel de Simulación y se percataron que aparecían objetos en el

ambiente cada vez que se seleccionaba simular, no tuvieron la misma dificultad

para los siguientes ingredientes. La interacción con los NPCs en los dos

primeros ingredientes fue entendida por los participantes a pesar de existir

molestias por el uso del texto en el Local Chat. Las machinimas demostraron ser

una herramienta de comunicación de los conceptos de la técnica de Workshops.

Tanto para el ingrediente de Trabajo Previo como para el de Espacio

Compartido, los participantes sintieron falta de un mecanismo de corrección de

errores. La retroalimentación en estos dos ingredientes fue diferente. Los

participantes expresaron que la retroalimentación visual dada en el ingrediente

de Trabajo Previo facilitó más la identificación de los errores, tal como se

observa en la Tabla 19, donde todos los participantes mostraron dificultad con la

retroalimentación textual del ingrediente de Espacio Compartido.

Tabla 19 Reincidencias en la facilidad de Uso

Personas Adecuadas Nº

Selecciona una de las respuestas del panel de simulación sin comunicarse con los NPCs. 6

Trabajo Previo

No puede retirar los objetos incorrectos una vez que verificó o acabó el tiempo (también para Espacio Compartido). 8

No puede retirar los objetos incorrectos cuando está jugando (también para Espacio Compartido). 6

Espacio Compartido

La lectura de la retroalimentación textual hace difícil saber cuáles son las respuestas correctas. 9


La Tabla 20 muestra las reincidencias en el entendimiento del objetivo del

juego. Para este primer tipo de juego basado en los ingredientes de Personas

Adecuadas y Propósito Compartido, los participantes manifestaron que el

objetivo del juego fue entendido con facilidad y sólo 2 participantes expresaron

que consiguieron la respuesta correcta pero no entendieron porque esa era la

respuesta, sintieron falta de un mecanismo que informe el porqué de su

selección.

Tabla 20 Reincidencias en el entendimiento del objetivo del juego

Personas Adecuadas y Propósito Compartido Nº

No está seguro porque esa respuesta es la correcta. 2

Trabajo Previo y Espacio Compartido

Al terminar de jugar el ingrediente sintió que no aprendió los términos de los elementos que no sabía dónde colocar (también para Espacio Compartido).

9

El segundo tipo de juego en TREG fue prototipado en los ingredientes de

Trabajo Previo y Espacio Compartido y está relacionado a la interacción del

participante con objetos 3D, presión del tiempo y la utilización del método ensayo

y error para alcanzar la solución. Tal como lo demuestra la Tabla 18, este tipo de

juego causó mayor dificultad de uso y entendimiento del objetivo del juego.

Cuando se analiza la facilidad del uso de estos ingredientes en la Tabla 19, se

muestra que los participantes sintieron la falta de un mecanismo para corregir los

elementos que fueron colocados incorrectamente. Además, la retroalimentación

de los errores cometidos por el participante fue diferente para los dos

ingredientes. En el ingrediente de Trabajo Previo, los elementos correctos

aparecían resaltados, lo que permitía al jugador visualizarlos en el ambiente. En

cambio, en el ingrediente Espacio Compartido, la retroalimentación al jugador

aparece en forma textual (Local Chat). Tal como se puede observar en la Tabla

20, este tipo de retroalimentación causo dificultad en todos los participantes. Al

haber utilizado sólo el contenido expuesto por el libro, algunos términos no son

definidos o se espera que sean sobreentendidos. Se debe considerar poner a

disposición de los participantes, un glosario de términos para minimizar este tipo

de dificultad.

5.3.3.Jugabilidad

Como se definió anteriormente, la jugabilidad de TREG debe tener la

capacidad para que el jugador pueda creerse lo que juega e integrarse en el


mundo virtual. Esta característica fue medida con el cuestionario IPQ que mide la

presencia del participante en el mundo virtual.

Los valores que se presentan en la Tabla 21, corresponde a los ajustes

propuestos por el método [41] a las respuestas de los participantes mostradas en

el Apéndice B8. Estos ajustes cambian el rango de medida de 1 a 7 para el

rango de 0 a 6. Por ejemplo, si el valor de una respuesta fue 5, este valor fue

cambiado para 4. Las variables 3 y 9 fueron invertidas antes de hacer los

ajustes.

Tabla 21. Conversión de resultados del cuestionario IPQ

IPQ Característica Prom. Des P1 P2 P3 P4 P5 P6 P7 P8 P9

G1 Sensación de estar ahí

4,00 1,66 3 2 6 4 2 4 3 6 6

SP1 Sensación de un entorno virtual por detrás

3,22 1,86 1 3 3 3 1 4 2 6 6

SP2 No percibí sólo figuras

4,78 1,20 6 4 6 3 4 4 4 6 6

SP3 sin sensación de estar en un espacio virtual

3,44 2,24 6 3 4 3 6 1 2 0 6

SP4 sensación de actuación en un entorno virtual

3,78 2,05 6 3 4 3 0 4 2 6 6

SP5 sensación de estar presente en el entorno virtual

4,22 1,56 6 3 4 3 3 5 2 6 6

INV1 Percepción del entorno real.

2,33 1,66 2 3 4 0 0 4 1 3 4

INV2 No percibe el entorno real. 1,78 2,17 0 3 4 0 6 2 1 0 0

INV3 No presté atención del entorno real.

1,78 1,64 0 3 1 0 2 5 1 3 1

INV4 Atención captada por el entorno virtual

2,11 1,45 0 2 3 1 1 4 1 3 4

IPQ: ID del cuestionario IPQ

G1: Ítem general

SPx: Presencia espacial

INVx: Participación

Prom: Promedio

Des: Desviación estándar

Px: Número de Participante


0

1

2

3

4

5

6

SP2 SP5 G1 SP4 SP3 SP1 INV1 INV4 INV2 INV3

0

1

2

3

4

5

6

Figura 26. Respuestas al cuestionario IPQ

La Figura 26 muestra el valor promedio de estas respuestas por ítem del

cuestionario y la desviación estándar de las respuestas. Los ítems fueron

ordenados descendentemente por el promedio.

Tabla 22. Promedio de los factores de Presencia del cuestionario IPQ

IPQ Característica Prom.

G1 Ítem general: Sensación de estar ahí 4,00 SP Presencia espacial 3,89 INV Participación 2,00

La Tabla 22 muestra el promedio de los factores del cuestionario IPQ. Se

puede observar que tanto el ítem general como la Presencia espacial alcanzaron

valores mayores. Estos ítems revelan la sensación que los participantes tuvieron

de estar en el mundo virtual. También se puede observar que el ítem INV fue

bajo lo que revela que el juego en el ambiente virtual no capturó toda la atención

del jugador. Esta puntuación es comprensible dado que el participante en

ocasiones dejaba de interactuar con el mundo virtual para hacer anotaciones en

una hoja de papel.


6 Conclusiones y trabajos futuros

En esta sección se presentan las conclusiones de nuestra experiencia en

el desarrollo de TREG así como los trabajos futuros.

6.1.Conclusiones

Este proyecto se propuso desarrollar un juego educacional en la técnica de

Workshops a través de simulaciones de diversas situaciones. Este trabajo

presenta un caso exploratorio de nuestra experiencia al combinar técnicas de

juegos y desarrollo de software con el fin de crear el contenido educacional y

prototipar el juego. Asimismo, dicha exploración utiliza como plataforma de

desarrollo el mundo virtual Second Life.

Este juego educacional involucra 2 aspectos importantes para su creación:

el contenido educacional, y el juego. Para la elaboración del contenido

educacional, se tomó como base el libro de Gottesdiener Requirements by

Collaboration [8]. En él, se plantea un proceso de desarrollo de Workshops e

“ingredientes” como las mejores prácticas en este proceso. Se realizó una

división de los ingredientes en torno a las fases del proceso. Se decidió incluir en

TREG a los ingredientes de la fase de planificación de esta división, la cual

incluye los ingredientes de Personas Adecuadas, Propósito Compartido, Trabajo

Previo y Espacio Compartido. Se seleccionó el contenido educacional para cada

uno de los ingredientes y se crearon simulaciones en base a este contenido. El

contenido educacional elaborado no pretende ser un sustituto del libro o del

contenido de una clase, sino ofrecer un juego para dar una visión general de la

importancia de planificar workshops para la captura de requisitos. En las pruebas

de usabilidad realizadas, los participantes expresaron que este objetivo fue

alcanzado.

El desarrollo del software fue guiado por el proceso de prototipación de

Effective Prototyping for Software Makers [9]. Los principales beneficios

obtenidos de este proceso fueron los siguientes:

� El proceso iterativo muestra los objetos tal como serán implantados

en el ambiente de producción debido a que los objetos fueron


creados en Second Life. Esto hace posible percibir el “look and feel”

de los objetos, tener visiones anticipadas del juego y decidir sobre

la permanencia de las características y funcionalidades de los

objetos.

� Reduce los riesgos del costo de implementación al tener varias

alternativas de métodos de prototipación. En el caso de TREG,

fueron utilizados cuatro métodos que fueron seleccionados de

acuerdo a las características de cada iteración. De este modo, se

prototipo en medida a lo necesario. Al tener prototipos de una

menor fidelidad en las dos primeras iteraciones fue posible refinar

el propósito del proyecto y reducir el tiempo de construcción y

programación de los prototipos.

� La técnica de ensayo y error en cada una de las iteraciones

favoreció la retroalimentación para refinar los requisitos hasta

alcanzar el prototipo deseado. Es así como en primera iteración se

pudo determinar el objetivo del proyecto y en la segunda iteración

se visualizó a Workshops como la técnica del contenido

educacional. En las siguientes iteraciones, además de incluir las

técnicas de desarrollo del software, fue posible determinar la

permanencia y necesidad de los objetos prototipados.

� Los criterios de diseño de los prototipos guiaron el diseño,

construcción y presentación de los mismos en Second Life. De esta

forma, se tuvieron guías para no sobrecargar la memoria del

usuario de TREG, uniformizar el diseño visual de los objetos, tener

un patrón de uso de la implementación de Second Life y considerar

aspectos del desempeño del juego.

El diseño de TREG fue orientado para una implementación de un juego

educacional en Second Life. Para esto se combinaron técnicas que posibilitaron

una anticipada retroalimentación en cada una de las iteraciones y tener una

visión de diversas perspectivas del software. Dichas técnicas fueron: Branching

Stories como un género de simulaciones en juegos, Escenarios como la técnica

de especificación de requisitos y los diagramas de clases, máquinas de estados

y comunicación para el modelamiento del software.

El grafo de Branching Stories fue implementado en TREG para tener una

visión general de los diversos caminos que el jugador podría escoger durante su

experiencia en TREG. Se seleccionó esta técnica sobre Storyboards dado que


para nuestra experiencia en la segunda interacción, Storyboards consumía un

mayor tiempo de elaboración. Los principales beneficios percibidos al uso de

Branching Stories fueron que posibilitó tener una visibilidad global del juego al

poder ver todos los caminos en TREG y dejó abierta al jugador la posibilidad de

intentar y errar así como tener conocimiento del impacto en sus decisiones al

obtener retroalimentación en las fallas de su selección.

El grafo de Branching Stories fue especificado usando la técnica de

Escenarios. Utilizando esta técnica de Requisitos se especificó cada nodo del

grafo manteniéndose la secuencia de los caminos a través de la sección de

excepciones. Asimismo, esta técnica guió el modelamiento del software al

proveer en detalle la información sobre el funcionamiento de TREG.

A pesar de que LSL no es un lenguaje de programación orientado a

objetos, el diseño de TREG adaptó diagramas usados para orientación a objetos

para tener diversas perspectivas del software. El diagrama de clases fue usado

para representar los objetos creados en Second Life y tener una visión de las

todas relaciones existentes entre ellos. Los diagramas de comunicación

mostraron para cada escenario especificado, los objetos y los canales de

comunicación existentes entre ellos así como las transiciones y los eventos que

son activados. Finalmente se utilizaron los diagramas de máquinas de estados

para otorgar el comportamiento dinámico de las entidades del juego. Con esta

perspectiva, además de tener el control del comportamiento del objeto en el

juego, facilitó la implementación en LSL, un lenguaje orientado a eventos.

Las pruebas realizadas mostraron las fortalezas y debilidades del juego en

cada una de las métricas evaluadas. Se contó dos principales tipos de juegos, el

primero (Personas Adecuadas y Propósito Compartido) mostró la interacción de

los participantes con NPCs y cómo el participante puede involucrarse con un rol

dentro de un mundo virtual. Asimismo, este tipo de juego mostró la posibilidad

del uso de machinimas como herramienta de comunicación de resultados e

información general. El otro tipo de juegos (Trabajo Previo y Espacio

Compartido) mostró la interacción del participante con objetos 3D y la utilización

del método de ensayo y error para alcanzar el objetivo.

Finalmente, nuestra experiencia en el desarrollo de este juego fue una

aprendizaje constante del uso de la herramienta Second Life lo que permitió la

prototipación de este juego a pesar de la existencia de limitaciones al utilizar sus

editores de construcción y programación. Cabe resaltar que se utilizó Second

Life como la plataforma de desarrollo pero esto no escapa a futuras

implementaciones de TREG en otras plataformas.


6.2.Trabajos futuros

Con la observación y recomendaciones realizadas en las pruebas de

usabilidad fue posible percibir la necesidad de incrementar el contenido de

TREG. A continuación se listan los posibles incrementos que podrían mejorar la

funcionalidad del juego:

o Estructurar TREG de forma multiusuario que posibilite que los

jugadores encuentren los ingredientes colaborativamente.

o Elaboración de un tablero de las Estrellas de TREG que muestre

los 5 mejores puntajes obtenidos en el juego para animar a los

jugadores a obtener los más altos puntajes.

o Introducir un glosario de los términos que pueda ser consultado

durante el juego.

o Utilización de machinimas para explicar el objetivo del juego.

o Incluir puntajes negativos cuando el jugador falla alguna de las

simulaciones de los ingredientes.

o Minimizar el uso de Local Chat como forma de mostrar el texto.

o Posibilitar la corrección de errores

Se espera que este trabajo colabore con la elaboración de otros proyectos

en las líneas de trabajo que quedan abiertas. A continuación resumimos aquellas

que consideramos más interesantes:

o Experimentar con la implementación de juegos en otras áreas de

conocimiento.

o Estudiar la posibilidad de ampliar el contenido educacional de

TREG para un juego multiusuario y explorar la interacción entre los

jugadores.

o Evaluar el aprendizaje de los participantes en este tipo de juegos.

o Utilizar el contenido educacional y las técnicas propuestas para

implementar TREG en un ambiente 2D y analizar su

comportamiento y diferencias.

o Incluir otras formas educacionales de exponer los resultados para

los participantes y obtener el feedback de ellos.

o Explorar la utilización de las técnicas de juegos y desarrollo de

software presentadas en este documento para implementar juegos

en otro tipo de ambientes.


Además este trabajo es un punto de partida de una propuesta de

doctorado que fue proyectado para trabajar con Cross-reality: Wearable

Computers y Mundos Virtuales. De esta forma, el aprendizaje obtenido en este

mundo virtual servirá como base para la elaboración de este futuro proyecto.


7 Referencias Bibliográficas

[1] C. PETTEY. Gartner Says 80 Percent of Active Internet Users Will Have A "Second Life" in the Virtual World by the End of 2011. Gartner Press. 2007.

[2] RYMASZEWSKI, AU, WALLACE, WINTERS, ONDREJKA, BATSTONE-CUNNINGHAM, et al. Second Life: the office guide. Wiley Press, 2007,.

[3] SIMTEACH: Information and Community for Educators using M.U.V.E.'s. Institutions in Second Life. 2010. Disponible en:

<http://www.simteach.com/wiki/index.php?title=Institutions_and_Organizations_in_SL>. Acceso en: 01 de Febrero del 2010.

[4] KLUGE S., RILEY L., Teaching in Virtual Worlds: Opportunities and Challenges, Issues in Informing Science and Information Technology, Informing Science Institute, 2008.

[5] ALDRICH, C.; Learning by doing; Pfeiffer, USA, 2005.

[6] JOHNSON, L., LEVINE, A., SMITH, R. 2009 Horizon Report. Austin, TX: The New Media Consortium, 2009.

[7] LENHART A., KAHNE J., MIDDAUGH E., MACGILL A., EVANS C., VITAK J. Teens, Games and Civics. 16 de Septiembre del 2008. Disponible en: <http://pewinternet.org/Reports/2008/Teens-Video-Games-and-Civics.aspx>. Acceso en: 01 de Febrero del 2010.

[8] GOTTESDIENER Ellen, Requirements by Collaboration: Workshops for Defining Needs, Addison Wesley, 2002.

[9] ARNOWITZ, J., ARENT M., BERGER N. Effective Prototyping for Software Makers, Morgan Kaufmann, Elsevier, Inc. 2007

[10] VIRTUAL WORDS REVIEW. What is a Virtual Word? Disponible en: < http://www.virtualworldsreview.com/info/whatis.shtml> Acceso en: 01 de Febrero del 2010.

[11] NITSCHE M., Film live: And Excursion into Machinima. Developing Interactive Narrative Content, Munich, pp. 210-243, 2005.

[12] DAVISON, R., The Role of Groupware in Requirements Specification. Group Decision and Negotiation. Springer Netherlands, pp 149-160, 2004.

[13] LEITE J., ROSSI G., BALAGUER F., MAIORANA V., KAPLAN G., HADAD G., OLIVEROS A.; Enhancing a Requirements Baseline with Scenarios; Requirements Engineering, Springer, 1997; pp. 84-198.

[14] AMBLER S., The elements of UML 2.0 style, Cambridge University Press, 2005

[15] JOY B., ALEXANDER M., Games-Based Requirements Engineering Training: An Initial Experience Report, 16th IEEE International Requirements Engineering Conference, Spain, 2008, pp. 211-216.


[16] SMITH R., GOTEL O., Gameplay to Introduce and Reinforce Requirements Engineering Practices, 16th IEEE International Requirements Engineering Conference, Spain, 2008, pp. 95-104.

[17] CYBULSKI J., PARKER C., SEGRAVE S., Using constructivist experiential simulations in RE education, In Proceedings of the 11th Australian Workshop on Requirements Engineering, Australia, 2006.

[18] CUNHA M., RAPOSO A., FUKS H., Educational Technology for Collaborative Virtual Environments, In Proceedings of 12th International Conference on CSCW in Design, China, April 16-18, 2008.

[19] EN YE, CHANG LIU, POLACK-WAHL, Enhancing Software Engineering Education Using Teaching Aids in 3-D Online Virtual Worlds. 37th ASEE/IEEE Frontiers in Education Conference T1E-8, Milwaukee, WI, October 2007.

[20] ERNST M., The Groupthink Specification Exercise, In Software Engineering Education in the Modern Age: Challenges and Possibilities, Lecture Notes in Computer Science vol. 4309, Dec. 2006, pp. 89-107.

[21] OHIO UNIVERSITY IN SECOND LIFE. Groupthink exercise. Disponible en: <http://slurl.com/secondlife/OHIO%20Outreach/144/156/32>, Acceso en: 01 de Febrero del 2010.

[22] NAVARRO, Emily Oh, HOEK, Andre van der, Comprehensive Evaluation of an Educational Software Engineering Simulation Environment, 20th Conference on Software Engineering Education & Training (CSEET'07), 2007, pp.195-202.

[23] OHIO UNIVERSITY IN SECOND LIFE. SimSE Game. Disponible en: <http://slurl.com/secondlife/OHIO%20Outreach/158/149/32>, Acceso en: 01 de Febrero del 2010.

[24] RAMLOLL, R., BEEDASY, J., HUDNALL STAMM, B., PILAND, N., CUNNINGHAM, B., KIRKWOOD, A., MASSAD, P., SPEARMAN, R., PATEL, A., TIVIS, R. AND C. KELCHNER, Distance Learning and Simulation Technologies to Support Bioterrorism Preparedness Education, Proceedings of the ISCA 21st International Conference, ISBN: 1-880843-58-7, pp 235-241, 2006.

[25] IDAHO STATE UNIVERSITY, Virtual training at Bingham Memorial Hospital, Disponible en: <http://play2train.us>. Acceso en: 01 de Febrero del 2010.

[26] IBM. Open Encounters of z Virtual Kind skills challenge. Disponible en: <http://www-304.ibm.com/jct01005c/university/students/contests/SecondLife /index.html> Acceso en: 20 de Octubre del 2009.

[27] Van ECK, P.A.T. (2001) A Compositional Semantic Structure for Multi-Agent Systems Dynamics. PhD thesis, Vrije Universiteit, Amsterdam. ISBN 90-9014746-2

[28] GADELHA, B. Comportamento autônomo no Second Life: Adicionando agentes ao TREG. Monografias em Ciência da Computação. Curso Multiagentes. PUC-Rio. 2009.

[29] KANER, S., L. LIND, C. TOLDI, S. FISK, D. BERGER, M. DOYLE; Facilitator’s Guide to Participatory Decision-Making; Jossey-Bass, USA, 2007.


[30] LEITE J., HADAD G., DOORN J., KAPLAN G.; A Scenario Construction Process; Requirements Engineering, 2000; pp. 38 - 61.

[31] TRUONG, K., HAYES, G, ABOWD G, Storyboarding: An Empirical Determination of Best Practices and Effective Guidelines, In Proceedings of the 6th conference on Designing Interactive systems, pp 12-21. 2006.

[32] VEGA, K., PEREIRA, A., ROBICHEZ, G., RAPOSO, A. & FUKS, H. Prototyping games for training and education in Second Life: Time2Play and TREG. SBGames 2009, VIII Brazilian Symposium on Digital Games and Entertainment, pp. 167-175.

[33] VEGA, K., ROBICHEZ, G. & FUKS, H. Training in Requirements by Collaboration:Branching Stories in Second Life . SBSC 2009, VI Simpósio Brasileiro de Sistemas Colaborativos, Fortaleza, outubro 2009. ISBN: 978-0-7695-3918-8, Ed. IEEE-CS, pp. 116-122.

[34] ISO 9241 Part 1-17: Ergonomic Requirements for Office Work with visual display terminals.

[35] CLANTON, C.: An Interpreted Demonstration of Computer Game Design. Proceedings of the conference on CHI 98 summary: human factors in computing Systems. Chi, 1998, 1-2

[36] PAPALOUKAS, S. XENOS, M. 2008. Usability and education of games through combined assessment methods. Proceedings of the 1st international conference on Pervasive Technologies Related to Assistive Environments, Athens, Greece, July 15-19, DOI=http://doi.acm.org/ 10.1145/1389586.1389670

[37] FEDEROFF, M. Heuristic and usability guidelines for the creation and evaluation of fun in video games. Thesis, University Graduate School of Indiana University. 2002.

[38] NILSEN, J. Why You Only Need to Test with 5 Users. Disponible en: <http://www.useit.com/alertbox/20000319.html> Acesso em: 18 de febrero del 2010.

[39] SECOND LIFE. System Requirements. Disponible en: <http://secondlife.com/support/system-requirements/> Acesso em: 02 de febrero del 2010.

[40] ERICSSON, K.; SIMON, H. Protocol Analysis: Verbal Reports as Data. Revised Edition. The MIT Pres, 1993.

[41] IGROUP.ORG PROJECT CONSORTIUM. Igroup Presence Questionnaire. Disponible en: <http://www.igroup.org/projects/ipq/>. Acesso em: 02 de febrero del 2010.

[42] ALENCAR, M. Composição de Métodos de Avaliação de IHC para Ambientes Virtuais Híbridos: Um Estudo de Caso com a HybridDesk. Master Thesis. PUC-Rio. 2009.


Apéndice A – Diseño del software

A.1. Escenario: Personas Adecuadas. Excepción opción A

Escenario

ID: WS04

Título: Personas Adecuadas. Excepción opción A

Objetivo: Muestra al jugador los problemas que ocasiona su selección (a) Ethan Harris, Andrea Richmond, Brianna Rosebud) y una posible solución.

Contexto: Se realizó el escenario WS03 y el jugador seleccionó una opción incorrecta.


Recursos: Machinima. NPCs sentados en la mesa según selección.

Actores: Jugador.

Episodios:

1. El objeto muestra un Machinima con. 1. a. Un diálogo entre los participantes seleccionados para el workshop. The workshop for identifying the primary Use Cases of the sales module begins…

Ethan Harris: I am glad we will work together for this project. This meeting we must talk about how to increase our sales the next month. Andrea: … Brianna: I could not agree more. Ethan: Thanks Brianna. Last year, our sales revenue grew from $5 million to $8 … One hour later….

Ethan: And now we can close this workshop. Please, read our agreements. Joshua: Well Mr. Haris, we didn’t identify any Use Case. 1. b. Los principales problemas de esta selección

- Project sponsor no para de hablar. - Direct User 2 no habla mucho. - Direct User 3 es influenciado por el Vice-presidente.

1. c. Se muestra al jugador una solución a el problema:

- Aplicar “wall of wonder”

- “Stacking”. Define prioridades de participación.

3. El HUD reduce el puntaje y no incrementa el número de ingredientes.

Figura A.1. Escenario de Personas Adecuadas. Excepción opción A


A.2. Escenario: Personas Adecuadas. Excepción opción B

Escenario

ID: WS05

Título: Personas Adecuadas. Excepción opción B

Objetivo: Muestra al jugador los problemas que ocasiona su selección (b) Ethan Harris, Brianna Rosebud, Olivia Devoix) y una posible solución.



Recursos: Machinima. NPCs sentados en la mesa según selección.

Actores: Jugador.

Episodios:

1. El objeto muestra un Machinima con. 1. a. Un diálogo entre los participantes seleccionados para el workshop. The workshop for identifying the primary Use Cases of the sales module begins...

You (the facilitator): Did anyone know the functionality of the old system? Kate White: I use the reports but I don’t know how the system works. Ethan Harris: I must admit that I don’t know the sale process in detail and I didn’t use the old system. Brianna Rosebud: Me neither. Olivia Devoix: (absent) 1. b. Los principales problemas de esta selección

- Project sponsor no para de hablar. - Ninguno de los participantes conoce y trabaja con el antiguo sistema. - Workshop Sponsor no asiste.

1. c. Se muestra al jugador una solución al problema:

- Reagendar el Workshops. Intente llamar a otros participantes como Content Participants o calling Subject Matter Experts (SMEs)


Figura A.2. Escenario de Personas Adecuadas. Excepción opción B


A.3. Escenario: Personas Adecuadas. Excepción opción D

Escenario

ID: WS06

Título: Personas Adecuadas. Excepción opción D

Objetivo: Muestra al jugador los problemas que ocasiona su selección (d) Elias Callisto, Andrea Richmond, Olivia Devoix) y una posible solución.


Ambiente: Cuarto de simulación Recursos: Machinima. NPCs sentados en la mesa según selección. Actores: Jugador. Episodios:

1. El objeto muestra un Machinima con. 1. a. Un diálogo entre los participantes seleccionados para el workshop. The workshop for identifying the primary Use Cases of the sales module goes on...

Elias: For this workshop, I bring the principal functionalities of the old system and its problems. Andrea: As I am new in the organization, I have made an activity diagram of the actual process of sale. You: thank you very much for your information. It will be very valuable for identifying the new system requirements. Kate White: I think we need an overview of all the business processes. But…Olivia Devoix didn’t come to the workshop. Olivia Devoix: (absent) 1. b. Los principales problemas de esta selección

- Workshop Sponsor no asiste.

1. c. Se muestra al jugador una solución al problema:

- Reagendar el Workshops. Intente llamar a otros participantes que puedan asistir al workshop.


Figura A.3. Escenario de Personas Adecuadas. Excepción opción D


A.4. Canales de comunicación de TREG

Tabla A.1. Canales de comunicación de TREG

Canal Objeto emisor Objeto receptor Mensaje Acción

-252626 TREG_Ingre_Simulate @SimulatorPanel TREG_SimulatorRoom_wall white Makes the windows or walls white or transparent

-27763 Prework Ix treg_flecha x + verificador if it got all the answers correct, the arrow color changes from red to cyan

-24352 Refrigerator MissWorkShop "0"+texture 0 Done Texture sent from refrigerator

-2020 ElementoX (shared space)

SharedSpaceBoard llGetObjectName() element touched

-2021 SharedSpaceBoard ElementoX (shared space) die element was located in the board. It dies.

-8344 Prim Participants TREG Info "1", "2", "3", "4", "5", "6", "7", "8"

Read the right people simulated case in the notecard. Lines: 1 Emma Graves 2 Sophia Amat 3 Andrea Richmond 4 Brianna Rosebud 5 Kate White 6 Olivia Devoix 7 Sara Johnson 8 Isabella Bates

-3445 TREGRightPplControl - Opt1,Opt2,Opt3,Opt4

kf_WSmesaSillas (BriannaOliviaRezz, AndreaRezz, EmmaSophiaRezz)

"1", "2", "3", "4"

Right People Rez in the table the participants selected in the Right People Ingredient BriannaOliviaRezz Message: 1, 3. Rezz:Brianna Message: 2, 4. Rezz: Olivia AndreaRezz Message: 1, 2, 3, 4. Rezz Andrea EmmaSophiaRezz


Message: 1, 2. Rezz: Emma Message: 3, 4. Rezz: Sophia Shared Purpose Message: 1-4. colored the NPC

-71138 Simulator Room Controller

TREGRightPplrezParticipants TREGRightPplControl "muere" Used for killing some objects (make them dissapear from the

environment)

-71138 TREGRightPplControl - Opt1,Opt2,Opt3,Opt4

TREGRightPplrezParticipants TREGRightPplControl "rightppl"

Used for killing some objects (make them dissapear from the environment)

-71138 TREGRightPplControl

- Opt1

TREGRightPplrezParticipants (TREGRightPplrezParticipants-SopieAmat, rezOlivia)

"rightppl1"

Rez the participants who must be stand up. Opt1. Sit: Emma Graves Andrea Richmond Brianna Rosebud Stand up: Sophia Amat Olivia Devoix

-71138 TREGRightPplControl - Opt2

TREGRightPplrezParticipants (RezBrianna, TREGRightPplrezParticipants-SopieAmat)

"rightppl2"

Rez the participants who must be stand up Opt2. Sit: Emma Graves Andrea Richmond Olivia Devoix Stand Up: Sophia Amat Brianna Rosebud

-6552 pot TREG_HUD ingredientes it asks for verifying how many correct answers the player had -6552 TREG_HUD pot verificador sends the number of correct answers the player had.

-732441 treg_chair teleporter object "die" it dissapears the teleporter chair

-2009 Simulator Room Controller ingredient says the ingredient were its changing



TREGRightPplrezParticipants (rezEmma, rezOlivia) "rightppl3"

Rez the participants who must be stand up Opt3. Sit: Sophia Amat Andrea Richmond Brianna Rosebud Stand up: Emma Graves Olivia Devoix


TREGRightPplrezParticipants (RezBrianna, rezEmma)

"rightppl4"

Rez the participants who must be stand up Opt4. Sit: Sophia Amat Andrea Richmond Olivia Devoix Stand Up: Emma Graves Brianna Rosebud

3000 TREG_Unidades, Decenas count = count +

(integer)message ;

Changes the number of ingredients in the HUD

3001 TREG_Unidades, Decenas, Centenas

count = count + (integer)message

; Changes the score of the HUD

2998 Changes the investment, time and level

-72673 Board 1| 2 | 3 | 4 TREG_HUD verificador ShareSpace If the 4 boards where correct, change the score

-72674 Board 1| 2 | 3 TREG_HUD verificador PreWork If the 3 boards where correct, change the score

-84336 opt 1 | 2 | 3 TREG_machinimas watch1, watch2, watch3

It will rezz the machinima video according to the rigth people option selected


A.5. Ejemplos de diagramas de comunicación en TREG

Figura A.4. Diagrama de comunicación del Escenario WS04

Figura A.5. Diagrama de comunicación del Escenario WS04


A.6. Ejemplos de diagramas de estados en TREG

Figura A.6. Diagrama de máquinas de estados del objeto MesaSillas

Figura A.7. Diagrama de máquinas de estados del objeto Notecard

Apéndice B – Documentos usados en las pruebas de usabilidad 97

Apéndice B - Documentos usados en las pruebas de usabilidad

B.1. Término de Consentimiento

Termo de Consentimento para Avaliação do TREG

Você foi convidado(a) pelo Groupware do Laboratório de Engenharia de

Software (LES) um grupo de pesquisas do Departamento de Informática da

PUC-Rio, para participar de um teste de avaliação do TREG, um jogo para o

treinamento em Engenharia de Requisitos.

Neste teste, buscamos verificar a usabilidade do TREG (Training in

Requirements Engineering Game), durante o uso do jogo em todos seus

cenários. Buscamos conhecer suas idéias e opiniões para que o jogo possa

atender da melhor maneira possível os seus usuários.

Por esta razão, solicitamos seu consentimento para a realização deste

teste e, em seguida, uma entrevista. Para tanto, é importante que você tenha

algumas informações:

1. Os dados coletados durante o teste destinam-se estritamente a

atividades de pesquisa e desenvolvimento.

2. A equipe desta pesquisa tem o compromisso de divulgar os resultados

de suas pesquisas para fins acadêmicos. A divulgação destes resultados pauta-

se no respeito a sua privacidade e o anonimato dos mesmos é preservado em

quaisquer documentos que elaboramos.

3. O consentimento para o teste é uma escolha livre, feita mediante a

prestação de todos os esclarecimentos necessários sobre a pesquisa.

4. A realização do teste pode ser interrompida a qualquer momento,

segundo a disponibilidade do participante. Neste caso, a equipe se compromete

a descartar o teste para fins da avaliação a que se destinaria.


5. Nossa equipe encontra-se disponível para contato através do telefone

(21) 83444854, ou pelo email [email protected]. Caso queira tirar alguma

dúvida, procure por Katia Cánepa Vega.

De posse das informações acima, gostaríamos que você se pronunciasse

acerca do teste.

( ) Dou meu consentimento para sua realização.

( ) Não autorizo sua realização.

Rio de Janeiro, _____ de Janeiro de 2010.

Participante Entrevistador e Responsável

Nome: _______________________

Assinatura:____________________

Nome: _______________________

Assinatura:____________________

Caso você tenha optado por participar, por favor, responda ao breve

questionário na próxima folha. Obrigada!


B.2. Cuestionario del Perfil y Experiencia del Participante

Questionário Pré-Uso –

Perfil e Experiência Participante

Data: ____ / ____ / _________

1. Dados Pessoais

Nome: _____________________________________________________

Idade: ______ Sexo (M ou F): ____

2. Experiência com Mundos Virtuais

Você usa freqüentemente Second Life?

( ) Sim

( ) Não, mas uso outros mundos virtuais 3D

( ) Não

Como você considera o seu nível de conhecimento com o SL?

(5 = especialista; 1 - novato)

3. Experiência com Workshops

Você usa a técnica de Workshops para a elicitação de requisitos?

( ) Sim. Eu utilizo a técnica de Workshops

( ) Não, mas uso outras técnicas

( ) Não, nunca fiz elicitação de requisitos


B.3. Entrenamiento en Second Life para el uso de TREG

El entrenamiento en Second Life se realizó en sesiones individuales en el

mismo entorno donde se realizaron las pruebas de usabilidad y bajo las mismas

condiciones técnicas. Cada entrenamiento se realizó dependiendo del perfil del

participante, basándonos en su experiencia con Second Life.

Checklist para Expertos en Second Life

El siguiente checklist fue mostrado para los participantes que conocían de

Second Life para verificar que éstos conocen la funcionalidad de Second Life a

ser utilizada en TREG:

Grupo 1: Dado que en este grupo se encuentran los expertos en Second

Life, no requirieron de entrenamiento, sólo un checklist con el entendimiento de

las funcionalidades a usar de Second Life en TREG. Duración aproximada de 1

minuto.

� Desplazamiento



� Local chat

� Inventario

� Ver vídeos en Second Life

� Usar objetos

Entrenamiento seguido con participantes no familiarizados con

Second Life

Dado que los grupos 2 y 3 no están familiarizados con Second Life, se

preparó un entrenamiento donde los participantes de ambos grupos debieron

cumplir con las mismas tareas y el tiempo de duración de cada una dependerá

de la dificultad del participante en acostumbrarse con esta funcionalidad de

Second Life.

Grupo 2: Formado por los participantes que conocen otros mundos

virtuales que no son Second Life. Dado que estos usuarios saben cómo

desplazarse en mundos virtuales, se mostraron los comandos de

desplazamiento y les entrenó en las características básicas para el uso de

Second Life en TREG. Duración aproximada: 21 minutos.


Grupo 3: El participante tendrá un entrenamiento con las mismas tareas

que el Grupo 2 pero más intensivo. Se realizó una introducción a mundos

virtuales y Second Life y se entrenó en los comandos de desplazamiento y en las

funcionalidades necesarias para conseguir jugar TREG. Duración aproximada:

40 minutos. Se dio un intervalo de 10 minutos para la persona descansar para

luego jugar TREG.

Los participantes fueron entrenados en las siguientes funcionalidades de

Second Life:

� Desplazamiento

El instructor enseña al participante las formas de desplazarse (hacia

delante, atrás, izquierda, derecha y correr). El participante experimenta las

formas de moverse en Second Life y sigue al avatar el instructor hasta

acostumbrarse con estos movimientos.


El participante fue teleportado a la isla de los Greenies. Un lugar muy

popular en Second Life donde el participante ve otros avatares y varios objetos

de dimensiones mucho mayores a las de su avatar. El entorno es una cocina

gigante y el instructor le da la tarea de buscar 3 elementos que en este

ambiente: un ipod, una revista y cigarros. El participante, sin desplazarse por el

ambiente, tiene que encontrar estos tres elementos que se encuentran

escondidos. De esta forma fue practicada la función de mover la cámara en torno

al eje de los objetos y aproximándose hasta ellos.

Figura B.1. Entrenamiento en Grennies’ home


Posteriormente se teleportó al participante a la isla de la PUC-Rio donde

se tenían preparados varios objetos para continuar con el entrenamiento.


El instructor mostró como los avatares pueden interactuar con los objetos

al hacer un simple clic en ellos o haciendo clic derecho y viendo el Pie Menu de

Second Life, donde muestran las opciones básicas de los objetos de Second Life

y, de ser el caso, las opciones programadas en el objeto (sentarse, tocar,

comprar, etc.).

Figura B.2. Instructor mostrando opción de Pie Menu en Second Life

� Local chat

Otra funcionalidad que se encuentra en Second Life y es usada en TREG

es el Local Chat. Funciona como un chat clásico donde los avatares se

comunican pero además los avatares pueden recibir mensajes de los objetos.

Para entender esta funcionalidad, se creó un juego. En este juego se tienen 9

objetos. Cuando el participante toca uno de los objetos, este le va a enviar un

mensaje con un número. La tarea del jugador es hacer clic a los objetos en el

orden correcto de tal forma que se tengan la secuencia del 1 al 9. Los

participantes podrán mantener la ventana del Local Chat abierta para verificar los

objetos tocados y sus respectivos números. De esta forma el participante es

entrenado en la comunicación de avatares con objetos y el uso del Local Chat en

Second Life.

Figura B.3. Juego para entrenamiento en el uso del Local Chat


� Inventario

El inventario es la recopilación de las pertenencias que cada avatar tiene

en Second Life (sin contar las tierras que pueda poseer y los objetos "no copy"

que estén renderizados). El participante recibirá objetos que podrá usar como

cabellos, ropa y zapatos. De esta forma se familiarice con el inventario y aprende

a usar objetos.

Figura B.4. Recepción de objetos y uso del inventario en Second Life.

� Ver vídeos en Second Life

El entrenamiento finaliza cuando se le muestra al participante como puede

ver videos usando la Interfaz en Second Life (parar, pausar o poner la

grabación).


B.4 Entrevista

1. Qual foi sua primeira impressão do jogo?

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

2. Qual foram os pontos fortes e fracos, e possíveis melhoras quando

interagiu com:

� Painel de simulação (Controle ambiente de simulação e simula os 4 ingredientes)

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

� Miss Workshop: (Ajuda no jogo) ___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

� Head Up Display (HUD): (Mostra a pontuação e os

ingredientes achados pelo usuário) ___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

___________________________________________________________

Ordene de 1 (mais) a 3 (menos) segundo a percepção da

importância com os seguintes elementos. Painel da simulação ( ) Miss Workshop () HUD ()


3. Qual foi sua impressão da facilidade/dificuldade no uso do TREG

em cada um dos ingredientes? Y do entendimento do objetivo do jogo?

(NPCs, Machinima, interação com os elementos 3D, tempo)

Ingrediente Facilidade do Uso Entendimento do objetivo

Personas

Adecuadas

Propósito

Compartido

Trabajo Previo

Espacio

Compartido

Ordene de 1 a 4 (de mais ao menos importante), os ingredientes do jogo segundo a facilidade no uso e ao entendimento do objetivo do jogo.

Ingrediente Facilidade de Uso Entendimento do

objetivo do jogo Personas Adecuadas Propósito Compartido Trabajo Previo Espacio Compartido

4. Ao final do jogo, o que você aprendeu sobre a importância de

planejar Workshops para a elicitação de requisitos?


B5 Cuestionario IPQ

Questionário Pós-Teste

Participante: _______________________ Data: ____ / ____ / ____

Favor responder ao questionário a seguir com relação à sua interação com

TREG.

Não existem respostas certas ou erradas, o que importa é a sua opinião

sobre esta experiência.

Marque um X no local da escala que representa seu grau de concordância

com a afirmação à esquerda ou à direita da escala.

1. Eu tive a sensação de estar dentro do ambiente virtual gerado pelo

computador.

Nem um pouco Muito

1 2 3 4 5 6 7

2. De alguma forma eu senti que o ambiente virtual estava à minha volta.

Discordo totalmente Concordo totalmente

1 2 3 4 5 6 7

3. Eu me senti como se estivesse percebendo apenas imagens.


1 2 3 4 5 6 7

4. Eu não me senti presente no espaço virtual.

Não me senti presente Me senti presente

1 2 3 4 5 6 7

5. Eu tive a sensação de estar agindo dentro do ambiente virtual, ao invés

de estar operando algo a partir de fora do ambiente.


1 2 3 4 5 6 7


6. Eu me senti presente no ambiente virtual.


1 2 3 4 5 6 7

7. O quanto você estava ciente do mundo real à sua volta enquanto

navegava no mundo virtual? (ex. ruidos, temperatura, outras pessoas, etc).

Extremamente ciente Nada ciente

1 2 3 4 5 6 7

8. Eu não estava ciente de meu ambiente real.


1 2 3 4 5 6 7

9. Eu ainda prestei atenção no meu ambiente real


1 2 3 4 5 6 7

10. Eu estava totalmente absorvido pelo ambiente virtual.


1 2 3 4 5 6 7


B6. Detalle del entrenamiento en Second Life

A continuación se muestra la tabla con la duración del entrenamiento de

cada uno de los participantes. Teniendo en cuenta que los expertos sólo

completaron el checklist y los novatos y de nivel intermedio completaron las

tareas anteriormente descritas.

Tabla B.1. Respuestas al cuestionario IPQ

Entrenamiento en Second Life

Nº Denominación Sexo Experiencia en Second Life

Tiempo (minutos)

1 Novato Femenino no 42



4 Intermedio Masculino otros mundos virtuales 17

5 Intermedio Masculino otros mundos virtuales

17

6 Intermedio Masculino otros mundos virtuales 30

7 Experto Masculino si 1




B7. Resultados del Cuestionario IP

Tabla B.2. Detalle de intentos de los participantes


Tarea P1 P2 P3 P4 P5 P6 P7 P8 P9

1 Recepción 1 1 1 1 1 1 1 1 1

2 Cocina 2 2 3 2 1 1 2 1 2

3 Right People 3 2 6 2 3 2 2 1 2

4 Shared Purpose 1 2 4 2 2 1 3 3 1

5 Pre-work 3 3 9 4 4 5 4 6 2

6 Shared Space 3 3 12 4 3 4 1 6 2

7 Cocina 1 1 1 1 1 1 1 1 1

Nro. de intentos 14 14 36 16 15 15 14 19 11

Tabla B.3. Detalle del tiempo empleado por los participantes


Tarea P1 P2 P3 P4 P5 P6 P7 P8 P9

1 Recepción 5 2 6 1 1 1 1 1 2

2 Cocina 4 2 7 3 2 4 2 1 4

3 Right People 33 24 21 9 23 7 11 4 35

4 Shared Purpose 20 7 7 3 7 9 8 6 15

5 Pre-work 45 12 32 14 20 23 15 18 15

6 Shared Space 19 13 48 21 21 23 7 25 12

7 Cocina 1 2 2 2 1 2 2 1 1

Tiempo total 127 62 123 53 75 69 46 56 84


B8. Resultados del Cuestionario IPQ

Tabla B.4. Respuestas al cuestionario IPQ


IPQ Característica Prom P1 P2 P3 P4 P5 P6 P7 P8 P9

G1 Sensación de estar ahí 5,00 4 3 7 5 3 5 4 7 7

SP1 Sensación de un entorno virtual detrás

4,22 2 4 4 4 2 5 3 7 7

SP2 sólo figuras 2,22 1 3 1 4 3 3 3 1 1

SP3 sin sensación de estar en un espacio virtual

4,44 7 4 5 4 7 2 3 1 7

SP4 sensación de actuación en un entorno virtual

4,78 7 4 5 4 1 5 3 7 7

SP5 sensación de estar presente en el entorno virtual

5,22 7 4 5 4 4 6 3 7 7

INV1 Percepción del entorno real. 3,33 3 4 5 1 1 5 2 4 5

INV2 No percibe el entorno real. 2,78 1 4 5 1 7 3 2 1 1

INV3 Sin atención del entorno real. 5,22 7 4 6 7 5 2 6 4 6

INV4 Atención captada por el entorno virtual 3,11 1 3 4 2 2 5 2 4 5

IPQ: ID del cuestionario IPQ

G1: ítem general

SPx: presencia espacial

INVx: participación

Prom: Promedio

Px: Número de Participante

Apéndice C – Observación del uso de TREG 111

Apéndice C. Observación del uso de TREG

En este apéndice se muestran los datos obtenidos después de concluidas las

pruebas. Estos datos fueron recolectados durante el entrenamiento, la observación de

las pruebas y las entrevistas realizadas. La siguiente figura muestra a los participantes

de las pruebas usando TREG durante las sesiones realizadas.

Figura C.1. Observación de participantes durante las pruebas


C1. Reporte de las Pruebas de Usabilidad de TREG (P2)

Fecha de las Pruebas: 21/01/2010

Localización de las Pruebas: Laboratorio de Ingeniería de Software (LES)

Participante: #2

Sexo: Femenino

Conocimiento en Second Life: Novato

Conocimiento en Workshops: Conoce otras técnicas

Duración: 1 hora y 50 minutos

Fases Tiempo en cada fase de la sesión

Entrenamiento: 34 minutos Cuestionario inicial: 2 minutos Jugando: 1 hora 2 minutos Entrevista: 10 minutos Cuestionario final: 2 minutos

Observación del Uso de TREG Camino seguido en el juego por el participante. Los participantes deberán

encontrar los ingredientes de la receta de Planificación de Workshops.

Resumen de las tareas realizadas por el jugador.

Tareas Tiempo (minutos) Intentos

Recepción 2 1 Cocina 2 2 Personas Adecuadas 24 2 Propósito Compartido 7 2 Trabajo Previo 12 3 Espacio Compartido 13 3 Cocina 2 1

Detalle de la observación del jugador en TREG

Tareas Recepción Objetivo: Iniciar el juego y encontrar los recursos del juego Tiempo:2 minutos Intentos:1 Observaciones:

� Recibe los recursos de Miss Workshop y viste. Presenta dificultad al


encontrar la opción del inventario en Second Life. � Tuvo dificultad para sentar en el sofá (no recordaba el Pie Menu de

Second Life. � No se percató del HUD.

Cocina Objetivo: Entender el objetivo del juego Tiempo: 2 minutos Intentos: 2 Observaciones:

� Encontró la receta del refrigerador pero no sabía cómo encontrar los ingredientes.

� Descubre la puerta que conduce al cuarto de simulación. Personas Adecuadas Objetivo: Simular el primer ingrediente, comunicarse con los NPCs y analizar sus características. Finalmente seleccionar el grupo con las personas adecuadas para el workshop propuesto. Tiempo: 24 minutos Intentos:2 Observaciones:

� Cuando simula el ingrediente, no descubre que los NPCs aparecieron en el ambiente. Intenta seleccionar una de las respuestas y tampoco percibe los cambios en el ambiente ni el video.

� Usa el panel de simulación y aprende como navegar por los ingredientes.

� Regresa al ingrediente Personas Adecuadas y simula el ingrediente nuevamente.

� Cuando se siente perdida, lee la información brindada en LEARN MORE. No encuentra la información que necesitaba. No le gusta tener tanto texto.

� Presenta problemas al mover la cámara y mantener los notecards abiertos.

� Después de 10 minutos de navegación en el Panel de simulación, ve a los NPCs que se encuentran parados en el ambiente y obtiene las características de ellos.

� No comprendió como seleccionar a los participantes del Workshop e intenta, sin éxito, arrastrar a los NPCs a las sillas.

� Se pregunta porque en las etiquetas de los NPCs, además del nombre y el Rol, no aparecen los cargos.

� Posteriormente se comunica con los NPCs sentados y lee las características de ellas.

� Cuando se sienta en la mesa, espera que suceda algo. � Entiende cómo seleccionar una respuesta en el panel de control y

selecciona la opción 2 (opción errada). En el ambiente, los NPCs aparecen sentados alrededor de la mesa del workshop y un video hecho en machinima muestra los errores y posibles soluciones para esa opción. El participante le gusta el video porque muestra el error de la opción seleccionada.

� Intenta nuevamente y encuentra la respuesta correcta.


Propósito Compartido Objetivo: Verificar que los participantes hayan entendido el propósito del workshop. Tiempo:7 minutos Intentos:2 Observaciones:

� Simula el ingrediente y después de la experiencia del anterior ingrediente, ahora ya sabe que los participantes aparecieron en el ambiente.

� Lee en LEARN MORE e percibe que sólo encuentra conceptos relacionados al ingrediente más no cómo solucionar el ingrediente.

� Se comunica con los NPCs y por lo aprendido en el ingrediente Personas Adecuadas, encuentra las opciones en el panel de simulación y selecciona la opción 1.

� Intenta nuevamente y lee con mayor detenimiento las indicaciones y compara el propósito del workshop con la información brindada por los NPCs y selecciona la opción correcta.

Trabajo Previo Objetivo: Identificar los elementos que sirven de entrada para un workshop iterativo. Tiempo: 12 minutos Intentos: 3 Observaciones:

� Inicia la simulación y lee las instrucciones. Entiendo el objetivo del juego.

� Intenta retirar uno de los objetos que colocó como entrada para otra entrada. Le gustaría tener la opción de corregir.

� Se pregunta porque cada entrada no puede tener el mismo número de elementos (8 elementos para 3 entradas).

� Busca información en el LEARN MORE y no encuentra lo que buscaba. Además el tiempo hace que deje de leer y continúe intentando colocar los elementos en las entradas.

� Le gustaría tener un glosario de términos. � Luego de analizar, entiende que los elementos en azul son los

correctos. � Consiguió la respuesta correcta después de 3 intentos.

Espacio Compartido Objetivo: Identificar las herramientas que pueden ser usadas en Workshops distribuidos o co-localizados, síncronos o asíncronos. Tiempo:13 minutos Intentos:3 Observaciones:

� Siente complicación al tener que leer los elementos en el suelo dado que al caer algunos aparecen al revés.

� Busca nuevamente en LEARN MORE información sobre los elementos que no conoce.

� Utiliza, con dificultad en la lectura, el feedback textual para entender cuáles fueron los elementos que erró.


� Escribe las respuestas correctas en una hoja. Utilizando la técnica de intentar y errar, encuentra la respuesta al tercer intento.

Cocina Objetivo: Terminar el juego poniendo los ingredientes en la olla. Tiempo:2 minutos Intentos:1 Observaciones:

� Se dirige a la cocina y busca como terminar el juego. � Toca los objetos en el ambiente. Miss Workshop le informa que debe

poner los objetos en la olla. Finalmente termina el juego. Hallazgos y recomendaciones

Primera impresión del juego

• Le gustó. Le pareció muy bien hecho. • Sintió que se trabó por no conocer Second Life. • Tuvo que adivinar algunas respuestas por no conocer. • Percibió que para una persona que no conoce inglés puede tener limitantes.

Interacción con los elementos del juego Panel de simulación

Lo percibió rápidamente. La información en LEARN MORE le pareció útil pero sugirió cambiar de lugar por ser muy destacado para las simulaciones. Miss Workshop

No sintió la ayuda. Sugirió ponerla en el Cuarto de Simulación para brindar ayuda cuando el jugador se sienta perdido. HUD

No percibió la presencia del HUD durante el juego. Facilidad de uso Personas Adecuadas No vio los objetos que aparecen en el ambiente del primer ingrediente cuando inicia la simulación. Dificultad para entender que cómo seleccionar los NPCs para sentarse. Sugirió tener una lista de las características de los NPCs en vez de tener la que hacer clic en cada uno de ellos. Sintió que las personas sentadas y las 3 sillas vacías, ayudan a entender que es una sala de trabajo a ser completada. Cuando terminó el video quería que desaparezca el monitor de Machinima para poder simular nuevamente el ingrediente. Tuvo dificultades en usar la cámara de Second Life. Propósito Compartido

Fue fácil de jugar.


Entendió como usar el juego porque ya había jugado Personas Adecuadas. Le pareció interesante tener los NPCs en pie y comunicarse con ellos. Sugirió tener el diálogo de los NPCs en llamadas forma de balones encima de ellos para que quede claro que son los NPCs que están hablando. Trabajo Previo Le pareció que fue fácil de jugar. Le pareció que el azul resalto bien a las respuestas correctas. Le gustaría tener la opción de retirar los objetos de los cuadrados si están incorrectos. Sintió la presión del tiempo. Por esta razón, la información en LEARN MORE fue leída muy rápidamente. Espacio Compartido

Le pareció fácil de usar y ayudó que ya había jugado Trabajo Previo. Tanto en Trabajo Previo como en Espacio Compartido:

• Es intuitivo cuando caen los objetos, que deben ser colocados en los cuadrados.

• Los bordes de los cuadrados (azules y brillantes) llaman la atención. • Sintió dificultad al leer algunos elementos que están seleccionados y

cambian de color a amarillo. Entendimiento del Juego Personas Adecuadas

Al inicio no entendió el objetivo del juego porque no entendía como jugarlo. Le pareció que no quedaron claros los roles en un Workshop. A través del video se pudo dar cuenta del error en su elección. Manifestó que el objetivo de este ingrediente era descubrir a las personas correctas para el Workshop. Propósito Compartido

Le fue fácil identificar que el objetivo del juego es ver si las personas entendieron correctamente el propósito del Workshop. Trabajo Previo Dado que el participante trabaja con Ingeniería de Software, entendió que el objetivo del juego con facilidad y le pareció muy intuitivo. Por la presión del tiempo, se sentía más enfocada en acertar las respuestas que en aprender para que servía cada elemento. Espacio Compartido

Fue fácil identificar el objetivo del juego. Tanto para este ingrediente como para Trabajo Previo, al no contar con un glosario, le fue complicado entender algunos términos y termina adivinando el resultado. Importancia de planificar Workshops para la elicitación de requisitos. Explica que en su parecer el juego puede ser utilizado para entrenar a una persona que se quiere iniciar en la técnica. Dio de ejemplo que podría ser usado para explicar los conceptos básicos a un nuevo integrante del equipo o empresa. Le pareció interesante el contenido del juego y sugirió que pueda usarse en otra plataforma, no necesariamente Second Life ni 3D.





Participante: #6

Sexo: Masculino

Conocimiento en Second Life: Intermedio

Conocimiento en Workshops: Conoce la técnica


Fases

Tiempo en cada fase de la sesión

Entrenamiento: 30 minutos Cuestionario inicial: 2 minutos Jugando: 1 hora 9 minutos Entrevista: 5 minutos Cuestionario final: 2 minutos

Observación del Uso de TREG

Camino seguido en el juego por el participante. Los participantes deberán




Recepción 1 1 Cocina 4 1 Personas Adecuadas 7 2 Propósito Compartido 9 1 Trabajo Previo 23 5 Espacio Compartido 23 4 Cocina 2 1



Tareas Recepción Objetivo: Iniciar el juego y encontrar los recursos del juego Tiempo:1 minuto Intentos:1 Observaciones:

� Recibe los recursos de Miss Workshop y viste sólo el HUD, siguiendo las instrucciones de Miss Workshop. Presenta dificultad al encontrar la opción del inventario en Second Life.

Cocina Objetivo: Entender el objetivo del juego Tiempo: 4 minutos Intentos: 1 Observaciones:

� Encontró la receta del refrigerador pero no sabía cómo encontrar los ingredientes. Se pregunta por las personas que debe encontrar para Personas Adecuadas.

� Descubre la puerta que conduce al cuarto de simulación. � Siente falta del movimiento de cámara horizontal y vertical que usaba

en juegos. Personas Adecuadas Objetivo: Simular el primer ingrediente, comunicarse con los NPCs y analizar sus características. Finalmente seleccionar el grupo con las personas adecuadas para el workshop propuesto. Tiempo: 7 minutos Intentos:2 Observaciones:

� Usa el panel de simulación y simula el ingrediente. � Ve a los NPCs que se encuentran parados en el ambiente y obtiene

las características de ellos. También se comunicó con uno de los que están sentados.

� Entiende cómo seleccionar una respuesta en el panel de control y selecciona la opción 4 (opción incorrecta). En el ambiente, los NPCs aparecen sentados alrededor de la mesa del workshop y un video hecho en machinima muestra los errores y posibles soluciones para esa opción. El participante ve el video y entiende su falla.

� Intenta comunicarse nuevamente con los NPCs pero no se da cuenta que tiene que simular nuevamente para seleccionar otra respuesta.

� Intenta simulando nuevamente y encuentra la respuesta correcta. Propósito Compartido Objetivo: Verificar que los participantes hayan entendido el propósito del workshop. Tiempo:9 minutos Intentos:1 Observaciones:

� Simula el ingrediente y lee en LEARN MORE algunos notecards.


� Se comunica con los NPCs y encuentra las opciones en el panel de simulación y selecciona la opción correcta.


� Inicia la simulación y lee las instrucciones. Entiendo el objetivo del juego. Le gustó el seleccionar un objeto y que aparezca en el cuadro seleccionado.

� Le llama la atención que llamen al cuadro de Input cuando según su entendimiento debería ser Input/Outputs o sólo Productos.

� Le incomoda los objetos que cayeron porque dificultan su lectura. Sugiere poner una etiqueta que aparezca cada vez que se pasa el Mouse por cada objeto.

� Intenta retirar uno de los objetos que colocó como entrada para otra entrada. Le gustaría tener la opción de corregir. Selecciona nuevamente la opción Simulate.

� Busca información en el LEARN MORE y no encuentra lo que buscaba. Siente que es mucha información. Le gustaría tener un glosario de términos.

� No se había dado cuenta que existe un reloj que está marcando el tiempo. No leía mucho el Local Chat, estaba más concentrado en el ambiente 3D.

� Cambia de ingrediente y después de conseguir el siguiente ingrediente. Regresa y simula nuevamente Trabajo Previo.

� Le incomoda tener que leer las instrucciones que aparecen en el Local Chat y le gustaría que desaparezcan.

� Siente incomodad al no poder tener una visión de todo el juego. � Luego de analizar, entiende que los elementos en azul son los

correctos. Le parece más fácil tener las respuestas incorrectas marcadas, información que no tenía cuando simuló Espacio Compartido.

� Hace anotaciones en una hoja de las respuestas correctas y los errores y consigue la respuesta correcta.

Espacio Compartido Objetivo: Identificar las herramientas que pueden ser usadas en Workshops distribuidos o co-localizados, síncronos o asíncronos. Tiempo:23 minutos Intentos:4 Observaciones:

� Simula el ingrediente y percibe que es parecido al anterior. � Busca en LEARN MORE información sobre los elementos que no

conoce. Al hacer clic desde lejos no puede abrir los notecards y se aproxima. Le gustaría poder realizar búsquedas para no leer los notecards. Pregunta si existe un glosario de términos.

� Intenta empujar los objetos hasta agruparlos para tener una mejor lectura de los elementos.


� Sintió falta de una explicación de los términos síncrono y asíncrono. � Utiliza el feedback textual para entender cuáles fueron los elementos

que erró. � Simula nuevamente el ingrediente y luego de colocar todos los

ingredientes, encuentra el botón para finalizar el juego. Analiza sus respuestas y se da cuenta que sólo tiene un error.

� Escribe las respuestas correctas en una hoja. Utilizando la técnica de intentar y errar, encuentra la respuesta al cuarto intento.

Cocina Objetivo: Terminar el juego poniendo los ingredientes en la olla. Tiempo:2 minutos Intentos:1 Observaciones:

� Al tener objetos en la puerta, no puede dirigirse a la cocina. Utiliza el Panel de Simulación para retirar los objetos y se dirige a la cocina.

� Miss Workshop le informa que debe poner los objetos en la olla. Al tener el término olla en inglés tuvo dificultad para saber la traducción a su idioma. Finalmente termina el juego.

Hallazgos y recomendaciones


• Le pareció que el hecho de no poder retirar los elementos del cuadro, no lo estimulaba para jugar nuevamente.

• Le gustaría tener las definiciones de los objetos. • Le incomodó mucho tener que leer las informaciones del LEARN MORE. • El local chat suele ser incómodo de leer ya sea porque después de unos

segundos desaparece y se tiene que abrir una ventana diferente o porque en otros casos, ya se entendió el objetivo del ingrediente y no se necesita.

• Sugiere un video explicando que se tiene que hacer en cada ingrediente para que la persona no se sienta perdida.

• Debería no dejar salir al jugador del cuarto de simulación hasta no terminar con todos los ingredientes.


Piensa que es intuitivo y sintió que tuvo facilidad de usarlo dado que él trabaja con informática. Sugiere tener un aviso en los elementos del suelo para seleccionar los correctos. Miss Workshop Le gustó. Sintió que es ella quien dice las instrucciones pero podría tener un audio mientras dice las instrucciones. HUD

Sólo se fijaba en el ingrediente y la puntuación no le sirvió.


Facilidad de uso Personas Adecuadas

Al inicio se sintió un poco perdido, un audio o video ayudaría. Propósito Compartido

Le pareció más fácil de jugar que el primero. Sintió que ya había aprendido como jugar en Personas Adecuadas. Tanto en Propósito Compartido como Personas Adecuadas, fue fácil por su experiencia en juegos. Trabajo Previo La etiqueta en los cuadros podría ser cambiada para input/output o para products. Espacio Compartido

Tanto para este ingrediente como para Trabajo Previo, le pareció que los elementos que caían al suelo dificultaban la lectura por estar al revés. Además sintió que el tiempo era razonable para terminar el juego, no sintió la presión del tiempo. Entendimiento del Juego Personas Adecuadas

En todos los ingredientes, sintió que leyendo las instrucciones era posible saber el objetivo del juego. Propósito Compartido Trabajo Previo Espacio Compartido Le pareció que faltaba una explicación de los términos síncrono y asíncrono (glosario). Importancia de planificar Workshops para la elicitación de requisitos.

Si fue posible aprender algunas cosas pero algunos conceptos específicos

no fue fácil de entender. Le parece que sin incluir a Trabajo Previo, los

ingredientes si enseñan la técnica para planificar Workshops.





Participante: #8

Sexo: Masculino

Conocimiento en Second Life: Experto

Conocimiento en Workshops: Nunca usó técnicas para elicitar de requisitos.


Fases

Tiempo en cada fase de la sesión

Checklist Second Life: 1 minuto Cuestionario inicial: 2 minutos Jugando: 56 minutos Entrevista: 10 minutos Cuestionario final: 2 minutos

Observación del Uso de TREG

Camino seguido en el juego por el participante. Los participantes deberán




Recepción 1 1 Cocina 1 1 Personas Adecuadas

4 1

Propósito Compartido

6 3

Trabajo Previo 18 6 Espacio Compartido

25 6

Cocina 1 1



Tareas Recepción Objetivo: Iniciar el juego y encontrar los recursos del juego Tiempo:1 minuto Intentos:1 Observaciones:

� Recibe los recursos de Miss Workshop y viste. � Busca como seguir en el juego e aparece el mensaje de Miss

Workshop. El jugador siente que este mensaje detallado llegó muy tarde porque ya había descubierto como seguir en TREG.

Cocina Objetivo: Entender el objetivo del juego Tiempo: 1 minuto Intentos: 1 Observaciones:

� Encontró la receta del refrigerador con facilidad y se dirige al cuarto de simulación.

Personas Adecuadas Objetivo: Simular el primer ingrediente, comunicarse con los NPCs y analizar sus características. Finalmente seleccionar el grupo con las personas adecuadas para el workshop propuesto. Tiempo: 4 minutos Intentos:1 Observaciones:

� Lee las instrucciones que aparecen cuando se simula el ingrediente y se comunica con los NPCs parados pero no con los sentados.

� Entiende cómo seleccionar una respuesta en el panel de control y selecciona la opción 3 y consigue el ingrediente. Ve en el HUD que cambio sus puntos y número de ingredientes.

Propósito Compartido Objetivo: Verificar que los participantes hayan entendido el propósito del workshop. Tiempo:6 minutos Intentos:3 Observaciones:

� Cambia el ingrediente para Propósito Compartido pero no presiona el botón simular y espera a que aparezcan los objetos en el ambiente. Luego se da cuenta que tiene que seleccionar “simulate”.

� Selecciona una opción incorrecta y vuelve a simular el ingrediente. � Cuando los NPCs aparecen, se pregunta si ellos dirán lo mismo. � Selecciona otra opción incorrecta. Ve que uno de los NPCs aparece

con una luz diferente y se pregunta si es que ganó o es la opción que seleccionó.

� Simula nuevamente el ingrediente y a leer las instrucciones se da cuenta que él había entendido incorrectamente el propósito del


workshop y por eso estaba seleccionado incorrectamente. � En este intento selecciona la opción correcta y obtiene el ingrediente.

Manifiesta que le gustaría ver el texto del Notecard de los ingredientes.


� Inicia la simulación y lee las instrucciones. Entiendo el objetivo del juego.

� El participante se pregunta cuántos objetos debe poner en cada cuadro y busca información en LEARN MORE. Desiste de leer y manifiesta que le da pereza leer.

� Descubre el botón para parar el tiempo y ver los resultados. Manifiesta que no es fácil ver que este botón sirve para parar el tiempo.

� Se da cuenta que uno de los elementos que colocó en el cuadro esta incorrecto y manifiesta que no le gusta tener que reiniciar el ingrediente y comenzar desde cero.

� Reclama que el texto en el local chat es muy amplio y que ya había entendido las indicaciones.

� Se olvida de uno de los elementos y selecciona el botón para verificar las respuestas. Le hubiese gustado que el juego le diga que se olvidó de un elemento para no tener que comenzar desde cero.

� Consiguió la respuesta correcta después de 6 intentos. Espacio Compartido Objetivo: Identificar las herramientas que pueden ser usadas en Workshops distribuidos o co-localizados, síncronos o asíncronos. Tiempo:25 minutos Intentos:6 Observaciones:

� Al simular el ingrediente, manifiesta que le gusta por estar más familiarizado con esos conceptos.

� Los elementos que no conoce, los coloca en cuadros aleatoriamente. � Al terminar de colocar los objetos, la verificación la realiza

observando el Local Chat pero le gustaría tener señalizado en azul como en el otro ingrediente.

� No conoce algunos conceptos (war room, webcast) y busca en LEARN MORE información pero la información no le ayudó a encontrar la solución. Le gustaría tener un glosario de términos

� Cuando lee la información en LEARN MORE, no percibe que existen texturas con información.

� Escribe las respuestas correctas en una hoja. Utilizando la técnica de intentar y errar, encuentra la respuesta al sexto intento.

Cocina Objetivo: Terminar el juego poniendo los ingredientes en la olla.


Tiempo:1 minuto Intentos:1 Observaciones:

� Se dirige a la cocina y busca como terminar el juego. � Toca la olla de la cocina y finaliza el juego. � Toca a Miss Workshop y esta le informa que el ya tiene los 4

elementos. Hallazgos y recomendaciones


• Le gustó. Siente que las indicaciones del juego conduce al jugador en lo que debe hacer y no se sintió perdido.

• No le gustó que el Local Chat de Second Life aparezca siempre que simule el ingrediente y no es la primera vez.

• Le pareció que el feedback del cuarto ingrediente debió ser como el tercero y mostrar los elementos incorrectos.

• Sintió frustración al tener que simular todo nuevamente en el tercer y cuarto ingrediente. Le gustaría tener la opción de retirar los objetos incorrectos del cuadro.


Le pareció que era fácil de usar. La textura “No Signal” le daba la sensación de tener que esperar para que suceda alguna otra cosa. Sólo percibió del LEARN MORE desde el tercer ingrediente, cuando necesitó buscar sobre algunos conceptos. Miss Workshop No sintió la ayuda en la recepción pero en la cocina sí. HUD

Si lo ayudó. Cada vez que terminaba una simulación del ingrediente, verificaba si su puntuación cambiaba y obtenía el ingrediente. Prefería usarlo de esta forma a tener que leer en el Local Chat. Facilidad de uso Personas Adecuadas

No sintió dificultad en el uso del ingrediente. No sabía que podía interactuar con los NPCs sentados. Propósito Compartido

Trabajo Previo

Tanto para Trabajo Previo como para Espacio Compartido • Sintió la presión del tiempo y le daba más tensión. • No le gustó el botón para parar el tiempo. • Le gustaría corregir sus errores.

Espacio Compartido


Le pareció interesante que no diga cuáles están incorrectos para así seguir intentando. Entendimiento del Juego Personas Adecuadas

Manifestó que el objetivo de este ingrediente era descubrir a las personas correctas para capturar requisitos. Tanto para este ingrediente como para Propósito Compartido, sintió que retrataban mucho más el objetivo del juego. Le mostraba la necesidad de interacción. Estos dos ingredientes los ligó más a un Workshop. Propósito Compartido Tuvo que leer nuevamente para entender el objetivo del Workshop y poder seleccionar la respuesta correcta. Definió como el objetivo del juego es ver si las personas estaban involucradas con el Workshop. Trabajo Previo

Entendió que el objetivo del juego era llevar al workshop los artefactos necesarios. Para conseguir este objetivo, dividió los artefactos en orden de detalle, llevando al primer workshop los artefactos de más alto nivel hasta el último donde buscaba los más técnicos. Este ingrediente y Espacio Compartido los ligó más a fundamentación conceptual. Espacio Compartido

Aprendió lo que es un Webcast. Importancia de planificar Workshops para la elicitación de requisitos.

Explica que no aprendió a planificar. Que aprendió lo necesario para

comenzar a preparar un Workshop, lo que denominó “Pre-planeamiento”.

Piensa que el juego da una visión general de la técnica pero no profundiza.

Apéndice D – Capturas de pantalla 127

Apéndice D. Capturas de pantallas

D.1. Áreas de TREG

El cuarto de simulación

Del área de recepción a la

cocina

De la cocina al cuarto de

simulación a

través del túnel


D.2. Panel de Simulación

1. Panel de Simulación

2. Respuestas

3. Learn More

4. Notecard en Learn More

1

2 3

4


D.3. Ingrediente de Personas Adecuadas

1. Iniciando el ingrediente de Personas Adecuadas 2. Conversación con NPCs sentados 3. Conversación con NPCs parados 4. Mostrando Machinima con los problemas y soluciones

1

2 3

4


D.4. Ingrediente de Propósito Compartido

1. Simulando el Ingrediente de Propósito Compartido 2. Conversación con los NPCs 3. Seleccionando correctamente la opción y ganando el ingrediente

1

2

3


D.5. Ingrediente de Trabajo Previo

1. Simulando el Ingrediente de Trabajo Previo 2. Indicación de cómo jugar mostrada en el panel de simulación 3. Reloj y elemento para parar el tiempo 4. Mostrando las respuestas correctas

1

2

3 4


D.6. Ingrediente de Espacio Compartido

1. Simulando el Ingrediente de Espacio Compartido 2. Indicación de cómo jugar mostrada en el panel de control 3. Respuestas en el tablero del ingrediente

1

2

3

Katia Fabiola Cánepa Vega TREG: Un juego de entrenamiento...

Documents

Transcript of Katia Fabiola Cánepa Vega TREG: Un juego de entrenamiento...