Trabalho Prático Integrador: Coach de Maratona ICPC (Assistente IA)
1. Introdução e Propósito
Este trabalho prático é a atividade principal da disciplina de Gestão de Projetos de Software. O objetivo é que sua equipe aplique os conceitos teóricos aprendidos em sala de aula para planejar, executar, monitorar e concluir um projeto real de desenvolvimento de software.
Ao longo do semestre, sua equipe irá construir um Assistente de IA focado em apoiar estudantes na resolução de problemas de Maratona de Programação (ICPC) usando uma API de inteligência artificial (ex: Gemini, OpenAI) e uma interface de escolha da equipe (ex: Telegram Bot, Streamlit, Web). Este projeto não se foca apenas na programação do bot, mas, principalmente, no processo de gestão de projetos que sua equipe irá utilizar para construí-lo, versionando tudo no GitLab.
2. Objetivos de Aprendizagem
Este trabalho foi projetado para que você possa:
- Aplicar Conceitos de Gestão: Colocar em prática as metodologias de gestão tradicional (PMBOK), ágil (Scrum) e híbrida.
- Utilizar Ferramentas de Mercado: Dominar ferramentas colaborativas como o GitLab (para versionamento de código, rastreamento de autoria e automação CI/CD).
- Engenharia de Prompt e Escopo: Aprender a gerenciar o “Scope Creep” lidando com LLMs, refinando prompts para garantir que a IA atue como tutor e não apenas entregue o código pronto.
- Praticar a Colaboração: Trabalhar em equipe para definir escopo, delegar tarefas, resolver conflitos e garantir a entrega de um produto de qualidade com base na contribuição de todos.
3. Descrição do Projeto
O produto final do seu projeto será um software funcional (O Coach ICPC), com as seguintes restrições de escopo:
- O Problema de Negócio: Alunos travam em problemas de juízes online (Beecrowd, Codeforces). O Assistente não deve apenas dar a resposta em C/C++, mas deve receber a descrição do problema e guiar o aluno passo a passo (ex: explicar a lógica, sugerir a classe do algoritmo como Programação Dinâmica ou Grafos, analisar a complexidade).
- Integração e Autoria: A lógica de negócio e o System Prompt serão construídos incrementalmente. Cada ajuste no prompt, cada refatoração da API e cada nova feature na interface deve ser acompanhada por commits e Merge Requests no Git. A sua contribuição individual é provada pelo seu rastro no repositório.
- Repositório-Modelo: A equipe deverá iniciar o projeto a partir de um Template Repository fornecido pelo professor, que já contém as estruturas iniciais de documentação e CI/CD.
O foco da avaliação não está em criar a IA do zero (vocês consumirão uma API), mas na qualidade do processo de gestão, na rastreabilidade de quem fez o que e na evolução do produto via Sprints.
4. Avaliação e Pontuação
O trabalho prático tem um valor total de 30 pontos, distribuídos ao longo dos quatro módulos da disciplina. A pontuação será baseada na demonstração da aplicação dos conceitos de gestão e nas evidências do trabalho colaborativo registradas no GitLab.
| Módulo de Avaliação | Valor em Pontos | Foco da Avaliação |
|---|---|---|
| Módulo 1: Iniciação e Planejamento | 5 pontos | Definição da interface (Bot/Web), criação de issues, backlog inicial e milestones no GitLab. |
| Módulo 2: Gestão e Documentação | 5 pontos | Construção do System Prompt inicial, refinamento de escopo, e rastreabilidade nas issues. |
| Módulo 3: Execução Ágil e CI/CD | 10 pontos | Adoção da metodologia ágil, uso do GitLab Boards, frequência de commits, e integração contínua (testes automatizados de prompt/API). |
| Módulo 4: Conclusão e Apresentação | 10 pontos | Qualidade do bot em funcionamento (apresentação pitch), realização da retrospectiva e clareza da autoria via Git. |
5. Requisitos e Diretrizes
Para a realização do projeto, as seguintes regras e diretrizes devem ser seguidas:
- Identificação: Todos os participantes devem ter um login no GitLab da disciplina. O projeto deve ser criado no subgrupo oficial gps-projetos-integradores (o professor já terá acesso automático).
- Papéis: Dentro da equipe, os membros devem definir e registrar seus papéis (Scrum Master, Product Owner, Desenvolvedores).
- Rastreamento de Autoria e Tarefas: Cada tarefa deve ser registrada como uma
issuee cada feature deve ser entregue via Merge Request. A ausência de commits anula a nota do membro. - Estimativa de Tempo: As issues devem incluir estimativas (ex:
1h,2h) para acompanhar o esforço. - Evidência: O histórico de commits, o refinamento do prompt da IA e o fechamento das issues servirão como evidência primária do trabalho.
- Responsabilidade e Nota Individual: A nota do trabalho prático não será, necessariamente, a mesma para todos. A avaliação considerará a contribuição individual com base nas evidências objetivas do GitLab (quem codou a interface, quem fez o prompt, quem documentou). Membros “caronas” serão identificados pela falta de rastreabilidade no repositório.