DESARROLLO AGIL DE SOFTWARE

DEFINICION Se entiende como desarrollo gil de software a un paradigma de desarrollo de software basado en procesos agiles. Los procesos agiles de desarrollo de software conocidos antes como metodologas livianas, intentan evitar tortuosos y burocrticos caminos de la 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 se denomina una iteracin, la cual debe durar de una a cuatro semanas, cada iteracin del 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.

POLITICAS Los mtodos agiles enfatizan las comunicaciones cara a cara en vez de la documentacin.la mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas plataformas de lanzamiento , la oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores de proyecto. Los mtodos agiles tambin enfatizan que el software funcional es la primera medida del progreso. Combinados con la preferencia por las comunicaciones cara a cara, generalmente los mtodos agiles son criticados y tratados como indisciplinados por la falta de documentacin tcnica.

PROGRAMACIN EXTREMA DEFINICION Es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia en 1999, Es el mas destacado de los procesos agiles del desarrollo de software. Al igual que estos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de xp consideran que los cambios de requisitos sobre la marcha son un aspecto normal, inevitable e incluso deseable del desarrollo de proyectos. Creen que adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto, es una aproximacin mejor y ms realista que intentar definir todos los requisitos el comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.

Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinmica durante el ciclo de vida del software.

POLITICA Los principios originales de la programacin extrema son : - Simplicidad -Comunicacin -Retroalimentacin -coraje

SIMPLICIDAD Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. con las constantes revisiones del cdigo por parte de los desarrolladores y su exponencial crecimiento y mejoramiento se hace necesario la refactorizacin del cdigo es decir para la reestructuracin del cdigo fuente, alterando su estructura interna sin modificar su comportamiento externo. Permitiendo de esta manera mantener el cdigo simple a medida que crece, se aplica este principio tambin en la documentacin del cdigo en cuanto a sus comentarios para que este permanezca autodocumentado.

COMUNICACIN La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado.

RETROALIMENTACION Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante. El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas de desarrollo.

CORAJE O VALENTIA

Se requiere coraje para implementar las caractersticas que el cliente quiere ahora sin caer en la tentacin de optar por un enfoque ms flexible que permita futuras modificaciones. RESPETO Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo.

DESARROLLO ADAPTATIVO DE SOFTWARE

DEFINICION El desarrollo adaptativo de software (DAS)fue propuesto por jim highsmith como una metodologa para desarrollar software y sistemas muy complejos. El se centra en la colaboracin humana y la organizacin en equipo. El ciclo de vida del DAS se conforma de tres fases; especulacin, colaboracin y aprendizaje. En la fase de especulacin se inicia el desarrollo del proyecto. En ella se utiliza informacin como la misin del cliente, las restricciones del proyecto y los requisitos bsicos para definir el conjunto de ciclos en el que se harn los incrementos del software. Para la fase de colaboracin se busca que el equipo no solo se comunique o se encuentren completamente integrados, se desea que exista confianza , donde se pueda realizar crticas constructivas y ayudar si resentimientos, trabajar tan duro como sea posible, comunicar de forma oportuna los problemas que se presenten para tomar acciones efectivas y poseer un conjunto de actitudes que contribuyan al trabajo que se encuentren realizando. El aprendizaje permite mejorar el entendimiento real sobre la tecnologa, los procesos utlizados y el proyecto.El parendizaje individual permite al equipo tener mayor posibilidad de xito.

MODELO AGIL

Es una metodologa basada en la prctica para modelado efectivo de sistemas de software. La metodologa AM es una coleccin de prcticas, guiadas por principios y valores que pueden ser aplicados por profesionales de software en el da a da. MA no es un proceso prescriptivo, ni define procedimientos detallados de cmo crear un tipo de modelo dado. En lugar de eso, sugiere practicas para ser modelador efectivo.es suave al tacto no es duro ni rpido, piense en MA como un arte, no una ciencia. POLITICA Asumir simplicidad Permitir el siguiente esfuerzo es el objetivo secundario Cambio incremental Maximizar la inversin de las partes interesadas en el proyecto Modelar con un propsito Mltiples modelos Trabajo de calidad Rpida retroalimentacin El software es el objetivo primario El contenido es mas importante que la presentacin Adaptacin local

MTODO DE DESARROLLO DE SISTEMAS DINAMICOS(MDSD) El mtodo de sistemas dinmicos (MDSD)permite la construccin de sistemas con restriccin de tiempo , realizando prototipos incrementales en un ambiente de proyecto controlado . Este modelo se compone de dos actividades que se realizan primero y consecuente con ellas se realizan tres ciclos de vida adicionales, las dos actividades primarias son el estudio de factibilidad en donde se establecen los requisitos bsicos del negocio y las restricciones asociadas a la metodologa para evaluar si las misma puede ser realizada bajo el esquema MDSD y la segunda es el estudio del negocio donde se establecen los requerimientos funcionales y la arquitectura bsica de la aplicacin. La iteracin de modelo funcional , se realizan diversos prototipos incrementales que permiten mostrar al cliente la funcionalidad del sistema. Con cada iteracin se recopilan requisitos adicionales que pueden ir siendo incluidos en el prototipo

La iteracin de construccin y diseo , contribuye a agregar el valor operativo del negocio para los usuarios, a travs de la construccin de prototipos durante la iteracin del modelo funcional. Implementacin, los prototipos que vayan surgiendo de la fase de construccin y diseo, se iran colocando en ambientes operativos(prototipos adicionales).

MELE

Es un modelo gil de proceso desarrollado por Jeff Sutherland y su equipo a los comienzos de la dcada de los 90(la palabra mel proviene de una palabra),Tambien es conocido con el nombre de Scrum.

Posee los siguientes principios que van en concordancia con los mtodos de desarrollo agiles:

Equipos auto-dirigidos Una vez elegida una tarea , no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa Iteraciones de 30 das, aunque se pueden realizar con ms frecuencia. Demostracin a participantes externos una vez culminada cada iteracin Al principio de cada iteracin , planeamiento adaptativo guiado por el cliente

EL CICLO DE VIDA DEL MEL

Planeamiento:El propsito es establecer la visin, definir expectativas y asegurarse la financiacin, las actividades son la escritura de la visin, el presupuesto, el registro de acumulacin o retraso del producto inicial y los tems estimados , as como la arquitectura de alto nivel, el diseo exploratorio y los prototipos.

Montaje: El propsito es identificar mas requerimientos y priorizar las tareas para la primera iteracin.las actividades son planificacin , diseo exploratorio y prototipos.

Desarrollo : El propsito es implementar un sistema listo para entrega en una seria de iteraciones de treinta das llamadas corridas.Las actividades son un encuentro de planeamiento de corridas de cada iteracin, la definicin de registro de acumulacin de corridas y los estimados y encuentros diarios. Liberacin:El propsito es el despliegue operacional . las actividades , documentacin, enfrentamiento , mercadeo y venta

METODOLOGA RUP

El Proceso Unificado de Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente.

POLITICA

El RUP est basado en 6 principios clave que son:

Adaptar el proces
El proceso deber adaptarse a las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un area subformal.

Equilibrar prioridades
Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos

de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados

Colaboracin entre equipos

El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados,etc.

Elevar el nivel de abstraccin

Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.