INSTITUTO POLITECNICO NACIONAL

Unidad interdisciplinaria de Ingeniera y Ciencias Sociales y

Administrativas

Metodologa: Cascada

Integrantes:

Dominguez Vazquez Samuel Ernesto

Lpez Martnez Roberto
Pinzon guila Zared
Rodrguez Lpez Salvador

Coordinador

Dominguez Vazquez Samuel Ernesto

Fecha: 16 de Febrero del 2017

1
Introduccin

Nadie puede negar la importancia de la computacin en nuestra vida, especialmente durante

estos tiempos. De hecho, la computacin se ha convertido en algo indispensable en nuestro
da a da y es usada en muchos mbitos tales como industria, medicina, educacin e incluso
agricultura. Hoy en da, las organizaciones se han vuelto ms dependientes de las
computadoras en sus trabajos, se ahorra tiempo, ayuda en la ejecucin de procesos
complejos, y la automatizacin de los mismos hace todo ms fcil. Adems, las personas no
solo usan las computadoras para trabajar, sino que tambin divertirse y entretenerse. El
nmero de compaas que producen software ha incrementado notablemente y lo hacen con
el propsito de facilitar trabajos de oficina, administracin, bancos, etc. El incremento en el
desarrollo de software tiene como resultado la necesidad de crear procedimientos para la
ingeniera de software cuyo objetivo es crear un trabajo adecuado que construya programas
de alta calidad.

El uso de metodologas/modelos tradicionales y giles para el desarrollo de software no son

aplicables en todos los proyectos, adems, de que se tiene que invertir tiempo, dinero y
esfuerzo en cada una de las reas de las empresas desarrolladoras de software. Siguen
existiendo desventajas en el uso de las distintas metodologas debido a un uso inadecuado
de ellas en el desarrollo de software. En muchos casos llega a suceder que el recurso
humano que se encuentra inmerso en los proyectos de desarrollo termina trabajando para la
metodologa, realizando un sinnmero de actividades y de formatos en lugar de que la
metodologa facilite las actividades que se deben de desarrollar para el proyecto.

Por ello lo que se propone en este trabajo es, dada recopilacin de informacin obtenida de
distintos lugares a cerca de lo que al tema de metodologa cascada se refiere, abordaremos
los puntos ms relevantes para la comprensin de este.

2
 ndice

Antecedentes....4

Creador..4

Contextualizacin.5

Estructura..6

Ventajas.9

Desventajas.10

Evolucin..10

Prospectiva..12

Conclusin13

Bibliografa14

3
Antecedentes

El origen del trmino cascada se cita a menudo para ser un artculo publicado en 1970 por
Winston W. Royce (1929-1995), aunque Royce no utiliz el trmino cascada en este
artculo. Irnico, Royce presentaba este modelo como ejemplo de un modelo daado, non-
working (Royce 1970).

En 1970 Royce propuso lo que actualmente se conoce como el modelo de cascada como un
concepto inicial, un modelo que segn l era defectuoso (Royce, 1970). Su trabajo explora
cmo el modelo inicial podra ser convertido en un modelo interactivo, con comentarios de
cada fase de influir en las fases posteriores. Es slo el modelo inicial que recibi la
notificacin, su propia crtica de este modelo inicial se ha ignorado en gran medida. La
expresin "modelo de cascada" rpidamente lleg a referirse no a la final de Royce, el diseo
interactivo, sino ms bien a su modelo puramente un orden secuencial.

El nombre de cascada se lo pusieron en 1976, Thomas y Thayer, en el artculo Software

Requirements: Are They Really A Problem?.

Creador

Como anteriormente se mencion Winston W. Royce fue el

creador de la metodologa cascada.

Winston W. Royce (1929 7 de junio de 1995) fue un comput

logo Americano, director en el Centro de Tecnologa de Software
Lockheed en Austin, Texas. Fue un pionero en el campo de
ingeniera de software, conocido por su papel en 1970 el cual el
modelo en cascada de ingeniera de software se extrajo por error.

4
Contextualizacin

En los comienzos de la informtica el software era considerado como algo extra a la

programacin, normalmente cuando se creaba un software quien lo creaba era porque lo
necesitaba y normalmente era el mismo quien le daba mantenimiento, adems de que haba
muy poca difusin. A mediados del siglo XX con el avance en el desarrollo de sistemas de
software empezaron a surgir varios problemas como: Retrasos considerables en la
planificacin de los proyectos, poca productividad, elevadas cargas de mantenimiento, la
demanda empez a subir de manera crtica comparada con la oferta, la baja calidad del
software era un problema cada vez mayor, a esto se le llamo Crisis del Software. Un
problema que vino surgiendo desde 1945.

Desde 1945 hasta 1955 programar no era una tarea diferenciada del diseo de una mquina
y se empezaron a usar el lenguaje mquina y ensamblador. Desde 1955 hasta 1965 se
comienzan a crear varios lenguajes de programacin con los cuales se da un gran paso en el
desarrollo de software.

En la dcada de los 60s cuando se comienza a ver al software como un producto y

comienzan a surgir empresas dedicadas a la creacin y distribucin del mismo.

Y es en 1965 cuando comienza una crisis dentro del desarrollo de software ya que hay el
desarrollo de grandes programas tiende a ser inacabable, principalmente por la falta de
eficacia, ineficiencia a la hora de programar, muchos errores e incluso el coste de los
programas se vuelve impredecible.

Lo anterior fue originado por una falta de organizacin y formalismo y en otras palabras de
una metodologa a la hora de crear el software.

En los aos 70s los sistemas informticos aumentaron mucho su complejidad y nacen las
redes de ordenadores, lo cual puso mucha presin a los desarrolladores por lo que cada vez
era ms necesario crear modelos de desarrollo para el software que permitieran asegurar el
xito de los proyectos.

5
Y as es como en 1970 Winston W. Royce propone la primera versin del modelo de cascada
como primer modelo de proceso introducido para mejorar la calidad y reducir los costos del
desarrollo de software, su filosofa es completar los pasos con un alto grado de exactitud
antes de pasar al siguiente, adems, de que emplea establece los requerimientos antes de
iniciar el programa.

Durante los aos siguientes este modelo se convertira en el ms usado por los ingenieros de
software.

Estructura

Figura 1.1 Modelo de Cascada

Roger S.Pressman [2002],Ingeniera de Software un enfoque prctico New York [Consulta: 11 de febrero 2017] McGraw-Hill

Tambin llamado modelo en cascada (denominado as por la posicin de las fases en el

desarrollo de esta, que parecen caer en cascada por gravedad hacia las siguientes fases).

Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando
el trabajo desde la comunicacin hasta el despliegue fluye en forma razonablemente lineal.
Esta situacin se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras
bien definidas a un sistema ya existente (por ejemplo, una adaptacin para software de
contabilidad que es obligatorio hacer debido a cambios en las regulaciones
gubernamentales). Tambin ocurre en cierto nmero limitado de nuevos esfuerzos de
desarrollo, pero slo cuando los requerimientos estn bien definidos y tienen una estabilidad
razonable.

6
Caractersticas:

Es el primer modelo de proceso de desarrollo de software que se public y sirve como

base para otras metodologas.
Se enfoca en una sola fase en la que todos los flujos de trabajo se ejecutan en forma
secuencial y la siguiente fase no debe empezar hasta que la fase previa haya
finalizado.
El resultado de cada fase es uno o ms documentos aprobados.
Es el modelo ms simple conocido
El resultado solo se ve al final. Si existe algn error esto tiene un resultado
catastrfico.

El modelo de la cascada, a veces llamado ciclo de vida clsico, sugiere un enfoque

sistemtico y secuencial para el desarrollo del software, que comienza con la especificacin
de los requerimientos por parte del cliente y avanza a travs de planeacin, modelado,
construccin y despliegue, para concluir con el apoyo del software terminado (vase la
figura).

Analicemos las fases de manera especfica:

Comunicacin (inicio del proyecto y recopilacin de los requerimientos).

El trabajo comienza estableciendo los requisitos de todos los elementos del sistema, el
proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software.
El ingeniero de software (Analistas) debe comprender el mbito de la informacin del
software, as como la funcin, el rendimiento y las interfaces requeridas

Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los
usuarios. Entonces, se definen en detalle y sirven como una especificacin del sistema.

Se analizan las necesidades de los usuarios finales del software para determinar qu
objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de
Especificacin de Requisitos), que contiene la especificacin completa de lo que debe hacer
el sistema sin entrar en detalles internos (debe comprender el mbito de la informacin del
software, as como la funcin, el rendimiento y las interfaces requeridas)

7
Planeacin (estimacin, programacin y seguimiento):

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el

anlisis de los requisitos. Los clientes suelen tener una idea ms bien abstracta del resultado
final, pero no sobre las funciones que debera cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del
mbito del desarrollo esto es, identificar las responsabilidades especficas y explicitas de las
personas que van a trabajar en el proyecto, es decir se asignan roles.

En esta fase adems de definir roles tambin da una estimacin del tiempo que se va dar a
cada proceso para as tener un control y no perder el tiempo.

Modelado (anlisis y diseo):

Descompone y organiza el sistema en elementos que puedan elaborarse por separado,

aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD
(Documento de Diseo del Software), que contiene la descripcin de la estructura relacional
global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como
la manera en que se combinan unas con otras.

El diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de
los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la
interfaz.

Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El

primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase
de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones
que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin
elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para
comenzar la implementacin.

Construccin (cdigo y pruebas):

El diseo debe traducirse en una forma legible para la mquina. El paso de codificacin
realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede
realizarse mecnicamente.

8
El software diseado segn el algoritmo tiene que ir a travs de pruebas de software
constante y procesos de correccin de errores para saber si hay alguna falla o error. La
salida de esta etapa debe ser un programa bien diseado que est a la par con el algoritmo
diseado.

Despliegue (entrega, soporte y retroalimentacin):

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya
realizaron exhaustivas pruebas para comprobar que el sistema no falle.

Por lo general (aunque no necesariamente), sta es la fase ms larga del ciclo de vida. El
sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica corregir
errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementacin
de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren
nuevos requerimientos.

Ventajas

Es un modelo sencillo
Es un modelo lineal y, por supuesto, los modelos lineales son las ms simples a ser
implementadas.
Es fcil aprender a utilizarlo y comprender su funcionamiento
La cantidad de recursos necesarios para implementar este modelo es mnima.
La documentacin se produce en cada etapa del desarrollo del modelo de cascada.
Esto hace que la comprensin del producto disear procedimiento ms sencillo.
Es perfecto cuando se tienen grandes equipos de trabajo con roles bien definidos y
adems donde se especifiquen muy bien los requerimientos y se conozca muy bien la
herramienta a utilizar.
Despus de cada etapa importante de la codificacin de software, las pruebas se
realizan para comprobar el correcto funcionamiento del cdigo.

9
Desventajas

Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo.
Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como
resultado, los cambios generan confusin conforme el equipo del proyecto avanza.
Su principal problema es su inflexibilidad, al dividir el proyecto en etapas secuenciales.
En la prctica, estas etapas se superponen y proporcionan informacin a las otras. Por
ejemplo, durante el diseo es posible identificar problemas con los requerimientos. El
ciclo de vida del software no es un modelo lineal simple.
Normalmente, es difcil para el cliente establecer explcitamente al principio todos los
requerimientos El modelo de la cascada necesita que se haga y tiene dificultades para
aceptar la incertidumbre natural que existe al principio de muchos proyectos.
El cliente debe tener paciencia. No se dispondr de una versin funcional del (de los)
programa (s) hasta que el proyecto est muy avanzado. Un error importante no
detectado hasta que el programa est funcionando puede ser desastroso

Evolucin

La metodologa en cascada se comenz a desarrollar a partir de 1966 y fue publicada en

1970 por Winston Royce, fue el primer modelo publicado sobre el proceso de desarrollo de
software y se deriv a partir de procesos ms generales de teoras de sistemas.

Se bas en un enfoque sistemtico y secuencial para el desarrollo de software, se define

como una secuencia de fases que en la etapa final rene la documentacin necesaria para
garantizar que cumple con las especificaciones y requisitos antes de pasar a la siguiente
fase.

Para ese entonces los programadores comienzan a notar los principales fallos del sistema.
Se dan cuenta de que el proceso de desarrollo de software no es lineal si no que se necesita
retroalimentacin de una fase a otra del proyecto y por otra parte se empiezan a detectar
errores y omisiones en los requerimientos originales, surgen errores de programa y diseo y
se detecta la necesidad de nueva funcionalidad, por lo que se detecta su principal problema
de ser muy inflexible entre distintas etapas del proceso, por lo que la evolucin del sistema
se vea muy necesaria.

10
Modelo en Cascada mejorado

El modelo en cascada mejorado consiste en la introduccin de una revisin y vuelta atrs en

cada fase del proceso, con el fin de corregir las deficiencias detectadas durante las distintas
etapas o para completar o aumentar las funcionalidades del sistema en desarrollo.

Figura 1.2 Modelo de Cascada

Carolina Zibert, Ciclos de vida de Ingeniera de Software [En lnea], Caracas Venezuela [Consulta: Abril
de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>

Modelo en V

Posteriormente surgira el modelo en V, propuesto por Alan Davis que fue desarrollado para
terminar con los problemas que presentaba el modelo en cascada tradicional ya que los
defectos no se encontraban a tiempo debido a que las pruebas se hacan al final del proceso.

El modelo en V permiti hacer ms explcita la tarea de la iteracin de las actividades del

proceso, ya que aadi pruebas al final de cada fase, sin tener que esperar a la fase final del
proceso lo que permiti que los programas fueran an ms precisos. Este modelo profiri un
gran avance en el desarrollo de software.

El modelo en V prcticamente se bas en el modelo en cascada sin embargo demostr ser

ms eficiente, con las pruebas en cada fase, se detectaron muchos menos errores ya que
estos pudieron ser corregidos al momento, sin embargo esto genero muchos costos y se
perda tiempo de entrega para el usuario final.

11
 Figura 1.3 Modelo de Cascada
Roger S.Pressman [2002],Ingeniera de Software un enfoque prctico New York
[Consulta: 11 de febrero 2017] McGraw-Hill.

Prospectiva
Como se ve a futuro:

Como tal esta metodologa de desarrollo para sistemas de informacin, no tiene un gran
futuro por delante ya que, en estos momentos, si bien no es considerada Obsoleta, si es un
poco ms limitado su campo de trabajo, debido a que su forma de desarrollo que se basa en
un proceso sumamente estricto, en el cual no se puede trabajar en dos o ms fases
simultneamente, sino que, se debe seguir el orden a continuacin mencionado:

Recopilacin de Informacin y anlisis de datos.

Diseo del sistema.
Implementacin.
Pruebas.
Mantenimiento.

12
Otra de las partes que hacen de esta metodologa un tanto menos eficiente para ser utilizada
en los proyectos, se debe a su poca flexibilidad ante los cambios de requerimientos que se
lleguen a solicitar por parte del cliente, adems de que los tiempos de trabajo pueden llegar a
ser ms largos, puesto que la lnea de trabajo va de forma secuencial.

Esta metodologa est siendo poco a poco sustituida por las metodologas agiles, ya que hoy
en da las empresas suelen realizar muchos cambios en los requerimientos de los sistemas
de informacin, adems de que generalmente una de las cosas que ms valoran las
empresas que compran los sistemas de informacin aparte de la eficiencia, utilidad y
versatilidad del sistema, buscan una entrega lo ms pronto posible, cosa que la metodologa
de Cascada no se puede permitir en el sentido del cambio de requerimientos.

Conclusin

Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando
los requisitos estn perfectamente definidos desde la comunicacin hasta el despliegue del
trabajo fluye en forma razonablemente lineal y es entonces cuando es recomendable utilizar
este mtodo ya que cada una de sus fases estn estructuradas de esta forma.

El modelo en Cascada fue el primer mtodo orientado al desarrollo de software, de poca

innovacin, a proyectos definitivos y detallados.

Podramos considerarlo como el ms sencillo de utilizar, aunque por su alto nmero de

inconvenientes puede dudarse de su eficacia, ya que cada etapa inicia cuando haya
finalizado la anterior.

A lo largo de los aos se ha modificado el modelo con el fin de mejorar los errores que
presenta y tambin ha servido de base para crear nuevos modelos.

De manera concreta podemos finalizar diciendo que la metodologa de cascada es una

alternativa viable para sistemas de informacin cuyos equipos de trabajo estn organizados
de manera modular, para encargarse de sus respectivas fases, teniendo una comunicacin
ms adecuada entre cada grupo de trabajo, de esta manera es ms eficiente utilizar esta
metodologa por consiguiente lograr un software de alta calidad.

13
Bibliografa

Sommerville, Ian (2005), Ingeniera de software, Ed. Addison Wesley 7 Edicion.

Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin

Nelson Medinilla Martnez, Facultad de Informtica, Universidad Politcnica de Madrid,

Anlisis y seleccin de estrategias de desarrollo de software [En lnea], Madrid
Espaa [Consulta: Mayo de 2006],
<http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/estrategias.pdf>

Carolina Zibert, Ciclos de vida de Ingeniera de Software [En lnea], Caracas

Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-
ModeloV.doc>

Tesis doctorales en Zarza, Ingeniera de Software [En lnea], Espaa [Consulta:

Mayo de 2006], <http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102-
102210//05Capitulo05.pdf>

Mundo Geek, Ciclos de vida del software [En lnea], [Consulta: Mayo de 2006],
<http://mundogeek.net/archivos/2004/05/20>

Wikipedia Foundation Inc, EUA Desarrollo en Cascada [En lnea], St. Petersburg
[Consulta: Mayo de 2006], <http://es.wikipedia.org/wiki/Modelo_en_cascada>

14