sexta-feira, 2 de março de 2007

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:
  • 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
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. 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.

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.

Para saber mais, recomendo os seguintes artigos (em inglês):

6 comentários:

lopez_23 disse...

muito bom safou-me numa aula de S.I.

R disse...

Bom encontrar um blog de Engenharia de Software.

Ricardo Emerick disse...

Estou lendo a respeito do modelo cascata, e gostei do que encontrei aqui no blog.

Muito importante sua iniciativa de criar um blog de Engenharia de Software.

hhh disse...

Muito bom o post!
Blog ja esta nos favoritos! o/

Edher disse...

Muito bom! Bem claro e objetivo... Obrigado amigo, parabéns pelo blog!

Arth Informática disse...

Gosto muito dos artigos de ótima qualidade do seu Blog. Quando for possível dá uma passadinha para ver nosso Curso de Informática Online. Lucas