Questão de Engenharia de Software — Geral — VUNESP 2025

Modelo em Cascata (Waterfall)

Gabarito: letra A. O modelo em cascata é uma abordagem sequencial de desenvolvimento de software, em que cada fase só se inicia após a conclusão e aprovação da fase anterior — exatamente o que a alternativa A descreve. Essa é a definição clássica do modelo, também chamado de clássico, linear, tradicional ou waterfall.

O modelo em cascata é um dos modelos de processo de software mais tradicionais e cobrados em concursos. Ele organiza o desenvolvimento em fases bem definidas e encadeadas: planejamento, análise e especificação de requisitos, projeto, implementação, testes, entrega e implantação, operação e manutenção. A característica central é o fluxo sequencial: a saída de uma fase é a entrada da próxima, e não se volta a fases anteriores — daí a metáfora da "cascata", que flui sempre para frente.

Essa abordagem é preferencialmente utilizada quando os requisitos são bem compreendidos desde o início e há pouca probabilidade de mudanças radicais. Sua principal desvantagem é o atraso na redução de riscos: como só se verifica se houve erros nas últimas fases, um problema identificado tarde pode ser muito caro para corrigir. Por outro lado, sua vantagem é a simplicidade de entender e controlar, já que cada fase tem entregas claras e o progresso é facilmente mensurável.

É importante distinguir o modelo em cascata dos modelos iterativos e incrementais, como o Scrum e o XP. Enquanto a cascata é sequencial e rígida, os modelos ágeis são iterativos (produzem versões melhoradas continuamente) e incrementais (entregam partes do software em builds). Essa distinção é a chave para resolver esta questão: a alternativa B descreve justamente a abordagem ágil, não a cascata.

A banca explora aqui a confusão entre o modelo em cascata e outras metodologias ou conceitos da engenharia de software. As alternativas C, D e E misturam elementos que não fazem parte da definição do modelo em cascata: UML é uma linguagem de modelagem, Arquitetura Limpa é um estilo arquitetural proposto por Robert Martin, e não há qualquer restrição de tamanho de equipe no modelo. Guarde a fronteira entre sequencial e iterativo: é exatamente nela que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa descreve com precisão a essência do modelo em cascata: abordagem sequencial, em que cada fase é concluída antes de passar para a próxima. Essa é a definição clássica do modelo, também chamado de clássico, linear, tradicional ou waterfall. O encadeamento simples entre as fases — uma fase só se inicia após o término e aprovação da anterior — é a característica que define o modelo.

Alternativa B — ❌ Incorreta

A alternativa descreve a abordagem iterativa e incremental, que é característica dos modelos ágeis (Scrum, XP) e de outros modelos como o incremental e o espiral. O modelo em cascata é o oposto: é sequencial, linear e rígido, sem iterações ou incrementos. A banca troca o modelo sequencial pelo modelo iterativo para confundir o candidato.

Alternativa C — ❌ Incorreta

A UML (Unified Modeling Language) é uma linguagem de modelagem visual usada para especificar, visualizar, construir e documentar artefatos de software. Ela não é base fundamental do modelo em cascata — é uma ferramenta que pode ser usada em diversos processos, mas não define o modelo. A cascata pode ser aplicada com ou sem UML.

Alternativa D — ❌ Incorreta

A Arquitetura Limpa (Clean Architecture) é um estilo arquitetural proposto por Robert C. Martin (Uncle Bob), que organiza o software em camadas concêntricas com dependências apontando para dentro. Não é base fundamental do modelo em cascata, que é um modelo de processo, não um estilo arquitetural. A banca mistura conceitos de processo com conceitos de arquitetura.

Alternativa E — ❌ Incorreta

Não há qualquer restrição de tamanho de equipe no modelo em cascata. Ele pode ser aplicado a equipes de qualquer tamanho, embora seja mais adequado a projetos com requisitos bem definidos e pouca mudança. A afirmação de que se aplica "exclusivamente" a equipes de até 5 desenvolvedores é uma generalização indevida, sem fundamento na literatura.

Gabarito: letra A