13

Engineering framework for the videogame development process

Marco de trabajo ingenieril para el proceso de desarrollo de videojuegos

Andy Hernández P.1, Karina Pérez T.2, Omar Correa M.3 1, 2, 3Universidad de las Ciencias Informáticas. La Habana, Cuba. 1Centro de Entornos Interactivos 3D. andyhp(AT)uci.cu 2Facultad 4. karinapt(AT)uci.cu 3Dirección de Investigaciones. ocorrea(AT)uci.cu

Artículo de Investigación

Recibido: 21-02-2017 Revisado: 03-05-2017 Aceptado: 19-05-2017

Abstract A software development process for its practice should be guided by guides, models, methodologies and/or frameworks that guarantee the implementation of a high-quality product. It is the software engineering that ground, defines and establishes the bases to carry out a viable implementation according to the needs of the clients. The use of good engineering practices must be in accordance with the context and application domain that the software product to be developed suggests. There are traditional and agile methodologies that define both procedures and guidelines for the development of software domains, such as: software systems, scientific and engineering, embedded, artificial intelligence, and web-based. However, for software development on the video game application domain, these procedures and / or guidelines do not focus on the basic functionalities that represent their mechanics, but focus on functional requirements. With the purpose of effectively contributing to an adequate correspondence between what is specified and represented, with a structured and organized implementation of video games, the present work aims to develop an engineering framework for the video game development process. The framework consists of five stages: conceptualization, design, implementation, testing and maintenance. In addition, it is composed of twenty activities, which generate nine products of engineering work as fundamental outputs from the use of various techniques and tools. The validity of the framework was verified with the application of the Iadov method, from which high satisfaction and positive criteria are obtained from its use.

Keywords: Engineering framework, mechanical, videogames. Resumen Para su práctica, un proceso de desarrollo de software se debe regir por guías, modelos, metodologías y/o marcos de trabajo que garanticen la implementación de un producto de alta calidad. Para llevar a cabo una implementación viable de acuerdo con las necesidades de los clientes, la Ingeniería del Software es la que fundamenta, define y establece las bases. La utilización de buenas prácticas ingenieriles debe estar acordes al contexto y al dominio de aplicación que sugiere el producto de software a desarrollar. Existen metodologías tradicionales y ágiles que definen procedimientos y pautas para el desarrollo de software de dominios, tales como software de sistemas, científicos y de ingeniería, empotrados, de inteligencia artificial y basados en la web. Sin embargo, para el desarrollo de software sobre el dominio de aplicación de videojuegos estos procedimientos no se centran en las funcionalidades básicas que representan sus mecánicas, sino en requisitos funcionales. Con el propósito de contribuir efectivamente a una adecuada correspondencia entre lo que se especifica y lo que se representa con una implementación estructurada y organizada de videojuegos, el presente trabajo tiene como objetivo desarrollar un marco de trabajo ingenieril para el proceso de desarrollo de videojuegos. El marco de trabajo está compuesto por cinco etapas: conceptualización, diseño, implementación, pruebas y mantenimiento; además, está integrado por veinte actividades que generan nueve productos de trabajo ingenieril, tales como salidas fundamentales a partir del uso de variadas técnicas y herramientas. La validez del marco de trabajo fue comprobada con la aplicación del método de Iadov, del cual se obtiene una alta satisfacción y criterios positivos a partir de su utilización.

Palabras clave: Marco de trabajo ingenieril, mecánicas, videojuegos.

© 2017. IAI All rights reserved

(2017). RACCIS 7(1), 13-26

14

1. Introducción

Actualmente, el desarrollo de sistemas informáticos se ha visto condicionado por las necesidades de mejorar los procesos sustanciales que complementan las diferentes esferas productivas, científicas y tecnológicas de la sociedad. Software que logre automatizar y guiar todos los procedimientos de la vida cotidiana están comportándose como punteros en la actual era digital. Las tendencias en la implementación de estos sistemas informáticos se proyectan hacia la utilización de un proceso de desarrollo de software ágil, bien organizado y estructurado.

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando se crea un producto (software o artefacto documental). Sin embargo, una actividad busca lograr un objetivo amplio y se desarrolla sin importar el dominio de la aplicación, tamaño del proyecto, complejidad del esfuerzo o grado de rigor con el que se usará la Ingeniería del Software. Por otro lado, una acción es un conjunto de tareas que produce un producto importante del trabajo y una tarea se centra en un objetivo pequeño, pero bien definido, que produce un resultado tangible [1]. En el contexto de la Ingeniería del Software, un proceso no es una prescripción rígida de cómo elaborar productos software, sino que es un enfoque adaptable que les permite a las personas, que hacen el trabajo, buscar y elegir el conjunto apropiado de acciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna y con calidad suficiente para satisfacer a quienes patrocinaron su creación y a aquellos que lo usarán [1].

Por eso es que la Ingeniería del Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al proceso de desarrollo, operación y mantenimiento de software [2]. Sin embargo, de acuerdo con Pressman [1], es una tecnología multicapas que se complementan y se distribuyen en procesos, métodos y herramientas, buscando un enfoque de calidad durante el proceso de desarrollo de software que, técnicamente, puede ser guiado por un marco de trabajo ingenieril, donde se identifica un pequeño número de actividades estructurales, aplicables a diferentes proyectos de software, sin importar su tamaño o complejidad. Además, la estructura del proceso incluye un conjunto de actividades de apoyo que se pueden aplicar a lo largo de todo el proceso del software [1]. En este proceso se aplican buenas prácticas que permiten alcanzar los niveles de calidad deseados, guiar documentalmente el proceso de producción y mejorar considerablemente la productividad de software. Además, permiten tener aproximaciones de lo que podría ser un producto desde su concepción inicial, teniendo además como referencia actividades de apoyo relacionadas con el seguimiento, el control y la gestión del software en general.

Además, un producto software debe estar orientado y normalizado por prácticas que garanticen su éxito final, sin importar su dominio de aplicación. En el mercado internacional los clientes actuales son más exigentes con el desarrollo de productos donde prime la dinámica y la interactividad, porque deben permitirles a los usuarios adentrarse en espacios virtuales que simulen una apariencia de la realidad. En muchas ocasiones los

usuarios potenciales se inclinan hacia software sobre este dominio de aplicación, debido a la falta de recursos reales para ejecutar actividades y ejercicios con aportes prácticos determinados. Dentro de este campo de aplicaciones dinámicas e interactivas se encuentran los videojuegos, considerados como productos que se ejecutan a través de una pantalla y orientados, mayormente, a la distracción personal y colectiva.

Para Zyda [3], un juego es una prueba física o mental, llevada a cabo de acuerdo con unas reglas específicas y cuyo objetivo es divertir o recompensar al participante. Mientras que un videojuego es una prueba mental realizada en computador y de acuerdo con ciertas reglas, cuyo fin es la diversión, esparcimiento, o ganar una apuesta. Sin embargo, destaca que un videojuego serio es una prueba mental, de acuerdo con unas reglas específicas, que usa la diversión como modo de formación, con objetivos en el ámbito de la educación, sanidad, política pública y comunicación estratégica.

En este sentido, los videojuegos, como medio de entretenimiento, han evolucionado abruptamente en los últimos años, convirtiéndose en una industria multimillonaria que supera en ocasiones a la industria del cine. En los casos de superproducciones de varios años de desarrollo, se necesitan cientos de programadores, artistas gráficos y de sonido, narración, marketing, leyes e inclusive actores [4]. Desarrollar un videojuego implica conocer diversas disciplinas y poseer habilidades creativas, y recorrer varias ciencias formales y sociales, cuyo proceso va mucho más allá de un típico desarrollo de software. En el proceso es importante tener en cuenta la estructura del producto a partir de un esquema básico que se aleja de cierta manera de cualquier otro tipo de software. Dicha estructura suele presentar un bucle principal que se repite hasta que termina el juego. En este bucle se realizan una serie de tareas a nivel de usuario que dan paso a las interacciones con entidades del mundo virtual y la Inteligencia Artificial que involucran. A este bucle se le denomina game loop [5].

A esta estructura la manejan motores de juego que implementan las mecánicas que la componen y que se definen como un sistema de software diseñado para la creación y desarrollo de videojuegos. Existen múltiples motores de juegos diseñados para trabajar en consolas y sistemas operativos, pero, en general, su funcionalidad típica es proveer un motor de renderizado para los gráficos 2D y 3D, motor físico o detector de colisiones, sonidos, animación, Inteligencia Artificial, redes, streaming, scripting, administración de memoria y escenario gráfico entre otros elementos. El desarrollo de un videojuego se reduce considerablemente al reusar o adaptar un mismo motor para crear diferentes juegos [6]. Las mecánicas que componen a un videojuego son desarrolladas por estos motores de juegos y se relacionan con los puntos, las medallas, los rankings, los logros, los niveles o la cuenta atrás, pero no se pueden considerar mecánicas de juego sino componentes o elementos para crearlas. Por lo tanto, una mecánica es una regla de juego con una entrada y una salida que produce cambios en el sistema [7]. Existen diversos motores de juegos que permiten la reutilización de mecánicas o mecanismos, tales como Unreal

15

Development Kit (UDK), Unity 3D, Ardor3D, Axioma Engine, Cry Engine, Fox Engine, Stingray y Frostbite entre otros [8]. En los videojuegos la definición de requisitos funcionales no se trata como en el desarrollo de sistemas de gestión de otros dominios, sino se especifican en términos de mecanismos que engloban los elementos que conforman las partes del producto como sistema a nivel de escena y por detrás de ella. Los elementos básicos que incluye un mecanismo son: objetos, propiedades, comportamientos y relaciones [9].

En el proceso de producción de software del Centro de Entornos Interactivos 3D, Vertex, de la Universidad de las Ciencias Informáticas de Cuba, se encuentra una línea de desarrollo de videojuegos que implementa estos productos sobre el motor de juego Unity 3D. Se emplea esta herramienta porque está enfocada en los bloques de construcción que permiten desarrollar plugins y módulos integrables a la interfaz de usuario de manera flexible, lo cual potencia la reutilización y en consecuencia se acelera y optimiza el tiempo de desarrollo y se minimiza el esfuerzo necesario para su realización, ya que las soluciones creadas son adaptables a futuros cambios. Las especificaciones y representaciones correspondientes a las implementaciones de estos productos software deben ser bien detalladas y esquemáticas, sin embargo, solamente con las prácticas ingenieriles tradicionales no se logra una correspondencia efectiva entre lo modelado y lo implementado.

Actualmente y de acuerdo con la experiencia de los autores en el análisis y el diseño de videojuegos, para el proceso ingenieril de estos productos existen algunas limitaciones que entorpecen el proceso desarrollo:

La definición inadecuada de responsabilidades y roles de los miembros de los proyectos no responde a las necesidades productivas, lo que afecta la calidad y el tiempo de desarrollo de los productos.

El proceso de documentación estándar del área ingenieril no apoya adecuadamente el proceso de desarrollo de videojuegos, ya que las funcionalidades referentes no se describen ni se representan con claridad. Esto provoca falta de entendimiento entre desarrolladores y analistas.

La aplicación de actividades estructurales que guíen el proceso de desarrollo de videojuegos de forma estándar no está acorde con el entorno en el que se opera, lo que provoca descontento en los miembros del equipo del proyecto y desorganización sistemática.

Las especificaciones que se generan no se encuentran directamente al alcance de los desarrolladores y les resultan difíciles de entender, lo que evidencia falta de relación entre el proceso ingenieril y el desarrollo.

Atendiendo a la situación problemática planteada, se define como objetivo de esta investigación desarrollar un marco de trabajo ingenieril para el proceso de desarrollo de videojuegos en el Centro de Entornos Interactivos 3D, que contribuya a mejorar la efectividad del proceso ingenieril.

2. Materiales y métodos

Como métodos teóricos se utiliza el análisis histórico-lógico e hipotético-deductivo. El primero se utiliza para realizar un análisis del estado del arte relacionado con las tendencias actuales para el proceso de desarrollo de videojuegos. La idea es establecer una caracterización de marcos de trabajo para el proceso de desarrollo, que guían el ciclo de vida del software y se encargan de garantizar el aseguramiento de la calidad de sus procesos y productos. Se analizan las características, el diseño y la estructura de los videojuegos en diferentes áreas de la sociedad. Además, en la investigación se aplica el segundo método porque, desde el inicio, el problema se analiza como un todo, revisando los aspectos más generales y los datos tomados de proyectos que hacen parte de la validación de la solución propuesta.

Por otro lado, se utilizan métodos empíricos, ya que describen y explican las características fenomenológicas del objeto, representan un nivel de la investigación cuyo contenido procede de la experiencia y se somete a cierta elaboración racional, específicamente las entrevistas y la revisión de documentos. El empleo de estos métodos constituye un medio para el conocimiento cualitativo de los fenómenos reales de la situación existente, que se emplea principalmente con el objetivo de obtener información sobre las principales características que definen a un marco de trabajo ingenieril para el proceso de desarrollo de software. 3. Bases conceptuales

3.1 Videojuegos

Un videojuego es un software creado para entretenimiento, diversión e inmersión en un entorno virtual, que se fundamenta en la interacción entre una o varias personas y un dispositivo electrónico; estos elementos pueden ser un computador, una videoconsola o un teléfono móvil; por lo general, estos elementos se conocen como plataformas. Para Cailois [10], el término juego se refiere a una actividad que es esencialmente libre/voluntaria, separada en el tiempo y el espacio, incierta e improductiva, que se rige por las reglas de la fantasía. Mientras que Frasca [11] afirma que incluye cualquier forma de software de entretenimiento por computador, usando cualquier plataforma electrónica, además de la participación de uno o varios jugadores en un entorno físico o de red. Para los autores de este trabajo un videojuego es un software de apoyo al entretenimiento que, a partir de la interacción entre entornos virtuales, dispositivos electrónicos y usuarios, logra la simulación de una apariencia de la realidad deseada y la inmersión en ella de, por lo menos, un jugador.

3.2 Características de videojuegos

Una característica esencial de un videojuego es la jugabilidad que se le atribuye, que se puede considerar independiente de los gráficos o de la ficción, aunque esta última tiene un papel importante en ayudar a los jugadores a entenderla. Rouse [12] presenta una definición ampliamente aceptada para el término en la que sostiene que es el grado y la naturaleza de la interactividad que el

16

juego incluye, es decir, cómo el jugador es capaz de interactuar con el mundo virtual y la forma en que el mundo virtual reacciona a las elecciones que el jugador ha hecho. Para Bjork y Holopainen [13] se refiere a las estructuras de interacción del usuario con el sistema de juego y con otros jugadores en el mismo. En todo caso, la jugabilidad finalmente permite definir el grado en el que el usuario se involucrará en la realidad virtual. El problema aquí es que, al permitir la ruptura de las barreras sociales en determinadas circunstancias, puede hacer que el usuario pierda el control establecido de la realidad.

Por otro lado, en un videojuego las mecánicas representan un componente esencial para la especificación detallada a diferentes niveles de los objetivos, entradas, caminos y salidas, que se pueden originar entre la interacción videojuego–jugador. Generalmente, se llama mecánica de juego a elementos tales como los puntos, las medallas, los rankings, los logros, los niveles o la cuenta atrás, aunque no son mecánicas de juego como tal, sino componentes o elementos para crear mecánicas de juego. También se le llama mecánica o mecanismo a los juguetes creados que relacionan objetos a través de sus propiedades y comportamientos con un fin en específico [7], por ejemplo: mecanismo de control de vidas, mecanismo de locomoción.

Las mecánicas de un videojuego se perciben como mecanismos, cajas negras, que pueden o no ser visibles y los jugadores entienden que ellas son capaces de recibir entradas y producir salidas, lo que conlleva a un cambio en su estado y a generar nuevas interacciones con otras cajas, provocando una reacción en cadena. Por lo tanto, la mecánica de un juego determinado puede ser capaz de recibir diferentes entradas y reaccionar en consecuencia. En términos de juego, para el jugador esto significa que la mecánica tiene características que le permiten desencadenar diferentes interacciones (Figura 1).

Figura 1. Desarrollo de mecanismos en videojuego [14]

Teniendo en cuenta los elementos asociados a las mecánicas de un videojuego, el autor define como mecanismo a los componentes creados que relacionan objetos a través de sus propiedades, relaciones y comportamientos con un fin determinado; estos componentes permiten la interacción videojuego-jugador para desencadenar, durante el proceso, acciones de entrada o salida. Además, para el diseño de un videojuego se debe poner en práctica técnicas para generar ideas que permitan la originalidad de mismo. Una de las técnicas más usadas es la tormenta de ideas, que consiste de un encuentro entre un grupo de personas donde todos aportan criterios para llevar a cabo un proyecto de juego a desarrollar. Una vez aclaradas y sintetizadas las ideas no se pueden perder de vista las características porque no deben faltar en un videojuego, además de la categoría o

tipo en el cual se enmarca. Con estos factores definidos se determinan los elementos importantes del videojuego y, para definir cada uno de estos elementos, el diseñador del juego debe pensar completamente como jugador.

Debido a que el video juego es un sistema, el diseño debe tener en cuenta los elementos formales y dramáticos, que se relacionan entre sí y se ponen en movimiento. Los mismos crean un sistema de juego que, a diferencia de otros sistemas, su objetivo no es crear un producto sino experiencias dinámicas (elementos dinámicos), donde el jugador se compromete y entretiene. Un sistema de juego está compuesto básicamente por los siguientes elementos [15]:

Objetos. Bloques básicos de construcción que interactúan entre sí; pueden ser físicos o abstractos, por ejemplo: avatar, pieza, nivel.

Propiedades. Atributos que definen los aspectos físicos y los conceptuales de los objetos, por ejemplo: color, posición, dinero.

Comportamientos. Potenciales acciones que un objeto puede realizar.

Relaciones. Existente entre objetos.

En la Figura 2 se observan los aspectos a tener en cuenta para el diseño estructurado y organizado de un videojuego.

Figura 2. Estructura para el diseño de un videojuego [15]

1. Establecer las metas que debe experimentar un jugador.

2. Estructurar el juego, para ello se tiene en cuenta los siguientes elementos:

Formales. Para definir la estructura del juego:

Jugadores: Invitación a jugar, número de jugadores, roles, patrón de interacción entre jugadores, relación con las metas trazadas.

Objetivos: Qué es lo que el jugador trata de lograr; siempre son realizables; pueden ser múltiples o sencillos, explícitos o implícitos; se relacionan con los elementos dramáticos del juego; los objetivos serán los encargados de definir la categoría o tipo a la que aplica el videojuego a desarrollar.

Procedimientos: Son los métodos dentro del juego y las acciones que el jugador puede ejecutar para lograr los objetivos; responden a ¿quién hace qué? ¿Dónde? ¿Cuándo?

17

¿Cómo? deben ser intuitivos de acceder y fácil de recordar; tienen una estrecha relación con los dispositivos de entrada y de salida; los procedimientos pueden ser para realizar acciones de comienzo, progresión, especiales o concluyentes; definen las acciones de los controles y botones en el juego.

Reglas: Tienen que ser claras para el jugador; definen objetos; limitan el comportamiento dentro del juego; determinan efectos.

Recursos: Elementos usados por el jugador con fin de cumplir los objetivos (vidas, dinero, tiempo, entre otros); su utilidad debe ser balanceada; definen la economía interna del juego.

Conflicto: Se genera a través de reglas, procedimientos y situaciones que no permiten cumplir los objetivos directamente (obstáculos, oponentes, dilemas); tienen estrecha relación con el jugador, las reglas y los procedimientos.

Frontera o límite: Es todo lo que separa el juego de lo que no es el juego; tiene estrecha relación con las metas trazadas

Resultado: Define la condición de ganado o perdido (en caso de existir); el final debe ser inesperado.

3. Definir el contexto del juego:

Dramáticos: Definen el entretenimiento y el nivel de inmersión de los jugadores:

Reto o desafío: Produce una experiencia de éxito y felicidad.

Juego: Define las relaciones del juego con cualquier otro de la misma línea.

Premisa: Define tiempo y lugar, relaciones entre personajes, estatus e introducción a la historia.

Caracteres: Se refiere a los personajes y sus características.

Historia: Se refiere a lo que se quiere contar y dónde se va a desenvolver el juego.

Arco dramático: Conflicto como base de la curva, es donde el juego alcanza el clímax.

4. Definir los mecanismos:

Dinámicos: Definen los mecanismos del juego y se basan en convertir los elementos formales y dramáticos en objetos, propiedades, comportamientos y relaciones:

Objetos: Personajes, reglas, procedimientos, conflictos.

Propiedades: Recursos, reglas.

Comportamientos: Procedimientos, reglas, conflictos, frontera.

Relaciones: conflictos, reglas, frontera.

3.3 Metodologías, marcos de trabajo y/o modelos para el desarrollo de videojuegos

Una metodología de desarrollo de software en Ingeniería del Software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo [16]. A continuación, se describen las metodologías y/o modelos más utilizados para el desarrollo de videojuegos [17, 18].

Cascada

Plantea que el diseño tiene que ser perfecto y estar completo antes de comenzar la implementación.

Es el más utilizado en las empresas grandes.

No responde bien ante los cambios.

Existen problemas de comunicación e interpretación.

Ejecuta linealmente las siguientes de requisitos, diseño, implementación, verificación y mantenimiento.

SCRUM

Es una metodología ágil que sirve para administrar y controlar el desarrollo de un producto. Se caracteriza por cinco valores: compromiso, enfoque, sinceridad, respeto y coraje, que son implementados mediante varias prácticas, tales como sprints, SCRUM master, SCRUM team, backlog de producto.

Al ser iterativo e incremental se obtienen versiones jugables del producto en intervalos regulares de tiempo.

Resulta difícil definir la descripción de las funcionalidades del videojuego en una granularidad adecuada, que no sea demasiado específica ni muy vasta.

Las actividades que complementan el proceso de desarrollo son: planificación iteración, ejecución iteración, inspección y adaptación.

Programación XP

La interacción frecuente entre los clientes y los diseñadores permite adaptar el desarrollo del videojuego a sus necesidades y a lograr el resultado esperado.

Las prácticas están pensadas principalmente para programadores y no necesariamente consideran otros roles.

Difícil aplicación en equipos de desarrollo numerosos.

Persigue un enfoque iterativo y se centra en productos de trabajo, tales como historias de usuario, tarjetas CRC y diseño de casos de prueba de aceptación.

Las actividades estándares a ejecutar durante el proceso de desarrollo son: exploración,

18

planificación de la entrega, iteración, producción, mantenimiento y muerte del proyecto.

Otras actividades a aplicar durante el proceso de desarrollo son: planificación, diseño, desarrollo y pruebas [19].

SUM

El objetivo es desarrollar videojuegos de calidad en tiempo y costo, así como la mejora continua del proceso para incrementar la eficacia y eficiencia. Pretende obtener resultados predecibles, administrar eficientemente los recursos y riesgos del proyecto, y lograr una alta productividad del equipo de desarrollo.

Adapta las estructuras y roles de SCRUM y XP para videojuegos.

El proceso de desarrollo se divide en cinco fases iterativas e incrementales que se ejecutan secuencialmente: concepto, planificación, elaboración, beta y cierre, con excepción de la fase de gestión de riesgos que se realiza durante todo el proyecto.

Sus productos de trabajo esenciales son: plan de proyecto, documento de concepto, documento de diseño, especificación de características y lista de riesgos [20].

Se recomienda utilizar SUM para equipos pequeños (2 a 7 integrantes), proyectos cortos (a menos de un año), equipos multidisciplinares, equipos que comparten un lugar de trabajo o están distribuidos y cuando existe un alto grado de participación del cliente.

Huddle

Se refiere a la reunión que se realiza en el juego antes de cada jugada en el futbol americano; la filosofía es que, mediante breves reuniones de planeación a corto plazo, se planee cada jugada que se inicie; con esto se da un seguimiento más estrecho al avance del proyecto y es posible hacer correcciones tempranas a las desviaciones.

Es un proceso específico para desarrollar de videojuegos que tiene las siguientes características: ágil, óptimo para equipos multidisciplinares de 5 a 10 personas, iterativo, incremental y evolutivo. Sin embargo, también se puede utilizar en equipos de menos de cinco integrantes.

Divide al proceso de desarrollo de software en tres actividades fundamentales: 1) pre-producción, en la que se define el juego, la concepción general con sus aspectos más relevantes y los términos en los que se llevará a cabo su materialización; 2) producción, una fase difícil por la confluencia de actividades diversas; en ella participan multitud de profesionales de

ámbitos muy específicos, con clara especialización en función de las sub-fases en las que se ubiquen: diseño del juego, artístico, mecánico y técnico, implementación, pruebas alpha y beta; y 3) postmortem: donde se analizan los aspectos positivos y negativos del proyecto de videojuego [21].

Huddle es una metodología apropiada para el proceso de desarrollo de videojuegos; describe los elementos esenciales que se deben llevar a cabo para la implementación de un videojuego, desde su concepción (pre-producción, producción) hasta la etapa final de análisis de tendencias (postmortem); es una metodología que combina prácticas de SCRUM, de ahí que la documentación que genera está en correspondencia con las necesidades de desarrollo; sin embargo, los artefactos que permite generar no representan ni describen adecuadamente un ámbito ingenieril.

Marco de trabajo de Pressman [1]. Describe las siguientes actividades para cualquier proceso:

Comunicación Planeación Modelado Construcción Despliegue

Cada actividad del marco contiene un conjunto de acciones de Ingeniería del Software y representa cada una con un número de conjuntos de tareas: una serie de tareas del trabajo, producto del trabajo, puntos de aseguramiento de la calidad y fundamentos del proyecto. Al final, el conjunto de tareas que mejor se ajuste a las necesidades del proyecto es el elegido. De ahí se desprende que cada acción se puede adaptar a las necesidades específicas de cada proyecto, así como a las características del equipo de desarrollo.

Marco Edulibre [22]

Este marco de trabajo está compuesto por varios subproductos (documentos) que contienen en detalle los procedimientos a llevar acabo para el desarrollo de los videojuegos.

Está basada en las metodologías de desarrollo ágil XP, SCRUM y SUM principalmente, de las que toma su estructura y la modifica y adapta a lo que se está buscando.

Es una metodología para el desarrollo de videojuegos educativos cuyo objetivo es facilitar su desarrollo en el tiempo y bajo costos razonables, dando lugar a mejoras cada vez que se utilice en función de la experiencia adquirida.

Es manejable para equipos multidisciplinares pequeños (no más de siete integrantes) y para proyectos con un máximo de duración de seis meses.

Presenta seis fases secuenciales: diseño educativo, concepto del videojuego,

19

planificación, desarrollo, pruebas beta y finalización.

Aunque se orienta a lo educativo, en caso de desarrollar otro tipo de videojuego, que busque algunas de las categorías enunciadas en esta investigación, su aplicación quedará incompleta y muchas de sus prácticas serán violadas. Por otro lado, los artefactos que se proponen no cumplen con las prácticas de modelos de referencia para alcanzar cierto grado de madurez y capacidad en la gestión de la calidad.

3.4 Proceso de desarrollo de software en la UCI

La actividad de desarrollo de producción en la UCI se rige por el modelo de referencia de calidad CMMI-DEV certificado en nivel 2, que propone la aplicación de prácticas genéricas y específicas [23] para la mejora continua de los procesos de una institución. El proceso de desarrollo de software en la Universidad de las Ciencias Informáticas se estructura por un Sistema de Gestión de la Calidad y una metodología de desarrollo, que integra prácticas de diferentes marcos de trabajo y/o metodologías, con el objetivo de insertarse de forma estándar en la producción de software en los distintos centros de desarrollo de la universidad. Esta metodología de desarrollo se denomina Proceso Unificado Ágil-versión Universidad de las Ciencias Informáticas (AUP-vUCI).

AUP-vUCI presenta tres fases que se ejecutan en orden: inicio, ejecución y cierre; el ciclo de vida de los proyectos se organiza en siete disciplinas: modelado de negocio, requisitos y análisis y diseño, implementación; mientras que en el caso de prueba se desagrega en: pruebas internas, de liberación y aceptación; las otras tres disciplinas de AUP asociadas a la parte de gestión para la variación UCI, se cubren con las áreas de procesos que define CMMI-DEV v1.3 para el nivel 2: gestión de la configuración (CM), planeación de proyecto (PP) y monitoreo y control de proyecto (PMC) [23]. Esto se debe a la certificación del nivel 2 de CMMI-DEV que tiene la universidad en la actividad de desarrollo de producción.

Para el modelado de negocio se propone tres variantes: casos de uso del negocio (CUN), descripción de procesos de negocio (DPN), o modelo conceptual (MC), y para encapsular los requisitos: casos de uso del sistema (CUS), historias de usuario (HU) y descripción de requisitos por procesos (DRP). De ahí surgen cuatro escenarios para modelar el sistema en los proyectos:

Escenario No. 1: Proyectos que modelen el negocio con CUN solamente pueden modelar el sistema con CUS. CUN + MC = CUS.

Escenario No. 2: Proyectos que modelen el negocio con MC solamente pueden modelar el sistema con CUS. MC = CUS.

Escenario No. 3: Proyectos que modelen el negocio con DPN solamente pueden modelar el sistema con DRP. DPN + MC = DRP.

Escenario No. 4: Proyectos que no modelan el negocio solamente modelan el sistema con HU.

La gestión de la calidad del software es una actividad esencial en cualquier empresa para asegurar la calidad de sus productos y la competitividad ante el mercado. Es un conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades, definidas por el cliente y que podrían parecer subjetivas; de cualquier forma, hay muchos aspectos sobre la calidad que pueden hacerse objetivamente. Esto requiere examinar cada una de las características individuales del software y determinar una o más métricas que pueden recolectarse para reflejar el estado de dichas características. Normalmente, la gestión o administración de la calidad se aplica a nivel empresa, aunque también puede darse al interior de la gestión de cada proyecto [25]. En la Figura 3 se muestra una representación gráfica del Sistema de Gestión de la Calidad (SGC) que se ejecuta en los proyectos de desarrollo en la Universidad de las Ciencias Informáticas.

Figura 3. Representación gráfica del SGC en la UCI [26]

4. Resultados y discusión

El desarrollo de videojuegos se realiza de forma diferente a un proceso de desarrollo de software tradicional; las actividades ingenieriles que se ejecutan en el proceso generan resultados diferentes; y los entregables o especificaciones no se conciben de la misma manera que en otras disciplinas, es decir, negocios, requisitos, análisis y diseño, implementación, pruebas y despliegue. Ocasionalmente se trata de seguir esta forma estándar para encapsular los requisitos que contribuyen al proceso de desarrollo, aplicando metodologías ágiles y tradicionales o marcos de trabajo, pero en mayormente no representan un apoyo base para la disciplina de implementación; e incluso las actividades que se ejecutan no son acordes con las necesidades descriptivas para garantizar la calidad del producto final.

El marco propuesto en este trabajo se compone de 20 actividades, divididas en cinco etapas que complementan el proceso de desarrollo de videojuegos (Figura 4): conceptualización, diseño, implementación, prueba y mantenimiento. Además, incluye técnicas para llevar a cabo las actividades englobadas en las etapas definidas, herramientas, roles y productos de trabajos ingenieriles. Por otro lado, en el proceso de ejecución adoptará actividades de calidad definidas en el SGC para los proyectos de desarrollo de la UCI. El propósito de este marco es contribuir con el proceso ingenieril para el desarrollo de videojuegos y entre sus objetivos específicos se encuentran:

20

Estructurar las actividades del proceso de desarrollo de videojuegos.

Generar productos de trabajo ingenieriles acordes con el desarrollo de videojuegos, utilizando herramientas informáticas de apoyo.

Alinear el proceso de desarrollo de videojuegos con el modelo de desarrollo en la UCI.

Una vez ejecutadas las actividades se obtiene como salida: diseño del videojuego, criterios para validar mecanismos, especificación de mecanismos, modelo de diseño, arquitectura de software, modelo de implementación, guía de jugabilidad, registro de defectos y reporte de postmortem. Estos entregables representan las características fundamentales para contribuir con el proceso ingenieril durante el desarrollo de videojuegos. Los artefactos que se obtienen como salida en cada una de las etapas funcionan como elementos de entrada para la siguiente y, de acuerdo con las definidas para el marco de trabajo, distribuyen como se muestra en la Tabla 1, teniendo en cuenta la estructura de la actividad de desarrollo-producción propuesta por la metodología AUP-vUCI y las fases estándares para el desarrollo de videojuegos

Figura 4. Marco de trabajo ingenieril para el proceso de

desarrollo de videojuegos

Tabla 1. Relación de actividades AUPvUCI, marco de trabajo ingenieril y desarrollo estándar de videojuegos

Fases AUP-vUCI Disciplinas AUP-vUCI Etapas marco de trabajo ingenieril Fases de desarrollo estándar

Inicio

Ejecución

Modelado de negocio (opcional) Conceptualización Pre-producción Requisitos Análisis y diseño

Diseño

Producción Implementación Implementación

Pruebas internas, Pruebas de liberación, Pruebas de aceptación

Pruebas

Mantenimiento Postmortem

Cierre

4.1 Premisas para la utilización del marco de trabajo

Para aplicar el marco de trabajo es necesario cumplir con las premisas:

1. Utilizar preferentemente un modelo de desarrollo iterativo e incremental.

2. Tener definidos los roles y responsabilidades.

3. Concepción de la implementación basada en componentes para facilitar la reutilización de activos del software (productos de trabajo, arquitectura extensible, componentes de la implementación, facilidades de integración mediante la utilización de scripts genéricos para la implementación del comportamiento basada en las mecánicas del videojuego).

A continuación, se describen las entradas, técnicas, herramientas y salidas de cada etapa, se muestra una representación gráfica de cada una y las actividades del marco de trabajo ingenieril propuesto.

Etapa 1. Conceptualización

Objetivo

Definir las ideas concretas para el desarrollo del videojuego (Figura 5).

Entradas

Alcance del proyecto. Ideas básicas del Videojuego. Recursos humanos y materiales necesarios.

Técnicas y herramientas a utilizar

Juicio de expertos. Tormenta de ideas. Entrevistas. Herramientas ofimáticas.

Salidas

Primera parte del Diseño del Videojuego.

Roles

Jefe de proyecto. Diseñador de juego. Guionista del juego. Analista de sistema. Programador líder.

Actividad 1.1. Definir el género sobre el cual se desarrollará el videojuego. Se debe describir el o los géneros [27, 28] que estarán relacionados con las ideas que se persiguen. El propósito es brindar una explicación general de manera que el lector, sin tener

21

que leerse el producto de trabajo diseño completo, entienda el objetivo del juego.

Actividad 1.2. Describir el gameplay o jugabilidad del videojuego. El diseñador asienta las ideas que se definieron sobre con información detallada del proyecto, desde el título, el o los géneros [27], la visión general, los modos de juego y las mecánicas [7] generales, que atribuirán a los aspectos esenciales de jugabilidad que se requiere.

Actividad 1.3. Especificar las metas para la experiencia del jugador. Es importante tener bien claro los objetivos máximos que se persiguen con la interacción jugador-juego. Es por ello que el diseñador debe enumerar las experiencias que quiere que los jugadores experimenten y enumerarlas en forma de metas a cumplir [15].

Figura 5. Representación esquemática de la Etapa de Conceptualización

Etapa 2. Diseño

Objetivos

Especificar características de diseño y lógicas del videojuego (Figura 6).

Representar características de diseño y lógicas del videojuego.

Entradas

Primera parte del producto de trabajo diseño del videojuego.

Técnicas y herramientas a utilizar

Lista de chequeo. Diagramación de paquetes del diseño. Diagramación de transiciones de estado. Herramientas ofimáticas. Herramienta CASE Visual Paradigm for UML.

Salidas

Diseño del videojuego. Especificación de mecanismos. Criterios para validar mecanismos. Matrices de trazabilidad. Arquitectura de software. Modelo de diseño.

Roles

Diseñador del juego. Analista de sistema.

Actividad 2.1. Describir los elementos formales. Se debe tener claro que son los que definen la estructura del juego [15]: jugadores (invitación a jugar, cantidad, roles, patrón de interacción), objetivos, procedimientos, reglas, recursos, conflictos, frontera o límite y resultado.

Actividad 2.2. Describir los elementos dramáticos. Se debe tener claro que son los que definen el entrenamiento y nivel de inmersión de los jugadores en el juego [15]: premisa, historia, reto.

Actividad 2.3. Diseñar las pantallas gráficas elementales. Representan un esquema estructurado y organizativo de los elementos principales que apreciará el usuario durante su interacción [29] con el videojuego. Para hacerlo, el analista podrá utilizar la herramienta Visual Paradigm que brinda módulos especializados para la modelación de prototipos gráficos.

Actividad 2.4. Validar los mecanismos teniendo en cuenta criterios técnicos. Para la aprobación técnica de los mecanismos a especificar y desarrollar en un videojuego, se propone emplear la lista de chequeo como técnica de validación [30], que se utiliza en inspecciones o revisiones de artefactos a generar de forma adecuada en el proceso de producción de software [31].

Actividad 2.5. Describir los elementos dinámicos. Son las mecánicas o mecanismos físicos y lógicos que componen un videojuego [15], y contribuyen de forma relacional con el incremento del grado de interactividad entre usuarios y videojuego, porque representan el conjunto de actividades a producirse con un mismo fin en diferentes escenarios. Este factor de interactividad puede ser activado por el diseñador y/o analista de forma creativa. De estos elementos se debe definir: objetos, propiedades, comportamientos, relaciones, organización arquitectónica. Estos elementos permiten conocer el grado de interactividad entre usuarios y videojuego.

Actividad 2.6. Describir las características no-funcionales. Representan las características que hacen

22

al producto atractivo, usable, rápido o confiable, y pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación [32]. Con el objetivo de estandarizarlos como atributos de calidad, se propone utilizar la taxonomía de ISO 25010 [33]. Si algún requisito no-funcional del proyecto no está recogido en estas clasificaciones, se puede ajustar a la nomenclatura propuesta, tal es el caso del atributo relacionado con la jugabilidad.

Actividad 2.7. Administrar los cambios mediante matrices de trazabilidad. Teniendo en cuenta las características que se exponen a cambios durante el proceso de desarrollo de un videojuego, se definen las siguientes: matriz_mecanismos-mecanismos, matriz_elementos_del_juego-mecanismos, matriz_mecanismos-pantallas_gráficas, matriz_mecanismos-paquetes_del_diseño, matriz_mecanismos-objetos_diagramas_de_transición_de_estado, matriz_mecanismos-scripts, matriz_mecanismos-componentes_de_la_implementación, matriz_mecanismos-usuarios_de_prueba, matriz_mecanismos-artefactos_ingenieriles.

Actividad 2.8. Representar la concepción arquitectónica de los mecanismos. Los mecanismos deben estar organizados arquitectónicamente por paquetes [14] y asignados a los paquetes: núcleos, alternativos, mejoradores (complementos o acopladores, poderes), opositores [15].

Actividad 2.9. Diseñar la estructura de los mecanismos. Un mecanismo de un videojuego está compuesto por uno o varios scripts que presentan la misma estructura de una clase estándar orientada a objetos. Para el desarrollo de un videojuego se debe tener en cuenta las ventajas de apoyo que propicia el motor de juego a utilizar [8]. Los archivos que encapsulan la implementación, creados desde el motor de juego, pueden ser denominados scripts que representan los componentes de la implementación [31] y que, estructuralmente, conforman una clase del diseño.

Actividad 2.10. Para modelar el comportamiento de la estructura de un software cualquiera se pueden utilizar los siguientes modelos [1]: diagrama de actividades, diagrama de transición de estados, diagramas de interacción (colaboración, secuencia).

Figura 6. Representación esquemática de la Etapa de Diseño

Etapa 3. Implementación

Objetivo

Implementar los elementos dinámicos del videojuego a partir de sus representaciones basadas en componentes (Figura 7).

Entradas

Diseño del videojuego. Especificación de mecanismos. Modelo de diseño. Arquitectura de software.

Técnicas y herramientas a utilizar

Motor de juego para el desarrollo. Estándar de codificación. Herramienta Visual Paradigm for UML.

Salidas

Modelo de implementación. Código fuente. Compilado del videojuego. Guía de jugabilidad.

Roles

Analista de sistema. Arquitecto de software. Implementador.

Actividad 3.1. Diseñar los componentes que encapsulan la implementación. Un componente es la parte modular, desplegable y reemplazable de un sistema que encapsula implementación y expone un conjunto de interfaces [1]. Las relaciones que se pueden establecer entre componentes son de

23

dependencia con líneas discontinuas o utilizando el estereotipo <<use>>, o también mediante interfaces. Un componente puede ser estereotipado como: executable: es un programa que se puede ejecutar en un nodo; library: es una biblioteca de objetos estática o dinámica; entity: es una tabla de una base de datos; file: es un archivo que contiene código fuente o datos; document: es un documento; web page: es una página que se obtiene de la ejecución del sistema; o date base: es una composición de entidades. De acuerdo con la tecnología con la que se implementa, de cada componente también se debe representar su extensión en consecuencia con el estereotipo utilizado: executable: .exe; library: .dll; entity: .dbf; file: .php, .jsp, .java, .cpp, .h, .js, .css, .xml, .txt, .cs, entre otros; document: .doc; web page: .html; date base: se debe especificar solamente el nombre que posee el script [1] [31].

Actividad 3.2. Desarrollar las mecánicas especificadas y diseñadas. Para desarrollar las mecánicas del videojuego de acuerdo con lo representado y especificado, es

necesario tener clara la arquitectura de software que se utiliza, así como los patrones de diseño que sustentan un desarrollo sólido, organizado y estructurado del videojuego. Tener en cuenta: normalmente un desarrollo de software basado en componentes se combina con una arquitectura de n capas [14]; para la distribución de los componentes se tiene en cuenta la estructura arquitectónica que presenta el framework de desarrollo; durante el desarrollo de un videojuego es importante considerar la definición de un estándar de codificación, porque permite el trabajo uniforme en el código fuente y posibilita que los nuevos desarrolladores que se incorporen al proyecto se familiaricen con la estructura que se refiere al modo de programación. Después de haber obtenido el compilado del videojuego se diseña la guía de jugabilidad, que consiste en describir los escenarios del juego que se pueden realizar de forma general. Este artefacto funcionará como elemento de entrada y apoyo para la ejecución de las pruebas en entornos controlados y no-controlados.

Figura 7. Representación esquemática de la Etapa de Implementación

Etapa 4. Pruebas

Objetivo

Evaluar objetivamente el videojuego desarrollado para disminuir la cantidad de errores (Figura 8).

Entradas

Diseño del videojuego. Especificación de mecanismos. Guía de jugabilidad del videojuego. Compilado del videojuego.

Técnicas y herramientas a utilizar

Compilado del videojuego. Revisión entre pares. Herramientas ofimáticas para recolección de los

defectos.

Salidas

Listado de defectos identificados. Compilado del videojuego actualizado.

Roles

Usuarios básicos de pruebas: equipo de desarrollo, usuarios finales, clientes.

Coordinador de las pruebas. Probador.

Actividad 4.1. Desarrollar pruebas Alfa. Para las pruebas Alfa y las Beta se debe presentar al equipo de pruebas una guía de jugabilidad que recoja los escenarios principales que se pueden ejecutar con la interacción usuario–videojuego [34].

Actividad 4.2. Desarrollar pruebas Beta. Las llevan a cabo los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de las Alfa, normalmente el desarrollador no está presente [34]. Así, la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por él.

Actividad 4.3. Registrar defectos durante las pruebas realizadas. Para el registro de defectos detectados sobre los escenarios descritos en las actividades anteriores, los participantes deben listar todas las inconsistencias percibidas durante la ejecución de las pruebas. Para adicionar un defecto hay que tener en cuenta las siguientes características: número del defecto, prioridad (alta, media o baja), descripción, ubicación, tipo de error (funcionalidad, error de interfaz, validación, excepciones, usabilidad, estética y diseño, errores ortográficos, error técnico, error de formato), imagen, respuesta [35].

24

Figura 8. Representación esquemática de la Etapa de Pruebas

Etapa 5. Mantenimiento

Objetivo

Analizar el software con el propósito de adicionar mejoras propuestas o identificadas en un tiempo de explotación determinado (Figura 9).

Entradas

Aceptaciones del videojuego. Mejoras propuestas.

Técnicas y herramientas a utilizar

Juicio de expertos. Tormentas de ideas. Motor de juego. Herramientas ofimáticas.

Salidas

Reporte de postmortem. Compilado del juego actualizado. Re-ingeniería a artefactos del marco de trabajo.

Roles

Alta gerencia. Jefe de proyecto. Analista de sistema. Diseñador del videojuego. Implementadores. Probadores.

Actividad 5.1. Realizar análisis Postmortem. El objetivo es realizar una evaluación del desempeño del equipo en el ciclo actual y generar estrategias para mejorar en los ciclos siguientes. Por lo tanto, se debe realizar una comparación de lo planeado vs lo ejecutado, analizar las oportunidades de mejora y decidir que prácticas se deben cambiar para el siguiente ciclo o para el siguiente proyecto.

Actividad 5.2. Retomar la etapa de Diseño. Teniendo en cuenta que el marco de trabajo tiene la característica de ser iterativo e incremental y a partir de los efectos positivos y negativos definidos (oportunidades de mejora, no-conformidades) en el reporte de postmortem, se recomienda re-definir nuevos proyectos de software sobre el propio videojuego que guíen hacia una nueva etapa de mantenimiento.

Figura 9. Representación esquemática de la Etapa de

Mantenimiento

5. Validación de la propuesta

El conocimiento del estado de satisfacción del usuario, respecto a la utilización de un marco de trabajo ingenieril para el proceso de desarrollo de videojuegos, contribuirá a mejorar la comunicación entre los analistas, desarrolladores y clientes. La técnica de Iadov [36] fue creada para el estudio de la satisfacción por la profesión en carreras pedagógicas, se utilizó para evaluar la satisfacción por la profesión en la formación profesional pedagógica [37] y se explicó la metodología para su utilización [38]. La misma constituye una vía para el estudio del grado de satisfacción de los implicados en el proceso objeto de análisis. Para el desarrollo de esta técnica se aplicó una encuesta para conocer el grado de satisfacción sobre el proceso integral de revisiones implementado, en cuanto a:

La definición de aspectos críticos a incorporar dentro del proceso de desarrollo de videojuegos actual.

La definición de un marco de trabajo ingenieril teniendo en cuenta especificaciones y representaciones consecuentes para satisfacer las necesidades del entorno de desarrollo.

El aumento de la eficiencia en el proceso de desarrollo de videojuegos mediante la utilización de un marco de trabajo ingenieril.

Las deficiencias existentes entre lo definido y el entorno real.

25

La técnica constituye una herramienta eficiente para el estudio de la satisfacción de un proceso, debido a que los criterios que utiliza se fundamentan en las relaciones que se establecen entre tres preguntas cerradas, relacionadas a través de lo que se denomina Cuadro Lógico de Iadov (Tabla 2), y dos abiertas:

1. ¿Considera factible el marco de trabajo ingenieril para el proceso desarrollo de videojuegos a partir de la generación de artefactos que permitan obtener especificaciones y representaciones de lo que deberá ser implementado?

2. ¿Si usted fuera a realizar otro proyecto de desarrollo de videojuegos utilizaría el marco de trabajo ingenieril propuesto para lograr una

correspondencia efectiva entre lo especificado y representado, con la implementación?

3. ¿Satisface sus necesidades en su rol de analista, diseñador, guionista y/o desarrollador el marco de trabajo ingenieril para el proceso de desarrollo de videojuegos?

4. ¿Incluiría o modificaría alguna etapa y/o actividad del marco de trabajo ingenieril para el proceso de desarrollo de videojuegos propuesto? Argumente.

5. ¿Considera útil el logro de un marco de trabajo ingenieril para el proceso de desarrollo de videojuegos en relación con la obtención de especificaciones y representaciones consecuentes con la implementación? Argumente.

Tabla 2. Cuadro lógico de Iadov evaluando la propuesta (Modificado por el autor)

1. ¿Si usted fuera a realizar otro proyecto de desarrollo de videojuegos utilizaría el marco de trabajo ingenieril propuesto para lograr una correspondencia efectiva entre lo especificado y representado con la implementación?

No No sé Sí

3. ¿Satisface sus necesidades en su rol de analista, diseñador, guionista y/o desarrollador el marco de trabajo ingenieril para el proceso de desarrollo de videojuegos?

2. ¿Considera factible el marco de trabajo ingenieril para el proceso desarrollo de videojuegos a partir de la generación de artefactos que permitan obtener especificaciones y representaciones de lo que deberá ser implementado? Sí No sé No Sí No sé No Sí No sé No

Me satisface mucho. 1 2 6 2 2 6 6 6 6 No me satisface tanto. 2 2 3 2 3 3 6 3 6 Me da lo mismo. 3 3 3 3 3 3 3 3 3

Me disgusta más de lo que me satisface. 6 3 6 3 4 4 3 4 4

No me satisface nada. 6 6 6 6 4 4 6 4 5 No sé qué decir. 2 3 6 3 3 3 6 3 4

La escala de satisfacción es la siguiente:

(1). Clara satisfacción, (2). Más satisfecho que insatisfecho, (3). No definida, (4). Más insatisfecho que satisfecho, (5). Clara insatisfacción y (6). Contradictoria.

Para medir el grado de satisfacción se tomó una muestra de 11 personas pertenecientes al centro Vertex de la Universidad de las Ciencias Informáticas, teniendo en cuenta los años de experiencia de trabajo, el rol que desempeñan y el tiempo de permanencia dentro del centro. Como resultado de la aplicación de la técnica se evidencia que la propuesta formulada presenta un elevado grado de aceptación entre la población encuestada. Esto se puede apreciar por el índice de satisfacción grupal que se obtuvo de 0,83, aproximadamente, lo que significa una clara satisfacción con la propuesta y reconocimiento de su utilidad en la mejora de la efectividad del marco de trabajo ingenieril para el proceso de desarrollo de videojuegos y su nivel de calidad. Además, la técnica Iadov contempla dos preguntas complementarias de carácter abierto, que permiten profundizar en las causas que originan los diferentes niveles de satisfacción. En este caso se formularon:

Pregunta 4: ¿Incluiría o modificaría usted alguna etapa y/o actividad del marco de trabajo ingenieril para el proceso de desarrollo de videojuegos propuesto? Argumente.

Pregunta 5: ¿Considera útil el logro de un marco de trabajo ingenieril para el proceso de desarrollo de

videojuegos en relación con la obtención de especificaciones y representaciones consecuentes con la implementación? Argumente.

Esta información se utilizó para perfeccionar la propuesta aportando elementos objetivos tales como roles, herramientas y técnicas, contribuyendo con la definición de etapas, actividades y resultados. Estos aspectos se tuvieron en cuenta para la formulación final de la misma.

6. Conclusiones

Con la práctica del marco de trabajo ingenieril propuesto para el proceso de desarrollo de videojuegos se logra una correspondencia aceptable entre especificaciones, representaciones ingenieriles y la implementación de estos productos, tanto en el contexto del Centro de Entornos Interactivos 3D, de la Universidad de las Ciencias Informáticas, como en cualquier otro escenario que se requiera.

El marco de trabajo propuesto está centrado en las mecánicas que definen el comportamiento en un videojuego, lo que posibilita una adecuada comprensión por parte del equipo de análisis y desarrollo del atributo de calidad, jugabilidad.

Como resultados concretos del marco de trabajo se obtienen artefactos del área ingenieril: diseño del videojuego, criterios para validar mecanismos, especificación de mecanismos, modelo de diseño,

26

arquitectura de software, modelo de implementación, guía de jugabilidad, registro de defectos y reporte de postmortem, que propician ejecutar cada una de las etapas y actividades para un proceso de desarrollo de videojuegos efectivo. De igual manera, la propuesta se acoge a un modelo de desarrollo incremental para garantizar la retroalimentación y entrega gradual del videojuego.

Además, la solución propuesta presenta los roles que deben ser ejecutados por los miembros de proyecto durante cada etapa contenida dentro del marco, lo cual permite una organización jerárquica de los involucrados del proyecto de este dominio de aplicación. Por otro lado, para la ejecución de cada una de las etapas del marco se proponen herramientas y técnicas tradicionales basadas en la sistematización, las cuales permiten generar descripciones y gráficas textuales como base para la implementación de videojuegos.

Referencias

[1] Pressman, R. (2010). Ingeniería de Software: Un enfoque práctico. Madrid: McGraw-Hill

[2] IEEE (1998). Standard for Developing Software Life Cycle Processes. Institute of Electrical and Electronics Engineers.

[3] Zyda, M. (2005). From Visual Simulation to Virtual Reality to Game. Computer 38(9), pp. 25-32.

[4] Arce, L. (2011). Desarrollo de Videojuegos. Trabajo de grado. Universidad del Aconcagua, Argentina.

[5] Muñoz, F. (2011). Ingeniero de Software especializado en el desarrollo de aplicaciones web. Online [Jul 2016].

[6] Alegsa, L. (2010). Definición de motor de videojuego. Diccionario de Informática y Tecnología. Online [Jul 2016].

[7] Adams, E. & Dormans, J. (2012). Game Mechanics: Advanced Game Design. USA: New Riders.

[8] Technologies, U. (2011). Motores Gráficos. Online [Aug 2016].

[9] Fulletron, T. (2008). Game Design WorkShop: A Playcentric Approach to Creating Innovative Games. UK: Morgan Kaufmann.

[10] Cailois, R. (1991). Les jeux et les hommes. Paris: Gallimard Editions.

[11] Frasca, G. (2001). Videogames of the Oppressed: Videogames as a Means for Critical Thinking and Debate. Georgia: Institute of Technology.

[12] Rouse, R. (2001). Game Design: Theory & Practice. Texas: Plano.

[13] Bjork, S. & Holopainen, J. (2005). Patterns in Game Design. Hingham: Charles River Media.

[14] Fabricatore, C. (2007). Gameplay and game mechanics design: A key to quality in videogames. Online [Sep 2016].

[15] Campistruz, J. (2014). Diseñando Videojuegos. Proceso de diseño centrado en el jugador. Disponible en herramienta de gestión documental: Excriba. Área Centro Vertex. Universidad de las Ciencias Informáticas.

[16] CMS (2008). Selecting a Development Approach. Online [Jul 2016]

[17] Govardhan, N. & Govardhan, A. (2010). A Comparison Between Five Models Of Software Engineering.

International Journal of Computer Science Issues 7(5), pp. 94-101.

[18] Acerenza, A. (2015). Producción y desarrollo de Videojuegos. Online [Jun 2016].

[19] Fernández, G. (2002). Introducción a Extreme Programming. Online [May 2016].

[20] Acerenza, A. et al. (2009). Una metodología para el desarrollo de videojuegos: versión extendida. Reporte Técnico RT 09-13. Instituto de Computación. Montevideo, Uruguay.

[21] Gerardo, A. et al. (2010). Procesos de desarrollo de Videojuegos. CULCyT 7(36-37), pp. 25-39.

[22] Cabrera, J. (2015). Propuesta de un marco de trabajo para el desarrollo de videojuegos educativos para la asociación civil Edulibre. Trabajo de grado. Universidad de San Carlos de Guatemala, Guatemala.

[23] SEI (2010). CMMI® para Desarrollo. Mejora de los procesos para el desarrollo de mejores productos y servicios. Technical Report CMU/SEI-2010-TR-033. Software Engineering Institute.

[24] Rodríguez, T. (2015). Metodología de desarrollo para la actividad productiva UCI. Cuba: Universidad de las Ciencias Informáticas.

[25] Scalone, F. (2006). Estudio comparativo de modelos y estándares de la calidad de software. Tesis Maestría. Universidad Tecnológica Nacional, Buenos Aires.

[26] Dirección Calidad UCI. (2012). Propuesta del Sistema de Gestión de la Calidad. Universidad de las Ciencias Informáticas. Online [May 2016].

[27] Latorre, Ó. (2011). Game and videogame genres. An approach from diverse theoretical perspectives. Revista de Recerca i d’Anàlisi 28(1), pp. 127-146.

[28] Urbina, S. et al. (2002). El rol de la figura femenina en los videojuegos. Online [Jun 2016].

[29] Hernández, A. (2016). Procedimiento de Arquitectura de información para entornos de Realidad Virtual con fines educativos. Serie Científica de la Universidad de las Ciencias Informáticas 9(4), pp. 41-55.

[30] Hernández, A. (2016). Criterios para verificar y validar mecanismos en el desarrollo de videojuegos. Excriba. Área Centro Vertex. Universidad de las Ciencias Informáticas.

[31] Sommerville, I. (2005). Ingeniería del Software. Madrid: Wesley.

[32] Rumbaugh, J., Jacobson, I., Booch, G. (2000). El lenguaje unificado de modelado. Madrid: Addison Wesley.

[33] López, J. (2014). Aseguramiento de la calidad en el diseño del software. Online [Jul 2016].

[34] González, J. (2013). Pruebas Alfa y Beta. Online [Jun 2016]. [35] Hernández, A. (2016). Módulo para la automatización de

artefactos en la disciplina de Pruebas. Online [May 2016]. [36] Kuzmina, N. (1970). Metódicas investigativas de la

actividad pedagógica. Online [Jun 2016]. [37] González, V. (1993). Niveles de integración de la motivación

profesional. Revista Cubana de Psicología 10(2-3), pp. 100-103.

[38] González, V. (2000). La profesionalidad del docente universitario desde una perspectiva humanista de la educación. En Congreso Iberoamericano de Formación de Profesores. Río Grande del Sur, Brasil.