Planificación de la iteración de Diciembre

Tipo de iteración

Elaboración


Objetivos generales

Conseguir un primer prototipo que implemente funcionalidad real minima, si bien no creemos que vaya a dar tiempo.

Arquitectura

Diseñar una arquitectura que se aproxime lo más posible a la estabilidad, a falta de cubrir con ella los casos de uso que relegaremos a posteriores iteraciones por ser menos críticos. Para ello necesitaremos definir un API, una estructura de clases que nos permita el reparto de trabajo a partir de la arquitectura preliminar con que contamos, y definir la comunicación front-end y back-end cuanto antes.

Investigación II

Concluir la fase de investigación que sea necesaria para el prototipo, relegando a fases posteriores las tecnologías que se requieran para la funcionalidad menos crítica (servidor de almacenamiento, grabar a CD, integración con nautilus y beagle, etc).

Integración primer prototipo

Partiendo de la arquitectura definida, una vez exista el código mínimo para probar las funcionalidades dedicar el resto de la iteración a integrar, ya que por ser la primera vez previsiblemente llevará más tiempo y obligará a revisar los estándares de proyecto.


Reparto de trabajo

Se mantiene el de noviembre. Los objetivos de cada grupo son:

  • Control de calidad: Mario se encargará, colaborando con los responsables de grupo, de iniciar la integración desde el principio para que lleve menos tiempo una vez esté el código listo, además de sus responsabilidades habituales.
  • Gestión : Asegurarse de que los procesos de control funcionan; refinar iteraciones, reparto de trabajo, etc. Se encarga Eze, con posibles asistencias de terceros.
  • ui : configurar preferencias; manual de usuario inicial. Concluir investigación dbus, y resto de tecnologías necesarias. Tabas, Rober y Carlos.
    • interfaz consola: se encarga Fede, separándose del grupo de ui. Una interfaz básica de consola que llame directamente a las funciones más críticas del software para poder probarlo, y para investigar sobre el API que necesitaremos.
    • (nuevo!!) lógica de programa : recibir órdenes de usuario y repartirlas por los subsistemas. Colabora estrechamente con la interfaz de consola y el wrapper de rdiff, inicialmente. De momento va implícita en la interfaz de consola; es previsible que se añada más gente en cuanto concluyamos la arquitectura.
  • snapshot: un wrapper alrededor de rdiff-backup orientado hacia los casos de uso. Salva (responsable) y Dani.
  • watcher: un módulo que parsee la configuración y avise a los diversos subsistemas. Además, vigilar cambios en archivos con inotify. Adrián es el responsable.
    • Del parsing de fichero de configuración se encarga Adrián.
    • De la vigilancia de cambios en archivos se encarga Jorge.
    • Del pegamento en general entre submódulos se encarga Diana.
  • base de datos: reiniciar la investigación sobre sqlite, esta vez basado en python. Crear un journal para poder reiniciar en caso de parada el software.
    • El sql del journal está creado. De su revisión y prueba se encarga Adrián.

Estimaciones de tiempo

  • 11 de diciembre: fecha límite para tener el código dispuesto para integrar. Como hay un puente justo antes prevemos que la funcionalidad no estará completa para entonces; queremos probar la integración cuanto antes porque puede conllevar a cambios importantes en el código de los módulos que, de haber mucho volumen de código, podrían ser más dificultosas. Nos reuniremos para juntar el código ("dónde está cada cosa")
  • 18 de diciembre: fecha tope para terminar la integración
  • 20 de diciembre: entrega.

Seguimiento

Ver Seguimiento Diciembre

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