Sprint Session BiaBot - Rubrica da competência de Projeto#

O projeto desta Sprint Session é a construção de um sistema funcional (front-end + back-end) para a BiaBot, uma plataforma de ferramentas clínicas para médicos. O sistema deve receber documentos de exames (PDF, imagem escaneada ou foto de celular), enviá-los ao serviço de extração disponibilizado pela BiaBot e apresentar o resultado de forma estruturada, com foco forte em UX e UI.

A análise e a modelagem do documento não fazem parte do escopo: a BiaBot disponibiliza o serviço de extração (API), o schema do JSON de saída e um conjunto de exames simulados. Nenhum dado real de paciente deve ser utilizado.

As histórias citadas abaixo (H1 a H10) referem-se ao documento do projeto disponível no Blackboard.

Rubrica funcionalidades#

• Conceito I: Não entregaram o projeto ou o projeto entregue não é funcional, ou seja, não é possível rodar o sistema, enviar um exame e visualizar o resultado.
• Conceito D: O projeto apresenta algumas telas ou funcionalidades implementadas, mas não atende completamente aos requisitos do conceito C. Há funcionalidades essenciais ausentes, incompletas ou sem funcionamento adequado.

• Conceito C:

  • O projeto implementa o fluxo básico ponta a ponta: o médico entra no sistema, envia um exame e visualiza o resultado estruturado. Para atingir este conceito, o grupo deve apresentar:
    • Área do médico (H7): cadastro, login, logout e recuperação de senha;
    • Pacientes (H7): cadastro de pacientes (dados mínimos e simulados) e vínculo de exames a pacientes;
    • Controle de acesso (H7): um médico nunca vê os pacientes e exames de outro médico;
    • Upload (H3): envio de PDF e imagem com validação de tipo e tamanho, integração com o serviço de extração da BiaBot e armazenamento do resultado em banco de dados;
    • Status do processamento (H3): cada documento exibe seu status (recebido → processando → concluído → erro), e falhas do serviço geram uma mensagem de erro compreensível para o médico;
    • Visualização de exame laboratorial (H4): tela de resultado agrupada (hemograma, função renal, lipídios...) com valor, unidade, faixa de referência e indicador visual dos valores fora da referência;
    • Histórico (H7): lista dos exames do médico com busca e filtros (tipo, data e paciente).
  • O sistema deve permitir que o médico acesse as principais telas e realize as operações fundamentais previstas para o projeto, utilizando os exames simulados fornecidos pela BiaBot.

• Conceito B: Atingiu o conceito C e, além disso, apresenta um back-end mais robusto, cobre os dois tipos de exame e gera o artefato que circula fora da plataforma. Para atingir este conceito, o grupo deve apresentar:

  • Pipeline assíncrono (H3): processamento em fila (ex.: Redis + Celery/RQ/BullMQ) com workers que chamam o serviço de extração, status atualizado em tempo real (sem a tela travar esperando a resposta) e tratamento de falhas com retry/timeout;
  • Upload completo (H3): arrastar e soltar, múltiplos arquivos e captura pela câmera no mobile;
  • Visualização de exame laboratorial completa (H4): resumo no topo ("X de Y analitos fora da referência") com os alterados listados primeiro, indicador da posição do valor dentro/fora da faixa sem depender só de cor, filtro "só alterados" e visualização do documento original lado a lado;
  • Visualização de laudo de imagem (H5): impressão diagnóstica em destaque, achados agrupados por órgão/região, destaque dos achados conforme a marcação do serviço (a plataforma não cria interpretação própria) e suporte a pelo menos 4 modalidades de exame;
  • PDF estruturado (H6): geração de PDF a partir do JSON com templates para exame laboratorial e de imagem, legível em impressão P&B, formato A4, com cabeçalho, rodapé de origem (laboratório, data do exame, data de geração) e aviso de que o documento reorganiza o laudo original e não o substitui;
  • Log de auditoria (H7): registro de acessos e ações do médico, com uma interface para visualizar esse log; a exclusão de um paciente apaga os dados associados;
  • Desacoplamento entre front-end e back-end utilizando uma API REST, com os endpoints documentados (ex.: Swagger/OpenAPI);
  • Os dados sensíveis, configurações e credenciais (incluindo as credenciais do serviço de extração) não estão escritos diretamente no código fonte, mas sim em variáveis de ambiente ou arquivos de configuração que não são versionados no controle de versão.
  • Neste conceito, espera-se que o projeto não seja apenas funcional, mas também possua uma arquitetura organizada e preparada para lidar com dados sensíveis de saúde (LGPD).

• Conceito A: Atinge o conceito B e inclui uma funcionalidade avançada que agregue valor real ao projeto. Para atingir este conceito, o grupo deve apresentar os itens descritos abaixo:

  • Realizaram deploy do projeto;
  • Testes automatizados que provem o controle de acesso, ou seja, que um médico não consegue acessar pacientes, exames ou PDFs de outro médico (H7);
  • Implementação de pelo menos uma das histórias do nível avançado:
    • Extrator via Telegram (H8): bot integrado à Telegram Bot API (via webhook ou long polling), recebendo PDF/imagem e devolvendo o PDF estruturado na mesma conversa, com mensagens de status e de erro amigáveis, vínculo da conta do Telegram a uma conta da plataforma (ex.: deep link com token no /start) e orientação para usuários não cadastrados;
    • Evolução do paciente (H9): normalização de analitos com tabela de equivalência documentada e conversão de unidades, linha do tempo por paciente e gráfico de evolução por analito com a faixa de referência ao fundo, funcionando com pelo menos 3 exames por paciente para 5 pacientes simulados;
    • Infraestrutura e observabilidade (H10): sistema containerizado (Docker/Docker Compose) e reproduzível, com pipeline de CI/CD no GitHub Actions executando os testes e realizando o deploy;
    • Ou uma funcionalidade avançada proposta pelo grupo, validada previamente com os professores e com a BiaBot, demonstrando que está alinhada às necessidades reais do projeto.
  • A funcionalidade avançada deve estar integrada ao sistema de forma consistente, contribuindo para a experiência do médico e não apenas aparecendo como um elemento isolado ou superficial.
  • O código está claro, organizado, bem documentado e é fácil de entender e manter.

• Conceito A+: Atinge o conceito A e apresenta uma entrega de excelência, sem ressalvas relevantes.

  • O README.md do projeto é completo, com informações detalhadas sobre o projeto, integrantes do grupo, como rodar o front-end, o back-end e os workers, como configurar o acesso ao serviço de extração, além de um link para o vídeo com a demonstração de todas as funcionalidades do projeto e um link do deploy do projeto.
  • Mais de uma história do nível avançado (H8, H9 ou H10) implementada de forma completa. No caso do Telegram (H8), incluem validação do token secreto do webhook (X-Telegram-Bot-Api-Secret-Token), idempotência para mensagens repetidas (ex.: pelo update_id) e demonstração ao vivo ponta a ponta em menos de 60 s por exame.
  • Robustez do pipeline: o sistema evita processar o mesmo exame duas vezes, lida bem com fotos de baixa qualidade e arquivos que não são exames, e a geração do PDF leva menos de 5 s para um exame típico.
  • Visualização dos exames bem planejada, mobile-first e pensada para o médico com pouco tempo: o que está alterado e o que mudou desde o último exame são identificados em segundos. A interface trata casos difíceis, como faixas de referência ausentes ou que variam por sexo/idade e campos extraídos com baixa confiança.
  • Gráficos e visualizações com bom acabamento, apresentando dados relevantes de maneira clara, visualmente organizada e coerente com a identidade do sistema. Os gráficos devem possuir títulos, legendas, rótulos, unidades e formatação adequados, evitando visualizações confusas ou meramente decorativas.
  • Funcionalidades extras relevantes, como o site institucional com demonstração interativa sem cadastro (H2), autenticação com segundo fator ou login social (H7), termo de uso e consentimento (H7) ou exportação dos gráficos de evolução para o PDF (H9). Essas funcionalidades devem estar integradas ao fluxo principal do sistema e demonstrar iniciativa do grupo em compreender e atender melhor às necessidades da BiaBot;
  • Neste conceito, espera-se que o projeto demonstre não apenas o cumprimento dos requisitos, mas também cuidado com a experiência do médico, preocupação real com privacidade e segurança dos dados de saúde, boa tomada de decisão técnica e atenção aos detalhes necessários para que o time técnico da BiaBot possa incorporar o trabalho à plataforma.

Rubrica de Trabalho em Equipe#

A competência de metodologias ágeis será avaliada na sprint session a partir da avaliação de: - Uso do framework ágil Scrum. - Trabalho em equipe. - Artefatos.

Uso do Framework Ágil Scrum#

Espera-se que o time utilize o framework ágil Scrum de forma adequada, seguindo o ciclo da Sprint com início e fim bem definidos. Os times devem fazer as reuniões diárias, de planejamento da Sprint e da retrospectiva da Sprint. Além disso, devem utilizar o quadro Scrum para priorizar e organizar as tarefas do projeto sempre mantendo o mesmo atualizado para que reflita o trabalho em andamento. Os papéis e responsabilidades devem estar claros e com os respectivos responsáveis definidos.

Trabalho em equipe#

O aluno deve estar comprometido com a entrega do projeto e com o time. Sempre atuando de forma colaborativa preocupado em apoiar os demais membros do time, utilizando de comunicação clara e frequente para relatar o andamento do seu trabalho e/ou a necessidade de auxílio para concluir uma tarefa.

• Conceito I: não atuou de forma colaborativa com o time. Não foi encontrada evidência de sua contribuição
• Conceito D:
  • atuou de forma colaborativa com o time
  • Ajudou, mas de forma desproporcional (para muito pouco ou muito)
  • Faltou muito
• Conceito C:
  • Todos os membros participaram das sessões com os coaches e fizeram todos os questionários a tempo
  • Atuou de forma colaborativa com o time. Comprometeu-se com as entregas dos projetos.
• Conceito B: atingiu C e realizou todas as suas tarefas.
• Conceito A: atingiu o conceito B, auxiliou os colegas a realizaram suas tarefas e participou das reuniões de planejamento e de retrospectiva.

Relatório do projeto#

O relatório deve conter no mínimo os elementos abaixo:

1. Introdução:
   1. Breve introdução do projeto (o que é, que problema resolve, etc.);
   2. Indique o que cada membro do grupo fez no projeto.
   3. Quais as tecnologias, bibliotecas, linguagens e frameworks utilizados e respectivas versões.
2. Arquitetura:
   1. Diagrama da arquitetura do sistema (front-end, back-end, fila/workers, banco de dados, serviço de extração da BiaBot e, se houver, Telegram).
   2. Principais decisões técnicas e justificativas (ex.: fila × chamada síncrona, autenticação própria × pronta, HTML→PDF × biblioteca nativa).
   3. Quais medidas foram tomadas para proteger os dados de saúde (LGPD).
3. Funcionalidades implementadas:
   1. Descrição de todas as funcionalidades implementadas pelo grupo, indicando a quais histórias (H1 a H10) correspondem.
   2. Prints de todas as telas desenvolvidas.
   3. Vídeo demonstrando todas as funcionalidades implementadas.
4. Quais as funcionalidades planejadas e quais as entregues por Sprint e no final.
5. Lições aprendidas ao longo do projeto, nas dimensões: código, ter um cliente real, trabalho em equipe e uso de metodologias ágeis.

O conceito referente ao relatório do projeto limita a nota do projeto.

• Conceito I: fez um relatório básico e mal escrito.
• Conceito D: o relatório é básico mas está organizado e legível.
• Conceito C: atingiu D e contemplou 70% dos tópicos do relatório de forma clara e organizada.
• Conceito B: atingiu C e contemplou todas as partes do relatório de forma clara e organizada.
• Conceito A: atingiu o conceito B fazendo um relatório bem escrito e organizado, com uma diagramação adequada e também com o vídeo bem completo

Uso do Framework Ágil Scrum#

Todo grupo deve enviar uma foto da daily via Blackboard.

• Conceito I: não utilizaram nada do framework ágil Scrum.
• Conceito D: tinham uma Sprint definida com início e fim claros e seguiam essa definição.
  • Realizaram a daily em menos de 50% das vezes.
• Conceito C: atingiu D e utilizavam o quadro Scrum.
  • Realizaram a daily em mais de 50% das vezes.
• Conceito B: atingiu C e tinham os papéis de Scrum Master e Product Owner definidos.
  • Realizaram a daily em mais de 80% das vezes.
• Conceito A: atingiu o conceito B e realizavam todas as cerimônias de planejamento da Sprint, realizavam alinhamento diário e todas as retrospectivas da Sprint.

Artefatos#

Espera-se como artefatos entregues: o uso e atualização constante do quadro Scrum e o pitch final de apresentação do projeto.

• Conceito I: não entregou ou seguiu nenhum artefato.
• Conceito D: tinham um quadro Scrum mas não era atualizado.
• Conceito C: atingiu D e atualizava constantemente o quadro Scrum
• Conceito B: atingiu C, faziam e tinham o checklist das atividades diárias.
• Conceito A: atingiu o conceito B e apresentaram o pitch do projeto final seguindo todas as partes recomendadas de um pitch.

Quadro Trello#

O quadro Scrum deve ser mantido no Trello e será usado como evidência na avaliação de Uso do Framework Ágil Scrum e de Artefatos. Use a rubrica abaixo nas retrospectivas (ou uma vez por semana) para saber onde o quadro ajuda a equipe e onde atrapalha.

Cada critério é avaliado de 1 a 4: 1 = Fraco, 2 = Em desenvolvimento, 3 = Sólido, 4 = Excelente. A tabela descreve os extremos (1 e 4).

A. Estrutura do quadro#

B. Qualidade dos cartões#

C. Atribuição de tarefas#

Exemplo de quadro Trello#

Qualidade de Código#

• Conceito I: o projeto não atingiu o conceito D. O código majoritariamente não segue boas práticas de programação.
• Conceito D: o projeto possui erros que impedem a execução do sistema.
• Conceito C:
  • O repositório do projeto está organizado.
  • Possui um README.md com instruções de como rodar o projeto.
  • Projeto possui arquivos de dependências (ex.: requirements.txt, package.json).
  • Possui um arquivo .env.example com as variáveis de ambiente necessárias (sem os valores reais).
  • Não possui arquivos desnecessários nem dados sensíveis versionados.
• Conceito B: atingiu o Conceito C e
  • O código está bem documentado, é possível entender nomes de funções e variáveis e dar manutenção no mesmo.
  • Os endpoints da API estão documentados.
• Conceito A:
  • O arquivo README.md está bem completo, com informações sobre o projeto, integrantes do grupo, como rodar o front-end, o back-end e os workers e como configurar o serviço de extração.
  • Além disso, há um link para o vídeo com a demonstração de todas as funcionalidades do projeto.
  • Também foi indicado o link do deploy do projeto.

Limitadores de Nota#

Sessão coach

• 1 Membro do grupo perde 1 sessão coach - Ele tem limitação de um conceito na nota de Projeto. Se houver 2 faltas do grupo na sessão coach a nota de projeto do grupo todo fica limitada a C

Formulário CATME

Caso algum formulário CATME não seja respondido, a nota do projeto fica limitada ao conceito C.

Aulas normais

• 4 faltas: Integrante tem nota de Projeto Limitada a B;
• 6 faltas: nota limitada a C;
• 7 ou mais faltas limitam a nota da sprint do integrante a D.

Commits

• Nota do projeto fica limitada ao conceito I: não possui commits no projeto.
• Nota do projeto fica limitada ao Conceito D: possui poucos commits com trabalho significativo.
• Nota do projeto fica limitada ao Conceito C: possui commits com trabalho significativo em pelo menos 6 dias diferentes durante o horário de aula estúdio.

Dados de pacientes

• O uso de dados reais de pacientes em qualquer parte do projeto (código, banco de dados, prints, vídeo ou relatório) limita a nota do projeto ao conceito D. Utilize apenas os exames simulados fornecidos pela BiaBot ou gerados pelo grupo a partir dos modelos.

Apresentação Final#

Caso o aluno não esteja presente na apresentação final, a nota do projeto fica limitada ao conceito C.