METODOLOGIA AUP

PROCESO UNIFICADO AGIL

DEFINICION.
El Proceso Unificado gil (AUP, del ingls Agile Unified Process) es una versin
simplificada del Proceso Unificado de Rational (Rational Unified Process, RUP)
desarrollada por Scott Ambler, la cual describe una aproximacin al desarrollo de
aplicaciones que combina conceptos propios del proceso unificado tradicional con
tcnicas giles, con el objetivo de mejorar la productividad.
En general, el Proceso Unificado gil supone un enfoque intermedio entre XP
(eXtreme Programming) y el Proceso Unificado de Rational, y tiene la ventaja de ser un
proceso gil que incluye explcitamente actividades y artefactos a los que la mayora de
desarrolladores ya estn, de alguna manera, acostumbrados. Muchas organizaciones
recelan de XP porque les parece demasiado ligero: XP no especfica cmo crear
algunos de los artefactos que los gestores necesitan, lo cual es en cierta manera una
contrariedad porque XP se considera, en general, un buen proceso gil.
En el otro lado est el Proceso Unificado de Rational, cuya gestin resulta realmente
sencilla pero que los desarrolladores suelen temer debido al gran nmero de artefactos
que requiere. Esto tambin resulta desafortunado porque el Proceso Unificado tiene
mucho que ofrecer, y puede ser adaptado y recortado hasta conseguir algo ms o
menos prctico (que es exactamente lo que IBM Rational recomienda).
El Proceso Unificado gil se encuentra entre ambos, adoptando algunas de las tcnicas
giles de XP y otros procesos giles, pero reteniendo parte de la formalidad del Proceso
Unificado de Rational.

FASES DEL AUP

El Proceso Unificado gil consta de cuatro fases que el proyecto atraviesa de forma
secuencial. Dichas fases son, al igual que en el Proceso Unificado de Rational:
1. Iniciacin. El objetivo de esta fase es identificar el alcance inicial del proyecto,
una arquitectura potencial para el sistema y obtener, si procede, financiacin para
el proyecto y la aceptacin por parte de los promotores del sistema.
2. Elaboracin. Mediante esta fase se pretende identificar y validar la arquitectura
del sistema.
3. Construccin. El objetivo de esta fase consiste en construir software desde un
punto de vista incremental basado en las prioridades de los participantes.
4. Transicin. En esta fase se vlida y despliega el sistema en el entorno de
produccin.
La siguiente figura muestra un esquema de estas cuatro fases incluyendo, adems, los
objetivos y tareas fundamentales de cada una, as como los diferentes hitos por los
que pasa el proyecto (a saber, LCO, LCA, IOC y PR):

A lo largo de las cuatro fases, se desarrollan actividades relativas a siete disciplinas de

manera iterativa:
1.

Modelado. Su objeto es entender la lgica de negocio de la aplicacin, el

dominio del problema del proyecto e identificar una solucin viable para el dominio
del problema.

2.

Implementacin. Transformar los modelos en cdigo ejecutable y realizar

pruebas bsicas, en particular pruebas unitarias.

3.

Pruebas. Realizar una evaluacin de los objetivos para asegurar la calidad. Esto
incluye encontrar defectos, validar que el sistema funciona como fue diseado y
verificar que los requisitos se cumplen.

4.

Despliegue. Planear la entrega del sistema y ejecutar el plan para hacer que el
sistema quede disponible para los usuarios finales.

5.

Gestin de la configuracin. Gestionar el acceso a los artefactos del proyecto.

Esto incluye, adems de la traza de versiones de los artefactos, el control de
cambios y la gestin de los mismos.

6.

Gestin del proyecto. Dirige las actividades que tienen lugar dentro del
proyecto, incluyendo gestin de riesgos, direccin del personal y coordinacin.

7.

Entorno. Apoyar el resto del esfuerzo asegurando que los procesos, mtodos y
herramientas estn disponibles para el equipo cuando los necesitan.

MODELOS Y DOCUMENTACIN
Un documento es cualquier artefacto externo al cdigo fuente cuyo propsito sea
transmitir informacin de una manera persistente. Esto plantea algunas diferencias con
el concepto de modelo, que se define como una abstraccin que describe uno o ms
aspectos de un problema o una solucin potencial a un problema.

El siguiente diagrama describe cmo se relacionan estos conceptos entre s:

En general, algunos modelos terminarn siendo documentos o partes de documentos, y

otros podrn simplemente ser descartados tras haber cumplido su funcin.
El ciclo de vida de un modelo gil vendra a ser:

Si no todos los modelos giles se conservan como parte del sistema, cundo se
puede considerar un modelo como permanente? Se debera considerar cuando cumpla
los siguientes requisitos:

Hay una razn clara y valiosa para hacerlo permanente.

Hay alguien para quien el modelo es importante.

Los promotores lo requieren.

Respecto a la documentacin, considerada parte intrnseca y necesaria del sistema por

la metodologa, se propone un enfoque gil y centrado en mantenerla lo ms ligera
posible, en parte debido al coste aadido que implica mantenerla actualizada.
Para

el

Proceso

Unificado

gil,

hay

algunas razones

vlidas para

crear

documentacin, resumidas en la siguiente lista:

Los promotores del proyecto lo requieren.

Para definir un modelo de contrato.

Como ayuda a la comunicacin con un grupo externo. Sin embargo, la

documentacin no debera ser el medio de comunicacin principal.

Como soporte a la memoria organizacional. No slo se necesita desarrollar el

software, sino que es necesario contar con documentacin apropiada para su uso,
soporte tcnico y mantenimiento a lo largo del tiempo.

Para labores de auditora.

Para ayudar a pensar sobre algo. El simple acto de escribir ideas en un papel
puede contribuir a consolidarlas y a descubrir problemas en ellas.

En relacin con la elaboracin de documentacin, en la metodologa se exponen

algunos puntos crticos y recomendaciones que se considera conveniente reproducir:
Lo fundamental es la comunicacin, no la documentacin.

La documentacin debe escribirse si es la mejor manera de alcanzar los

objetivos relevantes, aunque con frecuencia hay mejores maneras de alcanzar
estos objetivos que escribir documentacin esttica.

Documente elementos estables, no especulaciones.

Tome un enfoque evolutivo sobre el desarrollo de documentacin.

Prefiera artefactos ejecutables como pruebas de aceptacin y de desarrollo

sobre

Debe entender el coste total de propiedad (Total Cost of Ownership, TCO) para
cada documento.

La documentacin bien escrita es til como soporte a la memoria organizacional,

pero es una pobre manera de comunicar en un proyecto.

La documentacin debera ser concisa: resmenes y hojas de ruta son

generalmente preferibles sobre otro tipo de documentacin detallada.

Con un cdigo fuente de alta calidad y un conjunto de pruebas para respaldarlo,

no necesitar demasiada documentacin.

Viaje tan ligero de equipaje como pueda.

Cada artefacto que crea y que decide mantener necesitar ser mantenido a lo largo
del tiempo. Cada vez que resuelve mantener un modelo sacrifica agilidad a cambio de
conservar esa informacin disponible para su equipo de una manera abstracta. No
subestime la importancia de este sacrificio.

La documentacin debera ser slo tan buena como sea necesario.

La documentacin comprensiva no asegura el xito del proyecto. De

hecho, incrementa las probabilidades de fracaso.

Los modelos no son necesariamente documentos, y los documentos no son

necesariamente modelos.

La documentacin forma tanta parte del sistema como el cdigo fuente.

El objetivo principal de su equipo es desarrollar software, el objetivo secundario es

facilitar su siguiente esfuerzo.

El beneficio de tener documentacin debe ser mayor que el coste de crearla y

mantenerla.

Los desarrolladores rara vez confan en la documentacin, particularmente en la

documentacin detallada, porque generalmente no est actualizada con
respecto al cdigo.

Cada sistema tiene sus propias necesidades de documentacin.

Pregntese si necesita la documentacin, no si la quiere.

La inversin en documentacin del sistema es una decisin de negocio, no una

decisin tcnica.

Cree documentacin slo cuando la necesite en el punto adecuado del ciclo de

vida.

Actualice la documentacin slo cuando duela. Debera actualizar un modelo

slo cuando lo necesite. Es decir, cuando el hecho de no contar con un modelo
actualizado sea peor que el esfuerzo de actualizarlo.

Entregables
Respecto a los entregables, el Proceso Unificado gil distingue entre:

Entregables. Que deben ser producidos como parte permanente del sistema.

Otros productos de trabajo del proyecto que pueden descartarse porque no se

desea mantenerlos a lo largo de la vida del sistema.

Productos de trabajo de la organizacin, que sern mantenidos por el

departamento de desarrollo y compartidos con el resto de proyectos.
Asimismo, la metodologa propone las siguientes recomendaciones en relacin a
la documentacin entregable:

Mantenga los productos de trabajos tan simples y concisos como sea posible.

Necesita mucha menos documentacin de la que cree.

Trabaje cerca de la gente que va a crear un producto de trabajo de manera que

slo produzcan lo que necesiten.

Los documentos giles son slo tan buenos como requiera la tarea en cuestin.

Producir un documento es la peor manera de comunicar informacin. Varias

personas alrededor de una pizarra blanca es la mejor.

Use herramientas simples como pizarras blancas, papel y wikis para modelar y
capturar documentacin.

Considere adoptar plantillas libres como base para crear sus propias plantillas.

La siguiente tabla describe, en orden de prioridad, los entregables mnimos para un

proyecto basado en el Proceso Unificado gil:
Entregable

Descripcin

Recomendaciones

Sistema

El
software,
hardware
documentacin que deben
desplegados
y
puestos
produccin.

y
ser
en

Cdigo
fuente

El cdigo del sistema.

Seguir convenciones de codificacin

comunes.

Conjunto de
pruebas de
regresin

Coleccin de casos de pruebas, y

el cdigo para ejecutarlos en el
orden apropiado. El conjunto de
pruebas de regresin debera
incluir pruebas de aceptacin,
pruebas unitarias, pruebas del
sistema

Automatizar
las
pruebas
y
ejecutarlas con tanta frecuencia
como sea posible, idealmente cada
vez que algo cambie.

Scripts
de
instalacin

Cdigo para instalar el sistema en

el entorno de produccin.

Es conveniente disponer de uno o

varios scripts para instalar y
desinstalar
el
sistema
en
produccin.

Documentaci
n
del
sistema

La documentacin entregada como

parte del sistema para ayudar a los
usuarios a trabajar con l y a los

El sistema no es slo el cdigo que

se escribe.

Mantener la documentacin
ligera como sea posible.

tan

desarrolladores
a mantenerlo.
Generalmente se compone del
manual
de
operaciones,
documentacin
de
apoyo,
manuales de usuario y descripcin
general del sistema.
Notas de la
versin

Resumen
de
los
puntos
importantes sobre la versin actual
del sistema.

Algunas notas en forma de lista son

suficientes en general.

Modelo
de
requisitos

Describe los requisitos que el

sistema
debera
contemplar.
Comprende una gran variedad de
productos de trabajo, incluyendo
potencialmente
pruebas
de
aceptacin,
posibles
automatismos, procesos y reglas
de negocio, modelo del dominio,
modelo
de
la
organizacin,
glosario,
requisitos
tcnicos,
modelo de casos de uso y modelo
de la interfaz de usuario.

El objetivo es entender y despus

construir lo que los clientes
necesitan, no escribir montones de
documentacin.
No es necesario conservar todos los
aspectos del modelo de requisitos,
slo las partes que ayuden a
entender el alcance del proyecto. En
concreto, puede ser interesante
mantener:
los
diagramas
de
procesos de negocio, el glosario, los
test de aceptacin y la descripcin
de algunos casos de uso.

Describe el diseo del sistema.

Comprende cierta variedad de
artefactos,
potencialmente
un
modelo de despliegue, un modelo
de objetos, un modelo de datos, un
modelo
de
amenazas
de
seguridad, el documento de
resumen o vista general del
sistema y un modelo de la interfaz
de usuario.

Es preciso mantener los modelos de

diseo tan simples como sea
posible, y descartar todos los
modelos que se pueda una vez se
haya obtenido valor de ellos.
El mejor lugar para documentar el
diseo son las pruebas unitarias y el
cdigo fuente.
Se debera conservar el documento
de resumen del sistema y el modelo
de datos para la documentacin
permanente.
Tambin
pueden
conservarse algunos diagramas
importantes, como diagramas de
secuencia o de mquina de estados.

Modelo
diseo

de

Filosofas
AUP se basa en las siguientes filosofas:
1. Los empleados saben lo que estn haciendo. La gente no va a leer
documentacin del proceso detallada, pero quieren algo de orientacin a alto
nivel y/o formacin de vez en cuando. El producto AUP proporciona enlaces a
muchos de los detalles pero no fuerza a ellos.
2. Simplicidad. Todo est descrito de forma concisa.
3. Agilidad. AUP se ajusta a los valores y principios de desarrollo de software gil y
la Alianza gil
4. Foco en las actividades de alto valor. El foco est en las actividades que
realmente cuentan, no en todas las posibles cosas que pudieran pasar en un
proyecto.
5. Independencia de herramientas. Se puede usar cualquier conjunto de
herramientas. La recomendacin es que se usen las herramientas que mejor se
adapten al trabajo, que son con frecuencia herramientas simples.
6. Habr que adaptar AUP para cumplir con las necesidades propias.
INCREMENTO Y DESARROLLO DE AUP.
Los equipos de AUP suelen ofrecer versiones de desarrollo al final de cada iteracin en
preproduccin rea (s). Una versin de desarrollo de una aplicacin es algo que
podran ser liberados en la produccin si se ponen a travs de su pre-produccin de
garanta de calidad (QA), las pruebas y los procesos de despliegue.
La primera produccin de liberacin a menudo toma ms tiempo para entregar
versiones posteriores. La primera produccin de liberacin puede tomar doce meses
para entregar la segunda versin de nueve meses, y luego otras liberaciones se
entregan cada seis meses.
Una de las primeras se centra en cuestiones de despliegue, no slo permite evitar los
problemas, sino que tambin permite tomar ventaja de sus experiencias durante el
desarrollo. Por ejemplo, cuando despliegue un software en su rea deber tomar notas

de lo que funciona y lo que no, toma nota de que puede servir como la columna
vertebral de su instalacin de scripts.

PRINCIPIOS DE LA AUP.
La AUP es gil, porque est basada en los siguientes principios:
1. El personal sabe lo que est haciendo. La gente no va a leer detallado el proceso
de documentacin, pero algunos quieren una orientacin de alto nivel y / o
formacin de vez en cuando. La AUP producto proporciona enlaces a muchos de
los detalles, si usted est interesado, pero no obliga a aquellos que no lo deseen.
2. Simplicidad. Todo se describe concisamente utilizando un puado de pginas, no
miles de ellos.
3. Agilidad. gil ARRIBA El ajuste a los valores y principios de la Alianza gil.
4. Centrarse en actividades de alto valor. La atencin se centra en las actividades
que se ve que son esenciales para el de desarrollo, no todas las actividades que
suceden forman parte del proyecto.
5. Herramienta de la independencia. Usted puede usar cualquier conjunto de
herramientas que usted desea con el gil UP. Lo aconsejable es utilizar las
herramientas que son las ms adecuadas para el trabajo, que a menudo son las
herramientas simples o incluso herramientas de cdigo abierto.
6. Adaptacin de este producto para satisfacer sus propias necesidades. La AUP
producto es de fcil acomodo comn a travs de cualquier herramienta de
edicin de HTML. No se necesita comprar una herramienta especial, o tomar un
curso, para adaptar la AUP.

VENTAJAS Y DESVENTAJAS.
VENTAJAS:

El personal sabe lo que esta haciendo: no obliga a conocer detalles.

Simplicidad: apuntes concisos.
Agilidad: procesos simplificados del RUP
Centrarse en actividades de alto valor: esenciales para el desarrollo.
Herramientas independientes: a disposicin del usuario.
Fcil adaptacin de este producto: de fcil acomodo (HTML)

DESVENTAJAS.
El AUP es un producto muy pesado en relacin al RUP.
Como es un proceso simplificado, muchos desarrolladores eligen trabajar con
el RUP, por tener a disposicin ms detalles en el proceso.
CONCLUSIONES.
AUP se preocupa especialmente de la gestin de riesgos. Propone que aquellos
elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean
abordados en etapas tempranas del mismo.
El proceso AUP establece un Modelo ms simple que el que aparece en RUP por lo que
rene en una nica disciplina las disciplinas de Modelado de Negocio, Requisitos y
Anlisis y Diseo. El resto de disciplinas (Implementacin, Pruebas, Despliegue,
Gestin de Configuracin, Gestin y Entorno) coinciden con las restantes de RUP.