Ingeniería del Software de Gestión II Práctica UHU-Risk, El Risk de la UHU.

Transcripción

1 Ingeniería del Software de Gestión II Práctica UHU-Risk, El Risk de la UHU. 1. Objetivos Realizar el desarrollo completo de una aplicación desde la especificación de requisitos hasta su implementación en un lenguaje de programación. Planificar un proyecto de desarrollo software Utilizar un problema y un modelo real para aplicar los conocimientos adquiridos. Desarrollar aplicaciones siguiendo la arquitectura modelo-vista-controlador. Diseñar una aplicación completa siguiendo las actividades propuestas en una metodología estándar, Agile UP. Practicar el desarrollo de software en equipo. 2. Descripción del sistema Hemos decidido realizar una nueva versión del clásico juego de tablero 'Risk' para PC. Será una versión Java en la que intentaremos que en su funcionamiento puedan jugar jugadores humanos y virtuales, de un modo eminentemente visual, siempre siguiendo la metodología Agile UP, con una serie de entregables y fechas de entrega predefinidas. Risk (Riesgo, del Inglés en forma literal) es un juego de mesa comercial basado en turnos creado por Albert Lamorisse en 1950 y adquirido en 1958 por la empresa Parker Brothers la cual, hoy en día, es una división de Hasbro. Este juego pertenece a la categoria de los juegos de guerra y que evoca las Guerras Napoleónicas, siendo su principal característica su simplicidad y abstracción al no pretender simular correctamente la estrategia militar en los territorios específicos, la geografía del mundo y la logística de las campañas extensas. El Risk cuenta con un tablero dividido en 42 territorios, agrupados en 6 continentes, 5 dados, 3 rojos para el ataque y 2 azules para la defensa, una baraja de 56 cartas (42 cartas de territorios, 2 comodines y 12 cartas de misiones secretas): América del Norte 1. Alaska 2. Alberta 3. América Central 4. Estados Unidos del Este 5. Groenlandia 6. Territorios del Noroeste 7. Ontario 8. Quebec 9. Estados Unidos del Oeste América del Sur 1. Argentina 2. Brasil 3. Perú 4. Venezuela Europa 1. Gran Bretaña África 1. Congo 2. África Oriental 3. Egipto 4. Madagascar 5. África del Norte 6. Sudáfrica Asia 1. Afghanistan 2. China 3. India 4. Irkutsk 5. Japón 6. Kamchatka 7. Oriente Medio 8. Mongolia 9. Siam 10. Siberia

2 2. Iceland 3. Europa del Norte 4. Escandinavia 5. Europa del Sur 6. Ucrania 7. Europa Occidental 11. Ural 12. Yakutsk Australia 1. Australia Oriental. 2. Indonesia 3. Nueva Guinea 4. Australia Occidental 2.1 Resumen del juego El juego se inicia mediante el reparto de los territorios entre los jugadores, mediante el reparto de las cartas que identifican a cada territorio y la asignación de un determinado número de ejércitos a cada jugador, que, por turnos, situarán de manera estratégica en cada territorio de su propiedad, con un mínimo de un ejercito en cada territorio asignado. Una vez situados los ejércitos, por turnos, los jugadores pueden realizar las siguientes acciones: Cambiar cartas (por cada turno en que han ganado al menos un territorio reciben una carta, con un territorio y un tipo de ejercito, ya sea infantería, artillería o caballería), que podrán reemplazar por ejércitos. Ubicar ejércitos (si han recibido nuevos ejércitos al cambiar de turno o por cambiar cartas). Atacar a un territorio vecino. Desde un territorio propio se puede atacar a un vecino. Ambos indican con cuantos ejércitos atacan y se defienden y en función de ello tirarán un número determinado de dados. Invadir un territorio vecino. Si se ataca un territorio y se eliminan todos los ejércitos que hubiera, habrá que desplazar desde el territorio de origen cuántos ejércitos se quieran al nuevo, con al menos un ejercito. Transferir ejércitos. Una vez finalizados todos los ataques, el usuario que tiene el turno puede mover ejercitos de un territorio a su vecino. 2.2 Objetivo del juego Existen tres modalidades de juego: Dominación, donde gana aquél que conquista todos los territorios, Misión secreta, donde se asigna una carta a cada jugador con un objetivo secreto a conseguir. Capitales, cada jugador escoge un territorio que será su Cuartel General y habrá de defenderlo y conseguir invadir los cuarteles generales de, al menos, la mitad más uno de sus oponentes. Para ver en mayor detalle el funcionamiento de este juego, revisa las referencias. 3. El Proceso de Desarrollo

3 Como hemos comentado, se va a intentar seguir en la elaboración de este proyecto, una metodología iterativa e incremental. Como en principio el sistema propuesto no tiene porqué ser conocido, como si se tratara de un caso real, y la descripción que se nos ha proporcionado es muy general, necesitaremos especificar con más detalle los requerimientos del sistema y por tanto comunicarnos con los usuarios finales para tal fin. Para poder solventar este problema los profesores actuarán como usuarios finales. Para poder centralizar todas las preguntas al respecto del sistema, se va a crear un foro sobre requerimientos de esta práctica, de tal manera que las cuestiones referentes al funcionamiento de la herramienta y las respuestas de los usuarios (los profesores de la asignatura) se encuentren disponibles para todos. 3.1.Organización de los grupos de prácticas La ejecución de la práctica se realizará por grupos, formados por un conjunto de compañeros que se identificarán mediante un nombre de empresa. Cada grupo estará compuesto por un mínimo de 2 personas y un máximo de 4. Excepcionalmente, atendiendo a circunstancias particulares debidamente justificadas, se permitirá la elaboración individual de la práctica. Los componentes han de ser preferentemente del mismo grupo de prácticas. El entorno de trabajo natural del proyecto es el laboratorio, cuando en alguna empresa se necesite resolver alguna cuestión, algún componente de dicha empresa deberá plantearla en una clase de prácticas. Los grupos de prácticas deberán tener especial cuidado en mantener la coherencia lógica del proceso de desarrollo debiendo utilizar los resultados logrados en cada fase como base para la fase siguiente. En cada entrega, se subirá la versión estable del proyecto a la correspondiente tarea en la plataforma docente. Los equipos trabajarán apoyándose en un wiki o blog, donde irán documentando todo su trabajo. Cada equipo tendrá uno. 3.2.Foro de la práctica Se ha habilitado en la página de la asignatura un nuevo foro para que sirva de medio de comunicación entre las diferenctes empresas. Mediante este foro podremos: Abrir debates sobre partes de la especificación de la aplicación y elaboración de la práctica. Todas las dudas con respecto a lo que la aplicación debe o no hacer, requerimientos, elaboración de distintas partes de la práctica, etc... Colaboración entre empresas. Con el fin de que los diferentes grupos colaboren entre sí, se permite que se publiquen las soluciones que se hayan propuesto por empresas a las distintas fases del proyecto. Esta compartición podrá hacerse mediante la publicación de comentarios, ficheros de imágenes, extractos de código, documentación en formato javadoc, etc... pero nunca mediante la publicación de ficheros que formen parte de un proyecto Netbeans. Valoración de las colaboraciones. Se valorará especialmente que se colabore con otros grupos en la solución de aquellos aspectos más dificultosos de la práctica. Utilización de partes publicadas. Se podrá utilizar libremente partes de los proyectos de otros compañeros o fragmentos de código localizados en la web (o cualquier otra fuente bibliográfica) siempre y cuando estas partes se hayan publicado en el foro y se referencia su utilización. Si se utiliza una parte de un proyecto de otro

4 compañero que no se encuentre publicada o no se indique que es una parte desarrollada por otro compañero o tomada de algún lugar de referencia, se considerará que la parte se ha plagiado, se ha copiado sin autorización. 3.3.Planificación del proyecto Con el fin de poder coordinar el funcionamiento de las clases de prácticas manteniendo un nexo de unión común entre los diferentes grupos de prácticas, se marcarán una serie de hitos durante el desarrollo de la práctica. Estos hitos marcarán el fin de cada una de las fases importantes de la práctica. Vamos a enumerar el conjunto de entregables que se habrán de elaborar y entregar en cada iteración. Hito 1 (8/11/2008): Iteración I1:Se entregará: Modelado requisitos a alto nivel Elaboramos de manera sencilla, clara e informal un borrador del diagrama de casos de uso así como una breve descripción textual de cada caso de uso. Modelado arquitectura a alto nivel El objetivo es tratar de identificar una arquitectura con posibilidades de funcionar bien desde el punto de vista técnico y conceptual. Haremos un diagrama de despliegue para razonar los nodos y un borrador básico del diagrama de clases. Planificación del proyecto Se entregará un diagrama de Gantt en el que el grupo establece las tareas a realizar, los entregables a generar y asigna cada tarea a un recurso del grupo. PARA LA ARQUITECTURA Y LA INTERFAZ PODEIS TRABAJAR EN PAPEL O PIZARRA Y ESCANEAR O FOTOGRAFIAR EL RESULTADO, O BIEN USAR UNA HERRAMIENTA CASE. Hito 2 (22/11/2008): Iteración E1:Se entregará: Prueba de la arquitectura del sistema Se trata de asegurar en este punto que el equipo es capaz de desarrollar un sistema que satisfaga los requisitos. Para ello se elabora una aplicación básica, a partir de las clases obtenidas, que use mensajes en pantalla y que incluya la arquitectura básica, y realice la gestión de turnos. Establecimiento y actualización del gestor de la configuración. Llegados a este punto, todos los equipos deberán estar usando y tener actualizados sus proyectos en el gestor de configuraciones a usar. En las iteraciones de construcción, de manera iterativa, vamos analizando un conjunto de requisitos, diseñando una solución, construyéndola y probando el resultado.

5 Hito 3 (6/12/2008). Iteración C1: En esta iteración nos centramos en el análisis, diseño e implementación del tablero y el movimiento por él. Entregaremos tanto el diagrama de casos de uso revisado como el diagrama de clases, y el diagrama de secuencia del caso de uso que gestiona la partida. En código, se entregará una versión operativa que informe a través de mensajes en ventana de sistema, de las tiradas de dados en un enfrentamiento, dentro de un turno. Sólo consideramos jugadores humanos. Hito 4 (20/12/2008). Iteración C2: En esta iteración vamos a centrarnos en cómo se produce el rearmamiento en cada turno, y los trasvases entre territorios. Entregaremos tanto el diagrama de casos de uso revisado como el diagrama de clases, y el diagrama de secuencia del caso de uso que gestiona la partida. En código, se entregará una versión operativa que informe a través de mensajes. Hito 5 (12/1/2009). Iteración C3: Añadimos en esta iteración el componente gráfico, siguiendo el modelo vista-controlador, usaremos un formulario como tablero en el que se irán mostrando los elementos durante el juego. Posibilidad de juego en red, mediante programación de sockets. Entrega, hito 6 (27/1/2008). Iteración T1: En esta iteración, se añade la funcionalidad de poder almacenar/recuperar una partida, a través del uso de la persistencia. Así mismo, se prepara la herramienta para el despliegue, elaborándose: Documentación Pruebas a fondo Preparar distribución e instalación 4. Evaluación del proyecto Se divide en dos partes: Parte 1. Entregas periódicas, valoración de los trabajos del grupo entregados en tiempo y forma para su revisión. La puntuación del grupo es la puntuación dada a cada miembro. Parte 2. Defensa individual del proyecto. Mediante esta defensa individual se evaluará el grado de implicación, participación y conocimiento de cada miembro del grupo. Se evaluará la cantidad y calidad de los requisitos iniciales que implemente la herramienta. Se evaluará la calidad de la documentación del sistema (y de los requisitos) generada. Se valorarán muy especialmente la colaboración prestada en el foro a los compañeros. Se penalizará la no cumplimentación de algún requisito cuando éste haya sido solucionado de manera pública en el foro o en las clases prácticas. 5. Referencias Instrucciones originales del fabricante (en inglés):