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