You are on page 1of 21

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Metodologas giles

AESM

Componentes del grupo (mircoles de 17:00 a 19:00): Laura Sirvent Collado Rmulo Espinosa Montoya Dulce Isis Segarra Lpez Contacto: Blog de grupo: http://waphilim.blogspot.com/p/contacto.html Page | 0

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

ndice
DSDM - Dynamic System Development Method --------------------------------------------------Pgina 2 Introduccin Fases Factores que influyen en el xito de DSDM Roles Comparacin con otros mtodos de desarrollo Herramientas de aplicacin Crystal Clear -------------------------------------------------------------------------------------------------Pgina 8 Introduccin Aplicacin Propiedades Ventajas Desventajas Tcnicas Roles y artefactos Herramientas de aplicacin AUP Proceso Unificado gil --------------------------------------------------------------------------Pgina 12 Introduccin Caractersticas Fases Disciplinas Hitos Artefactos Herramientas de aplicacin Tablas comparativas -------------------------------------------------------------------------------------Pgina 18 Caractersticas Roles Artefactos Bibliografa y referencias -------------------------------------------------------------------------------Pgina 20

Page | 1

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

DSDM - Dynamic System Development Method


Se trata de un mtodo que nos brinda un marco de trabajo para llevar a cabo un desarrollo gil de software. DSDM es un mtodo 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 gua esta metodologa, encaja perfectamente con el movimiento de metodologas giles. La estructura de esta metodologa fue fundada siguiendo 9 principios: 1. 2. 3. 4. 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 propsito del negocio, ya que este ser un criterio esencial a la hora de que se acepten los entregables que se irn 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 travs 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 estn 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.

5. 6. 7. 8. 9.

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 ingls. 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 mnimo el sistema deber cumplir. Should have (debera tener): son requerimientos que tambin se debern cumplir ya que son importantes, adems debern resolverse a corto plazo. Could have (podra tener): son requerimientos que puede ser que se queden fuera del sistema.

Page | 2

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Want to have but wont have this time around (se quiere tener, pero no lo tendr esta vuelta): son requerimientos deseados pero que pueden esperar, son de una prioridad ms 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 financiacin 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 supondran un problema mucho mayor. En esta fase se crean los Trminos de referencia, un documento escrito de una o dos pginas 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 ms 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 iteracin del modelo funcional e iteracin del diseo y construccin. Finalmente se realiza la etapa de despliegue. Las 5 etapas son:

Estudio de la factibilidad: en primer lugar se evala el uso de DSDM u otra metodologa segn ciertos criterios, como son el tipo de proyecto, el tipo de organizacin y el personal de la misma. Si finalmente se determina que DSDM es la mejor opcin, se analizan las posibilidades tcnicas y los riesgos. Es entonces cuando se prepara un reporte de viabilidad y un plan con el desarrollo. En el caso de que la tecnologa no se conozca, se disea un pequeo prototipo. La duracin del estudio no debera durar ms de unas pocas semanas y, aunque este tiempo es algo elevado para tratarse de una metodologa gil, es menos del que una metodologa ms clsica necesita. Estudio del negocio: Se analizan las diferentes caractersticas de la organizacin y la tecnologa. Se suelen desarrollar una serie de talleres donde los expertos de los clientes consideran cules son las caractersticas 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 interactuarn con el sistema en una Definicin del rea de Negocios, gracias a ello se involucra al cliente y a gente clave de la organizacin en una etapa muy temprana.

Page | 3

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Iteracin del modelo funcional: se definen las caractersticas identificadas anteriormente de forma ms especfica. Tambin se lleva a cabo el cdigo, adems se construyen los prototipos y se mejoran los modelos de anlisis. Los prototipos se irn 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 cdigo del prototipo y los modelos de anlisis. Existen adems 4 productos que son creados en esta fase: Funciones priorizadas, Documentos de revisin del prototipado funcional, Requerimientos funcionales y Anlisis de riesgo de desarrollo. Iteracin del diseo y construccin: 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 mnimo acordado inicialmente. Tanto el diseo como la construccin son iterativos, adems el diseo y los prototipos funcionales son revisados por usuarios. Despliegue: el sistema entra en fase de produccin. Se entrega a los usuarios para que puedan hacer un uso adecuado del sistema, para ello se pone el mismo a su disposicin. Tambin son creados otros productos en esta fase, como son el Manual de usuario y el Reporte de revisin del sistema. Esta fase podra llegar a iterarse si fuese necesario. En cualquier caso, pueden darse 4 posibilidades 1. 2. 3. Si el sistema satisface todos los requerimientos, se puede dar por finalizado el desarrollo. Si queda un nmero elevado de requerimientos sin resolver, se puede comenzar el proceso nuevamente desde el principio. Si algn requerimiento no crtico no ha sido atendido, es posible realizar un proceso para incluirlo, empezando por la fase de la iteracin del modelo funcional, y desde esa fase se desarrolla todo el proceso hasta el final. Si algunas cuestiones tcnicas no pudieron resolverse debido a plazos que no se pudieron atender, se puede iterar desde la fase de diseo y construccin en adelante.

4.

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 metodologa Dynamic Systems Development Method. El mantenimiento puede basarse en un proceso iterativo e incremental. El proyecto adems, 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 Valoracin de beneficios, donde se detallarn los beneficios obtenidos por la implementacin de la solucin.

Page | 4

Grado en Ingeniera Multimedia Anlisis y Especificacin 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 metodologa DSDM. Gracias a esto se conseguir que todos los miembros del equipo estn 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 participacin 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 ms importantes en cuanto al proyecto se refiere, sin tener que realizar tediosas peticiones a la gerencia. Adems 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 nmero elevado si atendemos al nmero de roles del resto de metodologas giles. Los ms importantes son: 1. Programadores y programadores Senior: Son los nicos roles de desarrollo. El programador Senior es el lder dentro del equipo. Entre ambos roles cubren todos los roles del desarrollo, incluyendo analistas, diseadores, programadores y testeadores. 2. Coordinador tcnico: es el encargado de definir la arquitectura del sistema, adems, es el responsable de que el proyecto tenga una calidad tcnica adecuada. Tambin es el encargado del control tcnico y de la configuracin del sistema. 3. Usuario embajador: es el encargado de proporcionar conocimientos sobre la comunidad de usuarios y se encarga de retroalimentarlos con informacin 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 percepcin y el punto de vista ms exacto sobre los objetivos del sistema. Permite que los requerimientos ms 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 Ingeniera Multimedia Anlisis y Especificacin 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 organizacin con autoridad y responsabilidad financiera. 6. Facilitador: se encarga de administrar el progreso del desarrollo, y de facilitar la comunicacin 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.

Comparacin con otros mtodos de desarrollo


Aunque hay diversas metodologas parecidas a DSDM, hay algunas que se aproximan ms que otras. Por ejemplo guarda similitud con eXtreme Programming (XP) por tratarse tambin de una metodologa con un enfoque iterativo. Pero en cuanto a similitudes, quiz el ms similar a SDSM es el Proceso Unificado de Rational (RUP), ya que ambos son formas muy dinmicas de desarrollar sistemas de informacin, adems de compartir el enfoque iterativo. Existen ms metodologas que guardan similitudes con SDSM pero esta metodologa presenta una serie de caractersticas que la diferencian del resto: Proporciona un marco de trabajo independiente. Permite a los usuarios completar las etapas especficas del proceso con las tcnicas y ayudas software que crean oportunas. En esta metodologa las variables en el desarrollo del producto no son tiempo y recursos, sino los requisitos. Aunque otras metodologas tambin especifican que el compromiso con el proyecto y la metodologa elegida debe ser fuerte, en DSDM se considera un punto vital para asegurar un resultado satisfactorio del proyecto.

Herramientas de aplicacin
DSDM ha sido diseado de tal forma que no requiere de un software especfico 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 gestin de proyectos giles. Est diseado para brindar apoyo en metodologas giles como DSDM. La versin actual permite ir estableciendo los requerimientos del proceso de desarrollo, as como gestionar las tareas, errores e incidencias.

Page | 6

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Adems, 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 ms importantes, etc

Page | 7

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Crystal Clear
Est metodologa fue creada por Alistair Cockburn. La metodologa Crystal, ms que una metodologa en s, es considerada un conjunto de metodologas que se centran en la eficiencia y habitabilidad del proyecto. Se podra decir que este conjunto tienen algo en comn, algo llamado cdigo gentico que trata de los puntos claves que han de seguir. Las metodologas de las que se compone Crystal se clasifican segn el tamao del equipo y la complejidad del proyecto, asignndole a cada metodologa un color. Por ejemplo, para equipos de 8 personas o menos tendremos Clear, es decir, la metodologa Crystal Clear, para mayor tamao de equipo tendremos Yellow, Orange... De las metodologas Crystal, la ms 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 ms importante es la comunicacin del equipo, facilitando la misma con la entrega frecuente de cdigo confiable y funcionando, y permitiendo, gracias a ello, evitar distracciones. Esta metodologa est dirigida a equipos de menos de 6 u 8 personas para el desarrollo de sistemas no crticos.

Aplicacin
Como ya se ha dicho, Crystal Clear se aplica en grupos de 6 a 8 personas que trabajen el mismo sitio con uno o ms usuarios expertos disponibles. Este tipo de metodologa te permite moldear las tcnicas utilizadas para llevar a cabo ciertos proyectos que no se ajustan demasiado a la metodologa.

Propiedades
Crystal Clear cuenta con las siguientes propiedades, de las cuales, las tres primeras son imprescindibles: Entrega frecuente: se van realizando pequeas entregas a los clientes, de forma que van visualizando los cambios y viendo si se est obteniendo lo que realmente desea. Comunicacin osmtica: todos los desarrolladores se encuentran en un mismo cuarto, y en ocasiones se dispone de un experto diseador al que realizar cuestiones sobre el sistema. Mejora reexiva: 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 Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Seguridad personal: cuando hay algn 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. Fcil acceso a usuarios expertos: en esta metodologa se tiene alguna comunicacin con desarrolladores expertos a los que consultar.

Ventajas
Siguiendo las propiedades y tcnicas 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 mltiples proyectos que dichas propiedades y tcnicas contribuyen a ello. A diferencia de las metodologas tradicionales, Crystal Clear es flexible en cuanto a qu y cmo debe realizar el equipo un determinado proyecto. De hecho, Crystal Clear fue desarrollado especficamente para ser usado por el mayor nmero de equipos de proyecto posible teniendo que aprender el menor nmero de nuevas tcnicas posibles.

Desventajas
Crystal Clear intenta ser aplicable en tantos casos como sea posible. Esto evita que sea la mejor metodologa en un caso especfico. Crytal Clear es relativamente nuevo, lo que provoca que no tenga demasiada documentacin y experiencia real. Sin embargo, los principios de Crystal Clear estn basados en experiencias reales sobre proyectos reales.

Tcnicas
Con Crystal Clear se favorecen las siguientes tcnicas: Entrevistas de proyectos: se entrevista a los responsables proyecto para tener distintas visiones sobre el mismo. Reuniones de reflexin: 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 metodologa XP, se plantean unas tarjetas, cada una con una historia de usuario, sobre las que los desarrolladores habrn de plantear el tiempo de desarrollo y el esfuerzo que conlleva cada una. Una vez se haya estimado, el cliente ordena las tarjetas segn la prioridad que le d y teniendo en cuenta el valor de negocio que aporta cada una.

Page | 9

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Estimacin Delphi: se renen los responsables expertos para determinar el tamao del sistema, su tiempo de ejecucin y la fecha de entrega de cada una de las entregas que se irn realizando. Encuentros a pie: se trata de una breve reunin en la que identificar los posibles problemas. Grficos de quemado: se trata de grficas 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 algn retraso o problema, se podr detectar antes de que sea demasiado tarde. Programacin lado a lado: cada desarrollador se centra en su trabajo, pero siempre echando un ojo al compaero de al lado como posible apoyo.

Roles y Artefactos
Patrocinador: el patrocinador dice qu proyecto se ha de realizar, adems de proporcionar los recursos necesarios para el mismo. Realiza la declaracin de la misin con prioridades Comerciales (se describe el propsito 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 informacin 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. Diseador Principal: disea la arquitectura del sistema. El diseador principal tiene que ser de nivel 3, es decir, es capaz de realizar la mayor parte del diseo del proyecyo y de dirigir al equipo cuando sea necesario. En Metodologas giles se denen tres niveles de experiencia: o Nivel 1: es capaz de seguir los procedimientos. o Nivel 2: es capaz de apartarse de los procedimientos especcos y encontrar otros distintos. o Nivel 3: es capaz de manejar con uidez, mezclar e inventar procedimientos. El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programador ms experto. Diseador Programador: junto con el diseador principal, crea los borradores de pantallas, el modelo comn de dominio (esquema o diagrama en el que se muestra las entidades principales del sistema), las notas y diagramas de diseo, el cdigo fuente, el cdigo de migracin, las pruebas y el sistema empaquetado. En Crystal Clear no hay programadores, sino diseadores-programadores, ya que todo programa se basa en diseo y programa.

Page | 10

Grado en Ingeniera Multimedia Anlisis y Especificacin 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 polticas 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 iteracin y la agenda de visualizacin. Se encarga de manejar el proyecto. Verificador: se encarga de la realizacin 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 reexin.

Herramientas de aplicacin
Crystal Clear puede adaptarse a la hora de utilizar una herramienta para su implementacin, por ello puede utilizar cualquier herramienta para la aplicacin de metodologas giles. Crystal Clear no tiene una herramienta para su implementacin en concreto debido a que s encuentra en una fase temprana de su desarrollo.

Page | 11

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Proceso Unificado gil (AUP)


El Proceso Unificado gil (Agile Unified Process en ingls) o AUP, ideado por Scott Ambler, es una simplificacin del Proceso Unificado de Rational,que explica de una forma fcil y sencilla una manera de desarrollar software utilizando metodologas giles, como Extreme Programming, Test Driven Development o Agile Model Driven Development, fusionadas con conceptos ms tradicionales, es decir, RUP. Al ser una simplificacin del RUP, conserva algunas de sus caractersticas, 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 mtodo gil porque incluye de forma exacta algunas de las metodologas que se aplican en tcnicas giles como XP. Desde un punto de vista tradicional, el AUP puede verse ms simple que las versiones ms clsicas del proceso unificado, mientras que desde el punto de vista gil, puede entenderse como una versin ms pesada que las metodologas giles. Este puede ser un punto a favor a la hora de la empresa decidir que metodologa de desarrollo utilizar, por la incertidumbre que puede producir el elegir una metodologa a la que el proyecto no se adapte completamente.

Caractersticas
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 metodologas giles: Simplicidad, gracias a que reduce el nmero de disciplinas que tiene RUP. El nmero de disciplinas con las que cuenta AUP son siete: Modelado, Implementacin, Prueba, Despliegue, Gestin de Configuracin, Gestin de Proyectos y Ambiente, donde las cuatro primeras son de implementacin, 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, Anlisis y Diseo). Ajuste a los valores giles, como por ejemplo la aceptacin de cambios en los requisitos sobre la marcha, la entrega peridica y frecuente de software funcional, trabajar juntos el equipo de desarrollo con el cliente, etc. Siempre amoldndose a los principios de la Alianza gil.

Se centra en las actividades que ms valor tienen dentro del proyecto. AUP permite que las tareas sean priorizadas en funcin del valor que puedan tener, y en las que mayor atencin en el desarrollo requieren.
Page | 12

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Es adaptable al proyecto. Esto quiere decir que AUP puede amoldarse a las caractersticas 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 ms de adaptacin de esta metodologa al proyecto y a la empresa, por ejemplo si una empresa acostumbra a utilizar un software determinado para la gestin del proyecto, tomar AUP como metodologa 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 metodologas giles y metodologas tradicionales, es decir, que adoptan las caractersticas de la Alianza gil, pero que a su vez incluye de forma explcita 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 metodologa que cumpla estas caractersticas, y con un perfil de trabajadores abierto y capaz de adaptarse a la parte ms gil, o viceversa, que pueda adaptarse a la parte mas tradicional del AUP, como una desventaja si esta empresa ya tiene una metodologa asentada, sus trabajadores podran considerarla demasiado pesada, o si estn acostumbrados al proceso unificado, encontrar AUP demasiado ligero.

Fases
El ciclo de vida de AUP, de igual manera que su versin original, est compuesto por cuatro fases, Inicio, Elaboracin, Construccin y Transicin. A continuacin 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 definicin de qu va a componer el sistema, cmo va a desarrollarse y qu va a suponer, todo esto siendo de comn 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. Tambin se establece las herramientas con las que trabajar el equipo. Estimar costes y tiempos de desarrollo, donde estas estimaciones sern utilizadas para las primeras iteraciones de la fase de Elaboracin, y adems sern detalladas con ms acierto conforme avance el desarrollo del proyecto.

Page | 13

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Determinar riesgos, ya que la gestin 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 realizacin 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 trminos econmicos, los costes de desarrollo sean viables para la empresa, para determinar una posible cancelacin 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 sern necesarias para el desarrollo y que van a tener que adquirir (hardware y software). Fase de Elaboracin 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 ms 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 cdigo de calidad y que funcione, y adems que cumpla los requisitos y satisfaga los casos de uso. El equipo de desarrollo tambin 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 construccin del mismo, consiguiendo las herramientas necesarias, software, hardware. Por otra parte, no todos los requisitos estn determinados al llegar a esta fase, sino que slo han sido especificados en parte para poder ver con claridad los riesgos en la arquitectura. Estos riesgos son priorizados y son definidos con ms determinacin 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 demostracin con el prototipo que se ha creado. Si se llega al hito correctamente se pasa a la fase de Construccin. Fase de Construccin El objetivo principal de la fase es la de desarrollar el sistema hasta el punto de estar listo para las pruebas previas a la produccin final. Tanto en las fases de Inicio como de Elaboracin se han definido todos los requisitos y la arquitectura del software. En la Construccin se priorizan los requerimientos, se crea un modelo y a partir de ah, se empieza a escribir y probar el cdigo del software. Para ciertos proyectos, puede resultar necesario y positivo el lanzar versiones iniciales del sistema, ya sea de forma

Page | 14

Grado en Ingeniera Multimedia Anlisis y Especificacin 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 Construccin finaliza cuando se llega al hito de Initial Operational Capability, y el software construido es estable, tiene aceptacin de los riesgos, las estimaciones de coste y temporales son aceptables, y la empresa est lista para la produccin del sistema. Si se llega correctamente a este hito, el proyecto se mueve a la fase de Transicin. Fase de Transicin Por ltimo, la fase de Transicin se centra en llevar el sistema a su produccin. Las funciones ms 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 duracin y volumen de trabajo de esta fase es difcil de estimar y vara 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 produccin.

Disciplinas
Modelado: Entender el proyecto y su viabilidad en la empresa, buscar como solucionar el problema. Segn la fase en la que se encuentre el proyecto, esta disciplina tendr ms o menos volumen de trabajo, por ejemplo, en la fase de Inicio, se buscarn explcitamente los casos de uso y los requerimientos, los cuales sern priorizado, mientras que en la fase de Elaboracin se identificarn los riesgos tcnicos del proyecto. Se producen modelos del sistema, que sern utilizados en la disciplina de Implementacin. Implementacin: Convertir los modelos creados a cdigo ejecutable, adems de llevar a cabo pruebas generales. Aqu se adoptan ciertas metodologas giles, como TDD o programacin en parejas. Prueba: Llevar a cabo una evaluacin 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 requera y como se ha diseado. Despliegue: Se planea la produccin 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 Construccin. La fase de transicin es la que ms trabajo en esta disciplina tiene ya que se finalizan el paquete del software que va a distribuirse y su documentacin, se anuncia la distribucin, y dems tareas que llegan al usuario final.

Page | 15

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Gestin de Configuracin: Gestionar el acceso a herramientas del proyecto, hacer un seguimiento de las versiones en el tiempo y los posibles cambios que puedan hacerse. Gestin 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 finalizacin 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 Elaboracin, aceptando que la visin del proyecto y su arquitectura estn 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 Construccin, se acepta que el sistema es estable, teniendo el software suficiente documentacin y el software preparado para la entrega. Product Release (PR): Al acabar la fase de Transicin, se acepta que las operaciones para poner el sistema en produccin son correctas, los costes y tiempos estn bien estimados, los stakeholders de la empresa estn satisfechos con el sistema.

Artefactos
AUP tiene flexibilidad en cuanto al nmero y tipos de artefactos son necesarios para cada fase y disciplina, pero an as existen un mnimo de estos que deben ser creados para cumplir con la parte ms tradicional de esta metodologa. Los artefactos, en orden de prioridad que son necesarios son:

Page | 16

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Sistema Cdigo fuente Conjunto de pruebas Scripts de instalacin del sistema en el entorno del usuario Documentacin del sistema, para el mantenimiento del sistema Notas de las versiones lanzadas Modelo de requisitos Modelo de diseo Igualmente, pueden crearse los artefactos que la empresa necesite para la gestin del proyecto.

Roles
Los roles que toma cada una de las personas de una empresa que sigue la metodologa AUP. Los roles pueden ser asumidos por una o varias personas, una misma persona puede asumir ms de un rol. Algunos de los roles: Administrador del proyecto Desarrollador Modelador gil Administrador de bases de datos gil Administrador de la configuracin Implementador Examinador Administrador de pruebas, equipo de pruebas

Herramientas de aplicacin
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 ms se adapten el proceso.

Page | 17

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Comparativa de metodologas
Caractersticas
AUP Adaptar el proceso de desarrollo Alto nivel de abstraccin Fomento del aprendizaje de experiencias Centrarse en la arquitectura Interaccin continua con cliente Cdigo estndar Colaboracin entre equipo Demostrar resultados Iterativamente e incrementalmente Diseo simple Enfoque continuo en la calidad Permanecer gil y esperar los cambios Dirigido por Casos de Uso Para pequeos grupos de trabajo Para grandes grupos de trabajo Para proyectos complejos Para proyectos simples S NO NO S S S S S NO S S S NO S S NO CC S S NO NO S NO S S S NO NO S S NO NO S DSDM S S NO NO S NO S S NO S S NO S NO NO S

Roles
AUP Analista de Calidad Analista del Producto Arquitecto Desarrollador NO NO S S CC NO S S S DSDM S NO S S

Page | 18

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Involucrados Lder de Proyecto Probador Otro Roles

S S S S

S S S S

S S S S

Artefactos

AUP Caso del Negocio Documento de Arquitectura del Software Especificaciones Suplementarias Modelo de Casos de Uso Modelo de Diseo Modelo de Implementacin Plan de Gestin de Riesgos Plan de Implantacin Plan de Iteracin Plan de Pruebas Planificacin del Proyecto Visin del Sistema S* S* S S S S S* S* S* S* S S

CC S S S S S S NO S S S S S

DSDM S S S S NO S S NO NO S S NO

*No es obligatorio

Page | 19

Grado en Ingeniera Multimedia Anlisis y Especificacin de Contenidos

Segundo Curso Segundo Cuatrimestre

Bibliografa 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

You might also like