Modelo de Desenvolvimento – Waterfall

Diagramas

Está sendo colocado vários diagramas, apenas para mostrar que para cada autor, obra ou documento temos a apresentação de uma visão e conceitos diferentes.

Waterfall3

Waterfall1

Descrição

Imagine o caminho da água de uma cachoeira: O rio corre a partir do topo e flui para a parte inferior. É o mesmo no desenvolvimento de sistemas (gerenciamento de projetos). Com objetivos claramente definidos e uma linha do tempo estabelecida, as equipes trabalham nas tarefas de cada fase em seqüência, ou seja, cada fase deve ser concluída antes de começar a próxima fase do modelo.

  • É o clássico modelo de ciclo de vida.
  • Primeiro modelo de processo a ser introduzido, por Winston Royce em 1970.
  • Neste modelo, o ensaios (testes) começam apenas após o desenvolvimento estar completo.
  • As fases do modelo não se sobrepõem.

Vantagens

  • É muito simples de entender e usar.
  • Os marcos são bem compreendidos.
  • Define estabilidade dos requisitos.
  • Funciona bem quando a qualidade é mais importante do que o custo ou cronograma.
  • Funciona bem para projetos de menor dimensão onde as exigências são muito bem compreendidas.
  • Fácil de gerenciar (planejamento, equipe, monitoriamento) devido à rigidez do modelo, cada fase tem produtos específicos e um processo de revisão.

Desvantagens

  • Todos os requisitos devem ser conhecidos antecipadamente.
  • Inibe a flexibilidade.
  • A integração é um “big bang” no final.
  • Pouca oportunidade do cliente pré-visualizar (preview) os produtos.
  • Depois que um aplicativo está em fase de testes, é muito difícil retroagir e mudar algo que não foi bem pensado na fase de conceito.
  • É difícil a adaptação as todas mudanças do projeto ou modificar e corrigir as etapas anteriores (a água não pode subir a cascata!) – Assim é necessário ser proativo, antecipando os problemas antes que possam afetar o fluxo de trabalho. (ter que “nadar contra a corrente”).
  • Não é um bom modelo para projetos complexos, longos ou contínuos.
  • Não é adequado para os projetos em que os requisitos tem um risco moderado ou alto de serem alterados.
  • Quantidades elevadas de riscos e incertezas quando os requisitos não são bem definidos e conhecidos.
  • Não reflete a natureza iterativa do desenvolvimento exploratório.

Quando usar

  • Requisitos são muito bem conhecidos, claros e fixos.
  • Tecnologia é compreendida.
  • Definição do produto é estável.
  • Nova versão de um produto já existente.
  • O projeto é curto.
  • Os recursos disponíveis com elevada experiência.
  • Quando existir necessidade de exatidão de prazos e de orçamento.

Deixe uma resposta