CAPITULO II METODOLOGAS DE ANLISIS Y DISEO DE SISTEMAS 2.1. Modelos de Proceso de Software 2.1.1. Modelos Iterativos 2.1.1.1.

El modelo de codificar y fijar El modelo bsico usado en los primeros das del desarrollo de software, tiene dos pasos: (1) Escribir algn cdigo. (2) fijar los problemas en el cdigo. As, el orden de los pasos era fabricar algn cdigo primero y pensar sobre los requerimientos, diseo, prueba y mantencin a continuacin. Este modelo tiene las dificultades de presentar una baja estructuracin del cdigo 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 mtodo resumen las caractersticas de los mtodos ms formales desarrollados posteriormente, primero, la desvinculacin con el problema: hay, de partida dos interlocutores, un experto en la programacin o codificacin y, por otro lado, un usuario quien sera el experto en el problema a quien se debe satisfacer mediante la codificacin de la solucin, o programa. Lo anterior nos lleva, tambin, a la idea de iteracin: esta desvinculacin entre el origen del problema y la solucin imprime en los mtodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los mbitos. Pero, por otro lado, la primera evolucin en relacin a los mtodos es el resultado de las deficiencias presentadas por mtodo de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitira incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificacin, coordinacin y control. Esto tambin coincide con el tamao 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 codificacin 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 debera ir a continuacin de la anterior, poniendo nfasis en la documentacin que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificacin y de control. Todo tendiente a conformar una cadena de produccin de software, de manera similar a una cadena de montaje de automviles. 2.1.1.3. El modelo de cascada o ciclo de vida clsico Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentacin entre etapas, y una gua para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del trabajo involucrado en retroalimentaciones a travs de muchas etapas.

Segn 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 clsico, es tambin posible verlo como un mtodo independiente. Una definicin de un prototipo en software podra 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 representacin de un sistema, aunque no es un sistema completo, posee las caractersticas del sistema final o parte de ellas"

Segn Pressman se tiene

2.1.1.5. El Modelo DRA El Desarrollo Rpido 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 adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando una construccin 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 perodos cortos de tiempo.

2.1.2. Modelos Evolutivos El desarrollo evolutivo es una metodologa 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 produccin flexible y expandible. As, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mnimo 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 tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. En contraste, prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada iteracin es mucho ms importante para el desarrollo evolutivo. En la siguiente figura se puede ver grficamente esta diferencia.

2.1.2.1. El Modelo Incremental. El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin 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 construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial.

2.1.3. Modelos giles A principios de la dcada 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 Ingeniera de Software con el nombre de RAD o Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica 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 Metodologas giles y su apreciacin como tales en la comunidad de la Ingeniera de Software tiene sus inicios en la creacin de una de las metodologas 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 cdigo y empezar de cero utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, que administra la liquidacin de aproximadamente 10.000 empleados, y consiste de 2.000 clases y 30.000 mtodos, es puesto en operacin 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 metodologas giles al que se anexaran otras metodologas surgidas mucho antes que el propio Beck fuera convocado por Chrysler. Es as como que este tipo de metodologas fueron inicialmente llamadas metodologas livianas, sin embargo, aun no contaban con una aprobacin pues se le consideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasar de los aos, en febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace formalmente el trmino gil aplicado al desarrollo de software. En esta misma reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software con el objetivo de esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Tras esta reunin se cre The Agile Alliance, una organizacin, 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 filosofa gil. 2.1.3.1. El manifiesto gil El Manifiesto gil comienza enumerando los principales valores del desarrollo gil. Segn 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 ms 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 automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta

colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms 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 tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin 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 dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin 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 deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.