Visión dinámica de MEDEA 2

El ciclo de vida de los proyectos gestionados mediante la metodología MEDEA estará dividido en tres fases

1. Fase de elaboración: Lanzamiento del proyecto, recogida de requisitos, análisis y diseño.
2. Fase de construcción: Codificación del software, integración continua y controles de calidad por parte del equipo del proyecto
3. Fase de Liberación: Creación de una release, que puede estar destinada a la preproducción o a la producción, preparación del entorno, preparación de materiales de ayuda y formación de los usuarios.

La fase de elaboración comienza con las primeras entrevistas del jefe de proyecto con el cliente. En estas primeras entrevistas el Jefe de Proyecto comienza a recopilar la información necesaria para lanzar el proyecto y comenzar a preparar los recursos necesarios, sistemas, personal, etc. El objetivo de estas primeras tareas es comenzar a tomar el control del proyecto. Las primeras tareas que se ejecutan en esta fase del proyecto son las del proceso Definir el proyecto.

Paralelamente a estos primeros pasos por parte del Jefe del Proyecto, el Gestor de la configuración comienza a preparar todo lo necesario para poder tener una buena gestión de la configuración en el proyecto. Esto lo realiza ejecutando el proceso Establecer Sistema de Gestión de la Configuración

Una vez el Jefe de Proyecto ha realizado las tareas para lanzar el proyecto y el Gestor de la configuración ha establecido el sistema de gestión de la configuración, el Ingeniero de Requisitos puede comenzar a determinar el alcance del proyecto identificando los límites del sistema a construir, las personas interesadas, los sistemas externos con los que la aplicación estará relacionada, y las características funcionales y no funcionales que ha de tener el sistema a construir. Los requisitos que se toman en esta fase son requisitos de alto nivel, y más adelante habrá de profundizarse en ellos. Esta toma de requisitos se realiza ejecutando el proceso Determinar el alcance.

Una vez finalizada la determinación del alcance del proyecto, el Ingeniero de Requisitos pasará a profundizar en la toma de requisitos. Previamente, el Jefe del proyecto determinará el tipo de artefacto a utilizar para tomar los requisitos funcionales, si casos de uso o historias. El Ingeniero de Requisitos escribirá los casos de uso y/o las historias de acuerdo con lo indicado en el proceso Elicitar requisitos.

Los requisitos han de ser validados antes de pasar a la siguiente fase por dos veces. Primero han de ser validados por otro Ingeniero de Requisitos distinto al que los escribió. Por otra parte, una vez validados técnicamente, el Cliente ha de validarlos dándolos por buenos. El proceso que indica cómo realizar esto es el proceso Validar Requisitos.

Una vez los requisitos han sido validados por el Cliente, el Analista y el Arquitecto comenzarán la identificación de módulos del sistema a construir, definirán la arquitectura lógica del módulo y el modelo de clases del módulo. El proceso Analizar el proyecto indica cómo realizar esto.

Es importante tener en cuenta que para comenzar el análisis no necesitamos tener validados el 100% de los requisitos del proyecto, pero sí aquellos requisitos que determinan la arquitectura del sistema a construir. No existe una regla fija para saber cuándo hemos alcanzado este hito. Eso debe determinarlo conjuntamente entre el Jefe del Proyecto, el Ingeniero de requisitos, el Analista y el Arquitecto basándose en su conocimiento del sistema y experiencia previa.

También es importante reseñar que si hemos alcanzado esta fase sin tener validados el 100% de los requisitos, más adelante deberemos retomarla y corregir el análisis y diseño realizado previamente.

El Arquitecto pasará a diseñar con más detalle cada uno de los módulos identificados previamente. Esto se realizará según lo marcado en el proceso Diseñar los componentes del proyecto. Cuando el diseño sea suficiente, el Analista de datos realizará el diseño de la base de datos y el Diseñador de Interfaces diseñará aquellas pantallas que se consideren necesarias para proporcionar al cliente la información necesaria para que pueda validar el diseño.

Al igual que sucedía con los requisitos, un Arquitecto distinto al que ha realizado el diseño, debe validar el diseño de acuerdo con lo expuesto en el proceso Validar Técnicamente Análisis y Diseño.

El Cliente también debe validar el diseño propuesto. Evidentemente, el diseño está formado por una serie de documentos muy técnicos que el cliente no tiene por qué entender. Le explicaremos a su nivel los detalles suficientes y le mostraremos las pantallas realizadas por el Diseñador de interfaces en la fase anterior.

Esta tarea es la que concluye la fase de elaboración del proyecto. No debemos olvidar que todos los requisitos propuestos deben llegar a este punto, pero que no es necesario que todos los requisitos sean elicitados, validados, analizados y diseñados a la vez. Únicamente es imprescindible que en una primera tanda se eliciten, validen, analicen y diseñen los requisitos que nos impongan la arquitectura del proyecto. También es importante saber que cuanto menor sea el porcentaje de requisitos que lleguen a este punto en una primera vez mayor será la incertidumbre en el resto del proyecto.

La fase de construcción en MEDEA es iterativa e incremental. Dividiremos el trabajo en iteraciones y agruparemos las iteraciones en releases. Realizaremos tantas iteraciones como nos imponga el número de requisitos y el trabajo necesario para implantarlos. A continuación veremos cómo gestionar cada una de estas iteraciones, teniendo en cuenta que las tareas a realizar en cada una de las iteraciones es igual al realizado en las otras.

La única diferencia que hay entre una iteración y otras son ciertos trabajos que hay que realizar en la primera iteración y que no es necesario hacer en el resto.

Esta tarea será realizada por el Arquitecto únicamente al comienzo de la primera iteración. El arquitecto preparará la estructura de directorios del proyecto de acuerdo con lo indicado en el proceso Organizar el Código. Una vez tenga lista esta estructura la subirá a Subversion para que pueda ser utilizada por todos los que participan en el proyecto.

Paralelamente a la preparación del proyecto en el IDE, en la primera iteración, o en la primera iteración de una Release, el Jefe de Proyecto deberá realizar una planificación de la Release. Esta planificación es de alto nivel y se realiza tal y como se indica en la tarea Planifica las Release del proceso Planificación del proyecto. Esta planificación debe revisarse al final de cada iteración, para poder conocer si estamos en plazo o nos hemos desviado de lo planificado.

Al comienzo de cada iteración, el Jefe del proyecto, junto con los desarrolladores y arquitectos, realizará una planificación de la iteración de acuerdo con lo indicado en la tarea Planificar las iteraciones del proceso Planificación del Proyecto.

A partir de la planificación de la iteración comienza el trabajo de codificación del sistema.

Durante todo el desarrollo de la iteración, los Desarrolladores crean los componentes de acuerdo con los requisitos seleccionados para la iteración y, además, crean los test unitarios de los componentes que están codificando. Es importante que no se olviden de realizar los test unitarios. Una vez codificados los componentes, junto con los test unitarios, los Desarrolladores lo subirán a subversion.

Durante toda la iteración, un Integrador, normalmente uno de los desarrolladores, será el encargado de ir integrando el trabajo de todos los desarrolladores que participan en la iteración, de manera que, al final de la iteración, el software pueda funcionar como un todo. Para asegurar que la integración se mantiene a lo largo de la vida del proyecto también estará encargado de programar test de integración. Tanto la tarea de integración, como la de codificación están recogidas en el proceso Crear Componentes.

El jefe de proyecto ha preparado previamente el servidor de integración continua, Jenkins, para que diariamente vaya compilando el código subido por los desarrolladores e integradores. El Gestor de la Calidad irá observando diariamente cómo evolucionan los builds que Jenkins genera automáticamente, observando la correcta codificación con Checkstyle, la ausencia de errores con FindBug, la cantidad de código testeado con cobertura, etc. Todo esto se hará de acuerdo a lo indicado en el proceso Integrar Continuamente.

Paralelamente al trabajo de codificación durante las iteraciones, hay otros trabajos que realizar en el proyecto. Son los que se indican a continuación.

El Tester debe preparar los casos de prueba para poder verificar el software construido una vez finalizada la iteración/release correspondiente. Para ello debe diseñar los casos de prueba de acuerdo con los requisitos, tanto funcionales como no funcionales, y automatizar aquellos que sea posible. Para ello se guiará por lo indicado en la tarea Diseñar casos de prueba y Automatizar casos de prueba respectivamente.

Diariamente, el Jefe de Proyecto debe hacer un seguimiento de la marcha de la iteración para intentar resolver posibles desviaciones, tomar decisiones en cuanto a la priorización de tareas, eliminar obstáculos, etc. Este seguimiento se hace mediante la celebración del Scrum Daily meeting especificado en la tarea Seguimiento de Iteraciones.

En cualquier momento, el Jefe de proyecto puede recibir peticiones de cambio. Estas peticiones de cambio deben ser gestionadas por el Jefe de Proyecto. Esta gestión implica evaluar la pertinencia o no del cambio, definir el alcance, coste e impacto del cambio sugerido y, por último, junto con el Comité de Control de Cambios, aceptar la petición o no. En cualquier caso, las peticiones solicitadas no se incluirán en la iteración que se está desarrollando en este momento. Habrán de incluirse en posteriores iteraciones, estimando su coste y priorizándolas como cualquier otro requisito que tengamos pendiente de implantar en ese momento. El proceso Control de cambios explica claramente cómo deben ser gestionadas estas peticiones de cambio.

La existencia de las peticiones de cambio obligan al Jefe del Proyecto a hacer, por una parte, un seguimiento de los cambios introducidos en el proyecto, consultado los informes de progreso y de tendencia, tal y como indica el proceso Contabilidad del Proyecto y a llevar una gestión de los requisitos tal y como indica el proceso Gestionar los requisitos

Tras finalizar la iteración, es necesario mostrar a los clientes el resultado del trabajo desarrollado tras la iteración. Para ello se realizará una Demo de Sprint por parte de todo el equipo de trabajo en el que se mostrará el software funcionando. Tras realizar la demo de sprint, el Jefe del Proyecto convoca una reunión con todo el equipo, llamada retrospectiva de sprint, en el que se evalúa el trabajo realizado durante la iteración, además de ver si se consiguieron los objetivos. Las tareas de seguimiento de la iteración tras su finalización están indicadas en la tarea Seguimiento de Iteraciones.

Tras realizar el seguimiento de la iteración, el Jefe del proyecto hará un seguimiento de la release para ver si las posibles desviaciones en la iteración han afectado a la planificación de la release. El seguimiento de la release viene especificado en la tarea Seguimiento de Releases.

Paralelamente al seguimiento de la iteración o de la release, es posible que en algunas fases del proyecto haya que realizar el seguimiento de algunos de los hitos del proyecto. Esto ha de hacerse de acuerdo con la tarea Seguimiento de Hitos.

Una vez realizado el seguimiento de iteración, release e hitos, podemos tomar 2 caminos. Continuar desarrollando software si no están implantados todos los requisitos de la aplicación o comenzar con la liberación del software desarrollado. También es posible que tomemos ambos caminos simultáneamente. Por una parte podemos preparar el código desarrollado hasta el momento para ser liberado, mientras el equipo continúa desarrollando software pendiente. En este caso, se ejecutarán simultaneamente la fase de construcción y la de implantación.

Es el Jefe del proyecto el que debe ordenar la liberación de una release. Esta release, puede estar destinada a ser liberada en preproducción o puede que se despliegue únicamente en preproducción. En cualquier caso las tareas a realizar son las mismas.

Es el Gestor de la configuración el encargado de crear la release. Para ello seguirá lo indicado en la tarea Crear Release. El crear Release implica crear un tag, que puede materializarse en una rama o versión que incluya todo el software y la documentación creada hasta ese momento.

Paralelamente a la creación de la release por parte del Gestor de la Configuración, uno o varios Desarrolladores preparan el entorno para la ejecución de la aplicación según indica el proceso Preparar el entorno de ejecución. Preparar el entorno implica por parte de los Desarrolladores, crear el entorno de base de datos, cargar los datos iniciales, etc. Una vez realizadas estas tareas, el Gestor de la configuración desplegará la aplicación para comenzar las pruebas.

Una vez la aplicación está desplegada deben comenzar las pruebas para garantizar que la aplicación funciona correctamente y cumple con las necesidades de los usuarios.

Los Tester del equipo de trabajo probarán la aplicación tanto funcionalmente, ejecutando los casos de prueba, como ejecutando el plan de prueba de carga.

Una vez probada la aplicación funcionalmente y su rendimiento, los Tester comprobarán la calidad interna de la aplicación, comprobando que cumple con los criterios de la plantilla de seguridad y con los de la plantilla de accesibilidad.

Una vez que el equipo ha verificado el funcionamiento de la aplicación, ha realizado pruebas de carga y ha comprobado que se cumplen con los criterios de seguridad y accesibilidad, el cliente puede comenzar a realizar las pruebas de usuario.

Paralelamente, el Gestor de la Calidad está revisando los resultados de los test anteriores y los test de usuario, según marcan las tareas seguimiento de las pruebas de usuario y Evaluar resultados

Tras todas estas pruebas, se decidirá si la versión ha de pasar a producción o no. En el caso en que pase a producción, deberán prepararse las ayudas y manuales y deberá formarse a los usuarios.

Una vez que se ha decidido que la versión está preparada para ser liberada, los Formadores comienzan con la preparación de las ayudas, videotutoriales y manuales de la aplicación según lo marcado en el proceso Elaborar manuales de usuario.

Una vez se dispone, en los distintos formatos, de las ayudas de la aplicación se comienza a preparar la formación de los usuarios. Por una parte, el Gestor de la formación realiza las tareas administrativas de preparación de la formación según lo indicado en las tareas elaborar documento de gestión y elaborar la encuesta

Paralelamente, los formadores deben elaborar las presentaciones necesarias y, cuando todo está preparado, imparten la formación.

Una vez liberada una release de la aplicación pueden pasar dos cosas, o que el proyecto haya terminado o que siga desarrollándose la aplicación. En el segundo de los casos el proyecto continuará por donde estuviera tras impartir la formación, pero en el primero de los casos debemos cerrar el proyecto.

El cierre del proyecto debe realizarse por parte del Jefe del proyecto. Las tareas están explicadas en el proceso Cerrar el proyecto. Una vez realizadas estas tareas, recopilar métricas, valorar el proyecto, escribir y publicar las lecciones aprendidas podemos dar el proyecto por finalizado.

A partir de ahora comenzaremos con el mantenimiento del proyecto.