From c264d4111f72c6622b37141c66d6d6c42dc2a98b Mon Sep 17 00:00:00 2001 From: Caio Felipe Date: Sun, 15 Dec 2024 17:13:20 -0300 Subject: [PATCH] =?UTF-8?q?docs:=20atualiza=20e=20estiliza=20documenta?= =?UTF-8?q?=C3=A7=C3=A3o=20(#8)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * docs: atualiza membros da equipe * docs: cria seção para apresentações * docs: estiliza documentação Remove atividades e técnicas de ER para refatoração Remove pasta desnecessária de interação e comunicação com cliente Adiciona tema de ícones e estilizações para documentação * build: add requirements.txt --- docs/apresentacoes/index.md | 3 + docs/index.md | 15 +- docs/produto/cronograma-entregas.md | 6 +- docs/produto/estrategias.md | 154 +----------------- .../produto/interacao.md | 0 docs/produto/solucao.md | 14 +- docs/produto/visao-produto-projeto.md | 30 +--- mkdocs.yml | 27 ++- requirements.txt | 1 + 9 files changed, 64 insertions(+), 186 deletions(-) create mode 100644 docs/apresentacoes/index.md rename "docs/intera\303\247\303\243o/composi\303\247\303\243o.md" => docs/produto/interacao.md (100%) create mode 100644 requirements.txt diff --git a/docs/apresentacoes/index.md b/docs/apresentacoes/index.md new file mode 100644 index 0000000..d1ca3b2 --- /dev/null +++ b/docs/apresentacoes/index.md @@ -0,0 +1,3 @@ +# Apresentação de Entrega I + +![type:video](https://drive.google.com/file/d/1OF8X91xykGekYA8f2y5i1VYCJQ4NEa9C/preview) diff --git a/docs/index.md b/docs/index.md index 8a0d495..36f9843 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,5 +1,12 @@ # Início +## Histórico de Revisão + +| Data | Versão | Descrição | Autor | +|------------|--------|-----------------------|----------------| +| 01/11/24 | 1.0 | Criação do documento | Edilson Ribeiro | +| 04/11/24 | 1.0 | Correções do documento | Matheus Brant | + ## 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. @@ -41,4 +48,10 @@ Portanto, para este projeto, a Ideia Space é o cliente que necessita de uma sol

Matheus Brant

- \ No newline at end of file + +
+ +

Sebastian Zuzunaga

+
+ + diff --git a/docs/produto/cronograma-entregas.md b/docs/produto/cronograma-entregas.md index 93b6d1a..bf848df 100644 --- a/docs/produto/cronograma-entregas.md +++ b/docs/produto/cronograma-entregas.md @@ -1,5 +1,3 @@ -## 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
- Configuração da arquitetura (React, FastAPI, MongoDB)
- Ambiente de desenvolvimento configurado | Revisão do backlog e confirmação de prioridade | @@ -15,8 +13,8 @@ --- -### Considerações Importantes +## Considerações Importantes -- **Datas de Início e Fim**: Cada sprint tem duração média de duas semanas,porém existem variações. +- **Datas de Início e Fim**: Cada sprint tem duração média de duas semanas, porém existem variações. - **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. diff --git a/docs/produto/estrategias.md b/docs/produto/estrategias.md index 3121bdc..676ee96 100644 --- a/docs/produto/estrategias.md +++ b/docs/produto/estrategias.md @@ -1,6 +1,4 @@ -## Estratégias de Engenharia de Software - -### Estratégia Priorizada +## Estratégia Priorizada **Abordagem**: Ágil @@ -8,8 +6,7 @@ **Processo**: ScrumXP - -### Quadro Comparativo +## 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. @@ -29,153 +26,16 @@ O quadro a seguir, apresenta algumas características relacionadas ao RAD e ao S **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. - >Blibliografia - > - >GOMES, ANDRÉ: Scrum: o Framework Mínimo Viável. Disponível em: https://www.linkedin.com/pulse/scrum-o-framework-m%C3%ADnimo-vi%C3%A1vel-andr%C3%A9-gomes - > - > SCHWABER, KEN: SCRUM Development Process. Disponível em: http://www.jeffsutherland.org/oopsla/schwapub.pdf - > - > CIPULLO, GIOVANNA: RAD: você sabe como funciona o desenvolvimento ágil de aplicações? Disponível em: https://www.korp.com.br/rad-voce-sabe-como-funciona-o-desenvolvimento-agil-de-aplicacoes/ +!!! info "Referências" + - **GOMES, ANDRÉ.** Scrum: o Framework Mínimo Viável. Disponível em: [LinkedIn](https://www.linkedin.com/pulse/scrum-o-framework-m%C3%ADnimo-vi%C3%A1vel-andr%C3%A9-gomes) + - **SCHWABER, KEN.** SCRUM Development Process. Disponível em: [JeffSutherland](http://www.jeffsutherland.org/oopsla/schwapub.pdf) + - **CIPULLO, GIOVANNA.** RAD: você sabe como funciona o desenvolvimento ágil de aplicações? Disponível em: [Korp](https://www.korp.com.br/rad-voce-sabe-como-funciona-o-desenvolvimento-agil-de-aplicacoes/) -### Justificativa +## 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. - - -# ENGENHARIA DE REQUISITOS - -## Atividades e Técnicas de ER - -### Planejamento da Release - -#### Elicitação e Descoberta: -- **Entrevistas:** Entrevistas realizadas com o cliente, representante da Ideia Space, com o objetivo de entender melhor suas expectativas (associada a prioridades e necessidades) para uma nova versão. -- **Brainstorming:** Reuniões que permitem o surgimento de novas ideias para agregar na solução do produto de software. - -#### Análise e Consenso: -- **Storyboarding:** Narrativa para ilustrar o funcionamento esperado de novas funcionalidades. -- **Mapas mentais:** Utilização de mapas mentais para a organização de ideias e desenvolvimento de conceitos quando informações relacionadas ao produto não estão claras. -- **Sessões de validação:** Apresentação e validação de propostas com o cliente e a equipe para alinhamento e consenso. -- **Análise de custo-benefício:** Avaliação do impacto e custo de cada funcionalidade para definição da melhor escolha no momento. - -#### Declaração de Requisitos: -- **Critérios de aceitação:** Estabelecer critérios para cada funcionalidade para ajudar na validação e desenvolvimento. -- **Temas, Épicos e User Stories:** A organização dos requisitos em diferentes níveis proporciona uma melhor clareza do que deve ser desenvolvido. - -### Planejamento da Sprint - -#### Elicitação e Descoberta: -- **Refinamento de Requisitos:** Revisão e detalhamento dos requisitos no backlog, priorizando os itens para a sprint. -- **Análise Documental:** Avaliação de relatórios ou registros existentes para detalhar requisitos adicionais. - -#### Análise e Consenso: -- **Planning Poker:** Estimativa colaborativa do esforço e complexidade dos requisitos priorizados. -- **Diagramas de Sequência:** Representação visual de fluxos entre componentes do sistema para facilitar o entendimento técnico. -- **Discussões Técnicas:** Reuniões entre desenvolvedores para identificar dependências e alinhar estratégias de implementação. - -#### Declaração: -- **Definition of Done (DoD):** Lista de critérios para considerar uma funcionalidade concluída, incluindo testes e validações. -- **Critérios de Aceitação Detalhados:** Requisitos objetivos para validar que a funcionalidade atende às expectativas do cliente. -- **Kanban:** Utilizado para organizar e rastrear o progresso dos itens da sprint em colunas como "Planejado", "Em Progresso", "Em Teste" e "Concluído", proporcionando visibilidade contínua do status das funcionalidades e alinhamento com o DoD e os Critérios de Aceitação. - -#### Organização e Atualização: -- **Revisão do Backlog com Critérios DEEP:** Garantia de que os itens do backlog estão Detalhados, Estimáveis e Priorizados. -- **Priorização WSJF (Weighted Shortest Job First):** Técnica para priorizar tarefas com base em valor comercial, urgência e esforço necessário. - ---- - -### Execução da Sprint - -#### Elicitação e Descoberta: -- **Daily Scrum:** Reuniões diárias rápidas, geralmente de 15 minutos, realizadas para alinhar o progresso da equipe, identificar impedimentos e planejar as atividades do dia. - -#### Representação: -- **Protótipos:** Utilizados para validar a interface e o fluxo de funcionalidades antes do desenvolvimento completo. Eles permitem que a equipe visualize o produto final e realizem ajustes necessários no início da execução. - -#### Verificação e Validação: -- **Revisões de Código:** Atividade realizada entre pares para garantir que o código atenda aos padrões de qualidade e esteja alinhado aos requisitos. -- **Testes Automatizados:** Utilização de pipelines de integração contínua (CI) para validar o funcionamento correto das funcionalidades desenvolvidas. - -#### Desenvolvimento Colaborativo: -- **Pair Programming:** Técnica onde dois desenvolvedores trabalham juntos no mesmo código, alternando os papéis de "piloto" (quem escreve) e "navegador" (quem revisa). - -#### Organização e Atualização: -- **Kanban:** Quadro visual para acompanhar o progresso dos itens, com colunas como "Planejado", "Em Progresso", "Em Teste" e "Concluído", proporcionando visibilidade contínua do progresso da sprint. - ---- - -### Revisão de Sprint - -#### Verificação e Validação: -- **Checklist de Validação:** Garantir que os requisitos implementados atendem a todas as necessidades do cliente; apenas requisitos que completam totalmente o checklist serão apresentados. -- **Checklist de Verificação:** Garante que os requisitos implementados foram realizados corretamente; requisitos que não completem a checklist não poderão ser apresentados. -- **Definition of Done (DoD):** Será usado como base para a elaboração das checklists de validação e verificação. -- **Feedback do Cliente:** Durante a reunião de revisão, os comentários e sugestões do cliente sobre os requisitos implementados que foram apresentados serão documentados para uso futuro. -- **Revisão Informal:** A forma de apresentar os requisitos implementados ao cliente será por meio de demonstrações e explicações do seu funcionamento. As explicações serão orais e não se concentrarão muito no aspecto técnico, favorecendo casos de uso práticos. - -#### Análise e Consenso: -- **Análise de Custo / Benefício:** Verificar se as modificações e sugestões apresentadas pelo cliente geram valor suficiente para o negócio para serem implementadas. -- **Análise de Risco / Viabilidade:** Revisar, considerando o conhecimento do equipamento e as limitações do software utilizado, se é possível implementar as modificações e sugestões apresentadas pelo cliente. -- **Casos de Uso:** Verificar se existem casos de uso para as modificações e sugestões apresentadas pelo cliente para determinar se tais funcionalidades são necessárias. Caso existam, verificar o que deveria ou não ser permitido em cada uma delas. - ---- - -### Retrospectiva da Sprint - -#### Análise e Organização: -- **Feedback da Equipe:** Coleta de opiniões dos membros da equipe sobre pontos positivos e desafios enfrentados, com foco na melhoria contínua do processo. - -#### Atualização do Processo: -- **Definição de Ações Corretivas:** Planejamento de medidas para resolver os problemas identificados durante a sprint e melhorar a colaboração e eficiência do time. - -### Planejamento da Próxima Release - -#### Elicitação e Descoberta: -- **Revisão de Requisitos Pendentes:** Avaliação dos requisitos que não foram concluídos em sprints anteriores para decidir se ainda são relevantes e devem ser priorizados na próxima release. -- **Revisão do Backlog:** Análise do backlog existente para identificar requisitos alinhados com os objetivos do projeto e as necessidades do cliente. - -#### Análise e Consenso: -- **Priorização MoSCoW:** Técnica utilizada para classificar os requisitos em Must Have, Should Have, Could Have e Won’t Have, permitindo uma priorização clara baseada em impacto e valor. -- **Estimativas de Esforço e Tempo:** Utilização de práticas como o Planning Poker para estimar o esforço necessário para implementar cada requisito e prever o cronograma da próxima release. - -#### Declaração: -- **Definição de Objetivos da Release:** Estabelecimento das metas da próxima release por meio de sessões de brainstorming e reuniões colaborativas, garantindo alinhamento entre a equipe e os stakeholders. - -#### Organização e Atualização: -- **Backlog Organizado:** Aplicação de técnicas para organizar e priorizar os requisitos do backlog, garantindo que estejam prontos para o início do desenvolvimento. -- **Atualização do Backlog:** Revisão contínua do backlog para refletir as mudanças nas prioridades e no escopo do projeto. - - - -### Engenharia de Requisitos e ScrumXP - -| **Fases do Processo** | **Atividades ER** | **Prática** | **Técnica** | **Resultado Esperado** | -|--------------------------------|------------------------------------|---------------------------------|------------------------------------------------------------------|---------------------------------------------------------------------------------------| -| **Planejamento da Release** | **Elicitação e Descoberta** | Levantamento de requisitos | Entrevistas, brainstorming | Requisitos na sua forma mais bruta levantados | -| | **Análise e Consenso** | Confirmação dos requisitos | Mapas mentais, sessões de validação, análise de custo-benefício, storyboarding | Entendimento dos requisitos levantados e seleção para a release | -| | **Declaração** | Registro dos requisitos confirmados | Critérios de aceitação, temas, épicos e user stories | Registros que auxiliam no desenvolvimento e validação das funcionalidades | -| **Planejamento da Sprint** | **Refinamento de Requisitos** | Revisão Colaborativa | Análise Documental | Requisitos detalhados e prontos para desenvolvimento | -| | **Estimativa e Priorização** | Estimativa de Complexidade | Planning Poker | Requisitos priorizados com estimativas consensuais entre a equipe | -| | **Representação de Fluxos** | Planejamento Técnico | Diagramas de Sequência | Fluxos entre componentes do sistema detalhados para facilitar o entendimento técnico | -| | **Discussões Técnicas** | Definição de Padrões | Reuniões entre desenvolvedores | Estratégias alinhadas para resolver dependências e implementar requisitos | -| | **Validação de Conclusão** | Planejamento Visual | Kanban, Definition of Done (DoD) | Funcionalidades validadas conforme critérios predefinidos e organizadas visualmente | -| | **Revisão do Backlog** | Alinhamento Estratégico | Critérios DEEP, Priorização WSJF | Backlog refinado, com tarefas organizadas, priorizadas e alinhadas com os objetivos | -| **Execução da Sprint** | **Alinhamento Diário** | Planejamento Operacional | Daily Scrum | Progresso da equipe alinhado diariamente, com impedimentos identificados e resolvidos rapidamente | -| | **Desenvolvimento Colaborativo** | Colaboração entre Desenvolvedores | Pair Programming | Código desenvolvido com maior qualidade e compartilhamento de conhecimento entre os membros da equipe | -| | **Validação de Interface** | Prototipagem Ágil | Protótipos | Interface e fluxo validados antes do desenvolvimento completo, reduzindo retrabalho | -| | **Garantia de Qualidade** | Revisão Contínua | Revisões de Código, Testes Automatizados | Funcionalidades desenvolvidas com qualidade garantida e alinhadas aos requisitos | -| | **Rastreamento do Progresso** | Monitoramento Visual | Kanban | Progresso visualizado e rastreado continuamente, com itens atualizados durante a sprint | -| **Revisão da Sprint** | **Verificação e Validação** | Definição de requisitos a serem apresentados | Checklist de Validação, Checklist de Verificação, Definition of Done (DoD) | Lista de requisitos que serão apresentados ao cliente para revisão | -| | **Verificação e Validação** | Aprovação ou rejeição dos requisitos implementados | Feedback do cliente, Revisão informal | Requisito concluído, lista de modificações a serem feitas | -| | **Análise e Consenso** | Definição de novos requisitos | Análise de Custo / Benefício, Análise de Risco / Viabilidade, Casos de Uso | Lista de Requisitos RFs e RNFs com base nas modificações solicitadas pelo cliente | -| **Retrospectiva da Sprint** | **Feedback da Equipe** | Análise e Organização | Discussões em Grupo | Opiniões coletadas sobre pontos positivos e desafios enfrentados na sprint | -| | **Definição de Ações Corretivas** | Atualização do Processo | Planejamento de Melhorias | Medidas planejadas para resolver problemas e melhorar a eficiência do time | -| **Planejamento da Próxima Release** | **Organização e Atualização** | Revisão dos Requisitos Pendentes | Revisão do backlog | Requisitos alinhados e priorizados novamente | -| | **Análise e Consenso, Representação** | Priorização e Seleção de Requisitos | Técnica MoSCoW | Backlog organizado | -| | **Análise e Consenso** | Estimativas de Esforço e Tempo | Planning Poker | Previsão de cronograma | -| | **Análise e Consenso** | Definição dos Objetivos da Release | Brainstorm, reuniões entre a equipe, entrevistas | Metas da release definidas | diff --git "a/docs/intera\303\247\303\243o/composi\303\247\303\243o.md" b/docs/produto/interacao.md similarity index 100% rename from "docs/intera\303\247\303\243o/composi\303\247\303\243o.md" rename to docs/produto/interacao.md diff --git a/docs/produto/solucao.md b/docs/produto/solucao.md index 5fc2be8..17a6b87 100644 --- a/docs/produto/solucao.md +++ b/docs/produto/solucao.md @@ -1,12 +1,10 @@ -## SOLUÇÃO PROPOSTA - -### Objetivos do Produto +## Objetivos do Produto O objetivo da plataforma gamificada da Ideia Space é acompanhar o aprendizado do aluno para além das atividades presenciais, proporcionando um ambiente digital que permita o estudo contínuo em STEAM. A plataforma usa questionários e mecânicas de gamificação para capturar métricas de conhecimento que possibilitam que o educador acompanhe o nível de compreensão dos alunos fora do ambiente escolar. --- -### Características da Solução +## Características da Solução A solução será desenvolvida em torno das seguintes características: @@ -17,7 +15,7 @@ A solução será desenvolvida em torno das seguintes características: --- -### Tecnologias a Serem Utilizadas +## Tecnologias a Serem Utilizadas - **React**: Utilizado no frontend para criar uma interface de usuário responsiva e interativa, permitindo que alunos e educadores acessem as funcionalidades da plataforma de forma dinâmica. - **FastAPI**: Framework backend para desenvolvimento de APIs seguras e escaláveis, gerenciando dados dos alunos, autenticação e funcionalidades da plataforma. @@ -26,7 +24,7 @@ A solução será desenvolvida em torno das seguintes características: --- -### Pesquisa de Mercado e Análise Competitiva +## Pesquisa de Mercado e Análise Competitiva No mercado de startups de educação, as principais concorrentes da Ideia Space incluem empresas como **Happy Code** e **Br.ino**. Essas plataformas já oferecem softwares direcionados para alunos, com gamificação e funcionalidades básicas de aprendizado. No entanto, ambas apresentam escopos diferentes: @@ -38,12 +36,12 @@ A solução da Ideia Space irá se diferenciar por: - **Acompanhamento do aluno**: O educador acompanhará o progresso do aluno de acordo com a atividade feita. - **Abrangência de público**: O software abrangerá alunos de diversas faixas etárias, não se restringindo a apenas o público infanto-juvenil. -### Análise de Viabilidade +## Análise de Viabilidade A viabilidade técnica do projeto é alta, considerando que a equipe já possui conhecimentos essenciais nas tecnologias planejadas. O cliente demonstrou interesse e disponibilidade para acompanhar e entregar feedbacks constantes sobre o produto, o que facilita eventuais correções de erros e evita entregas que não agregam valor ao produto. --- -### Impacto da Solução +## Impacto da Solução Com uma plataforma gamificada, os estudantes terão acesso a uma experiência de aprendizado interativa e acessível, promovendo o engajamento contínuo e aprofundando o conhecimento em áreas de STEAM. Para a equipe pedagógica, a plataforma oferece uma ferramenta prática para monitorar o desempenho dos alunos, permitindo que adaptem suas estratégias com base em dados reais. Para a empresa, essa solução representa a oportunidade de se consolidar como uma referência em inovação educacional. diff --git a/docs/produto/visao-produto-projeto.md b/docs/produto/visao-produto-projeto.md index beb1d42..08146c1 100644 --- a/docs/produto/visao-produto-projeto.md +++ b/docs/produto/visao-produto-projeto.md @@ -1,23 +1,4 @@ -# Ideia Space - Visão do Produto e Projeto - -**Versão 1.0** - -Link para o vídeo da apresentação: [Google Drive](https://drive.google.com/file/d/1OF8X91xykGekYA8f2y5i1VYCJQ4NEa9C/view) - -## Histórico de Revisão - -| Data | Versão | Descrição | Autor | -|------------|--------|-----------------------|----------------| -| 01/11/24 | 1.0 | Criação do documento | Edilson Ribeiro | -| 04/11/24 | 1.0 | Correções do documento | Matheus Brant | - ---- - -# VISÃO DO PRODUTO E PROJETO - -## CENÁRIO ATUAL DO CLIENTE E DO NEGÓCIO - -### Introdução ao Negócio e Contexto +## Introdução ao Negócio e Contexto A Ideia Space é uma startup brasileira de educação que nasceu com o propósito de melhorar a qualidade do ensino no país, especialmente nas áreas de STEAM (Ciência, Tecnologia, Engenharia, Artes e Matemática). Voltada para estudantes e instituições de ensino que buscam novas metodologias, a Ideia Space leva suas atividades diretamente às escolas, proporcionando uma experiência educativa prática e envolvente, sem a necessidade de um espaço físico próprio. 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. @@ -27,17 +8,18 @@ Com o objetivo de se tornar referência em educação na América Latina nos pr --- -### Identificação da Oportunidade ou Problema +## 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. 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. -> **Nota**: A figura a seguir apresenta o diagrama de Ishikawa contendo as causas (organizadas pelos 6M’s) e o problema da Ideia Space. +!!! note "Nota" + A figura a seguir apresenta o diagrama de Ishikawa contendo as causas (organizadas pelos 6M’s) e o problema da Ideia Space. ![Diagrama de Ishikawa](../assets/ishikawa.png) -### Desafios do Projeto +## Desafios do Projeto Os principais desafios no desenvolvimento do projeto para a Ideia Space envolvem incentivar o aprendizado tanto dentro quanto fora da sala de aula. Entretanto, existem claras dificuldades geradas pela falta de interatividade e a abordagem tradicional de ensino, que contribuem para o desinteresse e a distração, agravada pela presença de tecnologias que muitas vezes competem pela atenção dos estudantes. A ausência de métricas claras para avaliação também dificulta o trabalho dos educadores, tornando o processo de feedback e ajuste pedagógico ineficaz. @@ -45,7 +27,7 @@ Isso exige o desenvolvimento de mecânicas de gamificação eficazes e motivador --- -### Segmentação de Clientes +## Segmentação de Clientes A Ideia Space atende a dois principais segmentos de clientes: diff --git a/mkdocs.yml b/mkdocs.yml index a5577a5..e77d4e4 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -6,11 +6,12 @@ repo_name: IdeiaSpace nav: - Home: "index.md" - Visão de Produto e Projetos: - - Visão do Produto e Projeto: produto/visao-produto-projeto.md + - Cenário atual do cliente e do negócio: produto/visao-produto-projeto.md - Solução proposta: produto/solucao.md - Estratégias de Engenharia de Software: produto/estrategias.md - Cronograma e entregas: produto/cronograma-entregas.md - - Interação entre equipe e cliente: interação/composição.md + - Interação entre equipe e cliente: produto/interacao.md + - Apresentações: apresentacoes/index.md theme: name: material @@ -31,6 +32,20 @@ theme: toggle: icon: material/lightbulb-outline name: Light mode + icon: + admonition: + note: fontawesome/solid/note-sticky + abstract: fontawesome/solid/book + info: fontawesome/solid/circle-info + tip: fontawesome/solid/bullhorn + success: fontawesome/solid/check + question: fontawesome/solid/circle-question + warning: fontawesome/solid/triangle-exclamation + failure: fontawesome/solid/bomb + danger: fontawesome/solid/skull + bug: fontawesome/solid/robot + example: fontawesome/solid/flask + quote: fontawesome/solid/quote-left features: - search @@ -42,3 +57,11 @@ theme: extra_css: - stylesheets/style.css + +markdown_extensions: + - admonition + - pymdownx.details + - pymdownx.superfences + +plugins: + - mkdocs-video diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 0000000..95af4e4 --- /dev/null +++ b/requirements.txt @@ -0,0 +1 @@ +mkdocs-video