====== Visión dinámica de MEDEA ====== ^Nota: ^Los gráficos se han puesto a tamaño máximo, ya que si los ponemos a un tamaño para que se vea el diagrama completo, queda demasiado pequeño. Para reducir el tamaño o aumentarlo puedes pulsar ctrl- o ctrl+, respectivamente. Para volver a su tamaño original pulsa ctrl 0.^ El ciclo de vida de los proyectos gestionados mediante la metodología MEDEA estará dividido en tres fases - **Fase de elaboración**: Lanzamiento del proyecto, elicitación de los requisitos y análisis y diseño. - **Fase de construcción**: Codificación del software, integración continua y controles de calidad por parte del equipo del proyecto - **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. ===== Fase de elaboración ===== {{:mda:mda-1.1-elaboracion.png|}} ==== Primeros pasos ==== 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 [[mda:gp:mda-pr-1.0-gp-definicion_del_proyecto|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 [[mda:gc:mda-pr-1.0-gc-establecer_el_sistema_de_gestion_de_configuracion|Establecer Sistema de Gestión de la Configuración]] ==== Primera toma de requisitos ==== 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 [[mda:req:mda-pr-1.0-req-alcance|Determinar el alcance]]. ==== Profundizando en la toma de requisitos ==== 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 [[mda:req:mda-pr-1.0-req-elicitacion_de_requisitos|Elicitar requisitos]]. ==== Validando los 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 [[mda:req:mda-pr-1.0-req-validacion|Validar Requisitos]]. ==== Análisis del sistema a construir ==== 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 [[mda:ana:mda-pr-1.0-ana-analisis_del_proyecto|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 cuando 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. ==== Diseño del sistema a construir ==== 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 [[mda:ana:mda-pr-1.0-ana-diseno_del_proyecto|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. ==== Validando 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 [[mda:ana:mda-pr-1.0-ana-validar_tecnicamente|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 porqué 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. ===== Fase de construcción ===== {{:mda:mda-1.1-construccion.png|}} 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 impongan el número de requisitos y el trabajo necesario para implantarlos. A continuación veremos como 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. ==== Preparar el proyecto en el IDE ==== 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 [[mda:de:mda-pr-1.0-de-organizar_el_codigo|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. ==== Planificar Release ==== 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 [[mda:gp:mda-pr-1.0-gp-planificacion_del_proyecto#mda-tr-1.0-planifica_las_releases|Planifica las Release]] del proceso [[mda:gp:mda-pr-1.0-gp-planificacion_del_proyecto|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. ==== Planificar Iteraciones ==== 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 [[mda:gp:mda-pr-1.0-gp-planificacion_del_proyecto#mda-tr-1.0-planifica_las_iteraciones|Planificar las iteraciones]] del proceso [[mda:gp:mda-pr-1.0-gp-planificacion_del_proyecto|Planificación del Proyecto]]. A partir de la planificación de la iteración comienza el trabajo de codificación del sistema. ==== Desarrollo de las iteraciones ==== === Codificación === 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. === Integración === 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 [[mda:de:mda-pr-1.0-de-crear_componentes|Crear Componentes]]. === Integración continua === El jefe de proyecto ha preparado previamente el servidor de integración continua, [[https://jenkins.um.es|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 [[mda:qs:mda-pr-1.0-qs-integrar_continuamente|Integrar Continuamente]]. ==== Trabajos paralelos al desarrollo de las iteraciones ==== 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. === Diseñar los casos de prueba funcionales === 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 [[mda:qs:mda-pr-1.0-qs-realizar_test_funcionales#mda-tr-1.0-qs-disenar_casos_de_prueba|Diseñar casos de prueba]] y [[mda:qs:mda-pr-1.0-qs-realizar_test_funcionales#mda-tr-1.0-qs-automatizar_casos_de_prueba|Automatizar casos de prueba]] respectivamente. === Seguimiento de las Iteraciones === 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 [[mda:gp:mda-pr-1.0-gp-seguimiento_del_proyecto#mda-tr-1.0-seguimiento_de_iteraciones|Seguimiento de Iteraciones]]. === Peticiones de cambio === 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 [[mda:gc:mda-pr-1.0-gc-controlar_los_cambios|Control de cambios]] explica claramente cómo deben ser gestionadas estas peticiones de cambio. === Gestión de los cambios === 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 [[mda:gc:mda-pr-1.0-gc-contabilidad_del_proyecto|Contabilidad del Proyecto]] y a llevar una gestión de los requisitos tal y como indica el proceso [[mda:req:mda-pr-1.0-req-gestion_de_requisitos|Gestionar los requisitos]] ==== Tras finalizar la iteración ==== === Seguimiento de las iteración === 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 [[mda:gp:mda-pr-1.0-gp-seguimiento_del_proyecto#mda-tr-1.0-seguimiento_de_iteraciones|Seguimiento de Iteraciones]]. === Seguimiento de la Release === 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 [[mda:gp:mda-pr-1.0-gp-seguimiento_del_proyecto#mda-tr-1.0-seguimiento_de_releases|Seguimiento de Releases]]. ==== Seguimiento de hitos ==== 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 [[mda:gp:mda-pr-1.0-gp-seguimiento_del_proyecto#mda-tr-1.0-seguimiento_de_hitos|Seguimiento de Hitos]]. ==== Fin de la fase de construcción ==== 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 simultaneamente. Por una parte podemos preparar el código desarrollado hasta el momento para ser liberado, mientras el equipo continua desarrollando software pendiente. En este caso, se ejecutarán simultaneamente la fase de construcción y la de implantación. ===== Fase de liberación ===== {{:mda:mda-1.1-liberacion.png|}} ==== Despliegue de la Release ==== Es el **Jefe del proyecto** el que debe ordenar la liberación de una release. Esta realease, puede estar destinada a ser liberada en preproducción o puede que de despliegue únicamente en preproducción. En cualquier caso las tareas a realizar son las mismas. === Creación de la Release === Es el **Gestor de la configuración**, el encargado de crear la release. Para ello seguirá lo indicado en la tarea [[mda:gc:mda-pr-1.0-gc-liberar_builds_y_releases#mda-tr-1.0-gc-crear_release|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. === Preparación del entorno === 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 [[mda:dsp:mda-pr-1.0-dsp-prepararentornodepruebas|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. ==== Pruebas de la Release ==== 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. === Pruebas por parte de equipo === Los **Tester** del equipo de trabajo, probarán la aplicación tanto funcionalmente, [[mda:qs:mda-pr-1.0-qs-realizar_test_funcionales#mda-tr-1.0-qs-ejecutar_casos_de_prueba|ejecutando los casos de prueba]], como [[mda:qs:mda-pr-1.0-qs-realizar_test_de_carga#mda-tr-1.0-qs-ejecutar_plan_de_pruebas_de_carga|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 [[mda:qs:mda-pr-1.0-qs-controlar_calidad_interna#mda-tr-1.0-qs-pasar_plantilla_de_seguridad|plantilla de seguridad]] y con los de la [[mda:qs:mda-pr-1.0-qs-controlar_calidad_interna#mda-tr-1.0-qs-pasar_plantilla_de_accesibilidad|plantilla de accesibilidad]]. === Pruebas de usuario === Una vez que el equipo ha verificado el funcionamiento de la aplicación, ha realizado pruebas de carga y ha comprobando 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 [[mda:dsp:mda-pr-1.0-dsp-probarsoftware#mda-tr-1.0-dsp-seguimiento_pruebas_de_usuario|seguimiento de las pruebas de usuario ]] y [[mda:qs:mda-pr-1.0-qs-controlar_calidad_interna#mda-tr-1.0-qs-evaluar_resultados|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. ==== Ayudas y formación ==== === Creación de ayudas y manuales === 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 [[mda:dsp:mda-pr-1.0-dsp-elaborardocumentacion|Elaborar manuales de usuario]]. === Formar a los usuarios === Una vez se dispone de las ayudas, en los distintos formatos, 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 [[mda:dsp:mda-pr-1.0-dsp-formarusuarios#mda-tr-1.0-dsp-elaborar_documento_de_gestion|elaborar documento de gestión]] y [[mda:dsp:mda-pr-1.0-dsp-formarusuarios#mda-tr-1.0-dsp-elaborar_encuesta|elaborar la encuesta]] Paralelamente, los formadores [[mda:dsp:mda-pr-1.0-dsp-formarusuarios#mda-tr-1.0-dsp-elaborar_presentacion|elaborar las presentaciones]] necesarias y, cuando todo está preparado, [[mda:dsp:mda-pr-1.0-dsp-formarusuarios#mda-tr-1.0-dsp-impartir_formacion|imparten la formación]]. ==== Cierre del proyecto ==== 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 [[mda:gp:mda-pr-1.0-gp-cierre_del_proyecto|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.