Riesgos

(Para ver un breve historial de los riesgos ocurridos y los planes de contingencia aplicados pulsa Aquí).

La siguiente tabla muestra un resumen de los riesgos considerados:

Riesgo	Probabilidad	Impacto
Falta de iniciativas entre los miembros del grupo	Muy alta	Catastrófico
Incompatibilidad de horarios entre los miembros del grupo	Muy alta	Tolerable
Discrepancias en el grupo	Muy alta	Tolerable
El protocolo es inadecuado para los juegos que hagamos	Alta	Serio / Catastrófico
Mala estimación en el tiempo necesario para completar las características fundamentales del proyecto	Alta	Serio
Falta de tiempo para realizar características secundarias	Alta	Tolerable
El proyecto no funciona en los puestos de laboratorio	Moderada	Catastrófico
No se dispone de un servidor para ejecutar la aplicación	Moderada	Catastrófico
El personal no es capaz de adquirir los conocimientos	Moderada	Serio
La aplicación es demasiado lenta como para ser usable	Moderada	Serio
La aplicación es excesivamente grande	Moderada	Serio
El portal no tiene aceptación por parte de los usuarios	Moderada	Serio
Bajas permanentes del personal (por bajas médicas, abandono de la asignatura, etc.)	Baja	Serio
La tecnologia del cliente usada presenta limitaciones	Alta	Serio
Los grupos de trabajo no se coordinan y/o no son capaces de comprender su tarea	Alta	Serio

(Nota: Los riesgos no marcados como eliminados, no han ocurrido y por tanto se eliminarian. No estan eliminados para saber los que se definieron en un principio)

El protocolo es inadecuado para los juegos que hagamos

Probabilidad	Alta
Impacto	Serio / Catastrófico
Descripción	El protocolo de comunicaciones diseñado para que interactúen las aplicaciones cliente de los juegos con el servidor presenta problemas o se queda corto para representar todas las funcionalidades necesarias en los juegos.
Consecuencias	Los juegos no pueden tener todas las funcionalidades esperadas o incluso determinados juegos no pueden funcionar con nuestro servidor.
Cómo evitarlo	Al ser el protocolo de comunicaciones una parte fundamental del proyecto y con altas posibilidades de presentar algún fallo se debe emplear el tiempo necesario para diseñar el protocolo correctamente, así como probar la mayor cantidad de situaciones posibles contra él para asegurarnos de que una buena cantidad de los posibles usos del mismo están cubiertos.
Cómo tratarlo	La solución pasaría por analizar los casos en los que el protocolo no soporta las funcionalidades necesarias e intentar añadir las extensiones al protocolo necesarias. Esto podría requerir una buena cantidad de tiempo en análisis y cambios en el servidor (Serio) así como la modificación de una gran mayoría de los programas clientes ya hechos (Catastrófico).
Eliminado	Iteracion Diciembre. En el prototipo, el protocolo, se ha probado en varias ocasiones entre ellas con un juego, y se ha visto que era adecuado.

El proyecto no funciona en los puestos de laboratorio

Probabilidad	Moderada
Impacto	Catastrófico
Cómo evitarlo	Encargar a un grupo la investigación de las versiones del software instalado en los puestos de laboratorio y limitar el desarrollo del proyecto a las versiones instaladas. Además hay que investigar y tener en cuenta el espacio de disco disponible, así como la memoria y el ancho de banda.
Cómo tratarlo	En caso de incompatibilidad con el software necesitado nos pondremos en contacto con los técnicos de los laboratorios, si no funciona este recurso se intentarán modificar las partes del proyecto problemáticas. Marzo: Se ha barajado traer hardware propio incluyendo portátiles y un router en caso de no poder solucionar las incompatibilidades
Eliminado	Iteracion Diciembre. El prototipo se ha podido hacer funcionar en los puestos de laboratorio. En la iteración de Marzo se descubren problemas que impiden su funcionamiento. En apariencia resueltos en Abril (a falta de pruebas serias). Tras las pruebas de Mayo se confirma que la aplicacion funciona en los puestos de laboratorio

No se dispone de un servidor para ejecutar la aplicación

Probabilidad	Moderada
Impacto	Catastrófico
Cómo evitarlo	Tratar de conseguir un servidor en el que colocar tanto el portal como el servidor de juegos a la mayor brevedad posible. Conseguir también un servidor secundario para el caso en que el primero falle. Diseñar el proyecto de forma que un ordenador de los laboratorios pueda actuar de servidor.
Cómo tratarlo	Si en el momento de la entrega el servidor no funciona, puede utilizarse uno de los puestos del laboratorio para actuar como tal. Si no se ha diseñado de forma que aquello funcione, las consecuencias son catastróficas.
Eliminado Parcialmente	Iteracion Diciembre. Se ha usado como tal un puesto de laboratorio, apoyandonos en servidores portables

Bajas permanentes del personal (por bajas médicas, abandono de la asignatura, etc.)

Probabilidad	Baja
Impacto	Serio
Cómo evitarlo	Concienciarles de que todos somos un grupo y debemos trabajar como tal. Organizar los trabajos de forma que una baja afecte lo mínimo posible. Como medida de prevención se evitará que sólo sea una persona la que esté encargada de investigar y utilizar una tecnología especifica.
Cómo tratarlo	Reorganizar el trabajo distribuyéndolo entre los miembros del grupo.
Eliminado	Al final del proyecto hubo suerte y nadie abandonó el grupo

El personal no es capaz de adquirir los conocimientos

Probabilidad	Moderada
Impacto	Serio
Consecuencias	El sujeto no puede progresar. El sujeto no es útil actualmente y además no desempeña trabajo. Otros grupos que dependen del sujeto no pueden avanzar. El proyecto se detiene en su parte asignada y, en el peor caso, totalmente.
Cómo evitarlo	Reparto adecuado de los grupos de trabajo, teniendo cuenta los conocimientos previos de los miembros.
Cómo tratarlo	Asignarle otra tarea en que pueda ser útil. Puede suponer reorganizar grupos para cubrir su parte. Construir con él un grupo más amplio con miembros de grupos más avanzados o más capacitados para facilitar el aprendizaje.
Eliminado	Todos los desarrolladores han conseguido realizar al menos un juego usando el framework con las tecnologías necesarias

Mala estimación en el tiempo necesario para completar las características fundamentales del proyecto

Probabilidad	Alta
Impacto	Serio
Cómo evitarlo	Tener los pies en la tierra y no a añadir características excesivamente complejas al programa sin ningún criterio.
Cómo tratarlo	Planificar con sumo cuidado cada paso a dar en la división de trabajo antes de empezar a programar. También podría paliar el problema tener a un grupo con la tarea adicional de investigar posibles alternativas a los métodos elegidos paralelamente al desarrollo del trabajo en sí.
Ocurrencias	El desarrollo de la parte cliente del framework llevó mas tiempo del esperado y fue necesario replanificar ciertas tareas

Falta de tiempo para realizar características secundarias

Probabilidad	Alta
Impacto	Tolerable
Cómo evitarlo	Una buena planificación del proyecto, estableciendo unas fechas para la finalización de cada parte (y cumpliéndolas). Teniendo claro cuales son las partes prioritarias y secundarias del proyecto.
Cómo tratarlo	Acordar entre todo el grupo las fechas de entrega de cada parte importante dejando un margen de tiempo de sobra para realizar las características secundarias y reajustes necesarios.
Ocurrencias	Efectivamente muchas de las características secundarias especificadas quedaron finalmente fuera de alcance

Incompatibilidad de horarios entre los miembros del grupo

Probabilidad	Muy alta
Impacto	Tolerable
Cómo evitarlo	Repartir el trabajo de tal manera que se puedan establecer grupos de trabajo más pequeños para posteriormente unificarlos.
Cómo tratarlo	Intentar establecer los horarios de tal forma que el mayor número de miembros pueda asistir. También basta con la presencia de un miembro de cada subgrupo creado para las distintas tareas del proyecto. Es importante recurrir a soluciones tecnológicas tales como una lista de distribución, un foro, un wiki y el uso de un CVS, que permitan a todos los miembros del grupo realizar cambios y ver los realizados por el resto del equipo.
Eliminado	La facilidad para edición colaborativa de la Wiki y del SVN han facilitado que personas con horarios incompatibles hayan podido seguir desarrollando sin problema

La aplicación es demasiado lenta como para ser usable

Probabilidad	Moderada
Impacto	Serio
Cómo evitarlo	Utilizar tecnologías que no impliquen un alto coste de rendimiento.
Cómo tratarlo	Dar prioridad a la jugabilidad y el manejo de la aplicación frente a opciones gráficas que puedan acusar un rendimiento excesivo (herramientas más eficientes, programación más fácil, etc.)
Eliminado	Las pruebas realizadas indican que la aplicacion se ejecuta a una velocidad correcta en los equipos objetivo

Discrepancias en el grupo

Probabilidad	Muy alta
Impacto	Tolerable
Cómo evitarlo	A lo largo del desarrollo del software dar libertad de decisión a todos y cada uno de los miembros del grupo de aportar ideas hacia la práctica, de forma que nadie vea sus ideas vetadas; siempre y cuando no haya inconvenientes serios a la hora de aceptar dichas ideas.
Cómo tratarlo	Intentar en la medida de lo posible llegar a una solución que toque todas las ideas del grupo.

Falta de iniciativas entre los miembros del grupo

Probabilidad	Muy alta
Impacto	Catastrófico
Cómo evitarlo	Concienciar a la gente de que o cada uno aporta su granito de arena y todos colaboramos o el proyecto se va a pique. La nota que saquemos es de y para todos. No vale quejarse de una mala gestión del grupo si no se aportan soluciones para que dicha mala gestión no tenga lugar.
Cómo tratarlo	En primer lugar dar un toque de atención a la/s persona/s que no hagan nada para que esto salga adelante. En segundo lugar, actuar dividiendo el trabajo en grupos lo más reducidos posible, de manera que el aporte individual sea crucial.

La aplicación es excesivamente grande

Probabilidad	Moderada
Impacto	Serio
Cómo evitarlo	Optimizar al máximo los recursos utilizados (sobre todo multimedia).
Cómo tratarlo	Pedir más espacio, utilizar memorias externas o usar otras herramientas más eficientes en espacio.
Eliminado	La parte servidor ocupa unos 20Mb y las descargas necesarias para la parte cliente no son excesivas para conexiones de banda ancha estandard

El portal no tiene aceptación por parte de los usuarios

Probabilidad	Moderada
Impacto	Serio
Cómo evitarlo	Consultar con posibles usuarios de manera periódica si la aplicación les causa interés. Para ello, buscaremos un grupo de personas (externas al grupo de desarrollo) dispuestas a probar el portal. Realizar encuestas con una muestra considerable de usuarios que dediquen un tiempo a utilizar nuestro portal.
Cómo tratarlo	Remodelación de la aplicación cara al gusto del usuario
Eliminado	Las pruebas en laboratorio indican que el portal es en gran medida del agrado de los usuarios y que consideran los juegos divertidos

La tecnologia de cliente usada presenta limitaciones

Probabilidad	Alta
Impacto	Serio
Cómo evitarlo
Cómo tratarlo	Implementar ciertas funcionalidades a mano
Eliminado	Iteracion Diciembre. En el prototipo se han eliminado esta limitaciones como anteriormente se ha descrito.

Los grupos de trabajo no se coordinan y/o no son capaces de comprender su tarea

Probabilidad	Alta
Impacto	Serio
Cómo evitarlo	Mejorando la comunicación entre los miembros del proyecto y preguntando cuando algo no se comprenda
Cómo tratarlo	Mejorando la documentacion y la comunicacion entre los miembros del grupo