Merge pull request #2 from mdsreq-fga-unb/feat/docs

docs: adiciona documentação

.github/workflows/docs.yml

@@ -0,0 +1,28 @@
+name: docs 
+on:
+  push:
+    branches:
+      - main
+permissions:
+  contents: write
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Configure Git Credentials
+        run: |
+          git config user.name github-actions[bot]
+          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV 
+      - uses: actions/cache@v4
+        with:
+          key: mkdocs-material-${{ env.cache_id }}
+          path: .cache
+          restore-keys: |
+            mkdocs-material-
+      - run: pip install mkdocs-material 
+      - run: mkdocs gh-deploy --force

docs/index.md

@@ -0,0 +1,44 @@
+# Início
+
+## Projeto
+
+Este projeto é parte da disciplina de Requisitos de Software, orientada pelo professor Dr. George Marsicano Corrêa, do curso de Engenharia de Software da Universidade de Brasília.
+
+O objetivo deste projeto é desenvolver uma solução de software utilizando a Engenharia de Requisitos, com foco nas técnicas de elicitação, análise, especificação e validação de requisitos, além da entrega de um produto de software que atenda às necessidades do cliente.
+
+## A Ideia Space 🚀
+
+A [Ideia Space](https://www.ideiaspace.com.br/) é uma startup brasileira de educação que tem como objetivo melhorar a qualidade do ensino, especialmente nas áreas de STEAM (Ciência, Tecnologia, Engenharia, Artes e Matemática). Sua proposta é utilizar o fascínio pelo espaço como tema central para envolver e capacitar os alunos em projetos que estimulam a criatividade e a resolução de problemas.
+
+Portanto, para este projeto, a Ideia Space é o cliente que necessita de uma solução de software capaz de criar uma experiência de aprendizado gamificada, associado à obtenção de métricas de desempenho dos alunos, para que possa avaliar a eficácia de seus métodos de ensino, associado ao engajamento dos alunos.
+
+## Equipe
+
+<div style="display: flex; justify-content: center; gap: 20px; flex-wrap: wrap; width: 80%; margin: 0 auto;">
+
+<div style="text-align: center;">
+    <a href="https://github.com/caio-felipee" target="_blank"><img src="https://github.com/caio-felipee.png" width="100" style="border-radius: 50%; margin: 5px 20px 5px 20px;"/></a>
+    <p style="margin: 0 0 0 0"><strong>Caio Felipe</strong></p>
+</div>
+
+<div style="text-align: center;">
+    <a href="https://github.com/Edilson-r-jr" target="_blank"><img src="https://github.com/Edilson-r-jr.png" width="100" style="border-radius: 50%; margin: 5px 20px 5px 20px;"/> </a>
+    <p style="margin: 0 0 0 0"><strong>Edilson Ribeiro</strong></p>
+    <p style="color: gray; margin: 0 0;">Líder</p>
+</div>
+
+<div style="text-align: center;">
+    <a href="https://github.com/femathrl" target="_blank"><img src="https://github.com/femathrl.png" width="100" style="border-radius: 50%; margin: 5px 20px 5px 20px;"/></a>
+    <p style="margin: 0 0 0 0"><strong>Felipe Matheus</strong></p>
+</div>
+
+<div style="text-align: center;">
+    <a href="https://github.com/IgorSPaiva" target="_blank"><img src="https://github.com/IgorSPaiva.png" width="100" style="border-radius: 50%; margin: 5px 20px 5px 20px;"/></a>
+    <p style="margin: 0 0 0 0"><strong>Igor Silva</strong></p>
+</div>
+
+<div style="text-align: center;">
+    <a href="https://github.com/Matheussbrant" target="_blank"><img src="https://github.com/Matheussbrant.png" width="100" style="border-radius: 50%; margin: 5px 20px 5px 20px;"/></a>
+    <p style="margin: 0 0 0 0"><strong>Matheus Brant</strong></p>
+</div>
+</div>

docs/interação/composição.md

@@ -0,0 +1,42 @@
+# Interação entre Equipe e Cliente
+
+## Composição da Equipe
+
+| Papel                  | Descrição                                                                                                                             | Responsável     | Participantes   |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------- | --------------- |
+| Gerente do Projeto     | Assegura a comunicação eficaz entre o cliente e a equipe, monitora prazos e gerencia as entregas para manter o projeto no cronograma. | Edilson Ribeiro |                 |
+| Desenvolvedor Frontend | Cuida do design e da implementação das funcionalidades no front-end, garantindo uma experiência de usuário intuitiva e atraente.      | Matheus Brant   | Igor Silva      |
+| Desenvolvedor Backend  | Realiza a integração com o banco de dados e APIs, garantindo que os processos internos e fluxos de dados funcionem corretamente.      | Caio Felipe     |                 |
+| Analista QA            | Conduz testes de funcionalidade, desempenho e usabilidade para assegurar que o produto atenda aos padrões exigidos.                   | Igor Silva      |                 |
+| Analista de Requisitos | Estabelece os requisitos funcionais e não funcionais e assegura sua implementação conforme planejado.                                 | Felipe Matheus  | Edilson Ribeiro |
+
+## Comunicação
+
+- **Telegram**: Utilizado para a comunicação diária entre os membros da equipe, permitindo o envio rápido de mensagens, compartilhamento de arquivos e criação de grupos específicos para discussões sobre funcionalidades, bugs ou tarefas. Também será uma ferramenta eficaz para interações rápidas com o cliente, garantindo uma comunicação fluida e contínua.
+- **Microsoft Teams**: As reuniões semanais de revisão e planejamento de sprints com o cliente serão realizadas por videoconferência no Microsoft Teams. Essas reuniões permitirão validar as entregas, coletar feedback e discutir as atividades planejadas para o próximo sprint, mantendo a equipe e o cliente alinhados quanto ao progresso e necessidades do projeto.
+
+- **Trello**: Ferramenta para gerenciamento do backlog, controle de tarefas e acompanhamento do progresso de cada sprint. Ele permitirá que tanto a equipe quanto o cliente visualizem o andamento do projeto em quadros organizados e participem ativamente do processo de priorização das funcionalidades, mantendo o fluxo de trabalho organizado e transparente.
+
+## Métodos e Frequência de Reuniões
+
+- **Reuniões Diárias (Daily Scrum)**: A equipe de desenvolvimento realizará reuniões diárias de 15 minutos (via Telegram) para discutir o progresso de cada membro, os obstáculos e as prioridades do dia. Essas reuniões garantirão que todos estejam cientes do andamento do projeto e possam resolver rapidamente problemas que possam surgir.
+
+- **Reunião de Revisão de Sprint (a cada 2 semanas)**: Ao final de cada sprint (a cada 2 semanas), haverá uma reunião de revisão com o cliente. Nessas reuniões, a equipe apresentará as funcionalidades desenvolvidas, permitirá que o cliente as teste e coletará feedback para ajustar o backlog, se necessário.
+
+- **Reunião de Planejamento de Sprint**: Após a reunião de revisão, a equipe e o cliente se reunirão para planejar o próximo sprint, revisando o backlog e definindo as prioridades de acordo com o feedback do cliente.
+
+- **Reunião de Retrospectiva**: Será realizada uma retrospectiva a cada final de sprint, onde a equipe discutirá o que funcionou bem, o que pode ser melhorado e as lições aprendidas no ciclo anterior, garantindo a melhoria contínua no processo.
+
+### Frequência de Interações com o Cliente
+
+- **Revisões de Sprint (a cada 2 semanas)**: O cliente estará diretamente envolvido nas revisões de sprint a cada 2 semanas, onde poderá validar as entregas e fornecer feedback.
+
+## Processo de Validação
+
+O processo de validação da solução será realizado em três etapas principais:
+
+1. **Definition of Ready (DoR)**: Para iniciar o desenvolvimento de uma funcionalidade, o DoR será utilizado, verificando se os requisitos estão claramente definidos, se há documentação e se todos os critérios de aceitação estão estabelecidos.
+
+2. **Definition of Done (DoD)**: A funcionalidade será considerada pronta apenas se passar pelos testes unitários, integração, e houver aprovação visual e funcional pelos membros da equipe e pelo cliente.
+
+3. **Testes de Aceitação pelo Cliente**: Após a validação interna, o produto será entregue ao cliente para testes de aceitação. Durante essa fase, o cliente irá verificar se o sistema atende aos requisitos estabelecidos. Cada funcionalidade será validada com base nos critérios de aceitação definidos durante o DoR.

docs/produto/cronograma-entregas.md

@@ -0,0 +1,20 @@
+## CRONOGRAMA E ENTREGAS
+
+| Sprint     | Início       | Fim         | Objetivo Principal                        | Entregas Esperadas                                                                                                                                                 | Validação do Cliente                                  |
+|------------|--------------|-------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------|
+| Sprint 1   | 14/11/2024   | 27/11/2024  | Planejamento e Definição de Backlog       | - Definição do backlog inicial <br> - Configuração da arquitetura (React, FastAPI, MongoDB) <br> - Ambiente de desenvolvimento configurado                        | Revisão do backlog e confirmação de prioridade       |
+| Sprint 2   | 28/11/2024   | 11/12/2024  | Implementação do Sistema de Cadastro e Autenticação | - Entrega Parcial 1: <br> - Desenvolvimento do sistema de cadastro e autenticação de usuários <br> - Testes de segurança e fluxo de login | Validação do sistema de autenticação e ajuste de fluxo |
+| Sprint 3   | 12/12/2024   | 25/12/2024  | Implementação do Sistema de Perguntas e Respostas | - Criação de um sistema básico de perguntas e respostas <br> - Testes de funcionalidade para coleta de resposta                                                  | Feedback sobre usabilidade e ajustes nas perguntas   |
+| Sprint 4   | 26/12/2024   | 08/01/2025  | Implementação da Gamificação              | - Entrega Parcial 2: <br> - Implementação de mecânicas de gamificação <br> - Funcionalidades de pontuação e recompensas para engajamento dos alunos               | Feedback sobre motivação e ajustes nas mecânicas de gamificação |
+| Sprint 5   | 09/01/2025   | 22/01/2025  | Implementação da Análise de Dados         | - Coleta e análise das respostas dos alunos <br> - Desenvolvimento de relatórios para professores e educadores                                                    | Validação das análises e feedback sobre a utilidade dos dados |
+| Sprint 6   | 23/01/2025   | 05/02/2025  | Integração Completa e Personalização      | - Entrega Parcial 3: <br> - Integração das funcionalidades principais (autenticação, perguntas, gamificação e análise de dados) <br> - Ajustes finais de interface e personalização para cada usuário | Validação do sistema integrado e feedback sobre experiência do usuário |
+| Sprint 7   | 06/02/2025   | 12/02/2025  | Testes de Segurança e Homologação         | - Testes de segurança finais, revisão de vulnerabilidades, homologação                                                                                          | Feedback sobre estabilidade e segurança              |
+| Sprint 8   | 13/02/2025   | 18/02/2025  | Lançamento e Monitoramento               | - Lançamento final da plataforma para usuários selecionados <br> - Monitoramento inicial e coleta de feedbacks                                                  | Ajustes finais com base no feedback dos usuários     |
+
+---
+
+### Considerações Importantes
+
+- **Datas de Início e Fim**: Cada sprint tem duração de duas semanas, com exceção das últimas duas, iniciando em 14/11/2024 e terminando em 18/02/2025.
+- **Validações**: Cada sprint inclui uma revisão de entregas com o cliente para feedback contínuo e ajustes no backlog.
+- **Entregas Parciais**: Entregas das funcionalidades principais, como integração de conteúdo, gamificação e análise dos dados, são distribuídas ao longo do projeto para garantir uma validação contínua antes do lançamento final.

docs/produto/estrategias.md

@@ -0,0 +1,38 @@
+## Estratégias de Engenharia de Software
+
+### Estratégia Priorizada
+
+**Abordagem**: Ágil
+
+**Ciclo de Vida**: Incremental e Iterativo
+
+**Processo**: ScrumXP
+
+
+### Quadro Comparativo
+
+O quadro a seguir, apresenta algumas características relacionadas ao RAD e ao ScrumXP, visando auxiliar no entendimento e justificativa da escolha do processo mais adequado ao caso da Ideia Space.
+
+| 	Características 	|	 RAD	 |	ScrumXP	|
+|---|---|---| 
+|	**Abordagem Geral** | Iterativo e incremental orientado à prototipagem e adaptação.|Iterativo e incremental com foco em entregas rápidas e feedback contínuo.
+|**Foco em Arquitetura**|	Arquitetura básica e flexível que pode ser rapidamente adaptada. A estrutura arquitetural inicial tende a ser simples, permitindo ajustes conforme as necessidades surgem ao longo do desenvolvimento. |	Arquitetura que evolui gradualmente, adaptando-se ao longo dos sprints. O foco é garantir uma estrutura flexível que responda às mudanças sem precisar de uma definição completa logo no início.
+|**Estrutura de Processos**|	Organiza o processo em fases rápidas: planejamento, design, construção e implementação. Visa colocar uma versão funcional do produto nas mãos dos usuários o quanto antes.|Estruturado em sprints de 2-4 semanas, com entregas incrementais e feedback contínuo.|
+|**Flexibilidade de Requisitos**|	Permite alterações de requisitos rapidamente entre as fases, adaptando-se ao feedback dos usuários e às mudanças de demanda sem um processo rígido de controle de escopo.|	Alta flexibilidade, permitindo mudanças de requisitos a cada sprint com base no feedback obtido.|
+|**Colaboração com Cliente**| O cliente é envolvido diretamente em cada fase de prototipagem, revisando as versões iniciais do produto e fornecendo feedback para orientar melhorias e ajustes imediatos.	|	Envolve o cliente continuamente, buscando seu feedback ao final de cada sprint para garantir que o produto evolua conforme as expectativas e necessidades.
+|**Complexidade do Processo** |Simples e rápido, com foco na prototipagem e na entrega de resultados visíveis em menor tempo. Reduz etapas complexas de planejamento e documentação. |Leve e ágil, com foco na entrega funcional e menos foco na documentação formal. Papéis e etapas bem definidos, facilitando a adaptação e o gerenciamento de tarefas.
+|**Qualidade Técnica** |A velocidade do RAD pode resultar em uma menor atenção inicial à qualidade técnica. A prioridade está em alcançar rapidamente uma versão funcional, e revisões de qualidade são feitas posteriormente.|Inclui práticas de qualidade como TDD (Test-Driven Development), integração contínua e pair programming, que garantem um código limpo e funcional.
+|**Práticas de Desenvolvimento**| A prototipagem rápida é o foco central, com práticas de desenvolvimento centradas em construir versões funcionais e viáveis, visando adaptações e melhorias ágeis durante o processo. |Inclui práticas técnicas robustas como TDD, refatoração contínua, integração contínua e pair programming,promovendo alta qualidade no código.
+|**Adaptação ao Projeto da Ideia Space**| Ideal para projetos que precisam de uma primeira versão rápida e visualizável para validação inicial, ideal para um ambiente em que o feedback imediato pode acelerar decisões de produto.|Ideal para projetos que exigem interação e adaptação contínuas, pois permite responder a mudanças de forma rápida, mantendo o cliente envolvido em cada ciclo de desenvolvimento.
+|**Documentação**|Documentação leve, com pouca estrutura formal, priorizando rapidez.|Documentação mínima e essencial, focada em comunicação ágil e feedback.
+|**Controle de Qualidade**|Feito após a prototipagem inicial. A ênfase é em revisar o produto após cada fase, possibilitando ajustes incrementais para refinar a qualidade conforme necessário.| Controle de qualidade embutido nas práticas do XP e em revisões em cada sprint, garantindo que o software seja testado a cada nova funcionalidade.|
+**Escalabilidade**|Mais adequado para equipes pequenas e projetos de menor escala, onde uma coordenação mais leve e rápida é viável. |Escalável, mas mais indicado para equipes menores e médias devido à sua abordagem colaborativa e interativa constante.
+|**Suporte a Equipes de Desenvolvimento**|Funciona bem em equipes pequenas, com desenvolvedores envolvidos diretamente nas fases rápidas de prototipagem. Não há papéis definidos formalmente, incentivando uma estrutura de trabalho colaborativa e ágil.|Suporta equipes menores e mais colaborativas, com papéis mais flexíveis, permitindo maior adaptação ao ritmo do projeto.
+
+### Justificativa
+
+-   **Maior Escalabilidade**: ScrumXP é mais adequado para equipes com projetos em crescimento. Ele possui papéis e processos bem definidos que permitem uma expansão maior do projeto. RAD, por outro lado, tende a se ajustar melhor a projetos pequenos, fazendo com que a sua expansão seja limitada .
+
+-   **Maior Flexibilidade nos Requisitos**: ScrumXP permite revisões e ajustes de requisitos a cada sprint, essencial para um projeto que precisa se adaptar rapidamente ao feedback e às demandas do cliente. RAD, por focar em protótipos rápidos, pode não acompanhar mudanças frequentes no mesmo nível de detalhe.
+
+-   **Integração Contínua  com o Cliente**: ScrumXP envolve o cliente de forma constante, promovendo feedback a cada sprint. No RAD, o feedback do cliente é mais pontual e menos estruturado, o que pode resultar em um desalinhamento nos requisitos ao longo do projeto.