Pervasive Modular Data Science - otimização e interoperabilidade

Universidade do Minho Escola de Engenharia Beatriz José Cunha Rodrigues Pervasive Modular Data Science – Otimização e interoperabilidade Outubro de 2023 Pervasive Modular Data Science – Otimização e interoperabilidade Beatriz José Cunha Rodrigues UMinho | 2023 Beatriz José Cunha Rodrigues Pervasive Modular Data Science – Otimização e interoperabilidade Outubro de 2023 Relatório de Dissertação de Mestrado Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação do/da/de Professor Carlos Filipe da Silva Portela i DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição-NãoComercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ ii AGRADECIMENTOS Com o encerramento de uma das fases mais marcantes da minha vida, gostaria de expressar a minha gratidão a todos que, de alguma forma, me incentivaram e ajudaram a tornar isso possível. Primeiramente, quero agradecer ao meu orientador, o Professor Carlos Filipe da Silva Portela, que me apoiou durante toda a elaboração desta tese e sempre esteve disponível para esclarecimentos. Quero também agradecer a toda a equipe da IOTech pelo tempo e conhecimento compartilhados, o que tornou a elaboração desta tese possível. Um agradecimento especial ao Daniel Carneiro, que sempre se mostrou disponível para me ajudar em qualquer dificuldade que surgiu ao longo do projeto. Aos meus colegas e amigos que, ao longo da minha jornada académica, não só me ajudaram na realização de trabalhos, mas também encheram essa jornada de diversão e alegria. Gostaria de fazer um agradecimento especial à Ana Carolina Pereira, cujas piadas secas ao longo de 18 anos de amizade sempre conseguem me surpreender, e à Daniela Ferreira, agradeço por estar sempre ao meu lado e pelos conselhos valiosos. Um grande agradecimento para toda a minha família, em especial aos meus pais e ao meu irmão, que sempre me incentivaram e proporcionaram todas as oportunidades que me permitiram atingir todos os meus objetivos académicos. Por fim, quero agradecer à Universidade do Minho, mais especificamente ao Departamento de Sistemas de Informação, e a todos os seus membros que, de alguma forma, contribuíram para a minha formação e para as minhas conquistas académicas. iii DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio, nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. iv RESUMO Pervasive Modular Data Science – Otimização e interoperabilidade Num contexto de avanços tecnológicos, a criação constante de conjuntos de dados tornou-se uma realidade marcante na sociedade atual. Neste cenário, a IOTech concebeu o ioScience com o objetivo de superar as dificuldades inerentes à análise em tempo real, proporcionando soluções eficazes para o tratamento de conjuntos de dados complexos e variados. Assim, procurando otimizar esta plataforma no âmbito do projeto ioCity, a IOTech precisa que ela seja melhorada ao nível dos módulos de interoperabilidade, visualização e previsão. Durante este projeto, foram aplicadas diferentes metodologias: Design Science Research, no que diz respeito à investigação, e a framework SCRUM e o CRISP-DM, no que diz respeito ao desenvolvimento da componente prática. Na primeira fase desta dissertação, foram adquiridos os conceitos necessários para o seu desenvolvimento, como, por exemplo, Data Science e Data Mining, juntamente com uma compreensão da patente ioScience. Após a fase inicial, foi iniciada a componente prática desta dissertação, na qual foi possível responder positivamente à questão de pesquisa "Qual a viabilidade de integrar um módulo preditivo no ioScience, seguindo as regras de construção deste?" com a implementação do módulo preditivo no ioScience, segundo as regras do mesmo, e a subsequente alteração na arquitetura da solução. Além disso, os demais objetivos do trabalho foram alcançados com a obtenção dos seguintes resultados: Implementação do Módulo Preditivo no ioScience; Alteração na arquitetura da solução; Otimização e implementação de componentes visuais no ioScience; Otimização e implementação de funcionalidades no ioScience; Reorganização no código; Teste utilizando dados o projeto do ioCity; Elaboração de 24 modelos de previsão; e Criação da API de previsão em Python. De forma geral, podese afirmar que este trabalho resultou na apresentação de um protótipo aprimorado da plataforma. Para este caso de estudo e como prova de conceito, a empresa IOTech foi utilizada, uma vez que esta foi responsável por fornecer os dados necessários para apoiar esta dissertação. Palavras-chave: análises em tempo-real; Data Science ; módulo preditivo; otimização. v ABSTRACT Pervasive Modular Data Science - Optimisation and interoperability In a context of technological advances, the constant creation of data sets has become a marked reality in today's society. In this scenario, IOTech designed ioScience with the aim of overcoming the difficulties inherent in real-time analysis, providing effective solutions for handling complex and varied data sets. In order to optimize this platform as part of the ioCity project, IOTech needs to improve its interoperability, visualization and forecasting modules. During this project, different methodologies were applied: Design Science Research for the research, and the SCRUM framework and CRISP-DM for the development of the practical component. In the first phase of this dissertation, the concepts necessary for its development were acquired, such as Data Science and Data Mining, along with an understanding of the ioScience patent. After the initial phase, the practical component of this dissertation began, in which it was possible to positively answer the research question "What is the viability of integrating a predictive module into ioScience, following its construction rules?" with the implementation of the predictive module in ioScience, according to its rules, and the subsequent change in the solution's architecture. In addition, the other objectives of the work were achieved with the following results: Implementation of the Predictive Module in ioScience; Change in the solution's architecture; Optimization and implementation of visual components in ioScience; Optimization and implementation of functionalities in ioScience; Reorganization of the code; Testing using data from the ioCity project; Development of 24 prediction models; and Creation of the prediction API in Python. In general, it can be stated that this work resulted in the presentation of an enhanced prototype of the platform. For this case study and as a proof of concept, the company IOTech was utilized since it was responsible for providing the necessary data to support this dissertation. Keywords: real-time analytics; Data Science ; predictive module; optimization. vi ÍNDICE 1. Introdução .................................................................................................................................. 1 1.1 Enquadramento e Motivação ................................................................................................ 1 1.2 Objetivos ............................................................................................................................. 2 1.3 Estrutura do Documento ...................................................................................................... 3 2. Revisão de Literatura .................................................................................................................. 5 2.1 Introdução ........................................................................................................................... 5 2.2 ioScience ............................................................................................................................. 6 2.2.1 Fonte de Dados.................................................................................................... 6 2.2.2 API (Interface de Programação de Aplicações) ...................................................... 7 2.2.3 Armazém de dados .............................................................................................. 7 2.2.4 OLAP ................................................................................................................... 7 2.2.5 Camada memória “Cache” .................................................................................. 7 2.2.6 Camada de Visualização ...................................................................................... 8 2.3 Data Science ....................................................................................................................... 8 2.3.1 Contexto do surgimento de Data Science .............................................................. 8 2.3.2 Modelo do processo de Data Science ................................................................... 9 2.3.3 Pervasive Data Science ...................................................................................... 13 2.3.4 Relação com o ioScience.................................................................................... 15 2.4 Big Data ............................................................................................................................ 15 2.4.1 Características de Big Data ................................................................................ 16 2.4.2 Tipos de Big Data ............................................................................................... 17 2.4.3 Relação com o ioScience.................................................................................... 18 2.5 Análise de Dados ............................................................................................................... 18 2.5.1 Relação com o ioScience.................................................................................... 19 xiii LISTA DE TABELAS Tabela 1 - Exemplos de desafios emergentes em ciência de dados omnipresente. ............................. 14 Tabela 2 - Operações OLAP .............................................................................................................. 23 Tabela 3 - Patentes semelhantes ao ioScience. ................................................................................. 26 Tabela 4 - Product Backlog ............................................................................................................... 33 Tabela 5 - Sprint Backlog .................................................................................................................. 34 Tabela 6 - Tecnologias/Ferramentas utilizadas nesta dissertação ...................................................... 36 Tabela 7 - Otimização visual da plataforma. ...................................................................................... 42 Tabela 8 - Estados das funcionalidades da plataforma antes e depois. ............................................... 48 Tabela 9 - Reorganização no código. ................................................................................................. 59 Tabela 10 - Métricas de modelos de classificação em Data Mining . ................................................... 61 Tabela 11 - Métricas de modelos de regressão em Data Mining . ........................................................ 62 Tabela 12 - Análise dos dados Vila Nova de Famalicão. ..................................................................... 64 Tabela 13 - Análise dos dados Lisboa. .............................................................................................. 65 Tabela 14 - Análise estatística dos dados Lisboa. .............................................................................. 65 Tabela 15 - Análise das variáveis numéricas Lisboa. .......................................................................... 66 Tabela 16 - Análise dos dados geográficos. ....................................................................................... 67 Tabela 17 - Análise dos dados meteorológicos. ................................................................................. 68 Tabela 18 - Nome final das variáveis. ................................................................................................ 71 Tabela 19 - Cenários de teste. .......................................................................................................... 73 Tabela 20 - Algoritmos de Classificação. ........................................................................................... 74 Tabela 21 - Algoritmos de Regressão. ............................................................................................... 76 Tabela 22 - Resultados de classificação do cenário A. ....................................................................... 77 Tabela 23 - Resultados de classificação do cenário B. ....................................................................... 77 Tabela 24 - Resultados de classificação do cenário C. ....................................................................... 78 Tabela 25 - Resultados de classificação do cenário D. ....................................................................... 78 Tabela 26 - Comparação de resultados entre cenários dos Modelos de Classificação. ........................ 78 Tabela 27 - Resultados de regressão do cenário A. ............................................................................ 79 Tabela 28 - Resultados de regressão do cenário B. ........................................................................... 79 Tabela 29 - Resultados de regressão do cenário C. ........................................................................... 80 xiv Tabela 30 - Resultados de regressão do cenário D. ........................................................................... 80 Tabela 31 - Comparação de resultados entre cenários dos Modelos de Regressão. ............................ 80 Tabela 32 - Objetivos VS Resultados Finais........................................................................................ 88 Tabela 33 - Lista de Riscos. .............................................................................................................. 89 1 1. INTRODUÇÃO Neste primeiro capítulo é apresentado o enquadramento do projeto de dissertação, bem como, uma breve exposição da motivação para a realização do mesmo. Além disto, são apresentados os objetivos e os resultados esperados, de forma a ser possível no final do mesmo responder à questão de investigação identificada. Por último, é apresentada a estruturação deste documento. 1.1 Enquadramento e Motivação Este projeto de dissertação leva em consideração o aumento considerável na formação de conjunto de dados, devido essencialmente aos diversos avanços tecnológicos na atualidade. Isto pode ser verificado quando é observado o ambiente à nossa volta, onde é possível identificar diversos dispositivos que realizam a recolha destes dados constantemente, sendo exemplos destes, smartphones, sites da internet e leitores automáticos de matrículas. Com isto em mente, o apoio à decisão em tempo-real com base em dados gerados no momento é visto pelas organizações, cada vez mais, como um fator decisivo para o sucesso na tomada de uma decisão. No entanto, as organizações têm dificuldades em fazer uma análise desses dados em tempo-real, devido à complexidade, quantidade e diversidade dos mesmos. Tendo por base este conceito, a IOTech desenvolveu o ioScience (Filipe Portela & Gisela Fernandes, 2022) e precisa que o mesmo seja otimizado, incluindo os resultados originais e outros desenvolvidos no âmbito do projeto ioCity, melhorando os módulos de interoperabilidade, visualização e previsão. Em relação a estes módulos, é importante clarificar o seguinte: − O módulo da interoperabilidade refere-se à solidificação da característica interoperabilidade dos dados, isto é, a implementação e integração de diferentes conjuntos de dados na plataforma do ioScience como forma de teste da mesma; − O módulo de visualização refere-se a otimizações visuais e funcionais de forma a tornar a utilização da plataforma pela parte do utilizador mais intuitiva, apelativa e eficiente; − O módulo de previsão refere-se à criação e implementação deste módulo na plataforma. No que diz respeito à IOTech, esta trata-se de uma start-up /empresa portuguesa de investigação e desenvolvimento (I&D), esta insere-se em várias áreas como Data Science , Inteligência Artificial, Internet 2 das Coisas ( Internet of Things - IoT ) - comunicação de sistemas, integração, interoperabilidade e desenvolvimento web - e gamificação. O ioScience resulta de uma patente da IOTech de “um modelo e arquitetura sistémica orientado para os dados, materializado por uma aplicação que inclui receber dados a partir de fontes estruturadas e/ou não estruturadas, processá-los, e apresentar os resultados analíticos ao utilizador final. Refere-se especificamente a um sistema que possibilita a realização de uma análise de dados em modo não conectado (do inglês offline) com a possibilidade de conexão a um módulo de Inteligência Artificial e respetivo método.” (Filipe Portela & Gisela Fernandes, 2022). Sendo a patente do ioScience a base para este projeto de dissertação, todo o desenvolvimento deste, desde a seleção das tecnologias, vai ao encontro com o que é identificado na patente. A motivação para este projeto de dissertação baseia-se no interesse desenvolvido na área de Data Science ao longo do percurso académico e na oportunidade de aumentar conhecimentos tanto na parte analítica, como preditiva desta área. Por fim, é de acrescentar que os resultados deste projeto foram testados com dados reais provenientes da Indústria. 1.2 Objetivos Este projeto de dissertação tem como questão de investigação “Qual a viabilidade de integrar um módulo preditivo no ioScience, seguindo as regras de construção deste?” Os objetivos principais para este projeto inserem-se em: − O1 - Otimizar o protótipo de uma solução web; − O2 - Criar um modelo preditivo; Os objetivos estruturantes para este projeto dividem-se em: − O1.1 - Testar e documentar o protótipo; − O1.2 - Melhorar o processo de análise de dados em tempo-real; − O1.3 - Adaptar a solução para diferentes projetos; − O2.1 - Explorar algoritmos inteligentes; − O2.2 - Testar modelos preditivos; 3 − O2.3 - Implementar APIs em Python. Para alcançar esses objetivos, e responder à questão de investigação definida, foi utilizada a metodologia de investigação Design Science Research (DSR) . Esta metodologia permitiu desenhar toda a solução e desenvolver um artefacto para o problema identificado, que se divide em dois momentos. No primeiro momento, foi desenvolvido o relatório intermédio, no qual, com base na patente existente, realizou-se uma revisão da literatura sobre os conceitos fundamentais ( Data Science , Big Data , Análise de Dados, Data Mining, Business Intelligence ), bem como a análise da patente do ioScience. O objetivo deste momento foi compreender o estado atual da patente e da literatura disponível. No segundo momento, além da documentação do relatório final, o projeto entrou na vertente prática desta dissertação, onde se adotou a framework SCRUM para o desenvolvimento e otimização da solução e o CRISP-DM para o desenvolvimento dos modelos de previsão. 1.3 Estrutura do Documento Este documento está dividido nos seguintes capítulos: − Introdução: aqui é apresentado o enquadramento e motivação para o projeto de dissertação, bem como os objetivos e resultados esperados; − Revisão da Literatura: neste capítulo é apresentada a patente do ioScience, bem como o resultado da investigação dos temas relacionados e outras patentes semelhantes a esta. Este capítulo está dividido em seis secções principais: Introdução, ioScience, Data Science , Big Data , Data Analysis (Análise de Dados) e Patentes parecidas ao ioScience; − Abordagem Metodológica, Materiais e Métodos: apresentação das metodologias selecionadas para este projeto (CRISP-DM, SCRUM e DSR), bem como das ferramentas que foram utilizadas para o projeto; − Trabalho Realizado: Nesta seção, é apresentado o trabalho desenvolvido ao longo deste projeto, que engloba a atualização da arquitetura da solução, as otimizações da plataforma ioScience ao nível visual e funcional e a descrição de todo o processo de data mining . − Discussão de resultados: aqui é realizada uma apresentação de todo o projeto de dissertação, com a apresentação dos todos os resultados obtidos, bem como quais objetivos do projeto estes alcançaram. 4 − Conclusão: aqui é realizada uma análise global de todo o documento, apresentando as conclusões referentes tanto à questão de investigação e objetivos do trabalho, quanto aos resultados alcançados durante a elaboração do projeto. Além disso, são apresentadas a tabela de riscos do projeto e indicações de possíveis questões a serem abordadas em trabalhos futuros. − Referências: lista de referências bibliográficas utilizadas ao longo do presente documento. Para além dos capítulos apresentados existe ainda a secção de anexos, onde encontram-se informações que não podem ser colocadas no corpo do documento e que fornecem detalhes adicionais e relevantes sobre tópicos abordados no documento, podendo se apresentar sob a forma de gráficos, tabelas, organogramas, esquemas, etc. 5 2. REVISÃO DE LITERATURA Neste capítulo, são apresentados os diversos conceitos fundamentais para o desenvolvimento da dissertação, os quais contribuíram para uma melhor compreensão do trabalho. Também são abordados trabalhos relacionados ao tema atual, bem como uma exposição de estudos semelhantes. 2.1 Introdução A revisão de literatura decorreu entre novembro de 2022 e fevereiro de 2023. Inicialmente foram definidas algumas estratégias para minimizar o desperdício de trabalho e tempo, restringindo quais os documentos que podem ser realmente relevantes para este trabalho (existindo exceções ao longo do documento). As estratégias adotadas foram as seguintes: − Utilizar diferentes serviços de indexação, como por exemplo: Scopus, Web of Science, ScienceDirect, IEEE, ResearchGate, Google Scholar e Google Patents; − Os documentos selecionados devem ser apresentados em inglês ou português; − O ano de publicação dos documentos deve ser a partir de 2010, exceto em alguns casos de documentos relevantes na área de estudo; − Os documentos devem ser de um dos seguintes tipos: artigos de revistas, artigos, livros ou outras dissertações; − Quando selecionado um documento, deve ser lido em primeiro lugar o resumo e as conclusões para avaliar o conteúdo do mesmo. Os temas abordados neste capítulo foram selecionados tendo em conta a patente do ioScience, onde este projeto se baseia, bem como o que seria importante para o desenvolvimento do projeto. Posto isto os conceitos selecionados são: − Data Science; − Big Data; − Análise de Dados; − Data Mining; − Bussiness Intelligence . 6 2.2 ioScience A patente do ioScience descreve um modelo e arquitetura sistémica orientado para os dados, que se apresenta como Data Science as a Service (DsaaS), materializando-se numa aplicação web/mobile. Esta inclui a capacidades de “receber dados a partir de fontes estruturadas e/ou não estruturadas, processálos, e apresentar os resultados analíticos ao utilizador final.” (Filipe Portela & Gisela Fernandes, 2022). Um dos pontos diferenciais deste sistema é o facto de este possibilitar a análise de dados em modo offline (não conectado) com a possibilidade de ser conectado a um módulo de Inteligência Artificial. O facto desta solução promover o conceito DsaaS significa que esta se apresenta como um sistema global que pode ser enquadrado em qualquer contexto empresarial, sendo que esta está preparada para se ligar aos mais variados tipos de bases de dados e a tratar de questões de escalabilidade futuras. “Toda a solução é interoperável, modular, escalável, segura, multiplataforma, e permite ter uma experiência de Ciência de Dados em modo offline.” (Filipe Portela & Gisela Fernandes, 2022). Neste sistema é possível identificar seis camadas, sendo estas as seguintes (Filipe Portela & Gisela Fernandes, 2022): i. uma Base(s) de Dados como uma Fonte de Dados e que permite alimentar o sistema; ii. uma Interface de Programação de Aplicações (API) que processa os dados e permite obter informações; iii. um Armazém de Dados onde o modelo multidimensional preenchido é armazenado; iv. uma camada de processamento analítico online OLAP (do Inglês On-line Analytical Processing ) para consultar os dados e fornecer diferentes perspetivas sobre os mesmos; v. uma camada memória “Cache” que gere o armazenamento das consultas; e vi. uma camada de Visualização onde os dados ficam disponíveis para o utilizador final através de um conjunto de painéis de gestão (do inglês dashboards ) apresentados numa aplicação. Para uma compreensão mais detalhada das seis camadas, elas serão descritas mais minuciosamente nos pontos a seguir. 2.2.1 Fonte de Dados A camada "Fontes de Dados" representa a(s) base(s) de dados, bem como outras fontes selecionadas de ficheiros JSON, CSV, XML, ou outros sistemas como ERPs (Planeamento de Recursos Empresariais), 7 SCMs (Gestão da Cadeia de Suprimentos), e CRM (Gestão de Relacionamento com o Cliente), que fornecem dados a todo o sistema. De preferência, armazena o MongoDB e algumas fontes de dados complementares (Filipe Portela & Gisela Fernandes, 2022). 2.2.2 API (Interface de Programação de Aplicações) A camada de Interface de Programação com Transferência Representacional de Estado (do inglês "RESTful API") contém parte do trabalho essencial a esta inovação. Pois é aqui que é feito o processamento de dados, transformando os dados brutos armazenados nas fontes de dados anteriormente apresentadas em informação relevante para serem utilizados na camada OLAP (Filipe Portela & Gisela Fernandes, 2022). 2.2.3 Armazém de dados A camada "Armazém de Dados" surge no âmbito de tratar devidamente as questões de velocidade e armazenamento. Assim, esta camada consiste em obter o modelo multidimensional preenchido na fase final da fase API e transferi-lo para a base de dados do Armazém de Dados. Isto é feito até ao final do processo ETL (Extração, Transformação e Carregamento) utilizando cursores e conectores aplicados aos tipos de bases de dados utilizados para apoiar o Armazém de Dados (Filipe Portela & Gisela Fernandes, 2022). 2.2.4 OLAP Uma estrutura OLAP possui elementos adequados selecionados a partir de dimensões, indicadores, filtros e hierarquias. Para que isso aconteça, é definido um conjunto de cubos individuais, cada um selecionando dados de uma dimensão diferente, e depois é criado outro cubo individual, com base nas relações com os outros que apresentam os dados da tabela de factos. Preenchida uma estrutura OLAP, segue-se a fase de definir as suas funções (em inglês drill down, roll-up, slice e dice ), e assim por diante (Filipe Portela & Gisela Fernandes, 2022). 2.2.5 Camada memória “Cache” A camada memória "Cache" está relacionada com o suporte de um sistema de cache através de uma base de dados do browser, permitindo que as diferentes consultas solicitadas desde a camada "Visualização" até à camada "OLAP" sejam armazenadas, tornando possível manter os painéis da 8 aplicação preenchidos com as informações mais atualizadas, mesmo sem ligação à Internet (Filipe Portela & Gisela Fernandes, 2022). 2.2.6 Camada de Visualização A última fase do sistema envolve a perceção do utilizador sobre o valor do trabalho. Isto torna esta fase extremamente importante, uma vez que, se o valor da solução não for percebido, a solução é uma falha, independentemente do que exista além dela. Por outras palavras, o trabalho substancial realizado antes dos painéis de instrumentos/relatórios não tem valor para o utilizador final se estes elementos visuais não apresentarem informação relevante, estruturada e organizada, nem forem atraentes para este (Filipe Portela & Gisela Fernandes, 2022). 2.3 Data Science No que se refere a Data Science , dependendo do autor podemos observar diferentes perspetivas e definições para este tema. Algumas destas definições são, por exemplo, de Cady (2016) “ Data Science significa fazer um trabalho analítico que, por uma razão ou outra, requer uma quantidade substancial de conhecimentos de engenharia de software.”, de Provost & Fawcett (2013) “ Data Science é um conjunto de princípios fundamentais que apoiam e orientam a extração de informação e conhecimento dos dados tendo por base princípios definidos.” ou de Gibert et al. (2018) “campo multidisciplinar que combina a análise de dados com métodos de processamento de dados e conhecimentos especializados no domínio, transformando os dados em conhecimentos compreensíveis e acionáveis relevantes para uma tomada de decisão informada”. No entanto, independentemente da abordagem tomada nestas definições, podemos obter o consenso que Data Science envolve a capacidade de analisar dados de maneira a obter informação e conhecimento. 2.3.1 Contexto do surgimento de Data Science Para compreender melhor o contexto do surgimento da Data Science , é apresentada a Figura 1. Nela, é representado que, devido aos avanços nas tecnologias de informação e à súbita explosão de dados, entramos na era do Big Data . Um dos grandes impulsionadores disto foi o surgimento da Big Data , que com ela trouxe diversas oportunidades que colidiram na criação de um paradigma denominado datadriven paradigm (Mayer-Schönberger & Cukier, 2013), que está relacionado com resolver problemas de diversos ramos, sendo um deles o empresarial, bem como a capacidade de resolver estes mesmos 15 Teoria Sistemas Pessoas Modelos formais de como os ambientes respondem às diferentes entradas de dados. Protocolos para comunicação segura com atuadores de loT. Interfaces para o controlo da utilização dos dados pelo utilizador. 2.3.4 Relação com o ioScience A patente do ioScience descreve um modelo e arquitetura sistémica orientada para os dados, oferecendo Data Science as a Service (DsaaS) por meio de uma aplicação web/mobile. Neste sentido, os conceitos de Data Science e, mais especificamente, Pervasive Data Science , são relevantes de ser analisados, uma vez que, estes são conceitos essenciais na compreensão da patente de ioScience, sendo que esta plataforma consiste inicialmente numa ferramenta de análise e compreensão de dados, onde o processo de Data Science é implementado como a base do sistema. 2.4 Big Data Com os avanços de tecnologias, a quantidade de mecanismos de captação de dados tem vindo a aumentar, que por consequente leva a um aumento dos dados em grande escala em diferentes setores. Neste ambiente de grande quantidade de dados, surge então o termo “ Big Data ”. Mas a que realmente se refere este conceito? Para Chen et al. (2014), “Sob o aumento explosivo dos dados globais, o termo big data é utilizado principalmente para descrever enormes conjuntos de dados. Comparado com conjuntos de dados tradicionais, os grandes dados incluem tipicamente massas de dados não estruturados que necessitam de mais análises em tempo real.”. Na perspetiva de Nugent et al. (2013), “ Big Data não é uma tecnologia única, mas uma combinação de tecnologias antigas e novas que ajuda as empresas a obter uma visão acionável. Portanto, os grandes dados são a capacidade de gerir um enorme volume de dados díspares, à velocidade certa, e dentro do prazo certo para permitir análises e reações em tempo real.” Segundo Zikopoulos et al. (2011), “o termo Big Data aplica-se à informação que não pode ser processada ou analisada utilizando processos ou ferramentas tradicionais.”. 16 Para além disto, estes autores também expõem que Big Data pode ser definido nas características Volume, Velocidade e Variedade, como é representado na Figura 3. Sendo que Chen et al. (2014) também mencionam a existência de uma quarta caraterística, Valor. Figura 3 - A IBM caracteriza Grandes Dados (Big Data) (adaptado de Zikopoulos et al., 2011). 2.4.1 Características de Big Data Neste ponto, serão descritas as características do modelo dos 3V’s (Volume, Velocidade e Variedade) e a característica apresentada por Chen et al. (2014), Valor. Para além destas características, em estudos mais recentes, podem ser encontradas diversas outras como é o caso de Veracidade, Validade e Volatilidade (Ali-ud-din Khan et al., 2014), criando assim um total de 7V’s. No entanto, é importante destacar que estas características variam ainda de autor para autor, não estando tão consolidadas como as que são apresentadas nesta secção. A. Volume A característica de volume refere-se à grande quantidade de dados que é constantemente gerada e recolhida. O aumento da quantidade de dados gerados é percebido quando observamos que os “volumes de dados mudou de terabytes para petabytes com uma inevitável mudança para zettabytes , e todos estes dados não podem ser armazenados nos seus sistemas tradicionais” (Zikopoulos et al., 2011). 17 B. Velocidade Uma das compreensões para esta característica é a da rapidez em que os dados são obtidos e armazenados. Por outro lado, podemos considerar que a velocidade significa que os procedimentos de tratamento dos dados devem ser realizados rapidamente e em tempo útil, de forma a assegurar que a velocidade que os dados estão a fluir representará o máximo valor comercial possível. C. Variedade A variedade diz respeito aos diversos tipos de dados (dados relacionais tradicionais, dados brutos, semiestruturados e não estruturados), que com o surgimento de sensores e dispositivos inteligentes, passaram a ser possíveis o armazenamento de, por exemplo, áudios, vídeos, páginas de web e texto. Esta variedade foi o que levou a que sistemas tradicionais começassem a ter “dificuldade em armazenar e realizar as análises necessárias para obter a compreensão do conteúdo destes registos” (Zikopoulos et al., 2011). D. Valor Esta característica, segundo Chen et al. (2014), diz respeito ao “problema mais crítico dos grandes dados, que é como descobrir valores de conjuntos de dados com uma escala enorme, vários tipos, e geração rápida.” 2.4.2 Tipos de Big Data No que diz respeito ao Big Data, existem diferentes tipos de dados que o compõem, sendo os dois principais: dados estruturados e não estruturados. Neste sentido, serão definidos ambos e apresentados alguns exemplos de cada um, uma vez que os dados podem ser gerados por computadores/máquinas ou pelo ser humano. A. Dados Estruturados Segundo Nugent et al. (2013), dados estruturados são geralmente dados que possuem um comprimento e um formato definidos, como números, datas, e grupos de palavras e strings . Embora estes dados sejam os mais comuns de ser utilizados, “peritos concordam que este tipo de dados representa cerca de 20 por cento dos dados que existem no mercado” (Nugent et al., 2013). Alguns exemplos destes dados são as seguintes: − Gerados por computadores/máquinas: Dados de sensores; dados financeiros; dados de pontos de venda; dados de registo na Web. 18 − Gerados pelo ser humano: Dados relacionados com jogos; dados Click-stream ; dados de input . B. Dados Não Estruturados Segundo Nugent et al. (2013), em contraste com os dados estruturados, os dados não estruturados são dados que não uma formatação específica. No entanto, isto não quer dizer que documentos de dados não estruturados não possuem uma estrutura específica ou formatação baseada no software que lhes deu origem, mas que o que é interno ao documento ser verdadeiramente não estruturado. Embora os peritos apontem que 80 por cento dos dados disponíveis sejam não estruturados, até recentemente “a tecnologia não suportava realmente fazer muito com eles, exceto armazená-los ou analisá-los manualmente” (Nugent et al., 2013). Alguns exemplos destes dados são as seguintes: − Gerados por computadores/máquinas: Imagens de satélite; Dados científicos; Fotografias e vídeo; Dados de radar ou sonar. − Gerados pelo ser humano: Texto interno à sua empresa; Dados dos meios de comunicação social; Dados móveis; Conteúdo do site. 2.4.3 Relação com o ioScience O conceito de Big Data, as suas características e tipos de dados são fundamentais para compreender as diferenças entre dados estruturados e não estruturados, bem como para entender como esses tipos de dados podem ser relevantes e utilizados na patente do ioScience. O conhecimento e a análise desses conceitos são cruciais para o desenvolvimento e o uso eficaz da plataforma ioScience, que lida com dados de diferentes naturezas e fontes. Isso permite que a plataforma processe e apresente informações analíticas aos usuários finais, conforme necessário. 2.5 Análise de Dados De acordo com Baesens (2014), devido às empresas estarem a ser inundadas por tsunamis de dados, estas cada vez mais possuem um potencial inexplorado de análise para melhor compreender, gerir, e explorar estrategicamente os dados que tem acesso. Sendo que com quantos mais dados são gerados maior é relevância e importância de estes serem analisados. “A análise de dados é o processo de limpeza, alteração e processamento de dados em bruto e extração de informação acionável e relevante” (Kelley, 2023) tanto para as empresas a tomarem decisões 19 informadas, como para os indivíduos no seu dia a dia. “O procedimento ajuda a reduzir os riscos inerentes à tomada de decisões, fornecendo informações e estatísticas úteis, frequentemente apresentadas em gráficos, imagens, tabelas e gráficos.” (Kelley, 2023). Segundo Lepenioti et al. (2020) e Bousdekis et al. (2022), “análise de dados é categorizada em três fases principais caracterizadas por diferentes níveis de dificuldade, valor e inteligência: (i) análise descritiva, respondendo às perguntas "O que aconteceu? "Porque aconteceu?", mas também "O que está a acontecer agora?". (principalmente num contexto de streaming ); (ii) análise preditiva, respondendo às perguntas "O que acontecerá?" e "Por que acontecerá?" no futuro; (iii) análise prescritiva, respondendo às perguntas "O que devo fazer?" e "Porque deveria fazê-lo?".” Como é possível observar na Figura 4, cada fase necessita da anterior como pré-requisito, tornando-se assim numa sequência. É ainda identificada uma fase zero, onde é realizado o pré-processamento de dados e onde os dados brutos são transformados para um formato capaz de ser processado posteriormente pelos algoritmos de análise de dados. Figura 4 - Os níveis de inteligência de acordo com a maturidade analítica dos dados. (adaptado de Bousdekis et al., 2022) No que diz respeito à análise descritiva, esta é a que envolve o nível mais aprofundado de investigação, mas depende fortemente do conhecimento na área. Por outro lado, a análise preditiva faz uso de dados disponíveis em maior escala, enquanto a análise prescritiva é a área menos explorada. 2.5.1 Relação com o ioScience No que diz respeito à patente ioScience, esta baseia-se na capacidade de receber, processar e analisar dados de diversas fontes, sejam eles estruturados ou não estruturados. A plataforma ioScience utiliza técnicas de análise de dados para extrair informações significativas a partir desses dados, permitindo aos usuários finais tomar decisões informadas. 20 2.6 Data Mining No que diz respeito a Data Mining , é difícil optar por uma definição única que forneça uma imagem completa quanto possível do fenómeno. Por esta razão, estas são algumas das definições que se podem encontrar de Data Mining : − A pesquisa automática de padrões em grandes bases de dados, utilizando técnicas computacionais de estatística, aprendizagem mecânica e reconhecimento de padrões; − A extração não trivial de informação implícita, anteriormente desconhecida e potencialmente útil dos dados; − A ciência da extração de informação útil a partir de grandes conjuntos de dados ou bases de dados; − A exploração e análise automática ou semiautomática de grandes quantidades de dados, a fim de descobrir padrões significativos; − O processo de descoberta automática de informação. A identificação de padrões e relações 'ocultas' nos dados. Exemplos de técnicas de Data Mining seriam CRISP-DM (Cross-Industry Standard Process for Data Mining) e “Knowledge Discovery in Databases” (KDD). No entanto, após uma pesquisa sobre os mesmos, foi considerado que, embora ambos sigam pontos semelhantes, o facto de CRISP-DM possuir unicamente seis fases, em comparação com o KDD que possui nove, possibilita uma utilização mais simples e clara deste. 2.6.1 Relação com o ioScience O conceito de Data Mining corresponde ao processo para criação de modelos preditivos em desenvolvimento na solução do ioScience, que representa um dos principais focos do projeto de dissertação atual. Data Mining desempenha um papel fundamental na capacidade da plataforma de extrair informações valiosas a partir de dados brutos e é uma parte essencial da funcionalidade do ioScience para análise de dados e geração de insights significativos. 21 2.7 Business Intelligence Segundo Scheps (2008), uma das definições para Business Intelligence (BI) é qualquer atividade, ferramenta, ou processo utilizado para obter a melhor informação para apoiar a processo de tomada de decisões. No entanto a definição que Scheps (2008) considera como mais relevante no seu livro é que “ Business Intelligence é essencialmente uma visão empresarial oportuna, precisa, de alto valor e acionável, e os processos de trabalho e tecnologias utilizadas para a sua obtenção.”. Nesta definição Scheps (2008) faz referência aos “BI’s Big Four” (Os Quatro Grandes do BI), isto é, as 4 principais características de BI: − Respostas precisas: Para que BI tenha qualquer valor no processo de tomada de decisão, as suas respostas devem ser precisas de forma a refletir corretamente a realidade objetiva da organização, pois sem precisão, os conhecimentos que são o produto do BI podem-se tornar prejudiciais para a empresa. − Perceções valiosas: o objetivo da BI não incide unicamente em produzir informação correta, mas sim em produzir informação que tenha um impacto positivo na organização, podendo este tomar diferentes formas desde redução de custos até à melhoria das operações. − Informação oportuna: a informação ser oportuna é um essencial, pois qualquer informação que pode ser considerada boa pode tornar-se inútil se não for obtida no momento certo. − Conclusões acionáveis: isto é referente ao facto de que, caso as conclusões retiradas do processo de BI não apresentem orientações para ações futuras, estas tornam-se inúteis. É necessário que, com base nas conclusões deste processo, seja possível escolher um caminho de ações futuras. Os valores de BI provêm da difusão de bons hábitos na tomada de decisões. Para adquirir uma abordagem racional no processo de tomada de decisões nas empresas, pode-se utilizar um ciclo contínuo de ações baseadas em evidências. Conforme apresentado na Figura 5, é possível compreender como esse ciclo funciona. 22 Figura 5 - Ciclo contínuo de ações baseadas em evidências (adaptado de Scheps, 2008). O ciclo apresentado inicia-se com a utilização de conceitos e ferramentas de BI para obter perceções significativas a partir dos dados operacionais. Se essas perceções seguirem as características anteriormente mencionadas (oportuno, preciso, de alto valor e acionável), as empresas podem então aplicá-las ao seu processo de tomada de decisão regular. Essas decisões levam à escolha de ações que, se tudo correr como esperado, resultarão em melhores resultados operacionais, recomeçando o ciclo mais uma vez. 2.7.1 OLAP OLAP (Processamento Analítico On-Line ) é uma técnica de BI que fornece a capacidade de olhar para os dados de uma forma verdadeiramente nova, isto é, “é um software concebido para permitir aos utilizadores navegar, recuperar, e apresentar dados comerciais. Em vez de retirar dados de um sistema relacional, escrevendo consultas complexas para os recuperar, e depois inserindo-os manualmente num relatório para análise, as ferramentas OLAP cortam os passos intermédios, armazenando de facto os dados num formato pronto para relatório.” (Scheps, 2008). Segundo Scheps (2008), no núcleo do OLAP está o conceito do cubo OLAP (também chamado cubo multidimensional, ou hipercubo). Isto é, “os dados são moldados em cubos de factos uniformemente estruturados, consistindo em valores analíticos, normalmente de tipo numérico, referidos como medidas, 23 determinados unicamente por valores descritivos extraídos de um conjunto de dimensões.” (Mansmann & Scholl, 2007). A. Arquiteturas Existem três arquiteturas principais de OLAP, segundo Mansmann and Scholl (2007): − MOLAP - Processamento Analítico Multidimensional Online - é a arquitetura baseada em cubos. Esta é construída com foco na velocidade, armazena dados em estruturas lógicas construídas exclusivamente para acelerar a recuperação. − ROLAP - Processamento Analítico Relacional On-Line - simula uma camada cúbica, inserindo uma camada semântica entre a base de dados e a ferramenta do utilizador final que imita as ações do cubo de dados. As ferramentas de acesso OLAP acedem à camada semântica como se estivessem a falar com o cubo OLAP. Isto surge para resolver os problemas que os RDBMS tinham com OLAP. − HOLAP - Processamento Analítico Híbrido On-Line - é uma tentativa de combinar o melhor de ambos os mundos. A estrutura do cubo está no lugar para lidar com um grande número de dimensões que abrangem muitos níveis de hierarquia, oferecendo um desempenho rápido e tempos de atualização rápidos para os trabalhadores que realizam análises e criam relatórios complexos. Entretanto, os sistemas híbridos podem contar com a arquitetura ROLAP economizadora de espaço para armazenar maiores volumes de dados em bruto, canalizando apenas a informação resumida necessária para o cubo. B. Operações OLAP De acordo com Mansmann and Scholl (2007), o OLAP permite uma poderosa análise de dados em tempo real e disponibiliza operações de consulta especializadas para a manipulação de dados multidimensionais, apresentadas na Tabela 2. Tabela 2 - Operações OLAP Operação Descrição DRILL-DOWN Aprofunda o nível de granularidade ao longo de uma dimensão ROLL-UP Diminui o nível de granularidade ao longo de uma dimensão. Operação Descrição SLICE&DICE Seleciona um sub-cubo, especificando condições de seleção em múltiplas dimensões no drill path . 24 RANKING Produz as n células do topo/fundo do cubo em relação ao valor do agregado. PIVOT Muda a orientação dimensional da vista, por exemplo, troca colunas e linhas numa tabela pivot. DRILL-THROUGH Mostra as entradas de facto originais por detrás dos agregados. DRILL-WITHIN Desce a uma hierarquia de classificação diferente, da mesma dimensão. DRILL ANYWHERE Aumenta a dimensionalidade ao descer numa dimensão que ainda não se encontra na trajetória da perfuração. DRILL-ACROSS Junta múltiplos cubos de dados relacionados ao longo das suas dimensões partilhadas para combinar ou comparar as suas medidas. SLICE Reduz a dimensionalidade do conjunto de dados, filtrando uma das dimensões no drill path para um único valor. DICE Especifica os valores a serem excluídos de uma dimensão no drill path . SELECT Reduz uma dimensão no drill path a um conjunto de valores ou a um determinado intervalo de valores. FILTER Especifica as condições de seleção nas dimensões fora do drill path , resultando assim em valores agregados alterados. CONDITIONAL HIGHLIGHTING Marca os agregados que satisfazem uma condição especificada no contexto do conjunto de dados original. PUSH Permite especificar uma medida a partir de uma categoria arbitrária da dimensão. PULL É o inverso de PUSH que permite converter uma medida numa dimensão. 2.7.2 Key Performance Indicators Key Performance Indicators (Indicadores-Chave de Desempenho) (KPIs), segundo Scheps (2008), são métricas e medidas que indicam o estado da empresa. “Os KPIs ajudam as organizações a compreender o seu desempenho em relação às suas metas e objetivos estratégicos.” (Marr, 2015). Por outras palavras, KPIs fornecem a informação de desempenho que permite às empresas compreender se a estratégia adotada atualmente está adequada as suas necessidades de negócio. De acordo com Marr (2015), existem diferentes tipos de KPIs que podem ser implementados nas empresas e que podem assumir as seguintes categorias: 31 ao seu trabalho, ações e comportamento. Os membros da SCRUM Team aprendem e exploram os valores enquanto trabalham com os eventos e os artefactos do SCRUM, sendo que quando estes valores são incorporados pela SCRUM Team , e pelas pessoas com quem esta trabalha, os pilares empíricos SCRUM da transparência, inspeção e adaptação ganham vida construindo confiança. Figura 7 - SCRUM framework (adaptado de Schwaber & Sutherland, 2020) SCRUM Team - A SCRUM Team é uma pequena equipa de pessoas, em que não existem subequipas ou hierarquias, e que é focada em um objetivo de cada vez, o Product Goal . As SCRUM Teams são autogeridas, o que significa que decidem internamente quem faz o quê, quando e como. − Developers - Os Developers são as pessoas da SCRUM Team que estão empenhados em criar qualquer aspeto de um Increment utilizável em cada Sprint. No que diz respeito à presente dissertação, a equipa de developers é composta por Beatriz Rodrigues. − Product Owner - O Product Owner é responsável por maximizar o valor do produto resultante do trabalho da SCRUM Team . No que diz respeito à presente dissertação, o Product Owner é a IOTech. − SCRUM Master - O SCRUM Master é responsável pela implementação do SCRUM tal como definido no Guia do SCRUM. Fá‐lo ajudando todos a compreender a teoria e a prática do SCRUM. No que diz respeito à presente dissertação, o SCRUM Master é o Professor Carlos Filipe Portela. 32 Eventos SCRUM - SCRUM combina quatro eventos formais (Planeamento do Sprint, SCRUM Diário, Revisão do Sprint, Retrospetiva do Sprint) para inspeção e adaptação dentro de um evento de contenção, o Sprint. Estes eventos funcionam porque implementam os pilares empíricos SCRUM de transparência, inspeção, e adaptação. − O Sprint - Os Sprints são o ponto essencial do SCRUM, pois é aqui onde as ideias são transformadas em valor. São eventos de duração fixa de um mês ou menos para criar consistência, sendo que um novo Sprint começa imediatamente após a conclusão do Sprint anterior. − Sprint Planning - O Sprint Planning inicia o Sprint e é aqui onde é determinando, por toda a equipa, o trabalho a ser realizado para o mesmo. O Sprint Planning aborda os seguintes tópicos: Porque é que este Sprint é valioso? O que se pode fazer neste Sprint? Como será feito o trabalho escolhido? − Daily SCRUM - O objetivo da Daily SCRUM é inspecionar o progresso em direção ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planeado. − Sprint Review - O objetivo da Sprint Review é inspecionar o resultado do Sprint e determinar adaptações futuras. A SCRUM Team apresenta os resultados do seu trabalho aos principais stakeholders e são discutidos os progressos rumo ao Product Goal . − Sprint Retrospective - O objetivo da Sprint Retrospective é planear formas de aumentar a qualidade e eficácia. A SCRUM Team inspeciona como correu o último Sprint e discute o que correu bem durante o Sprint, que problemas encontrou e como esses problemas foram (ou não) resolvidos. Artefactos do SCRUM - Os artefactos do SCRUM representam trabalho ou valor. São concebidos para maximizar a transparência da informação chave, para assim, todos os que inspecionam possuírem a mesma base para adaptação. − Product Backlog - O Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto. É a única fonte de trabalho levada a cabo pela SCRUM Team . − Sprint Backlog - O Sprint Backlog é composto pelo Sprint Goal (porquê), o conjunto de itens do Produto Backlog selecionados para o Sprint (o quê), bem como um plano acionável para a entrega do Increment (como). O Sprint Backlog é um plano de e para os Developers ., onde estes 33 conseguem visualizar o trabalho que planeiam realizar durante o Sprint, a fim de alcançar o Sprint Goal . − Increment - Um Increment é um degrau concreto em direção ao Product Goal , isto é um Increment representam pequenas partes do trabalho. 3.2.1 Product Backlog Na Tabela 4, apresentamos o Product Backlog relacionado a este projeto de dissertação. Conforme mencionado anteriormente, o Product Packlog é representado por uma lista emergente e ordenada do que é necessário para melhorar o produto, sendo que esta deve refletir os requisitos do proprietário do projeto, que, neste caso específico, é a empresa IOTech. Na Tabela 4, a coluna de "prioridade" classifica a importância dos diferentes requisitos, enquanto a coluna de "esforço" fornece uma estimativa do trabalho necessário para atender a cada requisito. Ambas são avaliadas em uma escala de 1 a 5, onde 1 é o mínimo e 5 é o máximo. A terceira variável, denominada "realizado", indica o estado de cumprimento de cada requisito e é classificada como "sim" ou "não". É importante destacar que "não" não significa que o requisito não tenha sido implementado, mas sim que não foi completamente alcançado. Tabela 4 - Product Backlog ID Requisitos Prioridade Esforço Realizado 1 Compreensão do estado atual da plataforma 5 2 Sim 2 Otimização visual da plataforma 3 3 Sim 3 Otimização das funcionalidades da plataforma 4 4 Sim 4 Criação de novas funcionalidades na plataforma 5 5 Sim 5 Processo de Data Mining 5 5 Sim 6 Adaptação para o projeto ioCity 4 2 Sim 7 Consolidação da nova versão da plataforma 3 2 Sim 3.2.2 Sprint Backlog Na tabela a seguir, Tabela 5, é apresentado o sprint backlog associado a esta dissertação. É importante notar que cada sprint deve ter um período associado, e, no caso desta dissertação, foram considerados 34 sprints quinzenais. Além da identificação do sprint e do período associado a ele, nesta tabela, serão também incluídos os IDs dos requisitos desenvolvidos em cada sprint. Tabela 5 - Sprint Backlog ID SPRINTS Início Fim ID Product Backlog 1 Sprint 1 27/02/2023 10/03/2023 1 2 Sprint 2 13/03/2023 24/03/2023 1 3 Sprint 3 27/03/2023 07/04/2023 2,3,4 4 Sprint 4 10/04/2023 21/04/2023 2,3,4 5 Sprint 5 24/04/2023 05/05/2023 4 6 Sprint 6 08/05/2023 19/05/2023 4 7 Sprint 7 22/05/2023 02/06/2023 4, 5 8 Sprint 8 05/06/2023 16/06/2023 4, 5, 6 9 Sprint 9 19/06/2023 30/06/2023 5, 6 10 Sprint 10 03/07/2023 14/07/2023 5 11 Sprint 11 17/07/2023 28/07/2023 5 12 Sprint 12 31/07/2023 11/08/2023 4, 5 13 Sprint 13 14/08/2023 25/08/2023 4, 5 14 Sprint 14 28/08/2023 08/09/2023 4, 5 15 Sprint 15 11/09/2023 22/09/2023 4, 7 16 Sprint 16 25/09/2023 06/10/2023 4, 7 17 Sprint 17 09/10/2023 20/10/2023 7 18 Sprint 18 23/10/2023 31/10/2023 7 3.3 CRISP-DM Como apresentado pela IBM (2021), um dos modelos mais utilizados para Data Mining é o CRISP-DM, que significa Processo Padrão para a Mineração de Dados entre Indústrias (Cross-Industry Standard Process for Data Mining). Este foi utilizado durante as tarefas três, Conceção e Desenvolvimento, e quatro, Demonstração, do DSR do presente projeto, uma vez que é uma forma comprovada pela indústria para orientar os esforços de mineração de dados. ▪ Como metodologia, inclui descrições das fases típicas de um projeto, as tarefas envolvidas em cada fase, e uma explicação das relações entre estas tarefas. ▪ Como modelo de processo, o CRISP-DM fornece uma visão geral do ciclo de vida de data mining . 35 Como é apresentado na Figura 8, e segundo Chapman et al. (2000), o ciclo de vida de um projeto de data mining consiste nas seguintes seis fases: − Compreensão do negócio: compreender os objetivos do projeto e os requisitos sob uma perspetiva de negócios; − Compreensão dos dados: recolha inicial de dados e prosseguindo com atividades que permitem familiarizar-se com os dados, identificar problemas de qualidade dos dados, descobrir as primeiras perceções sobre os dados e/ou detetar subconjuntos interessantes para formular hipóteses sobre informações ocultas; − Preparação de dados: atividades necessárias para construir o conjunto de dados final a partir dos dados brutos iniciais; − Modelação: selecionar e aplicar as diversas técnicas de modelação; − Avaliação: realizar a avaliação dos modelos criados utilizando as métricas definidas; − Implementação: organizar e apresentar os resultados obtidos neste processo de forma a estes possam ser utilizados pelo utilizador. 36 Figura 8 - Fases do modelo de referência CRISP-DM (adaptado de Chapman et al., 2000). “A sequência das fases não é fixa. Alternar entre as diferentes fases é sempre necessário. O resultado de cada fase determina qual fase ou tarefa específica deve ser executada em seguida. As setas indicam as dependências mais significativas e comuns entre as fases.” (Chapman et al., 2000). 3.4 Tecnologias e Ferramentas Aqui são apresentadas as tecnologias utilizadas no projeto, bem como as ferramentas que lhe dão suporte. Tendo em consideração que este projeto é baseado na patente do ioScience, foi necessário ter em consideração o que é utilizada na mesma. Na Tabela 6, são apresentadas todas as tecnologias e ferramentas utilizadas, bem como a respetiva justificação de utilização de cada uma. Tabela 6 - Tecnologias/Ferramentas utilizadas nesta dissertação Tecnologias/Ferramentas Justificação Tipo Python Utilizada para o desenvolvimento da RESTful API dedicado ao processo de ETL. Linguagem de Programação 37 Tecnologias/Ferramentas Justificação Tipo JavaScript Utilizada como linguagem de programação para desenvolver componentes da interface de web. Linguagem de Programação Vue.js Desenvolver a interface web. Framework Pandas Utilizada para permitir o armazenamento de dados em dataframes através de algumas etapas do processo ETL. Biblioteca Cube JS Utilizada para desenvolver a camada OLAP. Biblioteca Pinia Utilizada como uma biblioteca de armazenamento e estrutura de gerenciamento de estado para Vue.js. Biblioteca Scikit-learn Utilizada como uma biblioteca de aprendizado de máquina de código aberto, onde algoritmos de aprendizagem podem ser chamados para criação de modelos. Biblioteca Jupyter Notebook Utilizada no processo de análise de dados como uma extensão do python. Aplicação web de fonte aberta Apache ECharts Utilizada na criação de gráficos devidos as suas componentes de visualização. Biblioteca imblearn Utilizada na criação de modelos preditivos a quando a utilização da técnica SMOTE. Biblioteca Visual Studio Code Utilizada como ambiente de desenvolvimento. IDE DBeaver Interface para gerir a base de dados. Interface Docker Utilizada para ciar ambientes onde seriam executados as diferentes etapas do projeto. Plataforma de software Postman Utilizada para testar o funcionamento das APIs utilizadas neste projeto. Plataforma de software 3.5 Dados do projeto Durante a execução do presente do projeto de dissertação foram utilizados quatro conjuntos de dados: − Conjunto de dados de Vila Nova de Famalicão, onde se inserem os dados dos movimentos dos parques de Vila Nova de Famalicão, que foram fornecidos e referem-se ao período de dia 01-022021 até dia 20-03-2021, representando 11574 registos; 38 − Conjunto de dados de Lisboa, onde se inserem os dados dos movimentos dos parques de Lisboa, que estão disponibilizados na página dados.gov 1 , referente ao período de 01-01-2020 até 30-122022, originalmente representando 5.178.222 registos. No entanto, após o tratamento destes, explicado na secção 4.3.3, foram utilizados aproximadamente 23% destes; − Conjunto de dados de Meteorológicos referentes ao período dos movimentos dos parques registados, obtidos através da API Weatherbit 2 , representando 26808 registos; − Conjunto de dados de Localização, onde se inserem os dados de localização referentes aos parques de Lisboa, obtidos através da API geoapi.pt 3 , representando 26808 registos. 1 https://dados.gov.pt/pt/datasets/ocupacao-de-parques-de-estacionamento-historico/#_ 2 https://www.weatherbit.io/api/historical-weather-api 3 https://geoapi.pt/ 39 4. TRABALHO REALIZADO Este capítulo assume um papel central, uma vez que representa todo o processo de desenvolvimento guiado pela metodologia de Design Science Research (DSR). Este corresponde ao ponto três, conceção e desenvolvimento, referente à construção da nova arquitetura do projeto e todos os passos para atingir os resultados obtidos, e ao ponto quatro, demonstração, no que diz respeito à apresentação dos resultados obtidos através do teste das funcionalidades. Dividimos este capítulo em três principais subcapítulos que abordam os aspetos cruciais do projeto. O primeiro subcapítulo apresenta o estado da arquitetura anterior à elaboração deste projeto de dissertação e o estado atual da mesma, com a inserção de um novo módulo de previsão, realizando assim conceção da aplicação. O segundo subcapítulo abrange as otimizações realizadas na plataforma ioScience, destacando as novas funcionalidades do sistema e as melhorias implementadas ao nível da visualização e do desempenho do mesmo, apresentando o desenvolvimento e a demonstração destas funcionalidades. O terceiro subcapítulo é dedicado à descrição do processo de data mining que foi seguido, com o objetivo de criar um módulo preditivo no ioScience e, consequentemente, uma API e uma dashboard otimizadas capazes de realizar previsões aplicadas ao âmbito da ocupação de parques de estacionamento, apresentando o desenvolvimento e a demonstração deste módulo. 4.1 Arquitetura da Solução No que diz respeito à arquitetura da solução, esta teve de ser alterada com a adição dos resultados da subsecção 4.3. A arquitetura da solução originalmente era representada pela Figura 9, onde existem quatro camadas de desenvolvimento: camada de desenvolvimento de dados; camada de desenvolvimento de análise; camada de desenvolvimento de cache; e camada de desenvolvimento de visualização. 40 Figura 9 - Arquitetura antiga da solução. Para uma melhor compreensão das camadas de desenvolvimento da arquitetura antes da realização deste projeto (Figura 9), uma pequena descrição de cada uma seria: 1. Camada de Desenvolvimento de Dados (Camada 1): aqui estão incluídos todos os mecanismos necessários para conduzir os dados desde as fontes de dados até ao armazém de dados, utilizando uma RESTful API capaz de realizar o processo ETL que tem como objetivo a melhoria da qualidade dos dados; 2. Camada de Desenvolvimento de Análise (Camada 2): Nesta camada estão incluídos os mecanismos subjacentes à construção da camada OLAP, representando assim esta fase da arquitetura de alto nível; 3. Camada de Desenvolvimento de Caching (Camada 3): esta camada não faz parte integrante da arquitetura de alto nível, mas pode ser considerada uma ponte entre a camada OLAP e a camada de Visualização. Esta camada intermediária abriga os mecanismos que viabilizam a existência de um 'banco de dados em cache', permitindo visualizações limitadas offline dos dados; 4. Camada de Desenvolvimento da Visualização (Camada 4): Por último, mas não menos importante, nesta camada inclui-se toda a construção das dashboards e sua integração na aplicação web. 47 Figura 17 - Versão atual das KPIs. 48 4.2.2 Funcionalidades da plataforma ioScience No que diz respeito à plataforma do ioScience, no início da elaboração deste projeto, esta já possuía uma lista diversificada de funcionalidades implementadas, portanto, o objetivo aqui foi otimizar as funcionalidades existentes e expandi-las. Para facilitar a compreensão, foi criada a Tabela 8 , que apresenta as funcionalidades atuais da plataforma e o estado delas antes e após a conclusão deste projeto de dissertação. A Tabela 8 foi estruturada da seguinte forma: na coluna 'Antes', a funcionalidade já completamente implementada é indicada com o valor 'Sim' em verde; se a funcionalidade estava em desenvolvimento, mas não completamente estruturada, é marcada como 'Parcial' em amarelo; e se a funcionalidade é completamente nova em comparação com a versão anterior da plataforma, é marcada como 'Não'. Tabela 8 - Estados das funcionalidades da plataforma antes e depois. Número Funcionalidade Antes Depois 1 Combinar dados Sim Sim 2 Adicionar filtro Sim Sim 3 Sugerir dados no processo de filtragem Sim Sim 4 Criar vários gráficos de visualização e mapa Sim Sim 5 Visualizar dados em dois formatos (numéricos e percentagem) Sim Sim 6 Guardar gráficos na dashboard Sim Sim 7 Atribuir nome aos gráficos quando estes são adicionados a dashboard Sim Sim 8 Efetuar Drill-Down Sim Sim 9 Efetuar Rollup Sim Sim 10 Adicionar várias Dashboards Parcial Sim 11 Guardar gráficos na dashboard selecionada Parcial Sim 12 Guardar layout dos gráficos após mudar a dimensão e localização nas dashboards Parcial Sim 13 Descarregar gráficos Sim Sim 14 Mensagens amigáveis Sim Sim 49 Número Funcionalidade Antes Depois 15 Validações Sim Sim 16 Botão das tabelas dentro do gráfico Sim Sim 17 Opção de seleção de tema de cores Não Sim 18 Capacidade de realizar fullscreen da plataforma Parcial Sim 19 KPIs Sim Sim 20 Efetuar Drill-Down e Rollup nos KPIs Não Sim 21 Módulo analítico Sim Sim 22 Módulo preditivo Não Sim 23 Página inicial para a seleção do projeto pretendido Não Sim Ao analisar a Tabela 8, podemos compreender que, antes da realização deste projeto, aproximadamente 35% das funcionalidades atuais da plataforma estavam parcialmente incompletas ou não existiam. Notase que existe o mesmo número de funcionalidades parcialmente incompletas e funcionalidades que não existiam antes da execução deste projeto. Atualmente 100% das funcionalidades da plataforma encontram-se totalmente completas. A seguir, descrevemos com mais detalhes o propósito e as capacidades de cada uma das novas funcionalidades. a) Adicionar várias Dashboards A funcionalidade “Adicionar várias Dashboards ” surge da ideia de o utilizador ser capaz de criar dashboards dependendo das duas necessidades de visualização de dados e de forma a poder aceder aos gráficos de forma direta sem estar constantemente a ter de utilizar a ferramenta explorar, onde se realiza a construção dos gráficos. Esta funcionalidade, utilizando a biblioteca Pinia, é criada utilizando a definição de uma " store " (um tipo de armazenamento de estado), onde serão geridos os dados do painel de controlo das dashboards , utilizando a cache do sistema. Para sermos capazes de adicionar novas dashboards , é necessário a realização de três passos simples, como apresentados na Figura 18: 50 1. Na barra principal, entrar no menu lateral e na área de Componente Analítica para ser realizado a seleção da opção “Adicionar Dashboard ”; 2. Após isto, surgirá um pop-up onde será necessário inserir o nome para a nova dashboard e em seguida, simplesmente selecionar a opção “Criar” (" Create ") apresentada no pop-up para criar a nova dashboard ; 3. Após isto, a dashboard criada aparecerá no menu lateral com o nome atribuído. Ao clicar nela, poderá aceder à mesma. Além disso, se desejar eliminá-la, é possível fazê-lo através do botão com o símbolo de lixo localizado à direita do nome da dashboard . Figura 18 - Adicionar várias Dashboards. b) Guardar gráficos na dashboard selecionada A funcionalidade "Guardar gráficos na dashboard selecionada" segue a funcionalidade anterior, no sentido de que, quando existem várias dashboards nas quais os gráficos podem ser inseridos, é necessário permitir a seleção da dashboard na qual o gráfico deve ser guardado. Esta funcionalidade é incorporada no programa da “ store ”, mencionado na funcionalidade anterior, com o objetivo de adicionar os dados dos gráficos, como itens à cache de dados de cada dashboard , utilizando os métodos definidos nessa “ store ”. Para sermos capazes de guardar gráficos na dashboard selecionada, é necessário a realização de três passos simples, como apresentados na Figura 19: 51 1. Na página "Explorar", após criar o gráfico desejado, selecione a opção “Adicionar à Dashboard ” (" Add To Dashboard ") na lateral direita, acima do gráfico; 2. Após isto, irá aparecer um pop up , onde será necessário preencher o nome do gráfico e escolher em qual das dashboards criadas deseja inseri-lo. Em seguida, basta selecionar a opção "Guardar" apresentada no pop-up para adicionar o gráfico à dashboard ; 3. Após o gráfico ser adicionado à dashboard , este passará a ser exibido na mesma. Se desejar removê-lo, é possível fazê-lo através do botão “Eliminar” (“ Delete ") apresentado na parte inferior do gráfico. Figura 19 - Guardar gráficos na dashboard selecionada. c) Guardar layout dos gráficos após mudar a dimensão e localização nas dashboards A funcionalidade “Guardar layout dos gráficos após mudar a dimensão e localização nas dashboards ” segue as funcionalidades anterior, no sentido de que, após a inserção do gráfico na dashboard , poderá ser necessário alterar as suas dimensões e posições na dashboard . Esta funcionalidade, semelhante à anterior, é incorporada no programa da " store " e faz parte da descrição do gráfico. Esta inicialmente é definida com um valor, mas sempre que a sua localização ou tamanho são alterados, este valor é atualizado. Para ser possível guardar o layout dos gráficos após mudar a dimensão e localização nas dashboards, é necessário a realização de quatro passos simples, como apresentados nas Figura 20 e Figura 21: 52 1. Na página da dashboard selecionada, após a inserção de gráficos na mesma, é selecionada a opção de “É arrastável” (“ Is Draggable ”); 2. Após isto, como é apresentado na Figura 20, no caso de se querer alterar a dimensão do gráfico, é selecionado o canto inferior direito do gráfico e alterado as dimensões do mesmo; Figura 20 - Guardar layout dos gráficos após mudar a dimensão nas dashboards . 3. Por outro lado, como é apresentado na Figura 21, no caso de se querer alterar a localização pode-se selecionar qualquer parte da zona superior do gráfico, onde se encontra o titulo do mesmo, e alterar a localização deste na dashboard ; Figura 21 - Guardar layout dos gráficos após mudar a localização nas dashboards . 4. Após efetuar alterações nas dimensões e/ou localização do gráfico, é necessário voltar a selecionar a opção “É arrastável” (“ Is Draggable ”) para desativar a capacidade de fazer alterações no gráfico. 53 d) Opção de seleção de tema de cores A funcionalidade “Opção de seleção de tema de cores” surge da ideia de o utilizador ser capaz de alterar as cores da dashboard para a sua preferência. Para tal, foi criada uma matriz que contém objetos, representando diferentes temas de cores. Utilizando essa matriz e a biblioteca Pinia, é definida uma " store " (um tipo de armazenamento de estado), na qual será gerido e armazenado qual dos temas da matriz criada que estará ativo para ser apresentado no sistema. Para ser possível selecionar o tema de cores para o sistema, é necessário a realização de dois passos simples, como apresentados na Figura 22: 1. Na barra principal selecionar o icon de “Balde de tinta” e escolher o tema desejado; 2. Após isso, o tema de cores da plataforma será atualizado. No entanto, para os gráficos que já haviam sido gerados, é necessário regerá-los. Figura 22 - Opção de seleção de tema de cores. e) Capacidade de realizar fullscreen da plataforma A funcionalidade de "Capacidade de realizar fullscreen da plataforma" foi concebida para permitir ao utilizador colocar a plataforma em modo de ecrã inteiro, se necessário, para uma melhor visualização dos dados. Esta funcionalidade foi implementada exclusivamente para melhorar a experiência do utilizador. Esta funcionalidade utiliza APIs específicas de diferentes navegadores para ativar a opção de ecrã inteiro, que está associada ao botão de fullscreen . 54 Para ser possível realizar fullscreen da plataforma, é necessário a realização de dois passos simples, como apresentados na Figura 23: 1. Na barra principal selecionar o icon de “ Fullscreen ”; 2. Após isto, se desejar voltar ao tamanho normal, basta carregar no mesmo botão. Figura 23 - Capacidade de realizar fullscreen da plataforma f) Efetuar Drill-Down e Rollup nos KPIs A funcionalidade “Efetuar Drill-Down e Rollup nos KPIs” não é considerada uma funcionalidade inteiramente nova, uma vez que já estava implementada na versão anterior da plataforma, na página das dashboards . Portanto, trata-se da importação de uma funcionalidade já existente para a página das KPIs. Para ser possível efetuar Drill-Down e Rollup nos KPIs, é necessária a realização de três passos simples, como apresentados nas Figura 24 e Figura 25: 1. Quando nos encontramos na página das KPI’s do projeto, é importante refletir no que cada gráfico representa e perceber que os cartões numéricos, o mapa e o gráfico circular não são capazes de drill-drown ou rollup ; 2. Após isso, nos restantes gráficos, se se selecionar uma barra ou ponto onde se deseja realizar o drill-down , será descendido um nível, conforme mostrado na Figura 24 . Este processo pode ser repetido várias vezes, dependendo do nível em que se encontra. 55 Figura 24 - Efetuar Drill-Down nos KPIs. 3. Após realizar o drill-down , é apresentada a opção de efetuar o rollup . No primeiro botão, como mostrado na Figura 25 , é possível subir um nível. Já no segundo botão ao lado, se tiver descido mais do que um nível, ao clicar nele, todos os níveis serão revertidos ao estado original. Figura 25 - Efetuar Rollup nos KPIs. g) Módulo Preditivo Esta funcionalidade envolveu a criação de um novo setor na plataforma, juntamente com uma nova página. Após a criação de uma API de previsão, a página é capaz de apresentar a resposta dessa API num gráfico no estilo heatmap . 56 Em outras palavras, foi desenvolvida uma página que pode enviar pedidos a uma API e apresentar a resposta de forma acessível ao utilizador. No caso do presente projeto, a apresentação final desta página é realizada na secção 4.3.6, onde existe a aplicação desta para a previsão da ocupação dos parques de estacionamento. h) Página inicial para a seleção do projeto pretendido Esta última funcionalidade consiste na criação de uma página inicial para a plataforma, na qual o utilizador pode selecionar o projeto que deseja abrir dentro da sua conta, onde terá acesso unicamente aos seus dados. Após essa seleção, a plataforma carregará o conteúdo de acordo com a escolha feita pelo utilizador. Para esta funcionalidade, em semelhança com a funcionalidade “Opção de seleção de tema de cores”, foi criada uma matriz para conter objetos representando diferentes projetos, e utilizando esta matriz e a biblioteca Pinia, é definida uma " store " (um tipo de armazenamento de estado), onde serão geridos e armazenados qual dos projetos da matriz criada que estará ativo para ser apresentado na plataforma. Para sermos capazes de selecionar o projeto, de modo a ser apresentado na plataforma, é necessária realização de um passo simples, como apresentados na Figura 26: 1. Na página inicial da plataforma, à direita, é apresentada a lista de projetos disponíveis. Pode-se selecionar um projeto desta lista para visualizá-lo na plataforma. Após essa seleção, o restante da plataforma ioScience é carregado com os dados do projeto escolhido. Figura 26 - Página inicial para a seleção do projeto pretendido. 63 Métrica Descrição Justificação Valor número de elementos previstos. Quanto maior este número, pior é o desempenho do modelo. R-Quadrado ( R2 score ) Percentual da variância dos dados que é explicado pelo modelo Quanto maior é o valor de R-Quadrado, mais explicativo é o modelo em relação aos dados previstos. >= 85 % Erro Absoluto Médio ( MAE - Mean absolute error ) Média da diferença entre o valor real com o previsto. Medida da magnitude média dos erros de previsão do modelo. Quanto menor for o valor, melhor o modelo está em fazer previsões precisas. --- Erro Absoluto Relativo ( RAE - Relative absolute error ) Divisão do erro absoluto total e o erro absoluto total do preditor simples. Um bom modelo de previsão terá um rácio próximo de zero, enquanto um modelo fraco terá um rácio superior a um. --- 4.3.2 Compreensão dos dados Nesta etapa, é realizada uma análise profunda dos dados que serão a base de todo o modelo, alicerçando a compreensão do contexto e das características dos conjuntos de dados que irão nortear o projeto. Aqui é mapeado com precisão as nuances dos nossos dados, entendendo as relações, padrões, desafios e problemas que estes possuem. Neste projeto em particular, lidamos com quatro conjuntos de dados distintos, cada um desempenhando um papel fundamental na nossa análise. Todavia, é importante salientar que dois destes conjuntos podem ser considerados como os conjuntos de dados principais, sendo referentes a dados de Vila Nova de Famalicão e Lisboa, e que os outros dois são dados complementares relativos a dados de Localização para complementar os dados de Lisboa e a dados meteorológicos para completar ambos os conjuntos principais. 64 a) Cidade de Vila Nova de Famalicão O primeiro conjunto de dados, que é apresentado na Tabela 12, é relativo aos movimentos de parques de estacionamento de Vila Nova de Famalicão. Como este já foi objeto de tratamento num projeto anterior, serviu como uma base consolidada para o processamento dos restantes dados. Tabela 12 - Análise dos dados Vila Nova de Famalicão. Variáveis Descrição Formato Exemplo de Valores Possíveis name Nome do parque String Estação Rodoviária – Entrada totalplaces A capacidade total de lugares que o parque tem Inteiro 79 totaloccupied Total de lugares ocupados no parque Inteiro 5 city Cidade/concelho onde o parque se localiza String Vila Nova de Famalicão county Freguesia onde o parque se localiza String Crato district Distrito onde o parque se localiza String Braga date Data completa do registo do movimento Date 2021-01-01 fulltime Hora completa em que foi realizado o registo do movimento Tempo 00:00:00 latitude Latitude da localização do parque (Graus) Decimal -41.407140 longitude Longitude da localização do parque (Graus) Decimal -8.515050 65 b) Cidade de Lisboa O segundo conjunto de dados é composto por informações relativas aos movimentos de parques de estacionamento em Lisboa. Este conjunto de dados será o centro das atenções na próxima fase do CRISP-DM, na qual foi realizada a preparação dos dados para análise. Numa primeira tabela referente a estes dados, Tabela 13, é feita uma apresentação detalhada das diferentes variáveis deste conjunto de dados, bem como exemplos de valores para cada uma delas. Tabela 13 - Análise dos dados Lisboa. Variável Descrição Formato Exemplo de Valores Possíveis id_parque O número identificador do parque String P040 nome Nome do parque String Mercado de Alvalade ocupacao Número de lugares ocupados no parque quando os dados foram recolhidos Inteiro 88 capacidade_max A capacidade máxima de lugares do parque Inteiro 118 position Informação de localização do parque String “{'coordinates': [-9.164886, 38.761512], 'type': 'Point'}” data_ocupacao Hora e data da recolha dos dados Data 31/12/2019 23:59 Numa segunda tabela referente aos dados de Lisboa, Tabela 14, é apresentada uma análise estatística (média, desvio-padrão, mínimo, quartis e máximo) das variáveis numéricas: ocupação e capacidade_max. Tabela 14 - Análise estatística dos dados Lisboa. variable total Média std min 25% 50% 75% máx ocupacao 5178222 153.68 204.06 -69 31 75 21 1772 capacidade_max 5178222 329.08 355.69 0 118 238 400 2000 66 Na terceira tabela, referente aos dados de Lisboa, Tabela 15, é apresentada uma análise das variáveis numéricas: id_parque, nome, position e data_ocupacao. Neste contexto, identificou-se um possível problema na variável “ position” , devido à variação na forma de registo ao longo do período de obtenção dos dados. Esta questão é abordada na próxima fase de preparação dos dados. A suspeita surgiu devido ao maior número de valores únicos na variável “ position ” em comparação com as variáveis “id_parque" e "nome". Isso sugere que um parque pode ter mais de um valor " position ", o que não deveria acontecer. Além disso, é necessário tratar esta variável de forma a dividi-la em duas, representando latitude e longitude. Tabela 15 - Análise das variáveis numéricas Lisboa. variable total nº Valores Únicos top freq id_parque 5178222 47 P002 123349 nome 5178222 47 Picoas Plaza 123349 position 5178222 88 {"coordinates":[- 9.128867,38.716819],"type":"P... 327414 data_ocupacao 5178222 1162388 2022-11-03T18:24:33.000Z 72 Por fim, numa última análise dos dados deste conjunto, como é apresentado na Figura 31 , foi possível compreender que existem parques com mais de um valor de "capacidade máxima" associado. Uma vez que estamos a utilizar os dados de Vila Nova de Famalicão como base, tais discrepâncias nos valores não podem ocorrer. 67 Figura 31 - Análise de valores de capacidade_max. c) Localização Além disso, visando enriquecer o conjunto de dados de Lisboa, recorremos à API geográfica, geoapi.pt 4 que nos forneceu um conjunto de dados geográficos relevantes para complementar os dados existentes. Na Tabela 16 são apresentadas as seguintes variáveis: lon, lat, distrito, concelho, freguesia. Tabela 16 - Análise dos dados geográficos. Variáveis Descrição Formato Exemplo de Valores Possíveis lon Longitude da localização do parque (Graus) Decimal -9.135017 lat Latitude da localização do parque (Graus) Decimal 38.712416 4 https://geoapi.pt/ 68 Variáveis Descrição Formato Exemplo de Valores Possíveis distrito Distrito a qual o parque pertence String Lisboa concelho Concelho a qual o parque pertence String Lisboa freguesia Freguesia a qual o parque pertence String Santa Maria Maior d) Meteorologia Por último, é apresentado na Tabela 17, o conjunto de dados meteorológicos, também obtido através da API Weatherbit 5 . Este conjunto de dados meteorológicos foi utilizado tanto para os dados de Vila Nova de Famalicão quanto para os de Lisboa, enriquecendo a nossa compreensão das correlações entre as condições meteorológicas e a ocupação dos parques de estacionamento, isto é, a influência que o clima tem sobre a ocupação dos parques de estacionamento. Tabela 17 - Análise dos dados meteorológicos. Variáveis Descrição Formato Exemplo de Valores Possíveis timestamp_local Registo de data e hora na hora local Data 2020-10-25T01:00:00 night_day Parte do dia (d = dia / n = noite) String d precip Precipitação acumulada em equivalente líquido (por defeito mm) no local Decimal 0.0 temp Temperatura (por defeito Celcius) no local Decimal 10.2 5 https://www.weatherbit.io/api/historical-weather-api 69 4.3.3 Preparação dos dados A fase de Preparação dos Dados, no contexto do CRISP-DM (Cross-Industry Standard Process for Data Mining) marca um ponto crucial na jornada de qualquer projeto de análise de dados. Nesta etapa, a nossa atenção está voltada para a limpeza, transformação e enriquecimento dos conjuntos de dados, com o objetivo de torná-los prontos para análise e modelagem. No caso deste projeto, as maiores alterações foram realizadas no conjunto de dados referentes aos movimentos de parques de estacionamento em Lisboa. a) Cidade de Lisboa Uma das tarefas fundamentais na preparação deste conjunto de dados de Lisboa é a correção de variáveis, as quais podem incluir dados inconsistentes, valores em falta ou outros problemas que possam afetar a qualidade dos resultados. Estas correções basearam-se no que foi observado na fase anterior, sendo algumas delas: − Eliminar linhas em que o número de lugar ocupados é superior à capacidade máxima do parque; − Tratamento da variável ‘position’, de forma a ser possível obter as varáveis longitude e latitude; − Tratamento da variável ‘data_ocupação’, de maneira a ser possível obter as variáveis data (ex.: 15/03/2021) e hora (ex.: 13:00:00); − Tratamento da variável correspondente aos nomes dos parques, de modo a substituir caracteres que possam influenciar processos futuros, como acentos. Para além disto, devido à quantidade elevada de parques a serem tratados neste conjunto de dados, foi concluído pela equipa de desenvolvimento do projeto que se deveria diminuir à quantidade de registos para os dez parques com mais movimentos registados. De seguida, foi dado início à junção dos dados de Lisboa com os dados obtidos a partir da API geográfica. Para isto, foram selecionadas as variáveis latitude e longitude dos parques de Lisboa e realizada uma chamada à API para obter os dados desta. Isso enriquece o conjunto de dados, permitindo uma análise mais abrangente das características espaciais dos parques de Lisboa e sua relação com a ocupação. Após isto, procedeu-se ao enriquecimento do conjunto de dados de Lisboa através de variáveis já existentes no mesmo: − Utilização da variável corresponde à data completa para obter as variáveis: 'month', 'dayofweek', 'weekend', 'weekofyear'; 70 − Utilização da variável corresponde à hora completa para obter as variáveis: 'hour', 'minutes', 'timeofday'. De forma a incorporar o conjunto de dados meteorológicos, obtidos através da API de meteorologia histórica, foram utilizadas as variáveis longitude, latitude, hora e data para realizar a interligação com os restantes dados. Após discussão com a equipa de projeto, foi sugerido também serem acrescentadas algumas características dos parques através de uma pesquisa sobre as características dos mesmos, de maneira a que numa futura fase possa ser testada a relevância destas. Estas características representam variáveis binárias e são as seguintes: ▪ 'park_roof' que indica que o parque é coberto ou não; ▪ 'park_paid' que indica se o parque é pago; ▪ 'park_electric' que indica se o parque tem estacionamento elétrico; ▪ 'park_currency' que indica se o pagamento do parque pode ser em dinheiro; e ▪ 'park_ATM' que indica se o pagamento do parque pode ser com cartão de crédito. b) Cidade de Vila Nova de Famalicão No que diz respeito ao conjunto de dados de Vila Nova de Famalicão, dado que este já se encontrava tratado de um projeto anterior, como preparação para as fases seguintes do CRISP-DM, apenas foi realizado o tratamento da variável correspondente aos nomes dos parques, de forma a substituir carateres que podiam influenciar processos futuros, como acentos. Após isto, foi realizado o enriquecimento do conjunto de dados de Vila Nova de Famalicão através de variáveis já existentes no mesmo: − Utilização da variável corresponde à data completa para obter as variáveis: 'month', 'dayofweek', 'weekend', 'weekofyear' − Utilização da variável corresponde à hora completa para obter as variáveis: 'hour', 'minutes', 'timeofday' Seguido disto, de forma a incorporar o conjunto de dados meteorológicos, obtidos através da API de meteorologia histórica, como nos dados de Lisboa, foram utilizadas as variáveis longitude, latitude, hora e data para realizar a interligação com os restantes dados. 71 Por fim, como nos dados de Lisboa, foram acrescentadas algumas características dos parques através de uma pesquisa sobre as características dos mesmos: ▪ 'park_roof' que indica que o parque é coberto ou não; ▪ 'park_paid' que indica se o parque é pago; ▪ 'park_electric' que indica se o parque tem estacionamento elétrico; ▪ 'park_currency' que indica se o pagamento do parque pode ser em dinheiro; e ▪ 'park_ATM' que indica se o pagamento do parque pode ser com cartão de crédito. c) Junção de todos os dados Após todos os tratamentos e enriquecimento dos dados, tanto de Lisboa e Vila Nova de Famalicão, foi levado em conta a atribuição do mesmo nome a todas as variáveis em ambos os conjuntos de dados, de modo a ser possível a junção de ambos sem qualquer contratempo. Posto isto, na Tabela 18, é apresentado o nome do conjunto de dados que representa todos os conjuntos de dados em trabalho e o nome que estes possuíam no correspondente conjunto de dados de Lisboa ou Vila Nova de Famalicão. Tabela 18 - Nome final das variáveis. Final Vila Nova de Famalicão Lisboa nome name nome ocupacao totalplaces ocupacao capacidade_max totaloccupied capacidade_max lat latitude lat lon longitude lon distrito district distrito concelho city concelho freguesia county freguesia park_roof park_roof park_roof park_paid park_paid park_paid park_electric park_electric park_electric 72 Final Vila Nova de Famalicão Lisboa park_currency park_currency park_currency park_ATM park_ATM park_ATM data date data month month month dayofweek dayofweek dayofweek weekend weekend weekend weekofyear weekofyear weekofyear hora fulltime hora hour hour hour minutes minutes minutes timeofday timeofday timeofday precip precip precip temp temp temp night_day night_day night_day Após ser realizada a junção de todos os conjuntos de dados, foram consideradas as fases seguintes que necessitaram que as variáveis estivessem representadas da melhor forma possível para o processo da testagem dos modelos. Para isto, seguindo os critérios do Instituto Português do Mar e da Atmosfera 6 , foi realizada a categorização dos dados de temperatura (ex.: 1-Muito frio (inferior a 5ºC), 6-Muito quente (superior a 30ºC)) e precipitação (ex.: 1-Fraca (inferior a 0,5mm/h), 3-Forte (superior a 4mm/h))., transformando assim a variável “temp” em “class_temp”. Para além desta categorização, também foi realizada a categorização da variável “minutes” onde, por exemplo, a classe 1 se estende do valor 0 ao valor 15 e a classe 4 de 45 a 60. 6 https://www.ipma.pt/en/index.html 79 Cenário Acuidade (%) Precisão (%) Sensibilidade (%) F1-Score (%) Especificidade (%) Algoritmo Média Desvio Média Desvio Média Desvio Média Desvio Média Desvio B 88.32 13.60 89.45 11.66 88.32 13.60 87.46 15.73 93.31 2.90 DT C 91.60 8.66 93.27 6.14 91.60 8.66 91.31 9.18 96.99 1.53 DT D 89.31 9.84 90.82 7.70 89.31 9.84 88.96 10.50 93.54 2.02 NN b) Modelos de Regressão No que diz respeito aos modelos do cenário A, como se pode observar na Tabela 27, o algoritmo que obteve o melhor desempenho foi o RF, embora este não tenha atingido o valor estipulado para a métrica R2Score na compreensão do negócio. Tabela 27 - Resultados de regressão do cenário A. Algoritmo MSE R2Score MAE RAE DT 7543.88 0.21 59.66 43.04% LR 7740.84 0.19 61.54 44.40% RF 7544.02 0.21 59.66 43.04% No que diz respeito aos modelos do cenário B, como se verifica na Tabela 28, o algoritmo que obteve o melhor desempenho foi o DT, atingindo o valor estipulado para a métrica R2Score na compreensão do negócio e possuindo os melhores resultados nas restantes métricas. Tabela 28 - Resultados de regressão do cenário B. Algoritmo MSE R2Score MAE RAE DT 1372.67 0.86 18.84 13.59% LR 9461.81 0.01 73.73 53.19% RF 1372.74 0.86 18.84 13.59% No que diz respeito aos modelos do cenário C, como se observa na Tabela 29, o algoritmo que obteve o melhor desempenho foi o DT, atingindo o valor estipulado para a métrica R2Score na compreensão do negócio e possuindo os melhores resultados nas restantes métricas. 80 Tabela 29 - Resultados de regressão do cenário C. Algoritmo MSE R2Score MAE RAE DT 1302.81 0.86 18.28 13.18% LR 9426.11 0.01 73.80 53.24% RF 1309.62 0.86 18.33 13.22% No que diz respeito aos modelos do cenário D, como se pode observar na Tabela 30, o algoritmo que obteve o melhor desempenho foi o DT, atingindo o valor estipulado para a métrica R2Score na compreensão do negócio e possuindo os melhores resultados nas restantes métricas. Tabela 30 - Resultados de regressão do cenário D. Algoritmo MSE R2Score MAE RAE DT 365.85 0.96 5.82 4.20% LR 9412.88 0.01 73.52 53.04% RF 984.84 0.90 18.88 13.62% Por fim, comparando os algoritmos com melhor desempenho em cada cenário dos modelos de regressão, apresentados na Tabela 31, podemos concluir que, em semelhança aos modelos de classificação, os atributos do parque, para além do nome do mesmo, pioram os resultados. No entanto, em contraste com os resultados dos modelos de classificação, os atributos de data incluídos no cenário D melhoram significativamente os resultados em todas as métricas observadas, tonando o cenário D o que possui o melhor modelo. Tabela 31 - Comparação de resultados entre cenários dos Modelos de Regressão. Cenário MSE R2Score MAE RAE Algoritmo A 7544.02 0.21 59.66 43.04% RF B 1372.67 0.86 18.84 13.59% DT C 1302.81 0.86 18.28 13.18% DT D 365.85 0.96 5.82 4.20% DT 4.3.6 Implementação A fase de Implementação, no âmbito do CRISP-DM ( Cross-Industry Standard Process for Data Mining ), representa o ponto onde os modelos e as análises desenvolvidos se tornam ferramentas práticas e aplicáveis. 81 Nesta etapa, focalizámo-nos inicialmente na criação de uma API versátil, adaptável para a integração de qualquer modelo criado, para depois a utilizar na página anteriormente criada, na secção 4.2.2, na realização de previsões, que possui todos os mecanismos necessários para as previsões. a) Criação da API No que diz respeito à criação da API, inicialmente, esta foi configurada com modelo de regressão caraterizado por ser inserido no cenário D e utilizar o algoritmo Random Forest (RF). Esta configuração inicial serviu como um ponto de partida, permitindo que a API fosse testada e validada com sucesso. Os resultados obtidos com essa configuração ajudam a refinar o desempenho da API e a garantir que esteja pronta para implantação em cenários do mundo real. No que diz respeito aos requisitos da API, ela funciona quando recebe os seguintes dados: o nome do parque, a data de início da previsão e a data de fim da previsão. No entanto, o modelo utilizado para validar a API requer outros parâmetros, sendo estes: nome do parque codificado, mês, hora, dia da semana, semana do ano, variável binária se é fim de semana ou não, variável binária (se é dia ou noite), classe de temperatura, classe de precipitação, classe do minuto e classe de altura do dia. Para obter todas as informações necessárias para o modelo, foram realizadas transformações nos dados fornecidos, como a utilização de ficheiros de codificação criados aquando da criação do modelo. Isso ocorreu porque o modelo utilizado só aceita variáveis numéricas e chamadas à API de meteorologia (Weatherbit), onde foram impostos limites para não permitir o prosseguimento da previsão se esta ultrapassar 10 dias a partir do dia atual, uma vez que este é o limite da API meteorológica. Relativamente à resposta, e como apresentado na Figura 33 da ferramenta Postman, a API fornece os dados da capacidade máxima do parque, a data da previsão no formato DD-MM-AAAA, a hora da previsão e o valor da previsão, que neste caso representa o número de lugares livres disponíveis no parque. 82 Figura 33 - Resposta da API no Postman. b) Visualização ioScience Após a configuração da API, esta foi integrada no projeto ioScience, especificamente na página de previsão que foi previamente atualizada. Essa integração permite que as previsões de ocupação de parques de estacionamento geradas pelos modelos sejam acessíveis e utilizáveis de forma prática, facilitando a tomada de decisões informadas no contexto da gestão de parques de estacionamento. Para ser possível concretizar um pedido à API, de modo a respeitar todos os seus requisitos anteriormente mencionados, foi criado um formulário de introdução dos dados na página destinada à previsão, como ilustrado na Figura 34 , de forma a não aceitar valores inválidos, como uma data de início anterior ao dia atual. Além disso, também foi criado um filtro para facilitar o acesso ao nome do parque, onde se pode inserir o nome da cidade e rua a que este pertence para filtrar o campo do nome do parque e apenas apresentar os parques relacionados com a cidade e rua selecionadas. O campo de rua não é obrigatório ser selecionado. 83 Figura 34 - Campos a preencher para o funcionamento da API. Por fim, a resposta da API é adaptada de maneira a ser apresentada ao utilizador de forma mais fácil de compreensão na página de previsão. Neste caso, conforme demonstrado na Figura 35, passou por ser a utilização de um gráfico de heatmap, onde se faz a divisão dos dias que foram pretendidos para a previsão e as horas correspondentes desses dias. Se o dia atual for selecionado, a página apresenta unicamente os valores das horas futuras. Figura 35 - Apresentação da resposta da API na página de previsão 84 5. DISCUSSÃO DE RESULTADOS Em relação à parte prática desenvolvida neste projeto, conseguem-se identificar duas componentes principais de resultados. A primeira consiste na otimização da plataforma ioScience, abrangendo a otimização de todo o módulo analítico. A segunda componente refere-se à implementação do novo módulo preditivo da solução, com a subsequente apresentação do mesmo, utilizando os dados de ocupação de parques de estacionamento como exemplo. No que diz respeito à primeira componente, como é apresentado na secção 4.2, esta pode ser dividida em otimizações ao nível visual e ao nível funcional. Ao nível visual, o objetivo deste passava por facilitar ao utilizador a visualização e compreensão dos dados. Para além da plataforma ser totalmente responsiva e escalável para todos os tipos de dispositivos, como computadores, tablets, smartphones e ecrãs táteis de 75 polegadas, foram efetuadas as seguintes alterações: − Otimização da barra de menu, para uma melhor apresentação das diferentes páginas da plataforma; − Otimização dos gráficos, para uma uniformização das suas componentes, bem como a implementação de novos gráficos para uma maior capacidade de apresentação de dados; − Otimização das KPIs, para uma melhor experiência de visualização, que culmina numa melhor compreensão dos dados apresentados nas novas KPI’s criadas pela equipa. Alguns dos exemplos destas KPI’s são: Número de parque públicos; Número de parque com pagamento eletrónico; Média de lugares disponíveis; e Movimentos por parque. Ainda na primeira componente, no que diz respeito à otimização funcional da plataforma, existiu uma otimização, bem como, uma criação de funcionalidades para a plataforma do ioScience, como é apresentado na Tabela 8. No que diz respeito à funcionalidades otimizadas e desenvolvidas, estas são as seguintes: − Adicionar várias Dashboards; − Guardar gráficos na dashboard selecionada; − Guardar layout dos gráficos após mudar a dimensão e localização nas dashboards; − Opção de seleção de tema de cores; − Capacidade de realizar fullscreen da plataforma; 85 − Efetuar Drill-Down e Rollup nos KPIs; − Módulo preditivo; − Página inicial para a seleção do projeto pretendido. Esta primeira componente foi a responsável por concluir os seguintes objetivos deste projeto: − Otimizar o protótipo de uma solução web; − Melhorar o processo de análise de dados em tempo-real; − Adaptar a solução para diferentes projetos. Já no que implica a segunda componente de implementação do módulo preditivo, foram construídos dois tipos de modelos, modelos de classificação e modelos de regressão, sendo que para cada tipo foram utilizados 4 cenários. No que diz respeito aos modelos de classificação, estes tiveram como target uma variável binária, que se foca na quantidade de lugares livres. Se esta fosse maior que 25%, o parque encontra-se livre, caso contrário, encontra-se ocupado. Os modelos de classificação possuíam 5 métricas de avaliação (Acuidade, Precisão, Sensibilidade, F1-Score e Especificidade) e 3 algoritmos ( Decision tree (DT), Naive Bayes (NB), Neural Networks (NN)), resultando assim no desenvolvimento de 12 modelos de classificação. Os melhores resultados obtidos para estes modelos por cenário são apresentados na Tabela 26, sendo que o melhor destes corresponde ao modelo que utilizou o cenário C em combinação com o algoritmo DT. Estes resultados assumem os seguintes valores: 91.60% de Acuidade, 93.27% de Precisão, 91.60% de Sensibilidade, 91.31% de F1-Score e 96.99% de Especificidade. No caso dos modelos de regressão, estes tiveram como target o número de lugares livres no parque de estacionamento. Os modelos de classificação possuíam 4 métricas de avaliação (Erro Quadrático Médio (MSE), R-Quadrado (R2 score), Erro Absoluto Médio (MAE) e Erro Absoluto Relativo (ERA)) e 3 algoritmos ( Decision tree (DT), Random Forest (RF), Linear Regressions (LR)), sendo assim desenvolvidos 12 modelos de regressão. Os melhores resultados obtidos para estes modelos por cenário são apresentados na Tabela 31, sendo que o melhor destes corresponde ao modelo que utilizou o cenário D em combinação com o algoritmo DT. Estes resultados assumem os seguintes valores: 365.85 de MSE, 0.96 de R2Score, 5.82 de MAE e 4.20% de ERA. 86 Para além disto, ao observar os melhores resultados de ambos os modelos de classificação e regressão, podemos compreender que ambos superaram as métricas estipuladas na compreensão do negócio, sendo isto sinónimo de um desempenho notável e alinhado com os objetivos propostos. Essa superação das expectativas reforça a eficácia dos modelos implementados, evidenciando a sua capacidade de fornecer informações valiosas e contribuir positivamente para as estratégias empresariais. A partir dos modelos desenvolvidos, foi implementado o módulo preditivo na solução através de uma API desenvolvida em Python. Essa API é utilizada para, dependendo dos pedidos realizados, retornar as previsões realizadas pelo modelo selecionado, sendo que os resultados são apresentados na página de previsões da plataforma ioScience na forma de um heatmap . Esta segunda componente, para além de responder à questão de investigação “Qual a viabilidade de integrar um módulo preditivo no ioScience, seguindo as regras de construção deste?”, demonstrando que a implementação do módulo preditivo segundo as regras de construção definidas no ioScience é possível, também foi responsável por seguintes objetivos do projeto: − Criar um modelo preditivo; − Implementar APIs em Python. Por fim, e para concluir o objetivo "Testar e documentar o protótipo", disponibilizaram-se os dados do projeto ioCity para testar a plataforma do ioScience, conseguindo assim solidificar a característica de interoperabilidade dos dados da plataforma, uma vez que no projeto ioCity foram utilizadas diferentes fontes de dados. Adicionalmente, procedeu-se à adaptação da plataforma ioScience para que pudesse ser utilizada no projeto ioCity, conforme apresentado na secção 4.2.3. Com isso, foi possível garantir o sucesso do atual projeto de dissertação. 87 6. CONCLUSÃO Este capítulo resume às principais conclusões decorrentes do desenvolvimento da solução e de todo o processo de pesquisa associado. Além disso, a segunda subsecção descreve o trabalho futuro previsto com base na solução atual. Por fim, para avaliar os riscos e destacar as medidas adotadas para mitigar seu impacto no projeto, na última subsecção é apresentada a tabela de riscos. 6.1 Considerações finais O presente documento teve como propósito descrever todas as diferentes etapas deste projeto de dissertação, desde a compreensão do mesmo até a apresentação dos resultados finais. No que diz respeito ao título da presente tese, “Pervasive Modular Data Science – Otimização e interoperabilidade”, este engloba a essência do que este projeto atingiu. No que diz respeito à “Pervasive Data Science”, a aplicação final proporciona a qualquer utilizador a possibilidade de aceder ao conhecimento que a análise dos dados proporciona e de ter uma perspetiva abrangente do estado do objeto em análise, ao qual os dados se referem. Por outro lado, a presente dissertação foi capaz de inserir mais um módulo na plataforma do ioScience, o módulo preditivo, como se pode verificar na arquitetura da solução na secção 4.1. Por outro lado, existiu uma “Otimização e interoperabilidade” da plataforma, como é possível concluir depois de analisadas as otimizações visuais e funcionais, bem como o desenvolvimento de novas funcionalidades, que foram suportadas pela implementação de novos conjuntos de dados (Dados dos Parques da Cidade de Lisboa). A fase inicial do projeto de dissertação passou por realizar uma revisão de literatura destes conceitos relevantes, bem como a apresentação da patente do ioScience que foi a base deste projeto. Para além disto, foram também expostas algumas patentes que possuem semelhanças com o ioScience, para compreender o estado de arte de soluções semelhantes à em questão. Os resultados apresentados após a realização desta etapa foram utilizados para melhor definir uma estratégia para responder à questão apresentada no início deste documento, sendo que, para lidar com a complexidade deste projeto foram selecionadas duas metodologias que tiveram um papel crucial. O Design Science Research foi utilizado como metodologia de investigação e o SCRUM Framework para a componente prática do projeto. 88 Numa segunda etapa, foi apresentada a componente prática do mesmo onde, como apresentado na Tabela 32, cada objetivo definido anteriormente foi atingido aquando da obtenção dos resultados correspondentes, sendo que a questão de investigação, “Qual a viabilidade de integrar um módulo preditivo no ioScience, seguindo as regras de construção deste?” foi respondida através da implementação do módulo preditivo, segundo as regras de construção definidas no ioScience. O módulo foi desenvolvido de forma modular, com multidados, de fácil utilização e configuração, e com versão offline, além da subsequente alteração na arquitetura da solução. Tabela 32 - Objetivos VS Resultados Finais. Objetivos Resultados Finais O1 - Otimizar o protótipo de uma solução web Otimização e implementação de componentes visuais; Otimização e implementação de funcionalidades; Reorganização no código. O2 - Criar um modelo preditivo Implantação do modulo preditivo no ioScience através do processo de data mining . O1.1 - Testar e documentar o protótipo Teste utilizando dados o projeto do ioCity. O1.2 - Melhorar o processo de análise de dados em tempo-real Otimização das funcionalidades da plataforma ioScience. O1.3 - Adaptar a solução para diferentes projetos Implementação da funcionalidade capaz de selecionar o projeto desejado e consequente teste das funcionalidades da plataforma em diferentes projetos. O2.1 - Explorar algoritmos inteligentes Elaboração de 24 modelos de previsão. O2.2 - Implementar APIs em Python Criação da API de previsão em Python. Para quantificar todo o trabalho apresentado, destacam-se os principais resultados alcançados: − 3 otimizações visuais da plataforma ioScience implementadas; − 8 funcionalidades da plataforma ioScience implementadas; 95 SCRUM.org. (n.d.). What is SCRUM? Retrieved February 9, 2023, from {HYPERLINK https://www.SCRUM.org/resources/what-is-SCRUM} Song, I. Y., & Zhu, Y. (2015). Big data and Data Science : what should we teach? Expert Systems , 33 (4), 364–373. https://doi.org/10.1111/exsy.12130 Steele, B., Chandler, J., & Reddy, S. (2016). Algorithms for Data Science (1st ed. 2016). Springer. Visual Studio Code. (2021, November 3). Visual Studio Code Frequently Asked Questions . Retrieved February 23, 2023, from {HYPERLINK https://code.visualstudio.com/docs/supporting/FAQ} vuejs.org. (n.d.). Introduction | Vue.js . Vue.js. Retrieved February 23, 2023, from {HYPERLINK https://vuejs.org/guide/introduction.html} Zikopoulos, I., Eaton, C., & Zikopoulos, P. (2011). Understanding Big Data: Analytics for Enterprise Class Hadoop and Streaming Data (1st ed.). McGraw-Hill Osborne Media. 96 ANEXO I - DIAGRAMA DE GANTT Figura 36 - Diagrama de Gantt - Parte 1 97 Figura 37 - Diagrama de Gantt - Parte 2 98 ANEXO II – ARTIGO ‘DATA MINING MODELS TO PREDICT PARKING LOT AVAILABILITY’ Artigo com o objetivo de compreender como as condições meteorológicas influenciam a previsão da ocupação dos parques de estacionamento e identificar o algoritmo de previsão mais eficaz. Estado: Aceite para publicação Local de publicação: Lecture Notes in Computer Science (EPIA 2023). Springer. Referencia: Beatriz Rodrigues, José Vieira, Carlos Fernandes and Filipe Portela (2023), Data Mining Models to predict parking lot availability. Progress in Artificial Intelligence - Lecture Notes in Computer Science (EPIA 2023). LNAI Volume 14116. ISBN: 978-3-031-49010-1. Springer. DOI:10.1007/978-3031-49011-8_42 99 ANEXO III – ARTIGO ‘PERVASIVE REAL-TIME ANALYTICAL FRAMEWORK—A CASE STUDY ON CAR PARKING MONITORING’ Artigo que apresenta uma visão geral de todo o processo até à criação da framework OLAP. Estado: Publicado Local de publicação: MDPI ( Multidisciplinary Digital Publishing Institute ) Referencia: Francisca Barros, Beatriz Rodrigues, José Vieira, Filipe Portela (2023), Pervasive real-time analytical framework - A case study on car parking . Information - Information for Business and Management–Software Development for Data. Volume 14, Issue 11, 584. MDPI. DOI:10.3390/info14110584