Seguimiento

Aquí centralizamos el seguimiento cada iteración, del plan de fase, de la documentación, etc.

Plan de fase

A lo largo del desarrollo de la aplicación nos hemos encontrado con diversos problemas que podrían haber modificado el plan de fase original, pero por suerte solo uno de ellos nos obligó a ello. Incluso la incorporación de un nuevo miembro al equipo ha podido ser asimilada sin mayores dificultades.

En Enero, tras una iteración muy poco productiva debido a las vacaciones y también debido a los problemas encontrados con rdiff, la planificación de fase sufrió una modificación que introdujo un retraso en la entrega del primer prototipo Beta de Enero a Marzo.

Esto produjo un reajuste de la iteración de Enero que se convirtió en una de investigación de nuevas tecnologías que pudieran sustituir a la descartada. Además la iteración de Febrero se vio ligeramente modificada, aunque mantuvo el objetivo principal de investigación sobre nuevas funcionalidades.

Además, la iteración de Abril se vio afectada pasando a ser el objetivo principal la entrega de una segunda beta cuando estaba programado empezar con el mantenimiento y hacer pruebas de usabilidad con usuarios reales. Ello quedó atrasado para Mayo junto con lo que ya tenía asignada esa iteración.


Seguimiento de las iteraciones

Aquí comprobamos objetivos cumplidos y fallados del plan de iteración, y establecemos medidas correctoras al respecto.


Noviembre

Objetivos cumplidos

La investigación ha alcanzado un gran nivel de éxito, ya que se ha encontrado un módulo escrito en python que resuelve gran parte del problema del almacenamiento y gestión de instantáneas, sobradamente probado. Asimismo la documentación ha ganado en calidad mucho, y es bastante extensiva.

En cuanto a la organización del modelo de desarrollo, a falta de probar la integración de módulos diversos de momento es un éxito, ya que el personal se ha adaptado relativamente rápido al control de versiones.

Objetivos no alcanzados

La investigación ha llevado a cambiar de lenguaje de programación usado, lo que obliga a posteriores fases de investigación para familiarizarnos con el mismo; hubiera sido deseable concluir ya la investigación. Las estimaciones de requisitos no funcionales no ha dado tiempo a hacerlas, ya que la investigación ha cambiado bastante la orientación de la práctica.

Riesgos reducidos

Buena parte de los tecnológicos; confirmamos que las tecnologías responden a lo que necesitamos de ellas, y no encontramos ningún escenario de uso que no quede cubierto por ellas.

Nuevos riesgos

Usar un nuevo lenguaje de programación como python, con el que no tenemos familiaridad ninguno.

Tiempo real empleado

Al no haber una planificación previa esta sección es irrelevante, pero informalmente se pretendía tener lista la investigación de las tecnologías repartidas para diciembre, y se ha conseguido.

Conclusiones

La iteración ha resultado exitosa ya que ha reducido mucho los riesgos de proyecto, al encontrar una tecnología que reduce mucho los tiempos de desarrollo y cubre funcionalidad. Se han cumplido plazos (informales).


Diciembre

Objetivos cumplidos

En la iteración se han logrado dos prototipos. Por una parte, una GUI funcional que permite editar las preferencias (aunque aún no leerlas), además de mostrar una ventana de log en el menú View para comprobar que se monitorizan la creación, borrado y modificación de los archivos o carpetas configurados.

Por otra, se ha diseñado una aplicación que, mediante consola, permite realizar backups, listarlos y recuperarlos. Cuando se realiza un backup de algo que no estaba en las preferencias la aplicación añade dicha carpeta a las mismas.

Durante la integración hemos trabajado sobre los problemas de arquitectura y organización de código que deberemos utilizar, lo que nos resultará útil para futuras integraciones. El brainstorming ha ayudado a definir la arquitectura respecto a nuestras estimaciones iniciales, ayudando a tener en mente algunos casos de uso (como Exportar a disco externo importantes que hemos relegado para fases posteriores del desarrollo. Este caso y su simétrico, importar, cubren la importante funcionalidad de poder recuperarse después de un fallo catastrófico (formateo), o de un cambio de equipo, siempre que se conserven copias de seguridad.

La investigación en esta iteración se ha centrado en:

Python

Todos los equipos de desarrollo han debido familiarizarse con el nuevo entorno y bibliotecas; el nuevo lenguaje de programación no ha traído demasiados problemas. Se han puesto de manifiesto algunas carencias en la documentación interna (tutoriales) que deberán ser solventadas; no era posible detectarlo hasta que se realizaran las primeras integraciones y se probara un poco más el lenguaje.

Rdiff-backup

Por decisión común se decidió en la anterior iteración utilizar la aplicación rdiff-backup como medio de gestión de snapshots. Así, el desarrollo se limitaba al diseño de una API general expuesta al resto de módulos y una serie de wrappers que envolviesen el funcionamiento de la aplicación.

La investigación fue corta pero concluyente y se encuentra reflejada en el apéndice I del informe de investigación sobre snapshot-manager.

El desarrollo fue apresurado y difícil debido en primer lugar a la escasez de tiempo disponible por las circunstancias académicas y personales de los desarrolladores. Aun así, la entrega se efectuó a tiempo y la API cubría algunos de los casos de uso críticos expuestos en el documento correspondiente.

Uno de los principales problemas fue causado por el abandono de uno de los integrantes del equipo HD Lorean asignado precisamente a este módulo. Las consecuencias de la marcha de nuestro compañero resultaron en un aumento de la carga de trabajo del otro componente del equipo que se vio desbordado; un riesgo que no podemos mitigar completamente debido a la falta de personal, pero que en adelante mitigaremos mediante rebalanceos más frecuentes del trabajo. Además el análisis de alcance y el reparto de objetivos era incompleto, ya que no estaban explicitadas las prioridades; queda pendiente para la siguiente iteración.

La investigación a fondo de la aplicación ha puesto de manifiesto varios problemas. Por una parte, rdiff-backup genera deltas inversas, a diferencia de lo que creíamos: ello que cambia buena parte de las presuposiciones que hacíamos sobre el programa (tanto en funcionamiento como en requisitos), y a priori dificultaría el borrado de snapshots concretos, una funcionalidad necesaria entre otras para reducir el uso de disco. Además, por estar orientado a una granularidad mayor que la nuestra no ofrece la posibilidad de actualizar un archivo individual en el backup: el escaneo siempre es sobre los tiempos de modificación de la carpeta completa monitorizada, lo que inutiliza inotify y ralentiza el programa respecto al uso que queremos darle. Por otra parte, en el desarrollo de la arquitectura quedó patente que una base de datos que indexe contenido es necesaria aunque se use rdiff-backup debajo, lo cual limita aún más sus ventajas. Queda pendiente la investigación sobre si es posible y merece la pena solucionar estos problemas, o se debe descartar el uso de rdiff-backup y buscar alternativas o construirlas desde cero.

Cron

Administrador regular de procesos en segundo plano (véase demonio) que ejecuta programas a intervalos regulares (por ejemplo, cada minuto, día, semana o mes). En un primer momento se intentó modificar el crontab del usuario, pero para acceder a él se necesitaban privilegios de superusuario. Un requisito de la aplicación es que ésta se pudiera ejecutar como usuario (por ser el usuario medio el objetivo del desarrollo), y no necesariamente como administrador, lo cual suponía un problema.

Linux nos otorga ciertos comandos para poder acceder al crontab de forma segura, sin requerir estos permisos. Entre ellos existe uno que nos lista el contenido del fichero. La solución adoptada es abrir un pipe asociado a la salida de este comando para obtener su contenido, el cual verteremos en un archivo temporal. Este archivo temporal podemos modificarlo a nuestro antojo (manteniendo siempre la sintaxis de cron). Por último actualizaremos el crontab del usuario con este archivo temporal.

Un problema es que cron supone sistemas que están operativos siempre, y por ello si el sistema no esta activo en el momento de ejecutar la tarea, esta simplemente se pierde. Sin embargo, un pc personal suele apagarse y encenderse con cierta frecuencia, por lo que tenemos que buscar algún otro mecanismo para solventar este problema.

Anacron es un programador de tareas similar a cron, con la diferencia de que no necesita que el sistema esté en ejecución. Se puede utilizar para ejecutar los procesos que cron ejecuta normalmente de forma diaria, semanal y mensual. Lo más recomendable es que se utilicen ambos, cron para intervalos pequeños de tiempo, y anacron para intervalos mayores (a partir de un día). Con Anacron no se ha conseguido solucionar el problema de los permisos, por lo que posiblemente, si no se encuentra la manera, haya que decidir que nos interesa más, si usar anacron y ejecutar la aplicación como root o usar cron y que sólo se hagan las copias de seguridad cuando el equipo esté encendido.

Además se investigó fcron, similar a anacron, pero por el momento queda descartado, ya que instalarlo modifica instalaciones por defecto de Ubuntu.

Inotify

hemos descubierto que los límites por defecto se pueden saltar y definir según nuestras necesidades, lo que mitiga el riesgo de que no sirviera o de que dificultara en exceso el desarrollo. La funcionalidad que ofrece este componente está prácticamente concluida.

Formato de ayuda de YELP (ayuda de GNOME)

esta todo en xml y además resulta incómodo a la hora de editar. Sin embargo se ha localizado un editor (Conglomerate) específico para el formato docbook, todavía en desarrollo.

Objetivos no alcanzados

No ha dado tiempo a estabilizar la arquitectura ni a realizar la API; queda como tarea pendiente para la iteración de enero a fin de poder pasar a construcción cuando se concreten las clases y se realice el UML.

Riesgos reducidos
  • La incompatibilidad de horarios ha sido mitigada al establecer como estándar el martes por la tarde para las reuniones, el día que viene "menos mal" a todo el grupo.
  • El riesgo "no llegar a superar inotify" está cubierto e implementado, así como el riesgo que apareció durante la investigación de no tener suficientes handlers.
  • GTK razonablemente superado; ya hay un GUI, pero aún falta funcionalidad por implementar en el mismo.
  • Riesgo de corrupción de backup queda cubierto *siempre y cuando* se utilice rdiff-backup, que implementa checksums.
  • Launchpad reducido, lo hemos usado todos.
  • No lograr funcionar sin internet está superado, dado que dependemos menos del wiki y el control de versiones es distribuído (en última instancia puede funcionar "punto a punto", sin pasar por los servidores de launchpad).
Nuevos riesgos
  • rdiff-backup no cubre los casos de uso, lo que nos aprieta bastante los tiempos de desarrollo y puede suponer un bloqueo para seguir avanzando con la aplicación (mejores interfaces, etc), así como dificulta su desarrollo respecto de la previsión (que era corta porque, en la primera investigación, creímos erróneamente que nos solucionaba todos los casos de uso sin trabajo adicional).
  • Detectar dispositivos externos puede requerir del subsistema HAL, una nueva tecnología a investigar.
  • La integración en bazaar es delicada; hemos comprobado que es posible romper el repositorio por parte de cualquiera. La solución prevista, a falta de comprobar si podemos restringir escrituras dentro del grupo en el servidor, es una política clara de integración: resumiendo, nadie sube a ninguna parte fuera de su grupo de trabajo, y de integrar se encargan personas determinadas. A tal fin se desarrollarán tutoriales de integración y guidelines de desarrollo específicos en python para facilitar la integración.
  • Los exámenes están próximos, quedan bastantes entregas en las otras asignaturas y el problema de falta de tiempo se incrementa. Además hemos sufrido un abandono, lo que reduce aún más el personal disponible y convierte en más crítico otra hipotética baja de media duración. Mucha gente tendrá disponibilidad reducida o nula en vacaciones; para compensar, esta es la iteración más larga (un mes y una semana), y en vacaciones al no haber jornada lectiva ni laborable hay más tiempo para trabajar.
  • No hay api de nautilus; va implícita en el código, y no hay documentación ninguna. La integración con el mismo se complicará bastante por ello.
  • Cómo exportar nuestro sistema de backups aplanado a sistema de ficheros aún no está claro, pues es un problema no trivial en absoluto; además la documentación de FUSE, el sistema que se usaría para ello, es confusa. Como la funcionalidad que nos proporcionaría es principalmente interna este riesgo tiene un impacto bastante leve.
  • Python es un lenguaje interpretado y puede ser muy ineficiente en comparación con otros módulos. No obstante, la optimización queda pendiente para futuras fases de desarrollo, es posible enlazar python con módulos en C y además presumimos que el cuello de botella no estará marcado por tiempo de cpu sino de entrada / salida.
  • Fat32 impone límites al almacenamiento de archivo que se deben cubrir, sea mediante una aplicación externa o mediante un formato de archivo propio. Al ser el formato más común en discos externos (suelen venir preformateados) es crítico que funcione almacenar sobre fat32 si se quieren externalizar las copias. Algunos de esos riesgos son que no se soportan links (ni hard ni soft), ni permisos, ni archivos de más de 4 GB de tamaño. Los riesgos son compartidos en parte por ntfs.
  • Rdiff impone límites en sus funciones internas para paths muy largos; hay que investigar el alcance de ese riesgo y actuar en consecuencia. Los desarrolladores de rdiff-backup parecen tenerlo solucionado no obstante.
  • Las herramientas de modelado UML no suelen tener soporte para python: es escaso a la hora de realizar ingeniería inversa sobre código, y casi nulo para generarlo. Localizadas herramientas que cubren en teoría ambas funcionalidades, queda comprobar hasta qué punto lo hacen y familiarizarse con ellas.
Tiempo real empleado

En general no ha habido un buen reparto del trabajo, lo cual viene motivado en parte porque la investigación implica desconocimiento del tiempo de desarrollo, pero también porque el reparto no era bueno en origen y ha habido cierta desorganización. Para mitigar este problema, según la sugerencia dada en clase trataremos de hacer planificación semanal, mediante tareas atómicas ordenadas según su nivel de importancia y relevancia para el camino crítico, y revisando más frecuentemente el reparto. No obstante esto será difícil hasta la primera iteración de construcción, pues aún queda investigación por realizar. Asimismo se ha propuesto un método de refuerzo positivo: quien llegue tarde a la fecha de entrega pierde puntos, y quien la logre los obtiene. Esos puntos serían canjeables por fermentaciones líquidas varias en la cafetería, a gusto del consumidor.

Conclusiones

Aunque se han cumplido la mayoría de los objetivos, se puede mejorar bastante el proceso de trabajo. Es necesario mejorar la integración para conseguir interoperabilidad fácilmente entre el código de todos, y conseguir un reparto de trabajo más equitativo. Aunque la integración ha sido difícil era algo previsto por ser la primera; intentaremos resolver los procesos para ello para la próxima iteración. Además, la opinión general sobre Python, el nuevo lenguaje de programación usado en el proyecto, es que para lo que podía ser ha funcionado razonablemente bien, sin grandes dificultades de desarrollo.

Respecto del abandono de un miembro del equipo, solo destacar que al no ser un miembro activo hasta ese punto no ha afectado tanto a las planificaciones de reparto de trabajo. Confiamos en que no tengamos de nuevo ese problema, ya que el equipo de desarrollo está muy motivado.


Enero

Objetivos cumplidos
Integración de bases de código

Si bien el código del equipo de desarrollo del formato de snapshots no ha podido llegar a tiempo a la integración, las distintas bases de código ya están juntas en una única, de la que los distintos equipos harán branches independientes para trabajar en adelante. Para el equipo de desarrolladores trabajar sobre ramas de desarrollo separadas, y únicamente permitir acceso a los integradores en la rama conjunta y "de entregas" del código nos permitirá mucho más control de calidad que trabajar sobre un único repositorio, sin aumentar los riesgos derivados de ello ya que sí son posibles integraciones de código parciales entre código de los equipos, y todo el mundo tiene una versión razonablemente actualizada del código de los demás para poder probar. Además tener la aplicación completa permitirá una mayor visión de conjunto a todo el mundo de la función de sus respectivos subsistemas en el global de la aplicación.

Módulo Watcher

El módulo Watcher, a falta de retoques finales- como que se detecten automáticamente cambios hechos a mano en la configuración-, está finalizado. La lógica de planificación por ahora no existe por no ser crítica y depender de pruebas en condiciones reales, pero todo el código está listo para que pase por el planificador y por tanto es factible no realizar backups si no se está conectado a la corriente, o si la carga de CPU o E/S es demasiado alta. Ello permitirá reasignar a sus componentes de personal a grupos más necesitados de personal.

Wrapper base de datos

Los componentes dependientes de una tecnología concreta han sido abstraidos a un módulo wrapper que encapsula y abstrae los lenguajes propios de sqlite al resto de la aplicación. Esto, con poco coste de desarrollo y sobrecarga, nos permite reducir al mínimo el riesgo de que sqlite no de la talla para nuestros requisitos, facilitándonos un futuro cambio de tecnología de base de datos que durante el desarrollo se temió (sin llegar a confirmarse) necesario. Quedan por fijar las consultas finales que se harán desde las distintas tablas a la base de datos, que no están fijadas aún en código por no saberse fijas, pero que también irán en sitios concretos y abstraerán la funcionalidad que proporcionan las bases de datos del código SQL necesario para las mismas.

Especificación del formato de backups

Tras un importante esfuerzo de desarrollo se ha completado una especificación del formato de snapshots que esperamos sea lo bastante completa para el resto del trabajo que queda por hacer. Se adjunta al final de la entrega de Enero.

Tabla de historia

La tabla de historia, donde se guarda toda la información de los snapshots que almacena el sistema y donde se diseñaron las operaciones más críticas, está diseñada e implementada en los diversos módulos.

Comunicación frontend / backend

Con mayores dificultades de las previstas en el desarrollo, dbus ha cumplido su cometido y nos permitirá separar la aplicación en un demonio que corra siempre y un gui. Quedan por limar detalles de la implementación (como que si se lanza el gui sin un demonio corriendo arranque al demonio), pero el problema ha quedado solventado. Ello además conlleva modificaciones del diseño UML, ya que el propio sistema dbus actúa como proxy y elimina la funcionalidad del módulo DbusManager.

Cron

Un módulo sencillo que ha complicado el desarrollo del watcher por problemas con su nula integración con dbus para poder pasar mensajes al backend de la aplicación. Su desarrollo completo (incluyendo funcionalidad de realizar las tareas pendientes si el equipo estaba apagado) permite en adelante una planificación adecuada de backups, con funcionalidad como p.e. generar backups integrales por seguridad cada mes con la que se contaba en la planificación inicial de requisitos de HD Lorean.

Requisitos tiempo y espacio

Se han realizado las estimaciones pedidas de tiempo y espacio de la aplicación, que se adjuntan en la entrega de documentación de Enero.

Generación automática de documentación

Un script en la máquina de un miembro del equipo permitirá que, cada noche, se genere automáticamente la documentación de todos los módulos de HD Lorean, lo que sin duda facilitará el desarrollo y la comunicación entre equipos. Dicha documentación se encuentra en http://www.hdlorean.com .

Revisión de calidad de la documentación

Aunque aún no se encuentre finalizada, se ha efectuado una revisión en profundidad de los documentos de clases e interacciones de clases que se generaron la anterior iteración, y todos los problemas detectados se corregirán tan pronto como se terminen de concretar las clases que finalmente quedarán en el proyecto.

Objetivos no alcanzados
Reducir el riesgo del núcleo de la aplicación

El riesgo de rdiff-backup se ha mostrado crítico, tal y como se previo en la planificación del mismo. Finalmente dicha aplicación no cubre ni nuestros casos de uso (en particular borrados), ni nuestras restricciones informales de tiempo y espacio. La dificultad ha venido de que estos problemas no aparecieron en la fase de investigación debido a pruebas insuficientes para revelarlos, lo cual, junto a otra serie de problemas que se mencionan en "nuevos riesgos", ha impedido lograr los principales objetivos planificados para esta iteración y obligarán a modificar notablemente el plan de fase, y probablemente el alcance previsto de HD Lorean.

Primer prototipo funcional

Al no tener un módulo funcionando que hiciera los snapshots, nuestro siguiente prototipo es incompleto y solo se ha podido desarrollar funcionalidad periférica.

Interfaz de navegación de archivos

Los citados problemas de comunicación entre equipos, unidos al retraso del grupo encargado de los snapshots y a una dificultad imprevista para el grupo de GUI en desarrollar una interfaz más allá de las posibilidades del diseñador de interfaces Glade han paralizado casi por completo el desarrollo de la interfaz. Al no haber snapshots funcionando aún, no estaba claro qué se debía mostrar, y al no poder desarrollar tampoco la interfaz a tiempo el resultado ha sido no tener un API claro con los datos que tiene -o tendrá- el sistema de backups almacenados dentro.

Fijar la arquitectura del sistema.

Pese a que la arquitectura preliminar se ha mostrado bastante acertada, aún quedan flecos por concretar en los módulos por terminar, y APIs por definir entre módulos como la citada en el apartado anterior sobre información de un snapshot. Dichas APIs habrán de esperar para ser estables a que el núcleo de la aplicación esté concluido y funcionando, pero se está trabajando en aproximaciones cuanto antes a ellas.

UML

Tras cerca de dos semanas de investigación, se ha concluido que, debido a las características altamente dinámicas de python como lenguaje (reescritura de los diccionarios de funciones de las clases, por poner un ejemplo), no existen -o no se han logrado localizar- herramientas libres y de calidad que generen automáticamente ningún tipo de diagrama UML lo suficientemente completo y útil a partir del código existente. Ello ha ralentizado y frenará en el futuro el crear documentación en este lenguaje, ya que ha de ser mantenida a mano por cada equipo de desarrollo y está muy desacoplado del código fuente. A falta de investigar algunas alternativas de última hora que se han localizado, el UML se está generando a mano mediante la herramienta umbrello, que permite crear todos los tipos de diagramas necesarios; no obstante nos limitaremos a una descripción lo más de alto nivel posible (algo menos que subsistema, pero sin llegar a *todas* las clases necesarias) para que nos sea útil sin dificultar el trabajo.

Un ejemplo del trabajo realizado son las siguientes dos instantáneas:

Diagrama de clases
Diagrama de clases

Diagrama de interacción (parcial) para el caso de uso 2: Añadir nueva carpeta a indexar

Diagrama de interacción para el caso de uso 2
Fijar prioridades de los casos de uso

Por falta de tiempo no se ha realizado de un modo formal y consensuado, quedando implícito que la funcionalidad prioritaria es realizar y restaurar un snapshot, así como borrarlos para poder mitigar el impacto en espacio de la aplicación, que se preve el más crítico. Queda por tanto pendiente.

Investigación tecnologías (beagle, nautilus, HAL)

La falta de tiempo general ha provocado que haya sido imposible la investigación de tecnologías adicionales. Exceptuando nautilus, que se considera mucho más deseable de cara a la usabilidad de la aplicación, es probable que el resto queden fuera de alcance en la revisión que se haga del mismo en la próxima iteración.

Documentación adicional

De la documentación adicional faltan aún las guidelines de python y las de integración, aunque sobre python ya hemos concretado aspectos importantes como por ejemplo cómo guardar registros de errores / debug. Se han retrasado por problemas de incomunicación durante el periodo estival entre responsables, y se ha decidido esperar a concluir la integración en una sola base de código para simplificar la tarea a todos los miembros del grupo.

Riesgos reducidos
Sqlite

Al disponer de un wrapper según el diseño de la arquitectura, ya no dependemos tanto de esa tecnología específica y sería más sencillo cambiar a otra más potente como mysql.

Rdiff-backup

Al no usar esta tecnología, tras haber mostrado sus consecuencias su riesgo desaparece.

Problemas de definición de la arquitectura

La arquitectura diseñada parece responder a las necesidades de la aplicación correctamente, lo cual ha sido un éxito de diseño conseguido gracias a la interacción de clases con tarjetas CRC. En general el equipo es más consciente de la misma.

Investigación instalador

Se ha investigado la tecnología de instalación de python (distutils), lo que ha contruibuido a la viabilidad de integrar todas las distintas bases de código en una y facilitará el proceso de despliegue hacia el final del proyecto.

Integración de código (buscar por "bazaar").

Ya está claro y probado cómo se realizará la integración del código de los distintos equipos, y solo queda generar la documentación pertinente.

Demonio y frontend corriendo independientementes

El riesgo tecnológico que presentaba dbus como tecnología de interconexión está controlado y resuelto; ya tenemos la aplicación separada en demonio y frontend.

Nuevos riesgos

Aumenta: no lograr cubrir los casos de uso requeridos por la aplicación, por las nuevas dificultades de desarrollo en el backend. Ya no tenemos el colchón de seguridad que proporcionaba basarnos en una aplicación ya probada.
Aumenta: no lograr que HD Lorean sea lo bastante intuitivo y transparente al usuario, por falta de tiempo en el desarrollo que haga imposible lograr suficiente integración con el escritorio.
Nuevo riesgo tecnológico: por las tentativas que hay de formato de backups se ha detectado que usa un gran número de archivos. El número de inodos posibles en un sistema de ficheros está limitado, y si no se tiene cuidado podemos toparnos con él.
Aumenta: Falta de tiempo; el segundo cuatrimestre dos miembros del equipo se han incorporado a sendos trabajos, y además hay una optativa con prácticas que muchos de nosotros cursaremos que nos robará aún más tiempo.

Tiempo real empleado

Menor del deseable y planificado, ya que la planificación para las navidades no era realista y casi nadie ha sacado el tiempo necesario.

Conclusiones

Esta iteración ha resultado poco exitosa por la unión de varios factores. El principal problema que hemos debido afrontar ha sido el riesgo tecnológico de rdiff-backup, tecnología que no supimos detectar a tiempo que no era suficiente para nuestros propósitos porque nuestras pruebas fueron demasiado reducidas en ámbito; sencillamente no ha habido suficiente tiempo para finalizar el desarrollo de una tecnología nueva de snapshot desde cero. Por otra parte, en general todos hemos trabajado sensiblemente menos de lo planificado, lo cual nos servirá para futuras estimaciones de tiempo en presencia de otras fiestas de guardar. Además ha habido problemas importantes de comunicación entre equipos, y entre miembros de equipos, que han parado completamente el desarrollo durante las vacaciones; no se han sabido resolver los interbloqueos con propuestas de compromiso de API, lo cual ha detenido mucho al grupo de GUI, que por otra parte se ha encontrado en su desarrollo con más problemas de los esperados al comenzar con la funcionalidad más compleja del mismo. Asimismo, la sensación general ha sido de moderado desánimo, provocado por el cansancio, por haber encontrado las primeras dificultades de cierta envergadura en el desarrollo, y también en parte por una falta de delimitación de tareas claras que en ocasiones dejaba a la gente desocupada, esperando instrucciones sobre qué hacer que se creían entendidas.

Para solucionar estos problemas, en Marzo haremos una revisión profunda de procesos de desarrollo y reasignaremos al personal de Watcher, para mejorar esos problemas de comunicación y centrar los esfuerzos de programación en las zonas más necesitadas. Intentaremos recuperar el máximo posible del tiempo gastado de la planificación de fase original, para conseguir completar el máximo de funcionalidad posible. En cuanto al reparto de tareas, se espera que teniendo el código unificado sea más claro quién tiene que hacer qué y en qué momento, a lo que también contribuirán los movimientos de responsables en el personal.

Además será necesario reevaluar en profundidad las planificaciones, lo que probablemente obligará a reducir el alcance de la aplicación y la viabilidad del desarrollo de algunos de sus casos de uso.


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.


Marzo

Objetivos cumplidos
Beta funcional del programa

Consideramos que la primera entrega fue un fracaso previsto y avisado, ya que el tiempo era poco, y si bien se realizaron avances extraordinarios en dos semanas de intenso trabajo, la presión por la inmediatez de la entrega redujo notablemente la calidad del desarrollo, lo que condicionó notablemente nuestro fallo. Por parte del equipo consideramos que no es razonable volver a pedirle al personal semejante esfuerzo de desarrollo, que va contra la buena gestión del tiempo y contra una planificación realista y efectiva de los recursos humanos, y de cara a no gastar en exceso a la gente pretendemos que no se vuelva a repetir bajo ningún criterio. Esto, aunque implique tener que incumplir requisitos externos, siempre que por mayoría simple los juzguemos irrazonables, y con consciencia de las consecuencias.

No obstante, una vez liberados de ese problema inmediato hemos podido dedicarnos a la mejora del código solventando todos los problemas que habíamos ido localizando y posponiendo durante el apresurado desarrollo. Ejemplo sean los problemas detectados de codificación en el código con acentos, que se debían principalmente a faltas de consistencias entre los módulos.

Todo ello nos ha permitido una entrega a final del mes en gran parte ya funcional: al margen de hacer y recuperar versiones de archivos, también creamos un snapshot inicial del sistema al arrancar la aplicación (para protegernos de periodos durante los que esté cerrada), y están resueltas las planificaciones periódicas e instantáneas con cron (entre las que la inicial se puede considerar un caso particular) y los pequeños problemas que tenía el mecanismo de notificaciones de cambios en archivos. Además de esto, tenemos previstas y desarrolladas parcialmente (incluso sólo por probar exhaustivamente) bastantes de la funcionalidades que aún nos faltan para aproximarnos a los objetivos iniciales de proyecto y a los casos de uso planteados entonces, como por ejemplo borrar snapshots, caducarlos para poder borrarlos, obtener una eficiencia de uso de los recursos que permitan no notar la aplicación, feedback de las operaciones en curso hacia el usuario, o una versión en consola de la aplicación.

Queda pendiente una refactorización de partes del código que no están a la altura de la calidad requerida y que supondrá restar un tiempo extra al ya ajustado del que disponemos, en buena parte motivada por ese apresurado y algo caótico desarrollo inicial.

Contratación de personal

La reciente incorporación de un miembro extra a nuestro proyecto nos enorgullece y da perspectiva sobre cómo se percibe a nuestro grupo de proyectos externamente. Nos permitirá repartir mejor la carga de trabajo y reforzar áreas donde andamos escasos de personal y que podrán hacer buen uso de su talento, si bien nos supone nuevos riesgos y dedicarle a su vez a personal para introducirla a todo el material (documentación, procedimientos y código) que tenemos hasta ahora y que el resto conocemos. Nos supondrá, en resumen, un esfuerzo extra en formación que esperamos rentabilizar cuanto antes.

Puesta a prueba de la arquitectura

A raíz de tener la primera versión funcional del programa hemos empezado a explorar lo que haría falta para ampliarlo, de cuyo análisis inicial concluimos que buena parte de las horas invertidas en pensar la aplicación inicialmente ahora dan su fruto, y la mayoría de las extensiones para completar funcionalidad parecen "factibles" y hasta "fáciles", solo limitadas por el tiempo del que disponemos. La falta de cambios notables a la arquitectura para conseguir esto nos habla de la calidad de la misma y nos permite a partir de ahora un desarrollo mucho más rápido que en el caso contrario.

Puesta a prueba del despliegue

Dos entregas sucesivas en unos 10 puestos simultáneos han probado la arquitectura provisional de despliegue con éxito, no notándose ralentización alguna durante el uso pese a su perfil relativamente intensivo de uso de disco. Ello se ha debido en parte al equipo donde se ha desplegado, lo bastante potente y con un subsistema de disco solvente (dos discos en RAID0), y en parte a la relativa complejidad en probar una aplicación de este perfil en condiciones más reales (con un volumen más grande de documentos y archivos del usuario). Tener dos miembros del equipo trabajando de administradores de sistemas también ha sido determinante, con acceso a recursos de red que nos hubiera sido complicado obtener de otro modo.

Si bien esta arquitectura es provisional y solo motivada por las limitaciones que nos imponen los técnicos de laboratorio, nos servirá para generar el UML de despliegue y seguimos explorando y proponiendo a los técnicos otros medios de despliegue, como máquinas virtuales que, sin suponer un riesgo de seguridad, son un entorno más real sobre el que probar.

Quedan pendientes aún temas de empaquetado del software que se resolverán en breve.

Revisión de las pruebas

Durante las pruebas con usuarios reales, sobre todo la segunda, hemos obtenido bastante feedback sobre las mismas. Parte del mismo nos será de gran ayuda para mejorar usabilidad de la aplicación, habiéndose detectado problemas nuevos que por la falta de revisión formal se habían pasado por alto hasta ahora. Se dará buena cuenta de las sugerencias recibidas mientras seguimos explorando por nuestras cuenta otras mejoras adicionales.

Nuevo GUI

El uso de herramientas de prototipado rápido, como Python y sobre todo la herramienta Glade de desarrollo visual de interfaces en XML, nos han permitido cambiar el interfaz que teníamos inicialmente reutilizando casi todo el código preexistente, así como desarrollar nuevas interfaces como la vista en dos paneles, en muy corto espacio de tiempo. Ello ha mejorado mucho la calidad de la aplicación y nos demuestra lo acertado del enfoque de utilizar herramientas que desacoplen el diseño de interfaces del de código. Si bien hay multitud de aspectos a mejorar detectados, ahora el GUI es mucho más ordenado y visualmente atractivo. Además se han añadido elementos como una barra de botones que hacen accesibles las funciones más comunes y se han solventado fallos elementales como el no poder diferenciar entre una carpeta y un elemento, aunque esta mejora no llegó a la entrega.

Ruta de comunicación inversa

Un miembro del equipo ha desarrollado la funcionalidad de comunicación inversa usando el mismo canal D-Bus existente, esto es: de backend a frontend. Ello nos resuelve finalmente el riesgo del sistema de comunicación interproceso que utilizamos (D-Bus) y nos permite proporcionar feedback al usuario de modo eficiente (sin usar polling). Gracias a esto podremos desarrollar varias mejoras, como un refresco de la ventana principal para responder a cambios en el backend y exploraremos la posibilidad de incluir barras de progreso o popups de notificación.

Fechas de reunión

Ante la dificultad de encontrar horarios comunes por tener a 4 miembros del proyecto trabajando (un 30%, cifra muy elevada) hemos establecido para ello las horas de laboratorio de Jueves y Viernes, normalmente improductivas en lo que a desarrollo se refiere y en las que normalmente estamos todos presentes. En cualquier caso, el estado del desarrollo actual nos permite reunirnos menos que en la fase previa de definición del proyecto.

Licencias en el código

Hemos añadido la licencia GPLv2 al código y los copyright pertinentes para cumplir con la legalidad, al haber reutilizado pequeños fragmentos de otras aplicaciones que nos obligaban a ello. Con este cambio nos integramos plenamente en el floreciente mundo del desarrollo de software libre y mejoramos las posibilidades de su mantenimiento una vez acabado el desarrollo del proyecto, sea por nosotros o por terceros.

Hdlogger y tratamiento de fallos

El módulo desarrollado de logging nos ha permitido centralizar toda la información de depuración útil para diagnosticar fallos, e incluso desarrollar. Sobre el mismo hemos construido un módulo de informe de excepciones inesperadas y cuelgues, que nos enviará los archivos que Hdlogger genera, para poder analizar en profundidad los fallos que se produzcan en la aplicación.

Queda pendiente que sea exhaustivo y más útil aún y que se aproveche desde el GUI, lo que requiere moverlo ligeramente de donde está en la arquitectura para sacarlo del backend, y de un esfuerzo por parte de todos los desarrolladores para utilizarlo adecuadamente.

Bugtracker, listas de correo y traducciones

La aplicación web que utilizamos para la gestión de configuración, http://launchpad.net , además de centralizar el control de versiones que hemos estado usando hasta ahora, nos integra funcionalidad extra de seguimiento de bugs detectados, así como gestión de traducciones online (un aspecto sobre el que investigaremos, pues fue mencionado en las revisiones de las entregas), y recientemente listas de correo (archivadas e indexadas para su búsqueda). Exploraremos también la posibilidad de integrar la gestión de fallos mencionada anteriormente con launchpad, ya que recientemente hemos descubierto módulos Python que sirven para ello.

Retoques al modelo de desarrollo

Pendientes de ser documentados en inmediatas actualizaciones de la documentación, hemos realizado retoques al modelo de desarrollo para facilitar las integraciones de código y reducir riesgos. En adelante tendremos múltiples niveles de repositorios. Los que ya teníamos (los privados de cada usuario), se integrarán en los de cada grupo de desarrollo (como gui, db para bases de datos, console o snapshot-manager), donde se desarrollarán las features nuevas en progreso. La integración entre estos nuevos repositorios se hará a través de un repositorio común llamado unstable, que probablemente tenga problemas producto de esta integración. Tras estabilizarlo se migrará el código a un nuevo repositorio de testing, que debe ser estable y probado, y sobre el cual solo aplicaremos correcciones de errores (que, gracias al control de versiones que usamos, podrán ser portadas con algo de cuidado bidireccionalmente entre testing y unstable sin afectar a las divergencias que hayan surgido entre ambos). Finalmente, las versiones que hagamos se etiquetarán en testing y se dejarán en trunk, de donde obtendremos el resumen de todas las entregas al final del curso, y que estará establecido como repositorio principal.

Con esto solucionaremos todos los problemas de integración a la vez que podremos mantener baselines estables independientes del desarrollo y portar parches entre repositorios.

Objetivos no alcanzados
Documentación

La documentación ha sufrido un descenso de la calidad motivada por el exceso de trabajo. Al margen de la revisión y actualización de la documentación existente, no se han cumplido en absoluto las planificaciones acerca del desarrollo de UML por parte de los respectivos grupos de trabajo. Ello se debe sobre todo a la sobrecarga de trabajo de todo el mundo. Para solventar este problema hemos reasignado a tiempo completo a un miembro del equipo que ha trabajado en prácticamente todas las partes de la aplicación. Su trabajo, consistente en consultar a todos los equipos sobre la aplicación, desarrollar los pertinentes diagramas, detectar patrones de diseño aplicables que no hayamos usado y documentar los que sí, aún está por completar pero esperamos tenerlo listo para la siguiente iteración.

En cuanto a la revisión de la documentación existente, supone un riesgo cada vez mayor sobre el que exploraremos soluciones.

Por último, mencionar el retraso en las fechas de entrega de la documentación, motivado por el exceso de trabajo del mantenedor de la misma, así como por haber esperado a la segunda entrega de código y a evaluar sus resultados, la cual a su vez se retrasó hasta la primera semana de Abril por la Semana Santa.

Eficiencia aplicación

Al conseguir poner a funcionar la aplicación hemos detectado algunos problemas de esperas excesivas de cara al usuario sin feedback alguno. Como nos supone un riesgo muy importante (ya que si la aplicación es demasiado lenta será el primer impedimento para su usabilidad), según se detectó el problema se reasignó a personal para su evaluación y solución. El problema está en buena parte generado por el uso de llamadas síncronas -las más sencillas y habituales para el equipo de desarrollo- que dejan a la aplicación "esperando" operaciones grandes de disco, así como otros problemas relativos a la gestión de patrones para expresiones regulares. Confiamos en que la arquitectura, mediante el scheduler que tenemos incorporado, y un uso juicioso y sencillo (para evitar inestabilidad) de threads, nos permita al menos no perder la responsividad frente al usuario.

Consola

La consola, desarrollada hacia la mitad de la iteración, no ha sobrevivido a los numerosos cambios de la aplicación por no haber sido adecuadamente mantenida y probada. Su uso nos sería muy útil para automatizar el testeo de la aplicación completa muy fácilmente, con meros scripts (que pueden ir incluso al margen de las unidades de prueba), y cubre casos de uso con relativa sencillez.

Se resolverá cuanto antes y además se solventarán riesgos relativos a la misma, como medios alternativos de conectarla con el backend que no dependan de D-Bus (por ejemplo señales convencionales) y un nuevo proxy para las mismas (ya que es un servicio del sistema que no suele estar presente en un entorno sin gráficos, precisamente donde sería más útil en recuperación del sistema).

Calidad

Carecer de un plan de calidad más allá de las directrices establecidas nos empieza a pasar factura. El seguimiento de la calidad del código es irregular y no existen procesos para rechazar código, ni revisiones formales y exhaustivas sobre el mismo. Estas deficiencias, aparte de reducir nuestra puntuación para la evaluación de Software Capability Model, nos generan problemas al desarrollar y nos suponen un riesgo a la hora de mantener la aplicación que deberemos valorar y solucionar cuanto antes, mejorando nuestro proceso existente. Sin embargo, carecer de personal suficiente nos lo pone muy complicado.

Formación del nuevo personal

El nuevo miembro de personal incorporado aún no ha concluido su formación y por tanto aún nos supone un balance neto negativo de productividad; la información nueva es mucha, y además hay algunos fallos de actualización de la misma cuando está explicitada en el wiki. Ello deberá solventarse a la mayor prontitud posible.

Riesgos reducidos
  • Aplicación: ya tenemos una versión de la misma funcionando. Aunque le falten características, ha tranquilizado a todo el equipo, ya que desde aquí el proceso es mucho más incremental.
  • Despliegue: dos entregas sin percances nos quitan el problema de cómo presentar y probar la aplicación, uno de los más importantes y olvidados de cara a una entrega con éxito.
  • Personal: la reciente incorporación de un miembro más al equipo nos puede reducir la carga de trabajo en áreas importantes y descuidadas.
  • Personal: puesta a prueba durante un fin de semana de programación extrema, la dinámica del grupo funciona perfectamente y hemos resuelto todos los problemas entre nosotros sin percance alguno. El grupo funciona muy bien para trabajar, la relativa falta de jerarquías contribuye a la confianza entre miembros, lo que mejora el flujo de información y el control de los distintos grupos. Basar las decisiones delicadas y discutidas en revisiones del grupo permite reaccionar con cierta rapidez a cambios polémicos y subsanarlos de modo eficaz mediante consensos. A pesar de dicha falta de jerarquías formales, la confianza en las relativas capacidades de los miembros del equipo nos permite mejorar la rapidez en solucionar esas discusiones y agilizar la toma de decisiones.
Nuevos riesgos
  • Personal: Contratar a un nuevo miembro siempre supone un riesgo de personal: integrarse en un equipo y proceso de trabajo preestablecido, posibles roces con la gente, formación intensiva a esa persona, etc., no sin descuidar en entornos más formales que este los posibles problemas que surgieran de adquirir credenciales de seguridad, boicoteos internos, etc. Para mitigar este riesgo confiamos sobre todo en la buena dinámica de personal antes mencionada, pero además hemos comprobado que los procesos establecidos de gestión de código, ya basados en niveles de acceso a distintos repositorios de código, nos permiten dar permisos lo bastante atómicos para trabajar, así como determinar la autoría de los cambios en caso de posibles problemas. Por ello creemos mínimas las consecuencias de ese hipotético problema (principalmente en tiempo), y comprobamos la validez del proceso.
  • Personal: conforme avanza el desarrollo y se reduce el tiempo restante, el riesgo de "quemar" al personal crece por exceso de trabajo, y una planificación cuidadosa de procesos y asignación de responsabilidades es la única forma de minimizarlo hasta que sea irrelevante por haber acabado la asignatura. Es importante intentar extraer el máximo rendimiento posible del equipo, pero no debemos intentar extraer más que lo razonable y necesario por querer avanzar más de lo realista.
  • Tiempo: reducido por la formación del personal nuevo.
  • Tiempo: reducido del lead developer por otras asignaturas y cansancio del desarrollo seguido.
  • Tiempo: muy escaso para concluir la aplicación (solo dos iteraciones más).
  • Problemas de rendimiento de la aplicación que la hagan poco usable aumentan su posibilidad de aparición, pues ya han sido detectados, y se están evaluando y subsanando.
  • Tecnología de base de datos: demasiado lenta (bloquea entera la base de datos en escrituras); un cambio fue planificado y por tanto la arquitectura del código minimizaría el impacto, pero aún así sería un problema añadido que reduciría aún más el tiempo del que disponemos.
  • El uso de threads puede hacerse necesario para solucionar esos problemas de rendimiento, con el consiguiente riesgo de desarrollo por ser una tecnología relativamente complicada de aplicar bien y de depurar.
  • Carencias en la documentación: podrían no llegar a ser subsanadas a tiempo, y cuanto más tardan mayor es su impacto. Por ejemplo, por no haber examinado y completado el documento de la evaluación de Software Capability Model, no llegamos actualmente a nivel 2 (y no por no ser capaces de ello).
  • Futuras entregas "sorpresa" como la primera nos exponen al riesgo que conllevan: si no las entregamos, de cara a la asignatura, y si apresuramos el desarrollo y nos saltamos los controles que ralentizan el desarrollo, de cara a la calidad de la aplicación. Sin embargo consideramos este un riesgo no planificable en absoluto.
Tiempo real empleado

El tiempo empleado ha sido excesivo, incluso superior a lo planificado que ya contaba con los problemas para llegar a la primera entrega. Incluso hemos llegado a dedicar un fin de semana completo para desarrollar, aparte de ausencias en asignaturas por parte de buena parte del personal. Replanteados objetivos y medios, la segunda mitad del mes ha sido algo más relajada y a su vez mucho más productiva, necesario para no desgastar en exceso al personal. En general, debemos tratar de reducir nuestro alcance para no repetir esta situación, por complicado que resulte.

Conclusiones

Con cierta sorpresa para todos y también bastante ilusión, tenemos la aplicación al fin funcionando, al menos mínimamente, con lo que apenas hemos modificado el plan de fase existente y, aunque hay sensación de agobio, seguimos manteniendo vigente la última planificación de fase. Queda muy poco tiempo ya de desarrollo, así que habrá que aplicarse en estabilizar (crítico para el éxito hipotético de nuestra aplicación), a la vez que intentamos cubrir funcionalidades adicionales, lo que supone todo un conflicto de intereses a resolver con políticas adecuadas de release. Por lo demás, la iteración ha sido todo un éxito en la medida que hemos podido estrechar bastante los lazos entre el personal, en particular durante el apresurado y algo caótico desarrollo de la primera entrega. Nos quedamos por tanto con eso de toda la iteración: todo el equipo nos respetamos mucho más, al habernos visto trabajando -y rindiendo- bajo presión.

Como punto amargo, no haber conseguido hacer funcionar la entrega 1 por detalles de última hora nos lleva a tomar la decisión de no volver a realizar "maratones" de ese estilo para futuras entregas no planificadas -ni planificables-, conocedores del riesgo relativo en que incurrimos con ello.


Abril

Objetivos cumplidos

Hemos conseguido un seguimiento más individualizado de objetivos para tener más información sobre el rendimiento del personal. Además, el bugtracker ha sido de gran ayuda para dejar constancia de los fallos que íbamos encontrando y asignarles responsables de mejora, así como para seguir su progreso. En general hemos seguido avanzando en el desarrollo de la aplicación (con features importantes como el borrado de versiones y mover el directorio de backups), solucionando casi todos los problemas de rendimiento que teníamos presente.

El trabajo individual en el código de cada uno ha sido:

  • Carlos:
    • Bugfix treeview: al borrar un archivo, aparecía un icono de carpeta. Se ha cambiado y aparece un icono de salvado en disco (16/04/08).
    • Bugfix treeview: que no se comprima cuando se refresca la ventana (19/04/08).
    • Pop ups informativos (con Tabas) (20/04/08)
    • Bugfix treeview: mantener la selección cuando refresca (21/04/08).
    • Bugfix treeview: orden de las carpetas y archivos (23/04/08).
  • Robs:
    • Ventana porcentajes iniciada.
    • Ventana preferencias: cambio botones (09/04/08).
    • Añadir licencia y copyright en la ayuda (11/04/08).
    • Implementar la ayuda (con Diana) (23/04/08).
    • Testing: consola (23/04/08).
    • Cuestionario(s) para las pruebas (24/04/08 y 09/05/08).
  • Mario:
    • Consola.
  • Fede:
    • Añadidos dos campos en la base de datos (junto con Salva) (01/04/08).
    • Borrar snapshots (junto con Salva) (15/04/08).
    • Redefinido el concepto de "snapshot" por "versión" (17/04/08).
    • Bugfix: cambiada la ruta de las carpetas (no era lo bastante informativa) (18/04/08)
  • Diana:
    • Investigacion de los paquetes de traducción al español (20/04/08)
    • Implementación de la ayuda (con Robs) (23/04/08)
  • David:
    • Mantenimiento de la base de datos (todo el mes).
    • Investigación: Pylint para calidad del código (18/04/08).
    • Puesta en orden de las licencias en el código de la aplicación (22/04/08).
  • Jorge:
    • Expresiones regulares: patrones de exclusión (16/04/08).
    • Refactor del watcher (en progreso).
    • Mover el directorio de backups en progreso junto con Adrián.
  • Salva:
    • Añadidos dos campos en la base de datos (junto con Fede) (01/04/08)
    • Borrar snapshots (junto con Fede) (15/04/08).
  • Tabas:
    • Status bar (18/04/08).
    • Bugfix: Ventana de debug (18/04/08).
    • Drag and drop (de fuera a dentro) (10/04/08).
    • Bugfix: funciones D-Bus para la consola (07/04/08).
    • Boton derecho systray (07/04/08).
    • Selección múltiple para borrar varias versiones ("snapshots") y para restore (19/04/08)
    • Boton derecho (19/04/08) NOTA: Esto necesita mas aclaración.
    • Pop ups informativos (con Carlos) (20/04/08)
    • Investigación: threads y D-Bus.
  • Carmen:
    • Documentación: Revisión (11/04/08 - aprox).
    • Revisión de la planificación (work in progress).
    • Subir bugs (work in progress).
  • Adri:
    • Base de datos (thread safe, backoff, sanitizing inputs…) (20/04/08).
    • Gestión del bugtracker (durante todo el mes) y de releases.
    • Bugfix: varios (durante todo el mes).
  • Ezequiel:
    • Documentacion: Meter tutoriales en el printable (22/04/08)
    • Investigacion: imagen de QEmu para probar el despliegue sobre virtualización (25/04/08).
    • Documentación: Revisión en progreso.
    • Documentación: evaluación del Software Capability Model.
Objetivos no alcanzados.

En general, hemos gozado de menos tiempo del deseable para dedicarle al proyecto debido a entregas para otras asignaturas. Por tanto, no hemos tenido tiempo de investigar la sincronización con discos externos, y no creemos que sea factible realizarlo en condiciones dado que en adelante gozaremos de menos tiempo aún.

  • Mario: Testing: consola
  • Robs: Ventana de porcentajes.
  • Diana: UML - Tareas en cola:
    • Ayudar con la revisión del wiki: actualizar la arquitectura (poner nuevos pantallazos de UML).
  • David: Traducción. Informe de Pylint. - Tareas en cola:
    • Ayudar a Diana con el UML.
    • Documentación:
      • Revisión de los cambios hechos a la planificación de fase (con la historia de revisiones de la página).
      • Actualizar las tablas de riesgos iniciales con los que han ido apareciendo en todos los seguimientos (tanto los nuevos, como los que se han acabado por confirmar y demás).
  • Carmen: Planificación: Seguimiento de fechas: contabilizar si se han cumplido plazos y explicitar qué no se ha cumplido y por qué en el seguimiento de abril.
    • Investigación: IDE Eric para depuración y generación automática del UML.
    • Documentación: revisión del wiki (encontrar erratas e inconsistencias en la documentación).
    • Calidad: leer el código
  • Ezequiel:
    • Calidad: finalizar la documentación.
    • Software: investigar las versiones y el empaquetado.
    • Documentación: Documento de despliegue.
    • Documentación: Documentación de proceso del wiki.
  • Fede: Refactoring
  • Salva: Refactoring
  • Jorge: Refactor en Watcher.
Riesgos reducidos
  • Mantenimiento: merced al trabajo en progreso de refactorización y mejora general de la calidad del código, la aplicación será mucho más legible y mantenible.
Nuevos riesgos
  • Problemas con empaquetado se vuelven críticos.
  • Bugs que aparezcan en el software de cierta importancia se vuelven más críticos también, ya que queda poco tiempo para arreglarlos.
  • Que la aplicación se nos queda corta respecto a lo planeado es ya un hecho.
Tiempo real empleado

Todo el mundo hemos dedicado bastante tiempo a la asignatura, pero conforme avanzan las fechas han ido apareciendo entregas -con cuya dificultad no contábamos correctamente- para otras asignaturas que nos han privado de mucho tiempo que hubiera hecho falta para alcanzar plenamente los objetivos planteados para esta iteración, y limitarán notablemente el alcance de la siguiente y última.

Conclusiones

La iteración ha cundido menos de lo deseable, un riesgo previsto, y por tanto nos vemos obligados a reducir más las features que estarán en la entrega final de lo que quisiéramos. Sin embargo el proceso está ya bastante pulido, al haber incorporado el bugtracker y el director de releases (Adrian), y por tanto cualquier desarrollo extra que nos de tiempo a hacer será de alta productividad (al ya tener toda la arquitectura fijada, el proceso de control de configuración y de integración de bases de código, etc), lo que nos permitirá desarrollos intensivos de última hora de considerarlo conveniente.

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