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. |
page revision: 44, last edited: 22 May 2008 10:57