Desenvolver uma solução de dados voltada ao ensino à distância para a gestão e oferta de conhecimento, dando suporte às mais diversas arquiteturas de aprendizagem, alinhado com os objetivos estratégicos a serem alcançados por cada organização que atendemos como clientes. Fazer a gestão de logs para alimentar um Data Warehouse afim de possibilitar a melhor gestão estratégica do negócio.
✅ Sprint 1 | ✅ Sprint 2 | ✅ Sprint 3 | ✅ Sprint 4 |
---|
Para fazer o planejamento foi utilizado a metodologia de "Design Thinking". Segundo o wikipedia, Design Thinking é o conjunto de ideias e insights para abordar problemas, relacionados a futuras aquisições de informações, análise de conhecimento e propostas de soluções.
🔄O design thinking consiste em 5 partes ciclicas: empatia, definição, ideação, prototipo, teste.
- A primeira etapa (empatia) do primeiro ciclo foi realizada junto ao cliente.
- A etapa de definição é realizada durante as plannings do projeto.
- A etapa de ideação e prototipo são realizadas durante a sprint e
- A etapa de teste é realizada sempre que um prototipo vira funcionalidade através do fluxo de CI (continuous integration) e CD (continuous deploy/delivery) do projeto.
- 16/08/2021 até 22/08/2021 - Kick Off do Projeto
- 30/08/2021 até 19/09/2021 - Sprint 1
- 20/09/2021 até 10/10/2021 - Sprint 2
- 18/10/2021 até 07/10/2021 - Sprint 3
- 08/11/2021 até 28/11/2021 - Sprint 4
- 29/11/2021 até xx/12/2021 - Sprint Apresentação Final
- xx/xx/2021 até xx/xx/2021 - Sprint Feira de Soluções
Aqui é discutido o Gitflow Workflow. Gitflow é um dos muitos estilos de fluxos de trabalho Git que você e sua equipe podem utilizar.
Alguns dos principais aprendizados para saber sobre o Gitflow são:
- O fluxo de trabalho é ótimo para um fluxo de trabalho de software baseado em lançamento.
- O Gitflow oferece um canal dedicado de hotfixes para produção.
O fluxo geral do Gitflow é:
- Uma ramificação
development
é criada a partir damain
- Uma ramificação de
release
é criada a partir da ramificação dedevelopment
- As ramificações de
feature
são criadas a partir da ramificação dedevelopment
- Quando um
feature
é concluído, deve ser aberto um Pull Request paradevelopment
- Para completar o PR é necessário ser homologado pelo PO
- Quando a ramificação
release
é feita, é feito o merge dela na ramificaçãodevelopment
e namain
- Se for detectado um item na
main
, uma ramificação dehotfix
vai ser criada a partir damain
- Depois que o
hotfix
for concluído, existe o mesmo processo de homologação, ele passa por merge para a ramificaçãodevelopment
e àmain
No nosso projeto, configuramos o CI para realizar o build da aplicação e validar os teste unitários.
- Windows: https://docs.docker.com/desktop/windows/install/ obs.: Caso possua 2 hds e/ou queira uma melhor customização dos recursos utilizados, recomendo utilizar o Hyper-v no lugar do WSL (https://docs.microsoft.com/pt-br/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)
- Linux: https://docs.docker.com/engine/install/ubuntu/ || https://docs.docker.com/compose/install/
docker-compose -f <arquivo.yml> up -d
docker-compose <arquivo.yml> down
- Servidor do chat: http://157.245.243.16:3000/ (Importante que seja http por enquanto)
- Servidor Postgres: 157.245.243.16:5432
- Servidor Primary Mongo: 157.245.243.16:3002
- Portas Mongo Secundary: 3003, 3004
- Olap a. Visão Professor b. Visão Gestor c. Visão Administrador
Na descrição dos story cards, temos 4 personas: Aluno, Tutor, Gestor e Administrado.
- Como aluno, eu sou capaz de acessar o chat em tempo real para interagir/discutir com outros alunos e tutores;;
- Como tutor, eu sou capaz de acessar o chat do aluno para interagir/discutir com outros alunos;
- Como aluno, eu sou capaz de acessar o chatbot da plataforma para buscar orientações rápidas;
- Como aluno/tutor, eu sou capaz de acessar o sistema de LMS;
- Como gestor, eu sou capaz de adicionar/editar/excluir cursos;
- Como tutor, eu sou capaz de acessar um dashboard com painéis informativos específicos para tutoria;
- Como gestor, eu sou capaz de acessar um dashboard com painéis informativos específicos para gestão;
- Como administrador, eu sou capaz de acessar um dashboard com painéis informativos específicos para administração;
1 - Definir as tabelas FATO do Data Warehouse;
2 - Definir as dimensões e granularidade do Data Warehouse;
3 - Desenvolver um chat em tempo real com capacidade de até 1000 usuários simultâneos, capaz de gerar log das mensagens;
4 - Definir ferramentas para o pipeline ETL;
5 - Criar rotinas ETL da plataforma e do chat para alimentar o DW;
6 - Criar os dashboards OLAP com os indicadores requisitados;
7 - Definir os gráficos para visualização dos Dashboards;
8 - Criar um sistema OLAP com visualizações (com dados de testes) diferentes para os 3 tipos de usuário (Tutor, Gestor e ADM);
9 - Integrar o sistema OLAP com o Data Warehouse.
10 - Reestruturar os logs da aplicação de acordo com as métricas esperadas no Data Warehouse ( Ativação, Engajamento, Desempenho, Participação, Avaliação de reação, Registro do tempo de participação no curso)
11 - Refatorar a plataforma de LMS desenvolvida pela turma do 3º semestre de banco de dados (no primeiro semestre de 2021), para armazenar os dados dos logs em um banco de dados não-relacional;
12 - Criar rotinas para carregar os dados no Data Warehouse.
- Documentação completa e clara
- Facilidade de uso
- Segurança
- Escalabilidade
Gabriel Angelo | Fernanda Ramos | Nathan Nascimento | Paulo Filipini | Vitor Daniel |
---|---|---|---|---|
André Lars | Daniel Delgado | Felipe Braga | Giovanni Guidace | Jéssica Isri |
---|---|---|---|---|