A Metodologia de Desenvolvimento em Cascata foi o primeiro método de processo utilizado no Ciclo de Vida de Desenvolvimento de Software (SDLC). Atualmente, existem dois métodos dominantes em uso no SDLC: Ágil e Cascata. No método em Cascata, cada projeto (ou processo) deve ser concluído antes que o próximo possa ser iniciado. Os projetos são atividades de desenvolvimento lineares e sequenciais, onde o resultado de uma fase serve como entrada para a próxima fase, sequencialmente. Comparado ao método Ágil, o método em Cascata é mais estruturado, com cada fase possuindo entregas específicas e um processo de revisão. O método em Cascata é mais frequentemente utilizado para projetos simples, planejados e imutáveis, em vez do método Ágil , mais flexível e com maior participação do cliente . Para saber mais sobre as vantagens do método em Cascata, veja o que temos a dizer abaixo.
Fonte: TutorialsPoint
Leitura complementar: Quando usar metodologias ágeis ou em cascata no seu próximo projeto
Termos relacionados: Metodologia Ágil , Fim da Vida Útil (EOL) – Fim do Suporte (EOS) , Ciclo de Vida de Desenvolvimento de Software (SDLC )
Isso depende em grande parte da complexidade e da duração do seu projeto de desenvolvimento. Também depende das preferências do líder do seu projeto de desenvolvimento e se você deseja iterar em tempo quase real no seu desenvolvimento ou se você tem um objetivo específico e bem definido em mente. Em última análise, a decisão será sua, com base nesses e em uma série de outros fatores que vão além do escopo deste artigo. Provavelmente, é melhor pesquisar e discutir sua decisão com sua equipe.
Simples e fácil de entender e usar.
Fácil de gerenciar devido à rigidez do modelo. Cada fase tem resultados específicos e um processo de revisão.
As fases são processadas e concluídas uma de cada vez.
Funciona bem para projetos menores onde os requisitos são muito bem compreendidos.
Estágios de desenvolvimento claramente definidos.
Marcos bem compreendidos.
Fácil de organizar tarefas.
O processo e os resultados são bem documentados.
Nenhum software funcional é produzido até tarde durante o ciclo de vida.
Grandes quantidades de risco e incerteza.
Não é um bom modelo para projetos complexos e orientados a objetos.
Modelo ruim para projetos longos e contínuos.
Não é adequado para projetos onde os requisitos apresentam risco moderado a alto de alteração. Portanto, o risco e a incerteza são altos com este modelo de processo.
É difícil medir o progresso em etapas.
Não é possível acomodar requisitos em mudança.
Ajustar o escopo durante o ciclo de vida pode encerrar um projeto.
A integração é feita como um “big bang”. no final, o que não permite identificar antecipadamente qualquer gargalo ou desafio tecnológico ou de negócio.
https://www.youtube.com/watch?v=e1_eD-5zkGY
Descubra e compartilhe as últimas tendências, dicas e melhores práticas de segurança cibernética, além de novas ameaças às quais você deve ficar atento.
Autora: Katie Boquetti | Editorial: Craig Taylor Editorial de Craig Taylor: Já sabíamos disso há algum tempo...
Ler mais
Autora: Katie Boquetti | Editorial: Craig Taylor Editorial de Craig Taylor: Um CAPTCHA deve testar se...
Ler maisTenha uma visão mais aguçada dos riscos humanos com uma abordagem positiva que supera os testes de phishing tradicionais.
