Merge pull request #12 from mdsreq-fga-unb/docs/unidade2

Correção de issues e adição de DOR E DOD

docs/engenharia-requisitos/Dor_dod.md

@@ -0,0 +1,24 @@
+# DoR e DoD
+Esta seção apresenta os conceitos de Definition of Ready (DoR) e Definition of Done (DoD), que ajudam a garantir que o trabalho seja bem definido antes de ser iniciado e que esteja completo antes de ser considerado pronto para entrega.
+
+
+## Definition of Ready (DoR)
+
+O DoR define os critérios que devem ser atendidos para que uma história de usuário, caso de uso, ou cenário esteja pronto para ser desenvolvida. Isso ajuda a garantir que os requisitos estejam claros, bem declarados e que não haja impedimentos para o desenvolvimento.
+
+- **A equipe estimou o esforço necessário para completar a tarefa?** O requisito deve ter o seu esforço avaliado pela a equipe para saber se pode ser concluído na Sprint.
+- **O requisito possui informação necessária para ser trabalhado?** O requisito deve ter detalhes suficientes para que o time de desenvolvimento entenda o que precisa ser feito, sem ambiguidades.
+- **O requisito cabe em uma Sprint?** O tempo de desenvolvimento de um requisito não deve exceder a duração de um Sprint.
+- **O requisito foi priorizado?** A equipe precisa saber o quão importante é o requisito para a produção do MVP para saber melhor quando ele deve ser desenvolvido.
+
+
+## Definition of Done (DoD)
+
+O DoD define os critérios que precisam ser cumpridos para que uma funcionalidade seja considerada completa. Isso inclui os requisitos, desenvolvimento, testes, revisão e validação da qualidade, garantindo que a entrega atenda ao escopo e aos padrões de qualidade acordados
+
+- **O código foi desenvolvido e revisado (peer review):** A implementação foi concluída e revisada por outro desenvolvedor para garantir qualidade aos padrões.
+- **Teste manual:** Todos os testes manuais realizados pela a equipe de desenvolvimento foram concluídos sem nenhum erro encontrado.
+- **Entrega um incremento do produto:** A funcionalidade desenvolvida agrega valor ao produto, resultando em um incremento utilizável.
+- **Contempla os critérios de aceitação estabelecidos:** Todos os critérios de aceitação definidos foram cumpridos, garantindo que o comportamento esperado do requisito foi atingido.
+- **Funcionalidade validada pelo Product Owner (PO):** O PO revisou e aceitou a entrega, confirmando que atende aos requisitos de negócio.
+- **Está aderente aos padrões de codificação?** O código deve seguir os padrões de codificação estabelecidos pela equipe, garantindo qualidade, consistência e facilidade de manutenção.

docs/licoes/unidade1.md

@@ -0,0 +1,5 @@
+## Unidade 1
+
+Nessa unidade, fomos apresentados às abordagens, ciclos de vida e como cada atividade de requisitos se encaixa nos processos envolvidos em um projeto de software, assim como também tivemos que decidir quanto a metodologia que correspondesse melhor com as perspectivas do nosso próprio projeto, atendendo as necessidades de um cliente real. 
+
+Quanto as dificuldades encontradas, a adaptação necessária para conduzir um projeto de software com base na disciplina de requisitos, as dinâmicas de equipe que envolveram as apresentações e entregas e a determinação das tarefas de cada membro foram as que mais impactaram ao decorrer da unidade. A respeito disso, o que deve ser melhorado é flexibilizar algumas tarefas da equipe, sendo uma boa abordagem a ser seguida um rodízio em certas atividades no decorrer do projeto, de forma a atender os horários que cada membro possui para trabalhar no projeto assim como as limitações envolvidas em suas dificuldades pessoais, sejam elas de capacitação ou de qualquer outra natureza.

docs/licoes/unidade2.md

@@ -0,0 +1,4 @@
+## Unidade 2
+
+Diante das dificuldades apresentadas na unidade 1, a equipe conseguiu aprimorar o gerenciamento de tempo, permitindo dedicar tempo suficiente para revisar as atividades realizadas. Além disso, a equipe passou a lidar melhor com a dinâmica entre seus integrantes, compreendendo que nem todos têm disponibilidade para participar de todas as reuniões e que nem sempre as entregas são feitas dentro do prazo previsto. No entanto, sempre que necessário, a equipe realiza o remapeamento de atividades e oferece auxílio aos membros para garantir que as tarefas sejam concluídas.
+A lição principal aprendida foi a importância de realizar as atividades com base no conteúdo estudado e na revisão, em vez de depender do "feeling" para tomar decisões.

docs/produto/cronograma-entregas.md

@@ -1,14 +1,16 @@
-| 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    | 23/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     |
-| **Intervalo** | **24/12/2024** | **08/01/2025** | **Pausa no desenvolvimento devido ao intervalo festivo** |                                                                                                            |                                                        |
-| Sprint 4    | 09/01/2025    | 20/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    | 21/01/2025    | 03/02/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    | 04/02/2025    | 16/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    | 17/02/2025    | 22/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    | 23/02/2025    | 25/02/2025    | Lançamento e Monitoramento
+## Cronograma de Sprints
+
+| **Sprint**    | **Início**     | **Fim**       | **Objetivo Principal**                                 | **Entregas Esperadas**                                                                                                     | **Validação do Cliente**                                |
+|---------------|----------------|---------------|-------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
+| **Sprint 1** | 14/11/2024     | 27/11/2024    | Definição dos Requisitos e Backlog                    | Levantamento dos requisitos, definição inicial do backlog e criação de protótipos iniciais                                | Revisão e validação dos requisitos e dos protótipos    |
+| **Sprint 2** | 28/11/2024     | 11/12/2024    | Refinamento e Priorização do Backlog                  | Refinamento dos protótipos, priorização do backlog e estimativas de esforço                                               | Confirmação de prioridade e alinhamento com o MVP      |
+| **Sprint 3** | 12/12/2024     | 23/12/2024    | Planejamento Detalhado e Preparação                 | Validação dos protótipos e planejamento detalhado das entregas                                                            | Feedback sobre os protótipos e ajustes necessários     |
+| **Intervalo** | **24/12/2024** | **08/01/2025** | **Pausa no desenvolvimento devido ao intervalo festivo** |                                                                                                                            |                                                        |
+| **Sprint 4** | 09/01/2025     | 20/01/2025    | Cadastro de Alunos e Turmas                           | Implementação das funcionalidades de cadastro de alunos e turmas na plataforma                                            | Validação dos cadastros de alunos e turmas             |
+| **Sprint 5** | 21/01/2025     | 03/02/2025    | Gestão de Perguntas                    | Funcionalidades de criação, edição, exclusão e visualização do banco de perguntas                                         | Validação do gerenciamento de perguntas                |
+| **Sprint 6** | 04/02/2025     | 16/02/2025    | Sistema de Questionários                              | Implementação do sistema de liberação de questionários, resposta dos alunos e liberação de notas                         | Validação dos questionários e fluxo de notas           |
+| **Sprint 7** | 17/02/2025     | 22/02/2025    | Visualização e Análise de Desempenho                  | Funcionalidades para visualização de gráficos de desempenho dos alunos e gráficos globais                                 | Validação das visualizações de desempenho              |
+| **Sprint 8** | 23/02/2025     | 25/02/2025    | Relatórios e Download de Gráficos                     | Funcionalidades para geração e download de relatórios e gráficos de desempenho                                            | Validação dos relatórios e download de gráficos        |
 
 
 ---

docs/produto/visao-produto-projeto.md

@@ -10,9 +10,9 @@ Com o objetivo de se tornar referência em educação na América Latina nos pr
 
 ## Identificação da Oportunidade ou Problema
 
-A principal oportunidade identificada para a Ideia Space é uma forma de estender o engajamento e o aprendizado dos alunos para além das salas de aula tradicionais. Muitas abordagens educacionais enfrentam dificuldades em manter o interesse contínuo dos alunos, especialmente fora do ambiente escolar, onde o contato com os conteúdos se torna limitado e menos atrativo. A proposta busca possibilitar que os alunos pratiquem seus conhecimentos de forma gamificada fora de sala de aula.
+O principal problema identificado na Ideia Space é a falta de um método para avaliar o desempenho dos alunos fora das salas de aula. Atualmente, a empresa não possui uma maneira de medir o progresso dos alunos com métricas baseadas em seu desempenho. Isso dificulta o acompanhamento contínuo e impede que educadores obtenham informações precisas sobre o aprendizado dos estudantes.
 
-A necessidade de uma nova abordagem foi intensificada pelo avanço da tecnologia e pela demanda por métodos educacionais mais atrativos e acessíveis. A Ideia Space percebeu que, ao utilizar elementos de gamificação e temas espaciais que despertam curiosidade, pode aumentar significativamente o engajamento dos alunos, promovendo um aprendizado contínuo. Com essa plataforma, a empresa visualiza uma oportunidade de expandir seu impacto educacional, auxiliando os alunos a se manterem motivados e interessados em aprender.
+A proposta busca resolver essa dificuldade com a implementação de um sistema que permita monitorar e registrar o progresso dos alunos fora do ambiente escolar. Além disso, a gamificação será utilizada como um recurso adicional para manter os alunos mais engajados na plataforma, tornando o aprendizado fora de sala de aula mais dinâmico e atrativo.
 
 !!! note "Nota"
     A figura a seguir apresenta o diagrama de Ishikawa contendo as causas (organizadas pelos 6M’s) e o problema da Ideia Space.

mkdocs.yml

@@ -12,10 +12,15 @@ nav:
       - Cronograma e entregas: produto/cronograma-entregas.md
       - Interação entre equipe e cliente: produto/interacao.md
   - Engenharia de Requisitos:
-    - Atividades e Técnicas de ER: engenharia-requisitos/atividades_er.md
-    - Backlog: engenharia-requisitos/backlog.md
-    - Lista de requisitos: engenharia-requisitos/lista-requisitos.md
+      - Atividades e Técnicas de ER: engenharia-requisitos/atividades_er.md
+      - Backlog: engenharia-requisitos/backlog.md
+      - DoR e DoD: engenharia-requisitos/Dor_dod.md
+      - Lista de requisitos: engenharia-requisitos/lista-requisitos.md
   - Apresentações: apresentacoes/index.md
+  - Lições aprendidas: 
+      - Unidade 1: licoes/unidade1.md
+      - Unidade 2: licoes/unidade2.md
+
 
 theme:
   name: material