Ambientes computacionais para apoio ao ensino relacionado a requisitos de software tem sido desenvolvidos com diferentes vertentes. Santos et al. (2013) desenvolveram um jogo para ensino de conceitos de requisitos em sistemas ubíquos. Zuppiroli, Ciancarini e Gabbrielli (2012) desenvolveram um RPG (role-
playing game ou jogo de interpretação de papéis) que permite que requisitos
possam ser discutidos e avaliados em um laboratório de engenharia de software. Thiry, Zoucas e Gonçalves (2010) criaram um jogo educativo que faz uso de aspectos lúdicos e de desafios para promover a aprendizagem da Engenharia de Requisitos. Vargas et al. (2010) desenvolveram um jogo para a aprendizagem de elicitação de requisitos de software, através do uso de situações e cenários simulados.
Em relação ao acompanhamento do desempenho de alunos durante o processo de aprendizado em projeto de sistemas de software, a ferramenta SEREBRO fornece o desempenho de grupos no desenvolvimento de projetos de software, analisando a colaboração, a contribuição e o progresso de cada um (Hale, Jørgensen e Gamble 2011).
Práticas e ferramentas para apoio ao ensino de Engenharia de Software, sem o uso de ambientes computacionais, também tem sido criadas, como o jogo AprendES (Feitosa e Campos 2010). Esse é um jogo baseado em cartas, que permite estimar o esforço para se construir um projeto, definindo-se o número de módulos do projeto utilizando-se cartas do tipo ‘tamanho’. Já a ferramenta Modelando (Silva et al. 2012) é um jogo educacional para o ensino de Engenharia de Requisitos que proporciona aos estudantes da disciplina um exercício prático, lúdico e iterativo com o objetivo de praticar os conceitos assimilados, utilizando-se os diagramas da UML (Linguagem de Modelagem Unificada).
Porém, nenhum dos ambientes de apoio ao aprendizado citados anteriormente envolve a análise dos requisitos para estimativa de esforço utilizando
Planning Poker. Também não utilizam requisitos e esforços reais para apoio ao
3 REVISÃO DE ATIVIDADES EXECUTADAS
Como a técnica de estimativa de software baseada em julgamento de especialista Planning Poker se baseia no uso da experiência do estimador para elaboração da estimativa, este método não segue um método formal definido.
O julgamento do especialista, por ser realizado por seres humanos, sofre influências não apenas das características das atividades ou projetos a serem estimados, como prazo, complexidade, tamanho, método de desenvolvimento, entre outros. Essas outras influências, como as exploradas por Jørgensen e Grimstad (2012) e Jørgensen (2013b), podem ser estudadas separadamente para se realizar um apanhado destas, definirmos práticas que auxiliem o estimador a conseguir resultados mais acurados.
Hoje, na literatura, o contexto de estimativa de software baseado em julgamento de especialista é muito amplo e informal. Por isso a necessidade de focar em um método de execução de estimativas com revisão de atividades executadas.
Para verificar uma possível melhora no uso de revisões de atividades executadas, foram alterados três dos passos definidos no diagrama da Figura 1, como destacado no diagrama da Figura 2.
Figura 2 – Diagrama do fluxo de execução do Planning Poker com revisão de atividades executadas.
4 MATERIAIS E MÉTODOS
Este capítulo descreve como foram realizados os quatro experimentos. O método de aplicação dos experimentos foi definido para este trabalho e está descrito nas Figuras 3, 4, e 5, para as duas iterações, com 79 alunos da Universidade Tecnológica Federal do Paraná (UTFPR) dos cursos Bacharelado em Sistemas de Informação e Engenharia de Computação.
Na primeira etapa do experimento, cada participante integrante do grupo de estimativa deve se cadastrar, inserindo os seus dados pessoais e as suas competências profissionais e acadêmicas, conforme indicado pela atividade “Participantes cadastram os dados do participante” do diagrama da Figura 4. Os participantes cadastrados podem fazer a atualização dos dados cadastrados, se desejarem, como indicado na atividade “Participantes revisam os dados do cadastro” do diagrama da Figura 4.
Após o cadastro de todos os participantes, é possível selecionar, a partir de uma lista de requisitos, cada um dos requisitos e as suas especificações, a fim de ser feita a estimativa de esforço em horas-homem para o mesmo. Esta descrição é relativa à atividade “Participantes leem os dados referentes ao requisito” do diagrama da Figura 5.
Ao preencherem os campos de valor de estimativa e de justificativa para cada estimador, como na Figura 5, e terminarem a rodada, os dados respectivos a esta rodada são armazenados, e a tela é atualizada para permitir uma nova rodada, exibindo os valores anteriores estimados como “Valor Anterior” para que o moderador possa saber se os estimadores estão mudando suas estimativas ou não estão chegando a um consenso. Esta ação executa a atividade “Participantes realizam as rodadas de jogo, definindo e justificando o esforço estimado” do diagrama da Figura 5.
Caso os participantes cheguem a um consenso ou o moderador decida encerrar as rodadas por falta de consenso, os participantes devem definir o valor da estimativa final, permitindo a inserção da estimativa final. Os participantes devem, então, preencher os campos de estimativa final e de razões e incertezas. Esta ação executa a atividade “Participantes definem a estimativa final e a justificam” do diagrama da Figura 5. As razões e incertezas podem estar relacionadas a fatores como complexidade, dificuldade da linguagem de programação, ou profundidade insuficiente dos requisitos.
Apenas na segunda etapa, a fim de verificar o impacto da utilização da busca em repositório histórico durante a execução de estimativas utilizando Planning
Poker, os alunos passam a ter acesso a buscas por palavras-chave relativas, entre
outros filtros, aos requisitos a serem estimados. Esta ação executa a atividade “Participantes buscam atividades já executadas no banco de dados” do diagrama apresentado na Figura 5.