Home

Sprint 1, CAMAAR

1. Identificação do Grupo

Nome	Matrícula	Papel
Ana Paula Gomes de Matos	160023629	Product Owner
Gustavo Choueiri	232014010	Scrum Master
Analyce Rayssa Silva Nunes	211026548	Desenvolvedora
Marcus Paulo Kaller Vargas	200041096	Desenvolvedor
Rafael Carvalho Junior Araujo	222021817	Desenvolvedor

2. Projeto

O projeto CAMAAR tem como objetivo apoiar a gestão de avaliações acadêmicas remotas. A aplicação será desenvolvida em Ruby on Rails e permitirá o gerenciamento de usuários, turmas, disciplinas, templates de formulários, formulários de avaliação, respostas e resultados.

3. Escopo da Sprint 1

A Sprint 1 foi dividida em duas etapas.

Na primeira etapa, o grupo estudou as histórias de usuário disponíveis no repositório, elaborou o modelo Entidade Relacionamento do sistema CAMAAR e realizou uma investigação técnica sobre a possível implementação das views em Ruby on Rails.

Na segunda etapa, o grupo especificou os cenários BDD das histórias de usuário usando Cucumber. As funcionalidades ainda não foram implementadas nesta sprint, pois a implementação será realizada na Sprint 2.

4. Papéis no Scrum

Product Owner

A Product Owner da Sprint 1 foi a Ana Paula Matos.

Responsabilidades:

1. Priorizar as histórias de usuário.
2. Definir a complexidade das histórias junto ao grupo.
3. Revisar as regras de negócio.
4. Validar se os cenários BDD estão coerentes com as histórias de usuário.
5. Preparar o arquivo de entrega com link do repositório, nomes e matrículas.
6. Fazer documentação na wiki.

Scrum Master

O Scrum Master da Sprint 1 foi o Gustavo Choueiri.

Responsabilidades:

1. Organizar a branch da sprint.
2. Garantir que cada integrante realize seus próprios commits.
3. Acompanhar o andamento das tarefas.
4. Organizar a Pull Request da Sprint 1.
5. Apoiar a criação da Wiki e a organização do repositório.

5. Política de Branching

O grupo utilizou a branch sprint-1 para concentrar as entregas da primeira sprint.

A política adotada foi:

1. A branch sprint-1 deve conter somente os artefatos relacionados à Sprint 1.
2. Cada integrante deve realizar commit das próprias modificações.
3. Ao final da sprint, deve ser aberta uma única Pull Request do grupo.
4. Após a abertura da Pull Request, a branch sprint-1 não deve receber novos commits.
5. A Pull Request deve ser enviada para o repositório principal do projeto.

6. Organização das Histórias de Usuário

As histórias funcionais do sistema foram organizadas em quatro blocos principais.

Bloco 1, Acesso e Usuários

Responsável: Analyce

Issues:

1. #13, Sistema de Login
2. #12, Sistema de definição de senha
3. #10, Redefinição de senha
4. #17, Cadastrar usuários do sistema

Bloco 2, Dados Acadêmicos e Permissões

Responsável: Marcus

Issues:

1. #19, Importar dados do SIGAA
2. #9, Atualizar base de dados com os dados do SIGAA
3. #11, Sistema de gerenciamento por departamento

Bloco 3, Templates e Criação de Formulários

Responsável: Rafael

Issues:

1. #15, Criar template de formulário
2. #6, Visualização dos templates criados
3. #5, Edição e deleção de templates
4. #14, Criar formulário de avaliação
5. #4, Criação de formulário para docentes ou discentes

Bloco 4, Participante, Respostas e Resultados

Responsável: Choueiri

Issues:

1. #8, Visualização de formulários para responder
2. #18, Responder formulário
3. #7, Visualização de resultados dos formulários
4. #16, Gerar relatório do administrador

7. Pontuação das Histórias de Usuário

A pontuação das histórias foi definida usando a escala de Fibonacci, considerando complexidade, regras de negócio, dependências entre funcionalidades, quantidade de entidades envolvidas, telas necessárias e esforço esperado para testes.

Bloco	Issues	Pontuação
Bloco 1, Acesso e Usuários	#13, #12, #10, #17	14
Bloco 2, Dados Acadêmicos e Permissões	#19, #9, #11	21
Bloco 3, Templates e Criação de Formulários	#15, #6, #5, #14, #4	29
Bloco 4, Participante, Respostas e Resultados	#8, #18, #7, #16	26

Velocity planejada da Sprint 1:

90 pontos

Detalhamento da pontuação

Issue	História de usuário	Pontos
#13	Sistema de Login	3
#12	Sistema de definição de senha	3
#10	Redefinição de senha	3
#17	Cadastrar usuários do sistema	5
#19	Importar dados do SIGAA	8
#9	Atualizar base de dados com dados do SIGAA	8
#11	Sistema de gerenciamento por departamento	5
#15	Criar template de formulário	8
#6	Visualização dos templates criados	3
#5	Edição e deleção de templates	5
#14	Criar formulário de avaliação	8
#4	Criação de formulário para docentes ou discentes	5
#8	Visualização de formulários para responder	5
#18	Responder formulário	8
#7	Visualização de resultados dos formulários	8
#16	Gerar relatório do administrador	5

8. Regras de Negócio

8.1 Bloco 1, Acesso e Usuários

#13, Sistema de Login

1. O usuário deve conseguir acessar o sistema usando e-mail ou matrícula e senha cadastrada.
2. O sistema não deve permitir acesso com senha incorreta.
3. O sistema não deve permitir acesso com e-mail ou matrícula inexistente.
4. Após login válido, o usuário deve ser redirecionado conforme seu perfil.
5. Usuários administradores devem visualizar a opção de gerenciamento no menu lateral.
6. Usuários comuns não devem visualizar opções administrativas.

#12, Sistema de definição de senha

1. Um usuário recém-cadastrado deve definir sua senha antes de acessar o sistema.
2. A definição de senha deve ocorrer a partir do link recebido por e-mail.
3. O sistema deve validar se o link de definição de senha é válido.
4. O sistema não deve aceitar senha vazia.
5. O sistema deve salvar a senha de forma segura.
6. Após definir a senha, o usuário deve conseguir acessar o sistema.

#10, Redefinição de senha

1. O usuário deve conseguir solicitar a redefinição de senha pelo e-mail cadastrado.
2. O sistema deve enviar um link de redefinição para o e-mail do usuário.
3. O sistema não deve permitir redefinição com link inválido ou expirado.
4. A nova senha não pode ser vazia.
5. Após redefinir a senha, a senha anterior não deve mais permitir acesso.
6. O usuário deve conseguir fazer login com a nova senha.

#17, Cadastrar usuários do sistema

1. O administrador deve conseguir cadastrar usuários a partir dos dados importados do SIGAA.
2. Usuários já existentes não devem ser duplicados.
3. O cadastro inicial deve gerar uma solicitação de definição de senha.
4. O usuário só deve ser considerado apto a acessar o sistema após definir sua senha.
5. O sistema deve associar corretamente o usuário ao seu perfil.
6. O sistema deve manter vínculo entre usuário, turma, matrícula e departamento quando aplicável.

8.2 Bloco 2, Dados Acadêmicos e Permissões

#19, Importar dados do SIGAA

1. O administrador deve conseguir importar dados de turmas, matérias e participantes do SIGAA.
2. A importação deve considerar os arquivos JSON disponíveis no repositório.
3. O sistema deve criar apenas registros que ainda não existam na base.
4. Turmas, disciplinas, docentes, discentes e matrículas devem ser associadas corretamente.
5. Dados inválidos ou incompletos não devem ser importados sem validação.
6. Ao final da importação, os dados devem ficar disponíveis para uso nas funcionalidades de formulários.

#9, Atualizar base de dados com dados do SIGAA

1. O administrador deve conseguir atualizar a base existente com dados atuais do SIGAA.
2. Registros já existentes devem ser atualizados, não duplicados.
3. Novos registros encontrados nos dados do SIGAA devem ser adicionados.
4. A atualização deve preservar vínculos já existentes quando possível.
5. A base atualizada deve refletir corretamente turmas, disciplinas, usuários e matrículas.
6. Dados inválidos devem ser tratados sem comprometer a base existente.

#11, Sistema de gerenciamento por departamento

1. O administrador deve gerenciar apenas turmas do departamento ao qual pertence.
2. Um administrador não deve visualizar ou alterar turmas de outros departamentos.
3. A filtragem por departamento deve ser aplicada nas telas administrativas.
4. Ao criar formulários, o administrador só deve selecionar turmas do seu departamento.
5. Ao visualizar resultados, o administrador só deve acessar dados do seu departamento.
6. Usuários sem perfil administrativo não devem acessar funcionalidades de gerenciamento.

8.3 Bloco 3, Templates e Criação de Formulários

#15, Criar template de formulário

1. O administrador deve conseguir criar um template de formulário.
2. O template deve conter um título.
3. O template deve conter uma ou mais questões.
4. Cada questão deve possuir um tipo, como aberta ou múltipla escolha.
5. Questões de múltipla escolha devem possuir opções de resposta.
6. O template criado deve ficar disponível para gerar formulários de avaliação.

#6, Visualização dos templates criados

1. O administrador deve conseguir visualizar os templates existentes.
2. A listagem deve exibir informações básicas do template.
3. O administrador deve conseguir identificar quais templates pode editar ou deletar.
4. Templates inexistentes não devem ser exibidos.
5. Usuários sem permissão administrativa não devem acessar a tela de templates.

#5, Edição e deleção de templates

1. O administrador deve conseguir editar um template criado.
2. O administrador deve conseguir deletar um template criado.
3. A edição de um template não deve alterar formulários já criados a partir dele.
4. A deleção de um template não deve apagar formulários já enviados.
5. O sistema não deve permitir editar ou deletar template inexistente.
6. O sistema deve preservar o histórico dos formulários já criados.

#14, Criar formulário de avaliação

1. O administrador deve conseguir criar um formulário baseado em um template.
2. O administrador deve escolher uma ou mais turmas para receber o formulário.
3. O formulário criado deve copiar as questões do template selecionado.
4. O formulário deve ficar vinculado à turma escolhida.
5. O sistema não deve criar formulário sem template.
6. O sistema não deve criar formulário sem turma selecionada.

#4, Criação de formulário para docentes ou discentes

1. O administrador deve escolher se o formulário será destinado a docentes ou discentes.
2. O público-alvo escolhido deve determinar quem poderá visualizar e responder o formulário.
3. Discentes não devem visualizar formulários destinados apenas a docentes.
4. Docentes não devem visualizar formulários destinados apenas a discentes, exceto quando possuírem permissão administrativa.
5. O formulário deve permanecer associado à turma escolhida.
6. O sistema deve impedir criação de formulário sem público-alvo definido.

8.4 Bloco 4, Participante, Respostas e Resultados

#8, Visualização de formulários para responder

1. O participante deve visualizar apenas formulários das turmas em que está matriculado.
2. O participante deve visualizar apenas formulários ainda não respondidos.
3. Formulários já respondidos não devem aparecer como pendentes.
4. Formulários de turmas em que o participante não está matriculado não devem ser exibidos.
5. Se não houver formulários pendentes, o sistema deve informar que não existem avaliações disponíveis.
6. O participante deve conseguir escolher qual formulário deseja responder.

#18, Responder formulário

1. O participante deve conseguir responder um formulário disponível.
2. O sistema deve salvar as respostas vinculadas ao participante e ao formulário.
3. O sistema não deve permitir envio de formulário sem responder questões obrigatórias.
4. O sistema não deve permitir que o mesmo participante responda o mesmo formulário mais de uma vez.
5. Após o envio, o formulário deve deixar de aparecer como pendente para aquele participante.
6. As respostas devem ficar disponíveis para consulta nos resultados administrativos.

#7, Visualização de resultados dos formulários

1. O administrador deve conseguir visualizar os formulários criados.
2. O administrador deve conseguir acessar os resultados de um formulário.
3. O sistema deve exibir respostas associadas ao formulário selecionado.
4. Questões de múltipla escolha podem ser exibidas de forma agregada.
5. Questões abertas devem exibir o conteúdo textual das respostas.
6. O administrador não deve acessar resultados de formulários fora de sua permissão.

#16, Gerar relatório do administrador

1. O administrador deve conseguir gerar um relatório em formato CSV.
2. O relatório deve conter os resultados de um formulário selecionado.
3. O sistema não deve gerar relatório para formulário inexistente.
4. O sistema não deve gerar relatório sem respostas ou deve informar que não há dados disponíveis.
5. O arquivo CSV deve conter informações suficientes para análise do desempenho da turma.
6. O administrador só deve gerar relatórios de formulários que tem permissão para acessar.

9. Cenários BDD

Os cenários BDD foram especificados usando Cucumber e organizados na pasta features.

Arquivos criados:

1. features/acesso_usuarios.feature
2. features/dados_academicos.feature
3. features/templates_formularios.feature
4. features/participante_resultados.feature

Cada funcionalidade possui pelo menos um cenário feliz e um cenário triste.

10. Pull Request

A Sprint 1 será entregue por meio de um única Pull Request contendo os arquivos de especificação BDD.

Link do Pull Request:

[COLOCAR LINK DO PR AQUI]

11. Status das Entregas

Entrega	Status
Modelo Entidade Relacionamento	Concluído
Relatório da primeira etapa	Concluído
Investigação técnica das views em Rails	Concluído
Cenários BDD com Cucumber	Concluído
Wiki da Sprint 1	Concluído
Pull Request da Sprint 1	Concluído
Arquivo .txt para entrega no Aprender	Concluído

12. Observações Finais

A Sprint 1 teve como objetivo compreender o domínio do sistema, modelar suas entidades principais e especificar os cenários de aceitação das histórias de usuário. As funcionalidades descritas nesta Wiki servirão como base para a implementação na Sprint 2 e para a posterior refatoração, documentação e avaliação de qualidade na Sprint 3.

13. Documentação Sprint 1

• Relatório
• Arquivo com link do repositório: