Riesgos

Gestión de riesgos del proyecto.

Tabla de riesgos

Resuelto	Nombre	Tipo	Descripción	Probabilidad	Consecuencias	Prioridad de solución
S	Capa de dispositivos heterogénea	Proyecto	Las APIs de almacenamiento de snapshots son muy heterogeneas	Muy alta	serias	Media
N	Nadie contrata almacenamiento	Negocio	Nadie contrata la opción de guardar los backups en el almacenamiento extra	Muy alta	serias	Baja (actualmente nuestra prioridad es la aplicación, y no el modelo de negocio que pudiera desarrollarse alrededor)
S	Parones temporales	Proyecto	Parones en el trabajo debido a puentes o exámenes	Alta (pero predecible)	serias	Alta
D	Limites de Rdiff	Tecnológicos	Los límites que imponen en los path pueden causar problemas	Alta	serias	Alta
S	Falta organización	Negocio	Falta de coordinación entre los miembros del equipo	Alta	muy serias	Alta, estamos en ello
N	No dominar nautilus	Tecnológico	No conseguir integrar el programa en nautilus	Alta	tolerables	Media
N	Costes almacenamiento	Negocio	No sale rentable mantener el servicio de almacenamiento extra	Alta	serias	Baja (a priori, consideramos el trabajo sobre las características del modelo de negocio secundario. Además es un problema que, si está resuelto a nivel usuario individual, facilitaría su resolución a nivel almacenamiento compartido)
S	Falta de herramientas UML	Tecnológico	No hay herramientas de UML para python	Media	serias	Muy Alta
S	El equipo no rinde	Proyecto	La gente pasa del proyecto y se retrasa por falta de trabajo	Media	muy serias	Muy alta
S	El programa no funciona en los laboratorios	Proyecto	Los ordenadores del laboratorio no tienen las tecnologías o permisos necesarios	Media	catastróficas	Muy muy alta (surgirá en cuanto empecemos a desarrollar código)
S	No nos aclaramos con launchpad	Tecnológico	El launchpad nos da problemas y no nos aclaramos con el(machacamos cosas útiles y rompemos repos).	Media	seria	Alta
N	El profesor suspende una entrega	Proyecto	No gusta el desarrollo seguido	Media	serias	Alta
D	Rdiff-backup no cubre los casos de uso	Tecnológico	Rdiff no nos proporciona la funcionalidad deseada	Media	criticas	Alta
N	Programa con funcionalidad insuficiente	Producto	El programa se queda corto en cuanto a funcionalidad.	Media	tolerables a serias (según cuánta funcionalidad falte, y cómo de crítica resulte)	Alta
N	Demasiado lento	Producto	El programa ralentiza en exceso la CPU o memoria, o es demasiado lento haciendo backups	Media (muchas escrituras)	serias (el programa no sería demasiado usable)	Media
S	Nos llevamos mal	Negocio	Discusiones dentro del equipo, faltas a las reuniones…	Media	muy serias	Baja
S	No hay conexión a internet	Proyecto	Se cae el servicio y nos quedamos sin forma de trabajar durante un periodo de tiempo	Media	tolerables	Baja (ajena a nuestro control)
N	Se cae el servidor de almacenamiento	Negocio	El servidor de almacenamiento extra se cae y provoca el enfado de los usuarios	Media	muy serias a catastróficas (según consecuencias de la caída)	Baja
N	Ocupa demasiado espacio	Producto	El programa o sus backups ocupan demasiado espacio en disco.	Media (a priori no lo sabemos pero tenemos el limite impuesto por el laboratorio)	tolerables	Baja
S	Integración con bazaar	Tecnológico	Alta probabilidad de romper repositorios a la hora de usar bazaar.	Media	tolerables	Baja
N	Problemas con FAT32	Tecnológico	Posibles problemas con los limites que establece el sistema de archivos FAT32	Media	serias	Media
S	Arquitectura mal diseñada	Tecnológico	Hemos hecho mal la arquitectura y hay que realizar cambios.	Media	criticas	Media
S	No dominar sqlite	Tecnológico	No conseguir dominar sqlite	Media	tolerables	Media
N	No llegar a dominar Fuse	Tecnológico	No conseguir dominar Fuse	Media	tolerables	Baja
N	Se corrompe un backup	Producto	Un backup del programa se corrompe	Baja	catastróficas	Esperemos tener el proyecto avanzado cuando pase
S	El programa no es fiable	Producto	El programa tiene problemas al ejecutar y es inestable, posiblemente corrompe backups.	Baja	catastróficas	Muy alta
N	Wiki se cae	Proyecto	El wiki se cae y no podemos acceder a lo guardado en él o utilizarlo para seguir documentando	Impredecible (Baja)	serias / muy serias (según el tipo de caída, temporal o permanente, y si se pierden datos)	Muy alta, lo primero que vamos a solucionar.
S	Problemas de personal	Proyecto	Enfermedades, deserciones de la asignatura, etc.	Baja	tolerables	Baja (Siendo pocos una deserción es más crítica, ya que necesariamente estamos más especializados, lo que aumenta el riesgo)
S	No dominar GTK	Tecnológico	Nadie domina GTK en el grupo de trabajo	Baja	Muy serias (una interfaz usable es crítica para el éxito del proyecto)	Alta
N	Programa difícil de usar	Producto	El programa es demasiado complicado de utilizar para el usuario medio, o poco intuitivo, o no es predecible y las opciones no hacen lo que se esperaría.	Baja	serias	Media/Alta (si es demasiado complicado de utilizar el usuario no lo usará; si es impredecible el usuario achacará -con razón- el uso incorrecto a los desarrolladores)
S	No llegar a dominar Python	Tecnológico	No llegamos a dominar Python	Baja	Serias	Alta
N	No llegar a dominar beagle	Tecnológicos	Nadie domina beagle en el grupo de trabajo	Baja	tolerables (la integración con beagle no es crítica para el éxito del núcleo del proyecto, es funcionalidad adicional)	Media
N	Incompatibilidad de horarios	Negocio	Los horarios nos impiden reunirnos todo lo que nos gustaría	Baja	tolerables (según el grado de incompatibilidad)	Media
N	Falta de tiempo	Proyecto	El tiempo para realizar el proyecto se nos queda corto	Baja	tolerables a catastróficas (en función de en qué punto del desarrollo del proyecto nos quedásemos)	Media
S	No dominar dbus	Tecnológico	No conseguir manejar el uso de dbus (sistema de comunicación interproceso)	Baja	serias (dificultaría la separación backend-frontend)	Media
S	No dominar distutils	Tecnológico	No conseguir manejar el uso de distutils (tecnología de instalación de python)	Baja	serias	Media
N	Problemas con inodos	Tecnológico	El número de inodos posibles en un sistema de ficheros está limitado, y si no se tiene cuidado podemos toparnos con él.	Baja	serias	Media
N	No llegar a dominar HAL	Tecnológico	Nadie domina HAL en el grupo	Baja	poco serias	Baja
N	El repositorio se cae	Proyecto	El servidor donde alojemos el código se cae	Baja	insignificante	insignificante
S	No llegar a dominar inotify	Tecnológicos	Nadie domina inotify en el grupo de trabajo	Muy baja	muy serias (componente crítico para que el conocimiento de qué es necesario archivar sea eficiente)	Alta
N	Falta de material	Proyecto	No hay suficiente material para entregar por falta de tiempo	Muy baja	serias	Baja

Comentarios:

---

Tabla de planificación de riesgos

Nombre	Planificación
Capa de dispositivos heterogénea	Uso de una factoría para homogeneizar la API.
No llegar a dominar HAL	Investigar y comprobar si nos permite usarla para alguna funcionalidad de nuestra aplicación
No llegar a dominar Fuse	Investigación de esta herramienta y ver qué nos puede proporcionar
Problemas con FAT32	Informarse sobre los límites de los sistemas de archivos en general y ver en qué nos puede afectar
Falta de herramientas UML	Localizar herramientas que cubran, en teoría, ambas funcionalidades. Queda comprobar hasta qué punto lo hacen y familiarizarse con ellas.
Límites de Rdiff	Investigar el alcance de ese riesgo y actuar en consecuencia. Los desarrolladores de rdiff-backup parecen tenerlo solucionado
Rdiff-backup no cubre los casos de uso	Profundizar en la investigación y averiguar con certeza máxima su utilidad para nuestra aplicación. Cambiar a otro software o hacer que su wrapper supla la falta de características del mismo.
El wiki se cae	A. Utilizar un medio secundario para almacenar la documentación y realizar backups periódicos. Trabajar durante las caídas sobre medios alternativos que permitan edición concurrente como google docs. B. Migrar el contenido del wiki (perdiendo la historia y posiblemente el formato) a una solución albergada por el equipo. Conlleva coste de administración, pero podríamos replicarlo en varios servidores privados
No llegar a dominar Beagle	Estudiar su funcionamiento a fondo desde ahora. Alternativamente, no integrar búsquedas con contenido con nuestro proyecto.
Nos llevamos mal	Intentar cuidar las formas a la hora de relacionarnos. Realizar actividades comunes no académicas como ir de cañas.
Falta organización	Coordinarnos en subgrupos más manejables. Reparto de tareas más granular para poder subdividirse entre el número de personas. Establecer calendarios de trabajo.
El programa no funciona en los laboratorios	Tener en cuenta los recursos de los laboratorios a la hora de ir desarrollando; o bien se desarrolla contra esa base de código (nautilus, etc) ligeramente obsoleta, o bien será necesaria una fase de backporting de cambios y cierta planificación para evitar incompatibilidades severas.
No llegar a dominar inotify	Estudiar a fondo el funcionamiento de esta funcionalidad del kernel; posiblemente seguir ejemplos de proyectos diferentes que lo utilicen, como Rhythmbox
No llegar a dominar Glade	Estudiar a fondo el funcionamiento de esta utilidad. Alternativamente, codificar las interfaces a mano sin un editor de las mismas. Ralentizaría bastante el desarrollo de la interfaz.
No hay conexión a internet	Utilizar control de versiones distribuido que permite trabajar sin conexión (Bazaar). Generar la documentación offline en un solo ordenador, o utilizar herramientas de edición en red concurrentes. Cuando se recupere la conectividad, volcar de nuevo el contenido.
El repositorio se cae	Utilizar control de versiones distribuido que permite trabajo offline e intercambio de cambios sin depender de un servidor central.
Falta de tiempo	Intentar optimizar el tiempo disponible; separar el desarrollo en componentes lo más independientes posibles e intentar priorizar de más a menos crítico
Se corrompe un backup	Tener alguna copia actualizada en algún equipo
Ocupa demasiado espacio	Mantener un estudio del espacio que ocupa e intentar mejorarlo en el caso de que sea necesario. Buscar mejores codificadores de diferencias binarias (deltas).
Demasiado lento	Una vez funcione el programa, optimizarlo. Estudiar alternativas a nivel de sistema de ficheros como ZFS, y tenerlo en cuenta en el diseño de componentes para una posible futura adición. Buscar alternativas a rdiff-backup (o desarrollar nuestro gestor de snapshots). Minimizar la resolución de los disparadores como Inotify o Cron
Programa difícil de usar	Una vez haya una interfaz, trabajar con usuarios ajenos al proyecto y estudiar usabilidad sobre ellos.
Programa con funcionalidad insuficiente	Separar en componentes y priorizar el desarrollo de los mínimos y críticos para el éxito del proyecto, dejando la funcionalidad adicional a priori por implementar.
El programa no es fiable	Buscar la fiabilidad máxima desde el principio del desarrollo, usar suites de pruebas.
Nadie contrata almacenamiento	Prever que esta situación se puede dar, asumir los menos gastos de negocio posibles para reducir pérdidas.
Costes almacenamiento	Buscar un almacenamiento de coste asumible (servidores RAID de discos económicos), minimizar en lo posible el almacenamiento necesario, externalizar a backups en cinta (menor coste / GB) los datos poco usados por el cliente informándole de que recuperaciones de más de un cierto tiempo requerirán un cierto tiempo adicional.
Se cae el servidor de almacenamiento	Tener la máxima redundancia rentable y protocolos para evitarlo en lo posible, manteniendo la rentabilidad del modelo de negocio.
El equipo no rinde	Motivar para que todo salga adelante lo mejor posible, intentar optimizar el trabajo lo máximo posible
Parones temporales	Llevar el trabajo al día; prever entregas y parones y tener el trabajo preparado antes de exámenes.
Falta de material	Asegurarnos de que traemos siempre lo necesario
No nos aclaramos con launchpad	Estudiar a fondo el funcionamiento de este repositorio
Incompatibilidad de horarios	Trabajar con el que mayor grado de compatibilidad tenga, separar el trabajo en subgrupos y limitar las reuniones a los jefes de subgrupo para integración. Utilizar medios alternativos de comunicación (wiki, correo electrónico, mensajería instantánea) para no necesitar tanto reuniones en persona.
No dominar GTK	Estudiar a fondo esta tecnologia gráfica. Alternativamente, limitarnos a una interfaz de consola para el programa (lo que disminuiría su calidad notablemente).
No dominar nautilus	Estudiar el funcionamiento del explorador de Linux y las posibilidades de integración con el mismo a partir de proyectos diferentes. Alternativamente, renunciar a la integración y limitarse a una interfaz independiente de programa.
No dominar dbus	Estudiar el funcionamiento de dbus a partir de proyectos diferentes. Alternativamente, desarrollar otro método de comunicación entre el backend de almacenamiento y los diversos frontend gráficos posibles (nautilus, interfaz independiente, consola, etc).
El profesor suspende una entrega	Estudiar causas del fracaso e intentar corregirlas para realizar el desarrollo de la forma pedida
Problemas de personal	A priori se reparten las áreas de trabajo por competencias, pero intentando documentar lo máximo posible en el wiki sobre tecnologías concretas a fin de poder retomar el trabajo de un miembro que faltase si fuera necesario. Además, no se deja a nadie solo frente a un área concreta, y se adoptarán estándares de documentación de código para el mantenimiento que fuera necesario.
Integración con bazaar	Nadie sube a ninguna parte fuera de su grupo de trabajo, y de integrar se encargan personas determinadas. A tal fin se desarrollarán tutoriales de integración y guidelines de desarrollo específicos en python para facilitar la integración.
Problemas con inodos	Probar exhaustivamente y con casos extremos la aplicación.
No dominar sqlite	Buscar una alternativa, como MySql.
Arquitectura mal diseñada.	Revisar el proceso e insertar los cambios necesarios.
No dominar distutils	Buscar alternativa a esta tecnología.