• Author / Uploaded
• Laura Sirvent Collado

Citation preview

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Metodologías Ágiles

Componentes del grupo (miércoles de 17:00 a 19:00): Laura Sirvent Collado Rómulo Espinosa Montoya Dulce Isis Segarra López Contacto: Blog de grupo: http://waphilim.blogspot.com/p/contacto.html Page | 0

Segundo Curso Segundo Cuatrimestre

AESM

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Índice DSDM - Dynamic System Development Method --------------------------------------------------Página 2 Introducción Fases Factores que influyen en el éxito de DSDM Roles Comparación con otros métodos de desarrollo Herramientas de aplicación Crystal Clear -------------------------------------------------------------------------------------------------Página 8 Introducción Aplicación Propiedades Ventajas Desventajas Técnicas Roles y artefactos Herramientas de aplicación AUP – Proceso Unificado Ágil --------------------------------------------------------------------------Página 12 Introducción Características Fases Disciplinas Hitos Artefactos Herramientas de aplicación Tablas comparativas -------------------------------------------------------------------------------------Página 18 Características Roles Artefactos Bibliografía y referencias -------------------------------------------------------------------------------Página 20

Page | 1

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

DSDM - Dynamic System Development Method Se trata de un método que nos brinda un marco de trabajo para llevar a cabo un desarrollo ágil de software. DSDM es un método iterativo e incremental que incluye algunos principios del desarrollo ágil como es el de involucrar tanto a clientes como a usuarios en el desarrollo del sistema. Gracias al enfoque que guía esta metodología, encaja perfectamente con el movimiento de metodologías ágiles. La estructura de esta metodología fue fundada siguiendo 9 principios: 1. 2. 3. 4.

5. 6. 7. 8. 9.

El usuario debe estar involucrado en el proyecto en todo momento. El equipo de desarrollo debe ser el que tenga el poder de tomar las decisiones finales. Se ha de concentrar el esfuerzo en tratar de realizar entregas frecuentes de productos. El equipo y el cliente deben estar conformes con el propósito del negocio, ya que este será un criterio esencial a la hora de que se acepten los entregables que se irán generando. El desarrollo iterativo e incremental es vital para poder llevar a cabo un desarrollo correcto del sistema. Cualquier cambio que se realice durante el desarrollo del sistema, debe ser reversible. Los requerimientos se especifican a un alto nivel, es decir, de forma general. Las pruebas se integran a través del ciclo de vida del producto, es decir, se llevan a cabo a lo largo de todo el ciclo de vida del producto. Es vital que se siga un enfoque colaborativo y cooperativo entre las partes que están involucradas en el proyecto, es decir, todos deben colaborar para que el proyecto sea desarrollado de forma correcta, cumpliendo las expectativas de todas las partes.

Otro punto importante de DSDM es que no se ajustan tiempo y recursos para lograr cada funcionalidad, sino que es la funcionalidad la que se adapta a tanto al tiempo como a los recursos disponibles. Para establecer estas funcionalidades se siguen unas reglas, conocidas como “MoSCoW”, iniciales de su nombre en inglés. Las reglas organizan los requerimientos en una serie de prioridades: Must have (debe tener): estipula qué requerimientos son fundamentales para el sistema. De todos estos requerimientos, se establece un subconjunto que como mínimo el sistema deberá cumplir. Should have (debería tener): son requerimientos que también se deberán cumplir ya que son importantes, además deberán resolverse a corto plazo. Could have (podría tener): son requerimientos que puede ser que se queden fuera del sistema.

Page | 2

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Want to have but won’t have this time around (se quiere tener, pero no lo tendrá esta vuelta): son requerimientos deseados pero que pueden esperar, son de una prioridad más baja.

Fases En Dynamic System Development Method existen 3 fases en el desarrollo de un sistema. Estas son: Fase 1 - Pre-proyecto: se identifican los proyectos candidatos, se realiza la financiación del proyecto y se garantiza el compromiso del mismo. Abordar estas cuestiones en esta fase tan temprana del desarrollo, evita tener que afrontarlas en fases avanzadas donde supondrían un problema mucho mayor. En esta fase se crean los Términos de referencia, un documento escrito de una o dos páginas donde se especifican los temas indicados anteriormente, de esta forma se puede saber qué proyectos tienen potencial para ser desarrollados y cuales no. Fase 2 - Ciclo de vida del proyecto: esta fase es la más importante. Se divide en 5 etapas por las que el proyecto deberá pasar para poderse crear el sistema deseado. Las dos primeras etapas, Estudio de factibilidad y Estudio del negocio son fases secuenciales que se complementan entre ellas. Una vez realizadas dichas fases, el sistema se desarrolla de forma iterativa e incremental en las fases de iteración del modelo funcional e iteración del diseño y construcción. Finalmente se realiza la etapa de despliegue. Las 5 etapas son: •

Estudio de la factibilidad: en primer lugar se evalúa el uso de DSDM u otra metodología según ciertos criterios, como son el tipo de proyecto, el tipo de organización y el personal de la misma. Si finalmente se determina que DSDM es la mejor opción, se analizan las posibilidades técnicas y los riesgos. Es entonces cuando se prepara un reporte de viabilidad y un plan con el desarrollo. En el caso de que la tecnología no se conozca, se diseña un pequeño prototipo. La duración del estudio no debería durar más de unas pocas semanas y, aunque este tiempo es algo elevado para tratarse de una metodología ágil, es menos del que una metodología más clásica necesita.

•

Estudio del negocio: Se analizan las diferentes características de la organización y la tecnología. Se suelen desarrollar una serie de talleres donde los expertos de los clientes consideran cuáles son las características del sistema y establecen sus prioridades de desarrollo. Otro punto importante es que en esta fase se describen los diferentes procesos de negocio y las clases de usuario que interactuarán con el sistema en una Definición del Área de Negocios, gracias a ello se involucra al cliente y a gente clave de la organización en una etapa muy temprana.

Page | 3

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

•

Iteración del modelo funcional: se definen las características identificadas anteriormente de forma más específica. También se lleva a cabo el código, además se construyen los prototipos y se mejoran los modelos de análisis. Los prototipos se irán mejorando gradualmente, hasta alcanzar una calidad igual a la que debe tener el producto final. Como resultado se crea un Modelo Funcional que contiene el código del prototipo y los modelos de análisis. Existen además 4 productos que son creados en esta fase: Funciones priorizadas, Documentos de revisión del prototipado funcional, Requerimientos funcionales y Análisis de riesgo de desarrollo.

•

Iteración del diseño y construcción: se construye la mayor parte del sistema. El producto resultante es un sistema probado que deberá cumplir los requerimientos que se establecieron, al menos el mínimo acordado inicialmente. Tanto el diseño como la construcción son iterativos, además el diseño y los prototipos funcionales son revisados por usuarios.

•

Despliegue: el sistema entra en fase de producción. Se entrega a los usuarios para que puedan hacer un uso adecuado del sistema, para ello se pone el mismo a su disposición. También son creados otros productos en esta fase, como son el Manual de usuario y el Reporte de revisión del sistema. Esta fase podría llegar a iterarse si fuese necesario. En cualquier caso, pueden darse 4 posibilidades 1. 2. 3.

4.

Si el sistema satisface todos los requerimientos, se puede dar por finalizado el desarrollo. Si queda un número elevado de requerimientos sin resolver, se puede comenzar el proceso nuevamente desde el principio. Si algún requerimiento no crítico no ha sido atendido, es posible realizar un proceso para incluirlo, empezando por la fase de la iteración del modelo funcional, y desde esa fase se desarrolla todo el proceso hasta el final. Si algunas cuestiones técnicas no pudieron resolverse debido a plazos que no se pudieron atender, se puede iterar desde la fase de diseño y construcción en adelante.

Fase 3: En esta fase el equipo se cerciora de que el sistema opera de forma eficiente y efectiva. Para ello se realizan mantenimientos, mejoras y correcciones de acuerdo a los principios de la metodología Dynamic Systems Development Method. El mantenimiento puede basarse en un proceso iterativo e incremental. El proyecto además, en lugar de terminarse en un ciclo concreto, se puede volver a una etapa anterior para atender otros requerimientos o hacer las modificaciones que se crean oportunas. Por último, en esta fase se crea el producto Valoración de beneficios, donde se detallarán los beneficios obtenidos por la implementación de la solución.

Page | 4

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Factores que influyen en el éxito del DSDM Existen una serie de factores que juegan un papel importante a la hora de llevar a cabo los proyectos con éxito: Tanto la gerencia como los empleados deben aceptar la metodología DSDM. Gracias a esto se conseguirá que todos los miembros del equipo estén motivados desde el principio, al igual que el resto de personas involucradas en el proceso de desarrollo. Se requiere saber con seguridad que en usuario final va a participar a lo largo del desarrollo del producto. Un enfoque de prototipos requiere de una participación activa por parte del usuario final para que se puedan realizar pruebas óptimas y juzgar los prototipos de que se disponga. El equipo debe estar formado por miembros habilidosos, formando un grupo estable. Por ello, se debe otorgar al equipo el poder de decidir sobre los temas más importantes en cuanto al proyecto se refiere, sin tener que realizar tediosas peticiones a la gerencia. Además se debe brindar al equipo las herramientas hardware y software necesarias para llevar a cabo el proyecto sin dificultades.

Roles DSDM define quince roles, un número elevado si atendemos al número de roles del resto de metodologías ágiles. Los más importantes son: 1. Programadores y programadores Senior: Son los únicos roles de desarrollo. El programador Senior es el líder dentro del equipo. Entre ambos roles cubren todos los roles del desarrollo, incluyendo analistas, diseñadores, programadores y testeadores. 2. Coordinador técnico: es el encargado de definir la arquitectura del sistema, además, es el responsable de que el proyecto tenga una calidad técnica adecuada. También es el encargado del control técnico y de la configuración del sistema. 3. Usuario embajador: es el encargado de proporcionar conocimientos sobre la comunidad de usuarios y se encarga de retroalimentarlos con información sobre el progreso del sistema. Adicionalmente se define un rol de Usuario Asesor, el cual se encarga de representar otros puntos de vista importantes. 4. Visionario: se trata de un usuario que tiene la percepción y el punto de vista más exacto sobre los objetivos del sistema. Permite que los requerimientos más importantes, los esenciales, se cumplan, y que el proyecto siga el camino que ha de seguir para que sea un sistema adecuado para los usuarios.

Page | 5

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

5. Patrocinador ejecutivo: la persona que lleva a cabo este rol es la que tiene la última palabra a la hora de tomar las decisiones importantes. Esto se debe a que es una persona de la organización con autoridad y responsabilidad financiera. 6. Facilitador: se encarga de administrar el progreso del desarrollo, y de facilitar la comunicación entre el equipo. 7. Escriba: se encarga de registrar todos aquellos acuerdos y decisiones que se lleven a cabo en las diferentes sesiones y reuniones.

Comparación con otros métodos de desarrollo Aunque hay diversas metodologías parecidas a DSDM, hay algunas que se aproximan más que otras. Por ejemplo guarda similitud con eXtreme Programming (XP) por tratarse también de una metodología con un enfoque iterativo. Pero en cuanto a similitudes, quizá el más similar a SDSM es el Proceso Unificado de Rational (RUP), ya que ambos son formas muy dinámicas de desarrollar sistemas de información, además de compartir el enfoque iterativo. Existen más metodologías que guardan similitudes con SDSM pero esta metodología presenta una serie de características que la diferencian del resto: Proporciona un marco de trabajo independiente. Permite a los usuarios completar las etapas específicas del proceso con las técnicas y ayudas software que crean oportunas. En esta metodología las variables en el desarrollo del producto no son tiempo y recursos, sino los requisitos. Aunque otras metodologías también especifican que el compromiso con el proyecto y la metodología elegida debe ser fuerte, en DSDM se considera un punto vital para asegurar un resultado satisfactorio del proyecto.

Herramientas de aplicación DSDM ha sido diseñado de tal forma que no requiere de un software específico para ser implementado, en cualquier caso existen algunos software en el mercado dan soporte en el proceso, como es el caso de Spira Plan: Spira Plan – DSDM Project Management: Se trata de un sistema de gestión de proyectos ágiles. Está diseñado para brindar apoyo en metodologías ágiles como DSDM. La versión actual permite ir estableciendo los requerimientos del proceso de desarrollo, así como gestionar las tareas, errores e incidencias.

Page | 6

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Además, Spira Plan ofrece una herramienta para realizar informes sobre los progresos y los indicadores de riesgo del proyecto, como pueden ser: progreso de tareas, velocidad del proyecto, los riesgos e incidencias más importantes, etc…

Page | 7

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Crystal Clear Está metodología fue creada por Alistair Cockburn. La metodología Crystal, más que una metodología en sí, es considerada un conjunto de metodologías que se centran en la eficiencia y habitabilidad del proyecto. Se podría decir que este conjunto tienen algo en común, algo llamado “código genético” que trata de los puntos claves que han de seguir. Las metodologías de las que se compone Crystal se clasifican según el tamaño del equipo y la complejidad del proyecto, asignándole a cada metodología un color. Por ejemplo, para equipos de 8 personas o menos tendremos Clear, es decir, la metodología Crystal Clear, para mayor tamaño de equipo tendremos Yellow, Orange... De las metodologías Crystal, la más utilizada es Crystal Clear. Para Crystal Clear, el equipo de desarrollo es un factor clave, mientras que se le resta importancia a los procesos y a los artefactos. Los más importante es la comunicación del equipo, facilitando la misma con la entrega frecuente de código confiable y funcionando, y permitiendo, gracias a ello, evitar distracciones. Esta metodología está dirigida a equipos de menos de 6 u 8 personas para el desarrollo de sistemas no críticos.

Aplicación Como ya se ha dicho, Crystal Clear se aplica en grupos de 6 a 8 personas que trabajen el mismo sitio con uno o más usuarios expertos disponibles. Este tipo de metodología te permite moldear las técnicas utilizadas para llevar a cabo ciertos proyectos que no se ajustan demasiado a la metodología.

Propiedades Crystal Clear cuenta con las siguientes propiedades, de las cuales, las tres primeras son imprescindibles: Entrega frecuente: se van realizando pequeñas entregas a los clientes, de forma que van visualizando los cambios y viendo si se está obteniendo lo que realmente desea. Comunicación osmótica: todos los desarrolladores se encuentran en un mismo cuarto, y en ocasiones se dispone de un experto diseñador al que realizar cuestiones sobre el sistema. Mejora reflexiva: unas pocas horas a la semana o una vez al mes se toma un tiempo para reflexionar lo que se está realizando, discutirlo, revisar documentos.

Page | 8

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Seguridad personal: cuando hay algún problema en el grupo, han de hablar los implicados para resolverlo. Foco: siempre se ha de tener muy claro lo que se está realizando y tener la tranquilidad y el tiempo suficiente para ello. Fácil acceso a usuarios expertos: en esta metodología se tiene alguna comunicación con desarrolladores expertos a los que consultar.

Ventajas Siguiendo las propiedades y técnicas de Crystal Clear podremos obtener un final exitoso sobre el proyecto. Sin embargo, no se garantiza el éxito debido a factores externos, aunque se ha observado en múltiples proyectos que dichas propiedades y técnicas contribuyen a ello. A diferencia de las metodologías tradicionales, Crystal Clear es flexible en cuanto a qué y cómo debe realizar el equipo un determinado proyecto. De hecho, Crystal Clear fue desarrollado específicamente para ser usado por el mayor número de equipos de proyecto posible teniendo que aprender el menor número de nuevas técnicas posibles.

Desventajas Crystal Clear intenta ser aplicable en tantos casos como sea posible. Esto evita que sea la mejor metodología en un caso específico. Crytal Clear es relativamente nuevo, lo que provoca que no tenga demasiada documentación y experiencia real. Sin embargo, los principios de Crystal Clear están basados en experiencias reales sobre proyectos reales.

Técnicas Con Crystal Clear se favorecen las siguientes técnicas: Entrevistas de proyectos: se entrevista a los responsables proyecto para tener distintas visiones sobre el mismo. Reuniones de reflexión: el equipo ha de reflexionar un tiempo determinado sobre su trabajo, plantear inconvenientes, mejoras y plantearse el siguiente periodo del proyecto. Planteamiento Blitz: al igual que en la metodología XP, se plantean unas tarjetas, cada una con una historia de usuario, sobre las que los desarrolladores habrán de plantear el tiempo de desarrollo y el esfuerzo que conlleva cada una. Una vez se haya estimado, el cliente ordena las tarjetas según la prioridad que le dé y teniendo en cuenta el valor de negocio que aporta cada una.

Page | 9

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Estimación Delphi: se reúnen los responsables expertos para determinar el tamaño del sistema, su tiempo de ejecución y la fecha de entrega de cada una de las entregas que se irán realizando. Encuentros a pie: se trata de una breve reunión en la que identificar los posibles problemas. Gráficos de quemado: se trata de gráficas en las que se visualiza el rendimiento del equipo y la velocidad en que las tareas que se van realizando. De esta forma, en caso de haber algún retraso o problema, se podrá detectar antes de que sea demasiado tarde. Programación lado a lado: cada desarrollador se centra en su trabajo, pero siempre echando un ojo al compañero de al lado como posible apoyo.

Roles y Artefactos Patrocinador: el patrocinador dice qué proyecto se ha de realizar, además de proporcionar los recursos necesarios para el mismo. Realiza la declaración de la misión con prioridades Comerciales (se describe el propósito del proyecto y sus prioridades). Usuario Experto: es la persona que está familiarizada con el sistema y sus procedimientos, conociendo que atajos de teclado son necesarios y qué información necesita verse en pantalla. Junto con el experto en negocios produce la lista de actores objetivos y el archivo de casos de uso y requerimientos. Diseñador Principal: diseña la arquitectura del sistema. El diseñador principal tiene que ser de nivel 3, es decir, es capaz de realizar la mayor parte del diseño del proyecyo y de dirigir al equipo cuando sea necesario. En Metodologías Ágiles se definen tres niveles de experiencia: o Nivel 1: es capaz de seguir los procedimientos. o Nivel 2: es capaz de apartarse de los procedimientos específicos y encontrar otros distintos. o Nivel 3: es capaz de manejar con fluidez, mezclar e inventar procedimientos. El Diseñador Principal tiene roles de coordinador, arquitecto, mentor y programador más experto. Diseñador Programador: junto con el diseñador principal, crea los borradores de pantallas, el modelo común de dominio (esquema o diagrama en el que se muestra las entidades principales del sistema), las notas y diagramas de diseño, el código fuente, el código de migración, las pruebas y el sistema empaquetado. En Crystal Clear no hay programadores, sino diseñadores-programadores, ya que todo programa se basa en diseño y programa.

Page | 10

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Experto en Negocios: junto con el usuario experto produce la lista de actores objetivos y el archivo de casos de uso, requerimientos y modelo de roles de usuarios. Debe conocer las reglas y políticas del negocio. Coordinador: con la ayuda del equipo produce el mapa de proyecto, el plan de entrega, el estado del proyecto, la lista de riesgos, el plan y estado de iteración y la agenda de visualización. Se encarga de manejar el proyecto. Verificador: se encarga de la realización de pruebas. Puede ser un programador en tiempo parcial, o un equipo de varias personas. Escritor: produce el manual de usuario. El equipo es responsable de producir la estructura y convenciones del equipo y los resultados de las reuniones de reflexión.

Herramientas de aplicación Crystal Clear puede adaptarse a la hora de utilizar una herramienta para su implementación, por ello puede utilizar cualquier herramienta para la aplicación de metodologías ágiles. Crystal Clear no tiene una herramienta para su implementación en concreto debido a que s encuentra en una fase temprana de su desarrollo.

Page | 11

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Proceso Unificado Ágil (AUP) El Proceso Unificado Ágil (Agile Unified Process en inglés) o AUP, ideado por Scott Ambler, es una simplificación del Proceso Unificado de Rational,que explica de una forma fácil y sencilla una manera de desarrollar software utilizando metodologías ágiles, como Extreme Programming, Test Driven Development o Agile Model Driven Development, fusionadas con conceptos más tradicionales, es decir, RUP. Al ser una simplificación del RUP, conserva algunas de sus características, como el ser iterativo e incremental, aunque con algunas variaciones, como la de dar preferencia a actividades que tengan cierto riesgo, para que estas sean realizadas en las etapas tempranas del proceso de desarrollo. Igualmente es un método ágil porque incluye de forma exacta algunas de las metodologías que se aplican en técnicas ágiles como XP. Desde un punto de vista tradicional, el AUP puede verse más simple que las versiones más clásicas del proceso unificado, mientras que desde el punto de vista ágil, puede entenderse como una versión más pesada que las metodologías ágiles. Este puede ser un punto a favor a la hora de la empresa decidir que metodología de desarrollo utilizar, por la incertidumbre que puede producir el elegir una metodología a la que el proyecto no se adapte completamente.

Características Podemos destacar algunas de las propiedades que caracterizan el proceso unificado ágil, que como se ha explicado anteriormente, toma algunas del proceso unificado de Rational y las mezcla con otras provenientes de metodologías ágiles: Simplicidad, gracias a que reduce el número de disciplinas que tiene RUP. El número de disciplinas con las que cuenta AUP son siete: Modelado, Implementación, Prueba, Despliegue, Gestión de Configuración, Gestión de Proyectos y Ambiente, donde las cuatro primeras son de implementación, y las tres restantes son disciplinas denominadas de apoyo. Por otra parte, la disciplina de Modelado agrupa las cuatro primeras disciplinas de RUP (Modelado de negocio, Requerimientos, Análisis y Diseño). Ajuste a los valores ágiles, como por ejemplo la aceptación de cambios en los requisitos sobre la marcha, la entrega periódica y frecuente de software funcional, trabajar juntos el equipo de desarrollo con el cliente, etc. Siempre amoldándose a los principios de la Alianza Ágil.

Se centra en las actividades que más valor tienen dentro del proyecto. AUP permite que las tareas sean priorizadas en función del valor que puedan tener, y en las que mayor atención en el desarrollo requieren. Page | 12

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Es adaptable al proyecto. Esto quiere decir que AUP puede amoldarse a las características que tenga el proyecto que se va a implementar. Igualmente, AUP tiene independencia de la herramienta con la que se gestione, lo que implica otro grado más de adaptación de esta metodología al proyecto y a la empresa, por ejemplo si una empresa acostumbra a utilizar un software determinado para la gestión del proyecto, tomar AUP como metodología de desarrollo no obliga tener que adquirir otro software. Este enfoque de desarrollo de software puede estar orientado a equipos de desarrollo que buscan un punto intermedio entre metodologías ágiles y metodologías tradicionales, es decir, que adoptan las características de la Alianza Ágil, pero que a su vez incluye de forma explícita una serie de actividades y artefactos que puedan ser necesarios para el proyecto a implementar. Implica tanto una ventaja, en el sentido de si una empresa busca una metodología que cumpla estas características, y con un perfil de trabajadores abierto y capaz de adaptarse a la parte más ágil, o viceversa, que pueda adaptarse a la parte mas tradicional del AUP, como una desventaja si esta empresa ya tiene una metodología asentada, sus trabajadores podrían considerarla demasiado pesada, o si están acostumbrados al proceso unificado, encontrar AUP demasiado ligero.

Fases El ciclo de vida de AUP, de igual manera que su versión original, está compuesto por cuatro fases, Inicio, Elaboración, Construcción y Transición. A continuación se va a definir para cada una de estas fases tanto la finalidad de la fase como los objetivos determinados a cumplir al terminar dicha fase: Fase de Inicio Al finalizar esta fase, se obtendrá una primera definición de qué va a componer el sistema, cómo va a desarrollarse y qué va a suponer, todo esto siendo de común entendimiento entre el cliente y el equipo de desarrollo. Concretamente los objetivos a cumplir son los siguientes: Definir el ámbito y alcance del proyecto, determinando en alto nivel qué va a hacer y qué no va a hacer el sistema, todo establecido a partir de un tipo de lista que explica a grandes rasgos las funcionalidades del software a desarrollar y casos de uso. También se establece las herramientas con las que trabajará el equipo. Estimar costes y tiempos de desarrollo, donde estas estimaciones serán utilizadas para las primeras iteraciones de la fase de Elaboración, y además serán detalladas con más acierto conforme avance el desarrollo del proyecto.

Page | 13

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Determinar riesgos, ya que la gestión de los riesgos es de vital importancia en un proyecto AUP. Los riesgos conducen el camino que seguirá el proyecto, las tareas con mayores riesgos requieren mayor tiempo de realización y han de priorizarse correctamente. Por otra parte, determinar la viabilidad del proyecto, es decir, que el equipo sea capaz de poder desarrollar lo que se está pidiendo, y que en términos económicos, los costes de desarrollo sean viables para la empresa, para determinar una posible cancelación del proyecto si se dictamina que no es viable. Preparar el entorno del proyecto, reservando el espacio de trabajo para el equipo, planificando qué personas serán necesarias para el desarrollo y que van a tener que adquirir (hardware y software). Fase de Elaboración Principalmente, en esta fase, el equipo de desarrollo profundizará en los requisitos y la arquitectura del sistema que se va a desarrollar, para así asegurar que el equipo realmente puede implementar un sistema que cumpla los requisitos del cliente, para ello, lo más fiable es construir un prototipo de la arquitectura, que es una especie de esqueleto funcional del software, y que tiene como finalidad la de tener la posibilidad de escribir código de calidad y que funcione, y además que cumpla los requisitos y satisfaga los casos de uso. El equipo de desarrollo también tiene que prepararse para la siguiente fase, ya que conforme va conociendo la arquitectura del sistema, van a comenzar a definir el entorno para la construcción del mismo, consiguiendo las herramientas necesarias, software, hardware. Por otra parte, no todos los requisitos están determinados al llegar a esta fase, sino que sólo han sido especificados en parte para poder ver con claridad los riesgos en la arquitectura. Estos riesgos son priorizados y son definidos con más determinación en esta fase, por ejemplo, creando prototipos funcionales, pruebas o investigando sobre sistemas similares. La fase finaliza cuando se llega al hito Lifecycle Architecture, el equipo muestra que tiene una estrategia de desarrollo viable para construir el desarrollo a partir de la demostración con el prototipo que se ha creado. Si se llega al hito correctamente se pasa a la fase de Construcción. Fase de Construcción El objetivo principal de la fase es la de desarrollar el sistema hasta el punto de estar listo para las pruebas previas a la producción final. Tanto en las fases de Inicio como de Elaboración se han definido todos los requisitos y la arquitectura del software. En la Construcción se priorizan los requerimientos, se crea un modelo y a partir de ahí, se empieza a escribir y probar el código del software. Para ciertos proyectos, puede resultar necesario y positivo el lanzar versiones iniciales del sistema, ya sea de forma

Page | 14

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

interna o externa a la empresa, con el fin de conseguir opiniones y feedback de los usuarios. La fase de Construcción finaliza cuando se llega al hito de Initial Operational Capability, y el software construido es estable, tiene aceptación de los riesgos, las estimaciones de coste y temporales son aceptables, y la empresa está lista para la producción del sistema. Si se llega correctamente a este hito, el proyecto se mueve a la fase de Transición. Fase de Transición Por último, la fase de Transición se centra en llevar el sistema a su producción. Las funciones más importantes que son realizadas aquí son las de probar el software, lanzar versiones beta, y afinar el producto, con posibles reformas en el producto para eliminar posibles defectos. La duración y volumen de trabajo de esta fase es difícil de estimar y varía de proyecto en proyecto. Para dar por finalizada esta fase, el equipo tiene que llegar correctamente al hito de Product Release. En este momento, el sistema está listo para su producción.

Disciplinas Modelado: Entender el proyecto y su viabilidad en la empresa, buscar como solucionar el problema. Según la fase en la que se encuentre el proyecto, esta disciplina tendrá más o menos volumen de trabajo, por ejemplo, en la fase de Inicio, se buscarán explícitamente los casos de uso y los requerimientos, los cuales serán priorizado, mientras que en la fase de Elaboración se identificarán los riesgos técnicos del proyecto. Se producen modelos del sistema, que serán utilizados en la disciplina de Implementación. Implementación: Convertir los modelos creados a código ejecutable, además de llevar a cabo pruebas generales. Aquí se adoptan ciertas metodologías ágiles, como TDD o programación en parejas. Prueba: Llevar a cabo una evaluación objetiva, a partir de pruebas, del software con el fin de comprobar la calidad del mismo. Se buscan posibles errores y defectos, que el sistema funcione como se requería y como se ha diseñado. Despliegue: Se planea la producción o entrega del sistema al cliente, o hacer llegar el software a los usuarios finales. Se estima el rango de fechas en el que es posible entregar el software, y se comienza a crear un plan de despliegue, que se comienza en la fase de Inicio y se va construyendo hasta finalizar la fase de Construcción. La fase de transición es la que más trabajo en esta disciplina tiene ya que se finalizan el “paquete” del software que va a distribuirse y su documentación, se anuncia la distribución, y demás tareas que llegan al usuario final.

Page | 15

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Gestión de Configuración: Gestionar el acceso a herramientas del proyecto, hacer un seguimiento de las versiones en el tiempo y los posibles cambios que puedan hacerse. Gestión de Proyecto: Controlar las actividades que se van sucediendo en el ciclo de vida del proyecto, gestionando los riesgos, asignando tareas a los trabajadores, controlando el progreso del proyecto, y coordinar a todo el equipo, tanto en factores internos como externos, para que el sistema sea entregado en el tiempo acordado. Ambiente: Comprobar y asegurar que el entorno de trabajo es el adecuado, apoyar a los miembros del equipo, para garantizar que el proyecto es desarrollado satisfactoriamente.

Hitos AUP diferencia cuatro hitos, uno para la finalización de cada una de las fases: Lifecycle Objectives (LCO): Al finalizar la fase de Inicio, al llegar a este hito se aceptan una serie de puntos: Los requerimientos iniciales han sido definidos, se aceptan los riesgos, la viabilidad del proyecto, se ha hecho un plan de trabajo, con costes y tiempo estimado. Lifecycle Architecture (LCA): Se llega a este hito al acabar la fase de Elaboración, aceptando que la visión del proyecto y su arquitectura están estabilizada y son realistas, siendo la arquitectura suficiente para satisfacer los requerimentos. Se aceptan los riesgos, la viabilidad y el plan de trabajo. Initial Operational Capability (IOC): Al finalizar la fase de Construcción, se acepta que el sistema es estable, teniendo el software suficiente documentación y el software preparado para la entrega. Product Release (PR): Al acabar la fase de Transición, se acepta que las operaciones para poner el sistema en producción son correctas, los costes y tiempos están bien estimados, los stakeholders de la empresa están satisfechos con el sistema.

Artefactos AUP tiene flexibilidad en cuanto al número y tipos de artefactos son necesarios para cada fase y disciplina, pero aún así existen un mínimo de estos que deben ser creados para cumplir con la parte más tradicional de esta metodología. Los artefactos, en orden de prioridad que son necesarios son:

Page | 16

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Sistema Código fuente Conjunto de pruebas Scripts de instalación del sistema en el entorno del usuario Documentación del sistema, para el mantenimiento del sistema Notas de las versiones lanzadas Modelo de requisitos Modelo de diseño Igualmente, pueden crearse los artefactos que la empresa necesite para la gestión del proyecto.

Roles Los roles que toma cada una de las personas de una empresa que sigue la metodología AUP. Los roles pueden ser asumidos por una o varias personas, una misma persona puede asumir más de un rol. Algunos de los roles: Administrador del proyecto Desarrollador Modelador ágil Administrador de bases de datos ágil Administrador de la configuración Implementador Examinador Administrador de pruebas, equipo de pruebas

Herramientas de aplicación AUP tiene independencia de las herramientas con las que gestionen su ciclo de vida, por lo que puede adaptarse para utilizarse la herramienta que la empresa utilice normalmente, y que más se adapten el proceso.

Page | 17

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Comparativa de metodologías Características AUP

CC

DSDM

Adaptar el proceso de desarrollo

SÍ

SÍ

SÍ

Alto nivel de abstracción

NO

SÍ

SÍ

Fomento del aprendizaje de experiencias

NO

NO

NO

Centrarse en la arquitectura

SÍ

NO

NO

Interacción continua con cliente

SÍ

SÍ

SÍ

Código estándar

SÍ

NO

NO

Colaboración entre equipo

SÍ

SÍ

SÍ

Demostrar resultados Iterativamente e incrementalmente

SÍ

SÍ

SÍ

Diseño simple

NO

SÍ

NO

Enfoque continuo en la calidad

SÍ

NO

SÍ

Permanecer ágil y esperar los cambios

SÍ

NO

SÍ

Dirigido por Casos de Uso

SÍ

SÍ

NO

Para pequeños grupos de trabajo

NO

SÍ

SÍ

Para grandes grupos de trabajo

SÍ

NO

NO

Para proyectos complejos

SÍ

NO

NO

Para proyectos simples

NO

SÍ

SÍ

AUP

CC

DSDM

Analista de Calidad

NO

NO

SÍ

Analista del Producto

NO

SÍ

NO

Arquitecto

SÍ

SÍ

SÍ

Desarrollador

SÍ

SÍ

SÍ

Roles

Page | 18

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Involucrados

SÍ

SÍ

SÍ

Líder de Proyecto

SÍ

SÍ

SÍ

Probador

SÍ

SÍ

SÍ

Otro Roles

SÍ

SÍ

SÍ

AUP

CC

DSDM

Caso del Negocio

Sí*

SÍ

SÍ

Documento de Arquitectura del Software

SÍ*

SÍ

SÍ

Especificaciones Suplementarias

SÍ

SÍ

Sí

Modelo de Casos de Uso

SÍ

SÍ

SÍ

Modelo de Diseño

SÍ

SÍ

NO

Modelo de Implementación

SÍ

SÍ

SÍ

Plan de Gestión de Riesgos

Sí*

NO

SÍ

Plan de Implantación

Sí*

SÍ

NO

Plan de Iteración

Sí*

SÍ

NO

Plan de Pruebas

Sí*

SÍ

SÍ

Planificación del Proyecto

SÍ

SÍ

SÍ

Visión del Sistema

SÍ

SÍ

NO

Artefactos

*No es obligatorio

Page | 19

Grado en Ingeniería Multimedia Análisis y Especificación de Contenidos

Segundo Curso Segundo Cuatrimestre

Bibliografía y referencias Dynamic System Development Method - DSDM http://es.wikipedia.org/wiki/M%C3%A9todo_de_desarrollo_de_sistemas_din%C3%A1micos http://en.wikipedia.org/wiki/Dynamic_systems_development_method http://www.dsdm.org/ (requiere registro) http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF

Crystal Clear - CC http://www.ingenieriadesoftware.mex.tl/59189_Metodologia-Crystal.html http://blog.tercerplaneta.com/2007/02/ms-all-de-las-capacidades-tcnicas-que.html http://en.wikipedia.org/wiki/Crystal_Clear_%28software_development%29 http://infolific.com/technology/methodologies/crystal-methods/ http://www.cs.umss.edu.bo/doc/material/mat_gral_130/exposicion_Crystal.ppt http://paul.luon.net/essays/SEP-essay-final.pdf http://es.scribd.com/doc/55555056/Crystal-Clear-Version-Open-Document

Proceso Unificado Ágil – AUP http://www.ambysoft.com/unifiedprocess/agileUP.html http://www.ambysoft.com/downloads/agileUP.zip http://www.adolfo.mex.tl/images/18149/METODOLOGIAS%20AGILES.pdf http://www.ecured.cu/index.php/Agile_Unified_Process http://www.methodsandtools.com/archive/archive.php?id=21 http://wikis.uca.es/wikiCE/index.php/Agile_unified_process https://sites.google.com/site/ingsoportelogico/home/agile-unified-process

Page | 20