Вы находитесь на странице: 1из 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

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 obteno do grau de bacharel em Cincia da Computao

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 obteno do grau de bacharel em Cincia da Computao

Aprovado em ____/____/____.

Banca Examinadora _______________________________ Msc. Glaucia Melissa Medeiros Campos UERN Campus de Natal

_______________________________ Msc. Camila de Arajo UERN Campus de Natal

_______________________________ Dr. Joo Maria Pires UERN Campus de Natal

Aos que com sabedoria utilizam seus conhecimentos a servio do bem da humanidade.

AGRADECIMENTOS

Ao meu Senhor, o Deus criador do cu e da terra. Fao minhas as palavras do Apstolo 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. Ftima, amiga e incentivadora, sempre presente, com quem vencemos grandes desafios durante esta jornada, posso dizer como o sbio Salomo Aquele que encontra uma esposa, acha o bem, e alcana a benevolncia do Senhor, obrigado pelo seu amor, carinho e compreenso. 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 vocs. Aos irmos e amigos Alcides e Aninha, e na pessoa deles, a todos os irmos, de todas as congregaes que dirigimos neste perodo como tambm aos que no estiveram sobre nosso pastorado, pelas oraes e apoio. O Senhor vos recompensar. A professora Lyrene Fernandes, por me indicar o tema. A minha orientadora professora Glaucia Campos, pela dedicao, ateno e encorajamento, alm da pacincia de sempre nos atender em nossas dvidas. A todos os professores e professoras bem como a todos os funcionrios da UERN. Aos amigos que ao longo deste caminho conquistamos aos quais devo muito, no s pelas ajudas em momentos de provas, seminrios e trabalhos, mas seno tambm pela amizade e carinho com que sempre fomos tratados, em especial a: Jorge Felliphe, Dayanne Scall, Joo Batista, Jackson Costa, Thiago Augusto, Lidiane Oliveira, Mizael Araujo, Joel Gonalves, Wellington, Claudete e Karlyle, posso dizer de vocs o que

diz o sbio em provrbios como o leo e o perfume alegram o corao, assim, o amigo encontra doura no conselho cordial. Tendson, amigo que ganhamos

nesta jornada, que abriu a sua casa e compartilhou conosco sua coleo de jogos de tabuleiro para nos auxiliar na compreenso deste universo to maravilhoso que a ludicidade. Ao Professor Jlio 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 orao que a beno de Deus vos alcance e vos faam prosperar em tudo quanto fizerem.

O que ensina dedique-se em faz-lo.


Apstolo Paulo.

RESUMO

A utilizao de jogos educativos tem se mostrado til no auxilio do processo de ensino-aprendizagem em todos os nveis de ensino, em especial nas disciplinas que apresentam em seu contedo conceitos eminentemente tericos, exigindo do aluno um alto grau de abstrao para entend-los. A Engenharia de Software, dos cursos da rea de Computao, uma dessas disciplinas. Sendo assim, este trabalho apresenta o AprendES, um jogo educativo de tabuleiro, no eletrnico, 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 realizao o desenvolvimento de um projeto de software desde seu planejamento at sua finalizao, que pode ser bem sucedido ou no, permitindo assim que possa ser vivenciada a realidade de um ambiente de desenvolvimento de software. Ao final do trabalho, so apresentados resultados da avaliao 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 teachlearning 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 Apresentao do Projeto ao usurio do SESAM.( Frana, 2007) . 26 Figura 3: Planager, Fase caminho critico (KIELING et al, 2006) ...............................27 Figura 4: Scrumming Definio 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 evolucionrio (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 - doena.......................................................................... 47 Figura 14. Carta problema - grau de dificuldade 10 .................................................. 48 Figura 15. Carta ferramentas case. ........................................................................... 49 Figura 16. Carta convnio com custo. ....................................................................... 49 Figura 17. Botes ...................................................................................................... 50 Figura 18. Carta qualidade ........................................................................................50 Figura 19. Carta tamanho..........................................................................................51 Figura 20. Carta complexidade ................................................................................. 51 Figura 21. Moedas .................................................................................................... 52 Figura 22. Mdulos apresentando os conjuntos de artefatos. ................................... 53 Figura 23. Carta status do engenheiro de software...................................................53 Figura 24. Carta nvel de experincia de engenheiro de software ............................54 Figura 25. Mdulo 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 parmetros dos mtodos educacionais: ensino tradicional x aprendizagem construtivista. Fonte: Sauaia (1995:239)......................................... 23 Tabela 2. Oramento do projeto ................................................................................ 58 Tabela 3. Custos dos engenheiros ............................................................................ 60

LISTA DE GRFICOS

Grfico 1: Conseguiu entender as regras do jogo? ...................................................69 Grfico 2: Entendimento/Transmisso de conceitos. ............................................... 70 Grfico 3: Aparncia e funcionalidade da interface. .................................................. 71 Grfico 4: Preferncia entre jogo eletrnico ou na verso atual................................71

SUMRIO
CAPTULO 1 ............................................................................................................. 15 INTRODUO .......................................................................................................... 15 CAPTULO 2 ............................................................................................................. 19 EDUCAO LDICA ...............................................................................................19 2.1. JOGOS EDUCATIVOS NO ENSINO DA COMPUTAO ...............................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 CAPTULO 3 ............................................................................................................. 31 ENGENHARIA DE SOFTWARE ............................................................................... 31 3.1. GERNCIA DE PROJETO .............................................................................. 31 3.2. GERENCIAMENTO DE PESSOAL ................................................................. 32 3.3. GERENCIAMENTO DE RISCOS .................................................................... 34 3.4. GERENCIAMENTO DE QUALIDADE..............................................................36 3.5. VERIFICAO E VALIDAO ........................................................................ 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 EVOLUCIONRIO ............................................... 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. BOTES ................................................................................................... 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. MDULOS ................................................................................................52 4.1.9. CARTAS STATUS ....................................................................................53 4.1.10. CARTAS NVEL DE EXPERINCIA .......................................................53 4.1.11. MDULO DO JOGADOR ....................................................................... 54 4.1.12. CARTA ENGENHEIRO GERAL..............................................................54 4.1.13. CARTAS CONJUNTO DE ARTEFATOS ................................................ 55 4.2. REGRAS DO JOGO ........................................................................................55 CAPITLO 5 ............................................................................................................. 65 CONSIDERAES FINAIS ......................................................................................65 BIBLIOGRAFIA ........................................................................................................ 73 ANEXO......................................................................................................................76

15

Captulo 1 INTRODUO
De acordo com Karoline Kahl (2007), a utilizao de prticas ldicas contribui para o aprendizado. Sendo assim, diversos tipos de jogos educativos, independente do nvel de ensino, vm sendo utilizados para aprimorar a comunicao entre alunos e professores (Alves, 2006). Os jogos educativos propiciam aos professores

estimular os alunos quanto aprendizagem. A sua utilizao tem demonstrado isso quando os alunos entram em contato com o objeto de estudo, facilitando assim o trabalho do professor, pois a dinmica dos jogos permite ao aluno desenvolver habilidades a partir da compreenso de suas regras, bem como apreender os conceitos do contedo alvo do jogo. Outra vantagem desta abordagem de ensino que desenvolve tambm 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 vitria ou derrota no jogo, o aluno aprende a elaborar seus relacionamentos e observar melhor a realidade social em que est inserido. Os simuladores de vo so um exemplo pratico desta realidade, pois auxiliam no processo de ensino-aprendizagem de como pilotar um avio (Soares, 1998), criando um ambiente simulado dos diversos cenrios que envolvem esta atividade. Tem se comprovado atravs da utilizao desta tcnica que o impacto de decises erradas tomadas durante os exerccios evitam prejuzos significativos caso as mesmas se dessem em um ambiente real.

16

No de hoje que os jogos educativos vm sendo utilizados em diversos cursos de graduao. Nos cursos da rea de Computao tem se comprovado que a utilizao de jogos auxilia o estudante a absorver melhor os conceitos estudados e a compreender as conseqncias das decises 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 acadmico, que disciplinas como Engenharia de Software que so estudadas de forma predominantemente terica, tem os seus resultados, com relao compreenso dos conceitos e mtodos estudados, se mostrado insuficiente para preparar adequadamente o profissional para o mercado de trabalho, se este no tiver tido previamente alguma vivencia prtica, por mais simples que seja (Reif e Mitri, 2005). Por isso a importncia da utilizao de jogos no ensino da Engenharia de Software, visando simular o ambiente de trabalho, propiciando ao aluno aprender os conceitos tericos da disciplina, assim como vivenciar, atravs da simulao, diferentes cenrios e prticas de ambientes reais de desenvolvimento de software, possibilitando, dessa forma, o exerccio nas tomadas de decises dentro do processo. A utilizao de simulaes permite ainda que o aluno se depare com uma gama maior de situaes diferentes em um menor espao de tempo. Alm da simulao, a utilizao de jogos no aprendizado possui diversas vantagens, pois permite explorar um determinado ramo de conhecimento, alm de trabalhar com algumas habilidades, como, por exemplo, destreza, associao de idias e raciocnio lgico e indutivo. No contexto da Engenharia de Software, isso

17

especialmente importante, uma vez que a motivao dos alunos tende a diminuir devido ao excesso de teoria que lhe passado. Sendo assim, este trabalho apresenta um jogo de cartas, no eletrnico, com carter 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 Computao. Em virtude da disciplina de Engenharia de Software envolver muitos conceitos e na exposio do assunto no permitir ao aluno vivenciar na prtica o que est sendo discutido em aula, o jogo propiciar, alm da apreenso desses conceitos, a possibilidade de se trabalhar com o desenvolvimento de algumas das atividades inerentes Engenharia de Software, dentre elas, a interao que deve haver entre a equipe de desenvolvedores, por isso a opo de se fazer um jogo que no seja eletrnico, mas sim um jogo que permita aos alunos trabalharem em equipe, considerando que na sua quase totalidade os jogos eletrnicos so individualizados, pois mesmo os jogos de computador multiplayer foram uma situao de cada um em seu lugar, ou no seu micro, no propiciando que haja contato real entre as pessoas. As vantagens desta colaborao podem ser observadas em Schaeffer (2006), onde o autor afirma que os jogos em grupo possibilitam aos indivduos trabalharem com a regularidade, o limite, o respeito e a disciplina, por meio de aes necessariamente subordinadas a regra. Todos esses aspectos se fazem importantes para a vida do indivduo 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 condies que muitas vezes no podemos controlar (estrutura, tempo e lugar), alm de poderem acomodar vrias pessoas ao mesmo tempo.

18

Este trabalho est organizado em cinco captulos, sendo a Introduo o primeiro deles e o restante estruturado da seguinte forma: o Captulo 2 apresenta a importncia da educao ldica, assim como mostra alguns jogos encontrados na literatura, que so utilizados nos cursos de Computao; o Captulo 3 descreve os principais conceitos da Engenharia de Software a serem utilizados no jogo; o Captulo 4 apresenta os componentes e as regras do AprendES. Por fim, o captulo 5 apresenta as consideraes finais e os trabalhos futuros.

19

Captulo 2 EDUCAO LDICA

A educao ldica est distante da concepo ingnua de passatempo, brincadeira vulgar, diverso superficial. Ela uma ao inerente na criana, no adolescente, no jovem e no adulto e aparece sempre como uma forma transacional em direo a algum conhecimento, que se redefine na elaborao constante do pensamento individual em permutaes com o pensamento coletivo. (Paulo Nunes de Almeida)

A utilizao de jogos pelo ser humano remonta a centenas de anos atrs. E, ao contrrio do que se possa imaginar, que os jogos serviam somente para diverso e entretenimento, o desenvolvimento de alguns jogos j tinham a finalidade de serem utilizados como ferramenta de ensino. Tem se notcias de jogos para treinamento e desenvolvimento de estratgias, como o GO, um jogo de tabuleiro, criado pelo imperador chins Yao (2337-2258 a.C.) para ensinar seu filho Danzhu disciplina, concentrao e equilbrio. (Fernandes & Werner, 2009)

O modelo tradicional de ensino, baseado na teoria do filsofo ingls John Locke (Wikipdia, 2009), v o aprendiz como um sujeito desprovido de qualquer conhecimento anterior sobre o objeto a ser estudado, da a denominao dada a tal aprendiz de tabula rasa, termo que deriva do latim folha em branco (Wikipdia, 2010). Ento, neste modelo, o aprendiz receptor do conhecimento do professor, onde este pode imprimir o contedo que est sendo transmitido ao aluno, a Folha em Branco. Nesta viso, o professor detentor do conhecimento e muitas vezes no estimula no aluno sua capacidade reflexiva, de anlise e vivncia 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 matria estudada apenas para o dia da prova, para se obter a nota necessria para aprovao. Este princpio ainda permeia a maneira como as polticas educacionais de muitos pases so pensadas e desenvolvidas, inclusive no Brasil (Wikipdia, 2010).

Outro modelo mais recente que se contrape ao ensino tradicional o modelo construtivista do epistemologista suo, Jean Piaget (Konrath et al, 2005). Neste modelo, o aluno visto como algum dotado de conhecimentos natos, e que estes precisam ser feitos vir a tona atravs de estmulos corretos. A discusso ento gira em torno de que se pode substituir o mtodo tradicional de ensino por mtodos inovadores, sem que haja a quebra do propsito de no s ensinar um contedo, mas tambm de prepar-lo para os desafios da vida. Dentre esses mtodos inovadores, tem-se utilizado os jogos educativos, observando-se que atravs do ldico podem ser ensinados contedos bsicos para crianas, contedos mais complexos como fsica e matemtica para alunos do ensino mdio e tambm em cursos no ensino superior, como os jogos de empresa utilizados nos cursos de administrao de empresas, conforme pode ser observado em Martinelli (1987). Os jogos educativos so uma rea que pode tornar-se alvo de inmeras pesquisas. Se o ensino for ldico e desafiador, a aprendizagem prolonga-se fora da sala de aula, fora da escola, pelo cotidiano, num crescimento muito mais rico do que algumas informaes que o aluno decora (Neto, 1992). Tenta-se assim mudar a idia, at ento vigente, que ensinar simplesmente transmitir, o que ocorreu por muito tempo. Busca-se ento material pedaggico que desperte o interesse do aluno, em virtude de que o interesse do aluno comanda o processo da

21

aprendizagem e suas experincias e descobertas o que movimenta o seu progresso. O professor assume ento o papel de gerador de situaes estimuladoras e eficazes. nesse contexto que o jogo ganha um espao como ferramenta ideal de aprendizagem, na medida em que prope estmulo 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 elaborao do raciocnio lgico e simboliza um instrumento pedaggico que leva o professor condio de condutor, estimulador e avaliador da aprendizagem. Na anlise apresentada no VII Encontro Nacional de Pesquisa em Educao em Cincia, as autoras (Fontoura et al, 2000) mostram os resultados de sua pesquisa sobre jogos educativos realizada com uma das turmas do 9 perodo, do Instituto de Aplicao Fernando Rodrigues da Silveira (CAP/UERJ). Foi feita a seguinte pergunta: Jogos educativos ajudam na compreenso de alguma matria? 88% dos alunos responderam de forma afirmativa. As autoras concluram que a contribuio positiva dos jogos educativos foi, em vista disso, reafirmada no pblicoalvo desta pesquisa, e que a diverso proporcionada pelos jogos motiva a participao dos alunos em aula e facilita a compreenso de contedos mais complexos, permitindo que os alunos consigam relembrar as atividades e os temas abordados em sala de aula. Observamos ento que a prtica, embutida nos jogos, permite ao aluno vivenciar o assunto estudado, e este vivenciar ajuda-o a apreender os conceitos. Sendo assim, a utilizao 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 caractersticas do ensino baseado na aprendizagem construtivista, tecendo uma anlise comparativa com o ensino tradicional. Segundo Sauaia (1995), no ensino tradicional, o educador desempenha o papel principal. Ele o personagem que apoiado em suas experincias, deseja ensinar a seus alunos, estabelecendo, para isso, objetivos educacionais coletivos, orientados para a classe como um todo. Mantm a aula em andamento mediante a gerao permanente de estmulos 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 apresentao expositiva e individual do instrutor. So exercitados contedos 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 unio entre os educandos e entre eles e o educador (Martinelli, 1987).

23

Tabela 1 Comparativo e parmetros dos mtodos educacionais: ensino tradicional x aprendizagem construtivista. Fonte: Sauaia (1995:239) Parmetros Educacionais Orientao didtica Personagem central Contedos trabalhados Envolvimento do educador Envolvimento do educando Atitude que orienta Tcnica usual Tipo de aprendizagem reas trabalhadas Aplicao de conceitos Objetivos educacionais Avaliados da aprendizagem Andamento da aula Ambiente criado Ensino Tradicional Aprendizagem construtivista Ensino Educador Do educador Alto Baixo Quero ensinar Expositiva Cognitiva Crebro Terica Gerais e coletivos Educador Estmulo do educador Competitivo Aprendizagem Educando Do educando Baixo Alto Quero aprender Atividade em grupo Cognitiva, afetiva, cooperativa, atitudinal e comportamental Todo o indivduo Prtica Especficos e individualizados Educando Motivos do educando Competitivo e cooperativo

Podemos ento dizer que uma vez estabelecido e obedecido o sistema de um jogo, aprender pode tornar-se to divertido quanto brincar e, nesse caso, aprender torna-se interessante para o aluno e passa a fazer parte de sua lista de preferncias. Certamente, fazer com que o aluno veja o ato de aprender como algo interessante em vez de tedioso o grande desafio nas atuais prticas educacionais. Como o objetivo do trabalho est direcionado para a utilizao de jogos no ensino da computao, as sees seguintes apresentam exemplos de jogos educativos utilizados em instituies de nvel superior para esta rea.

2.1. JOGOS EDUCATIVOS NO ENSINO DA COMPUTAO

Os cursos de nvel superior que envolvem o ensino da computao esto descobrindo as vantagens da utilizao 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 simulao para criar algoritmos recursivos, utilizado no ensino de algoritmos recursivos para alunos do primeiro semestre, da disciplina de Algoritmos em C, do Departamento de Informtica Aplicada, da Universidade da Macednia, em Salnica, Grcia.

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 lana os dados, quem recebe o maior nmero comea o jogo e cada um d uma volta. Se um jogador chega ao topo de uma escada ou na cabea de uma cobra, uma questo apresentada. Se o jogador responde corretamente, a sua pedra move-se para cima, no topo da escada e fica na cabea da serpente. Caso contrrio, 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 aps esta experincia podem ser considerados positivos levando-se em conta as respostas dos alunos concernentes a aplicao do jogo como ferramenta de apoio para o ensino da disciplina. Mais da metade dos estudantes (62,5%) afirmaram que seus conhecimentos em algoritmos alcanaram um alto grau de desenvolvimento e assim podem distinguir um algoritmo recursivo e seus elementos de maneira mais fcil. Com relao realizao dos objetivos educacionais e da motivao que o jogo causou, 87,5% dos estudantes consideraram que as metas foram bem sucedidas e que nenhum dos estudantes levaram em considerao que os objetivos educacionais no foram alcanados. Todos os alunos que participaram da

experincia responderam que eles gostariam de que esta se repetisse em outras disciplinas pois segundo eles " mais eficaz aprender jogando. Algumas outras razes porque o jogo permiti aliar o entretenimento e a aprendizagem simultaneamente a compreenso dos novos conceitos. O que no 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 computao, em Engenharia de Software tambm esto sendo utilizados jogos educativos com o propsito de facilitar o processo de ensino aprendizagem. Sero apresentados alguns jogos, como amostra, entre os que so 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 gesto adotada em um projeto podem influenciar seus resultados globais; examinar as conseqncias de mudana do processo ou recursos; treinar futuros gerentes de projeto, expondo-os realidade sobre problemas e situaes tpicas nos projetos (Monsalve, 2010). A figura 2 mostra a tela de apresentao inicial do projeto ao usurio (gerente).

Figura 2: Tela de Apresentao do Projeto ao usurio do SESAM.( Frana, 2007)

27

2.2.2. O JOGO PLANEGER,

Desenvolvido para apoiar o ensino de conceitos de gerncia de projetos (Kieling et al, 2006), Objetiva a simulao de alguns processos utilizados na gerncia 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 prticas do Scrum como definir e monitorar Sprint, visualizar grfico de burndown, adcionar ou remover atividades de backlog. Scrum um processo gil que permite manter o foco na entrega de maior valor de negcio, no menor tempo possvel. (Schwaber, 2004). A figura 4 apresenta a tela do mdulo de simulao: utilizado pelo usurio para simular sprints de um projeto

Figura 4: Scrumming Definio 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 medio e planos GQM. Objetiva fazer com que o estudante assuma o papel de um analista de medio e possa assim seguir a sequncia de todas as tarefas envolvidas de definio aplicadas a um programa de medio. ( Prikladnicki

29

e Wangenheim, 2008). A figura 5 mostra as telas de apresentao de reunio; de alternativas de objetivos de medio 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 no so 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. Atravs deste jogo, seus participantes, preferencialmente alunos, aprendem importantes conceitos de computao e especialmente de engenharia de software. Os recursos do jogo so: cartes 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 mdulos, oramento... . Um tabuleiro(ver figura 6). Cartas e um dado. A figura 6

30

mostra o tabuleiro do SimulES com um cenrio de jogo com a contratao de dois engenheiros. As cartas de artefatos so colocadas nas clulas do tabuleiro, abaixo do engenheiro que as produziram e nas linhas referentes aos seus tipos. Por exemplo, na linha de requisitos da figura 6 esto dois artefatos feitos por Janana e um por Carlos.

Figura 6: Tabuleiro do jogo SimulES((Figueiredo et al, 2006 )).

Este captulo apresentou a importncia da utilizao de jogos na educao, dando nfase aos jogos encontrados na literatura que so utilizados em cursos de Computao. Alguns destes jogos, como o SimulES, foi utilizado como base para o desenvolvimento da proposta deste trabalho, o AprendES.

31

CAPTULO 3 ENGENHARIA DE SOFTWARE


A Engenharia de Software uma disciplina da engenharia relacionada com todos os aspectos da produo de software, desde os estgios iniciais at sua manuteno, depois que este entrar em operao (Sommerville, 2007). Software a parte programvel de um sistema de informtica que realiza estruturas complexas e flexveis que trazem funes, utilidades e valor ao sistema, sendo que associado a isso se tem toda a documentao e os dados de configurao necessrios para fazer com que esses programas operem de forma correta (Filho, 2003). Considerando o que software, suas funes e finalidades, entende-se que para que estes sejam produzidos com qualidade, necessria a compreenso e aplicao dos conceitos desta disciplina pelos que trabalharam em qualquer fase do desenvolvimento de software. A seguir sero apresentados os principais conceitos abordados neste trabalho que esto envolvidos no processo de desenvolvimento de software. 3.1. GERNCIA DE PROJETO A Gerncia 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 organizaes que desenvolvem e adquirem o software. Faz-se necessria porque o desenvolvimento de software est sempre sujeito s restries de oramento e de cronograma que so estabelecidos pela organizao que necessita do software (Sommerville, 2007). As principais atividades de gerenciamento so:

32

Elaborao 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 identificao das atividades, marcos1 e produtos que sero gerados pelo projeto, e considera o tempo necessrio para cada

atividade, estimando assim o tempo total necessrio para concluso do projeto. Custo do projeto: a estimativa do valor total requerido pelo projeto, considerando gastos com pessoal, instalaes fsicas, hardware e softwares especficos, entre outros. Monitorao e revises de projeto: atividade de acompanhar o desenvolvimento do projeto em todas as suas fases, promovendo revises quando necessrio. Seleo e avaliao de pessoal: consiste em selecionar e avaliar pessoal necessrio para desenvolver o projeto, considerando as necessidades e o oramento previsto. Elaborao de relatrios e apresentaes: consiste em apresentar aos clientes e a empresa as informaes 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 gesto inadequada de pessoal. Considerando que as
1

Um marco o ponto final de uma atividade de processo de software

33

pessoas so o patrimnio mais importante em uma organizao, importa que o gerenciamento de pessoal seja realizado com eficincia. A gerncia de pessoal envolve: Seleo de pessoal: deciso sobre quem indicar para um projeto, relacionando a experincia do candidato com as necessidades do projeto e os recursos financeiros existentes. Motivao: uma das principais tarefas de um gerente de pessoal com relao a sua equipe de trabalho, considerando proporcionar suas necessidades bsicas de satisfao social, de auto-estima e de autorealizao. Devendo se levar em conta ainda os diferentes tipos de personalidades das pessoas, que segundo (Bass e Dunteman, 1963 apud Sommerville, 2007) so: Orientados a tarefas: profissionais que so motivados pelo

trabalho que fazem. Auto-orientados: motivados pelo sucesso profissional e pelo

reconhecimento. Orientados a interaes: motivados pela presena e pela ao

dos colegas de trabalho. Coeso: a caracterstica de uma equipe onde no h lugar para individualismo e existe uma identificao clara das metas estabelecidas e todos trabalham para atingi-la. Tem a vantagem de poder desenvolver um padro 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 programao sem egos exaltados pode existir, ou seja, os programas so considerados da equipe e no de algum membro em particular. Comunicao: essencial para um trabalho em equipe eficiente. As informaes devem ser trocadas sobre o andamento do trabalho, as decises de projeto e as mudanas nas decises prvias. Boas comunicaes tambm fortalecem a coeso 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 anlise dos riscos constitui-se em uma das atividades essenciais para o bom andamento de um projeto de software (Mazolla, 2009). Toma como base a realizao das quatro tarefas seguintes: A identificao 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 esto associados a problemas relacionados ao prprio processo de desenvolvimento, tais como, oramento, cronograma e pessoal. Riscos tcnicos, que consistem dos problemas de projeto

efetivamente, tais como, implementao, manuteno, interfaces e plataformas de implementao.

35

Riscos de produto, os quais esto mais relacionados aos problemas que vo surgir para a insero do software como produto no mercado, tais como, oferecimento de um produto que ningum est interessado, oferecer um produto ultrapassado e produto

inadequado venda. Projeo dos riscos: projetar ou estimar possveis riscos possibilitando assim que se permita definir se h a probabilidade de que o risco ocorra durante o projeto e quais as conseqncias dos problemas associados ao risco no caso de ocorrncia do mesmo. Avaliao dos riscos: o objetivo processar as informaes sobre o fator de risco, o impacto do risco e a probabilidade de ocorrncia. Nesta avaliao, sero checadas as informaes obtidas na projeo de riscos, buscando prioriz-los e definir formas de controle destes ou de evitar a ocorrncia daqueles com alta probabilidade de ocorrncia. Administrao e monitorao dos riscos: uma vez avaliados os riscos de desenvolvimento, importante que medidas sejam tomadas evitando assim a ocorrncia dos riscos ou que haja a definio de aes para a eventualidade da ocorrncia dos riscos, utilizando para isto as informaes obtidas da avaliao de riscos, com relao descrio, probabilidade de ocorrncia 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 fcil de definir a falta de satisfao do cliente (Gustafson, 2003). O gerenciamento de qualidade em processos de desenvolvimento de software complexo devido s particularidades envolvidas na produo de software, como por exemplo, a dificuldade em se estabelecer uma especificao perfeita para um software. Segundo Sommerville (2007), a atividade de gerenciamento de qualidade est assim dividida: Garantia de qualidade: estabelece procedimentos e padres

organizacionais para qualidade. Planejamento de qualidade: seleciona procedimentos e padres aplicveis para um projeto especfico e o modifica quando necessrio. Controle de qualidade: assegura que os procedimentos padres sejam seguidos pela equipe de desenvolvimento de software. Convm ressaltar que o gerenciamento de qualidade deve ser separado do gerenciamento de projeto para assegurar independncia.

3.5. VERIFICAO E VALIDAO A verificao e validao do software uma etapa importante, pois responde s seguintes questes: o software que est sendo construdo obedece as suas especificaes? Atende ao que o cliente deseja?

37

O processo de verificao e validao um processo de ciclo de vida completo que deve ser aplicado a cada estgio do processo de

software(Sommerville, 2007). Tem dois objetivos principais: Descobrir defeitos em um sistema; Avaliar se o sistema til e usvel ou no em uma situao operacional.

H duas abordagens complementares, dentro do processo de Verificao e Validao, para verificao e anlise de sistema. A primeira a de testes, composta por: Teste de validao: 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 presena de defeitos em um sistema; A segunda a inspeo de software que envolve pessoas que examinam uma representao original com o objetivo de descobrir anomalias e defeitos, podendo ser aplicadas em qualquer representao do sistema, tais como requisitos, projeto, dados de configurao, dados de teste, etc. A inspeo tm se mostrado uma tcnica efetiva para descobrir erros de programa. 3.6. REQUISITOS DE SOFTWARE Requisitos de um sistema so as descries dos servios fornecidos pelo sistema e suas restries operacionais (Sommerville, 2007). Os requisitos de sistema definem detalhadamente as funes, os servios e as restries operacionais do sistema e so classificados em:

38

Requisitos funcionais: so as declaraes de servios que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como o sistema deve se comportar em determinadas situaes.

Requisitos no-funcionais: so as restries sobre servios ou funes oferecidas pelo sistema tais como restries de timing, restries sobre o processo de desenvolvimento, padres, etc.

Requisitos de domnio: so os requisitos que vm do domnio de aplicao do sistema e que refletem as caractersticas desse domnio.

3.7. MODELOS DE PROCESSO DE SOFTWARE Um processo de software engloba todas as atividades que resultam na produo de um produto de software. Um modelo de processo de software uma representao abstrata desse processo. As sees seguintes apresentam alguns modelos: 3.1.1. MODELO CASCATA dividido em fases distintas que so realizadas uma aps a outra na seguinte ordem: Anlise e definio de requisitos. Projeto de sistema e software. Implementao e teste de unidade. Integrao e teste de sistema. Operao e manuteno.

39

A principal desvantagem do modelo cascata a dificuldade de acomodao das mudanas depois que o processo est em andamento. Uma fase tem de estar completa antes de passar para a prxima. A Figura 7 apresenta o modelo cascata com as suas fases.

Figura 7 : Fases do modelo cascata (Sommerville 2007)

3.1.2. DESENVOLVIMENTO EVOLUCIONRIO Baseado na idia de desenvolvimento de uma implementao inicial (prottipo), expondo o resultado ao usurio e obtendo-se respostas para aperfeioar esta verso at que se atinja o desenvolvimento de um sistema adequado. Neste modelo, as atividades de especificao, desenvolvimento e validao so 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 mdio porte (at 500 mil linhas). A figura 8 apresenta o desenvolvimento evolucionrio.

40

Figura 8: Desenvolvimento evolucionrio (Sommerville 2007)

3.1.3. ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES

Baseado em reuso sistemtico onde sistemas so integrados a partir de componentes existentes ou de sistemas COTS (Commercial-of-the-shelf). Os estgios em um processo orientado a reuso so: Anlise dos componentes; Modificao de requisitos; Projeto de sistema de reuso; Desenvolvimento e integrao.

Esta abordagem tem a vantagem de diminuir o nmero de software que precisa ser desenvolvido, o que diminui os custos e os riscos, aliado a uma entrega mais rpida 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 iterao de processo, onde estgios iniciais so retrabalhados, sempre parte do processo dos sistemas de grande porte. A iterao pode ser aplicada a qualquer um dos modelos de processo. As sees seguintes apresentam duas abordagens que so relacionadas: 3.1.4.1. ENTREGA INCREMENTAL Combina as vantagens do modelo Cascata com as do modelo Evolucionrio. A idia 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 obteno do sistema final, sendo que, a cada passo realizado, modificaes podem ser introduzidas. Uma vantagem desta abordagem a facilidade em testar o sistema, uma vez que a realizao de testes em cada nvel de desenvolvimento , sem dvida, mais fcil do que testar o sistema final. A desvantagem que os incrementos devem ser relativamente pequenos (at 20 mil linhas de cdigo), e tambm 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 mtodos geis. A extreme programming (XP) leva uma abordagem extrema para desenvolvimento iterativo: novas verses podem ser compiladas vrias vezes por dia; os incrementos so entregues para os clientes a cada duas semanas; todos os testes devem ser realizados para cada nova verso e a nova compilao 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 invs de uma seqncia de atividades com realimentao. Cada ciclo na espiral est dividido em quatro setores:

43

Identificao dos objetivos e as diferentes alternativas para se atingir aqueles objetivos assim como as restries impostas.

Avaliao das diferentes alternativas com base nos objetivos fixados, o que vai permitir tambm definir incertezas e riscos de cada alternativa.

Desenvolvimento de estratgias permitindo resolver ou eliminar as incertezas levantadas anteriormente, o que pode envolver atividades de prototipao, simulao, avaliao de desempenho, etc...

Desenvolvimento do software e o planejamento dos prximos passos so realizados.

Uma das caractersticas 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

CUSTO ACUMULADO

AVANO Determina objetivos alternativas e restries Anlise de Riscos Anlise de Riscos

Avalia alternativas, identifica e resolve riscos

Reviso

Prximas etapas do plano

Anlise de Riscos ProtProt- tipo Anlise de Riscos Prot- tipo 3 Operacional tipo 2 Prottipo 1 Plano de Requisitos Simulaes, modelos, ... Plano de Ciclo Conceito de de Vida Operao Requisitos de Software Projeto Projeto do pro- DetalhaPlano de duto de do Desenvolvimento Validao dos software Requisitos Cdigo Plano de Teste Integrao e Testes Validao e Veride ficao do Prounijeto Inte- dade Desenvolve e verifica grao Teste Produto do Prximo Imple- de acei- e teste Nvel menta- tao o

Figura 12: O modelo espiral (Mazzola, 2003).

Este captulo 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 esto descritos no Captulo 4.

45

CAPITULO 4 O JOGO AprendES


O AprendES um jogo de cartas no eletrnico, na categoria dos jogos cooperativos, onde todos os jogadores trabalham em equipe para vencer o

tabuleiro. O AprendES baseia-se na idia do jogo SimulES (Figueiredo et al, 2006) e SimulES Verso 2.0 (Napolitano et al, 2007), ambos jogos de cartas no eletrnicos na categoria dos jogos competitivos, onde os jogadores disputam entre si para ver quem vencer o jogo. O AprendES apresenta em relao ao SimulES a diferena 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, nvel de experiencia e status. (Criadas para montagem do projeto) Tabuleiro: Apresenta novas caractersticas e funcionalidades (Ver detalhamento na seo 4.2).. Montagem do Projeto Linha do Tempo Mdulos Nvel de Experiencia Status Mdulo do Jogador

46

O objetivo do AprendES levar os participantes a conclurem um projeto de software desde a sua concepo, at sua concluso, o que permitir aos mesmos apreender conceitos importantes da Engenharia de Software. A equipe vencer o jogo se conseguir concluir o projeto no extrapolando o oramento disponvel, assim como o tempo, que medido por nmeros de rodadas. Tambm necessrio que na validao no haja nenhum artefato2, com defeito nos mdulos validados, de acordo com a qualidade exigida, ou ainda que no tenham sofrido nenhuma penalidade, atravs de alguma carta problema, que a equipe no consiga resolver, impedindo assim a continuidade do jogo. Para melhor compreenso do funcionamento do jogo, a seo 4.1 apresenta os componentes definidos para o AprendES. 4.1. COMPONENTES DO JOGO O jogo composto por um tabuleiro, onde so organizados os componentes de acordo com as regras estabelecidas. A seguir sero apresentados estes componentes, assim como descrita as funes dos mesmos. 4.1.1. CARTAS PROBLEMAS As cartas problemas apresentam o cdigo da carta, pode conter a referncia na literatura onde se encontra a descrio do problema, a condio para que a carta seja ativada e os problemas a serem resolvidos com as penalidades associadas a estes problemas. Na descrio da condio de ativao da carta e das penalidades encontram-se alguns termos e siglas com o seguinte significado:
2

NE Nvel de Experincia, EG Engenheiro Geral,

Artefatos so os produtos (documentos, modelos, cdigos...) criados pelos engenheiros de software.

47

ES Engenheiro de Software, TAMANHO Refere-se ao tamanho do projeto.

A Figura 13 apresenta a carta doena com um problema de recurso humano, cdigo RH11, a condio para sua ativao para qualquer engenheiro de software o que quer dizer que o jogador que tirou a carta do mao 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 cdigo 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 cdigo CD11 e sua condio para ativao consiste em que ela s ter efeito nos mdulos que tenham a quantidade de artefatos de requisitos menor igual a um e de cdigo maior igual a quatro. Esta quantidade artefatos pode j ter sido construda ou no.

Figura 13. Carta problema - doena

48

Figura 14. Carta problema - grau de dificuldade 10

4.1.2. CARTAS CONCEITOS

As cartas conceitos apresentam o cdigo da carta, pode conter a referncia na literatura onde se encontra a descrio do problema, a descrio de como a carta pode ser utilizada, podem ter um custo associado a elas que varia de acordo com a complexidade do projeto. Na descrio da utilizao 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 cdigo CCOR2 que anula qualquer carta problema. A figura 16 apresenta a carta convenio carta conceito de recursos humanos com o cdigo CRH1 que tem um custo associado de 5% sobre o valor total do oramento se a complexidade do projeto for 1 e de 10% se a complexidade for 2.

49

Figura 15. Carta ferramentas case.

Figura 16. Carta convnio com custo.

4.1.3. BOTES

Os botes representam os artefatos que devem ser construdos. A Figura 17 apresenta os diferentes botes utilizados no jogo: botes verdes, que correspondem aos artefatos de alta qualidade, definidos na proporo de 4 sem defeito, para 1 com defeito; botes rosas, que correspondem aos artefatos de baixa qualidade, definidos na proporo de 1 sem defeito para 1 com defeito. Os botes marrons so para na montagem do tabuleiro no inicio do jogo marcar nos mdulos nos conjuntos de

50

artefatos a quantidade de artefatos a serem construdos pelos Engenheiros de Software.

Figura 17. Botes

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 nmero a quantidade de mdulos que sero 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 mdulos 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 oramento do projeto. Definem o nmero de aes dos jogadores por rodada (1 tem direito a duas aes e 2 a trs aes). 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 monetrias) e so utilizadas para pagar o oramento do projeto, que calculado multiplicando o nmero de artefatos necessrios 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 fictcio procurou-se assemelhar o calculo as tcnicas de estimativa(Sommerville, 2007), onde se considera o esforo total para a execuo do projeto, que envolve a complexidade, que quanto maior mais custo acarretar ao oramento pois

demandar mais tempo para sua concluso, 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. MDULOS

Os mdulos contm os tipos de artefatos que compem o sistema: requisitos, desenho, cdigo, rastro e ajuda. Nos testes feitos durante o desenvolvimento do jogo observou-se que um nmero grande de mdulos poderia acarretar em um tempo muito longo para a execuo de uma partida, o que tornaria o jogo montono, podendo ocasionar por esta razo a falta de interesses nos alunos. Estabeleceu-

se assim uma quantidade mnima de mdulos, que varia de dois a quatro, que definida no inicio da partida pelas cartas tamanho. A Figura 22 apresenta os mdulos com seus respectivos conjuntos de artefatos.

53

Figura 22. Mdulos apresentando os conjuntos de artefatos.

4.1.9. CARTAS STATUS

As cartas status definem os nveis de produtividade dos engenheiros, de acordo com o sucesso na construo dos artefatos necessrios em cada mdulo, baseado em sua especialidade. A Figura 23 apresenta a carta status com valor 2.

O2

Figura 23. Carta status do engenheiro de software

4.1.10. CARTAS NVEL DE EXPERINCIA

As cartas nvel de experincia representam o somatrio das habilidades e maturidade de um engenheiro de software. A Figura 24 apresenta a carta NE com valor 3.

54

Figura 24. Carta nvel de experincia de engenheiro de software

4.1.11. MDULO DO JOGADOR

Corresponde mesa de trabalho de cada engenheiro de software, onde so colados os componentes relacionados ao mesmo. A Figura 25 apresenta o mdulo de um jogador.

Figura 25. Mdulo 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 nvel de experincia. O engenheiro geral o chefe da equipe e nas situaes 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 soluo para o problema.

55

Figura 26. Engenheiro Geral

4.1.13. CARTAS CONJUNTO DE ARTEFATOS As cartas conjunto de artefatos so utilizadas no inicio da partida na montagem do tabuleiro, elas servem para definir o nmero de artefatos que sero necessrios para compor cada conjunto de artefatos nos mdulos. 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 seo 3.1. Participam do jogo quatro jogadores, que so 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 cdigo ou de rastro. 2. Determinar o tamanho do projeto. O tamanho do projeto definido puxando-se uma carta no mao de cartas tamanho. Esta carta determina em quantos mdulos ser composto o projeto. Caso o nmero escolhido seja trs, ento o tamanho do projeto trs, ou seja, trs mdulos devem ser preenchidos de acordo com o passo seguinte. Os mdulos restantes no tabuleiro que no sero utilizados so cobertos. 3. Definir a quantidade de artefatos. Para determinar o nmero de artefatos a ser construdo em cada mdulo, o engenheiro puxa no mao de cartas conjunto de artefatos correspondente a sua especialidade, tantas cartas quanto sejam o nmero de mdulos

57

escolhidos no passo anterior. Por exemplo, se o nmero de mdulos determinado foi dois, e o engenheiro de software de requisitos est montando seu conjunto de artefatos, ele puxa duas cartas no mao de cartas conjunto de artefatos de requisitos, de acordo com a quantidade que aparecer na primeira carta ele preenche o primeiro mdulo com os botes marrons e assim sucessivamente nos mdulos restantes. Os demais engenheiros faro 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 necessrios para concluir o projeto. Se, por exemplo, a soma de todos os artefatos a serem construdos for 26, ento se marca na linha tempo com o pino vermelho o nmero 26. 5. Definir a qualidade do projeto. A qualidade do projeto definida considerando-se o tamanho do projeto. O mao de cartas qualidade adequado ao tamanho do projeto, ou seja, se o tamanho definido for trs, ento se retira a carta de nmero quatro do mao 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 mao de cartas complexidade uma carta que varia de um a dois, preenchendo o espao correspondente no tabuleiro com este valor. 7. Definir o nvel de experincia de cada engenheiro de software. O nvel de experincia dos engenheiros de software definido com cada um puxando no mao de cartas nvel de experincia correspondente a sua

58

especialidade e colocando a carta escolhida no local apropriado em sua mesa de trabalho. 8. Definir o nvel de experincia do engenheiro geral. O nvel de experincia atribudo ao engenheiro geral do projeto ser um nvel acima ao maior nvel dado aos engenheiros de software. E este ser marcado no local apropriado do tabuleiro. 9. Calcular oramento total do projeto. O oramento calculado considerando a complexidade do projeto. Por exemplo: um projeto em que seja preciso construir 23 artefatos, e que tenha complexidade 1, o oramento de UM$ 2760 unidades monetrias. A tabela 2 apresenta os valores do oramento de acordo com a quantidade de artefatos e a complexidade do projeto.
Tabela 2. Oramento do projeto

10. Depois de calculado o oramento do projeto, deduz-se do valor o que ser pago aos engenheiros, tanto ao engenheiro geral como aos

59

engenheiros de software. Os valores fictcios a serem pagos aos engenheiros sero considerados de acordo com o nvel de experincia de cada um, multiplicado pelo tamanho do projeto, que igual ao tempo ou nmeros de rodadas que os jogadores disporo para concluir o projeto. A Tabela 3.2 apresenta os custos de cada engenheiro. Se considerarmos o oramento de UM$ 2760, como mostrado no exemplo acima, teremos ento que o tempo igual a 23. Agora, consideremos a titulo de facilitar o exemplo, que todos os engenheiros tenham nvel de experincia igual a cinco, ento 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 monetrias o valor restante disponvel 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 mdulo onde o conjunto de artefato respectivo especialidade do engenheiro no apresente nenhum artefato a ser construdo, ento ele inicia com status 1, seno ele inicia com status zero. A cada conjunto de artefato que ele consiga completar, construindo todos os artefatos necessrios neste conjunto, seu status acrescido em mais um ponto, at igualar ao valor correspondente do tamanho do projeto. O status alcanado no muda mesmo que qualquer conjunto de artefatos sofra alguma penalidade e perca artefatos j construdos. 12. Dispor cartas problemas e conceitos no tabuleiro, cada mao no seu lugar respectivo. Depois de executados os passos acima descritos, tm-se incio s rodadas do jogo. Em cada rodada, os jogadores executam as suas tarefas:

61

Comprar carta problema: consiste em retirar a carta no mao de cartas correspondente;

Comprar carta conceito: consiste em retirar a carta no mao de cartas correspondente.

Realizar aes: O nmero de aes permitidas em cada rodada determinado pela complexidade do projeto. Para complexidade um, permitida a realizao para cada engenheiro de duas aes por rodada. E para complexidade dois, so permitidas trs aes para cada engenheiro por rodada. As aes permitidas so: Construir artefatos, que consiste em substituir os botes marrons que esto nos mdulos por botes verdes ou rosa. Escolhe-se de forma aleatria, no recipiente de botes verdes ou rosas, e estes botes so adquiridos sem se identificar se eles apresentam defeito ou no e so dispostos nos mdulos com a face virada para baixo. Para cada ao pode se adquirir um boto 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 no inspecionado ou corrigido, pode auxiliar os demais engenheiros na construo, inspeo ou correo de seus artefatos. Inspecionar

artefatos que consiste em verificar, colocando a face dos botes para cima, se estes tm defeito ou no. O ato de inspecionar um artefato contado como uma ao. Corrigir artefatos consiste em trocar, quando permitido, um artefato com defeito por um sem defeito. O ato de corrigir um artefato contado como uma ao.

62

Convocar reunio: A reunio consiste em apresentar o problema trazido por alguma carta problema para ser solucionada pelo engenheiro geral.

Na primeira rodada, executam-se o nmero de aes permitidas apenas para construir artefatos. Nas rodadas seguintes, podem ser executadas as seguintes tarefas: Retirar uma carta problema no mao destas cartas e dependendo do grau de dificuldade, executa a mesma ou solicita uma reunio no fim da rodada ao engenheiro geral, ficando assim impedido de realizar quaisquer aes nesta rodada; As cartas problemas que podem ser levadas para reunio so aquelas que apresentam algum grau de dificuldade, que poder ser resolvido pelo engenheiro geral imediatamente, lanando-se o dado e somando o valor obtido com o nvel de experincia do Engenheiro Geral. Se o total for maior ou igual ao grau de dificuldade da carta, o problema est solucionado, seno necessrio 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 nvel de experincia do Engenheiro Geral seja 4, lana-se o dado e obtm mais 6, ento o problema est solucionado. Mas no caso de no lanamento do dado se obter 3, ento necessita-se de mais 3 pontos, o que vai custar 10% do valor do oramento. O custo para 1 ou 2 pontos 5%, para 3 ou 4 10 % e 5 ou 6 15%. Estes valores so fictcios, mas foram definidos considerando que quanto maior for a experiencia exigida do consultor mais caro seu servio.

63

Retirar uma carta conceito do conjunto destas cartas e execut-la imediatamente ou no. No entanto, um jogador no pode acumular mais do que duas dessas cartas na sua mesa de trabalho;

Executar a quantidade de aes permitidas, que podem ser construir, inspecionar ou corrigir artefatos. O nmero de aes est ligado complexidade do jogo.

Uma vez que um mdulo tenha sido todo completado com todos os conjuntos de artefatos preenchidos, inspecionados e corrigidos ou no, este pode ser integrado, e uma vez integrado no poder ser executado mais nenhuma ao nele.

Aps terem sidos integrados todos os mdulos ser feita a validao do projeto que consiste em verificar se h ao menos a quantidade de mdulos exigida pelo controle de qualidade que no apresente defeito. Por exemplo, se a qualidade exigida para o projeto na partida que encerrou for 2, deve haver ao menos dois mdulos que no apresentem nenhum artefato com defeito.

Os engenheiros perdem o jogo pelos seguintes motivos: As unidades de tempo, que correspondem ao nmero de rodadas, foram finalizadas e o projeto no foi concludo; O oramento foi extrapolado; Ao final do jogo, ao validar os mdulos a qualidade exigida para o projeto no tenha sido satisfeita. Considera-se ganho o jogo quando todos os artefatos definidos pelo projeto foram construdos dentro do tempo e oramento estipulados e na validao a qualidade exigida para o projeto tenha sido satisfeita.

64

Este captulo 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 no sobrecarregar o captulo com muitas figuras, o Apndice A apresenta todos os componentes do AprendES.

65

CAPITLO 5 CONSIDERAES FINAIS


Os jogos educativos so ferramentas teis que podem contribuir no processo de ensino-aprendizagem. Os resultados obtidos quando da utilizao de jogos educativos em qualquer nvel de ensino comprova esta afirmao, conforme exposto no Capitulo 2 deste trabalho. Nos cursos da rea de Computao, muitas disciplinas apresentam carter eminentemente terico, o que em diversas situaes dificulta a fixao do contedo por no permitir a vivncia do aluno com os processos envolvidos em uma empresa. A disciplina de Engenharia de Software se enquadra neste cenrio, onde existem muitos conceitos que devem ser apreendidos durante a sua aplicao aos alunos. O tempo necessrio para que o aluno desenvolva habilidades que lhe sero exigidas pelo mercado de trabalho muitas vezes no contemplado dentro da carga horria definida pelos cursos para a disciplina. Estes fatores tm relao direta com as dificuldades encontradas pelos alunos egressos quando se deparam com a realidade das empresas. Considerando este cenrio, este trabalho se props a desenvolver um jogo educativo, no eletrnico, que tem como objetivo auxiliar o processo de ensinoaprendizagem 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 concepo at a sua concluso, permitindo a cooperao entre os seus

66

participantes. Alguns dos conceitos apresentados pela disciplina que foram contemplados pelo jogo so: Gerncia de projeto, que envolve formao de equipe de pessoal, estimativa de tamanho, tempo (cronograma do projeto) e de custos do projeto (oramento); Gerenciamento de pessoal, envolvendo seleo, motivao,

comunicao, modelo de maturidade e capacitao; 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; Verificao e validao, principalmente no tocante a inspeo de software, que procura por defeitos no software. Para a o desenvolvimento do jogo foi necessrio, 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 possvel, no jogo AprendES. So exemplos de regras aplicadas no AprendES: Uso de cartas para tomada de decises de maneira mais rpida durante o jogo, como definio da qualidade, do tamanho, da complexidade, do nvel de experincia dos engenheiros de software, e da quantidade de artefatos em cada conjunto de artefatos; O uso de moedas, permitindo assim uma maior aproximao da realidade no manuseio do oramento do projeto;

67

A utilizao 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 organizao do tabuleiro durante as partidas;

Dado para determinar algumas aes durante o jogo; Estratgias utilizadas nas cartas conceito e cartas problemas, como determinar um grau de dificuldade a algumas cartas problemas visando dar um maior dinamismo ao jogo.

Convm ressaltar que o jogo desenvolvido no se prende a nenhum dos Modelos de Processo de Desenvolvimento de Software da Engenharia de Software. No entanto, mais se aproxima do Modelo Evolucionrio, pois durante o jogo no h uma seqncia a ser seguida pelos engenheiros de software (jogadores) na construo dos artefatos, embora no incio, tendo sido montado o tabuleiro, a primeira ao do engenheiro de requisito na construo de alguns de seus artefatos, estabelecendo assim os requisitos iniciais para o projeto a ser desenvolvido. Considerou-se ainda que o modelo evolucionrio uma abordagem mais realista, pois projetos reais raramente seguem o fluxo seqencial e logo no incio difcil estabelecer explicitamente, por exemplo, todos os requisitos, alm do que o jogo simula um projeto de pequeno porte e este modelo para este tipo de projeto o mais recomendado (Sommerville, 2007). No se estabeleceu um modelo especifico, ou no se possibilitou a opo para escolha de um modelo especfico no incio do jogo porque no havia disponibilidade de tempo para a insero de todos os modelos de desenvolvimento de software dentro do jogo, o que pode ser implementado no jogo em verses futuras. Uma vez desenvolvido o jogo, conseguiu-se atingir a primeira etapa dos objetivos do trabalho. No entanto, ainda seria necessrio validar a proposta

68

aplicando o jogo aos alunos do curso de Cincia da Computao. 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 esto no incio da disciplina (segunda semana de aula) e os outros quatros concluram-na em semestres anteriores (2009.2 e 2008.2). Optou-se por escolher alunos que esto iniciando a disciplina e alunos que j a cursaram com o propsito 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 concluso com as respostas apresentadas a seguir, analisando os resultados obtidos atravs dos alunos, pois, aps a aplicao do jogo os alunos receberam um questionrio (ver Apndice B) a ser preenchido com perguntas sobre a funcionalidade do jogo. Para comprovar a aplicao do jogo em sala de aula, seguem em anexo as fotos dos alunos com o jogo (ver Apndice C). Conforme se pode observar no Grfico 1, a maioria dos alunos conseguiram entender as regras do jogo. Os alunos que no compreenderam, justificaram com o fato de no terem tido acesso s regras do jogo anteriormente. No entanto, mesmo considerando esta justificativa, o que se pde observar que os alunos concluram com xito todas as etapas do jogo.

69

Grfico 1: Conseguiu entender as regras do jogo?

ALUNOS INICIANTES
25% SIM NO 75%

ALUNOS QUE CONCLURAM


0% SIM NO 100%

Embora a maioria dos alunos iniciantes tenha compreendido as regras do jogo, quando questionados sobre as dificuldades encontradas, foram unnimes 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 compreenso ainda maior dos conceitos inseridos no jogo. Os alunos concluintes no encontraram dificuldades em jogar e ainda perceberam que durante o jogo, atravs das regras definidas, consegue-se associ-las aos conceitos da disciplina. Convm observar que como se trata de um jogo educativo, onde o objetivo no s o entretenimento, mas tambm transmitir os conceitos da disciplina, necessrio 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 afirmao pode ser justificada considerando a observao dos alunos concluintes, que detm o conhecimento da disciplina e tiveram uma compreenso melhor dos conceitos transmitidos pelo jogo. O Grfico 2 apresenta os resultados sobre a compreenso dos alunos com relao aos conceitos de Engenharia de Software atravs do jogo. Convm ressaltar que foi questionado aos alunos que concluram a disciplina se o jogo transmite conceitos de Engenharia de Software e aos iniciantes se entenderam conceitos

70

atravs do jogo da referida disciplina, bem como se o jogo contribui para o processo de ensino-aprendizagem.
Grfico 2: Entendimento/Transmisso de conceitos.

ALUNOS INICIANTES
25% SIM NO 75%

ALUNOS QUE CONCLURAM


0% SIM NO 100%

Observa-se que a maioria dos alunos iniciantes entendeu conceitos da disciplina no uso do jogo, bem como os que j concluram a disciplina puderam perceber que o jogo consegue transmitir conceitos de Engenharia de Software. Essa observao tambm pode ser considerada nas respostas sobre a contribuio do jogo no processo de ensino-aprendizagem da disciplina. Com relao avaliao dos alunos sobre a importncia do jogo ser cooperativo, foram unnimes na resposta, afirmando que na prtica a Engenharia de Software exercida em regime de cooperao. Os alunos tambm foram questionados sobre a aparncia e a funcionalidade da interface do jogo. As respostas foram classificadas em ruim, mdio e bom. A maioria dos alunos respondeu que a interface do jogo est boa, considerando inclusive, segundo a opinio deles, que no h necessidade de quaisquer alteraes. Apenas um nico aluno colocou que a interface deveria ser mais

intuitiva. O Grfico 3 apresenta os resultados segundo esta classificao.

71

Grfico 3: Aparncia e funcionalidade da interface.

ALUNOS INICIANTES
0% 25% RUIM MDIO 75% BOM

ALUNOS QUE CONCLURAM


0% RUIM MDIO 100% BOM

O Grfico 4 apresenta os resultados segundo o questionamento a respeito do jogo ter uma maior contribuio caso fosse eletrnico. De acordo com as respostas, observou-se que para os iniciantes, 50% preferem a verso atual (jogo de tabuleiro) e os outros 50%, a verso eletrnica. No entanto, os alunos que concluram a disciplina preferem a verso atual, pois permite uma maior interatividade entre os jogadores.
Grfico 4: Preferncia entre jogo eletrnico ou na verso atual.

ALUNOS INICIANTES
ELETRONICO 50% 50% VERSO ATUAL

ALUNOS QUE CONCLURAM


0% ELETRONICO 100% VERSO ATUAL

O ltimo questionamento feito aos alunos se os mesmos julgam importante a utilizao de jogos educativos para o processo de ensino-aprendizagem. Houve unanimidade em responder de forma afirmativa, o que comprova que independente do nvel de ensino, o uso de jogos educativos como ferramenta de auxlio nesse processo encontra espao para a sua utilizao. 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.

72

Este trabalho apresenta como propostas futuras a insero de nveis de evoluo para o jogo, assim como dos outros modelos de desenvolvimento de software. Aproveitando a sugesto dos alunos, tambm podem ser inseridos mecanismos que substituam as cartas em alguns momentos, utilizando, por exemplo, uma roleta. Tambm foi sugerida uma melhora na linguagem empregada nas cartas conceito e problemas visando uma compreenso mais rpida para sua utilizao durante as partidas.

73

BIBLIOGRAFIA
Alves, V. K. C. A importncia dos jogos e brincadeiras no cotidiano escolar. Monografia apresentada na Ps-Graduao 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 Formao de Recursos Humanos na Indstria. VI Simpsio Brasileiro de Informtica na Educao. Anais. Florianpolis: 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 Computao 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 Concluso de Curso de Cincia da Computao, PUC-RJ, Rio de Janeiro, 2006. Filho, W P P., Engenharia de Software Fundamentos , Mtodos e Padres. 2 Edio. LTC- Livros Tcnicos e Cientficos 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 Aplicao Fernando Rodrigues da Silveira, UERJ, Instituto de Biologia Roberto Alcntara Gomes/Departamento de Ensino de Cincias e Biologia, Artigo apresentado no VII Encontro Nacional de Pesquisa em Educao em Cincia, Florianoplis, 2000. Frana, B B N., Proposta de um Modelo de Simulao de Processo de Software para o Ambiente WebAPSEE. Trabalho de Concluso de Curso de Cincia da Computao, UFPA,. Belm, 2007. Gustafson, D. A. Teoria e Problemas de Engenharia de software, Traduo Fernanda Cladia Alves Campos, Bookman, Porto Alegre, 2003. Kahl, K., Lima, M. E de O., Gomes, I. Alfabetizao: Construindo alternativas com jogos pedaggicos. Extensio: Revista Eletrnica de Extenso, v. 4, n. 5. Dezembro de 2007. Kieling, E., Rosa, R. Planager - Um Jogo para Apoio ao Ensino de Conceitos de Gerncia de Projetos de Software. Trabalho de Concluso de Curso de Cincia da Computao, FACIN, PUCRS, Porto Alegre, 2006. Konrath, M L P., Falkembach, G A M., Tarouco, L M R. Utilizao de jogos na sala de aula: Aprendendo atravs de atividades digitais, Artigo, Cinted-UFRGS, 2005.

74

Martinelli, Dante Pinheiro, A Utilizao de Jogos de Empresas no Ensino da Administrao, So Paulo, FEA-USP, Dissertao de Mestrado, 1987. Mazzola , V B., Engenharia de Software e Sistemas de Informao - 3 EDIO. BRASPORT, SO Paulo, 2009 Monsalve, E. S., Construindo Um Jogo Educacional com Modelagem Intencional Apoiados em princpios de Transparncia. Tese de Mestrado. Puc-Rio, Rio de Janeiro, 2010. Napolitano, F., Serrano, B., Serrano, M., Soares, B. Evoluo do SimulES Verso 2.0. Trabalho de Pesquisa de Evoluo 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. Laboratrio de matemtica. In: Didtica da Matemtica. So Paulo: tica, 1992. 200p. p. 43-84. Prikladnicki, R., Wangenheim, C G. Scruming - O Uso de Jogos Educacionais para o Ensino de Gerncia de Projetos de Software. Trabalho de Concluso de Curso de Cincia da Computao,Faculdade de Informtica, 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. Disponvel em: http://www.ece.salford.ac.uk/proceedings/papers/17_07.pdf Acesso em: junho de 2010 SAUAIA, Antonio C. A., Satisfao e Aprendizagem em Jogos de Empresas: Contribuies para a Educao Gerencial, So Paulo, FEA-USP, Tese de Doutorado, 1995 Schaeffer, E. H. O jogo matemtico como experincia de dilogo: anlise fenomenolgica da percepo de professores de matemtica. 2006. Dissertao (Mestrado) Mestrado em Educao para a Cincia e o Ensino de Matemtica, Universidade Estadual de Maring, Maring. Schwaber, K. Agile Project Management with Scrum. Microsoft Press, 2004. Soares, Paulo Marcelo. Ponte area nos simuladores de vo, TAM Fokker 100. So Paulo, 1998. Disponvel em: <http://www.fsa.com.br/cursos/files/ponteaerea21highres.pdf>. Acesso em 08 de fevereiro de 2010 Sommerville, Ian. Engenharia de software, 8 edio. Traduo: Selma Shin Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa. Reviso tcnica: Kechi Kirama. So Paulo, Pearson Addison-Wesley, 2007.

75

Wikipdia Tabula Rasa. Disponivel em: <htpp://PT.wikipedia.org/wiki/tabula_rasa> Acesso em 13 de maio de 2010. Wikipdia. John Locke. Disponvel em: <htpp://pt.wikipedia.org/wiki/John_Locke.> Acesso em: 17 de dezembro de 2009.

76

ANEXO

Este trabalho apresenta como anexo os questionrios aplicados aos alunos do curso de Cincia da Computao para validao deste trabalho, assim como as fotos que comprovam a aplicao do jogo em sala de aula. Tambm so considerados anexos todos os componentes do jogo AprendES. Para no sobrecarregar o trabalho com um nmero elevado de pginas, este anexo foi inserido no formato digital (cd-rom). Este CD armazena um arquivo *.pdf com os diversos Apndices (total de 3).

Оценить