Nombre del Modelo Definicin Caractersticas Ventajas Desventajas

MODELO LINEAL
SECUENCIAL











Sugiere un enfoque
sistemtico secuencial para
el desarrollo del software
que comienza en un nivel de
sistemas y progresa con el
anlisis, diseo,
codificacin, pruebas y
mantenimiento
Conocido como
Modelo Cascada
Una variante de la
representacin del
modelo de la
cascada se
denomina modelo
en V.
El modelo de la
cascada es el
paradigma ms
antiguo de la
ingeniera de
software.
Desarrollado entre
1960-1980.
Basado en el
modelo en cascada
de Winston Royce.
Se conoce como el
ciclo de vida bsico.
Secuencia de
calendarizadas.
Sean proyectos
pequeo, en el que
el perodo
descongelacin de
los requisitos es
corto, o un proyecto
cununos requisitos
bastante estables
Facilita el desarrollo
en lo que respecta a
la interfaz de
usuario.

Construye un
prototipo rpido o
desechable, que
ayudara a refinar y
validar los
requerimientos.

Sirve como un
modelo de proceso
til en situaciones
en las que los
requerimientos son
fijos y el trabajo
avanza en forma
lineal hacia el final.

Facilita la gestin
del desarrollo
A menudo es difcil que el
cliente exponga
explcitamente todos los
requisitos

Los errores de anlisis y
diseo son costosos de
eliminar, y se propagan a las
fases siguientes con un
efecto conocido como bola
de nieve

El usuario debe esperar
mucho tiempo para ver los
resultados. Se tarda mucho
en pasar por todo el ciclo.

Se genera mucho
mantenimiento inicial, debido
al periodo de congelacin de
requisitos y este recae,
principalmente en el cdigo
fuente.

Es raro que los proyectos
reales sigan el flujo
secuencial propuesto por el
modelo.

El modelo de la cascada
tiene dificultades para
aceptar la incertidumbre

natural que existe al principio
de muchos proyectos

Se genera mucho
mantenimiento inicial debido
al perodo decongelacin de
requisitos y ste recae, en su
mayor parte
Nombre del Modelo Definicin Caractersticas Ventajas Desventajas





MODELO ESPIRAL













Modelo de proceso de
software evolutivo que
conjuga la naturaleza
iterativa de la
construccin de
prototipos con los
aspectos controlados y
sistemticos del modelo
lineal secuencial
Propuesto por Barry Boehm

En este modelo, el software
se desarrolla en una serie de
versiones incrementadas.

Se divide en un nmero de
actividades de marco de
trabajo, tambin llamadas
regiones de trabajo.

Existen 6 regiones de trabajo:
1.-comunicacin con el cliente
2.-Planificacion
3.- Anlisis de riesgos
4.- Ingeniera
5.-Construccion y accin
6.- Evaluacin del cliente

Es un enfoque realista del
desarrollo de sistemas y de
software a gran escala.

Utiliza la construccin de
prototipos como mecanismo
de reduccin de riesgos.

Enfoque cclico para el
crecimiento incremental del
grado de definicin de un
sistema y su implementacin,
mientras que disminuye su
grado de riesgo.

Asegura el compromiso del
participante con soluciones
factibles y satisfactorias

Metodologa demorada para
obtener un modelo optimo


Mezcla del modelo lineal
secuencial y prototipos.
Proporciona el
potencial para el
desarrollo rpido de
versiones completas.

Reduce riesgos del
proyecto.

Incorpora objetivos
de calidad.

Integra el desarrollo
con el
mantenimiento.

Usa los prototipos
como mecanismo de
reduccin de riesgos.

Permite aplicar el
enfoque de hacer
prototipos en
cualquier etapa de la
evolucin del
producto.

Se aplica a cualquier
proyecto sin importar
el tamao.

Permite evaluar si el
ciclo que se va a
hacer, aporta algo o
no (reduccin de
riesgos).




Se mejora la calidad
con el tiempo
(mientras ms
tiempo pase mejor).

Genera mucho tiempo
en el desarrollo de
sistemas.

Modelo Costoso.

Requiere experiencia
en la identificacin de
riesgos.

Hay problemas si
algn riesgo
importante no se
descubre y
administra.

-No es una tcnica de
aprendices

-Es una tcnica muy
demorada para
obtener un producto
final.

-Debe existir un
control para el
nmero de ciclos
necesarios para
obtener el producto
final.
Hace un anlisis de
riesgos que pueden
afectar el proyecto.


NOMBRE DEFINICIN CARACTERSTICAS VENTAJAS DESVENTAJAS



MODELO DRA

(Desarrollo Rpido de
Aplicaciones )



Modelo de proceso de
desarrollo del software
lineal secuencial, que
enfatiza un ciclo de
desarrollo
extremadamente cort.

El modelo DRA
comprende las siguientes
fases.
*Modelado de Gestin
*Modelado de datos
*Modelado de Proceso
*Pruebas y Entrega

Desarrollado inicialmente
por James Martin en
1980
Se basa en el modelo
lineal secuencial.
Se hace en etapas
secuenciales.
Se entrega en corto
tiempo.
Construccin basada en
componentes (elementos
de otros sistemas).

Necesita de habilidades
de programadores y
analistas.

Usa cdigos reutilizable
Requiere de bastante
personal.
El personal debe contar
con experiencia.
Comprar puede ahorrar
dinero en comparacin
con construir.

El proceso DRA permite al
equipo de desarrollo crear
un sistema
completamente funcional,
dentro de periodos cortos
de tiempo.

Es muy rpido


Permite trabajar en el a
varias personas a la vez

Mayor flexibilidad.


Posiblemente menos
fallas.

Posiblemente menor
costo.

Permite entregar
aplicaciones en corto
tiempo
Para proyectos grandes, el
DRA requiere recursos
humanos suficientes, para
crear el nmero correcto de
equipos DRA.

No todos los tipos de
aplicaciones son
apropiados para el DRA.


DRA no es adecuado
cuando los riesgos son
altos.

El producto pone en riesgo
la misin o la vida.


El producto no puede ser
modularizado.

Si no hay componentes ya
desarrollados no se puede
utilizar.

Personal con experiencia.


NOMBRE DEFINICIN CARACTERSTICAS VENTAJAS DESVENTAJAS








MODELO
CONCURRENTE





Permite que un
equipo de
software
represente
elementos
iterativos y
concurrentes de
cualquiera de los
modelos
Tambin llamado Ingeniera
Concurrente

Define una serie de eventos
que desencadenan transiciones
de un estado a otro para cada
una de las actividades,
acciones o tareas de ingeniera
de software.

se puede representar en forma
de esquema como una serie de
actividades tcnicas
importantes, tareas y estados
asociados a ellas.

Este modelo se utiliza a
menudo como el paradigma de
desarrollo de aplicaciones
cliente/servidor.

El modelo concurrente tiene la
capacidad de describir las
mltiples actividades del
software ocurriendo
simultneamente.

Un modelo de proceso
concurrente est dirigido por las
necesidades del usuario, las
decisiones de la gestin y los
resultados de las revisiones.
El modelo concurrente
es aplicables a todos
los tipos de desarrollo
de software y
proporciona un
panorama apropiado
al estado actual del
proyecto.

En lugar de confinar
las actividades,
acciones y tareas dela
Ing. De Software a
una secuencia de
eventos, define una
red del proceso

.
Excelente para
proyectos en los que
se conforman grupos
de trabajo
independientes.

Proporciona una
imagen exacta del
estado actual de un
proyecto.

Si no se dan las
condiciones
sealadas no es
aplicable.

Si no existen
grupos de trabajo
no se puede
trabajar en este
mtodo













Nombre del Modelo

Definicin Caractersticas Ventajas Desventajas





MODELO DE
PROTOTIPOS










Permite que todo el sistema o
alguna de sus partes se
construyan rpidamente para
comprender con facilidad y
aclarar ciertos aspectos en los
que se aseguren que el
desarrollador, usuario y cliente
estn de acuerdo en lo que se
necesita y de esta forma
minimizar el riesgo y la
incertidumbre en el desarrollo.
Se encarga del desarrollo diseos para
que estos sean analizados y prescindir de
ellos a medida que se adhieran nuevas
especificaciones.

Es ideal para medir el alcance del
producto, pero no se asegura su uso real.

Este modelo se aplica cuando un cliente
define un conjunto de objetivos generales
para el software a desarrollarse sin
delimitar los requisitos de entrada,
proceso y salida.

Se encarga principalmente de ayudar al
ingeniero de sistemas y al cliente a
entender de menor manera cual ser el
resultado de la construccin cuando los
requisitos estn satisfechos.

**El paradigma de construcciones tiene 3
pasos.

ESCUCHAR AL CLIENTE: Recoleccin
de requisitos.

CONSTRUIR Y REVISAR LA MAQUETA:
(prototipo).

El cliente prueba la maqueta (prototipo) y
lo utiliza para refinar los requisitos del
software.



Este modelo es til cuando el
cliente no identifica los requisitos
detallados.

Es til cuando el responsable del
desarrollo no esta seguro de la
eficiencia de un algoritmo, sistema
operativo o de la interface
hombre-maquina.

Ofrece un mejor enfoque cuando
el responsable del desarrollo del
software esta inseguro de la
eficacia de un algoritmo, de la
adaptacin de un sistema
operativo o la forma que debe
tomar interaccin humano-
maquina.

Reduce el riesgo de construir
productos que no satisfagan las
necesidades de los usuarios.

Nos asegura que nuestro software
sea de mejor calidad

En el desarrollo de los prototipos
es ms probable que las
especificaciones del prototipo se
acerquen ms a la realidad.

Permite a todos los involucrados
entender bien y mejor el problema
antes de la implementacin final.

Es necesario reescribir
parte del prototipo para
hacerlo funcional.

Es posible que el prototipo
sea:
Lento

Muy grande.

No muy amigable en su
uso.

Se encuentre escrito en un
lenguaje de programacin
inadecuado.

Da la impresin de que se
pierden esfuerzos en el
desarrollo de los
prototipos.

Al crear un prototipo de
forma rpida, se suelen
desatender aspectos
importantes, tales como la
calidad y el mantenimiento
a largo plazo.


NOMBRE DEFINICIN CARACTERSTICAS VENTAJAS DESVENTAJAS








MODELO
COMPONENTES





Es evolutivo por
naturaleza y
exige un
enfoque
interactivo para
la creacin del
software. Sin
embargo, el
modelo de
desarrollo
basado en
componentes
configura
aplicaciones
desde
componentes
preparados de
software
(clases).


Muestra la relacin entre
componentes de software, sus
dependencias, su comunicacin su
ubicacin y otras condiciones.
Permite reutilizar piezas de cdigo
pre elaborado que permiten
realizar diversas tareas.
Identificable: Debe tener una
identificacin que permita acceder
fcilmente a sus servicios que
permita su clasificacin.
Auto contenido: Un componente
no debe requerir de la utilizacin
de otros para finiquitar la funcin
para la cual fue diseado.
Puede ser remplazado por otro
componente: Se puede remplazar
por nuevas versiones u otro
componente que lo remplace y
mejore.
Sus servicios no varan: Las
funcionalidades ofrecidas en su
interfaz no deben variar, pero su
implementacin s.
Bien Documentado: Un
componente debe estar
correctamente documentado para
facilitar su bsqueda si se quiere
actualizar, integrar con otros,
adaptarlo, etc.
Es genrico: Sus servicios deben
servir para varias aplicaciones.
Reutilizado dinmicamente: Puede
ser cargado en tiempo de
ejecucin en una aplicacin.
Independiente de la plataforma.
Reutilizacin del
software.

Simplifica las pruebas.

Simplifica el
mantenimiento del
sistema.

Mayor calidad.

El anlisis del riesgo
se hace de forma
explcita y clara.

Une los mejores
elementos de los
restantes modelos.

Reduce riesgos del
proyecto.

Incorpora objetivos de
calidad.

Integra el desarrollo
con el mantenimiento.

Funcionalidad
mejorada.
Genera mucho tiempo en el
desarrollo del sistema.

Modelo costoso.

Requiere experiencia en la
identificacin de riesgos.

Cuando un sistema falla se pierde
tiempo y coste dentro de la empresa

Exige una cierta habilidad en los
analistas (es bastante difcil).

Genera mucho trabajo adicional.