Game Unified Process - Historial de revisiones

Arnold.santana: Revertidos los cambios de Nelson.ochagavia (disc.) a la última edición de Javiermartin jc

2021-12-18T15:08:34Z

Revertidos los cambios de Nelson.ochagavia (disc.) a la última edición de Javiermartin jc

Nelson.ochagavia en 00:33 17 dic 2021

2021-12-17T00:33:21Z

Javiermartin jc: Texto reemplazado: «
» por «»

2019-06-23T15:39:12Z

Texto reemplazado: «<div align="justify">» por «»

Wendy idict en 17:07 25 jun 2012

2012-06-25T17:07:47Z

Ariagna en 13:52 1 jun 2012

2012-06-01T13:52:40Z

Ariagna en 13:46 1 jun 2012

2012-06-01T13:46:06Z

Ariagna en 13:01 1 jun 2012

2012-06-01T13:01:34Z

Ariagna en 20:10 2 nov 2011

2011-11-02T20:10:08Z

Ariagna en 19:07 20 oct 2011

2011-10-20T19:07:09Z

Ruslan unhicch en 14:24 20 oct 2011

2011-10-20T14:24:56Z

@@ Línea 7: / Línea 7: @@
 ==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.
+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==

@@ Línea 7: / Línea 7: @@
 ==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.
+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==

@@ Línea 2: / Línea 2: @@
 |Nombre=Game Unified Process (GUP)
 |imagen=GUP.JPG|concepto=Es una adaptación de la versión ágil de la metodología de desarrollo de software [[RUP]], para [[videojuegos]].
-}}<div align="justify">
+}}
 '''Game Unified Process''' metodología adaptada de la versión ágil de [[RUP]], para [[videojuegos]].

@@ Línea 1: / Línea 1: @@
-{{Definición|Nombre=Game Unified Process (GUP)|imagen=GUP.JPG|concepto=Es una adaptación de la versión ágil de la metodología de desarrollo de software [[RUP]], para [[videojuegos]].}}
+{{Definición
 |Nombre=Game Unified Process (GUP)
 '''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.
+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==
@@ Línea 11: / Línea 13: @@
 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==
+==Principios de la metodología GUP==
 Esta versión ágil de la metodología [[RUP]] para [[videojuego]], se basa en los siguientes principios:
@@ Línea 40: / Línea 42: @@
 '''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)
+'''Especificación o detalles del Diseño''': en este flujo de trabajo es donde se realiza el modelado del diseño ([[Animación 3D|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)
@@ Línea 65: / Línea 67: @@
 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]])
+* Diseñador (Modelador en [[2D]] ó [[Animación 3D|3D]])
 * Artistas
 ** Guionista
@@ Línea 77: / Línea 79: @@
 ** Rol: Revisores (Flood 2003)
-==Fuente==
+==Fuentes==
 * Arego Pulido, A. Y. (2009). Videojuegos cubanos tienden al incremento. Juventud rebelde. La Habana, Cuba.

@@ Línea 34: / Línea 34: @@
 * 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 requerimientos, ensamblándolos o agrupándolos con los requerimientos del guión o la historia y los requerimientos artísticos (música, dibujo, pintura, etc.). (Flood 2003; Morales Urrutia 2010)
+'''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 requerimientos. (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)
+'''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 requerimientos. 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)
+'''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:
+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 requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido. (Flood 2003)
+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 requerimientos no se incorporan hasta el inicio de la próxima iteración. (Flood 2003)
+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
@@ Línea 65: / Línea 65: @@
 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)
+* Diseñador (Modelador en [[2D]] ó [[3D]])
 * Artistas
 ** Guionista

@@ Línea 25: / Línea 25: @@
 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
+==Flujos de Trabajo==
-ü      Requisitos
+* Requisitos
-ü      Especificación de los requisitos
+* Especificación de los requisitos
-ü      Arquitectura
+* Arquitectura
-ü      Especificación o detalles del Diseño
+* Especificación o detalles del Diseño
-ü      Código
+* Código
-ü      Prueba y corrección de errores
+* Prueba y corrección de errores
-ü      Despliegue
+* 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 requerimientos, ensamblándolos o agrupándolos con los requerimientos del guión o la historia y los requerimientos 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 requerimientos. (Flood 2003; Morales Urrutia 2010)
+'''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 requerimientos, ensamblándolos o agrupándolos con los requerimientos del guión o la historia y los requerimientos artísticos (música, dibujo, pintura, etc.). (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)
+'''Especificación de los requisitos''': este es el flujo de trabajo donde se especifican y detallan los requerimientos. (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 requerimientos. 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)
+'''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)
 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
+'''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)
 Propone las mismas cuatro fases de RUP:
-·        Creación o Inicio
+* 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 requerimientos (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 requerimientos 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)

← Revisión anterior		Revisión del 20:10 2 nov 2011
Línea 24:		Línea 24:

	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.		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.
−
−	~~==Enlaces externos==~~
−
−	http://www.google.com.cu/url?sa=t&rct=j&q=game%2Bunified%2Bprocess&source=web&cd=8&ved=0CFgQFjAH&url=http%3A%2F%2Fwww.acronymgeek.com%2FGUP%2FGame_Unified_Process&ei=fyugTtGUFYi3tgfn-5WkBQ&usg=AFQjCNH7IidqVQLjmWdHBFHdBg4cDlG4pQ

	==Fuente==		==Fuente==

← Revisión anterior		Revisión del 14:24 20 oct 2011
Línea 1:		Línea 1:
		+	{{Normalizar}}
	{{Definición\|Nombre=Game Unified Process\|imagen=GUP.JPG\|concepto=Es una adaptación de la versión ágil de la metodología de desarrollo de software [[RUP]], para [[videojuegos]].}}		{{Definición\|Nombre=Game Unified Process\|imagen=GUP.JPG\|concepto=Es una adaptación de la versión ágil de la metodología de desarrollo de software [[RUP]], para [[videojuegos]].}}