Plan de Iteracion Mayo

Objetivo

El objetivo de esta iteración es continuar con el mantenimiento del producto, solucionando los problemas existentes y satisfaciendo, en la medida de lo posible, los requerimientos y sugerencias propuestos por los usuarios que han participado en las pruebas.
También es muy importante que tras esta iteración tengamos una documentación completa, uniforme, bien organizada y, en general, lo mejor posible.

Planificación

Esta iteración comienza el 14 de mayo, tras la celebración de una reunión en el que se hace el reparto de tareas y cada grupo implicado asume y acepta las tareas que se le han asignado, y termina el día 6 de junio, día de la entrega final.

Tareas

1. Mantenimiento del software

1.1. Global

  • 1.1.1. Donde sea necesario, adaptar los proyectos a la convención de nombres de paquetes (mantenimiento preventivo)
  • 1.1.2. Adaptar el código para que cumpla con todos los puntos del control de calidad (mantenimiento preventivo)
  • 1.1.3. Corregir aquellos defectos de software que surjan o hayan surgido (mantenimiento correctivo)
  • 1.1.4. Aquellos paquetes que vayan a estar almacenados en el servidor web para ser descargados por los usuarios (es decir, la parte cliente y común de los juegos y las librerías usadas por el cliente), deberían estar comprimidos. El NetBeans incluye la posibilidad de comprimir automáticamente los archivos ".jar" que genera.

1.2. Juegos

  • 1.2.1. Desarrollo del juego: ASCOttergories (mantenimiento perfectivo)
  • 1.2.2. Correcciones en juego: Mentiroso (mantenimiento correctivo)
  • 1.2.3. Desarrollo del juego: Quien es Quien (mantenimiento perfectivo)
  • 1.2.4. Desarrollo del juego: Hundir la Flota (mantenimiento perfectivo)
  • 1.2.5. Desarrollo del juego: Trivial (mantenimiento perfectivo)
  • 1.2.6. Desarrollo del juego: Damas (mantenimiento perfectivo)
  • 1.2.7. Que los juegos de las Siete y Media y el Mentiroso compartan las clases para gestionar una baraja de cartas (mantenimiento preventivo)
  • 1.2.8. Correcciones en juego: Tres en Raya (mantenimiento correctivo)
  • 1.2.9. Desarrollo del juego: Buscaminas (mantenimiento perfectivo)

1.3. Portal Web

  • 1.3.1. Botones homogéneos (mantenimiento correctivo)
  • 1.3.2. Incluir el Foro (mantenimiento perfectivo)
  • 1.3.3. Establecer un color para la letra que proporcione mayor contraste con el fondo (mantenimiento correctivo)
  • 1.3.4. Imagen juegos grande cuando estás en ellos (mantenimiento correctivo)
  • 1.3.5. No mostrar partidas llenas en las que no se pueden entrar a mitad. (mantenimiento correctivo)
  • 1.3.6. Buscador de amigos jugando (no Juegando y quitar "Activo") (mantenimiento correctivo)
  • 1.3.7. Imagen del logo principal (mantenimiento correctivo)
  • 1.3.8. Borde negro 1px en imágenes juegos. (mantenimiento correctivo)
  • 1.3.9. Avatares más grandes (que no muestre la ruta de la foto) (mantenimiento correctivo)
  • 1.3.10. Estadísticas de juego centradas. (mantenimiento correctivo)
  • 1.3.11. Sección de información para desarrolladores (mantenimiento perfectivo)
  • 1.3.12. Permitir editar la información personal a los usuarios (mantenimiento adaptativo)
  • 1.3.13. Mejorar y pulir los aspectos que se consideren necesarios (mantenimiento correctivo)

2. Mantenimiento de la documentación

2.1. Sección de diseño

  • 2.1.1. Incluir un diagrama que relacione los elementos abstractos de la arquitectura
  • 2.1.2. Incluir un diagrama de secuencia que describa el funcionamiento completo de una acción compleja (por ejemplo una partida a la patata caliente)
  • 2.1.3. Actualizar la especificación del diseño de los componentes desarrollados. Ampliar y pulir dicha documentación para que quede lo más clara posible.

2.2. Historias

  • 2.2.1. Reescribir las historias para que tengan un tono más formal.

2.3. Interfaces

  • 2.3.1. Dividir la sección de interfaces en varias subsecciones, agrupando aquellas interfaces que pertenecen al portal web y a cada uno de los juegos concretos en secciones separadas.
  • 2.3.2. Aumentar el número de interfaces capturadas de la aplicación para describir todas las posibles situaciones (es decir, todas las secciones del portal y todas las interfaces de cada uno de los juegos).
  • 2.3.3. Crear un diagrama que relacione las transiciones entre interfaces (al menos para las del portal web)

2.4. Casos de uso

  • 2.4.1. Dividir la sección de casos de uso en varias subsecciones, agrupando las interfaces de cada uno de los juegos y las interfaces propias del portal web.
  • 2.4.2. Elaborar un diagrama de casos de uso lo más general posible.
  • 2.4.3. Agregar aquellos casos de uso que se hayan desarrollado sin que estuviesen previstos en un principio (los casos de uso de los juegos que faltan, por ejemplo).
  • 2.4.4. Marcar aquellos casos de uso que hayan quedado fuera del alcance.
  • 2.4.5. Cambiar los requisitos no funcionales a datos más concretos.

2.5. Riesgos

  • 2.5.1. Actualizar los riesgos, agregando y descartando según corresponda.
  • 2.5.2. Elaborar un breve historial que describa los riesgos que han ocurrido y el plan de contingencia aplicado, los riesgos que se han evitado, etc.

2.6. Control de calidad

  • 2.6.1. Ampliar la información de cómo se ha realizado el control de calidad, e incluir un enlace a la sección donde se llevan a cabo las revisiones.
  • 2.6.2. Completar las revisiones de las iteraciones anteriores.

2.7. Glosario

  • 2.7.1. Actualizar el glosario eliminando aquellos términos que hayan quedado obsoletos (es decir, que no se utilicen en la aplicación ni en la documentación) y añadiendo aquellos que hayan surgido y que deban ser descritos.

2.8. Secciones del portal

  • 2.8.1. Mover esta sección de la página de documentación. Esta sección se podría fusionar con la sección de interfaces del portal, o moverla a otro lugar.
  • 2.8.2. Actualizar esta sección con las secciones finalmente incluidas en la aplicación.

2.9. Protocolos

  • 2.9.1. Explicar en detalle los protocolos de comunicación de cada subsistema. Describir los mensajes enviados y recibidos (contenido y significado). Esto es aplicable a todos los subsistemas que tengan algún protocolo propio (módulo de chat, módulo de juegos, y cada uno de los juegos).

2.10. Gestión de configuración

  • 2.10.1. Elaborar un informe que explique las herramientas de gestión de configuración utilizadas, su uso y su utilidad para el desarrollo de la aplicación.
  • 2.10.2. Archivar el código disponible en cada entrega. Para cada entrega, deben incluirse solamente aquellos proyectos que estaban lo suficientemente maduros (excluir aquellos proyectos recién creados o que aún ni siquiera podían probarse).
  • 2.10.3. Archivar la documentación disponible en cada entrega.

2.11. Requisitos, alcance y viabilidad

  • 2.11.1. Elaborar un documento de especificación del sistema (requisitos).
  • 2.11.2. Elaborar un documento de alcance.
  • 2.11.3. Elaborar un documento de viabilidad.

2.12. Patrones de diseño

  • 2.12.1. Incluir una sección que describa los patrones utilizados.
  • 2.12.2. En caso de que se pudiese haber utilizado un patrón y no se haya hecho, justificar el porqué. Estos datos se incluirán tanto en la sección de Patrones de diseño como en la de Diseño de cada elemento concreto.

2.13. Base de datos

  • Elaborar un documento que explique la estructura de la base de datos, mencionando qué elementos (servidor web, servidor de juegos) leen o escriben cada una de las tablas.

2.14. Tarjetas CRC

  • Añadir a la Wiki las tarjetas CRC elaboradas en su día.

2.15. Reingeniería

  • Incluir un documento que exponga algunos casos en los que ha sido necesario aplicar los principios de reingeniería.

2.16. Software Capability Maturity Model

  • Incluir el documento que justifica el nivel CMM conseguido por nuestro grupo.

2.17. Tecnologías

  • Actualizar la sección de tecnologías, concretando los datos ofrecidos con la información más actual disponible. Especificar dónde y por qué se ha incluido cada una de las tecnologías.

2.18. Pruebas

  • Actualizar la sección de pruebas con los datos del último día de pruebas.

2.19. Estimación

  • 2.19.1. Elaborar informe de estimación de costes por cada uno de los métodos vistos.

2.20 Estudio de mercado

  • 2.20 Elaborar un documento de estudio de mercado que compare nuestro producto con otros similares

2.21 Planificación y Entregas

  • 2.21.1 Completar la sección de entregas
  • 2.21.2 Actualizar el plan de fase

3. Manuales de usuario

3.1. Manuales de usuario de los juegos

  • 3.1.1. Crear un documento que explique las reglas del juego y cómo se juega a dicho juego a través de nuestro portal. En la reunión acordamos que habría que dividir este documento en 3 secciones: una que explique las reglas del juego, otro que explique cómo crear / unirse a una partida de ese juego, y una última sección que explique las interfaces de usuario una vez se está jugando.
  • 3.1.2. El manual de usuario de los juegos debe generarse en formato PDF y subirse a la carpeta del SVN destinada a tal fin ("portal/cliente/manuales").

3.2. Manuales de usuario del framework y aplicaciones para desarrolladores

Los manuales de usuario del framework, junto con todos los archivos necesarios para el desarrollo de una aplicación para el portal deben incluirse en un único fichero comprimido descargable desde la sección de "Información para desarrolladores". Para ello

  • 3.2.1. Crear la sección de Información para desarrolladores, que incluya una breve descripción del proceso de desarrollo de juegos para el portal. Debería solamente mencionar los pasos a nivel abstracto, sin ahondar en el desarrollo en sí, sino en cómo obtener el framework y qué hacer una vez tenemos un juego terminado. Hay que ser coherentes, no todos los juegos que se reciban se van a poner, esto hay que advertirlo sin que desanime a un posible desarrollador.
  • 3.2.2. Elaborar documentación de usuario para el framework (tanto la parte cliente como servidor)
  • 3.2.3. Elaborar documentación del probador offline.

Asignación

Daniel y Daniel

  • 1.1
  • 1.2.2
  • 1.2.7 (No lo haremos)
  • 2.1.3
  • 2.3.2
  • 2.4.3
  • 2.6.2
  • 2.9
  • 2.12
  • 2.15
  • 2.17
  • 2.19
  • 3.1

Rubén y Beatriz

  • 1.1
  • 1.2.1
  • 2.1.2
  • 2.1.3
  • 2.3.2
  • 2.4.3
  • 2.5.1
  • 2.5.2
  • 2.6.2
  • 2.8.1
  • 2.9
  • 2.10.2
  • 2.12
  • 2.18
  • 3.1
  • 3.2.2

Santi y Víctor

  • 1.1
  • 1.2.5 (Casi, by Víctor)
  • 2.1.3
  • 2.3.2 (Somos Servidor No Tenemos Capturas)
  • 2.4.3
  • 2.6.2
  • 2.9
  • 2.10.1
  • 2.10.3 (Santi está en ello)
  • 2.12 (nuestros patrones son los generales del Servidor->ya hecho)
  • 2.16
  • 3.1 (Segun termine el Trivial lo hago)

Ezequiel y Guillermo

  • 1.1
  • 1.2.4
  • 2.1.1
  • 2.1.2
  • 2.1.3
  • 2.3.2
  • 2.4.3
  • 2.6.1
  • 2.6.2
  • 2.9
  • 2.12
  • 2.14
  • 3.1
  • 3.2.2
  • 2.21

Patri y Conrado

  • 1.1
  • 1.2.7
  • 2.1.3
  • 2.3.2
  • 2.4
  • 2.6.2
  • 2.9
  • 2.12
  • 3.1

Jonás y Lara

  • 1.1
  • 1.2.8
  • 2.1.3
  • 2.3.2
  • 2.4.3
  • 2.6.2
  • 2.9
  • 2.11
  • 2.12
  • 3.1

Jesús e Isaac

  • 1.1
  • 1.2.3 (No se va a hacer)
  • 2.1.3
  • 2.2
  • 2.3.2
  • 2.4.3
  • 2.6.2
  • 2.9
  • 2.12
  • 3.1
  • 3.2.3

Cristian y Pablo

  • 1.1
  • 1.2.9
  • 2.1.3
  • 2.3.2
  • 2.4.3
  • 2.6.2
  • 2.9
  • 2.12
  • 2.20
  • 3.1

Gerardo y Eduardo

  • 1.1
  • 1.2.6
  • 1.3
  • 2.1.3
  • 2.3.1
  • 2.3.2
  • 2.3.3
  • 2.4.3
  • 2.6.2
  • 2.8.2
  • 2.9
  • 2.12
  • 2.13
  • 3.1
  • 3.2.1