A origem do termo cascata de modelo em cascata frequentemente citado como sendo um artigo publicado em 1970 por Winston W. Royce.

. Apesar de ser mencionado como criador do modelo , em seu artigo Royce no mencionou o termo cascata e, diferente do que se poderia pensar, defendia uma abordagem interativa para desenvolvimento de software. Nesse artigo Royce descreve o mtodo de cascata como um risco e um convite para falhas.

Gerenciando o desenvolvimento de grandes sistemas de software. Dr. Winston W. Royce Introduo Irei descrever minha viso pessoal sobre o gerenciamento do desenvolvimento de grandes softwares. Eu tive varias designaes durante os ltimos nove anos, com maior enfoque em pacotes de softwares para planejamento, comando e analises ps-voo, de misses de veculos espaciais. Nessas atribuies eu experimentei diferentes graus de sucesso a respeito da chegada ao estado operacional, do tempo, e dos custos. Eu fui prejudicado pelas minhas experincias e irei relatar alguns desses prejuzos nesse artigo.

Funes de desenvolvimento de programas para computador. Existem dois passos comuns e essenciais para o desenvolvimento de programas de computador, independentemente do tamanho ou da complexidade. Existe primeiro o passo da analise, seguido pelo passo de codificao retratado na Figura 1. Esse tipo bem simples de conceito de implementao , de fato, tudo que preciso se o esforo for suficientemente pequeno e se o produto final for utilizado por aqueles que o produziram como geralmente feito com programas de computador para uso interno. Esse tambm o tipo de desenvolvimento que a maioria dos clientes ficam felizes em pagar, sendo que ambos os passos envolvem genuinamente o trabalho criativo que contribui diretamente para a utilidade do produto final. Um plano de implementao de um grande software manufaturado, e com a chave apenas nesses dois passos, entretanto, esta fadado ao fracasso. Vrios passos adicionais so necessrios, nenhuma contribuindo diretamente para o produto final como a analise e a codificao, e todos eles demando custos de desenvolvimento. Um cliente pessoal geralmente no desejar pagar por eles, e seria prefervel que o desenvolvimento pessoal no fosse implementado. A principal funo do gerenciamento a de vender essas ideias para ambos os grupos e ento se fazer cumprir a observncia na parte de desenvolvimento pessoal.

Imagem 1 Figura 1. Passos para implementao para entregar um pequeno programa de computador para operaes internas.

Uma aproximao mais detalhada do desenvolvimento de software ilustrada na figura 2. Os passos de analise e codificao ainda esto na figura, mas eles so precedidos por dois leveis de analise de requerimento, e so separados pelo passo de design de programa, e seguido por um passo de teste. Essas adies so tratadas separadamente da analise e da codificao porque eles so distintos na forma em que so executados. Eles devem ser planejados e cuidados de formas diferentes para melhor utilizao dos recursos do programa. A figura 3 retrata a relao interativa entre fases sucessivas de desenvolvimento para esse esquema. A ordem dos passos baseada no seguinte conceito: com cada passo avanando e o design sendo mais detalhado, h uma interao entre os passos anteriores e posteriores, mas raramente com mais de um passo vago em sequencia. A vantagem de tudo isso que, conforme o projeto prossegue, os procedimentos se dividem em tamanhos flexveis. Em qualquer ponto em que a concepo aps a analise de requisitos concluda existe uma empresa e um close-up, para mudar a linha de base de acordo com as dificuldades de design imprevistas. O que temos uma posio efetiva de fallback que tende a maximizar o trabalho inicial com o que aproveitvel. Imagem 2. Passos para implementao para o desenvolvimento de um grande programa do computador para a entrega a um cliente. Eu acredito nesse conceito, mas a implementao descrita acima ariscada e um convite para falhas. O problema ilustrado na figura 4. A fase de testes que ocorre no final do ciclo de desenvolvimento o primeiro evento que o tempo, o armazenamento, transferncias de sada e entrada, etc., e so experimentados e analisados distintamente. Esses fenmenos no so analisados precisamente. Eles no so solues para as equaes diferenciais parciais padres, por exemplo. Ainda assim se esses fenmenos falam em satisfazer as varias restries externas, ento, invariavelmente, uma grande reformulao se faz necessria. Um patch parcial ou refazer alguns pontos no ser o suficiente para corrigir esses problemas. As alteraes necessrias so suscetveis a interferir nos requisitos dos softwares nos quais o projeto se baseia e fornece a logica para tudo. Ou os requisitos devem ser modificados ou uma grande modificao deve ser realizada. Na realidade o processo de desenvolvimento voltar para o inicio, o que implicar em um gasto de at 100% a mais de tempo e custo.