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
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.
otótipo de alta fidelidade Protótipos
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 Figueiredo

Heloisa Santos

Laura

Leonardo

Lucas de Oliveira

Pedro Henrique

Samuel Santos
Explore as atas do nosso projeto
Acesse a pasta do nosso projeto no GitHub para obter mais detalhes.
Acessar Atas