Desenho e implementação de um Sistema de Apoio à Decisão para o Planeamento do Abastecimento da Biomassa Florestal

Texto

(1)FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO. Desenho e implementação de um Sistema de apoio à decisão para o Planeamento do abastecimento da Biomassa Florestal Carolina Catorze. Mestrado em Engenharia de Software Orientador: António Manuel Lucas Soares Co-orientador: Alexandra Sofia da Fonseca Marques. 24 de Julho de 2019.

(2)

(3) Desenho e implementação de um Sistema de apoio à decisão para o Planeamento do abastecimento da Biomassa Florestal. Carolina Catorze. Mestrado em Engenharia de Software. 24 de Julho de 2019.

(4)

(5) Resumo A consciencialização para o aproveitamento e valorização da biomassa florestal tem aumentado recentemente de forma considerável. No entanto, as caraterísticas destes produtos florestais não permitem a sua fácil e rápida utilização. Com este projecto o planeamento do abastecimento da biomassa fica facilitado, pois o produtor disponibiliza a pilha, o prestador de serviços compra, processa e transporta-a para centrais de biomassa. Apesar de o desenvolvimento de software de apoio à decisão ser desafiante, complexo e criterioso, a sua implementação traduz-se num considerável número de vantagens para os utilizadores, de forma a que o processo de planeamento possa ser facilitado. Assim, esta dissertação propõe o desenho e implementação de um sistema de apoio à decisão para o planeamento do abastecimento da Biomassa Florestal. O sistema foi especificado e implementado tendo em conta os requisitos dos stakeholders. Para esse efeito, foram adotadas metodologias de conceção de sistemas alinhadas com as boas práticas na literatura, nomeadamente a framework SCRUM. Resultando assim num sistema de apoio à decisão que permite a interação de forma user friendly de todas as suas funcionalidades.. i.

(6) ii.

(7) Abstract Awareness of the use and enhancement of forest biomass has recently increased considerably. However, the characteristics of these forest products do not allow their easy and quick use. With this project the biomass supply planning is facilitated, because the producer makes the pile available, the service provider buys, processes and transports it to biomass plants. Although the development of decision support software is challenging, complex and judicious, its implementation translates into a considerable number of benefits for users, so that the planning process can be facilitated. Thus, this dissertation proposes the design and implementation of a decision support system for planning the supply of Forest Biomass. The system was specified and implemented taking into account stakeholder requirements. For this purpose, methodologies for designing systems aligned with good practices in the literature, namely the SCRUM framework, were adopted. This results in a decision support system that allows a user friendly interaction of all its functionalities.. iii.

(8) iv.

(9) Agradecimentos A realização desta dissertação de mestrado em Engenharia de software contou com importantes apoios e incentivos sem os quais esta dissertação não se teria tornado uma realidade e aos quais demonstro a minha enorme gratidão. Em primeiro lugar gostaria de agradecer aos meus orientadores, Sr. Professor Doutor António Lucas Soares e Sra. Professora Doutora Alexandra Marques por me terem proposto um tema tão atual e por me transmitirem tanto conhecimento neste ano que passou tão rápido. Gostaria também de dar especial destaque à Sra. Professora Doutora Alexandra Marques pelo tempo despendido, pela paciência e pela dedicação incansável. Não posso deixar de agradecer ao INESC TEC pela oportunidade de utilizar as suas instalações e possibilidade de interagir e aprender com os seus colaboradores. Em especial ao Engenheiro Ricardo Soares e ao Engenheiro Jorge Cunha que me apoiaram tanto no trabalho como nas pausas. Aproveito também para fazer uma agradecimento à minha família em geral que sempre me apoiou e me perdoou algumas ausências. Em particular aos meus pais que financiaram e acima de tudo sempre acreditaram em mim e nas minhas capacidades, obrigada por fazerem de mim uma privilegiada, obrigada por tudo. Gostaria também de agradecer aos meus amigos por todo o apoio e pedir desculpa pelas ausências. Em especial aos Fora de Rota. Por fim agradeço a todos aqueles que de alguma forma contribuíram para esta etapa.. Carolina Martins Catorze. v.

(10) vi.

(11) “For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. ”. Richard P. Feynman. vii.

(12) viii.

(13) Conteúdo 1. 2. 3. 4. Introdução 1.1 Contexto . . . . . . . . . . . . . 1.2 Caracterização do Problema . . 1.3 Objetivos e Resultados esperados 1.4 Estrutura da dissertação . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 1 1 2 2 3. Enquadramento Teórico 2.1 Desenho e implementação um DSS . . . . 2.1.1 Componentes . . . . . . . . . . . 2.1.2 Processos . . . . . . . . . . . . . 2.2 DSS’s para apoiar o planeamento florestal 2.2.1 DSS’s para a Biomassa Florestal .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 5 6 6 7 9 11. . . . . . .. 13 13 14 15 15 15 16. . . . . . . . . . . . . . . . .. 17 17 17 17 17 17 17 18 18 18 18 18 18 18 18 27 27. . . . .. . . . .. . . . .. . . . .. Metodologia 3.1 Caracterização do problema . . . . . . . . 3.2 Definição da arquitectura do DSS . . . . . . 3.3 Especificação, requisitos e mockups . . . . 3.4 Implementação do DSS . . . . . . . . . . . 3.4.1 Ciclo de Vida do Desenvolvimento . 3.5 Análise da implementação . . . . . . . . . Análise de requisitos do forSCOPE 4.1 Introdução . . . . . . . . . . . . . . 4.1.1 Âmbito . . . . . . . . . . . 4.2 Práticas consideradas . . . . . . . . 4.3 Descrição geral . . . . . . . . . . . 4.3.1 Perspectiva . . . . . . . . . 4.3.2 Funcionalidades . . . . . . 4.3.3 Características do utilizador 4.4 Requisitos de interface externa . . . 4.4.1 Interfaces dos utilizadores . 4.4.2 Interfaces de Hardware . . 4.4.3 Interfaces de Software . . . 4.4.4 Interfaces Comunicações . 4.5 Funcionalidades do Sistema . . . . 4.5.1 Casos de Uso . . . . . . . 4.5.2 Registo e Autenticação . . . 4.5.3 Logout . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. ix. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . ..

(14) x. CONTEÚDO. 4.6 5. 6. 4.5.4 Acesso ao perfil . . . . . . . . . . . . . 4.5.5 Inputs de necessidades e disponibilidades 4.5.6 Criação de planos . . . . . . . . . . . . . 4.5.7 Matriz de Rastreabilidade de Requisitos . Storyboards . . . . . . . . . . . . . . . . . . . .. Implementação 5.1 Ferramentas utilizadas . . . 5.2 Âmbito . . . . . . . . . . . 5.3 Estrutura de dados . . . . . . 5.4 Interfaces gráficas . . . . . . 5.5 Disseminação do forSCOPE Conclusões e Trabalho Futuro. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 28 28 32 34 36. . . . . .. 43 43 44 44 46 54 55. A Mockups. 57. Referências. 99.

(15) Lista de Figuras 1.1 1.2. Breve descrição do processo Logístico da Biomassa [14] . . . . . . . . . . . . . Árvore de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 2. 3.1 3.2 3.3. Etapas que constituem a metodologia . . . . . . . . . . . . . . . . . . . . . . . . Arquitectura do Software [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . Ciclo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13 14 15. Planeamento Logístico da Biomassa . . . . . . . . . . . . . . . . . . . . . . . . UC1.1 Registar pilha de biomassa . . . . . . . . . . . . . . . . . . . . . . . . . UC1.2 Registar pedido de Biomassa . . . . . . . . . . . . . . . . . . . . . . . . UC1.3 Registar parques intermédios e UC1.4 Registar equipamento/colaboradores/veículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 UC2.1 Criar plano e UC2.2 Analisar cenário e plano . . . . . . . . . . . . . . . 4.6 UC3 Validar o plano reunindo comentários de outros utilizadores . . . . . . . . . 4.7 Monitorização e controlo dos processos logísticos da biomassa . . . . . . . . . . 4.8 Storyboard Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Storyboard Registo de pilhas e entrada em planos visível no mapa e no gantt Produtor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Storyboard Registo de equipas e entrada em plano - Fornecedor de serviços . . . 4.11 Storyboard Criação de cenários e planos - Planeador . . . . . . . . . . . . . . . 4.12 Storyboard Administração do sistema - Administrador . . . . . . . . . . . . . .. 20 21 22. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9. 45 46 47 48 49 50 51 52 53. 4.1 4.2 4.3 4.4. Modelo entidade Relacionamento - forSCOPE Registo no software . . . . . . . . . . . . . . Login no software . . . . . . . . . . . . . . . Home do produtor . . . . . . . . . . . . . . . Home do produtor, formulário aberto . . . . . Home do produtor, formulário . . . . . . . . Home com Gráfico de gantt . . . . . . . . . . Home com mapa e rota . . . . . . . . . . . . Home do planeador . . . . . . . . . . . . . .. xi. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 23 24 25 26 37 38 39 40 41.

(16) xii. LISTA DE FIGURAS.

(17) Lista de Tabelas 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10. Requisitos Funcionais - Registo e Autenticação . . . . . . . . . . . . . . . . Requisitos Funcionais - Logout . . . . . . . . . . . . . . . . . . . . . . . . . Requisitos Funcionais - Acesso ao perfil . . . . . . . . . . . . . . . . . . . . Requisitos Funcionais - Inputs de necessidades e disponibilidades . . . . . . Requisitos Funcionais - Inputs de necessidades e disponibilidades continuação Requisitos Funcionais - Inputs de necessidades e disponibilidades continuação Requisitos Funcionais - Criação de planos . . . . . . . . . . . . . . . . . . . Requisitos Funcionais - Criação de planos continuação . . . . . . . . . . . . Matriz de rastreabilidade de Requisitos . . . . . . . . . . . . . . . . . . . . . Matriz de rastreabilidade de requisitos continuação . . . . . . . . . . . . . .. xiii. . . . . . . . . . .. . . . . . . . . . .. 27 27 28 29 30 31 32 33 34 35.

(18) xiv. LISTA DE TABELAS.

(19) Acrónimos INESC TEC GUI GIS SDLC JSON API AJAX. Instituto de Engenharia de Sistemas e Computadores, Tecnologia e Ciência Graphical User Interface Geographic information system Ciclo de vida do desenvolvimento de sistemas JavaScript Object Notation Application Programming Interface Asynchronous Javascript and XML. xv.

(20)

(21) Capítulo 1. Introdução 1.1. Contexto. O planeamento da gestão da biomassa florestal, tem sido crescentemente explorado englobando aspectos ambientais, económicos, administrativos, legais e sociais uma vez que a sociedade tem vindo a reforçar o papel crucial da biomassa como fonte de energia primária global. A valorização da biomassa como fonte de energia é muito desafiante, pois existe uma enorme variedade de fontes de biomassa e de tecnologias de conversão, tornando essencial desenvolver cadeias de valorização otimizadas que permitam criar mercados viáveis [19]. A consciencialização para um mais eficiente aproveitamento dos recursos naturais está a aumentar, assim é previsível que a procura de biomassa florestal também aumente requerendo soluções mais poderosase mais focadas em facilitar a sua utilização, em analisar objetivos tais como minimizar custos e ao mesmo tempo manter um impacto ambiental mínimo. Ferramentas de apoio às operações logísticas de biomassa florestal que permitem quantificar, qualificar e distinguir os diferentes tipos de biomassa são necessários e com brevidade de forma a otimizar os processos associados ao seu consumo eficiente.. Figura 1.1: Breve descrição do processo Logístico da Biomassa [14] 1.

(22) 2. Introdução. 1.2. Caracterização do Problema. Este projeto foi proposto pelo INESCTEC surgindo da necessidade de mostrar o valor o modelo de otimização desenvolvido para a gestão e o planeamento da cadeia de Biomassa com teor energético variável. Cada entrada no modelo corresponde a uma solução que possibilita o planeamento tático para um determinado serviço pretendido numa determinada data, utilizando os recursos envolvidos de uma forma rentável e eficiente. Este projecto está inserido no projecto de investigação EasyFlow, que tem por objectivo aumentar o uso e valorização da biomassa florestal, diminuindo os custos logísticos com os modelos de optimização integrados. Para isso existe a necessidade de mostrar o seu potencial através de interfaces gráficas, que permitem a utilização do modelo de optimização de forma user friendly.. 1.3. Objetivos e Resultados esperados. Este projecto irá especificar e implementar interfaces gráficos de utilizador (GUI) com grande usabilidade, integradas com módulos de optimização. Com o objectivo principal de obter uma boa resposta por parte dos potenciais clientes, a user experience tem de ser agradável e intuitiva. Na seguinte figura estão estabelecidos os objectivos para o projeto, o objetivo principal e os subobjetivos que têm de ser cumpridos para que o projecto seja um sucesso.. Figura 1.2: Árvore de objetivos.

(23) 1.4 Estrutura da dissertação. 1.4. 3. Estrutura da dissertação. O primeiro capítulo está reservado a uma contextualização do tema em que se insere o projecto e detalhando os seu objectivos. No seguinte é revisto o estado da arte quanto ao desenvolvimento de sistemas de apoio à decisão com ênfase para DSS’s para a biomassa florestal. Na terceira parte é descrita a metodologia geral e detalhada de cada processo do projecto. Já no quarto capítulo começam a ser definidos os requisitos e a suas relações com os casos de uso e os mockups. No capítulo quinto é descrita a implementação e os seus resultados sendo concluído este documento como uma reflexão do trabalho realizado e os próximos passos..

(24) 4. Introdução.

(25) Capítulo 2. Enquadramento Teórico O conceito de Decision Support System (DSS) sistema de apoio à decisão, foi desenvolvido por Gorry e Scott Morton em 1971, tendo por base o trabalho de Herbert Simon focado apenas nas tomadas de decisões organizacionais, trabalho esse realizado em 1960 [15]. Os sistemas de apoio à decisão têm como objectivo ajudar no processo de estruturação e resolução de tomadas de decisão. Para tornar as decisões mais informadas, as soluções mais oportunas e aumentar a sua eficiência quando o conhecimento e os seus impactos são incertos, contestáveis, ou até mesmo voláteis. Embora o conceito de DSS esteja bastante associado ao sucesso e ao progresso, nem sempre é garantido, pois devido a pobres concepções, falhas no envolvimento dos stakeholders e até má implementação, o sucesso nem sempre é atingido,[11] por vezes os DSS’s não são utilizados pelos utilizadores finais pretendidos, isto é, pelos utilizadores definidos no início do projecto como utilizadores alvo. Existem quatro tipos de sistemas de apoio à decisão. Os sistemas orientados pela decisão, orientados pelo processo, orientados pelos dados e orientados pelo sistema [23]. O desenho de um sistema de apoio à decisão é composto por uma base de dados com acesso a dados internos e externos, modelos de optimização e uma interface que permita ao utilizador a tomada de decisão mais eficiente [21]. Inicialmente os DSS’s apenas apoiavam decisões individuais mas mais recentemente já auxiliam decisões de grupo em especial grupos virtuais. O apoio à decisão baseado em modelos pode ser dividido em três etapas a formulação, a solução e a análise. A formulação refere-se à especificação de um problema de decisão de forma algébrica inicialmente e depois de forma a ser compreendida por um algoritmo, isto é, o desenvolvimento de um modelo para resolver o problema encontrando possíveis soluções. A solução é apenas o resultado da fase da formulação, ou seja, a solução algorítmica do modelo. A etapa da análise, como o nome indica é análise dos resultados, permitindo interpretações através da visualização da solução numa forma perceptível e útil para o utilizador [18]. O desenho gráfico do sistema deve ter em conta o contexto do utilizador alvo, tendo por base uma interface user-friendly permitindo uma interação clara entre o utilizador e o DSS.[15, 21] 5.

(26) 6. Enquadramento Teórico. 2.1. Desenho e implementação um DSS. Nesta secção serão abordadas diferentes metodologias de desenho e implementação de sistemas de apoio à decisão definidas na literatura. Serão focados os componentes padrão de um DSS e os seus os processos de desenvolvimento mais usados.. 2.1.1. Componentes. Os componentes típicos de um DSS são, como acima referidos, um módulo de base de dados, um módulo com o modelo de optimização e o módulo da interface gráfica. O sistema de apoio à decisão CAFE implementou um módulo de base de dados que armazena os dados, um módulo de gestão de tarefas que permite fazer a gestão dos dados e das tarefas com o módulo de análise de dados, todo este processo leva a um resultado que apenas será claro para o utilizador através do módulo da interface gráfica Web-based [25]. F.G. Filip em [10] sugere também módulos GIS, geographic information system, que permite ao utilizador visualizar e interagir com os dados num mapa facilitando assim a tomada de decisão em termos gráficos. Outra plataforma que implementa o GIS é CyberGIS Gateway com a integração do modelo BioScope, uma infraestrutura cibernética alto desempenho, e uma interface web interativa [12]. Um componente importante referido em [13] é o sistema de apoio à decisão ser um mediador no contexto. No DSS referido em [8] quatro módulos diferentes compõem o sistema, o módulo de informação; o modelo de gestão integrada; o módulo de preferências de decisão; o módulo de localização. Módulo de informações integra a base de dados necessária para desenvolver o modelo. A ligação à base de dados e a integração são feitas neste módulo, nomeadamente pela utilização de informação numérica introduzida com referências espaciais específicas. Módulo de gestão integrado permite otimizar os critérios mais relevantes considerados, usando um modelo de gestão bioeconomica, que integra todas as informações disponíveis e produz resultados por unidade biofísica e por tipo de propriedade. O módulo de preferências de decisão permite a definição de consenso entre diferentes partes interessadas, usando uma metodologia de programação de objetivos estendida, que permite definir o consenso da maioria e da minoria entre diferentes objetivos, mas também soluções intermediárias. Esta ferramenta é particularmente importante em situações nas quais existem diferentes stakeholders com diferentes pontos de vista e preferências, em relação a vários critérios diferentes. Os pesos obtidos para os critérios podem ser inseridos novamente na abordagem implementada no módulo anterior. Módulo de localização complementa o modulo de gestão integrado anterior e permite que os resultados do módulo de gestão integrado sejam distribuídos para uma aplicação de campos detalhados. O sistema em [26] resolve os principais pontos, incluindo a preparação de recursos do modelo, a gestão e publicação dos recursos do modelo e a invocação e execução de serviços. A análise ocorre utilizando cenários para o sistema e tipos de recursos de geo-simulação. Também foi implementada uma interface para o utilizador e o protocolo de serviço entre instâncias de execução de modelo e o sistema para enriquecer a interação para os utilizadores do serviço. Finalmente, é.

(27) 2.1 Desenho e implementação um DSS. 7. fornecida uma implementação do sistema de invólucro e dois casos (modelo SWAT e FVCOM) no sistema. Assim, publicando a geoanálise dos modelos como serviços no ambiente web aberto, o sistema suporta reutilização orientada a serviços e a partilha de modelos de geoanálise e pesquisa geográfica.. 2.1.2. Processos. O ciclo de vida de desenvolvimento de sistemas (SDLC) pode ser visto como um conceito fundador de todas as metodologias que foram desenvolvidas no campo da tecnologia da informação. O desenvolvimento e implementação de DSS, implica grandes mudanças organizacionais. O desenvolvimento de um DSS a partir do SDLC não é a melhor opção devido à sua rigidez e ao enorme volume de documentação do projeto necessário. Uma alternativa ao conceito SDLC é a análise ROMC. De acordo com esse modelo, a análise do sistema se concentra mais nas representações (R), operações (O), auxiliares de memória (M) e controlos (C). O conceito de ROMC usado para o design do DSS, pressupõe que o analista do sistema investigará e criará modelos para as representações existentes que serão usadas como ferramentas de comunicação entre o DSS e os utilizadores. O conceito de ROMC é muito útil para projetar a interface DSS [7]. A Análise da Categoria Funcional é outro método de design do DSS. Este método revela as funções necessárias para o design do DSS. As funções são selecionadas a partir de uma lista de funções, tais como: seleção, agregação, simulação e otimização. Esse método tem sua melhor utilidade no projeto baseado em conhecimento e baseado em modelo. O processo geral de desenvolvimento de DSS é composto pelos seguintes elementos ou fases: Identificação de objetivos e recursos de DSS , Análise do sistema, Requisitos funcionais, Requisitos de interface, requisitos de Segurança, Projeto do sistema, Construção do sistema, Implementação do sistema, Adaptação incremental. O método RAD é caracterizado por um desenvolvimento rápido e iterativo dos sistemas de informação, usando protótipos e instrumentos CASE. As principais características desse método são: combina as melhores técnicas e procedimentos para o rápido desenvolvimento do sistema. O projeto é feito com a contribuição direta dos utilizadores, avançando com a possibilidade de avaliação do sistema, antes que o sistema seja entregue. Implementação sequencial e iterativa do sistema. O sistema é desenvolvido em etapas, assim como as sugestões e necessidades do utilizador. O uso de protótipos é o método mais comum para um rápido desenvolvimento dos sistemas de informação. Ele pode ser encontrado na quase totalidade das técnicas e métodos usados para desenvolver sistemas de informação. Este método é conhecido sob o nome de design iterativo. O uso de protótipos no desenvolvimento do DSS tornou-se, nos últimos anos, uma atividade comum no desenvolvimento do DSS. É focado numa atividade específica, dinâmica e complexa, que requer uma série de atualizações e testes. Essa pode ser uma das razões pelas quais o método dos protótipos se tornou tão popular nos últimos anos. A tendência atual relacionada à complexidade do DSS impõe um processo de projeto integrado e rápido, que deve ser orientado para um reprocessamento dos componentes do sistema..

(28) 8. Enquadramento Teórico. Segundo [13] Os princípios-chave enfatizam um foco claro do envolvimento do utilizador, desenvolvimento de um sistema iterativo e incremental com prototipagem inicial e contínua e avaliações realizadas no contexto do uso. O projeto de sistemas centrado no utilizador consiste em três fases principais; análise de requisitos, desenvolvimento de sistemas evolutivos (que é tanto iterativo quanto incremental) e a sua implementação. O sistema de apoio à decisão pode ser desenvolvido das seguintes formas: Método do protótipo e Abordagem do ciclo de vida. No método do protótipo, os métodos iniciais são desenvolvidos primeiro. Uma vez implementado, o sistema é refinado e modificado de acordo com novas especificações. Este processo iterativo e é seguido até que o sistema seja aceite pelos stakeholders. Na abordagem do ciclo de vida, o desenvolvimento do DSS é realizado em diferentes fases. As fases são: Inteligência, Design, Escolha, Implementação e Monitorizar. A escolha do design DSS é decidida com base na natureza do sistema e suas aplicações [21]. Em [27] é enfatizado o facto do DSS necessitar de ser sensível a algumas limitações, tais como a possível mudança do utilizados, novas maneiras de utilizar a informação em prol da decisão do utilizador e dos conhecimentos que eles possuem. É sugerido dividir o desenvolvimento em duas fases, a fase da análise de atores e tomada de decisão e a fase do design interativo. A primeira fase é uma promissora técnica participativa que pode ser explorada, é o mapeamento cognitivo, que é uma técnica de mapeamento mental que permite aos utilizadores visualizarem seus processos de tomada de decisão e considerações com os pesquisadores que facilitam. A segunda fase é onde os requisitos do utilizador são traduzidos em design no “espaço de design”. Como o trabalho durante as etapas desta fase envolve um designer profissional, os materiais e ferramentas utilizados e descritos, bem como os consequentes efeitos no design, podem ser representante da experiência e das preferências do designer. Recomendações de Melhores Práticas para desenvolver um Sistema de apoio à decisão segundo [15] Projectar interfaces userfriendly com base na elucidação das necessidades e capacidades dos utilizadores. Design para facilidade de uso - A interface do utilizador deve ser adaptável aos diferentes tipos de utilizadores, com base em seus conhecimentos / experiências. As ferramentas devem ser bem documentadas com recursos de ajuda adequados. Design para utilidade No início, é necessário identificar claramente os utilizadores finais e as partes interessadas e suas funções, responsabilidades, necessidades e capacidades. Tempo e recursos para uma análise de requisitos ou pesquisa de usabilidade é essencial. Considerar incluir cientistas sociais para fornecer informações sobre os fatores humanos envolvidos no projeto do DSS. Foco no sistema geral e quais problemas devem ser resolvidos? Quem vai usar o DSS? Que valor agregado isso traz? Trabalhar com utilizadores finais e as partes interessadas para definir o sucesso do projeto, incluindo considerando a sua relação custo-eficácia vs. outros meios de alcançar resultados. Seleção do modelo base em escala espacial e temporal e nível de complexidade requerido para problemas e para se adequar às estratégias de decisão do utilizador final. Ser honesto sobre os pontos fracos do sistema e as áreas que precisam de melhorias, estabelecendo confiança e credibilidade incluindo incertezas e suposições do cronograma de desenvolvimento do modelo permitindo discussão com os utilizadores e fornecer feedback sobre suas sugestões / ideias. Proporcionar às partes interessa-.

(29) 2.2 DSS’s para apoiar o planeamento florestal. 9. das a oportunidade de contribuir significativamente durante o desenvolvimento. Colaboração regular entre todas as partes para entender as requisitos e compartilhar conhecimentos. Desenvolver e manter documentos de scope (incluindo questões levantadas, decisões tomadas). Desenvolver ativamente a capacidade dentro da comunidade de utilizadores finais e partes interessadas. Implementar estratégias para garantir que o Sistema de apoio à decisão seja fácil e barato de usar. Planear a longevidade. Plano de continuidade do apoio ao sistema. Garantir que as informações necessárias e as base de dados possam ser facilmente atualizadas. Criar um plano de negócios para definir explicitamente custos e resultados esperados. Projetar um sistema de apoio à decisão que possa ser usado para resolver vários problemas. Começar simples e pequeno. Desenvolver ferramentas incrementalmente usando tecnologias conhecidas. Evitar a complexidade do modelo. Usar uma abordagem modular para modelagem ou estruturas de modelagem. Os modelos mais complexos tendem a exigir interfaces complicadas e a pesquisa em [17] acaba de começar a explorar as múltiplas possibilidades do design de interface orientável. Todavia diferenças estatisticamente significativas foram encontradas, todos os aspectos experimentais deste trabalho devem ser estendidos em estudos completos por si mesmos. O debate público sobre os desafios globais, como a mudança climática, atualmente está muito mal desenvolvido, tendo como esperança que uma maior acessibilidade e envolvimento com modelos complexos de decisão espacial ajudem a comunidade a superar a lacuna de conhecimento. Trazendo conhecimento de uma forma mais user-friendly.. 2.2. DSS’s para apoiar o planeamento florestal. A procura por ferramentas para apoiar o planeamento e a tomada de decisões evoluiu. Com o crescimento das populações, as procuras sobre os recursos florestais aumentaram e o suprimento de produtos madeireiros e não-madeireiros da floresta tornou-se crucial para o desenvolvimento das populações humanas. Devido à sobre-exploração, regulamentos e diretrizes foram necessários para garantir um fornecimento sustentável de madeira. Na Europa, as escolas de silvicultura foram estabelecidas no final do século XVIII e foram as origens das abordagens clássicas para o crescimento e a regulação de produtividade em florestas. A floresta era vista como um recurso a ser utilizado de maneira controlada[22]. No início dos anos 80, o DSS também captou interesse no domínio florestal e, desde então, o DSS tem sido crescentemente aplicado nas ciências florestais. Davis e Clark em 1989, numa das primeiras revisões do desenvolvimento e aplicação de DSS na gestão de recursos naturais identificaram cerca de 100 DSS [22]. As conquistas científicas e as experiências adquiridas nas ciências da decisão, na modelagem de ecossistemas e na tecnologia da informação influenciaram o processo de desenvolvimento do DSS e sua aplicação. As primeiras tentativas de fornecer uma decisão baseada na ciência estrutura de suporte baseada nas necessidades do utilizador, princípios de ciência de decisão e tecnologia de ponta, como interoperabilidade, modularidade e transferibilidade de componentes de software,.

(30) 10. Enquadramento Teórico. podem ser encontrados na estratégia para o desenvolvimento e aplicação de DSSs para recursos naturais e ambiente a partir do ano de 1998[22]. A Ação COST FP0804 - FORSYS - Forest Management Decision Support Systems, fornece uma visão geral das experiências mundiais com o desenvolvimento e aplicação de DSSs florestais para a gestão florestal como uma base sólida para inovação tecnológica e colaboração entre parceiros de pesquisa. Uma revisão dos DSSs florestais existentes, bem como uma descrição dos métodos, modelos e técnicas aplicadas. Neste contexto, os modelos florestais são usados em grande medida para prever as consequências de diferentes opções de gestão. Quase metade de todos os casos de DSS usa um GIS para apoiar a análise espacial [2]. Uma revisão das informações sobre os DSSs coletados no FORSYS Wiki indica que poucos DSSs foram usados em um contexto colaborativo. A maioria dos DSSs atualmente utilizados não inclui meios para lidar com as preferências do grupo. Em muitos casos, é possível incluir apenas as preferências de um tomador de decisão. Apenas alguns DSSs (por exemplo, HEUREKA, NED e MONSU) incluem variáveis que não estão relacionadas à produção de madeira. Apenas alguns sistemas podem ser desenvolvidos pelos utilizadores. A revisão da página do Wiki FORSYS e a literatura também mostra que poucos DSSs incluem ferramentas para MCDA (Multicriteria Decision Analysis)[16]. O MCDA, baseado em GIS, ajuda a trazer informações científicas sobre os ecossistemas florestais em ambientes de tomada de decisão, sem enfraquecer os dados. Isso permite que os gestores florestais lidem com as complexidades dos valores concorrentes em uma base local a local, em vez de implementar políticas gerais generalizadas que reforcem a fragmentação da paisagem e os cenários de uso dominante, levando a uma tomada de decisão mais consciente. Os seguintes recursos são identificados como os drivers tecnológicos futuros emergentes para o desenvolvimento do DSS em [22]. Primeiro as redes sociais pois podem reunir pessoas e seus conhecimentos usando várias tecnologias e variados recursos como a voz e recursos visuais compartilhados. De seguida indústria do jogo possibilitou a disseminação de inovações sociotécnicas. Já os desenvolvimentos recentes no campo de serviços GIS permitem que pelo menos algumas das limitações nos processos de participação pública sejam superadas. Análises espaciais e estudos sobre alocação de terras não estão mais limitados a especialistas em GIS; o público em geral é capaz de se envolver em tais processos de tomada de decisão. A "Internet das coisas"é um driver adicional para futuros desenvolvimentos do DSS. Será possível que quase todos os dispositivos, seres humanos e processos estejam conectados à World Wide Web com um identificador único. Isso permitirá que os developers do DSS forneçam serviços em execução em smartphones que se comuniquem com outros dados públicos e privados. A necessidade de adaptação às alterações climáticas tem despertado interesse adicional em abordagens de gestão adaptativa no apoio à decisão. Assim, os diferentes problemas emergentes na floresta estimularam o desenvolvimento de DSSs e aumento da demanda para integrar várias técnicas, modelos e métodos de forma holística e flexível [22]. Detalhando um pouco mais com casos concretos a abordagem adoptada pelo DSS em [24] é usar as camadas GIS de produtividade florestal para vincular um site / local (ou polígono) sele-.

(31) 2.2 DSS’s para apoiar o planeamento florestal. 11. cionado a uma tabela de rendimento de pesquisa (ou meta-modelo) que é gerada a partir do DSS de gestão florestal. Outro exemplo de integração do GIS é o ELECTRE TRI, que integra ferramentas de análise e gestão de dados geográficos, modelos de optimização e a interface para o utilizador [20]. A interface do ELECTRE TRI permite a configuração, previsão, visualização e análise dos resultados do modelo tudo no mesmo ambiente, existindo assim coerência no sistema, que aumenta a confiando do utilizador no sistema. Em [24] são sugeridos, como forma de aumentar o envolvimento e compromisso do utilizador, seminário de transferência técnica, grupo de utilizadores e artigos sobre as implicações e impactos das novas funcionalidades. Afirma também que é necessário um esforço continuo para conquistar o a confiança do utilizador e melhor a usar imagem dos DSS’s de gestão florestal. Outra sugestão é a de aumentar o scope do sistema de modelagem traduzindo também os resultados numa linguagem de fácil compreensão por parte do utilizador, algo mais gráfico.. 2.2.1. DSS’s para a Biomassa Florestal. No Sistema em [24] a inovação é a inclusão de propriedades da madeira e sua distribuição. Um protótipo de módulo de simulação de qualidade de produto final estava em desenvolvimento para completar a cadeia de valor e conectar a tomada de decisões de crescimento florestal precoce com o desempenho dos produtos finais. Em [20] é reforçada a necessidade de agradar o utilizador com exploração das potencialidades de exibição gráfica do ELECTRE TRI, que fornece ao tomador de decisão informações cada vez mais ricas e fáceis de entender. Com o GIS, os dados podem estar disponíveis num formato que será facilmente interpretado, pode ser exibido de forma interativa, está pronto para o processamento digital e pode ser facilmente atualizado..

(32) 12. Enquadramento Teórico.

(33) Capítulo 3. Metodologia A dimensão deste projeto impõe que seja definido uma plano de projeto, uma metodologia bem definida e adaptada ao mesmo. A metodologia definida foi uma fusão entre a investigação cientifica simples orientada ao problema com a framework SCRUM1 aproveitando os ciclos de feedback. O projeto proposto nesta dissertação implica um trabalho dividido em cinco fases: investigação do problema, a definição da arquitectura, a especificação de requisitos e mockups, a implementação e a análise de implementação. Estas duas ultimas fases beneficiam da fusão com SCRUM, pois compreendem os ciclos de feedback melhorado assim o valor do produto final. Na figura 4.1, é apresentado um esquema que ilustra a sequência das etapas que constituem a metodologia adotada para este projeto.. Figura 3.1: Etapas que constituem a metodologia. 3.1. Caracterização do problema. A primeira análise ao problema é realizada através de uma consulta a estudos que descrevem as técnicas já utilizadas e desenvolvidas na abordagem de problemas de teor semelhante ao deste 1 Scrum(subs): Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.[9]. 13.

(34) 14. Metodologia. projeto. Começa aqui, também o primeiro contacto com os stakeholders de forma a introduzir já a próxima etapa que inclui a especificação, a definição dos requisitos e a elaboração de mockups.. 3.2. Definição da arquitectura do DSS. Nesta etapa é tido em conta o trabalho já começado na arquitectura deste software. No diagrama podemos ver a constituição do DSS, conforme previsto pelos investigadores do INESC TEC envolvidos no projecto EasyFlow. Começando pelo nível mais a baixo temos a camada da base de dados, que está localizada no último nível da arquitetura e consiste no arquivo de dados relativos aos utilizadores, os dados compostos pela lista de pedidos, informações acerca dos recursos, das suas características dos produtos, dos pedidos e por fim, dos planos existentes que são armazenados neste nível. Apesar dos dados correspondentes às localizações, tanto dos pontos de entrada como os de saída do modelo necessitarem de um tratamento prévio estes também serão armazenados nesta camada. Na seguinte camada temos a camada das aplicações que contém o mecanismo de otimização que por sua vez compreende o módulo de otimização tático e a fila de execução de cenário. Esta camada envolve também o mecanismos de controlo que irá monitorizar através de sensores, da camada de interoperabilidade. Na última camada temos a interface que irá mostrar o trabalho feito pela camada anterior de forma a que utilizador consiga inserir os dados de modo a usufruir tanto do mecanismo de optimização como do mecanismo de monitorização e controlo. Os atores para acederem a este serviço terão de estar devidamente registados e autenticados.. Figura 3.2: Arquitectura do Software [14].

(35) 3.3 Especificação, requisitos e mockups. 3.3. 15. Especificação, requisitos e mockups. Nesta fase começam as reuniões quinzenais com os stakeholders de forma a entabular a especificação do sistema e os seus requisitos. Quando os requisitos estão estáveis procede-se à elaboração dos mockups, também sujeitos às reuniões. Os mockups foram produzidos na ferramenta Figma2 o que permitiu uma interação direta dos stakeholders nos protótipos encurtando assim a distância natural entre os stakeholders e o designer gráfico.. 3.4. Implementação do DSS. A etapa de implementação é destinada a todas as atividades que compreendem o desenvolvimento da solução ao nível da implementação do software correspondente à arquitetura desenvolvida, respeitando os requisitos definidos na especificação das interfaces e os mockups produzidos e aprovados pelos stakeholders. Os métodos aplicados nesta etapa são ao nível técnico e direcionados à implementação das interfaces de utilizador, à criação de uma base de dados e à integração das mesmas com o algoritmo de otimização anteriormente desenvolvido.. 3.4.1. Ciclo de Vida do Desenvolvimento. O modelo que será usado durante o desenvolvimento deste projecto é baseado em SCRUM. Este modelo difere do SCRUM tradicional em alguns aspectos, nomeadamente no backlog, em que será apenas a lista dos casos de uso e não user stories. As daily scrum meetings também serão suprimidas pois a equipa de desenvolvimento apenas tem um elemento. Os sprints serão de duas semanas, e o planeamento do sprint acontecerá no último dia da sprint anterior.. Figura 3.3: Ciclo de Desenvolvimento. 2A. primeira ferramenta de design de interface colaborativa do mundo. O Figma permite que os designers criem e prototipem suas experiências digitais - juntos em tempo real e em um único lugar - ajudando-os a transformar suas ideias e visões em produtos, mais rapidamente. A missão da Figma é tornar o design acessível a todos. A API do Figma é uma das maneiras que pretendemos fazer isso.[1].

(36) 16. Metodologia. 3.5. Análise da implementação. Na última etapa está descrita a análise de tudo o que foi implementado no desenvolvimento deste software. Nesta etapa é realizada e expressa uma reflexão acerca de todos os processos realizados com o intuito de obter a solução desejada, expondo as dificuldades encontradas nos mesmos. É também aferido se foram cumpridos os requisitos propostos e todas as oportunidades de melhoria que possam ser consideradas na realização de um trabalho futuro, isto é, num possível trabalho de evolução do sistema já implementado..

(37) Capítulo 4. Análise de requisitos do forSCOPE 4.1 4.1.1. Introdução Âmbito. O produto desenvolvido é o desenho gráfico do forSCOPE e o seu principal objectivo é aumentar o uso e valorização da biomassa florestal, reduzindo o risco de incêndio florestal, diminuindo os custos logísticos com modelos de otimização integrados. Desenvolvido para os produtores, consumidores de biomassa e para o planeador que fará a gestão dos planos criados pelo forSCOPE.. 4.2. Práticas consideradas. Nas seguintes secções deste capítulo são consideradas as boas práticas do processo de engenharia de requisitos e a linguagem de modelação unificada (UML) tendo sido complementadas com algumas adaptações à realidade do projecto.. 4.3 4.3.1. Descrição geral Perspectiva. Este produto foi projetado para ajudar a aumentar o uso e valorização da biomassa florestal, reduzindo o risco de incêndio florestal, diminuindo os custos logísticos com modelos de otimização integrados.. 4.3.2. Funcionalidades. Esta aplicação visa alcançar as seguintes funcionalidades: • Autenticar do utilizador • Registar oferta de pilhas com as suas características 17.

(38) 18. Análise de requisitos do forSCOPE. • Registar centros de consumo e pedidos de Consumo com caraterísticas associadas • Registar Recursos logísticos de processamento e transporte • Criar, analisar e alterar planos.. 4.3.3. Características do utilizador. O utilizadores deste sistema pertencem a um espectro muito alargado, em termos de idade, tendo em conta a idade ativa, e podem ou não ter contacto frequente com sistemas informáticos. Existem quatro tipos de utilizador, o produtor de biomassa, o consumidor de biomassa, o fornecedor de serviços e o planeador. Estes utilizadores podem ter backgrounds bastante distintos mas o forSCOPE foi desenhado a pensar neles e nos seus conhecimentos e capacidades.. 4.4 4.4.1. Requisitos de interface externa Interfaces dos utilizadores. A interface dos utilizadores permitirá todo o planeamento, controlo e monitorização de tarefas associadas à produção, ao transporte e ao consumo de biomassa.. 4.4.2. Interfaces de Hardware. Este software irá interagir com um navegador da Web por isso os utilizadores precisam de ter uma máquina para entrar na plataforma web.. 4.4.3. Interfaces de Software. O aplicativo da Web deve ser executado em qualquer navegador principal, permitindo aos utilizadores um acesso rápido e fácil aos planos e a todo o processo de criação dos mesmos.. 4.4.4. Interfaces Comunicações. O sistema deve ser capaz de se comunicar com um base de dados central, permitindo que o aplicativo da Web adicione, altere e / ou simplesmente visualize os dados existentes. O aplicativo da Web exige uma conexão de Internet em tempo integral para garantir que todas as alterações na base de dados sejam armazenadas com êxito.. 4.5 4.5.1. Funcionalidades do Sistema Casos de Uso. Esta visão descreve a funcionalidade do sistema da perspectiva do mundo exterior. Contém diagramas que descrevem o que o sistema deve fazer a partir de uma perspectiva de caixa preta..

(39) 4.5 Funcionalidades do Sistema. 19. Essa visão normalmente contém diagramas de casos de uso. Todas as outras visualizações usam essa exibição para guiá-las. Use Case Diagram: Captura do aspecto dinâmico de um sistema reunindo os requisitos de um sistema, incluindo influências internas e externas..

(40) 20. Análise de requisitos do forSCOPE. Figura 4.1: Planeamento Logístico da Biomassa.

(41) 4.5 Funcionalidades do Sistema. Figura 4.2: UC1.1 Registar pilha de biomassa. 21.

(42) 22. Análise de requisitos do forSCOPE. Figura 4.3: UC1.2 Registar pedido de Biomassa.

(43) 4.5 Funcionalidades do Sistema. 23. Figura 4.4: UC1.3 Registar parques intermédios e UC1.4 Registar equipamento/colaboradores/veículo.

(44) 24. Análise de requisitos do forSCOPE. Figura 4.5: UC2.1 Criar plano e UC2.2 Analisar cenário e plano.

(45) 4.5 Funcionalidades do Sistema. Figura 4.6: UC3 Validar o plano reunindo comentários de outros utilizadores. 25.

(46) 26. Análise de requisitos do forSCOPE. Figura 4.7: Monitorização e controlo dos processos logísticos da biomassa.

(47) 4.5 Funcionalidades do Sistema. 4.5.2. Registo e Autenticação. 4.5.2.1. Descrição e prioridade. 27. O registo e autenticação do utilizador são metodologias que serão usadas para identificar um utilizador no sistema e quais informações sobre ele estão armazenadas na base de dados. Esta especificação descreve o processo de registo e autenticação de um utilizador, o processo de criação username e password para identificar o utilizador. Este recurso é de alta prioridade pois sem registo e login não existe acesso ao sistema. Tabela 4.1: Requisitos Funcionais - Registo e Autenticação Requisitos. ID caso de uso. RF01: O utilizador deverá ser capaz criar uma conta não sendo obrigatória a sua associação a uma empresa. RF02: O utilizador deverá ser capaz de iniciar sessão com uma conta previamente registada RF14: O utilizador, autenticado como administrador deverá ser capaz de gerir todos os utilizadores registados.. 4.5.3 4.5.3.1. Estímulo. Resposta. O utilizador clica em registar e preenche todos os campos.. O sistema guarda a informação do utilizador.. O utilizador insere o seu username e password para fazer login. O utilizador registado como administrador, Clica em “Gerir Utilizadores.. O sistema carrega todo o conteúdo a que o utilizador tem acesso. O sistema carrega todo o conteúdo relativo aos utilizadores registados.. Logout Descrição e prioridade. Consiste em desconectar a conta no servidor, a fim de evitar a partilha de informações pessoais possibilitando a troca de conta de utilizador no mesmo dispositivo. Este recurso tem prioridade média. Tabela 4.2: Requisitos Funcionais - Logout Requisitos RF03: O utilizador deverá estar com a sessão iniciada. RF04: O item Logout deverá estar acessível.. ID caso de uso. Estímulo. Resposta. O utilizador clica logout.. O sistema deverá mostrar uma mensagem de sucesso..

(48) 28. Análise de requisitos do forSCOPE. 4.5.4. Acesso ao perfil. 4.5.4.1. Descrição e prioridade. O utilizador deverá poder consultar as informações da sua conta. Este recurso tem prioridade média. Tabela 4.3: Requisitos Funcionais - Acesso ao perfil Requisitos RF03: O utilizador deverá estar com a sessão iniciada.. ID caso de uso. Estímulo. Resposta. O utilizador clica no seu username no canto superior direito.. O sistema deverá mostrar todas as suas informações bem como a possibilidade de alteração.. RF06: O sistema deverá mostrar o perfil após clique no item “username” com sessão iniciada. RF07: O sistema deverá permitir a alteração/recuperação da password.. 4.5.5. Inputs de necessidades e disponibilidades. 4.5.5.1. Descrição e prioridade. A unidade onde serão introduzidas com as devidas parametrizações da criação de tipos de biomassa, da criação de ofertas de pilhas de biomassa, da criação de pedidos, da criação de equipamento e de parques intermédios essenciais ao bom funcionamento do sistema. Este recurso tem prioridade alta..

(49) 4.5 Funcionalidades do Sistema. 29. Tabela 4.4: Requisitos Funcionais - Inputs de necessidades e disponibilidades Requisitos. ID caso. Estímulo. Resposta. Após o login na aplica-. O sistema deverá apre-. gistados como administradores. ção, se registado como. sentar um formulário. poderão ter acesso ao formulá-. administrador,. para. com os parâmetros ne-. rio de criação de tipos de bio-. criar tipos de biomassa. cessários para a cria-. massa.. o. deverá. ção do tipo de biomassa. clicar em “Adicionar. e após a submissão do. Tipos de Biomassa”.. mesmo deverá ser guar-. de uso RF08: Apenas utilizadores re-. U.C.1.1.1. utilizador. dada na base de dados. RF09: Apenas utilizadores re-. U.C. 1.1. Após o login na aplica-. O sistema deverá apre-. gistados como produtores de bi-. ção, se registado como. sentar um formulário. omassa poderão ter acesso ao. produtor de biomassa,. com os parâmetros ne-. formulário de registo/disponibi-. para criar uma oferta de. cessários (localizar a. lização da pilha de biomassa.. pilha o utilizador deverá. fonte (coordenadas ge-. clicar em CRIAR PI-. ográficas e a morada),. LHA.. classificar o tipo de biomassa, estimar a disponibilidade da biomassa para um determinado plano ou período de tempo, estimar a humidade, selecionar uma data para levantamento da biomassa e + informação) para criação da pilha e após a submissão do mesmo deverá ser guardado na base de dados.. RF15: O sistema deverá permi-. U.C. 1.1. Após o login na aplica-. O sistema deverá apre-. tir a introdução de localizações,. ção, se registado como. sentar um formulário. pelas coordenadas geográficas e. consumidor, para criar. com os parâmetros ne-. ou pela morada.. pedido de biomassa o. cessários para a criação. utilizador deverá clicar. do pedido de biomassa. em “Criar Pedido”.. e após a submissão do mesmo deverá ser guardada na base de dados..

(50) 30. Análise de requisitos do forSCOPE. Tabela 4.5: Requisitos Funcionais - Inputs de necessidades e disponibilidades continuação Requisitos. ID caso. Estímulo. Resposta. Após o login na aplica-. O sistema deverá apre-. tir a seleção do tipo de biomassa. ção, se registado como. sentar um formulário. através da seleção de caracterís-. planeador,. com os parâmetros ne-. ticas da biomassa.. veículos/equipamen-. cessários para a criação. to/equipas o utilizador. de veículos/equipamen-. deverá. “. to/equipas e após a sub-. Criar Veículos / Criar. missão do mesmo de-. Equipamentos / Criara. verá ser guardada na. Equipas ”.. base de dados.. Após o login na apli-. O sistema deverá apre-. mitir a inserção do volume da. cação,. registado. sentar um formulário. biomassa, a sua disponibilidade. como planeador, para. com os parâmetros ne-. num intervalo de tempo, a es-. criar. in-. cessários para a criação. timativa de humidade, a sua. termédios o utilizador. de stockyards intermé-. “idade” e a sua data de preferên-. deverá clicar em “ Criar. dios e após a submis-. cia para levantamento.. Stockyards Intermédios. são do mesmo deverá. ”.. ser guardada na base de. de uso RF16: O sistema deverá permi-. RF17: O sistema deverá per-. U.C.1.1. U.C.1.1. para criar. clicar. se. em. stockyards. dados. RF33: O sistema deverá permi-. U.C.1.1. tir o acréscimo na quantidade de biomassa, tendo de adicionar uma data preferencial para esse acréscimo. RF34:O sistema deverá permi-. U.C.1.1. tir a eliminação de uma pilha, sendo apenas possível se a pilha não estiver incluída num plano. RF10: Apenas utilizadores re-. U.C.1.2. gistados como consumidores poderão ter acesso ao formulário de pedido de biomassa. RF18: O sistema deverá permitir a inserção de volumes exigidos por período, este período não deverá exceder os dois dias consecutivos .. U.C.1.2.

(51) 4.5 Funcionalidades do Sistema. 31. Tabela 4.6: Requisitos Funcionais - Inputs de necessidades e disponibilidades continuação Requisitos. ID caso de uso. RF19: O sistema deverá permi-. U.C.1.2. tir a especificação do preço segundo as características da biomassa. RF11: Apenas utilizadores re-. U.C.1.4. gistados como Fornecedor de serviços poderão ter acesso aos formulários de criação de veículos/equipamento/equipas. RF20: O sistema deverá permi-. U.C.1.4. tir a inserção de componentes de custo (tais como custo da distância e custo do tempo despendido), registar a produtividade e a sua disponibilidade para um dado período. RF05: O sistema deverá permi-. U.C.1.4. tir adicionar uma identificação, por exemplo um nome. RF12: Apenas utilizadores re-. U.C.1.3. gistados como administradores poderão ter acesso aos formulários de criação de parques de Biomassa intermédios. RF21: O sistema deverá permitir a inserção da capacidade armazenamento e taxa de secagem estimada. RF13:O sistemas após a submissão de qualquer formulário deverá mostrar uma mensagem de sucesso e guardar todos os dados do formulário na base de dados.. U.C.1.3. Estímulo. Resposta.

(52) 32. Análise de requisitos do forSCOPE. 4.5.6 4.5.6.1. Criação de planos Descrição e prioridade. A unidade onde serão criados os planos pelos planeador, analisados, comentados e validados pelos outros utilizadores incluídos no plano. Este recurso tem prioridade alta. Tabela 4.7: Requisitos Funcionais - Criação de planos Requisitos RF22: O sistema deverá permitir a parametrização do modelo de optimização tática.. RF23: O sistema deverá permitir a compilação das pilhas disponíveis e dos pedidos de biomassa para o período a planear.. ID caso de uso U.C.2.1. U.C.2.1. Estímulo. Resposta. O planeador para criar um plano, terá de criar um cenário para o plano, parametrizando o modelo de optimização tático, compilando todas as entradas no sistema dos produtores e consumidores de biomassa para o período estipulado e enviar para fila de execução. O planeador com os cenários criados poderá ler e analisar as informações obtidas tendo a possibilidade de selecionar o cenário que irá ser o plano.. O sistema deverá mostrar o formulário de parametrização do modelo de optimização tática, enviar para a fila de execução e o mostrar seu resultado.. O sistema deverá permitir a leitura do programa de operações num gantt, dos equipamento/veículos envolvidos nos cenários num mapa, outras informações e análises e também a possibilidade de exportar o cenário otimizado ou plano..

(53) 4.5 Funcionalidades do Sistema. 33. Tabela 4.8: Requisitos Funcionais - Criação de planos continuação Requisitos. ID caso. Estímulo. Resposta. após a seleção do cená-. O sistema deverá enviar. RF23 deverá permitir o seu en-. rio todos os utilizado-. todas as informações do. vio para a fila de execução.. res envolvidos deverão. cenário escolhido para. receber as informações. os utilizadores envolvi-. do mesmo e validar com. dos. Recolhendo uma. opção de comentar.. validação dos mesmo. de uso RF24: O sistema após mostrar o. U.C.2.1. com opção de comentário, enviando essa informação ao planeador para ajustes ou ativar o plano. RF25: O sistema deverá permi-. U.C.2.2. tir fazer uma cópia do cenário criado ou mesmo do plano selecionado. RF26: O sistema deverá mos-. U.C.2.2. trar um gantt com as operações de cada cenário, com as movimentações previstas num mapa. RF27: O sistema deverá enviar. U.C.3. as informações ao utilizadores envolvidos no cenário selecionado. RF28: O sistema deverá permitir a validação ou não do plano, com a opção de comentários por parte dos utilizadores envolvidos. RF29: O sistema deverá permi-. U.C.3. tir o planeador ativar o plano após as validações dos utilizadores envolvidos, enviado essa informação ao mesmos. RF30: O sistema deverá permi-. U.C.3. tir a seleção do cenário que se tornará o plano. RF31: O sistema deverá permitir ver o status dos cenários na fila de execução.. U.C.3.

(54) 34. Análise de requisitos do forSCOPE. 4.5.7. Matriz de Rastreabilidade de Requisitos. Esta matriz relaciona os requisitos funcionais descritos nas tabelas anteriores e os Mockups no Anexo A.. Tabela 4.9: Matriz de rastreabilidade de Requisitos ID Requisitos. ID Mockups. Grau de Implementação (0 a 100). RF01. 1.1. 100. 1.2 RF02. 1.1. 100. RF03. 2.1. 100. 3.1 4.1 5.1 6.1 RF04. 2.1. 100. 3.1 4.1 5.1 6.1 RF05. 4.2. 100. 4.3 4.4 RF06. 2.1. 50. 3.1 4.1 5.1 6.1 RF07. 1.3. 0. RF08. 6.3. 100. RF09. 2.2. 100. RF10. 3.4. 00. RF11. 4.2. 100. 4.3 4.4. Observações.

(55) 4.5 Funcionalidades do Sistema. 35. Tabela 4.10: Matriz de rastreabilidade de requisitos continuação ID Requisitos. ID Mockups. Grau de Implementação. RF12. 6.4. 100. RF13. 100. Observações A mensagem é mostrada em pop-up, não aparece no mockup. RF14. 6.2. 0. RF15. 2.2. 100. 3.4 6.4 RF16. 2.2. 100. 3.4 6.4 RF17. 2.2. 100. RF18. 3.4. 80. RF19. 3.2. 100. RF20. 4.2. 100. 4.3 4.4 RF21. 6.4. 100. RF22. 5.2. 100. RF23. 5.2. 100. RF24. 5.2. 50. RF25 RF26. 0 2.6. Em falta, adicionar botão. 50. 3.8 4.7 5.3 RF27. 5.3. 100. RF28. 2.6. 100. 3.8 4.7 RF29. 5.3. 50. RF30. 5.3. 0. RF31. 0. Em falta a visualização do status.

(56) 36. Análise de requisitos do forSCOPE. 4.6. Storyboards. Todos o trabalho de prototipagem foi realizado na ferramenta Figma, que permitiu começar pela elaboração do desenho simples da interface alterando e adicionando funcionalidades aos mockups, resultando assim nos storyboards a seguir apresentados..

(57) 4.6 Storyboards. 37. Figura 4.8: Storyboard Login.

(58) 38. Análise de requisitos do forSCOPE. Figura 4.9: Storyboard Registo de pilhas e entrada em planos visível no mapa e no gantt - Produtor.

(59) 4.6 Storyboards. Figura 4.10: Storyboard Registo de equipas e entrada em plano - Fornecedor de serviços. 39.

(60) 40. Análise de requisitos do forSCOPE. Figura 4.11: Storyboard Criação de cenários e planos - Planeador.

(61) 4.6 Storyboards. Figura 4.12: Storyboard Administração do sistema - Administrador. 41.

(62) 42. Análise de requisitos do forSCOPE.

(63) Capítulo 5. Implementação 5.1. Ferramentas utilizadas. A arquitetura tecnológica específica os principais requisitos tecnológicos e práticas adotadas no desenvolvimento do software que suporta o planeamento logístico das operações que envolvem a biomassa florestal de forma eficiente e eficaz. As GUI foram desenvolvidas através de tecnologias computacionais constituintes de algoritmos elaborados com base numa combinação de três linguagens: • HTML - Hyper Text Markup Language; • CSS - Cascading Style Sheets; • JavaScript. A estruturação da página, o seu aspeto e apresentação foi realizado com base numa framework designada por BootStrap. Esta framework é open-source e sustentada por HTML e CSS que facilita o design das interfaces para que sejam caraterizadas pelo seu modo de atuar responsivo, pela interatividade e pela sua aparência agradável [3]. Definida a estrutura e o estilo das interfaces, o conteúdo das mesmas é estabelecido através da linguagem HTML. A utilização de JavaScript no seu desenvolvimento proporciona funcionalidades que permitem melhorar e adicionar características dinâmicas e interativas das interfaces. As interfaces têm três pontos de interatividade, os formulários que permitem registar na base de dados, o mapa que permite abrir os formulários de registo, visualizar e alterar as pilhas/pedidos/equipas com a sua localização e até mesmo a sua ligação a uma plano, e o Gantt que permite visualizar e alterar as pilhas/pedidos/equipas já com planos associados e as suas tarefas com a devida descrição. O Gantt foi implementado com a biblioteca Highcharts que é desenvolvida em JavaScript permitindo a sua interatividade. Highcharts é uma biblioteca de gráficos multi-plataforma. Baseada em SVG e começou a ser desenvolvida em 2009. Como é responsiva, funciona bem tanto em uma visão web quanto numa visão mobile. Além disso, é altamente customizável e extremamente rápida na implementação e na sua renderização. Um detalhe: para fins comerciais, Highcharts necessita de uma licença, enquanto, para uso pessoal, essa licença não se faz necessária.[5] 43.

(64) 44. Implementação. A API do Leaflet, permite a comunicação com serviços com o intuito de apresentar o mapa no browser através de AJAX. As funções que permitem uma utilização funcional do mapa e retirar os dados a partir dessa foram desenvolvidas em JavaScript, utilizando a documentação disponibilizada para esse propósito. Com a combinação de todas as tecnologias descritas, são desenvolvidas as interfaces que permitem a utilização do mapa como suporte às funções a realizar em cada caso. Ao nível da base de dados, a opção para a sua implementação passou pela adoção do modelo relacional no arquivo dos dados associados. Deste modo, o repositório dos mesmos é efetuado em tabelas e através de comandos definidos em SQL. A implementação foi feita num servidor local com recurso ao software livre designado por Ampps. Um servidor web de nome Apache integra esta ferramenta que acrescenta MySQL, PHP entre outras tecnologias, permitindo a concretização de certas ações implementadas e a implementar no sistema.. 5.2. Âmbito. Esta secção compreende o que foi implementado, isto é, o projeto inicial tinha um âmbito muito alargado. Após a definição da arquitectura do sistema de apoio à decisão, foram definidos os seus casos de uso. Com a delimitação dos requisitos e a produção dos mockups o âmbito foi um pouco restringido, deixando de fora a parte da monitorização e controlo. Na implementação o foco foi menos para os requisitos relacionados com a implementação do Gantt e das dashboards e mais para os requisitos respeitantes à ligação e criação da base de dados, à ligação ao otimizador e às interações no mapa.. 5.3. Estrutura de dados. O Modelo Entidade Relacionamento, como o nome sugere, é um modelo conceitual utilizado na Engenharia de Software para descrever os objetos (entidades) envolvidos com suas características (atributos) e como elas se relacionam entre si (relacionamentos). O modelo apresentado a seguir foi desenvolvido cumprindo as regras aplicadas aos diagramas de classes, encontrando-se em conformidade com a linguagem de modelação visual standard, designada por UML..

(65) 5.3 Estrutura de dados. Figura 5.1: Modelo entidade Relacionamento - forSCOPE. 45.

(66) 46. Implementação. 5.4. Interfaces gráficas. Para os utilizadores usufruírem do sistema de apoio à decisão necessitam de efectuar login por consequência requer um registo na aplicação. A figura 5.2 e a figura 5.3 são prints da interface do forSCOPE onde é permitido efetivar o registo e o devido login. O utilizador terá de preencher os campos Nome, nome de utilizador, número de identificação fiscal, email, uma password, a confirmação da password, e o tipo de utilizador, opcionalmente poderá identificar a empresa a que pertence.. Figura 5.2: Registo no software.

(67) 5.4 Interfaces gráficas. 47. Para efetuar Login basta apenas inserir o nome de utilizador e a palavra passe. Efectuado o Login o utilizador terá acesso à sua home, que se apresentará diferente para cada tipo de utilizador.. Figura 5.3: Login no software.