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 |