Game Unified Process

Game Unified Process
Información sobre la plantilla
GUP.JPG
Concepto:Es una adaptación de la versión ágil de la metodología de desarrollo de software RUP, para videojuegos.

Game Unified Process metodología adaptada de la versión ágil de RUP, para videojuegos.

Surgimiento

Surge producto de un proyecto, consistente en un videojuego de casino online. Es una adaptación que permite el desarrollo de videojuegos dentro del plazo planificado.

Características

Básicamente esta metodología es una combinación de dos metodologías de desarrollo utilizadas comúnmente en el software tradicional. La primera es la utilización del Rational Unified Process el cual plantea un diseño estricto y una documentación rigurosa de cada paso y funcionalidad a implementar. Y la metodología eXtreme Programming con algunas variaciones para que pueda ser aplicada por personas de otras disciplinas. En este proceso los ciclos cortos ayudaron a mantener la comunicación fluida entre equipos y el componente artístico no se restringe tanto, como cuando se utiliza el RUP, proporcionando así mayor capacidad comunicativa.

Principios de la Metodología GUP

Esta versión ágil de la metodología RUP para videojuego, se basa en los siguientes principios:

  • Simplicidad: Todo se describe concisamente utilizando poca documentación, no miles de ellas.
  • Agilidad: El ajuste a los valores y principios de la Alianza Ágil.
  • Centrarse en actividades de alto valor: La atención se centra en las actividades que en realidad lo requieren, no en todo el proyecto.
  • Herramienta de la independencia: Se puede usar cualquier conjunto de herramientas que se desea con el GUP. Se sugiere utilizar las herramientas más adecuadas para el trabajo, que a menudo son las herramientas simples o incluso herramientas de código abierto.

La metodología GUP es un producto de fácil uso utilizando cualquier herramienta. No es necesario comprar una herramienta especial, o tomar un curso, para adaptar esta metodología.

Flujos de Trabajo

  • Requisitos
  • Especificación de los requisitos
  • Arquitectura
  • Especificación o detalles del Diseño
  • Código
  • Prueba y corrección de errores
  • Despliegue

Requisitos: el objetivo de este flujo de trabajo es conceptualizar la idea del videojuego y elaborar el guión, es decir, entender y definir el objetivo. Además se definir la lista de requisitos, ensamblándolos o agrupándolos con los requisitos del guión o la historia y los requisitos artísticos (música, dibujo, pintura, etc.). (Flood 2003; Morales Urrutia 2010)

Especificación de los requisitos: este es el flujo de trabajo donde se especifican y detallan los requisitos. (Flood 2003; Morales Urrutia 2010)

Arquitectura: en este flujo de trabajo es donde se define la arquitectura del software (herramientas, metodología, lenguaje de programación, lenguaje de modelado, etc.). (Flood 2003; Morales Urrutia 2010)

Especificación o detalles del Diseño: en este flujo de trabajo es donde se realiza el modelado del diseño (3D, 2D, elaboran los dibujos). Además es donde se especifican los detalles del diseño del software. (Flood 2003; Morales Urrutia 2010)

Código: el objetivo de este flujo de trabajo es transformar su (s) modelo (s) en código ejecutable. (Flood 2003; Morales Urrutia 2010)

Prueba y corrección de errores: este flujo de trabajo tiene como objetivo realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, verificando que se cumplan los requisitos. Así como corregir defectos. No hay que esperar al final de la primera versión para realizar las pruebas o correcciones, es un flujo de trabajo que está presente desde la fase de inicio. (Flood 2003; Morales Urrutia 2010)

Despliegue: el objetivo de este flujo de trabajo es el plan para la prestación del juego y la ejecución de dicho plan, para que el juego quede a disposición de los usuarios finales. (Flood 2003; Morales Urrutia 2010)

Fases

Propone las mismas cuatro fases de RUP:

  • Creación o Inicio

Esta fase tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en el flujo de trabajo Requisitos y Especificación de los requisitos. Es la única fase que no necesariamente culmina con una versión ejecutable. (Flood 2003)

  • Elaboración

El objetivo de esta fase es completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensión del sistema completo y los requisitos (funcionales y no funcionales) identificados de acuerdo al alcance definido. (Flood 2003)

  • Construcción

Fase compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones del sistema que satisfacen los principales casos de uso. Los cambios en los requisitos no se incorporan hasta el inicio de la próxima iteración. (Flood 2003)

  • Transición

Se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción. (Flood 2003)

Roles

Los roles que propone esta metodología son los siguientes:

  • Programador (rol encargado de escribir, depurar y mantener el código fuente)
  • Diseñador (Modelador en 2D ó 3D)
  • Artistas
    • Guionista
    • Dibujante
  • Ingenieros en Software
    • Rol: Gestor de Software
    • Rol: Líder de Proyecto
    • Rol: Analista
    • Rol: Arquitecto
    • Rol: Probador
    • Rol: Revisores (Flood 2003)

Fuente

  • Arego Pulido, A. Y. (2009). Videojuegos cubanos tienden al incremento. Juventud rebelde. La Habana, Cuba.
  • Borrego, C. D. (2010). "Metodología de desarrollo de juegos." from www.construyeciudades.blogspot.com.
  • Flood, K. (2003). "Game Unified Process (GUP)."
  • Flynt, J. y. S., Omar (2005). Software Engineering for Game Developers.
  • Gerónimo Castillo, G., Fernández Fernández, C.A. y Ruíz Rodríguez, R. (2011) Una Aproximación a la Evaluación y Desarrollo de Software. Dirigido a Niños.
  • Hoffman, S. (2002) Game Design Workshop: Designing, Prototyping, and Playtesting Games.
  • Lamonthe, A. (2002) Software Engineering and Computer Games.
  • Llopis, N. y. S., Brian (2002). Solid Software Engineering for Games.
  • Morales Urrutia, G. A. (2010) PROCESOS DE DESARROLLO PARA VIDEOJUEGOS.