Seguimiento Enero
Objetivos cumplidos
Integración de bases de código

Si bien el código del equipo de desarrollo del formato de snapshots no ha podido llegar a tiempo a la integración, las distintas bases de código ya están juntas en una única, de la que los distintos equipos harán branches independientes para trabajar en adelante. Para el equipo de desarrolladores trabajar sobre ramas de desarrollo separadas, y únicamente permitir acceso a los integradores en la rama conjunta y "de entregas" del código nos permitirá mucho más control de calidad que trabajar sobre un único repositorio, sin aumentar los riesgos derivados de ello ya que sí son posibles integraciones de código parciales entre código de los equipos, y todo el mundo tiene una versión razonablemente actualizada del código de los demás para poder probar. Además tener la aplicación completa permitirá una mayor visión de conjunto a todo el mundo de la función de sus respectivos subsistemas en el global de la aplicación.

Módulo Watcher

El módulo Watcher, a falta de retoques finales- como que se detecten automáticamente cambios hechos a mano en la configuración-, está finalizado. La lógica de planificación por ahora no existe por no ser crítica y depender de pruebas en condiciones reales, pero todo el código está listo para que pase por el planificador y por tanto es factible no realizar backups si no se está conectado a la corriente, o si la carga de CPU o E/S es demasiado alta. Ello permitirá reasignar a sus componentes de personal a grupos más necesitados de personal.

Wrapper base de datos

Los componentes dependientes de una tecnología concreta han sido abstraidos a un módulo wrapper que encapsula y abstrae los lenguajes propios de sqlite al resto de la aplicación. Esto, con poco coste de desarrollo y sobrecarga, nos permite reducir al mínimo el riesgo de que sqlite no de la talla para nuestros requisitos, facilitándonos un futuro cambio de tecnología de base de datos que durante el desarrollo se temió (sin llegar a confirmarse) necesario. Quedan por fijar las consultas finales que se harán desde las distintas tablas a la base de datos, que no están fijadas aún en código por no saberse fijas, pero que también irán en sitios concretos y abstraerán la funcionalidad que proporcionan las bases de datos del código SQL necesario para las mismas.

Especificación del formato de backups

Tras un importante esfuerzo de desarrollo se ha completado una especificación del formato de snapshots que esperamos sea lo bastante completa para el resto del trabajo que queda por hacer. Se adjunta al final de la entrega de Enero.

Tabla de historia

La tabla de historia, donde se guarda toda la información de los snapshots que almacena el sistema y donde se diseñaron las operaciones más críticas, está diseñada e implementada en los diversos módulos.

Comunicación frontend / backend

Con mayores dificultades de las previstas en el desarrollo, dbus ha cumplido su cometido y nos permitirá separar la aplicación en un demonio que corra siempre y un gui. Quedan por limar detalles de la implementación (como que si se lanza el gui sin un demonio corriendo arranque al demonio), pero el problema ha quedado solventado. Ello además conlleva modificaciones del diseño UML, ya que el propio sistema dbus actúa como proxy y elimina la funcionalidad del módulo DbusManager.

Cron

Un módulo sencillo que ha complicado el desarrollo del watcher por problemas con su nula integración con dbus para poder pasar mensajes al backend de la aplicación. Su desarrollo completo (incluyendo funcionalidad de realizar las tareas pendientes si el equipo estaba apagado) permite en adelante una planificación adecuada de backups, con funcionalidad como p.e. generar backups integrales por seguridad cada mes con la que se contaba en la planificación inicial de requisitos de HD Lorean.

Requisitos tiempo y espacio

Se han realizado las estimaciones pedidas de tiempo y espacio de la aplicación, que se adjuntan en la entrega de documentación de Enero.

Generación automática de documentación

Un script en la máquina de un miembro del equipo permitirá que, cada noche, se genere automáticamente la documentación de todos los módulos de HD Lorean, lo que sin duda facilitará el desarrollo y la comunicación entre equipos. Dicha documentación se encuentra en http://www.hdlorean.com .

Revisión de calidad de la documentación

Aunque aún no se encuentre finalizada, se ha efectuado una revisión en profundidad de los documentos de clases e interacciones de clases que se generaron la anterior iteración, y todos los problemas detectados se corregirán tan pronto como se terminen de concretar las clases que finalmente quedarán en el proyecto.

Objetivos no alcanzados
Reducir el riesgo del núcleo de la aplicación

El riesgo de rdiff-backup se ha mostrado crítico, tal y como se previo en la planificación del mismo. Finalmente dicha aplicación no cubre ni nuestros casos de uso (en particular borrados), ni nuestras restricciones informales de tiempo y espacio. La dificultad ha venido de que estos problemas no aparecieron en la fase de investigación debido a pruebas insuficientes para revelarlos, lo cual, junto a otra serie de problemas que se mencionan en "nuevos riesgos", ha impedido lograr los principales objetivos planificados para esta iteración y obligarán a modificar notablemente el plan de fase, y probablemente el alcance previsto de HD Lorean.

Primer prototipo funcional

Al no tener un módulo funcionando que hiciera los snapshots, nuestro siguiente prototipo es incompleto y solo se ha podido desarrollar funcionalidad periférica.

Interfaz de navegación de archivos

Los citados problemas de comunicación entre equipos, unidos al retraso del grupo encargado de los snapshots y a una dificultad imprevista para el grupo de GUI en desarrollar una interfaz más allá de las posibilidades del diseñador de interfaces Glade han paralizado casi por completo el desarrollo de la interfaz. Al no haber snapshots funcionando aún, no estaba claro qué se debía mostrar, y al no poder desarrollar tampoco la interfaz a tiempo el resultado ha sido no tener un API claro con los datos que tiene -o tendrá- el sistema de backups almacenados dentro.

Fijar la arquitectura del sistema.

Pese a que la arquitectura preliminar se ha mostrado bastante acertada, aún quedan flecos por concretar en los módulos por terminar, y APIs por definir entre módulos como la citada en el apartado anterior sobre información de un snapshot. Dichas APIs habrán de esperar para ser estables a que el núcleo de la aplicación esté concluido y funcionando, pero se está trabajando en aproximaciones cuanto antes a ellas.

UML

Tras cerca de dos semanas de investigación, se ha concluido que, debido a las características altamente dinámicas de python como lenguaje (reescritura de los diccionarios de funciones de las clases, por poner un ejemplo), no existen -o no se han logrado localizar- herramientas libres y de calidad que generen automáticamente ningún tipo de diagrama UML lo suficientemente completo y útil a partir del código existente. Ello ha ralentizado y frenará en el futuro el crear documentación en este lenguaje, ya que ha de ser mantenida a mano por cada equipo de desarrollo y está muy desacoplado del código fuente. A falta de investigar algunas alternativas de última hora que se han localizado, el UML se está generando a mano mediante la herramienta umbrello, que permite crear todos los tipos de diagramas necesarios; no obstante nos limitaremos a una descripción lo más de alto nivel posible (algo menos que subsistema, pero sin llegar a *todas* las clases necesarias) para que nos sea útil sin dificultar el trabajo.

Un ejemplo del trabajo realizado son las siguientes dos instantáneas:

Diagrama de clases
Diagrama de clases

Diagrama de interacción (parcial) para el caso de uso 2: Añadir nueva carpeta a indexar

Diagrama de interacción para el caso de uso 2
Fijar prioridades de los casos de uso

Por falta de tiempo no se ha realizado de un modo formal y consensuado, quedando implícito que la funcionalidad prioritaria es realizar y restaurar un snapshot, así como borrarlos para poder mitigar el impacto en espacio de la aplicación, que se preve el más crítico. Queda por tanto pendiente.

Investigación tecnologías (beagle, nautilus, HAL)

La falta de tiempo general ha provocado que haya sido imposible la investigación de tecnologías adicionales. Exceptuando nautilus, que se considera mucho más deseable de cara a la usabilidad de la aplicación, es probable que el resto queden fuera de alcance en la revisión que se haga del mismo en la próxima iteración.

Documentación adicional

De la documentación adicional faltan aún las guidelines de python y las de integración, aunque sobre python ya hemos concretado aspectos importantes como por ejemplo cómo guardar registros de errores / debug. Se han retrasado por problemas de incomunicación durante el periodo estival entre responsables, y se ha decidido esperar a concluir la integración en una sola base de código para simplificar la tarea a todos los miembros del grupo.

Riesgos reducidos
Sqlite

Al disponer de un wrapper según el diseño de la arquitectura, ya no dependemos tanto de esa tecnología específica y sería más sencillo cambiar a otra más potente como mysql.

Rdiff-backup

Al no usar esta tecnología, tras haber mostrado sus consecuencias su riesgo desaparece.

Problemas de definición de la arquitectura

La arquitectura diseñada parece responder a las necesidades de la aplicación correctamente, lo cual ha sido un éxito de diseño conseguido gracias a la interacción de clases con tarjetas CRC. En general el equipo es más consciente de la misma.

Investigación instalador

Se ha investigado la tecnología de instalación de python (distutils), lo que ha contruibuido a la viabilidad de integrar todas las distintas bases de código en una y facilitará el proceso de despliegue hacia el final del proyecto.

Integración de código (buscar por "bazaar").

Ya está claro y probado cómo se realizará la integración del código de los distintos equipos, y solo queda generar la documentación pertinente.

Demonio y frontend corriendo independientementes

El riesgo tecnológico que presentaba dbus como tecnología de interconexión está controlado y resuelto; ya tenemos la aplicación separada en demonio y frontend.

Nuevos riesgos

Aumenta: no lograr cubrir los casos de uso requeridos por la aplicación, por las nuevas dificultades de desarrollo en el backend. Ya no tenemos el colchón de seguridad que proporcionaba basarnos en una aplicación ya probada.
Aumenta: no lograr que HD Lorean sea lo bastante intuitivo y transparente al usuario, por falta de tiempo en el desarrollo que haga imposible lograr suficiente integración con el escritorio.
Nuevo riesgo tecnológico: por las tentativas que hay de formato de backups se ha detectado que usa un gran número de archivos. El número de inodos posibles en un sistema de ficheros está limitado, y si no se tiene cuidado podemos toparnos con él.
Aumenta: Falta de tiempo; el segundo cuatrimestre dos miembros del equipo se han incorporado a sendos trabajos, y además hay una optativa con prácticas que muchos de nosotros cursaremos que nos robará aún más tiempo.

Tiempo real empleado

Menor del deseable y planificado, ya que la planificación para las navidades no era realista y casi nadie ha sacado el tiempo necesario.

Conclusiones

Esta iteración ha resultado poco exitosa por la unión de varios factores. El principal problema que hemos debido afrontar ha sido el riesgo tecnológico de rdiff-backup, tecnología que no supimos detectar a tiempo que no era suficiente para nuestros propósitos porque nuestras pruebas fueron demasiado reducidas en ámbito; sencillamente no ha habido suficiente tiempo para finalizar el desarrollo de una tecnología nueva de snapshot desde cero. Por otra parte, en general todos hemos trabajado sensiblemente menos de lo planificado, lo cual nos servirá para futuras estimaciones de tiempo en presencia de otras fiestas de guardar. Además ha habido problemas importantes de comunicación entre equipos, y entre miembros de equipos, que han parado completamente el desarrollo durante las vacaciones; no se han sabido resolver los interbloqueos con propuestas de compromiso de API, lo cual ha detenido mucho al grupo de GUI, que por otra parte se ha encontrado en su desarrollo con más problemas de los esperados al comenzar con la funcionalidad más compleja del mismo. Asimismo, la sensación general ha sido de moderado desánimo, provocado por el cansancio, por haber encontrado las primeras dificultades de cierta envergadura en el desarrollo, y también en parte por una falta de delimitación de tareas claras que en ocasiones dejaba a la gente desocupada, esperando instrucciones sobre qué hacer que se creían entendidas.

Para solucionar estos problemas, en Marzo haremos una revisión profunda de procesos de desarrollo y reasignaremos al personal de Watcher, para mejorar esos problemas de comunicación y centrar los esfuerzos de programación en las zonas más necesitadas. Intentaremos recuperar el máximo posible del tiempo gastado de la planificación de fase original, para conseguir completar el máximo de funcionalidad posible. En cuanto al reparto de tareas, se espera que teniendo el código unificado sea más claro quién tiene que hacer qué y en qué momento, a lo que también contribuirán los movimientos de responsables en el personal.

Además será necesario reevaluar en profundidad las planificaciones, lo que probablemente obligará a reducir el alcance de la aplicación y la viabilidad del desarrollo de algunos de sus casos de uso.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License