Seguimiento Febrero
Objetivos cumplidos
Núcleo de la aplicación terminado

La funcionalidad crítica de crear y recuperar backups está finalizada. Aunque no era un objetivo fijado para el mes, gracias a un notable esfuerzo por parte del desarrollador principal durante la última semana ya está desarrollado el código para crear y recuperar snapshots. Lo que queda por delante, en esencia, será ampliar la funcionalidad para cubrir el máximo de casos de uso (pues por ahora solo cubre lo esencial), así como conectarlo con el resto de la aplicación definiendo ya de un modo fijo las API internas, y naturalmente un testeo intensivo de esta parte de la aplicación.

Investigación unit tests

La investigación sobre unidades de prueba está finalizada, con un tutorial aquí. Queda decidir los procedimientos sobre el mismo, así como automatizar el testeo una vez se tengan disponibles las pruebas en un servidor para que se realice todas las noches, lo cual se estima trivial.

Investigación nautilus

Durante exámenes un miembro del grupo ha realizado la investigación sobre la arquitectura interna de nautilus y sus posibilidades de extensión, mediante estudio de la documentación disponible y contacto con los desarrolladores mediante correo electrónico. La conclusión es que resultaría notablemente más difícil de lo estimado, al no tener ninguna documentación sobre código ni estar realmente preparado para ello con interfaces externas. Si bien hay bastantes sitios donde integrarse con el mismo (propiedades de un archivo, menús contextuales…) para realizar una vista nueva que incluyese la funcionalidad de la barra de tiempo hay que reimplementar, en C, y prácticamente desde cero sin documentación. No obstante lo dicho, se intentará durante la primera semana confirmar la dificultad del desarrollo, dado que es una parte que aportaría gran calidad y usabilidad a la aplicación.

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

La adaptación del equipo al nuevo esquema de trabajo en el launchpad ha sido sorprendentemente rápida y efectiva. Todos los equipos están trabajando ya sobre la base de código común, y por tanto la integración de trabajo entre grupos es en esencia trivial y no es obligatorio esperar a cada mes para ello, si bien pueda ser recomendable en algunos casos. Además disponemos de la ventaja del control de versiones que proporciona historial extensivo e independiente para cada cambio realizado por cada grupo, lo que en potencia facilitará mucho el depurado y testeo de regresión al poder localizar enseguida cualquier cambio introducido que haga fallar a la aplicación.

Concluir la gestión de archivo de configuración

La clase ConfigFileManager está finalizada y el formato del archivo de configuración definido, junto a funciones get y set auxiliares adicionales. Ello reduce las decisiones a tomar y los posibles malentendidos, al haber un api al que ceñirse.

Objetivos no alcanzados
Completar módulos planificados

Los módulos que se debían completar (watcher y dbus) aún están faltos de pequeños retoques, en algunos casos por peticiones de última hora como en el de dbus (para conseguir una ruta de feedback desde el backend hacia la aplicación). Se estima que lo que queda es mínimo.

Unificar la jerarquía de excepciones del programa

Por falta de tiempo durante exámenes aún no está documentado este paso, si bien existen jerarquías parciales de excepciones.

Migrar la información de depuración a la clase HDLogger
Revisión de calidad de la documentación
Decisión sobre la licencia final del código

Haber utilizado código ajeno (pequeños snippets de ejemplo, principalmente) nos obliga a ceñirnos a la licencia de dicho código. En principio es LGPL, pero se adoptará la GPLv2 por comodidad. Falta simplemente consensuar entre todo el equipo esto, así como modificar los archivos para añadirles la licencia, y posiblemente modificar el entorno de desarrollo para que añada esa cabecera automáticamente.

Riesgos reducidos
  • El riesgo más importante de la aplicación está solucionado, a falta de integrar y testear. Ello nos da un respiro al plan de fase, permitiéndonos probar durante más tiempo la aplicación y en potencia cubrir más casos de uso.
  • El riesgo de integración de bases de código está solucionado sin apenas problemas, que se estimaba de importancia crucial.
  • Riesgos de personal que se habían detectado, independientes de la falta de tiempo, están mitigados y planificados convenientemente.
  • Dos grandes subsistemas de la aplicación (Watcher y SnapshotManager) están muy avanzados (en el primer caso está concluido totalmente, a falta de pequeños problemas que se van detectando y de optimizaciones que se pudieran aplicar). Ello reduce bastante el impacto del riesgo de falta de personal, y además los problemas de intercomunicación, ya que solo quedan dos grandes equipos (backend, concretamente gestión de backups, y frontend dedicados al GUI, estando solucionado casi todo el código intermedio de comunicaciones y gestión de la base de datos).
Nuevos riesgos
  • Otro miembro del equipo ha encontrado trabajo, lo que hace un total de 4 los que están simultaneando trabajo y estudios, más del 25% del equipo. Esto reduce en mucho el ya de por sí pequeño equipo de desarrolladores y aumenta el riesgo de no lograr completar el desarrollo a tiempo.
  • Relacionado con este problema de personal, aún desconocemos el esfuerzo que requerirán las asignaturas de carácter práctico del segundo cuatrimestre para los miembros del equipo. Cabe suponer que, como es habitual, el segundo cuatrimestre sea más intenso en este ámbito que el primero, lo que reducirá aún más el tiempo disponible.
  • El fin de exámenes ha traído notable desorganización al grupo, al no tener el día fijo común para reunirnos. Esto crea un riesgo muy importante de no lograr los objetivos de la primera entrega de Marzo, para la que de por sí hay muy poco tiempo.
  • La sorpresa de la entrega de Marzo, unida al retraso en los grupos de GUI y backend, hace un riesgo de consecuencias severas e importancia altísima el de no poder cumplir ese plazo. Desde el equipo se achaca a avisar con solo un mes y medio de antelación, con los exámenes de por medio.
  • La negativa por parte del equipo técnico a instalar software en los laboratorios nos va a dificultar notablemente el despliegue y testeo de la aplicación, así como hará imposible su instalación en dichos pc's debido a las dependencias lógicas del software que desarrollamos, que intenta reutilizar el máximo de componentes externos posibles. Por nuestra parte consideramos imposible dicho objetivo (desplegar sobre unos equipos que no admiten ningún cambio en la aplicación), y trataremos de llegar a soluciones de compromiso mucho menos que ideales (equipos personales, accesos remotos).
  • La fecha avanza y se agota el tiempo para testeo, mantenimiento y demás.
Tiempo real empleado

Muy poco, al estar de exámenes todo el equipo. El lead developer ha sido quien más trabajo útil ha sacado, dedicando por completo la última semana a finalizar su módulo.

Conclusiones

Como se previo la iteración de Febrero ha sido improductiva, pero nos ha cogido por sorpresa la desorganización del fin de exámenes y los nuevos horarios del segundo cuatrimestre, haciendo que durante la última -y crítica- semana de Febrero no nos hayamos reunido y nos hayamos comunicado mucho peor por ello. No obstante lo dicho, el trabajo de última hora ha salvado la iteración y nos permite un respiro para Marzo, a sabiendas de que, al margen de terminar el interfaz gráfico, lo que queda sobre todo es comunicar módulos, y depurar. Todo el equipo está mentalizado para la importante entrega de Marzo y ya se ha retomado el ritmo de trabajo, en especial ahora que las prácticas de terceras asignaturas aún nos permiten un pequeño respiro.

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