AprendES Um Jogo Educacional Para Auxiliar o Proceso de Ensino-Aprendizagem Da Engenharia de...
76
UNIVERSIDADE DO ESTADO DO RIO GRANDE DO NORTE Aldefran Carvalho Feitosa AprendES: um jogo educacional para auxiliar o processo de ensino-aprendizagem da Engenharia de Software NATAL/RN 2010
-
Upload
jonathas-feitosa -
Category
Documents
-
view
544 -
download
0
Transcript of AprendES Um Jogo Educacional Para Auxiliar o Proceso de Ensino-Aprendizagem Da Engenharia de...
UNIVERSIDADE DO ESTADO DO RIO GRANDE DO NORTE
Aldefran Carvalho Feitosa
AprendES: um jogo educacional para auxiliar o processo de ensino-aprendizagem da Engenharia de
Software
NATAL/RN
2010
Aldefran Carvalho Feitosa
AprendES: um jogo educacional para auxiliar o processo de ensino-aprendizagem da Engenharia de Software
Monografia apresentada à Universidade do Estado do Rio Grande do Norte como um dos pré-requisitos para obtenção do grau de bacharel em Ciência da Computação
ORIENTADOR(A): Glaucia Melissa Medeiros Campos
NATAL/RN
2010
Aldefran Carvalho Feitosa
AprendES: um jogo educacional para auxiliar o processo de ensino-aprendizagem da Engenharia de Software
Monografia apresentada à Universidade do Estado do Rio Grande do Norte como um dos pré-requisitos para obtenção do grau de bacharel em Ciência da Computação
Aprovado em ____/____/____.
Banca Examinadora
_______________________________ Msc. Glaucia Melissa Medeiros Campos
UERN – Campus de Natal
_______________________________ Msc. Camila de Araújo
UERN – Campus de Natal
_______________________________ Dr. João Maria Pires
UERN – Campus de Natal
Aos que com sabedoria utilizam seus conhecimentos a serviço do bem da humanidade.
AGRADECIMENTOS
Ao meu Senhor, o Deus criador do céu e da terra. Faço minhas as palavras do
Apóstolo Paulo em Atos “Porque nele vivemos, e nos movemos, e existimos”. A
meus pais, Francisco Alves Feitosa (In Memorian) e Aldenora Carvalho Feitosa pelo
amor, incentivo e o norte que sempre deram à minha vida. À Fátima, amiga e
incentivadora, sempre presente, com quem vencemos grandes desafios durante
esta jornada, posso dizer como o sábio Salomão “Aquele que encontra uma esposa,
acha o bem, e alcança a benevolência do Senhor”, obrigado pelo seu amor, carinho
e compreensão. Te amo. Aos meus filhos Jemima e Jonathas, pelo apoio e pela
torcida para que tudo desse certo, obrigado por entenderem quando foi preciso me
ausentar para dar vencimento àquilo que o curso exigia. Amo vocês. Aos irmãos e
amigos Alcides e Aninha, e na pessoa deles, a todos os irmãos, de todas as
congregações que dirigimos neste período como também aos que não estiveram
sobre nosso pastorado, pelas orações e apoio. O Senhor vos recompensará. A
professora Lyrene Fernandes, por me indicar o tema. A minha orientadora
professora Glaucia Campos, pela dedicação, atenção e encorajamento, além da
paciência de sempre nos atender em nossas dúvidas. A todos os professores e
professoras bem como a todos os funcionários da UERN. Aos amigos que ao longo
deste caminho conquistamos aos quais devo muito, não só pelas ajudas em
momentos de provas, seminários e trabalhos, mas senão também pela amizade e
carinho com que sempre fomos tratados, em especial a: Jorge Felliphe, Dayanne
Scallé, João Batista, Jackson Costa, Thiago Augusto, Lidiane Oliveira, Mizael
Araujo, Joel Gonçalves, Wellington, Claudete e Karlyle, posso dizer de vocês o que
diz o sábio em provérbios “como o óleo e o perfume alegram o coração, assim, o
amigo encontra doçura no conselho cordial”. À Tendson, amigo que ganhamos
nesta jornada, que abriu a sua casa e compartilhou conosco sua coleção de jogos
de tabuleiro para nos auxiliar na compreensão deste universo tão maravilhoso que é
a ludicidade. Ao Professor Júlio Leite e a Felipe Napolitano da PUC-Rio pela
presteza em nos atender e fornecer material que foi muito proveitoso no
desenvolvimento deste trabalho. Muito obrigado a todos, a minha oração é que a
benção de Deus vos alcance e vos façam prosperar em tudo quanto fizerem.
O que ensina dedique-se em fazê-lo. Apóstolo Paulo.
RESUMO
A utilização de jogos educativos tem se mostrado útil no auxilio do processo
de ensino-aprendizagem em todos os níveis de ensino, em especial nas disciplinas
que apresentam em seu conteúdo conceitos eminentemente teóricos, exigindo do
aluno um alto grau de abstração para entendê-los. A Engenharia de Software, dos
cursos da área de Computação, é uma dessas disciplinas. Sendo assim, este
trabalho apresenta o AprendES, um jogo educativo de tabuleiro, não eletrônico, na
categoria de jogos cooperativos, como uma ferramenta para auxiliar o processo de
ensino-aprendizagem desta disciplina. Para seu desenvolvimento foi realizado um
estudo dos conceitos da disciplina, bem como de outros jogos utilizados no ensino
da Engenharia de Software e de diversos jogos de tabuleiro. O AprendES oferece a
oportunidade aos seus participantes de terem contato com conceitos importantes da
disciplina simulando durante a sua realização o desenvolvimento de um projeto de
software desde seu planejamento até sua finalização, que pode ser bem sucedido
ou não, permitindo assim que possa ser vivenciada a realidade de um ambiente de
desenvolvimento de software. Ao final do trabalho, são apresentados resultados da
avaliação do jogo realizada por alunos iniciantes e concluintes da disciplina.
PALAVRAS-CHAVES: AprendES, Jogos Educativos, Engenharia de Software.
ABSTRACT The use of educative games has if shown useful in it I assist of the process of teach-
learning in all the education levels, in special in them you discipline that theoreticians
present in its content concepts eminently, demanding of the pupil one high degree of
abstraction to understand them. The Engineering of Software, of the courses of the
area of Computation, is one of these disciplines. Being thus, this work presents the
AprendES, an educative tray game, not electronic, in the category of cooperative
games, as a tool to assist the process of teach-learning of this disciplines. For its
development a study of the concepts was carried through of disciplines, as well as of
other games used in the education of the Engineering of Software and diverse tray
games. The AprendES offers the chance to its participants to have contact with
important concepts of disciplines simulating during its accomplishment the
development of a software project since its planning until its finishing, that can be
successful or not, allowing as soon as can be lived deeply the reality of an
environment of software development. To the end of the work, they are presented
resulted of the evaluation of the game carried through for beginning pupils and to
conclude of it disciplines.
KEYWORDS: AprendES, Educative Games, Engineering of Software.
LISTA DE FIGURAS
Figura 1: Snakes and Ladders algoritmo recursivo Game (o tabuleiro do jogo) ........ 24
Figura 2: Tela de Apresentação do Projeto ao usuário do SESAM.( França, 2007) . 26
Figura 3: Planager, Fase caminho critico (KIELING et al, 2006) ............................... 27
Figura 4: Scrumming Definição de uma Sprint (Prikladnicki e Wangenheim, 2008) . 28
Figura 5: Exemplos de telas do X-MED v1.0 (Prikladnicki e Wangenheim, 2008) .... 29
Figura 6: Tabuleiro do jogo SimulES((Figueiredo et al, 2006 )). ................................ 30
Figura 7 : Fases do modelo cascata (Sommerville 2007).......................................... 39
Figura 8: Desenvolvimento evolucionário (Sommerville 2007) .................................. 40
Figura 9: Engenharia de software baseado em componentes (Sommerville 2007) .. 41
Figura 10: Entrega incremental (Sommerville 2007) ................................................. 42
Figura 11: Ciclo de release em XP (Sommerville 2007). ........................................... 42
Figura 12: O modelo espiral (Mazzola, 2003). ........................................................... 44
Figura 13. Carta problema - doença .......................................................................... 47
Figura 14. Carta problema - grau de dificuldade 10 .................................................. 48
Figura 15. Carta ferramentas case. ........................................................................... 49
Figura 16. Carta convênio com custo. ....................................................................... 49
Figura 17. Botões ...................................................................................................... 50
Figura 18. Carta qualidade ........................................................................................ 50
Figura 19. Carta tamanho.......................................................................................... 51
Figura 20. Carta complexidade ................................................................................. 51
Figura 21. Moedas .................................................................................................... 52
Figura 22. Módulos apresentando os conjuntos de artefatos. ................................... 53
Figura 23. Carta status do engenheiro de software ................................................... 53
Figura 24. Carta nível de experiência de engenheiro de software ............................ 54
Figura 25. Módulo dos jogadores (Engenheiro de Software) .................................... 54
Figura 26. Engenheiro Geral ..................................................................................... 55
Figura 27. Conjuntos de artefatos ............................................................................. 55
Figura 28. Tabuleiro do Jogo AprendES ................................................................... 56
LISTA DE TABELAS
Tabela 1– Comparativo e parâmetros dos métodos educacionais: ensino tradicional
x aprendizagem construtivista. Fonte: Sauaia (1995:239)......................................... 23
Tabela 2. Orçamento do projeto ................................................................................ 58
Tabela 3. Custos dos engenheiros ............................................................................ 60
LISTA DE GRÁFICOS
Gráfico 1: Conseguiu entender as regras do jogo? ................................................... 69
Gráfico 2: Entendimento/Transmissão de conceitos. ............................................... 70
Gráfico 3: Aparência e funcionalidade da interface. .................................................. 71
Gráfico 4: Preferência entre jogo eletrônico ou na versão atual. ............................... 71
SUMÁRIO
CAPÍTULO 1 ............................................................................................................. 15
INTRODUÇÃO .......................................................................................................... 15
CAPÍTULO 2 ............................................................................................................. 19
EDUCAÇÃO LÚDICA ............................................................................................... 19
2.1. JOGOS EDUCATIVOS NO ENSINO DA COMPUTAÇÃO ............................... 23
2.1.1. SNAKES AND LADDERS: JOGO PARA O ENSINO DE ALGORITMOS 24
2.2 . JOGOS PARA O ENSINO DA ENGENHARIA DE SOFTWARE ..................... 25
2.2.1. O JOGO SESAM(Software Engineering Simulation by Animated Models)
............................................................................................................................ 26
2.2.2. O JOGO PLANEGER, ............................................................................. 27
2.2.3. O JOGO SCRUMMING, ........................................................................... 28
2.2.4. O JOGO X-MED v1.0, .............................................................................. 28
2.2.5. O JOGO SimulES ..................................................................................... 29
CAPÍTULO 3 ............................................................................................................. 31
ENGENHARIA DE SOFTWARE ............................................................................... 31
3.1. GERÊNCIA DE PROJETO .............................................................................. 31
3.2. GERENCIAMENTO DE PESSOAL ................................................................. 32
3.3. GERENCIAMENTO DE RISCOS .................................................................... 34
3.4. GERENCIAMENTO DE QUALIDADE.............................................................. 36
3.5. VERIFICAÇÃO E VALIDAÇÃO ........................................................................ 36
3.6. REQUISITOS DE SOFTWARE ....................................................................... 37
3.7. MODELOS DE PROCESSO DE SOFTWARE ................................................. 38
3.1.1. MODELO CASCATA ................................................................................ 38
3.1.2. DESENVOLVIMENTO EVOLUCIONÁRIO ............................................... 39
3.1.3. ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES .......... 40
3.1.4. MODELO ITERATIVO .............................................................................. 41
3.1.4.1. ENTREGA INCREMENTAL ................................................................ 41
3.1.4.2. DESENVOLVIMENTO ESPIRAL ........................................................ 42
CAPITULO 4 ............................................................................................................. 45
O JOGO APRENDES ............................................................................................... 45
4.1. COMPONENTES DO JOGO ........................................................................... 46
4.1.1. CARTAS PROBLEMAS ............................................................................ 46
4.1.2. CARTAS CONCEITOS ............................................................................. 48
4.1.3. BOTÕES ................................................................................................... 49
4.1.4. CARTAS QUALIDADE .............................................................................. 50
4.1.5. CARTAS TAMANHO ................................................................................ 50
4.1.6. CARTAS COMPLEXIDADE ...................................................................... 51
4.1.7. MOEDAS .................................................................................................. 51
4.1.8. MÓDULOS ................................................................................................ 52
4.1.9. CARTAS STATUS .................................................................................... 53
4.1.10. CARTAS NÍVEL DE EXPERIÊNCIA ....................................................... 53
4.1.11. MÓDULO DO JOGADOR ....................................................................... 54
4.1.12. CARTA ENGENHEIRO GERAL.............................................................. 54
4.1.13. CARTAS CONJUNTO DE ARTEFATOS ................................................ 55
4.2. REGRAS DO JOGO ........................................................................................ 55
CAPITÚLO 5 ............................................................................................................. 65
CONSIDERAÇÕES FINAIS ...................................................................................... 65
BIBLIOGRAFIA ........................................................................................................ 73
ANEXO...................................................................................................................... 76
15
Capítulo 1
INTRODUÇÃO
De acordo com Karoline Kahl (2007), a utilização de práticas lúdicas contribui
para o aprendizado. Sendo assim, diversos tipos de jogos educativos, independente
do nível de ensino, vêm sendo utilizados para aprimorar a comunicação entre alunos
e professores (Alves, 2006). Os jogos educativos propiciam aos professores
estimular os alunos quanto à aprendizagem. A sua utilização tem demonstrado isso
quando os alunos entram em contato com o objeto de estudo, facilitando assim o
trabalho do professor, pois a dinâmica dos jogos permite ao aluno desenvolver
habilidades a partir da compreensão de suas regras, bem como apreender os
conceitos do conteúdo alvo do jogo. Outra vantagem desta abordagem de ensino é
que desenvolve também o aspecto afetivo-social entre os alunos envolvidos, o que
os prepara para a vida fora do ambiente de aprendizagem, visto que na disputa, na
vitória ou derrota no jogo, o aluno aprende a elaborar seus relacionamentos e
observar melhor a realidade social em que está inserido.
Os simuladores de vôo são um exemplo pratico desta realidade, pois auxiliam
no processo de ensino-aprendizagem de como pilotar um avião (Soares, 1998),
criando um ambiente simulado dos diversos cenários que envolvem esta atividade.
Tem se comprovado através da utilização desta técnica que o impacto de decisões
erradas tomadas durante os exercícios evitam prejuízos significativos caso as
mesmas se dessem em um ambiente real.
16
Não é de hoje que os jogos educativos vêm sendo utilizados em diversos
cursos de graduação. Nos cursos da área de Computação tem se comprovado que a
utilização de jogos auxilia o estudante a absorver melhor os conceitos estudados e a
compreender as conseqüências das decisões tomadas, simulando durante o jogo a
realidade que enfrentará no dia-a-dia quando estiver efetivamente trabalhando nos
projetos em que esteja envolvido (Rossiou e Papadakis, 2007).
Estudos já observaram, do ponto de vista acadêmico, que disciplinas como
Engenharia de Software que são estudadas de forma predominantemente teórica,
tem os seus resultados, com relação à compreensão dos conceitos e métodos
estudados, se mostrado insuficiente para preparar adequadamente o profissional
para o mercado de trabalho, se este não tiver tido previamente alguma vivencia
prática, por mais simples que seja (Reif e Mitri, 2005).
Por isso a importância da utilização de jogos no ensino da Engenharia de
Software, visando simular o ambiente de trabalho, propiciando ao aluno aprender os
conceitos teóricos da disciplina, assim como vivenciar, através da simulação,
diferentes cenários e práticas de ambientes reais de desenvolvimento de software,
possibilitando, dessa forma, o exercício nas tomadas de decisões dentro do
processo. A utilização de simulações permite ainda que o aluno se depare com uma
gama maior de situações diferentes em um menor espaço de tempo.
Além da simulação, a utilização de jogos no aprendizado possui diversas
vantagens, pois permite explorar um determinado ramo de conhecimento, além de
trabalhar com algumas habilidades, como, por exemplo, destreza, associação de
idéias e raciocínio lógico e indutivo. No contexto da Engenharia de Software, isso é
17
especialmente importante, uma vez que a motivação dos alunos tende a diminuir
devido ao excesso de teoria que lhe é passado.
Sendo assim, este trabalho apresenta um jogo de cartas, não eletrônico, com
caráter educativo, que seja aplicado na sala de aula, para auxiliar o processo de
ensino-aprendizagem da disciplina de Engenharia de Software, dos cursos da área
de Computação. Em virtude da disciplina de Engenharia de Software envolver
muitos conceitos e na exposição do assunto não permitir ao aluno vivenciar na
prática o que está sendo discutido em aula, o jogo propiciará, além da apreensão
desses conceitos, a possibilidade de se trabalhar com o desenvolvimento de
algumas das atividades inerentes à Engenharia de Software, dentre elas, a interação
que deve haver entre a equipe de desenvolvedores, por isso a opção de se fazer um
jogo que não seja eletrônico, mas sim um jogo que permita aos alunos trabalharem
em equipe, considerando que na sua quase totalidade os jogos eletrônicos são
individualizados, pois mesmo os jogos de computador multiplayer forçam uma
situação de cada um em seu lugar, ou no seu micro, não propiciando que haja
contato real entre as pessoas.
As vantagens desta colaboração podem ser observadas em Schaeffer (2006),
onde o autor afirma que os jogos em grupo possibilitam aos indivíduos trabalharem
com a regularidade, o limite, o respeito e a disciplina, por meio de ações
necessariamente subordinadas a regra. Todos esses aspectos se fazem importantes
para a vida do indivíduo em sociedade. Outro fator é que os jogos de tabuleiro
podem ser jogados a qualquer hora e lugar, enquanto um jogo sem tabuleiro pode
depender de condições que muitas vezes não podemos controlar (estrutura, tempo e
lugar), além de poderem acomodar várias pessoas ao mesmo tempo.
18
Este trabalho está organizado em cinco capítulos, sendo a Introdução o
primeiro deles e o restante estruturado da seguinte forma: o Capítulo 2 apresenta a
importância da educação lúdica, assim como mostra alguns jogos encontrados na
literatura, que são utilizados nos cursos de Computação; o Capítulo 3 descreve os
principais conceitos da Engenharia de Software a serem utilizados no jogo; o
Capítulo 4 apresenta os componentes e as regras do AprendES. Por fim, o capítulo
5 apresenta as considerações finais e os trabalhos futuros.
19
Capítulo 2
EDUCAÇÃO LÚDICA
“A educação lúdica está distante da concepção ingênua de
passatempo, brincadeira vulgar, diversão superficial. Ela é uma ação inerente na criança, no adolescente, no jovem e no adulto e aparece sempre como uma forma transacional em direção a algum conhecimento, que se redefine na elaboração constante do pensamento individual em permutações com o pensamento coletivo”. (Paulo Nunes de Almeida)
A utilização de jogos pelo ser humano remonta a centenas de anos atrás. E,
ao contrário do que se possa imaginar, que os jogos serviam somente para diversão
e entretenimento, o desenvolvimento de alguns jogos já tinham a finalidade de
serem utilizados como ferramenta de ensino. Tem se notícias de jogos para
treinamento e desenvolvimento de estratégias, como o GO, um jogo de tabuleiro,
criado pelo imperador chinês Yao (2337-2258 a.C.) para ensinar seu filho Danzhu
disciplina, concentração e equilíbrio. (Fernandes & Werner, 2009)
O modelo tradicional de ensino, baseado na teoria do filósofo inglês John
Locke (Wikipédia, 2009), vê o aprendiz como um sujeito desprovido de qualquer
conhecimento anterior sobre o objeto a ser estudado, daí a denominação dada a tal
aprendiz de tabula rasa, termo que deriva do latim “folha em branco” (Wikipédia,
2010). Então, neste modelo, o aprendiz é receptor do conhecimento do professor,
onde este pode imprimir o conteúdo que está sendo transmitido ao aluno, a “Folha
em Branco”. Nesta visão, o professor é detentor do conhecimento e muitas vezes
não estimula no aluno sua capacidade reflexiva, de análise e vivência com o objeto
20
de estudo, o que impede ao aluno elaborar conceitos que permitam ligar o que
estudou com a sua vida cotidiana, onde a matéria estudada é apenas para o dia da
prova, para se obter a nota necessária para aprovação. Este princípio ainda permeia
a maneira como as políticas educacionais de muitos países são pensadas e
desenvolvidas, inclusive no Brasil (Wikipédia, 2010).
Outro modelo mais recente que se contrapõe ao ensino tradicional é o modelo
construtivista do epistemologista suíço, Jean Piaget (Konrath et al, 2005). Neste
modelo, o aluno é visto como alguém dotado de conhecimentos natos, e que estes
precisam ser feitos vir a tona através de estímulos corretos. A discussão então gira
em torno de que se pode substituir o método tradicional de ensino por métodos
inovadores, sem que haja a quebra do propósito de não só ensinar um conteúdo,
mas também de prepará-lo para os desafios da vida.
Dentre esses métodos inovadores, tem-se utilizado os jogos educativos,
observando-se que através do lúdico podem ser ensinados conteúdos básicos para
crianças, conteúdos mais complexos como física e matemática para alunos do
ensino médio e também em cursos no ensino superior, como os jogos de empresa
utilizados nos cursos de administração de empresas, conforme pode ser observado
em Martinelli (1987).
Os jogos educativos são uma área que pode tornar-se alvo de inúmeras
pesquisas. Se o ensino for lúdico e desafiador, a aprendizagem prolonga-se fora da
sala de aula, fora da escola, pelo cotidiano, num crescimento muito mais rico do que
algumas informações que o aluno decora (Neto, 1992). Tenta-se assim mudar a
idéia, até então vigente, que ensinar é simplesmente transmitir, o que ocorreu por
muito tempo. Busca-se então material pedagógico que desperte o interesse do
aluno, em virtude de que o interesse do aluno comanda o processo da
21
aprendizagem e suas experiências e descobertas é o que movimenta o seu
progresso. O professor assume então o papel de gerador de situações
estimuladoras e eficazes.
É nesse contexto que o jogo ganha um espaço como ferramenta ideal de
aprendizagem, na medida em que propõe estímulo ao interesse do aluno. O jogo
ajuda-o a construir suas novas descobertas, desenvolve e enriquece sua
personalidade, permiti o seu desenvolvimento afetivo-social, auxilia na elaboração
do raciocínio lógico e simboliza um instrumento pedagógico que leva o professor à
condição de condutor, estimulador e avaliador da aprendizagem.
Na análise apresentada no VII Encontro Nacional de Pesquisa em Educação
em Ciência, as autoras (Fontoura et al, 2000) mostram os resultados de sua
pesquisa sobre jogos educativos realizada com uma das turmas do 9º período, do
Instituto de Aplicação Fernando Rodrigues da Silveira (CAP/UERJ). Foi feita a
seguinte pergunta: Jogos educativos ajudam na compreensão de alguma matéria?
88% dos alunos responderam de forma afirmativa. As autoras concluíram que a
contribuição positiva dos jogos educativos foi, em vista disso, reafirmada no público-
alvo desta pesquisa, e que a diversão proporcionada pelos jogos motiva a
participação dos alunos em aula e facilita a compreensão de conteúdos mais
complexos, permitindo que os alunos consigam relembrar as atividades e os temas
abordados em sala de aula.
Observamos então que a prática, embutida nos jogos, permite ao aluno
vivenciar o assunto estudado, e este vivenciar ajuda-o a apreender os conceitos.
Sendo assim, a utilização de jogos educativos na sala de aula constitui-se de
ferramenta que auxilia o professor na sua tarefa de ensinar.
22
A Tabela 1 resume as principais características do ensino baseado na
aprendizagem construtivista, tecendo uma análise comparativa com o ensino
tradicional. Segundo Sauaia (1995), no ensino tradicional, o educador desempenha
o papel principal. Ele é o personagem que apoiado em suas experiências, deseja
ensinar a seus alunos, estabelecendo, para isso, objetivos educacionais coletivos,
orientados para a classe como um todo. Mantém a aula em andamento mediante a
geração permanente de estímulos externos. Atuando desta forma, cria um ambiente
eminentemente individualista e competitivo. Na aprendizagem construtivista, o papel
principal desloca-se para o educando, que passa a ser o centro do processo,
diferentemente do ensino tradicional. Isto facilita um envolvimento maior, pelo desejo
fomentado na busca de aprendizagem competitiva e cooperativa. O trabalho em
grupo prevalece sobre a apresentação expositiva e individual do instrutor. São
exercitados conteúdos do educando e do educador. O processo é calcado
nos motivos dos educandos, em um ambiente que desafia, ao mesmo tempo em que
acolhe, combinando momentos de disputa e de união entre os educandos e entre
eles e o educador (Martinelli, 1987).
23
Tabela 1– Comparativo e parâmetros dos métodos educacionais: ensino tradicional x aprendizagem construtivista. Fonte: Sauaia (1995:239)
Parâmetros Educacionais Ensino Tradicional Aprendizagem construtivista
Orientação didática Ensino Aprendizagem
Personagem central Educador Educando
Conteúdos trabalhados Do educador Do educando
Envolvimento do educador Alto Baixo
Envolvimento do educando Baixo Alto
Atitude que orienta Quero ensinar Quero aprender
Técnica usual Expositiva Atividade em grupo
Tipo de aprendizagem Cognitiva Cognitiva, afetiva, cooperativa, atitudinal e comportamental
Áreas trabalhadas Cérebro Todo o indivíduo
Aplicação de conceitos Teórica Prática
Objetivos educacionais Gerais e coletivos Específicos e individualizados
Avaliados da aprendizagem Educador Educando
Andamento da aula Estímulo do educador
Motivos do educando
Ambiente criado Competitivo Competitivo e cooperativo
Podemos então dizer que uma vez estabelecido e obedecido o sistema de um
jogo, aprender pode tornar-se tão divertido quanto brincar e, nesse caso, aprender
torna-se interessante para o aluno e passa a fazer parte de sua lista de preferências.
Certamente, fazer com que o aluno veja o ato de aprender como algo interessante
em vez de tedioso é o grande desafio nas atuais práticas educacionais.
Como o objetivo do trabalho está direcionado para a utilização de jogos no
ensino da computação, as seções seguintes apresentam exemplos de jogos
educativos utilizados em instituições de nível superior para esta área.
2.1. JOGOS EDUCATIVOS NO ENSINO DA COMPUTAÇÃO
Os cursos de nível superior que envolvem o ensino da computação estão
descobrindo as vantagens da utilização dos jogos educativos para facilitar o
processo de ensino aprendizagem das disciplinas ministradas aos seus alunos.
24
2.1.1. SNAKES AND LADDERS: JOGO PARA O ENSINO DE ALGORITMOS
A Figura 1 apresenta a tela do jogo Snakes and Ladders (Rossiou e
Papadakis, 2007), um ambiente de simulação para criar algoritmos recursivos,
utilizado no ensino de algoritmos recursivos para alunos do primeiro semestre, da
disciplina de Algoritmos em C, do Departamento de Informática Aplicada, da
Universidade da Macedónia, em Salónica, Grécia.
Figura 1: Snakes and Ladders algoritmo recursivo Game (o tabuleiro do jogo)
O jogo funciona da seguinte forma: os estudantes jogam em pares. Durante o
jogo, cada aluno lança os dados, quem recebe o maior número começa o jogo e
cada um dá uma volta. Se um jogador chega ao topo de uma escada ou na cabeça
de uma cobra, uma questão é apresentada. Se o jogador responde corretamente, a
sua pedra move-se para cima, no topo da escada e fica na cabeça da
serpente. Caso contrário, a pedra fica na parte inferior da escada ou desce para a
cauda da cobra. O primeiro jogador que chega ao quadrado 100 ganha o jogo.
25
Os resultados obtidos após esta experiência podem ser considerados
positivos levando-se em conta as respostas dos alunos concernentes a aplicação do
jogo como ferramenta de apoio para o ensino da disciplina. Mais da metade dos
estudantes (62,5%) afirmaram que seus conhecimentos em algoritmos alcançaram
um alto grau de desenvolvimento e assim podem distinguir um algoritmo recursivo e
seus elementos de maneira mais fácil.
Com relação à realização dos objetivos educacionais e da motivação que o
jogo causou, 87,5% dos estudantes consideraram que as metas foram bem
sucedidas e que nenhum dos estudantes levaram em consideração que os objetivos
educacionais não foram alcançados. Todos os alunos que participaram da
experiência responderam que eles gostariam de que esta se repetisse em outras
disciplinas pois segundo eles "é mais eficaz aprender jogando”. Algumas outras
razões é porque o jogo permiti aliar o entretenimento e a aprendizagem
simultaneamente a compreensão dos novos conceitos. O que não acontece com a
maneira tradicional quando se estuda com os livros!. (Rossiou e Papadakis, 2007).
2.2 . JOGOS PARA O ENSINO DA ENGENHARIA DE SOFTWARE
Assim como em outras disciplinas dos cursos de computação, em
Engenharia de Software também estão sendo utilizados jogos educativos com o
propósito de facilitar o processo de ensino aprendizagem. Serão apresentados
alguns jogos, como amostra, entre os que são atualmente utilizados para auxiliar o
ensino de engenharia de Software.
26
2.2.1. O JOGO SESAM(Software Engineering Simulation by Animated Models)
Tem como objetivo testar o jogador, que assume o papel de um gerente de
projetos. Ganha-se o jogo se o projeto obtiver sucesso. O jogo oportuniza:
Demonstrar e explicar como os recursos utilizados, ou a abordagem de gestão
adotada em um projeto podem influenciar seus resultados globais; examinar as
conseqüências de mudança do processo ou recursos; treinar futuros gerentes de
projeto, expondo-os à realidade sobre problemas e situações típicas nos projetos
(Monsalve, 2010). A figura 2 mostra a tela de apresentação inicial do projeto ao
usuário (gerente).
Figura 2: Tela de Apresentação do Projeto ao usuário do SESAM.( França, 2007)
27
2.2.2. O JOGO PLANEGER,
Desenvolvido para apoiar o ensino de conceitos de gerência de projetos
(Kieling et al, 2006), Objetiva a simulação de alguns processos utilizados na
gerência de projetos, notadamente os de planejamento(Gerenciamento do escopo e
gerenciamento do tempo).
A figura 3 mostra a fase do caminho critico, onde durante o jogo o jogador
preenche os nodos do caminho critico do projeto em que esteja trabalhando.
Figura 3: Planager, Fase caminho critico (KIELING et al, 2006)
28
2.2.3. O JOGO SCRUMMING,
Simula o uso de algumas práticas do Scrum como definir e monitorar Sprint,
visualizar gráfico de burndown, adcionar ou remover atividades de backlog. Scrum
é um processo ágil que permite manter o foco na entrega de maior valor de negócio,
no menor tempo possível. (Schwaber, 2004). A figura 4 apresenta a tela do módulo
de simulação: utilizado pelo usuário para simular sprints de um projeto
Figura 4: Scrumming Definição de uma Sprint (Prikladnicki e Wangenheim, 2008)
2.2.4. O JOGO X-MED v1.0,
O jogo Incentiva os alunos a aprender como desenvolver ou selecionar
objetivos de medição e planos GQM. Objetiva fazer com que o estudante assuma o
papel de um analista de medição e possa assim seguir a sequência de todas as
tarefas envolvidas de definição aplicadas a um programa de medição. ( Prikladnicki
29
e Wangenheim, 2008). A figura 5 mostra as telas de apresentação de reunião; de
alternativas de objetivos de medição e a tela de feedbeck.
Figura 5: Exemplos de telas do X-MED v1.0 (Prikladnicki e Wangenheim, 2008)
2.2.5. O JOGO SimulES
O jogo SimulEs(Figueiredo et AL, 2007 ) permite que um estudante assuma o
papel de gerente de projeto e depare com problemas que não são bem cobertos em
aulas tradicionais. O jogo tem por finalidade fazer com que os jogadores disputem
para terminar um projeto de software e o vencedor será aquele que implantar o
projeto primeiro. Através deste jogo, seus participantes, preferencialmente alunos,
aprendem importantes conceitos de computação e especialmente de engenharia de
software. Os recursos do jogo são: cartões de projeto, que é escolhido
aleatoriamente no inicio do jogo aonde está pré-definido os dados do projeto a ser
desenvolvido durante a partida, como tamanho, complexidade, quantidade de
módulos, orçamento... . Um tabuleiro(ver figura 6). Cartas e um dado. A figura 6
30
mostra o tabuleiro do SimulES com um cenário de jogo com a contratação de dois
engenheiros. As cartas de artefatos são colocadas nas células do tabuleiro, abaixo
do engenheiro que as produziram e nas linhas referentes aos seus tipos. Por
exemplo, na linha de requisitos da figura 6 estão dois artefatos feitos por Janaína e
um por Carlos.
Figura 6: Tabuleiro do jogo SimulES((Figueiredo et al, 2006 )).
Este capítulo apresentou a importância da utilização de jogos na educação,
dando ênfase aos jogos encontrados na literatura que são utilizados em cursos de
Computação. Alguns destes jogos, como o SimulES, foi utilizado como base para o
desenvolvimento da proposta deste trabalho, o AprendES.
31
CAPÍTULO 3
ENGENHARIA DE SOFTWARE
A Engenharia de Software é uma disciplina da engenharia relacionada com
todos os aspectos da produção de software, desde os estágios iniciais até sua
manutenção, depois que este entrar em operação (Sommerville, 2007). Software é a
parte programável de um sistema de informática que realiza estruturas complexas e
flexíveis que trazem funções, utilidades e valor ao sistema, sendo que associado a
isso se tem toda a documentação e os dados de configuração necessários para
fazer com que esses programas operem de forma correta (Filho, 2003).
Considerando o que é software, suas funções e finalidades, entende-se que para
que estes sejam produzidos com qualidade, é necessária a compreensão e
aplicação dos conceitos desta disciplina pelos que trabalharam em qualquer fase do
desenvolvimento de software. A seguir serão apresentados os principais conceitos
abordados neste trabalho que estão envolvidos no processo de desenvolvimento de
software.
3.1. GERÊNCIA DE PROJETO
A Gerência de Projeto está relacionada às atividades envolvidas em
assegurar que o software será entregue dentro do prazo definido no cronograma e
de acordo com os requisitos das organizações que desenvolvem e adquirem o
software. Faz-se necessária porque o desenvolvimento de software está sempre
sujeito às restrições de orçamento e de cronograma que são estabelecidos pela
organização que necessita do software (Sommerville, 2007). As principais atividades
de gerenciamento são:
32
Elaboração de proposta: descreve os objetivos do projeto e como ele será
realizado, incluindo o modelo de desenvolvimento.
Planejamento e desenvolvimento de cronograma do projeto: está
relacionado à identificação das atividades, marcos1 e produtos que serão
gerados pelo projeto, e considera o tempo necessário para cada
atividade, estimando assim o tempo total necessário para conclusão do
projeto.
Custo do projeto: é a estimativa do valor total requerido pelo projeto,
considerando gastos com pessoal, instalações físicas, hardware e
softwares específicos, entre outros.
Monitoração e revisões de projeto: atividade de acompanhar o
desenvolvimento do projeto em todas as suas fases, promovendo revisões
quando necessário.
Seleção e avaliação de pessoal: consiste em selecionar e avaliar pessoal
necessário para desenvolver o projeto, considerando as necessidades e o
orçamento previsto.
Elaboração de relatórios e apresentações: consiste em apresentar aos
clientes e a empresa as informações sobre o andamento do projeto de
forma coerente e concisa.
3.2. GERENCIAMENTO DE PESSOAL
Um dos fatores mais relevantes para falhas em projetos de software está
ligado diretamente a uma gestão inadequada de pessoal. Considerando que as 1 Um marco é o ponto final de uma atividade de processo de software
33
pessoas são o patrimônio mais importante em uma organização, importa que o
gerenciamento de pessoal seja realizado com eficiência. A gerência de pessoal
envolve:
Seleção de pessoal: decisão sobre quem indicar para um projeto,
relacionando a experiência do candidato com as necessidades do projeto
e os recursos financeiros existentes.
Motivação: é uma das principais tarefas de um gerente de pessoal com
relação a sua equipe de trabalho, considerando proporcionar suas
necessidades básicas de satisfação social, de auto-estima e de auto-
realização.
Devendo se levar em conta ainda os diferentes tipos de personalidades das
pessoas, que segundo (Bass e Dunteman, 1963 apud Sommerville, 2007) são:
Orientados a tarefas: profissionais que são motivados pelo
trabalho que fazem.
Auto-orientados: motivados pelo sucesso profissional e pelo
reconhecimento.
Orientados a interações: motivados pela presença e pela ação
dos colegas de trabalho.
Coesão: é a característica de uma equipe onde não há lugar para
individualismo e existe uma identificação clara das metas estabelecidas e
todos trabalham para atingi-la. Tem a vantagem de poder desenvolver um
padrão de qualidade para a equipe, permitir que os membros da equipe
trabalhem rigorosamente em conjunto. Sendo assim, os membros podem
34
conhecer os trabalhos uns dos outros e a chamada programação sem
egos exaltados pode existir, ou seja, os programas são considerados da
equipe e não de algum membro em particular.
Comunicação: é essencial para um trabalho em equipe eficiente. As
informações devem ser trocadas sobre o andamento do trabalho, as
decisões de projeto e as mudanças nas decisões prévias. Boas
comunicações também fortalecem a coesão da equipe, uma vez que
promovem o entendimento.
3.3. GERENCIAMENTO DE RISCOS
Risco é a possibilidade de que alguma adversidade ocorra durante o
desenvolvimento de um projeto. A análise dos riscos constitui-se em uma das
atividades essenciais para o bom andamento de um projeto de software (Mazolla,
2009). Toma como base a realização das quatro tarefas seguintes:
A identificação dos riscos: objetiva que sejam levantados, pelo gerente e
pelos profissionais envolvidos no projeto, todos os eventuais riscos aos
quais este será submetido, podendo-se detectar nesta fase:
Riscos de projeto, os quais estão associados a problemas
relacionados ao próprio processo de desenvolvimento, tais como,
orçamento, cronograma e pessoal.
Riscos técnicos, que consistem dos problemas de projeto
efetivamente, tais como, implementação, manutenção, interfaces e
plataformas de implementação.
35
Riscos de produto, os quais estão mais relacionados aos problemas
que vão surgir para a inserção do software como produto no
mercado, tais como, oferecimento de um produto que ninguém está
interessado, oferecer um produto ultrapassado e produto
inadequado à venda.
Projeção dos riscos: projetar ou estimar possíveis riscos possibilitando
assim que se permita definir se há a probabilidade de que o risco ocorra
durante o projeto e quais as conseqüências dos problemas associados ao
risco no caso de ocorrência do mesmo.
Avaliação dos riscos: o objetivo é processar as informações sobre o fator
de risco, o impacto do risco e a probabilidade de ocorrência. Nesta
avaliação, serão checadas as informações obtidas na projeção de riscos,
buscando priorizá-los e definir formas de controle destes ou de evitar a
ocorrência daqueles com alta probabilidade de ocorrência.
Administração e monitoração dos riscos: uma vez avaliados os riscos de
desenvolvimento, é importante que medidas sejam tomadas evitando
assim a ocorrência dos riscos ou que haja a definição de ações para a
eventualidade da ocorrência dos riscos, utilizando para isto as
informações obtidas da avaliação de riscos, com relação à descrição,
probabilidade de ocorrência e impacto sobre o processo, associadas a
cada fator de risco.
36
3.4. GERENCIAMENTO DE QUALIDADE
Software de qualidade é aquele que atende as necessidades do cliente. A
falta de qualidade mais fácil de definir é a falta de satisfação do cliente (Gustafson,
2003). O gerenciamento de qualidade em processos de desenvolvimento de
software é complexo devido às particularidades envolvidas na produção de software,
como por exemplo, a dificuldade em se estabelecer uma especificação perfeita para
um software. Segundo Sommerville (2007), a atividade de gerenciamento de
qualidade está assim dividida:
Garantia de qualidade: estabelece procedimentos e padrões
organizacionais para qualidade.
Planejamento de qualidade: seleciona procedimentos e padrões aplicáveis
para um projeto específico e o modifica quando necessário.
Controle de qualidade: assegura que os procedimentos padrões sejam
seguidos pela equipe de desenvolvimento de software.
Convém ressaltar que o gerenciamento de qualidade deve ser separado do
gerenciamento de projeto para assegurar independência.
3.5. VERIFICAÇÃO E VALIDAÇÃO A verificação e validação do software é uma etapa importante, pois responde
às seguintes questões: o software que está sendo construído obedece as suas
especificações? Atende ao que o cliente deseja?
37
O processo de verificação e validação é um processo de ciclo de vida
completo que deve ser aplicado a cada estágio do processo de
software(Sommerville, 2007). Tem dois objetivos principais:
Descobrir defeitos em um sistema;
Avaliar se o sistema é útil e usável ou não em uma situação operacional.
Há duas abordagens complementares, dentro do processo de Verificação e
Validação, para verificação e análise de sistema. A primeira é a de testes, composta
por:
Teste de validação: um teste bem sucedido é aquele que mostra que um
requisito foi adequadamente implementado.
Teste de defeitos: um teste de defeitos bem sucedido é aquele que revela
a presença de defeitos em um sistema;
A segunda é a inspeção de software que envolve pessoas que examinam
uma representação original com o objetivo de descobrir anomalias e defeitos,
podendo ser aplicadas em qualquer representação do sistema, tais como requisitos,
projeto, dados de configuração, dados de teste, etc. A inspeção têm se mostrado
uma técnica efetiva para descobrir erros de programa.
3.6. REQUISITOS DE SOFTWARE
Requisitos de um sistema são as descrições dos serviços fornecidos pelo
sistema e suas restrições operacionais (Sommerville, 2007). Os requisitos de
sistema definem detalhadamente as funções, os serviços e as restrições
operacionais do sistema e são classificados em:
38
Requisitos funcionais: são as declarações de serviços que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas e como o
sistema deve se comportar em determinadas situações.
Requisitos não-funcionais: são as restrições sobre serviços ou funções
oferecidas pelo sistema tais como restrições de timing, restrições sobre o
processo de desenvolvimento, padrões, etc.
Requisitos de domínio: são os requisitos que vêm do domínio de
aplicação do sistema e que refletem as características desse domínio.
3.7. MODELOS DE PROCESSO DE SOFTWARE
Um processo de software engloba todas as atividades que resultam na
produção de um produto de software. Um modelo de processo de software é uma
representação abstrata desse processo. As seções seguintes apresentam alguns
modelos:
3.1.1. MODELO CASCATA
É dividido em fases distintas que são realizadas uma após a outra na seguinte
ordem:
Análise e definição de requisitos.
Projeto de sistema e software.
Implementação e teste de unidade.
Integração e teste de sistema.
Operação e manutenção.
39
A principal desvantagem do modelo cascata é a dificuldade de acomodação
das mudanças depois que o processo está em andamento. Uma fase tem de estar
completa antes de passar para a próxima. A Figura 7 apresenta o modelo cascata
com as suas fases.
Figura 7 : Fases do modelo cascata (Sommerville 2007)
3.1.2. DESENVOLVIMENTO EVOLUCIONÁRIO
Baseado na idéia de desenvolvimento de uma implementação inicial
(protótipo), expondo o resultado ao usuário e obtendo-se respostas para aperfeiçoar
esta versão até que se atinja o desenvolvimento de um sistema adequado. Neste
modelo, as atividades de especificação, desenvolvimento e validação são
intercaladas. É uma abordagem que na maioria das vezes é mais eficaz do que a
abordagem em cascata, quando se quer atender as necessidades imediatas do
cliente. Esta abordagem, segundo Sommerville (2007), é a melhor para sistemas de
pequeno e médio porte (até 500 mil linhas). A figura 8 apresenta o desenvolvimento
evolucionário.
40
Figura 8: Desenvolvimento evolucionário (Sommerville 2007)
3.1.3. ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES
Baseado em reuso sistemático onde sistemas são integrados a partir de
componentes existentes ou de sistemas COTS (Commercial-of-the-shelf). Os
estágios em um processo orientado a reuso são:
Análise dos componentes;
Modificação de requisitos;
Projeto de sistema de reuso;
Desenvolvimento e integração.
Esta abordagem tem a vantagem de diminuir o número de software que
precisa ser desenvolvido, o que diminui os custos e os riscos, aliado a uma entrega
mais rápida do sistema ao cliente. A figura 9 apresenta o modelo baseado em
componentes
41
Figura 9: Engenharia de software baseado em componentes (Sommerville 2007)
3.1.4. MODELO ITERATIVO
Requisitos de sistema sempre evoluem no curso de um projeto e, sendo
assim, a iteração de processo, onde estágios iniciais são retrabalhados, é sempre
parte do processo dos sistemas de grande porte. A iteração pode ser aplicada a
qualquer um dos modelos de processo. As seções seguintes apresentam duas
abordagens que são relacionadas:
3.1.4.1. ENTREGA INCREMENTAL
Combina as vantagens do modelo Cascata com as do modelo Evolucionário.
A idéia principal deste modelo é a de que um sistema deve ser desenvolvido de
forma incremental, sendo que cada incremento vai adicionando ao sistema novas
capacidades funcionais, até a obtenção do sistema final, sendo que, a cada passo
realizado, modificações podem ser introduzidas.
Uma vantagem desta abordagem é a facilidade em testar o sistema, uma vez
que a realização de testes em cada nível de desenvolvimento é, sem dúvida, mais
fácil do que testar o sistema final. A desvantagem é que os incrementos devem ser
relativamente pequenos (até 20 mil linhas de código), e também que cada um destes
incrementos deve entregar alguma funcionalidade do sistema. A Figura apresenta 10
o modelo de entrega incremental.
42
Figura 10: Entrega incremental (Sommerville 2007)
Uma variante dessa abordagem incremental é denominada de Extreme
Programming. É talvez o mais conhecido e mais amplamente usado dos métodos
ágeis. A extreme programming (XP) leva uma abordagem ‘extrema’ para
desenvolvimento iterativo: novas versões podem ser compiladas várias vezes por
dia; os incrementos são entregues para os clientes a cada duas semanas; todos os
testes devem ser realizados para cada nova versão e a nova compilação somente é
aceita se todos os testes forem realizados com sucesso. A figura 11 apresenta o
ciclo de release em XP.
Figura 11: Ciclo de release em XP (Sommerville 2007).
3.1.4.2. DESENVOLVIMENTO ESPIRAL
O processo é representado como uma espiral ao invés de uma seqüência de
atividades com realimentação. Cada ciclo na espiral está dividido em quatro setores:
43
Identificação dos objetivos e as diferentes alternativas para se atingir
aqueles objetivos assim como as restrições impostas.
Avaliação das diferentes alternativas com base nos objetivos fixados, o
que vai permitir também definir incertezas e riscos de cada alternativa.
Desenvolvimento de estratégias permitindo resolver ou eliminar as
incertezas levantadas anteriormente, o que pode envolver atividades de
prototipação, simulação, avaliação de desempenho, etc...
Desenvolvimento do software e o planejamento dos próximos passos são
realizados.
Uma das características principais do modelo espiral que o diferencia dos
outros modelos de desenvolvimento é o reconhecimento explicito do risco, ou seja,
daquilo que pode dar errado, o que torna o modelo adequado principalmente a
sistemas que representem um alto risco de investimento para o cliente. A figura 12,
apresenta o modelo espiral.
44
Protótipo 1
Conceito deOperação
Plano de RequisitosPlano de Ciclo
de Vida
Revisão
Análisede Riscos
Análisede Riscos
Análisede Riscos
Protó-tipo 2
Protó-tipo 3
Protó-tipo
Simulações, modelos, ...
Requisitosde Software
RequisitosValidação dosDesenvolvimento
Plano de
Integração e TestesPlano de
ficação do Pro-Validação e Veri-
jeto
Projetodo pro-
duto desoftware
Opera-cional
ProjetoDetalha-do
CódigoTeste
deuni-dadeInte-
graçãoe testeTeste
de acei-tação
Imple-menta-ção
Próximas etapasdo plano
Avalia alternativas,identifica e resolve
riscos
Desenvolve e verificaProduto do Próximo
Nível
Determina objetivosalternativas e restrições
Análisede Riscos
CUSTO ACUMULADO
AVANÇO
Figura 12: O modelo espiral (Mazzola, 2003).
Este capítulo apresentou conceitos importantes da Engenharia de Software,
incluindo os modelos de desenvolvimento de software, como forma de contextualizar
o leitor para que o mesmo compreenda as regras e os componentes definidos para o
AprendES que estão descritos no Capítulo 4.
45
CAPITULO 4
O JOGO AprendES
O AprendES é um jogo de cartas não eletrônico, na categoria dos jogos
cooperativos, onde todos os jogadores trabalham em equipe para vencer o
tabuleiro. O AprendES baseia-se na idéia do jogo SimulES (Figueiredo et al, 2006) e
SimulES Versão 2.0 (Napolitano et al, 2007), ambos jogos de cartas não eletrônicos
na categoria dos jogos competitivos, onde os jogadores disputam entre si para ver
quem vencerá o jogo. O AprendES apresenta em relação ao SimulES a diferença
quanto a categoria, é um jogo cooperativo, e outras, relacionadas aos componentes
do jogo, como:
Cartas problemas e cartas conceitos: Adaptadas para o jogo
cooperativo.
Cartas complexidade, qualidade, tamanho, nível de experiencia e
status. (Criadas para montagem do projeto)
Tabuleiro: Apresenta novas características e funcionalidades (Ver
detalhamento na seção 4.2)..
Montagem do Projeto
Linha do Tempo
Módulos
Nível de Experiencia
Status
Módulo do Jogador
46
O objetivo do AprendES é levar os participantes a concluírem um projeto de
software desde a sua concepção, até sua conclusão, o que permitirá aos mesmos
apreender conceitos importantes da Engenharia de Software. A equipe vencerá o
jogo se conseguir concluir o projeto não extrapolando o orçamento disponível, assim
como o tempo, que é medido por números de rodadas. Também é necessário que
na validação não haja nenhum artefato2, com defeito nos módulos validados, de
acordo com a qualidade exigida, ou ainda que não tenham sofrido nenhuma
penalidade, através de alguma carta problema, que a equipe não consiga resolver,
impedindo assim a continuidade do jogo.
Para melhor compreensão do funcionamento do jogo, a seção 4.1 apresenta
os componentes definidos para o AprendES.
4.1. COMPONENTES DO JOGO O jogo é composto por um tabuleiro, onde são organizados os componentes de
acordo com as regras estabelecidas. A seguir serão apresentados estes
componentes, assim como descrita as funções dos mesmos.
4.1.1. CARTAS PROBLEMAS
As cartas problemas apresentam o código da carta, pode conter a referência
na literatura onde se encontra a descrição do problema, a condição para que a carta
seja ativada e os problemas a serem resolvidos com as penalidades associadas a
estes problemas. Na descrição da condição de ativação da carta e das penalidades
encontram-se alguns termos e siglas com o seguinte significado:
NE – Nível de Experiência,
EG – Engenheiro Geral, 2 Artefatos são os produtos (documentos, modelos, códigos...) criados pelos engenheiros de software.
47
ES – Engenheiro de Software,
TAMANHO – Refere-se ao tamanho do projeto.
A Figura 13 apresenta a carta doença com um problema de recurso humano,
código RH11, a condição para sua ativação é para qualquer engenheiro de software
o que quer dizer que o jogador que tirou a carta do maço de cartas problemas
escolherá entre os demais engenheiros, ou ele mesmo, quem sofrerá a penalidade,
que é perda do direito a realizar qualquer tarefa nas duas rodadas seguintes.. A
Figura 14 apresenta o exemplo de cartas com mais um atributo chamado de grau de
dificuldade, como pode ser observado pelo ícone ao lado do código da carta sendo
que o problema apresentado nesta carta pode ser resolvido pelo Engenheiro Geral
ao fim da rodada que a carta aparece. É uma carta de problema de código CD11 e
sua condição para ativação consiste em que ela só terá efeito nos módulos que
tenham a quantidade de artefatos de requisitos menor igual a um e de código maior
igual a quatro. Esta quantidade artefatos pode já ter sido construída ou não.
Figura 13. Carta problema - doença
48
Figura 14. Carta problema - grau de dificuldade 10
4.1.2. CARTAS CONCEITOS
As cartas conceitos apresentam o código da carta, pode conter a referência
na literatura onde se encontra a descrição do problema, a descrição de como a carta
pode ser utilizada, podem ter um custo associado a elas que varia de acordo com a
complexidade do projeto. Na descrição da utilização da carta encontram-se os
mesmos termos e siglas definidos para as cartas problemas.
A Figura 15 apresenta a carta ferramenta case, carta coringa com o código
CCOR2 que anula qualquer carta problema. A figura 16 apresenta a carta convenio
carta conceito de recursos humanos com o código CRH1 que tem um custo
associado de 5% sobre o valor total do orçamento se a complexidade do projeto for
1 e de 10% se a complexidade for 2.
49
Figura 15. Carta ferramentas case.
Figura 16. Carta convênio com custo.
4.1.3. BOTÕES
Os botões representam os artefatos que devem ser construídos. A Figura 17
apresenta os diferentes botões utilizados no jogo: botões verdes, que correspondem
aos artefatos de alta qualidade, definidos na proporção de 4 sem defeito, para 1 com
defeito; botões rosas, que correspondem aos artefatos de baixa qualidade, definidos
na proporção de 1 sem defeito para 1 com defeito. Os botões marrons são para na
montagem do tabuleiro no inicio do jogo marcar nos módulos nos conjuntos de
50
artefatos a quantidade de artefatos a serem construídos pelos Engenheiros de
Software.
Figura 17. Botões
4.1.4. CARTAS QUALIDADE
As cartas qualidade possuem valores que variam de 1 à 4 e servem para
determinar a qualidade do sistema, sendo este número a quantidade de módulos
que serão validados ao final do jogo. A Figura 18 apresenta a carta qualidade com
valor 1.
Figura 18. Carta qualidade
4.1.5. CARTAS TAMANHO
As cartas tamanho possuem valores que variam de 3 a 4, que correspondem
o tamanho de módulos a ser completados durante a partida. A Figura 19 apresenta a
carta tamanho com valor 3.
51
Figura 19. Carta tamanho
4.1.6. CARTAS COMPLEXIDADE
As cartas complexidade possuem valores que variam de 1 a 2 e contribuem
para definir o orçamento do projeto. Definem o número de ações dos jogadores por
rodada (1 tem direito a duas ações e 2 a três ações). A Figura 20 apresenta a carta
complexidade com valor 1.
Figura 20. Carta complexidade
4.1.7. MOEDAS
As moedas possuem valores que variam de 5 UM$ a 1000 UM$(unidades
monetárias) e são utilizadas para pagar o orçamento do projeto, que é calculado
multiplicando o número de artefatos necessários para o projeto pela soma do valor a
52
ser pago aos engenheiros envolvidos no projeto, o resultado é depois multiplicado
por um fator pré-estabelecido de 2,0, se a complexidade do sistema for 1, ou por 3,0
se a complexidade do sistema for 2. Embora no jogo este calculo seja fictício
procurou-se assemelhar o calculo as técnicas de estimativa(Sommerville, 2007),
onde se considera o esforço total para a execução do projeto, que envolve a
complexidade, que quanto maior mais custo acarretará ao orçamento pois
demandará mais tempo para sua conclusão, o total gasto com pessoal e o tamanho
do software. A Figura 21 apresenta o conjunto de moedas utilizadas no jogo.
Figura 21. Moedas
4.1.8. MÓDULOS
Os módulos contêm os tipos de artefatos que compõem o sistema: requisitos,
desenho, código, rastro e ajuda. Nos testes feitos durante o desenvolvimento do
jogo observou-se que um número grande de módulos poderia acarretar em um
tempo muito longo para a execução de uma partida, o que tornaria o jogo monótono,
podendo ocasionar por esta razão a falta de interesses nos alunos. Estabeleceu-
se assim uma quantidade mínima de módulos, que varia de dois a quatro, que é
definida no inicio da partida pelas cartas tamanho. A Figura 22 apresenta os
módulos com seus respectivos conjuntos de artefatos.
53
Figura 22. Módulos apresentando os conjuntos de artefatos.
4.1.9. CARTAS STATUS
As cartas status definem os níveis de produtividade dos engenheiros, de
acordo com o sucesso na construção dos artefatos necessários em cada módulo,
baseado em sua especialidade. A Figura 23 apresenta a carta status com valor 2.
Figura 23. Carta status do engenheiro de software
4.1.10. CARTAS NÍVEL DE EXPERIÊNCIA
As cartas nível de experiência representam o somatório das habilidades e
maturidade de um engenheiro de software. A Figura 24 apresenta a carta NE com
valor 3.
O2
54
Figura 24. Carta nível de experiência de engenheiro de software
4.1.11. MÓDULO DO JOGADOR
Corresponde à mesa de trabalho de cada engenheiro de software, onde são
colados os componentes relacionados ao mesmo. A Figura 25 apresenta o módulo
de um jogador.
Figura 25. Módulo dos jogadores (Engenheiro de Software)
4.1.12. CARTA ENGENHEIRO GERAL
Esta carta representa o engenheiro geral do projeto no jogo. A Figura 3.14
apresenta o engenheiro geral no tabuleiro com a escala para preenchimento com
seu nível de experiência. O engenheiro geral é o chefe da equipe e nas situações
em que surja um problema grave que venha a causar um grande impacto na partida,
como o apresentado na figura 26, o jogador pode aguardar e ao final da rodada
solicitar ao engenheiro geral a solução para o problema.
55
Figura 26. Engenheiro Geral
4.1.13. CARTAS CONJUNTO DE ARTEFATOS
As cartas conjunto de artefatos são utilizadas no inicio da partida na
montagem do tabuleiro, elas servem para definir o número de artefatos que serão
necessários para compor cada conjunto de artefatos nos módulos. A figura 27
apresenta as cartas conjuntos de artefatos.
Figura 27. Conjuntos de artefatos
4.2. REGRAS DO JOGO
Inicialmente, organiza-se o tabuleiro (Figura 28) distribuindo todos os
componentes descritos na seção 3.1. Participam do jogo quatro jogadores, que são
os engenheiros de software.
56
Figura 28. Tabuleiro do Jogo AprendES
O tabuleiro é organizado de acordo com a seguinte ordem:
1. Defini-se aleatoriamente entre os jogadores, qual especialidade cada
um assumirá se engenheiro de software de requisitos, de desenho, de
código ou de rastro.
2. Determinar o tamanho do projeto. O tamanho do projeto é definido
puxando-se uma carta no maço de cartas tamanho. Esta carta
determina em quantos módulos será composto o projeto. Caso o
número escolhido seja três, então o tamanho do projeto é três, ou
seja, três módulos devem ser preenchidos de acordo com o passo
seguinte. Os módulos restantes no tabuleiro que não serão utilizados
são cobertos.
3. Definir a quantidade de artefatos. Para determinar o número de
artefatos a ser construído em cada módulo, o engenheiro puxa no
maço de cartas conjunto de artefatos correspondente a sua
especialidade, tantas cartas quanto sejam o número de módulos
57
escolhidos no passo anterior. Por exemplo, se o número de módulos
determinado foi dois, e o engenheiro de software de requisitos está
montando seu conjunto de artefatos, ele puxa duas cartas no maço de
cartas conjunto de artefatos de requisitos, de acordo com a quantidade
que aparecer na primeira carta ele preenche o primeiro módulo com os
botões marrons e assim sucessivamente nos módulos restantes. Os
demais engenheiros farão o mesmo com suas cartas correspondentes
sendo que o conjunto de artefatos de ajuda será preenchido pelo
engenheiro de rastros.
4. Calcular o tempo. O tempo é igual à soma de todos os artefatos
necessários para concluir o projeto. Se, por exemplo, a soma de todos
os artefatos a serem construídos for 26, então se marca na linha
tempo com o pino vermelho o número 26.
5. Definir a qualidade do projeto. A qualidade do projeto é definida
considerando-se o tamanho do projeto. O maço de cartas qualidade é
adequado ao tamanho do projeto, ou seja, se o tamanho definido for
três, então se retira a carta de número quatro do maço e embaralha as
demais. Posteriormente, escolhe-se uma carta, o valor que sair define
a qualidade exigida do projeto.
6. Definir a complexidade do projeto. A complexidade é definida puxando
no maço de cartas complexidade uma carta que varia de um a dois,
preenchendo o espaço correspondente no tabuleiro com este valor.
7. Definir o nível de experiência de cada engenheiro de software. O nível
de experiência dos engenheiros de software é definido com cada um
puxando no maço de cartas nível de experiência correspondente a sua
58
especialidade e colocando a carta escolhida no local apropriado em
sua mesa de trabalho.
8. Definir o nível de experiência do engenheiro geral. O nível de
experiência atribuído ao engenheiro geral do projeto será um nível
acima ao maior nível dado aos engenheiros de software. E este será
marcado no local apropriado do tabuleiro.
9. Calcular orçamento total do projeto. O orçamento é calculado
considerando a complexidade do projeto. Por exemplo: um projeto em
que seja preciso construir 23 artefatos, e que tenha complexidade 1, o
orçamento é de UM$ 2760 unidades monetárias. A tabela 2 apresenta
os valores do orçamento de acordo com a quantidade de artefatos e a
complexidade do projeto.
Tabela 2. Orçamento do projeto
10. Depois de calculado o orçamento do projeto, deduz-se do valor o que
será pago aos engenheiros, tanto ao engenheiro geral como aos
59
engenheiros de software. Os valores fictícios a serem pagos aos
engenheiros serão considerados de acordo com o nível de experiência
de cada um, multiplicado pelo tamanho do projeto, que é igual ao
tempo ou números de rodadas que os jogadores disporão para
concluir o projeto. A Tabela 3.2 apresenta os custos de cada
engenheiro. Se considerarmos o orçamento de UM$ 2760, como
mostrado no exemplo acima, teremos então que o tempo é igual a 23.
Agora, consideremos a titulo de facilitar o exemplo, que todos os
engenheiros tenham nível de experiência igual a cinco, então de
acordo com a tabela teremos:
Engenheiro Geral, igual a UM$ 460.
Engenheiros de software igual a UM$ 230 cada, que totaliza UM$ 1150.
Resulta em:
UM$ 2760 UM$ 1610 – ___________
UM$ 1150 Um mil cento e cinquenta unidades monetárias é o valor restante disponível
para ser gasto até o final da partida.
60
Tabela 3. Custos dos engenheiros
11. Marcar status. Todos os engenheiros de software marcam com a carta
devida seu status em sua mesa de trabalho. Se houver algum módulo
onde o conjunto de artefato respectivo à especialidade do engenheiro
não apresente nenhum artefato a ser construído, então ele inicia com
status 1, senão ele inicia com status zero. A cada conjunto de artefato
que ele consiga completar, construindo todos os artefatos necessários
neste conjunto, seu status é acrescido em mais um ponto, até igualar
ao valor correspondente do tamanho do projeto. O status alcançado
não muda mesmo que qualquer conjunto de artefatos sofra alguma
penalidade e perca artefatos já construídos.
12. Dispor cartas problemas e conceitos no tabuleiro, cada maço no seu
lugar respectivo.
Depois de executados os passos acima descritos, têm-se início às rodadas do
jogo. Em cada rodada, os jogadores executam as suas tarefas:
61
Comprar carta problema: consiste em retirar a carta no maço de cartas
correspondente;
Comprar carta conceito: consiste em retirar a carta no maço de cartas
correspondente.
Realizar ações: O número de ações permitidas em cada rodada é
determinado pela complexidade do projeto. Para complexidade um, é
permitida a realização para cada engenheiro de duas ações por rodada. E
para complexidade dois, são permitidas três ações para cada engenheiro
por rodada. As ações permitidas são: Construir artefatos, que consiste em
substituir os botões marrons que estão nos módulos por botões verdes ou
rosa. Escolhe-se de forma aleatória, no recipiente de botões verdes ou
rosas, e estes botões são adquiridos sem se identificar se eles
apresentam defeito ou não e são dispostos nos módulos com a face
virada para baixo. Para cada ação pode se adquirir um botão verde ou
dois rosas. Os engenheiros de software podem inicialmente construir
artefatos somente em seu conjunto de artefatos ou no conjunto de
artefatos de ajuda, estando o seu conjunto preenchido, embora não
inspecionado ou corrigido, pode auxiliar os demais engenheiros na
construção, inspeção ou correção de seus artefatos. Inspecionar
artefatos que consiste em verificar, colocando a face dos botões para
cima, se estes têm defeito ou não. O ato de inspecionar um artefato é
contado como uma ação. Corrigir artefatos consiste em trocar, quando
permitido, um artefato com defeito por um sem defeito. O ato de corrigir
um artefato é contado como uma ação.
62
Convocar reunião: A reunião consiste em apresentar o problema trazido
por alguma carta problema para ser solucionada pelo engenheiro geral.
Na primeira rodada, executam-se o número de ações permitidas apenas para
construir artefatos. Nas rodadas seguintes, podem ser executadas as seguintes
tarefas:
Retirar uma carta ‘problema’ no maço destas cartas e dependendo do
grau de dificuldade, executa a mesma ou solicita uma reunião no fim da
rodada ao engenheiro geral, ficando assim impedido de realizar quaisquer
ações nesta rodada;
As cartas problemas que podem ser levadas para reunião são aquelas
que apresentam algum grau de dificuldade, que poderá ser resolvido pelo
engenheiro geral imediatamente, lançando-se o dado e somando o valor
obtido com o nível de experiência do Engenheiro Geral. Se o total for
maior ou igual ao grau de dificuldade da carta, o problema está
solucionado, senão é necessário contratar um consultor, o que acarreta
em custo para o projeto que será calculado na seguinte base:
Suponhamos que o grau de dificuldade da carta seja 10 e que o nível de
experiência do Engenheiro Geral seja 4, lança-se o dado e obtém mais 6,
então o problema está solucionado. Mas no caso de no lançamento do
dado se obter 3, então necessita-se de mais 3 pontos, o que vai custar
10% do valor do orçamento. O custo para 1 ou 2 pontos é 5%, para 3 ou 4
10 % e 5 ou 6 15%. Estes valores são fictícios, mas foram definidos
considerando que quanto maior for a experiencia exigida do consultor
mais caro é seu serviço.
63
Retirar uma carta ‘conceito’ do conjunto destas cartas e executá-la
imediatamente ou não. No entanto, um jogador não pode acumular mais
do que duas dessas cartas na sua mesa de trabalho;
Executar a quantidade de ações permitidas, que podem ser construir,
inspecionar ou corrigir artefatos. O número de ações está ligado à
complexidade do jogo.
Uma vez que um módulo tenha sido todo completado com todos os
conjuntos de artefatos preenchidos, inspecionados e corrigidos ou não,
este pode ser integrado, e uma vez integrado não poderá ser executado
mais nenhuma ação nele.
Após terem sidos integrados todos os módulos será feita a validação do
projeto que consiste em verificar se há ao menos a quantidade de
módulos exigida pelo controle de qualidade que não apresente defeito.
Por exemplo, se a qualidade exigida para o projeto na partida que
encerrou for 2, deve haver ao menos dois módulos que não apresentem
nenhum artefato com defeito.
Os engenheiros perdem o jogo pelos seguintes motivos:
As unidades de tempo, que correspondem ao número de rodadas, foram
finalizadas e o projeto não foi concluído;
O orçamento foi extrapolado;
Ao final do jogo, ao validar os módulos a qualidade exigida para o projeto
não tenha sido satisfeita.
Considera-se ganho o jogo quando todos os artefatos definidos pelo projeto
foram construídos dentro do tempo e orçamento estipulados e na validação a
qualidade exigida para o projeto tenha sido satisfeita.
64
Este capítulo apresentou o jogo AprendES desenvolvido como proposta
deste trabalho para auxiliar o processo de ensino-aprendizagem da disciplina de
Engenharia de Software. Foram apresentados os componentes e as regras do jogo.
Para não sobrecarregar o capítulo com muitas figuras, o Apêndice A apresenta
todos os componentes do AprendES.
65
CAPITÚLO 5
CONSIDERAÇÕES FINAIS
Os jogos educativos são ferramentas úteis que podem contribuir no processo
de ensino-aprendizagem. Os resultados obtidos quando da utilização de jogos
educativos em qualquer nível de ensino comprova esta afirmação, conforme exposto
no Capitulo 2 deste trabalho.
Nos cursos da área de Computação, muitas disciplinas apresentam caráter
eminentemente teórico, o que em diversas situações dificulta a fixação do conteúdo
por não permitir a vivência do aluno com os processos envolvidos em uma empresa.
A disciplina de Engenharia de Software se enquadra neste cenário, onde existem
muitos conceitos que devem ser apreendidos durante a sua aplicação aos alunos. O
tempo necessário para que o aluno desenvolva habilidades que lhe serão exigidas
pelo mercado de trabalho muitas vezes não é contemplado dentro da carga horária
definida pelos cursos para a disciplina. Estes fatores têm relação direta com as
dificuldades encontradas pelos alunos egressos quando se deparam com a
realidade das empresas.
Considerando este cenário, este trabalho se propôs a desenvolver um jogo
educativo, não eletrônico, que tem como objetivo auxiliar o processo de ensino-
aprendizagem da disciplina de Engenharia de Software, permitindo aos alunos
aproximar os conceitos envolvidos na disciplina da realidade vivenciada pelas
empresas. O jogo AprendES simula o desenvolvimento de um projeto de software,
da sua concepção até a sua conclusão, permitindo a cooperação entre os seus
66
participantes. Alguns dos conceitos apresentados pela disciplina que foram
contemplados pelo jogo são:
Gerência de projeto, que envolve formação de equipe de pessoal,
estimativa de tamanho, tempo (cronograma do projeto) e de custos do
projeto (orçamento);
Gerenciamento de pessoal, envolvendo seleção, motivação,
comunicação, modelo de maturidade e capacitação;
Gerenciamento de riscos, onde é avaliado os riscos de projeto que podem
afetar o cronograma ou os recursos do projeto.
Gerenciamento de qualidade, que prevê a qualidade pretendida ao fim do
projeto e o que se deve fazer para alcançá-la;
Verificação e validação, principalmente no tocante a inspeção de
software, que procura por defeitos no software.
Para a o desenvolvimento do jogo foi necessário, inicialmente, um estudo dos
conceitos envolvidos na disciplina de Engenharia de Software, assim como o
entendimento do jogo SimulES. Posteriormente, foi analisado o funcionamento de
diversos jogos de tabuleiro, como Pandemic, Cuba, Ghost History, El grande e War,
com o intuito de aprender as suas regras e aplicá-las, quando possível, no jogo
AprendES. São exemplos de regras aplicadas no AprendES:
Uso de cartas para tomada de decisões de maneira mais rápida durante o
jogo, como definição da qualidade, do tamanho, da complexidade, do
nível de experiência dos engenheiros de software, e da quantidade de
artefatos em cada conjunto de artefatos;
O uso de moedas, permitindo assim uma maior aproximação da realidade
no manuseio do orçamento do projeto;
67
A utilização da linha do tempo para controlar as rodadas das partidas;
A mesa de trabalho dos engenheiros de software, componente do jogo
que permite uma melhor organização do tabuleiro durante as partidas;
Dado para determinar algumas ações durante o jogo;
Estratégias utilizadas nas cartas conceito e cartas problemas, como
determinar um grau de dificuldade a algumas cartas problemas visando
dar um maior dinamismo ao jogo.
Convém ressaltar que o jogo desenvolvido não se prende a nenhum dos
Modelos de Processo de Desenvolvimento de Software da Engenharia de Software.
No entanto, mais se aproxima do Modelo Evolucionário, pois durante o jogo não há
uma seqüência a ser seguida pelos engenheiros de software (jogadores) na
construção dos artefatos, embora no início, tendo sido montado o tabuleiro, a
primeira ação é do engenheiro de requisito na construção de alguns de seus
artefatos, estabelecendo assim os requisitos iniciais para o projeto a ser
desenvolvido. Considerou-se ainda que o modelo evolucionário é uma abordagem
mais realista, pois projetos reais raramente seguem o fluxo seqüencial e logo no
início é difícil estabelecer explicitamente, por exemplo, todos os requisitos, além do
que o jogo simula um projeto de pequeno porte e este modelo para este tipo de
projeto é o mais recomendado (Sommerville, 2007). Não se estabeleceu um modelo
especifico, ou não se possibilitou a opção para escolha de um modelo específico no
início do jogo porque não havia disponibilidade de tempo para a inserção de todos
os modelos de desenvolvimento de software dentro do jogo, o que pode ser
implementado no jogo em versões futuras.
Uma vez desenvolvido o jogo, conseguiu-se atingir a primeira etapa dos
objetivos do trabalho. No entanto, ainda seria necessário validar a proposta
68
aplicando o jogo aos alunos do curso de Ciência da Computação. Nesta etapa,
reunimos um total de oito alunos do referido curso, da Universidade do Estado do
Rio Grande do Norte (UERN), sendo que quatro deles estão no início da disciplina
(segunda semana de aula) e os outros quatros concluíram-na em semestres
anteriores (2009.2 e 2008.2). Optou-se por escolher alunos que estão iniciando a
disciplina e alunos que já a cursaram com o propósito de avaliar o jogo, entre outros
aspectos, para determinar em que momento o mesmo pode ser aplicado em turmas
de Engenharia de Software. Concluiu-se que o jogo pode ser aplicado no inicio da
disciplina, para apresentar os conceitos, durante a disciplina para auxiliar o aluno no
sentido de vivenciar o processo de desenvolvimento de um projeto, como no final
para fixar os conceitos apresentados. Chegou-se a esta conclusão com as respostas
apresentadas a seguir, analisando os resultados obtidos através dos alunos, pois,
após a aplicação do jogo os alunos receberam um questionário (ver Apêndice B) a
ser preenchido com perguntas sobre a funcionalidade do jogo. Para comprovar a
aplicação do jogo em sala de aula, seguem em anexo as fotos dos alunos com o
jogo (ver Apêndice C).
Conforme se pode observar no Gráfico 1, a maioria dos alunos conseguiram
entender as regras do jogo. Os alunos que não compreenderam, justificaram com o
fato de não terem tido acesso às regras do jogo anteriormente. No entanto, mesmo
considerando esta justificativa, o que se pôde observar é que os alunos concluíram
com êxito todas as etapas do jogo.
69
Gráfico 1: Conseguiu entender as regras do jogo?
Embora a maioria dos alunos iniciantes tenha compreendido as regras do
jogo, quando questionados sobre as dificuldades encontradas, foram unânimes em
afirmar que a principal dificuldade é a grande quantidade de regras, sendo sugerido
por eles que deveria haver uma melhora no enunciado das regras, o que
proporcionaria uma compreensão ainda maior dos conceitos inseridos no jogo. Os
alunos concluintes não encontraram dificuldades em jogar e ainda perceberam que
durante o jogo, através das regras definidas, consegue-se associá-las aos conceitos
da disciplina.
Convém observar que como se trata de um jogo educativo, onde o objetivo
não é só o entretenimento, mas também transmitir os conceitos da disciplina, é
necessário que haja um mediador, que pode ser o professor para orientar os alunos
durante o jogo, visando um melhor entendimento por parte destes dos conceitos que
se pretende transmitir. Esta afirmação pode ser justificada considerando a
observação dos alunos concluintes, que detém o conhecimento da disciplina e
tiveram uma compreensão melhor dos conceitos transmitidos pelo jogo.
O Gráfico 2 apresenta os resultados sobre a compreensão dos alunos com
relação aos conceitos de Engenharia de Software através do jogo. Convém ressaltar
que foi questionado aos alunos que concluíram a disciplina se o jogo transmite
conceitos de Engenharia de Software e aos iniciantes se entenderam conceitos
75%
25%
ALUNOS INICIANTES
SIM
NÃO
100%
0%
ALUNOS QUE CONCLUÍRAM
SIM
NÃO
70
através do jogo da referida disciplina, bem como se o jogo contribui para o processo
de ensino-aprendizagem.
Gráfico 2: Entendimento/Transmissão de conceitos.
Observa-se que a maioria dos alunos iniciantes entendeu conceitos da
disciplina no uso do jogo, bem como os que já concluíram a disciplina puderam
perceber que o jogo consegue transmitir conceitos de Engenharia de Software. Essa
observação também pode ser considerada nas respostas sobre a contribuição do
jogo no processo de ensino-aprendizagem da disciplina.
Com relação à avaliação dos alunos sobre a importância do jogo ser
cooperativo, foram unânimes na resposta, afirmando que na prática a Engenharia de
Software é exercida em regime de cooperação.
Os alunos também foram questionados sobre a aparência e a funcionalidade
da interface do jogo. As respostas foram classificadas em ruim, médio e bom. A
maioria dos alunos respondeu que a interface do jogo está boa, considerando
inclusive, segundo a opinião deles, que não há necessidade de quaisquer
alterações. Apenas um único aluno colocou que a interface deveria ser mais
intuitiva. O Gráfico 3 apresenta os resultados segundo esta classificação.
75%
25%
ALUNOS INICIANTES
SIM
NÃO
100%
0%
ALUNOS QUE CONCLUÍRAM
SIM
NÃO
71
Gráfico 3: Aparência e funcionalidade da interface.
O Gráfico 4 apresenta os resultados segundo o questionamento a respeito do
jogo ter uma maior contribuição caso fosse eletrônico. De acordo com as respostas,
observou-se que para os iniciantes, 50% preferem a versão atual (jogo de tabuleiro)
e os outros 50%, a versão eletrônica. No entanto, os alunos que concluíram a
disciplina preferem a versão atual, pois permite uma maior interatividade entre os
jogadores.
Gráfico 4: Preferência entre jogo eletrônico ou na versão atual.
O último questionamento feito aos alunos é se os mesmos julgam importante
a utilização de jogos educativos para o processo de ensino-aprendizagem. Houve
unanimidade em responder de forma afirmativa, o que comprova que independente
do nível de ensino, o uso de jogos educativos como ferramenta de auxílio nesse
processo encontra espaço para a sua utilização.
Diante dos resultados apresentados, fica evidente que o trabalho atingiu o
objetivo proposto ao desenvolver um jogo educativo para auxiliar no processo de
ensino-aprendizagem da disciplina de Engenharia de Software.
0%25%
75%
ALUNOS INICIANTES
RUIM
MÉDIO
BOM
0%0%
100%
ALUNOS QUE CONCLUÍRAM
RUIM
MÉDIO
BOM
50%50%
ALUNOS INICIANTES
ELETRONICO
VERSÃO ATUAL
0%
100%
ALUNOS QUE CONCLUÍRAM
ELETRONICO
VERSÃO ATUAL
72
Este trabalho apresenta como propostas futuras a inserção de níveis de
evolução para o jogo, assim como dos outros modelos de desenvolvimento de
software. Aproveitando a sugestão dos alunos, também podem ser inseridos
mecanismos que substituam as cartas em alguns momentos, utilizando, por
exemplo, uma roleta. Também foi sugerida uma melhora na linguagem empregada
nas cartas conceito e problemas visando uma compreensão mais rápida para sua
utilização durante as partidas.
73
BIBLIOGRAFIA Alves, V. K. C. A importância dos jogos e brincadeiras no cotidiano escolar. Monografia apresentada na Pós-Graduação “Lato Sensu” – Instituto a Vez do Mestre, Universidade Candido Mendes. Rio de Janeiro, 2006.
Bass, B M., Dunteman, G. Behaviour in groups as function of self, interaction and task orientation. J.Abnorm. Soc. Psychology,1963.
Fernandes, L. D. et al. Jogos no Computador e a Formação de Recursos Humanos na Indústria. VI Simpósio Brasileiro de Informática na Educação. Anais. Florianópolis: SBC-UFSC, 1995. Fernandes, L., Werner, C M L. Sobre o uso de Jogos Digitais para o Ensino de Engenharia de Software, Programa de Engenharia de Sistemas e Computação – COPPE, Universidade Federal do Rio de Janeiro, 2007. Figueiredo, E M L., Lobato, C A., Dias, K L., Leite, J C S P., Lucena, C J P. SimulES: Um Jogo para o Ensino de Engenharia de Software, Trabalho de Conclusão de Curso de Ciência da Computação, PUC-RJ, Rio de Janeiro, 2006. Filho, W P P., Engenharia de Software Fundamentos , Métodos e Padrões. 2ª Edição. LTC- Livros Técnicos e Científicos Editora Ltda, Rio de Janeiro, 2003.
Fontoura, M T S., Lima, R F., Santos, A S., Pereira, R M M. Aplicabilidade de Jogos Educativos com Alunos do Segundo Segmento do Ensino Fundamental do Instituto de Aplicação Fernando Rodrigues da Silveira, UERJ, Instituto de Biologia Roberto Alcântara Gomes/Departamento de Ensino de Ciências e Biologia, Artigo apresentado no VII Encontro Nacional de Pesquisa em Educação em Ciência, Florianopólis, 2000. França, B B N., Proposta de um Modelo de Simulação de Processo de Software para o Ambiente WebAPSEE. Trabalho de Conclusão de Curso de Ciência da Computação, UFPA,. Belém, 2007.
Gustafson, D. A. Teoria e Problemas de Engenharia de software, Tradução Fernanda Claúdia Alves Campos, Bookman, Porto Alegre, 2003.
Kahl, K., Lima, M. E de O., Gomes, I. Alfabetização: Construindo alternativas com jogos pedagógicos. Extensio: Revista Eletrônica de Extensão, v. 4, n. 5. Dezembro de 2007.
Kieling, E., Rosa, R. Planager - Um Jogo para Apoio ao Ensino de Conceitos de Gerência de Projetos de Software. Trabalho de Conclusão de Curso de Ciência da Computação, FACIN, PUCRS, Porto Alegre, 2006. Konrath, M L P., Falkembach, G A M., Tarouco, L M R. Utilização de jogos na sala de aula: Aprendendo através de atividades digitais, Artigo, Cinted-UFRGS, 2005.
74
Martinelli, Dante Pinheiro, A Utilização de Jogos de Empresas no Ensino da Administração, São Paulo, FEA-USP, Dissertação de Mestrado, 1987.
Mazzola , V B., Engenharia de Software e Sistemas de Informação - 3ª EDIÇÃO. BRASPORT, SÃO Paulo, 2009
Monsalve, E. S., Construindo Um Jogo Educacional com Modelagem Intencional Apoiados em princípios de Transparência. Tese de Mestrado. Puc-Rio, Rio de Janeiro, 2010.
Napolitano, F., Serrano, B., Serrano, M., Soares, B. Evolução do SimulES Versão 2.0. Trabalho de Pesquisa de Evolução de Software, Puc-Rio, Rio de Janeiro, 2007.
Navarro, E.; Baker, A.; Hoek, A. "Teaching Software Engineering Using Simulation Games". In: International Conference on Simulation in Education (ICSIE). California, 2004.
NETO, E. R. Laboratório de matemática. In: Didática da Matemática. São Paulo: Ática, 1992. 200p. p. 43-84.
Prikladnicki, R., Wangenheim, C G. Scruming - O Uso de Jogos Educacionais para o Ensino de Gerência de Projetos de Software. Trabalho de Conclusão de Curso de Ciência da Computação,Faculdade de Informática, FACIN, PUCRS, Porto Alegre, 2008. Reif, H. L., Mitri, M. How University Professors Teach Project Management for Information Systems. Communications of the ACM, Vol. 48, N. 8, Ago/2005.
Rossiou, E. Papadakis, S. Educational Games in Higher Education: a case study in teaching recursive algorithms. University of Macedonia and The Hellenic Open University, 2007. Disponível em: http://www.ece.salford.ac.uk/proceedings/papers/17_07.pdf Acesso em: junho de 2010
SAUAIA, Antonio C. A., Satisfação e Aprendizagem em Jogos de Empresas: Contribuições para a Educação Gerencial, São Paulo, FEA-USP, Tese de Doutorado, 1995
Schaeffer, E. H. O jogo matemático como experiência de diálogo: análise fenomenológica da percepção de professores de matemática. 2006. Dissertação (Mestrado) – Mestrado em Educação para a Ciência e o Ensino de Matemática, Universidade Estadual de Maringá, Maringá.
Schwaber, K. Agile Project Management with Scrum. Microsoft Press, 2004.
Soares, Paulo Marcelo. Ponte aérea nos simuladores de vôo, TAM Fokker 100. São Paulo, 1998. Disponível em: <http://www.fsa.com.br/cursos/files/ponteaerea21-highres.pdf>. Acesso em 08 de fevereiro de 2010
Sommerville, Ian. Engenharia de software, 8ª edição. Tradução: Selma Shin Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa. Revisão técnica: Kechi Kirama. São Paulo, Pearson Addison-Wesley, 2007.
75
Wikipédia Tabula Rasa. Disponivel em: <htpp://PT.wikipedia.org/wiki/tabula_rasa> Acesso em 13 de maio de 2010. Wikipédia. John Locke. Disponível em: <htpp://pt.wikipedia.org/wiki/John_Locke.> Acesso em: 17 de dezembro de 2009.
76
ANEXO
Este trabalho apresenta como anexo os questionários aplicados aos alunos do curso de Ciência da Computação para validação deste trabalho, assim como as fotos que comprovam a aplicação do jogo em sala de aula. Também são considerados anexos todos os componentes do jogo AprendES. Para não sobrecarregar o trabalho com um número elevado de páginas, este anexo foi inserido no formato digital (cd-rom). Este CD armazena um arquivo *.pdf com os diversos Apêndices (total de 3).
