Objetivo do Projeto | Visão do Produto | Metodologia | Tecnologias | MVP | Sprints | Backlog & Artefatos | Rastreamento de Requisitos | Autores
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 ✅
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.
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.
Note
Estas foram as tecnologias utilizadas no desenvolvimento do projeto:
Sprint - 1️⃣ 🎯 (Clique aqui) Concluída ☑️
Sprint - 2️⃣ 🎯 (Clique aqui) Concluída ☑️
Sprint - 3️⃣ 🎯 (Clique aqui) Concluída ☑️
Sprint - 4️⃣ 🎯 (Clique aqui) Concluída ☑️
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!
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 storiesIssue ligada ao requisito
Branch ligada ao requisito
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 storiesIssue ligada ao requisito
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
Issue ligada ao requisito
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
Issue ligada ao requisito
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
-
-
Issue ligada ao requisito
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
-
-
-
-
Issue ligada ao requisito
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
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.
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
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
Issue ligada ao requisito
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
Issue ligada ao requisito
- (Adicionar link da issue aqui)
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
- US28: Testes de Integração no Front-End
- US29: Testes Unitários no Back-End
- US30: Testes de Integração no Back-End
Issue ligada ao requisito
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
Issue ligada ao requisito
- (Adicionar link da issue aqui)
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)
| Nome | Função | Github | |
|---|---|---|---|
| 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 | |
|