diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml new file mode 100644 index 0000000..ae72d93 --- /dev/null +++ b/.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 diff --git a/docs/assets/ideaspace_icon.png b/docs/assets/ideaspace_icon.png new file mode 100644 index 0000000..28cc91e Binary files /dev/null and b/docs/assets/ideaspace_icon.png differ diff --git a/docs/assets/ideaspace_logo.png b/docs/assets/ideaspace_logo.png new file mode 100644 index 0000000..14e500d Binary files /dev/null and b/docs/assets/ideaspace_logo.png differ diff --git a/docs/assets/ishikawa.png b/docs/assets/ishikawa.png new file mode 100644 index 0000000..aed7070 Binary files /dev/null and b/docs/assets/ishikawa.png differ diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..8a0d495 --- /dev/null +++ b/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 + +
+ +
+ +

Caio Felipe

+
+ +
+ +

Edilson Ribeiro

+

Líder

+
+ +
+ +

Felipe Matheus

+
+ +
+ +

Igor Silva

+
+ +
+ +

Matheus Brant

+
+
\ No newline at end of file diff --git "a/docs/intera\303\247\303\243o/composi\303\247\303\243o.md" "b/docs/intera\303\247\303\243o/composi\303\247\303\243o.md" new file mode 100644 index 0000000..ada17e4 --- /dev/null +++ "b/docs/intera\303\247\303\243o/composi\303\247\303\243o.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. diff --git a/docs/produto/cronograma-entregas.md b/docs/produto/cronograma-entregas.md new file mode 100644 index 0000000..c5a1514 --- /dev/null +++ b/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
- Configuração da arquitetura (React, FastAPI, MongoDB)
- 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:
- Desenvolvimento do sistema de cadastro e autenticação de usuários
- 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
- 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:
- Implementação de mecânicas de gamificação
- 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
- 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:
- Integração das funcionalidades principais (autenticação, perguntas, gamificação e análise de dados)
- 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
- 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. diff --git a/docs/produto/estrategias.md b/docs/produto/estrategias.md new file mode 100644 index 0000000..d63e3a2 --- /dev/null +++ b/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. diff --git a/docs/produto/solucao.md b/docs/produto/solucao.md new file mode 100644 index 0000000..3414b31 --- /dev/null +++ b/docs/produto/solucao.md @@ -0,0 +1,50 @@ +## SOLUÇÃO PROPOSTA + +### 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 + +A solução será desenvolvida em torno das seguintes características: + +- A plataforma fará a integração de conteúdos multidisciplinares para gerar engajamento em alunos com diferentes interesses. +- O sistema fornecerá perguntas a respeito das seções de conteúdo estudadas pelo aluno, de forma a avaliar se o mesmo foi capaz de absorver o conteúdo. +- A plataforma contará com recursos para coleta de dados sobre o desempenho dos alunos, facilitando na reestruturação dos métodos de ensino dentro e fora da sala de aula. +- A plataforma precisa suportar um número elevado de alunos e contar com uma interface de fácil uso e bem estruturada, sem sobrecarregar o sistema. + +--- + +### 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. +- **Docker**: Ferramenta de conteinerização que isola os serviços da aplicação, assegurando portabilidade e consistência entre os ambientes de desenvolvimento e produção. +- **MongoDB**: Banco de dados para armazenamento flexível de informações sobre o progresso e atividades dos alunos, facilitando a análise de dados e o crescimento da plataforma. +- **Supabase**: Banco de dados como serviço que fornece um armazenamento flexível e seguro de informações sobre o progresso e atividades dos alunos, facilitando a análise de dados e o crescimento da plataforma. + +--- + +### 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: + +- **Happy Code**: A organização utiliza o aplicativo próprio “Stem Play”, porém é voltada apenas ao público infanto-juvenil e oferece um conteúdo específico oferecido pela plataforma. O educador não consegue visualizar o progresso feito pelo aluno. +- **Br.ino**: A organização oferece a própria IDE, porém a plataforma não apresenta para o educador uma forma de acompanhar o progresso do aluno ou uma aproximação gamificada que engaje o usuário. + +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 + +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 + +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. \ No newline at end of file diff --git a/docs/produto/visao-produto-projeto.md b/docs/produto/visao-produto-projeto.md new file mode 100644 index 0000000..9bfc30a --- /dev/null +++ b/docs/produto/visao-produto-projeto.md @@ -0,0 +1,52 @@ +# Ideia Space - Visão do Produto e Projeto + +**Versão 1.0** + +## 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 + +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. + +A missão da Ideia Space é tornar o aluno protagonista do processo educacional, utilizando a temática espacial como uma poderosa ferramenta de conexão e transformação. A startup busca engajar os jovens a identificar problemas e desenvolver soluções práticas, como a criação de missões espaciais e a construção de pequenos satélites, incentivando uma formação criativa e prática. + +Com o objetivo de se tornar referência em educação na América Latina nos próximos quatro anos, a Ideia Space baseia-se em valores como transformação, excelência, inovação, empoderamento, união, inspiração e respeito. + +--- + +### 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. + +![Diagrama de Ishikawa](../assets/ishikawa.png) + +### 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. + +Isso exige o desenvolvimento de mecânicas de gamificação eficazes e motivadoras, evitando que se tornem repetitivas. Identificar as técnicas de gamificação mais adequadas ao público-alvo e traduzi-las em funcionalidades que incentivem o engajamento é crucial para o sucesso do projeto. + +--- + +### Segmentação de Clientes + +A Ideia Space atende a dois principais segmentos de clientes: + +- **Estudantes do Ensino Fundamental e Médio**: São crianças e adolescentes entre 6 e 19 anos que estão no momento de sua formação acadêmica e pessoal, tendo conhecimentos variáveis a respeito das tecnologias do projeto. Eles buscam atividades para aprender de forma prática e divertida, especialmente nas áreas de STEAM. Por meio de atividades inovadoras, como a criação de missões espaciais, eles se envolvem em projetos que estimulam a criatividade, a resolução de problemas e o trabalho em equipe. + +- **Equipe Pedagógica**: Esse grupo faz parte da organização e possui formação em áreas de STEAM, entretanto têm pouco conhecimento sobre as tecnologias a serem utilizadas. Além da educação, buscam também engajar e monitorar o conhecimento de seus alunos fora da sala de aula. diff --git a/docs/stylesheets/style.css b/docs/stylesheets/style.css new file mode 100644 index 0000000..132e889 --- /dev/null +++ b/docs/stylesheets/style.css @@ -0,0 +1,12 @@ +.md-header__button.md-logo { + margin-top: 0; + margin-bottom: 0; + padding-top: 0; + padding-bottom: 0; +} + +.md-header__button.md-logo img, +.md-header__button.md-logo svg { + height: 70px; + width: 70px; +} diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..cb82ceb --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,44 @@ +site_name: Documentação IdeiaSpace + +repo_url: https://github.com/mdsreq-fga-unb/2024.2-T01-IdeaSpace +repo_name: IdeiaSpace + +nav: + - Home: "index.md" + - Visão de Produto e Projetos: + - Estratégias de Engenharia de Software: produto/estrategias.md + - Interação entre equipe e cliente: interação/composição.md + - Cronograma e entregas: produto/cronograma-entregas.md + - Solução proposta: produto/solucao.md + - Visão do Produto e Projeto: produto/visao-produto-projeto.md + +theme: + name: material + favicon: assets/ideaspace_icon.png + logo: assets/ideaspace_icon.png + + palette: + - scheme: default + primary: "indigo" + accent: "pink" + toggle: + icon: material/lightbulb + name: Dark mode + + - scheme: slate + primary: "indigo" + accent: "pink" + toggle: + icon: material/lightbulb-outline + name: Light mode + + features: + - search + - navigation.tabs + - navigation.tabs.sticky + - navigation.sections + - navigation.path + - navigation.top + +extra_css: + - stylesheets/style.css