Obras BSB

Mapeamento de Obras Públicas do Distrito Federal

História do Projeto

O Projeto de Mapeamento de Obras Públicas do Distrito Federal nasceu da necessidade de otimizar o acompanhamento e a transparência das obras públicas em andamento na região.
Com o crescente volume de recursos públicos destinados a investimentos em infraestrutura e desenvolvimento urbano, surgiu a ideia de criar uma ferramenta que facilitasse a visibilidade dessas obras, garantindo uma maior transparência para a população do Distrito Federal.

Transparência Pública

O projeto DF em Obras visa promover a transparência ao disponibilizar informações atualizadas sobre obras públicas em andamento, concluídas ou atrasadas no Distrito Federal.

Controle Social

Através de um mapa interativo, qualquer cidadão pode acompanhar o progresso das obras, com dados como localização, status, prazos e responsáveis técnicos.

Controle Social

Com filtros e visualização intuitiva, o projeto incentiva o controle social, permitindo que a população fiscalize o uso dos recursos públicos e cobre melhorias de forma embasada.

Tecnologias Usadas

HTML5
CSS3
Python
Node.js
API Obras Gov
Axios
Tweepy
Leaflet

Story Map

Arquitetura

1. Introdução

Este documento descreve a arquitetura do Sistema de Análise de Obras Públicas do Distrito Federal, que evolui uma versão anterior do mesmo sistema. O objetivo principal é apresentar informações sobre obras públicas do DF de forma interativa e acessível, utilizando um mapa interativo e integração com redes sociais.

2. Histórico e Justificativas Técnicas

O backend principal utiliza Node.js, em continuidade tecnológica com a versão anterior do sistema, permitindo reaproveitamento de código e da equipe técnica familiarizada com essa tecnologia. O armazenamento dos dados das obras públicas é feito em arquivos JSON, mantendo compatibilidade com o projeto passado e facilitando a simplicidade de manipulação local.

3. Arquitetura do Sistema

O sistema é organizado em três camadas principais:
3.1 Camada de Apresentação Sistema Web: Interface web que apresenta o mapa interativo das obras públicas, utilizando a API Leaflet.js para a visualização geográfica. Usuário: Cidadãos em geral interessados em consultar dados das obras no DF.
3.2 Camada de Aplicação (Backend) Backend Node.js: Responsável por consumir a API pública de obras, processar os dados e construir as visualizações do mapa. Bot Python (Bot_X): Automatiza o envio de tweets relatando anomalias detectadas nas obras, utilizando a API Tweepy e a inteligência artificial da Cohere para gerar mensagens humanizadas.
3.3 Camada de Dados Fonte de dados: API pública do governo que fornece dados atualizados sobre obras públicas. Armazenamento: Dados são salvos localmente em formato JSON, seguindo o padrão do sistema anterior.

4. Integrações e Fluxos

O backend realiza chamadas à API de obras públicas, com frequência aproximada diária.
O bot Python executa o monitoramento das informações e a geração dos tweets.
A comunicação entre os componentes ocorre via consumo da API pública e armazenamento compartilhado em JSON.
Integrações com APIs externas incluem:
API de Obras Públicas do DF.
Leaflet.js para visualização.
Tweepy para postagem na rede social X (antigo Twitter).
Cohere AI para geração de texto natural.

5. Segurança e Privacidade

Todos os dados tratados são públicos, provenientes de fontes governamentais abertas.
O gerenciamento das chaves de API (para Tweepy, Cohere etc.) é importante garantir que fiquem armazenadas de forma segura, idealmente via variáveis de ambiente ou arquivos .env.

6. Escalabilidade e Performance

O sistema espera um número considerável de acessos simultâneos.
A arquitetura atual é suficiente para o estágio atual do projeto, mas poderá ser revisada conforme o crescimento do uso.

7. Roadmap de Evolução

Iteração Funcionalidade Justificativa
1 Integração com API da Região Administrativa (RA) Melhor granularidade e precisão dos dados
2 Módulo de gráficos estatísticos Visualização avançada do status das obras
3 Filtros interativos no mapa Melhor experiência e personalização para o usuário
4 Melhor organização da interface Maior clareza e usabilidade para cidadãos

8. Decições Arquiteturais

Manutenção de Node.js no backend e JSON para armazenamento baseadas na continuidade do projeto anterior, visando reaproveitamento e facilidade de manutenção.
Separação do bot em Python, possibilita uso específico de bibliotecas como Tweepy e Cohere.

Documento de Requisitos

1. Introdução

Este documento descreve os requisitos funcionais e não funcionais para a evolução da aplicação web DF em Obras. O objetivo é tornar o sistema mais acessível, intuitivo e informativo, proporcionando uma melhor experiência ao usuário e maior transparência na exibição de dados.

Requisitos Funcionais

2.1 Página de Obras Atrasadas

Objetivo: Melhorar a usabilidade e clareza da página de obras.
Requisitos:
RF01: As informações devem ser organizadas e visualmente intuitivas.
RF02: O sistema deve mostrar o motivo de atraso de cada obra.
RF03: Para obras concluídas, o sistema deve exibir o valor final e o valor inicial, permitindo comparação.
User Stories:
US 1.1.1 Como usuário, quero ver as informações das obras atrasadas de forma organizada para entender rapidamente a situação.
US 1.1.2 Como cidadão, quero ver o motivo de cada obra estar atrasada para que eu entenda a situação com mais transparência.
US 1.1.3 Como cidadão, quero comparar o valor final e o valor inicial de obras concluídas para entender se houve aumento de custo.

2.2 Mapa Responsivo com Filtros

Objetivo: Melhorar o mapa de obras com filtros interativos.
Filtros:
Por Região Administrativa (RA).
Por status: obras concluídas / inacabadas.
Por ano de início da obra.
Por valor mínimo/máximo da obra (filtro a confirmar).
Requisitos:
RF04: Cores do mapa devem estar de acordo com o status das obras.
RF05: O mapa deve ser responsivo.
User Stories:
US 2.2.1 Como usuário, quero acessar o mapa em qualquer dispositivo (PC, celular, tablet).
US 2.2.2 Como usuário, quero filtrar obras por RA para ver as que me interessam.
US 2.2.3 Como usuário, quero filtrar obras por status (concluída ou inacabada).
US 2.2.4 Como usuário, quero filtrar obras por ano de início para comparar entre períodos.
US 2.2.5 Como usuário, quero definir um intervalo de valor mínimo/máximo das obras para entender os investimentos por faixa de valor.
US 2.2.6 Como usuário, quero que as cores do mapa sejam condizentes com o status da obra, facilitando a visualização.

2.3 Acessibilidade

Objetivo: Garantir acessibilidade para todos os usuários. Requisitos: RF06: Opção para o usuário aumentar o tamanho da fonte.
RF07: Disponibilizar modo de alto contraste.
RF08: Melhorar a comunicação entre o usuário e o sistema, com telas mais intuitivas e navegação facilitada.
User Stories:
US 3.3.1 Como usuário com baixa visão, quero aumentar o tamanho da fonte para ler melhor os textos.
US 3.3.2 Como usuário com sensibilidade visual, quero ativar um modo de alto contraste para navegar confortavelmente.

2.4 Comunicação e Visualização dos Dados

Objetivo: Melhorar a comunicação visual com gráficos e redes sociais.
Gráficos desejados:
Proporção de obras concluídas x inacabadas.
Valor total gasto com obras atrasadas.
Valor total gasto com obras concluídas.
Requisitos:
RF09: O bot do Twitter deve publicar os gráficos de gasto, informando o valor gasto com obras atrasadas.
User Stories:
US 4.4.1 Como cidadão, quero ver gráficos que mostrem a proporção de obras concluídas vs inacabadas.
US 4.4.2 Como cidadão, quero ver gráficos que mostrem o valor total gasto com obras atrasadas.
US 4.4.3 Como cidadão, quero ver gráficos que mostrem o valor total gasto com obras concluídas.
US 4.4.4 Como cidadão que acompanha o projeto no Twitter, quero que o bot publique os gráficos com os valores atualizados automaticamente.

Requisitos Não Funcionais

Objetivo: Requisitos técnicos.
Requisitos:
RNF01: O site deve ser responsivo, funcionando corretamente em dispositivos móveis, tablets e desktops.
RNF02: O código-fonte deve seguir o padrão de codificação definido pela equipe de desenvolvimento, garantindo legibilidade e manutenibilidade.
RNF03: O sistema deve ser compatível com as duas últimas versões dos navegadores Google Chrome e Mozilla Firefox.
RNF04: Melhorar navegação e usabilidade geral.

Protótipos

otótipo de alta fidelidade

Navegue pelo nosso protótipo de alta fidelidade do sistema de mapeamento de obras públicas no DF. O protótipo foi criado no Figma

Sobre o Grupo

Fazemos parte do Grupo 11 da disciplina de Métodos de Desenvolvimento de Software, orientada pela professora Carla Rocha. Somos estudantes de Engenharia de Software que atuam na atualização e evolução de projetos reais, com foco na aplicação de práticas ágeis como o Scrum, além de técnicas de testes, qualidade e gestão de projetos. Nosso trabalho é baseado em uma abordagem prática, colaborativa e voltada para a inovação, com o objetivo de aprimorar soluções tecnológicas existentes. No projeto de Mapeamento de Obras Públicas do DF, o nosso Grupo está modernizando uma versão anterior do sistema, incorporando novas tecnologias, melhorias na visualização de dados e integração com redes sociais.

Colaboradores do Projeto

Beatriz

Beatriz Figueiredo

Heloisa

Heloisa Santos

Laura

Laura

Leonardo

Leonardo

Lucas

Lucas de Oliveira

Pedro

Pedro Henrique

Samuel

Samuel Santos

Explore as atas do nosso projeto

Acesse a pasta do nosso projeto no GitHub para obter mais detalhes.

Acessar Atas