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 minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin 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 iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto. Los mtodos Agiles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos Agiles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls). La oficina debe incluir revisores, diseadores de iteracin, escritores de documentacin y ayuda y directores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica. Metodologas giles Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean Software Development (LSD) Agile Unified Process (AUP) Software Development Rhythms Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Agile Data Method Database Refactoring LeanCMMI PROCESO UNIFICADO AGIL (AUP).El Proceso Unificado Agil de Scott Ambler o Agile Unified Process (AUP) en ingls es una versin simplificada del Proceso Unificado de Rational (RUP). 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 an se mantienen vlidos en RUP. El AUP aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (test driven development

- TDD), Modelado Agil, Gestin de Cambios Agil, y Refactorizacin de Base de Datos para mejorar la productividad. El proceso unificado (Unified Process o 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 ms conocida es RUP (Rational Unified Process) de IBM. 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. Para 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 elaboracin del producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos tcnicos. 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. CICLO DE VIDA DEL PROCESO UNIFICADO AGIL (AUP).-

Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de manera consecutiva y que acaban con hitos claros alcanzados: Inception(Concepcin): El objetivo de esta fase es obtener una comprensin comn clienteequipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo. Elaboracin: El objetivo es que el equipo de desarrollo profundice en la comprensin de los requisitos del sistema y en validar la arquitectura. Construccin: Durante la fase de construccin el sistema es desarrollado y probado al completo en el ambiente de desarrollo.

 Transicin: el sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y aceptacin y finalmente se despliega en los sistemas de produccin. Las disciplinas se llevan a cabo de manera sistemtica, a la definicin de las actividades que realizan 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: 1. Modelo. El objetivo de esta disciplina es entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio. 2. Aplicacin. El objetivo de esta disciplina es transformar su modelo (s) en cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular, la unidad de pruebas. 3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificando que se cumplan los requisitos. 4. Despliegue. El objetivo de esta disciplina es la prestacin y ejecucin del sistema y que el mismo este a disposicin de los usuarios finales. 5. Gestin de configuracin. El objetivo de esta disciplina es la gestin de acceso a herramientas de su proyecto. Esto incluye no slo el seguimiento de las versiones con el tiempo, sino tambin el control y gestin del cambio para ellos. 6. Gestin de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestin de riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc), coordinacin con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. 7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el adecuado, la orientacin (normas y directrices), y herramientas (hardware, software, etc) estn disponibles para el equipo segn sea necesario. 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. CONCLUSIONES.Si deseamos un mtodo gil entre XP y RUP tradicionales, que incluya explcitamente las actividades y las herramientas que estn acostumbrados, entonces la ms aconsejable es la AUP. XP no muestra explcitamente cmo crear algunos de las herramientas que la administracin quiere ver. En el otro extremo del espectro est RUP, que es el gestor ms utilizado de los desarrolladores, pero presenta una gran cantidad de herramientas. La AUP en comparacin entre los dos, es la adopcin de muchas de las tcnicas giles de XP y otros procesos giles que mantiene de las RUP. El usuario final es el mejor juez que determina se la AUP es el mtodo gil ms adecuado. En relacin al XP, el AUP resulta ser un proceso muy pesado y en relacin al RUP resulta ser un proceso muy simplificado, entonces, los desarrolladores debern decidir en: si desea buscar una forma de trabajo ligero esta XP y si desea trabajar con un proceso ms detallado esta RUP.

MS SOBRE EL PROCESO UNIFICADO GIL: FASES Y DISCIPLINAS

Cuando empec el desarrollo de Lets req!, mi proyecto de fin de carrera, dediqu unos das a investigar algunos procesos de desarrollo de software que me haban llamado la atencin cuando estudi Administracin de Proyectos Informticos, en busca de un proceso que me guiara por el desarrollo pero que no me aadiera ms trabajo que el desarrollo en s :-P. As que busqu algo que se pareciera al Proceso Unificado, que era el que habamos utilizado como referencia a lo largo de toda la carrera, pero quizs no tan centrado en la documentacin. Y llegu al Proceso Unificado gil.

El Proceso Unificado gil (AUP, del ingls Agile Unified Process, AUP) es una versin simplificada del Proceso Unificado de Rational (Rational Unified Process, RUP) desarrollada por Scott Ambler, que 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 intermedioentre 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 especifica 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, pues, se haya 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. 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 valida 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. En la prxima entrega veremos cmo se tratan en el Proceso Unificado gil los modelos y la documentacin.
Pablo Torrecilla is an enthusiast Ruby on Rails developer, passionate about design of large-scale, distributed, software-intensive systems and actively committed to the new API economy7 de June de 2012 23:13Posted in IngenieraTagged metodologas giles, proceso unificado, proceso unificado gilComments (0)

A simple algorithm for word singularization in spanish Ms sobre el Proceso Unificado gil: modelos y documentacin

NO COMMENTS

Proceso Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplementeRUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, elProceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson,Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican

libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

ndice 1 Caractersticas o o o o 1.1 Iterativo e Incremental 1.2 Dirigido por los casos de uso 1.3 Centrado en la arquitectura 1.4 Enfocado en los riesgos

2 Lenguaje unificado de modelado o 2.1 Por qu analizar y disear?

3 Vase tambin 4 Bibliografa

Caractersticas[editar cdigo]
Iterativo e Incremental[editar cdigo]
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.

Dirigido por los casos de uso[editar cdigo]

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

Centrado en la arquitectura[editar cdigo]

El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.

Enfocado en los riesgos[editar cdigo]

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

Lenguaje unificado de modelado[editar cdigo]

El Lenguaje unificado de modelado no es el sucesor de la oleada de metodos de analisis y diseno orientados a objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los metodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance ha llegado a formar parte fundamental de la Ingeniera de Software tras su estandarizacin en 1997 con el OMG (Object Management Group o Grupo de administracion de objetos).

Por qu analizar y disear?[editar cdigo]

En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son solo imagenes bonitas. Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, pg. 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qu lo har y cmo le ayudar a usted cuando llegue el momento de escribir el cdigo. No existe una evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas; pero lo que s es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos de mediana/avanzada envergadura.

Vase tambin[editar cdigo]

Ingeniera Tcnica en Informtica de Gestin

Bibliografa[editar cdigo]

JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. El Proceso Unificado de Desarrollo de Software. Pearson Addisson-Wesley. Ao 2000.. Categora:

Ingeniera de software