METODOLOGIAS AGILES

PROCESO UNIFICADO AGIL (AUP)

1.- INTRODUCCION.
Los procesos giles de desarrollo de software, conocidos anteriormente como metodologas
livianas, intentan evitar los tortuosos y burocrticos caminos de las metodologas tradicionales
enfocndose en la gente y los resultados.
Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el
desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo
gil! la mayora minimi"a riesgos desarrollando software en cortos lapsos de tiempo. El software
desarrollado en una unidad de tiempo es llamado una iteraci#n, la cual debe durar de una a cuatro
semanas. $ada iteraci#n del ciclo de vida incluye% planificaci#n, anlisis de requerimientos, dise&o,
codificaci#n, revisi#n y documentaci#n. 'na iteraci#n no debe agregar demasiada funcionalidad
para justificar el lan"amiento del producto al mercado, pero la meta es tener un demo (sin errores)
al final de cada iteraci#n. *l final de cada iteraci#n el equipo vuelve a evaluar las prioridades del
proyecto.
Los mtodos *giles enfati"an las comunicaciones cara a cara en ve" de la documentaci#n. La
mayora de los equipos *giles estn locali"ados en una simple oficina abierta, a veces llamadas
+plataformas de lan"amiento+ (bullpen en ingls). La oficina debe incluir revisores, dise&adores de
iteraci#n, escritores de documentaci#n y ayuda y directores de proyecto. Los mtodos giles
tambin enfati"an que el software funcional es la primera medida del progreso. $ombinado con la
preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y
tratados como +indisciplinados+ por la falta de documentaci#n tcnica.
Metodolog! "g#le!
Extreme Programming (XP)
Scrum
Agile Modeling Adaptive Software Development (ASD)
Crstal Clear
Dnamic Sstems Development Met!od (DSDM)
"eature Driven Development ("DD)
#ean Software Development (#SD)
Agile $nified Process (A$P)
Software Development %!t!ms
Agile Documentation
&C'(&X Process
Microsoft Solutions "ramewor) (MS")
Agile Data Met!od
Data*ase %efactoring
#eanCMM&
PROCESO UNIFICADO AGIL (AUP).-
El ,roceso 'nificado *gil de -cott *mbler o *gile 'nified ,rocess (*',) en ingls es una versi#n
simplificada del ,roceso 'nificado de .ational (.',). Este describe de una manera simple y fcil
de entender la forma de desarrollar aplicaciones de software de negocio usando tcnicas giles y
conceptos que a/n se mantienen vlidos en .',. El *', aplica tcnicas giles incluyendo
0esarrollo 0irigido por ,ruebas (test driven development 1 200), 3odelado *gil, 4esti#n de
$ambios *gil, y .efactori"aci#n de 5ase de 0atos para mejorar la productividad.
El proceso unificado ($nified Process o ',) es un marco de desarrollo software iterativo e
incremental. * menudo es considerado como un proceso altamente ceremonioso porque especifica
muchas actividades y artefactos involucrados en el desarrollo de un proyecto software. 0ado que
es un marco de procesos, puede ser adaptado y la ms conocida es .', (%ational $nified
Process) de 653.
*', se preocupa especialmente de la gesti#n de riesgos. ,ropone que aquellos elementos con
alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas
del mismo. ,ara ello, se crean y mantienen listas identificando los riesgos desde etapas inciales
del proyecto. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables
durante la base de elaboraci#n del producto, donde se demuestre la valide" de la arquitectura para
los requisitos clave del producto y que determinan los riesgos tcnicos.
El proceso *', establece un 3odelo ms simple que el que aparece en .', por lo que re/ne en
una /nica disciplina las disciplinas de 3odelado de 7egocio, .equisitos y *nlisis y 0ise&o. El
resto de disciplinas (6mplementaci#n, ,ruebas, 0espliegue, 4esti#n de $onfiguraci#n, 4esti#n y
Entorno) coinciden con las restantes de .',.
CICLO DE $IDA DEL PROCESO UNIFICADO AGIL (AUP).-
*l igual que en .',, en *', se establecen cuatro fases que transcurren de manera consecutiva y
que acaban con hitos claros alcan"ados%
6nception($oncepci#n)% El objetivo de esta fase es obtener una comprensi#n com/n cliente1
equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas
candidatas para el mismo.
Elaboraci#n% El objetivo es que el equipo de desarrollo profundice en la comprensi#n de los
requisitos del sistema y en validar la arquitectura.
$onstrucci#n% 0urante la fase de construcci#n el sistema es desarrollado y probado al
completo en el ambiente de desarrollo.
2ransici#n% el sistema se lleva a los entornos de preproducci#n donde se somete a pruebas
de validaci#n y aceptaci#n y finalmente se despliega en los sistemas de producci#n.
Las disciplinas se llevan a cabo de manera sistemtica, a la definici#n de las actividades que
reali"an los miembros del equipo de desarrollo a fin de desarrollar, validar, y entregar el software
de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son%
8. 3odelo. El objetivo de esta disciplina es entender el negocio de la organi"aci#n, el
problema de dominio que se abordan en el proyecto, y determinar una soluci#n viable para
resolver el problema de dominio.
9. *plicaci#n. El objetivo de esta disciplina es transformar su modelo (s) en c#digo ejecutable
y reali"ar un nivel bsico de las pruebas, en particular, la unidad de pruebas.
:. ,rueba. El objetivo de esta disciplina consiste en reali"ar una evaluaci#n objetiva para
garanti"ar la calidad. Esto incluye la b/squeda de defectos, validar que el sistema funciona
tal como est establecido, y verificando que se cumplan los requisitos.
;. 0espliegue. El objetivo de esta disciplina es la prestaci#n y ejecuci#n del sistema y que el
mismo este a disposici#n de los usuarios finales.
<. 4esti#n de configuraci#n. El objetivo de esta disciplina es la gesti#n de acceso a
herramientas de su proyecto. Esto incluye no s#lo el seguimiento de las versiones con el
tiempo, sino tambin el control y gesti#n del cambio para ellos.
=. 4esti#n de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a
cabo en el proyecto. Esto incluye la gesti#n de riesgos, la direcci#n de personas (la
asignaci#n de tareas, el seguimiento de los progresos, etc), coordinaci#n con el personal y
los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo
y dentro del presupuesto.
>. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuer"os por garanti"ar
que el proceso sea el adecuado, la orientaci#n (normas y directrices), y herramientas
(hardware, software, etc) estn disponibles para el equipo seg/n sea necesario.
INCREMENTO % DESARROLLO DE AUP.-
Los equipos de *', suelen ofrecer versiones de desarrollo al final de cada iteraci#n en pre1
producci#n rea (s). 'na versi#n de desarrollo de una aplicaci#n es algo que podran ser liberados
en la producci#n si se ponen a travs de su pre1producci#n de garanta de calidad (?*), las
pruebas y los procesos de despliegue. La primera producci#n de liberaci#n a menudo toma ms
tiempo para entregar versiones posteriores. La primera producci#n de liberaci#n puede tomar doce
meses para entregar la segunda versi#n de nueve meses, y luego otras liberaciones se entregan
cada seis meses. 'na de las primeras se centra en cuestiones de despliegue, no s#lo permite
evitar los problemas, sino que tambin permite tomar ventaja de sus experiencias durante el
desarrollo. ,or 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 instalaci#n de
scripts.
PRINCIPIOS DE LA AUP.-
La *', es gil, porque est basada en los siguientes principios%
8. El personal sabe lo que est haciendo. La gente no va a leer detallado el proceso de
documentaci#n, pero algunos quieren una orientaci#n de alto nivel y @ o formaci#n de ve"
en cuando. La *', producto proporciona enlaces a muchos de los detalles, si usted est
interesado, pero no obliga a aquellos que no lo deseen.
9. -implicidad. 2odo se describe concisamente utili"ando un pu&ado de pginas, no miles de
ellos.
:. *gilidad. Agil *..65* El ajuste a los valores y principios de la *lian"a Agil.
;. $entrarse en actividades de alto valor. La atenci#n 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.
<. Berramienta de la independencia. 'sted puede usar cualquier conjunto de herramientas
que usted desea con el gil ',. Lo aconsejable es utili"ar las herramientas que son las
ms adecuadas para el trabajo, que a menudo son las herramientas simples o incluso
herramientas de c#digo abierto.
=. *daptaci#n de este producto para satisfacer sus propias necesidades. La *', producto es
de fcil acomodo com/n a travs de cualquier herramienta de edici#n de B23L. 7o se
necesita comprar una herramienta especial, o tomar un curso, para adaptar la *',.
CONCLUSIONES.-
-i deseamos un mtodo gil entre C, y .', tradicionales, que incluya explcitamente las
actividades y las herramientas que estn acostumbrados, entonces la ms aconsejable es la *',.
C, no muestra explcitamente c#mo crear algunos de las herramientas que la administraci#n
quiere ver. En el otro extremo del espectro est .',, que es el gestor ms utili"ado de los
desarrolladores, pero presenta una gran cantidad de herramientas. La *', en comparaci#n entre
los dos, es la adopci#n de muchas de las tcnicas giles de C, y otros procesos giles que
mantiene de las .',.
El usuario final es el mejor jue" que determina se la *', es el mtodo gil ms adecuado.
En relaci#n al C,, el *', resulta ser un proceso muy pesado y en relaci#n al .', resulta ser un
proceso muy simplificado, entonces, los desarrolladores debern decidir en% si desea buscar una
forma de trabajo ligero esta C, y si desea trabajar con un proceso ms detallado esta .',.