# 📋 Gabarito Positivo e Negativo - Prova Teórica 1: Gestão de Projetos de Software

**Disciplina:** Gestão de Projetos de Software  
**Curso:** Engenharia de Computação - 2º Período  
**Professor:** Aléssio M. Júnior  
**Valor Total:** 25 pontos

***

## 🎯 **Critérios de Avaliação Geral**

- **Excelente (90-100% dos pontos):** Resposta completa, técnica, demonstra conhecimento profundo, integração de conceitos, exemplos práticos relevantes
- **Bom (70-89% dos pontos):** Resposta adequada, alguns aspectos técnicos, conhecimento satisfatório, alguns exemplos
- **Regular (50-69% dos pontos):** Resposta básica, poucos aspectos técnicos, conhecimento limitado, exemplos genéricos
- **Insuficiente (0-49% dos pontos):** Resposta incompleta, erros conceituais, conhecimento inadequado, falta de exemplos

***

## 📚 **GABARITO DETALHADO: RESPOSTAS POSITIVAS E NEGATIVAS**

### **Questão 1 (3 pontos): Programar vs Engenharia de Software e Gestão de Projetos**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 3 pontos)**

**Programar:**
- Atividade técnica de codificação
- Foco na implementação de funcionalidades específicas
- Escrever código seguindo lógica e sintaxe de uma linguagem
- Atividade pontual e específica

**Fazer Engenharia de Software:**
- Disciplina abrangente que inclui múltiplas atividades:
  - Análise de requisitos
  - Design e arquitetura
  - Implementação (codificação)
  - Testes e validação
  - Manutenção e evolução
  - Gestão de qualidade
  - Gestão de projeto
- Processo sistemático e disciplinado
- Considera todo o ciclo de vida do software

**Relação com Gestão de Projetos:**
- Gestão de Projetos organiza e coordena as atividades de Engenharia de Software
- Garante que o processo de desenvolvimento seja eficiente e eficaz
- Facilita a comunicação entre stakeholders
- Controla recursos, tempo, custo e qualidade

**Papel do Gerente de Projetos:**
- Planejamento e controle do projeto
- Comunicação entre stakeholders
- Alocação de recursos
- Gestão de riscos
- Mediação de conflitos
- Garantir que objetivos sejam alcançados

**Exemplo Prático - Projeto Portfólio:**
- **Programar:** Escrever código HTML/CSS para criar a página de perfil de um membro da equipe
- **Engenharia de Software:** Definir a estrutura do site, escolher tecnologia (Hugo), planejar arquitetura, definir padrões de código, planejar testes
- **Gestão de Projetos:** Organizar equipe, definir prazos, controlar entregas, gerenciar issues no GitLab, coordenar sprints

**Distribuição de Pontos:**
- Diferença programar vs engenharia de software: 1 ponto
- Relação com gestão de projetos: 0,5 pontos
- Papel do gerente de projetos: 0,5 pontos
- Exemplos práticos do Portfólio: 1 ponto

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-1 ponto)**

**Erros Comuns:**
- Confundir programar com engenharia de software (tratá-los como sinônimos)
- Não diferenciar claramente os conceitos
- Não explicar a relação com gestão de projetos
- Papel do gerente de projetos muito vago ou incorreto
- Falta de exemplos práticos ou exemplos genéricos demais

**Exemplo de Resposta Incorreta:**
> "Programar é fazer engenharia de software. O gerente de projetos é quem programa. No projeto Portfólio, programamos o site."

**Por que está errado:**
- Não diferencia os conceitos
- Papel do gerente de projetos incorreto
- Exemplo muito genérico e sem detalhamento

***

### **Questão 2 (5 pontos): Viabilidade e Project Charter**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 5 pontos)**

**Tipos de Viabilidade:**

1. **Viabilidade Técnica:**
   - Recursos técnicos disponíveis
   - Tecnologias necessárias
   - Competências da equipe
   - Infraestrutura técnica

2. **Viabilidade Econômica:**
   - Custos do projeto
   - Benefícios esperados
   - ROI (Retorno sobre Investimento)
   - Recursos financeiros disponíveis

3. **Viabilidade Operacional:**
   - Processos organizacionais
   - Pessoas e capacidades
   - Infraestrutura operacional
   - Capacidade de operação e manutenção

4. **Outros tipos (opcional):**
   - Legal: Conformidade, regulamentações
   - Temporal: Prazos e cronograma
   - Organizacional: Estrutura e cultura

**Critérios para Projeto Portfólio:**

**Viabilidade Técnica:**
- Conhecimento de HTML/CSS/JavaScript pela equipe
- Disponibilidade de Hugo e GitLab
- Competência da equipe em desenvolvimento web
- **Justificativa:** Garantir que equipe possui habilidades técnicas necessárias para desenvolver o site

**Viabilidade Econômica:**
- Custos de hospedagem (se houver) - GitLab Pages é gratuito
- Tempo investido pela equipe (custo de oportunidade)
- Benefício: Portfólio profissional, aprendizado, experiência
- **Justificativa:** Validar que benefícios (aprendizado, portfólio) superam custos (tempo investido)

**Viabilidade Operacional:**
- Tempo disponível dos membros da equipe
- Infraestrutura (computadores, internet)
- Processos de trabalho em equipe
- Capacidade de manter e atualizar o site
- **Justificativa:** Garantir que projeto pode ser executado na prática com recursos disponíveis

**Project Charter:**

**Definição:**
- Documento que autoriza formalmente o início do projeto
- Define objetivos, escopo inicial e recursos
- Define autoridade do gerente de projetos
- Estabelece contexto e limites do projeto

**Elementos Principais:**
- Objetivos e justificativa do projeto
- Escopo inicial (alto nível)
- Stakeholders principais
- Recursos necessários
- Riscos iniciais identificados
- Critérios de sucesso
- Restrições e premissas
- Orçamento inicial (se aplicável)
- Autoridade do gerente de projetos

**Relação com Processo de Iniciação:**
- Primeiro documento formal do projeto
- Autoriza início do trabalho
- Base para planejamento detalhado
- Comunica projeto aos stakeholders
- Estabelece contexto e limites
- Formaliza compromisso com o projeto

**Distribuição de Pontos:**
- Tipos de viabilidade (3-6 tipos): 1,5 pontos
- Exemplos práticos do Portfólio (técnica, econômica, operacional): 1,5 pontos
- Justificativa da importância: 0,5 pontos
- Definição e importância do Project Charter: 0,5 pontos
- Elementos essenciais (5-7 itens): 1 ponto
- Relação com processo de iniciação: 0,5 pontos

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-2 pontos)**

**Erros Comuns:**
- Listar apenas 1-2 tipos de viabilidade
- Não fornecer exemplos práticos do Portfólio
- Exemplos genéricos sem conexão com o projeto
- Não justificar importância dos tipos de viabilidade
- Project Charter definido incorretamente ou de forma muito vaga
- Elementos do Project Charter incompletos (menos de 3 itens)
- Não relacionar Project Charter com processo de iniciação

**Exemplo de Resposta Incorreta:**
> "Viabilidade técnica é saber programar. Viabilidade econômica é ter dinheiro. Project Charter é um documento que autoriza o projeto."

**Por que está errado:**
- Definições muito vagas e superficiais
- Falta de exemplos práticos do Portfólio
- Não justifica importância
- Project Charter sem elementos principais
- Não relaciona com processo de iniciação

***

### **Questão 4 (3 pontos): Escopo e Requisitos**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 3 pontos)**

**Escopo do Projeto:**
- Trabalho necessário para entregar o produto
- Inclui todas as atividades de gestão, planejamento, execução e controle
- Exemplo: Criar EAP, planejar sprints, desenvolver site, fazer testes, documentar

**Escopo do Produto:**
- Características e funções do produto final
- Foco nas funcionalidades e entregas do produto
- Exemplo: Páginas do site, navegação, formulário de contato, perfis dos membros

**Requisitos Funcionais (O QUE o sistema deve fazer):**
- Funcionalidades específicas do sistema
- O que o sistema deve fazer
- Exemplos para Projeto Portfólio:
  1. Página principal com apresentação da equipe
  2. Navegação entre páginas de perfil dos membros
  3. Formulário de contato funcional
  4. Exibição de projetos realizados

**Requisitos Não Funcionais (COMO o sistema deve funcionar):**
- Características de qualidade e performance
- Como o sistema deve funcionar
- Exemplos para Projeto Portfólio:
  1. Carregamento em menos de 3 segundos
  2. Design responsivo (mobile, tablet e desktop)
  3. Compatibilidade com navegadores modernos (Chrome, Firefox, Edge)
  4. Acessibilidade (WCAG básico)

**Distribuição de Pontos:**
- Diferença escopo projeto vs produto: 1 ponto
- Diferença requisitos funcionais vs não funcionais: 1 ponto
- Exemplos do Portfólio (2 de cada tipo): 1 ponto

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-1 ponto)**

**Erros Comuns:**
- Confundir escopo do projeto com escopo do produto
- Não diferenciar claramente requisitos funcionais e não funcionais
- Exemplos genéricos sem conexão com o Portfólio
- Menos de 2 exemplos de cada tipo
- Exemplos incorretos (ex: classificar requisito não funcional como funcional)

**Exemplo de Resposta Incorreta:**
> "Escopo do projeto é o que vai ser feito. Escopo do produto é o produto. Requisitos funcionais são os que funcionam. Requisitos não funcionais são os que não funcionam."

**Por que está errado:**
- Definições muito vagas
- Não diferencia corretamente os conceitos
- Interpretação incorreta de requisitos não funcionais
- Falta de exemplos práticos

***

### **Questão 5 (3 pontos): Estrutura Analítica do Projeto (EAP)**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 3 pontos)**

**Definição de EAP:**
- Decomposição hierárquica do trabalho do projeto
- Organiza trabalho em entregas e componentes
- Estrutura em níveis progressivos de detalhamento
- Ferramenta fundamental para planejamento

**Três Níveis Típicos:**
1. **Nível 1:** Projeto completo (visão macro)
2. **Nível 2:** Fases ou grandes entregas (visão intermediária)
3. **Nível 3:** Pacotes de trabalho ou componentes específicos (visão detalhada)

**Exemplo Simplificado - Projeto Portfólio:**

```
Nível 1: Projeto Portfólio de Equipe
    |
    ├─ Nível 2: Planejamento e Setup
    |   ├─ Nível 3: Project Charter
    |   ├─ Nível 3: Estrutura GitLab (repositório, issues, milestones)
    |   └─ Nível 3: Configuração Hugo (instalação, tema, estrutura)
    |
    ├─ Nível 2: Desenvolvimento
    |   ├─ Nível 3: Página Inicial (homepage)
    |   ├─ Nível 3: Páginas de Perfil (perfil de cada membro)
    |   └─ Nível 3: Formulário de Contato
    |
    └─ Nível 2: Deploy e Documentação
        ├─ Nível 3: Configuração CI/CD (GitLab CI)
        ├─ Nível 3: Deploy do Site (GitLab Pages)
        └─ Nível 3: Documentação Final (README, guias)
```

**Distribuição de Pontos:**
- Definição de EAP: 1 ponto
- Três níveis explicados: 0,5 pontos
- Exemplo construído com 3 níveis e entregas: 1,5 pontos

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-1 ponto)**

**Erros Comuns:**
- Definição de EAP incorreta ou muito vaga
- Não explicar os três níveis
- Exemplo sem hierarquia clara (menos de 3 níveis)
- Exemplo genérico sem conexão com o Portfólio
- Estrutura confusa ou sem entregas identificáveis

**Exemplo de Resposta Incorreta:**
> "EAP é uma lista de tarefas. Nível 1 é o projeto, nível 2 são as tarefas. Exemplo: Fazer site, programar, testar."

**Por que está errado:**
- Definição muito simplificada
- Não explica adequadamente os níveis
- Exemplo sem hierarquia adequada
- Falta de detalhamento e entregas específicas

***

### **Questão 6 (3 pontos): Custo da Qualidade e Controle de Qualidade**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 3 pontos)**

**Conceito de Custo da Qualidade:**
- Custo total associado à garantia de qualidade do produto
- Inclui custos de prevenir problemas e custos de corrigir problemas
- Investir em prevenção reduz custos totais a longo prazo
- Filosofia: "Prevenir é mais barato que corrigir"

**Custos de Conformidade (Prevenção e Avaliação):**
- **Prevenção:** Planejamento de qualidade, treinamento, processos bem definidos, design cuidadoso
- **Avaliação:** Testes, inspeções, auditorias, revisões de código, validações

**Custos de Não Conformidade (Falhas):**
- **Falhas Internas:** Retrabalho, scrap, correções antes da entrega ao cliente
- **Falhas Externas:** Garantia, perda de clientes, retificações pós-entrega, danos à reputação

**Exemplos Práticos - Projeto Portfólio:**

**Custos de Conformidade:**
- Tempo para planejar estrutura do site (prevenção)
- Revisões de código entre membros (avaliação)
- Testes de funcionalidades antes do deploy (avaliação)
- Estabelecer padrões de código (prevenção)

**Custos de Não Conformidade:**
- Retrabalho devido a bugs não detectados (falha interna)
- Perda de credibilidade se site tiver problemas (falha externa)
- Tempo para corrigir erros pós-deploy (falha externa)
- Reescrita de código mal planejado (falha interna)

**Processo de Controle de Qualidade:**
1. **Medir:** Coletar dados de qualidade (bugs, tempo de carregamento, etc.)
2. **Comparar:** Analisar contra padrões/critérios estabelecidos
3. **Analisar:** Identificar causas de problemas
4. **Corrigir:** Implementar melhorias e correções

**Plano de Controle para Portfólio:**
- Definir critérios de aceitação claros para cada funcionalidade
- Estabelecer pontos de verificação (checkpoints) em cada sprint
- Criar lista de verificação (checklist) de requisitos
- Realizar testes sistemáticos antes de cada merge

**Técnicas de Controle de Qualidade (mínimo 3):**
1. **Inspeção:** Revisão manual de código e design
2. **Testes:** Testes funcionais, de usabilidade, responsividade
3. **Peer Review:** Revisão entre pares antes de merge no GitLab
4. **Validação com Stakeholders:** Feedback dos usuários/testadores
5. **Métricas:** Medição de performance (tempo de carregamento, acessibilidade)
6. **Checklist:** Lista de verificação de requisitos funcionais e não funcionais

**Importância do Investimento em Ações Preventivas:**
- Previne problemas antes que ocorram
- Reduz custos totais a longo prazo
- Melhora qualidade do produto final
- Aumenta satisfação do cliente/usuário
- Evita retrabalho e atrasos
- Melhora reputação e credibilidade

**Distribuição de Pontos:**
- Conceito de custo da qualidade: 0,5 pontos
- Diferença conformidade vs não conformidade: 0,5 pontos
- Exemplos práticos do Portfólio: 0,5 pontos
- Processo de controle de qualidade: 0,5 pontos
- Plano de controle para Portfólio: 0,5 pontos
- Técnicas (3+ técnicas): 0,5 pontos
- Importância da prevenção: 0,5 pontos (bonus se mencionado)

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-1 ponto)**

**Erros Comuns:**
- Não diferenciar custos de conformidade e não conformidade
- Exemplos genéricos sem conexão com o Portfólio
- Processo de controle de qualidade não explicado
- Plano de controle muito vago ou ausente
- Menos de 3 técnicas de controle mencionadas
- Não mencionar importância da prevenção
- Confundir controle de qualidade com garantia de qualidade

**Exemplo de Resposta Incorreta:**
> "Custo da qualidade é o dinheiro gasto. Controle de qualidade é testar. Técnicas: testar, revisar, verificar."

**Por que está errado:**
- Definições muito vagas
- Não diferencia custos de conformidade e não conformidade
- Falta de exemplos práticos
- Técnicas muito genéricas sem detalhamento
- Não menciona processo ou plano de controle

***

### **Questão 7 (3 pontos): Gestão de Riscos e Documentação**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 3 pontos)**

**Conceito de Risco:**
- Evento ou condição incerta que pode afetar objetivos do projeto
- Pode ser negativo (ameaça) ou positivo (oportunidade)
- Caracterizado por probabilidade e impacto
- Requer identificação, análise e resposta

**Risco Negativo (Ameaça):**
- Pode causar danos ao projeto (atrasos, custos, qualidade)
- Requer estratégias: Evitar, Transferir, Mitigar, Aceitar
- Exemplo: Falta de conhecimento técnico da equipe

**Risco Positivo (Oportunidade):**
- Pode trazer benefícios ao projeto (aceleração, economia, melhorias)
- Requer estratégias: Explorar, Compartilhar, Melhorar, Aceitar
- Exemplo: Descoberta de tecnologia mais eficiente

**Dois Riscos Reais para Projeto Portfólio:**

**Risco 1: Dificuldade da equipe em usar Hugo**
- **Tipo:** Ameaça (negativo)
- **Probabilidade:** Alta
- **Impacto:** Alto
- **Classificação:** Crítico (Alta probabilidade + Alto impacto)
- **Estratégia:** Mitigar - Treinar equipe, fornecer documentação, tutoriais, apoio técnico

**Risco 2: Conflitos de versão no Git**
- **Tipo:** Ameaça (negativo)
- **Probabilidade:** Média
- **Impacto:** Médio
- **Classificação:** Médio (Média probabilidade + Médio impacto)
- **Estratégia:** Mitigar - Estabelecer práticas Git, branch protection, code review obrigatório

**Como a Documentação Ajuda na Gestão de Riscos:**

**Identificação:**
- Matriz de riscos documenta todos os riscos identificados
- Brainstorming documentado em atas de reunião
- Histórico de projetos anteriores (lições aprendidas)

**Exposição:**
- Matriz de riscos visualiza probabilidade e impacto
- Registro de riscos comunica riscos aos stakeholders
- Relatórios de status incluem riscos ativos

**Mitigação:**
- Plano de ação documenta estratégias de resposta
- Atas de reunião registram decisões sobre riscos
- Histórico de mudanças mostra evolução dos riscos
- Documentação técnica ajuda prevenir riscos técnicos

**Exemplos Concretos de Documentos:**
1. **Matriz de Riscos:** Tabela com riscos, probabilidade, impacto e estratégias
2. **Atas de Reunião:** Registro de discussões sobre riscos e decisões
3. **Histórico de Mudanças:** Rastreamento de mudanças que podem gerar novos riscos
4. **Plano de Ação:** Documento com ações específicas para mitigar riscos
5. **Registro de Riscos:** Lista detalhada de todos os riscos do projeto

**Distribuição de Pontos:**
- Conceito de risco (negativo vs positivo): 0,5 pontos
- Dois riscos reais do Portfólio com classificação: 1 ponto
- Como documentação ajuda (identificação, exposição, mitigação): 1 ponto
- Exemplos concretos de documentos (2-3 documentos): 0,5 pontos

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-1 ponto)**

**Erros Comuns:**
- Não diferenciar risco negativo e positivo
- Riscos genéricos sem conexão com o Portfólio
- Classificação de probabilidade/impacto incorreta ou ausente
- Não explicar como documentação ajuda na gestão de riscos
- Exemplos de documentos muito vagos ou incorretos
- Menos de 2 riscos citados
- Riscos irreais ou não relevantes

**Exemplo de Resposta Incorreta:**
> "Risco é algo que pode dar errado. Risco negativo é ruim, positivo é bom. Exemplo: site não funcionar. Documentação ajuda porque documenta."

**Por que está errado:**
- Definições muito vagas
- Não diferencia adequadamente riscos negativos e positivos
- Risco genérico sem classificação
- Explicação sobre documentação muito superficial
- Falta de exemplos concretos de documentos

***

### **Questão 8 (2 pontos): Desafios nos Checkpoints 1 e 2**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 2 pontos)**

**Estrutura da Resposta:**
- Desafio no Checkpoint 1: descrição clara e específica
- Papel do aluno no Checkpoint 1: ações, contribuições, aprendizados
- Desafio no Checkpoint 2: descrição clara e específica
- Papel do aluno no Checkpoint 2: ações, contribuições, aprendizados

**Exemplo de Resposta Positiva:**

**Checkpoint 1 - Desafio:**
- Configuração inicial do GitLab e criação da estrutura do projeto
- Dificuldade em entender como organizar issues e milestones
- Coordenação inicial da equipe para definir escopo

**Meu Papel no Checkpoint 1:**
- Pesquisei documentação do GitLab e criei tutorial para equipe
- Organizei reunião para alinhar escopo do projeto
- Criei template de issues para padronizar trabalho
- Aprendi importância de documentação e comunicação clara

**Checkpoint 2 - Desafio:**
- Criação do documento de projeto (Project Charter) completo
- Dificuldade em estimar prazos realistas
- Gestão de riscos e identificação de dependências

**Meu Papel no Checkpoint 2:**
- Liderou criação do Project Charter, organizando contribuições da equipe
- Pesquisou técnicas de estimativa e aplicou no cronograma
- Identificou riscos principais e criou matriz de riscos
- Aprendi importância de planejamento detalhado e realismo nas estimativas

**Distribuição de Pontos:**
- Desafio no Checkpoint 1 descrito: 0,5 pontos
- Papel do aluno no Checkpoint 1: 0,5 pontos
- Desafio no Checkpoint 2 descrito: 0,5 pontos
- Papel do aluno no Checkpoint 2: 0,5 pontos

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-0,5 pontos)**

**Erros Comuns:**
- Desafios muito genéricos ou vagos
- Não descrever papel pessoal do aluno
- Falta de ações, contribuições ou aprendizados
- Apenas um checkpoint mencionado
- Resposta muito curta ou superficial
- Desafios irreais ou não relacionados ao projeto

**Exemplo de Resposta Incorreta:**
> "No Checkpoint 1 foi difícil. No Checkpoint 2 também foi difícil. Eu ajudei."

**Por que está errado:**
- Desafios muito vagos
- Não descreve papel pessoal
- Falta de detalhamento sobre ações e aprendizados
- Resposta muito superficial

***

### **Questão 9 (6 pontos): Caso Prático Integrado**

#### ✅ **RESPOSTA POSITIVA (EXCELENTE - 6 pontos)**

Esta questão avalia integração de conhecimentos. A resposta deve demonstrar compreensão sistêmica e capacidade de aplicação integrada.

**a) Conter o Escopo (2 pontos):**

**Processo de Controle de Escopo:**
- Revisar escopo original do projeto e comparar com situação atual
- Documentar todas as mudanças solicitadas informalmente
- Avaliar impacto de cada mudança (tempo, custo, recursos)
- Estabelecer processo formal de mudanças (Change Control Board)

**Técnicas de Gestão de Escopo:**
- **Freeze de escopo:** Congelar escopo para iterações específicas
- **Backlog de mudanças:** Criar backlog para novas solicitações (avaliação posterior)
- **Validação de critérios de aceitação:** Revisar e reforçar critérios originais
- **Comunicação clara:** Comunicar limites do escopo aos stakeholders
- **WBS revisão:** Revisar EAP para garantir que trabalho está alinhado
- **Documentação de mudanças:** Registrar todas as solicitações de mudança

**Exemplo Prático:**
- Criar issue no GitLab para cada nova solicitação de mudança
- Avaliar impacto antes de aprovar
- Manter backlog separado para "nice-to-have"
- Comunicar à equipe que escopo está congelado para Sprint atual

**b) Ajustar Cronograma (1 ponto):**

**Reavaliação do Cronograma:**
- Analisar atividades atrasadas e identificar causas
- Reestimar durações de forma realista (considerando aprendizado)
- Identificar dependências críticas e gargalos
- Recalcular caminho crítico (se usando PERT/CPM)

**Ajustes Possíveis:**
- Redefinir prioridades usando MoSCoW (Must, Should, Could, Won't)
- Reduzir escopo não essencial (focar em MVP - Minimum Viable Product)
- Aumentar recursos (se viável) - mais pessoas ou mais tempo
- Estender prazo final (com aprovação de stakeholders)
- Paralelizar atividades quando possível
- Remover funcionalidades de baixa prioridade

**Exemplo Prático:**
- Revisar milestones no GitLab e ajustar datas
- Priorizar funcionalidades essenciais (Must have)
- Adiar funcionalidades opcionais (Could have) para sprint seguinte
- Comunicar novo cronograma à equipe e stakeholders

**c) Implementar Controle de Qualidade (1 ponto):**

**Medidas de Controle de Qualidade:**
- Implementar testes sistemáticos antes de cada merge
- Estabelecer code review obrigatório (todos os merges revisados)
- Criar checklist de qualidade para cada entrega
- Definir critérios de aceitação claros para cada funcionalidade
- Realizar inspeções regulares (daily checks)
- Implementar testes automatizados (se possível)
- Estabelecer ambiente de staging para testes antes de produção

**Exemplo Prático:**
- Configurar GitLab CI para rodar testes automáticos
- Criar template de code review no GitLab
- Definir que nenhum merge é aceito sem aprovação de 2 membros
- Criar checklist: funcionalidade testada, responsivo verificado, sem erros de console

**d) Tratar Riscos Identificados (1 ponto):**

**Risco: Membros não finalizarem no prazo**

**Estratégia: MITIGAR**

**Ações Específicas:**
- Redistribuir trabalho entre membros disponíveis
- Aumentar comunicação (daily standups, checkpoints frequentes)
- Estabelecer checkpoints semanais para acompanhar progresso
- Criar plano de contingência (backup de membros para tarefas críticas)
- Identificar tarefas críticas e garantir que têm backup
- Oferecer suporte adicional para membros com dificuldades

**Reavaliação de Riscos:**
- Atualizar registro de riscos com novas probabilidades e impactos
- Identificar novos riscos decorrentes da situação atual
- Revisar estratégias de resposta para riscos existentes
- Documentar riscos que se materializaram e ações tomadas

**Exemplo Prático:**
- Atualizar matriz de riscos no GitLab Wiki
- Criar issues para ações de mitigação
- Estabelecer daily check-in para identificar problemas cedo
- Designar "backup" para cada tarefa crítica

**e) Documentar Ações Tomadas (1 ponto):**

**Documentação Necessária:**
- **Registro de Mudanças de Escopo (Change Log):** Documentar todas as mudanças solicitadas e decisões tomadas
- **Cronograma Revisado:** Atualizar cronograma com novas datas e justificativas
- **Plano de Ação de Qualidade Atualizado:** Documentar novas medidas de controle
- **Registro de Riscos Atualizado:** Atualizar matriz de riscos e estratégias de resposta
- **Ata de Reunião:** Registrar reunião onde decisões foram tomadas, participantes, ações acordadas
- **Plano de Ação Integrado:** Documento consolidado com todas as ações (escopo, cronograma, qualidade, riscos)
- **Lições Aprendidas Parciais:** Registrar o que foi aprendido com a situação

**Onde Documentar:**
- GitLab Wiki (documentação centralizada)
- Issues no GitLab (rastreamento de ações)
- Milestones atualizados (cronograma)
- Commits com mensagens descritivas

**Exemplo Prático:**
- Criar página na Wiki: "Plano de Ação - Contenção de Escopo"
- Atualizar Project Charter com mudanças aprovadas
- Criar issues para cada ação do plano
- Documentar em ata de reunião as decisões tomadas

**Distribuição de Pontos:**
- **a)** Controle de escopo: 2 pontos (processo + técnicas + exemplo)
- **b)** Ajuste de cronograma: 1 ponto (reavaliação + ajustes + exemplo)
- **c)** Controle de qualidade: 1 ponto (medidas concretas + exemplo)
- **d)** Tratamento de riscos: 1 ponto (estratégia + ações + reavaliação)
- **e)** Documentação: 1 ponto (documentos relevantes + onde documentar)

**Critérios Adicionais para Excelência:**
- Integração clara entre diferentes áreas de conhecimento
- Exemplos práticos relacionados ao Portfólio
- Ações específicas e acionáveis
- Demonstração de compreensão sistêmica do problema
- Plano coerente e viável

***

#### ❌ **RESPOSTA NEGATIVA (INSUFICIENTE - 0-2 pontos)**

**Erros Comuns:**
- Respostas muito genéricas sem detalhamento
- Falta de integração entre áreas de conhecimento
- Ações não específicas ou não acionáveis
- Não mencionar técnicas específicas de gestão
- Falta de exemplos práticos
- Documentação muito vaga ou incompleta
- Não demonstrar compreensão sistêmica
- Plano incoerente ou inviável

**Exemplo de Resposta Incorreta:**
> "Para conter escopo, não adicionar mais coisas. Para ajustar cronograma, adiar prazos. Para qualidade, testar. Para riscos, evitar. Documentar tudo."

**Por que está errado:**
- Respostas muito genéricas
- Falta de técnicas específicas
- Não demonstra integração de conhecimentos
- Ações não detalhadas
- Falta de exemplos práticos
- Documentação muito vaga

***

## 📊 **Resumo da Distribuição de Pontos**

| Questão | Valor | Tópicos Principais |
|--------|-------|-------------------|
| **1** | 3 | Programar vs Engenharia, Gestão de Projetos |
| **2** | 5 | Viabilidade, Project Charter |
| **4** | 3 | Escopo, Requisitos |
| **5** | 3 | EAP |
| **6** | 3 | Custo da Qualidade, Controle de Qualidade |
| **7** | 3 | Riscos, Documentação |
| **8** | 2 | Desafios Checkpoints 1 e 2 |
| **9** | 6 | Caso Prático Integrado |
| **TOTAL** | **25** | |

***

## 🎓 **Observações para Correção**

1. **Abordagem Integrada:** A questão 9 requer integração de conhecimentos. Valorizar respostas que demonstram compreensão sistêmica.

2. **Exemplos Práticos:** Questões que pedem exemplos devem ser avaliadas pela relevância e conexão com o projeto Portfólio.

3. **Clareza e Completude:** Respostas devem ser claras, organizadas e completas. Parcialmente corretas recebem pontuação proporcional.

4. **Articulação Conceitual:** Valorizar respostas que demonstram compreensão além da mera memorização.

5. **Contextualização:** Respostas genéricas são aceitas, mas exemplos específicos do Portfólio aumentam a qualidade da resposta.

6. **Trabalho em Equipe:** Na questão 8, valorizar respostas que demonstram reflexão pessoal e aprendizado real.

***

## 🔍 **Como Usar Este Gabarito**

- **Respostas Positivas:** Use como referência para identificar respostas excelentes e atribuir pontuação máxima
- **Respostas Negativas:** Use para identificar respostas insuficientes e justificar pontuação baixa
- **Distribuição de Pontos:** Guie-se pela distribuição detalhada em cada questão
- **Critérios Adicionais:** Considere os critérios de excelência para diferenciar respostas boas de excelentes

***

*Boa correção!*