Quais são os problemas do modelo em cascata?

O modelo em cascata é uma abordagem de projeto sequencial relativamente linear para certas áreas do projeto de engenharia.

No desenvolvimento de software, tende a estar entre as abordagens menos iterativas e flexíveis, pois o progresso flui em grande parte em uma direção descendente, como uma cascata, através das fases de concepção, iniciação, análise, projeto, construção, teste, implantação e manutenção. Usadas em projetos de desenvolvimento de software, as fases geralmente se parecem com isso:

1. Requisitos

Se você gosta de desenvolvimento de software ou de qualquer tipo de equipe de criação de projetos, gostaria de conhecer o contexto de negócios do que está tentando criar – deseja definir que tipo de problemas está tentando resolver e como as pessoas reagiriam ao seu produto final. Depois de definir todos esses “requisitos”, você tem a entrada necessária para passar para a próxima etapa.

2. Projeto

Esta etapa é composta de todas as etapas necessárias para atender a todos os requisitos determinados anteriormente. No desenvolvimento de software, esta é a parte onde você define toda a arquitetura de software e hardware, linguagem de programação, armazenamento de dados, etc. Esta é também a parte em que você determina como o projeto seria útil para seu usuário final.

3. Implementação

Nesta etapa, você começa a construir o que projetou em seu plano. Esta parte do método Waterfall é dedicada a atender aos padrões que você estabeleceu nas etapas anteriores. Esta é a parte em que as pessoas da equipe de desenvolvimento entram e fazem acontecer todas as coisas discutidas nas etapas anteriores.

4. Verificação

Esta é a parte do método em que as pessoas de garantia de qualidade entram para garantir que a equipe de desenvolvimento não cometeu nenhum erro. Essa também é provavelmente a parte em que as pessoas percebem o que está funcionando ou não em seu plano.

Observe que

Quando todas as coisas são satisfeitas pelos desenvolvedores do projeto, o cliente ou o usuário final entra e faz a chamada final se o projeto estiver pronto para ser lançado.

O método Waterfall faz questão de que, quando algo dá errado em um estágio específico, as pessoas podem voltar ao anterior para ver o que deu errado. Por exemplo, se houver um problema na Implementação do Plano e as pessoas souberem que simplesmente seguiram o projeto que lhes foi entregue, os gerentes analisam seu plano e fazem suas revisões a partir daí.

Qual é o problema da cachoeira?

Os clientes podem não saber exatamente quais são seus requisitos antes de verem o software funcionando e, assim, alterar seus requisitos, levando ao redesenho, redesenvolvimento e reteste, além de aumentar os custos.

Os desenvolvedores podem não estar cientes de dificuldades futuras ao projetar um novo produto ou recurso de software; nesse caso, é melhor revisar o projeto do que persistir em um projeto que não leve em conta quaisquer restrições, requisitos ou problemas recém-descobertos.

Assim, não há garantia de que os requisitos que a organização pensou realmente funcionariam. A partir daqui, você perceberia que o modelo Waterfall tem os seguintes problemas:

1.  As pessoas seguem cegamente os planos.

No método tradicional, as pessoas prestam mais atenção em como as coisas vão acontecer no momento certo, sem estar atentas se as coisas estão realmente se encaixando. Embora o planejamento seja importante, também é importante que os desenvolvedores e verificadores de qualidade entendam como as coisas devem acontecer, especialmente com o cliente ou o usuário final. Também é importante que todas as pessoas envolvidas no projeto possam dizer imediatamente como uma etapa específica no cumprimento do projeto pode desmoronar sem ter que esperar pelo estágio de teste.

2.  Processo sequencial e mudanças tornam-se dispendiosas

Essa abordagem não permite a mudança de requisitos definidos à medida que o projeto avança. Assim, há um grande potencial de que o software não atenda totalmente o requisito do usuário, seja ineficiente e tenha pouca funcionalidade.

É inadequado, pois os desenvolvedores não podem simplesmente voltar e mudar algo em uma fase anterior à medida que o requisito do consumidor muda, mas o desenvolvedor precisa voltar para onde o requisito precisa mudar e iniciar essa fase toda. Não até que essa fase esteja completa ele pode passar para a próxima fase.

3.  Os usuários finais não sabem o que querem.

Na maioria das vezes, a mente de um usuário final está em constante mudança e a maioria das pessoas tem uma vaga ideia de seus requisitos de software e é à medida que o software se desenvolve que eles especificam seus requisitos.

Quando chega a hora de entregar o produto acabado a um cliente, é provável que ele não goste de como ficou, apesar de dizer deliberadamente o contrário durante os estágios iniciais. É fácil para clientes e usuários finais alterarem o que desejam ao longo do tempo. O sistema Waterfall ainda não tem como resolver isso, sem ter que revisar os planos e refazer todo o projeto por completo.

4.  Os testes de qualidade podem sofrer.

É impossível prever com precisão os resultados de um projeto e, quando toda a equipe está pressionada pelo tempo, é possível encurtar o estágio de teste para cumprir o prazo.

5.  Você nunca saberá em que palco você realmente está.

Como o produto que você está tentando criar não será produzido até o final, você não tem certeza se ainda está planejando ou se já está no estágio de desenvolvimento. Isso significa que também é provável que você passe mais tempo em um palco do que o esperado devido a essa baixa visibilidade.

No final, o método Waterfall pode ser muito arriscado, pois é muito rígido. Para que você produza um produto que funcione e seja flexível o suficiente para ajudá-lo a descobrir o que está funcionando ou não.

Recursos Relacionados

• Agile & Scrum — Artigos de desenvolvimento de software ( inglês ) ( chinês ) ( japonês )