Sistema de Gerenciamento do EJC da Paróquia São Cristóvão

Transcrição

1 Universidade Federal de Campina Grande UFCG Centro de Engenharia Elétrica e Informática CEEI Departamento de Sistemas e Computação DSC Curso de Graduação em Ciência da Computação CCC Sistema de Gerenciamento do EJC da Paróquia São Cristóvão Sprint #2 Equipe: André Aranha Erickson Filipe Janderson Jason José Leandro Professor: Rohit Gheyi Disciplina: Laboratório de Engenharia de Software - LES Campina Grande, PB Março de 2011

2 Sprint #2 1. Planejamento Membros Product Owner Nome: Danielle Gomes Equipe André Farias Aranha Monteiro ( ) Erickson Filipe Guedes dos Santos ( ) Janderson Jason Barbosa Aguiar ( ) José Leandro de Assis ( ) Scrum Master Erickson Filipe Guedes dos Santos Product Backlog A Imagem 1, retirada da ferramenta online Acunote, mostra os itens atuais do Product Backlog. De acordo com modificações de requisitos do cliente, esses itens poderão ser alterados ou incrementados posteriormente. Como a prioridade, na ferramenta, é descrita numa escala de P0 a P5, consideramos P0 como prioridade alta, P1 como prioridade média, e P2 como prioridade baixa. Reunião diária e Planejamento da Sprint Quantas foram realizadas? Quem participou? Dia Participantes Presencial segunda-feira(14/03) André, Erickson, Janderson e Leandro Sim quarta-feira(16/03) André, Erickson e Janderson Não quinta-feira(17/03) André, Erickson e Janderson Sim sábado(19/03) André, Erickson, Janderson e Leandro Não domingo(20/03) André, Erickson, Janderson e Leandro Não

3 Contrariando o esperado, as reuniões não presenciais foram mais úteis que as presenciais, muito provavelmente, porque as reuniões presenciais foram feitas em horário de almoço, curta duração e o ambiente era pouco viável, pois tinha muito barulho e sem recursos. As reuniões não presenciais foram bastante úteis, pois foi onde vários impedimentos foram resolvidos, e com maior tempo de duração, era possível que os desenvolvedores pudessem se ajudar. Que impedimentos foram encontrados e como foram solucionados? Houve problemas na utilização do mercurial, onde um desenvolvedor, por questão de descuido, desconsiderou os arquivos enviados por outro, criando assim duas heads no repositório. Como três dos desenvolvedores estavam online no gtalk, e dois deles eram os envolvidos, foi decidido que nenhum deles deveria alterar o código enquanto o terceiro mesclava as heads consertando o repositório, logo o problema foi facilmente resolvido. O envio de arquivos do tipo *.class e *.log, que são gerados sempre que o servidor é rodado, também foi um impedimento encontrado desde a primeira sprint. Esses arquivos causavam conflitos quando era necessário atualizar seu projeto com o código do repositório, o que diminuía a produtividade, além de dificultar a visualização dos arquivos modificados em cada commit. A solução encontrada foi adicionar um arquivo.hgignore ao repositório em que foram descritos as extensões dos arquivos e pastas a serem ignorados nos commits.

4 Imagem 1 Product Backlog no Acunote Descrição geral do planejamento O planejamento desta sprint levou em consideração a experiência adquirida na sprint passada em relação ao conhecimento de groovy/grails. Por isso decidimos adiantar algumas funcionalidades nesta semana, colocando a maior parte dos CRUDs, além da implementação do login, recuperação de senha, restrições de acesso a determinadas páginas e ações. Entretanto, por questões gerenciais da disciplina, nem todas as funcionalidades serão consideradas para esta sprint (indicado posteriormente neste relatório). Com o término da sprint, o core do sistema estará quase pronto, faltando apenas o CRUD de evento, para que assim possamos implementar as outras funcionalidades além de novas que o cliente pode pedir, tratar detalhes de segurança e customizar a interface. Sprint Backlog De acordo com a Imagem 1, destacamos os itens na Imagem 2 como os itens realizados na semana desta segunda sprint:

5 Imagem 2 Itens do Product Backlog para a Semana da Sprint #2 Entretanto, seguindo os critérios da disciplina (quatro requisitos funcionais por sprint), consideraremos em sprints posteriores os itens Os usuários do sistema podem ser Visitantes (com visualização bastante restrita) ou Membros. Os membros, se forem cadastrados como Membros do J5, terão privilégios de criação/edição no sistema (administradores) e Recuperar senha. No geral, dividimos as atividades desenvolvidas na semana da Sprint #2 nas tarefas mostradas na Imagem 3. Nessa imagem (printscreen da ferramenta Acunote tirado no dia anterior a entrega) é possível ver o task board utilizado. No momento em que a imagem abaixo foi capturada, tínhamos ainda tínhamos cinco tarefas Not Started (to do), três atividades In progress (doing) e as demais Completed (Done). Imagem 3 - Tarefas da Semana da Sprint #2 cadastradas no Acunote.

6 Burndown Chart Imagem 4.1 Line Burndown (multiuser) O gráfico na imagem 4.1 é auto-explicativo, mas temos alguns pontos a considerar. A linha azul, que corresponde a André, não está como deveria, pois o mesmo ainda não se acostumou a atualizar o Acunote. Já a verde, Leandro, tem uma queda brusca, pois ele esteve sem internet durante a semana, e somente no sábado pôde começar suas atividades. Imagem 4.2 Line Burndown (team)

7 O gráfico 4.2 mostra que, mesmo com o citado acima para a imagem 4.1, conseguimos manter um bom ritmo de desenvolvimento durante toda a sprint. A velocidade da equipe, considerando os 4 membros e os 7 dias da semana, consistiu de 2h/dia de cada integrante. Vale ressaltar que as imagens 2, 3, 4.1 e 4.2 são relativas ao desenvolvimento da semana, pois se desconsiderássemos as tarefas realizadas a mais, haveria desenvolvedores sem muita participação nessa sprint, o que não ocorreu de fato. Mas, para deixar claras as funcionalidades que devem ser consideradas, o Acunote foi atualizado contemplando as duas versões (tarefas feitas na semana e tarefas a serem consideradas na semana). Os prints a seguir (imagens 5 e 6) refletem as tarefas a serem consideradas na disciplina para a Sprint #2. Imagem 5 Itens do Product Backlog para considerar na Sprint #2

8 Imagem 6 - Tarefas para considerar na Sprint #2 cadastradas no Acunote. Como não foi encontrado no Acunote opção para comparar o tempo estimado e o tempo gasto para as tarefas, criamos uma planilha com esse intuito, onde cada desenvolvedor coloca o tanto que gastou para realizar as suas atividades e a justificativa, caso tenha gasto mais tempo realizando as tarefas do que foi estimado, abaixo estão os gráficos e as justificativas:

9 André Erickson Janderson Leandro Justificativas Gastei tempo aprendendo Interceptors, que no final não estava como eu esperava. Gastei muito tempo estudando plugin, que acabei não usando, pois não encontrei um que fornecesse acesso aos controladores e views para adaptar ao sistema. Na implementação do login, foi necessário modificar a interface gráfica que já existia, e para não fazer trabalho sujo, acabei logo modificando a página inicial criada pelo grails, e modificando o template usado por todas as páginas do sistema. Os testes, planejados para uma hora, cada, demandaram aproximadamente isso mesmo. O tempo subestimado foi no planejamento relativo à implementação dos CRUDs, pensado como tarefa básica de 1h, cada, mas que demandaram mais tempo do que planejado, uma vez que as classes de domínio tinham dependências entre si e foi preciso entender melhor como essas classes deveriam funcionar no sistema. Gastei tempo estudando Views, que nunca tinha utilizado. E tive

10 problema também para gerar testes funcionais para Mudar Senha, tive que obter ajuda dos meus colegas do grupo. Defect Backlog A atualização de um usuário não Ativo para Ativo deveria ficar apto a logar. Textos com acentuação estão sendo exibidos de forma estranha, por causa da codificação 2. Requisitos, Implementação e Testes Os requisitos funcionais realizados, a serem considerados nesta segunda sprint, estão listados a seguir. Ao final da descrição de cada requisito, estão os testes funcionais correspondentes, que são relativos também aos testes de aceitação do cliente. Requisito Funcional Nome: Descrição: Fluxos de eventos Fluxo principal: CRUD de Encontro O sistema deve permitir que os encontros sejam cadastrados, pesquisados, atualizados ou removidos. Cada Encontro deverá ser formado por Dirigente Espiritual, Círculos, Data, Tema, Local e Equipes. Sendo possível, depois de criado, visualizar, atualizar esses dados e remover Encontro. 1. O sistema dá opção de criar novo encontro O usuário é criado com os seguintes dados sendo informados: Dirigente Espiritual Tema Data Local Círculos Equipes 1.2. O sistema verifica se os dados são válidos; 1.3. O sistema armazena os dados do encontro no banco de dados e informa que o cadastro foi realizado com sucesso. 2. O sistema dá opção de visualizar os dados cadastrados de encontro. 3. O sistema dá opção de atualizar os dados cadastrados de encontro O sistema verifica se os dados atualizados são válidos; 3.2. O sistema armazena os dados atualizados do encontro no banco de dados e informa que a atualização

11 Fluxo secundário 1: Fluxo secundário 2: Fluxo secundário 3: Fluxo secundário 4: foi realizada com sucesso. 4. O sistema dá opção de remover encontro O sistema atualiza o banco de dados. Se o Dirigente Espiritual não for informado no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Se a Data não for informada no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Se o Tema não for informado no ato de cadastro, ou se conter caracteres diferentes de letras, deverá ser exibida uma mensagem sobre o erro correspondente e continuar na tela de cadastro. Se o Local não for informado no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Teste 01 (Requisito funcional: CRUD de Encontro) Descrição: Teste de Encontro Válido Selecione, na criação de Encontro, um usuário válido como Dirigente Entrada: Espiritual, uma data válida, tema em Tema e local em Local. Selecione Criar. Saída: Usuário Cadastrado com Sucesso Teste 02 (Requisito funcional: CRUD de Encontro) Teste de Encontro Inválido (tema não deveria ter dígitos ou caracteres Descrição: especiais) Entrada: Digite aqui mesmo em Local e 123 em Tema. Saída: O campo Tema não atende ao padrão definido. Teste 03 (Requisito funcional: CRUD de Encontro) Descrição: Teste de Atualização de dados válidos de Encontro Entrada: Selecione um encontro cadastrado e coloque tema como novo tema e local como novo local. Clique em Update. Saída: Atualizações realizadas com sucesso Teste 04 (Requisito funcional: CRUD de Encontro) Descrição: Teste de Atualização de dados inválidos de Encontro Selecione um encontro cadastrado e coloque tema e local vazios. Entrada: Clique em Update. Saída: O tema e o local não podem ficar em branco. Teste 05 (Requisito funcional: CRUD de Encontro) Descrição: Teste de Remoção de Encontro Selecione Deletar Encontro a partir de um encontro previamente Entrada: visualizado. Saída: Encontro removido Requisito Funcional Nome: Descrição: CRUD de Circulo O sistema deve permitir que os círculos sejam cadastrados,

12 Fluxos de eventos Fluxo principal: Fluxo secundário 1: Fluxo secundário 2: Fluxo secundário 3: Fluxo secundário 4: pesquisados, atualizados ou removidos. Para cadastrar um círculo é necessário selecionar uma cor (cores prédefinidas). Para cadastrar um círculo, é necessário informar a cor, o nome e os participantes. Os participantes serão: um Jovem Coordenador, um Casal Apoio, e demais Jovens que estão fazendo ou farão o encontro. Os círculos existentes poderão ser listados, facilitando o controle dos que já existem e os que ainda faltam ser criados. O sistema permitirá a atualização dos dados de um círculo e sua possível remoção. 1. O sistema dá opção de criar novo círculo O círculo é criado com os seguintes dados sendo informados: Nome Círculo Cor Jovem Coordenador Casal Apoio Encontro Participantes 1.2. O sistema verifica se os dados são válidos; 1.3. O sistema armazena os dados do círculo no banco de dados e informa que o cadastro foi realizado com sucesso. 2. O sistema dá opção de visualizar os dados cadastrados do círculo. 3. O sistema dá opção de atualizar os dados cadastrados do círculo O sistema verifica se os dados atualizados são válidos; 3.2. O sistema armazena os dados atualizados do círculo no banco de dados e informa que a atualização foi realizada com sucesso. 4. O sistema dá opção de remover círculo O sistema atualiza o banco de dados. Se a Cor não for informada no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Se o Nome do Círculo não for informado no ato de cadastro, ou se conter caracteres diferentes de letras, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Se o Jovem Coordenador não for informado no ato de cadastro, deverá ser exibida uma mensagem sobre o erro correspondente e continuar na tela de cadastro. Se o Casal Coordenador não for informado no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Teste 01 (Requisito funcional: CRUD de Circulo) Descrição: Teste de Círculo Válido (apenas nome completo)

13 Digite Nome em Nome do Círculo, selecione Azul em Cor do Entrada: Círculo, usuários válidos em Jovem Coordenador e Casal Apoio, e selecione Criar. Saída: Círculo Cadastrado com Sucesso Teste 02 (Requisito funcional: CRUD de Circulo) Descrição: Teste de Círculo Inválido (nome do círculo inválido) Entrada: Saída: Selecione Criar sem selecionar/digitar nada. O círculo não será cadastrado, pois, mesmo que tenha usuários e cor selecionados automaticamente, terá campo Nome vazio, indicando esse erro. Teste 03 (Requisito funcional: CRUD de Circulo) Descrição: Teste de Atualização de dados válidos de Círculo Entrada: Selecione um círculo cadastrado e coloque Amarelo em Cor e novo nome em Nome. Clique em Update. Saída: Atualizações realizadas com sucesso Teste 04 (Requisito funcional: CRUD de Circulo) Descrição: Teste de Atualização de dados inválidos de Círculo Selecione um usuário cadastrado e digite n0v0 n0m3 em Nome. Entrada: Clique em Update. Saída: Nome inválido. Teste 05 (Requisito funcional: CRUD de Circulo) Descrição: Teste de Remoção de Círculo Selecione Deletar Círculo a partir de um círculo previamente Entrada: visualizado. Saída: Círculo removido. Requisito Funcional Nome: Descrição: Fluxos de eventos Fluxo principal: CRUD de EquipeDeTrabalho O sistema deve permitir que as equipes de trabalho sejam cadastradas, pesquisadas, atualizadas ou removidas. Cada equipe de trabalho tem um nome e é formada por coordenadores e encontreiros (membros da equipe). Os coordenadores podem ser até um casal e dois jovens. Para cadastrar uma equipe de trabalho é necessário selecionar um nome (equipes pré-definidas). Deve ser possível atualizar as pessoas que farão parte das equipes de trabalho. 1. O sistema dá opção de criar nova equipe de trabalho A equipe de trabalho é criada com os seguintes dados sendo informados: Nome Equipe Jovem Coordenador 1 Jovem Coordenador 2 Casal Coordenador Encontro Encontreiros

14 Fluxo secundário 1: 1.2. O sistema verifica se os dados são válidos; 1.3. O sistema armazena os dados da equipe de trabalho no banco de dados e informa que o cadastro foi realizado com sucesso. 2. O sistema dá opção de visualizar os dados cadastrados da equipe de trabalho. 3. O sistema dá opção de atualizar os dados cadastrados da equipe de trabalho O sistema verifica se os dados atualizados são válidos; 3.2. O sistema armazena os dados atualizados da equipe de trabalho no banco de dados e informa que a atualização foi realizada com sucesso. 4. O sistema dá opção de remover equipe de trabalho O sistema atualiza o banco de dados. Se o Nome da Equipe não for informado no ato de cadastro, deverá ser exibida uma mensagem de erro e continuar na tela de cadastro. Teste 01 (Requisito funcional: CRUD de EquipeDeTrabalho) Descrição: Teste de EquipeDeTrabalho Válido Selecione J5 em NomeEquipe e um encontro válido e selecione Entrada: Criar. Saída: Equipe de Trabalho cadastrada com Sucesso Teste 02 (Requisito funcional: CRUD de EquipeDeTrabalho) Descrição: Teste de EquipeDeTrabalho Inválido Entrada: Selecione Criar sem selecionar um Encontro válido. Saída: O campo Encontro não pode ser vazio. Teste 03 (Requisito funcional: CRUD de EquipeDeTrabalho) Descrição: Teste de Atualização de dados de EquipeDeTrabalho Entrada: Troque J5 por Lanchinho em NomeEquipe. Clique em Update. Saída: Atualizações realizadas com sucesso Teste 04 (Requisito funcional: CRUD de EquipeDeTrabalho) Descrição: Teste de Remoção de Equipe de Trabalho Selecione Deletar EquipeDeTrabalho a partir de uma equipe Entrada: previamente visualizada. Saída: Equipe de Trabalho removida. Requisito Funcional Nome: Descrição: Fluxos de eventos Fluxo principal: Login O acesso a determinadas opções do sistema será feito através de login. 1. O sistema mostra a página de login. [FS1] 2. O usuário informa: Login Senha 3. O usuário seleciona a opção login para se autenticar;

15 Fluxo secundário 1: 3.1 O sistema verifica se os dados informados em (2) corresponde a algum usuário existente. [FS2] 4. O sistema redireciona para a tela inicial e uma mensagem é exibida informando que o usuário está logado. Se o usuário estiver logado, aparecerá a opção logout, que, ao ser selecionada, levará o usuário ao passo (1) do fluxo principal. Fluxo secundário 2: Se os dados informados o login e senha não corresponderem a nenhum usuário no sistema, volta para o passo (1) do fluxo principal e uma mensagem de erro é exibida. Teste 01 (Requisito funcional: Login) Teste de login correto (Admin é um usuário existente no sistema, você Descrição: pode digitar nos campos login e senha, valores válidos que correspondam a um usuário existente, e a saída será a mesma.) Digite admin no campo login e admin no campo senha e selecione Entrada: a opção Login Redirecionado para a tela principal do sistema e exibida a mensagem Saída: Hello, admin!. Teste 02 (Requisito funcional: Login) Descrição: Teste de Login não existente Entrada: Digite xpto no campo login e plaejfijwds no campo senha e seleciona a opção Login Saída: O sistema continuará na tela de login e uma mensagem de erro será exibida Teste 03 (Requisito funcional: Login) Descrição: Teste de Logout. O usuário está logado no sistema. Entrada: Selecione a opção logout. Saída: O sistema redirecionará para a tela de login e uma mensagem será exibida informando que o usuário está desconectado. 3. Sprint Planning Meeting O que se aprendeu da retrospective meeting? Comprovamos que os testes e a funcionalidade, se feitos pela mesma pessoa, torna mais fácil o desenvolvimento, por questão de não dependência. E, como mostrados nos gráficos de estimativa versus tempo real, não devemos subestimar as atividades, pois muitas vezes é necessário modificar muito do sistema, que acaba ocasionando conflito de versões, e geralmente esses conflitos não são tão triviais de resolver. Scrum Master Sprint #3 José Leandro

16 Itens do Product Backlog a serem realizados, Tasks, Poker planning e Alocação de atividades As imagens 5 e 6 mostram o planejamento para a próxima sprint, cadastrado no Acunote. Imagem 5 Itens do Product Backlog para a sprint 3 Imagem 6 Tasks, Poker Planning e Alocação de atividades para a Sprint 3