CUADRO COMPARATIVO DE LAS METODOLOGÍAS EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN

METODOLOGÍAS

PROPUESTA POR

CARACTERISTICAS

VENTAJAS

DESVENTAJAS

FASES

MODELO EN CASCADA PURO

Winston Royce en el año 1970

• Es un proceso de desarrollo secuencial, el desarrollo se ve fluyendo hacia abajo(como una cascada)
• Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente
• Modelo rígido, poco flexible y con muchas restricciones
• Fue uno de los primeros y sirvió de base para los demás modelos de ciclo de vida
• Ciclo de vida clásico

• Planificación sencilla
• Producto de calidad sin necesidad de un personal altamente calificado
• Apropiado para proyectos estables

(especialmente para proyectos con requisitos no cambiantes)

• Funciona bien en proyectos pequeños
• Simple y fácil de usar
• No se mezclan las fases y está bien organizado

• No cuenta con todos los requerimientos al comienzo del proyecto y si han cometido errores y no se detectan en la etapa inmediata es muy costoso volver atrás para realizar las correcciones
• Los resultados no son visibles progresivamente, el producto se ve cuando ya está finalizado (inseguridad en el cliente)

1. Especificaciones de requisitos
2. Diseño
3. Construcción (Codificación)
4. Integración
5. Pruebas
6. Instalación
7. Mantenimiento

MODELO SASHIMI

Peter DeGrace

• Tiene fases solapadas, como el pescado japonés
• Es una modificación del cascada puro por eso a veces hace referencia como el modelo en cascada con retroalimentación

• Se pueden actuar durante las ventajas anteriores

• No es muy adecuado para proyectos bien estructurados

MODELO ITERATIVO

-Modelo derivado del ciclo de vida en cascada

-Consiste en la iteración de varios ciclos de vida en cascada

-El cliente es quien evalúa el producto y lo corrige o propone a mejoras

-Busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa recogida de requisitos

-Se suelen utilizar en proyectos donde los requisitos no están claros por parte del usuario

-Ciertos problemas relacionados con la arquitectura debido a no tener los requisitos definidos desde el principio

MODELO ESPIRAL

Barry Boehm en 1985

-Consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro.

-Evaluar riesgos

-Las actividades se conforman en un espiral, cada bucle representa un conjunto de actividades

-Comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos más asumibles y se hace un ciclo de espiral. Esto se da hasta que el proyecto sea aceptado y no necesite mejoras.

-Está pensado para proyectos largos, caros y complicados

-Reduce riesgos del proyecto

-Incorpora objetivos de calidad

-Integra el desarrollo con el mantenimiento

-No es rígido ni estático

-Genera mucho trabajo adicional

-Al ser el análisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos.

-Es un modelo costoso y no funciona bien para proyectos pequeños.

1. Determinar o fijar objetivos
2. Análisis de riesgos
3. Desarrollar, verificar y validar
4. Planificar

MODELO DE PROTOTIPOS

-Comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software entonces aparece un diseño rápido  

-Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer prototipo

-Permite introducir cambios en la iteraciones siguientes del ciclo

-Se hacen fuertes inversiones en un producto desechable ya que los prototipos se descartan

MODELO RAD

James Martin en 1980

-Rápido desarrollo de aplicaciones

-Responde a las necesidades de entregar sistemas muy rápidos

-Comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE

-Velocidad de desarrollo

-Ciclos de desarrollo más cortos

-Mayor flexibilidad que otros modelos

-No es apropiado para todos los proyectos

MODELO ORIENTADO A OBJETOS

-Presentada en la década del 70

-Cada funcionalidad o requerimiento solicitado por el usuario es considerado un objeto

-Los objetos son representados en atributos y métodos

-Característica principal es la abstracción de los requerimientos

-Es mucho más flexible que los demás modelos

-La abstracción es lo que nos permite analizar y desarrollar las características esenciales de un objeto

-Favorece la reducción de la complejidad del problema que deseamos abordar y permite el perfeccionamiento del producto

MODELO XP

-Programación extrema

-Coloca al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente

-Se aplica de manera dinámica durante el ciclo de vida del software

-Es capaz de adaptarse a los cambios de requisitos

-Programación organizada

-Menor taza de errores

-Satisfacción del programador

-Es recomendable emplearlo solo en proyectos a corto plazo

-Altas comisiones en caso de fallar

1. Exploración
2. Planificación de la entrega
3. Iteraciones
4. Producción
5. Mantenimiento