Qual a principal desvantagem do Modelo em Cascata de processo de software

Criando em 1970 por Winston Walker Royce, o Modelo em Cascata (também conhecido como Modelo Sequencial Linear) é o mais antigo de todos os processos e possui esse nome devido a sua forma sequencial cascateada que acontece de uma fase para a outra.

Considerado o “modelo clássico de desenvolvimento”, o Modelo em Cascata é “sugerido para projetos pequenos” e sua ideia defende que “para uma fase iniciar, a anterior deve estar totalmente finalizada” (ENGHOLM, 2010) e que o “resultado de cada etapa é a aprovação de um ou mais documentos ‘assinados’” (SOMMERVILLE, 2011).

Basicamente, o desenvolvimento é dividido em cinco etapas, que começam assim que a anterior termina:

1. Especificação: é feita a análise e captação das necessidades do cliente e definidos os “requisitos do sistema” com suas funcionalidades;
2. Projeto do software: é elaborado o desenho da arquitetura geral do sistema, seguindo as informações coletadas na etapa anterior. Tudo é separado em partes chamadas de “unidades de programa” para poder agilizar o desenvolvimento. Cada unidade terá seu próprio “requisito de unidade”;
3. Implementação: nesta etapa, com o projeto definido, cada “unidade de programa” é implementada, podendo alocar vários programadores simultaneamente.
4. Teste unitário: no final da implementação, são feitos os “testes de unidade” para certificar (validação) que as implementações atendem aos “requisitos de unidade”;
5. Integração: com as unidades testadas, a próxima tarefa é integrar todas elas para compor um sistema completo.
6. Teste de Sistema: no final da integração, é feito um teste geral para certificar (validação) que os “requisitos do sistema” foram completamente atendidos. Por fim, o software é entregue ao cliente;
7. Operação e manutenção: Ao operar, ou seja, utilizar o sistema, o cliente poderá encontrar erros ou necessidades que não foram identificadas anteriormente. Esta fase se responsabiliza pela correção dos erros ou melhorias do sistema (evolução).

Vantagens

• Por causa de sua natureza separada em unidades, o modelo em cascata possibilita a implementação concorrente entre vários programadores, agilizando a entrega;
• É útil quando o pessoal envolvido no projeto é fraco tecnicamente. (McCONNEL, 1996);
• O modelo apresenta uma grande vantagem quando o escopo do trabalho é claramente definido. Se as especificações estiverem corretas (o que é muito difícil em projetos de médio e grande porte), um software pode ser desenvolvido de forma muito rápida.

Desvantagens

• O próprio criador do método (Royce) afirmou que, se a especificação não for bem definida, ele pode ser tornar um risco e um convite para falhas (TORRES, 2014). Afirmou também que o modelo tratava-se era um conceito inicial e ainda defeituoso;
• Como o modelo não possui flexibilidade, seguindo um sequencia engessada, é considerado um modelo frágil, principalmente nos dias de hoje que os projetos mudam muito no decorrer do desenvolvimento;
• Também é difícil estabelecer explicitamente todos os requisitos logo o início do projeto, pois no começo, sempre existe uma incerteza natural;
• O cliente deve ter muita paciência, pois uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento;
• Projetos grandes raramente seguem a sequencia proposta pelo modelo. A produção e aprovação de documentos durante as etapas costumam se caras e geradoras de muito retrabalho;
• Durante o processo, é comum o cliente solicitar o congelamento de partes do desenvolvimento para dar continuidade aos estágios posteriores, tornando a solução dos problemas mais difícil, pois acaba sendo programada para mais tarde e, dependendo da situação, acaba sendo parcial ou totalmente ignorada;
• O congelamento prematuro de partes da implementação pode resultar em um sistema que não faça o que o usuário quer. Também pode “levar a sistemas mal estruturados, quando os problemas de projeto são contornados por artifícios de implementação” (SOMMERVILLE, 2011);
• EVANS (2017), defensor de uma linguagem de arquitetura que reflita as regras de negócio do cliente, afirma que no Modelo em Cascata, os especialistas de um negócio conversam com os analistas, […] que passam o resultado para os programadores […] No entanto, essa abordagem falha porque lhe falta feedback. Em outra palavras, o software resultante pode atender às necessidades do cliente, mas o código não reflete as regras de negócio, uma vez que os programadores “só programam”, não sendo possível identificar os termos de negócio olhando no código;
• A natureza linear do modelo leva a “estados de bloqueio”, nos quais alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes (PRESSMAN, 2006);

Segundo ENGHOLM (2010), as desvantagens podem ser resumidas aos seguintes itens:

• É muito difícil retornar para as fases anteriores para corrigir problemas detectados posteriormente;
• Muito tempo é gasto para garantir que as fases sejam executadas corretamente;
• Demora muito para o cliente ver algum resultado;
• O cliente se decepciona quando recebe o produto;
• A equipe de desenvolvimento está sempre “quase acabando”;
• Esconde os riscos por muito tempo, retardando sua resolução;

Resumindo, o Modelo em Cascata “não foi elaborado para lidar com mudanças” (ENGHOLM, 2010).

Nos próximos artigos serão abordados outros modelos de processo de software. Espero que o conteúdo seja útil. Um grande abraço e até a próxima!

Leia também o próximo artigo sobre o assunto:

Leia todos os artigos desta série:

• Os Processos de Software
• O Modelo em Cascata
• O Modelo Incremental
• O Modelo em Espiral de Boehm
• O Processo Unificado
• Extreme Programming

Referências para aprofundamento

ENGHOLM, Hélio. Engenharia de Software na Prática. Novatec Editora. São Paulo, Brasil, 2010.

EVANS, Eric. Domain-Driven Design Atacanto as Complexidades no Coração do Software. Altabooks Editora. Rio de Janeiro, Brasil, 2017.

McCONNEL, Steve. Rapid development. Redmond, WA: Microsoft Press, 1996.

PRESSMAN, Roger. S. Engenharia de Software, 6ª Edição. McGrawHill, Nova York, EUA, 2006

SOMMERVILLE, Ian. Engenharia de Software, 9ª Edição. Pearson. São Paulo, Brasil, 2011.

TORRES, Luis Fernando (2014). Fundamentos de gerenciamento de processos. Rio de Janeiro: Elsevier.