Planificacion Iteración Marzo

Tipo de iteración

Construcción


Objetivos generales

Pasados los exámenes, la iteración de Marzo se centrará en conseguir de una vez por todas una beta funcional del programa. Dado el imprevisto de la entrega y testeo con usuario real antes de Semana Santa, estructuraremos la iteración en dos partes; la primera, concluir la solución de los problemas pendientes de la aplicación y desarrollar lo que queda del GUI para poder demostrar la aplicación, y la segunda, una vez realizada la prueba del programa, solventar lo que descubramos en dicha prueba (bugs, problemas de usabilidad, etc) y mejorar la calidad de la aplicación y de la documentación con ello.

Concluir el GUI

Actualmente el GUI tiene una gestión de preferencias extensiva, si bien puede recibir bastantes mejoras de usabilidad y calidad. Para poder demostrar la aplicación necesitaremos algún interfaz para mostrar toda la información que se tiene almacenada -junto con otros datos como cuándo se guardó, y cuánto ocupa- y poder extraer snapshots, borrarlos, etc. Ello implica, además del riesgo de desarrollo propio por no estar aún empezado, problemas adicionales en la comunicación con el backend, ya que necesitamos un método de refresco de dicha información para evitar hacer polling -costoso y poco elegante, tanto en código como de cara al usuario-, lo que requiere de una ruta de información adicional inversa a la que teníamos y que vaya desde backend a frontend.

Asimismo, será interesante explorar alguna posibilidad de presentar ese feedback al usuario sin tener la aplicación principal en ejecución, como un icono de la barra de tareas, o popups de información avisando de problemas, o de la conclusión de alguna operación larga, lo cual podría incluso requerir de un pequeño demonio de usuario adicional para evitar hacer dependiente el backend de ningún tipo de interfaz gráfica, o en su defecto de funcionalidad añadida en el GUI que permita minimizarse a la barra de tareas.

La interfaz plenamente usable de la barra de tiempo queda relegada al siguiente mes a sabiendas de la escasez de tiempo, ya que se está investigando actualmente sobre la integración con nautilus y para reutilizar trabajo sería conveniente que, tanto desde nautilus como desde la aplicación, el código de visualización fuera el mismo. En cualquier caso se juzga útil y sencillo de usar tener dos tipos de vista, una con "todos" los backups, y otra relacionándolos directamente con su ubicación en el sistema de ficheros, para que sea como explorar el disco del modo habitual. Se comenzará en cualquier caso su desarrollo durante la segunda mitad de esta iteración, para anticipar posibles problemas.

Concluir el backend de creación de backups

Concluido el desarrollo aceleradamente del mismo, queda integrarlo con la aplicación, definir del todo sus API, testearlo y documentarlo convenientemente. A sabiendas de su importancia, es la prioridad máxima, junto al interfaz que permita su demostración, en nuestro desarrollo.

Nueva organización de trabajo

El segundo cuatrimestre ha cambiado los horarios de todo el grupo, y por tanto debemos encontrar un nuevo horario de reunión.

Abstraer dbus en el backend y frontend.

Dado que la aplicación era meramente un prototipo y la comunicación entre procesos aún estaba en pruebas, el código tiene la funcionalidad referente a dicha comunicación repartido en todas las funciones que lo necesitan. Se abstraerá dicha funcionalidad a clases independientes que se encarguen de dicha comunicación y actúen como proxys, para facilitar la depuración, separar en responsabilidades las clases y reducir problemas de refactorización.

Consola de la aplicación

Inicialmente creada para un prototipo, se ha recuperado su desarrollo y se tendrá una versión ejecutable en consola de la aplicación de funcionalidad completa, que además de ayudar con la automatización de las pruebas permitirá cubrir historias de uso (ejemplo: restaurar la configuración de xorg).

API de las bases de datos

Actualmente, y por flexibilidad en el desarrollo, usamos unas funciones bastante genéricas para el acceso a las bases de datos de la aplicación. Una vez van estando concluidos los módulos que las usan, queda cerrar esos subsistemas concretando en funciones específicas esos accesos, para conseguir la independencia real de la base de datos.

Testing

Durante la segunda mitad del mes, se deberá decidir la política sobre unidades de pruebas que seguiremos, documentarla y en su caso implementarla.

Documentación

Se deberá concluir de documentar los cambios en los procesos (testing, integración, entorno de desarrollo pydev), así como el UML y todo lo referente a patrones de diseño. Se realizará durante la segunda mitad del mes, pasada la entrega, y para el UML y los patrones de diseño se intentará contar con el equipo entero por considerarse imposible de otro modo y ser además importante para el examen de la asignatura.

Codetón

Hemos establecido una fecha para reunirnos en casa de uno de los miembros del equipo durante todo un fin de semana y avanzar el desarrollo. Pese al riesgo de baja productividad de no estar programando solos, se considera que será provechoso por la presión de la fecha de entrega, de estar todo el grupo juntos (donde quien trabaje presionará a quien no lo haga), y sobre todo por la facilidad de intercomunicación entre distintos grupos de trabajo para solucionar problemas referentes a la comunicación entre partes distintas del código. A tal fin se deberá tener el código "interno a cada parte" listo para entonces, y se empleará la mayor parte del tiempo en integración.

Despliegue del software

Dado el importante handicap de última hora de que no se pueda instalar software en linux en los laboratorios para nuestro proyecto, hemos de buscar formas de despliegue alternativas. Varias posibilidades están en trámite, entre ellas utilizar nuestros portátiles para ello, y combinarlo con uso de las X en remoto a través de la red de la complutense hacia equipos situados en otra parte, permitiendo ejecutar la aplicación "en remoto" albergada en terceros sistemas - a los que Adrián y Ezequiel pueden conseguir acceso- lo bastante grandes como para permitir varios usuarios a la vez operando.


Reparto de trabajo

Dado que una parte de la aplicación está concluida (watcher y las bases de datos) se reasignará el personal de ese grupo para apoyar en el resto. El nuevo reparto de personal queda como sigue:

  • Interfaz de usuario: Daniel Tabas, Rober y Carlos, a los que se unen en principio Adrián y Diana. Asume la responsabilidad del grupo Adrián.
    • Tabas acaba la comunicación backend / frontend, por ser el más experimentado trabajando con dbus, y la ruta de feedback que está por desarrollar, incluyendo posiblemente la investigación sobre systray y popups con libnotify.
    • Mario se encarga de la consola, ya está trabajando en ello.
  • Backend : se une Jorge como mercenario y sale Mario. Responsable sigue siendo Salva.
  • Bases de datos: sigue al mando David, que deberá implementar a petición, ayudar con el testeo del backend (en lo tocante a inicializar esas bases de datos para su prueba) y cerrar lo antes posible el API de las mismas, documentándolo en el proceso.
  • Documentación: Adrián y Ezequiel, ayudados por Salva cuando proceda. El UML lo haremos entre todos, cada uno ocupándose de su parte.
  • Preparación de la entrega: A priori, Adrián y Ezequiel, que intentarán preparar la entrega (el despliegue).

Estimaciones de tiempo

  • 5 de marzo: cierre parcial de código de cara a la codetón. Solamente minimizar lo que queda por hacer interno a cada módulo, y solucionar los problemas de la última integración.
  • 8 de marzo: decisión sobre la integración con Nautilus.
  • 7 de marzo al 9 de marzo: Codetón. Para poder dedicarnos plenamente a solucionar problemas de la comunicación entre partes del código, así como dependencias entre las mismas.
  • 11 de marzo: cierre parcial de código. Solo bugfixes críticos a trunk, el resto en cada rama de desarrollo.
  • 13 de marzo: Entrega en laboratorio.
  • 14 de marzo al 23 de marzo: Semana Santa (aprox). A falta de reunirnos, aún no está establecido quién podrá trabajar durante esa semana, y probablemente será complicado reunirnos durante ella. No obstante se planificará trabajo recién entregado.
  • lunes 24 de marzo: Nuevo cierre parcial de código, depuración, integración de todas las ramas de desarrollo. Documento de clases actualizado y UML de todos los equipos entregado.
  • 27 ó 28 de marzo: Entrega final.

Seguimiento

Ver seguimiento-marzo

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