Considere que é preciso desenvolver um sistema cujos objetivos gerais são inicialmente conhecidos; porém, não se identificou muito bem quais são todos os requisitos (funcionais e não funcionais).
Apresente uma vantagem e uma desvantagem frequentemente encontradas quando o modelo incremental é utilizado para este sistema. Justifique a sua resposta utilizando exemplos do sistema especificado em sala de aula (trabalho da disciplina).

Passo 1

O que o enunciado pede:
  • Apresentar uma vantagem e uma desvantagem frequentemente encontradas ao usar o modelo incremental para um sistema cujo objetivo geral é conhecido, mas cujos requisitos (funcionais e não funcionais) não estão bem identificados.
  • Justificar cada ponto usando exemplos do sistema do trabalho da disciplina (ou seja, ligar a vantagem e a desvantagem a situações concretas desse sistema).
Informações dadas:
  • Objetivos gerais do sistema estão conhecidos.
  • Requisitos completos não foram bem identificados.
  • Deve-se usar exemplos práticos do sistema do trabalho da disciplina para justificar as afirmações.

Passo 2

Rápida explicação do que é o modelo incremental (para entendermos os prós/cons):
O modelo incremental consiste em construir o sistema por partes (incrementos). Cada incremento entrega um subconjunto funcional do produto final, de forma que o cliente/usuário possa usar e opinar desde cedo. Entre os incrementos ocorrem avaliação, ajuste de requisitos e planejamento do próximo incremento. Pontos importantes a ter em mente: entregas parciais, feedback iterativo, e evolução contínua do produto.

Passo 3

Vantagem frequente: entrega precoce e feedback que reduz incertezas.
Por que isso acontece (didático): quando os requisitos não estão claros, entregar uma primeira parcela funcional permite aos usuários ver concretamente como o sistema funciona, testar hipóteses e dizer “isso não é bem assim” ou “isso deveria também fazer X”. Esse feedback torna possível ajustar requisitos antes de gastar tempo desenvolvendo tudo errado. Além disso, funcionalidades críticas aparecem cedo, o que reduz risco do projeto (descobre-se cedo se a solução atende ou não às necessidades).
Exemplo aplicado ao trabalho da disciplina (exemplo prático): suponha que o sistema do trabalho seja um sistema de reservas/gestão (ou outro módulo central do trabalho). No primeiro incremento entrega-se apenas: autenticação, cadastro de salas/recursos e criação de reserva simples. Usuários começam a testar e dizem: “na verdade precisamos de reservas recorrentes e bloqueios por horário especial” — isso revela requisitos que não estavam claros no início. Como consequência, nos próximos incrementos pode-se priorizar a funcionalidade de reservas recorrentes e regras de bloqueio (em vez de gastar esforço em relatórios avançados que talvez não sejam necessários). Resultado: o time foca no que realmente importa e evita trabalho inútil.

Passo 4

Desvantagem frequente: risco de arquitetura frágil e acúmulo de dívida técnica que dificulta evolução.
Por que isso acontece (didático): ao priorizar entregas rápidas de incrementos, é comum projetar soluções simples e localizadas ao problema imediato. Se não houver cuidado em projetar uma base arquitetural estável (por exemplo, APIs coerentes, modelo de dados adequado e separação de camadas), features futuras podem exigir grande retrabalho, reorganização do banco ou reescrita de módulos — o que consome tempo e anula a vantagem das entregas incrementais.
Exemplo aplicado ao trabalho da disciplina (exemplo prático): imagine que, no primeiro incremento do sistema de gestão, optou‑se por salvar horários de reserva como strings simples e sem um modelo consistente (para acelerar o release). Posteriormente, quando for necessário adicionar fuso horário, recorrências e checagens de conflito avançadas, descobre‑se que o esquema de dados não suporta essas operações sem grande refatoração do banco e da lógica de negócio. Ou então a UI foi feita de forma ad hoc e, ao tentar oferecer um dashboard corporativo, é preciso refazer grande parte das telas. Isso mostra como uma decisão inicial feita para “entregar logo” pode gerar retrabalho caro nos incrementos seguintes.

Passo 5

Resumo das causas e dicas práticas (para a prova / para o time):
  • Por que a vantagem acontece: feedback real transforma requisitos vagos em requisitos acionáveis; prioriza o que agrega valor.
  • Por que a desvantagem ocorre: falta de visão arquitetural e cortes para acelerar entregas geram dívida técnica.
  • Como mitigar na prática (dica rápida que vale na prova): começar o projeto com um pequeno “spike” arquitetural (provar a forma do modelo de dados e APIs), definir um backbone estável (camadas, contratos de API) e reservar tempo de cada incremento para refatoração e testes automatizados. Assim preserva‑se a vantagem do incremental sem sofrer tanto a desvantagem.

Passo 6

Linguagem motivacional curta (pra você se animar): escolher o modelo incremental é uma ótima opção quando os requisitos são incertos — ele te dá respostas rápidas do usuário. Só precisa lembrar de proteger a arquitetura desde cedo; com isso você ganha velocidade sem se enredar em retrabalho. Vai dar certo — com cuidado dá para aproveitar o melhor dos dois mundos.

Resposta

Vantagem: Entregas parciais permitem obter feedback real dos usuários e refinar requisitos incertos — por exemplo, no trabalho da disciplina entregar primeiro o cadastro e criação básica de reservas revela que é prioritário implementar reservas recorrentes, evitando desenvolver funcionalidades irrelevantes.
Desvantagem: Pode causar acúmulo de dívida técnica e necessidade de grande refatoração se a arquitetura inicial for frágil — por exemplo, um esquema de dados simplista criado para acelerar o primeiro incremento pode obrigar a reescrever o banco e a lógica ao adicionar recorrência, fuso horário e checagem de conflitos.

Exercícios relacionados