Modelo en Cascada

el modelo de cascada (Figura 7.8) requiere que el trabajo corriente abajo no

debe comenzar hasta que se resuelvan las incertidumbres de aguas arriba y de
las principales crticas (puertas de decisin) han sido satisfechas. La Cascada,
desarrollado por el Dr. Winston W. Royce, se llama as porque el desarrollo de
software se representa como fluye desde la parte superior a la parte inferior,
en, fases secuenciales lineales discretos. 13 El modelo representa el ciclo de
desarrollo de software como una serie de pasos que avanzan en diagonal
desde la parte superior izquierda a la inferior derecha. En general, los
proyectos de alto riesgo complejos, esto es inapropiado. Rona Stillman, un
cientfico informtico de la Oficina de Contabilidad General de Estados Unidos,
sostiene que: "El modelo de cascada es adverso al riesgo. Alienta costo poco
realista y estimaciones de horario y la aparicin de un desarrollo libre de
problemas. "A menudo hay una necesidad de iniciar el diseo y la codificacin
de software, as como el modelado de hardware, ms temprano en el ciclo de
desarrollo para asegurar que los requisitos estn debidamente comprendidos y
al demostrar la viabilidad tcnica. Por estas razones, muchas organizaciones no
abrazan estos y otros modelos de desarrollo tcnico
otra definicin
hay momentos en que estn bien los requisitos para un problema entendidos,
cuando los flujos de trabajo de comunicacin a travs de la implementacin de
una manera razonablemente lineal. esta situacin se encuentra a veces
cuando adaptaciones bien definidos o mejoras de unos sistemas existentes
deben ser presentadas (por ejemplo, una adaptacin de software de
contabilidad que ha recibido el mandato debido a los cambios en las
regulaciones del gobierno). tambin puede ocurrir en un nmero limitado de
nuevos esfuerzos de desarrollo, pero slo cuando los requerimientos son bien
definidos y razonablemente estable
el modelo de cascada a veces llamado el ciclo de vida clsico sugiere un
enfoque secuencial sistemtico para el desarrollo de software que comienza
con la especificacin del cliente de los requisitos y progresa a travs de
modelos de planificacin de la construccin, y el despliegue, que culmin con
el apoyo permanente del software completado
el modelo de cascada es el paradigma ms antiguo de la ingeniera de
software. Sin embargo, en las ltimas cuatro dcadas, la crtica de este modelo
de proceso ha causado incluso partidarios ardientes de cuestionar su eficacia
[hank95]. Entre los problemas que se encuentran a veces, cuando se aplica el
modelo de cascada son
1- proyecto real rara vez se sigue el flujo secuencial que el modelo
propone. aunque el modelo lineal con capacidad iteracin, lo hace
indirectamente. como resultado, los cambios pueden causar confusin
en cuanto el equipo avanza el proyecto

2- a menudo es difcil para el cliente para indicar todo requisito explcito. el

modelo de cascada requiere esto y tiene dificultad para acomodar la
incertidumbre natural que existe en el comienzo de muchos proyectos
3- el cliente debe tener paciencia. una versin de trabajo de los programas
no estar disponible hasta finales del perodo de tiempo del proyecto. un
grave error, si no se detecta hasta que el programa de trabajo se revisa,
puede ser desastroso
en un interesante anlisis de proyecto real, Bradac [brad94] encontr que la
naturaleza lineal del ciclo de vida clsico conduce al "bloqueo de Estados" en el
que algunos miembros del equipo del proyecto deben esperar a que otros
miembros del equipo para completar, tareas dependientes. de hecho, el tiempo
de espera puede exceder el tiempo dedicado a trabajo productivo. el estado de
bloqueo tiende a ser ms frecuente en el inicio y el final de un proceso
secuencial lineal
hoy en da, el trabajo de software es de ritmo rpido y con sujecin a una
corriente interminable de cambios (a las caractersticas, funciones y contenido
de la informacin). el modelo de cascada es a menudo inapropiado para este
tipo de trabajo. sin embargo, puede servir como un modelo de proceso til en
situaciones donde se fijan los requisitos y el trabajo es proceder a la
terminacin de una manera lineal
documento origina de Royce
introduccin
voy a describir mis puntos de vista personales sobre la gestin de grandes
desarrollos de software. He tenido varias asignaciones durante los ltimos
nueve aos, en su mayora preocupados por el desarrollo de paquetes de
software para la planificacin de misiones en el espacio, comandando y anlisis
post-vuelo. En estas asignaciones he experimentado diferentes grados de xito
con respecto a llegar a un estado funcional, a tiempo y dentro de los costos. He
sido perjudicada por mis experiencias y yo voy a relatar algunos de estos
prejuicios en esta presentacin.
Yo voy a describir mi opinin personal sobre la administracin de grandes desarrollos de
software. Yo he tenido varias tareas durante los ltimos nueve aos, la mayora preocupado
por el desarrollo de paquetes de software para la planeacin de misiones en el espacio,
comandando y anlisis post-vuelo. En estas tareas he experimentado diferentes grados de
xito con respecto a la llegar a un estado funcional, a tiempo y dentro de los costos. He sido
perjudicado por mis experiencias y ahora en esta presentacin les voy a contar algunos de
estos prejuicios

COMPUTER PROGRAM DEVELOPMENT FUNCTIONS

Hay dos pasos esenciales comunes a todos los desarrollos de programas de
ordenador, independientemente de su tamao o complejidad. Existe primero
una etapa de anlisis, seguido por una segunda etapa de codificacin, tal como
se representa en la Figura 1. Este tipo de concepto muy simple implementado
es, de hecho, todo lo que se requiere si el esfuerzo es suficientemente pequeo

y si el producto final va a ser operada por aquellos que lo construy - como se

hace normalmente con los programas de computacin para uso interno.
Tambin es el tipo de esfuerzo de desarrollo para los cuales la mayora de los
clientes estn dispuestos a pagar, ya que ambas medidas implican trabajo
genuinamente creativo que contribuye directamente a la utilidad del producto
final. Un plan de implementacin para la fabricacin de sistemas de software
grandes, e introducido solamente para estos pasos, sin embargo, est
condenado al fracaso. Se requieren muchos pasos de desarrollo adicionales,
ninguno como contribuir directamente al producto final como el anlisis y la
codificacin, y todos elevan los costos de desarrollo. Personal del Cliente
normalmente prefieren no pagar por ellos, y personal de desarrollo prefieren no
aplicarlas. La funcin primordial de la gestin es la venta de estos conceptos
para ambos grupos y luego exigir el cumplimiento por parte del personal de
desarrollo

Un enfoque ms grandioso al desarrollo de software se ilustra en la Figura 2. El

anlisis y las medidas de codificacin estn todava en la imagen, sino que son
precedidos por dos niveles de anlisis de requisitos, estn separadas por una
etapa de diseo del programa, y seguido de una etapa de prueba. Estas
adiciones se tratan por separado a partir del anlisis y la codificacin, ya que
son claramente diferentes en la forma en que se ejecutan. Ellos deben ser
planificados y dotados de forma diferente a la mejor utilizacin de los recursos
del programa.
La figura 3 representa la relacin entre las fases de desarrollo iterativo
sucesivas a este sistema. El orden de las etapas se basa en el siguiente
concepto: que a medida que cada paso progresa y el diseo es ms detallada,
hay una iteracin con los pasos anteriores y posteriores, pero rara vez con los
pasos ms remotos de la secuencia. La virtud de todo esto es que a medida
que el diseo avanza el proceso de cambio tiene como alcance a lmites
manejables. En cualquier punto del proceso de diseo despus de que el
anlisis de requisitos se completa existe un firme acercamiento, la lnea de
base en movimiento al que regresar en caso de dificultades de diseo
imprevistos. Lo que tenemos es una posicin de retirada efectiva que tiende.
para maximizar el alcance de los primeros trabajos que es rescatable y
preservado.

Creo en este concepto, pero la implementacin se ha descrito anteriormente es

riesgoso e invita al fracaso. El problema se ilustra en la Figura 4. La fase de
prueba que se produce al final del ciclo de desarrollo es el primer evento para
el cual las transferencias de sincronizacin, de almacenamiento, de entrada /
salida, etc., se experimentan como distingue de analizar. Estos fenmenos no
son precisamente analizables. No son las soluciones a las ecuaciones en
derivadas parciales estndar de la fsica matemtica, por ejemplo. Sin
embargo, si estos fenmenos no satisfacen las diversas limitaciones externas,
entonces se requiere invariablemente un importante rediseo. Un parche octal
simple o rehacer de algn cdigo aislada no solucionar este tipo de
dificultades. Los cambios de diseo requeridos son propensos a ser tan
perturbador que los requisitos de software sobre el que el diseo se basa y se
permite la justificacin de todo lo que se violan. Cualesquiera de los requisitos
deben ser modificados, o se requiere un cambio sustancial en el diseo. En
efecto, el proceso de desarrollo ha vuelto al origen y uno puede esperar hasta
un l00 por ciento invadido en el horario y / o costos.
Punto, cabe destacar que ha habido un largo saltarse una de las fases de
anlisis y de cdigo. Uno no puede, por supuesto, producir software sin estos
pasos, pero en general estas fases son administradas con relativa facilidad y
tienen poco impacto en los requerimientos, diseo y pruebas. En mi
experiencia hay departamentos enteros consumidos con el anlisis de la
mecnica de la rbita, determinacin de actitud nave espacial, optimizacin
matemtica de la actividad de carga y dems, pero cuando estos
departamentos han completado su trabajo difcil y complejo, los pasos del
programa resultantes implican unas pocas lneas de serie cdigo de la
aritmtica. Si en la ejecucin de su trabajo difcil y complejo que los analistas
han cometido un error, la correccin se realiza siempre por un cambio menor
en el cdigo sin retroalimentacin perjudicial en las otras bases de desarrollo.
Sin embargo, creo que el enfoque se ilustra a ser fundamentalmente slida. El
resto de esta discusin presenta cinco caractersticas adicionales que hay que
sumar a este enfoque bsico para eliminar la mayor parte de los riesgos de
desarrollo.

PASO 1: DISEO DEL PROGRAMA ES LO PRIMERO

El primer paso hacia una solucin se ilustra en la Figura 5. Una fase de diseo
del programa preliminar se ha insertado entre la fase de generacin de
requisitos de software y la fase de anlisis. Este procedimiento puede ser
criticado sobre la base de que el diseador del programa se ve obligado a
disear en el vaco relativo de los requisitos iniciales de software sin ningn
tipo de anlisis existentes. Como resultado, su diseo preliminar puede ser
sustancialmente por error con respecto a su diseo, si tuviera que esperar
hasta que el anlisis fue completa. Esta crtica es correcta, pero pierde el
punto. Por esta tcnica, el diseador del programa asegura que el software no
fallar debido almacenamiento, tiempo y datos de flujo razones. Como anlisis
de los ingresos en la fase sucesiva el diseador del programa debe imponer al
analista el almacenamiento, el tiempo y las limitaciones operativas de tal
manera que l siente las consecuencias. Cuando justificadamente requiere ms
de este tipo de recursos con el fin de poner en prctica sus ecuaciones hay que
arrebat al mismo tiempo de sus compatriotas de los analistas. De esta
manera todos los analistas y los diseadores de programas contribuirn a un
proceso de diseo significativa que culminar en la correcta asignacin de
tiempo de ejecucin y los recursos de almacenamiento. Si el total de los
recursos que se aplicarn son insuficientes o si el diseo embrin operativa
est mal que sern reconocidos en esta etapa temprana y la iteracin con los

requisitos y el diseo preliminar se pueden rehacer antes de diseo final, la

codificacin y la prueba comienza.
Cmo se lleva a cabo este procedimiento? Se requieren los siguientes pasos.
1Comience el proceso de diseo con los diseadores de programas, no los
analistas o programadores.
2) Diseo, definir y asignar los modos de procesamiento de datos aun a riesgo
de equivocarse. Asignar de procesamiento, funciones, el diseo de la base de
datos, definir el procesamiento de base de datos, asignar tiempo de ejecucin,
definir interfaces y modos de procesamiento con el sistema operativo, describir
entrada y procesamiento de salida, y definir procedimientos operativos
preliminares.
3) un documento general que sea comprensible, informativa y actual. Todos y
cada trabajador debe tener una comprensin elemental del sistema. Al menos
una persona debe tener un profundo conocimiento del sistema que viene en
parte de haber tenido que escribir un documento general.

PASO 2: Documento EL DISEO

En este punto es oportuno plantear la cuestin de - "cunta documentacin?"
Mi punto de vista es "mucho"; sin duda, ms que la mayora de los
programadores, analistas, diseadores de programas o estn dispuestos a
hacerlo si se deja a su suerte. La primera regla de la gestin de desarrollo de
software es la aplicacin despiadada de los requisitos de documentacin.
De vez en cuando se me pide para revisar el progreso de otros esfuerzos de
diseo de software. Mi primer paso es investigar el estado de la
documentacin, si la documentacin es una infraccin grave de mi primera
recomendacin es simple. Vuelva a colocar la gestin de proyectos. Detener
todas las actividades no relacionadas con la documentacin. Traiga la
documentacin a los estndares aceptables. Gestin de software es
simplemente imposible sin un grado muy alto de la documentacin. A modo de
ejemplo, permtanme ofrecer las siguientes estimaciones para la comparacin.
Con el fin de adquirir un dispositivo de hardware de 5 millones de dlares, yo
esperara que una especificacin de 30 pginas proporcionara detalles

adecuados para el control de la adquisicin. Con el fin de procurar a 5 millones

de dlares de software que estimara una especificacin 1000 pgina est
sobre la derecha con el fin de lograr un control comparable,
Por qu tanta documentacin?
1) Cada diseador debe comunicarse con la interfaz diseadores, con su
gestin y, posiblemente, con el cliente. Un registro verbal es demasiado
intangible para proporcionar una base adecuada para una decisin de interfaz
o de gestin. Una descripcin escrita aceptable obliga al diseador a tomar una
posicin inequvoca y ofrecer pruebas tangibles de su finalizacin. Evita que el
diseador de su escondite detrs THE- "l am 90 por ciento terminado" - el
sndrome de mes tras mes.
2) Durante la fase temprana de desarrollo de software es la documentacin de
la especificacin y es el diseo. Hasta que comience la codificacin de estos
tres nombres (documentacin, especificacin, diseo) denotan una sola cosa.
Si la documentacin es mala el diseo es malo. Si la documentacin no existe
todava no existe todava ningn diseo, slo las personas pensar y hablar
sobre el diseo que es de algn valor, pero no mucho.
3) El valor monetario real de una buena documentacin comienza aguas abajo
en el proceso de desarrollo durante la fase de prueba y contina a travs de las
operaciones y rediseo. El valor de la documentacin se puede describir en
trminos de tres, situaciones tangibles concretas que cada caras gerente de
programa
a) Durante la fase de prueba, con una buena documentacin del gestor puede
concentrarse personal sobre los errores en el programa. Sin una buena
documentacin de cada error, grande o pequea, es analizada por un hombre
que probablemente cometi el error en el primer lugar porque l es el nico
hombre que comprende la zona del programa.
b) Durante la fase de explotacin, con una buena documentacin del
administrador puede utilizar personal de operacin orientada a operar el
programa y para hacer un mejor trabajo, ms barato. Sin una buena
documentacin del software debe ser operado por los que lo construy.
Generalmente estas personas son relativamente desinteresadas en
operaciones y no hacen un trabajo tan eficaz como el personal de operaciones
orientada. Cabe sealar a este respecto que en una situacin operativa, si hay
alguna colgar el software est siempre culpado primero. En fin, ya sea para
absolver el software o para fijar la culpa, la documentacin del software debe
hablar con claridad.
c) A raz de las operaciones iniciales, . Si la documentacin no existe, en
general, todo el marco existente de software operativo debe ser basura, incluso
para cambios relativamente modestos.
La Figura 6 muestra un plan de documentacin que est encabezado a los
pasos mostrados anteriormente. Tenga en cuenta que se producen seis

documentos, y en el momento de la entrega del producto final, Documentos

No, 1, No. 3, No. 4, No. 5, y N 6 se actualizan y actual.

PASO 3: hacerlo dos veces

Despus de documentacin, el segundo criterio ms importante para el xito
gira en torno a si el producto es totalmente original. Si el programa de
ordenador en cuestin est siendo desarrollado por primera vez, ordenar
asuntos de manera que la versin finalmente entregado al cliente para su
despliegue operacional es en realidad la segunda versin de la medida en el
diseo como crtica / reas de operaciones se refiere. La Figura 7 ilustra cmo
esto puede llevarse a cabo por medio de una simulacin. Tenga en cuenta que
se trata simplemente de todo el proceso hecho en miniatura, a una escala de
tiempo que es relativamente pequea con respecto al esfuerzo global. La
naturaleza de este esfuerzo puede variar ampliamente dependiendo
principalmente de la escala de tiempo general y la naturaleza de las reas
problemticas crticos para ser modelado. Si el esfuerzo se ejecuta 30 meses,
entonces este desarrollo temprano de un modelo piloto puede ser programado
para 10 meses. Para este programa, los controles bastante formales,
procedimientos de documentacin, etc., pueden ser utilizados. Si, sin embargo,
los esfuerzos generales se redujeron a 12 meses, entonces el esfuerzo piloto
podra ser comprimido a tres meses tal vez, a fin de obtener suficiente
influencia en el desarrollo de la lnea principal. En este caso se requiere un tipo
muy especial de competencia amplia por parte del personal involucrado.
Deben tener una sensacin intuitiva para el anlisis, la codificacin y el diseo
del programa. Deben sentir rpidamente los puntos conflictivos en el diseo,
modelarlos, modelo de sus alternativas, olvidar los aspectos sencillos de diseo
que no son dignos de estudio en este momento temprano, y finalmente llegar a
un programa sin errores. En cualquier caso, el punto de todo esto, como con
una simulacin, es que las cuestiones de calendario, almacenamiento, etc., que

de otro modo son materia de juicio, ahora pueden ser estudiados con precisin.
Sin esta simulacin el director del proyecto est a merced del juicio humano.
Con la simulacin que, al menos, puede realizar pruebas experimentales de
algunas hiptesis clave y el alcance hacia abajo lo que queda para el juicio
humano, que en el mbito del diseo de los programas de ordenador (como en
la estimacin de peso bruto de despegue, los costos para completar, o el doble
al da) es invariablemente serio y optimista.

PRUEBAS DE PLAN, CONTROL Y MONITOR: PASO 4

Sin lugar a dudas el mayor usuario de los recursos del proyecto, ya se trate de
mano de obra, tiempo de computadora, o juicio de la administracin, es la fase
de prueba. Es la fase de mayor riesgo en trminos de dlares y horario. Se
produce en el punto ltimo en el calendario cuando las alternativas de copia de
seguridad son menos disponibles, en todo caso.
Las tres recomendaciones anteriores para disear el programa antes de iniciar
el anlisis y codificacin, para documentar por completo, y la construccin de
un modelo piloto tienen por objeto el descubrir y resolver problemas antes de
entrar en la fase de prueba. Sin embargo, incluso despus de hacer estas cosas
todava hay una fase de prueba y todava hay cosas importantes por hacer.
Figura 8 enumera algunos aspectos adicionales de la prueba. En la
planificacin de las pruebas, me permito sugerir lo siguiente para su
consideracin.
1) Muchas partes del proceso de prueba se manejan mejor por especialistas de
las pruebas que no contribuyen necesariamente al diseo original. Si se
argumenta que slo el diseador puede realizar una prueba a fondo, ya que
slo l entiende la zona construy, este es un signo seguro de un fracaso para
documentar adecuadamente. Con una buena documentacin es factible el uso
de especialistas en la garanta de producto de software que, a mi juicio, hacer
un mejor trabajo de la prueba de que el diseador.

2) La mayora de los errores son de naturaleza obvia que puede ser fcilmente
detectado por la inspeccin visual. Cada pedacito de un anlisis y cada trozo
de cdigo debe ser sometido a una exploracin visual simple por una segunda
parte que no hacer el anlisis o cdigo original, pero que sera detectar cosas
como cado signos menos, los factores que faltan de dos, salta a direcciones
equivocadas, etc., que estn en la naturaleza de la correccin de pruebas y el
anlisis de cdigo. No utilice el equipo para detectar este tipo de cosas - que es
demasiado caro.
3) Prueba de cada camino lgico en el programa de ordenador al menos una
vez con algn tipo de verificacin numrica. Si yo fuera un cliente, yo no
acepto la entrega hasta que se complet y certificado este procedimiento. Este
paso va a descubrir que la mayora de los errores de codificacin. Si bien este
procedimiento de ensayo suena simple, para un programa grande y complejo
equipo es relativamente difcil de arar a travs de todos los caminos de lgica
con los valores controlados de entrada. De hecho, hay quienes sostienen que
es casi imposible. A pesar de esto me persistir en mi recomendacin de que
cada camino lgico ser sometido al menos a una autntica verificacin.
4) Despus se eliminan los errores simples (que son la mayora, y que
oscurecen los grandes errores), entonces es el momento de entregar el
software para el rea de prueba para fines de pago y envo. En el momento
adecuado durante el curso del desarrollo y en las manos de la persona
adecuada el propio ordenador es el mejor dispositivo para la salida. Las
decisiones de gestin clave son: cundo es el momento y quin es la persona
a hacer la comprobacin final?
PASO 5: INVOLUCRAR AL CLIENTE
Por alguna razn, lo que es un diseo de software que va a hacer es objeto de
interpretacin amplia, incluso despus de un acuerdo previo. Es importante
involucrar a los clientes de una manera formal para que l se ha comprometido
en los puntos anteriores antes de la entrega final. Para dar rienda suelta
contratista entre definicin de requisitos y la operacin est invitando a
problemas. Figura g indica tres puntos siguientes requisitos definicin, donde la
intuicin, el juicio, y el compromiso del cliente pueden reforzar el esfuerzo de
desarrollo.
RESUMEN
Figura 10 resume los cinco pasos que creo que es necesario para transformar
un proceso de desarrollo arriesgada en uno que proporcionar el producto
deseado. Me gustara hacer hincapi en que cada artculo cuesta cierta
cantidad adicional de dinero. Si el proceso relativamente simple y sin las cinco
complejidades descritas aqu sera trabajar con xito, a continuacin, por
supuesto, el dinero adicional no est bien gastado. En mi experiencia, sin
embargo, el mtodo ms sencillo que nunca ha trabajado en grandes esfuerzos
de desarrollo de software y los costos para recuperar super con creces las
necesarias para financiar el proceso de cinco pasos enumerados

Aqu van las ultimas 3 pginas de los esquemas

Cascada Modelo Pros y Contras
Ventaja
La ventaja de desarrollo en cascada es que permite para departamentalizacin
y control. Un horario se puede establecer los plazos para cada etapa de
desarrollo y un producto puede proceder a travs de los procesos de desarrollo
de fases modelo uno a uno.
Desarrollo mueve desde el concepto, a travs del diseo, implementacin,
prueba, instalacin, solucin de problemas, y termina en la operacin y
mantenimiento. Cada fase del desarrollo procede por riguroso orden.
desventaja
La desventaja de desarrollo en cascada es que no permite mucha reflexin o
revisin.
Una vez que la aplicacin se encuentra en fase de pruebas, es muy difcil
volver atrs y cambiar algo que no estaba bien documentado o pensamiento
sobre la etapa de concepto.
La siguiente tabla muestra los pros y los contras de modelo de cascada:

Informtico lder estadounidense y del ingeniero de desarrollo de software en la

segunda mitad del siglo 20.
B.Sc. en fsica, M.Sc y Ph.D. en ingeniera aeronutica, todos del Instituto de
Tecnologa de California (Caltech).
Trabaj en el campo de la ingeniera de sistemas de software desde 1961.
Desde la dcada de 1970 - El director de Lockheed centro de tecnologa de
software en Austin, Texas.
El primero en describir "el modelo de cascada".
Recibi el premio de los sistemas de informacin AIAA en 1975