Questão de Engenharia de Software — Processos de Software — FUNDATEC 2025
Engenharia de Software›Processos de Software
Código
qg484505
Banca
FUNDATEC
Órgão
UFRGS
Ano
2025
Nível
Médio
Cargo
Técnico em Tecnologia da Informação/Área: Sistemas de Informação
No contexto da Engenharia de Software Clássica, o Modelo de Ciclo de Vida em Cascata (Waterfall) é frequentemente criticado por sua natureza sequencial e linear. A principal desvantagem arquitetural que frequentemente leva a desafios significativos no projeto e, consequentemente, a insucesso, reside no fato de que:
AEle prioriza a entrega contínua (continuous delivery) de funcionalidades incrementais, exigindo grande esforço de integração tardiamente no ciclo.
BSua estrutura é intrinsecamente incompatível com as Especificações de Requisitos de Software (ERS) detalhadas, promovendo a codificação prematura.
CA exigência de concluir formalmente cada fase antes da seguinte reduz drasticamente a capacidade de absorver feedback ou mudanças posteriores.
DO alto índice de reutilização de código e componentes intrínseco ao modelo resulta em baixa produtividade em projetos de grande escala.
EA metodologia promove ativamente a integração e o teste contínuo (continuous integration), o que onera as etapas iniciais de análise e projeto.
Revelar gabarito e comentário▾
GabaritoC — A exigência de concluir formalmente cada fase antes da seguinte reduz drasticamente a capacidade de absorver feedback ou mudanças posteriores.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Gabarito: letra C. A principal desvantagem do modelo cascata é sua rigidez: cada fase deve ser concluída formalmente antes de iniciar a próxima, o que praticamente inviabiliza a incorporação de feedback ou mudanças tardias, pois o retorno a fases anteriores é custoso ou proibido. Essa característica é amplamente descrita na literatura de Engenharia de Software (ex.: Pressman, Sommerville).
O modelo cascata é sequencial e linear: o resultado de cada estágio é a aprovação de documentos, e o estágio seguinte só começa após a conclusão do anterior. Isso dificulta a adaptação a requisitos que evoluem, sendo adequado apenas quando os requisitos são bem compreendidos e estáveis.
1Requisitos (ERS)
2Projeto
3Implementação
4Testes
5Implantação
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A alternativa afirma que o modelo prioriza entrega contínua de funcionalidades incrementais, o que é típico de métodos ágeis (Scrum, XP), não do cascata. No cascata, a entrega ocorre apenas ao final do ciclo, e a integração é feita de uma só vez, mas isso não é uma vantagem nem desvantagem apontada como principal.
Alternativa B — ❌ Incorreta
O modelo cascata é plenamente compatível com Especificações de Requisitos de Software (ERS) detalhadas – na verdade, exige que os requisitos sejam definidos e documentados completamente na fase inicial. A codificação prematura não é incentivada; pelo contrário, o desenvolvimento só começa após a aprovação dos requisitos e do projeto.
Alternativa C — ✅ Correta ⟵ GABARITO
A descrição está correta: a natureza sequencial com fases estanques reduz drasticamente a capacidade de absorver feedback ou mudanças posteriores. Como cada fase depende da conclusão da anterior, qualquer alteração tardia exige retrabalho em cascata, com alto custo. Essa é a crítica central ao modelo.
Alternativa D — ❌ Incorreta
O modelo cascata não é conhecido por alto índice de reutilização de código. A reutilização é mais associada a modelos orientados a objetos ou componentes. No cascata, o foco está no desenvolvimento linear, e a produtividade em projetos de grande escala é baixa justamente pela rigidez, não por reutilização.
Alternativa E — ❌ Incorreta
O cascata não promove integração e teste contínuos; a integração normalmente ocorre ao final, e os testes são realizados apenas após a codificação. Métodos ágeis ou DevOps é que defendem integração contínua. As etapas iniciais de análise e projeto são longas, mas não por causa de testes contínuos.