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.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License