MODELOS DE DESARROLLO DE SOFTWARE

1. MODELO SECUENCIAL LINEAL

Este es tambin llamado "Modelo Clsico", "Modelo Tradicional" o "Modelo en
Cascada".
Este es el ms bsico de todos los modelos, y sirve como bloque de
construccin para los dems modelos de ciclo de vida. La visin del modelo
cascada del desarrollo de software es muy simple; dice que el desarrollo de
software puede ser a travs de una secuencia simple de fases. Cada fase tiene
un conjunto de metas bien definidas, y las actividades dentro de una fase
contribuyen a la satisfaccin de metas de esa fase o quizs a una
subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin
entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia
atrs representan la retroalimentacin.

Caractersticas:

Planear un proyecto antes de embarcarse en l.

Definir el comportamiento externo deseado del sistema antes de disear

su arquitectura interna.

Documentar los resultados de cada actividad.

Disear un sistema antes de codificarlo.

Testear un sistema despus de construirlo.

Ventaja:

Una de las contribuciones ms importantes del modelo cascada es para

los administradores, posibilitndoles avanzar en el desarrollo, aunque en
una escala muy bruta.

Desventajas:

Los cambios introducidos durante el desarrollo pueden confundir al

equipo profesional en las etapas tempranas del proyecto. Si los cambios
se producen en etapa madura (codificacin o prueba) pueden ser
catastrficos para un proyecto grande.

No es frecuente que el cliente o usuario final explicite clara y

completamente los requisitos (etapa de inicio); y el modelo lineal lo
requiere. La incertidumbre natural en los comienzos es luego difcil de
acomodar.

El cliente debe tener paciencia ya que el software no estar disponible

hasta muy avanzado el proyecto. Un error detectado por el cliente (en
fase de operacin) puede ser desastroso, implicando reinicio del
proyecto con altos costos.

Critica:

Este es un modelo en el cual se debe usar cuando todos los requerimientos

han sido establecidos claramente de entrada.
2. MODELO DE CONSTRUCCION DE PROTOTIPOS
El prototipado de requerimientos es la creacin de una implementacin parcial
de un sistema, para el propsito explcito de aprender sobre los requerimientos
del sistema. Un prototipo es construido de una manera rpida tal como sea
posible. Esto es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos experimenten con el prototipo. Estos individuos luego
proveen la retroalimentacin sobre lo que a ellos les gust y no les gust
acerca del prototipo proporcionado, quienes capturan en la documentacin
actual de la especificacin de requerimientos la informacin entregada por los
usuarios para el desarrollo del sistema real. El prototipado puede ser usado
como parte de la fase de requerimientos (determinar requerimientos) o justo
antes de la fase de requerimientos (como predecesor de requerimientos). En
otro caso, el prototipado puede servir su papel inmediatamente antes de algn
o todo el desarrollo incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la
especificacin de requerimientos para sistemas complejos tienden a ser
relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que
es mucho ms fcil proveer retroalimentacin convenientemente basada en la
manipulacin, leer una especificacin de requerimientos potencialmente
ambigua y extensa.

Escu
char
al
client
e

Valid
ar
proto
tipo

Cons
truir
proto
tipo

Diferente del modelo evolutivo donde los requerimientos mejor entendidos

estn incorporados, un prototipo generalmente se construye con los
requerimientos entendidos ms pobremente.

Desventajas:

Cliente cree que es el sistema.

Peligro de familiarizacin con malas elecciones iniciales (quick and

dirty).

Critica:
Se debe usar cuando inicialmente no estn claros los requerimientos. Para as
definir claramente de entrada las reglas con el cliente.
3. MODELOS EVOLUTIVOS
Se adaptan ms fcilmente a los cambios introducidos a lo largo del

desarrollo.
Iterativos
En cada iteracin se obtienen versiones ms completas del SW.
3.1. MODELO INCREMENTAL

Los riesgos asociados con el desarrollo de sistemas largos y complejos son

enormes. Una forma de reducir los riesgos es construir slo una parte del
sistema, reservando otros aspectos para niveles posteriores. El desarrollo
incremental

es

el

proceso

de

construccin

siempre

incrementando

subconjuntos de requerimientos del sistema. Tpicamente, un documento de

requerimientos es escrito al capturar todos los requerimientos para el sistema
completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada.
El desarrollo incremental no demanda una forma especfica de observar el
desarrollo de algn otro incremento. As, el modelo cascada puede ser usado
para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos

para los proyectos:

Construir un sistema pequeo es siempre menos riesgoso que construir

un sistema grande.

Al ir desarrollando parte de las funcionalidades, es ms fcil determinar

si los requerimientos planeados para los niveles subsiguientes son
correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser

descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en

incremento del sistema) decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser

usado.

Los errores de desarrollo realizados en un incremento, pueden ser

arreglados antes del comienzo del prximo incremento.

En la figura

se muestra un refino del diagrama previo, bajo un esquema

temporal, para obtener finalmente el esquema del Modelo de ciclo de vida

Iterativo Incremental, con sus actividades genricas asociadas. Aqu se
observa claramente cada ciclo cascada que es aplicado para la obtencin de
un incremento; estos ltimos se van integrando para obtener el producto final
completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la figura 5 se muestra como secuencial puro.
Se observa que existen actividades de desarrollo (para cada incremento) que
son realizadas en paralelo o concurrentemente, as por ejemplo, en la figura,
mientras se realiza el diseo detalle del primer incremento ya se est
realizando en anlisis del segundo.
Ventajas:
El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.
Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de tiempo
real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice
de riesgos.
Critica:
En este modelo se debe especificar con precisin todo lo que el sistema va a
hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuira los
costos.
3.2. MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la
naturaleza iterativa de la construccin de prototipos, pero conservado aquellas
propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe as:

El modelo de desarrollo en espiral es un generador de modelo de proceso
guiado por el riesgo que se emplea para conducir sistemas intensivos de
ingeniera de software concurrente y a la vez con muchos usuarios.
Caractersticas:

Un enfoque cclico para el crecimiento incremental del grado de

definicin e implementacin de un sistema, mientras que disminuye su
grado de riesgo.

Un conjunto de puntos de fijacin para asegurar el compromiso del

usuario con soluciones de sistema que sean factibles y mutuamente
satisfactorias.

El modelo espiral no es una alternativa del modelo cascada, ellos son

completamente compatibles.
Funcionamiento del modelo Espiral

En cada vuelta tomamos en cuenta:

Los Objetivos: Que necesidad debe envolver el programa.

Alternativas: Los varios mtodos de alcanzar los objetivos de
manera exitosa, a travs de diferentes puntos como son:
o Caractersticas: experiencia del personal, exigencias a
efectuar.
o Formas de gestin del programa.
o Riesgo tomado con cada alternativa.

Desarrollar y Verificar: Programar y probar el programa .

Se planificaran los siguientes pasos y se volver a empezar la
espiral. La espiral tiene una forma de caracola y se dice que
mantiene dos dimensiones la radial y la angular:
o Angular=Avance del proyecto Software, dentro de un ciclo.
o Radial=Aumento del coste del proyecto, ya que con cada
nueva iteracin se pasa ms tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creacin
de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los
aspectos fundamentales de su xito radica en que el equipo que lo aplique sea
capaz de detectar y catalogar correctamente dicho riesgo.
Desventajas:

Requiere mucha experiencia y habilidad para la evaluacin de los

riesgos, lo cual es requisito para el xito del proyecto.

Es difcil convencer a los grandes clientes que se podr controlar este

enfoque evolutivo.

Critica:

Este modelo es til para grandes proyectos pero no ha sido utilizado tanto
como el lineal secuencial o el de prototipos. Tiene similitud con el modelo en
cascada, pero aqu lo enfoca en un sistema ms real.

3.3. MODELO WINWIN

Una variante interesante del Modelo Espiral previamente visto es el "Modelo
Espiral Win-Win" (Barry Boehm). El Modelo Espiral previo (clsico) sugiere la
comunicacin con el cliente para fijar los requisitos, en que simplemente se
pregunta al cliente qu necesita y l proporciona la informacin para continuar;
pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y
desarrollador entran en una negociacin, se negocia coste frente a
funcionalidad, rendimiento, calidad, etc.
"Es as que la obtencin de requisitos requiere una negociacin, que tiene xito
cuando ambas partes ganan".
Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win &
Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el
desarrollador tambin gane consiguiendo presupuesto y fecha de entrega
realista. Evidentemente, este modelo requiere fuertes habilidades de
negociacin.
El modelo Win-Win define un conjunto de actividades de negociacin al
principio de cada paso alrededor de la espiral; se definen las siguientes
actividades:
1 - Identificacin del sistema o subsistemas clave de los directivos(*)
(saber qu quieren).
2 - Determinacin de "condiciones de victoria" de los directivos (saber
qu necesitan y los satisface)

3 - Negociacin de las condiciones "victoria" de los directivos para

obtener condiciones "Victoria & Victoria" (negociar para que ambos
ganen).

(*) Directivo: Cliente escogido con inters directo en el producto, que puede ser
premiado por la organizacin si tiene xito o criticado si no.

El modelo WinWin hace nfasis en la negociacin inicial, tambin introduce 3

hitos en el proceso llamados "puntos de fijacin", que ayudan a establecer la
completitud de un ciclo de la espiral, y proporcionan hitos de decisin antes de
continuar el proyecto de desarrollo del software.
Critica:
En este modelo las actividades que se definen son importantes como lo son: la
identificacin del sistema, la determinacin de las condiciones y la negociacin
de estas.

3.4. MODELO DE DESARROLLO CONCURRENTE

Como el modelo espiral, el modelo concurrente provee una meta-descripcin
del proceso software. Mientras que la contribucin primaria del modelo espiral
es en realidad que esas actividades del software ocurran repetidamente, la
contribucin del modelo concurrente es su capacidad de describir las mltiples
actividades del software ocurriendo simultneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas
actividades que ocurren en algn tiempo del proceso de desarrollo de software.
Los requerimientos son usualmente "lneas de base", cuando una mayora de
los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica
un esfuerzo considerable al diseo. Sin embargo, una vez que comienza el
diseo, cambios a los requerimientos son comunes y frecuentes (despus de
todo, los problemas reales cambian, y nuestro entendimiento de los problemas

desarrollados tambin). Es desaconsejado detener el diseo en este camino

cuando los requerimientos cambian; en su lugar, existe una necesidad de
modificar y rehacer lneas de base de los requerimientos mientras progresa el
diseo. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseo puede no ser afectado, medianamente afectado o se
requerir comenzar todo de nuevo.
Durante el diseo de arquitectura, es posible que algunos componentes
comiencen a ser bien definidos antes que la arquitectura completa sea
estabilizada. En tales casos, puede ser posible comenzar el diseo detallado
en esos componentes estables. Similarmente, durante el diseo detallado,
puede ser posible proceder con la codificacin y quizs regular testeando en
forma unitaria o realizando testeo de integracin previo a llevar a cabo el
diseo detallado de todos los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado
concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la
etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un
componente 2, mientras que se est haciendo codificacin sobre un
componente 3, mientras se realiza diseo sobre una etapa 4, y especificacin
de requisitos sobre un componente 5.
Critica:
Este

modelo

se

utiliza

cuando

las

actividades

estn

ocurriendo

simultneamente as, se posibilita el conocimiento del estado real en el que se

encuentra el proyecto.