SUMÁRIO 1 INTRODUÇÃO 2 ENGENHARIA DE SOFTWARE 3 … · Camadas da Engenharia de Software Fonte:...
50
11 SUMÁRIO 1 INTRODUÇÃO ...................................................................................................... 13 2 ENGENHARIA DE SOFTWARE ....................................................................... 15 3 JOGOS EDUCATIVOS ........................................................................................ 19 3.1 Jogos para Engenharia de Software ...................................................................... 21 4 TAXONOMIA REVISADA DE BLOOM ........................................................... 23 5 METODOLOGIA .................................................................................................. 26 5.1 Comparativo entre Mapeamento Sistemático e Revisão Sistemática ................... 26 5.2 Etapas do Mapeamento Sistemático (Protocolo) .................................................. 27 6 MAPEAMENTO SISTEMÁTICO DE JOGOS EDUCATIVOS PARA ES .... 29 6.1 Definição do problema .......................................................................................... 29 6.2 Planejamento – Definição do Protocolo ............................................................... 29 6.2.1 Objetivo ............................................................................................................. 29 6.2.2 Escopo e questões de pesquisa ........................................................................... 30 6.2.3 Fontes de pesquisa ............................................................................................. 30 6.2.4 String de busca ................................................................................................... 31 6.2.5 Critérios de inclusão .......................................................................................... 32 6.2.6 Critério de Qualidade ......................................................................................... 33 6.2.7 Extração de dados .............................................................................................. 33 6.2.8 Síntese de dados ................................................................................................. 34 6.3 Condução do Mapeamento ................................................................................... 34 6.4 Análise dos Resultados ......................................................................................... 37 6.4.1 Jogos e Simuladores encontrados ...................................................................... 37 6.4.2 Quais os jogos que mais estão em evidência ou são utilizados como referência para o ensino-aprendizagem da Engenharia de Software? ......................................... 40 6.4.3 Qual a área da Engenharia de Software mais explorada pelos jogos? ................ 41
Transcript of SUMÁRIO 1 INTRODUÇÃO 2 ENGENHARIA DE SOFTWARE 3 … · Camadas da Engenharia de Software Fonte:...
11
SUMÁRIO
1 INTRODUÇÃO ...................................................................................................... 13
2 ENGENHARIA DE SOFTWARE ....................................................................... 15
3 JOGOS EDUCATIVOS ........................................................................................ 19
3.1 Jogos para Engenharia de Software ...................................................................... 21
4 TAXONOMIA REVISADA DE BLOOM ........................................................... 23
5 METODOLOGIA .................................................................................................. 26
5.1 Comparativo entre Mapeamento Sistemático e Revisão Sistemática ................... 26
5.2 Etapas do Mapeamento Sistemático (Protocolo) .................................................. 27
6 MAPEAMENTO SISTEMÁTICO DE JOGOS EDUCATIVOS PARA ES .... 29
6.1 Definição do problema .......................................................................................... 29
6.2 Planejamento – Definição do Protocolo ............................................................... 29
6.2.1 Objetivo ............................................................................................................. 29
6.2.2 Escopo e questões de pesquisa ........................................................................... 30
6.2.3 Fontes de pesquisa ............................................................................................. 30
6.2.4 String de busca ................................................................................................... 31
6.2.5 Critérios de inclusão .......................................................................................... 32
6.2.6 Critério de Qualidade ......................................................................................... 33
6.2.7 Extração de dados .............................................................................................. 33
6.2.8 Síntese de dados ................................................................................................. 34
6.3 Condução do Mapeamento ................................................................................... 34
6.4 Análise dos Resultados ......................................................................................... 37
6.4.1 Jogos e Simuladores encontrados ...................................................................... 37
6.4.2 Quais os jogos que mais estão em evidência ou são utilizados como referência
para o ensino-aprendizagem da Engenharia de Software? ......................................... 40
6.4.3 Qual a área da Engenharia de Software mais explorada pelos jogos? ................ 41
12
6.4.4 Quais os níveis, segundo a taxonomia revisada de Bloom, encontrados com mais
frequência nos jogos voltados para Engenharia de Software? ..................................... 42
6.4.5 Como está distribuída sua produção/aplicação no tempo (cronologia) e no espaço
(geograficamente)? ..................................................................................................... 44
6.4.6 Segundo as pesquisas, é possível apontar se há algum jogo mais eficiente para o
ensino da Engenharia de Software? ............................................................................ 46
6.4.7 Classificação por mídia ...................................................................................... 46
7 CONCLUSÃO ......................................................................................................... 48
REFERENCIAS ........................................................................................................ 49
APÊNDICE A – JOGOS ENCONTRADOS .......................................................... 55
13
1 INTRODUÇÃO
Atualmente, a Engenharia de Software (ES) encara um intenso desafio centrado
na necessidade de suprir a utilização de mecanismos de ensino que propiciam mais
eficiência no processo de ensino-aprendizagem (SANTOS et. al., 2008). Diante dos
artefatos que asseguram um bom projeto de software, os estudantes têm se mostrado
desinteressados pela disciplina (de Engenharia de Software) considerando-a teórica e
burocrática, e assumindo a preferência pela escrita e funcionamento de programas a
documentar formalmente os seus sistemas (De LUCENA et. al., 2006). Outro desafio do
ensino da Engenharia de Software se caracteriza pela acentuação no âmbito das
inovações tecnológicas. Frente a esses fatores, a maneira de ensino mais tradicional,
condensada em demasia no professor, gera uma carência de oportunidades aos
estudantes para aplicação prática dos conceitos obtidos em aula (CHEN et. al., 2008).
Uma maneira encontrada para melhorar a situação desenvolve-se por intermédio de
técnicas de ensino alternativas, a exemplo, jogos, simuladores, estudos de caso, entre
outros. Nos últimos anos, vem-se aumentando a expectativa de que os jogos
educacionais sejam uma solução bastante satisfatória. De modo geral, estes jogos são
desenvolvidos para serem aplicados em ambientes educacionais e como complemento
às aulas de determinados assuntos. Ademais, são desenvolvidos para além do
fundamento educacional, e englobam elementos inerentes a jogos, como contexto,
regras, objetivos, competição e interação (PRENSKY, 2001).
Através de ambientes virtuais, ferramentas de simulação e determinados jogos,
os estudantes adquirem capacidades, fruto de uma experiência com situações realísticas
e “concretas” e que também são encontradas na prática. Além do mais, essa abordagem
concede o desenvolvimento de experiências isentas de riscos reais (PFAHL et. al.
2000). Outra vertente favorável à aplicação de jogos e simuladores parte do pressuposto
de que o estudante aprende fazendo, mitigando a lacuna que há entre teoria e prática
(BAKER et. al., 2005).
Também se faz relevante a existência de evidências dos benefícios dos jogos
antes de sua aplicação em sala de aula. É imprescindível a clareza acerca dos resultados
pós-utilização desse tipo de recurso, possibilitando julgar se os custos e esforços
adotados são válidos. Apesar dos indícios de que os jogos educacionais sejam
ferramentas capazes de aprimorar o processo de ensino-aprendizagem (GARRIS et. al.,
2002), esse tipo de recurso desperta a atenção de professores e alunos sem assegurar
com total certeza os reais subsídios que os jogos podem trazer para a educação.
Assim, é imprescindível conhecer quais jogos educacionais foram desenvolvidos
e adotados para o ensino de Engenharia de Software nos últimos anos, bem como os
estudos voltados para sua aplicação e eficiência em relação aos estudantes que utilizam
esses jogos.
14
Este trabalho teve como objetivo geral a realização de um mapeamento
sistemático que seja capaz de identificar e mensurar a produção e a aplicação de jogos
para o ensino-aprendizagem de Engenharia de Software. Além disso, verificar se a
aplicação desses jogos para o ensino no nível superior corresponde às expectativas.
Como objetivos específicos, este trabalho pretendeu verificar quais níveis da
taxonomia revisada de Bloom são atingidos pelos jogos voltados para o ensino ES, esta
que serve para auxiliar o planejamento e organização didático-pedagógico (Bloom et. al.
1956), pretende verificar quais são os jogos que mais se destacam ou que mais são
utilizados como referência para o ensino da ES, bem como sua eficiência, situando de
maneira cronológica e geográfica sua produção.
O presente trabalho está dividido em sete capítulos. O primeiro deles apresenta a
introdução sobre o tema abordado e os objetivos. O segundo capítulo apresenta a
fundamentação sobre a Engenharia de Software, seguido do capítulo voltado para jogos
educativos. O quarto capítulo mostra uma pequena abordagem à Taxonomia Revisada
de Bloom. O quinto capítulo descreve um mapeamento sistemático, mostrando suas
diferenças para uma revisão sistemática. O sexto é a aplicação do mapeamento
sistemático, seguindo os passos do protocolo pré-estabelecido, e aponta os passos sobre
como a pesquisa foi construída, analisando e discorrendo sobre seus resultados. O
sétimo capítulo é a conclusão do trabalho.
15
2 ENGENHARIA DE SOFTWARE
Na busca de uma definição formal, diversos autores elaboraram definições
distintas sobre a engenharia de software. Não obstante, numa conferência pioneira sobre
o assunto em 1969, Friedrich Bauer (1969, p. 231), cientista da computação alemão,
proclamou a definição que segue “Engenharia de software é a criação e a utilização de
sólidos princípios de engenharia a fim de obter softwares econômicos que sejam
confiáveis e que trabalhem eficientemente em máquinas reais”.
Esta é uma definição que ainda gera discussão uma vez que não contempla
aspectos mais técnicos sobre a qualidade do software, sobre a satisfação do cliente, ou
ainda sobre a importância de um processo mais maduro.
De acordo com Pressman (2006, p. 16) um processo de software é definido
como “... um arcabouço para as tarefas que são necessárias para construir softwares de
alta qualidade.” Ainda segundo o autor, processo e engenharia podem ser analisados
como sinônimos ou não. Um processo de software caracteriza a abordagem que é
aplicada quando um software é elaborado. E por outro lado, a engenharia inclui também
outras tecnologias que constituem um processo.
Para tanto, Pressman (2006) definiu a Engenharia de Software como uma
tecnologia em camadas e que se alicerça num compromisso com a qualidade e pode ser
entendida de acordo com a Figura 1.
Figura 1. Camadas da Engenharia de Software
Fonte: PRESSMAN (2006, p.17)
Conforme ilustrado na Figura 1, a camada que se encontra no topo, a camada das
ferramentas de Engenharia de Software, oferece apoio, podendo este ser automatizado
ou semi-automatizado para as camadas que se encontram abaixo.
16
A camada do processo, a base da engenharia de software, é responsável por
estabelecer um arcabouço, ou seja, um conjunto de atividades adotadas a todos os
projetos que envolvem a produção de um software, não dependendo da sua
complexidade. Os processos constituem o embasamento do controle gerencial,
definindo métodos, os produtos (modelos, documentos, relatórios, etc.) e recursos, além
de assegurar a qualidade.
A camada intermediária ou os métodos de engenharia de software são uma
espécie de receita para a construção do software. Entre suas atribuições estão aquelas de
analisar os requisitos, modelar o projeto, as atividades teste e manutenção assim como
incluem regras e guias de processo.
O processo possui quatro atividades fundamentais – especificação,
desenvolvimento, validação e evolução/manutenção – e, dependendo do tipo de
software, de pessoas e estruturas envolvidas, elas são realizadas de forma diferente, não
existindo uma maneira certa ou errada de organizá-las. Por exemplo, no modelo
evolucionário elas são intercaladas e, no modelo em cascata, as atividades são em
sequência (SOMMERVILLE, 2007).
A primeira dessas atividades básicas, a especificação ou engenharia de
requisitos, é descrita por Sommerville (2007, p. 49) como:
[...] o processo para compreender e definir quais serviços são
necessários e identificar as restrições de operação e de
desenvolvimento do sistema. A engenharia de requisitos é um estagio
particularmente crítico do processo de software, pois os erros nesse
estágio conduzem inevitavelmente a problemas posteriores no projeto
e na implementação do sistema (SOMMERVILLE, 2007, p. 49).
A engenharia de requisitos, como atenta a Figura 2, é constituída ainda de quatro
fases principais: o estudo de viabilidade, a elicitação e análise de requisitos, a
especificação de requisitos e a validação desses requisitos. Essas atividades não são
efetuadas simplesmente em uma sequência predefinida. Logo, esse processo conduz à
produção de um documento, denominado documento de requisitos, que é basicamente a
especificação do sistema (SOMMERVILLE, 2007).
O desenvolvimento começa com o projeto e a implementação do software
especificado pela engenharia de requisitos. Em outras palavras, é a conversão de uma
especificação num sistema executável. Sommerville (2007) aborda esse processo da
seguinte maneira:
[...] é a descrição da estrutura de software a ser implementada, dos
dados que são partes do sistema, das interfaces entre os componentes
do sistema e, às vezes, dos algoritmos usados. Os projetistas não
chegam ao projeto final imediatamente, mas desenvolvem o projeto
iterativamente por meio de varias versões. (SOMMERVILLE, 2007,
p. 50).
17
Esse processo é todo pautado na clareza de entendimento dos requisitos.
Figura 2. Processo da Engenharia de Requisitos
Fonte: SOMMERVILLE (2007, p.50)
Assim, de acordo que o projeto avança, essas especificações se tornam mais
minuciosas. Por fim, o processo de projeto pode ser decomposto em algumas atividades
específicas assim como o processo anterior. São elas: o projeto de arquitetura, as
especificações abstratas, os projetos de interface, os projetos de componente, projeto de
estruturas de dados e projeto de algoritmo. Não serão fornecidos detalhes dessas etapas,
pois não são o foco do estudo.
A implementação parte de cada indivíduo que participa da equipe e não existe
um processo padrão que a descreve. Alguns desenvolvedores preferem partir por blocos
que entenderam mais claramente e outros optam por deixá-los para o fim. Enquanto
desenvolvem, os programadores também realizam pequenos testes de código criados
por eles mesmos.
A terceira atividade está relacionada à validação do software. Segundo
Sommerville (2007, p.52), a “verificação e validação (V&V) destina-se a mostrar que
um sistema está em conformidade com sua especificação e que atende às expectativas
do cliente que está adquirindo o sistema”. O processo de teste é composto por alguns
estágios: teste de componente, teste de sistema e teste de aceitação. Nesses estágios
alguns componentes individuais são testados separadamente, conforme pode ser
observado na Figura 3, e logo em seguida, os componentes são integrados para realizar
os testes que têm como objetivo uma busca por erros. E também o teste “final”,
garantindo que o sistema seja aceito para uso operacional.
18
Figura 3: Fases de teste
Fonte: SOMMERVILLE (2007, p.53)
Por fim, após as etapas descritas anteriormente chega-se à evolução do software
que conforme definido por Sommerville (2007):
A flexibilidade dos sistemas de software é uma das principais razões
pelas quais cada vez mais o software está sendo incorporado a
sistemas complexos de grande porte. Após a decisão de aquisição de
hardware, é muito oneroso fazer mudanças no projeto de hardware.
No entanto, mudanças podem ser feitas no software a qualquer
instante durante ou após o desenvolvimento do sistema. Mesmo
mudanças extensas são mais baratas do que as mudanças
correspondentes no hardware do sistema (SOMMERVILLE, 2007, p.
54).
Com isso, ele ratifica a importância da manutenção, que, por vezes têm custos
iniciais maiores de desenvolvimento, mas que seus processos de manutenção se
justificam por serem menos desafiadores que o próprio desenvolvimento em si.
19
3 JOGOS EDUCATIVOS
O método de ensino que predomina nas escolas de nível superior nos dias de
hoje é aquele baseado em aulas expositivas, onde os professores pronunciam e os alunos
escutam (DJAJALAKSANA, 2011). Essa forma de ministrar aulas é apropriada para a
apresentação de conceitos abstratos e alguns tipos de relatos de fatos, porém, pesquisas
apontam que o rendimento dos alunos nesse tipo de aula cai depois de aproximadamente
quinze minutos, devido à perda de concentração. Como consequência, sua absorção de
conteúdo reduz-se radicalmente (BIGGS; TANG, 2011). Além disso, outras estratégias
como leitura são somente capazes de provocar uma aprendizagem superficial
(WAGNER, 1970).
A forma tradicional de ensino centrada demasiadamente no professor cria uma
carência de oportunidade aos estudantes para aplicação prática dos conceitos (CHEN et.
al., 2008). Com essa finalidade, é preciso, além das aulas expositivas a utilização de
outros mecanismos institucionais voltados à aprendizagem e que realmente estimulem o
aluno, requisitando sua presença e participação em tarefas cognitivas de níveis mais
altos (SASKATOON, 2009).
Segundo Morais (2009, p.2), “Um jogo cria uma representação simples,
subjetiva e deliberada da realidade”. Em outras palavras, os jogos são submundos da
realidade objetivando o ensinamento através do entretenimento. Incorporado nesse
contexto, um jogo voltado para o ensino e aprendizagem precisa contemplar duas
dimensões: ser um jogo, ou seja, haver uma competição com restrições para ao final se
vencer; e ser educativo, que consiste em ser projetado para transferir determinado
conhecimento (ABT, 2002).
A fim de dar legitimidade ao assunto, instituições estimadas como Harvard,
MIT, Georgia Tech, Oxford, Universidade de Copenhague, entre outras, e inúmeras
empresas privadas e laboratórios de pesquisa voltaram suas atenções ao gênero de jogo
através do aumento do financiamento de investigação em sala de aula (McLESTER,
2005). Aumentando o suporte a essa nova “técnica” de ensino, alguns cursos de MBA
(Mestre em Administração de Negócios) já utilizam jogos do tipo Business Game, onde
a simulação de negócios, ao mesmo tempo em que se apresenta de forma dinâmica e
divertida e com fins educacionais, o aluno pratica a tomada de decisões e desenvolve
competências para a gestão de negócios num ambiente livre de riscos reais.
Wang (2005, p. 4) observa que:
Em muitos aspectos, os jogos eletrônicos possibilitam um melhor
ambiente de aprendizado. Eles permitem um ajuste ao nível de
dificuldade conforme as habilidades do jogador, provêm aos jogadores
um feedback claro e imediato, e dá aos jogadores escolhas e controle
sobre suas ações. Também despertam a fantasia e a curiosidade, além
20
de oportunidades para colaborar, competir, ou socializar-se com os
outros jogadores (WANG, 2005, p. 4).
Por essa vertente é possível ainda ratificar que os jogos criam um contexto social
entre os jogadores e dispõem diversas modalidades de aprendizado de acordo com a
taxonomia revisada de Bloom (Anderson et. al. 2001). Além de encorajar a tomada de
decisões, como já foi dito, num ambiente com riscos controlados, o conceito pode ser
visto em oposição aos modelos atuais de ensino que se baseiam em testes de avaliação
onde os fracassos aumentam o “medo”.
Shtub (2010) evidencia que entre os benefícios de se aplicar jogos para o ensino,
ainda estão a facilidade de compreensão das relações entre áreas dentro de um assunto,
bem como o aumento da retenção de atenção.
Por outro lado, Buckingham (2007), sugere cautela ao promover a educação de
maneira interativa pelo fato de que, em algumas circunstâncias, pode transparecer a
ideia de que jogar um jogo é mais fácil do que o aprendizado em si, além do fato de
diminuir, em parte, a autonomia do professor.
Apesar da popularidade dos jogos atravessar esse período de ampla aprovação
que engloba uma maior aceitação entre alunos e professores, existem alguns obstáculos
que retardam sua aplicação e aproveitamento de suas potencialidades e que, segundo
Wang (2005), foram os formadores dos três pilares fundamentais para o sucesso na
utilização de jogos. São eles: educadores preparados, estrutura que permita a aplicação
dos jogos e um planejamento adequado, outrossim, uma variedade e qualidade de jogos
à disposição que se encaixam no planejamento.
Num estudo mais antigo, Passarelli (1997, p. 2) definiu as alterações no modelo
de ensino e que cabe como proposta para o tema discutido até os dias atuais “O
conhecimento é como uma teia de ideias interconectadas que atravessa vários domínios
[...]. A escola [...] não mais pode se dar ao luxo de ignorar as profundas alterações que
os meios/tecnologias de comunicação introduziram na sociedade [...]”.
E ela reforça seu pressuposto através de uma referência a outro autor ainda mais
antigo:
Os novos paradigmas para a educação consideram que os alunos
devem ser preparados para conviver numa sociedade em constantes
mudanças, assim como devem ser os construtores do seu
conhecimento e, portanto, serem sujeitos ativos deste processo onde a
"intuição" e a "descoberta" são elementos privilegiados desta
construção. Neste novo modelo educacional os professores deixam de
ser os entregadores principais da informação passando a atuar como
facilitadores do processo de aprendizagem, onde o aprender a
aprender é privilegiado em detrimento da memorização de fatos. [...]
como argumenta Howard Gardner em seu livro Frames of Mind.
(PASSARELLI, 1997, p. 3).
21
Como se pode notar, o aprendizado do aluno necessita então, de outros artifícios
que exercitem a aplicação do seu conhecimento. Nesse quesito encaixam-se os jogos
e/ou simuladores. A forma tradicional de ensino com foco demasiadamente no professor
criou uma carência de oportunidade aos estudantes para aplicação prática dos conceitos
e aumentou a necessidade de desenvolver outras inteligências como mencionado por
Passarelli. É nesse sentido que a utilização de jogos permite ao estudante aprender
fazendo, e dessa maneira, reduzir a lacuna que existe entre teoria e prática.
Existe uma demanda crescente pelo ensino e aprendizado da Engenharia de
Software de maneiras não triviais para lecionar para aqueles que ainda não possuem
experiência na esfera. Foi constatado, do ponto de vista acadêmico, que a Engenharia de
Software em cursos de graduação e pós-graduação não atinge o efeito esperado quando
o futuro profissional não possui alguma experiência prática prévia, por mais corriqueira
que a experiência seja (REIF; MITRI, 2005).
3.1 Jogos para Engenharia de Software
Realizando uma analogia com outras revisões sistemáticas com objetivos
semelhantes, as buscas por artigos foram realizadas em bases de dados científicas como
IEEEXplore e ACM Digital Library, além dos domínios de busca Scielo, Capes e
Google Scholar, visando encontrar um maior número de estudos que abordam jogos
desenvolvidos para a Engenharia de Software. Nesse âmbito, existem trabalhos
desenvolvidos especificamente para alguns domínios da Engenharia de Software, como
os jogos apresentados por Gonçalves, Thiry e Zoucas (2010) que se limitam à
engenharia de requisitos, ou ainda, a avaliação realizada por Lopes, Marques e Conte
(2011), voltada para a análise da inspeção de software.
A fim de não limitar a pesquisa, foram considerados todos os tipos de jogos ou
simuladores com objetivos educacionais, voltados para o ensino e aprendizagem da
Engenharia de Software, incluindo os jogos não eletrônicos (por exemplo, jogos de
tabuleiro, cartas). Não foram considerados protótipos conceituais de jogos ou que foram
apenas modelados sem sequer terem sido implementados.
Já havia sido realizada uma revisão sistemática sobre a avaliação de jogos
voltados para aprendizagem de engenharia de software no Brasil. A revisão que foi
conduzida por Wangenheim; Kochanski e Savi (2010) contemplava, porém, apenas
jogos desenvolvidos para o ensino da ES no Brasil, fato que limita a variedade e
quantidade de jogos para a área em questão. Este trabalho não limitou-se a trabalhos
publicados no país, ainda que tenha havido um pouco mais de ênfase nesse quesito.
Outro fator que divergiu os resultados da pesquisa consiste no fato de que a revisão
foi realizada, ainda que de forma automática e com uma string de busca apropriada, apenas
22
no domínio do Google e em busca de trabalho com extensão .pdf. O que acontece é que
instituições como IEEEXplore só permite que os trabalhos disponíveis em seu sítio
eletrônico sejam acessados se a busca for realizada com através de uma instituição
cadastrada. Ou seja, para refinar os resultados, parte da condução da pesquisa teve de
ser realizada na própria instituição de ensino da Universidade Estadual do Sudoeste da
Bahia – Uesb.
Por último, o próprio fato de ter sido feita uma revisão, e não um mapeamento,
já difere quanto a abrangência das pesquisas.
23
4 TAXONOMIA REVISADA DE BLOOM
No ensino, definir os objetivos da aprendizagem consiste na estruturação, de
maneira consciente, do processo educacional, de modo a criar oportunidades de pensar,
conduzir e tomar decisões. Essa estruturação é fruto de um processo diretamente
relacionado à escolha do conteúdo, dos procedimentos, atividades, etc., e da
metodologia a ser adotada por um determinado período de tempo.
De acordo com essa definição Ferraz e Belhot (2010) afirmam que:
Muitos dos objetivos implícitos estão relacionados a aspectos
cognitivos de alta abstração, em outras palavras, os educadores
almejam que seus alunos atinjam um nível de maturidade de
conhecimento muitas vezes incompatível com os objetivos declarados
e com os procedimentos, estratégias e conteúdos utilizados e
ministrados (FERRAZ & BELHOT, 2010, p. 422).
Para tanto, desenvolver tal competência de abstração e utilizar um conhecimento
específico de maneira multidisciplinar requer um bom planejamento. Principalmente no
ensino da Engenharia de Software, onde é solicitado aos alunos um alto grau de
abstração na realização de algumas etapas que simulam a realidade de maneira abstrata.
Nesse contexto, a utilização de ferramentas que facilitem essa atividade é fundamental,
e um dos instrumentos que propiciam esse processo nos cursos superiores é a taxonomia
proposta por Bloom, cujo objetivo é ajudar no planejamento, organização e controle dos
objetivos de aprendizagem.
A taxonomia de Bloom foi gerada a partir de um contexto acadêmico na década
de 1950 com o objetivo de apoiar os processos de projeto e avaliação educacional
(CHAPMAN, 2009). Sua proposta holística aborda o domínio cognitivo, o
desenvolvimento motor e atitudes.
Criada de maneira hierárquica e unidimensional, de acordo com Anderson
(2001), a taxonomia original relacionava a aquisição de conhecimento com a mudança
de comportamento.
Na Taxonomia Revisada de Bloom que pode ser observada na Figura 4, foi
mantida a base das categorias, continuando a existir seis delas, além de manter o nome
da taxonomia, aparecendo eventualmente com o termo “revisada” adicionado, porém,
ao dividir, conceitualmente, o conhecimento do processo cognitivo, ocorreram tais
mudanças: as categorias Sintetizar e Criar sofreram permuta; os aspectos verbais
utilizados na categoria Conhecimento foram mantidos, apesar de sua renomeação para
Lembrar; Compreensão foi renomeada para Entender; e a forma verbal das demais foi
alterada para o infinitivo.
24
Figura 4. Taxonomia revisada de Bloom, proposta por Anderson et. al. (2001)
Fonte: FERRAZ & BELHOT (2010, p. 427)
Embora essa não seja a taxonomia original, ela mantém o design hierárquico da
original, e foi modificada para englobar a aquisição do conhecimento, competência e
atitudes, visando facilitar o planejamento do processo de ensino e aprendizagem, além
de ser flexível, e possibilitar considerar a interpolação de categorias do processo
cognitivo quando necessário. Isso ocorre porque determinados assuntos podem ser mais
facilmente compreendidos. Por exemplo, pode ser mais fácil entender um assunto após
aplicá-lo para então explicá-lo (FERRAZ & BELHOT, 2010).
Os conceitos a seguir são a descrição dos seis níveis da Taxonomia Revisada de
Bloom (Figura 4) e foram esclarecidos segundo Ferraz (2010):
Quadro 1. Estrutura do processo cognitivo na taxonomia revisada de Bloom
1. Lembrar: Relacionado a reconhecer e reproduzir ideias e conteúdos. Reconhecer
requer distinguir e selecionar uma determinada informação e reproduzir ou recordar
está mais relacionado à busca por uma informação relevante memorizada.
Representado pelos seguintes verbos no gerúndio: Reconhecendo e Reproduzindo.
2. Entender: Relacionado a estabelecer uma conexão entre o novo e o conhecimento
previamente adquirido. A informação é entendida quando o aprendiz consegue
reproduzi-la com suas “próprias palavras”. Representado pelos seguintes verbos no
gerúndio: Interpretando, Exemplificando, Classificando, Resumindo, Inferindo,
Comparando e Explicando.
3. Aplicar: Relacionado a executar ou usar um procedimento numa situação específica
e pode também abordar a aplicação de um conhecimento numa situação nova.
Representado pelos seguintes verbos no gerúndio: Executando e Implementando.
4. Analisar: Relacionado a dividir a informação em partes relevantes e irrelevantes,
importantes e menos importantes e entender a inter-relação existente entre as partes.
Representado pelos seguintes verbos no gerúndio: Diferenciando, Organizando,
Atribuindo e Concluindo.
25
Quadro 1. Estrutura do processo cognitivo na taxonomia revisada de Bloom
5. Avaliar: Relacionado a realizar julgamentos baseados em critérios e padrões
qualitativos e quantitativos ou de eficiência e eficácia. Representado pelos seguintes
verbos no gerúndio: Checando e Criticando.
6. Criar: Significa colocar elementos junto com o objetivo de criar uma nova visão,
uma nova solução, estrutura ou modelo utilizando conhecimentos e habilidades
previamente adquiridos. Envolve o desenvolvimento de ideias novas e originais,
produtos e métodos por meio da percepção da interdisciplinaridade e da
interdependência de conceitos. Representado pelos seguintes verbos no gerúndio:
Generalizando, Planejando e Produzindo.
Fonte: FERRAZ & BELHOT (2010, p.429)
26
5 METODOLOGIA
A fim de dar continuidade ao estudo de qualquer área do conhecimento é
essencial que se realize uma revisão bibliográfica da área específica. Assim sendo,
conhecer o que já foi foco de estudo é extremamente relevante para, por exemplo,
encontrar lacunas com o intuito de iniciar uma nova pesquisa ou ainda identificar áreas
onde mais estudos primários precisam ser conduzidos. Uma revisão bibliográfica é uma
forma de revisar como determinado tema foi abordado e analisado em estudos
anteriores. De um modo geral, ela é conduzida como parte inicial de um estudo
científico. A revisão sistemática da literatura e o mapeamento sistemático são dois
métodos de realizar essa atividade.
5.1 Comparativo entre Mapeamento Sistemático e Revisão Sistemática
Um mapeamento sistemático é um tipo particular de revisão sistemática e utiliza
praticamente a mesma metodologia de base da revisão. Segundo Kitchenham (2007), o
mapeamento sistemático é uma revisão mais ampla de estudos primários e podem ser
classificadas de natureza exploratória e descritiva, enquanto que a revisão sistemática
foca em questões de pesquisas mais específicas e se volta para um ponto mais definido
da área de estudo.
Além dessa visão geral do cerne de alguma pesquisa, a realização de um
mapeamento cria a possibilidade de tomar conhecimento das frequências de publicações
no decorrer do tempo, e também de alguns tipos de pesquisa, propiciando a
identificação de tendências (PETERSEN, 2008). Através da visualização do Quadro 2 é
possível identificar as principais diferenças entre um mapeamento e uma revisão
sistemática.
Quadro 2. Mapeamento Sistemático x Revisão Sistemática
Mapeamento Sistemático
Revisão Sistemática
Extração de dados
Mais abrangente
Mais detalhada
Objetivo da extração
Foco na classificação e
categorização dos
resultados
Foco na identificação das
melhores práticas e
efetividade da área de
27
estudo. Há também a
verificação da qualidade
dos estudos primários
Protocolo
Menor
Maior
Termos de busca
Menos foco no assunto de
pesquisa
Mais foco no que está
sendo pesquisado
Fonte: MONTEIRO (2009, p.2)
5.2 Etapas do Mapeamento Sistemático (Protocolo)
Cruzando alguns dos conceitos de Kitchenham (2007), Petersen (2008) e Ramos
(2011) é possível identificar as etapas no processo que conduz a um mapeamento
sistemático. O primeiro passo consiste em definir o tema a ser mapeado para limitar a
obtenção de dados relevantes e já existentes na literatura, ou seja, definir o problema.
Em seguida, é necessário planejar um protocolo que servirá para orientar o
estudo. Através dele será:
Definido o objetivo do mapeamento;
Definidas algumas questões de pesquisa a serem respondidas;
Definir as fontes de pesquisa;
Construir uma string de busca partindo de técnicas bem definidas;
Estabelecer critérios de inclusão para os trabalhos encontrados;
Estabelecer critérios de qualidade que garantirão a integridade do
resultado;
Determinar como será realizada a extração de dados e a análise de
resultados.
Vale ressaltar que a identificação das questões a serem respondidas se manifesta
num dos tópicos mais importantes no momento de planejar o protocolo, pois são elas
quem irão demarcar o escopo da pesquisa (DYBA, 2007).
28
Com o protocolo definido, segue com o processo de busca que pode ser dividido
em manual e/ou automática. A busca manual admite uma maior restrição à área
estudada e o acesso aos artigos deve ser realizado manualmente. Já a busca automática
só ocorre após a definição de uma string de busca que inclui as palavras-chave do tema
a ser mapeado, e é composta frequentemente por operadores booleanos como AND e
OR.
Após a execução das buscas, entra-se em outros detalhes previamente definidos
no protocolo. Com os critérios de inclusão bem definidos, será realizada uma triagem
dos artigos encontrados para posteriormente seguir com uma análise detalhada dos
artigos retornados, identificando os mais relevantes e importantes para extrair seus
dados, bem como, responder as questões de pesquisa estabelecidas. Por fim, é
necessário apontar se os artigos e trabalhos serão analisados apenas através de seu
resumo ou se serão lidos por completo.
Os resultados gerados pelo estudo de um mapeamento sistemático são
habitualmente exibidos em forma de gráficos.
O desenvolvimento da metodologia empregada no mapeamento deste trabalho
foi guiado pelas etapas de um protocolo descrito conforme a seção 5.2, e teve como
principal objetivo uma análise relacionada à produção e aplicação de jogos voltados
para o ensino-aprendizagem da Engenharia de Software, este que ficou definido como
tema a ser mapeado, limitando a pesquisa e a obtenção de dados em literatura existente.
O mapeamento sistemático mostrou ser a maneira mais apropriada quanto aos
objetivos do estudo com a intenção de ser uma revisão formal, rigorosa e confiável. O
capítulo a seguir apresenta como o mapeamento sistemático foi conduzido.
29
6 MAPEAMENTO SISTEMÁTICO DE JOGOS EDUCATIVOS PARA ES
6.1 Definição do problema
Aprendizagem baseada em jogos é um assunto relativamente novo (Prensky,
2001). Engenharia de Software não. O ensino da Engenharia de Software tem gerado
uma carência de oportunidades aos estudantes para aplicação prática dos conceitos
obtidos em aula, livre de riscos reais. Atrelando as duas abordagens, esta pesquisa
mapeou algumas iniciativas que auxiliam no processo de ensino-aprendizagem da
Engenharia de Software através da utilização de jogos e simuladores.
6.2 Planejamento – Definição do Protocolo
6.2.1 Objetivo
O objetivo deste mapeamento sistemático foi identificar e catalogar os jogos e
simuladores direcionados ao ensino-aprendizagem da Engenharia de Software e/ou seus
processos.
6.2.2 Escopo e questões de pesquisa
Procurou-se responder as questões de pesquisa que serviram de guia no
mapeamento desta pesquisa, de modo que foi possível concluir e explanar acerca da
produção e aplicação de jogos educativos para a Engenharia de Software. As questões
previamente definidas foram:
Questão 1 – Quais os jogos que mais estão em evidência ou são utilizados como
referência para o ensino-aprendizagem da Engenharia de Software?
Questão 2 – Qual a área da Engenharia de Software mais explorada pelos jogos?
Questão 3 – Quais os níveis, segundo a taxonomia revisada de Bloom,
encontrados com mais frequência nos jogos voltados para Engenharia de Software?
30
Questão 4 – Como está distribuída sua produção/aplicação no tempo
(cronologia) e no espaço (geograficamente)?
Questão 5 – Segundo as pesquisas, é possível apontar se há algum jogo mais
eficiente para o ensino da Engenharia de Software?
6.2.3 Fontes de pesquisa
Com as questões de pesquisa definidas, foi realizada preliminarmente uma busca
manual de possíveis trabalhos. Para este processo, restringiu-se a busca aos seguintes
sítios eletrônicos: IEEEXplore1, ACM Digital Library
2, Scielo
3 e Capes
4. Verificou-se
ainda, através desta busca manual, que a quantidade de trabalhos no idioma português
para estas fontes foi surpreendentemente baixa. Para suprir estes resultados aquém do
esperado, foi decidida junto ao orientador a inclusão da fonte Google Scholar5. Além
disso, foram adicionados à string de busca do Google Scholar (string em português) os
processos da Engenharia de Software, a fim de encontrar o maior número possível de
trabalhos relevantes.
6.2.4 String de busca
Travassos (2007) afirma que a estratégia da busca automática ocorre durante o
desenvolvimento do protocolo, de forma interativa, e com o levantamento de palavras-
chave, seus sinônimos e da própria definição da string.
A construção da string de busca foi determinada partindo da seguinte técnica:
Definição das palavras-chave baseando-se em artigos relevantes consultados
manualmente através de uma revisão informal;
Identificação de termos alternativos e sinônimos para as palavras-chave;
Utilização do conector booleano AND para unir as palavras-chave;
Utilização do conector booleano OR para agregar sinônimos e palavras
alternativas;
1 http://ieeexplore.ieee.org/Xplore/home.jsp
2 http://dl.acm.org/
3 http://www.scielo.org/php/index.php
4 http://www.capes.gov.br/publicacoes
5 http://scholar.google.com.br/
31
Verificação da eficiência da string de busca através de buscas-piloto manuais.
Os quadros a seguir permitem a inferência das strings de busca em seus idiomas
e respectivos engenhos de busca.
Quadro 3. String, em inglês, utilizada nos domínios IEEEXplore, ACM Digital Library, Scielo e Capes
String de busca: idioma inglês
(“Teaching software engineering processes” OR “Learning software engineering” OR
“Teaching software development” OR “Learning software development”) AND
(“Game” OR “Simulation” OR “Simulator”) OR (“game” AND “software
engineering”)
Com a adição dos processos da Engenharia de Software à string do Google
Scholar esta ultrapassou o limite de caracteres para a busca automática e, como
alternativa, ela foi dividida em duas, uma vez que na revisão informal preliminar,
realizada através de uma busca manual, foram encontrados trabalhos relevantes para
ambas.
Quadro 4. Strings em português, utilizadas para mapeamento no engenho de busca Google Scholar
Strings de busca: idioma português
(“projeto de software” OR “requisitos de software” OR “gerência de projetos” OR
“construção de software” OR “implementação de software” OR “teste de software”)
AND (“jogo” ou “simulação” OR “simulador”) OR (“jogo” AND “engenharia de
software”)
---------------------------------------------------------------------------------------------------------
(“ensinar” AND “processos” AND “engenharia de software” OR “aprender” AND
“engenharia de software” OR “ensinar” AND “desenvolvimento de software” OR
“aprender” AND “desenvolvimento de software”) AND (“jogo” ou “simulação” OR
“simulador”) OR (“jogo” AND “engenharia de software”)
Ainda nesta etapa, ficou definido que a relevância partiria dos títulos, palavras-
chave, resumo e abstract dos artigos encontrados e aqueles considerados menos
32
relevantes seriam descartados. Segundo Travassos (2007), critérios de inclusão devem
ser baseados nas questões de pesquisa, logo eles serão definidos na próxima seção deste
trabalho.
6.2.5 Critérios de inclusão
A fim de limitar a triagem dos artigos encontrados nos sítios de busca, foram
definidos alguns critérios de inclusão de artigos para esse mapeamento de acordo com o
quadro abaixo:
Quadro 5. Critérios de Inclusão
Critérios de Inclusão
1) Artigos devem apresentar conteúdo referente à produção/aplicação de jogos
desenvolvidos para Engenharia de Software.
2) Artigos devem apresentar conteúdo referente à eficiência da aplicação de jogos
voltados para a Engenharia de Software.
3) Os artigos devem ter sido escritos nos últimos quinze anos.
4) Não apenas jogos, mas simuladores e afins serão considerados nesta busca.
5) Os artigos devem ter sido escritos em inglês ou português.
Todos os artigos que atenderem aos critérios de inclusão devem responder a
algumas das questões de pesquisa que foram levantadas.
6.2.6 Critério de Qualidade
O critério que define a qualidade dos estudos previamente selecionados está
apresentado de forma simples no Quadro 6. Após a seleção dos estudos, somente foram
33
considerados aqueles que apresentaram uma descrição ou respondem algumas das
questões de pesquisa da seção 6.2.2 deste capítulo, garantindo dessa forma a integridade
do resultado do mapeamento.
Quadro 6. Critérios de Qualidade
Critérios de Qualidade
Os estudos apresentam a criação e/ou a aplicação de jogos voltados ao ensino-
aprendizagem da Engenharia de Software, documentados em um formato de escrita de
padrão e descritos de forma explícita e organizada.
6.2.7 Extração de dados
O método de extração de dados consistiu nas seguintes etapas:
I. Execução das buscas automáticas nos engenhos de busca estabelecidos na seção 6.2.3
com as strings da seção 6.2.4.
II. Como método primário de extração, foi realizada a leitura dos títulos, abstracts e
palavras-chave para que os artigos potencialmente relevantes para o estudo fossem
selecionados.
III. Um conjunto de trabalhos foi selecionado a partir da verificação dos critérios de
inclusão e de qualidade. A inclusão dos estudos foi feita por meio de uma leitura
superficial dos estudos primários, tendo como foco identificar os critérios estabelecidos.
IV. Aqueles que preenchiam parcialmente os critérios de inclusão passaram para a fase
posterior, que contou com uma leitura minuciosa do conteúdo. Por fim, leram-se por
completo os artigos selecionados na etapa III e, entendendo suas propostas, foi feita
uma análise dos resultados para que se respondesse as perguntas da seção 6.2.2.
Os desacordos encontrados foram discutidos com o orientador a fim de que se
chegasse a uma conclusão quanto ao seu enquadramento.
34
6.2.8 Síntese de dados
O mapeamento sistemático apresentou diversos metadados sobre os trabalhos
publicados. Nas próximas seções eles foram analisados, avaliados e discutidos com a
finalidade de responder com fidelidade às questões de pesquisa definidas na seção 6.2.2.
6.3 Condução do Mapeamento
Na primeira etapa do mapeamento foram encontrados ao todo dois mil duzentos
e oitenta e quatro trabalhos, decorrentes das buscas automáticas realizadas com as
strings de busca da seção 6.2.4. A Tabela 1 ilustra a quantidade de trabalhos
encontrados a partir da busca automática em cada sítio eletrônico.
Tabela 1. Trabalhos encontrados a partir da busca automática
Fonte Total de trabalhos retornados em
decorrência da busca automática
IEEEXplore 765
ACM Digital Library 164
Scielo 21
Capes 27
Google Scholar 1307
Total 2284
Em seguida, os trabalhos foram submetidos a uma triagem, descrita nos tópicos
6.2.6 e 6.2.7. Nesta etapa, foram selecionados 113 trabalhos potencialmente relevantes
de acordo com seus títulos e resumos/abstracts. A Tabela 2 ilustra a quantidade de
trabalhos potencialmente relevantes. Dentre os trabalhos potencialmente relevantes,
havia, por exemplo, trabalhos redigidos em espanhol que, não fosse o critério de
inclusão 5 (consultar Quadro 5) , se encaixaria na pesquisa.
35
Tabela 2. Quantidade de trabalhos potencialmente relevantes selecionados após a triagem
Fonte Potencialmente relevantes
IEEEXplore 47
ACM Digital Library 5
Scielo 3
Capes 6
Google Scholar 52
Total 113
Finalmente, os trabalhos potencialmente relevantes foram lidos minuciosamente
e, alguns deles foram excluídos pelo seu não enquadramento na descrição do protocolo.
Após esta última etapa foram catalogados 39 trabalhos, sendo um deles publicado em
dois desses sítios. Todos os jogos encontrados estão dispostos no Apêndice A. A Tabela
3 ilustra a quantidade de trabalhos catalogados por fonte de busca após a leitura do
conteúdo.
Tabela 3. Trabalhos catalogados por fonte de busca
Fonte Após leitura do conteúdo
IEEEXplore 17
ACM Digital Library 3
Scielo 1
Capes 2
Google Scholar 16
Total 39
A Tabela 4 a seguir condensa todas estas etapas numa única tabela.
36
Tabela 4. Etapas da Busca
Fonte Total retornado por
busca automática
Potencialmente
relevantes
Após leitura do
conteúdo
IEEEXplore 765 47 17
ACM Digital
Library 164 5 3
Scielo 21 3 1
Capes 27 6 2
Google Scholar 1307 52 16
Total 2284 113 39
6.4 Análise dos Resultados
Nesta seção os resultados são analisados com base nas informações colhidas dos
trabalhos selecionados pelo mapeamento sistemático. Para tanto, foram subdivididos
através dos parâmetros analisados e procuraram responder as questões de pesquisa.
6.4.1 Jogos e Simuladores encontrados
A princípio, procurou-se listar os jogos encontrados e descrevê-los, a fim de,
posteriormente, fazer os gráficos para realizar conexões com as questões de pesquisa e
evidenciá-las de maneira mais objetiva.
Como resultado deste mapeamento, foram encontrados 36 jogos, dentre os quais
mencionados, criados e aplicados, e são descritos brevemente no quadro a seguir. A
descrição contempla os jogos que foram aplicados e/ou criados, excluindo aqueles que
foram apenas mencionados no conteúdo dos trabalhos.
37
Quadro 7. Jogos encontrados
Nome do Jogo Descrição
SimSE (Software Engineering Simulation) é um simulador single-
player, isto é, para um jogador, de processos de Engenharia
de Software cujo objetivo é gerir um projeto dentro de um
determinado conjunto de restrições. (NAVARRO; HOEK,
2009)
Problems and
Programmers
Jogo de cartas multiplayer que simula o processo de
especificação de requisitos de software a partir da entrega
do produto com base no ciclo de vida em cascata.
(BAKER; NAVARRO; HOEK, 2003)
SESAM
* Destinado para profissionais
e não para estudantes.
(Software Engineering Simulation by Animated Models) é
um simulador single-player cuja ideia básica é criar um
modelo de processo de desenvolvimento de software e
executá-lo usando o sistema de simulação. (LUDEWING,
2003)
MO-SEProcess Jogo multiplayer online baseado no jogo SimSE. Tem
como objetivo ensinar os princípios do processo de
desenvolvimento de software através da simulação do
desenvolvimento de um projeto de software de tamanho
moderado. (YE; LIU; POLACK-WAHL, 2007)
Communication and
Traceability Game
Jogo multiplayer cujo objetivo é terminar corretamente (e
dentro do possível menor tempo) um conjunto de artefatos
relacionados com o desenvolvimento de um software,
melhorando o ensino de experiências relacionadas ao
levantamento de requisitos. (JARAMILLO, 2010)
SPIAL Jogo single-player cujo objetivo é proporcionar uma
experiência mais realista no desenvolvimento de software e
seus processos, voltando-se também à melhoria dos
processos de software. (KUPSCH; RESENDE, 2013)
Magic Analysis Game Jogo single-player cujo objetivo consiste em auxiliar o
desenvolvimento da especificação dos requisitos baseando-
se em estudos de caso. (SHABALINA, 2013)
Rolly-Polly Game Jogo single-player cujo objetivo consiste em auxiliar na
implementação e validação de um projeto. Foi baseado no
modelo de ciclo de vida em espiral. (SHABALINA, 2013)
38
UbiRE Jogo single-player cujo objetivo consiste em favorecer o
entendimento da Engenharia de Requisitos. (LIMA et. al.,
2012)
Five-Phase Game Jogo single-player cujo objetivo é fornecer uma ferramenta
de ensino eficaz abrangendo os conceitos básicos de
engenharia de software. (RUSU et. al., 2010)
SimVBSE (Value-Based Software Engineering Simulation) é um jogo
single-player cujo objetivo é integrar considerações de
valor baseados em toda a gama de princípios de engenharia
de software existentes e suas práticas. (JAIN; BOEHM,
2006)
SDM Jogo single-player cujo objetivo é o auxílio na
aprendizagem do conhecimento de Engenharia de Software
de uma forma que aproveita os benefícios de diversão e
entretenimento, com foco no projeto e implementação.
(KOHWALTER; CLUA; MURTA, 2011)
Board Game Jogo multiplayer cujo objetivo é gerenciar um projeto de
software através dos processos de planejamento, requisitos,
arquitetura/design, implementação e testes da Engenharia
de Software. (TARAN, 2007)
SimulES-W Jogo multiplayer baseado no SimulES cujo objetivo é ensinar
conceitos da Engenharia de Software. (MONSALVE;
WERNECK; LEITE, 2011)
RE-O-Poly Jogo multiplayer cujo objetivo é explicar e explorar boas
práticas da Engenharia de Requisitos. (SMITH; GOTEL,
2008)
PlayScrum Jogo multiplayer cujo objetivo é promover um
desenvolvimento de software mais produtivo, e com maior
qualidade, uma vez que o desenvolvimento de software
envolve variáveis que tornam o desenvolvimento
imprevisível e complexo, exigindo flexibilidade para
acompanhar as mudanças. (FERNANDES; SOUSA, 2010)
TREG Jogo online cujo objetivo é a aprendizagem de técnicas de
Engenharia de Requisitos utilizando simulações baseadas
na colaboração. (VEGA et. al., 2010)
SimjavaSP Jogo single-player cujo objetivo é desenvolver um projeto
de software dentro do prazo e do orçamento necessário, e
39
de qualidade aceitável, exigindo a otimização dos fatores de
tempo, despesas e qualidade em paralelo. (SHAW;
DERMOUDY, 2005)
UTest Jogo single-player cujo objetivo é reconhecer e entender os
principais conceitos de teste de software de maneira geral.
(SILVA, 2010)
SPARSE Jogo single-player cujo objetivo é gerir o projeto de um
software preservando o custo e prazo, bem como a
qualidade do software em paralelo. (SOUZA et. al., 2010)
InspectorX Jogo single-player cujo objetivo é o incentivo ao
aprendizado em inspeção, mais especificamente na
identificação de defeitos em artefatos do processo de
desenvolvimento. (POTTER; SCHOTS, 2011)
SE•RPG Jogo single-player cujo objetivo é a conclusão do processo
de desenvolvimento de um software de acordo com um
projeto escolhido pelo jogador entre as opções existentes.
(BENITTI; MOLLERI, 2008)
Ilha dos Requisitos Jogo single-player cujo objetivo é auxiliar no ensino dos
principais conceitos envolvidos na área de conhecimento
Engenharia de Requisitos, tais como os processos e os tipos
de Engenharia de Requisitos. (THIRY; ZOUCAS;
GONÇALVES, 2010)
6.4.2 Quais os jogos que mais estão em evidência ou são utilizados como referência
para o ensino-aprendizagem da Engenharia de Software?
À medida que os trabalhos incluídos nos critérios de busca do mapeamento eram
lidos minuciosamente, foi-se criado uma planilha eletrônica de extensão .xls (Microsoft
Excel) para cada um dos trabalhos. Estes documentos criados foram alimentados com os
dados obtidos dos respectivos trabalhos.
Dentre os dados que constituem a planilha eletrônica .xls, foi criada uma seção
para indicar quais jogos aquele trabalho referenciava. A partir dessas informações, ficou
constatado que, do total de 36 jogos, 19 (dezenove) deles estavam presentes no
conteúdo de mais de um trabalho. A Figura 5 detalha quais são estes jogos.
40
Figura 5. Ranking dos jogos mais citados em outros trabalhos
Com destaque para SimSE, Problems and Programmers e SESAM, mencionados
17 (dezessete), 11 (onze) e 10 (dez) vezes, respectivamente, o SimSE serve como um
modelo de jogo para diversas outras publicações, além de apresentar um feedback
razoável quanto ao gerenciamento de projetos. O segundo deles se destaca por alguns
atributos negativos apesar de se comprovar sua qualidade através da aplicação (Navarro
et. al. 2004). O jogo Problems and Programmers – Card Game deixa uma importante
lacuna por não considerar aspectos modernos de software, como desenvolvimento
iterativo e evolução e vai além a partir do momento em que se percebe a ausência de um
mapeamento explícito entre os artefatos do jogo e conceitos básicos da Engenharia de
Software.
Outra informação de valor vem a ser o fato de que, dentre os 36 jogos que, entre
eles, mencionados, criados e aplicados, 21 deles foram criados. Ou seja, é possível
inferir que nos últimos quinze anos, existe uma média superior a 1 jogo por ano, voltado
para o ensino-aprendizado da Engenharia de Software sendo criado. Ainda que
mensurar sua eficiência seja uma tarefa complicada, é significativo que jogos venham
sendo criados e aplicados para a área de Engenharia de Software.
6.4.3 Qual a área da Engenharia de Software mais explorada pelos jogos?
A Engenharia de Software está dividida em processos. Nesta etapa, os resultados
são apresentados num gráfico em formato de pizza, conforme ilustra a Figura 6,
41
informando quais, dentre as quatro atividades fundamentais do processo, –
Especificação ou Engenharia de Requisitos, Projeto e Implementação, Validação/Testes
e Evolução/Manutenção – são aquelas em que predominam a produção e aplicação
desses jogos. Para esta informação, vale ressaltar que alguns jogos e simuladores não
contemplavam uma área específica da ES, mas sim alguns de seus conceitos gerais e,
portanto, deu-se a criação desta categoria em particular.
Figura 6. Subáreas da ES a que são destinados os jogos
Através da leitura do gráfico é possível inferir que 39% dos jogos têm como
foco o processo de projeto e implementação, seguido por conceitos gerais, 30%,
engenharia de requisitos, 19% e apenas 12% de validação/testes. Com exceção daqueles
jogos que interpelam conceitos gerais da Engenharia de Software, seu maior foco é o
gerenciamento de projetos. Segundo Sotille (2014), a gerência de projetos tem se
tornado um dos mais difíceis por ter de corresponder ou até mesmo exceder as
necessidades envolvendo o equilíbrio de diversas demandas concorrentes relacionadas
ao escopo, tempo, custo e qualidade, bem como aos requisitos identificados
(necessidades) e os não identificados (expectativas).
Alguns jogos que abordam os conceitos gerais explicam de forma superficial
sobre os processos de evolução/manutenção, mas não há exclusivamente nenhum jogo
para este domínio da Engenharia de software.
42
6.4.4 Quais os níveis, segundo a taxonomia revisada de Bloom, encontrados com
mais frequência nos jogos voltados para Engenharia de Software?
Outra abordagem se deu referente às taxonomias mais frequentes conforme a
Taxonomia Revisada de Boom. Levando-se em consideração o entendimento que parte
da leitura e explanação do feedback e resultados pós-aplicação presentes nos trabalhos,
foi possível fazer um levantamento sobre quais, dentre as 6 categorias, são as que mais
estão em voga.
Alguns dos trabalhos, a exemplo Thiry; Zoucas e Gonçalves (2010), já
indicavam a qual nível da taxonomia pertencia cada jogo, porém em outros ficou a
critério de interpretação, baseado em similaridade, bem como alguns testes individuais.
Alguns dos jogos que estavam disponíveis online foram jogados para determinar com
fidelidade a qual nível o mesmo pertencia. Em outros, que sequer foram encontrados
para download e/ou teste, foi necessário realizar a leitura sobre o funcionamento do
jogo, em literaturas separadas, para estabelecer quais níveis da Taxonomia Revisada
eram atingidos.
A Figura 7 a seguir detalha quais os níveis mais atingidos segundo a Taxonomia
Revisada de Bloom. No apêndice A é possível verificar, individualmente, qual ou quais
os níveis que cada jogo atinge.
Figura 7. Níveis mais alcançados pelos jogos em relação à Taxonomia revisada de Bloom
Interpretando o gráfico é possível inferir que os jogos, em geral, partem da base
dos processos cognitivos de aprendizado. Apontados pelos 40% do nível Lembrar,
43
seguido de perto pelos 32% do nível acima na pirâmide, Entender, os 100% total são
atingidos com mais 16% do nível Aplicar, 8% de Analisar, 3% de Sintetizar e apenas
1% de criar. Parte-se da base, do reconhecer e reproduzir ideias e conteúdos, passando a
estabelecer uma conexão entre o novo e o conhecimento previamente adquirido até
atingir o topo, onde envolve a criação de uma nova visão, uma nova solução que está
diretamente relacionado ao desenvolvimento de ideias.
6.4.5 Como está distribuída sua produção/aplicação no tempo (cronologia) e no
espaço (geograficamente)?
Relacionado ao aspecto da distribuição espacial das publicações dos trabalhos,
“Como está distribuída sua produção/aplicação no espaço (geograficamente)?”, antes
que houvesse sido realizada a classificação dos trabalhos encontrados no Google
Scholar, não havia uma grande predominância quanto à origem da publicação. Para
tanto, é vital observar que todos os trabalhos advindos da fonte Google Scholar têm
suas publicações no Brasil, o que acabou gerando a disparidade no gráfico da Figura 8.
Estes trabalhos aumentaram a proporção da distribuição para a América do Sul em mais
de 25%, encenados pelos 16 trabalhos que se encaixaram nos critérios de busca.
Quanto à de publicação, a Figura 8 ilustra essas publicações quanto ao
continente. Na Figura 8 é possível verificar as publicações quanto às suas
instituições/estados (para os trabalhos encontrados no Google Scholar).
Figura 8. Gráfico da distribuição espacial, por continente, de onde os trabalhos foram publicados
44
A seguir, a Figura 9 quantifica os trabalhos de acordo com a sua região do
Brasil. Todos os trabalhos oriundos do Google Scholar estão presentes nesta figura,
assim como alguns trabalhos que foram publicados no exterior, mas são de origem
brasileira.
Figura 9. Trabalhos publicados de acordo com a região do Brasil
A PUC-Rio, instituição situada no Rio de Janeiro, é a que mais se destaca, com 4
trabalhos que foram classificados como aptos para integrar a pesquisa. Também do Rio
de Janeiro, a UFRJ, juntamente com a UFMG de Belo Horizonte e a Univali, de Santa
Catarina, aparecem empatadas com 3 trabalhos para cada. Diante desses dados, o que
mais se torna relevante é o predominante “domínio” das instituições situadas na região
sudeste do país.
Outra informação passível de análise foi quanto à contemporaneidade dos dados
obtidos através do mapeamento. Respondendo à questão de pesquisa: “Como está
distribuída sua produção/aplicação no tempo (cronologicamente)?”, foram levantados os
dados que formularam o gráfico da Figura 10 a seguir.
45
Figura 10. Gráfico da distribuição cronológica das publicações de trabalhos sobre a produção/aplicação
de jogos voltados para a ES
É perceptível pela análise da Figura 10 que até 2009 houve um crescimento com
certo padrão na linha cronológica, com um ano de 2010 mostrando um acentuado
número de trabalhos e artigos publicados na área de jogos voltados para o ensino e
aprendizagem da Engenharia de Software. Após este ano, ocorre uma queda abrupta
entrando novamente num “certo padrão” dos anos anteriores.
6.4.6 Segundo as pesquisas, é possível apontar se há algum jogo mais eficiente para
o ensino da Engenharia de Software?
A avaliação de resultados da aplicação dos jogos e simuladores não é conclusiva
para todos, havendo alguns autores não chegaram a realizar avaliação com os
estudantes. Caso de SimulES (Figueiredo et. al. 2007), InspectorX (Potter; Schots,
2007), além daqueles jogos que foram apenas mencionados, sem sequer terem sido
aplicados ou explanados com base em algum estudo previamente feito, caso de Honey,
Planager, Scrumming (Wangenheim; Savi, 2010), Magic Analysis Game, Rolly-Polly
game (Shabalina et. al., 2013), Re-O-Polly, Software Quantum (Thiry, 2010). Algumas
das avaliações de eficiência, quando existentes, foram baseadas em questionários
preenchidos pelos estudantes que preenchiam respostas com pontos de vista sobre os
resultados alcançados XMED, The Incredible Manager. Em Dermoudy (2005), os
resultados não foram mensurados por demonstrativo de eficiência, mas pela experiência
de jogar, e este se mostrou um fator bastante positivo.
46
Outro resultado interessante é mostrado por Drapp e Ludewig (2000), onde eles
afirmam em seu trabalho que a partir dos resultados alcançados, a sugestão é de que não
utilize o SESAM para melhorar suas habilidades sem qualquer formação complementar.
A proposta SE•RPG (Ambrósio, 2008) fez a utilização de uma avaliação do
aprendizado por intermédio de um questionário de conhecimentos antes e depois da
utilização do jogo. E vai além quando diz que viabiliza aos professores uma ferramenta
que auxilia a aplicação na prática dos conhecimentos passados em sala de aula.
Em sua grande maioria, foi possível constatar um aumento de desempenho; um
feedback positivo em relação ao conhecimento adquirido pelos alunos. Vale ressaltar
também que parte do aumento de conhecimento se deve ao fato de que os jogos são
mais pedagogicamente eficazes quando utilizados como um complemento a métodos
como aulas de classe, palestras, etc. Sendo eficazes na articulação e auxílio à
compreensão desse conhecimento.
Para fins conclusivos, não foi possível apontar se, de fato, existe um jogo que
seja mais eficiente que os demais. Existem jogos que são mais adequados para
determinadas subáreas, assim como existem jogos que os estudantes preferem jogar, não
se fazendo necessário serem mais eficientes no acúmulo de aprendizado, mas
simplesmente pelo fato de proporcionar diversão e competição.
6.4.7 Classificação por Mídia
Um último dado levantado, a classificação midiática encontrou quatro maneiras
distintas de aplicação dos jogos e os separou da seguinte maneira: jogos eletrônicos,
jogos de tabuleiro (não eletrônico), jogos de carta (não eletrônico) e jogo de lista (não
eletrônico), conforme Figura 11. Para verificar a classificação de um jogo específico
quanto à sua mídia, consultar o Apêndice A.
Os jogos eletrônicos são aqueles que necessitam de um computador para serem
jogados. Não foi levado em consideração quanto ao fato de serem jogos online ou não.
E para um jogo de cartas eletrônico a sua categoria ficou definida como “Jogos
Eletrônicos”, ainda que fosse de “cartas”.
O jogo de listas, Guess what we want (Alexander e Betty, 2008) tem como
objetivo ensinar a importância de ter requisitos bem claros. Nele, os estudantes são
separados em grupos e o professor fornece uma lista de requisitos que é comum a todos
os grupos. Os grupos então apresentam uma solução para o “cliente” valendo-se dos
requisitos recebidos. Na rodada seguinte o professor fornece o mesmo conjunto de
requisitos, porém com mais detalhes, e os grupos discutem as diferenças entre suas
47
soluções, até que as soluções tornam-se semelhantes, e o pode atender às expectativas se
bem compreendido.
Figura 11. Gráfico da classificação dos jogos por mídia
48
7 CONCLUSÃO
Este trabalho teve por objetivo encontrar os jogos educativos para Engenharia de
Software através de um processo de mapeamento sistemático, uma maneira mais ampla
de se aplicar uma revisão sistemática.
O mapeamento sistemático foi conduzido por meio de um protocolo que
especificou as etapas realizadas durante a condução da pesquisa. Os critérios definidos
no protocolo foram necessários e suficientes para se encontrar os trabalhos
imprescindíveis à realização da pesquisa. Além disso, o mapeamento sistemático se
mostrou uma metodologia eficaz, embora consuma demasiado tempo, e envolveu um
trabalho árduo de leitura e análise dos estudos primários com o propósito de responder
às questões levantadas para a pesquisa.
Dos resultados estabelecidos, foi possível responder às questões levantadas.
Diante disso, foi possível encontrar 36 jogos e simuladores educativos para a
Engenharia de Software, bem como fazer um levantamento dos níveis cognitivos que
estes jogos atingem, baseados na Taxonomia Revisada de Bloom.
Além de inferir quais são os jogos mais referenciados pelos autores dos
trabalhos, foi possível apontar para qual área específica da ES está mais voltada a
produção e aplicação desses jogos.
Em relação ao número de trabalhos realizados com origem no Brasil, é visível
que ainda existem poucas publicações sobre jogos educacionais para ensino da
Engenharia de Software refletindo a necessidade de aperfeiçoamento deste método de
ensino na área. Atualmente, prevalece uma predominância da região sudeste quanto à
produção de trabalhos para a área, com uma diferença indiscutível para as demais
regiões do país.
Quanto ao critério de aplicação dos jogos, alguns trabalhos traziam uma
mensuração a fim de medir o atendimento às expectativas quanto aos estudantes, mas
outras publicações não citam nenhum tipo de avaliação ou apenas tiveram avaliação
informal e superficial realizada.
A expectativa é de que os jogos eletrônicos sejam os meios mais vantajosos para
completar o ensino das competências relacionadas à área da computação. E acredita-se
que esta pesquisa apresenta benefícios tanto no seguimento acadêmico como
profissional.
Para um próximo estudo, deixa-se a sugestão de ser realizada uma seleção dos
jogos mais mencionados e sua posterior aplicação em sala de aula com o propósito de
medir o desempenho do aprendizado dos estudantes, reforçando as respostas quanto a
questão de pesquisa relacionada à eficiência.
49
REFERÊNCIAS
ABT, C. Serious Games. University Press of America, 2002.
ALEXANDER, M.; BEATTY, J. Effective Design and Use of Requirements
Engineering Training Games. Barcelona, 2008.
AMBROSIO, F. SE•RPG 2.0: Uma Nova Versão de Software Engineering-
Roleplaying Game. Universidade Regional de Blumenau. Blumenau, 2008.
ANDERSON, L. W. et. al. A taxonomy for learning, teaching and assessing: a
revison of Bloom’s Taxonomy of Educational Objectives. New York: Addison
Wesley Longman, 2001.
BAKER, A.; NAVARRO, E.; Van Der HOEK, A. An Experimental Card Game for
Teaching Software Engineering Processes. 16 ª Conferência sobre Engenharia de
Software, Educação e Formação, Madrid, 2003.
BENITTI, F.; MOLLÉRI, J. Utilização de um RPG no Ensino de Gerenciamento e
Processo de Desenvolvimento de Software. Anais do XXVIII Congresso da SBC –
2008.
BIGGS, J.; TANG, C. Teaching for Quality Learning at University. Open University
Press, 4. ed., 2001.
BLOOM, B. S. et. al. Taxonomy of educational objectives. New York: David Mckay,
1956.
BOEHM, B. The Spiral Model as a Tool for Evolutionary Software Acquisition.
CrossTalk Magazine. Disponível em: <http://www.crosstalkonline.org/storage/issue-
archives/2001/200105/200105-Boehm.pdf> Acesso em: 12 mai. 2014.
BRABAND, C. How to make sure your students learn what you want them to.
Palestra, Universidade Federal de Pernambuco, 2010. Disponível em:
<http://www.itu.dk/people/brabrand/Teaching-Learning-UFPE-2010.ppt> Acesso em:
13 jun. 2014.
BRASIL, M.; RAMOS, E. Um Mapeamento Sistemático sobre Padrões de Software
para Reengenharia de Sistemas. Universidade Estadual do Ceará, 2011.
BRERETON, P. et. al. Lessons from applying the systematic literature review
process within the software engineering domain. Journal of Systems and Software v.
80, n. 4, p. 571-583. New York, 2007.
BUCKINGHAM, D. Crescer na era das Mídias Eletrônicas. São Paulo: Loyola,
2007.
50
CHAPMAN, A. Bloom's taxonomy - learning domains. Businessballs, 2009.
Disponível em:
<http://www.businessballs.com/bloomstaxonomyoflearningdomains.htm>. Acesso em:
18 jul. 2014.
CHEN, W. et. al. A Game-based Learning System for Software Engineering
Education. Prod. of 38th ASEE/IEEE Frontiers in Education Conference. Saratoga
Springs: New York, 2008.
DANTAS, A. Jogos de Simulação no Treinamento de Gerentes de Projetos de
Software. Universidade Federal do Rio de Janeiro, 2003.
De LUCENA, V. F.; BRITO, A.; GOHNER, P. A Germany-Brazil Experience
Report on Teaching Software Engineering for Electrical Engineering
Undergraduate Students. CONFERENCE ON SE EDUCATION & TRAINING –
CSEET, p. 69-76. Washington: IEEE Computer Society, 2006.
DERMOUDY, K. Engendering an empathy for software engineering. School of
Computing; University of Tasmania, 2005.
DJAJALAKSANA, Y. A National Survey of Instructional Strategies Used to Teach
Information Systems Courses: An Exploratory Investigation. PhD thesis, University
of South Florida, 2011.
DRAPP, A.; LUDEWIG, J. Simulation in Software Engineering Training. 22ª
Conferência Internacional de Engenharia de Software, Alemanha, 2000.
FARIAS, V.; MOREIRA, C.; COUTINHO, E.; SANTOS, I. iTest Learning: Um Jogo
para o Ensino do Planejamento de Testes de Software. Universidade Federal do
Ceará, 2012.
FERNANDES, J.; SOUSA, S. PlayScrum - A Card Game to Learn the Scrum Agile
Method. Segunda Conferência Internacional sobre Jogos e Mundos Virtuais para
aplicações sérias, Braga, 2010.
FERRAZ, A.; BELHOT, R. Taxonomia de Bloom: revisão teórica e apresentação
das adequações do instrumento para definição de objetivos instrucionais. Gest.
Prod., São Carlos, v. 17, n. 2, p. 421-431, 2010.
FIGUEIREDO, E.; LOBATO, C.; DIAS, K.; LEITE, J.; LUCENA, C. Um jogo para o
Ensino de Engenharia de Software Centrado na Perspectiva de Evolução. XXVVII
Congresso da SBC. XV Workshop sobre Educação em Computação. Rio de Janeiro,
2007.
FIGUEIREDO, K.; FERREIRA, J.; MURTA, L.; CLUA, E. Um Jogo de Estratégia de
Gerência de Configuração. III Fórum de Educação em Engenharia de Software, 2010.
51
GARRIS, R.; AHLERS, R.; DRISKELL, J. Games, Motivation, and Learning: A
Research and Practice Model. Simulation Gaming 33, n. 4, p. 441-467, 2002.
GONCALVES, R. Q.; THIRY, M. Development of a game to support the teaching of
Requirements Engineering: The Requirements Island. In: SIMPÓSIO
BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL (SBGames), 9., 2010,
Florianópolis, Porto Alegre, RS: SBC, 2010. p. 358-361.
ISOTTON, E. Scrumming - Ferramenta Educacional para Ensino de Práticas de
SCRUM. Pontifícia Universidade Católica do Rio Grande do Sul, 2008.
JAIN, A.; BOEHM, B. SimVBSE: Developing a Game for Value-Based Software
Engineering. Conferência de Engenharia de Software, Educação e Formação. Turtle
Bay, 2006.
JARAMILLO, C. Communication and traceability game: a way to improve
requirements elicitation process teaching. Rev. Fac. Ing. Univ. Antioquia N.° 56 pp.
213-221. Medelin, 2010.
KITCHENHAM, B. Procedures for Performing Systematic Reviews. Technical
Report Software Engineering Group, Keele University, 2004.
KITCHENHAM, B. Guidelines for performing Systematic Literature Reviews in
Software Engineering. Technical Report EBSE-2007-01, Software Engineering Group
Department of Computer Science Keele University, 2007.
KNAUSS, E.; SCHNEIDER, K.; STAPEL, K. A Game for Taking Requirements
Engineering More Seriously. Third International Workshop on Multimedia and
Enjoyable Requirements Engineering. Spain, Barcelona, 2008.
KOCHANSKI, D.; SAVI, R.; WANGENHEIM, C. Revisão Sistemática sobre
Avaliação de Jogos Voltados para Aprendizagem de Engenharia de Software no
Brasil. Florianópolis, 2009.
KOHWALTER, T.; CLUA, E.; MURTA, L. SDM – An Educational Game for
Software Engineering. Simpósio Brasileiro de Jogos e Entretenimento Digital,
Salvador, 2011.
KUPSCH, D.; RESENDE, R. SPIAL: Uma Ferramenta de Apoio ao Aprendizado de
Melhoria de Processos de Software. Universidade Federal de Minas Gerais, 2008.
LIMA, T.; CAMPOS, B.; SANTOS, R.; WERNER, C. UbiRE: A Game for Teaching
Requirements in the Context of Ubiquitous Systems. XXXVIII Conferência Latino-
americana de Informática, Medellin, 2012.
52
LOPES, A.C.; MARQUES, A. B; CONTE,T. Avaliação do Jogo Inspsoft: Um Jogo
Para o Ensino de Inspeção de Software. Amazonas: Universidade Federal do
Amazonas (UFAM), 2011.
LUDEWIG, J. Models in software engineering – an introduction. In Software and
Systems Modeling. 5-14. Springer Berlin / Heidelberg. Volume 2, Number 1, 2003.
McCLESTER, S. Game Plan. Tech & Learning. Disponível em:
<http://www.techlearning.com/features/0039/game-plan/43016>. Acesso em: 10 abr.
2014.
MIRA, S.; SANTOS, R.; COSTA, H. ProMEG: Um Jogo para Ensino de Gerência de
Projetos com Foco na Gerência de Recursos Humanos. Universidade Federal de
Lavras, 2012.
MONSALVE, E.; WERNECK, V.; LEITE, J. Teaching Software Engineering with
SimulES-W. 24ª Conferência sobre Engenharia de Software, Educação e Formação.
Honolulu, 2011.
MONTEIRO, D. Revisão Sistemática e Mapeamento Sistemático. 2009. Disponível
em: <http://www.monteiro.inf.br/blog/revisao-sistematica-e-mapeamento-sistematico/>.
Acesso em: 20 jul. 2014
MORAIS, F.; SILVA, C. Desenvolvimento de Jogos Eletrônicos. Uni-BH, 2009.
NAVARRO, E.; HOEK, A. Multi-Site Evaluation of SimSE. 40th ACM technical
symposium on Computer science education p326-330 Chattanooga, USA, 2009.
PASSARELLI, B. Teoria das Múltiplas Inteligências aliada à Multimídia na
Educação: Novos Rumos Para o Conhecimento. MiniWeb Cursos. Disponível em:
<http://www.miniwebcursos.com.br/artigos/PDF/Teoria_das_M%FAltiplas_Intelig%E
Ancias.pdf>. Acesso em: 09 mai. 2014.
PETERSEN, K. et. al. Systematic Mapping Studies in Software Engineering.
Conference on Evaluation and Assessment in Software Engineering. v. 17, 2008.
PFAHL, D.; KLEMM, M.; RUHE, G. Using System Dynamics Simulation Models
for Software Project Management Education and Training. Software Process
Simulation Modeling Workshop. Londres, 2000.
POTTER, H.; SCHOTS, M. InspectorX: Um jogo para o Aprendizado em Inspeção
de Software. Universidade do Estado do Rio de Janeiro, 2011.
PRENSKY, M. Digital Game-Based Learning. New York: McGraw-Hill, 2001.
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.
53
PRIKLADNICKI, R.; WANGENHEIM, C. O Uso de Jogos Educacionais para o
Ensino de Gerência de Projetos de Software. Rio Grande do Sul, 2008.
REIF, H. L., MITRI, M. How University Professors Teach Project Management for
Information Systems. Communications of the ACM, v. 48, n. 8, p. 134-136, 2005.
ROSA, R.; KIELING, E. Planager - Um Jogo para Apoio ao Ensino de Gerência de
Projetos de Software. Rio Grande do Sul, 2006.
RUSU, A.; RUSSEL, R.; ROBINSON, J.; RUSU, A. Learning Software Engineering
Basic Concepts using a Five-Phase Game. Fronteiras na Conferência de Educação,
Washington, 2010.
SANTOS, R.; SANTOS, P.; WERNER, C.; TRAVASSOS, G.; Utilizando
Experimentação para Apoiar a Pesquisa em Educação em Engenharia de Software
no Brasil. I FEES - I Fórum de Educação em Engenharia de Software. Campinas, 2008.
SASKATOON Public Schools. Instrucional Strategies Online. 2003-2009. Disponível
em: <http://olc.spsd.sk.ca/de/pd/instr/index.html>. Acesso em: 09 jun. 2014.
SHABALINA, O.; SADOVNIKOVA, N.; KRAVETS, A. Methodolody of Teaching
Software Engineering: Game-based Learning Cycle. Volgograd State Technical
University. Russia, 2013.
SHAW, K.; DERMOUDY, J. Engendering an Empathy for Software Engineering.
7ª Conferência Austrália/Ásia sobre Educação para Computação, 2005.
SHTUB, A. Project Management Simulation With PTB Project Team Builder.
Faculty of Industrial Engineering and Management. Technion Israel Institute of
Technology, 2010.
SILVA, A. Jogo educacional para apoiar o ensino de técnicas para elaboração de
testes de unidade. Universidade do Vale do Itajaí, 2010.
SMITH, R.; GOTEL, O. RE-O-Poly: A Customizable Game to Introduce and
Reinforce Requirements Engineering Good Practices. Pace University, New York,
2008.
SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley,
2003.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison
Wesley, 2007.
SOTILLE, M. Gerenciamento de Projetos na Engenharia de Software. 2014. PM
TECH - Capacitação em Projetos. Disponível em:
<http://www.pmtech.com.br/artigos/Gerenciamento_Projetos_Software.pdf>. Acesso
em: 25 jul. 2014.
54
SOUZA, D.; VASCONCELOS, C.; AZEVEDO, R.; FUJIOKA, R.; ALMEIDA, M.;
FREITAS, F. Honey: Um Ambiente Virtual Baseado em Agentes para Apoiar o
Ensino de Engenharia de Software. In: XIX Simpósio Brasileiro de Informática na
Educação, Fortaleza-CE. v. 1. p. 55-64, 2008.
SOUZA, M.; RESENDE, R.; PRADO, L.; FONSECA, E.; CARVALHO, F.;
RODRIGUES, A. SPARSE: Um Ambiente de Ensino e Aprendizado de Engenharia
de Software Baseado em Jogos e Simulação. Univerisdade Federal de Alfenas, 2010.
TARAN, G. Using Games in Software Engineering Education to Teach Risk
Management. 20 ª Conferência sobre Software Engineering Education & Training,
Dublin, 2007.
THIRY, M.; ZOUCAS, A.; GONÇALVES, R. Promovendo a Aprendizagem de
Engenharia de Requisitos de Software Através de um Jogo Educativo. Universidade
do Vale do Itajaí, São José - SC, 2010.
VEGA, K.; PEREIRA, A.; ROBICHEZ, G.; FUKS, H. TREG Usability Tests:
Evaluating a training game in Second Life. Simpósio Brasileiro de Sistemas
Colaborativos, p. 63-70, Belo Horizonte, 2010.
VERONESE, G. Sistematização do Desenvolvimento de Jogos de Simulação para
Treinamento. Universidade Federal do Rio de Janeiro, 2004.
WAGNER, R. Edgar Dale: Professional Theory into Practice. v. 9. p. 89-95, 1970.
WANG, W. O Aprendizado através de jogos para computador: por uma escola
mais divertida e mais eficiente. São Paulo, 2005.
WANGENHEIM, C.; THIRY, M.; e KOCHANSKI, D. Empirical evaluation of na
educational game on software measurement. Empirical Software Engineering, v. 1, p.
1-35, 2008.
WANGENHEIM, C.; WANGENHEIM, A. Ensinando Computação com Jogos.
Florianópolis: Bookess Editora, 2012.
WANGENHEIM, C.; KOCHANSKI, D.; SAVI, R. Revisão Sistemática sobre
Avaliação de Jogos Voltados para Aprendizagem de Engenharia de Software no
Brasil. Universidade Federal de Santa Catarina, 2010.
YE, E.; LIU, C.; POLACK-WAHL, J. L. Enhancing Software Engineering
Education Using Teaching Aids in 3-D Online Virtual Worlds. Conferência de
Educação - Engenharia Global: Conhecimento Sem Fronteiras, Oportunidades Sem
Passaportes, Milwaukee, 2007.
55
APÊNDICE A – JOGOS ENCONTRADOS
ID Jogo Idioma Subárea da ES Jogadores Nível T. Bloom Mídia Autores
1.6 SimSE Inglês Gerenciamento de Projetos Single-player Lembrar
Jogo
Eletrônico
(Navarro e Hoek
2009)
2.7 Problems and
Programmers
Inglês Conceitos Gerais Multiplayer Lembrar, Entender Jogo de
Cartas
(Baker, Navarro
e Hoek 2003)
3.8 SESAM Alemão Conceitos Gerais e
Gerenciamento de Projetos
Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Ludewig 2003)
4.9 SimulES Português Conceitos Gerais e
Gerenciamento de Projetos
Multiplayer Lembrar, Analisar Jogo de
Tabuleiro
(Figueiredo et.
al. 2007)
6 http://www.ics.uci.edu/~emilyo/SimSE/downloads.html
7 http://boardgamegeek.com/images/boardgame/21999/problems-and-programmers
8 http://www.iste.uni-stuttgart.de/se/research/sesam/index_e.html
9 http://homepages.dcc.ufmg.br/~figueiredo/simules/
56
5.10
MO-SEProcess Inglês Conceitos Gerais Multiplayer Lembrar Jogo
Eletrônico
(Ye, Liu e
Polack-Wahl
2007)
6.11
The Incredible
Manager
Inglês Gerenciamento de Projetos Single-player Lembrar, Entender,
Aplicar e Analisar
Jogo
Eletrônico
(Dantas 2003)
7.12
Ilha dos Requisitos Português Engenharia de Requisitos Single-player Lembrar, Entender Jogo
Eletrônico
(Thiry, Zoucas e
Gonçalves 2010)
8.13
SPIAL Inglês Gerenciamento de Projetos e
Validação/Testes
Single-player Entender, Analisar Jogo
Eletrônico
(Kupsch e
Resende 2013)
9.14
Planager Português Gerenciamento de Projetos Single-player Entender, Criar Jogo
Eletrônico
(Rosa e Kieling
2006)
10.15
Software Quantum Inglês Engenharia de Requisitos Single-player Lembrar Jogo
Eletrônico
(Knauss,
Schneider e
Stapel 2008)
10
http://slurl.com/secondlife/OHIO%20Outreach/173/190/34
11 http://reuse.cos.ufrj.br/site/pt/index.php?option=com_docman&task=cat_view&gid=19&Itemid=30
12 http://www.incremental.com.br/ilhadosrequisitos/
13 http://homepages.dcc.ufmg.br/~cascini/
14 http://www.inf.pucrs.br/~rafael/Planager
15 http://docentis.inf.um.es/REgames/sq.html
57
11. SimVBSE Inglês Gerenciamento de Projetos Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Jain e Boehm
2006)
12. SimulES-W Inglês Conceitos Gerais Multiplayer Lembrar, Entender e
Analisar
Jogo
Eletrônico
(Monsalve,
Werneck e Leite
2011)
13.16
RE-O-Poly Inglês Engenharia de Requisitos Multiplayer Aplicar Jogo de
Tabuleiro
(Smith e Gotel
2008)
14. TREG Inglês Engenharia de Requisitos Single-player Lembrar Jogo
Eletrônico
(Vega et. al.
2010)
15. SimJavaSP Inglês Conceitos Gerais e
Gerenciamento de Projetos
Single-player Lembrar, Entender e
Avaliar
Jogo
Eletrônico
(Shaw e
Dermoudy 2005)
16.17
SE-RPG Português Gerenciamento de Projetos Single-player Lembrar, Aplicar Jogo
Eletrônico
(Benitti e Molleri
2008)
17.18
X-Med Inglês Validação/Testes Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Wangenheim,
Thiry e
Kochanski 2008)
18. Magic analysis game Inglês Engenharia de Requisitos Single-player Lembrar, Entender e Jogo (Shabalina 2013)
16
http://home.comcast.net/~r-smith/site/?/page/RE_Game/
17 http://siaiacad17.univali.br/serpg/
18 http://www.incremental.com.br/xmed/
58
Analisar Eletrônico
19. Five-Phase Game Inglês Conceitos Gerais Single-player Lembrar, Entender Jogo
Eletrônico
(Rusu et. al.
2010)
20. Communication and
Traceability Game
Inglês Engenharia de Requisitos Multiplayer Lembrar, Entender Jogo
Eletrônico
(Jaramillo 2010)
21.19
JEEES Português Conceitos Gerais Multiplayer Lembrar Jogo de
Tabuleiro
(Figueiredo et.
al. 2010)
22.20
PlayScrum Inglês Conceitos Gerias e
Gerenciamento de Projetos
Multiplayer Lembrar e Aplicar Jogo de
Cartas
(Fernandes e
Sousa 2010)
23.21
SDM Inglês Conceitos Gerais Multiplayer Lembrar e Analisar Jogo
Eletrônico
(Kohwalter, Clua
e Murta 2011)
24. Rolly-Polly game Inglês Implementação e
Validação/Testes
Single-player Aplicar Jogo
Eletrônico
(Shabalina 2013)
25.22
UTest Português Validação/Testes Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Silva 2010)
19
http://sel.ic.uff.br/jeees/
20 http://www.playscrum.com/games/
21 http://gems.ic.uff.br/sdm/
22 http://www.incremental.com.br/utest/
59
26. SPARSE Português Gerenciamento de Projetos Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Souza et. al.
2010)
27. InspectorX Português Validação/Testes Single-player Entender e Analisar Jogo
Eletrônico
(Potter e Schots
2011)
28. Board game Inglês Conceitos Gerais Multiplayer Entender Jogo de
Cartas
(Taran 2007)
29. Guess what we want Inglês Engenharia de Requisitos Multiplayer Lembrar e Avaliar Jogo de
Listas
(Alexander e
Beatty 2008)
30. UbiRE Português Engenharia de Requisitos Single-player Lembrar e Entender Jogo
Eletrônico
(Lima et. al.
2012)
31. Honey Português Conceitos Gerais Single-player Lembrar Jogo
Eletrônico
(Souza et. al.
2008)
32. Scrumming Português Gerenciamento de Projetos Single-player Entender e Aplicar Jogo
Eletrônico
(Isotton 2008)
33. CBT Inglês Gerenciamento de Projetos Single-player Lembrar e Entender Jogo
Eletrônico
(Pfahl, Klemm e
Ruhe 2000)
34. YAMM Inglês Gerenciamento de Projetos Single-player Lembrar e Entender Jogo
Eletrônico
(Veronese 2004)
35. PROMEG Inglês Gerenciamento de Projetos Single-player Lembrar, Entender e
Aplicar
Jogo
Eletrônico
(Mira, Santos e
Costa 2012)
60
36.23
iTest Lerning Português Validação/Testes Single-player Lembrar e Entender Jogo
Eletrônico
(Farias et. al.
2012)
ID = Identificação;
*OBS: A Subárea “Conceitos Gerais” aborda as quatro fases dos processos da Engenharia de Software, podendo, ou não, ter tendência a uma subárea específica. Exemplo: O
jogo SimSE aborda conceitos gerais, mas sua ênfase é o gerenciamento de projetos.
23
https://sistemas.quixada.ufc.br/iTestLearning/
