2010

MODELO EN
CASCADA
Y MODELO EN V
Metodologías para el Desarrollo de
Proyectos Informáticos

PUBLICADO EN: http://www.calameo.com/books/000359039f05cc9907e95

MARGARITA VARGAS CHACÓN

UNEMI
30/07/2010
 ADMINISTRACIÓN DE PROYECTOS Modelo en Cascada y Modelo en V
UNIVERSIDAD ESTATAL DE MILAGRO Margarita Vargas Chacón

MODELO EN CASCADA

El modelo en cascada es una de las primeras metodologías que han sido propuestas para el desarrollo de
proyectos informáticos, establecido por Winston Royce en 1970.

El tratamiento de este proceso se considera como fluyendo constantemente hacia abajo (como una
cascada); en este modelo se debe seguir un riguroso orden de todas las etapas que conforman el ciclo de
vida de un proyecto de software Fig.1 (El Modelo de Cascada); donde cada una de las fases debe
completarse antes de iniciar la siguiente, manteniendo un estricto control sobre cada etapa. De esta manera
cuando todos los requisitos del cliente han sido detallados, analizados para comprobar su integridad y
consistencia, y documentados, recién entonces el equipo de desarrollo del proyecto puede seguir con las
actividades del diseño del sistema.

Este modelo nos muestra una visión muy clara de cómo suceden las etapas dentro de su tratamiento,
sugiriendo a los desarrolladores la secuencia de eventos que pueden encontrar en cada una de las etapas.

ETAPAS DEL MODELO:

El ciclo de vida de software está conformado por las siguientes actividades:

1. Ingeniería y Análisis del Sistema

2. Análisis de los Requisitos del Software
3. Diseño
4. Codificación
5. Prueba
6. Aplicación y Mantenimiento

Ingeniería y Análisis del Sistema.- En esta fase se realiza un análisis global de todas las necesidades de
los usuarios finales del sistema informático, para detallar los objetivos que el software desempeñara. Luego
se redacta el Documento de Especificación de Requisitos conocido también como SDR; en la
elaboración de este documento se debe plasmar los resultados del análisis en forma de contrato, con los
requisitos que la aplicación informática deberá cumplir. El SDR debe lograr tres objetivos en mente:

1. Describir lo que requiere el usuario.

2. Establecer una base para la creación de un diseño de software.
3. Definir un conjunto de requisitos que se puedan validar una vez que se ha construido el software.

Considerando previamente estos objetivos planteados, se logran establecer las bases para un buen diseño
de sistemas. También es importante señalar que en esta fase se debe consensuar todo lo que se requiere
del sistema informático, ya que esto servirá de base para las siguientes etapas, sin poder requerir nuevos
resultados a mitad del proceso de elaboración del software.

Análisis de los Requisitos del Software.- Su enfoque principalmente se centra e intensifica en detallar los
requerimientos del software, se debe comprender el ámbito de la información del software, así como por
ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Diseño.- El diseño del software se descompone y organiza el sistema en elementos que pueden elaborarse
por separado, enfocándose en estos cuatro atributos:

1. La estructura de los datos,

2. La arquitectura del software,
3. El detalle de los procedimientos y
4. La determinación de la interfaz.

Como resultado se obtiene el SDD o Documento de Diseño del Software, en el cual se describe el modelo
relacional global del sistema, la función de cada una de sus partes y así como también se adjunta la
interactividad que existe en cada una de ellas.
 ADMINISTRACIÓN DE PROYECTOS Modelo en Cascada y Modelo en V
UNIVERSIDAD ESTATAL DE MILAGRO Margarita Vargas Chacón

Logrando traducir los requisitos en una representación del software con la calidad que se requiere antes de
que se dé inicio a la etapa de la codificación; es decir que el diseño del sistema no es más que una
plataforma para la eficacia de un código de programación. La fase de diseño conduce a una salida para la
próxima fase es decir, declaraciones formales obligatorias que es la codificación.

Codificación.- Esta es la fase de la programación, en donde se implementará el código fuente dependiendo

del lenguaje de programación que se vaya a utilizar, es decir en esta etapa las especificaciones del sistema
se convierten en un lenguaje legible para la máquina y así construir el software.

Según el lenguaje de programación y la versión que se utilice se podrá hacer uso de componentes
reutilizables inmersos en el mismo proyecto que harán que el proceso de la codificación sea mucho más
rápido.

Prueba.- Este proceso consta de la elaboración de pruebas que nos sirven para comprobar si el software
cumple con todos los requerimientos que se deseaba obtener, estas pruebas o evaluaciones están
centradas netamente en la lógica del software; es decir, verificar su correcto funcionamiento, y validar todas
las respuestas que se obtengan; si están de acuerdo con lo que se quería alcanzar.

Aplicación y Mantenimiento.- Una vez terminada la fase de prueba se procede a implementar el sistema;
es decir a la utilización del software por parte del usuario. También se debe tener en cuenta que el sistema
sufrirá cambios al realizar la entrega al cliente. Los cambios sucederán debido a que el cliente haya
encontrado posibles errores, a que el sistema deberá adaptarse a distintos cambios del entorno externo, o si
el cliente desea implementar nuevas funcionalidades al sistema informático, por lo que es necesario un
realizar un mantenimiento.

VENTAJAS:

• Este modelo se basa en procesos sencillos e intuitivos fáciles de seguir a la hora de desarrollar el
sistema.
• Provee seguridad en los requerimientos.

• Es ideal para proyectos rígidos, donde se especifiquen claramente los requerimientos concretos a
utilizar y se conozca perfectamente la herramienta de aplicación.
• Es un modelo compresible para los usuarios.

DESVENTAJAS:

• Es un modelo muy rígido.

• Es muy difícil para el cliente detallar todos los requerimientos que se desea obtener del sistema, por
lo que hay un nivel muy alto de riesgos.
• En la práctica, difícilmente un proyecto sigue una estricta secuencia lineal, razón por la cual el
proyecto tiene una mala implementación.
• La etapa de creación del proyecto necesita mucho tiempo, ya que primero se debe pasar por el
proceso de prueba.
• El cliente debe ser paciente; la fase de operación se cumple a finales de las etapas del
modelo.
• Los cambios establecidos en una etapa madura del proceso pueden ocasionar confusión a
los desarrolladores del sistema, y sus consecuencias pueden ser desastrosas.

MODELO EN V

Este paradigma nace de la evolución del modelo en cascada, implementando un proceso interactivo entre
las distintas etapas que lo comprenden, donde se puede detallar la relación que existe entre las actividades
de prueba, análisis y diseño del software.
 ADMINISTRACIÓN DE PROYECTOS Modelo en Cascada y Modelo en V
UNIVERSIDAD ESTATAL DE MILAGRO Margarita Vargas Chacón

Al estudiar su proceso podemos observar que sus primeras fases son similares al método cascada,
teniendo como punto intermedio la etapa de la implementación de programas y prueba unitaria (que forma
la punta de la V, véase Figura 2. Modelo en V) y las que lo complementan son las encargadas de la
realización de pruebas e integrarse a cada una de las de la mitad anterior.

Este modelo tiene la funcionalidad de poder hacer la a documentación para las pruebas que se realizarán
posteriormente; opción que resulta muy favorable para los desarrolladores del sistema ya que así lograrán
definir precisos detalles al momento de la codificación; en otras palabras funciona igual que el mecanismo
análogo usado en clase al dar un examen, es muncho más fácil si antes de evaluar se proporciona un
cuestionario con temas similares de los que tratará la prueba.

Este mecanismo interactivo de verificación y validación en el diseño del software optimiza en un grado
considerable la capacidad e aceptar el producto resultante.

La verificación se fundamenta en demostrar si el producto se está construyendo correctamente.

La validación certifica que el producto cumple con las exigencias detalladas por el cliente.

Las pruebas que el modelo implementa son las siguientes:

Prueba unitaria y de aceptación: En esta prueba los encargados de realizar el proyecto de software
deberán asegurar que todos los requerimientos del programa han sido implementados de forma correcta en
el proceso de la codificación,

Prueba del sistema: Los desarrolladores en esta evaluación deben verificar el correcto funcionamiento del
sistema informático, certificando que todos los aspectos analizados en el código estén efectuados
correctamente.

Prueba de aceptación: En esta última prueba interviene el cliente, mas no el desarrollador; valida los
requerimientos asociando un paso de prueba con cada elemento de la especificación; con este tipo de
prueba se puede verificar si todos los requisitos se han implementado por completo, antes de que el
software será aceptado y pagado.

VENTAJAS:

• El modelo en V hace más explicita la tarea parte de la iteración de las actividades del proceso.
• Las pruebas de cada fase ayudaran a corregir posibles errores sin tener que esperar a que sean
rectificados en la etapa final del proceso.
• Con las pruebas unitarias y de integración se consigue obtener exactitud en los programas.

DESVENTAJAS:

• Al encontrarse errores luego de realizar las pruebas se pierde tiempo y dinero, ya que cada prueba
se realiza luego de haber terminado la implementación.

CONCLUSIÓN:

Los dos modelos tienen sus respectivas ventajas y desventajas al momento de implementar un proyecto de
software.

El paradigma en cascada nos ofrece un desarrollo más estable y lineal, poniendo a los procesos en
exactitud y actividad, mientras que el modelo en V es una mejora de el modelo cascada, ubicándolo en un
nivel superior, ya que nos permite interactuar con las diferentes actividades haciendo el proceso más
dinámico, y con la opción de realizar pruebas que nos ayudarán a corregir posibles errores durante su fase
de desarrollo, implementando también el rehacer tareas que están ocultas en la representación de la
cascada, ventajas realmente notables que lo convierten en un modelo más completo y robusto que nos
ayudará a obtener un sistema de mejor calidad.
 ADMINISTRACIÓN DE PROYECTOS Modelo en Cascada y Modelo en V
UNIVERSIDAD ESTATAL DE MILAGRO Margarita Vargas Chacón

ANEXOS:

Figura 1. El modelo en Cascada

Figura 2. El modelo en V
 ADMINISTRACIÓN DE PROYECTOS Modelo en Cascada y Modelo en V
UNIVERSIDAD ESTATAL DE MILAGRO Margarita Vargas Chacón

FUENTES CONSULTADAS:

SHARI LAWRENCE PFLEEGER, INGENIERÍA DE SOFTWARE TEORÍA Y PRÁCTICA

http://es.wikipedia.org/wiki/Desarrollo_en_cascada

http://www.worldlingo.com/ma/enwiki/es/Waterfall_model

http://es.wikipedia.org/wiki/Software

http://www.compute-rs.com/es/consejos-352291.htm

http://www.biblioteca.co.cr/pdf/unidad12-4.pdf

http://www.carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc

http://caraujo334.blogspot.es/1192584300/