Um requisito muda no meio do projeto. Se sua metodologia é process-driven de verdade, a resposta é simples: não muda, não agora. Isso soa rígido, e é — mas para o tipo certo de projeto, essa rigidez é exatamente o que garante previsibilidade, orçamento e documentação sólida do início ao fim.
Metodologias process-driven se baseiam num conjunto de passos que devem ser executados à risca durante o desenvolvimento. Geralmente esses passos seguem o SDLC clássico: levantamento de requisitos, planejamento e design, desenvolvimento, testes, implantação e manutenção — só que de forma mais engessada, sem espaço fácil para alterar a ordem ou o escopo pelo caminho.
Por que alguém escolheria isso
Os benefícios são reais: clareza e organização melhor do que será desenvolvido, documentação mais detalhada e explícita, e maior gerenciamento de risco — porque você evita problemas que só apareceriam ao longo de um desenvolvimento mais solto. Isso funciona muito bem quando o “caminho feliz” se aplica: os requisitos não mudam no percurso.
O problema aparece quando os requisitos mudam no meio do caminho. É aí que essas metodologias começam a doer — e é também aí que as metodologias ágeis, tema de outro artigo aqui do blog, começam a brilhar.
Cascata (Waterfall)
O modelo mais tradicional e mais fácil de entender. A analogia é literal: numa cascata, depois que a água cai, ela não sobe de volta. Uma vez que você avança de estágio — por exemplo, sai do levantamento de requisitos e entra no planejamento —, não tem mais volta para aquele estágio anterior. Assim segue até a entrega ao cliente, quando começa a fase de manutenção.
Vantagens: cada estágio funciona como um checkpoint claro — você sempre sabe dizer ao cliente em que fase está o projeto. E como a documentação precisa estar pronta e robusta antes de “descer a cascata”, você chega ao desenvolvimento com escopo bem definido.
Desvantagens: inflexibilidade total. Se no meio de uma feature você quer trocar a ordem ou inserir um requisito novo, não consegue — está tudo planejado para acontecer conforme a cascata avança. E existe risco grande de atraso em cascata literal: atrasou na codificação, atrasa o teste, atrasa a entrega.
Iterativo Incremental
Aqui você pega o escopo total do software e divide em partes pequenas. Cada vez que você finaliza uma parte, tem um incremento do software pronto — e o ciclo se repete (por isso “iterativo”) até todos os incrementos estarem entregues.
Vantagens: fica fácil adaptar uma característica nova, mudando a ordem de quando ela será implementada. Também reduz risco, porque separar o software em partes pequenas facilita identificar onde um problema específico está travando o avanço.
Desvantagens: o escopo pode ficar incontrolável — quanto mais incrementos você faz, mais fácil é o escopo crescer conforme problemas aparecem, e o retrabalho junto com ele.
Espiral
O foco aqui é gerenciamento de risco: você descobre se desenvolver determinada feature é benéfico antes de comprometer a solução final. Ideal para projetos complexos que exigem prova de conceito e validação de ideia antes de implementar de verdade.
O fluxo: você faz um pequeno incremento, planeja, faz análise e gerenciamento de risco, cria um protótipo. Uma vez validado esse protótipo, você o descarta e parte para a arquitetura do software final — codifica, testa, entrega (uma release). Depois o ciclo recomeça, criando literalmente uma espiral até o software terminar.
Vantagens: gerenciamento de risco mais efetivo, porque você está constantemente levantando riscos e validando protótipos. Maior flexibilidade para ajustes.
Desvantagens: consome tempo e, consequentemente, custo — você cria protótipo, descarta, começa de novo. E a documentação fica limitada, porque cada iteração documenta só aquela feature ou aquele protótipo específico.
Modelo V
É a evolução do modelo Cascata. A diferença é que cada fase de desenvolvimento tem uma fase de teste correspondente: levantamento de requisitos tem uma fase que testa se os requisitos levantados foram implementados conforme o esperado; design e arquitetura tem uma fase que verifica se aquela arquitetura atendeu bem ao projeto; código tem testes unitários, e assim por diante.
Vantagens: a qualidade do software é garantida quando você termina a execução, e a documentação final tende a ser melhor.
Desvantagens: alto consumo de tempo e recurso — você precisa validar todas as fases, e normalmente precisa de dois times (um que desenvolve, outro que testa), o que exige um time maior ou pessoas que poderiam estar em outra parte do projeto, mas estão dedicadas à fase de teste.
Quando usar cada uma
Um jeito rápido de decidir:
- Cascata ou Modelo V: requisitos bem definidos, que não vão sofrer mudança ao longo do projeto. Se você tem certeza do “caminho feliz”, esses modelos entregam previsibilidade e documentação sólida.
- Iterativo Incremental ou Espiral: casos que precisam de flexibilidade — alterar a ordem de implementação de uma feature — e que exigem feedback contínuo, seja porque o cliente pode mudar de ideia, seja porque você precisa validar uma ideia antes de comprometer a arquitetura.
O segredo para equilibrar qualidade, tempo e custo é escolher a metodologia que se adequa às suas necessidades reais, não a que está na moda. Metodologias process-driven são ótimas quando os requisitos não mudam no percurso — mas se você sabe, desde o início, que os requisitos vão mudar, esse é justamente o cenário onde as metodologias ágeis fazem mais sentido, assunto de outro artigo aqui no blog. Se quiser ver essas quatro metodologias detalhadas com mais exemplos, o vídeo “Como Escolher Metodologias Process-Driven” no canal FortShield cobre esse conteúdo na íntegra.
