diff --git "a/Entregas/Declara\303\247\303\243o de Escopo do Produto.pdf" "b/Entregas/Declara\303\247\303\243o de Escopo do Produto.pdf" index 8df75589..76bf6ac7 100644 Binary files "a/Entregas/Declara\303\247\303\243o de Escopo do Produto.pdf" and "b/Entregas/Declara\303\247\303\243o de Escopo do Produto.pdf" differ diff --git "a/Entregas/Documento Vis\303\243o.pdf" "b/Entregas/Documento Vis\303\243o.pdf" index 4cd89610..934b7ca1 100644 Binary files "a/Entregas/Documento Vis\303\243o.pdf" and "b/Entregas/Documento Vis\303\243o.pdf" differ diff --git a/README.md b/README.md index d392b746..8e500366 100644 --- a/README.md +++ b/README.md @@ -3,14 +3,14 @@ ## MkDocs - [Link para o mkdocs da equipe](https://fga0138-mds-ajax.github.io/2023-2-POLLUX/) -## Entregáveis +## Entregáveis (Atualizados) - [Documento Visão](/Entregas/Documento%20Visão.pdf) - [Declaração de Escopo](/Entregas/Declaração%20de%20Escopo%20do%20Produto.pdf) - [Documento de Arquitetura](/Entregas/Documento%20de%20Arquitetura.pdf) ## Apresentações - [1° Apresentação - Visão do Produto - 04/09/2023](Apresentações/1°%20Apresentação.pdf) -- [1° Apresentação - Arquitetura - 01/11/2023](Apresentações/2°%20Apresentação%20-%20Arquitetura.pdf) +- [2° Apresentação - Arquitetura - 01/11/2023](Apresentações/2°%20Apresentação%20-%20Arquitetura.pdf) ## Atas - [1° Reunião](/Atas/1°%20Reunião.pdf) @@ -18,4 +18,6 @@ - [3° Reunião](/Atas/3°%20Reunião.pdf) - [4° Reunião](/Atas/4°%20Reunião.pdf) - [5° Reunião](/Atas/5°%20Reunião.pdf) - +- [6° Reunião](/Atas/6°%20Reunião.pdf) +- [7° Reunião](/Atas/7°%20Reunião.pdf) +- [8° Reunião](/Atas/8°%20Reunião.pdf) diff --git a/docs/assets/DiagramaDeCasos de Uso.png b/docs/assets/DiagramaDeCasos de Uso.png new file mode 100644 index 00000000..b22f875c Binary files /dev/null and b/docs/assets/DiagramaDeCasos de Uso.png differ diff --git a/docs/assets/DiagramaDeIshikawa.png b/docs/assets/DiagramaDeIshikawa.png new file mode 100644 index 00000000..e8b55749 Binary files /dev/null and b/docs/assets/DiagramaDeIshikawa.png differ diff --git a/docs/declaracaoEscopo.md b/docs/declaracaoEscopo.md index 0b58151c..355738ac 100644 --- a/docs/declaracaoEscopo.md +++ b/docs/declaracaoEscopo.md @@ -1,8 +1,13 @@ # Declaração de Escopo do Produto -## **1.0 Problema / Sistema de Software** -Definição da equipe. +**Histórico de Revisão** + +|**Data** |**Versão** |**Descrição** |**Autor** | +| - | - | - | - | +|23/10/2023 |1\.0 |Início do Documento Visão. |Nicollas Gabriel; Samuel Ribeiro; Eric Rabelo; Isaque Colem; Rodrigo Braz | +|10/11/2023 |2\.0 |Aplicando alterações ao documento de acordo com a correção do professor Ricardo Ajax. |Nicollas Gabriel Samuel Ribeiro Eric Rabelo Isaque Colem Rodrigo Braz | +## **1.0 Problema / Sistema de Software** ### **Definição da equipe** - Nicollas Gabriel – Responsável por desenvolver funcionalidades e implementação de rotas Backend. - Samuel Ribeiro – Responsável pelo desenvolvimento funcionalidades e correções de bugs no Backend. @@ -11,7 +16,8 @@ Definição da equipe. - Eric Rabelo – Responsável pelo desenvolvimento e funcionalidades no Frontend. ### **Resumo do problema** -Nosso software representa uma aplicação web que oferece uma abordagem prática e em tempo real para avaliar e pesquisar os professores da FGA. O propósito central desta ferramenta é criar um ambiente seguro e anônimo onde estudantes, tanto novos quanto veteranos, possam compartilhar suas opiniões sobre os professores e as disciplinas ministradas na Faculdade do Gama (FGA). +Como proporcionar aos estudantes da FGA um sistema eficaz que lhes permita avaliar e acessar avaliações de outros alunos sobre os professores, a fim de facilitar a escolha de suas disciplinas e professores de maneira informada e alinhada com suas +preferências acadêmicas? ### **Sistema de Software** Este sistema permite que os alunos avaliem os professores e as disciplinas de forma anônima, proporcionando feedback valioso para a melhoria contínua do ensino. Além disso, o “GamaTrack” também oferece aos professores a oportunidade de entender melhor as necessidades e expectativas dos alunos, permitindo-lhes ajustar seus métodos de ensino de acordo. @@ -53,7 +59,7 @@ Aqui está um breve resumo de como o Scrum foi aplicado: - **Revisão do Sprint:** No final do Sprint, a equipe se reúne para revisar o trabalho realizado e discutir o que funcionou bem e o que pode ser melhorado. -O uso da metodologia Scrum permitiu à nossa equipe responder rapidamente às mudanças, melhorar continuamente nossos processos e entregar resultados de alta qualidade de forma consistente. +O uso da metodologia Scrum permitiu à nossa equipe responder rapidamente às mudanças, melhorar continuamente nossos processos e entregar resultados de alta qualidade de forma consistente quando aliadas às práticas técnicas do Extreme Programming (XP) para garantir a qualidade técnica do software. ## 2.0 Backlog do Produto @@ -110,7 +116,7 @@ O uso da metodologia Scrum permitiu à nossa equipe responder rapidamente às mu | Administrador | Responsável por manter os perfis de acesso da aplicação, criar novos usuários, alterar usuários já existentes, ou excluir usuários (Manter usuários). | Descrever sucintamente as permissões de acesso. | | Usuário Comum | Pode acessar as principais funcionalidades e utilizar livremente o software. | Acesso às informações e funcionalidades principais. | -### *2.2 Cenários Funcionais** +### **2.2 Cenários Funcionais** | Numeração do Cenário | Nome do Cenário | Sprints | | -------------------- | -------------------------------------------- | --------- | @@ -127,33 +133,34 @@ O uso da metodologia Scrum permitiu à nossa equipe responder rapidamente às mu | Numeração da Sprint | Nome do Requisito (Cenário / Requisito) | Tipo de Requisito | Priorização do Requisito (Funcional / Não Funcional) | Must, Should, Could | Descrição Sucinta do Requisito | User Stories (U.S.) Associadas | | ------------------- | ------------------------------------- | ----------------- | ------------------------------------------------------ | ------------------ | ------------------------------ | ----------------------------- | -| 1 | Sprint 5 - Registro de Usuário | Funcional | Must | | Os usuários devem ser capazes de criar uma conta no sistema. | US-01 / US-03 | -| 2 | Sprint 5 - Login de Usuário | Funcional | Must | | Os usuários devem ser capazes de fazer login no sistema. | US-02 | -| 3 | Sprint 6 - Busca de Professores | Funcional | Must | | Os usuários devem ser capazes de procurar por professores. | US-05 / US-07 | -| 7 | Sprint 7 - Avaliação de Professores | Funcional | Must | | Os usuários devem ser capazes de avaliar os professores. | US-08 / US-11 / US-12 / US-13 / US-17 | -| 8 | Sprint 6 - Visualização de Outras Avaliações | Funcional | Must | | Os usuários devem ser capazes de ver avaliações feitas por outros usuários. | US-08 / US-09 / US-14 / US-15 | -| 5 | Sprint 8 - Busca de Matérias por Curso | Funcional | Should | | Os usuários devem ser capazes de buscar todas as matérias de uma engenharia específica. | US-06 | -| 4 | Sprint 3 - Visualização dos Dados de um Professor Específico | Funcional | Must | | Os usuários devem ser capazes de visualizar dados de um professor específico. | US-07 / US-08 / US-09 / US-10 | -| 6 | Sprint 4 - Visualização dos Professores de uma Matéria Específica | Funcional | Should | | Os usuários devem ser capazes de visualizar todos os comentários feitos por outros alunos sobre um professor específico. | US-06 / US-07 | +| 1 | Registro de Usuário | Funcional | Must | | Os usuários devem ser capazes de criar uma conta no sistema. | US-01 / US-03 | +| 2 | Login de Usuário | Funcional | Must | | Os usuários devem ser capazes de fazer login no sistema. | US-02 | +| 3 | Pesquisa por Professor | Funcional | Must | | Os usuários devem ser capazes de procurar por professores. | US-05 / US-07 | +| 7 | Avaliação de um Professor Específico | Funcional | Must | | Os usuários devem ser capazes de avaliar os professores. | US-08 / US-11 / US-12 / US-13 / US-17 | +| 8 | Visualização de Avaliações de outros Alunos | Funcional | Must | | Os usuários devem ser capazes de ver avaliações feitas por outros usuários. | US-08 / US-09 / US-14 / US-15 | +| 5 | Listagem de Matérias por Engenharia | Funcional | Should | | Os usuários devem ser capazes de buscar todas as matérias de uma engenharia específica. | US-06 | +| 4 | Visualização dos Dados de um Professor Específico | Funcional | Must | | Os usuários devem ser capazes de visualizar dados de um professor específico. | US-07 / US-08 / US-09 / US-10 | +| 6 | Visualização dos Professores de uma Matéria Específica | Funcional | Should | | Os usuários devem ser capazes de visualizar todos os comentários feitos por outros alunos sobre um professor específico. | US-06 / US-07 | ### **2.4 Sprints Previstas** | Sprint | Descrição | Objetivos | User Stories | | ------- | --------------------------------------------- | ---------------------------------------- | -------------------- | | Sprint 1 | Tema 1 - Acesso a aplicação | Implementação da funcionalidade de registro e login do usuário. | US-01, US-02, US-03, US-16, US-18 | -| | | | | | Sprint 2 | Tema 1 - Acesso a aplicação | Desenvolvimento do login e cadastro de usuários. | US-18, US-19, US-20 | -| | | | | | Sprint 3 | Tema 2 - Busca de Professores | Implementar a funcionalidade de busca de professores. | US-05 | -| | | | | | Sprint 4 | Tema 2 - Listagem de Matérias por Engenharia | Implementar a funcionalidade de listagem de todas as matérias das engenharias da FGA. | US-06 | -| | Tema 3 - Avaliação de Professores | Implementação de avaliar e comentar anonimamente nos perfis dos professores. | US-07, US-09, US-10, US-11, US-12, US-13, US-14, US-17 | -| | | | | -| Sprint 5 | | Implementar funcionalidades adicionais. | | -| | | | | +| Sprint 5 | | Implementar funcionalidades adicionais. | | | Sprint 6 | Teste e funcionalidade do projeto | Fazer todos os testes do software e reparo do código. | | +| Versão | Funcionalidade | Data Estimada | +| ------ | -------------- | ------------- | +| 1.0 | Perfil dos Professores | 15/11/2023 | +| 2.0| Avaliação dos Professores | 30/11/2023 | +| 3.0| Versão Final | 15/11/2023 | + + ## **3.0 Definição de Ready / Done** Os critérios de "Ready" indicam as condições que uma tarefa deve atender antes de ser considerada pronta para os testes. Isso inclui ter uma descrição clara da tarefa, critérios de aceitação bem definidos, a resolução de todas as dependências, garantir que a equipe de teste tenha os recursos necessários e a devida priorização no backlog. @@ -191,6 +198,21 @@ Os critérios de "Ready" indicam as condições que uma tarefa deve atender ante ## **5.0 Casos de Uso** +![](/assets/DiagramaDeCasos%20de%20Uso.png) + +Estudante: Este ator tem várias ações que pode realizar. +Criar uma conta: O estudante pode criar uma nova conta no sistema. +Logar no sistema: Após criar uma conta, o estudante pode fazer login no sistema. +Buscar professor: O estudante pode buscar diretamente o professor pelo nome. +Buscar por curso: O estudante também pode buscar por curso, onde serão listadas matérias referentes ao curso escolhido, assim fazendo com o que o estudante tenha uma variedade de opções de professores que dão aquela disciplina. +Ver avaliações do professor: O estudante pode visualizar detalhes sobre um professor específico. Como opiniões de alunos que já fizeram a disciplina com aquele professor. +Avaliar professor: O estudante pode avaliar um professor com base em sua experiência. + +Administrador: Este ator tem responsabilidades adicionais. +Gerenciar avaliações: O administrador pode gerenciar as avaliações feitas pelos estudantes. Visando a segurança e a ética da aplicação. +Gerenciar contas de usuários: O administrador tem a capacidade de editar as informações de +usuários. Podendo e criar ou excluir contas, também visando a segurança e ética da aplicação. + ## **6.0 MVP** O Produto Mínimo Viável (MVP) para o nosso projeto é uma versão simplificada do sistema que inclui as funcionalidades essenciais para atender às necessidades básicas dos usuários. Para o nosso sistema, definimos o MVP da seguinte forma: diff --git a/docs/documentoArquitetura.md b/docs/documentoArquitetura.md index 3be107dd..450b66bf 100644 --- a/docs/documentoArquitetura.md +++ b/docs/documentoArquitetura.md @@ -1,24 +1,13 @@ -GamaTrack ![](Aspose.Words.2189e231-3b66-4f8b-89ae-efd262cf4a7e.001.png) +**Histórico de Revisão** -**Documento de Arquitetura** -Versão 1.0 - -**Histórico de Revisão** - - - -|Data** |Versão** |Descrição** |Autor(es)** | +|Data |Versão |Descrição |Autor(es) | | - | - | - | - | -|02/11/2023** |1\.0 |Versão inicial do documento |Eric Rabelo Nicollas Gabriel Isaque Colem Samuel Ribeiro Rodrigo Braz | -||||| -||||| -||||| -Autores: - +|02/11/2023 |1\.0 |Versão inicial do documento |Eric Rabelo; Nicollas Gabriel; Isaque Colem; Samuel Ribeiro; Rodrigo Braz | +Autores: -|Matrícula** |Nome** |Descrição do papel assumido na equipe** |% de contribuição ao trabalho | +|Matrícula |Nome |Descrição do papel assumido na equipe |% de contribuição ao trabalho | | - | - | :- | :- | |21/1030729 |Eric Rabelo |Desenvolvedor Frontend |20% | |22/1022300 |Isaque Colem |Desenvolvedor Frontend |20% | diff --git a/docs/documentoVisao.md b/docs/documentoVisao.md index 96b14140..d1ca9ca5 100644 --- a/docs/documentoVisao.md +++ b/docs/documentoVisao.md @@ -1,179 +1,281 @@ -## Histórico de Revisão +**Histórico de Revisão** -## 1.0 Visão do Produto e Projeto -### 1.1 Problema -- Contexto: Atualmente, os alunos da FGA enfrentam desafios ao fornecer e receber feedback sobre os professores de forma eficiente e anônima. -- Problema: Ineficácia na Avaliação e Seleção dos Professores Universitários da FGA. +|**Data** |**Versão** |**Descrição** |**Autor** | +| - | - | - | - | +|02/10/2023 |1\.0 |Início do Documento Visão. |Nicollas Gabriel; Samuel Ribeiro; Eric Rabelo; Isaque Colem; Rodrigo Braz | +|09/11/2023 |2\.0 |Aplicando alterações ao documento de acordo com a correção do professor Ricardo Ajax. |Nicollas Gabriel Samuel Ribeiro Eric Rabelo Isaque Colem Rodrigo Braz | - IMAGEM DO DIAGRAMA +## 1. **Visão do Produto e Projeto** +### 1.1 **Problema** +- **Contexto**: Atualmente, os alunos da FGA enfrentam desafios ao fornecer e receber feedback sobre os professores de forma eficiente e anônima. -- Solução de Software Proposta: Nosso software representa uma aplicação web que -oferece uma abordagem prática e em tempo real para avaliar e pesquisar os -professores da FGA. O propósito central desta ferramenta é criar um ambiente seguro -e anônimo onde estudantes, tanto novos quanto veteranos, possam compartilhar suas -opiniões sobre os professores e as disciplinas ministradas na Faculdade do Gama -(FGA). +- **Problema:** Como proporcionar aos estudantes da FGA um sistema eficaz que lhes permita avaliar e acessar avaliações de outros alunos sobre os professores, a fim de facilitar a escolha de suas disciplinas e professores de maneira informada e alinhada com suas preferências acadêmicas? -### 1.2 Declaração de Posição do Produto +![diagrama de ishikawa](/assets/DiagramaDeIshikawa.png) - TABELA VISAO DO PRODUTO +Imagem 1 - Diagrama de Ishikawa. -### 1.3 Objetivos do Produto +- **Solução de Software Proposta**: Nosso software representa uma aplicação web que oferece uma abordagem prática e em tempo real para pesquisar e avaliar os professores da FGA. A proposta nasce em um contexto de ineficácia da avaliação e consulta de outras avaliações dos docentes da FGA, como pode ser contemplado no diagrama de ishikawa acima. O propósito central desta ferramenta é criar um ambiente seguroe anônimo onde estudantes, tanto novos quanto veteranos, possam compartilhar suas opiniões sobre os professores e as disciplinas ministradas na Faculdade do Gama (FGA). -Desenvolver uma plataforma de avaliação de professores universitários que permita aos -estudantes da FGA avaliar de maneira prática e anônima os professores e suas respectivas -disciplinas. O principal foco é fornecer aos estudantes informações confiáveis para auxiliá-los -na seleção de professores e disciplinas que melhor atendam às suas necessidades acadêmicas. +### 1.2 **Declaração de Posição do Produto** -### 1.4 Tecnologias a Serem Utilizadas +Tabela 1 - Visão do Produto -**Ferramentas de Gerenciamento de Projeto:** +|Para: |Direcionado a todos os discentes das graduações da FGA (Faculdade do Gama). No entanto, sua validação será conduzida por um grupo de estudantes que não está matriculado na disciplina de 'Métodos de Desenvolvimento de Software'. | +| - | :- | +|Necessidade: |Ineficácia na avaliação e a consulta de avaliações dos docentes por discentes da FGA. | +|O (nome do produto): |GamaTrack. | +|Que: |O software visa auxiliar os discentes a selecionar os docentes que mais se adequam às suas preferências, permitindo-lhes avaliar os professores e consultar avaliações de outros alunos. Esse processo visa possibilitar aos estudantes uma escolha mais informada, contribuindo para que possam aproveitar ao máximo as disciplinas acadêmicas. | +|Ao contrário: |Das atuais abordagens para avaliação e pré-seleção de docentes por discentes para o curso de uma disciplina são limitadas, que geralmente envolvem grupos em redes sociais, onde a obtenção de informações é desafiadora e suscetível a comentários de qualquer pessoa, sem restrições. | +|Nosso produto: |Em contraste, oferece uma solução mais eficiente e confiável, centralizando todas as avaliações e informações dos docentes da FGA em uma plataforma dedicada, garantindo um acesso mais prático e confiável a tal informação. | -- GitHub: Utilizado para gerenciamento de código-fonte, controle de versão e -colaboração entre a equipe. -- Trello: Usado para organizar tarefas, criar listas de afazeres e acompanhar o progresso -do projeto. +### 1.3 **Objetivos do Produto** -- Teams: Uma plataforma de comunicação e colaboração que auxilia na comunicação da -equipe e reuniões virtuais. +Desenvolver uma plataforma de avaliação de professores universitários que permita aos estudantes da FGA avaliar de maneira prática e anônima os professores e suas respectivas disciplinas. O principal foco é fornecer aos estudantes informações confiáveis para auxiliá-los na seleção de professores e disciplinas que melhor atendam às suas necessidades acadêmicas. -**Frontend:** +### 1.4 **Tecnologias a Serem Utilizadas Ferramentas de Gerenciamento de Projeto:** +- **GitHub**: Utilizado para gerenciamento de código-fonte, controle de versão e colaboração entre a equipe. +- **Trello**: Usado para organizar tarefas, criar listas de afazeres e acompanhar o progresso do projeto. +- **Teams**: Uma plataforma de comunicação e colaboração que auxilia na comunicação da equipe e reuniões virtuais. -- React.js: Uma biblioteca JavaScript popular para a criação de interfaces de usuário -interativas e responsivas. -- Figma: Uma ferramenta de design de interface de usuário (UI) que permite criar -protótipos, designs e colaborar na criação da interface do usuário do seu aplicativo web. +**Frontend:** -**Backend:** +- **React.js**: Uma biblioteca JavaScript popular para a criação de interfaces de usuário interativas e responsivas. +- **Figma**: Uma ferramenta de design de interface de usuário (UI) que permite criar protótipos, designs e colaborar na criação da interface do usuário do seu aplicativo web. -- Node.js: Uma plataforma de tempo de execução JavaScript que permite o -desenvolvimento do lado do servidor. +**Backend:** -- Express.js: Um framework web Node.js que simplifica o desenvolvimento de -aplicativos web e APIs. +- **Node.js**: Uma plataforma de tempo de execução JavaScript que permite o desenvolvimento do lado do servidor. +- **Express.js**: Um framework web Node.js que simplifica o desenvolvimento de aplicativos web e APIs. +- **MongoDB**: Um sistema de gerenciamento de banco de dados NoSQL, que é escalável e adequado para armazenar dados flexíveis e não estruturados. -- MongoDB: Um sistema de gerenciamento de banco de dados NoSQL, que é escalável -e adequado para armazenar dados flexíveis e não estruturados. +## 2. **Visão Geral do Projeto** -## 2.0 Visão Geral do Produto +### 2.1 **Ciclo de vida do projeto de desenvolvimento de software** +- **Metodologia:** Visando a flexibilidade, a praticidade para colaboração e a otimização do tempo disponível, a abordagem filosófica será o uso de uma metodologia ágil, ideal para desenvolver este projeto de forma eficiente e eficaz, considerando a dinamicidade necessária para alinhar objetivos e reavaliar metas ao longo da matéria. Para tanto, o grupo optou por seguir os princípios do Scrum. De acordo com Audy (2015), o SCRUM é um framework ágil que enfatiza a colaboração, a adaptação a mudanças e a entrega de valor contínuo ao cliente. +- **Processo:** O processo de desenvolvimento de software adota uma abordagem híbrida, combinando o framework Scrum para a gestão do projeto com práticas técnicas do Extreme Programming (XP) para garantir a qualidade técnica do software (PMI, 2017). Iniciamos com a fase de iniciação, onde definimos o escopo do projeto e identificamos as partes interessadas. Durante essa fase, também criamos o Product Backlog, que lista os requisitos iniciais. À medida que avançamos para a fase de Planejamento da Sprint, selecionamos um conjunto de itens do Product Backlog para a próxima Sprint e definimos os objetivos da Sprint. Ao mesmo tempo, as práticas técnicas do XP, como pair programming e integração contínua, são adotadas durante o desenvolvimento. A equipe trabalha colaborativamente para produzir código de alta qualidade, enquanto a integração contínua garante que o software seja testado regularmente para identificar problemas precocemente. Ao final de cada Sprint, realizamos a Revisão da Sprint, onde o cliente fornece feedback sobre o trabalho concluído. +- **Procedimento:** O ciclo de vida ágil, escolhido pela equipe, envolve um conjunto de procedimentos para o desenvolvimento de projetos de forma iterativa e colaborativa. Ele inclui planejamento, priorização, desenvolvimento, revisão, feedback do cliente, adaptação, monitoramento, controle e encerramento. O procedimento central deste projeto envolverá as seguintes etapas: cadastro de alunos, armazenamento de dados relevantes e interação com os usuários. Essas ações serão realizadas ao longo das iterações do Scrum para garantir a entrega contínua de valor aos envolvidos. +- **Métodos:** Nossas atividades incluirão a realização de reuniões semanais para manter a equipe alinhada e promover a comunicação eficaz. Além disso, utilizaremos o planejamento de sprints para definir metas claras e prioridades para cada iteração do projeto. Para a organização eficaz das atividades da equipe, implementaremos um quadro Kanban, permitindo o acompanhamento visual do fluxo de trabalho e facilitando a gestão das tarefas em andamento. Além disso, para uma gestão mais eficiente e transparente das tarefas, todas as atividades serão listadas em formato de "issues" no repositório da equipe Pollux no GitHub, onde poderemos monitorar o progresso, atribuir responsabilidades e colaborar de forma mais eficaz. Essas práticas e métodos combinados contribuirão para a melhoria da organização e do gerenciamento de tarefas da equipe de desenvolvimento, promovendo uma abordagem ágil e eficiente em nosso processo de desenvolvimento de software. -### 2.1. Ciclo de vida do projeto de desenvolvimento de software +- **Ferramentas:** Para dar suporte ao desenvolvimento e gestão do projeto, serão utilizadas as seguintes ferramentas: ferramentas de desenvolvimento de código — Visual Studio Code com a extensão Live Share, a fim de possibilitar a prática de pair programming à distância sem grandes complicações e Insomnia, para realização dos testes de bancos de dados; ferramentas de organização de projeto (Trello e GitHub) e ferramentas de comunicação síncronas e assíncronas (Discord, Teams e WhatsApp). -- **Metodologia:** Visando a flexibilidade, a praticidade para colaboração e a otimização -do tempo disponível, a abordagem filosófica será o uso de métodos ágeis, ideal para -desenvolver este projeto de forma eficiente e eficaz, considerando a dinamicidade -necessária para alinhar objetivos e reavaliar metas ao longo do desenvolvimento do -produto. +### 2.2 **Organização do Projeto** -- **Processo:** O processo adotado seguirá as diretrizes e princípios do Scrum. O Scrum é -conhecido por suas iterações curtas, chamadas de "sprints", nas quais as tarefas são -planejadas, executadas e revisadas de forma colaborativa. +Tabela 2 – Tabela de Organização -- **Procedimento:** O procedimento central deste projeto envolverá as seguintes etapas: -cadastro de alunos, armazenamento de dados relevantes e interação com os usuários. -Essas ações serão realizadas ao longo das iterações do Scrum para garantir a entrega -contínua de valor aos envolvidos. +|***Papel*** |***Atribuições*** |***Responsável*** |***Participantes*** | +| - | - | - | - | +|Desenvolvedor |Codificação do produto, colaboração em equipe, aplicação de práticas técnicas e compromisso com os objetivos do produto.|*Todos os integrantes* |
Nicollas Gabriel Samuel Ribeiro Eric Rabelo Isaque Colem
Rodrigo Braz
| +|Dono do Produto |Atualizar o escopo do produto, organizar o escopo das sprints, validar as entregas |*Todos os integrantes* |Grupo seleto de estudantes da FGA não matriculados na disciplina. | +|Cliente |Fornecimento de requisitos e validação da aplicação. |*Todos os integrantes* |Estudantes da FGA. | -- **Métodos:** Incluirá a realização de reuniões semanais, planejamento de sprints, revisões -de sprint. Além disso, terão práticas como a priorização de backlog e quadro Kanban -para ajudar no processo. +### 2.3 **Planejamento das Fases e/ou Iterações do Projeto** -- **Ferramentas:** Para dar suporte ao desenvolvimento e gestão do projeto, serão -utilizadas as seguintes ferramentas: ferramentas de desenvolvimento de código, -ferramentas de organização de projeto (Trello), Ferramentas de comunicação (Discord -e Teams). +Tabela 3 – Planejamento e Sprint -### 2.2 Organização do Projeto -- TABELA DE ORGANIZAÇAO +| Sprint | Produto (Entrega) | Data Início | Data Fim | Entregáveis | Responsáveis | Conclusão | +| ------- | ---------------------------------------- | ----------- | --------- | --------------------------------------------------- | ------------ | --------- | +| Sprint 0 | Definição do produto. | 05/09/2023 | 12/09/2023 | Escolha do tema e definição do escopo do projeto. | Todos | 100% | +| Sprint 1 | Definição de tecnologias e treinamento das equipes. | 12/09/2023 | 19/09/2023 | Linguagens e frameworks identificados. Conhecimento básico da equipe nas tecnologias. | Todos | 100% | +| Sprint 2 | Protótipo de telas no Figma. | 19/09/2023 | 25/09/2023 | Todas as telas do software modeladas no Figma. | Todos | 100% | +| Sprint 3 | Codificação das telas Login e Cadastro. Criação do banco de dados. | 26/09/2023 | 03/10/2023 | Estrutura das telas de login e cadastro. | Todos | 100% | +| Sprint 4 | CRUD do usuário. Alimentar base de dados com professores. Lógica de autenticação. Início da documentação no MkDocs. | 03/10/2023 | 10/10/2023 | Sistema CRUD para usuários. Base de dados atualizada e populada com informações de professores. | Todos | 100% | +| Sprint 5 | Lógica de registro e cadastro do usuário. Desenvolvimento da página inicial. Integração do Front e Back no login e cadastro. Importar banco de dados no backend. | 10/10/2023 | 17/10/2023 | Implementação do sistema CRUD de usuários, base de dados atualizada com informações de professores, lógica de autenticação e início da documentação no MkDocs. | Todos | 100% | +| Sprint 6 | Otimizar conexão com banco de dados. Desenvolver barra de pesquisa para busca de professores. Melhorar usabilidade de login/cadastro. Implementar API para busca de professores. | 17/10/2023 | 24/10/2023 | Otimização da conexão com o banco de dados, criação da barra de pesquisa, aprimoramento da usabilidade no login/cadastro e implementação da API de busca de professores. | Todos | 75% | +| Sprint 7 | Desenvolver componente de card dos professores. Realizar webscraping para coleta de dados. Implementar API de dados dos professores. Implementar lógica de busca de professores no cliente. | 24/10/2023 | 31/10/2023 | Melhora na aparência da tela de busca. Complemento de informações para o banco de dados. Lógica de busca completa. | Todos | 100% | +| Sprint 8 | Desenvolver cabeçalho com informações do professor. Implementar redirecionamento após autenticação bem-sucedida. | 31/10/2023 | 07/11/2023 | Desenvolvimento da tela de perfil dos professores, melhora na autenticação e redirecionamento. | Todos | 100% | +| Sprint 9 | Criar pasta para registro de avaliações no banco de dados. Realizar cálculo de nota do professor no Backend. Implementar funcionalidade de avaliação. | 07/11/2023 | 14/11/2023 | Implementação de funcionalidades referentes à avaliação dos professores. | Todos | Em aberto | +| Sprint 10 | Implementar página de matérias filtrada pela engenharia. Implementar página de professores que lecionam cada matéria. | 14/11/2023 | 21/11/2023 | Implementação e melhorias em telas. | Todos | Em aberto | +| Sprint 11 | Realizar testes unitários na aplicação. Deploy da aplicação. | 21/11/2023 | 28/11/2023 | Teste da aplicação, correção e possíveis melhorias. | Todos | Em aberto | +| Sprint 12 | Realizar testes unitários na aplicação. Entrega do produto. | 28/11/2023 | 05/12/2023 | Teste da aplicação, correção e entrega. | Todos | Em aberto | -### 2.3 Planejamento das Fases e/ou Iterações do Projeto -### 2.4 Matriz de Comunicação +### 2.4 **Matriz de Comunicação** -### 2.5. Gerenciamento de Riscos +Tabela 4 – Comunicação do grupo -**Possíveis Riscos do Projeto** +| Descrição | Área/Envolvidos | Periodicidade | Produtos Gerados | +| ------------------------------------------------- | ---------------------- | ------------- | --------------------------------------------------- | +| - Acompanhamento das Atividades em Andamento | Equipe | Semanal | - Ata de reunião | +| | | | - Relatório de situação do projeto | +| | | | - Novas Atividades | +| | | | - Revisão | +| - Acompanhamento dos Riscos, Compromissos, Ações Pendentes, Indicadores | Equipe | Semanal | - Ata de reunião | +| | | | - Relatório de situação do projeto | +| - Comunicar situação do projeto | - Equipe | - Monitor | - Ata de reunião | +| | | | - Relatório de situação do projeto | -- Comentários falsos ou tendenciosos de estudantes podem prejudicar a qualidade da -avaliação dos professores. -- Não coletar feedbacks de usuários reais suficientes, resultando em problemas de -usabilidade. +### 2.5 **Gerenciamento de Riscos** -- Resistência pela parte dos professores: alguns educadores podem não gostar da -implementação e de ter seu nome exposto. +**Comentários falsos ou tendenciosos de estudantes:** Este risco pode ser crítico, pois pode afetar diretamente a qualidade da avaliação dos professores e prejudicar a credibilidade do sistema. -- Integração Complexa: a integração dos diferentes componentes pode apresentar -problemas técnicos. +- Mitigação: Implementar ferramentas de detecção de comentários falsos ou tendenciosos e incentivar a moderação de conteúdo. +- Contingência: Implementar um sistema de denúncia e eliminação de comentários. -- Falhas no design de segurança podem expor dados dos alunos. +**Falhas no design de segurança**: A exposição de dados dos alunos é um risco significativo, já que a segurança dos dados é uma preocupação fundamental em sistemas educacionais. -### 2.6. Critérios de Replanejamento +- Mitigação: Realizar uma avaliação rigorosa da segurança do sistema, implementar práticas de criptografia e controle de acesso. +- Contingência: Ter planos de resposta a incidentes em vigor e notificar imediatamente as partes afetadas em caso de violação de segurança. -- Mudanças nos Requisitos : Se houver mudanças nos requisitos do projeto que -impactem o escopo, prazo ou recursos necessários, terá que ter um replanejamento para -ajustar o projeto de acordo com as novas especificações. +**Não coletar feedbacks de usuários reais suficientes:** A usabilidade é importante, mas este risco pode ser gerenciado de forma mais flexível, coletando feedback ao longo do tempo e ajustando o sistema conforme necessário. -- Riscos do Projeto: Os critérios de replanejamento estarão fortemente associados aos -riscos identificados no projeto. Se um risco se materializar ou se tornar mais provável, -o replanejamento será necessário para diminuir seus impactos e manter o projeto no -caminho certo. +- Mitigação: Implementar uma estratégia de coleta de feedback ativa e incentivadora para os usuários. +- Contingência: Realizar testes de usabilidade frequentes e ajustes iterativos com base no feedback disponível. -- Atrasos: Se o projeto sofrer atrasos que possam comprometer o cronograma, será -necessário replanejar para reavaliar e ajustar as datas de entrega +**Integração Complexa:** Problemas técnicos na integração podem atrasar o projeto, mas podem ser mitigados por meio de testes rigorosos e planejamento adequado. -## 3.0 Processo de Desenvolvimento de Software +- Mitigação: Realizar testes rigorosos de integração durante o desenvolvimento e envolver especialistas técnicos na resolução de problemas. +- Contingência: Ter um plano de contingência para lidar com atrasos na integração e manter as partes interessadas informadas sobre quaisquer impactos no cronograma. -A equipe optou pela metodologia ágil SRUM, que se baseia em princípios de transparência, -colaboração e adaptação contínua para entregar produtos de alta qualidade de maneira -eficiente. +**Resistência pela parte dos professores:** Embora seja um risco, a resistência pode ser gerenciada por meio de treinamento, comunicação eficaz e envolvimento dos educadores no processo de implementação. -**Papéis:** +- Mitigação: Envolver os professores no processo de planejamento e comunicar os benefícios da implementação do sistema. +- Contingência: Estabelecer um plano de comunicação eficaz para lidar com a resistência, oferecendo suporte contínuo. -- Scrum Master: Responsável por garantir que a equipe siga os princípios do Scrum, -remove impedimentos e facilita a colaboração. +### 2.6 **Critérios de Replanejamento** +- Mudanças nos Requisitos: Se houver mudanças nos requisitos do projeto que impactem + - escopo, prazo ou recursos necessários, deverá ser replanejado paraajustar o projeto de acordo com as novas especificações. +- Riscos do Projeto: Os critérios de replanejamento estarão fortemente associados aos riscos identificados no projeto. Se um risco se materializar ou se tornar mais provável, + - replanejamento será necessário para diminuir seus impactos e manter o projeto no caminho certo. De acordo com a definição de prioridades da equipe (Segurança > Usabilidade > Interface), em caso de risco à segurança da aplicação como todo, o replanejamento deverá ser feito imediatamente e a solução tratada como prioridade máxima; casos de usabilidade serão encarados de acordo com seu grau de importância para que o MVP seja alcançado e tratados, em primeiro momento, como débito técnico, + - que pode evoluir para um replanejamento caso o tempo estimado para contenção do risco ultrapasse a duração total de 1 (uma) sprint (7 dias). Riscos de interface serão tratados como débito técnico e serão resolvidos sem necessidade de replanejamento. +- Atrasos: Se o projeto sofrer atrasos que possam comprometer o cronograma, será necessário replanejar para reavaliar e ajustar as datas de entrega. +## 3.0 **Processo de desenvolvimento de Software** -- Product Owner: Representa os interesses dos stakeholders, define as prioridades do -backlog e toma decisões sobre o produto. +A equipe de desenvolvimento de software optou por adotar uma abordagem híbrida, estruturando seu processo por meio da combinação do framework Scrum, que oferece diretrizes sólidas para a gestão do projeto, com práticas técnicas do Extreme Programming (XP), que visam garantir a mais alta qualidade técnica do software. Essa escolha baseia-se nas melhores práticas definidas pelo Project Management Institute (PMI) no seu renomado Guia PMBOK® (2017), e busca otimizar o desenvolvimento do projeto, assegurando a eficiência na gestão e a excelência na execução técnica. -- Equipe de Desenvolvimento: Responsável por criar o produto de acordo com as -prioridades estabelecidas. +Dessa forma, o Scrum fornece a estrutura ideal para o planejamento, acompanhamento e entrega das metas do projeto, enquanto as práticas técnicas do XP, tais como pair programming e integração contínua, são adotadas para garantir que o software seja desenvolvido e testado com o mais alto padrão de qualidade técnica. O resultado é um processo que une a agilidade e a disciplina necessárias para atingir os objetivos do projeto, alinhados com as diretrizes do PMI. -**Reuniões:** +**Papéis:** -- Periódicas: A equipe decidiu optou por realizar minirreuniões durante o decorrer da -sprint para acompanhar o progresso do grupo nas atividades e tratar possíveis -obstáculos. +- **Scrum Master**: Responsável por garantir que a equipe siga os princípios do Scrum, remove impedimentos e facilita a colaboração. +- **Product Owner**: Representa os interesses dos stakeholders, define as prioridades do backlog e toma decisões sobre o produto. +- **Equipe de Desenvolvimento**: Responsável por criar o produto de acordo com as prioridades estabelecidas. -- Sprint Review: Ao final de cada sprint, é realizada uma reunião para formalizar as -entregas e compreender. +**Reuniões:** -## 4.0 Detalhamento de Atividades do Projeto +- **Periódicas**: A equipe decidiu optou por realizar minirreuniões durante o decorrer da sprint para acompanhar o progresso do grupo nas atividades e tratar possíveis obstáculos. +- **Sprint Review:** Ao final de cada sprint, é realizada uma reunião para formalizar as entregas e compreender possíveis atrasos. Após essa etapa, planejamos as atividades para a próxima sprint. +## 4.0 **Detalhamento de atividades do projeto** - TODAS AS SPRINTS +### 4.1 **Sprint 0** +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Definição do produto. |SCRUM/XP |Teams |12/09 | -## 5.0 Lições Aprendidas +### 4.2 **Sprint 1** -### 5.1. Unidade 1 -Acompanhamento Regular: Realize reuniões de acompanhamento diárias ou regulares -para verificar o progresso das tarefas da sprint. Isso ajuda a identificar atrasos com -antecedência. +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Definir tecnologias. |SCRUM /XP |Teams |19/09 | +|Treinamento das equipes. |SCRUM /XP |Teams |19/09 | -### 5.2. Unidade 2 -Comunicação Efetiva: Promova uma comunicação aberta e transparente dentro da -equipe. Isso inclui relatar prontamente qualquer obstáculo ou problema que possa -afetar o andamento do projeto. +### 4.3 **Sprint 2** -### 5.3. Unidade 3 -Durante o desenvolvimento da parte do back-end de nosso aplicativo, encontramos -vários desafios, sendo o principal deles relacionado à implementação do banco de -dados MongoDB e às operações CRUD relacionadas ao sistema de login. -### 5.4. Unidade 4 -Durante o desenvolvimento do projeto React, uma das principais dificuldades que -enfrentamos foi a configuração das rotas entre as diferentes páginas do aplicativo -utilizando a biblioteca React Router. +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Prototipação das telas. |SCRUM /XP |Figma; Teams |26/09 | -## 6.0 Próximos Passos \ No newline at end of file +### 4.4 **Sprint 3** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Prototipação das telas |SCRUM /XP |Figma; Teams. |26/09 | +|Codificar tela de login |SCRUM /XP |Visual Studio Code; React; Teams. |03/10 | +|Codificar tela de cadastro |SCRUM /XP |Visual Studio Code; React; Teams. |03/10 | +|Criar banco de dados |SCRUM /XP |Visual Studio Code; MongoDB; Teams. |03/10 | +|Criar API |SCRUM /XP |Visual Studio Code; Node.js; Express; Teams. |03/10 | + +### 4.5 **Sprint 4** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Criar CRUD de usuário|SCRUM /XP |Visual Studio Code; MongoDB; Express; Node.js; Teams. |10/10| +|Alimentar DB de professores |SCRUM /XP |Visual Studio Code; MongoDB; Express; Node.js; Teams. |10/10| +|Implementar autenticação de usuário|SCRUM /XP |Visual Studio Code; React; MongoDB; Express; Node.js; Teams. |10/10| +|Iniciar documentação no MkDocs |SCRUM /XP |Visual Studio Code; Teams. |10/10| + +### 4.6 **Sprint 5** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Implementar registro de usuário |SCRUM /XP |Visual Studio Code; React; MongoDB; Express; Node.js; Teams. |17/10 | +|Integração Backend-Frontend |SCRUM /XP |Visual Studio Code; React; MongoDB; Express; Node.js; Teams. |17/10 | +|Implementar tela inicial |SCRUM /XP |Visual Studio Code; React; Teams. |17/10 | + +### 4.7 **Sprint 6** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Otimizar conexão com o banco de dados|SCRUM /XP |Visual Studio Code; React; Teams. |24/10 | +|Implementar API de professores |SCRUM /XP |Visual Studio Code; React; Teams. |24/10 | + +### 4.8 **Sprint 7** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Implementar API que fornece dados dos professores para o front end. |SCRUM /XP |Visual Studio Code; React; Teams. |31/10 | +|Implementar logica de busca de professores pelo lado do cliente. |SCRUM /XP |Visual Studio Code; React; Teams. |31/10 | + +### 4.9 **Sprint 8** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Implementar funcionalidade de redirecionamento. |SCRUM /XP |Visual Studio Code; React; Teams. |07/11 | + +### 4.10 **Sprint 9** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Realizar lógica de cálculo da nota do professor no Backend.|SCRUM /XP |Visual Studio Code; React; Teams. |14/11 | +|Implementar funcionalidade de avaliação dos professores. |SCRUM /XP |Visual Studio Code; React; Teams. |14/11 | + +### 4.11 **Sprint 10** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Implementar página de matérias filtrada pela engenharia.|SCRUM /XP |Visual Studio Code; React; Teams. |21/11 | +|Implementar página de professores que lecionam cada matéria. |SCRUM /XP |Visual Studio Code; React; Teams. |21/11 | + +### 4.12 **Sprint 11** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Realizar teste unitários na aplicação. |SCRUM /XP |Visual Studio Code; jasmine; Teams. |28/11 | +|Deploy da aplicação. |SCRUM /XP |Visual Studio Code; GitHub; Teams. |28/11 | + +### 4.13 **Sprint 12** + +|***Atividade*** |***Método*** |***Ferramenta*** |***Entrega*** | +| - | - | - | - | +|Realizar testes unitários na aplicação. |SCRUM /XP |Visual Studio Code; jasmine; Teams. |05/11 | +|Entrega do produto |SCRUM /XP |Visual Studio Code; GitHub; Teams. |05/11 | + + +## 5.0 **Lições Aprendidas** +### 5.1 **Unidade 1** + +Acompanhamento Regular: Realize reuniões de acompanhamento diárias ou regulares para verificar o progresso das tarefas da sprint. Isso ajuda a identificar atrasos com antecedência. + +### 5.2 **Unidade 2** + +Comunicação Efetiva: Promova uma comunicação aberta e transparente dentro da equipe. Isso inclui relatar prontamente qualquer obstáculo ou problema que possa afetar o andamento do projeto. + +### 5.3 **Unidade 3** + +Durante o desenvolvimento da parte do back-end de nosso aplicativo, encontramos vários desafios, sendo o principal deles relacionado à implementação do banco de dados MongoDB e às operações CRUD relacionadas ao sistema de login + +### 5.4 **Unidade 4** + +Durante o desenvolvimento do projeto React, uma das principais dificuldades que enfrentamos foi a configuração das rotas entre as diferentes páginas do aplicativo utilizando a biblioteca React Router. + +## 6.0 **Próximos Passos** + +## 7.0 **Referências Bibliográficas** + +PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia do Conhecimento em Gerenciamento de Projetos. 6. ed. Newtown Square, Pensilvânia: PMI, 2017. + +Audy, Jorge. Scrum 360: Um guia completo e prático de agilidade. São Paulo: Casa do Código, 2015. diff --git a/docs/index.md b/docs/index.md index c6e4a993..634305f0 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,4 +1,4 @@ -# Pollux +# GamaTrack Nosso software representa uma aplicação web que oferece uma abordagem prática e em tempo real para avaliar e pesquisar os diff --git a/docs/sprints.md b/docs/sprints.md index 1870737e..28e8d3d5 100644 --- a/docs/sprints.md +++ b/docs/sprints.md @@ -7,4 +7,4 @@ - [*Sprint 6*](./sprints/sprint6.md) - [*Sprint 7*](./sprints/sprint7.md) - [*Sprint 8*](./sprints/sprint8.md) - +- [*Sprint 9*](./sprints/sprint9.md) diff --git a/docs/sprints/sprint8.md b/docs/sprints/sprint8.md index 32c182a6..3774080e 100644 --- a/docs/sprints/sprint8.md +++ b/docs/sprints/sprint8.md @@ -1,4 +1,4 @@ -# **Planning da Sprint 7** +# **Planning da Sprint 8** - **Período:** 31/10/2023 a 07/11/2023 - **Objetivo:** @@ -7,6 +7,10 @@ ## **Issues** +|Atividade|Histórias de Usuário Envolvidas|Descrição|Responsáveis|Status da Entrega| +|:----:|:----------:|:----------:|:------:|:--:| +|#1| | Desenvolver cabeçalho com informações do professor| Eric e Isaque | Ok | +|#2|US-05, US-07, US-08, US-10| Implementar funcionalidade de redirecionamento para a aplicação após autenticação de usuário bem sucedida| Eric, Isaque, Nicollas, Samuel e Rodrigo | Ok | ## **Review das Atividades** diff --git a/docs/sprints/sprint9.md b/docs/sprints/sprint9.md new file mode 100644 index 00000000..60333fbb --- /dev/null +++ b/docs/sprints/sprint9.md @@ -0,0 +1,21 @@ +# **Planning da Sprint 9** + +- **Período:** 31/10/2023 a 07/11/2023 +- **Objetivo:** + +--- + +## **Issues** + +|Atividade|Histórias de Usuário Envolvidas|Descrição|Responsáveis|Status da Entrega| +|:----:|:----------:|:----------:|:------:|:--:| +|#1| | Criar para registro de avaliações separadas no banco de dados| Eric e Isaque | Ok | +|#2|US-05, US-07, US-08, US-10| Implementar funcionalidade de redirecionamento para a aplicação após autenticação de usuário bem sucedida| Eric, Isaque, Nicollas, Samuel e Rodrigo | Ok | + + +## **Review das Atividades** + +--- + +### **Atividade #1** + diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css index e72e3467..00376e10 100644 --- a/docs/stylesheets/extra.css +++ b/docs/stylesheets/extra.css @@ -1,6 +1,16 @@ [data-md-color-scheme="jungle"] { - --md-primary-fg-color: #007D30; /* Verde Selva */ - --md-primary-fg-color--light: #8BCC9E; /* Tom mais claro de Verde Selva */ - --md-primary-fg-color--dark: #00511E; /* Tom mais escuro de Verde Selva */ - } - \ No newline at end of file + --md-primary-fg-color: #007D30; /* Verde Selva */ + --md-primary-fg-color--light: #8BCC9E; /* Tom mais claro de Verde Selva */ + --md-primary-fg-color--dark: #00511E; /* Tom mais escuro de Verde Selva */ + --md-background-color: #FFFFFF; /* Background color for light mode */ + --md-background-color--dark: #222222; /* Background color for dark mode */ +} + +[data-md-color-scheme="jungle-dark"] { + --md-primary-fg-color: #007D30; /* Verde Selva */ + --md-primary-fg-color--light: #8BCC9E; /* Tom mais claro de Verde Selva */ + --md-primary-fg-color--dark: #00511E; /* Tom mais escuro de Verde Selva */ + --md-background-color: #222222; /* Background color for dark mode */ + --md-background-color--light: #FFFFFF; /* Background color for light mode */ +} + diff --git a/mkdocs.yml b/mkdocs.yml index 5be7e977..7d9f9619 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,4 +1,4 @@ -site_name: Pollux | MDS +site_name: Pollux | GamaTrack repo_name: "2023-2-Pollux" repo_url: "https://github.com/FGA0138-MDS-Ajax/2023-2-POLLUX" @@ -16,7 +16,7 @@ theme: - content.tabs.link - content.code.annotation - content.code.copy - + language: pt font: @@ -24,20 +24,17 @@ theme: code: "sans-serif" palette: - - scheme: default + - scheme: default toggle: - icon: material/toggle-switch-off-outline + icon: material/toggle-switch-off-outline name: Switch to dark mode - primary: red - accent: indigo + primary: lime - scheme: slate toggle: icon: material/toggle-switch - name: Switch to light mode - primary: red - accent: indigo - + name: Switch to light mode + primary: lime extra_css: - stylesheets/extra.css