CAPITULO II METODOLOGÍAS DE ANÁLISIS Y DISEÑO DE SISTEMAS 2.1. Modelos de Proceso de Software 2.1.1. Modelos Secuenciales 2.1.1.1. El modelo de codificar y fijar El modelo básico usado en los primeros días del desarrollo de software, tiene dos pasos: (1) Escribir algún código. (2) fijar los problemas en el código. Así, el orden de los pasos era fabricar algún código primero y pensar sobre los requerimientos, diseño, prueba y mantención a continuación. Este modelo tiene las dificultades de presentar una baja estructuración del código luego de alguna cantidad de fijaciones, pese a que se puede desarrollar un software de calidad, es posible que éste tenga una correspondencia muy pobre con las reales necesidades del usuario y, finalmente, si no existe la conciencia de la necesidad real de pruebas y modificaciones el costo de las sucesivas fijaciones será muy alto. Este método resumen las características de los métodos más formales desarrollados posteriormente, primero, la desvinculación con el problema: hay, de partida dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa. Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos. Pero, por otro lado, la primera evolución en relación a los métodos es el resultado de las deficiencias presentadas por método de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitiría incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificación, coordinación y control. Esto también coincide con el tamaño de los problemas a resolver, el que se va incrementando debido, sobre todo, al aumento de las capacidades del hardware. 2.1.1.2. El modelo de etapas En 1956, el enfrentarse a un gran sistema de software como el Semi-Automated Ground Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificación y esto llevó al desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo estipula que el software será desarrollado en sucesivas etapas:
El modelo de etapas consideraba que cada una de ellas debería ir a continuación de la anterior, poniendo énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificación y de control. Todo tendiente a conformar una cadena de producción de software, de manera similar a una cadena de montaje de automóviles. 2.1.1.3. El modelo de cascada o ciclo de vida clásico Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del trabajo involucrado en retroalimentaciones a través de muchas etapas.
Según Pressman se tiene:
2.1.1.4. El desarrollo orientado a prototipos Si bien algunos autores consideran que esto es parte del ciclo de vida clásico, es también posible verlo como un método independiente. Una definición de un prototipo en software podría ser: "...es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas"
Según Pressman se tiene
2.1.1.5. El Modelo DRA El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de períodos cortos de tiempo.
2.1.2. Modelos Evolutivos El desarrollo evolutivo es una metodología de desarrollo de software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El énfasis esta puesto sobre la importancia de obtener un sistema de producción flexible y expandible. Así, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mínimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible. La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendría la propiedad de satisfacer los nuevos requerimientos lo más rápido posible. En contraste, prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada iteración es mucho más importante para el desarrollo evolutivo. En la siguiente figura se puede ver gráficamente esta diferencia.
2.1.2.1. El Modelo Incremental. El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos.
2.1.2.2. El modelo Espiral. El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.
2.1.3. Modelos Ágiles A principios de la década del ’90, surgió un enfoque que fue bastante revolucionario para su momento ya que iba en contra de toda creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por Martin y se dio a conocer en la comunidad de Ingeniería de Software con el nombre de RAD o Rapid Application Development. RAD consistía en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de programadores utilizando herramientas que generaban código en forma automática tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo.
La historia de las Metodologías Ágiles y su apreciación como tales en la comunidad de la Ingeniería de Software tiene sus inicios en la creación de una de las metodologías utilizada como arquetipo: XP, eXtreme Programming, que nace de la mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham. Durante 1996, Beck es llamado por Chrysler como asesor del proyecto Chrysler Comprehensive Compensation (C3) Payroll System. Dada la poca calidad del sistema que se estaba desarrollando, Beck decide tirar todo el código y empezar de cero utilizando las prácticas que él había ido definiendo a lo largo del tiempo. El sistema, que administra la liquidación de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000 métodos, es puesto en operación en Mayo de 1997 casi respetando el calendario propuesto. Como consecuencia del éxito de dicho proyecto, Kent Beck dio origen a XP iniciando el movimiento de metodologías ágiles al que se anexarían otras metodologías surgidas mucho antes que el propio Beck fuera convocado por Chrysler. Es así como que este tipo de metodologías fueron inicialmente llamadas “metodologías livianas”, sin embargo, aun no contaban con una aprobación pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los años, en febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace formalmente el término “ágil” aplicado al desarrollo de software. En esta misma reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software con el objetivo de esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El puntoo de partida fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”. 2.1.3.1. El manifiesto ágil El Manifiesto Ágil comienza enumerando los principales valores del desarrollo ágil. Según el Manifiesto se valora: •
•
•
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
•
colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son: 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. 7. El software que funciona es la medida principal de progreso. 8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. 9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.
