DESARROLLO AGIL DE SOFTWARE

ROLANDO JAVIER MENDOZA IVAN TORREZ PETER FABIO VIDAURRE

INTRODUCCION
En 2001, Kent Beck y otros 16 notables desarrolladores,

escritores y consultores [BEC01] (conocidos como la "Alianza gil") firmaron el "Manifiesto para el desarrollo gil de software", el cual estableca: A los individuos y sus interacciones sobre los procesos y las herramientas. Al software en funcionamiento sobre la documentacin extensa. A la colaboracin del cliente sobre la negociacin del contrato. A una respuesta al cambio sobre el seguimiento de un plan.

INTRODUCCION
Se entiende como Desarrollo gil de software a un

paradigma de Desarrollo de Software basado en procesos giles. 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.

AGILIDAD
La agilidad se ha convertido en la palabra idnea para describir

un proceso de software moderno. Un equipo gil es un equipo rpido que responde de manera apropiada a los cambios.

Cambios propios del software, Cambios entre miembros del equipo Cambios de nuevas tecnologas Cambios que inciden en el producto o proyecto

Un equipo gil reconoce que el software lo desarrollan

individuos que trabajan en equipo y que las aptitudes y su capacidad de colaboracin, son esenciales para el xito del proyecto. La agilidad es dinmica, con contenido especfico, ajustable al cambio de manera dinmica y orientada al crecimiento

AGILIDAD
La Alianza gil [AGI03] define 12 principios para quienes

1.
2.

3.

4.

5.

quieren alcanzar la agilidad: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso. Bienvenidos los requisitos cambiantes, incluso en fases tardas del desarrollo. La estructura de los procesos giles cambia para la ventaja competitiva del cliente. Entregar con frecuencia software en funcionamiento, desde un par de semanas hasta un par de meses, con una preferencia por la escala de tiempo ms corta. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado.

AGILIDAD
El mtodo ms eficiente y efectivo de transmitir informacin hacia y dentro de un equipo de desarrollo es la conversacin cara a cara. 7. El software en funcionamiento es la medida primaria de progreso. 8. Los procesos giles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante de manera indefinida. 9. La atencin continua a la excelencia tcnica y al buen diseo mejora la agilidad. 10. La simplicidad [el arte de maximizar la cantidad de trabajo no realizado]es esencial. 11. Las mejores arquitecturas, los mejores requisitos y los mejores diseos emergen de equipos auto organizados. 12. A intervalos regulares el equipo refleja la forma en que se puede volver ms efectivo; entonces su comportamiento se ajusta y adeca en concordancia.
6.

AGILIDAD
La agilidad se puede aplicar en cualquier proceso de

software, pero el equipo debe ser capaz de adaptar y coordinar las tareas con fluidez de un enfoque de desarrollo gil, y enfatizar en una estrategia de entrega incremental que proporcione software en funcionamiento al cliente tan rpido como sea factible para el tipo de producto y el ambiente operativo.

PROCESO AGIL
Cualquier proceso gil de software se caracteriza de

una manera que refiere tres suposiciones clave de los proyectos de software: 1. Es difcil predecir los requisitos de software que persistirn y cuales cambiarn. Es difcil presagiar como cambiarn las prioridades del cliente mientras se ejecuta un proyecto. 2. El diseo y la construccin se deben realizar de manera conjunta. 3. El anlisis, el diseo y la construccin no son predecibles(desde el punto de vista de la planeacin)

PROCESO AGIL
Un proceso gil de software debe adaptarse en forma

incremental. Un equipo gil requiere de la retroalimentacin con el cliente para que sea factible realizar la adaptaciones apropiadas. Para una efectiva retroalimentacin se manejan prototipos operacionales o una porcin de un sistema operacional. Por lo anterior debe instituirse una estrategia incremental de desarrollo.

LAS POLTICAS DEL DESARROLLO GIL

Existe un debate considerable (a veces estridente) sobre los

beneficios y la aplicabilidad del desarrollo gil del software como alternativa a procesos de ingeniera del software ms convencionales. Jim Highsmith [HlG02a] (a manera de broma) analiza los extremos cuando caracteriza el sentimiento del campo pro agilidad ("agilitadores"). "Los metodlogos tradicionales son un conjunto de tipos que se arrastran en el lodo y que prefieren producir documentacin que no fluye, en vez de un sistema de trabajo que cubra las necesidades del negocio." Como contraparte, establece la posicin del campo de la ingeniera del software (de nuevo, en forma de broma): "Los metodlogos 'ligeros' y, en, 'giles' son un conjunto de intrusos informticos que van a estar ah para dar una maldita sorpresa cuando intenten elevar sus juguetes al nivel de software de la empresa".

POLITICA DE DESARROLLO AGIL

Nadie est en contra de la agilidad. La pregunta real es: cul es la mejor

manera de lograrla? Igual de importante es la pregunta: cmo se construye un software que satisfaga hoy las necesidades de los clientes y muestre las caractersticas de calidad que le permitan extenderse y escalar para cubrir a largo plazo las necesidades del cliente?
No existen respuestas absolutas para ninguna de estas preguntas. Aun

dentro de la escuela gil se han propuesto varios modelos de proceso, cada uno con un enfoque sutilmente diferente para el problema de la agilidad. Dentro de cada modelo hay un conjunto de "ideas" (que los agilitado res suelen llamar "tareas de trabajo") que representan una separacin significativa de la ingeniera del software convencional. Y aun as, muchos conceptos de agilidad son tan slo adaptaciones de buenos conceptos de la ingeniera del software. Como punto final, hay mucho que ganar si se considera lo mejor de ambas escuelas, y nada que ganar si se denigra alguno de los dos enfoques.

Metodologa gil
Pocos Artefactos. El modelado es prescindible, modelos desechables. Pocos Roles, ms genricos y flexibles No existe un contrato tradicional, debe ser bastante flexible Cliente es parte del equipo de desarrollo (adems in-situ) Orientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitio La arquitectura se va definiendo y mejorando a lo largo del proyecto nfasis en los aspectos humanos: el individuo y el trabajo en equipo Se esperan cambios durante el proyecto

Metodologa Tradicional
Ms Artefactos. El modelado es esencial, mantenimiento de modelos Ms Roles, ms especficos Existe un contrato prefijado El cliente interacta con el equipo de desarrollo mediante reuniones Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos Se promueve que la arquitectura se defina tempranamente en el proyecto nfasis en la definicin del proceso: roles, actividades y artefactos Se espera que no ocurran cambios de gran impacto durante el proyecto