Planificacion Iteración Febrero

Tipo de iteración

Elaboración


Objetivos generales

La iteración de Febrero, como estaba previsto en los riesgos de proyecto, no permitirá generar demasiados resultados debido a la presencia de exámenes en las tres cuartas partes del mes. Por tanto se dedicará a cerrar flecos que, por falta de tiempo, hayan quedado cerca de completar en la de Enero. Relegaremos a Marzo el conseguir un prototipo de funcionalidad crítica, así como reasignar recursos de personal, y revisar la viabilidad de los casos de uso, en concreto externalizar backups a medios como CD o discos duros externos, y la integración y usabilidad del interfaz. Además otro objetivo para Marzo será identificar claramente los patrones presentes en nuestro diseño y explicitarlos, y desarrollar los distintos diagramas UML por completo.

Completar módulos Watcher y clase ConfigFileManager

Estas clases son ya funcionales y solo falta terminar de documentarlas, añadir detalles como la detección automática de cambios a mano en el archivo de configuración, y en el caso del gestor de configuración cambiar los accesores genéricos por específicos para poder estandarizar el nombre y valores posibles de las opciones del programa, a fin de reducir los riesgos derivados de la no estandarización y de cubrir del todo la responsabilidad asignada a esta clase.

Unificar la jerarquía de excepciones del programa

En la misma línea del anterior objetivo, se buscará unificar la jerarquía de excepciones usada en el programa y documentarla, a fin de hacer HD Lorean más robusto y legible.

Migrar la información de depuración a la clase HDLogger

A fin de poder tener la información sobre el programa unificada en un único archivo de log y evitar tener que parsear salida por consola, lo cual no es viable para un demonio que debe correr en background, será necesario migrar toda la información de depuración que generemos para que utilice la nueva clase de logging. Ello debería ser sencillo, pero por el volumen de la base de código es probable que no se llegue a finalizar para Febrero. Unificar el logging permitirá, junto con las excepciones, automatizar los tests sobre la aplicación más fácilmente.

Concluir la integración de las bases de código

Si bien la integración se realizó durante la pasada iteración, queda sencillamente avisar a los distintos equipos de desarrollo del nuevo modelo de trabajo y migrar los repositorios para que todo el mundo trabaje con la base común de código. Será necesario por tanto actualizar la documentación de los procesos de trabajo para reflejar este nuevo hecho. Además se ha considerado deseable -de cara a facilitar las pruebas y el análisis sobre la aplicación- que dicha base de código común sea funcional como un proyecto de pydev (el plugin de desarrollo python para el IDE eclipse), trabajo que aún está pendiente de hacer.

Revisión de calidad de la documentación

El grueso del trabajo de revisión está centrado en los documentos de clases y su interacción de la iteración de Diciembre, pero por falta de un módulo no fue posible tener esta revisión lista para Enero. Se tratará de actualizar para esta iteración.

Decisión de la licencia final del código

Dado que utilizamos código diverso del mundo del software libre, habrá que investigar la licencia definitiva que podemos usar, que probablemente será GPLv2. Sería también conveniente configurar el entorno de desarrollo para que genere los nuevos archivos con una cabecera de licencia, y añadirla a los existentes (algo fácilmente automatizable).

Investigación sobre integración con nautilus y unit tests de python

A fin de poder desarrollar cuanto antes el análisis de viabilidad de Marzo, se intentará investigar en la última semana de febrero sobre las posibilidades prácticas de la integración con el navegador de archivos de Gnome. Asímismo se comenzará la investigación y documentación sobre la funcionalidad de unit test que ofrece python, con vistas a automatizar esos tests cada noche del mismo modo que está automatizada la generación de documentación.


Reparto de trabajo

Al no haber objetivos nuevos se mantiene el reparto de trabajo de la anterior iteración, con vistas a renovarlo y realizar movimientos de personal en la siguiente iteración de Marzo, probablemente reasignando responsables de grupo. Es probable que sean necesarias ayudas de todo el equipo con la documentación, ya que forma el grueso de los objetivos para Febrero y es responsabilidad de una única persona.


Estimaciones de tiempo

  • 12 de febrero: Proyecto pydev listo sobre la base común de código .
  • 25 de febrero: Todos hemos concluido exámenes. Iniciar preparación de la entrega, que debe consistir sobre todo en documentación y la planificación para Marzo.
  • 29 de febrero: Entrega

Seguimiento

Ver seguimiento-febrero

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