Metodologias AUP

Grado en Ingeniera Multimedia
Anlisis y Especificacin de Contenidos
Metodologas giles
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
Segundo Curso
Segundo Cuatrimestre
AESM

Segundo Curso
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
AUP Proceso Unificado gil --------------------------------------------------------------------------Pgina 12
Introduccin
Caractersticas
Fases
Disciplinas
Hitos
Artefactos
Tablas comparativas -------------------------------------------------------------------------------------Pgina 18
Caractersticas
Roles
Artefactos
Bibliografa y referencias -------------------------------------------------------------------------------Pgina 20
Page | 1

Segundo Curso
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.
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 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.
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

Segundo Curso
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

Segundo Curso
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.
4.
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.
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

Segundo Curso
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

Segundo Curso
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.
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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.
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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

Segundo Curso
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
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

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

Segundo Curso
Involucrados
Lder de Proyecto
Probador
Otro Roles
AUP
CC
DSDM
Caso del Negocio
S*
Documento de Arquitectura del Software
S*
Especificaciones Suplementarias
Modelo de Casos de Uso
Modelo de Diseo
NO
Modelo de Implementacin
Plan de Gestin de Riesgos
S*
NO
Plan de Implantacin
S*
NO
Plan de Iteracin
S*
NO
Plan de Pruebas
S*
Planificacin del Proyecto
Visin del Sistema
NO
Artefactos
*No es obligatorio
Page | 19

Segundo Curso
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

Metodologias AUP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologias AUP

Cargado por

Copyright:

Formatos disponibles

Grado en Ingeniera Multimedia

Anlisis y Especificacin de Contenidos

Componentes del grupo (mircoles de 17:00 a 19:00):

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

DSDM - Dynamic System Development Method

El usuario debe estar involucrado en el proyecto en todo momento.

Grado en Ingeniera Multimedia

Estudio de la factibilidad: en primer lugar se evala el uso de DSDM u otra

Estudio del negocio: Se analizan las diferentes caractersticas de la organizacin

Grado en Ingeniera Multimedia

Iteracin del modelo funcional: se definen las caractersticas identificadas

Iteracin del diseo y construccin: se construye la mayor parte del sistema. El

Despliegue: el sistema entra en fase de produccin. Se entrega a los usuarios

Si el sistema satisface todos los requerimientos, se puede dar por finalizado

Fase 3: En esta fase el equipo se cerciora de que el sistema opera de forma

Grado en Ingeniera Multimedia

Factores que influyen en el xito del DSDM

Grado en Ingeniera Multimedia

Comparacin con otros mtodos de desarrollo

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

Estimacin Delphi: se renen los responsables expertos para determinar el

Grado en Ingeniera Multimedia

Experto en Negocios: junto con el usuario experto produce la lista de actores

Grado en Ingeniera Multimedia

Proceso Unificado gil (AUP)

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

Determinar riesgos, ya que la gestin de los riesgos es de vital importancia en un

Grado en Ingeniera Multimedia

interna o externa a la empresa, con el fin de conseguir opiniones y feedback de los

Grado en Ingeniera Multimedia

Gestin de Configuracin: Gestionar el acceso a herramientas del proyecto, hacer

Grado en Ingeniera Multimedia

Grado en Ingeniera Multimedia

Adaptar el proceso de desarrollo

Alto nivel de abstraccin

Fomento del aprendizaje de experiencias

Interaccin continua con cliente

Colaboracin entre equipo

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

Analista del Producto

Grado en Ingeniera Multimedia

Caso del Negocio

Documento de Arquitectura del Software

Modelo de Casos de Uso

Plan de Gestin de Riesgos

Planificacin del Proyecto

Visin del Sistema

Grado en Ingeniera Multimedia

Proceso Unificado gil AUP

También podría gustarte