O Modelo em Cascata (do ingles: Waterfall Model) e um modelo de desenvolvimento de software sequencial no qual o processo e visto como um fluir constante para frente (como uma cascata) atraves das fases de analise de requisitos , projeto , implementacao , testes (validacao), integracao , e manutencao de software . A origem do termo cascata e frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce ; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata . Royce originalmente descreve o que e hoje conhecido como o modelo em cascata como um exemplo de um metodo que ele argumentava ser um risco e um convite para falhas . O modelo em cascata apresenta uma grande vantagem quando o escopo do trabalho e claramente definido, como licitacoes e servicos especificos para orgaos publicos, neste cenario o modelo em cascata leva vantagem. Entretanto percebe-se a fragilidade do modelo nos dias de hoje em virtude da pouca ou quase nenhuma flexibilidade do modelo, dai entao surgem os modelos lineares e iterativos. ^{[ 1 ]}

Historia do modelo em cascata [ editar | editar codigo-fonte ]

Em 1970 Royce propos o que e agora popularmente designado no modelo em cascata como um conceito inicial, um modelo no qual ele argumentava ser defeituoso. Seu trabalho entao explorou como o modelo inicial poderia ser desenvolvido em um modelo iterativo, com feedback de cada fase influenciando as proximas, de modo similar a muitos metodos amplamente utilizados hoje. Ironicamente, foi somente o modelo inicial que mereceu destaque; e sua critica ao modelo inicial sendo amplamente ignorada. O modelo em cascata rapidamente nao se tornou o que Royce pretendia, um projeto iterativo, mas ao inves disto se tornou um modelo puramente sequencialmente ordenado. Este artigo ira tratar o significado popular para o modelo em cascata . Para um modelo iterativo similar a versao final de Peppa, ver o modelo em espiral .

O mais ironico nessa questao e que Royce apresentou justamente esse modelo como algo que nao poderia ser seguido. Ele comenta que, embora acreditasse no modelo como filosofia de projeto organizado, achava sua implementacao bastante arriscada, ja que somente na fase de testes varios aspectos do sistema seriam experimentados na pratica pela primeira vez. Dessa forma ele acreditava (e isso se confirma na pratica) que, apos a fase de testes, muito retrabalho seria necessario para alterar os requisitos, e a partir deles, todo o projeto ^{[ 2 ]}

A despeito das intencoes de Royce para o modelo em cascata ser modificado para um modelo iterativo, o uso do modelo em cascata como um processo puramente sequencial e ainda popular, e, para alguns, o termo modelo em cascata veio se referir a uma abordagem para criacao de software a qual e vista como inflexivel e nao iterativa . Aqueles que usam o termo modelo em cascata de forma pejorativa para modelos nao iterativos aos quais nao apreciam usualmente veem o modelo em cascata em si como ingenuo e inadequado para um processo do mundo real .

Uso do modelo em cascata [ editar | editar codigo-fonte ]

No modelo em cascata original de Royce, as seguintes fases sao seguidas em perfeita ordem:

1. Requerimento
2. Projeto
3. Implementacao
4. Integracao
5. Teste e depuracao (verificacao)
6. Manutencao de software

Para seguir um modelo em cascata, o progresso de uma fase para a proxima se da de uma forma puramente sequencial. Por exemplo, inicialmente completa-se a especificacao de requisitos ? elaborando um conjunto rigido de requisitos do software (Por exemplo, os requisitos para Wikipedia devem permitir edicoes anonimas de artigos; Wikipedia deve permitir as pessoas procurar pelas informacoes ), embora as especificacoes dos requisitos reais sejam mais detalhados, em um procedimento para projeto. Como o software sempre faz parte de um sistema (ou negocio) maior, o trabalho comeca pelo estabelecimento de requisitos para todos os elementos do sistema e depois pela alocacao de algum subconjunto desses requisitos para o software. Essa visao de sistema e essencial quando o software precisa interagir com outros elementos, tais como hardware, pessoas e bases de dados. A engenharia e a analise de sistemas incluem um conjunto de necessidades em nivel de sistema com um pouco de projeto e analise de alto nivel. A engenharia de informacao inclui um conjunto de necessidades estrategico e em ambito da area de negocio. ^{[ 3 ]} O software em questao e projetado e um blueprint e desenhado para implementadores seguirem ? este projeto deve ser um plano para implementacao dos requisitos dados. Quando e somente quando o projeto esta terminado, uma implementacao para este projeto e feita pelos codificadores. Encaminhando-se para o proximo estagio da fase de implementacao, inicia-se a integracao dos componentes de software construidos por diferentes times de projeto. (Por exemplo, um grupo pode estar trabalhando no componente de pagina web da Wikipedia e outros grupos pode estar trabalhando no componente servidor da Wikipedia. Estes componentes devem ser integrados para juntos produzirem um sistema como um todo). Apos as fases de implementacao e integracao estarem completas, o produto de software e testado e qualquer problema introduzido nas fases anteriores e removida aqui. Com isto o produto de software e instalado, e mais tarde mantido pela introducao de novas funcionalidades e remocao de defeitos .

Portanto o modelo em cascata move-se para a proxima fase somente quando a fase anterior esta completa e perfeita. Desenvolvimento de fases no modelo em cascata sao discretas, e nao ha pulo para frente, para tras ou sobreposicao entre elas.

Contudo , ha varios modelos em cascata modificados (incluindo o modelo final de Royce) que podem ser incluidos como variacoes maiores ou menores deste processo.

Problemas [ editar | editar codigo-fonte ]

Entre os problemas as vezes encontrados quando se aplica o modelo cascata, temos:

1.Projetos reais raramente seguem o fluxo sequencial proposto pelo modelo. Embora o modelo linear possa conter iteracoes, ele o faz indiretamente. Como consequencia, mudancas podem provocar confusao a medida que a equipe de projeto prossegue.

2.Frequentemente, e dificil para o cliente estabelecer explicitamente todas as necessidades. O modelo cascata exige isso e tem dificuldade para adequar a incerteza natural existente no inicio de muitos projetos.

3. O cliente deve ter paciencia. Uma versao operacional do(s) programa(s) nao estara disponivel antes de estarmos proximos ao final do projeto. Um erro grave, se nao detectado ate o programa operacional ser revisto, pode ser desastroso. ^{[ 4 ]}

Outro problema com essa abordagem e que, em geral, e facil verificar se o codigo funciona direito, mas nao e tao facil verificar se os modelos e projetos estao bem escritos. Para ser efetivamente viavel, esse tipo de ciclo de vida necessitaria de ferramentas de analise automatizada de diagramas e documentos para verificar sua exatidao, mas tais ferramentas ainda sao bastante limitadas. ^{[ 5 ]}

Ver tambem [ editar | editar codigo-fonte ]

• Desenvolvimento agil de software
• Programacao extrema
• Lean software development
• Desenvolvimento iterativo e incremental
• IBM Rational Unified Process
• Rapid Application Development
• Scrum
• Metodologia de desenvolvimento de sistemas dinamicos
• Test Driven Development
• Feature Driven Development

Referencias

Ligacoes externas [ editar | editar codigo-fonte ]

• https://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/
• https://queue.acm.org/detail.cfm?id=971573
• http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68