Modelo en Cascadael 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 tcnicootra definicinhay 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 estableel 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 completadoel 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 son1- 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 proyecto2- 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 proyectos3- 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 desastrosoen 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 linealhoy 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 linealdocumento origina de Royceintroduccinvoy 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 prejuiciosCOMPUTER PROGRAM DEVELOPMENT FUNCTIONSHay 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 PRIMEROEl 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 DISEOEn 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 programaa) 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 vecesDespus 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 4Sin 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 CLIENTEPor 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.RESUMENFigura 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 enumeradosAqu van las ultimas 3 pginas de los esquemas Cascada Modelo Pros y ContrasVentajaLa 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.desventajaLa 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