Modelo de desenvolvimento: Cascata(Waterfall)

No último post, eu comentei que não existe o melhor modelo de desenvolvimento de software. Existe aquele que melhor atende às necessidades da sua cia, do seu negócio ou do seu time. E para decidir qual é o melhor, você deve conhecer seu time, seu produto e os diferentes modelos. Como não posso ajudar com seu time ou seu produto, acredito que posso ajudar muito apresentando os modelos que eu conheço. Assim, o trabalho de identificar o melhor modelo para você vai ficar mais fácil.

Este é o primeiro de uma série de posts sobre os modelos e vamos falar sobre o tão conhecido modelo Cascata(Waterfall). Acredito que este deve ser o modelo mais antigo, ensinado em todas as disciplinas de engenharia de software. E por incrível que pareça, também é o mais utilizado no desenvolvimento de software.

O diagrama acima nos apresenta uma típica divisão de fases de um projeto que usa modelo Cascata. Alguns podem adicionar mais fases, como dois níveis de verificação(Verification). Mas, no fim, a estrutura é esta.

1. Análise de requisitos(Requirement): Esta primeira fase tem como objetivo entender os requisitos do produto e produzir um documento de requisitos de usuário. Nesta fase, um analista de requisitos entrevista o cliente, entende o que ele quer, como quer e escreve um documento que guiará todas as demais fases. É o documento mais importante pois contém requisitos de negócio, usabilidade e segurança. Ao término desta fase, o conjunto de requisitos está definido e congelado para seguir para a próxima fase.
2. Desenho(Design): Após a produção e aprovação do documento de requisitos, a equipe técnica traduz os requisitos do produto em desenhos de arquitetura, identifica pontos de integração, desenha protótipos de tela e o que mais for necessário para implementar exatamente o que foi pedido no documento de requisitos.
3. Implementação(Implementation): De posse do desenho de arquitetura do sistema, as equipes técnicas passam a trabalhar na implementação do produto. As equipes codificam, testam(unitariamente e de forma integrada) de forma a entregar um produto funcional para a próxima fase.
4. Verificação(Verification): É nesta fase que o cliente volta em cena. Esta fase pode ter algumas subdivisões, mas é aqui que o produto funcional, entregue pela fase anterior, é confrontado com o documento de requisitos. Problemas, gaps ou defeitos são identificados nesta fase e encaminhados para correção.
5. Operação(Maintenance): O produto é implantado e a equipe técnica entra no período de suporte caso o sistema precise de alguma manutenção que foi identificada apenas com uso em larga escala ou no ambiente produtivo.

Com a descrição das fases, nota-se que a próxima fase do projeto só começa quando a fase anterior termina. A próxima fase é alimentada pelos artefatos produzidos na fase anterior. Logo, se o artefato não foi produzido porque a fase não terminou, não há como começar a próxima fase. Pelo diagrama acima, a fase de levantamento dos requisitos(Requirement) produz o documento de requisitos. A fase de desenho(Design) precisa do documento de requisitos finalizado para seu início.

Este modelo é muito criticado e muitas pessoas acreditam que ele é ultrapassado e não atende as necessidades dos projetos de software atuais. Mas este modelo não tem só desvantagens. Ele possui vantagens também.

 Vantagens

1. É muito fácil de implementar e não requer muitos recursos para isso;
2. Permite departamentalização e especialização pois cada um tem um papel específico ao longo do projeto;
3. Facilita o controle gerencial pois produz um artefato ao final de cada fase. Tanto o cliente quanto o gerente do projeto conseguem acompanhar o progresso com alta visibilidade. O trabalho linear também permite confrontar o término de cada fase com o objetivo estabelecido no início do projeto. Assim é fácil saber se estamos “dentro do cronograma” do projeto;
4. A equipe de desenvolvimento começa a trabalhar(codificar) muito mais rápido(ou cedo) que em outros modelos pois eles recebem o que tem que ser feito definido da fase anterior;
5. Diminui o tempo que o cliente precisa dedicar ao logo das fases 2 e 3. Como o modelo foca na produção de documentação, a interação com o cliente diminui pois está tudo documentado no artefato produzido pela fase 1;

 Desvantagens

1. Não permite mudanças de requisitos e, quando ocorre, seus custos e prazos são muito altos. Isso porque as mudanças ocorrerão na fase de Verificação que é onde o cliente vê seus requisitos traduzidos em produto. Nem sempre o produto real faz tanto sentido quanto o produto que foi escrito no documento. Diante de uma mudança, é preciso voltar todas as fases e refazê-las: especificar, desenhar, implementar e testar novamente;
2. Como este modelo é estritamente linear,  as interações não são previstas e são tratadas de forma “fora do modelo”. Nem preciso dizer a confusão que isso pode trazer conforme o projeto avança. Quem nunca ouviu a frase “Não está no documento de requisitos mas eu pedi isso para o fulano.”
3. Traz incerteza tanto para o time técnico quanto para o cliente. Como este modelo não prevê feedback, é difícil saber se, além de estar no prazo, o software real está de acordo com a ideia do cliente.

 

 Conclusão

Este modelo é muito recomendado para projetos onde a qualidade é mais importante do que custo ou prazo. Atender os requisitos é o fator de sucesso do projeto e o aumento do custo ou prazo é um risco que decide-se correr.

Também é recomendado para projetos onde o modelo de negócio está muito bem definido, os requisitos muito claros e estáveis e para projetos curtos.  Neste modelo você mantém requisitos, software e hardware congelados e isso é extremamente difícil de fazer num longo espaço de tempo.