Planificacion 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

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