Mtodo

Cascada
Pura

Consiste en:
Consiste en realizar
una revisin al final
de cada etapa para
determinar si est
preparado para
pasar a la siguiente
etapa. Cuando la
revisin determina
que el proyecto no
est listo pasar a la
siguiente,
permanece en la
etapa actual hasta
que est preparado.

Ventajas
1.-Se utiliza correctamente para
ciclos en los que se tiene una
deficion estable del producto.
2.-Puede constituir una eleccin
correcta para el desarrollo rpido.
3.-ayuda a minimizar los gastos de la
planificacin porque permite
realizarla sin problemas.
4.-Funciona bien
5.-Evita una fuente comn de errores
importantes.

Desventajas
1.--Dificultad para especificar claramente
los requerimientos al comienzo del
proyecto (no permite flexibilidad en los
cambios).
2.-Para un proyecto de desarrollo rpido, el
modelo de cascada puede suponer una
cantidad excesiva de documentacin.
3.-Si se intenta mantener la flexibilidad, la
actualizacin de la especificacin se puede
convertir en un trabajo a tiempo completo.
4.-No es imposible volver atrs utilizando
el modelo de cascada pura, pero si difcil.
5.-Genera pocos signos visibles de
progreso hasta el final.

Espiral

Consiste en una serie

de ciclos que se
repiten en forma de
espiral, comenzando
desde el centro o
punto de
anteproyecto. El
Espiral puede verse
como un modelo
evolutivo que
conjuga la naturaleza
iterativa del
modelo MCP con los
aspectos controlados
y sistemticos
del Modelo Cascada.

Reduce riesgos del proyecto

Incorpora objetivos de
calidad
Integra el desarrollo con el
mantenimiento.

Genera mucho tiempo en el

desarrollo del sistema

Modelo costoso

Requiere experiencia en la
identificacin de riesgos

Modelo
de
prototipo

Consiste en permitir
que todo el sistema se
construya rpidamente
para comprender con
facilidad y aclarar
ciertos aspectos

1)

Permiten el desarrollo de un

1) El usuario quiere empezar a trabajar

sistema a partir de requisitos poco

desde el primer momento con el prototipo

claros o cambiantes.

para solucionar su problema particular,

2)

Como

informacin

complementaria a los requisitos

cuando el prototipo es solo un modelo de

lo que ser el producto.

3. 2) Requiere participacin activa del

constituyen un gran apoyo a las
estimaciones de esfuerzo de todas

usuario, al menos, para evaluar el

las reas, incluyendo proveedores.

prototipo. Y mucho ms involucramiento si

3) Son ms fciles de abordar con

queremos que participe en su creacin.

los usuarios finales.

4) Se

reduce

incertidumbre

el

riesgo

sobre

4.

3) Una desventaja importante a tener en

la

cuenta es la falta de experiencia que tienen

la

muchos Analistas Funcionales en

implementacin del software.

programacin y en actividades de diseo

de interfaces de usuario.

Mtodo
de
Codificar
y
Corregir

Es un modelo poco til,

pero sin embargo
bastante comn Se
puede tener una
especificacin formal,
o no tenerla Si no se ha
utilizado formalmente
un mtodo,
probablemente ya se
est usando el mtodo
Codificar y Corregir en
forma intuitiva Cuando
se utiliza ste mtodo
se empieza con una
idea general de lo que
se necesita construir,
Se utiliza cualquier
combinacin de
diseo, cdigo,
depuracin y mtodos
de prueba no formales
que sirven hasta que se
tiene el producto listo
para entregarlo.

1) No conlleva ninguna gestin;

no se pierde tiempo en la
planificacin, en la
documentacin, en el control de
calidad, en el cumplimiento de
los estndares, o en cualquier
otra actividad que no sea
codificacin pura.
2) Como se pasa directamente a
codificar, se pueden mostrar
inmediatamente indicios de
progreso.
3) Requiere poca experiencia:
cualquier persona que haya
escrito alguna vez un programa
est familiarizada con ste
modelo.
4) Para proyectos pequeos que
se intentan liquidar en un tiempo
breve, o para modelos como
programas de demostracin o
prototipos desechables, el
modelo codificar y corregir puede
ser til.

1) El modelo resulta peligroso para otro

tipo de proyectos que no sean pequeos.
Puede que no suponga gestin alguna,
pero tampoco ofrece medios de evaluacin
del progreso.
2) No proporciona medios de evaluacin
de la calidad o de identificacin de riesgos.
Si al llevar tres cuartas partes de la
codificacin descubre que el diseo es
incorrecto, no hay otra solucin que
desechar el trabajo y comenzar de nuevo.

Diseo y
Anlisis
estructurado

El Anlisis
Estructurado (SA)
en ingeniera
de

software y su tcnica
aliada, Diseo
estructurado (SD),
son mtodos para
analizar
y
convertir requisito
(sistemas) de negocio
dentro
de
especificaciones y en
ltima
instancia, Programa
informtico,
configuraciones de
hardware
y

procedimientos
manuales
relacionados.

completar una fase antes de

Entregar el sistema para los

comenzar la prxima, ocasionando

usuarios a tiempo: puesto que

a algunos proyectos lo que se

La puntualidad depende de dos

cosas buena planificacin, y
buena gestin y control.
Proporcionar sistemas que
responden a los cambios en el
entorno empresarial: asegura
que el proyecto est enfocado
en lo que la empresa requiere.
Fomentar un uso ms eficaz y
econmico de los conocimientos
disponibles: el SSADM utiliza la
habilidad ms fcil de adquirir
en un mercado amplio, se apoya
en el modelado de flujo de
datos, el modelado de datos
lgicos, entre otros.

En el enfoque SSADM se tiene que

conoce como "parlisis de anlisis".

En resumen, utilizar esta

metodologa implica un
compromiso significativo que puede
no ser adecuado para todos los
proyectos.