diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 00000000..e69de29b diff --git a/404.html b/404.html new file mode 100644 index 00000000..5b12a3d7 --- /dev/null +++ b/404.html @@ -0,0 +1,1404 @@ + + + +
+ + + + + + + + + + + + + + +O projeto LicitaBSB tem como objetivo coletar licitações do site "Meu Querido Diário" relacionadas a Brasília e organizá-las em um feed de rede social. Os usuários poderão realizar buscas avançadas para encontrar licitações específicas de seu interesse.
+A camada de apresentação é responsável por interagir diretamente com o usuário e exibir as informações de forma adequada. Utilizaremos o framework React para desenvolver a interface do usuário, garantindo interatividade, responsividade e uma estilização eficiente.
+Tecnologia | +Versão | +
---|---|
React | +17.0.2 | +
JavaScript | +ES2022 | +
A camada de dados é responsável pelo armazenamento e gerenciamento dos dados do sistema. No contexto deste projeto, optaremos por armazenar os dados em formato JSON diretamente no próprio repositório do GitHub. Isso proporcionará uma abordagem simples e acessível para gravar e compartilhar os dados coletados do "Meu Querido Diário".
+Essa abordagem elimina a necessidade de utilizar bancos de dados tradicionais como MongoDB ou MySQL, pois os dados serão armazenados como arquivos JSON no repositório do GitHub, aproveitando a infraestrutura existente e facilitando a colaboração entre os membros da equipe.
+Dessa forma, não há necessidade de especificar versões de tecnologias relacionadas a bancos de dados, pois estaremos utilizando a infraestrutura nativa do GitHub para armazenamento de dados.
+A camada de aplicação é responsável pela lógica de negócios e processamento das requisições do cliente. Utilizaremos o framework Django em Python para desenvolver o back-end da aplicação, devido à sua simplicidade e versatilidade. O JavaScript também será utilizado em certas partes da aplicação devido à sua eficiência no tratamento de requisições assíncronas.
+Tecnologia | +Versão | +
---|---|
Django | +4.1.0 | +
Python | +3.12.0 | +
Para tarefas agendadas, consideraremos o uso de Python e escolheremos entre Google Cloud ou AWS para hospedagem e execução dessas tarefas, levando em consideração escalabilidade, facilidade de uso e custo.
+Para o web scraping e resgate de documentos, utilizaremos Python juntamente com bibliotecas específicas para essa finalidade. A biblioteca PyPDF2 será empregada para o processamento de arquivos PDF, permitindo a extração e manipulação de texto desses documentos.
+Biblioteca | +Descrição | +
---|---|
PyPDF2 | +Biblioteca em Python para manipulação de arquivos PDF. | +
Scrapy | +Biblioteca em Python para realizar webscraping. | +
Data | +Versão | +Descrição | +Autores | +
---|---|---|---|
2024-04-12 | +1.0 | +Versão inicial da documentação | +Marcelo Adrian | +
O LicitaBSB é um projeto que tem como objetivo coletar licitações do site "Meu Querido Diário" relacionadas a Brasília e organizá-las em um feed de rede social. Os usuários terão a capacidade de realizar buscas avançadas para encontrar licitações específicas de seu interesse.
+Data | +Versão | +Descrição | +Autores | +
---|---|---|---|
2024-04-15 | +1.0 | +Versão inicial da documentação | +Marcelo Adrian | +
Esta ata registra os acontecimentos da reunião realizada em 27/03 (quarta-feira). Inicialmente, foi discutido que cada membro deve escolher em qual cargo deseja trabalhar dentro do projeto. Também foi mencionada a possibilidade de rotacionar o cargo de Arquiteto dentro do projeto, exceto os papéis de Scrum Master e Product Owner.
+Preliminarmente, foi decidido que Marllon Fausto Cardoso desempenhará o papel de Product Owner (PO), enquanto Maria Helena Carvalho será a Scrum Master. Os demais cargos ainda estão pendentes de definição.
+Foi acordado que será desenvolvido um formulário para que cada membro da equipe possa informar sobre suas capacidades e habilidades. Esta tarefa será coordenada por Nathan Abreu e Otávio Henrique. Cada membro deverá indicar sua preferência de cargo dentro do projeto.
+Além disso, foi decidido que as três ideias do projeto serão detalhadamente descritas no Miro, incluindo a listagem das possíveis tecnologias a serem utilizadas. Esta atividade será realizada pelos membros responsáveis por cada uma das três ideias: Marllon Fausto, Maria Helena e Thales Henrique. Inicialmente, o cargo de arquiteto não será atribuído a uma pessoa específica.
+Marcelo Adrian ficou responsável por auxiliar os membros responsáveis por detalhar as três propostas de projeto e ajudar a desenvolver o formulário de pesquisa das habilidades dos membros.
+Outra tarefa atribuída nesta reunião foi a organização do planejamento da Sprint atual (Sprint 0) no repositório do projeto. Isso inclui a indicação das atividades presentes nela, com descrição, objetivos e seus responsáveis. Para esta atividade, Victor Schmidt foi designado.
+Por fim, foi acordado que a reunião de revisão desta sprint será realizada em 01/04 (segunda-feira).
+Marllon Fausto relatou sua atividade de contatar pessoas para compreender a biblioteca do Querido Diário, mas não obteve respostas. Continuará tentando contatar.
+Thales Henrique discutiu o progresso da atividade com Marcelo Adrian, explorando a possibilidade de usar a biblioteca nativa do Querido Diário para extrair textos de documentos.
+Victor e Maria Helena realizaram uma pesquisa sobre as Issues do GitHub, que será uma atividade recorrente para documentar o progresso do projeto.
+Thales também atualizou sobre a atividade de capacitação em Python e acordou com Marcelo Adrian para trabalhar nisso através das Issues.
+Nathan apresentou os resultados da pesquisa sobre os conhecimentos do time. Maria Helena sugeriu detalhar mais para entender melhor os objetivos individuais dos membros.
+Foi decidido criar uma pasta no repositório do projeto para armazenar as atas das reuniões, responsabilidade de Marllon Fausto.
+Os membros discutiram os acertos e problemas da sprint em desenvolvimento, como a falta de resposta nas atividades. Decidiram definir as stacks como JavaScript, React e Python, com outros detalhes a serem decididos posteriormente.
+A partir do formulário de capacidade da equipe, ficou estabelecido que Marllon, Maria Helena e Otávio trabalharão no front-end, Thales, Marcelo Adrian e Victor no back-end, enquanto Nathan será responsável pela integração.
+Na reunião do projeto, liderada por Maria Helena, foram abordados diversos tópicos essenciais para o andamento eficaz das atividades. Inicialmente, houve uma discussão sobre os cargos no projeto, onde foram definidas as responsabilidades do Product Owner (PO), Scrum Master, Arquiteto e Time de Desenvolvimento. Destacou-se a importância da comunicação entre o PO e o Scrum Master para garantir o bom andamento do projeto.
+Posteriormente, foi discutida a possibilidade de implementar uma rotação de cargos no projeto, visando promover o desenvolvimento profissional e pessoal da equipe. A decisão sobre a rotação será enviada ao grupo de WhatsApp para que os interessados se manifestem.
+As atividades da sprint foram detalhadas, incluindo o desenvolvimento dos requisitos do projeto, capacitação em SCRUM, pesquisa sobre ferramentas necessárias para o backend e frontend, além da documentação de arquitetura e escolhas tecnológicas.
+Foi ressaltada a importância de estabelecer um padrão de mensagens de commit, utilizando como referência um link específico para garantir a consistência e organização no versionamento do código.
+Por fim, foi orientado que todos os membros criem suas próprias issues para detalhamento das tarefas, evitando dependência excessiva do PO. Essas issues servirão para acompanhar o progresso das atividades de forma mais eficiente.
+Nesta reunião, foi discutido sobre as atividades da sprint em questão. Essa discussão começou com o membro Marllon comentando sobre sua atividade de Pesquisa de Mercado e User Storie Map. Nesse sentido, ele explicou quais são as jornadas do usuário presentes no sistema e quais funcionalidades serão priorizadas em cada MVP, foi comentado também que o User storie Mapping foi elaborado a partir de uma pesquisa de mercado feita e registrada no próprio Miro do projeto.
+Posteriormente, a Maria Helena comentou sobre a capacitação em SCRUM.
+O Victor seguiu comentando sobre o framework web que foi escolhido, o Django, já sobre o de raspagem de dados, foi comentado que poderá ser utilizado o Beautiful Soup, Scrapy e o Selenium no projeto.
+Já o Thales comentou sobre a impossibilidade de usar a biblioteca do Querido Diário por problemas em ler arquivos pdf, para isso, foi recomendado utilizar a Apache Tika para essa tarefa. Ele também comentou sobre a GitPage do projeto, explicando como ela funciona e como os outros membros da equipe podem realizar modificações nela.
+O Nathan comentou sobre as ferramentas de deploy e database. Nesse contexto, ele elaborou um documento descrevendo diversas opções que podem ser utilizadas. Ele ressaltou o MongoDB, Firestone e MySQL para o database e o Heroku e PythonAnywhere para o deploy. Foi acordado que, ainda para essa sprint, devemos decidir qual banco de dados a equipe irá usar para esse projeto.
+Foi comentado sobre as últimas notícias que dizem que o X vai ser bloqueado no país, mas que isso não vai alterar o prosseguimento do trabalho da equipe.
+A membra Maria Helena destacou as entregas relacionadas aos membros Marcelo, Adrian e Otávio, dada a ausência dos mesmos na reunião anterior. O membro Marcelo informou que o progresso estava em andamento, exceto pelo documento de escolhas tecnológicas, enquanto o membro Otávio assegurou que tudo estava dentro dos padrões ou seria resolvido durante a semana.
+O membro Marllon conduziu a reunião, atribuindo as tarefas a serem realizadas e designan do os responsáveis por elas. Durante o processo, Marllon propôs a implementação de um padrão de issues do Github, o que foi prontamente aceito pelo grupo.
+Otávio ficou encarregado de definir os frameworks e bibliotecas frontend a serem utilizados, além da capacitação em Figma. Victor assumiu a responsabilidade de testar e implementar um miniprojeto com Django, enquanto Marcelo e Nathan foram incumbidos de implantar um projeto piloto sobre banco de dados. Este teste servirá tanto como um exercício de aprendizado quanto para avaliar as capacidades da versão gratuita do banco de dados escolhido, bem como configurar um projeto no Github.
+Maria Helena será responsável pela capacitação em SCRUM, Thales ficará encarregado de testar e implementar um miniprojeto com a biblioteca de extração de dados de PDFs, e Marcelo assumirá a redação do Documento de Arquitetura. E, Marcelo e Thales ficaram responsáveis por fazer a aba 'Project' do GitHub. Por fim, Maria Helena, Otávio e Marllon serão responsáveis pelo desenvolvimento do protótipo do MVP 1.
+Capacitação em Figma: Encerrada, documentada e adicionada ao repositório do projeto para suporte no desenvolvimento do protótipo.
+Documento de Arquitetura: Elaborado e adicionado ao repositório, destacando a necessidade de alterações constantes ao longo do projeto.
+Documentação do Story Map: Desenvolvida durante a elicitação de requisitos e adicionada ao repositório. O requisito de obtenção da modalidade das licitações foi removido devido à sua inconsistência.
+Artefatos do SCRUM: Discutidos conforme acordado na reunião anterior sobre capacitação.
+Implementação do GitHub Projects: Definido que faltava apenas a criação adequada de listas para representar o fluxo de trabalho do projeto para conclusão.
+Protótipo do Produto: Desenvolvido conforme requisitos, mas com baixo nível de fidelidade. Para a próxima sprint, acordou-se em aumentar o nível de fidelidade e obter aprovação da equipe.
+Desenvolvimento de Mini-Projetos (Back-end e Front-end): Back-end desenvolvido e documentado; Front-end será desenvolvido na próxima sprint.
+Configuração do Ambiente de Desenvolvimento: Planejada para a próxima sprint, com cada membro realizando a configuração individualmente. Também será feita a revisão e padronização das descrições das issues das sprints anteriores.
+Primeiramente, foi apresentado para o restante da equipe o protótipo do projeto do figma que foi finalizado. Em seguida, foi falado que a documentação sobre como setar o ambiente de desenvolvimento já está no repositório do projeto e o restante da equipe deve configurar suas próprias máquinas. Alguns membros ainda não terminaram de reescrever as descrições das issues que ficaram responsáveis e isso terminará até o dia 26 de Abril.
+Posteriormente, foi comentado sobre os membros do front-end adiantarem a landing page até a entrega da primeira release (também na sexta, 26 de Abril), além da equipe do back-end procurar implementar algum requisito até o mesmo dia.
+O primeiro tópico foi sobre como será feita a apresentação da release 1. Na próxima semana irá concentrar-se na parte do código, tanto do back quanto o front. O front-end desenvolverá a home page e a página de sobre licitações, sendo que Marllon fará a parte de sobre licitações. Enquanto isso Maria Helena e Otávio faram a home. + Já o back-end focará na API que retorna os dados de uma licitação do diário da união, os responsáveis serão Schimidt e Thales. O scraping servirá para subir todos os diários para poder resgatar os dados necessários, ficou com Thales e Schimidt. Esses dados serão convertidos em .txt, alguém irá analisar esses separando o que realmente é necessário. Depois será convertido para jason, os responsáveis foram Adrian e Natan. O back-end ficou um pouco pesado, mas são poucas as tarefas seguintes dessa área o prazo dessa pode ser estendido. + Por fim, finalizaram-se os slides que serão apresentados na release 1.
+A reunião teve início com discussões sobre aspectos-chave do projeto em andamento. Marcelo Adrian trouxe à tona questões relacionadas aos dados, enfatizando a importância de definir claramente o escopo do projeto e a necessidade de alinhar as interpretações divergentes sobre licitações. Ele também ressaltou a urgência de atualizar a lista de requisitos do scrappy no repositório.
+Victor compartilhou sua perspectiva sobre o evento recente, descrevendo-o como tranquilo e bem-sucedido, o que trouxe um momento de serenidade à discussão.
+Thales e Victor destacaram o êxito do scrappy do Querido Diário, evidenciando sua execução eficiente.
+Maria Helena e Marlon apresentaram os avanços na criação da landing page, demonstrando um progresso significativo e promissor.
+Ao final da reunião, houve uma discussão detalhada sobre a atribuição das tarefas para a próxima sprint. Foi consensual entre os membros da equipe que esta sprint seria especialmente focada no escopo do projeto e no aprofundamento do estudo sobre o conceito de licitação.
+https://docs.google.com/document/d/1zbXIZH9cTjQZYHsMCCh-WvcXmF1yhWRKJCSpjxutl5g/edit?usp=sharing
+https://docs.google.com/document/d/1OnvH6gjw9I79cTZjoHXa_PNAQXMUkzmBxhpHUEmuKfk/edit?usp=sharing
+https://docs.google.com/document/d/134xI9UhBLAtKU9Z9lLlZbXlXCuu5nn30WJF1pbOksp0/edit?usp=sharing
+https://docs.google.com/document/d/1A3KhSRzfA4lt9lg9CROKK7Ck1VeQqYRGvbDV0P9YVvc/edit?usp=sharing
+https://docs.google.com/document/d/1XvbIby2J_i7G9wv73kABNwdLT0FShgTg54fuusqNyFc/edit?usp=sharing
+https://docs.google.com/document/d/1XwP1JJ-4JxRhUBc7z8aRzWUUGzOnBh91zBHN8A62Gf0/edit?usp=sharing
+https://docs.google.com/document/d/18Dx8JvBTkDPH0d5h2FJZrZmeqZW3WFDXwnMdxndStHk/edit?usp=sharing
+https://docs.google.com/document/d/10D2mbbK9NRo5WtMAP-V62PTBPteCiDXKQj6hAp_tvDM/edit?usp=sharing
+https://docs.google.com/document/d/1UdYTlA7NrNsLdsX-zuxKYdt7JWSmAfA1JK9Z72IrGf4/edit?usp=sharing
+https://docs.google.com/document/d/1rc6C_01yYmb9X4UXKJYjL1c7oi9JTs7CeqhPB9jj7Go/edit
+ + + + + + + + + + + + + +Com base na pesquisa que conduzi, identifiquei a necessidade dos seguintes procedimentos:
+Criação de um Formulário de Inscrição: Dada a natureza do nosso site, desprovido de qualquer sistema de login, proponho a implementação de um formulário simples para coleta de emails dos usuários interessados em receber atualizações por meio deste canal.
+Gerenciamento de Emails: Para tal, torna-se imperativo o estabelecimento de um banco de dados privado, a fim de armazenar as informações dos usuários. Nesse sentido, é essencial atentar-se à conformidade com a Lei Geral de Proteção de Dados (LGPD), evitando a exposição indevida de dados sensíveis.
+Seleção de uma Tecnologia para Envio de Emails: Embora opções como Mailchimp e SendGrid ofereçam soluções automatizadas, a viabilidade financeira pode ser uma questão, considerando seus planos de assinatura mensal, mesmo que ofereçam versões gratuitas com funcionalidades limitadas. Portanto, uma alternativa viável identificada é a utilização da biblioteca Python chamada PyWin32, conhecida por sua facilidade de aplicação e gratuidade.
+Desenvolvimento do Modelo e Disparador de Emails: Esta etapa será integrada ao término da coleta de dados e consistirá na criação de um sistema de disparo de emails, integrando-se ao banco de dados para alcançar múltiplos usuários de forma eficiente.
+Cumprimento dos Regulamentos de Proteção de Dados: No contexto do meu projeto, três fatores são de suma importância: o consentimento do usuário, a segurança dos dados e a transparência na coleta dessas informações. O consentimento e a transparência estão diretamente ligados à fase inicial de coleta de dados, com a adição de um sistema para que os usuários possam facilmente cancelar a inscrição na lista de emails. Quanto à segurança dos dados, é crucial a implementação de um banco de dados separado, em conformidade com a LGPD, para evitar possíveis violações.
+Em síntese, identifiquei a possibilidade de implementar um sistema automatizado de envio de emails aos usuários, utilizando a biblioteca PyWin32, de fácil utilização e gratuita. No entanto, ressalto que o principal desafio será a criação de um banco de dados segregado para armazenamento das informações dos usuários, visando a conformidade com a LGPD, o que implica em um aumento da complexidade do backend do projeto.
+Fontes: +- https://sendgrid.com/en-us/resources/guides +- https://mailchimp.com/pt-br/resources/marketing-automations/ +- https://www.youtube.com/watch?v=N97q96BygUg +- https://pypi.org/project/pywin32/ +- https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
+ + + + + + + + + + + + + +Para acessar a base de dados abertos, utilize o seguinte link:
+ +Essa ferramenta é essencial para obter informações governamentais de forma transparente e acessível.
+ + + + + + + + + + + + + +Clique aqui e veja a apresentação sobre os cargos em PDF
+Pelo Scrum Guide (Guia do Scrum), o Scrum Master é o responsável por promover e apoiar as boas práticas do Scrum durante o desenvolvimento de um projeto planejado por essa metodologia ágil.
+Ao lado desse papel fundamental do Scrum estão o Product Owner (Dono do Produto) e o time de desenvolvimento. Mas no Scrum não há confusões entre Product Owner e Scrum Master, cada um tem suas atribuições muito bem definidas.
+Para isso, o papel do Scrum Master é ajudar todos os envolvidos no projeto a entender escopo, metas e domínio do produto, além de facilitar eventos do Scrum, conforme necessidade ou solicitação.
+Entre as atividades do Scrum Master, também cabe ser uma espécie de coach da equipe de desenvolvimento auto-organizada, remover impedimentos ao progresso do desenvolvimento do produto, ajudar a manter a produtividade, além de auxiliar a equipe a criar produtos de alto valor.
+Clique aqui e tenha acesso ao ScrumGuide em PDF
+++Maximizar o valor do produto resultante do trabalho do Time de Desenvolvimento. +O membro cuja função é a de Product Owner deve, principalmente, definir todas as características do produto e de priorizar as entregas que mais vão contribuir com o cliente e com o negócio, organizando-as na ordem do que mais gera valor ao produto para o que menos agrega. Nesse sentido, seu papel envolve o cuidado com o que será produzido, analisando desde a estratégia de negócios ao design do produto. Entre suas responsabilidades, está a definição do escopo do produto que será criado, escrito em uma linguagem que chamamos de 'histórias de usuário' e a priorização do que deve ser feito primeiro. O escopo do produto é chamado de BACKLOG DO PRODUTO.
+
Dito isso, é recomendado que o PO tenha habilidades de conhecer a gestão ágil de projetos e produtos, conhecer bem do negócio e das necessidades de seus clientes, ter total disponibilidade para o projeto e comprometimento com a equipe, saber se comunicar bem para atuar em estreita colaboração, saber negociar, saber ajudar o time de desenvolvimento em todas as fases de execução em relação à dúvidas do produto, ter profundo conhecimento de análise do negócio, do cliente e do mercado, porque é ele quem irá tomar as decisões sobre os recursos do produto.
+O Arquiteto será um cargo definido e mantido durante o nosso projeto de MDS. Sendo assim, suas funções serão:
+Este projeto contém scripts para extrair informações sobre avisos de licitação do Diário Oficial da União (DOU), especificamente focando em licitações relacionadas a Brasília. O script principal (main.py
) permite executar o scraping em diferentes modos: para um intervalo de datas específico, a partir de uma data inicial até a data atual, ou desde 02/01/2013 até a data atual.
main.py
: Script principal para execução via terminal.functions.py
: Contém todas as funções auxiliares utilizadas pelo script principal.data.json
: Arquivo JSON onde os dados extraídos são armazenados.requests
, beautifulsoup4
, urllib3
Você pode instalar as bibliotecas necessárias utilizando:
+pip install requests beautifulsoup4 urllib3
+
+Você pode executar o script main.py
de três maneiras diferentes:
Processar desde 02/01/2013 até a data atual:
+ sh
+ python3 main.py
Processar desde uma data inicial até a data atual:
+ sh
+ python3 main.py <dia-inicial>/<mes-inicial>/<ano-inicial>
Exemplo:
+sh
+python3 main.py 01/01/2020
Processar um intervalo específico de datas:
+ sh
+ python3 main.py <dia-inicial>/<mes-inicial>/<ano-inicial> <dia-final>/<mes-final>/<ano-final>
Exemplo:
+sh
+python3 main.py 01/01/2020 31/12/2020
As datas devem ser fornecidas no formato dd/mm/aaaa
.
Os dados extraídos são armazenados no arquivo data.json
no diretório atual. O script adiciona novos dados ao arquivo existente, se houver.
Configura uma sessão HTTP com tentativas automáticas de reenvio em caso de falhas.
+Capturar Link do Jornal Diário:
+Gera o link para a edição do DOU de uma data específica.
+Extrair URLs de Títulos:
+Obtém as URLs de todas as publicações do DOU para uma data específica.
+Extrair Avisos de Licitação:
+Filtra as URLs para encontrar apenas avisos de licitação.
+Filtrar Avisos de Brasília:
+Verifica se os avisos de licitação são referentes a Brasília.
+Extrair Informações dos Avisos:
+Extrai detalhes dos avisos de licitação, como tipo, número, órgão responsável, objeto, assinante, data de publicação, etc.
+Criar JSON com Avisos:
+python3 main.py 01/01/2020 31/12/2020
+
+Isso processará todos os avisos de licitação do DOU para o intervalo de 01/01/2020 a 31/12/2020 e armazenará as informações em data.json
.
Para executar os testes, utilize o comando:
+python3 -m pytest teste_functions.py
+
+Isso irá executar todos os testes definidos no arquivo teste_functions.py
e fornecer um relatório detalhado dos resultados.
Esses testes visam aumentar a cobertura de testes e garantir que as funções no módulo functions.py
funcionem corretamente sob diferentes condições. Por favor, revise os testes adicionados e informe caso haja alguma sugestão ou modificação necessária.
Obrigado!
+1. Instalando dependências
+Certifique-se de ter a versão mais recente do NodeJS instalada.
+Navegue até o diretório web
e execute o seguinte comando:
npm install
+
+2. Executando o React
+Para rodar o projeto, dentro do diretório /web, execute o comando:
+npm run dev
+
+O site estará disponível por padrão na porta 5432 em http://localhost:5432/ ou http://127.0.0.1:5432/
+ + + + + + + + + + + + + + + + + + +