Adicionando várias correções

docs/avaliacao-usm-space.md

@@ -2,9 +2,6 @@ Neste documento, apresentamos os resultados da verificação e validação do Us
 
 A metodologia utilizada foi a de Checklist de verificação e Checklist de Validação. Assim sendo o de Verificação com foco na estrutura da atividade de USM e o de Validação mais concentrado no conteúdo do USM. 
 
-## Verificação e Validação (MIRO)
-<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKvdDBkU=/?moveToViewport=542904,311400,145320,75016&embedId=300046176389" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
-
 
 ## Checklist de Verificação 
 Segue abaixo a tabela 1 com os resultados obtidos da verificação estrutural da atividade de USM realizada pelo grupo [Space Edge](https://mdsreq-fga-unb.github.io/2024.1-Echoeasy/#/./entregas/missao_03/entrega_final?id=_3-usm-user-story-maping)

docs/healthnet-bdd.md

@@ -10,9 +10,9 @@ No BDD, as funcionalidades são descritas em uma linguagem simples e estruturada
 
 A "HealthNet" enfrenta um desafio significativo devido à falta de uma estrutura unificada para a gestão de dados de pacientes em suas diversas unidades espalhadas por vários estados. Os profissionais de saúde lidam com sistemas desatualizados e incompatíveis, resultando em prontuários isolados que não se comunicam entre si. Isso atrasa os processos, aumenta o risco de erros médicos e dificulta o acesso a informações completas e atualizadas. Além disso, os sistemas de agendamento de consultas são ineficientes, causando longos tempos de espera e frustração. O controle de medicamentos também é prejudicado, dificultando o rastreamento de prescrições e aumentando o risco de complicações médicas. A dependência de processos manuais e papelada agrava ainda mais a situação, tornando as operações lentas, propensas a erros, e complicando a conformidade com regulamentações de proteção de dados de saúde.
 
-**BDD HealthNet**
+**BDD HealthNet (MIRO)**
 
-<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKvdDBkU=/?moveToViewport=710817,226151,173243,38716&embedId=951516841249" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
+<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKmAWbH4=/?moveToViewport=-63792,26239,96724,33239&embedId=811494119752" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
 
 Com base nas histórias de usuário e seus respectivos critérios de aceitação, foram criados cenários de BDD. Os cenários cobrem aspectos de sucesso, falha e comportamentos alternativos que mapeiam diretamente os requisitos do sistema, permitindo uma validação precisa e garantindo que as funcionalidades atendam às necessidades dos usuários finais. Estes cenários servem de guia para o desenvolvimento e testes do sistema, facilitando a comunicação entre as equipes e assegurando a entrega de um produto de alta qualidade.
 

docs/healthnet-pbb.md

@@ -27,7 +27,5 @@ A criação segue a mesma apresentada no PBB da atividade (HealthNet), com a dif
 
 | Versão | Data       | Descrição                                                         | Autor(es)       |
 |--------|------------|-------------------------------------------------------------------|-----------------|
-| 2.3   | 20/08/2024 |  USM - ComunEventos                              | Grupo   |
-|2.3|21/08/2024| PBB - HealthNet, PBB - OBJEX   | Grupo
-|2.3|23/08/2024| Revisão e video   | Grupo
+| 1.0   | 20/08/2024 |  Criação da página e adição do PBB                              | Grupo   |
 

docs/missao2-criterios-aceitacao.md

@@ -9,6 +9,9 @@ As imagens a seguir, apresentam os Critérios de Aceitação para cada uma das H
 ## Critérios de Aceitação FE02 - CRUD Aluno
 ![Critérios de Aceitação FE02 - CRUD Aluno](assets/criterios-aceitacao/fe02-crud-aluno.png){: style="height:auto", width="100%"}
 
+## Critérios de Aceitação FE03 - CRUD Monitor
+<span style="color:white; font-size:26px;">Não entrou no MVP.</span><br><br>
+
 ## Critérios de Aceitação FE04 - CRUD Grupo
 ![Critérios de Aceitação FE04 - CRUD Grupo](assets/criterios-aceitacao/fe04-crud-grupo.png){: style="height:auto", width="100%"}
 
@@ -21,6 +24,9 @@ As imagens a seguir, apresentam os Critérios de Aceitação para cada uma das H
 ## Critérios de Aceitação FE07 - Emitir Planilhas
 ![Critérios de Aceitação FE07 - Emitir Planilhas](/assets/criterios-aceite-submeterAtividades.png){: style="height:auto", width="100%"}
 
+## Critérios de Aceitação FE08 - Correção automática de código
+![Critérios de Aceitação FE08 - Correção automática de código](/assets/fe08-correcao-codigo.png){: style="height:auto", width="100%"}
+
 ## Critérios de Aceitação FE09 - CRUD Professor
 ![Critérios de Aceitação FE09 - CRUD Professor](assets/criterios-aceitacao/fe09-crud-professor.png){: style="height:auto", width="100%"}
 
@@ -35,15 +41,21 @@ As imagens a seguir, apresentam os Critérios de Aceitação para cada uma das H
 ## Critérios de Aceitação FE12 - Entrar e Sair de Grupos
 ![Critérios de Aceitação FE12 - Entrar e sair de grupos](assets/criterios-aceitacao/fe12-entrar-e-sair-grupos.png){: style="height:auto", width="100%"}
 
-## Critérios de Aceitação FE14 - Professor/Admin Login e Logout
-![Critérios de Aceitação FE14 - Professor/Admin Login e Logout](assets/criterios-aceitacao/fe14-professor-admin-login-logout.png){: style="height:auto", width="100%"}
+## Critérios de Aceitação FE13 - Visualizar e Baixar Conteúdos
+<span style="color:white; font-size:26px;">Não entrou no MVP.</span><br><br>
+
+## Critérios de Aceitação FE14 - Professor Login e Logout
+![Critérios de Aceitação FE14 - Professor/Admin Login e Logout](assets/criterios-aceitacao/fe14-professor-login-logout.png.png){: style="height:auto", width="100%"}
 
 ## Critérios de Aceitação FE15 - Aluno Login e Logout
 ![Critérios de Aceitação FE15 - Aluno Login e Logout](/assets/criterio-aceite-Aluno-login-logout.png){: style="height:auto", width="100%"}
 
-## Critérios de Aceitação FE13 - Visualizar e Baixar Conteúdos
-<span style="color:white; font-size:26px;">Não entrou no MVP.</span><br><br>
+## Critérios de Aceitação FE16 - Admin Login e Logout
+![Critérios de Aceitação FE15 - Aluno Login e Logout](/assets/criterios-aceitacao/fe16-admin-login-logout.png){: style="height:auto", width="100%"}
+
+
 
 | Versão | Data       | Descrição                                                         | Autor(es)       |
 |--------|------------|-------------------------------------------------------------------|-----------------|
-| 1.0    | 20/08/2024 | Criação da página e criterios de aceitação                                    | Grupo   |
+| 1.0    | 20/08/2024 | Criação da página e criterios de aceitação                                    | Grupo   |
+| 2.0    | 09/09/2024 | Atualizações                                    | Grupo   |

docs/missao2-mvp.md

@@ -26,7 +26,7 @@ O conceito de MVP (Minimum Viable Product), ou Produto Mínimo Viável, é funda
 | EP01 - Professor|US23 | Eu como professor, quero ser capaz de deletar uma atividade para caso ela não seja mais necessária |
 | EP01 - Professor|US24 | Eu como professor quero emitir planilhas de grupos formados para facilitar a organização dos mesmos |
 | EP01 - Professor|US25 | Eu como professor quero emitir planilhas de turmas para facilitar a organização das mesmas|
-| EP01 - Professor|US26 | Eu como professor quero corrigir as atividades dos alunos para poder atribuir notas|
+| EP01 - Professor|US26 | Eu como professor quero acessar as respostas de código que foram corrigidas pelo sistema|
 | EP01 - Professor|US27 | Eu como professor Admin, quero ser capaz de cadastrar um professor para que ele consiga exercer suas funções |
 | EP01 - Professor|US28 | Eu como professor Admin, quero ser capaz de editar um professor para alterar suas informações |
 | EP01 - Professor|US29 | Eu como professor Admin, quero ser capaz de visualizar um professor para verificar suas informações|
@@ -37,7 +37,7 @@ O conceito de MVP (Minimum Viable Product), ou Produto Mínimo Viável, é funda
 | EP01 - Professor|US43 | Eu como Professor Admin, desejo fazer logout para sair da plataforma de maneira segura |
 | EP03 - Aluno|US38 |Eu como aluno desejo fazer login para ter acesso às funcionalidades |
 | EP03 - Aluno|US39 |Eu como aluno desejo fazer logout para sair da plataforma de maneira segura |
-| EP03 - Alunos|US32 | Eu como aluno desejo responder atividades de múltipla escolha para poder ser avaliado |
+| EP03 - Alunos|US32 | Eu como aluno desejo responder atividades de texto para poder ser avaliado |
 | EP03 - Alunos|US33 | Eu como aluno desejo responder atividades de código para poder ser avaliado |
 | EP03 - Alunos|US34 |Eu como aluno desejo responder atividades de envio de imagem para poder ser avaliado |
 | EP03 - Alunos|US35 | Eu como aluno desejo entrar em um grupo para que eu possa participar das atividades da disciplina  |

docs/ppb.md

@@ -5,7 +5,7 @@
 
 A "HealthNet" enfrenta um desafio significativo devido à falta de uma estrutura unificada para a gestão de dados de pacientes em suas diversas unidades espalhadas por vários estados. Os profissionais de saúde lidam com sistemas desatualizados e incompatíveis, resultando em prontuários isolados que não se comunicam entre si. Isso atrasa os processos, aumenta o risco de erros médicos e dificulta o acesso a informações completas e atualizadas. Além disso, os sistemas de agendamento de consultas são ineficientes, causando longos tempos de espera e frustração. O controle de medicamentos também é prejudicado, dificultando o rastreamento de prescrições e aumentando o risco de complicações médicas. A dependência de processos manuais e papelada agrava ainda mais a situação, tornando as operações lentas, propensas a erros, e complicando a conformidade com regulamentações de proteção de dados de saúde.
 
-<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKvdDBkU=/?moveToViewport=555638,227310,123111,36455&embedId=743100508146" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
+<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKmAWbH4=/?moveToViewport=-68576,-12863,93259,35647&embedId=790013818028" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
 
 A atividade de PBB foi realizada com a criação de 3 Frames no Miro, sendo o primeiro (PBB) o diagrama PBB em si, detalhando os Problemas e Expectativas acerca de como é feito atualmente e como as personas esperam que seja. Detalha as personas, informando o que elas fazem e o que elas esperam fazer no produto.
 
@@ -15,13 +15,6 @@ Logo em seguida, são mostrados os Itens do Product Backlog, que são as Histór
 
 A priorização das US's foi feita em seguida, no Frame chamado PRIORIZAÇÃO COORG, utilizando o método de priorização COORG, onde a priorização é realizada verticalmente e horizontalmente, onde, verticalmente representa a prioridade (quanto mais alta, maior), e horizontalmente representando a sequência lógica de ordem.
 
-## PBB do Projeto (ObjeX)
-
-A título de curiosidade, segue o PBB do nosso próprio projeto.
-
-<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKuUGHA8=/?moveToViewport=-114086,65674,34019,11385&embedId=948523812326" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
-
-A criação segue a mesma apresentada no PBB da atividade (HealthNet), com a diferença de que só possui dois Frames no Miro, o primeiro sendo o PBB em si, e o segundo (Pontuação VN DFD) sendo a priorização das US's seguindo o método de Priorização Dificuldade + Valor de Negócio.
 
 ## Histórico de Versão
 

docs/produto-problema.md

@@ -12,7 +12,7 @@ Dificuldade no lançamento de notas:
 
 * Devido a grande quantidade de alunos, o processo de correção e lançamento de notas é extenso e exaustivo. Dificultando a entrega de notas e até mesmo gerar um feedback aos alunos para que eles possam melhorar nos pontos em que falharam. 
 
-Esses desafios impactam negativamente o andamento do curso, tornando necessário um sistema eficiente e organizado para a resolução dos problemas citados acima. Com isso, aliado ao desejo do professor em gamificar a disciplina, surgiu a ideia do ObjeX.
+Esses desafios impactam negativamente o andamento do curso, tornando necessário um sistema eficiente e organizado para a resolução dos problemas citados acima. Com isso, surgiu a ideia do ObjeX.
 
 
 ## Histórico de Versão

docs/usm.md

@@ -0,0 +1,33 @@
+**User Story Mapping (USM)** é uma técnica de visualização usada para entender as necessidades e jornadas dos usuários ao interagir com um produto ou serviço. Ela ajuda equipes de desenvolvimento, designers e stakeholders a organizarem e priorizarem as funcionalidades e requisitos do produto de forma colaborativa.
+
+## ComunEventos 
+
+A ComunEventos é uma startup criada por três jovens empreendedores que, após participar de eventos comunitários, identificaram a necessidade de otimizar a experiência para organizadores e participantes. A missão da empresa é desenvolver uma plataforma online que facilite a organização e promoção desses eventos, promovendo um ecossistema digital para que a comunidade se conecte e participe de atividades que reflitam seus valores. Eventos comunitários, como feiras, workshops e atividades culturais, são importantes para fortalecer laços sociais e promover a coesão na comunidade, permitindo que as pessoas se conectem, aprendam e trabalhem juntas para melhorar seu ambiente. 
+
+A plataforma irá permitir que Organizadores de Eventos consigam contatar Patrocinadores e Voluntários para organizar os eventos e também promovê-los por meio da plataforma, para que os Participantes interessados consigam ver os detalhes dos eventos, comprar ingressos e ir aos eventos.
+
+## USM:
+
+<iframe width="768" height="432" src="https://miro.com/app/live-embed/uXjVKmAWbH4=/?moveToViewport=-68784,64516,79636,18820&embedId=248765000082" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
+
+Foram produzidas 88 Histórias de Usuários, portanto nas tabelas abaixo só foi possível apresentar os Títulos. Para verificar as Histórias de Usuário é necessário expandir os Cards de Título de História de Usuário no Miro (acima), conforme o tutorial:
+
+## Como verificar as Histórias de Usuário:
+
+Primeiramente, coloque em tela cheia para facilitar a visualização:
+![Fullscreen no Iframe Miro](assets/tutorial-miro-1.png){: style="height:auto", width="100%"}
+
+Aproxime do Card que deseja verificar a US, em seguida selecione-o, por fim, aperte o botão com ícone de Expadir:
+![SAFe](assets/tutorial-miro-2.png){: style="height:auto", width="100%"}
+
+Desça até a descrição do Card, onde se encontra a História de Usuário:
+![SAFe](assets/tutorial-miro-3.png){: style="height:auto", width="100%"}
+
+<span style="color:red; font-size:22px; text-align:justify"><strong>Observação: </strong></span><span>Caso seja necessário necessário fazer auditoria do último horário onde foram realizadas modificações no quadro Miro para verificar fraude, por favor entrar em contato com a equipe, pois apenas membros com permissão de edição conseguem visualizar o histórico do quadro. E a mensagem de "Última Modificação" apresentada ao abrir o quadro, geralmente é atualizada mesmo sem modificações relevantes.</span>
+<br>
+
+## Histórico de Versão
+
+| Versão | Data       | Descrição                                                         | Autor(es)       |
+|--------|------------|-------------------------------------------------------------------|-----------------|
+| 1.0   | 09/09/2024 |  Adicionando USM corrigido                             | Grupo   |

mkdocs.yml

@@ -100,6 +100,7 @@ nav:
     - DOR e DOD: dor-dod.md
     - BDD: healthnet-bdd.md
     - PBB: ppb.md
+    - USM: usm.md
 
 copyright: |
   REQ-2024.1 <a href="https://github.com/mdsreq-fga-unb/2024.1-ObjeX"  target="_blank" rel="noopener">CyberHunterz</a>