MODELO CARACTERISTICAS
CASCADA • Es el más utilizado.
• Es una visión del proceso de
desarrollo de software como
una sucesión de etapas que
produce productos
intermedios.
• Si se cambia el orden de las
fases, el producto final será de
inferior calidad.
ESPIRAL • En cada giro se construye un
nuevo modelo del sistema
completo.
• Es el mejor modelo para el
desarrollo de grandes
sistemas.
• Este modelo puede
combinarse con otros modelos
de proceso de desarrollo.
INCREMENTAL • Se evitan proyectos largos y se
entrega “algo de valor” a los
usuarios con cierta frecuencia.
• Difícil de evaluar el costo.
• El resultado puede ser muy
positivo.
BASADO EN COMPONENTES • Se basa en la reutilización de
software existente.
• Este modelo nos permite
reutilizar partes de código pre
elaborado.
PROCESO DE DESARROLLO UNIFICADO •Permite el desarrollo de software a
gran escala mediante un proceso
continuo de pruebas y
retroalimentación.
RAD •Tiempo de creación rápido.
•Equipos Híbridos.
•Herramientas Especializadas.
•"Timeboxing“.
•Prototipos Iterativos y Evolucionarios
CONCURRENTE •Todos trabajan al mismo tiempo.
•Las actividades llevan procesos
concurrentes.
•Es aplicable a todo tipo de desarrollo
de software.
•Es un módulo aplicable para cliente
soñador.
•Está dirigido por las necesidades del
usuario.
•Es aplicable al cliente servidor.
RUMBAUGH •Es un modelo dinámico.
BOOCH •Es orientado a objetos.
VENTAJAS
• Se tiene todo bien organizado
y no se mezclan las fases.
• La planificación es sencilla.
• La calidad del producto
resultante es alta.
• El modelo en espiral permite a
quien desarrolla aplicar el
enfoque de construcción de
prototipos en cualquier etapa
de evolución del producto.
• Con un paradigma incremental
se reduce el tiempo de
desarrollo inicial, ya que se
implementa la funcionalidad
parcial.
• También provee un impacto
ventajoso frente al cliente, que
es la entrega temprana de
partes operativas del software.
• Se ahorra tiempo en desarrollo
del software y ahorra dinero.
• Simplifica las pruebas. Permite
que las pruebas sean
ejecutadas probando cada uno
de los componentes antes de
probar el conjunto completo
de componentes ensamblados.
•Junto a UML constituye la
metodología estándar más utilizada
para análisis, diseño, implementación y
documentación de sistemas orientados
a objetos.
•Comprueba y ahorra dinero en
comparación con construir.
•Visibilidad temprana.
•Mayor involucramiento de los
usuarios.
•Posiblemente menos fallas.
•Posiblemente menor costo.
•Ciclos de desarrollo más pequeños
•Eficiencia en tiempo
•Excelente para proyectos en los que
se conforman grupos de trabajo
independientes.
•Proporciona una imagen exacta del
estado actual de un proyecto.
•Se muestra al cliente una estructura
antes de su creación y se comunica con
él para reducir la complejidad del
sistema.
•Ayuda a diseñar los sistemas usando
paradigma orientado a objetos.
DESVENTAJAS
• Se tarda mucho tiempo en
pasar por todo el ciclo.
• Es difícil incorporar nuevas
cosas si se quiere actualizar.
• Iteraciones costosas.
• Tiene una elevada
complejidad.
• Es un modelo costoso.
• Genera mucho tiempo en el
desarrollo del sistema.
• Requiere de mucha
planeación, tanto
administrativa como técnica.
• Requiere de metas claras para
conocer el estado del
proyecto.
•Las actualizaciones de los
componentes adquiridos no están en
manos de los desarrolladores del
sistema.
•Por el grado de complejidad puede
ser no muy adecuado para proyectos
pequeños.
•Menos eficiente.
•Progreso más difícil de medir.
•Menos eficiente.
•Menor precisión científica.
•Riesgo de revertirse a las prácticas
sin control de antaño.
• Más fallas (por síndrome de
"codificar a lo bestia").
•Prototipos pueden no escalar, un
problema mayúsculo.
•Si no se dan las condiciones señaladas
no es aplicable.
•Si no existen grupos de trabajo no se
puede trabajar en este método.
•No es útil en la práctica.
•Se necesita experiencia para manejar
esta metodología.