Universidad Regional Autónoma de los Andes
“UNIANDES”
Facultad: Sistemas Mercantiles
Carrera: Sistemas
Materia: Desarrollo de Proyectos informáticos
Docente: Ing. Julieta Campi M.
Alumno: Jonathan Cevallos G.
Nivel: 6 Semestre

Modelo Cascada
En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el
enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa
anterior.
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce
necesariamente al rediseño y nueva programación del código afectado, aumentando los costos
del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el
esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.
● Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un
sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos
del sistema y luego asignando algún subconjunto de estos requisitos al software.
● Análisis de los requisitos del software: El proceso de recopilación de los requisitos se
centra e intensifica especialmente en el software. El ingeniero de software debe
comprender el ámbito de la información del software, así como la función, el rendimiento
y las interfaces requeridas.
● Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz.
● Codificación: el diseño debe traducirse en una forma legible para la máquina. El paso de
codificación realiza esta tarea.

● Prueba: La prueba se centra en la lógica interna del software, y en las funciones
externas, realizando pruebas que aseguren que la entrada definida produce los
resultados que realmente se requieren.
● Mantenimiento: El software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debido a que hayan encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o
debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
Modelo Espiral
El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso
de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los
aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el
potencial para el desarrollo rápido de versiones incrementales del software que no se basa en
fases claramente definidas y separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un
prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del
sistema diseñado.
EL modelo en espiral se divide en un número de actividades de marco de trabajo, también
llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un
conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las
características del proyecto que va a emprenderse en todos los casos se aplican actividades de
protección.
Tipos
El modelo espiral tuvo varias modificaciones que son:
● Modelo Original de Boehm.
● Modelo Tipico de Seis Regiones.
● Modelo WINWIN.
Modelo original BOEHM
No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión
de proyecto.

Cada vuelta se divide en 4 sectores:
● Planificación : determinación de los objetivos, alternativas y restricciones
● Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
● Ingeniería : desarrollo del producto hasta "el siguiente nivel".
● Evaluación : valoración por parte del cliente de los resultados obtenidos.
El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada
vez se van construyendo versiones sucesivas del software, cada vez más completas.
Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a
las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del
cliente de los resultados del software.
Modelo Típico de seis regiones
A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el
modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora. Una visión alternativa del modelo en espiral puede ser considerada examinando el
eje de punto de entrada en el proyecto.
Las regiones de tareas que componen este modelo son:
● Comunicación con el cliente: las tareas requeridas para establecer comunicación entre
el desarrollador y el cliente.

● Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
● Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.
● Ingeniería: las tareas requeridas para construir una o más representaciones de la
aplicación.
● Construcción y adaptación: las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.
● Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la
evaluación de las representaciones del software creadas durante la etapa de ingeniería e
implementación durante la etapa de instalación.
Modelo WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al
principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación
con el cliente se definen las siguientes actividades:
● Identificación del sistema o subsistemas clave de los directivos.
● Determinación de las condiciones de victoria de los directivos.

● Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto
de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que
ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de
decisión antes de continuar el proyecto de software.
Ventajas
● El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
● Como el software evoluciona a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele
evolutivos.
● El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
● El modelo en espiral demanda una consideración directa de los riesgos técnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos
antes de que se conviertan en problemas.
● En la utilización de grandes sistemas a doblado la productividad.
Desventajas
● Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
● Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
● Genera mucho tiempo en el desarrollo del sistema.

● Modelo costoso.
● Requiere experiencia en la identificación de riesgos.
Modelo Prototipo
El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El
prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar
muchos recursos.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para
el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por
el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se
desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente.
Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea
resultados a corto plazo.
Ventajas
● Este modelo es útil cuando el cliente conoce los objetivos generales para el software,
pero no identifica los requisitos detallados de entrada, procesamiento o salida.

● También ofrece un mejor enfoque cuando el responsable del desarrollo del software está
inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de
la forma que debería tomar la interacción humano­máquina.
Desventajas
● El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema
final.
● A causa de la intención de crear un prototipo de forma rápida, se suelen desatender
aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que
obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha
cumplido su función.
● Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se
construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo
de un estado poco recomendado.
Modelo Orientado a hitos
Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto.

Ventajas
El cliente va viendo los resultados.
Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor
prioridad con esta técnica.
Desventajas
Se analiza todo el sistema al principio, y se puede perder mucho tiempo en la especificación y
diseño de funcionalidades que al final no nos da tiempo a implementar.
Modelo de Transformación (Evolutivo)
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va
refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del
usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de
separarse.
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del
sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos
propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es
comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los
requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos
del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas
en comparación con un enfoque en cascada ya que el sistema se va ajustando a las
necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin
embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos
grandes problemas:
1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir
el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos
que reflejen cada versión del sistema.

2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a
corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en
una tarea difícil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas
pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo
dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que
puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo
mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.
Modelo Mixto
El modelo de desarrollo mixto combina dos o más modelos de desarrollo de software. Entre
estos modelos tenemos el modelo incremental.
El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y
del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”,
que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del
proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están
orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el
sistema en su versión final.