Data de Publicação

03/10/2026

Data de Modificação

13/09/2026

Questionário e Gabarito - Aula 5: Qualidade e Recursos (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 5 (Aula 5). O prazo final geral (Milestone) é 20/09/2026 (Domingo).

Questão 1: O Custo Oculto da Não-Conformidade e a Regra 1:10:100

Due Date: 2026-09-20

Texto da Issue

Muitas equipes de software iniciantes pulam a fase de testes unitários e revisões de código sob a justificativa de “precisamos entregar logo, testamos tudo no final antes de subir”. Em Engenharia de Software, essa decisão é um erro matemático desastroso.

  1. Explique a diferença entre Custo de Conformidade (Prevenção e Avaliação) e Custo da Não-Conformidade (Falhas Internas e Falhas Externas), demonstrando como a Regra 1:10:100 pune financeiramente quem empurra a qualidade para o fim.
  2. O caso real no seu Projeto Integrador: Imagine que o seu Assistente I.A. foi lançado para os alunos de Programação e, devido a uma falha não testada, ele começa a fornecer o código completo da prova em vez de dar dicas socráticas. Classifique esse problema (Falha Interna ou Externa?) e descreva 1 ação preventiva de QA (no processo/pipeline) que sua equipe deveria ter implementado para barrar esse erro antes que ele chegasse ao usuário final.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente teóricas sem o cenário aplicado do projeto do seu grupo não receberão nota máxima.)

Gabarito / Rubrica de Correção

  • Excelente (10): Diferencia com exatidão Prevenção/Avaliação de Falhas Internas/Externas; aplica a regra 1:10:100; identifica a falha do assistente como Externa e propõe teste automatizado/filtro de prompt preventivo no CI/CD.
  • Bom (7): Explica a teoria do custo, mas a ação preventiva proposta é superficial (ex: “pedir pro colega olhar com mais atenção”).
  • Insuficiente (0): Confunde conformidade com não-conformidade ou não aplica ao projeto.

Questão 2: O Conflito do “Falso Pronto” (Critérios de Aceitação vs. Definition of Done)

Due Date: 2026-09-20

Texto da Issue

Um desenvolvedor conclui a tela do Assistente I.A., arrasta a Issue para Done e avisa no grupo: “Terminei!”. Minutos depois, o colega de time tenta rodar a aplicação e ela quebra porque não havia tratamento para API sem chave, os testes quebraram e não houve revisão de código. O desenvolvedor reclama: “Mas a tela tá pronta, funciona na minha máquina!”.

  1. Diferencie formalmente Critérios de Aceitação (específicos de uma história/issue) de Definition of Done - DoD (critério transversal de engenharia para o repositório).
  2. O DoD do seu time no GitLab: Liste os 4 itens mínimos que compõem o Definition of Done do seu Projeto Integrador para que um Merge Request possa ser aceito na branch main (ex: testes passando, aprovação de MR, etc.). Como o desrespeito ao DoD gera dívida técnica imediata para os outros membros do grupo?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Distingue que Critério de Aceitação é o O Quê/Negócio e DoD é o Como/Engenharia; lista 4 critérios técnicos claros do repositório do seu time e detalha o impacto de retrabalho gerado.
  • Bom (7): Entende a diferença, mas o DoD citado é vago ou não reflete o fluxo real no GitLab.
  • Insuficiente (0): Trata DoD e Critério de Aceitação como a mesma coisa.

Questão 3: O “Desenvolvedor Herói”, o Fator Ônibus e o Nivelamento

Due Date: 2026-09-20

Texto da Issue

Em equipes acadêmicas e profissionais, é comum a figura do “Desenvolvedor Herói” — o membro mais experiente que puxa para si todas as tarefas complexas (banco, infraestrutura, Docker e integração com LLM), deixando apenas correções cosméticas para os colegas novatos.

  1. Sob a ótica de Gestão de Recursos Humanos, explique por que a existência de um “Herói” é um perigo crítico para o projeto, conceituando Silo de Conhecimento e Fator Ônibus (Bus Factor).
  2. Nivelamento na sua equipe: Como a técnica de Nivelamento de Recursos (Resource Leveling) e práticas como Pair Programming ou Code Review cruzado devem ser aplicadas no seu Projeto Integrador para garantir que a carga de trabalho fique distribuída e o conhecimento da arquitetura não fique na cabeça de uma única pessoa?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Demonstra que Bus Factor = 1 é fragilidade estrutural; explica como o nivelamento equilibra o cronograma e cita ações práticas de compartilhamento de conhecimento no seu grupo.
  • Bom (7): Aponta que o herói pode ficar sobrecarregado, mas não articula o conceito de nivelamento nem de silos técnicos.
  • Insuficiente (0): Defende que ter um desenvolvedor concentrando tudo é positivo por ser mais rápido.

Questão 4: A Matriz RACI e a Autoridade Única no Merge Request

Due Date: 2026-09-20

Texto da Issue

“Se todo mundo é responsável por aprovar, ninguém se sente responsável por nada.”
Na Matriz RACI (Responsible, Accountable, Consulted, Informed), existe uma regra pétrea: só pode haver exatamente UM ‘A’ (Accountable) por atividade.

  1. Explique por que a sobreposição de múltiplos ‘A’ na mesma tarefa gera paralisia decisória ou o fenômeno do “jogo de empurra” em momentos de falha crítica.
  2. Tradução para o GitLab do seu grupo: Em um Merge Request (MR) crítico que adiciona uma nova regra socrática ao assistente:
    • Quem do seu grupo atua como o R (Assignee)?
    • Quem atua como o único A (Reviewer encarregado de dar Merge)?
    • Quem é C (consultado antes do merge)?
    • Quem é I (informado via @menção após o merge)?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Justifica com clareza a unicidade do ‘A’ na governança; mapeia com precisão os 4 papéis do RACI diretamente nas funcionalidades do GitLab do time (Assignee, Reviewer, Discussão, Notificação).
  • Bom (7): Entende o RACI, mas erra na correlação com os mecanismos do GitLab (confunde R com A).
  • Insuficiente (0): Não define o RACI ou sugere que múltiplos ‘A’ é boa prática.

Questão 5: A Economia da I.A. e o Fim do Custo Marginal Zero

Due Date: 2026-09-20

Texto da Issue

No modelo tradicional de software (SaaS), o custo marginal de atender um novo usuário é praticamente zero após o sistema estar pronto. Na era dos sistemas baseados em Inteligência Artificial Generativa, esse paradigma foi quebrado.

  1. Explique por que soluções que consomem LLMs não possuem custo marginal zero e por que lançar um Assistente de I.A. cobrando uma “assinatura fixa barata com uso ilimitado” pode falir uma startup em poucas semanas.
  2. O custo do seu Assistente: No projeto do seu grupo, cite 2 decisões arquiteturais ou de processo (ex: cache semântico, modelos menores para triagem, limite de contexto de prompt, controle de tokens por sessão) que reduzem os custos variáveis de inferência sem prejudicar a experiência do usuário.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

  • Excelente (10): Relaciona o consumo contínuo de GPU/tokens ao custo marginal real por requisição; demonstra o risco da assimetria entre receita fixa e custo variável de API; propõe 2 otimizações técnicas concretas e viáveis para o assistente.
  • Bom (7): Entende que LLM gasta por token, mas não sabe propor soluções arquiteturais para mitigar o custo.
  • Insuficiente (0): Acha que software com IA tem custo fixo após o desenvolvimento.
De volta ao topo