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.