Apêndice 05 - Documentação de software
Histórico de Versões
| Data | Responsável(eis) | Descrição | Versão |
|---|---|---|---|
| 13/04/2024 | Rafael | Escrita de template do Epico e US | 1.0 |
| 16/04/2024 | Lucas e Rafael | Definição de requisitos de software | 1.1 |
| 16/04/2024 | Felipe | Revisão, ajustes e adição de requisitos funcionais | 1.2 |
| 16/04/2024 | Caio | Revisão, ajustes e adição de histórias de usuários | 1.3 |
| 17/04/2024 | Rafael, Victor Hugo e Felipe | Ajustes dos RNFs e Adicao de priorizacao | 1.4 |
| 23/04/2024 | Laura Pinos | Adiciona introdução benchmarking | 1.5 |
| 25/04/2024 | Francisco Ferreira | Adicionando diagrama de componentes | 1.6 |
| 26/04/2024 | Victor Hugo | Adiciona documento de visão geral | 1.7 |
| 26/04/2024 | Lucas Queiroz | Revisão do documento | 1.7 |
| 26/04/2024 | Laura Pinos | Adicionando benchmarking | 1.8 |
| 29/04/2024 | Matheus Costa e Rafael | Revisão e pequenas correções textuais | 1.9 |
| 30/04/2024 | Laura Pinos | Correção de arquivo | 1.10 |
| 02/05/2024 | Caio | Revisar e Refinar Documento | 1.11 |
| 02/05/2024 | Caio | Remover referências ao sensor de peso | 1.12 |
| 04/05/2024 | Paulo Gonçalves | Adiciona requisito para o envio de mensagens pelos sensores | 1.13 |
| 16/06/2024 | Rafael | Adição do diagrama de classes do codigo embarcado | 2.0 |
| 16/06/2024 | Rafael | Adição da seção sobre UML e detalhamento dos diagramas UML | 2.1 |
| 8/07/2024 | Rafael | Atualização da Visão Geral | 2.2 |
Visão Geral
Este documento tem por objetivo estabelecer um posicionamento sobre a aplicação, suas características e seu desenvolvimento em questão. Também definindo seus requisitos em termos de necessidade para usuários finais. Essencialmente, o documento de visão estabelece uma visão clara e compartilhada entre todas as partes envolvidas no projeto, incluindo desenvolvedores, clientes e stakeholders. Serve como um ponto de referência crucial para garantir que o desenvolvimento do software esteja alinhado com as expectativas e necessidades de todas as partes envolvidas.
Escopo
Conforme evidenciado por estudos da SENAR (2018), o armazenamento inadequado de grãos tem impactos significativos na qualidade e na quantidade dos produtos. Estimativas indicam perdas de bilhões de reais anualmente no Brasil devido a problemas como controle deficiente de temperatura e umidade que afeta tanto a produção quantitativa quanto a qualidade dos grãos.
A oportunidade de negócio está na crescente demanda por métodos mais eficientes de armazenamento de grãos, impulsionada pelas perdas significativas e pelos impactos econômicos observados devido ao armazenamento inadequado. Além disso, a necessidade de garantir a qualidade dos grãos ao longo do tempo e a pressão por práticas sustentáveis na agricultura também são fatores que favorecem esse tipo de produto.
Então, o objetivo desse projeto é criar uma solução adaptativa para controlar temperatura e concentração de CO2 nos silos, prevenindo o crescimento de microrganismos e a deterioração das sementes. O produto proposto inclui uma haste com furos para manter um fluxo de ar e uma interface para monitoramento e controle das condições no silo.
Descrição do problema
| Questão | Informações do Produto |
|---|---|
| O Problema é | Armazenamento inadequado de grãos |
| Que afeta | A qualidade e quantidade dos grãos |
| Cujo impacto é | Perdas de bilhões de reais anualmente no Brasil |
| Uma boa solução seria | Um produto que permita o controle e monitoramento da temperatura nos silos de armazemamento dos grãos |
Descrição dos Usuários
| Nome | Descrição |
|---|---|
| Produtores Rurais | Agricultores que desejam armazenar suas |
| colheitas com segurança e eficiência. | |
| Indústrias Alimentícias | Empresas que processam grãos para |
| produção de alimentos | |
| Exportadores | Precisam armazenar grãos antes do |
| envio ao exterior. | |
| Cooperativas Agrícolas | Gerenciam o armazenamento coletivo |
| de grãos. | |
| Empresas de Comercialização | Negociam grãos no mercado. |
Descrição dos Envolvidos
| Nome | Descrição | Responsabilidade |
|---|---|---|
| Equipe de PI2 | Estudantes da Disciplina de Projeto Integrador de Engenharia 2 da UnB FGA | Criar e manter documentos; Desenvolver e testar o produto; Tomar decisões a respeito do produto. |
| Idealizadores do Projeto Silo Air | Estudantes Agronomia da Faculdade de Agronomia e Medicina Veterinária (FAV) da UnB, e o professor Dr. Jean Pierre Passos Medaets | Auxiliar na compreensão e na elicitação de requisitos do produto; Ajudar no conhecimento técnico necessário sobre os grãos e seu armazemamento correto. |
| Avaliadores | Professores da disciplina de PI2 | Avaliar e conceder feedback sobre a qualidade do projeto desenvolvido pelos alunos de PI2 |
Resumo das Capacidades
| Benefícios | Recursos de Suporte |
|---|---|
| Facilidade em monitorar e controlar as condições do silo | A aplicação possui uma interface web de fácil uso para visualizar e analisar os dados dos sensores da haste, também conduz de maneira coerente e amigável o usuário para que ele realize o controle da circulação de ar pelo acionamento da ventilação da haste |
| Disponibilização de dados ao longo do tempo | A aplicação se encarrega de disponibilizar relatórios periódicamente sobre as condições do silo ao longo do tempo |
| Possibilidade de rápida resposta para intercorrências | A aplicação deve notificar de forma rápida os responsáveis pela manutenção do silo quando valores medidos pelos sensotes oscilarem para limites críticos |
Perspectivas do Produto
O produto se destaca por sua abordagem adaptativa e inovadora, utilizando tecnologias como hastes com furos para ventilação controlada, sensores de temperatura e concentração de CO2 integrados, além de uma interface digital para acesso aos dados e controle das condições de armazenamento.
A posição do produto é fortalecida pela demanda crescente por soluções eficientes no setor agrícola, especialmente diante das perdas significativas e dos impactos econômicos causados pelo armazenamento inadequado de grãos. Além disso, a preocupação com a qualidade dos produtos e a busca por práticas sustentáveis na agricultura impulsionam a aceitação e a adoção de tecnologias avançadas para o armazenamento de grãos.
Elicitação de Requisitos
Segundo Summervile e Kotonya (1998), a elicitação de requisitos é a primeira atividade no processo de engenharia de requisitos, na qual se busca entender quais são as necessidades do usuário que devem ser atendidas pelo software que será desenvolvido.
Diante disso, as tabelas a seguir ilustrarão sobre este processo de levantamento de requisitos feito pela equipe, por meio da identificação de épicos e histórias de usuário.
Tabela 1: Épicos
| ID | Nome | Descrição |
|---|---|---|
| E01 | Coleta de dados | O sistema deve coletar informações sobre o estado do silo onde a haste está inserida. |
| E02 | Monitoramento | O sistema deve apresentar as informações coletadas para o usuário |
| E03 | Sistema notificador | O sistema deve informar o usuário sobre a situação do silo |
Fonte: Autor
Tabela 2: História de Usuários
| ID | Épico | Nome | Descrição |
|---|---|---|---|
| US01 | E02 | Medição de temperatura | Eu, como usuário, quero saber a temperatura interna do silo para saber se os grãos estão sendo conservados |
| US02 | E02 | Medição de concentração de CO2 | Eu, como usuário, quero saber a concentração interna de C02 do silo para analisar a troca de oxigênio dos grãos com o ar |
| US03 | E03 | Notificação de perda de conexão | Eu, como usuário, quero ser notificado quando houver a perda de conexão com algum dos instrumentos de coleta de dados no silo |
| US04 | E03 | Formulação de relatório mensal | Eu, como usuário, quero receber, mensalmente, um relatório com as possíveis situações dos grãos no silo |
| US05 | E03 | Notificação de valores anômalos | Como usuário, quero ser notificado pelo sistema quando valores de dados coletados, como temperatura, apresentarem uma mudança significativa em relação ao padrão. |
Fonte: Autor
Tabela 3: Requisitos Funcionais
| ID | Épico | Descrição |
|---|---|---|
| RF01 | E01 | O sistema deve coletar automaticamente dados sobre a situação do silo por meio de sensores de temperatura e concentração de CO2 instalados no silo. |
| RF02 | E02 | O sistema deve apresentar em tempo real as informações de temperatura e concentração de CO2 dos grãos para os usuários. |
| RF03 | E02 | O sistema deve permitir que os usuários visualizem gráficos e relatórios históricos das condições do silo a partir do que foi coletado nos sensores. |
| RF04 | E02 | O sistema deve ser capaz de controlar automaticamente o ambiente dentro do silo, ajustando a potência do ar quente para manter os níveis ideais de temperatura e concentração de CO2. |
| RF05 | E02 | O sistema deve ser capaz de enviar o comando para injetar ar fresco no silo quando os níveis de CO2 estiverem elevados, para evitar a formação de mofo nos grãos. |
| RF06 | E03 | O sistema deve enviar notificações aos usuários em caso de condições anormais dentro do silo, como aumento repentino da temperatura ou concentração perigosa de CO2. |
| RF07 | E03 | O sistema deve notificar os usuários sobre a necessidade de intervenção manual em situações críticas ou falhas de sensores. |
| RF08 | E03 | O sistema deve enviar aos usuários mensalmente um relatório com as situações dos grãos no silo. |
| RF09 | E03 | O sistema deve fornecer uma interface de configuração para permitir que os usuários ajustem os parâmetros de operação, como temperatura de ativação do aquecedor. |
| RF10 | E02 | As mensagens enviadas pelos sensores devem ter o timestamp de quando foi feita a medição |
Fonte: Autor
Tabela 4: Requisitos não funcionais
| ID | Épico | Descrição |
|---|---|---|
| RNF01 | E01 | O sistema deve garantir uma medição precisa e confiável da temperatura interna do silo |
| RNF02 | E01 | O sistema deve garantir uma medição precisa e confiável da concentração de CO2 no silo |
| RNF03 | E02 | O sistema deve ser capaz de lidar com um aumento no número de usuários monitorados sem comprometer o desempenho ou a disponibilidade |
| RNF04 | - | O sistema deve estar disponível para uso dos usuários durante a maior parte do tempo, com tempo de inatividade planejado limitado para manutenção e atualizações programadas |
| RNF05 | - | O sistema deve ser projetado para operar de forma eficiente em termos de consumo de energia, minimizando o impacto ambiental e os custos operacionais para os usuários |
| RNF06 | E02 | Os sensores devem enviar mensagens de dados 1 em 1 segundo |
| RNF06 | E02 | As mensagens enviadas pelos sensores não podem passar de 10KB |
Fonte: Autor
Priorização
O MoSCoW é um método popular de priorização em software para dar previsibilidade a projetos com entregas incrementais. O método faz isso estabelecendo quatro categorias de recursos: Must Have, Should Have, Could Have e Won’t Have, de onde foi cunhada a sigla MoSCoW (Miranda, 2022).
Significado das categorias MoSCoW:
-
Must Have (Deve Ter): Requisitos essenciais para o sucesso do projeto. São funcionalidades imprescindíveis e sem as quais o sistema não terá valor para o cliente.
-
Should Have (Deveria Ter): Requisitos importantes, mas não essenciais para o lançamento inicial do produto. Podem ser adiados para futuras iterações se necessário.
-
Could Have (Poderia Ter): Requisitos desejáveis, mas que não são críticos para o sucesso do projeto. Podem ser incluídos se houver tempo e recursos disponíveis.
-
Won’t Have (Não Terá): Requisitos que foram decididos conscientemente não serem incluídos no escopo do projeto atual. São funcionalidades que podem ser consideradas em versões futuras, mas não são prioritárias no momento.
Tabela 5: Priorização de requisitos
| ID | Requisito | MoSCoW |
|---|---|---|
| PR01 | RF01 | Must |
| PR02 | RF02 | Must |
| PR03 | RF03 | Should |
| PR04 | RF04 | Must |
| PR05 | RF05 | Could |
| PR06 | RF06 | Should |
| PR07 | RF07 | Must |
| PR08 | RF08 | Should |
| PR09 | RF09 | Must |
| PR10 | RF10 | Should |
Fonte: Autor
UML
Em 1997, o Object Management Group (OMG) lançou o Unified Modeling Language (UML). Seu objetivo era oferecer à comunidade de desenvolvedores uma linguagem de design comum para a construção e desenvolvimento de aplicações de software. O UML introduziu uma notação padronizada de modelagem que os profissionais de TI desejavam há muito tempo. Com essa modelagem, esses profissionais passaram a ser capazes de ler e disseminar a estrutura e os planos de design dos sistemas de maneira semelhante à forma como os trabalhadores da construção civil utilizam plantas arquitetônicas para a construção de edificações (BELL, 2023).
Diagrama de camada/componentes
No UML, o diagrama de componentes mostra a estrutura do sistema de software descrevendo seus componentes, interfaces e dependências, podendo ser usado tanto para modelar sistemas de alto nível quanto para detalhar componentes em baixo nível. Este tipo de diagrama é essencial para o desenvolvimento baseado em componentes, onde um sistema de software é dividido em componentes e interfaces reutilizáveis e substituíveis. Eles são úteis para definir aspectos executáveis e reutilizáveis de um sistema, identificar problemas de configuração de software através de relacionamentos de dependência e apresentar uma representação precisa de um aplicativo de software antes de qualquer alteração ou melhoria (IBM, 2023).
Figura 1: Diagrama arquitetural
Fonte: Autor
A Figura 1 mostra que o sistema de monitoramento de grãos possui duas etapas bem definidas. A de eletrônica, que é responsável por fazer o controle da parte de estrutural do projeto e coletar dados dentro do silo, e monitoramento de dados, que a partir do protocolo MQTT recebe as informações coletadas pela parte embarcada e apresentar ao usuarios na forma de dashboards para visualização do usuário final.
Diagrama de Classes
O diagrama de classes é uma representação visual das classes em um sistema de software, bem como seus relacionamentos. Usam-se caixas retangulares para representar classes onde possuem três seções; a primeira o nome da classe; a segunda, se existir, os atributos da classe; e a terceira que representa os metodos da classe. Existem linhas para representar relacionamentos entre as classes nas quais possuem rótulos que indicam a multiplicidade do relacionamento. Por exemplo, um relacionamento "um para muitos" pode ser indicado por uma linha com o numeral "1" em uma extremidade e o símbolo "*" na outra. Um diagrama de classes bem elaborado pode ser uma ferramenta valiosa para comunicar o design de um sistema de software para outras pessoas. Ele pode ajudar a identificar e resolver problemas potenciais no design e pode facilitar a compreensão do sistema como um todo. Todavia, é importante notar que os diagramas de classes não são uma representação completa de um sistema de software. Eles não mostram o comportamento do sistema ou como os componentes do sistema interagem entre si (STARR, 2008).
Figura 2: Diagrama de classes - embarcados
Autor
Esse diagrama da Figura 2 representa, de maneira inicial, como é feita a organização do código para relizar a comunicação com o subsistema de eletrônica do projeto.
Benchmark
Os negócios usam o benchmarking como uma estratégia fundamental para avaliar e comparar suas práticas, desempenho e resultados com os de seus concorrentes e referências do mercado. As empresas podem melhorar sua competitividade e alcançar melhores resultados ao aprender como outras empresas estão se destacando e descobrir as melhores práticas do mercado. Neste contexto, o benchmarketing foi feito no projeto para a tomada de decisões e a busca pela excelência no quesito condensação em silos.
Em um mercado tão competitivo e dinâmico como o de sistemas de aeração para unidades armazenadoras, o benchmarking dessas empresas líderes oferece insights valiosos para identificar as melhores práticas e tendências emergentes, permitindo que outras empresas se inspirem e busquem aprimorar suas próprias estratégias e produtos. Aqui temos algumas empresas que oferecem um serviço equivalente ao nosso projeto.
Tabela 6: Produtos Relevantes
| Empresa | Produto | Descrição | Link |
|---|---|---|---|
| GSI | Ventiladores | Nos sistemas de aeração, a relação entre as médias das áreas de chapas perfuradas, versus a do fundo do silo, fica em torno de 22,5%. Os ventiladores utilizados são centrífugos e de alta eficiência (acima de 90%). | GSI |
| QualyCable | Termometria | Cabos com sensores digitais para silo. Controlador inteligente. Módulo WiFi. Estação meteorológica. Software e Aplicativo de Gerenciamento. Controlador automático de aeração. | QualyCable |
| Qualygran | Termometria | Trabalha de maneira independente e inteligente, sem a necessidade de computador ou software. A própria termometria gera uma conexão Wi-Fi para o cliente usar, assim, o sistema não depende de Internet. A Estação Meteorológica informa: Temperatura ambiente, a Umidade relativa do ar e a ocorrência de Chuva. A memória SD armazena o histórico da armazenagem e da aeração. | Qualygran/Cycloar |
| Weg | Solução de Aeração | Gerencie a aeração da unidade armazenadora de qualquer lugar do mundo. Racionalização do consumo de energia elétrica. Conservação do peso da massa de grão estocada. Redução dos custos de tratamento fitossanitários. Resfriamento prolongado da massa de grãos. Redução de mão de obra e maior segurança na operação. Conservação da qualidade da massa de grão estocada. | Weg |
Fonte: Autor
Fazendo uma comparação dos produtos citados com o Silo Air, podemos analisar o que o nosso faz que os outros não fazem na seguinte tabela:
| Pontos em Comum | Silo Air | GSI | QualyCable | Qualygran/Cycloar | WEG |
|---|---|---|---|---|---|
| Ventilação | ✔️ | ✔️ | |||
| Sensores de Temperatura | ✔️ | ✔️ | ✔️ | ||
| Sensores de Umidade | ✔️ | ✔️ | |||
| Sensores de Concentração de CO2 | ✔️ | ||||
| Controle Digital | ✔️ | ✔️ | ✔️ | ||
| Módulo WiFi | ✔️ | ✔️ |
Protótipo Alta Fidelidade
Você pode encontrar o protótipo de software no documento de prova de conceito, onde detalhamos todas as ferramentas que serão empregadas.