Planificación Iteración Enero

Tipo de iteración

Elaboración


Objetivos generales

Aprovechando que, pese a las fiestas, la iteración de Enero es la más larga (una semana extra) y que en vacaciones hay más tiempo en general, pretendemos llegar al primer prototipo funcional completo de la arquitectura y con ello cerrar la fase de elaboración. Este prototipo debe incluir las funcionalidades mínimas de guardar backups, recuperar backups y listar los presentes mediante un interfaz gráfica además de la de consola; posiblemente se incluya también borrar snapshots, importante para mitigar el impacto en uso de disco de nuestra aplicación.

Además pretendemos fijar con ello la arquitectura del sistema para poder desarrollar el resto de funcionalidades, así como poder repartir mejor el trabajo desde ese momento (ya que, fijadas las interfaces, es más sencillo repartir las clases).

Por último, y como parte del objetivo de desarrollar un interfaz útil, es necesario comenzar el manual de usuario.


Primer prototipo funcional

Para conseguir este objetivo concreto actuaremos en dos frentes: por un lado, concluir una interfaz de usuario funcional, y por el otro reducir al mínimo el riesgo del núcleo de la aplicación (los backups).

Solucionar el riesgo de rdiff-backup

En la iteración anterior se localizaron problemas en este sistema de almacenamiento que suponen un bloqueo para continuar completando la funcionalidad de la aplicación (ver Apéndice A del informe de investigación de snapshot core). Este riesgo es de máxima prioridad para nuestra aplicación y debe ser resuelto en esta iteración, bien completando de algún modo la funcionalidad que nos falta en rdiff-backup para usarla bajo la nuestra, o bien desarrollando nuestro propio sistema de snapshots (lo que aumentará el riesgo mientras se finaliza, así como el tiempo de desarrollo y de comprobación de errores, que debe ser exhaustiva).

Fijar la arquitectura del sistema

Con vistas a poder finalizar la fase de elaboración lo antes posible, intentaremos en esta iteración consensuar una arquitectura del sistema lo bastante sólida y flexible como para cubrir nuestros casos de uso, en base a las interacciones que describimos en el brainstorming y las consiguientes clases y sus interacciones. Será necesario actualizar los documentos de arquitectura existentes, así como describirla en UML. Contamos no obstante con que las necesidades del desarrollo obligarán probablemente a varias revisiones de la arquitectura, quizá prolongándose otra iteración más.

Además, crear un interfaz y probar su usabilidad nos obligará a definir con más detalle la estructura de clases del GUI, por ahora relegada a un segundo plano.

Como ejemplo de la necesidad de este trabajo, la funcionalidad deseada de la clase Watcher aún no está reunida, sino que está distribuida por otros módulos que aún no se ajustan a la arquitectura deseada (por facilidad del desarrollo del prototipo). Se busca en suma evitar este tipo de problemas, que a medio plazo nos pueden limitar mucho y dificultar el trabajo.

UML

Según lo explicado en clase se modelará la arquitectura de clases y sus interacciones mediante diagramas UML. Para ello es necesario familiarizarse con las herramientas, así como localizar aquellas que permitan un flujo de trabajo bidireccional entre código en python y diagramas, para poder reducir el tiempo invertido. Todo ello implicará crear nuevos documentos donde se aclare al equipo el funcionamiento de los programas, así como probablemente modificaciones a los procesos establecidos de trabajo y los estándares, para poder facilitar la integración de código posterior y mejorar el reparto de trabajo, uno de los problemas importantes que se detectaron en la anterior iteración.

Explicitar prioridades de casos de uso

Con vistas a conseguir el prototipo en el tiempo que tenemos, es necesario partir los casos de uso lo más posible en subtareas, y priorizarlas para buscar el camino crítico sin el cual no habrá prototipo alguno. Una vez se tenga explicitado, se debe priorizar el desarrollo de los componentes de ese camino crítico. La importancia de los casos de uso es algo medianamente consensuado en el equipo, pero que aún no ha sido explicitado. En una estimación previa, los componentes sin desarrollar y por investigar más importantes son:

Finalizar gestión de preferencias

La configuración del programa está en una fase avanzada de desarrollo, pero aún no es funcional y probablemente deberá sufrir rediseños en función de problemas de usabilidad que se detecten. Sin embargo, una interfaz mínima que funcione para configurar el programa es importante, y será lo primero que se termine por estar ya muy avanzado.

Tabla de historia

Es una tabla a donde se migra la información de los backups desde el journal (que a su vez es donde se anota qué operaciones hay que hacer cuanto antes, para poder planificarlas y reiniciar transacciones en caso de fallo). Esta tabla necesita información adicional, como dónde se encuentra un archivo (no necesariamente local), su propietario y otros atributos (tamaño, permisos, etc). Toda esa información adicional, que debemos aún concretar, no es crítica para el prototipo pero sí para la funcionalidad de exportar backups, sea a CD o a disco duro externo, por lo que el diseño debe tenerla en cuenta y merece la pena una implementación preliminar de la misma.

Comunicación frontend / backend

Por ahora backend y frontend han seguido desarrollos separados, solo integrándose parcialmente para la demostración de tecnologías de la iteración de diciembre. Es necesario desarrollar la comunicación entre los mismos y también el API, a fin de que ambos equipos de desarrollo puedan probar su código teniendo en mente las necesidades y posibilidades de la aplicación completa, además de que hace falta para completar el prototipo sobre la arquitectura deseada. Para esta parte se utilizará la tecnología dbus de comunicación interproceso, ya investigada parcialmente pero aún sin prototipo funcional; por tanto es también prioritario.

Interfaz de navegación de archivos

Dado que el GUI ya tiene una interfaz de preferencias casi funcional, el siguiente paso necesario para poder demostrar el programa es una interfaz que muestre los archivos con copia de seguridad y permita navegar entre ellos, así como restaurarlos. Ello requiere del anterior punto para usar el backend real y consensuar cómo comunicarse con él, así como de cierto tiempo de desarrollo para terminar de dominar los componentes del toolkit gráfico GTK.

Integración con nautilus

Una de los requisitos funcionales es que la aplicación sea usable para cualquiera, lo que requiere que esté integrada de modo transparente en el uso habitual del equipo. Para ello se decidió que integraríamos nuestro código con nautilus, el explorador de archivos de GNOME, mediante su API de plugins; no obstante la investigación preliminar ha demostrado que apenas hay documentación del mismo. Por ser menos prioritario, se relega el desarrollo de la integración a Febrero.

Integración con Beagle

Beagle permitiría buscar dentro del contenido almacenado en nuestros backups, facilitando mucho el uso del programa e integrándolo aún más. No obstante el riesgo de este desarrollo es mucho menor, requiere en potencia mucho más tiempo y además depende de finalizar el modelo de almacenamiento final de nuestra aplicación, por lo que también queda relegado indefinidamente hasta que se juzgue adecuado.

Tecnología HAL

La tecnología HAL permite detectar dispositivos conectados al equipo y podría ser potencialmente útil para facilitar el uso de un disco duro externo como almacenamiento. Su investigación también queda relegada a una fase posterior, una vez el prototipo permita esa funcionalidad de externalizar la copia de seguridad.

Estimar requisitos de tiempo y espacio de la aplicación

A petición del cliente, trataremos de realizar una estimación del espacio y tiempo que usará la aplicación, que posteriormente iremos refinando conforme se optimice y se concrete más el código.

Nueva documentación.

Algunos de los documentos por escribir que se consideran necesarios para el trabajo son:

  1. Guidelines de código en Python: de cara a la integración. Cómo probar el código, dónde colocar todo, etc.
  2. Manual de integración: una vez se termine de investigar el modo más eficaz de usar el control de versiones distribuido, se debe informar al equipo de cómo se usa para facilitar el trabajo y permitir mejor integración entre grupos separados de desarrolladores.
  3. Guidelines para errores: desde unas directrices sobre qué información generar para logs del programa, hasta una jerarquía de excepciones que usar consistentemente en todo el programa.
  4. Manual de uso de la aplicación.

Reparto de trabajo

Los objetivos de cada grupo son:

  • Documentación: Actualizar la arquitectura preliminar que tenemos según las Interacciones entre clases. Concretar la arquitectura del GUI y documentarla. En general, mantener el wiki actualizado según las exigencias de entregas de Gervás, y concluir la documentación deseada como objetivos. Ezequiel se responsabiliza, y Adrián ayudará como responsable de la integración en la iteración pasada. Además, de sobrar tiempo Ezequiel comenzará la investigación y el desarrollo de manuales sobre la integración de nautilus.
    • Manual de uso: Como depende del GUI lo escribirán ellos.
  • Watcher: Desarrollo de la clase Watcher e inicio del Planner. Adrián es el responsable y reparte trabajo.
    • Adrián: Concluir Watcher. Comienzos de Planner.
    • Diana: Terminar la funcionalidad de crontab y gestionar las peticiones de anacron. Ayudar en D-Bus Manager.
    • Jorge: Concluir funcionalidad de Inotify handler; refinar funcionalidad.
  • GUI: Carlos, Rober y Tabas. Responsable: Rober. Se ocuparán de concluir un GUI con la funcionalidad crítica desarrollada.
  • BBDD: David. Como previsiblemente habrá poco trabajo y es dinámico según le vayan necesitando, ayudará en documentación y en Snapshot manager.
  • D-Bus Manager: Atender a las necesidades del GUI y distribuir trabajo por el backend (previsiblemente a planner). Diana se responsabiliza.
    • Diana: representante de backend que conoce dónde está cada cosa, y esbozará la clase planner junto con Adrián para repartir trabajo por el backend (inicialmente sin lógica de planificación). Ayudada por Adrián en ello.
    • Rober / Tabas: Una vez investigado el modo de uso de dbus, enviarán las peticiones necesarias y recibirán datos del backend para poder presentarlos al usuario.
  • Snapshot: Salva, Fede, David y Mario hasta que se solucione el riesgo, el más importante actualmente. Responsable: Salva, quien asignará trabajo concreto.
    • Realizar estimaciones de tiempo y espacio del almacenamiento para la documentación.
  • Integración de código: Adrián realizó la integración pasada; una vez aclaremos los procesos Ezequiel y David ayudarán.

Estimaciones de tiempo

  • 31 diciembre (+/- 2 días): Terminado preferencias. Guidelines de integración; resueltos los procesos de tirar código ordenado y útil. Tomarse las uvas.
  • 7 enero: Dejar de jugar con los regalos de los reyes. Watcher. Investigación terminada de dbus con prototipos funcionales; clase dbus manager funcionando para poder hacerle peticiones. Prioridad de desarrollo de los casos de uso establecida (lo que condiciona y modifica el alcance); plan más detallado de desarrollo en el seguimiento.
  • 14 enero: Watcher integrado con inotify, cron. UML. Estimaciones tiempo y espacio. Toda la documentación complementaria salvo posiblemente manual de usuario sujeta a revisión del equipo.
  • 21 enero: Primera integración parcial para detectar problemas en el seguimiento de las guidelines y la arquitectura. Cierre parcial de código. GUI funcionando completo, a falta posiblemente de resolver errores puntuales. Finalizar los objetivos a falta de las previsibles correcciones de errores.
  • 25 enero, 14:00: Cierre total de código, comienzo de integración. Cierre de API obligatorio; bugfix únicamente a través de los integradores.
  • 31 enero: entrega.

Como condicionante importante, en Navidades no todo el mundo podrá trabajar: Salva no tiene ordenador y por tanto tiene dos semanas inhábiles, Ezequiel estará fuera una de las dos semanas y tiene bastante carga de trabajo de otras asignaturas, Mario estará fuera, y en general todo el mundo está ocupado con PLG y recuperándose de los excesos navideños, por lo que no serán dos semanas demasiado productivas. Por otra parte, al no tener horas lectivas ni laborales esto se compensará en gran medida y prevemos que cunda.


Seguimiento

Ver seguimiento-enero.

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