-
Notifications
You must be signed in to change notification settings - Fork 0
Documentação e Implementação: Sprint 2
Segue a documentação da implementação das Issues do nosso projeto, com todo os dados de como foram realizadas:
Para a criação do banco de dados, foram feitas as migrations necessárias para gerar todas as entidades, além de definidas models e controllers básicos. Todos os arquivos precisaram ser alterados posteriormente para adicionar algumas relações, chaves estrangeiras entre outras pequenas customizações para que tudo funcionasse do jeito que está prevista nas histórias de usuário.
Foi utilizado o SQLite como nosso banco de dados, pois é a configuração padrão do Rails. Para popular o banco de dados, foi criado uma seed presente em 'project/db/seed.rb'
Para a criação das rotas, foi utilizado o modelo de Controller e Models do Rails, com os Controllers fornecendo as rotas e impondo as regras de negócio. Todas as rotas necessárias para desenvolver as histórias de usuário com a etique MVP foram implementadas, assim como as rotas padrão que são geradas ao criar as entidades. Para os testes unitários, foram usadas as ferramentas do RSpec, onde foram definidas Factories para fornecer os objetos necessários para testes. No diretório 'project/spec' estão testes para o Controller (testa regras de negócio), Models (Simulando o comportamento da interação entre aplicação e banco de dados) e testes de Request (testa o fluxo completo da requisição HTTP)
Os testes de cenários BDD foram escritos em linguagem natural estruturada, utilizando o Cucumber com a sintaxe Gherkin, sendo possível descrever o comportamento do sistema do ponto de vista do usuário. Cada cenário é composto por passos no estilo "Given When Then", que são associados com métodos Ruby chamados step_definitions. Assim, na pasta 'project/features/step_definitions' estão os passos de testes definidos para cada história de usuário das features que foram implementadas.
Cada integrante do grupo foi responsável por implementar as features que foram escolhidas na primeira sprint. Para cada integrante, o objetivo era implementar individualmente suas histórias de usuário e focar, depois de concluído, iniciar o momento de integração das etapas, que se mostrou simples por causa da arquitetura do framework Rails, em que todas as regras e definições se encontram organizadas na estrutura do projeto.
No final, nós conseguimos implementar as seguintes features:
| Funcionalidade / História de Usuário | Link da Issue | Pontos (Estimativa) | Responsável | Completa? |
|---|---|---|---|---|
| Admin criar template para formulários | Issue #102 | 3 | Rafael | SIM |
| Usuário (participante) responder questionário da turma | Issue #99 | 2 | Gabriel | SIM |
| Admin criar formulário a partir de um template para as turmas | Issue #103 | 3 | Rafael | SIM |
| Admin criar formulário a partir de um template para alunos ou professores (Bônus) | Issue #113 | 2 | Luiz | NÃO |
| Admin exportar resultados de formulário como um arquivo CSV | Issue #101 | 5 | Gabriel | SIM |
| Admin editar e deletar templates criados | Issue #112 | 5 | Rafael | SIM |
| Admin importar dados do SIGAA | Issue #98 | 2 | Luiz | SIM |
| Usuário fazer login no sistema | Issue #104 | 2 | Diego | SIM |
| Admin gerenciar turmas do departamento pertencente (Bônus) | Issue #106 | 1 | Luiz | NÃO |
| Usuário definir senha no primeiro acesso via e-mail de cadastro | Issue #105 | 3 | Diego | SIM |
| Usuário redefinir senha a partir do e-mail (Bônus) | Issue #107 | 3 | Diego | SIM |
| Administrador cadastrar participantes de turmas do SIGAA | Issue #100 | 3 | Diego | SIM |
| Administrador gerenciar templates criados | Issue #111 | 2 | Rafael | SIM |
| Admin atualizar base de dados existente com dados atuais do SIGAA | Issue #108 | 2 | Luiz | SIM |
| Usuário visualizar formulários não respondidos de suas turmas | Issue #109 | 2 | Gabriel | SIM |
| Admin ver formulários criados e gerar relatório de respostas | Issue #110 | 5 | Gabriel | SIM |
| Carga Total Planejada (Pontos de Story) | — | 45 | — | - |
Para criar um template, o administrador pode adicionar quantas perguntas quiser antes de salvar. Cada clique no botão "+" recarrega a tela com um campo extra de pergunta, sem gravar nada no banco ainda. Só quando o admin confirma é que tudo é salvo de uma vez, e o sistema impede salvar perguntas sem texto.
Quando um formulário é criado a partir de um template, as perguntas são copiadas para o formulário, então mudanças futuras no template não afetam formulários já criados. O público-alvo do formulário também é copiado do template, e todo formulário novo começa em estado "rascunho" e precisa estar vinculado a um template e a uma turma.
Cada admin só vê os próprios templates na lista, que mostra título, público-alvo e quantidade de perguntas. Só quem criou o template pode editá-lo ou excluí-lo; se outro admin tentar, é redirecionado com um aviso. Hoje essa é a única proteção, já que o sistema ainda não tem login.
Excluir um template não exclui os formulários criados a partir dele, eles só perdem o vínculo com o template original, mas continuam funcionando normalmente, já que suas perguntas foram copiadas e não dependem mais dele. Ao editar um template, as perguntas existentes são atualizadas e as novas são adicionadas, com validação aplicada só às novas.
Nesta sprint foram implementadas as funcionalidades relacionadas ao acesso dos usuários ao
sistema. Foi utilizado um modelo único User para representar administradores e participantes,
com o campo role diferenciando os perfis admin e participant. A autenticação foi feita com
has_secure_password, permitindo que o usuário faça login usando e-mail ou matrícula e senha.
Também foram adicionadas as rotas necessárias para os fluxos de autenticação:
-
GET /loginePOST /login, para entrada no sistema; -
DELETE /logout, para encerramento da sessão; -
GET/PATCH /senha/definir/:token, para definição da primeira senha; -
GET/POST /senha/esqueci, para solicitação de redefinição de senha; -
GET/PATCH /senha/redefinir/:token, para redefinição da senha; -
POST /imports/class_members, para importação de participantes do SIGAA.
Foi implementado o serviço Sigaa::ClassMembersImporter, responsável por ler o arquivo
class_members.json, cadastrar participantes como usuários do sistema, associá-los às turmas
correspondentes e enviar um e-mail com link para definição da primeira senha.
A importação foi implementada de forma a que se um usuário já existir com o mesmo
e-mail ou matrícula, ele não é duplicado. Também foi criada a entidade ImportInconsistency,
usada para registrar registros inválidos, como participantes sem e-mail ou matrícula, sem
interromper o processamento dos demais participantes válidos.
O sistema agora permite que usuários acessem a aplicação usando e-mail ou matrícula e senha. Usuários administradores visualizam opções administrativas, enquanto participantes visualizam apenas as opções correspondentes ao seu perfil. Usuários que ainda não definiram senha não conseguem acessar o sistema até concluir o fluxo de definição da primeira senha.
Usuários importados inicialmente ficam sem senha definida. O sistema gera um token de definição de senha e envia um link por e-mail. Ao acessar esse link, o usuário informa e confirma a nova senha. O sistema valida se a confirmação confere e invalida o token após a senha ser salva.
Também foi implementado o fluxo de recuperação de senha. O usuário informa seu e-mail na página de “esqueci minha senha” e, caso o e-mail esteja cadastrado, recebe um link de redefinição. A mensagem exibida é genérica para não revelar se um e-mail está ou não cadastrado no sistema. Tokens expirados ou inválidos não permitem alteração da senha.
O administrador agora possui uma interface centralizada de listagem (Index) onde pode gerenciar todos os formulários criados por ele. A tela exibe as informações essenciais de forma consolidada, incluindo o título do formulário, a turma vinculada e o status atual. A partir desta listagem, o administrador pode navegar para os detalhes do formulário e acessar a área de resultados.
Para os participantes (alunos), foi construída uma listagem dinâmica que funciona como um painel de tarefas pendentes. O FormulariosController realiza uma consulta otimizada no banco de dados que cruza as turmas em que o usuário está matriculado (current_user.course_classes) e filtra ativamente os formulários, ocultando aqueles que já possuem um registro associado na tabela de Submissao para o usuário logado. Caso o aluno já tenha respondido a todas as avaliações, o sistema exibe uma mensagem de feedback informando que não há pendências.
Os participantes podem acessar os questionários pendentes e submeter suas avaliações (notas). Para garantir a integridade e sincronização com o esquema do banco de dados, o RespostaController foi configurado para tratar a submissão em duas etapas transacionais: primeiro, cria-se uma Submissao (que serve de ponte para registrar que aquele usuário específico respondeu àquele formulário); em seguida, cria-se a entidade Respostum, que armazena a nota (valor_numerico) vinculada à questão. O sistema conta com validações na View e no Controller para impedir o processamento de envios com questões em branco.
Para facilitar a análise de desempenho das turmas, foi desenvolvida a funcionalidade de exportação de dados. Utilizando a biblioteca nativa csv do Ruby direto no Controller, o sistema itera sobre as respostas salvas e monta dinamicamente um arquivo .csv estruturado para download. Como regra de negócio e otimização de interface, o botão de exportação só é renderizado na tela se houver pelo menos uma submissão registrada no formulário, prevenindo a geração de planilhas vazias.
O serviço Sigaa::DataSynchronizer executa Sigaa::ClassMembersImporter, que importa os dados dos usuários do sistema e realiza o procedimento de cadastro, e Sigaa::ClassesImporter, que importa os dados das turmas/matérias presentes em classes.json, considerando quantos registros foram adicionados, atualizados, ou já sincronizados com o SIGAA.
Na seção de Projects do repositório, se encontra o Kanban criado para acompanhar o desenvolvimento das features do sistema. Acesse o quadro aqui!
A sprint seguiu as regras de formatação e pode ser encontrada com o nome Sprint-2