Relatório de maturidade - TP1 - maieutIA

Gestão de Projetos de Software (2026-2) — Relatório de Avaliação do Módulo 1

Autor

Prof. Aléssio Miranda Júnior

Data de Publicação

2026-09-21

Data de Modificação

21/09/2026

1. Resumo da Rubrica de Avaliação (5,0 Pontos)

Critério Descrição Peso Nota Obtida Evidência Principal
1. Identidade e Equipe README.md com logo, membros (@username), papéis e stack tecnológica 0,5 0.5 ✅ Completo
2. Project Charter docs/PROJECT_CHARTER.md com objetivos SMART, justificativa WokDex e escopo 0,8 0.8 ✅ Completo
3. EAP / WBS docs/EAP.md com decomposição hierárquica e códigos numéricos 0,8 0.8 ✅ Mermaid + Numeração
4. Diretrizes de Prompt docs/DIRETRIZES_PROMPT.md com postura socrática e exemplos de diálogo 0,7 0.7 ✅ Completo com Exemplos
5. Backlog no GitLab 4 Milestones, Issues com labels/estimativas, dependências e todos membros 1,2 1.2 35 Issues, 4 Milestones
6. Spike Técnico / MVP Código de consumo da API LLM integrado via Merge Request 1,0 1.0 ✅ Spike + MR integrado
TOTAL Pontuação Consolidada do Checkpoint 01 5,0 5.0 pts ✅ Concluído no Prazo

2. Participação e Métricas Individuais dos Membros

Avaliação do envolvimento de cada integrante cadastrado oficialmente:

Integrante Matrícula Usuário GitLab Commits Issues Criadas Issues Atribuídas MRs Criados MRs Revisados Nível de Engajamento
Arthur Eler 20223004240 @ArchieBaltar 14 35 10 0 0 🟢 Alto
João Carlos Martins 20213003750 @joaocarlos.fm 5 0 17 1 0 🟢 Alto
Bianca Barros 20223004410 @biancaB 5 0 8 0 0 🟢 Alto

3. Auditoria Detalhada dos Artefatos de Documentação

📄 README.md

  • Arquivo presente: ✅ Sim
  • Identificação dos membros com login: ✅ Sim
  • Descrição da Stack Tecnológica: ✅ Sim

📄 docs/PROJECT_CHARTER.md (Termo de Abertura)

  • Arquivo presente: ✅ Sim
  • Objetivos SMART definidos: ✅ Sim
  • Fronteiras de Escopo (Dentro / Fora): ✅ Sim

📄 docs/EAP.md (Estrutura Analítica do Projeto)

  • Arquivo presente: ✅ Sim
  • Diagrama Mermaid ou visual: ✅ Sim
  • Numeração hierárquica de pacotes: ✅ Sim

📄 docs/DIRETRIZES_PROMPT.md (Filosofia do Bot)

  • Arquivo presente: ✅ Sim
  • Postura socrática e investigativa: ✅ Sim
  • Exemplos práticos de diálogos (O que deve / não deve fazer): ✅ Sim

⚡ Spike Técnico de Conexão com a LLM

  • Evidências no Repositório: Diretório encontrado: spike/, Arquivo de spike/código: spike/test_api.py
  • Merge Request associado: ✅ Identificado MR de integração

4. Governança no GitLab: Milestones, Issues e MRs

  • Total de Commits: 24 (23 no prazo, 1 após o prazo)
  • Total de Issues Cadastradas: 35
  • Total de Milestones: 4
  • Total de Merge Requests: 1
  • Dependência Bloqueante Mapeada: ✅ Sim (vínculo is blocked by ativo)
  • Uso de Estimativas de Tempo: ✅ Sim

Amostra de Issues do Projeto

# Título da Issue Autor Responsáveis Labels Estado
#35 Realizar retrospectiva final do projeto @ArchieBaltar @ArchieBaltar Gestão opened
#34 Revisão final da documentação @ArchieBaltar @ArchieBaltar Docs, Gestão opened
#33 Preparar apresentação/Pitch final @ArchieBaltar @biancaB Docs opened
#32 Coletar métricas de uso e taxa de acerto @ArchieBaltar @biancaB Docs, Requisitos opened
#31 Testes finais end-to-end do MVP @ArchieBaltar @joaocarlos.fm BackEnd opened
#30 Refinar tratamento de falhas @ArchieBaltar @joaocarlos.fm BackEnd opened
#29 Organizar Sprint Review / Retrospectiva da Sprint 3 @ArchieBaltar @ArchieBaltar Gestão opened
#28 Acompanhar Board Kanban e limite de WIP @ArchieBaltar @ArchieBaltar Gestão opened
#27 Testar usabilidade da interface @ArchieBaltar @biancaB Docs, FrontEnd opened
#26 Executar migração de modelo (se necessário) @ArchieBaltar @joaocarlos.fm BackEnd opened
#25 Tratamento de rate limit e erros de API (1.3.3) @ArchieBaltar @joaocarlos.fm BackEnd opened
#24 Configurar pipeline de CI/CD (1.4.1) @ArchieBaltar @joaocarlos.fm BackEnd, Gestão opened
#23 Implementar exibição incremental das dicas (1.1.3) @ArchieBaltar @joaocarlos.fm FrontEnd opened
#22 Implementar fluxo de submissão (1.1.2) @ArchieBaltar @joaocarlos.fm BackEnd, FrontEnd opened
#21 Implementar layout Streamlit (1.1.1) @ArchieBaltar @joaocarlos.fm FrontEnd opened

5. Diagnóstico de Maturidade do Projeto

NotaEscopo e evidências analisadas

Foram analisados relatorio_maieutia.qmd e trabalhos-baixados/coach-de-maratona-icpc, relacionados ao grupo maieutIA. A cópia contém README, documentação, spike/test_api.py, estrutura de aplicação, prompts e testes. Ela pode não refletir o estado remoto atual nem a totalidade de MRs e discussões.

Síntese executiva

O grupo demonstra uma base de maturidade robusta, com planejamento, arquitetura inicial e estrutura de projeto além dos artefatos mínimos. O backlog cobre a evolução do Professor Agente, incluindo usabilidade, falhas de API, testes e métricas. Há dependência bloqueante registrada na auditoria, reforçando a consciência de encadeamento do trabalho. O próximo ganho está em converter as diretrizes pedagógicas em experimentos, critérios de aceite e evidências de qualidade.

Quadro de maturidade

Dimensão Estágio Evidências Risco ou limitação
Identidade e visão Avançado README, charter e organização de app/core/prompt. Confirmar que o recorte do MVP evita dispersão.
Escopo e requisitos Consistente Charter, requisitos e diretrizes presentes. Critérios mensuráveis de aceite pedagógico precisam ser explicitados.
Planejamento e rastreabilidade Avançado EAP visual e numerada; milestones, estimativas e dependência registradas. A cópia não permite auditar o histórico vivo do board.
Viabilidade técnica e segurança Consistente Spike, .env.example, arquitetura e testes presentes. Não foi executado o projeto nem auditada a configuração efetiva de segredos.
Qualidade documental e colaboração Consistente Documentação ampla e evidência de MR na auditoria. Há evidência limitada de revisão distribuída na auditoria; confirmar o fluxo praticado.

Evidências positivas verificáveis

  • Estrutura local inclui app/, core/, docs/, spike/, tests/ e .env.example.
  • Existem docs/ARQUITETURA.md, requisitos, EAP e diretrizes de prompt.
  • A auditoria registra tarefas para validação, rate limit, testes end-to-end e métricas de uso.

Lacunas e riscos priorizados

  • P0: validar que o prompt, o fluxo de interface e a integração estão conectados por uma jornada mínima demonstrável.
  • P1: não foi confirmada na cópia uma suíte executada de testes pedagógicos; isso é ausência de evidência, não deficiência comprovada.
  • P1: o planejamento amplo pode ampliar o escopo antes de validar o núcleo socrático.

Recomendações para o Módulo 2

  • P0: definir conjunto versionado de cenários de conversa, saídas esperadas e critérios de falha para o Professor Agente.
  • P1: vincular arquitetura, requisitos e issues à primeira demonstração vertical.
  • P1: registrar decisão de segurança para credenciais, logs e dados de conversa.
  • P2: consolidar prática de revisão cruzada em MRs para alterações de prompt e integração.

Perguntas de validação

  1. Quais cenários distinguem uma resposta socrática de uma solução pronta?
  2. Qual componente é responsável por aplicar limites pedagógicos e como será testado?
  3. Como o time observará falhas, custo e rate limit sem registrar dados sensíveis?

Nota metodológica

Análise assistida por LLM, baseada em evidências documentais locais e relatório heurístico. Requer revisão docente e não substitui a avaliação formal.

6. Considerações e Ajustes Finais do Docente

Parecer Geral: ✅ Concluído no Prazo com nota calculada em 5.0 / 5,0.

Observações do Professor: [ ] Revisão validada sem ressalvas [ ] Ajuste manual de nota necessário: ______

Comentários adicionais:

Voltar ao Relatório Consolidado (TP1) | Ir para o Dashboard Geral

De volta ao topo