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.