Integrantes da Equipe • Projeto API • Produto • Tecnologias Utilizadas • Configurar o Ambiente • Wireframe do Produto • Requisitos • Backlog do Produto • Backlog das Sprints
| Integrantes | Redes Sociais |
|---|---|
| Naira Maximo - Product Owner |   |
| Carla Daiane - Scrum Master | |
| João Pedro - Developer | |
| Lucas Alexandre - Developer | |
| Pablo Henrique - Developer | |
| Renato Mendes - Developer | |
| Ruth Mira - Developer | |
| Vitor Morais - Developer | |
- Implementar Aplicação usando Linguagem de Programação (LP) Java Web para BackEnd.
- Implementar Aplicação usando conceitos de Orientação a Objetos (OO).
- Utilizar IDE´s na implementação de Aplicação em Java.
- Aplicar Técnicas de Depuração e Análise de Logs através da IDE com suporte para a LP Java.
- Implementar web services REST.
- Implementar clientes para consumir web services.
- Implementar projeto de Banco de Dados Relacional em termos de seus Principais Objetos (Schema, Tabelas, Views, Índices).
- Implementar consultas em um Banco de Dados Relacional, utilizando junções, subconsultas e agrupamentos.
- Implementar manutenção de dados utilizando DML.
- Programação de Banco de Dados - Prof.ª Juliana Forin Pasquini Martinez
- Linguagem de Programação II - Prof. Lucas Gonçalves Nadalete
- Laboratório de Desenvolvimento em Banco de Dados III - Prof. Giuliano Araújo Bertoti
- 26/08 a 30/08 - Kick-off
- 09/09 a 29/09 - Primeira Sprint
- 30/09 a 20/10 - Segunda Sprint
- 21/10 a 10/11 - Terceira Sprint
- 11/11 a 01/12 - Quarta Sprint
- 12/12 - Feira de Soluções e Apresentação Final API
- Java 22
- Spring Boot 3.3.3
- Spring Data JPA
- Spring Web
- Spring Thymeleaf
- Spring DevTools
- MySQL como banco de dados relacional
- Lombok para reduzir a verbosidade do código
- Jsoup para web scraping
- Jackson para manipulação de dados JSON e XML
Para instalar configurar o banco, atualizar o Maven e demais informações importantes para a utilização do sistema, consulte o Arquivo de Teste.
- Wireframe do produto disponível pelo Figma
| Código | Requisito Funcional |
|---|---|
| R1 | Cadastro de Portais de notícias |
| R2 | Cadastro de APIs |
| R3 | Cadastro de Tags |
| R4 | Cadastro de Jornalistas |
| R5 | Processo de web scraping (capturar os dados de notícias e apis e armazenar em banco de dados) |
| R6 | Indicação de tags que estão relacionadas |
| R7 | Tela de consulta de notícias, com filtros de pesquisa |
| R8 | Tela de APIs, com filtros de pesquisa |
| Código | Requisito Não Funcional |
|---|---|
| RN1 | Prever um grande volume de notícias armazenadas |
| RN2 | Utilizar softwares livres |
| RN3 | Manual do Usuário |
| RN4 | Guia de instalação |
| RN5 | Java (linguagem de programação, frameworks e APIs) |
| RN6 | Documentação API – Application Programming Interface com OpenID |
| RN7 | Modelagem de Banco de Dados ou Arquivo de dados |
| RN8 | Deverá ser uma aplicação web |
| RN9 | O front-end deve ser desenvolvido de forma minimalista |
| Ranking | Prioridade | User Story | Estimativa | Sprint | Requisitos |
|---|---|---|---|---|---|
| 1 | Alta | Como usuário, quero poder cadastrar portais de notícias para que eu possa coletar e armazenar informações desses canais para posterior pesquisa e análise | 8 | 1 | R1, RN1, RN7 e RN9 |
| 2 | Alta | Como usuário, quero cadastrar APIs públicas para coleta de dados estratégicos contextualizados com a minha área de pesquisa, para que eu possa integrar essas informações nas análises | 8 | 2 | R2, RN7 e RN9 |
| 3 | Alta | Como usuário, quero que o sistema capture notícias dos portais cadastrados para armazenar as informações relevantes no banco de dados | 13 | 1 | R5, R4, RN1 e RN7 |
| 4 | Alta | Como usuário, quero cadastrar tags que serão usadas para categorizar e filtrar notícias para melhorar a organização e a busca de dados | 8 | 3 | R3, R6, RN3, RN7 e RN9 |
| 5 | Média | Como usuário, quero consultar notícias filtrando por tag para focar em tópicos específicos | 5 | 4 | R7, R6, RN1 e RN9 |
| 6 | Média | Como usuário, quero consultar APIs associadas a determinadas tags para gerenciar as APIs que estou usando | 5 | 4 | R8 e RN9 |
| 7 | Média | Como usuário, quero consultar notícias filtrando por data para revisar informações dentro de um período específico | 2 | 2 | R7, RN1 e RN9 |
| 8 | Média | Como usuário, quero consultar APIs filtrando por data de cadastro para revisar e gerenciar o uso de APIs em um período específico | 2 | 4 | R8 e RN9 |
| 9 | Média | Como usuário, quero consultar notícias e APIs que contenham uma palavra específica no conteúdo para encontrar informações relevantes, sendo possível pelo cadastro da tag no portal e o vínculo com a notícia postada por esse canal | 13 | 3 | R3, R5, R6, RN1 e RN7 |
| 10 | Baixa | Como usuário, quero configurar e validar o funcionamento dos portais de notícia, para que o processo de web scraping ocorra de forma eficiente de acordo com o agendamento e sem duplicações, garantindo a integridade dos dados. | 7 | 2 | R1, R5, RN7 e RN9 |
SPRINT 1
1-sprint_izc5hZPS.mp4
Como usuário, quero poder cadastrar portais de notícias para que eu possa coletar e armazenar informações desses canais para posterior pesquisa e análise.
- O sistema deve permitir a inserção de detalhes do portal, como nome, URL, marcadores da página (seletores HTML) e período de alimentação do banco (diário, semanal ou mensal)
- Os inputs serão de preenchimento obrigatório do cliente, dos marcadores/seletores HTML para local onde ficam as notícias no portal, data de publicação, jornalista, título e conteúdo. As orientações e exemplos de como fazer a inspeção da página ficarão disponíveis para o usuário.
- O período de alimentação padrão é “diário”, caso não seja definido pelo cliente.
- A data de cadastro do portal precisa ser armazenada no banco. Essa informação determina a sucessão de alimentação do banco para os agendamentos semanais e mensais.
- O usuário deve poder editar e desativar portais cadastrados.
- A interface deve ser simples e fácil de usar.
Como usuário, quero que o sistema capture notícias dos portais cadastrados para armazenar as informações relevantes no banco de dados.
- O sistema deve utilizar a configuração feita pelo usuário no cadastro para coletar dados dos locais certos da página e reconhecê-los, como informações de marcadores/seletores no HTML do site.
- Os dados capturados devem incluir título, data, conteúdo e jornalista.
- A raspagem de dados deve consultar a informação de agendamento no banco para saber quando salvar as notícias.
- Quando o agendamento é semanal ou mensal, o primeiro salvamento de notícias ocorre no dia do cadastro do portal. Os próximos ocorrem de 7 em 7 ou 30 em 30 dias, respectivamente.
- As notícias salvas são as publicadas no dia, não é necessário fazer o salvamento retroativo.
- Quando o agendamento é diário, o salvamento de notícias é feito todos os dias.
- As informações devem ser armazenadas em um banco de dados relacional.
SPRINT 2
Apresentacao.2.Sprint.1.1.mp4
Como usuário, quero configurar e validar o funcionamento dos portais de notícia, para que o processo de web scraping ocorra de forma eficiente de acordo com o agendamento e sem duplicações, garantindo a integridade dos dados.
- Desenvolver testes unitários que garantam o funcionamento correto dos fluxos de edição e desativação de portais.
- Verificar a integridade dos dados após edições e desativações de portais, garantindo que as notícias e portais estejam corretamente associados e atualizados no banco.
- Garantir que todos os campos obrigatórios sejam validados durante o cadastro e edição dos portais. Por padrão, novos portais devem ser cadastrados como ativos.
- Criar cenários de teste que validem o comportamento da rotina de web scraping em diferentes configurações de periodicidade (diária, semanal e mensal), garantindo que a raspagem ocorra conforme esperado.
Como usuário, quero cadastrar APIs públicas para coleta de dados estratégicos contextualizados com a minha área de pesquisa, para que eu possa integrar essas informações nas análises.
- O sistema deve permitir a inserção de detalhes da API, como nome, URL, tipo de dados e período de alimentação do banco (diário, semanal ou mensal).
- Validar os campos para garantir que todas as informações obrigatórias sejam fornecidas (default ativo).
- O período de alimentação padrão é “diário”, caso não seja definido pelo cliente.
- A data de cadastro da API precisa ser armazenada no banco. Essa informação determina a sucessão de alimentação do banco para os agendamentos semanais e mensais.
- O usuário deve poder editar e desativar APIs cadastradas.
- O dia do cadastro da API não deve ser alterado durante a edição.
- Criar testes para garantir que a lógica de cadastro e salvamento de APIs funcione corretamente.
- Incluir cenários de teste para diferentes periodicidades.
- Incluir cenários de teste para verificar a integridade dos dados após a edição e desativação.
- Atualizar o estado da API para indicar que estão desativados.
Como usuário, quero consultar notícias filtrando por data para revisar informações dentro de um período específico.
- O sistema deve permitir a seleção de um intervalo de datas (um dia ou mais).
- A consulta deve retornar todas as notícias dentro do intervalo especificado.
- Criar testes unitários e de integração para validar a funcionalidade de consulta de notícias por data.
- Garantir que as notícias retornadas estejam dentro do intervalo especificado.
Visualizar o Wireframe da Sprint 2.
SPRINT 3
Video.sem.titulo.3.mp4
Como usuário, quero cadastrar tags que serão usadas para categorizar e filtrar notícias para melhorar a organização e a busca de dados.
- O sistema deve permitir a criação de tags em uma interface independente, com validação para evitar duplicidade.
- O sistema deve suportar tags com regionalismos, vinculando palavras com significados iguais automaticamente.
- Uma tabela alimentada por APIs de sinônimos será utilizada no relacionamento entre tags e sinônimos.
- Palavras compostas ou pequenas frases devem ser separadas por hífen.
- O usuário deverá ser capaz de editar uma tag cadastrada, com validação de consistência e duplicidade.
- As tags devem ser aplicáveis a portais e APIs.
- O cliente será capaz de aplicar uma tag no cadastramento de um portal ou API, por meio de input com busca elástica, onde aparecem as tags salvas no banco com o começo igual a palavra que está sendo digitada.
Como usuário, quero consultar notícias e APIs que contenham uma palavra específica no conteúdo para encontrar informações relevantes, sendo possível pelo cadastro da tag no portal e o vínculo com a notícia postada por esse canal.
- O sistema deve permitir a busca por tags previamente cadastradas nos portais pelo conteúdo das notícias.
- Como a maioria das APIs são requisições para dados específicos, ao cadastrar uma API com uma ou mais tags, todas os dados salvos terão essa ou essas tags associadas.
- Caso a palavra da tag seja encontrada no título ou no corpo da notícia, a tag cadastrada no portal será atribuída à notícia e ela será retornada na consulta por tag. Mas caso a varredura na notícia não encontre nenhuma das tags cadastradas no portal, a notícia não receberá tags.
- No cadastramento, o conteúdo de todas as notícias que são salvas no primeiro scraping é verificado e se conter a palavra da tag cadastrada, é atribuída a tag para a notícia.
- As notícias que serão salvas posteriormente, respeitando o agendamento, também seguirão esse padrão de verificação de conteúdo e atribuição ou não da tag.
- Quando o usuário edita um portal ou API e atribui uma tag nova, apenas as futuras raspagens farão a verificação dessa tag. As notícias já armazenadas e os dados das requisições das APIs se manterão com as tags antigas.
SPRINT 4
Video.sem.titulo.4.1.mp4
Como usuário, quero consultar notícias filtrando por tag para focar em tópicos específicos.
- O usuário utilizará um input com busca elástica, onde aparecem as tags salvas no banco com o começo igual a palavra que está sendo digitada, para facilitar a localização da tag considerando uma quantidade grande de registros.
- Ao clicar na tag escolhida, ficará disponível em uma caixa inferior.
- O sistema deve permitir a seleção de uma ou mais tags cadastradas.
- A consulta deve retornar notícias associadas a portais com pelo menos uma das tags selecionadas.
- Verificar diferentes cenários, como múltiplas tags e ausência de resultados.
Como usuário, quero consultar APIs associadas a determinadas tags para gerenciar as APIs que estou usando.
- O usuário utilizará um input com busca elástica, onde aparecem as tags salvas no banco com o começo igual a palavra que está sendo digitada, para facilitar a localização da tag considerando uma quantidade grande de registros.
- Ao clicar na tag escolhida, ficará disponível em uma caixa inferior.
- O sistema deve permitir a seleção de uma ou mais tags cadastradas.
- A consulta deve retornar dados de APIs associadas a pelo menos uma das tags selecionadas.
- Verificar diferentes cenários, como múltiplas tags e ausência de resultados.
Como usuário, quero consultar APIs filtrando por data de cadastro para revisar e gerenciar o uso de APIs em um período específico.
- O sistema deve permitir a filtragem de APIs cadastradas dentro de um intervalo de datas.
- A consulta deve retornar todas as APIs cadastradas dentro do intervalo especificado.
Acesse o board do produto disponível no Jira
Acesse a página do projeto disponível no Confluence
Acesse a documentação de Contribuição do Projeto no arquivo CONTRIBUTING
SPRINT 1 | 09/09/2024 até 29/10/2024
Nesta sprint, usamos usando points por histórias para medir nosso progresso em relação às entregas propostas.
Pontuação total: 29
Última Atualização: 01/10/2024
SPRINT 2 | 30/09/2024 até 20/10/2024
Nesta sprint, usamos points por tarefa para medir nosso progresso em relação às entregas propostas.
Pontuação total: 145
| História | Tarefa finalizada | Story Points | Data de Finalização |
|---|---|---|---|
| PYG-36 | PYG-47 | 5 | 04/10/2024 |
| PYG-3 | PYG-35 | 8 | 04/10/2024 |
| PYG-3 | PYG-33 | 5 | 04/10/2024 |
| PYG-3 | PYG-38 | 5 | 04/10/2024 |
| PYG-3 | PYG-41 | 5 | 04/10/2024 |
| PYG-36 | PYG-46 | 5 | 05/10/2024 |
| PYG-36 | PYG-48 | 8 | 05/10/2024 |
| PYG-36 | PYG-50 | 5 | 07/10/2024 |
| PYG-36 | PYG-51 | 8 | 08/10/2024 |
| PYG-3 | PYG-54 | 0 | 08/10/2024 |
| PYG-36 | PYG-49 | 21 | 09/10/2024 |
| PYG-3 | PYG-53 | 13 | 11/10/2024 |
| PYG-3 | PYG-37 | 5 | 11/10/2024 |
| PYG-3 | PYG-55 | 5 | 14/10/2024 |
| PYG-17 | PYG-44 | 7 | 14/10/2024 |
| PYG-17 | PYG-39 | 8 | 16/10/2024 |
| PYG-3 | PYG-52 | 8 | 17/10/2024 |
| PYG-3 | PYG-34 | 16 | 17/10/2024 |
| PYG-17 | PYG-42 | 3 | 17/10/2024 |
| PYG-17 | PYG-43 | 5 | 19/10/2024 |
Última Atualização: 20/10/2024
SPRINT 3 | 21/10/2024 até 10/11/2024
Nesta sprint, usamos points por tarefa para medir nosso progresso em relação às entregas propostas.
Pontuação total: 202
Obs.: Houve uma mudança de escopo durante o desenvolvimento, resultando em uma redução de 26 pontos que serão tratados na próxima sprint. Essa alteração é visível no burndown.
| História | Chave do item | Status | Data de Finalização | Story Point Tarefa |
|---|---|---|---|---|
| PYG-14 | PYG-70 | Concluído | 24/out./24 00:12 | 5 |
| PYG-93 | PYG-102 | Concluído | 25/out./24 10:49 | 3 |
| PYG-14 | PYG-69 | Concluído | 25/out./24 13:17 | 8 |
| PYG-93 | PYG-107 | Concluído | 25/out./24 13:27 | - |
| PYG-14 | PYG-67 | Concluído | 26/out./24 00:03 | 5 |
| PYG-14 | PYG-82 | Concluído | 26/out./24 02:32 | 5 |
| PYG-14 | PYG-68 | Concluído | 28/out./24 14:48 | 21 |
| PYG-93 | PYG-94 | Concluído | 28/out./24 18:02 | - |
| PYG-93 | PYG-95 | Concluído | 28/out./24 18:02 | - |
| PYG-14 | PYG-84 | Concluído | 29/out./24 19:54 | 8 |
| PYG-14 | PYG-87 | Concluído | 30/out./24 12:45 | 5 |
| PYG-14 | PYG-109 | Concluído | 30/out./24 12:45 | 8 |
| PYG-93 | PYG-104 | Concluído | 30/out./24 20:41 | - |
| PYG-14 | PYG-88 | Concluído | 01/nov./24 16:01 | 8 |
| PYG-14 | PYG-89 | Concluído | 01/nov./24 16:01 | 13 |
| PYG-93 | PYG-105 | Concluído | 01/nov./24 16:05 | - |
| PYG-93 | PYG-106 | Concluído | 01/nov./24 16:11 | - |
| PYG-93 | PYG-97 | Concluído | 04/nov./24 14:58 | - |
| PYG-110 | PYG-111 | Concluído | 05/nov./24 16:15 | 13 |
| PYG-110 | PYG-117 | Concluído | 05/nov./24 16:15 | 8 |
| PYG-110 | PYG-120 | Concluído | 06/nov./24 11:05 | 5 |
| PYG-93 | PYG-98 | Concluído | 07/nov./24 00:39 | - |
| PYG-93 | PYG-101 | Concluído | 07/nov./24 10:34 | - |
| PYG-110 | PYG-119 | Concluído | 07/nov./24 12:49 | 8 |
| PYG-110 | PYG-113 | Concluído | 08/nov./24 20:22 | 8 |
| PYG-110 | PYG-114 | Concluído | 08/nov./24 20:22 | 8 |
| PYG-110 | PYG-116 | Concluído | 10/nov./24 00:29 | 13 |
| PYG-110 | PYG-115 | Concluído | 10/nov./24 00:30 | 8 |
| PYG-93 | PYG-108 | Concluído | 10/nov./24 14:07 | - |
| PYG-110 | PYG-112 | Concluído | 10/nov./24 14:14 | 8 |
| PYG-14 | PYG-90 | Concluído | 10/nov./24 14:44 | 8 |
Última Atualização: 10/11/2024
SPRINT 4 | 11/11/2024 até 01/12/2024
Nesta sprint, usamos story points para medir nosso progresso em relação às entregas propostas.
Pontuação total: 220
| História | Resumo | Status Concluído | Data de Finalização | Story Point |
|---|---|---|---|---|
| PYG-122 | Melhorias e Refatoração no Cadastro de Portais e APIs - Parte 2 | 10/11/2024 16:10 | 01/12/2024 21:48 | 89.0 |
| PYG-22 | Consultar APIs por Tag | 11/09/2024 20:41 | 28/11/2024 14:46 | 55.0 |
| PYG-21 | Consultar APIs por Data | 11/09/2024 20:33 | 26/11/2024 07:25 | 21.0 |
| PYG-18 | Consultar Notícias por Tag | 11/09/2024 20:26 | 18/11/2024 15:54 | 55.0 |
Última Atualização: 10/11/2024