O documento descreve o modelo cascata de engenharia de software, no qual as atividades de desenvolvimento ocorrem de forma sequencial e linear, com a saída de uma etapa servindo como entrada para a próxima. O modelo introduziu disciplina e estrutura ao processo de desenvolvimento, porém também é criticado por ser rígido e não permitir feedback ou modificações entre as etapas. O documento discute também quando o modelo cascata é mais apropriado e quais são seus principais problemas na prática.

1. Engenharia de Software Modelo Cascata Antonio Carlos Almir Ramos Eryson Raphael Rafael G. Leitão

2. O Modelo Cascata O modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são:

3. O Modelo Cascata Estudo de viabilidade Análise e especificação de requisitos Design da arquitetura Design detalhado Codificação e testes de unidades Integração e teste do sistema Entrega e instalação Manutenção

4. O Modelo Cascata Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente. Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização.

5. O Modelo Cascata Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software. O modelo Cascata também é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

6. O Modelo Cascata Características particulares do software (ser conceitual, por exemplo) e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo seqüencial, permitindo volta atrás para eventuais modificações. Veremos mais adiante modelos que propõem maior flexibilidade no fluxo de execução. As métricas utilizadas nas estimativas de prazos e recursos humanos são ainda bastante imprecisas e quase sempre o planejamento de atividades precisa ser revisto. Normalmente, os prazos não são cumpridos, pois o planejamento, neste modelo, é feito unicamente nas etapas iniciais do desenvolvimento. A estrutura seqüencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

7. O Modelo Cascata

9. Vantagens Torna o processo de desenvolvimento estruturado; Tem uma ordem sequencial de fases; Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte; Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; Esta abordagem é atualmente a norma e provavelmente permanecerá como tal nos próximos tempos;

10. Desvantagens Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores; Não suporta modificações nos requisitos; Não prevê a manutenção; Não permite a reutilização; É excessivamente sincronizado; Se ocorrer um atraso todo o processo é afetado; Faz aparecer o software muito tarde;

11. Problemas O ciclo de vida Cascata é o paradigma mais visto e mais amplamente empregado na engenharia de software, porém sua aplicabilidade, em muitos campos, tem sido questionada. Entre os problemas que surgem quando se aplica o modelo são: Na realidade, os projetos raramente seguem o fluxo sequencial que o modelo propõe; A interação é sempre necessária e está presente, criando problemas na aplicação do modelo; Em princípio, é difícil para o cliente especificar os requisitos explicitamente, o que acarreta a incerteza natural do início de qualquer projeto; O cliente deve ser paciente, pois uma versão funcional não estará disponível até o final do desenvolvimento. Qualquer erro ou mal entendido, se não for detectado até que o software seja revisado, pode ser desastroso;

12. Problemas Apesar desses problemas, o modelo Cascata tem um lugar bem definido e importante nos trabalhos de engenharia de software. Ele fornece um padrão do qual se encaixam métodos para a análise, projeto, codificação e manutenção.

13. Domínio de aplicações O modelo Cascata aplica-se bem em situações em que o software a ser desenvolvido é simples, os requisitos são bem conhecidos, a tecnologia de Programação. Melhorias e correções podem ser consideradas como parte do desenvolvimento. As etapas descritas são as principais, porém existem sub-etapas dentro de cada etapa, as quais diferem muito de um projeto para outro. Também é possível que certos projetos de software exijam a incorporação de uma etapa extra ou a separação de uma etapa em outras etapas. Com certeza, todas essas variações do modelo Cascata possuem o mesmo conceito básico: a ideia de que uma etapa fornece saída que serão usadas como entradas para a etapa seguinte.

14. Domínio de aplicações Portanto, o processo de desenvolvimento de um produto de software de acordo com o modelo Cascata é simples de conhecer e controlar. Outras atividades que também são levadas em consideração em cada uma das etapas de desenvolvimento do software são: Verificação; Administração das etapas serem documentadas. A verificação, por sua vez, é necessária para que uma etapa forneça os dados corretos para a etapa seguinte. Já a administração, efetua a gestão e o controle da etapa.