Procesos Agiles
Procesos Agiles
Procesos Agiles
La ingeniera de software gil combina una filosofa y un conjunto de directrices de desarrollo. La filosofa busca la satisfaccin del cliente y la entrega temprana de software incremental; equipos de proyecto pequeos y con alta motivacin; mtodos informales; y un mnimo de productos de trabajo de la ingeniera del software; y una simplicidad general del desarrollo. Las directrices de desarrollo resaltan la entrega sobre el anlisis y el diseo y la comunicacin activa y continua entre los desarrolladores y los clientes. Los ingenieros de software y otros participantes del proyecto trabajan juntos en un equipo gil: un equipo con organizacin propia y que controla su propio destino. Un equipo gil fomenta la comunicacin y la colaboracin entre todos los que trabajan en el. El ambiente moderno de los negocios ocasiona que los sistemas basados en computadoras y los productos de software estn acelerados y en cambio continuos. Ingeniera de software gil representa una opcin razonable la ingeniera convencional para ciertas clases de software. Ha demostrado su utilidad al entregar sistemas exitosos con rapidez. El desarrollo gil podra llamarse con mayor precisin ingeniera del software ligera. Las actividades bsicas del marco de trabajo comunicacin con el cliente, planeacin, modelo, construccin, entrega y evolucin se conservan, pero estas se conforman como un conjunto mnimo de tareas que empuja al equipo de proyecto hacia la construccin y la entrega. Los clientes e ingenieros de software que han adoptado la filosofa gil tienen la misma visin: el nico producto de trabajo realmente importante es un incremento de software en funcionamiento, el cual se entrega al cliente en una fecha prometida. Si el equipo de software est de acuerdo en que el proceso funciona y dicho equipo produce incrementos de software entregables que satisfacen al cliente, entonces el trabajo est bien hecho. La alianza gil [AG103] define 12 principios para quienes quieren alcanzar la agilidad: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso. 2. Bienvenidos los requisitos cambiantes, incluso en fases tardas del desarrollo. La estructura de los procesos giles cambia para la ventaja competitiva del cliente.
3. 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. 4. La gente de negocios y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto. 5. Construir proyectos alrededor de individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado. 6. 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 l 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 autoorganizados. 12. A intervalos regulares el equipo refleja la forma en que se puede volver ms efectivo; entonces su comportamiento se ajusta y adecua en concordancia. La agilidad se puede aplicar en cualquier proceso de software. Sin embargo, para lograrlo es esencial que el proceso sea diseado en una forma que permita al equipo del proyecto adaptar y coordinar las tareas, conducir la planeacin en una forma que entienda la fluidez de un enfoque de desarrollo gil, eliminar todo pero no los productos de trabajo esenciales que proporcione software en funcionamiento al cliente tan rpido como sea factible para el tipo de producto y el ambiente operativo. Cualquier proceso gil de software se caracteriza de una manera que refiere tres suposiciones clave [FOW02] acerca de la mayora de los proyectos de software: 1. Resulta difcil predecir cuales requisitos del software persistirn y cuales cambiaran. De igual forma, es difcil presagiar como cambiaran las prioridades del cliente mientras se ejecuta un proyecto. 2. Para muchos tipos de software, el diseo y la construccin estn intercalados. Esto es, ambas actividades se deben realizar de manera conjunta, de modo que los modelos de diseo se deben realizar de manera conjunta, de modo que los modelos de diseo sean probados conforme se crean. Resulta difcil predecir cuanto diseo se necesita antes de que la construccin se utiliza para probar el diseo.
3. El anlisis, el diseo y la construccin no son predecibles (desde el punto de vista de la planeacin), lo que sera deseable. No existe un sustituto para la retroalimentacin rpida, ni el proceso de desarrollo ni en el producto mismo. MODELOS AGILES DE PROCESO La historia de la ingeniera del software est llena de decenas de descripciones y metodologas, mtodos de modelado y notaciones, herramientas y tecnologas obsoletas. Cada elemento surgi con notoriedad y despus lo eclips algo nuevo y mejor. La programacin extrema utiliza un enfoque orientado a objetos como su paradigma de desarrollo preferido. La PE abarca un conjunto de reglas y prcticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planeacin, diseo, codificacin y pruebas.
TECNICAS (CAJA NEGRA Y CAJA BLANCA) Las tcnicas de caja negra de QA manejan aplicaciones, o partes de ellas, que ya estn construidas. Estas tcnicas verifican si el software cumple o no con sus requerimientos. Las tcnicas de caja blanca (o caja de vidrio) de QA se aplican a las componentes que forman la unidad que se estn probando.
2. Identificar el proceso
QA
4. Disear y construir
3. Planear
Cristal
Modelado gil
Ventajas Es orientado a objetos, lleva un marco de trabajo (planeacin, diseo, codificacin y prueba). Colaboracin humana, tiene un ciclo de vida, aprendizaje (grupos enfocados, revisin tcnicas formales y post mortem). Proporciona un marco de trabajo para construir, equipos auto-organizados. Equipos de trabajo pequeos, se realiza documentacin conforme se construye el producto. Juego cooperativo de inventiva, se entrega un software til y en funcionamiento, seleccin de miembros. Orientado a objetos, se puede aplicar en proyectos de software de tamao moderado o grande, puede implementarse en dos semanas o menos, agrupamiento jerrquico relacionado con el negocio. Es aplicado en sistemas grandes, toma en cuenta el problema y la calidad, tiene un mrito significativo.
Enfrenta dificultades y es desafiante sostener muchos proyectos, dificultad para el mantenimiento del modelo.