Skip to content

Latest commit

 

History

History
153 lines (115 loc) · 6.39 KB

File metadata and controls

153 lines (115 loc) · 6.39 KB

Documentação do microHelium

Plataforma web para maratonas de programação no estilo ICPC: múltiplos contests, múltiplas sedes, auto-judge distribuído em sandbox, placar com congelamento e revelação, clarificações, rejulgamento auditável e Contest API.

Comece por aqui

Você quer… Vá para
usar o sistema (competir, organizar, julgar, atender) Manuais
entender como o sistema é por dentro Especificação de software
saber por que algo foi feito de um jeito Decisões de projeto
integrar com a API api/openapi.yaml
operar algo específico Runbooks

Manuais

Um por papel, escrito para quem vai usar — não para quem vai programar.

  • Participante — competir: enviar, acompanhar, clarificação, S.O.S.
  • Organizador — montar o evento, conduzir o ciclo da prova, publicar o resultado.
  • Juiz — fila, verificação, pausa de problema, rejulgamento.
  • Staff e sede — S.O.S., tarefas, impressão, coordenação de sede.

Índice dos manuais


Especificação de requisitos (SRS)

Documento único, consolidado e normativo. Usa DEVE / NÃO DEVE / PODE, e identificadores estáveis (RF-*, RNF-*, RN-*, UC-*, ENT-*, INT-*) para serem citados em issues, PRs, testes e decisões.

Cobre, numa peça só:

Parte Conteúdo
1–2 definição, escopo, glossário, stakeholders, arquitetura, RN-001…RN-060
3 F01…F25 com critérios de aceite, não funcionais em 10 categorias, interfaces
4–5 priorização P0/P1/P2 e rastreabilidade
6–9 classes, processo de desenvolvimento, cronograma e custo
A casos de uso detalhados UC-01…UC-26
B catálogo UML: pacotes, componentes, implantação, máquinas de estado, sequência, atividades
C modelagem de dados: DER, dicionário de entidades, integridade
D contratos de API e integrações, incluindo CLICS
E segurança, privacidade e fronteiras de confiança
F estratégia de testes e critérios de aceite de release
G eventos, auditoria e observabilidade
H checklist operacional de competição

Ele descreve comportamento implementado, não intenção. Se a tela divergir do documento, o documento está desatualizado — abra uma issue.

Os diagramas ficam em software-spec/: classe, caso de uso e a fonte editável.


Decisões de projeto (specs)

Uma issue que chega num ponto de decisão vira um documento aqui: o que foi decidido, com que evidência, e o que reabriria a decisão.

Ciclo da prova e placar

Julgamento

Problemas e pacotes

Integração

Pessoas, sedes e acesso

Deploy


Runbooks

Procedimento para executar quando chegar a hora.


Frontend


Handoffs

handoffs/ — estado do trabalho no momento em que uma sessão terminou, para outra pessoa (ou outra sessão) retomar sem redescobrir contexto.


Como manter isto vivo

  • Mudou papel, rota, entidade, ciclo de vida, julgamento ou placar? A especificação e os manuais mudam no mesmo PR — ou o PR justifica por que não há impacto documental.
  • Uma decisão arquitetural vira docs/specs/<issue>-<tema>.md, com a evidência e o que a reabriria.
  • Um procedimento que alguém vai executar vira docs/runbooks/.
  • Um manual descreve o que o sistema faz, não o que se pretendia que ele fizesse. Divergiu da tela? O manual está errado.