Printable Marzo

Planificación de fase

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 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


Seguimiento 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.


Releases:

Entrega 13/03/2008

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".

Entrega 03/04/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.

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