El documento describe el modelo en cascada y el modelo en V para el desarrollo de software. Explica que el modelo en cascada sigue un enfoque secuencial de análisis de requisitos, diseño, codificación, prueba y mantenimiento. El modelo en V añade las fases de verificación y validación y muestra la relación entre las fases de desarrollo y prueba asociadas. Ambos modelos tienen ventajas como una metodología bien definida, pero también desventajas como la dificultad de cambiar requisitos tarde en

1. UNIVERSIDAD ESTATAL DE MILAGRO
Facultad Ciencias de la Ingeniería
TEMA:
Modelo en cascada y modelo en V
DOCENTE
Ing. Richard Ramírez
RESPONSABLE:
Ángel Novillo
PERIODO LECTIVO:
2010 - 2011

2. Indice General
Introducción……………………………………………………………………………………………………………..3
Modelo en Cascada.….…………………………………………………………….….………………………………4
Ingeniería y Análisis del sistema…………………………………………………….….…………………………….4
Análisis de los requisitos del software……………….………………………….….………………………………..4
Diseño………………...……………………………………………………………….………………………………...4
Codificación…………………………………………………………………………….……………………………….4
Prueba………………………………………………………...…………………………………………………………4
Mantenimiento………………………………………………………………………………………………………….4
Problemas…………………………….………………………………………………………………………………...4
Ventajas y desventajas………………………………………………………………………………………………..5
Relación con modelo V………………………………………………………………………………………………..5
Verificación……………………………………………………………………………………………………………..6
Validación……………………………………………………………………………………………………………….6
Desventajas…………………………………………………………………………………………………………….6
Conclusión………………………………………………………………………………………………………………7
Bibliografía………………………………………………………………………………………………………………8
2

3. Introducción
El modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida
del software, de tal forma que el inicio de c3ada etapa debe esperar a la finalización de la inmediatamente
anterior.
El modelo en cascada puede ser aplicado para las necesidades específicas de una organización. Si bien
modelos de desarrollo, como el cascada uno de los más antiguos, es útil para que el desarrollador
visualice lo que va hacer, han dado como resultado la aparición de nuevas técnicas más desarrolladas.
Un ejemplo de una metodología de desarrollo en cascada es:
Análisis de requisitos
Diseño del Sistema
Diseño del Programa
Codificación
Pruebas
Implantación
Mantenimiento
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 costes 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.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma
más seguido al día de hoy.
V-modelo es un proceso del desarrollo del software cuál se puede presumir para ser la extensión del
modelo de la cascada. En vez de la mudanza abajo de una manera linear, los pasos de proceso están
doblados hacia arriba después de codificación fase, formar la forma de V típica. El V-Modelo demuestra las
relaciones entre cada fase del ciclo vital del desarrollo y su fase asociada de prueba
3

4. Modelo en Cascada
El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida
abarca las siguientes actividades:
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
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 (Analistas) 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. El proceso de diseño
traduce los requisitos en una representación del software con la calidad requerida antes de que comience
la codificación.
Codificación:
El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea.
Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.
Prueba: una vez que se ha generado el código comienza la prueba del programa. 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.
Problemas:
No siempre se sigue el flujo secuencial.
Es difícil tener un 100% de los requisitos al inicio.
El cliente debe tener paciencia. Los primeros resultados serán hasta que ya este operando el
sistema.
4

5. Ventajas
Etapas y actividades están bien definidas para facilitar la comprensión
Auto de motivos de usuario
Es también ayudan en la planificación y las jornadas cuando se someten a los proyectos
Claridad de los objetivos del proyecto.
Estable requisitos del proyecto.
El progreso del sistema se puede medir.
Desventajas
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay
iteraciones y se crean problemas en la aplicación del paradigma.
Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El
ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que
pueden existir al comienzo de muchos productos.
El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible
una versión operativa del programa. Un error importante no detectado hasta que el programa este
funcionando puede ser desastroso.
La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la
hora de desarrollar el software.
Relación con el Modelo V
El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución
del mismo.
Los planes de prueba son OPERACION
el nexo entre el desarrollo Y MANTENIMIENTO
y la verificación
ANALISIS DE Plan de
Pruebas PRUEBA DE
REQUERIMIENTOS
de Aceptación ACEPTACION
Validar requerimientos
Plan de
DISEÑO DEL Pruebas PRUEBA DEL
SISTEMA del Sistema SISTEMA
Verificar diseño
DISEÑO Plan de PRUEBA DE
DETALLADO Pruebas INTEGRACION
de Integración
IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA UNITARIA
Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad
hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior.
5

6. Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que
este modelo involucra chequeos de cada una de las etapas del modelo de cascada.
Este modelo es una versión mejorada del modelo cascada, incorpora o se enfoca, de mejor manera al
control de calidad, este modelo también muestra la relación iterativa entre las distintas fases en el proceso
de desarrollo de software y añade dos partes que son:
La Verificación:
Que tiene relación con la pregunta ¿Se está haciendo correctamente el producto?
La Validación:
Que tiene relación con la pregunta ¿Se está haciendo el producto , es decir, la demostración de que el
software cumple con exactitud la finalidad pretendida.
En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relación entre
ellas.
Desventajas:
El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final
de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación,
lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y
dinero.
El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que
en la realidad puede ocurrir.
Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo
que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el
Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.
6

7. Conclusión
El Método-V fue desarrollado para regular el proceso de desarrollo de software por la Administración
Federal Alemana. Describe las actividades y los resultados que se producen durante el desarrollo del
software.
Proporciona una guía para la planificación y realización de proyectos. Los siguientes objetivos están
destinados a ser alcanzados durante la ejecución del proyecto:
Minimización de los riesgos del proyecto: Mejora la transparencia del proyecto y control del proyecto,
especificando los enfoques estandarizados, describe los resultados correspondientes y funciones de
responsabilidad. Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de
procesos, reduciendo así los riesgos del proyecto.
Mejoramiento y Garantía de Calidad: Como un modelo de proceso estándar, asegura que los resultados
que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales
definidos se puede comprobar en una fase temprana. La uniformidad en el contenido del producto mejora
la legibilidad, comprensibilidad y verificabilidad.
Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida: El esfuerzo para el
desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y control
de manera transparente mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la
dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.
Fase de la verificación
Análisis de requisitos
En esta fase, los requisitos del sistema propuesto son recogidos analizando las necesidades de los
usuarios. Se refiere sobre establecer lo que tiene que realizarse el sistema ideal. Sin embargo, no se
determina cómo el software será diseñado o construido. Generalmente, se entrevistan con los usuarios y
un documento llamado el documento de las exigencias del consumidor se genera. El documento de las
exigencias del consumidor describirá típicamente el sistema funcional, físico, el interfaz, el funcionamiento,
los datos, los requisitos etc de la seguridad según lo esperado por el usuario
Fases de la validación
Prueba de la unidad
En el V-modelo del desarrollo del software, la prueba de la unidad implica la primera etapa de prueba
dinámica proceso. Según experto del desarrollo del software Barry Boehm, una avería descubierta y
corregida en la fase de prueba de la unidad es más que cientos veces más barato que si se hace después
de entrega al cliente.
7

8. Bibliografía
http://eproano334.blogspot.es/tags/Modelo/
http://www.compute-rs.com/es/consejos-352291.htm
http://es.wikipedia.org/wiki/M%C3%A9todo_en_V
8