|
Table of Contents
|
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 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
Seguimiento 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).
