https://github.com/grupo-syntax-squad/tupan
O projeto tem como objetivo desenvolver um sistema de monitoramento de estações meteorológicas de baixo custo, capaz de receber e armazenar dados de sensores como direção e velocidade do vento, pluviometria, umidade, temperatura e pressão. O sistema gerará relatórios e dashboards com o histórico de leituras e enviará alertas em situações de risco.
https://github.com/grupo-syntax-squad/tupan
4dsm django fatec-sjc nextjs postgresql python redis scrum tailwindcss typescript web wheather wheather-analysis
Last synced: 3 months ago
JSON representation
O projeto tem como objetivo desenvolver um sistema de monitoramento de estações meteorológicas de baixo custo, capaz de receber e armazenar dados de sensores como direção e velocidade do vento, pluviometria, umidade, temperatura e pressão. O sistema gerará relatórios e dashboards com o histórico de leituras e enviará alertas em situações de risco.
- Host: GitHub
- URL: https://github.com/grupo-syntax-squad/tupan
- Owner: Grupo-Syntax-Squad
- License: other
- Created: 2024-08-26T12:59:11.000Z (10 months ago)
- Default Branch: main
- Last Pushed: 2024-10-23T11:37:33.000Z (8 months ago)
- Last Synced: 2024-10-24T10:05:03.115Z (8 months ago)
- Topics: 4dsm, django, fatec-sjc, nextjs, postgresql, python, redis, scrum, tailwindcss, typescript, web, wheather, wheather-analysis
- Language: JavaScript
- Homepage:
- Size: 5.28 MB
- Stars: 3
- Watchers: 0
- Forks: 0
- Open Issues: 10
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Security: SECURITY.md
Awesome Lists containing this project
README
Objetivo do Projeto |
Visão do Produto |
Metodologia |
Tecnologias |
MVP |
Sprints |
Backlog & Artefatos |
Rastreamento de Requisitos |
Autores
## 📌Objetivo do Projeto
> [!IMPORTANT]
> O objetivo do projeto é desenvolver um sistema para monitoramento de estação meteorológica de baixo custo. Este sistema deve fornecer as medidas enviadas por sensores como: direção e velocidade do vento, índice pluviométrico, umidade, temperatura e pressão. Todo o histórico de dados enviados pela estação meteorológica devem ser armazenados pelo sistema, possibilitando a geração de relatórios e dashboards que informem o período e leituras realizadas. O projeto deve também ser capaz de enviar alertas para situações de risco, onde sejam detectadas leituras acima da média conhecida para a região onde a estação meteorológica está instalada. O sistema deve ser capaz de adicionar outros sensores que possam ser instalados nas estações meteorológicas posteriormente. Afim de difundir o conhecimento, o sistema deve fornecer conceitos matemáticos envolvidos nos cálculos dos parâmetros de leitura das estações meteorológicas.
> **Status do Projeto: Concluído ✅**
## 💡Visão do Produto
> [!TIP]
> As estações meteorológicas são um recurso importante fornecendo dados das condições climáticas locais ou regionais. Também são usadas para o monitoramento e portanto, redução de danos, causados por desastres naturais envolvendo condições climáticas severas, como alagamentos, deslizamentos, incêndios e riscos à saúde da população. Com o nosso sistema Tupã, as estações são capazes de fornecer um fluxo periódico de informações sobre as condições climáticas, permitindo um monitoramento com mais acurácia. A capacidade de envio de alertas para a população e órgãos públicos, dá uma capacidade de tomada de decisão mais precisa e com maior tempo hábil para medidas necessárias em caso de condições adversas que coloquem a segurança pública em risco. O nosso sistema também permite gerar um histórico para acompanhar as condições meteorológicas locais, gerando dados que podem dar informações valiosas sobre o impacto do clima ou mudanças climáticas.
## 📚Metodologia
O framework de Metodologia Ágil utilizado no produto foi o Scrum, um método ágil adaptativo, iterativo, flexível e eficaz. Entre as ferramentas utilizadas no Scrum, uma é a divisão do projeto em **Sprints**. Para selecionar quais seriam as entregas das nossas Sprints, primeiro definimos nosso **MVP**, priorizando as tarefas que trariam maior entrega de valor para o cliente. Então, a partir das Tarefas foi construído o **Backlog do Produto**, o qual foi aprovado pelo cliente e dividido em 4 Backlog de Sprint.
Dessa forma, com as Tarefas já traçadas, definimos a quantidade de tempo necessário para cada Tarefa, sendo dividido, de maneira mais otimizada, entre os Desenvolvedores do time.
## 🔌**Tecnologias**
> [!NOTE]
> Estas foram as tecnologias utilizadas no desenvolvimento do projeto:
## 🏆**MVP**
## 📅Sprints
### Sprint - 1️⃣ 🎯 ([Clique aqui](https://github.com/Grupo-Syntax-Squad/SkyGuard/tree/sprint-1)) Concluída ☑️
### Sprint - 2️⃣ 🎯 ([Clique aqui](https://github.com/Grupo-Syntax-Squad/SkyGuard/tree/sprint-2)) Concluída ☑️
### Sprint - 3️⃣ 🎯 ([Clique aqui](https://github.com/Grupo-Syntax-Squad/SkyGuard/tree/sprint-3)) Concluída ☑️
### Sprint - 4️⃣ 🎯 ([Clique aqui](https://github.com/Grupo-Syntax-Squad/SkyGuard/tree/sprint-4)) Concluída ☑️
## 👥User Stories
[DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
## 🌱Backlog do Produto
## 🌱Backlog das Sprints
## 🧱Modelo de Dados
## 🧱Arquitetura
## 📜 Rasteamento de Requisitos
## Introdução
Este tópico apresenta a organização da documentação do projeto para a rastreabilidade de requisitos. A estrutura permite rastrear os requisitos desde a fase inicial até o desenvolvimento e a entrega, garantindo que cada funcionalidade atenda a um ou mais requisitos funcionais ou não funcionais.
o rastreamento começa assim que o Poroduct Owner entende quais são as dores do cliente, e com basse nisso define os requisitos do projeto e seus critérios de aceitação, assim como Dor/Dod.
após isso, são criadas as user stories para detalhar melhor cada uma das funcionalidades atende os requisitos do cliente. E é feito o Dod/Dor de cada user story.
A partir desta documentação feita, é possivel criar as issues e tasks de forma claras e com confiabilidade que os critérios sejam entendidos e atingidos pelo time de desenvolvimento.
Para a realização de cada task, é criada pelo desenvolvedor responsavel pela task, uma branch para que todo o rastreamento daquela tarefa esteja centralizado, e minimizando as chances de haverem problemas de conflito a cada commit. O nome de cada Branch deve seguir o padrão descrito na imagem a seguir.
após a realização da tarefa, é feito o teste unitário para validar as funções ou dados utilizados na funcionalidade.
assim que a tarefa é aprovada nesse teste, o desenvolvedor cria um pull request para que outro integrante do time que não estava diretamente ligado a tarefa analise o código e aprove ou aponte os pontos de melhorias.
após a validação da tarefa individualmente, é feito o teste de integração, para garantir que a tarefa não afetou outras funcionalidades do sistema e é realizado o merge nos casos onde o teste é bem sucedido!
## 📜 Tags de Commit
## Requisito 1: Desenvolvimento de um DataLogger
Detalhes do Requisito
**Descrição:** O sistema deve utilizar um DataLogger para realizar a recepção dos dados de uma estação meteorologica e enviar para um banco de dados temporarios, onde
**Definition of Done (DOD)**
- O sistema implementa a recepção de dados a partir do DataLogger a cada 15 minutos e envia esses dados para o banco de dados temporário.
- O DataLogger é configurável e aceita dados com parâmetros variáveis em quantidade e tipo.
- As User Stories associadas (US01, US18, US19 e US23) estão implementadas, testadas e revisadas.
- Os dados recebidos e processados são exibidos corretamente na interface do usuário, conforme os requisitos.
- O código foi revisado, está documentado e sem erros críticos.
- Foram realizados testes de unidade e integração para garantir a correta recepção e processamento dos dados.
- A aplicação está otimizada para lidar com o recebimento de dados sem perda de desempenho ou inconsistências.
- A documentação técnica e de uso foi atualizada para incluir detalhes sobre a configuração e operação do DataLogger.
- A funcionalidade foi implantada e validada em um ambiente de produção ou de homologação com dados reais.
**Definition of Ready (DOR)**
- Os critérios de aceitação para o DataLogger foram definidos e estão claros para toda a equipe.
- Todas as dependências técnicas, como especificações de API e integração com o banco de dados, foram documentadas e revisadas.
- O design de como os dados serão exibidos na interface está aprovado.
- As User Stories estão detalhadas e priorizadas para o desenvolvimento.
- Os ambientes de desenvolvimento e teste estão configurados e prontos para a implementação do DataLogger.
- A arquitetura da solução foi revisada, e os requisitos de desempenho e segurança foram especificados.
- Todos os recursos necessários, incluindo bibliotecas ou componentes de hardware, estão disponíveis.
- As dependências entre este requisito e outras funcionalidades foram mapeadas e discutidas.
**Critérios de Aceitação:**
- O DataLogger deve ser flexivel, aceitando dados com parametros e a quantidade dos mesmos variaveis.
- Deve fazer a recepção dos dados a cada 15 minutos.
**User Story's ligadas ao requisito**
[DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [Issue - #46 Task - BackEnd - criação do DataLogger](https://github.com/Grupo-Syntax-Squad/Tupan/issues/46)
**Branch ligada ao requisito**
- [Branch - 46-func/criação do DataLogger](https://github.com/Grupo-Syntax-Squad/Tupan-Consumer/tree/46-func/criação-do-dataLogger)
### Requisito 2: Montagem de uma Estação Meteorológica
Detalhes do Requisito
**Descrição:** O sistema deve permitir que independente de como foi feita a montagem de uma estação meteorológica, os dados e parametros da mesma, podem ser inseridos em tempo real.
**Definition of Done (DOD)**
- O sistema permite o cadastro, atualização e exclusão de estações meteorológicas.
- Os dados das estações, como nome, local (CEP, latitude e longitude), parâmetros de medição e status (ativo/inativo), são salvos corretamente no banco de dados.
- A funcionalidade para coletar dados meteorológicos em tempo real (temperatura, umidade, pressão atmosférica, velocidade do vento, etc.) está integrada e operacional.
- Todas as User Stories associadas foram implementadas, testadas e passaram nos testes unitários e de aceitação.
- O código está revisado, sem erros críticos, e documentado conforme os padrões do projeto.
- O frontend está implementado e visualmente validado para exibir informações de forma clara e correta.
- Testes de integração e automação foram realizados para verificar a comunicação entre o frontend e o backend.
- Todos os cenários críticos foram testados, incluindo a manipulação de falhas de rede e a precisão dos dados meteorológicos.
- A documentação do sistema foi atualizada com detalhes das funcionalidades e instruções de uso.
- A aplicação foi implantada em ambiente de produção e validada com dados reais.
**Definition of Ready (DOR)**
- Os critérios de aceitação estão claramente definidos e compreendidos por todos os membros da equipe.
- As User Stories estão definadas, completas e priorizadas, prontas para serem implementadas.
- Os requisitos funcionais e não funcionais foram especificados (incluindo desempenho e segurança).
- O design da interface de usuário para a funcionalidade foi aprovado e está disponível.
- Todos os detalhes técnicos necessários, como especificações da API e esquemas de banco de dados, foram definidos.
- Os ambientes de desenvolvimento e teste estão configurados e prontos para receber novas funcionalidades.
- A arquitetura da solução foi revisada para garantir que suporta os novos requisitos.
- Todos os recursos e permissões necessários foram garantidos para a execução da tarefa.
**User Stories ligadas ao requisito**
[DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [ #16-estações-front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/16)
### Requisito 3: CRUD Estações, Parâmetros, Alertas e Usuários
Detalhes do Requisito
**Descrição:** O sistema deve permitir operações de CRUD para estações, parâmetros, alertas e usuários.
**Definition of Done (DOD)**
- As operações CRUD (Criar, Ler, Atualizar, Deletar) estão implementadas e funcionam corretamente para estações, parâmetros, alertas e usuários.
- As User Stories (US01, US02, etc.) associadas ao requisito estão implementadas e passaram por testes unitários e de aceitação.
- Todos os dados estão sendo corretamente validados antes de serem enviados ou processados no sistema.
- A interface do usuário exibe corretamente os dados de CRUD e oferece feedback apropriado para cada operação.
- Foram realizados testes de usabilidade para garantir uma experiência amigável.
- O código passou por revisão e está sem erros críticos ou vulnerabilidades conhecidas.
- Foram implementadas medidas de segurança para proteger os dados dos usuários.
- A aplicação foi testada em ambientes diferentes para garantir a consistência e o desempenho esperado.
- A documentação foi atualizada para incluir as operações CRUD e as permissões associadas.
- A funcionalidade foi implantada e validada em produção, com todos os casos de uso operacionais.
**Definition of Ready (DOR)**
- Os critérios de aceitação foram claramente definidos e compreendidos por toda a equipe.
- Todas as User Stories relacionadas ao CRUD estão detalhadas, priorizadas e com dependências resolvidas.
- Os requisitos técnicos, como endpoints de API e modelos de banco de dados, foram especificados.
- O design da interface de usuário foi aprovado e está disponível para a equipe de desenvolvimento.
- As dependências externas foram identificadas e estão prontas para uso.
- O ambiente de desenvolvimento e testes está configurado e acessível à equipe.
- A equipe tem acesso a exemplos de dados e à documentação técnica necessária para a implementação.
- As permissões de acesso ao repositório e outras ferramentas estão garantidas.
- As condições e restrições de segurança foram revisadas e aprovadas.
- O backlog foi atualizado, e a equipe de desenvolvimento está alocada para trabalhar nesse requisito.
**Critérios de Aceitação:**
- Deve ser possível criar, ler, atualizar e deletar estações e seus parâmetros.
**User Stories ligadas ao requisito**
- [user stories de 1 à 15](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
- [DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [#2-Parâmetros - Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/2)
- [#5-Alertas / Histórico Alertas / Medição - Back](https://github.com/Grupo-Syntax-Squad/Tupan/issues/5)
- [#12-Parâmetros / Estações - Back](https://github.com/Grupo-Syntax-Squad/Tupan/issues/12)
- [#15-Usuários - Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/15)
- [#16-Estações - Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/16)
- [#17-Alertas - Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/17)
### Requisito 4: Recepção dos Dados das Estações Meteorológicas
Detalhes do Requisito
**Descrição:** O sistema deve ser capaz de receber e processar os dados coletados pelas estações meteorológicas.
**Prioridade:** Alta
**Critérios de Aceitação:**
- O sistema deve conseguir receber e processar os dados de diferentes fontes meteorológicas.
**User Stories ligadas ao requisito**
- 
- [DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [#39- func - Criação do serviço de recepção dos dados das estações](https://github.com/Grupo-Syntax-Squad/Tupan-Consumer/tree/39-func/criacao-do-servico-de-recepcao-dos-dados-das-estacoes)
### Requisito 5: Dashboard para Visualização dos Parâmetros Meteorológicos
Detalhes do Requisito
**Descrição:** O sistema deve fornecer um dashboard para visualizar os parâmetros meteorológicos coletados, facilitando a consulta de dados.
**Prioridade:** Média
**Critérios de Aceitação:**
- O usuário deve ser capaz de visualizar os parâmetros meteorológicos em gráficos interativos, podendo assim filtrar dados como parametros e datas.
**User Stories ligadas ao requisito**
- 
- [DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [#44- Recepção das Medições e exibição nos gráficos](https://github.com/Grupo-Syntax-Squad/Tupan/issues/44)
### Requisito 6: Geração de Alertas
Detalhes do Requisito
**Descrição:** O sistema deve ser capaz de gerar alertas com base em uma analise nos parâmetros coletados em relação a parametros pré estabelecidos pelo cliente.
**Prioridade:** Alta
**Critérios de Aceitação:**
- O sistema deve gerar alertas automaticamente quando determinados parâmetros forem atingidos.
**User Stories ligadas ao requisito**
- 
- 
- 
- [DOD/DOR Das user stories](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's)
**Issue ligada ao requisito**
- [#55 Observabilidade de Alertas no Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/55)
- [#52 Task - BackEnd - disparo de alertas](https://github.com/Grupo-Syntax-Squad/Tupan/issues/52)
### Requisito 7: Tutorial e Significado de cada Parâmetro Meteorológico
Detalhes do Requisito
**Descrição:** O sistema deve fornecer tutoriais que expliquem o significado de cada parâmetro meteorológico e explique como são feitas as medições dos mesmos.
**Prioridade:** Baixa
**Critérios de Aceitação:**
- O usuário deve ter acesso a explicações detalhadas sobre os parâmetros meteorológicos e como são tratados.
**User Stories ligadas ao requisito**
- 
**Issue ligada ao requisito**
- [#31 Educacional - Front](https://github.com/Grupo-Syntax-Squad/Tupan/issues/31)
## Requisitos Não Funcionais
### Requisito 8: UX dos Dashboards
Detalhes do Requisito
**Descrição:** A interface do dashboard deve ser intuitiva e de fácil uso.
**Prioridade:** Média
**Critérios de Aceitação:**
- O design do dashboard deve ser responsivo e otimizado para dispositivos móveis.
### Requisito 9: Documentação
Detalhes do Requisito
**Descrição:** O sistema deve ter documentação clara e acessível para todos os desenvolvedores e usuários.
**Prioridade:** Alta
**Critérios de Aceitação:**
- A documentação deve cobrir todas as funcionalidades principais e como utilizá-las.
**Issue ligada ao requisito**
- [57# rastreabilidade de requisitos - Devops](https://github.com/Grupo-Syntax-Squad/Tupan/issues/57)
- [32# docs - documentacao de projeto](https://github.com/Grupo-Syntax-Squad/Tupan/issues/32)
### Requisito 10: Pipeline de IC
Detalhes do Requisito
**Descrição:** O sistema deve ter um pipeline de integração contínua para automatizar testes e deploy.
**Prioridade:** Alta
**Critérios de Aceitação:**
- O pipeline deve executar testes automaticamente para cada commit.
**User Stories ligadas ao requisito**
- [user stories 27, 28, 29](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us27-testes-unit%C3%A1rios-no-front-end)
**Issue ligada ao requisito**
- [#54 Teste de integração dos módulos de usuário](https://github.com/Grupo-Syntax-Squad/Tupan/issues/54)
- [#49 Devops - Testes unitários](https://github.com/Grupo-Syntax-Squad/Tupan/issues/49)
- [#42 Setup do ambiente de produção](https://github.com/Grupo-Syntax-Squad/Tupan/issues/42)
- [#53 Configurar Teste Unitário](https://github.com/Grupo-Syntax-Squad/Tupan/issues/53)
- [#48 FrontEnd - configurar testes unitarios](https://github.com/Grupo-Syntax-Squad/Tupan/issues/48)
### Requisito 11: Deploy Automático
Detalhes do Requisito
**Descrição:** O sistema deve realizar o deploy automático sempre que uma nova versão for aprovada.
**Prioridade:** Alta
**Critérios de Aceitação:**
- O deploy automático deve ser acionado após a aprovação do código no pipeline de IC.
**User Stories ligadas ao requisito**
- [US26: Deploy Automático](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us26-deploy-autom%C3%A1tico)
**Issue ligada ao requisito**
- (Adicionar link da issue aqui)
### Requisito 12: Testes Automatizados
Detalhes do Requisito
**Descrição:** O sistema deve ter testes automatizados implementados para garantir a qualidade e a estabilidade das funcionalidades.
**Prioridade:** Alta
**Critérios de Aceitação:**
- Testes de unidade devem validar funcionalidades críticas do sistema.
- Testes de integração devem garantir que os principais fluxos funcionam conforme esperado.
**User Stories ligadas ao requisito**
- [US27: Testes Unitários no Front-End](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us27-testes-unit%C3%A1rios-no-front-end)
- [US28: Testes de Integração no Front-End](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us28-testes-de-integra%C3%A7%C3%A3o-no-front-end)
- [US29: Testes Unitários no Back-End](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us29-testes-unit%C3%A1rios-no-back-end)
- [US30: Testes de Integração no Back-End](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us30-testes-de-integra%C3%A7%C3%A3o-no-back-end)
**Issue ligada ao requisito**
- [FrontEnd - configurar testes unitarios#48](https://github.com/Grupo-Syntax-Squad/Tupan/issues/48)
- [Devops - Testes unitários#49](https://github.com/Grupo-Syntax-Squad/Tupan/issues/49)
- [Configurar Teste Unitário#53](https://github.com/Grupo-Syntax-Squad/Tupan/issues/53)
### Requisito 13: Manual de Usuário
Detalhes do Requisito
**Descrição:** O sistema deve fornecer um manual de usuário que cubra todas as funcionalidades e permita ao usuário aprender a usar a aplicação de forma intuitiva.
**Prioridade:** Alta
**Critérios de Aceitação:**
- O manual deve conter instruções detalhadas sobre o uso de todas as funcionalidades.
- O conteúdo deve incluir imagens ou capturas de tela para facilitar o entendimento.
- O manual deve estar acessível online em formato digital a qualquer momento.
- O manual deve estar em conformidade com os padrões de clareza e linguagem.
**User Stories ligadas ao requisito**
- ([US25: Informações](https://github.com/Grupo-Syntax-Squad/Tupan/wiki/09%E2%80%90-User-Story's#us25-informa%C3%A7%C3%B5es))
**Issue ligada ao requisito**
- (Adicionar link da issue aqui)
### Requisito 14: Geração de Relatórios
Detalhes do Requisito
**Descrição:** O sistema deve ser capaz de gerar relatórios com dados relevantes de forma eficiente, permitindo ao usuário personalizar a geração dos relatórios.
**Prioridade:** Média
**Critérios de Aceitação:**
- Relatórios devem incluir dados organizados conforme especificado.
- Relatórios devem ser gerados em formatos como Excel.
- O usuário deve poder selecionar filtros ou parâmetros para personalizar os relatórios.
- Relatórios devem ser gerados de maneira eficiente, com um tempo de resposta inferior a 10 segundos para grandes conjuntos de dados.
**User Stories ligadas ao requisito**
- (Adicionar links das user stories aqui)
**Issue ligada ao requisito**
- (Adicionar link da issue aqui)
## 👨💻**Autores**
| Nome | Função | Github | Linkedin |
| :--------------: | :-----------: | :----------------------------------------------------------: | :----------------------------------------------------------: |
| Mateus Henrique Lima dos Reis | Product Owner | 
| 
| Diego Dias Motta Boa Sorte | Scrum Master | | |
| Gabriel de Oliveira Silva Reis | Desenvolvedor | | |
| Gabriel Felipe dos Santos | Desenvolvedor | |
| Iago Cardoso Souza | Desenvolvedor | |
| João Vitor dos Santos Pereira | Desenvolvedor | | |
| Ryan Verissimo de Araujo | Desenvolvedor | | |
| Wellington Luiz de Faria | Desenvolvedor | | |