Metodologia Aup

METODOLOGIA AUP

METODOLOGIAS AGILES

“PROCESO UNIFICADO AGIL (AUP)”

1 INTRODUCCION

Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza 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. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Metodologías ágiles

•Extreme Programming (XP)

•Scrum

•Agile Modeling Adaptive Software Development (ASD)

•Crystal Clear

PROCESO UNIFICADO AGIL (AUP).-

El Proceso Unificado Agil de Scott Ambler o Agile UnifiedProcess (AUP) en inglés es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test drivendevelopment - TDD), Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad.

El proceso unificado (UnifiedProcesso UP) es un marco de desarrollo software iterativo e incremental. A menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y artefactos involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede ser adaptado y la más conocida es RUP (RationalUnifiedProcess) de IBM.

AUP se preocupa especialmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean y mantienen listas identificando los riesgos desde etapas iníciales 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 validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos técnicos.

El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que reúne en una única disciplina las disciplinas de Modelado de Negocio, Requisitos y Análisis y Diseño. El resto de disciplinas (Implementación, Pruebas, Despliegue, Gestión de Configuración, Gestión y Entorno) coinciden con las restantes de RUP.

2 ANTECEDENTES

Evolución histórica de las metodologías de desarrollo de software

Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para los años 60 y consistía en codificar y corregir (Code-and-Fix), si al terminar se descubría que el diseño era incorrecto, la solución era desecharlo y volver a empezar 3, este modelo implementaba el código y luego se pensaba en los requisitos, diseño, validación y mantenimiento. los principales problemas del modelo de procesos son:

Los arreglos se hacen costosos, después de tantas correcciones el código tenia una mala estructura.

El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y modificar.

En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y administración. El modelo en cascada surge como respuesta al modelo de procesos, este modelo tiene mas disciplina y se basa en el análisis, diseño, pruebas y mantenimientos. 4

La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno siempre cambiante y en rápida evolución en que se han de desarrollar los programas informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global.

Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo.

Las metodologías más utilizadas a nivel mundial en orden cronológico:13

Década de los 70s

• Programación Estructurada Jackson desde 1975

Década de los 80s

• Structured Systems Analysis and Design Methodology (SSADM) desde 1980

• Structured Analysis and Design Technique (SADT) desde 1980

• Ingeniería de la Información (IE/IEM) desde 1981

Década de los 90s

• Rapid Application Development (RAD) desde 1991.

• Programación Orientada a Objetos (OOP) a lo largo de la década de los 90's

• Virtual Finite State Machine (VFSM) desde 1990s

• Dynamic Systems Development Method desarrollado en UK desde 1995.

• Rational Unified Process (RUP) desde 1999

Año 2000 en adelante

• Extreme Programming (XP) desde 1999

• Enterprise UnifiedProcess (EUP) extensiones RUP desde 2002

• Constructionist Design Methodology (CDM) desde 2004 porKristinn R. Thórisson

• Agile Unified Process (AUP) desde 2005 por Scott Ambler

La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar, luego a establecer funciones en etapas o módulos, continuar en resaltar en la primera etapa el análisis de los requisitos, seguido de basarse en objetos, y por último agilizar el desarrollo del software y minimizar los costos. Estos cambios de paradigma han logrado las mejoras para desarrollar software y aunque principalmente buscar acortar el tiempo de solución sin reprochar los recursos disponibles.

Generaciones de metodologías

Las metodologías han ido cambiando con el tiempo, al surgir nuevos paradigmas que rompe con lo tradicional para abrir paso a nuevas técnicas de solución.5Han evolucionando a lo largo del tiempo estas herramientas, inicialmente el periodo de desarrollo convencional (practicas artesanales), luego surge el Desarrollo estructurada (parte de la programación estructurada seguido de los método de análisis y diseño, cubre todo el ciclo de vida completo). Actualmente aparece el paradigma de la orientación a objetos.

Desarrollo Convencional

En los años 50 el desarrollo estaba a cargo de programadores, por lo que se vio la importancia del análisis y diseño en el desarrollo de los sistemas. Aparecen los analistas programadores y analistas de sistemas.6

En esta misma época, no existían metodologías de desarrollo. Las personas que desarrollaban los sistemas eran programadores más enfocados en la tarea de codificar, que en la de recoger y comprender las necesidades de los usuarios. Estos, a menudo, no quedaban satisfechos con el sistema, porque sus necesidades no estaban definidas con claridad en una fase de análisis previo. Ante esta perspectiva se vio la importancia del análisis y del diseño en el desarrollo de un sistema. Ahora se empieza a hablar de analistas programadores y analistas de sistemas.

Hasta hace relativamente poco tiempo cuando se hablaba de “desarrollo” se aludía únicamente al crecimiento económico dando por supuesto que dicho crecimiento se revierte de manera casi automática en los otros sectores de la estructura social. Las estrategias de desarrollo se han concentrado fundamentalmente en estrategias económicas, que aunque incorporan elementos de otros sectores –por ejemplo del sector social-, buscan como objetivo fundamental

...