📋 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:

Viabilidade Técnica:
- Recursos técnicos disponíveis
- Tecnologias necessárias
- Competências da equipe
- Infraestrutura técnica
Viabilidade Econômica:
- Custos do projeto
- Benefícios esperados
- ROI (Retorno sobre Investimento)
- Recursos financeiros disponíveis
Viabilidade Operacional:
- Processos organizacionais
- Pessoas e capacidades
- Infraestrutura operacional
- Capacidade de operação e manutenção
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

Abordagem Integrada: A questão 9 requer integração de conhecimentos. Valorizar respostas que demonstram compreensão sistêmica.
Exemplos Práticos: Questões que pedem exemplos devem ser avaliadas pela relevância e conexão com o projeto Portfólio.
Clareza e Completude: Respostas devem ser claras, organizadas e completas. Parcialmente corretas recebem pontuação proporcional.
Articulação Conceitual: Valorizar respostas que demonstram compreensão além da mera memorização.
Contextualização: Respostas genéricas são aceitas, mas exemplos específicos do Portfólio aumentam a qualidade da resposta.
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!