Una propuesta metodológica para la construcción de videojuegos
Jose Angel Gonzalez Gill Universidad Tecnológica de Panamá
Facultad de Ingeniería en Sistemas Computacionales
Ciudad de Panamá, Panamá
[email protected]
Efrain Perez
Universidad Tecnológica de Panamá
Facultad de Ingeniería en Sistemas Computacionales
Ciudad de Panamá, Panamá
[email protected]
Resumen-Este artículo presenta una propuesta metodológica llamada CASCRUM para el desarrollo de videojuegos en 2d como una herramienta para la construcción de este tipo de software. Esta propuesta se fundamenta en las etapas del ciclo de vida de la metodología de Cascada y como método de seguimiento de las etapas de CASCRUM integramos de la metodología Scrum el ciclo de reuniones Daily Scrum con una variante de la misma semanal la cual llamamos Week Meeting Planning. Para la evaluación de la propuesta tomamos como escenario a la Facultad de Ingeniería en Sistemas Computacionales de la Universidad Tecnológica de Panamá Campus Central. El tiempo de experimentación fue durante los años 2013 al 2014. En el periodo académico del 2013 los estudiantes recibían la guía de un instructor con conocimientos avanzados en videojuegos en 2d, para el año 2014 algunos de los estudiantes del periodo anterior fueron los monitores de los grupos. Con el fin de evaluar si CASCRUM era eficiente para la construcción de videojuegos en 2d, se formaron tres grupos en ambos periodos y cada grupo se le asignaba una única metodología de desarrollo a lo largo del periodo de experimentación, las metodologías que se implementaron fueron (Cascada, Scrum y CASCRUM), para homologar los resultados se utilizaron las métricas del ciclo de vida de videojuegos.
Palabras Claves: Cascada; CASCRUM; Scrum; videojuegos; metricas de evaluacion de videojuegos.
INTRODUCCIÓN
Para Wolf un videojuego, es un software desarrollado para el entretenimiento en el que existe interacción entre una o varias personas y un aparato electrónico. El usuario espera encontrar dentro del videojuego algunos elementos que estimulen su deseo de jugarlo como por ejemplo: conflicto contra un oponente o contra las circunstancias, reglas que determinan que se puede hacer y que no, el uso de las habilidades del jugador (como por ejemplo destreza, estrategia o suerte) y un resultado valorado (como por ejemplo obtener la mayor puntuación o realizar una tarea en el menor tiempo). El desarrollo de un videojuego es una actividad que involucra una serie de disciplinas tales como el desarrollo de software, diseño de arte, creación audiovisual entre otras. El mismo proceso de desarrollo de un videojuego tiene ya establecido una ciclo de vida con métricas de evaluación en cada una de ellas, esta metodología es totalmente diferente al ciclo de vida de un software, he aquí en donde se presenta la problemática de la industria de desarrollo de videojuegos ya que los objetivos para los cuales son desarrollados los mismos son difíciles de medir ya que se basan en la parte subjetiva del cliente como por ejemplo (diversión, estrés entre otros factores). Los desarrolladores de videojuegos presentan constantemente un sin números de problemas para la recolección de requerimientos y esto se debe a:
-La rápida y constante evolución de las tecnologías.
-Los requisitos cambiantes y difíciles de evaluar (diversión, atractivo gráfico).
-La comunicación se dificulta por ser una industria multidisciplinaria (artistas, diseñadores, sonidistas, etc.)
-Búsqueda de perfección lleva a retrasos en los plazos planificados (mejores armas, mejores escenarios, etc.)
-Concentración de conocimientos en pocas personas (un especialista en inteligencia artificial)
-El programador dedica un tiempo considerable a pedidos de los artistas y los diseñadores y menos tiempo a implementar nuevas características funcionales del juego en sí.
-El código termina atado a Un juego en particular, reduciendo considerablemente la reusabilidad del código. Tanto los artistas como los diseñadores se ven perjudicados ya que ante cualquier cambio o ajuste pequeño dependen de cambios en el código por un programador y no pueden ver el mismo rápidamente. Además de esto factores, no existe una metodología estándar definida para la el desarrollo de videojuegos de forma eficiente, esto conlleva a que cada empresa utilice la metodología de desarrollo que más le convenga.
Esta investigación propone una metodología de desarrollo de videojuegos en donde se enmarca la fusión de dos metodologías extendidas a nivel mundial la de Cascada y Scrum. El ambiente de prueba para la implementación de la misma es la Facultad de Ingeniería en Sistemas Computacionales de la Universidad Tecnológica, y con el fin de fortalecer el proyecto, los agentes de experimentación para determinar si la propuesta es funcional o no, son los estudiantes de la FISC, los cuales por estar relacionados directamente en su gran mayoría con videojuegos entienden cuáles son las requerimientos para el desarrollo de los mismos.
Objetivo General
Diseñar una Metodología de desarrollo de videojuegos, que se adapte al contexto actual del mercado actual de este sector económico.
Objetivos Específicos
-Recopilar información sobre las metodologías que se usarán como base para la construcción del nuevo modelo, en nuestro caso: Metodología de Cascada y Scrum.
-Analizar los componentes más importantes de ambas metodologías para obtener los elementos que se usarán para el diseño de la nueva metodología híbrida llamada CASCRUM.
-Diseñar la metodología CASCRUM, tomando los elementos obtenidos del punto anterior.
-Seleccionar los requerimientos necesarios para la construcción del videojuego en 2d usando la metodología CASCRUM.
-Obtener los diferentes artefactos de las etapas del Proceso de Desarrollo de CASCRUM DEL VIDEOJUEGO 2D.
-Evaluar los resultados de las diferentes etapas del proceso de desarrollo de software CASCRUM DEL VIDEOJUEGO 2D.
Justificación
Las actuales metodologías de desarrollo de software han demostrado que no son eficientes para la construcción de videojuegos, y esto conlleva a que el producto no cumpla con los requerimientos indicados para el cliente. Esto se debe a que las empresas de desarrollo de videojuegos, no han estandarizado una metodología de desarrollo de videojuegos, que se ajuste de forma adecuada al proceso de diseño y de construcción del producto de software. Ciertamente cada videojuego tiene sus propias características únicas, mantienen un denominador en común (presentan el mismo modelo de desarrollo desde su fase de conceptualización, hasta el mantenimiento del mismo). Nosotros queremos demostrar con esta investigación, que con el desarrollo de la metodología CASCRUM, podemos obtener una metodología de construcción eficiente de videojuegos, la cual reduzca los costes de (Concepción, Diseño, Planificación, Producción, Pruebas, Mantenimiento).
Límites y Alcances
El tiempo de la investigación es desde el año académico 2013 hasta el año académico 2014. Se usarán 3 metodologías de desarrollo de software (Scrum, la de cascada, y la híbrida la fusión de la (Cascada-Scrum), como metodologías de desarrollo. Solo se conformaron tres grupos, uno por cada metodología, las metodologías fueron asignadas de forma aleatoria. No se evaluaron aspectos de calidad del producto de software. Solo se evaluó si la metodología propuesta cumple con la entrega del artefacto correspondiente a cada etapa.
II. METODOLOGÍA HÍBRIDA PROPUESTA (CASCRUM) PARA LA IMPLEMENTACIÓN DE VIDEOJUEGOS
CASCRUM es una metodología de desarrollo de software híbrida entre (El método de Cascada y el Scrum). La pregunta de fondo es, ¿Por qué se escogieron estas dos metodologías para construir CASCRUM?, la elección se basó en:
Scrum es un modelo que explica cómo se deben hacer las reuniones y cómo coordinar personas para aprovechar al máximo el tiempo. Esta metodología marca una serie de reglas que bien usadas pueden conseguir un aumento en la eficiencia de los equipos de trabajo. Aplicando Scrum a un equipo, se puede conseguir mejorar los plazos de entrega, aumentar la versatilidad y la capacidad de adaptación del equipo. Esto se consigue mediante la eliminación de tiempos muertos, mejora en la comunicación y dando importancia preferente a las cuestiones relevantes.
Cascada es un modelo que tiene una visión del proceso de desarrollo de software como una sucesión de etapas que produce productos intermedios. Se tiene todo bien organizado y no se mezclan las fases. Si se cambia el orden de las fases, el producto final será de inferior calidad. Además de esto permite que:
La planificación sea sencilla.
La calidad del producto resultante es alta.
Características de CASCRUM
CASCRUM retoma una importante característica de las metodologías ágiles: incluir a los usuarios finales como parte del equipo de desarrollo. Esto ayuda en gran medida a lograr el éxito del proyecto, ya que son ellos quienes saben lo que quieren, por lo tanto, se debe tener el cuidado de propiciar un ambiente de confianza y colaboración con ellos.
El equipo debe estar conformado por seis miembros, en caso tal si el equipo de desarrollo es menor de seis integrantes, es decir que no se pueda asignar al menos un rol a cada integrante (Líder del Proyecto, Administrador del Proyecto, Programador, Probador y Documentador), pueden hacerse las adecuaciones necesarias para que una persona cumpla con uno o dos roles; aunque se sugiere que una persona sea destinada a cumplir sólo un rol.
Las reuniones semanales se llaman Week Planning Meeting tienen las siguientes características:
-La reunión comienza puntualmente a su hora.
-El grupo tienen derecho a voz y voto.
-La reunión tiene una duración fija de dos horas.
-La reunión puede cambiar de lugar, disponiendo de la disponibilidad.
-Se presenta documento semanal de avances.
-El cliente es invitado a la reunión, y da sus aportaciones si se está cumpliendo con lo que el pide, en base a la información recibida, del documento semanal que se le entrega.
-Las preguntas son abiertas en su gran mayoría para determinar el estado de avance de la etapa.
Realizar lluvias de ideas durante las reuniones: Esta técnica consiste en que el equipo de trabajo intenta descubrir cuál es el problema, cuál es la causa de un problema y cómo resolverlo; a través de la participación de cada miembro con sus ideas. El proceso de esta técnica consiste en los siguientes pasos:
Seleccionar el tema.
Generar la lluvia de ideas a través de la participación de los involucrados.
Realizar el análisis de las ideas.
Seleccionar las mejores ideas.
Fases de CASCRUM
CASCRUM se fundamenta en cinco fases las cuales son (Especificación de requisitos, Planificación, Construcción, Implementación y PostMorten) tal como se puede apreciar en la figura 1.
Figura 1. Ciclo de Vida de CASCRUM.
Dentro de cada etapa de la metodología hay un proceso de retroalimentación semanal llamado (Week Planning Meeting), esto garantiza que los productos de cada fase sean desarrollados de forma eficiente.
a. Fase de Definición de los requisitos
Es la etapa más crítica de toda la metodología, es aquí donde se determina los requerimientos funcionales y no funcionales del videojuego para su posterior construcción. Los requisitos de desarrollo son dados por el cliente. Esta metodología propone que se dedique aproximadamente el veinte por ciento del total del proyecto, ya que hay evidencias La etapa de Planteamiento, es crucial para el desarrollo correcto del videojuego, ya que si no se tiene claro, hasta donde es límite del proyecto el costo del proyecto. En las reuniones semanales Week Planning Meeting de esta etapa se debe lograr tener la lista de requerimientos por parte del usuario antes de pasar a la siguiente etapa. Aquí se desarrolla un documento de concepto del juego que es el producto para la siguiente etapa.
b. Fase de Planificación
En base al documento de concepto de la fase anterior, se desarrolla la etapa de planificación. En esta etapa se determinan los hitos de desarrollo del videojuego. Es aquí donde se determinan los hitos para las siguientes etapas, el coste de desarrollo, y de implementación del videojuego. Es aquí donde se desarrolla el documento de diseño del producto que es el insumo de la siguiente etapa.
c. Fase de Construcción
En base al documento de diseño, se desarrolla la etapa de producción. Esta etapa es la fase de desarrollo del producto en donde se crean los primeros prototipos del mismo.
d. Fase de Implementación
Esta fase tiene como objetivos entregar la versión final del videojuego al cliente según las formas establecidas y evaluar el desarrollo del proyecto. Para la evaluación se estudian los problemas ocurridos, los éxitos conseguidos, las soluciones halladas, el cumplimiento de objetivos y la certeza de las estimaciones. Con las conclusiones extraídas se registran las lecciones aprendidas y se plantean mejoras a la metodología.
e. Fase de PostMortem
Esta fase se realiza el análisis del costo de cada etapa de desarrollo del producto en referencia a la cantidad de horas usadas para determinar si hubo un sobrecosto en la ejecución del proyecto.
III. ESCENARIO DE EVALUACIÓN
Metodologías de Comparación
Se utilizaron dos metodologías para comparar si la metodología propuesta CASCRUM cumplia con las expectativas para la cual fue diseñada e implementada. Se utilizaron las siguientes metodologías, Ya que ambas son el fundamento de CASCRUM:
Scrum
Cascada
Características de los Equipos
Se estableció algunos parámetros para la conformación de los grupos de trabajo, estos fueron:
-Todos deben estar entre las edades de a 17 años a 22 años.
-No deben tener experiencia previa sobre el uso de metodologías de desarrollo de Ingeniería de Software.
-Deben ser parte de un mismo salón de clases.
-Deben tener un máximo de siete integrantes cada equipo.
-La selección de la metodología de desarrollo fue al azar.
Selección de grupos: Año 2013
La selección de los grupos se dio en dos fases, una entrevista individual con preguntas mixtas para determinar el estado del estudiante con referente a cuan avanzado estaba en habilidades técnicas de programación y sobre su conocimiento en base a metodologías de desarrollo de software.
La segunda fase tienen como objetivo principal la de seleccionar los grupos de trabajo. Para esto se usó la metodología de las entrevistas con preguntas abiertas. Los grupos se agruparon en base a su afinidad de amistad, ya que esto facilitaría el trabajo en equipo.
Selección de grupos: Año 2014
Hubo una variante en los Project Managers, son estudiantes que participaron en el proceso de desarrollo 2013. Solo se aplicó los puntos A Y B para la selección de los grupos del año 2014.
Alcance de la aplicación de las metodologías
-Tiempo de desarrollo de los videojuegos promedio de 7 meses.
-Equipos de desarrollo conformados por 6 estudiantes (sin contar a los usuarios y al cliente).
Seguimiento a los grupos
Durante el proceso de desarrollo del video juego, se tendrán que prevenir riesgo, para esto es necesario hacer uso del Ciclo de Deming. Se les daba seguimientos para poder apoyar a los estudiantes en sus habilidades de desarrollo para poder completar el proyecto. Esto consistía en una reunión semanal por cada equipo por un tiempo de 4 horas, introduciéndolos en el desarrollo de videojuegos.
Además se le dio un seminario taller para el aprendizaje de las metodologías asignadas. Estas reuniones de apoyo a las habilidades de desarrollo y de aprendizajes de las metodologías de software, no son en nada parecidas a las de Week Meeting Planning.
Selección de Métricas de Evaluación
Para poder evaluar la eficiencia de las metodologías utilizadas en este proyecto, se seleccionaron los artefactos del ciclo de vida de un videojuego. Ya que un videojuego presenta su propio modelo de desarrollo, cabe destacar que su metodología es parecida al modelo de cascada.
IV. ANALISIS DE LOS RESULTADOS. DE LA APLICACIÓN DE LAS METODOLOGÍAS DE DESARROLLO EN LOS VIDEOJUEGOS CONSTRUIDOS
Etapa de Conceptualización
La tabla 1, muestra que la metodología de cascada presenta problemas a la hora de entregar la documentación de esta fase , el grupo que usó esta metodología indicó que preferían ir al desarrollo de las interfaz del juego primeramente y luego documentar ya que les parecía tedioso escribir.
Mientras tanto en las otras dos metodologías usadas, los estudiantes si presentaron la documentación solicitada ya que hay un proceso de seguimiento diario y semanal.
Tabla 1. Métricas de Evaluación de la Etapa de Conceptualización.
AÑO 2013 | ||||||||
METRICA | METODOLOGIA | OBSERVACIONES | ||||||
CASCADA | SCRUM | CASCRUM | ||||||
CUMPLE | ||||||||
Entrega Del Prototipo | NO | NO | NO | Los prototipos cumplen con requerimientos establecidos | ||||
Entrega Del Historial De Versiones | NO | NO | SI | Ambos equipos no entregaron la documentación completa. | ||||
Entrega Del Documento de la Visión general del juego | NO | SI | SI | No entregó la documentación completa |
El grupo de la metodología Scrum aseguro que era tedioso reunirse constantemente todos los días debido a los múltiples deberes que tienen con las demás asignaturas, entre tanto el grupo que usó la metodología CASCRUM, se sentía satisfecho con el seguimiento semanal ya que les permitía poder organizarse correctamente.
Etapa de Pre- Producción
La tabla 2, muestra que la metodología de cascada presenta problemas a la hora de entregar la documentación de esta fase, el grupo indicó que encuentra difícil planificarse a la hora de documentar todo el proceso, que el desarrollo de un videojuego sin supervisión es difícil y que se encuentran desanimados.
Tabla 2. Métricas de Evaluación de la Etapa de Pre-Producción.
AÑO 2013 | ||||
METRICA | METODOLOGIA | OBSERVACIONES | ||
CASCADA | SCRUM | CASCRUM | ||
CUMPLIO | CUMPLIO | CUMPLIO | ||
Causa por qué no se cumplió. | ||||
Entrega Del Documento De Diseño | NO | SI | SI | El grupo que utilizo la metodología de cascada, comento que no logro entender claramente, como se relacionaba el documento de entrega con la etapa. |
Entrega Del Documento De Producción De Arte | NO | SI | SI | No hay comentarios |
Entrega Del Prototipo | NO | SI | SI | El grupo que utilizo la metodología de cascada, no logro terminar el prototipo a tiempo debido a la falta de organización del equipo, para el desarrollo del producto inicial. |
Entrega Del Historial De Versiones | NO | SI | SI | El grupo que utilizo la metodología de cascada, no logro entregar el documento debido a la falta de organización en el grupo. |
Mientras tanto en las otras dos metodologías usadas, los estudiantes si presentaron la documentación solicitada ya que hay un proceso de seguimiento diario y semanal.
El grupo de la metodología Scrum confirma una vez más que era tedioso reunirse constantemente todos los días debido a los múltiples deberes que tienen con las demás asignaturas y sumado a eso el líder del Proyecto(un estudiante) carece de conocimientos de cómo liderar al grupo. Entre tanto el grupo que usó la metodología CASCRUM, confirma que el seguimiento semanal les ha podido ayudar a organizarse pero sin embargo también indican que el líder del Proyecto(un estudiante) también desconoce de muchos de los elementos necesarios para terminar el proyecto.
Etapa de Producción
Tabla 3. Métricas de Evaluación de la Etapa de Producción.
AÑO 2013 | ||||
METRICA | METODOLOGIA | OBSERVACIONES | ||
CASCADA | SCRUM | CASCRUM | ||
CUMPLE | ||||
Plantillas de los Documentos de Producción | NO | NO | SI | El grupo de cascada desistio del Proyecto. El Scrum no entrego el documento por falta de tiempo. CASCRUM lo termino pero a medias. |
Etapa de Conceptualización
La tabla 4, muestra que la metodología de cascada pudo esta vez entregar el document ya que se introdujo un lider de Proyecto del año anterior con experiencia, esto en gran manera facilito el proceso de desarrollo.
Tabla 4. Métricas de Evaluación de la Etapa de Conceptualización.
AÑO 2014 | ||||
METRICA | METODOLOGIA | OBSERVACIONES | ||
CASCADA | SCRUM | CASCRUM | ||
CUMPLIO | CUMPLIO | CUMPLIO | ||
Entrega Del Prototipo | SI | SI | SI | No hay |
Entrega Del Historial De Versiones | SI | SI | SI | No hay |
Entrega Del Documento De La Visión General Del Juego | SI | SI | SI | No hay |
El grupo de la metodología Scrum confirma una vez más que era tedioso reunirse constantemente todos los días debido a los múltiples deberes que tienen con las demás asignaturas pero han encontrado un gran apoyo con el líder del Proyecto(un estudiante con experiencia en desarrollo de videojuegos).
Entre tanto el grupo que usó la metodología CASCRUM, confirma que el seguimiento semanal les ha podido ayudar a organizarse y con el apoyo del lider del Proyecto(un estudiante con experiencia el rendimiento ha sido mejor).
Etapa de Pre- Producción
Tabla 5. Evaluación de la Etapa de Pre-Producción.
2014 | ||||
METRICA | METODOLOGIA | OBSERVACIONES | ||
CASCADA | SCRUM | CASCRUM | ||
CUMPLIO | CUMPLIO | CUMPLIO | ||
Plantillas de los Documentos de Producción | SI | SI | SI | Todos los grupos presentaron el product en la fecha indica. |
Etapa de Producción
Tabla 6. Métricas de Evaluación de la Etapa de Producción.
AÑO 2014 | ||||
METRICA | METODOLOGIA | OBSERVACIONES | ||
CASCADA | SCRUM | CASCRUM | ||
CUMPLIO | CUMPLIO | CUMPLIO | ||
Causa por qué no se cumplió. | ||||
Entrega Del Documento De Diseño | SI | SI | SI | No hay comentarios |
Entrega Del Documento De Producción De Arte | SI | SI | SI | No hay comentarios |
Entrega Del Prototipo | SI | SI | SI | No hay comentarios |
Entrega Del Historial De Versiones | SI | SI | SI | No hay comentarios |
V. CONCLUSIONES
Desarrollar un producto de software, es tarea compleja, y aún más cuando se trabaja con estudiantes de primer ingreso, sin
conocimientos previos de desarrollo y sobre el uso de las metodologías de desarrollo de software. Esto puede parecer una gran desventaja, pero ajustando las metodologías al contexto adecuado se puede obtener resultados interesantes.
A continuación se describirán las conclusiones más importantes de este proyecto:
-La diferencia entre los proyectos de desarrollo de videojuegos entre los periodos académicos 2013-2014, se marcó fue en la entrega de los artefactos y en el seguimientos de los requerimientos dados al principio del proyecto del año académico 2014. Un factor importante fue la introducción de un estudiante que participó en el proyecto del año académico 2013. El estudiante tenía habilidades más avanzadas sobre el desarrollo del proceso de la construcción de los videojuegos.
-La etapa que presentó los mejores resultados en el desarrollo de videojuegos independientemente de la metodología usada, fue la de (conceptualización). La mayor parte de los grupos el documento en la fecha indicada. Los estudiantes comentan que el documento de entrega de esta fase es fácil de entender y de desarrollar en comparación al respeto de los artefactos de las demás etapas de desarrollo.
-Sobre los Roles usados en todas las metodologías de desarrollo usadas en el proyecto, la que mejor dio resultados fue la propuesta por CASCRUM. Este aspecto en base al artefacto de Post Mortem. Dicho documento refleja que los miembros del grupo mantenían una comunicación efectiva a lo largo del desarrollo del proyecto.
-La metodología más eficiente para el desarrollo de videojuegos en estudiantes, fue la de cascada. Los estudiantes indican que el proceso de la metodología, no les permitía tener retroalimentaciones directas con el cliente y esto dificulta, el desarrollo de forma eficiente del videojuego.
-Scrum fue la segunda mejor metodología evaluada en el proyecto, pero sin embargo, los estudiantes indicaron que las reuniones diarias eran casi imposible de hacerla. Una de las causas es que los estudiantes desarrollaban a la par de los proyectos múltiples de sus materias regulares de curso las cuales les restaban tiempo.
-Los estudiantes que usaron la metodología Cascrum, mencionaron que el Week Planning Meeting, les permitió avanzar rápidamente en el desarrollo del producto de software, ya que al tener libertad de escoger la hora y el dia, de la reunión ellos se podían planificar correctamente, las siguientes etapas de la elaboración del videojuego.
-Los grupos que usaron la metodología Cascrum, indicaron que entendieron perfectamente las etapas de la metodología y que sabían perfectamente que se esperaba en cada una de ellas. Mientras tanto en las demás metodologías no se logró entender con claridad que se deseaba en cada fase.
-Los grupos que usaron la metodología de cascada no lograron desarrollar el producto con las especificaciones indicadas, y no entregaron la documentación completa de los artefactos, esto se debió a que los miembros de los grupos dices, que las etas son complejas y no son fáciles de llevar por la falta de retroalimentación.
REFERENCIAS
[1] Hans Van Vliet, “Software Engineering. Principles and Practice” (Tercera edición, 2002) Ian Sommerville, “Software Engineering” (Sexta Edición, 2001)
[2] Mitchel H. Levine, “Analyzing the Deliverables Produced in the Software Development Life Cycle” (2000)
[3] Lawrence-Pfleeger y Shari, “Software Engineering: Theory and Practice”, (1998)
[4] Ron Burback, “Software Engineering Methodology”, (1998)
[5] Roger S. Pressman, “Software Engineering. A practitioner’s Approach” (Quinta Edición, 2001)
[6] R. Kazman, J. Asundi, M. Klein, N. L. Compton, and L. Col, “Making architecture design decisions: An economic approach,” 2002
[7] Keith, C. 2009. Waterfall Game Development. Obtenido de Agile Game Development: http://www.agilegamedevelopment.com/2009/01/in- dawnof-video-game-development.html
[8] http://www.uio.no/studier/emner/matnat/ifi/INF5700/h12/undervisnings materiale/bb-samlet.pdf
[9] http://www.mccormickpcs.com/images/Waterfall_vs_Agile_Methodolo gy.pdf¡
[10] http://www.serena.com/docs/agile/papers/Managing-The-Development- of-Large-Software-Systems.pdf
[11] http://www.inf.ed.ac.uk/teaching/courses/seoc2/2004_2005/slides/metho dologies_4up.pdf
[12] http://www.tutorialspoint.com/sdlc/pdf/sdlc_waterfall_model.pdf
[13] http://www.cs.rit.edu/~hpb/Scia/Bridge_2005/intro_se_workshop_mater ials/s2_process_models.pdf
[14] http://www.cs.rit.edu/~hpb/Scia/Bridge_2005/intro_se_workshop_mater ials/s2_process_models.pdf
[15] http://programmers.stackexchange.com/questions/134256/what-is-the- difference-between-a-software-process-model-and-software-engineering
[16] http://ifs.host.cs.standrews.ac.uk/Books/SE7/Presentations/PDF/ch4.pdf
[17] http://www.cs.toronto.edu/~torsten/THahmann_CSC444_Tutorial1_SW DevProcesses.pdf
[18] http://www.csie.nuk.edu.tw/~ayen/teach/se/se-note02.pdf
[19] Emerging Trends in Software Engineering presented by Roger S. Pressman, Ph.D. R.S. Pressman & Associates, Inc. Boca Raton, Florida USA January, 2009
[20] Flood, K. 2003. Game Unified Process. Obtenido de GameDev:http://www.gamedev.net/reference/articles/article1940.asp.
[21] SANGER, J., WILSON, J., DAVIES, B. y WHITTAKER, R. (1997): Young children, videos and computer games: Issues for teachers and parents. Londres: Falmer
[22] ROUSE III, R. (2005): Game design: Theory and practice. Texas: Wordware Publishing.
[23] RYAN, M. L. (2001): Narrative as virtual reality: Immersion and interactivity in literature and electronic media. Baltimore: Johns Hopkins University Press.
[24] Otter. 2008. The Movie Industry Vs. the Gaming Industry. Obtenido de Associated Content: http://www.associatedcontent.com/article/1015720/the_mo vie_industry_vs_the_gaming_industry.html