Architecture

Quando Seguir a Receita Falha: Repensando o Modelo Cascata

Conceitos e práticas de desenvolvimento de software

Série: Fundamentos de Engenharia de Software | Parte 3 de 19 > Ministrada na Universidade Potiguar (UnP) em 2010

Na terceira aula do curso de Engenharia de Software na Universidade Potiguar (UnP), mergulhamos em abordagens de processo definido — com foco no conhecido modelo cascata. Mas mais do que memorizar estágios e sequências, esta aula foi sobre contexto, reflexão e adaptabilidade.

Quando seguir a sequência é melhor?

Abrimos a aula com uma provocação direta: quando faz sentido seguir uma sequência rígida de passos? Para isso, recorremos a uma analogia simples: como você soma dois números?

A ideia é trazer clareza sobre a diferença entre processos definidos e empíricos. Um processo definido pressupõe que entendemos bem os passos, os riscos e os resultados. Ele é eficaz em contextos onde a previsibilidade é alta. Por outro lado, em ambientes mais incertos, a abordagem empírica — baseada em inspeção e adaptação — se mostra mais eficaz.

Atividade: Classificando contextos

A primeira atividade da aula consistiu em dividir os alunos em grupos para analisarem cenários reais ou fictícios e responderem: este é um processo definido ou empírico? Para cada resposta, era necessário justificar com base nos componentes do ambiente.

Essa dinâmica é excelente para equipes em empresas também. Basta adaptar os cenários para produtos ou processos internos e promover um debate: onde nossa abordagem atual se encaixa? O objetivo é estimular o discernimento entre controle e adaptação — algo fundamental tanto para alunos quanto para times de produto.

O modelo cascata com olhos críticos

Na segunda parte, apresentamos o modelo clássico de ciclo de vida: levantamento de requisitos, análise, projeto, implementação, testes e manutenção. Um passo após o outro, como numa receita.

Mas fomos além da sequência. Discutimos o Big Design Up Front (BDUF) e as razões históricas por trás dessa abordagem. Introduzimos o gráfico de Barry Boehm sobre o custo de mudanças ao longo do projeto, mostrando que antecipar decisões fazia sentido em uma era de projetos de meses e deploys raros.

Também usamos analogias como “construir um prédio” para exemplificar o racional por trás da rigidez do modelo. Ainda assim, deixamos claro que rigidez e clareza são coisas diferentes — e que projetos modernos exigem flexibilidade sem sacrificar planejamento.

Problemas no mundo real

Na terceira parte da aula, o debate girou em torno das falhas do modelo em ambientes reais. O prédio pode ser movido de lugar depois de construído? O software precisa esperar tudo estar pronto para começar a entregar valor?

Trouxemos trechos da literatura clássica que expõem as limitações do modelo em contextos imprevisíveis. Também refletimos sobre o papel da supervisão e do acompanhamento ativo (“o boi só engorda no olho do dono”), questionando o excesso de confiança em documentos e cronogramas.

Para facilitar com profundidade

Se você quiser aplicar uma aula ou workshop com esse conteúdo, comece com provocações simples e progressivas. Use analogias do cotidiano para explicar conceitos técnicos. Estimule atividades que contrastem modelos com a realidade da turma.

E, acima de tudo, não transforme o modelo cascata em vilão. Mostre que ele é uma das ferramentas do engenheiro de software — útil em certos contextos e limitada em outros. O que queremos é formar pensadores críticos, não apenas seguidores de método.

Publicado como parte do diário de aula da disciplina de Engenharia de Software. Hoje, refletimos sobre receitas, projetos e a importância de pensar antes de seguir qualquer processo.