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: 25, last edited: 22 May 2008 11:39