MODELO CASCATA

MODELO CASCATA

1. Atividades

   • Levantamento de Requisitos (ou Comunicação)
     • Abrange o levantamento de requisitos e outras atividades relacionadas
   • Planejamento
     • Estabelece um plano para o trabalho, descrevendo as tarefas técnicas conduzidas, os riscos prováveis, os recursos que serão necessários, os produtos de trabalho a ser produzidos e um cronograma
   • Modelagem (Análise e Projeto de Sistemas)
     • Inclui a criação de modelos que permitam ao desenvolvedor e ao cliente entender melhor os requisitos do software e o projeto que atende tais requisitos
   • Implementação (Construção)
     • Geração de códigos
   • Testes
     • Para revelar erros no código
   • Implantação
     • O software é entregue ao cliente, que avalia o produto e fornece feedback.

2. Fluxo de Trabalho

   • Sugere uma abordagem sequencial e sistemática para o desenvolvimento de software
   • O resultado de cada fase consiste de um ou mais documentos aprovados
   • A fase seguinte não deve começar antes que a fase anterior tenha terminado
   • Durante o projeto, os problemas com requisitos são identificados e, durante a codificação, os problemas encontrados e assim por diante
   • O processo de software não é um modelo linear simples, mas envolve o feedback de uma fase para outra. Assim, os documentos produzidos em cada fase podem ser modificados para refletirem as alterações feitas em cada um deles

3. Vantagens

   • Documentação produzida em cada fase e sua aderência a outros modelos de processo de engenharia
   • Esse modelo é indicado apenas quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento do sistema

4. Desvantagens

   • A aprovação de documentos e as iterações são onerosas e envolvem um “retrabalho” significativo
   • O congelamento prematuro de requisitos pode significar que o sistema não fará o que o usuário deseja
   • A natureza linear do modelo em cascata leva a “estados de bloqueio”, pois alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes
   • Como o software só é colocado em uso na fase de operação e manutenção erros e omissões nos requisitos somente são descobertos depois que o produto está pronto,

5. Principal problema

   • Divisão inflexível do projeto em estágios distintos, tornando difícil atender requisitos do usuário que mudam