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 metodologías livianas, intentan evitar tortuosos y burocráticos caminos de la 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 se denomina una iteración, la cual debe durar de una a cuatro semanas, cada iteración del 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. POLITICAS Los métodos agiles enfatizan las comunicaciones cara a cara en vez de la documentación.la mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas plataformas de lanzamiento , la oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos agiles también enfatizan que el software funcional es la primera medida del progreso. Combinados con la preferencia por las comunicaciones cara a cara, generalmente los métodos agiles son criticados y tratados como “indisciplinados” por la falta de documentación técnica. PROGRAMACIÓN EXTREMA DEFINICION Es un enfoque de la ingeniería 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 programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más é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 aproximación mejor y más realista que intentar definir todos los requisitos el comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinámica durante el ciclo de vida del software. POLITICA Los principios originales de la programación extrema son : - Simplicidad -Comunicación -Retroalimentación -coraje SIMPLICIDAD Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. con las constantes revisiones del código por parte de los desarrolladores y su exponencial crecimiento y mejoramiento se hace necesario la refactorización del código es decir para la reestructuración del código fuente, alterando su estructura interna sin modificar su comportamiento externo. Permitiendo de esta manera mantener el código simple a medida que crece, se aplica este principio también en la documentación del código en cuanto a sus comentarios para que este permanezca autodocumentado. COMUNICACIÓN La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. RETROALIMENTACION Al estar el cliente integrado en el proyecto, su opinión 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 más importante. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. CORAJE O VALENTIA Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. RESPETO Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. DESARROLLO ADAPTATIVO DE SOFTWARE DEFINICION El desarrollo adaptativo de software (DAS)fue propuesto por jim highsmith como una metodología para desarrollar software y sistemas muy complejos. El se centra en la colaboración humana y la organización en equipo. El ciclo de vida del DAS se conforma de tres fases; especulación, colaboración y aprendizaje. En la fase de especulación se inicia el desarrollo del proyecto. En ella se utiliza información como la misión del cliente, las restricciones del proyecto y los requisitos básicos para definir el conjunto de ciclos en el que se harán los incrementos del software. Para la fase de colaboración se busca que el equipo no solo se comunique o se encuentren completamente integrados, se desea que exista confianza , donde se pueda realizar críticas 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 tecnología, los procesos utlizados y el proyecto.El parendizaje individual permite al equipo tener mayor posibilidad de éxito. MODELO AGIL Es una metodología basada en la práctica para modelado efectivo de sistemas de software. La metodología AM es una colección de prácticas, guiadas por principios y valores que pueden ser aplicados por profesionales de software en el día a día. MA no es un proceso prescriptivo, ni define procedimientos detallados de cómo crear un tipo de modelo dado. En lugar de eso, sugiere practicas para ser modelador efectivo.es “suave al tacto “no es duro ni rápido, piense en MA como un arte, no una ciencia. POLITICA - Asumir simplicidad Permitir el siguiente esfuerzo es el objetivo secundario Cambio incremental Maximizar la inversión de las partes interesadas en el proyecto Modelar con un propósito Múltiples modelos Trabajo de calidad Rápida retroalimentación El software es el objetivo primario El contenido es mas importante que la presentación Adaptación local MÉTODO DE DESARROLLO DE SISTEMAS DINAMICOS(MDSD) El método de sistemas dinámicos (MDSD)permite la construcción de sistemas con restricción 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 básicos del negocio y las restricciones asociadas a la metodología 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 básica de la aplicación. La iteración de modelo funcional , se realizan diversos prototipos incrementales que permiten mostrar al cliente la funcionalidad del sistema. Con cada iteración se recopilan requisitos adicionales que pueden ir siendo incluidos en el prototipo La iteración de construcción y diseño , contribuye a agregar el valor operativo del negocio para los usuarios, a través de la construcción de prototipos durante la iteración del modelo funcional. Implementación, los prototipos que vayan surgiendo de la fase de construcción y diseño, 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 década 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 métodos 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 días, aunque se pueden realizar con más frecuencia. Demostración a participantes externos una vez culminada cada iteración Al principio de cada iteración , planeamiento adaptativo guiado por el cliente EL CICLO DE VIDA DEL MELÉ Planeamiento:El propósito es establecer la visión, definir expectativas y asegurarse la financiación, las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso del producto inicial y los ítems estimados , así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. Montaje: El propósito es identificar mas requerimientos y priorizar las tareas para la primera iteración.las actividades son planificación , diseño exploratorio y prototipos. Desarrollo : El propósito es implementar un sistema listo para entrega en una seria de iteraciones de treinta días llamadas “corridas”.Las actividades son un encuentro de planeamiento de corridas de cada iteración, la definición de registro de acumulación de corridas y los estimados y encuentros diarios. Liberación:El propósito es el despliegue operacional . las actividades , documentación, enfrentamiento , mercadeo y venta METODOLOGÍA RUP El Proceso Unificado de Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más 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 características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También 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 podrán 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 iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados Colaboración entre equipos El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados,etc. Elevar el nivel de abstracción Este principio dominante motiva el uso de conceptos reutilizables tales como patrón 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 codificación 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 reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar 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 iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.