Gestión
Table of Contents

Introducción

En esta página centralizamos todo lo referente a gestión del proyecto: estándares, planes, entregas, reparto de tareas, etc. Los contenidos se incluyen a fin de poder incluir esta página directamente en printable; van en páginas independientes por comodidad (a sabiendas de que los includes de cada página son más o menos reducidos).


Estándares

Introducción

  • De la formación del personal se encargan los tutoriales, que no solo tratan de tecnologías específicas de cada grupo de trabajo sino también de todo lo necesario como el control de versiones. Todo el mundo documentará sus tecnologías, así minimizamos el riesgo de personal de que, en ausencia de alguien, nadie supiera cómo seguir su trabajo.
  • El modelo de desarrollo a seguir para el código queda establecido como propuesta-modelo-desarrollo la propuesta inicial, disponible en los tutoriales.
  • La evaluación de la calidad queda repartida entre todo el personal. Se repartirá a cada uno código a leer de otros grupos para revisar la legibilidad y concordancia a estándares del mismo. En cuanto a la documentación, Ezequiel queda como gestor último de la calidad de la misma, y se ruega a todo aquel que encuentre problemas en la misma que los solucione o al menos notifique.
  • El estándar de documentación en wiki es sencillo: Todo aquello que vaya a ser incluido a posteriori debe empezar con el header de tamaño 2: ++, para que con el de tamaño 1 se pueda categorizar al incluirlo. A partir de ahí, se ruega la máxima legibilidad y corrección, así como la estructura que se considere adecuada mediante headers. Se ruega a cada equipo que documente en el wiki todo lo posible para tener constancia al final.
  • Por favor, para mantener el nivel de calidad en la documentación usad el corrector ortográfico de firefox. Ahorraréis trabajo a control de calidad ;).
  • Todo fragmento de documentación exigido por Gervás debe tener como padre (o abuelo, vaya) doc, como categoría doc: y debe comprobarse que queda incluido correctamente en printable (que no se rompe la anidación de headers, generalmente). Si no está allí, no se entrega al final…
  • Para poner fragmentos de código se *debe* usar la etiqueta [code].
  • Respecto a los comentarios, ya lo he mencionado en lista de correo: No dejéis comentarios entre la documentación, usad las páginas de comentarios de cada página y así los podemos ver juntos… Si echáis en falta la sección comentarios, añadidla con :
[[div class="comentarios" ]]
+++ Comentarios: [!--anidamiento según la página--]
[[module Comments title="" hide="true"]]
[[/div]]

Con esto solucionaremos el tema de flujo de información interna en el proyecto sin riesgos a la calidad de la documentación final (ya que al imprimir en PDF no se verá).
  • El estándar de código seguirá estandar-codigo. Se escribirá lo más posible en inglés, para facilitar salidas posteriores a nuestro proyecto.

Modelo de desarrollo de código

Introducción

Tras estudiar un poco el funcionamiento de http://launchpad.net (no tan intuitivo como pretenden), he aquí una propuesta de modo de trabajo "con-código" para cuando tengamos que tirar líneas.

Los tutoriales concretos de bazaar siguiendo este modelo están aquí.

Ejemplo

Para resumir muy mucho, como algunos sabréis bazaar es un sistema de control de versiones que sirve igual que la historia de la wiki: lleva todas las versiones de tus archivos de código (en realidad de cualquiera), te enseña las diferencias entre versiones y te permite hacer otro millón de cosas interesantes como trabajar mucha gente a la vez (como subversion, pero sin necesidad de un server central), o mezclar bien los cambios entre el trabajo de mucha gente (lo más automático posible: si dos escribimos distinto una línea obviamente hay que revisar a mano, esto no es IA). Bazaar puede trabajar en modo "checkout", donde es básicamente "subversion" (el server centralizado, cuando cambias algo detecta tus cambios y tienes que mandarlos al repositorio remoto con "commit", y bajarte los cambios de otros con "update" antes de trabajar), pero también puede hacer "branch" (o "ramas", que son como "variantes" de una base de código con tus modificaciones por entendernos) con lo que todo se almacena en local, y para juntar tu código con otros branches hay un comando "merge" entre branches separados (parecido, supongo, al svn merge).

ojo que los comandos no son exactos, sino cogidos de los equivalentes en subversion.

Basamos el modelo de desarrollo en la propuesta de separarnos en grupitos de desarrollo con los que organizamos un poco.

Modelo de desarrollo

INDIVIDUO
  • Absolutamente opcional. Para que la gente que no se aclare con el bazaar no tenga que liarse más de lo estrictamente necesario. Esto sirve solo para facilitar al trabajo al que se quiera complicar un poquito la vida al principio, es útil cuando eres desorganizado como yo.
  • Trabajar en local con bazaar, y descentralizado.
  • Puedes hacer commits locales (esto es, *sin* conexión a internete). Pero también puedes subir tu código a tu espacio de launchpad con bzr push, para bajarte el código desde la facu, sincronizar con tu portátil, tener un cierto backup o lo que sea. Sin embargo al no necesitar conexión para hacer commits puedes hacerlos frecuentemente (casi con cada cambio que hagas que ande a medias, vamos), y tienes "time machine" de tus archivos de código (de eso va el commit tb, puedes hacer "revert" y deshacer cambios).
  • Puedes usarlo para otros proyectos tuyos, tener cienmil branches del código
  • Como contra, hay que *aprender* a usarlo.
  • Aquí es donde tiras tus líneas de código.

EQUIPO
  • Los cuatro equipos del apocalipsis XD.
  • Separación de trabajo por bloques de funcionalidad, o como podamos o queramos repartírnoslo.
  • Cada equipo agrupa features del código, probablemente inestables y rotas, mientras se desarrollan.
  • Trabajamos con el modelo "checkout" que es trabajar *igual* que en subversion, los commits son *solo* remotos.
  • Dos opciones de trabajo:
    1. Si trabajas con bazaar en local, tus branches locales llevan tu código y su historia, y por tanto tienes que hacer merge de tu código personal con el branch del equipo (lógicamente, hay que sincronizarlo). En principio no debe ser mucho lío (nada que ver con subversion al respecto), pero esto es lo que habría que aprender realmente. Pero a cambio solo te hace falta conexión para sincronizar tu trabajo con el equipo, y puedes ir sincronizando más a alto nivel (cuando algo te medio funciona como para que el resto puedan usarlo, no una-vez-por-cada-cambio-en-archivos).
    2. Si pasas de liarte con bazaar en local, pasas a trabajar totalmente como si fuera subversion. Pierdes los commits locales y necesitas conexión (constante) a internet para cada commit, y pierdes también la posibilidad de hacer tus branches del branch del equipo (maldad extrema). A cambio, no te lías con merge y es muy similar a usar subversion, con el que algunos ya hemos trabajado.
  • Aquí centralizamos el curro de cada equipo.
  • Comentario: no es necesario un equipo *por feature*, en realidad para eso están los branches… Si os dais cuenta todos los equipos suben al *proyecto* hdlorean (lo veréis enseguida!), y en la página del proyecto quedan tanto los branches personales como los branches de equipo registrados, que pueden ser varios (se ve quién los publica, el equipo, y los nombres de esos branches, que sí pueden ser por feature).

PROYECTO
  • Donde tenemos el proyecto ya todo junto.
  • El "trunk" que viene por defecto en launchpad.
  • Probablemente con sus propias branches (p.e. entregas a tal y cual fecha -se puede hacer con un tag-, estable, inestable, etc. ).
  • A diferencia de los de equipo, feature-complete.
  • Sirve para *integrar* el curro de los equipos: Aquí aplicamos control de calidad, los responsables de equipo (o team leaders que suena como más pijo) nos encargamos de mergear lo que sea, Mario controla que funcione como deba. El caso es que solo entre el código funcionando y se mantenga así lo más posible.
  • Sería como un branch "de integración".
  • nuevo: Usamos dos niveles de integración: en testing nos dedicamos a control de calidad y estabilizar código, mientras que unstable es para mezclar código entre repositorios separados y poder probarlo integrado. Todos los repositorios de equipo, por tanto, heredan de unstable y son mergeables con él.

Justificación

Como digo todo esto es un poco teórico porque no sé seguro si bazaar nos dejará hacerlo todo, pero creo que al menos sí bastante de ello. Así todo junto parece un follón, pero es solo para aclararnos. A la hora de la verdad se podría trabajar contra el checkout del team como quien curra con subversion, y solo hay problemas a la hora de integrar cambios entre todos. La contrapartida es que los desarrollos son separados, no hay problemas de tu-cambio-ha-roto-nuestro-código-en-otra-parte, etc.

Para entendernos: a la hora de la verdad, puede quedar en que tú subes tu código al branch de tu equipo, y luego solo nos peleamos un poco más los responsables con bazaar para integrarlo. Que es, por otra parte, quienes han confirmado que están dispuestos a trabajar así (al fin y al cabo somos quienes sufrirán un poco más para integrarlo). Para mayores problemas, recurriremos a Adrián como director de integración, o a Ezequiel como persona más informada en la tecnología.

Las ventajas de tener todo en launchpad es que cuando hay bugs se pueden relacionar con *todas* las partes afectadas por un bug a la vez (p.e. tu branch personal si trabajas con bazaar, a la vez el branch del equipo, y el proyecto que es donde apareciese). Puedes arreglar en *un* sitio y propagar los cambios a *todos*, o arreglar diferente en "estable" (con un parche cerdo XD) y en "inestable" (cambiando en plan serio lo que hubiese que cambiar). IDEM para peticiones de features, o lo que sea. Y el bugtracking así es más sencillo.

Otras "historias" de esto pueden ser p.e. que un equipo necesite un feature de otro equipo y estén ocupados con alguna otra prioridad, o lleve mucho tiempo implementarlo. Puedes o bien pedírselo amablemente, o bien implementarlo tú lo mínimo posible para que funcione y luego en el merge quitar tu implementación (ya bien sea en el merge hacia-proyecto o pillando trozos del código del otro equipo cuando está funcionando ya), o incluso implementarlo tú entero y que luego sea el equipo "responsable" de ese código el que lo pille de tu branch y lo mergee con el suyo.


Estándar de código

Consideraciones generales sobre el código

  1. El código se escribirá íntegramente en inglés a fin de mejorar la distribución de nuestro proyecto como software libre.
  2. Los identificadores no deben contener más de 15 caracteres y deben ser lo más significativos posible.
  3. El código se sangrará adecuadamente y siempre mediante uso de tabuladores.
  4. El desarrollador debe perseguir la eficacia de su código, sometiendo esta a los criterios de legibilidad y eficiencia. En este orden. Es decir, que funcione bien, que cualquiera lo pueda entender y, por último, que funciones rápido.
  5. Los que uséis eclipse, al crear un nuevo proyecto, marcad la opción python 2.4 (la que hay en los laboratorios) o, si usáis otro editor, procurad no usar features de python 2.5
  6. Para el tema de licencias: hay que incluir en la cabecera de cada archivo nuevo:
#Copyright (C) 2008 autores-del-código

#This file is part of HDLorean.
#
#HDLorean is free software: you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation, version 2 of the License.

#HDLorean is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#GNU General Public License for more details.

#You should have received a copy of the GNU General Public License
#along with HDLorean.  If not, see <http://www.gnu.org/licenses/>.

Clases

  1. Los nombres de las clases siguen la convención UpperCamelCase.
  2. Las clases deben incluir comentarios Doxygen indicando su función, autores y responsables de mantenimiento.
  3. Se declararán en primer lugar los miembros privados, y en segundo lugar los públicos.
  4. De la misma manera, se declararán previamente los atributos y posteriormente los métodos.
  5. Se aconseja declarar los constructores y destructores antes que cualquier otro método público.

Miembros de clase

  1. Todos los miembros de clase, tanto públicos como privados siguen la convención lowerCamelCase. precedidos de guión bajo "_". (Por ejemplo, _privateMethod() o _privateVar)
  2. Todo miembro debe incluir comentarios Doxygen. Los siguientes campos son obligatorios:
  • Descripción breve. Se seguirá la convención propia de Javadoc, por la cual se considera descripción todo aquello que se encuentre antes del primer punto.
  • Descripción detallada.
  • Autor/es.
  • Parámetros de entrada (si procede).
  • Parámetros de retorno (si procede).
  • Excepciones lanzadas (si procede)
  • Referencias a otros métodos involucrados (si procede).

Comentarios

  1. Los comentarios que conforman la documentación del código, se escribirán íntegramente en Inglés. Quedan exentos de esta regla aquellos con carácter temporal.
  2. Los comentarios deben otorgar una descripción clara y concisa sobre la entidad descrita.
  3. El código sin comentarios no será aceptado y se devolverá al autor para que lo comente adecuadamente.
Convenios adicionales sobre comentarios

Algunos grupos de desarrolladores, como KDE, utilizan algunos convenios para marcar partes del código que necesitan ser revisadas más adelante.

1.- Fixme

Indica que el código debe ser arreglado, puesto que el actual o bien no funciona correctamente, o bien no es legible, o bien no cumple el estándar de código establecido.

 // FIXME: breve descripción de por qué hay que arreglarlo

2.- Remember

Indica algo que debe recordarse acerca de un fragmento del código.

 // REMEMBER: breve descripción del recordatorio

3.- TODO

Indica alguna tarea pendiente de implementación.

 // TODO: Breve descripción de la tarea por hacer
Convenios adicionales para comentarios C++

Para comentarios en línea, se hará uso de la forma:

// Comentario de linea

Para comentarios de bloque se hará uso de la forma:

/* Comentario de
    bloque
*/

Para comentarios Doxygen se hará uso de la forma:

/**
    Comentario de
    documentación Doxygen
*/

Excepciones

  1. Las excepciones suponen un deterioro del rendimiento, pero son necesarias en proyectos grandes como HD Lorean para gestionar de manera controlada situaciones excepcionales o errores.
  2. Todas las funciones que lo precisen deberán usar excepciones
  3. El desarrollador del método creará las excepciones que sean necesarias para el buen funcionamiento de su código.
  4. Se desaconseja el uso de métodos cuyo valor de retorno sea el estado de éxito o fracaso de la operación. Para este tipo de situaciones es preferible hacer uso de excepciones.

Optimizaciones (Regla de Oro)

  1. No optimices…
  2. …todavía. (sólo expertos)

Estructura del wiki

  • doc (categoría, pero no página): documentación relativa al proyecto concreto HD Lorean (arquitectura, casos de uso, etc).
    • doc:printable: Página que incluye todo. Conforma la entrega final de Junio, así que incluye incluso las entregas parciales (para dejar constancia de nustro trabajo). Para ello, hace includes de varios niveles (por ejemplo incluyendo gestion solamente, que a su vez incluye las planificaciones y demás), lo que simplifica su complejidad y reduce su tamaño.
    • doc:printable-MES: Hay un printable por entrega desde Noviembre. Como mínimo, incluyen la planificación de la iteración siguiente, y el seguimiento de la de ese mes; también incluyen las páginas nuevas creadas durante esa iteración. No van incluidas en la entrega final (porque sería duplicar trabajo); no obstante, podemos entregarlas aparte como complemento a esa documentación "integrada".
  • gestion: documentación relativa a la gestión del proyecto, que sería reutilizable para futuros proyectos del grupo de desarrollo. Estándares de código, dónde está todo en el wiki, criterios de calidad, planificación seguida, etc.
    • gestion:estandares: Centralización de los principales estándares seguidos.
    • gestion:planificacion-fase: Quién hace qué y cuándo, ideas a grosso modo de cómo trabajaremos durante el mes. Con enlaces (pero no includes) a las iteraciones.
    • gestion:planificacion-iteracion-MES: Planificaciones concretas para cada mes.
    • gestion:seguimiento: Seguimiento general del proyecto (del plan de fase).
      • gestion:seguimiento-mes: seguimiento de cada iteración individual.
  • tutoriales: documentación interna para la formación del personal en las distintas tecnologías.
  • template (categoría): Plantillas útiles para crear paginas que se quiera consistentes entre sí (cada doc:printable, cada planificacion-iteracion-mes, etc).

[]


Software Capability Maturity Model

Introducción

El Capability Maturity Model es un modelo de la madurez de los procesos de una organización, para evaluar las capacidades efectivas de desarrollo que tendrá dicha organización y poder predecir con mayor precisión sus éxitos en futuros desarrollos, mejorando al tiempo los puntos débiles de dichos procesos. Aunque ha sido sustituido recientemente por el Capability Maturity Model Integration, por estar muy extendido y sernos requerido haremos el estudio de nuestra organización respecto al original.

Referencia: apuntes de la asignatura, y wikipedia.


Nivel 1

Objetivos

Los procesos en el nivel 1, el punto de partida, están generalmente indocumentados y son implícitos, o bien no se siguen por parte del personal por desconocimiento u otras razones. Aunque es posible el desarrollo exitoso de proyectos, nada garantiza futuros éxitos.


Nivel 2: repetible

Objetivos

La base del nivel 2 del Software Capability Maturity Model, el cual debemos alcanzar necesariamente como requisito del curso, es que el proceso sea repetible, esto es: que el proceso seguido de creación del producto o proyecto permita generar futuros productos de un modo similar, convirtiendo su resultado en algo repetible y no fruto de la casualidad.

Aunque en el nivel 2 la disciplina de procesos pueda no ser rigurosa, se intenta seguir los procesos existentes siempre, incluso en situaciones de presión (entregas, exámenes, etc).

Es importante reseñar que en este nivel aún hay un importante riesgo de exceder las estimaciones de coste y de tiempo en futuros proyectos, al no existir revisiones de los procesos que los mejoren (y a las estimaciones).

Áreas clave de proceso

Gestión de requisitos
  1. Tenemos requisitos y especificación de lo que queremos, para saber hacia dónde orientamos el desarrollo y el trabajo que queda.
  2. Los planes, productos y actividades se mantienen consistente con esa especificación, aunque nos falta un proceso más definido de revisión (que no se requiere para nivel 2).
Planificación de proyecto
  1. Las estimaciones están documentadas y son reales. Se basan en alcanzar un compromiso entre estimaciones bottom-up (lo que los desarrolladores estiman que van a poder hacer, dados sus compromisos) y top-down (lo que consideramos imprescindible de la aplicación que debe estar en cualquier caso), y de momento funcionan con bastante exactitud, habiéndonos mantenido fieles al plan de fase y a la estimación de alcance durante las últimas iteraciones.
  2. Las planificaciones donde se detallan los compromisos del personal están documentadas en los planes de iteración y fase.
  3. El personal se lee los planes y está al corriente de los mismos. Es debido a que la planificación la realizamos siempre con el máximo número posible de miembros del personal, avisando además por lista de correos cuando se actualiza para que la gente sea consciente de sus obligaciones y planificaciones para el siguiente mes, por ejemplo si no pudieron estar presentes en la planificación.
Seguimiento de proyecto
  1. El seguimiento se contrasta con las planificaciones anteriores al realizar la siguiente, imprescindible para saber qué queda por hacer de lo que debiera estar hecho, además de para permitirnos estimar mejor los tiempos de desarrollo.
  2. Se toman acciones correctivas; al hacer los nuevos planes de iteración se tiene en cuenta qué ha fallado y por qué, y de ser necesario (complejidad inesperada, problemas de personal, etc) se replanifica.
  3. Si hay cambios en las responsabilidades, son de mutuo acuerdo por todo el mundo y por las partes. Es debido a que somos todos conscientes de que somos un grupo reducido de personal, y no hay otro modo de sacar el proyecto adelante.
Subcontratas

No aplicable para nuestro caso.

  1. El contratista elige subcontratas cualificadas.
  2. Ambos están de acuerdo con sus compromisos.
  3. Mantienen comunicación.
  4. El contratista comprueba si la subcontrata cumple los compromisos adquiridos.
Garantías de calidad
  1. Hay planificadas actividades de control de calidad desde las últimas iteraciones, así como procesos automáticos de revisión de la misma mediante pylint.
  2. Se verifica objetivamente que todo cumple los estándares, procedimientos y requisitos desde las últimas iteraciones (centradas en esto mismo).
  3. Los individuos afectados son informados de las actividades de calidad y los resultados. Cuando se detectan problemas de calidad se advierten al responsable, y además hay responsables definidos de cada área.
  4. Cuando se falla algo en calidad y no se sabe resolver se decide desde arriba qué hacer. Contamos con cierta jerarquía y proceso de decisión, aunque algo horizontal, que nos funciona por el escaso número de jefes que tenemos.
SCM (Gestión de configuración de software)

Se entiende por configuración de proyecto al conjunto de documentos y material relativo al proyecto en un momento (especificación, diseño, código y pruebas); la gestión de dicha configuración se refiere por tanto al mecanismo de control de cambios (sea de requisitos, de documentación, de código, etc).

  1. Hay. Existe control de código y de su migración entre versiones más o menos inestables (parecido a los baselines). Hay baselines, responsable de releases y de su mantenimiento, y un proceso de testeo manual para decidir cuándo establecemos un nuevo baseline (generalmente, tras la entrega de un baseline y los últimos bugfixes para dejarlo realmente estable).
  2. Existen versiones del software más o menos establecidas, una por release, que pueden obtenerse individualmente.
  3. Los cambios al software están controlados. En nuestro caso, solo están controlados los de código y documentación con control de versiones, no los de arquitectura (pero estos últimos no han sido necesarios, y pueden considerarse como parte de la documentación).
  4. Los grupos afectados están informados del estado y el contenido de los baselines. Antes de cada release se deja claro qué pretendemos que esté, y mientras trabajamos sobre ella mantenemos información sobre el estado de la misma para saber qué problemas son responsabilidad de cada quién.

Nivel 3: definido

Objetivos

En este nivel el proceso de desarrollo no solo es repetible sino que está claramente definido y establecido, y es susceptible de mejorar. Los procesos existentes se usan para conseguir consistencia, y se personalizan para cada proyecto (en nuestro caso, el modelo de desarrollo seguido sería válido para cualquier otro proyecto solo cambiando temas de grupos concretos encargados de subsistemas).

Áreas clave de proceso

Foco del proceso
  1. El desarrollo del proceso y sus mejoras subsiguientes están coordinadas a través del grupo. Aunque el proceso de mejora de procesos sea algo informal y que responda a cómo observamos, algo intuitivamente y poco cuantitativamente, que se comporta el mismo. Los procesos se discuten entre varias personas siempre, y se descartan cuando no son efectivos para el proyecto para poder agilizar nuestro desarrollo.
  2. Identificar ventajas / inconvenientes de cada proceso es algo que ya hacemos por tanto.
  3. Si bien gozamos de poco tiempo, se planifican mejoras del proceso a cada iteración conforme se detectan aspectos que pueden optimizarse en el mismo, o nuevas necesidades que cubra un nuevo proceso.
Definición de procesos
  1. Existe un proceso de desarrollo y se mantiene según detectamos problemas en el mismo (por ejemplo, la decisión de un repositorio donde estabilizar las releases sin aceptar features nuevas).
  2. Pendiente Se obtiene y distribuye información sobre el uso de este proceso (solo informalmente).
Formación
  1. Hay planificadas actividades de formación del personal, centralizadas en los tutoriales.
    1. Justificadas por el uso de tecnologías nuevas para todo el grupo (como el propio control de revisiones o el lenguaje de programación usado), que, investigadas por un grupo o individuo, son luego explicadas al resto del personal.
    2. Justificadas asimismo por la incorporación de personal al grupo.
  2. Se provee de materiales de educación para la formación del personal relativo a la gestión del software (por ejemplo bazaar para el control de versiones).
  3. Los individuos en el grupo de ingeniería del software también reciben formación adecuada (mediante otros tutoriales como sqlite, así como formación horizontal entre compañeros, y las clases propiamente dichas de la asignatura).
Gestión integrada de software
  1. El proceso de desarrollo de software es una versión a medida del estándar de desarrollo (debido a que el estándar ha surgido en paralelo al proceso concreto).
  2. Pendiente el proceso relativo al proyecto se planifica y gestiona sobre el estándar. No es posible dado que no hemos contado con un estándar predefinido del que partir antes de definir nuestros procesos, si bien teníamos ideas sobre "mejores prácticas" a seguir como el control de versiones en todas partes, o la gestión de releases.
Coordinación entre grupos
  1. Pendiente (parcial) Los requisitos del cliente son aceptados por todos los grupos. Si bien los requisitos se discutieron al inicio, los requisitos del cliente pueden estar algo olvidados por parte de los grupos de trabajo, y necesitar nuevo consenso.
  2. Los compromisos de los distintos grupos están acordados entre todos (ya que se planifica también entre todos).
  3. Los propios grupos identifican, siguen y resuelven los problemas entre ellos.
Peer review ("revisión entre iguales").
  1. Hay planificadas revisiones por parte de otros grupos del trabajo de cada uno para la última iteración, como parte de la mejora de calidad.
  2. Los defectos en el software son identificados, seguidos en el bugtracker y eliminados.

Nivel 4: gestionado

Objetivos

En este nivel se controlan con diversas métricas los procesos seguidos, para conseguir adaptarlos a los proyectos concretos sin desviarse significativamente de los objetivos.

Áreas clave de proceso

Gestión cuantitativa de procesos
  1. Pendiente Hay planificadas actividades de gestión cuantitativa de procesos.
  2. Pendiente Se controla cuantitativamente el rendimiento de los determinados procesos de desarrollo.
  3. Pendiente se conocen cuantitativamente las capacidades de desarrollo del grupo.
Gestión de calidad del software
  1. Hay planificadas actividades de gestión de la calidad del software (orientadas hacia el mantenimiento).
  2. Pendiente Hay definidos objetivos medibles en la calidad, y también sus importancias relativas.
  3. Pendiente Se cuantifica el progreso seguido hacia esos objetivos.

Nivel 5: optimizado

Objetivos

Llegados al último nivel, el objetivo es encontrar mejoras aplicables a los procesos (que ya son medibles merced al nivel 4). En particular, es posible mediante adaptaciones de los procesos no desviarse de las planificaciones y costes estimados.

Áreas clave de proceso

Prevención de defectos
  1. Pendiente Hay planificadas actividades de prevención de defectos.
  2. Las causas más comunes de defectos son identificadas (aparte de mediante la experiencia del trabajo común, mediante herramientas que detectan causas comunes como copy-paste).
  3. Se eliminan sistemáticamente dichas causas.
Gestión de cambios tecnológicos
  1. Pendiente Se planifica la incorporación de cambios tecnológicos.
  2. Las nuevas tecnologías son evaluadas para determinar su efecto sobre calidad y productividad. En nuestro grupo de desarrolladores hay bastantes que siempre experimentan con últimas tecnologías de por sí, así que encontrar algunas que sean aplicables al proyecto es casi natural.
  3. Las tecnologías nuevas apropiadas se incorporan a lo largo de la organización. Para ello ayudan dichos "early-adopters", habiendo localizado ya los problemas más comunes con las mismas durante su uso de las tecnologías.
Gestión de cambios en los procesos

Nos es posible obtener alta puntuación en este campo por ser un grupo pequeño y flexible de desarrolladores.

  1. Se planifican cambios continuos a los procesos.
  2. Toda la organización participa en la mejora de los procesos.
  3. Se mejoran continuamente los procesos, tanto el estándar como los de los proyectos.

Riesgos

Gestión de riesgos del proyecto.

Tabla de riesgos

Resuelto Nombre Tipo Descripción Probabilidad Consecuencias Prioridad de solución
S Capa de dispositivos heterogénea Proyecto Las APIs de almacenamiento de snapshots son muy heterogeneas Muy alta serias Media
N Nadie contrata almacenamiento Negocio Nadie contrata la opción de guardar los backups en el almacenamiento extra Muy alta serias Baja (actualmente nuestra prioridad es la aplicación, y no el modelo de negocio que pudiera desarrollarse alrededor)
S Parones temporales Proyecto Parones en el trabajo debido a puentes o exámenes Alta (pero predecible) serias Alta
D Limites de Rdiff Tecnológicos Los límites que imponen en los path pueden causar problemas Alta serias Alta
S Falta organización Negocio Falta de coordinación entre los miembros del equipo Alta muy serias Alta, estamos en ello
N No dominar nautilus Tecnológico No conseguir integrar el programa en nautilus Alta tolerables Media
N Costes almacenamiento Negocio No sale rentable mantener el servicio de almacenamiento extra Alta serias Baja (a priori, consideramos el trabajo sobre las características del modelo de negocio secundario. Además es un problema que, si está resuelto a nivel usuario individual, facilitaría su resolución a nivel almacenamiento compartido)
S Falta de herramientas UML Tecnológico No hay herramientas de UML para python Media serias Muy Alta
S El equipo no rinde Proyecto La gente pasa del proyecto y se retrasa por falta de trabajo Media muy serias Muy alta
S El programa no funciona en los laboratorios Proyecto Los ordenadores del laboratorio no tienen las tecnologías o permisos necesarios Media catastróficas Muy muy alta (surgirá en cuanto empecemos a desarrollar código)
S No nos aclaramos con launchpad Tecnológico El launchpad nos da problemas y no nos aclaramos con el(machacamos cosas útiles y rompemos repos). Media seria Alta
N El profesor suspende una entrega Proyecto No gusta el desarrollo seguido Media serias Alta
D Rdiff-backup no cubre los casos de uso Tecnológico Rdiff no nos proporciona la funcionalidad deseada Media criticas Alta
N Programa con funcionalidad insuficiente Producto El programa se queda corto en cuanto a funcionalidad. Media tolerables a serias (según cuánta funcionalidad falte, y cómo de crítica resulte) Alta
N Demasiado lento Producto El programa ralentiza en exceso la CPU o memoria, o es demasiado lento haciendo backups Media (muchas escrituras) serias (el programa no sería demasiado usable) Media
S Nos llevamos mal Negocio Discusiones dentro del equipo, faltas a las reuniones… Media muy serias Baja
S No hay conexión a internet Proyecto Se cae el servicio y nos quedamos sin forma de trabajar durante un periodo de tiempo Media tolerables Baja (ajena a nuestro control)
N Se cae el servidor de almacenamiento Negocio El servidor de almacenamiento extra se cae y provoca el enfado de los usuarios Media muy serias a catastróficas (según consecuencias de la caída) Baja
N Ocupa demasiado espacio Producto El programa o sus backups ocupan demasiado espacio en disco. Media (a priori no lo sabemos pero tenemos el limite impuesto por el laboratorio) tolerables Baja
S Integración con bazaar Tecnológico Alta probabilidad de romper repositorios a la hora de usar bazaar. Media tolerables Baja
N Problemas con FAT32 Tecnológico Posibles problemas con los limites que establece el sistema de archivos FAT32 Media serias Media
S Arquitectura mal diseñada Tecnológico Hemos hecho mal la arquitectura y hay que realizar cambios. Media criticas Media
S No dominar sqlite Tecnológico No conseguir dominar sqlite Media tolerables Media
N No llegar a dominar Fuse Tecnológico No conseguir dominar Fuse Media tolerables Baja
N Se corrompe un backup Producto Un backup del programa se corrompe Baja catastróficas Esperemos tener el proyecto avanzado cuando pase
S El programa no es fiable Producto El programa tiene problemas al ejecutar y es inestable, posiblemente corrompe backups. Baja catastróficas Muy alta
N Wiki se cae Proyecto El wiki se cae y no podemos acceder a lo guardado en él o utilizarlo para seguir documentando Impredecible (Baja) serias / muy serias (según el tipo de caída, temporal o permanente, y si se pierden datos) Muy alta, lo primero que vamos a solucionar.
S Problemas de personal Proyecto Enfermedades, deserciones de la asignatura, etc. Baja tolerables Baja (Siendo pocos una deserción es más crítica, ya que necesariamente estamos más especializados, lo que aumenta el riesgo)
S No dominar GTK Tecnológico Nadie domina GTK en el grupo de trabajo Baja Muy serias (una interfaz usable es crítica para el éxito del proyecto) Alta
N Programa difícil de usar Producto El programa es demasiado complicado de utilizar para el usuario medio, o poco intuitivo, o no es predecible y las opciones no hacen lo que se esperaría. Baja serias Media/Alta (si es demasiado complicado de utilizar el usuario no lo usará; si es impredecible el usuario achacará -con razón- el uso incorrecto a los desarrolladores)
S No llegar a dominar Python Tecnológico No llegamos a dominar Python Baja Serias Alta
N No llegar a dominar beagle Tecnológicos Nadie domina beagle en el grupo de trabajo Baja tolerables (la integración con beagle no es crítica para el éxito del núcleo del proyecto, es funcionalidad adicional) Media
N Incompatibilidad de horarios Negocio Los horarios nos impiden reunirnos todo lo que nos gustaría Baja tolerables (según el grado de incompatibilidad) Media
N Falta de tiempo Proyecto El tiempo para realizar el proyecto se nos queda corto Baja tolerables a catastróficas (en función de en qué punto del desarrollo del proyecto nos quedásemos) Media
S No dominar dbus Tecnológico No conseguir manejar el uso de dbus (sistema de comunicación interproceso) Baja serias (dificultaría la separación backend-frontend) Media
S No dominar distutils Tecnológico No conseguir manejar el uso de distutils (tecnología de instalación de python) Baja serias Media
N Problemas con inodos Tecnológico El número de inodos posibles en un sistema de ficheros está limitado, y si no se tiene cuidado podemos toparnos con él. Baja serias Media
N No llegar a dominar HAL Tecnológico Nadie domina HAL en el grupo Baja poco serias Baja
N El repositorio se cae Proyecto El servidor donde alojemos el código se cae Baja insignificante insignificante
S No llegar a dominar inotify Tecnológicos Nadie domina inotify en el grupo de trabajo Muy baja muy serias (componente crítico para que el conocimiento de qué es necesario archivar sea eficiente) Alta
N Falta de material Proyecto No hay suficiente material para entregar por falta de tiempo Muy baja serias Baja

Comentarios:


Tabla de planificación de riesgos

Nombre Planificación
Capa de dispositivos heterogénea Uso de una factoría para homogeneizar la API.
No llegar a dominar HAL Investigar y comprobar si nos permite usarla para alguna funcionalidad de nuestra aplicación
No llegar a dominar Fuse Investigación de esta herramienta y ver qué nos puede proporcionar
Problemas con FAT32 Informarse sobre los límites de los sistemas de archivos en general y ver en qué nos puede afectar
Falta de herramientas UML Localizar herramientas que cubran, en teoría, ambas funcionalidades. Queda comprobar hasta qué punto lo hacen y familiarizarse con ellas.
Límites de Rdiff Investigar el alcance de ese riesgo y actuar en consecuencia. Los desarrolladores de rdiff-backup parecen tenerlo solucionado
Rdiff-backup no cubre los casos de uso Profundizar en la investigación y averiguar con certeza máxima su utilidad para nuestra aplicación. Cambiar a otro software o hacer que su wrapper supla la falta de características del mismo.
El wiki se cae A. Utilizar un medio secundario para almacenar la documentación y realizar backups periódicos. Trabajar durante las caídas sobre medios alternativos que permitan edición concurrente como google docs.
B. Migrar el contenido del wiki (perdiendo la historia y posiblemente el formato) a una solución albergada por el equipo. Conlleva coste de administración, pero podríamos replicarlo en varios servidores privados
No llegar a dominar Beagle Estudiar su funcionamiento a fondo desde ahora. Alternativamente, no integrar búsquedas con contenido con nuestro proyecto.
Nos llevamos mal Intentar cuidar las formas a la hora de relacionarnos. Realizar actividades comunes no académicas como ir de cañas.
Falta organización Coordinarnos en subgrupos más manejables. Reparto de tareas más granular para poder subdividirse entre el número de personas. Establecer calendarios de trabajo.
El programa no funciona en los laboratorios Tener en cuenta los recursos de los laboratorios a la hora de ir desarrollando; o bien se desarrolla contra esa base de código (nautilus, etc) ligeramente obsoleta, o bien será necesaria una fase de backporting de cambios y cierta planificación para evitar incompatibilidades severas.
No llegar a dominar inotify Estudiar a fondo el funcionamiento de esta funcionalidad del kernel; posiblemente seguir ejemplos de proyectos diferentes que lo utilicen, como Rhythmbox
No llegar a dominar Glade Estudiar a fondo el funcionamiento de esta utilidad. Alternativamente, codificar las interfaces a mano sin un editor de las mismas. Ralentizaría bastante el desarrollo de la interfaz.
No hay conexión a internet Utilizar control de versiones distribuido que permite trabajar sin conexión (Bazaar). Generar la documentación offline en un solo ordenador, o utilizar herramientas de edición en red concurrentes. Cuando se recupere la conectividad, volcar de nuevo el contenido.
El repositorio se cae Utilizar control de versiones distribuido que permite trabajo offline e intercambio de cambios sin depender de un servidor central.
Falta de tiempo Intentar optimizar el tiempo disponible; separar el desarrollo en componentes lo más independientes posibles e intentar priorizar de más a menos crítico
Se corrompe un backup Tener alguna copia actualizada en algún equipo
Ocupa demasiado espacio Mantener un estudio del espacio que ocupa e intentar mejorarlo en el caso de que sea necesario. Buscar mejores codificadores de diferencias binarias (deltas).
Demasiado lento Una vez funcione el programa, optimizarlo. Estudiar alternativas a nivel de sistema de ficheros como ZFS, y tenerlo en cuenta en el diseño de componentes para una posible futura adición. Buscar alternativas a rdiff-backup (o desarrollar nuestro gestor de snapshots). Minimizar la resolución de los disparadores como Inotify o Cron
Programa difícil de usar Una vez haya una interfaz, trabajar con usuarios ajenos al proyecto y estudiar usabilidad sobre ellos.
Programa con funcionalidad insuficiente Separar en componentes y priorizar el desarrollo de los mínimos y críticos para el éxito del proyecto, dejando la funcionalidad adicional a priori por implementar.
El programa no es fiable Buscar la fiabilidad máxima desde el principio del desarrollo, usar suites de pruebas.
Nadie contrata almacenamiento Prever que esta situación se puede dar, asumir los menos gastos de negocio posibles para reducir pérdidas.
Costes almacenamiento Buscar un almacenamiento de coste asumible (servidores RAID de discos económicos), minimizar en lo posible el almacenamiento necesario, externalizar a backups en cinta (menor coste / GB) los datos poco usados por el cliente informándole de que recuperaciones de más de un cierto tiempo requerirán un cierto tiempo adicional.
Se cae el servidor de almacenamiento Tener la máxima redundancia rentable y protocolos para evitarlo en lo posible, manteniendo la rentabilidad del modelo de negocio.
El equipo no rinde Motivar para que todo salga adelante lo mejor posible, intentar optimizar el trabajo lo máximo posible
Parones temporales Llevar el trabajo al día; prever entregas y parones y tener el trabajo preparado antes de exámenes.
Falta de material Asegurarnos de que traemos siempre lo necesario
No nos aclaramos con launchpad Estudiar a fondo el funcionamiento de este repositorio
Incompatibilidad de horarios Trabajar con el que mayor grado de compatibilidad tenga, separar el trabajo en subgrupos y limitar las reuniones a los jefes de subgrupo para integración. Utilizar medios alternativos de comunicación (wiki, correo electrónico, mensajería instantánea) para no necesitar tanto reuniones en persona.
No dominar GTK Estudiar a fondo esta tecnologia gráfica. Alternativamente, limitarnos a una interfaz de consola para el programa (lo que disminuiría su calidad notablemente).
No dominar nautilus Estudiar el funcionamiento del explorador de Linux y las posibilidades de integración con el mismo a partir de proyectos diferentes. Alternativamente, renunciar a la integración y limitarse a una interfaz independiente de programa.
No dominar dbus Estudiar el funcionamiento de dbus a partir de proyectos diferentes. Alternativamente, desarrollar otro método de comunicación entre el backend de almacenamiento y los diversos frontend gráficos posibles (nautilus, interfaz independiente, consola, etc).
El profesor suspende una entrega Estudiar causas del fracaso e intentar corregirlas para realizar el desarrollo de la forma pedida
Problemas de personal A priori se reparten las áreas de trabajo por competencias, pero intentando documentar lo máximo posible en el wiki sobre tecnologías concretas a fin de poder retomar el trabajo de un miembro que faltase si fuera necesario. Además, no se deja a nadie solo frente a un área concreta, y se adoptarán estándares de documentación de código para el mantenimiento que fuera necesario.
Integración con bazaar 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.
Problemas con inodos Probar exhaustivamente y con casos extremos la aplicación.
No dominar sqlite Buscar una alternativa, como MySql.
Arquitectura mal diseñada. Revisar el proceso e insertar los cambios necesarios.
No dominar distutils Buscar alternativa a esta tecnología.

Necesidades tecnológicas

Lista de Software Necesario para hacer funcionar y desarrollar HD Lorean en los laboratorios de la facultad.

Crítico

  1. sqlite3
  2. libsqlite3-dev
  3. libsqlite3-0
  4. python-pysqlite2
  5. glade (versión >=3)
  6. glade-gnome (versión >= 3.4.0.2)
  7. gnome >= 2.20
  8. python-pyinotify
  9. rdiff
  10. python-nautilus
  11. libnautilus-extension1
  12. python-fuse
  13. libfuse2
  14. python2.4-dbg
  15. beagle
  16. rdiff-backup
  17. xdelta

Deseable

  1. python 2.5
  2. python2.5-dbg
  3. sqlite3-doc
  4. bzr
  5. pydev plugin de eclipse para python
  6. plugin de eclipse para modelado UML
  7. Plugin de eclipse para generar código python desde el uml.
  8. mkisofs
  9. wodim
  10. genisoimage
  11. tracker
  12. xdelta3

Estimación de costes

Estimación aproximada

Una sola persona a tiempo completo tardaría 3 años
~ 36 * (1 persona 1 mes)

Estimación por líneas de código

Optimista: 11000
Exagerada: 25000
Estimación (caso medio): 15000

Fórmula = (optimista + 4*estimación + exagerada)/6
(11000+25000+15000*4)/6 = 25.806 ~ 26 persona mes

Estimación por líneas de código y módulos

Modulo Optimista Estimación Exagerada Fórmula
Intefaz 3000 10000 20000 10500
Consola 300 400 800 450
Watcher 2500 3200 6000 3550
Snapshot-core 500 1500 20000 4416,67
DB 800 1400 2500 1483,33

Fórmula = (optimista + 4*estimación + exagerada)/6
Total estimación líneas de código = 20399
Total/620 => 20399/620 = 32,9 ~ 33 persona mes

Estimación por puntos de función

~ 46 persona mes


Planificación de fase

Table of Contents

Planificación de fase

Hitos principales:

  • Octubre: Definición del proyecto, requisitos, casos de uso, riesgos

Al terminar octubre tenemos una idea general de cómo será nuestra aplicación: funcionalidades básicas, planificación sobre cómo llevarla a cabo, límites de hardware, de dispositivos, etc. En definitiva, el ámbito general del proyecto.

  • Noviembre: Investigación principal de tecnologías

Habremos decidido qué lenguaje de programación utilizaremos, al menos para el núcleo del programa, así como las tecnologías de cada uno de los módulos del proyecto, o al menos varias opciones de implementación, para poder elegir más tarde con cual quedarse. Las tecnologías más importantes a investigar son: entorno gráfico que usaremos, tecnologías para el núcleo de copia de seguridad, de base de datos, y de comunicación interna y externa.

  • Diciembre: Prototipo Alpha (prueba de integración)

Se tendrá el núcleo de la aplicación, o al menos ciertos módulos para comenzar a integrar. De este modo tendremos el esqueleto de la arquitectura, con las principales tecnologías investigadas por completo e implementadas para más adelante continuar con funcionalidades menos críticas.

  • Enero: Fase de investigación; procedimiento de integración cerrado.

Subsiguiente prototipo de investigación de tecnologías (comunicación frontend / backend, planificación de tareas), si bien carente de la crítica de backup, restore, eliminación de copias, etc. Finalización del proceso de integración de bases de código distintas, quedando preparadas las metodologias para las fases de desarrollo posteriores.
Los principales riesgos tecnológicos están ya localizados. La arquitectura se ha desarrollado hasta quedar prácticamente cerrada, a falta de algunas apis importantes.

  • Febrero: Repaso de documentación e investigación sobre funcionalidades adicionales

Esta iteración se centrará en documentar los nuevos procesos desarrollados y completar la documentación existente, pero dada la falta de tiempo por los exámenes, se reduce la cantidad de tiempo para el proyecto, con lo que no se esperan grandes avances. Se dedica a la investigación también porque, en nuestra experiencia, los exámenes son época de trastear con las más extrañas tecnologías en los ratos muertos que se debieran aprovechar para estudiar.

  • Marzo: Prototipo Beta (funcionalidad crítica). Replanificación y reevaluación de viabilidad. Reasignación de personal.

Eliminados los riesgos tecnológicos, es necesario replantearse la planificación y la viabilidad de los casos de uso menos importantes para el tiempo existente. Se deberá concluir la construcción de la aplicación y sus funcionalidades críticas, con vistas a poder comenzar cuanto antes el mantenimiento y testeo de esta funcionalidad, que se preve largo; en los tres meses desde Enero la arquitectura está más que fijada y desarrollar debería ser previsible en tiempo y esfuerzo, al contar con prototipos funcionales de todas las tecnologías. Se tratará de avanzar en funcionalidad menos importante (al menos estudiando su viabilidad).
La semana santa dificultará la planificación, en función del personal y su disponibilidad por viajes, prácticas, etc.
Además, se debe tratar de completar lo más posible la documentación, en particular todos los tipos de diagramas UML utilizables en nuestro proyecto, así como identificar patrones de diseño tanto preexistentes en nuestro código pero no explicitados, como susceptibles de ser aplicados.

  • Abril: Beta 2 (funcionalidad decidida completa). Mantenimiento, pruebas de usabilidad con usuario real, optimización en general, pruebas de empaquetado para distribuir.

Completar la funcionalidad ausente en la anterior iteración. Asimismo, preparar el despliegue de la aplicación, y iniciar un proceso de prueba intensiva, lo más automatizada que sea posible y razonable; consumido el margen de tiempo, se debe tratar de testear lo más posible durante el desarrollo de la aplicación -y no exclusivamente en Abril- para conseguir la máxima fiabilidad del programa, lo que es importante para su éxito.

  • Mayo: Release: Empaquetar, y preparar la entrega (diapositivas, vídeo, web, presentación…). Mejorar la calidad todo lo que de tiempo (que será poco por la proximidad de los exámenes).

Perfil de personal

Adri

Administrador de sistemas y hábil en general. Autogestionado. Encargado de la gestión de sistemas del infierno, si se lo propone. Si es fácil, no es para él… C++ -er. Analista en general. Entusiasta donde los haya. Sincero ;). Buen gestor de personal; manejo del látigo eficaz, en particular del de 9 colas, lo que le convierte en el jefe de release ideal.

Carlos

Programador por encargo. Viciado en general. Viajero incansable.

Daniel

Primera baja del proyecto. M.I.A.

David

Databaser. Autogestionado. Programador por encargo bastante rápido; trabaja bajo presión. Asiduo del copy-paste (algo dadaista).

Diana

Analiza tus frases y suelta verdades como puños. Gran consejera. Programadora por encargo.

Eze

Gestor de todo lo gestionable. Maestro en tecnologías varias habidas y por haber. Hijo del bleeding edge (si funciona, actualiza). Capitán diccionario. Analista en general. Arquitecto (le falta la barba blanca solo). Entusiasta pero muy limitado en tiempo.

Fede

Líder nato y relaciones públicas. GNU master. Analista en general. Mejora la moral de la tropa. Hospitalario ^^. Hermano de Eze (por aquello de que también es hijo del bleeding edge). Fuente incansable de ideas a añadir a la apretada agenda.

Jorge

Autogestionado. Programador altamente competente. Tú fast, tú furious.

Mario

Redacta diversos tipos de documentos, observando escrupulosamente las reglas de redacción y ortografía (teniente diccionario, digamos). Programador por encargo. Relajado (paz, hermano).

Rober

Programador por encargo. Mejora notablemente la moral de la tropa. Formateador de cerebros. Currante nato.

Salva

Analista en general. Lead developer estilo ninja (no hace ruido, nadie le ve, pero aparecen sus líneas de código de repente). Master (del universo, digamos). Competente como programador. Entusiasta del proyecto, pero limitado en tiempo. Altamente experimentado. En ocasiones desvaría y hay que meterle en cintura ;) (por ejemplo, con el citado látigo de 9 colas).

Tabas

Programador por encargo. Dbusman y showman en general. Caja de sorprrresas.

Carmen

El nuevo fichaje. Programadora por encargo. Escritora hipermaniática. Friki en sus ratos libres (el resto lo es a tiempo completo)


Planificación iteración Noviembre

Tipo de iteración

Elaboración

Objetivos generales

Investigación I

Investigaremos las tecnologías que puedan ser necesarias para el desarrollo de nuestro código, intentando reutilizar el máximo posible para evitar implementarlo. A fin de ello hicimos una arquitectura preliminar en cuatro módulos:

  1. ui, o investigación de interfaces con el usuario
  2. watcher, o vigilancia de cambios en archivos a fin de guardar las copias de seguridad
  3. bases de datos, por su previsible uso en el almacenamiento del programa
  4. snapshots, o almacenamiento de las instantáneas de archivos que archivamos.
Arquitectura preliminar

Necesaria como se ha dicho en investigación.

Revisión documentación

Revisión de la calidad de la documentación del proyecto, completarla, etc. También se pidieron estimaciones de requisitos no funcionales de tiempo y espacio del proyecto.

Prueba del modelo de organización y tecnologías asociadas

Familiarizar al personal con el modelo de desarrollo propuesto y las tecnologías necesarias como el control de versiones.

Reparto de trabajo

  1. ui: Fede, Carlos, Rober y Tabas
  2. watcher: Jorge, Diana y Adrián.
  3. bases de datos: David
  4. snapshots: Salva y Dani.

Al margen del código, se ha repartido:

  1. gestión de calidad: Mario
  2. gestión de proyecto / wiki: Ezequiel
  3. comunicación con profesor / representante: Fede

Estimaciones de tiempo

No ha habido (se escribe la iteración a posteriori)

Seguimiento

Ver Seguimiento Noviembre


Planificación iteración 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


Planificación iteración Enero

Tipo de iteración

Elaboración


Objetivos generales

Aprovechando que, pese a las fiestas, la iteración de Enero es la más larga (una semana extra) y que en vacaciones hay más tiempo en general, pretendemos llegar al primer prototipo funcional completo de la arquitectura y con ello cerrar la fase de elaboración. Este prototipo debe incluir las funcionalidades mínimas de guardar backups, recuperar backups y listar los presentes mediante un interfaz gráfica además de la de consola; posiblemente se incluya también borrar snapshots, importante para mitigar el impacto en uso de disco de nuestra aplicación.

Además pretendemos fijar con ello la arquitectura del sistema para poder desarrollar el resto de funcionalidades, así como poder repartir mejor el trabajo desde ese momento (ya que, fijadas las interfaces, es más sencillo repartir las clases).

Por último, y como parte del objetivo de desarrollar un interfaz útil, es necesario comenzar el manual de usuario.


Primer prototipo funcional

Para conseguir este objetivo concreto actuaremos en dos frentes: por un lado, concluir una interfaz de usuario funcional, y por el otro reducir al mínimo el riesgo del núcleo de la aplicación (los backups).

Solucionar el riesgo de rdiff-backup

En la iteración anterior se localizaron problemas en este sistema de almacenamiento que suponen un bloqueo para continuar completando la funcionalidad de la aplicación (ver Apéndice A del informe de investigación de snapshot core). Este riesgo es de máxima prioridad para nuestra aplicación y debe ser resuelto en esta iteración, bien completando de algún modo la funcionalidad que nos falta en rdiff-backup para usarla bajo la nuestra, o bien desarrollando nuestro propio sistema de snapshots (lo que aumentará el riesgo mientras se finaliza, así como el tiempo de desarrollo y de comprobación de errores, que debe ser exhaustiva).

Fijar la arquitectura del sistema

Con vistas a poder finalizar la fase de elaboración lo antes posible, intentaremos en esta iteración consensuar una arquitectura del sistema lo bastante sólida y flexible como para cubrir nuestros casos de uso, en base a las interacciones que describimos en el brainstorming y las consiguientes clases y sus interacciones. Será necesario actualizar los documentos de arquitectura existentes, así como describirla en UML. Contamos no obstante con que las necesidades del desarrollo obligarán probablemente a varias revisiones de la arquitectura, quizá prolongándose otra iteración más.

Además, crear un interfaz y probar su usabilidad nos obligará a definir con más detalle la estructura de clases del GUI, por ahora relegada a un segundo plano.

Como ejemplo de la necesidad de este trabajo, la funcionalidad deseada de la clase Watcher aún no está reunida, sino que está distribuida por otros módulos que aún no se ajustan a la arquitectura deseada (por facilidad del desarrollo del prototipo). Se busca en suma evitar este tipo de problemas, que a medio plazo nos pueden limitar mucho y dificultar el trabajo.

UML

Según lo explicado en clase se modelará la arquitectura de clases y sus interacciones mediante diagramas UML. Para ello es necesario familiarizarse con las herramientas, así como localizar aquellas que permitan un flujo de trabajo bidireccional entre código en python y diagramas, para poder reducir el tiempo invertido. Todo ello implicará crear nuevos documentos donde se aclare al equipo el funcionamiento de los programas, así como probablemente modificaciones a los procesos establecidos de trabajo y los estándares, para poder facilitar la integración de código posterior y mejorar el reparto de trabajo, uno de los problemas importantes que se detectaron en la anterior iteración.

Explicitar prioridades de casos de uso

Con vistas a conseguir el prototipo en el tiempo que tenemos, es necesario partir los casos de uso lo más posible en subtareas, y priorizarlas para buscar el camino crítico sin el cual no habrá prototipo alguno. Una vez se tenga explicitado, se debe priorizar el desarrollo de los componentes de ese camino crítico. La importancia de los casos de uso es algo medianamente consensuado en el equipo, pero que aún no ha sido explicitado. En una estimación previa, los componentes sin desarrollar y por investigar más importantes son:

Finalizar gestión de preferencias

La configuración del programa está en una fase avanzada de desarrollo, pero aún no es funcional y probablemente deberá sufrir rediseños en función de problemas de usabilidad que se detecten. Sin embargo, una interfaz mínima que funcione para configurar el programa es importante, y será lo primero que se termine por estar ya muy avanzado.

Tabla de historia

Es una tabla a donde se migra la información de los backups desde el journal (que a su vez es donde se anota qué operaciones hay que hacer cuanto antes, para poder planificarlas y reiniciar transacciones en caso de fallo). Esta tabla necesita información adicional, como dónde se encuentra un archivo (no necesariamente local), su propietario y otros atributos (tamaño, permisos, etc). Toda esa información adicional, que debemos aún concretar, no es crítica para el prototipo pero sí para la funcionalidad de exportar backups, sea a CD o a disco duro externo, por lo que el diseño debe tenerla en cuenta y merece la pena una implementación preliminar de la misma.

Comunicación frontend / backend

Por ahora backend y frontend han seguido desarrollos separados, solo integrándose parcialmente para la demostración de tecnologías de la iteración de diciembre. Es necesario desarrollar la comunicación entre los mismos y también el API, a fin de que ambos equipos de desarrollo puedan probar su código teniendo en mente las necesidades y posibilidades de la aplicación completa, además de que hace falta para completar el prototipo sobre la arquitectura deseada. Para esta parte se utilizará la tecnología dbus de comunicación interproceso, ya investigada parcialmente pero aún sin prototipo funcional; por tanto es también prioritario.

Interfaz de navegación de archivos

Dado que el GUI ya tiene una interfaz de preferencias casi funcional, el siguiente paso necesario para poder demostrar el programa es una interfaz que muestre los archivos con copia de seguridad y permita navegar entre ellos, así como restaurarlos. Ello requiere del anterior punto para usar el backend real y consensuar cómo comunicarse con él, así como de cierto tiempo de desarrollo para terminar de dominar los componentes del toolkit gráfico GTK.

Integración con nautilus

Una de los requisitos funcionales es que la aplicación sea usable para cualquiera, lo que requiere que esté integrada de modo transparente en el uso habitual del equipo. Para ello se decidió que integraríamos nuestro código con nautilus, el explorador de archivos de GNOME, mediante su API de plugins; no obstante la investigación preliminar ha demostrado que apenas hay documentación del mismo. Por ser menos prioritario, se relega el desarrollo de la integración a Febrero.

Integración con Beagle

Beagle permitiría buscar dentro del contenido almacenado en nuestros backups, facilitando mucho el uso del programa e integrándolo aún más. No obstante el riesgo de este desarrollo es mucho menor, requiere en potencia mucho más tiempo y además depende de finalizar el modelo de almacenamiento final de nuestra aplicación, por lo que también queda relegado indefinidamente hasta que se juzgue adecuado.

Tecnología HAL

La tecnología HAL permite detectar dispositivos conectados al equipo y podría ser potencialmente útil para facilitar el uso de un disco duro externo como almacenamiento. Su investigación también queda relegada a una fase posterior, una vez el prototipo permita esa funcionalidad de externalizar la copia de seguridad.

Estimar requisitos de tiempo y espacio de la aplicación

A petición del cliente, trataremos de realizar una estimación del espacio y tiempo que usará la aplicación, que posteriormente iremos refinando conforme se optimice y se concrete más el código.

Nueva documentación.

Algunos de los documentos por escribir que se consideran necesarios para el trabajo son:

  1. Guidelines de código en Python: de cara a la integración. Cómo probar el código, dónde colocar todo, etc.
  2. Manual de integración: una vez se termine de investigar el modo más eficaz de usar el control de versiones distribuido, se debe informar al equipo de cómo se usa para facilitar el trabajo y permitir mejor integración entre grupos separados de desarrolladores.
  3. Guidelines para errores: desde unas directrices sobre qué información generar para logs del programa, hasta una jerarquía de excepciones que usar consistentemente en todo el programa.
  4. Manual de uso de la aplicación.

Reparto de trabajo

Los objetivos de cada grupo son:

  • Documentación: Actualizar la arquitectura preliminar que tenemos según las Interacciones entre clases. Concretar la arquitectura del GUI y documentarla. En general, mantener el wiki actualizado según las exigencias de entregas de Gervás, y concluir la documentación deseada como objetivos. Ezequiel se responsabiliza, y Adrián ayudará como responsable de la integración en la iteración pasada. Además, de sobrar tiempo Ezequiel comenzará la investigación y el desarrollo de manuales sobre la integración de nautilus.
    • Manual de uso: Como depende del GUI lo escribirán ellos.
  • Watcher: Desarrollo de la clase Watcher e inicio del Planner. Adrián es el responsable y reparte trabajo.
    • Adrián: Concluir Watcher. Comienzos de Planner.
    • Diana: Terminar la funcionalidad de crontab y gestionar las peticiones de anacron. Ayudar en D-Bus Manager.
    • Jorge: Concluir funcionalidad de Inotify handler; refinar funcionalidad.
  • GUI: Carlos, Rober y Tabas. Responsable: Rober. Se ocuparán de concluir un GUI con la funcionalidad crítica desarrollada.
  • BBDD: David. Como previsiblemente habrá poco trabajo y es dinámico según le vayan necesitando, ayudará en documentación y en Snapshot manager.
  • D-Bus Manager: Atender a las necesidades del GUI y distribuir trabajo por el backend (previsiblemente a planner). Diana se responsabiliza.
    • Diana: representante de backend que conoce dónde está cada cosa, y esbozará la clase planner junto con Adrián para repartir trabajo por el backend (inicialmente sin lógica de planificación). Ayudada por Adrián en ello.
    • Rober / Tabas: Una vez investigado el modo de uso de dbus, enviarán las peticiones necesarias y recibirán datos del backend para poder presentarlos al usuario.
  • Snapshot: Salva, Fede, David y Mario hasta que se solucione el riesgo, el más importante actualmente. Responsable: Salva, quien asignará trabajo concreto.
    • Realizar estimaciones de tiempo y espacio del almacenamiento para la documentación.
  • Integración de código: Adrián realizó la integración pasada; una vez aclaremos los procesos Ezequiel y David ayudarán.

Estimaciones de tiempo

  • 31 diciembre (+/- 2 días): Terminado preferencias. Guidelines de integración; resueltos los procesos de tirar código ordenado y útil. Tomarse las uvas.
  • 7 enero: Dejar de jugar con los regalos de los reyes. Watcher. Investigación terminada de dbus con prototipos funcionales; clase dbus manager funcionando para poder hacerle peticiones. Prioridad de desarrollo de los casos de uso establecida (lo que condiciona y modifica el alcance); plan más detallado de desarrollo en el seguimiento.
  • 14 enero: Watcher integrado con inotify, cron. UML. Estimaciones tiempo y espacio. Toda la documentación complementaria salvo posiblemente manual de usuario sujeta a revisión del equipo.
  • 21 enero: Primera integración parcial para detectar problemas en el seguimiento de las guidelines y la arquitectura. Cierre parcial de código. GUI funcionando completo, a falta posiblemente de resolver errores puntuales. Finalizar los objetivos a falta de las previsibles correcciones de errores.
  • 25 enero, 14:00: Cierre total de código, comienzo de integración. Cierre de API obligatorio; bugfix únicamente a través de los integradores.
  • 31 enero: entrega.

Como condicionante importante, en Navidades no todo el mundo podrá trabajar: Salva no tiene ordenador y por tanto tiene dos semanas inhábiles, Ezequiel estará fuera una de las dos semanas y tiene bastante carga de trabajo de otras asignaturas, Mario estará fuera, y en general todo el mundo está ocupado con PLG y recuperándose de los excesos navideños, por lo que no serán dos semanas demasiado productivas. Por otra parte, al no tener horas lectivas ni laborales esto se compensará en gran medida y prevemos que cunda.


Seguimiento

Ver seguimiento-enero.


Planificación 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


Planificación 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


Planificación iteración Abril

Tipo de iteración

Construcción


Objetivos generales

En esta iteración buscamos alcanzar un nivel de features suficiente para congelar el desarrollo lo antes posible, y a partir de ahí nos dedicaremos a solucionar todos los errores que detectemos, a mejorar la calidad del código que tenemos para facilitar su mantenimiento, y a mejorar el proceso mismo de desarrollo para aumentar la calidad del código y su robustez. Además tenemos en mente el poco tiempo que queda de desarrollo, y por tanto comenzaremos la investigación final que queda sobre el empaquetado del producto y su distribución final. Sin embargo, también hemos detectado durante las entregas de código una multitud de pequeñas mejoras que iremos aplicando en función de su dificultad, y de cuánto estimemos que pudieran afectar a la robustez del resultado final.

Mejoras en el backend

Pretendemos aplicar numerosas mejoras y ampliaciones sobre el núcleo de la aplicación, ahora que tenemos una base funcionando de la que partir. Posiblemente no haya tiempo de implementarlas todas durante esta iteración por imprevistos del desarrollo, pero dejamos constancia de ellas y se indica su prioridad.

  • Eficiencia: hemos detectado algunos problemas que hacen a la aplicación poco manejable (al margen de su eficiencia algorítmica) afectando a su usabilidad y que requieren solución prioritaria. Las causas que estimamos más probables para estos problemas de rendimiento son:
    • Conexión frontend / backend bloqueante: Como el frontend usa llamadas síncronas, queda esperando para cualquier operación grande de E/S y el resultado "visible" es un bloqueo del GUI. Para solucionarlo pasaremos a usar threads moderadamente. Esto genera una nueva serie de problemas, al tener que considerar si son seguras todas las funciones que puedan estar ejecutándose concurrentemente. Sin embargo en la planificación inicial ya tuvimos en cuenta la posibilidad de que apareciese este problema, por lo que utilizamos bases de datos (inherentemente concurrentes, aunque hemos encontrado bugs en nuestra implementación del wrapper y posibles limitaciones de la tecnología usada que están en proceso de evaluación y solución) y un módulo de planificación de operaciones (scheduler) que será quien implemente inicialmente los bloqueos necesarios para seguir manteniendo el mínimo de operaciones en ejecución garantizadas (en principio una, hasta investigar más a fondo), mientras no mejoremos la implementación para conseguir más granularidad.
    • Expresiones regulares: Por ahora deshabilitadas. El usar expresiones regulares para los patrones de inclusión/exclusión de archivos implica que hay que expandirlas y añadir watches a cada archivo, lo cual es un proceso costoso y lento - en especial para las de inclusión - que además se ejecuta en el arranque o en cada cambio de la configuración. Al margen de investigar su viabilidad para el beneficio que aporta, también procuraremos ejecutar este proceso en un hilo que no bloquee la aplicación, algo a priori perfectamente factible.
  • Consola: Como se indicó en el seguimiento del mes anterior, la consola actualmente no funciona debido a los numerosos cambios en el código durante la primera entrega. Aparte de dejarla de nuevo funcionando, investigaremos formas alternativas de conectarla al backend, pues así evitaríamos depender de D-Bus y la haríamos más resistente a problemas en el sistema, que es precisamente en las ocasiones en que sería más útil.
  • Informe de errores: Durante la anterior iteración ya pusimos en práctica el módulo hdlogger encargado de centralizar todos los logs de la aplicación, así como el informe automatizado para los cierres no esperados. Es necesario por tanto limpiar la aplicación de cualquier print que quede que se haya usado durante el desarrollo, así como completarla con las llamadas necesarias para completar una traza de la aplicación en cualquier punto, lo que nos permitiría depurar más eficientemente. Además queda pendiente la investigación de apport, un módulo de ubuntu que integra el informe de bugs y la recopilación automática de información (trazas, sistema operativo, versiones de software instalado, etc) con la gestión de bugs de launchpad, subiendo automáticamente los archivos a la web del proyecto.
  • Borrado de snapshots: Planificado para esta iteración, es crítico para alcanzar eficiencia en espacio y cubrir el diseño inicial de la aplicación el poder borrar snapshots individuales de modo eficiente y seguro. Esto serviría en un posterior desarrollo, junto con la planificación con Cron de eventos periódicos, para poder "caducar" la multiplicidad de versiones no necesariamente relevantes de los archivos más usados, quedándonos por ejemplo solo con versiones semanales de los documentos cambiados hace un año. Esto requiere, además, de una investigación a nivel de usabilidad para no confundir al usuario, y además haría buen uso y al tiempo facilitaría la posibilidad de externalizar backups (ya que un CD está limitado en espacio también), todavía no desarrollada y que quizás nos quede fuera de alcance debido a la falta de tiempo. Por el momento, por tanto, implementaremos el borrado explícito y manual, dejando el implícito para más adelante si nos es posible.
    • Borrado automático: Si bien no se preve implementarlo, sería interesante investigar las implicaciones de implementar dicho borrado automático en función de varios criterios (fecha, espacio -sugerido en las preferencias-, u otros alternativos como relevancia) en el backend, especialmente para valorar en su justa medida su viabilidad.
  • Sincronización: Se planifica investigar la sincronización con (y exportar a) dispositivos externos: Exportar a CD/DVD y sincronizar con unidades de disco externas. Se investigará desde el momento en que haya versión estable, a partir de segunda quincena.
  • Estimaciones: Aconsejado tanto por sentido común como por algunas pruebas preliminares de los usuarios, necesitamos un feedback más explícito hacia el usuario sobre las operaciones en curso y, especialmente, sobre su estado de terminación. Para ello podemos crear estimaciones, ya sea en tiempo o en porcentaje, a fin de no dar la imagen al usuario de "aplicación colgada" -lo cual, según múltiples estudios de usabilidad consultados, lleva al usuario a creer que su acción no está registrada y a pulsar más veces, con lo que el problema de la espera puede agravarse. Ello implica, además de la ruta de feedback ya creada, de modificaciones en el backend para crear esos porcentajes o estimaciones temporales (que a su vez tienen implicaciones en el caso de realizar varias operaciones a la vez con threads), y mandarlos hacia el GUI. Un posible algoritmo inicial muy ligero en procesamiento para las recuperaciones -el caso más crítico- sería contabilizar el tamaño de disco a recuperar (una simple consulta a la base de datos), y tras recuperar cada archivo informar de cuánto se ha avanzado, de cuánto queda, y del tiempo invertido para poder deducir la tasa de transferencia y con ello estimar el tiempo restante. Además, probablemente necesitemos reincorporar al diseño una de las clases de estadísticas, que apareció inicialmente para centralizar esa información.
  • Refactorizaciones: Hemos localizado varios puntos susceptibles de refactorización para conseguir más limpieza del código, que se tratarán lo antes posible para no dificultar el mantenimiento. En concreto, planificaremos el del módulo XDelta3Wrapper, de los más críticos de la aplicación, así como probablemente los wrapper de la base de datos.
  • Mover directorio de backups: Una de las posibilidades de las preferencias del GUI, de una relevancia media, es mover dónde se van a almacenar los backups. Esto es útil para escoger particiones con más espacio o incluso unidades remotas montadas en el sistema (sincronización con discos externos). Sin embargo requiere de ciertas operaciones aún no implementadas en el backend, ya que ese directorio está deliberadamente ignorado para no entrar en un bucle recursivo (cambio registrado en el soporte físico de la base de datos -> registrar cambio -> genera cambio): hay que pasar a ignorar el directorio destino, mover las bases de datos sin detener la aplicación y, a continuación, volver a añadir los watches a la carpeta origen, que volverá a estar vigilada según se indique en el archivo de configuración.
Mejoras del GUI

Buena parte de las mejoras en el GUI vienen sugeridas por las pruebas con usuarios reales, que obligan a ver los defectos de usabilidad en lugar de posponerlos y permiten evaluar su importancia relativa. Algunas de las mejoras a implementar son:

  • Feedback: En general hay poca o nula información sobre los procesos en curso y es muy importante para que el usuario no piense que la aplicación está colgada o no responde a sus interacciones. Pretendemos implementar una barra de estado con información desde la que, al pincharle, se eleve una ventana con los porcentajes agregados e individuales de las operaciones en curso al estilo del nuevo diálogo de operaciones de archivo de Nautilus 2.22, que encontramos muy usable. Además, otros medios interesantes son tooltips y burbujas desde el icono en la bandeja del sistema, invocados con señales desde el backend, para informar de eventos puntuales como "finalizada recuperación".
  • Recarga de la ventana principal (bugfix): La ventana principal ya se recarga sin polling ante cualquier evento porque se lanzan señales desde el backend. Sin embargo al recargarse se vuelve a contraer el árbol por donde íbamos navegando a través de los snapshots, lo cual hace muy molesto el uso de la aplicación (porque este refresco es, a priori, imprevisible). Solventar este bug es de prioridad máxima, y probablemente sea muy sencillo.
  • Reconsolidar glosario y nomenclatura: Pese a contar ya con un glosario específico, se ha descubierto confusión con los usuarios entre snapshots (instantáneas del estado del sistema completo en un punto en el tiempo) y backups (cada una de las versiones de un archivo; varios backups forman parte de un snapshot). Además, la metáfora de snapshot se solapa parcialmente con la de backup, lo que no ayuda. Es necesario y de prioridad alta encontrar una nomenclatura más clara e incluso sencilla, que a su vez implicará cambios en el GUI para responder a las nuevas metáforas (por ejemplo: si se intenta restaurar "un archivo" sin haber elegido snapshot, algo detectado en las pruebas de usuario, no se hace nada y resulta confuso; conviene concretar el comportamiento lógico esperable en ese caso, incluso si no permitimos que haga nada).
  • Mejorar usabilidad del panel de snapshots: En general hemos observado que queda bastante por hacer para clarificar el funcionamiento de la aplicación a los usuarios noveles, y probablemente sea necesario implementar varias opciones distintas y probarlas todas ante usuario real para observar su reacción y determinar su conveniencia (por ejemplo, si conviene mostrar todo el árbol de directorios del disco duro aunque no se pueda recuperar más que lo vigilado, separando visualmente ambas clases de archivos; o solo mostrar lo que almacenamos en el sistema).
    • Textos: Por una parte, las columnas necesitan títulos y textos más claros: probablemente haya que convertir el timestamp dado a "horas locales" -ya que el timestamp incluye la información sobre configuración GMT y de horario de verano que dificultan su lectura-, así como las unidades de tamaño a algo más legible, e incluso las operaciones.
    • Formato de columnas: Además, sería interesante cambiar el formato de las columnas (quizá en cursiva, quizá con un background diferente para resaltar) para, de un solo golpe de vista, entender el historial de los cambios. Opciones visuales como "verde == creado, amarillo == modificado, rojo == borrado" son de fácil entendimiento en cualquier cultura y permiten seguir más fácilmente los cambios a un archivo dado.
    • Ordenación de columnas: Los componentes GTK usados tienen facilidades para la ordenación de las columnas pinchando en los títulos de las mismas, como es esperable en un GUI habitual. Es prioritario (por indicado repetidamente en las pruebas con usuarios) que esta ordenación funcione para poder clasificar la información mostrada. Además sería conveniente que la búsqueda escribiendo texto, como en el resto de componentes GTK similares en aplicaciones como Nautilus, funcionase para poder localizar un cambio concreto rápidamente.
    • Menús contextuales: Actuando sobre los distintos elementos del panel principal, deben proporcionar información relacionada con los mismos y relevante (recuperar, información, dejar de monitorizar, volver a monitorizar para un archivo que se tuvo y del que se retienen copias pero que ya no se vigila, etc). Prioridad media.
    • Arrastrar y soltar: Sería muy usable poder arrastrar elementos hacia fuera del programa para restaurarlos en el destino. Implica bastante complejidad por la no uniformidad del entorno Linux en este ámbito, pero la investigación ya ha comenzado y se tratará de conseguir para esta iteración.
    • Rutas mostradas: por el diseño trivial del código que se usó inicialmente como prueba de concepto, la ruta mostrada solo contiene el último nivel de las carpetas y no es lo bastante informativa. Además, desaparece cuando pulsamos un snapshot en lugar de proporcionar información, posiblemente extendida (atributos, tamaño del cambio realizado…) sobre el mismo. Es necesario y muy importante solucionar esta carencia de usabilidad.
    • Previsualización rápida: Ante la presencia de múltiples cambios para un mismo archivo distanciados muy poco en el tiempo, puede ser complicado concretar cuál es la versión exacta que buscamos al no saber el tiempo exacto. Sería útil implementar una previsualización, o en su defecto que pulsar intro sobre un snapshot lo descomprimiera al directorio temporal y tratase de abrirlo con la aplicación registrada por defecto, para poder mostrar rápidamente al usuario lo que intenta recuperar. Ello es delicado para archivos grandes que resulten lentos de recuperar o que no estén presentes físicamente en el sistema (caso que aún no está implementado pero se daría con la externalización a CDs), lo que debe tenerse en cuenta en el API. No obstante, por falta de desarrolladores se postpone a priori esta mejora.
  • Refactorización: Parte del código del GUI relacionado con el panel principal se escribió con prisas para la primera entrega y es susceptible de muchas mejoras en código para hacerlo más fácilmente modificable. Esto es importante, ya que es el GUI lo que más debiera cambiar de aquí a la entrega final. En concreto, es conveniente una clase Columna para los treeview que además cambie el uso de números mágicos (0,1,2…) por constantes como FILE_SIZE, TIMESTAMP, etc.
  • Asistente inicial: Desarrollado en las investigaciones iniciales sobre Glade, convendría actualizar el asistente inicial y activarlo en el primer arranque de la aplicación para que el usuario esté informado de cómo va a funcionar, así como añadirlo a la ventana de preferencias para poder reconfigurar la aplicación en cualquier momento.
  • Traducción al castellano: Indicado en las primeras pruebas de usuario como un problema, estudiaremos su relevancia real, y el proceso de realizar las traducciones, que en principio launchpad nos permite hacer desde el propio entorno web. Ello nos familiarizaría con el proceso de localización en un producto de carácter internacional.
  • Opciones de cierre de la aplicación: Actualmente diferenciadas entre el tray o bandeja del sistema y los menús de la aplicación, convendría unificar todos los puntos de salida (incluida la casilla "cerrar" de la ventana principal) en una única ventana que pregunte si solo se desea cerrar el interfaz o también matar al demonio en ejecución. Quizá sería interesante también incluir una opción avanzada en las preferencias sobre la configuración por defecto al respecto; las pruebas con usuario nos darán más información sobre la opción idónea.
  • Mejoras a la ventana de propiedades: A su vez, sobre la ventana de propiedades se han encontrado diversos problemas a solucionar:
    • Problemas de redimensionamiento: La ventana no permite su redimensionamiento para hacerse muy pequeña y en general no escala bien con los textos, además de presentar algunos problemas con las ventanas desplegables de propiedades. Solucionarlo requerirá de un fuerte conocimiento del modelo de contenedores de GTK. Otra investigación útil sería una propiedad de GTK mencionada por un tester, que abrevia con puntos suspensivos automáticamente los textos para dimensionarlos al tamaño que tienen disponible para mostrarlos. Su prioridad es media/baja por no afectar, de momento, a la usabilidad en exceso.
    • Checkboxes de activación y rango de valores admitidos y por defecto: No debieran admitirse valores especiales como "-1" para indicar valores automáticos o por defecto, sino usarse checkboxes para ello y activar o desactivar los campos. Además, los valores por defecto deben consultarse al backend (no tiene sentido, por ejemplo, permitir que los backups caduquen cada cero días, pero no es responsabilidad del GUI conocer esos valores óptimos o iniciales). Es un problema importante, sobre todo de calidad del código, y por tanto tiene prioridad media / alta.
    • Desactivar opciones no utilizadas: Por ejemplo, maximum size. Supone un importante problema de calidad a la hora del testeo con usuario final ("no, esa opción no funciona"), existiendo soluciones tan sencillas como desactivar el campo de entrada.
    • Mejorar feedback sobre el estado de las casillas: Para ceñirnos al convenio de GUI extendido y mejorar la familiaridad para el usuario, se deben cambiar las opciones "guardar / cancelar" por el estándar "aplicar / aceptar / cancelar", desactivando además la casilla aplicar cuando no queden cambios nuevos por aplicar respecto al estado actual de las propiedades.
  • Integración con Nautilus: La investigación ha determinado que la integración deseada con Nautilus es muy difícil y está fuera de alcance para los medios de que disponemos. Esto es principalmente debido a los importantes cambios sucedidos en la última versión (2.22) de Nautilus, que ha cambiado el backend que utilizan para mostrar sistemas de ficheros de Gnome-vfs a gvfs. El nuevo backend conforma un api aún no estabilizada y sujeta a cambios y muy pobremente documentada, pero la opción de Gnome-vfs está deprecada en el código y por tanto no justificaría el esfuerzo de desarrollo. Sin embargo, integraciones más pequeñas sí son sencillas mediante las extensiones Nython de Nautilus, como añadidos a los menús contextuales y pestañas adicionales de propiedades, así que investigaremos al respecto su desarrollo si no supone demasiado esfuerzo y tiempo.
  • Opciones de borrado de snapshots: Cuando la funcionalidad de borrar esté desarrollada en el backend habrá que exponerla al usuario del modo más usable posible (por ejemplo, con opciones sobre los snapshots concretos además de mediante las propiedades, que de por sí son menos accesibles). Haría falta marcar snapshots tanto para borrar como para conservarlos y que no se borren automáticamente, dar opciones y feedback sobre la caducidad de snapshots, etc. Todas estas features dependen ante todo de que el backend esté desarrollado, pero se pueden ir pensando y diseñando.
Proceso de release

Como a partir de ahora las entregas van a ser muy frecuentes y periódicas, debemos tomar decisiones sobre el proceso de generación de baselines que seguiremos para juzgar qué código se entrega y cuándo se considera listo para ello. Esto es necesario para alcanzar unos mínimos de calidad y evitar entregar sin haber realizado unas pruebas previas lo bastante extensivas, o con bugs conocidos y resueltos en otras versiones del código. Por el momento queda pendiente además cómo gestionaremos el backporting de parches de versiones inestables a los baselines, para lo que es necesario que investiguemos las posibilidades que nos da la herramienta antes de tomar decisiones al respecto.

Otras medidas a tomar al respecto son:

  • Seguimiento de entregas: A fin de poder presentarlas juntas en junio, es necesario recopilar la información sobre qué se entregó en cada fecha, añadiendo esa información al wiki y centralizando también las encuestas a usuarios hechas durante las mismas, y demás información relevante. Además, es conveniente etiquetar las entregas mediante la herramienta de control de versiones para poder seguirlas.
  • Modificaciones al proceso de desarrollo: Apenas modificado desde la propuesta de modelo de desarrollo inicial, para poder gestionar la calidad y los baselines más cómodamente, usaremos un repositorio adicional llamado testing, que esté dedicado exclusivamente a la estabilización del producto final, tal y como se indicó en el seguimiento del mes anterior. Además, evitaremos realizar planificaciones tan detalladas como esta: en adelante los bugs y features deseadas se añadirán directamente al gestor de launchpad, desde donde podemos realizar más fácilmente y centralizado el seguimiento del desarrollo de los mismos, así como asignar tareas.
  • Mejoras de distribución del código: Varias son interesantes de investigar:
    • Refactorización de paths: El script de instalación debe tener en cuenta los problemas de paths relativos en la aplicación para que pueda funcionar instalada en cualquier subconjunto de carpetas (según se elija en el instalador, que toma los valores por defecto de cada sistema donde se distribuye). Ello es una mejora investigada pero aún por aplicar, y prioritaria.
    • Paquete de Ubuntu: A poco tiempo de la entrega final, es necesario terminar de desarrollar la tecnología de instalación y crear un paquete .deb que pueda instalarse directamente en la distribución objetivo: Ubuntu. Ello requerirá de una notable investigación al respecto, pero debería ser medianamente automatizable a partir del script que tenemos.
    • Versionado: A la vez que establecemos una política de baselines, conviene incluir esas versiones en el código para seguir la pista de lo que distribuimos más fácilmente. Además, esto nos permitiría detectar versiones antiguas de los archivos que usamos en la aplicación, reduciendo el riesgo de utilizar configuraciones que ya no son funcionales en la versión actual, o que hayan sufrido diversas refactorizaciones que hicieran que no funcionase correctamente.
    • Documentación interna del código: en lugar de distribuirla junto al código, sería interesante generarla con el script de instalación si la herramienta doxygen está presente. Así se distribuye un paquete mucho más pequeño, y no hay riesgo de distribuir documentación interna obsoleta. También convendría incluir parte del UML cuando esté listo.
  • Testunits: la aparente dificultad de desarrollar unidades de prueba válidas, así como la reacción inicial negativa del equipo a las mismas, debe ser evaluada en función de los beneficios reales que nos aportaría. Probablemente sea necesario un desarrollador altruista que ponga en marcha el marco de funcionalidad común a todas, para facilitar el posterior desarrollo. Valoraremos la posibilidad de explicitar con una testunit cada bug encontrado durante la segunda mitad del desarrollo.
Formación nuevo personal y reasignación de tareas

La formación del nuevo miembro del personal para que sea lo más productiva posible cuanto antes supondrá de un esfuerzo extra que debemos repartirnos en la medida de lo posible. La estamos formando, por tanto, entre todo el equipo en todo lo relevante y crítico (modelo de documentación, procesos de desarrollo y toma de decisiones, control de versiones…), y estimamos que será productiva en breve tanto en calidad de la documentación como en testeo de la aplicación, dos tareas para las que el conocimiento del código necesario es menor.

Gestión de la calidad

Durante la pasada iteración hemos concluido que los actuales problemas de calidad son excesivos, y por tanto tenemos que poner en marcha -pese a la carencia de personal- un plan de calidad, e incluirlo en nuestros procesos de desarrollo. Una vez superemos la siguiente entrega, congelaremos temporalmente el desarrollo de nuevas funcionalidades y nos centraremos en mejorar lo máximo posible la calidad, tanto en código como en bugs, de la aplicación, mientras decidimos un proceso de control de calidad adecuado a nuestras posibilidades reales. También exploraremos el uso de herramientas de control de estilo de código específicas de Python como Pylint, capaces de detectar copy - paste y otros problemas potenciales.

Evaluación y mejora de Software Capability Model

El ejercicio de clase acerca del modelo de capacidades de software ha puesto de manifiesto ciertas carencias que debemos suplir para alcanzar el requerido nivel 2. Inicialmente es necesario formalizar las notas tomadas durante esa evaluación, y a continuación trabajaremos sobre los aspectos que aún nos faltan, intentando no solo superar ese nivel sino aproximarnos al siguiente, ya que nos faltarían pocas cosas para ello.

Iniciar revisión documentación

Junto con la parada de control de calidad a mitad de la iteración, iniciaremos una profunda revisión de la documentación para ponerla al día en aquellos aspectos en que esté obsoleta que sean más importantes, así como para añadir a la página que centraliza la entrega final aquellos documentos que aún falten. Con el UML en progreso, también revisaremos su exactitud al lado del código y ampliaremos la documentación relativa al mismo.

Investigar ERIC

Hemos encontrado un nuevo entorno de desarrollo integrado que permite depurar -a diferencia del que utilizamos, donde fallan varias cosas para ello- y que probablemente genere diagramas de herencia UML desde el código. Será necesario investigar su uso y conveniencia a estas alturas del desarrollo.


Reparto de trabajo

Probablemente debamos flexibilizar el reparto de trabajo actual, al haber demasiadas subtareas y poco personal. En principio mantenemos los grupos de trabajo de la anterior iteración, con la excepción de Salva que probablemente pase al grupo de GUI. Algunas responsabilidades específicas son:

  • Tabas y Robs: Opciones para salir + investigación drag and drop. Mejoras varias al GUI (Tabas: redimensionamiento).
  • Carlos: iconos treeview. Mejoras varias al GUI.
  • David: mantenimiento de la base de datos. Traducciones aplicación. Investigación de uso de Pylint.
  • Mario: arreglar la consola.
  • Jorge: investigación sobre inotify para hacerlo compatible con gedit. Detener notificador. Bugfixing de esa zona en general.
  • Adri: coordinación de release. Testing en general.
  • Carmen: revisión entrega documentación. Testeo de la aplicación. Posiblemente testunits.
  • Fede: borrar snapshots. Junto a Salva, refactorización de XDelta3Wrapper.
  • Diana: UML
  • Eze: puesta al día de documentación. Decisiones de proceso de desarrollo. Investigación deploy alternativo. Investigación packaging. Investigación Nautilus adicional.

Estimaciones de tiempo

  • 7 Abril:
    • Iconos del treeview cambiados para que sean diferenciables a simple vista las carpetas de los archivos.
    • Funcionalidad de borrar los snapshots ya desarrollada y por testear.
    • Base de datos thread-safe.
    • Backups ordenados por el usuario funcionando.
    • Bugs de encoding solucionados.
    • Detener notificador de cambios.
  • 14 Abril:
    • Desarrollo congelado.
    • Bugs resueltos: recargar vista contrae las carpetas desplegadas
    • La mayoría de los problemas de rendimiento detectados y en solución.
    • Consola funcionando.
    • Estabilización de la entrega. Testeo intensivo.
    • Formación del nuevo personal completada.
  • 17 Abril:
    • Entrega de código.
    • Inicio de la revisión de calidad.
    • Descongelado de features en paralelo al bugfixing.
    • Inicio de revisión del UML.
  • 24 Abril (estimado):
    • Prints eliminados de toda la aplicación.
    • Decisión sobre los testunits.
    • Investigación sobre Pylint terminada; integración con proceso de calidad si es relevante.
  • 28 de Abril:
    • Documentación actualizada en el wiki.
    • Nueva congelación total de features.
  • 1 de Mayo: entrega (telemática) de la documentación del mes.
  • 8 de Mayo: siguiente entrega de código (ya que el 1 y 2 serán previsiblemente puente).

Seguimiento

Ver seguimiento-abril


Planificación iteración Mayo

Tipo de iteración

Elaboración / Transición


Objetivos generales

Dado que nos acercamos ya al final del curso y el tiempo disponible por parte de todos se reducirá bastante para poder estudiar y trabajar en el proyecto, nos planteamos que será poco el desarrollo adicional que podamos hacer, y crearía demasiados riesgos sobre un aspecto tan crítico para nuestro proyecto como la robustez de la aplicación. Por tanto optamos por pulir lo más posible lo que tenemos, preparándonos para un hipotético mantenimiento, y preparando la también importante presentación y la documentación, tanto de cara a la entrega como a preparar entre todos el examen.

Sin menoscabo de esto, es posible que hacia la mitad de la iteración se escinda un pequeño grupo de "fuerzas especiales", como se les denominaba en las charlas de representantes de grupos de otros años, para intentar desarrollar alguna feature extra.

Por tanto, hemos decidido congelar el código y dedicar 2 semanas a documentación y calidad. Una vez finalizadas, nos escindiremos en grupos de presentación, bugfix, features y calidad, probablemente con solapamiento de responsabilidades por nuestro escaso número. Esto lo decidiremos a mitad de iteración, y en función de la disponibilidad prevista del personal.

Calidad y documentación
  • Revisión de calidad del código: Se planifica que cada uno revise el código en el que ha estado trabajando (ya que es la persona mejor cualificada para reescribirlo) y además otra sección adicional, de modo que todo sea revisado por al menos dos personas.
  • Cambiar los términos snapshot y backup por versión en toda la aplicación.
  • Preparar la presentación para la entrega final.
  • UML: patrones presentes en nuestro código
  • Despliegue de la aplicación definitivo y documentación del mismo.
  • Actualizar riesgos.
  • Centralizar apuntes de cara al estudio de la asignatura.
Features
  • Asistente inicial de la aplicación.
  • Porcentajes y estimaciones de tiempo en la aplicación para proporcionar feedback.
  • Ordenar por columnas la lista de snapshots.
  • Caducar -> Exportar a CD
  • Mover el directorio del backup finalizado.
  • Empaquetado definitivo de la aplicación (instalador, etc).
  • Precacheo del árbol en el GUI para mayor eficiencia.
  • Refactor watcher: hacerlo independiente de inotify.

Reparto de trabajo

Revisión de calidad
  • Salva - GUI + apuntes junto a Eze.
  • Jorge - GUI
  • Fede - Watcher
  • Rober - Watcher
  • Mario - snapshot-manager
  • Tabas - snapshot-manager
  • Adri - base de datos
  • David - Cron
  • Carlos - consola
  • Diana - hará una revisión general siguiendo el UML
  • Carmen - hará una revisión general siguiendo el UML
  • Eze - la documentación
Features
  • Wizard - Carlos
  • Porcentajes - Tabas y Fede
  • Ordenar por columnas - Carlos y Rober
  • Centralizar apuntes - Eze, Salva
  • Caducar -> Exportar a CD - Salva y Fede (Si da tiempo)
  • Mover el directorio del backup - Adri
  • Empaquetado - Eze
  • Precacheo del arbol en el GUI - Tabas
  • Refactor watcher: hacerlo independiente de inotify

Estimaciones de tiempo

  • 9 de mayo: Primera entrega.
  • 19 de mayo: Nueva organización para preparar la entrega final. Empaquetado listo. Congelado final de código salvo grupo de "fuerzas especiales".
  • 22 de mayo: Última entrega antes de la final.
  • finales de mayo / principios de Junio: Reunión un día común para preparar el examen.

Seguimiento

Ver seguimiento-mayo



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.


Releases

Table of Contents

Aquí centralizaremos la información sobre las releases de código, hasta cierto punto independientes de las entregas de documentación sobre planificaciones: notas sobre cada versión, tags del control de versiones, etc.

Primera entrega (13 Marzo)

Resumen

El apresurado desarrollo no ha permitido una entrega funcional. Por tanto, ha resultado prácticamente una preview del GUI y no ha sido demasiado útil, salvo para probar el método de despliegue en condiciones de escasa carga.

Información
  • Entregada mediante sesión remota.
  • Etiquetada en trunk como Entrega-13-03-08 , revisión 98. (enlace).
  • Número de encuestas recibidas: 39.
Otras observaciones en la encuesta

En general la encuesta fue de poca utilidad, al no poder probarse nuestra aplicación. Sin embargo quedó patente el problema del glosario, ya que las preguntas relativas al "snapshot" daban como respuesta más repetida "no sé qué es / no sé si lo necesito".


Segunda entrega (03 Abril 2008)

Resumen

La segunda entrega ha resultado más productiva, con nuestra aplicación funcionando por primera vez, y hemos recibido feedback muy útil principalmente para mejorar la usabilidad del interfaz.

Información
  • Entregada mediante sesión remota de escritorio.
  • Etiquetada en el repositorio trunk como Entrega-03-04-08, revisión 16.32.17. (enlace).
  • Número de encuestas recibidas: 28.
Interfaz Gráfica
  1. ¿Es fácil de usar?:
    Nota media aproximada: entre 5 y 6.
    Observaciones: Se nos ha sugerido incluir una ayuda. Si la implementamos, sería interesante probar a no explicarles nada en alguna entrega y animar a los usuarios a que utilicen la ayuda.
  2. Diseño:
    1. Orden de los menús:
      Nota media aproximada: 7
      Observaciones: Alguien pregunta si la opción de borrar no suele ir al final en vez de al principio.
    2. Estilo de los menús/botones:
      Nota media aproximada: entre 7 y 8
    3. Claridad de la vista en árbol:
      Nota media aproximada: 5
      Observaciones: A los usuarios les molesta que se cierre al guardar algo. Interpretamos con esto que se refieren a la contracción del treeview cuando hay un refresco (producido con el evento de "guardar algo"), bug que ya tiene prioridad de solución.
    4. Icono de la aplicación:
      Buena acogida en general, aunque hay gente que dice que no se ve bien.
    5. Tipos de iconos (del sistema o propios):
      La opinión mayoritaria es que los iconos deben ser diferentes a los del sistema, aunque algunos usuarios prefieren que se les pregunte.
  3. ¿Es completa o queda funcionalidad por cubrir?:
    Nota media aproximada: 5 .
    Concluimos que nuestra aplicación se percibe como muy incompleta aún.
  4. ¿La vista de los archivos es clara?:
    Nota media aproximada: 7
  5. ¿Son suficientes los datos mostrados acerca de cada archivo?:
    Nota media aproximada: 8
    Observaciones: Un usuario pide que el tipo de operación sea mas explicativo, pero pensamos que esto se podría solucionar en la ayuda.
  6. Buscar la versión de un fichero:
    Se solicita un sistema de búsqueda por nombres, fechas, ubicación, etc. También nos piden iconos que permitan distinguir entre carpetas y archivos.
  7. ¿Poner descripción sobre la versión?:
    Una amplia mayoría piensa que sí.
  8. ¿Se podrían usar etiquetas en lugar de descripciones?:
    Hay preferencia por las etiquetas en lugar de descripciones. Un usuario pide que se pueda gestionar desde el treeview.
  9. En el treeview ¿deben aparecer solo los archivos versionados o el árbol de directorios completo?:
    Hay mucha diversidad de opiniones. Nos planteamos la viabilidad de dejarlo a elección del usuario. Se prefiere el uso de colores para diferenciar cuáles están versionados y cuales no.
  10. ¿Uso de botón derecho para añadir un archivo a la vigilancia?:
    Rotundo sí.
  11. ¿Idioma (Ingles/Castellano/el del sistema)?:
    Los usuarios creen que el idioma debe coincidir con el del sistema.
Funcionalidad
  1. ¿Versionar arrastrando un archivo a la ventana de HD Lorean?
    No hay una preferencia clara aunque sí están de acuerdo en que se tendría que poner alguna manera mejor de añadir a la vigilancia sin tener que abrir el menú de preferencias.
  2. ¿Exportar?
    Claramente sí.
Otras observaciones en la encuesta

Se nos ha preguntado si se puede restaurar un snapshot entero. Creemos que esto podría venir bien en caso de tener la información en un disco duro externo y que se haya producido una avería en el disco duro del sistema.


Tercera entrega (24 Abril 2008)

Resumen

Esta tercera entrega ha resultado de gran utilidad aunque no se hayan recogido tantas encuestas como en la anterior, ya que nos muestra qué debemos corregir con gran exactitud y qué debemos incorporar para que sea mas fácil de usar. También notamos algo de mejoría en algunos aspectos de la encuesta.

Información
  • Entregada mediante VNC.
  • Número de encuestas recibidas: 17.
Interfaz Gráfica
  1. ¿Es fácil de usar?:
    Nota media aproximada: entre 7 y 8.
  2. Diseño:
    1. Orden de los menús:
      Nota media aproximada: 7 y 8
      Observaciones: Los usuarios permanecen en desacuerdo sobre el orden de los botones, prefieren eliminar al final y hacer versión al principio.
      # Estilo de los menús/botones:
      Nota media aproximada: 8
      # Claridad de la vista en árbol:
      Nota media aproximada: entre 7 y 8
      # Icono de la aplicación:
      Se repiten los comentarios de la anterior encuesta: se ve poco o mal aunque tiene buena acogida.
    2. Tipos de iconos (del sistema o propios):
      No se ponen de acuerdo y hay opiniones para todos los gustos, aunque los iconos del sistema no desagradan.
  3. ¿Es completa o queda funcionalidad por cubrir?:
    Nota media aproximada: entre 7 y 8 .
    Ahora parece que la gente entiende que la funcionalidad se acerca más a lo que esperan.
  4. ¿La vista de los archivos es clara?:
    Nota media aproximada: entre 7 y 8
  5. ¿Son suficientes los datos mostrados acerca de cada archivo?:
    Nota media aproximada: 8
    Observaciones: Aún queda gente que piensa que la información es insuficiente.
  6. Buscar la versión de un fichero:
    En general encuentran bien la versión del archivo que buscan pero siguen demandando un sistema de búsqueda.
  7. ¿Poner descripción sobre la versión?:
    Siguen opinando que sería útil si la descripción la introdujera el usuario.
  8. ¿Se podrían usar etiquetas en lugar de descripciones?:
    División de opiniones, algunos creen que es incompatible con las descripción mientras que otro piensas que ambas opciones vendrían bien.
  9. En el treeview ¿deben aparecer solo los archivos versionados o el árbol de directorios completo?:
    Las respuestas siguen siendo diferentes, como en la anterior encuesta.
  10. ¿Uso de botón derecho para añadir un archivo a la vigilancia?:
    Esta opción sigue recibiendo un gran apoyo.
  11. Uso del botón derecho:
    En general ha gustado mucho que haciendo click con el botón derecho se puede ordenar una eliminación, restauración o nueva versión de un archivo o una carpeta.
  12. ¿Idioma (Ingles/Castellano/el del sistema)?:
    Como en la encuesta anterior muchos indican que lo prefieren en castellano, aunque también señalan que lo adecuado es que esté en el idioma del sistema.
  13. ¿La ayuda es completa?:
    En general opinan que sí, pero casi todos señalan que se podría completar un poco más.
Funcionalidad
  1. ¿Exportar?
    Los encuestados siguen viendo muy útil que la aplicación de la opción de exportar a un dispositivo externo.
Consola

La ayuda de la consola ha gustado aunque alguno indica que es demasiado densa. En cuanto a la funcionalidad encuentran útil poder borrar todas las versiones de un archivo en un intervalo de fechas dado, o indicar varias fechas.


Cuarta entrega (09 Mayo 2008)

Resumen

La cuarta entrega no ha resultado de mucha utilidad debido al escaso número de encuestas que hemos recibido de la gente que lo ha probado, pero aún así nos sirve para saber si hemos ido por el camino correcto.

Información
  • Entregada mediante sesión remota.
  • Número de encuestas recibidas: 4.
Interfaz Gráfica
  1. ¿Crees que esta mejor que en anteriores entregas? ¿Cuánto mejor?:
    Coinciden en que está mejor aunque varían en la cantidad de mejoría. Obtenemos un 7 de media.
  2. ¿Qué te parece la traducción? Comenta los fallos que encuentres:
    En general están contentos con que la aplicación esté en castellano.
    Observaciones: ¿Que sería mas correcto: "Guardar versión actual" o "Guardar estado actual"?
  3. ¿Te parece intuitiva la nueva nomenclatura?:
    Todos coinciden en que es más fácil hablar de versiones que de backups o snapshots.
  4. ¿Notas un mejor rendimiento?:
    Mas o menos notan que ha mejorado algo pero no saben decir qué exactamente.
  5. ¿Te parece mas informativa la lista de versiones? ¿La información es mas clara?:
    En esta pregunta discrepan, unos encuentran información útil y otros no saben que significa exactamente o no se acuerdan de que había antes.
  6. ¿Echas en falta alguna opción desde el interfaz?:
    Solo una persona indica que se debería poder crear archivos y carpetas desde la aplicación.
  7. ¿Poner descripción sobre la versión?:
    Una amplia mayoría piensa que sí.
  8. ¿Resulta útil la información que muestran los globitos? ¿Molestan demasiado?:
    En general la consideran útil y que no molesta demasiado. Ello confirma la usabilidad de esta característica
  9. ¿Tal y como esta el proyecto lo usarías?:
    3 de los encuestados dicen que sí, un 75%.
Consola

Coinciden en que es buena idea tener algo distinto a la GUI aunque se usaría poco. También comentan que estaría bien que estuviera en castellano.

Otras observaciones en la encuesta
En la ventana de preferencias comentan que el botón aplicar debería aparecer desactivado y que se debería activar cuando se realice algún cambio.

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