APRESENTAÇÃO O Processo Seletivo Unificado para ingresso nos ...
UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ … · Figura 3-Processo Unificado ... O processo de...
70
UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ FACULDADE DE COMPUTAÇÃO E ENGENHARIA ELÉTRICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO Lyon Nickson Alves Ferreira DESENVOLVIMENTO, VALIDAÇÃO E AVALIAÇÃO DO SOFTWARE EDUCATIVO URIHI MARABÁ 2014 Lyon Nickson Alves Ferreira
Transcript of UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ … · Figura 3-Processo Unificado ... O processo de...
UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ
FACULDADE DE COMPUTAÇÃO E ENGENHARIA ELÉTRICA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Lyon Nickson Alves Ferreira
DESENVOLVIMENTO, VALIDAÇÃO E AVALIAÇÃO DO SOFTWARE
EDUCATIVO URIHI
MARABÁ
2014
Lyon Nickson Alves Ferreira
DESENVOLVIMENTO, VALIDAÇÃO E AVALIAÇÃO DO SOFTWARE
EDUCATIVO URIHI
Trabalho de Conclusão de Curso,
apresentado para obtenção do grau de
Bacharel em Sistemas de Informação.
Orientador: Prof. Msc. Josué Leal
Moura Dantas
Co-orientadora: Prof. Drª. Danielle
Costa Carrara Couto.
MARABÁ
2014
FICHA CATALOGRÁFICA
UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁ
FACULDADE DE COMPUTAÇÃO
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Lyon Nickson Alves Ferreira
DESENVOLVIMENTO, VALIDAÇÃO E AVALIAÇÃO DO SOFTWARE
EDUCATIVO URIHI
Trabalho de Conclusão de Curso, apresentado para obtenção do grau de Bacharel em
Sistemas de Informação.
Data da defesa: 25 de Junho de 2015.
Conceito:
Banca Examinadora
____________________________________________________
Prof. Msc. Josué Leal Moura Dantas
FACEEL/UNIFESSPA - Orientador
____________________________________________________
Prof. Drª. Danielle Costa Carrara Couto
FACEEL/UNIFESSPA - Membro
____________________________________________________
Prof. Evaldo Andrade
FACEEL/UNIFESSPA - Membro
V
DEDICATÓRIA
Dedico esse trabalho à todos que fazem
parte da minha vida, Deus, família,
professores que acreditaram em mim
desde o início e me mostravam as pedras
em meu caminho e aos meus colegas e
amigos que sempre me apoiaram.
Lyon Nickson
VI
AGRADECIMENTOS
Agradeço primeiramente a Deus, pela força para poder me superar a cada barreira
e dificuldade.
A minha família, meu porto seguro.
À universidade e professores pela oportunidade em fazer esse curso e por todo o
conhecimento que me passaram ao longo da minha jornada.
Aos meus orientadores, Danielle Costa Carrara Couto, Josué Leal Moura Dantas,
que acreditaram em meu potencial e me mantiveram focado em meus objetivos sempre.
Aos meus amigos Dalton Soeiro, Rubem Ribeiro, Dennis Santana, Erick Luis, seja
perto ou longe, sempre me apoiaram, seja nos bons e maus momentos.
A Sinara Araujo e Klétila Mayara que começaram esse trabalho comigo, e que
mesmo separados sempre houve apoio de ambas as partes.
A Ronaldo Ripardo pela paciência, ensinamentos e grande apoio.
VII
RESUMO
Urihi é um jogo educativo que visa contribuir com a educação e preservação do
bioma amazônico auxiliando alunos do ensino fundamental na aprendizagem de estudos
ecológicos voltados a preservação e sustentabilidade a partir de princípios lúdicos. Este
trabalho teve como objetivo central avaliar funcionalidades do Jogo Urihi decorrentes da
aplicação de testes de sistemas. O trabalho teve como objetivos específicos desenvolver
atividades de testes práticos do jogo Urihi para obtenção de parâmetros para possíveis
melhorias do jogo e identificar possibilidades e limites do Jogo Urihi levando em
consideração a aceitação do público alvo. A caminhada metodológica teve como principal
base de análise a metodologia qualitativa/quantitativa e envolveu, além de pesquisas
documentais e bibliográficas, a pesquisa de campo na Escola Municipal de Ensino
Fundamental Salomé Carvalho do município de Marabá, onde foram realizados testes
com duas turmas de terceiro ano, sendo aplicados questionários para validação do jogo
como ferramenta pedagógica. Os resultados da pesquisa indicam que o software é
organizado e funcional, porém ainda possui a ocorrência de pequenos problemas e erros
na programação, assim gerando um feedback usado para uma futura versão mais polida.
Palavras-Chaves: Jogo Educacional, Software Educativo, Testes de Software, Validação
de Software Educativo.
VIII
ABSTRACT
Urihi is an educational game which aims to contribute to the education and
preservation of the Amazon biome helping elementary school students in the learning of
ecological studies aimed at preservation and sustainability as from playful principles. This
work had as main objective to evaluate the Urihi Game features arising from the
implementation of system testing. The work was specific objectives develop practical
testing activities of Urihi game to obtain parameters for possible improvements of the
game and identify possibilities and limits of game Urihi taking into consideration
acceptance of the target audience. The methodological hiking was mainly based on
analysis of the qualitative methodology / quantitative and involved, as well as
documentary and bibliographic searches, the search field at the Municipal Elementary
School Teaching Salome Carvalho in the municipality of Maraba, where tests with two
groups of the third year of elementary school were performed, and questionnaires for
game validation as a pedagogical tool. The survey results indicate that the software is
organized and functional, but also has the occurrence of small problems and errors in
programming, thus forming a feedback used for a future more polished version.
Keywords: Educational Game, Educational Software, Software Testing,
Educational Software Validation.
IX
LISTA DE TABELAS
Quadro 1 – Computadores do laboratório e suas configurações .................................... 58
X
LISTA DE FIGURAS
Figura 1-Modelo prototipação ..................................................................................... 28
Figura 2- Modelo espiral .............................................................................................. 29
Figura 3-Processo Unificado ........................................................................................ 31
Figura 4- Estratégia de teste ........................................................................................ 34
Figura 5- Etapas de teste de software ......................................................................... 35
Figura 6- Teste de unidade .......................................................................................... 36
Figura 7- O processo de depuração ............................................................................ 43
Figura 8- Interface do GIMP ....................................................................................... 46
Figura 9- Etapas de criação de um personagem ........................................................ 46
Figura 10- Joãozinho das couves ................................................................................. 48
Figura 11- a) Fiscal do IBAMA, b) Índio ................................................................... 48
Figura 12- a) Madeireiro irregular, b) Fazendeiro irregular c) Turista desleixado
........................................................................................................................................ 49
Figura 13- sprites da animação do fazendeiro irregular .......................................... 49
Figura 14- Sprites de animação do madeireiro irregular ......................................... 50
Figura 15- Sprites de animação do Indio ................................................................... 50
Figura 16- Sprites de animação da Fiscal do IBAMA ............................................... 51
Figura 17- Conscientização do turista ........................................................................ 52
Figura 18- Evitando o desmatamento ......................................................................... 52
Figura 19- Missão de evitar incêndio .......................................................................... 53
Figura 20- Diagrama de atividades da primeira parte da missão da água ............. 54
Figura 21- Diagrama de atividades da segunda parte da missão da água .............. 55
Figura 22- Diagrama de atividades da missão do fogo ............................................. 56
Figura 23- Ambiente de testes- Laboratório de informática da escola Salomé
Carvalho ........................................................................................................................ 58
Figura 24- Urihi emulado no Wine 1.4 ....................................................................... 59
Figura 25- Urihi emulado no Wine 1.2.2 .................................................................... 60
Figura 26- Gráfico de dificuldade para jogar o Urihi ............................................... 61
Figura 27- Gráfico de ocorrência de erros no jogo Urihi ......................................... 61
Figura 28- Mensagem informativa da primeira missão do jogo Urihi .................... 62
Figura 29- Exemplo de comando pouco intuitivos .................................................... 63
Figura 30- Personagem preso à casa do cenário da primeira missão ...................... 64
XI
SUMÁRIO
1 INTRODUÇÃO .................................................................................................. 13
2 SOFTWARES EDUCACIONAIS ...................................................................... 17
2.1 PROJETOS E INCENTIVOS DO GOVERNO ................................................... 18
2.1.1 EDUCOM ................................................................................................. 18
2.1.2 PRONINFE ............................................................................................... 19
2.1.3 PROINFO ................................................................................................. 20
2.1.4 PROUCA ....................................................................................................... 20
2.2 TIPOS DE SOFTWARES EDUCACIONAIS ..................................................... 21
3 DESENVOLVIMENTO DE SOFTWARE ......................................................... 26
3.1 MODELO DE PROCESSO EVOLUCIONÁRIO ............................................... 27
3.2 FASES DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE .......... 29
4 TESTES DE SOFTWARES ............................................................................... 32
4.1 FASES DE TESTES ............................................................................................. 33
4.1.1 Teste de unidade ....................................................................................... 35
4.1.2 Teste de integração ................................................................................... 37
4.1.3 Teste de sistema ........................................................................................ 38
4.2 TESTE DE VALIDAÇÃO ................................................................................... 41
4.3 DEPURAÇÃO ...................................................................................................... 42
5 JOGO EDUCACIONAL URIHI ........................................................................ 45
5.1 PARTICIPAÇÃO NO DESENVOLVIMENTO DO JOGO ................................ 45
5.1.1 GIMP ............................................................................................................. 45
5.2 NÍVEL DE RECUPERAÇÃO ............................................................................. 47
5.3 NÍVEL DE PROTEÇÃO ...................................................................................... 47
5.4 NÍVEL DE SUSTENTABILIDADE.................................................................... 47
5.5 PERSONAGENS ................................................................................................. 47
5.6 OS CENÁRIOS .................................................................................................... 51
5.7 O PROTÓTIPO .................................................................................................... 51
6 TESTES E VALIDAÇÃO .................................................................................. 58
6.1 AMBIENTE ......................................................................................................... 58
6.2 ACEITAÇÃO ....................................................................................................... 60
XII
6.3 VALIDAÇÃO ...................................................................................................... 62
7 CONSIDERAÇÕES FINAIS .............................................................................. 64
7.1 TRABALHOS FUTUROS ................................................................................... 65
8 REFERÊNCIAS ................................................................................................. 66
APÊNDICE A – PRIMEIRO QUESTIONÁRIO PARA AVALIAÇÃO DO JOGO
EDUCATIVO ........................................................................................................ 69
APÊNDICE B – SEGUNDO QUESTIONÁRIO, MAIS SIMPLIFICADO PARA
AVALIAÇÃO DO JOGO EDUCATIVO .............................................................. 70
13
1 INTRODUÇÃO
Atualmente, estamos cercados por tecnologias, e a utilização do computador já se faz
presentes nos mais diversos setores da sociedade, e na educação não podia ser diferente. A
informática na escola é um meio importante para o professor e seus alunos, pois, facilita para o
professor executar suas atividades em sala de aula e aprimora para seus alunos (VITORIA et
al, 2013).
O software tornou-se hoje profundamente incorporado em praticamente todos os
aspectos de nossas vidas e, consequentemente, o número de pessoas interessadas nos recursos
e nas funções oferecidas por uma determinada aplicação tem crescido significativamente
(PRESSMAN, 2011).
Através do grande avanço da tecnologia os softwares adquiriram reconhecimento e
importância na sociedade. No decorrer dos anos, observando a necessidade da utilização dos
recursos tecnológicos no meio educacional, muitos desenvolvedores passaram a criar softwares
destinados à educação.
Inserir softwares educacionais e colocar os alunos em contato com o computador passa
a ser um diferencial no processo educacional, deixando-os entusiasmados a vivenciar
experiências novas, podendo contribuir para o entendimento de assuntos discutidos em sala de
aula de forma lúdica (CANAL et al,2012).
Por meio de suas técnicas e inovações tecnológicas, a Informática tem contribuído de
forma significativa para o ambiente educativo. Para Moratori, (2003), o uso da informática na
educação através de softwares educativos é uma das áreas da informática que mais ganhou
espaço nas últimas décadas.
O uso de softwares educativos, principalmente os jogos computacionais, oferece
resultados significativamente positivos para a aprendizagem dos alunos (OMORI, 2010). Para
Santos et al. (2006), os jogos educacionais podem, portanto, desenvolver as capacidades
intelectuais do jogador.
Segundo o Ministério da Educação (MEC), o governo tem incentivado a produção de
vários softwares educativos de qualidade e tem analisado esses softwares quanto o seu aspecto
de efetividade pedagógica e seu impacto no aluno e no ambiente escolar.
Através do MEC as escolas têm sido equipadas com computadores, desde a rede
particular à pública e do ensino infantil ao ensino superior. Diversas foram suas ações com a
finalidade de levar as escolas programas educacionais que modificaram o ambiente escolar, o
14
Proinfo, que é um programa educacional com o objetivo de promover o uso pedagógico da
informática na rede pública de educação básica, é um exemplo.
Sendo tão presentes e tendo tanta importância nas escolas, os softwares educativos assim
como qualquer outro software, necessitam ser testados, validados e avaliados, pois eles se
destinam a um fim, de acordo com a Norma ISO/IEC 9126 eles têm como obrigação possuir
qualidade, usabilidade, confiabilidade, eficiência, portabilidade. Testar softwares hoje, tem se
tornado uma necessidade que aumentou muito durante os últimos anos, devido à crescente
busca por qualidade, resultado da maior exigência dos consumidores.
A preocupação com testes e a avaliação de um software educativo se dá devido ao fato,
de que estes passaram a ser utilizados dentro das escolas com o objetivo de facilitar e tornar
mais claro o entendimento de um determinado assunto.
O processo de desenvolvimento de software envolve uma série de atividades nas quais,
apesar das técnicas, métodos e ferramentas empregados, erros no produto ainda podem ocorrer.
Teste de software é o processo de execução de um produto, para determinar se ele
atingiu ou não suas especificações e se funciona corretamente no ambiente para o qual foi
projetado. O seu objetivo principal é identificar falhas, para que estas sejam corrigidas antes da
entrega ao usuário final (DIAS, 2007). E de acordo com Pressman (2011), teste é um conjunto
de atividades que podem ser planejadas com antecedência e executadas sistematicamente.
Segundo Delamaro et al. (2007), para que tais erros não perdurem, ou seja, para serem
descobertos antes de o software ser liberado para utilização, existe uma série de atividades,
coletivamente chamadas de “Validação, Verificação e Teste, ou VV & T, com finalidade de
garantir que tanto o modo pelo qual o software está sendo construído quanto o produto em si
estejam em conformidade com o especificado.
De acordo com Silveira (1999), muitos softwares disponíveis no mercado que são ditos
como educacionais, não apresentam relevância pedagógica. Possuem, muitas vezes, apenas
interfaces agradáveis, coloridas, mas são pobres em conteúdo. Além disso, exploram, na
maioria das vezes, a repetição de exercícios, caracterizando os chamados CAI (Computer Aided
Instruction) – Instrução Auxiliada por Computador, que são classificados como os mais simples
softwares educacionais.
Além da avaliação para saber se o software atende as exigências para as quais ele foi
designado, sendo analisada a ausência ou presença de falhas, o mesmo deve ainda ser avaliado
considerando a questão da efetividade como ferramenta educacional e também deve ser
analisada a aceitação do software educacional por parte dos alunos, como também considerar
ensino-aprendizagem, avaliando o contato dos mesmos com o software.
15
Avaliar significa analisar como um software pode ter um uso educacional, como ele
pode ajudar o aprendiz a construir seu conhecimento e a modificar sua compreensão de mundo
elevando sua capacidade de participar da realidade que está vivendo (SANTOS, 2011). Nesta
perspectiva, uma avaliação bem criteriosa pode contribuir para apontar para que tipo de
proposta pedagógica o software em questão poderá ser mais bem aproveitado.
Existem critérios que foram sendo desenvolvidos para testar e avaliar um software
educativo desde sua concepção, passando pelo seu desenvolvimento até sua implantação. E para
que essas etapas sejam bem desenvolvidas é importante uma organização das mesmas
utilizando metodologias, para então, obter um produto final de qualidade e obter ainda, a
satisfação dos usuários.
Definir uma abordagem própria de avaliação pode ser uma solução prática e adequada
quando métodos, aplicados isoladamente e em sua íntegra, não atendem às expectativas e
necessidades de determinados tipos de projeto (VALIATI, s/d.).
Alguns métodos se mostram mais eficazes do que outros e, o presente trabalho busca
fornecer um panorama de alguns desses métodos que podem ser utilizados tanto para testar o
software na sua forma técnica, como também propor métodos para avaliar se o mesmo é efetivo
na sua proposta educacional e se está contribuindo para o ensino-aprendizagem dos alunos,
apoiado assim o Grupo de Pesquisa LCA (Laboratório de Computação Aplicada) que
desenvolve jogos educativos e objetos de aprendizagem em diversos projetos de extensão que
atendem as escolas públicas de Marabá.
Este trabalho aborda conceitos de desenvolvimento, avaliação, e validação, com o
objetivo de avaliar o ensino aprendizagem e a capacidade de influência que o software
educacional Urihi, jogo educativo para auxiliar a educação ambiental desenvolvido pelo LCA,
pode exercer no processo de aprendizagem e no raciocínio de crianças da Escola Municipal de
Ensino Fundamental Salomé Carvalho no município de Marabá – PA. A Escola Salomé
Carvalho foi à escolhida para que possamos realizar a instalação do jogo e a aplicação dos
questionários com alunos e professores.
O software educacional Urihi é um jogo computacional que aborda a questão da
preservação ambiental e sustentabilidade para alunos do Ensino Fundamental. O mesmo foi
desenvolvido utilizando a ferramenta Game Maker 8.1. Esse software proporcionou aos alunos
da escola Salomé Carvalho obter conhecimento de maneira divertida e motivadora sobre
conceitos de educação ambiental. Os alunos tiveram acesso ao mesmo através do laboratório
da escola onde o jogo está instalado e posteriormente será testado para que possamos avaliar a
aprendizagem dos alunos em relação aos conteúdos embutidos no jogo.
16
Objetivo geral desse trabalho é avaliar funcionalidades do Jogo Urihi decorrentes da
aplicação de testes de sistemas realizados na Escola Salomé de Carvalho no município de
Marabá.
Nessa perspectiva, segue os objetivos específicos:
Desenvolver atividades de testes práticos do jogo Urihi para obtenção de parâmetros
para possíveis melhorias do jogo.
Identificar possibilidades e limites do Jogo Urihi levando em consideração a aceitação
do público alvo.
Este trabalho está organizado em 7 capítulos. Além desta Introdução, o segundo
capítulo, tratamos dos softwares educativos, explanando os diversos tipos de softwares
existentes e os programas de incentivo à informática na educação, elaborados pelo governo. No
terceiro é apresentado os principais modelos e etapas utilizados no processo de
desenvolvimento do jogo Urihi. No quarto apresentamos os diversos tipos de testes que podem
ser realizados em um software educativo. No quinto apresentamos o jogo Urihi. No sexto
capítulo apresentamos os Materiais e Métodos utilizados nesse trabalho, os testes e validação
do jogo. Por fim, são feitas as considerações finais demonstrando os resultados alcançados, as
dificuldades e relatando o que será realizado para trabalhos futuros.
17
2 SOFTWARES EDUCACIONAIS
Nos últimos anos houve um enorme investimento na educação, no sentido de
informatizá-la. O uso de computadores como ferramenta educacional de complementação e de
possível mudança na qualidade do ensino fez-se necessário, pois vivemos atualmente num
mundo dominado pela informação, e o computador oferece uma variedade de ambientes de
ensino e aprendizagem que podem despertar o interesse do aluno.
Porém, devemos enfatizar que o uso de computadores nas escolas não é suficiente, ele
necessita de outros recursos para que tenha sua efetividade garantida. O computador pode ser
considerado um grande aliado no desenvolvimento cognitivo dos alunos, em especial, através
da utilização de Softwares Educacionais (CENCI et al., 2012).
Afirma Mathis (2011), que o desenvolvimento dos softwares educacionais ampliou-se
devido à entrada do computador nas escolas. Este alargamento fez com que esta atividade
conquistasse o mercado.
O processo educacional passou a ter um diferencial desde que os softwares
educacionais foram inseridos no ambiente escolar, proporcionando aos alunos o contato com a
tecnologia, o qual permitiu que eles agregassem valores e experiências.
Os softwares educacionais servem como um apoio pedagógico se tornando um novo
recurso para educação, dessa forma, eles auxiliam os alunos a aprenderem de forma mais
interativa motivando aprendizado do aluno.
Segundo Silveira (1999), os softwares educacionais são programas elaborados com o
intuito de fornecer aos professores e alunos uma ferramenta útil na construção do conhecimento,
reforçando conteúdos vistos em aula ou sendo utilizados como ferramenta que servirá de base
para a aquisição de conhecimento em sala de aula.
De acordo com Moratori, (2003), uma justificativa muito utilizada para aquisição de
softwares educativos pelas escolas, é que estes possibilitam uma maior motivação aos alunos.
Um software educacional deve auxiliar no processo de aprendizagem de alunos,
colaborando para que haja uma aquisição de conhecimento por parte dos estudantes, de maneira
simples, motivadora e de forma lúdica.
Dalmon (2012), diz que no Brasil, a criação de sistemas educacionais é realizada em
muitas universidades por grupos de pesquisa em Informática na Educação (IE), assim como o
LCA, além de empresas de desenvolvimento de software. O desenvolvimento de software
educacional em universidades possibilita a experimentação de novos conceitos e paradigmas
em protótipos que podem ser levados posteriormente ao mercado.
18
Este capítulo tem como objetivo abordar os principais conceitos relacionados aos
softwares educacionais, abordando os incentivos do governo para a área da informática na
educação e explanando os diversos tipos de softwares educacionais existentes.
2.1 PROJETOS E INCENTIVOS DO GOVERNO
Segundo Valente (1999), no Brasil, as políticas de implantação da informática na escola
pública, têm sido norteadas na direção da mudança pedagógica. Embora os resultados dos
projetos governamentais sejam modestos, esses projetos têm sido coerentes e sistematicamente
têm enfatizado a mudança na escola.
No decorrer dos anos, surgiram alguns projetos no intuito de introduzir,
pedagogicamente, a informática na educação, como exemplo podemos citar o projeto Educom,
e o Proninfe, que foram um dos pioneiros no Brasil, surgindo na década de 1980.
2.1.1 EDUCOM
Criado em 1983 pela Secretaria Especial de Informática da Presidência da República e
pelo Ministério da Educação, sua implantação definitiva ocorreu apenas em 1985, com a
instalação de cinco centros de pesquisa em universidades: Universidade Federal de
Pernambuco, Universidade Federal de Minas Gerais, Universidade Federal do Rio de Janeiro,
Universidade de Campinas e Universidade Federal do Rio Grande do Sul (MACHADO, 2009).
Segundo Tavares (2003), o objetivo principal do projeto EDUCOM era desenvolver
pesquisas interdisciplinares sobre a aplicação da informática no processo de ensino-
aprendizagem, bem como a formação de recursos humanos. Os centros-piloto também se
dedicaram à produção de softwares educacionais e à pesquisa na área de educação especial.
Segundo Andrade (2011), como pano de fundo, o projeto Educom surgiu também como
parte integrante do projeto de informatização da sociedade brasileira dentro da política
modernizante então vigente no país (1964-85), que buscou uma autonomia tecnológica no setor
de informática e microeletrônica, associada a uma perspectiva de progresso econômico e social.
Várias foram as metas do projeto EDUCOM, uma delas era desenvolver a pesquisa do
uso educacional da informática (entenda-se na época o uso da linguagem Logo e da linguagem
Basic, disponíveis no Brasil), ou seja, perceber como o aluno aprende sendo apoiado pelo
recurso da informática e se isso melhora efetivamente sua aprendizagem. Outra meta era levar
19
os computadores às escolas públicas, para possibilitar as mesmas oportunidades que as
particulares ofereciam a seus alunos (TAVARES, 2003).
De acordo com Tavares (2003), o projeto EDUCOM foi vital na organização de um
grupo de pesquisadores ativos até hoje, na estruturação dos objetivos nacionais e nos planos de
ação. Mesmo passando por inúmeras dificuldades, foi uma referência para todos os demais
projetos estruturados a partir dele.
Outro programa que apontou após o Educom, foi o Proninfe (Programa Nacional de
Informática na Educação), por volta de 1989. Esse projeto surgiu com o intuito de desenvolver
ainda mais a informática no nosso país.
2.1.2 PRONINFE
Conforme Moraes (1997), após ó projeto Educom, foi estabelecida uma sólida base para
a criação de um Programa Nacional de Informática Educativa - PRONINFE, o que foi efetivado
em outubro de 1989, através da Portaria Ministerial nº 549/GM. O PRONINFE tinha por
finalidade: Desenvolver a informática educativa no Brasil, através de projetos e atividades,
articulados e convergentes, apoiados em fundamentação pedagógica sólida e atualizada, de
modo a assegurar a unidade política, técnica e científica imprescindível ao êxito dos esforços e
investimentos envolvidos.
Ele que tinha como objetivo criar núcleos, distribuídos geograficamente pelo país, a fim
de desenvolver a formação de professores, a utilização da informática na educação, o
desenvolvimento de metodologias, processos e sistemas na área educacional. Esses centros
foram divididos em três categorias para atuação em cada campo que foram os seguintes: Centros
de Informática na Educação de 1º e 2º graus (CIEd); Centro de informática na Educação
Tecnológica (CIET) e o Centro de Informática na Educação Superior (CIES), (ANDRADE,
2011).
Dentre suas ações prioritárias destacavam-se as atividades voltadas para capacitação de
professores e técnicos dos diferentes sistemas de ensino, desenvolvimento de pesquisa básica e
aplicada, implantação de centros de informática educativa, produção, aquisição, adaptação e
avaliação de softwares educativos. Pretendia-se, também, facilitar a aquisição de equipamentos
computacionais por parte dos sistemas de educação pública, implantação de rede pública de
comunicação de dados, incentivo a cursos de pós-graduação na área, bem como
acompanhamento e avaliação do Programa (MORAES, 1997).
20
Anos depois o Proninfe se transformou no Proinfo - Programa Nacional de Tecnologia
- tal programa foi proposto pelo MEC em abril de 1997, pela Portaria nº 522/MEC e
regulamentado pelo Decreto 6.300,em dezembro de 2007, para iniciar o processo de
universalização do uso de tecnologia de ponta no sistema público de ensino.
2.1.3 PROINFO
O PROINFO (Programa Nacional de Informática na Educação) foi lançado em abril de
1997, quase dez anos depois do PRONINFE, com a intenção de formar 25 mil professores e
atender a 6,5 milhões de estudantes, através da compra e distribuição de 100 mil computadores
interligados à Internet (TAVARES, 2003).
Conforme o MEC ele é um programa educacional com o objetivo de promover o uso
pedagógico da informática na rede pública de educação básica. O programa leva às escolas
computadores, recursos digitais e conteúdos educacionais. Em contrapartida, estados, Distrito
Federal e municípios devem garantir a estrutura adequada para receber os laboratórios e
capacitar os educadores para uso das máquinas e tecnologias.
O funcionamento do ProInfo se dá de forma descentralizada, existindo em cada unidade
da Federação uma Coordenação Estadual, e os Núcleos de Tecnologia Educacional (NTE),
dotados de infraestrutura de informática e comunicação que reúnem educadores e especialistas
em tecnologia de hardware e software (FNDE).
Segundo Tavares (2003), o PROINFO está subordinado à SEED/MEC e tem como
objetivo principal introduzir a informática na rede pública de ensino (municipal e estadual),
através de redes técnicas de produção, armazenamento e transmissão de informações, uma
tecnologia que a sociedade está empregando cada vez mais. Portanto, o Programa é fortemente
centrado nas tecnologias de telecomunicações mediadas pelo computador.
Os programas do governo têm como finalidade utilizar o computador na escola com
intuito de criar um ambiente de aprendizagem onde o aluno processe a informação, adicione-a
ao seu intelecto e utilize-a diante de desafios ou situação problemáticas.
2.1.4 PROUCA
Instituído pela Lei nº 12.249, de 14 de junho de 2010, o Programa um Computador Por
Aluno tem por objetivo promover a inclusão digital pedagógica e o desenvolvimento dos
21
processos de ensino e aprendizagem de alunos e professores das escolas públicas brasileiras,
mediante a utilização de computadores portáteis denominados laptops educacionais (FNDE).
Projeto idealizado pelo pesquisador norte americano Nicholas Negroponte. “Um Laptop
Para Cada Criança” - OLPC; foi apresentado no Fórum de Davos, em 2005. O governo
brasileiro se interessou e o projeto foi recontextualizado, passando a ser chamado no Brasil de:
“Programa Um Computador por Aluno”. E está apoiado na perspectiva de que a disseminação
do laptop educacional com acesso à internet pode ser uma poderosa ferramenta de (1) inclusão
digital, (2) de melhoria da qualidade da educação e (3) inserção da indústria brasileira no
processo, objetivos centrais do Programa.
O PROUCA tem como finalidade garantir que todos os alunos de escolas públicas
tenham o direito de utilizar um computador, para que possam ter acesso a informação e assim
adquirir conhecimento.
O programa PROUCA integra as ações para o uso de novas tecnologias da informação
e da comunicação (TIC) nas escolas, por meio da distribuição de computadores portáteis aos
alunos da rede pública de ensino. O projeto piloto está sendo realizado em cinco escolas de
quatro estados brasileiros (Rio de Janeiro, Rio Grande do Sul, São Paulo e Tocantins), além do
Distrito Federal (BRASIL, 2008).
O Projeto foi estruturado de modo a se integrar aos planos e projetos educacionais de
tecnologia educacional. As ações estão inseridas no Plano de Desenvolvimento da Educação
(PDE) e integram o ProInfo.
2.2 TIPOS DE SOFTWARES EDUCACIONAIS
Segundo Mathis (2011, p.11), “os softwares educacionais, quando bem
contextualizados, podem tornar-se aliados no processo de ensino e aprendizagem, pois
desempenham uma dupla função: a lúdica e a didática, de maneira criativa, motivadora e
prazerosa”.
De acordo com Silveira (1999), os tipos mais comuns de softwares educacionais são
simulação, tutorial, exercício e prática, demonstrações, ferramentas e jogos educativos.
Os tipos de softwares classificados como simulação, reproduzem situações do mundo
real para tornar mais fácil o aprendizado do aluno. Esse tipo de software constitui o ponto forte
do computador na escola, pois possibilitam a vivência de situações difíceis ou até perigosas de
serem reproduzidas em aula.
22
Segundo Valente (1989), um determinado fenômeno pode ser simulado no computador,
bastando para isso que um modelo desse fenômeno seja implementado na máquina. Ao usuário
da simulação, cabe a alteração de certos parâmetros e a observação do comportamento do
fenômeno, de acordo com os valores atribuídos.
De acordo com Paprocki (1995, apud SILVEIRA, 1999), simulação é basicamente a
utilização do computador para obtenção de resultados através de modelos matemáticos que
imitam a realidade. A informação é colocada no computador com a finalidade de representar os
fatores necessários a permitir uma melhor aproximação do real. Através de demonstrações que
imitam a realidade, o aluno poderá aprender virtualmente.
Tutorial são programas de perguntas e repostas onde os alunos escrevem, ou selecionam
as respostas para as perguntas propostas. Caracterizam-se por transmitir informações
pedagogicamente organizadas, como se fossem um livro animado, um vídeo interativo ou um
professor eletrônico. A informação é apresentada ao aprendiz seguindo uma sequência, e o
aprendiz pode escolher a informação que desejar.
Segundo Valente (1999), um tutorial é um software no qual a informação é organizada
de acordo com uma sequência pedagógica particular e apresentada ao estudante, seguindo essa
sequência, ou então o aprendiz pode escolher a informação que desejar.
Segundo Liguori, Ribeiro, Stahl (1997, 1994, 1991, apud SILVEIRA 1999), o programa
analisa as respostas e registra os resultados. Em um tutorial, o computador passa a ser o instrutor
do estudante, adaptando-se às necessidades especificas do aluno. Os tutoriais ensinam e
controlam o progresso da aprendizagem. É a forma tecnológica de fornecer a cada aluno um
tutor individual que é paciente, adequado às necessidades do aluno, infatigável.
Conforme Rodrigues (2006), os programas tutoriais podem introduzir conceitos novos,
pretender a aquisição de conceitos, princípios e ou generalizações através da transmissão de
determinado conteúdo ou da proposição de atividades que verifiquem a aquisição deste
conteúdo. Servem como apoio ou reforço para aulas, para preparação ou revisão de atividades,
entre outros aspectos.
Os tutoriais se encaixam na classe do “ensino assistido por computador”, constituindo os
sistemas de Instruções Assistidas por Computadores (CAI), inspirados no método da instrução
programada. A informação que está disponível ao aprendiz é definida e organizada previamente
(RODRIGUES, 2006).
Um software educacional do tipo de exercício e prática, tem como característica ensinar
através da repetição de exercícios propostos, fazendo com que o aprendizado do aluno venha
23
através da prática. Tipicamente esses os programas são utilizados para revisar material visto em
classe, principalmente material que envolve memorização e repetição, como aritmética e
vocabulário (VALENTE, 1993).
Guilherme (1991, apud SILVEIRA, 1999) explana que esta é umas das aplicações
educacionais mais comuns, conhecidas e também desacreditada. Elas são conhecidas como
“CAI” - Instrução Auxiliada por Computador. Estes softwares apresentam questões aos alunos,
e estas podem ser de múltipla escolha explícita ou múltipla escolha implícita onde é o aluno
que escreve sua resposta. Liguori (1997, apud SILVEIRA, 1999), diz que a vantagem dos
programas de exercício e prática é a correção imediata do erro.
Segundo Valente (1993), estes programas requerem a resposta frequente do aluno,
propiciam feedback¹ imediato, exploram as características gráficas e sonoras do computador e,
geralmente, são apresentados na forma de jogos.
Nesse tipo de programa os professores tem acesso a uma infinidade de exercícios que o
aprendiz pode realizar de acordo com seu interesse e seu conhecimento. Valente (1993), afirma
que se o software, além de apresentar o exercício, coletar as respostas de modo a verificar a
performance do aprendiz, então, o professor terá à sua disposição um dado importante sobre
como o material visto em classe está sendo absorvido.
Liguori, Paprocki (1997,1995, apud SILVEIRA, 1999) dizem que as demonstrações são
utilizadas principalmente no ensino tradicional de ciência e matemática. Quando se utiliza esse
tipo de software educacional as demonstrações, por exemplo, do movimento planetário,
estrutura atômica, processos geológicos, correntes oceânicas, entre outras, têm um potencial
interativo muito maior e mais rico do que o tradicional “quadro negro”.
Como diz Paprocki e Stahl (1995,1991, apud SILVEIRA, 1999), ferramentas são uma
modalidade de software educacional em que o computador é utilizado tanto pelos professores
quanto pelos alunos como instrumento capaz de realizar tarefas úteis. Essas aplicações são
extremamente versáteis, tendo aplicação em todas as áreas do currículo escolar. Como
exemplos podemos citar as planilhas eletrônicas, processadores de texto, linguagens de
programação etc.
Diversos jogos educativos desenvolvidos trazem benefícios aos alunos, aumentando a
sua motivação e auxiliando no desenvolvimento de diversas habilidades. Os jogos com objetivo
voltado à educação são considerados instrumentos lúdicos de aprendizagem que proporcionam
rapidez no processo de modificação de comportamento e obtenção de novos conhecimentos, de
forma eficaz (MORATORI, 2003).
24
Segundo Santos et al. (2006), os jogos computacionais, por serem ferramentas
tecnológicas para entretenimento, podem ser adotados como mais uma alternativa de solução,
uma vez que beneficiam o usuário com seu poder de simulação e maximizam a atração e
interação por meio da introdução do elemento lúdico no aprendizado.
Para Machado (2004), o brincar, através do jogo, é uma atividade natural do ser humano.
Entretanto, é importante pensar no jogo como um meio educacional, deixando de lado a ideia
do jogo pelo jogo, e observando-o como um instrumento de trabalho e um meio para atingir
objetivos preestabelecidos, tal como o desenvolvimento de conteúdos curriculares.
Um jogo educativo pode despertar a vontade de aprender. O aluno está estudando um
determinado conteúdo sem que se dê conta disso. Não é um tipo de ensino tradicional, onde o
aluno observa as explicações do professor, depois as aplica em listas de exercícios. Os jogos
educativos podem facilitar a aprendizagem do aluno sem “explicarem” explicitamente
determinados conteúdos (SILVEIRA, 1999).
Os jogos educacionais podem ter características dos tutoriais ou de softwares de
simulação aberta, dependendo do quanto o aprendiz pode descrever suas ideias para o
computador (VALENTE, 1999).
Os jogos educativos utilizam - se do cognitivismo, o aluno “aprende” através da busca,
da descoberta e do raciocínio.
De acordo com Valente (1999), os jogos tentam desafiar e motivar o aprendiz,
envolvendo-o em uma competição com a máquina ou com colegas. A maneira mais simples de
fazer isso é, por exemplo, apresentar perguntas em um tutorial e contabilizar as respostas certas
e erradas. Nesse caso, pode-se dizer que as ações do aprendiz são mais semelhantes ao que
acontece em um tutorial.
Segundo Campos (1996, apud SILVEIRA, 1999), os jogos educativos estimulam a
autoaprendizagem, enfatizam a descoberta, despertam a curiosidade, incorporam a fantasia e o
desafio, exploram efetivos visuais e sonoros que mantém o interesse e o entusiasmo; possuem
grande capacidade interativa e incorporam estratégias cognitivas que motivam, envolvem e
capturam a atenção de maneira lúdica e prazerosa por um maior intervalo de tempo.
Desta forma os jogos possuem um importante papel no desenvolvimento infantil, pois
atuam como motivadores no processo de ensino aprendizagem e mantém uma estreita relação
com a construção do conhecimento (MACHADO, 2004).
O Software Educacional desenvolvido por Jeter Campos (2012) em seu Trabalho de
Conclusão de Curso em conjunto com o grupo LCA da Universidade Federal do Pará, é do tipo
jogo educacional, o mesmo irá proporcionar aos alunos da escola Salomé Carvalho uma nova
25
forma de aprender e/ou aperfeiçoar conteúdo ensinados pelos professores em sala de aula sobre
educacional ambiental.
O jogo possui uma dinâmica bem agradável onde o aprendiz além de adquirir
informações importantes acerca de sustentabilidade, preservação ambiental e etc., irá construir
seu conhecimento.
26
3 DESENVOLVIMENTO DE SOFTWARE
Para Rezende (2002, apud SILVA, 2012), a produção de software é uma atividade
bastante complexa que envolve pessoas, técnicas e ferramentas, quando se tratam de projetos
bastante extensos a complexidade cresce gigantescamente e a presença de falhas se torna
inevitável. Fatores como especificação errada ou requisitos impossíveis de serem
implementados são exemplos de motivos que originam falhas.
De acordo com Pressman (2011), o desenvolvimento de software conta com uma série
de etapas a serem seguidas chamadas de processos de software. Os processos são conjuntos de
ações que direcionam e organizam o desenvolvimento do software e são importantes para
manter controle no desenvolvimento.
O desenvolvimento de um software requer da organização um planejamento cuidadoso
das etapas que serão desenvolvidas, para que tanto a empresa de desenvolvimento quanto o
cliente esteja satisfeito, é necessário que seja seguido uma metodologia de trabalho bem
preparada. É muito importante que a empresa não deixe abalar a sua estrutura metodológica
com a pressão que normalmente são impostas pelos clientes em relação ao prazo de entrega do
produto. Toda metodologia de desenvolvimento tem uma etapa de testes (SILVA, 2012).
De acordo com Pressman (2011), a área de Engenharia de Software auxilia na
construção de softwares mais confiáveis, econômicos e de qualidade. Além da qualidade, foca-
se também nos processos, métodos e ferramentas.
Uma metodologia de processo estabelece o alicerce para um processo de engenharia de
software completo, por meio da identificação de um pequeno número de atividades estruturais
aplicáveis a todos os projetos de softwares, independente do tamanho ou complexidade
(PRESSMAN, 2011).
Ainda segundo Pressman (2011), uma metodologia de processo genérica para a
engenharia de software estabelece cinco atividades metodológicas: comunicação,
planejamento, modelagem, construção e entrega.
Comunicação ajuda a definir metas e objetivos gerais. A intenção dessa fase é
compreender os objetivos das partes interessadas para com o projeto e fazer o levantamento das
necessidades que ajudarão a definir as funções e características do software, portanto é de vital
importância a comunicação com o cliente.
Planejamento engloba um conjunto de práticas técnicas e gerenciais que permitem à
equipe de software definir um roteiro à medida que segue na direção de seus objetivos
estratégicos e táticos. A atividade de planejamento cria um “mapa” que ajuda a guiar a equipe
27
na sua jornada. O mapa – denominado plano de projeto de software – define o trabalho de
engenharia de software, descrevendo as tarefas técnicas a serem conduzidas, os riscos
prováveis, os recursos que serão necessários, os produtos a serem produzidos e um cronograma
de trabalho.
Modelagem é a etapa em que criam-se modelos para uma melhor compreensão do que
será realmente construído. O modelo deve ser capaz de representar as informações que o
software transforma, a arquitetura e as funções que possibilitam a transformação, as
características que os usuários desejam e o comportamento do sistema à medida que a
transformação ocorra.
Construção é a atividade que combina geração de código (manual ou automatizada) e
testes necessários para revelar erros na codificação. O foco inicial dos testes é voltado para os
componentes, com frequência, denominado de teste de unidade. Outros níveis incluem: testes
de integração (realizado à medida que o software é construído), teste de validação que avalia se
os requisitos foram atendidos, e os testes de aceitação, conduzido pelo cliente, voltado para
empregar todos os fatores e funções requisitadas. Teste consiste em um processo de execução
de um programa com o intuito de encontrar um erro.
Emprego é quando o software (como uma entidade completa ou como um incremento
parcialmente efetivado) é entregue ao cliente, que avalia o produto entregue e fornece feedback,
baseado na avaliação.
3.1 MODELO DE PROCESSO EVOLUCIONÁRIO
Os softwares, como todos os sistemas complexos, evoluem de acordo com o passar do
tempo e os requisitos do negócio e do produto mudam comumente à medida que o
desenvolvimento prossegue, impedindo que se tenha um caminho direto para um produto final
de qualidade.
Modelos evolucionários são iterativos. Apresentam características que possibilitam
desenvolver versões cada vez mais completas do software (PRESSMAN, 2011). São eles a
prototipação e o modelo espiral.
Prototipação é um modelo de processo, no qual uma versão inicial é desenvolvida e
implementada e então vai sendo refinada através das muitas versões que serão produzidas, até
que o sistema esperado tenha sido obtido. Esse modelo de processo auxilia os clientes e
interessados no produto a entender os requisitos para o sistema.
28
O paradigma da prototipação (Figura 4) começa com a comunicação. Faz-se uma
reunião com os envolvidos para definir os objetivos gerais do software, identificar quais
requisitos já são conhecidos e esquematizar quais áreas necessitam, obrigatoriamente, de uma
definição mais ampla (PRESSMAN, 2011).
Figura 1-Modelo prototipação
Fonte: Pressman (2011).
De acordo com Pressman (2011), o projeto rápido leva a construção de um protótipo,
que é empregado e avaliado pelos envolvidos, que fornecerão um retorno (feedback), que
servirá para aprimorar os requisitos. A iteração ocorre conforme se ajusta o protótipo às
necessidades de vários interessados e, ao mesmo tempo, possibilita a melhor compreensão das
necessidades que devem atendidas.
O autor ainda enfatiza que embora possam ocorrer problemas, a prototipação pode ser
um paradigma efetivo para a engenharia de software. O segredo é definir as regras do jogo logo
no início; isso significa que todos os envolvidos devem concordar que o protótipo é construído
para servir como um mecanismo para definição de requisitos. Portanto será descartado (pelo
menos em parte) e o software final é arquitetado visando a qualidade.
Conforme Pressman (2011, p. 65), “o modelo espiral é um modelo de processo se
software evolucionário que acopla a natureza iterativa da prototipação com os aspectos
sistemáticos e controlados do modelo cascata”.
29
De acordo com Sommerville (2007), em vez de representar o processo de software como
uma sequência de atividade com algum retorno entre uma atividade e outra. O processo é
representado como uma espiral. Cada loop na espiral representa uma fase no processo de
software.
Segundo Pressman (2011), usando-se o modelo espiral, o software será desenvolvido
em uma série de versões evolucionárias. Nas primeiras iterações, a versão pode consistir em
um modelo ou em um protótipo. Já nas iterações posteriores, são produzidas versões cada vez
mais completas do sistema que passa pelo processo de engenharia (Figura 5).
Figura 2- Modelo espiral
Fonte: Pressman (2011).
Para Sommerville (2007), “a principal diferença entre o modelo em espiral e os outros
modelos de processo de software é o reconhecimento explícito do risco no modelo em espiral”.
3.2 FASES DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
30
Uma das fases de um processo de desenvolvimento de software consiste no
Levantamento de Requisitos. As outras etapas, sugeridas por muitos autores, são: Análise de
Requisitos, Projeto, Codificação, Testes, e Implantação. Dependendo do método/processo
adotado, essas etapas ganham nomenclaturas diferentes, algumas delas podem ser resumidas
em uma etapa única ou uma etapa ser dividida em duas ou mais etapas. Um exemplo disto é o
Processo Unificado, ele divide-se em quatro fases: Concepção, onde é feito o levantamento de
requisitos; Elaboração, onde é feita a análise dos requisitos e o projeto do software; Construção,
onde o software é implementado e testado; e Transição, onde o software será implantado
(GUEDES, 2011).
Para Pressman (2011), o Processo Unificado é uma tentativa de aproveitar os melhores
recursos e características dos modelos tradicionais de processo de software.
Ainda segundo o autor, o Processo Unificado reconhece a importância da comunicação
com o cliente e de métodos racionalizados para descrever a visão do cliente sobre um sistema
(os casos de uso).
As fases que compõem o Processo Unificado estão relacionadas às atividades
metodológicas genéricas (figura 6). Pressman (2011) descreve essas fases seguinte forma:
Fase de Concepção envolve tanto a atividade de comunicação com o cliente como a de
planejamento. Nessa fase, identificam-se as necessidades de negócio para o software; propõe-
se uma arquitetura rudimentar para o sistema e se desenvolve um planejamento para a natureza
iterativa e incremental do projeto decorrente. O planejamento identifica recursos, avalia os
principais riscos, define um cronograma e estabelece uma base para as fases que serão aplicadas
à medida que o incremento de software é desenvolvido.
Fase de Elaboração abrange as atividades de comunicação e modelagem do modelo de
processo genérico. A elaboração refina e expande os casos práticos preliminares, desenvolvidos
como parte da fase de concepção, e amplia a representação da arquitetura, incluindo cinco
visões diferentes do software: modelo de caso prático, modelo de requisitos, modelo de projeto,
modelo de implementação e modelo de emprego. No auge da fase de elaboração, o plano é
revisado cuidadosamente para assegurar que escopo, riscos e datas de entrega permaneçam
razoáveis. Normalmente, as modificações no planejamento são feitas nessa oportunidade.
Fase de Construção é idêntica à atividade de construção definida para o processo de
software genérico. Tem como entrada o modelo de arquitetura e por isso desenvolve ou adquire
componentes de software, esses componentes farão com que cada caso prático (de uso) se torne
operacional para os usuários finais.
31
Fase de Transição abrange os últimos estágios da atividade da construção genérica e a
primeira parte da atividade de emprego genérico: entrega e realimentação (feedback). Nessa
fase, entrega-se o software aos usuários finais para testes beta e o feedback dos usuários relata
defeitos e mudanças necessárias. Na conclusão da fase de transição, o incremento torna-se uma
versão do software utilizável.
Fase de Produção coincide com a atividade de emprego do processo genérico. Durante
essa fase, o uso contínuo do software é monitorado, e é disponibilizado suporte para o ambiente
(infraestrutura) operacional, além de realizar e avaliar relatórios de defeitos e solicitações de
mudanças.
Figura 3-Processo Unificado
Fonte: Pressman (2011).
32
4 TESTES DE SOFTWARES
Todo software necessita passar por uma etapa fundamental no decorrer do seu
desenvolvimento, essa etapa é conhecida como Teste de Software. Como objetivo principal, o
teste de software irá revelar a presença de erros e verificar se todos os requisitos do sistema
foram desenvolvidos corretamente e de acordo com as perspectivas dos clientes, garantindo a
qualidade do software.
Segundo Pressman (2011), o teste proporciona o último elemento a partir do qual a
qualidade pode ser estimada e, mais pragmaticamente, os erros podem ser descobertos.
A atividade de teste é complexa. São diversos os fatores que podem colaborar para a
ocorrência de erros (DELAMARO et al., 2007).
Por isso, o software passa por fases de teste, essas fases são divididas em teste de
unidade, teste de integração e teste de sistema. No teste de unidade cada unidade do programa
será testada separadamente, no teste de integração os componentes que foram testados
separadamente agora serão acoplados e testados em conjunto, após esses dois testes, o sistema
já está completo, então é feito o teste de sistema, no qual o sistema será testado como um todo.
Para Pfleeger (2004), ao desenvolver um grande sistema, o teste, geralmente, envolve
vários estágios. Primeiro cada componente do programa é testado, isolado dos outros
componentes do sistema. Esse teste, conhecido como teste de módulo, teste de componente ou
teste de unidade, verifica se o componente funciona de forma adequada aos tipos de entradas
esperadas, a partir do estudo do projeto do componente.
Testar o sistema é muito diferente dos testes de unidade e de integração. Ao realizar o
teste de unidade em seus componentes, você tem o controle total do processo de teste
(PFLEEGER, 2004). Para o autor, o objetivo dos testes de unidade e de integração foi o de
assegurar que o código implementava adequadamente o projeto, isto é, que os programadores
tinham escrito um código que fazia o que os projetistas queriam. No teste de sistema, temos um
objetivo muito diferente: assegurar que o sistema faz o que o cliente quer que ele faça.
De acordo com Pressman (2011), o desenvolvedor do software é sempre responsável
pelo teste das unidades individuais (componentes) do programa, garantindo que cada uma
executa a função ou apresenta o comportamento para o qual foi projetada. Em muitos casos, o
desenvolvedor faz também o teste de integração – uma etapa de teste que leva à construção (e
teste) da arquitetura completa do software.
33
É válido destacar, que antes da execução de cada uma das fases de testes, é importante
ter uma estratégia de teste de software, que são etapas que descrevem como esses testes serão
efetuados.
Independentemente da fase de teste, existem algumas etapas bem definidas para a
execução da atividade de teste. São elas: 1) planejamento; 2) projeto de casos de teste; 3)
execução; e 4) análise (DELAMARO et al., 2007).
Para Pressman (2011), qualquer estratégia de teste deve incorporar planejamento dos
testes, projeto de casos de teste, execução dos testes, coleta e avaliação dos dados resultantes.
Além das fases de teste, há um teste que deverá ser realizado denominado de teste de
validação, o qual tenta descobrir os erros do software, porém, o seu objetivo principal é avaliar
os requisitos.
Validação refere-se a um conjunto de tarefas que asseguram que o software foi criado e
pode ser rastreado segundo os requisitos do cliente (PRESSMAN, 2011).
Durante o processo de teste de software, conforme os erros vão sendo encontrados, eles
devem ser corrigidos, para isso é utilizado um processo chamado de depuração.
Segundo Pressman (2011), a depuração ocorre como consequência de um teste bem-
sucedido. Isto é, quando um caso de teste descobre um erro, a depuração é o processo que
resulta na remoção do erro.
4.1 FASES DE TESTES
Quanto ao seu objetivo na busca por erros do programa, segundo Pfleeger (2004), os
testes de software podem ser subdivididos em testes de unidade, teste de integração e teste de
sistema.
Porém, quando for iniciado o processo de teste de software, poderá ser estabelecido
estratégias que irão auxiliar a realização desses testes da melhor maneira possível. Uma das
estratégias está no conceito de uma espiral, como visto na figura 4.
O teste de unidade começa no centro da espiral e se concentra em cada unidade do
software conforme implementado no código-fonte. O teste prossegue movendo-se em direção
ao exterior da espiral, passando pelo teste de integração, em que o foco está no projeto e
construção da arquitetura de software. Continuando na mesma direção da espiral, encontramos
o teste de validação, em que requisitos estabelecidos como parte dos requisitos de modelagem
34
são validados em relação ao software criado. Finalmente, chegamos ao teste de sistema, no qual
o software e outros elementos são testados como um todo (PRESSMAN, 2011).
Figura 4- Estratégia de teste
Fonte: Pressman (2011).
De acordo com a figura 5, as etapas do teste de software ocorrem de forma sequencial.
Inicialmente, os testes focalizam cada componente individualmente, garantindo que ele
funcione adequadamente como uma unidade, daí o nome de teste de unidade. O teste de unidade
usa intensamente técnicas de teste com caminhos específicos na estrutura de controle de um
componente para garantir a cobertura completa e a máxima detecção de erro. O teste de
integração cuida de problemas associados com aspectos duais de verificação e construção de
programa. Depois que o software foi integrado, é executado uma série de testes de ordem
superior. O teste de validação proporciona a garantia final de que o software satisfaz a todos os
requisitos informativos, funcionais, comportamentais e de desempenho. O teste de sistema
verifica se todos os elementos se combinam corretamente e se a função/desempenho global do
sistema é conseguida (PRESSMAN, 2011).
35
Figura 5- Etapas de teste de software
Fonte: Adaptada de Pressman (2011)
4.1.1 Teste de unidade
Os testes de unidade, conhecidos também como teste unitário ou teste de módulo, é a
fase em que as menores unidades do software que foram criadas, serão testadas. Este teste tem
como objetivo identificar falhas de funcionamento, como erros de lógica e de implementação
que estejam nas unidades dos sistemas, o teste de unidade é feito separadamente em cada
módulo do software independente do todo.
De acordo com Delamaro et al. (2007), o teste de unidade tem como foco as menores
unidades de um programa, que podem ser funções, procedimentos, métodos ou classes.
Segundo Pressman (2011), esse teste enfoca a lógica interna de processamento e as
estruturas de dados dentro dos limites de um componente.
A figura 9 ilustra como os testes de unidade são executados. A interface do modulo é
testada para assegurar que as informações fluam corretamente para dentro e para fora da
unidade de programa que está sendo testada. A estrutura de dado local é examinada para garantir
que os dados armazenados temporariamente mantenham sua integridade durante todos os
passos na execução de um algoritmo. Todos os caminhos independentes da sua estrutura de
controle são usados para assegurar que todas as instruções em um módulo tenham sido
executadas pelo menos uma vez. As condições limite são testadas para garantir que o módulo
opera adequadamente nas fronteiras estabelecidas para limitar ou restringir o processamento.
Finalmente são testados todos os caminhos de manipulação de erro. Casos de testes deverão ser
36
projetados para descobrir erros devido a computações errôneas, comparações incorretas ou
fluxo de controle inadequado (PRESSMAN, 2011).
Figura 6- Teste de unidade
Fonte: Adaptada de Pressman (2011)
O teste de unidade é considerado uma técnica de teste de caixa branca, que pode ser
concretizado em paralelo sobre diferentes módulos.
O teste de caixa branca são aqueles executados a partir de uma análise dos caminhos
lógicos possíveis de serem executados. Esse teste é chamado também de teste estrutural ou
orientado à lógica, o qual avalia o comportamento interno do componente de software
(MYERS, 1979).
Para Delamaro et al. (2007), o teste estrutural baseia-se no conhecimento da estrutura
interna do programa, sendo os aspectos de implementação para a geração/seleção dos casos de
teste associados.
O teste de unidade normalmente é considerado um auxiliar para a etapa de codificação.
O projeto dos testes de unidade pode ocorrer antes de começar a codificação ou depois que o
código-fonte tiver sido gerado (PRESSMAN, 2011).
37
4.1.2 Teste de integração
O teste de integração tem como foco identificar falhas que surgiram quando houve a
integração dos componentes de um sistema. Esse teste visa encontrar erros que estejam
agregados às interfaces entre os módulos do software, na maioria das vezes esses erros são
decorrentes da transmissão de dados.
No teste de integração, que deve ser realizado após serem testadas as unidades
individualmente, a ênfase é dada na construção da estrutura do sistema (DELAMARO et al.,
2007).
Quando os módulos são agregados, dados podem ser perdidos. O teste de integração é
feito para garantir que as unidades que foram testadas individualmente trabalhem de forma
cooperativa quando forem integradas.
É durante o teste de integração que serão identificados se os componentes do software
não irão gerar erros quando são postos para trabalhar em conjunto. Os chamados erros de
interface são exemplos de erro que são encontrados com frequência durante a execução do teste
de integração, esses erros são provenientes da incompatibilidade de interface entre módulos que
deverão funcionar de forma unificada.
Segundo Pressman (2011), o teste de integração é uma técnica sistemática para construir
a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados
com as interfaces. O objetivo é construir uma estrutura de programa determinada pelo projeto
a partir de componentes testados em unidade.
Quando estivermos convencidos de que os componentes individuais estão funcionando
corretamente e de atingem nossos objetivos, os combinamos em um sistema em funcionamento.
Essa integração é planejada e coordenada de modo que quando uma falha ocorre, temos alguma
ideia do que a causou (PFLEEGER, 2004).
O teste de integração é composto por: Integração não incremental, no qual o programa
é testado como um todo, acarretando em um maior número de erros encontrados; e integração
incremental, no qual os módulos são integrados pouco a pouco. O teste de integração é
executado de maneira mais eficiente quando feito de forma incremental.
Para Pressman (2011), na integração incremental, o programa é construído e testado em
pequenos incrementos, em que os erros são mais fáceis de isolar e corrigir; as interfaces tem
maior probabilidade de ser testadas completamente; e uma abordagem sistemática de teste pode
ser aplicada.
38
Duas das estratégias de integração incremental são conhecidas como: Integração
descendente e Integração ascendente.
Conhecida também como uma abordagem “top-down”, a integração descendente
integra os módulos de cima para baixo.
Teste de integração descendente é uma abordagem incremental para a construção da
arquitetura de software. Os módulos são integrados deslocando-se para baixo através da
hierarquia de controle, começando com o modulo de controle principal. Módulos subordinados
ao modulo de controle principal são incorporados à estrutura de uma maneira: primeiro-em-
profundidade ou primeiro-em-largura (PRESSMAN 2011).
A integração ascendente é denominada também de abordagem “bottom-up”, onde os
seus componentes são integrados de baixo para cima, ou seja, os módulos que serão combinados
são aqueles que ficam no seu nível inferior.
O teste de integração ascendente começa a construção e o teste com módulos atômicos
(isto é, componentes nos níveis mais baixos na estrutura do programa) (PRESSMAN 2011).
4.1.3 Teste de sistema
O teste de sistema abrange diversos tipos de testes, e tem como objetivo testar o sistema
computacional como um todo. Mesmo cada teste sendo caracterizado com uma finalidade
diferente o objetivo geral não deixa de ser atingido, que é examinar se todos os elementos que
constituem o sistema foram integrados de forma adequada.
Teste de sistema é na realidade uma série de diferentes testes cuja finalidade primária é
exercitar totalmente o sistema (PRESSMAN, 2011).
Segundo Delamaro et al. (2007), depois que se tem o sistema completo, com todas as
suas partes integradas, inicia-se o teste de sistema. O objetivo é verificar se as funcionalidades
especificadas nos documentos de requisitos estão todas corretamente implementadas.
Esse teste tende a executar o sistema de acordo com a visão do seu usuário final. Nele é
averiguado, á procura de falhas, os aspectos de funcionamento do software, interligado aos
demais elementos do sistema, como o hardware e outros elementos.
Após a realização dos testes de integração, será a vez dos testes de sistemas, os quais
são utilizados com a finalidade de garantir a funcionalidade desejada do sistema.
Segundo Pfleeger (2004), as várias etapas dos testes do sistema são Teste funcional,
teste de desempenho, teste de aceitação, teste de instalação e teste funcional.
Segundo Delamaro et al. (2007), teste funcional é uma técnica para se projetarem casos
de testes na qual o programa ou sistema é considerado uma caixa preta e, para testá-lo, são
39
fornecidas entradas e avaliadas as saídas geradas para verificar se estão em conformidade com
os objetivos especificados. Nessa técnica os detalhes de implementação não são considerados
e o software é avaliado segundo o ponto de vista do usuário.
Os testes funcionais, também conhecidos como testes de caixa-preta, são gerados a
partir de uma análise dos relacionamentos entre os dados de entrada e de saída.
Conforme Pfleeger (2004), o teste do sistema começa como o teste funcional. Enquanto
os testes anteriores se concentravam nos componentes e em suas interações, essa primeira etapa
ignora a estrutura do sistema e tem como foco a sua funcionalidade.
Cabe ao teste funcional a avaliação do comportamento externo do componente de
software, porem ele não irá avaliar o comportamento interno do mesmo. O teste funcional não
leva em consideração a maneira como o software está organizado internamente, mesmo que
isto cause algum impacto durante a operação de alguma função analisada em sua interface.
Segundo Pfleeger (2004), um teste funcional avalia o sistema, para determinar se as
funções descritas na especificação dos requisitos são realmente realizadas pelo sistema
integrado. O resultado é um sistema em funcionamento. Ainda para o autor, um teste funcional
verifica se o sistema integrado realiza as funções especificadas nos requisitos.
Uma vez que determinamos que o software realize as funções exigidas pelos requisitos,
voltamos a atenção para o modo como essas funções são realizadas. Portanto, o teste funcional
lida com os requisitos funcionais, e o teste de desempenho trata dos requisitos não-funcionais
(PFLEEGER, 2004).
Os requisitos são à base dos testes de desempenho. Esse teste acompanha o desempenho
do sistema, averiguando se o mesmo atende aos objetivos de desempenho que o cliente propôs.
Assim que a equipe de testes estiverem convencida de que as funções são executadas
como foi especificado, o teste de desempenho compara os componentes integrados com os
requisitos não funcionais do sistema (PFLEEGER, 2004).
O teste de desempenho é projetado para testar o desempenho em tempo de execução do
software dentro do contexto de um sistema integrado. O teste de desempenho é feito em todas
as etapas no processo de teste. Até mesmo em nível de unidade, o desempenho de um módulo
individual pode ser avaliado durante o teste. No entanto, o verdadeiro desempenho de um
sistema só pode ser avaliado depois que todos os elementos do sistema estiverem totalmente
integrados (PRESSMAN, 2011).
Conforme Pfleeger (2004), quando os testes funcionais e de desempenho são
concluídos, estamos convencidos de que o sistema satisfaz todos os requisitos especificados
40
durante os estágios iniciais de desenvolvimento do software. O próximo passo é perguntar aos
clientes e usuários se eles concordam com isso.
A partir de então, inicia-se o teste de aceitação, onde os usuários finais irão testar o
sistema e verificar se o mesmo está conforme foram especificados.
Quando o teste de desempenho está completo, os desenvolvedores ficam seguros de que
o sistema funciona de acordo com o entendimento obtido da descrição do sistema. O próximo
passo é conferir com o cliente se o sistema está de acordo com as expectativas dele. O teste de
aceitação é realizado em conjunto com os clientes e nele o sistema é verificado em comparação
com a descrição dos requisitos do cliente (PFLEEGER, 2004).
Os testes de aceitação são realizados por usuários finais do sistema, os quais vão simular
as operações de rotina do sistema com a finalidade de examinar se seus procedimentos estão
conforme o solicitado.
Os clientes também testam o sistema a fim de garantir que corresponda ao que eles
entendem dos requisitos, o que pode ser diferente daquilo que os desenvolvedores entendem.
Esse teste, chamado de teste de aceitação, assegura aos clientes que o sistema solicitado é o que
foi construído (PFLEEGER, 2004).
Depois de se ter finalizado o teste de aceitação, o sistema aceito é instalado no ambiente
em que será utilizado. Um teste de instalação final é, então, executado para assegurar que o
sistema ainda funciona como devido (PFLEEGER, 2004).
O teste de instalação também conhecido como teste de disponibilização corresponde a
última etapa dos testes de sistemas. Ele estará completo somente quando o usuário estiver
satisfeito com os resultados, e então o sistema será entregue ao cliente.
O teste de disponibilização, também chamado de teste de configuração, exercita o
software em cada ambiente no qual ele deve operar. Além disso, o teste de disponibilização
examina todos os procedimentos de instalação e software especializado de instalação que serão
usados pelos clientes e, toda a documentação que será usada para fornecer o software para os
usuários finais (PRESSMAN, 2011).
Segundo Pfleeger (2004), o ciclo final dos testes consiste em instalar um sistema nos
locais em que estão os usuários. Se os testes de aceitação tiverem sido realizados no local, o
teste de instalação poderá ser dispensado. Contudo, se as condições do teste de aceitação não
forem as mesmas condições reais do local, serão necessários testes adicionais. O autor também
destaca também que os testes enfocam dois aspectos: a integridade do sistema instalado e a
verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas
condições do local de operação.
41
Além dos quatro tipos de testes de sistema que foram apresentados, existe também um
teste de grande importância, que deve ser executado em qualquer fase de teste, esse teste é
conhecido como teste de segurança.
De acordo com Pressman (2011), qualquer sistema de computador que trabalhe com
informações sensíveis ou que cause ações que podem inadequadamente prejudicar (ou
beneficiar) indivíduos, é um alvo para acesso impróprio ou ilegal.
O teste de segurança irá examinar quais são as partes do sistema que possui facilidades
em sofrer ataques de segurança. Ao finalizar o teste, não significa que o sistema estará livre de
invasões, mas, o desenvolvedor tem por função dificultar essas invasões.
O teste de segurança tenta verificar se os mecanismos de proteção incorporados ao
sistema vão de fato protegê-lo, contra acesso indevido (PRESSMAN, 2011).
4.2 TESTE DE VALIDAÇÃO
A validação pode ser definida de várias maneiras, mas uma definição simples (embora
rigorosa) é que a validação tem sucesso quando o software funciona de uma maneira que pode
ser razoavelmente esperada pelo cliente (PRESSMAN, 2011).
Mesmo que o software esteja funcionando de forma correta, um grande fator deverá ser
analisado, se o software apresenta as propriedades e funcionalidades que foram definidas
durante a etapa de especificação dos requisitos.
A validação de software é conseguida por meio de uma série de testes que demonstram
conformidade com os requisitos. Um plano de teste descreve as classes de testes a ser
conduzidas e um procedimento de teste define casos de testes específicos destinados a garantir
que todos os requisitos funcionais sejam satisfeitos, todas as características comportamentais
sejam obtidas, todo o conteúdo seja preciso e adequadamente apresentado, todos os requisitos
de desempenho sejam atendidos, a documentação esteja correta e outros requisitos sejam
cumpridos (PRESSMAN, 2011).
Validar um software exige esforço. Geralmente, o desenvolvedor tem dificuldades em
predizer como o software será utilizado, na visão do programador o software pode está
excelente em todos os aspectos, porém, o usuário poderá não ter a mesma visão.
Quando é construído um software personalizado para um cliente, são feitos testes de
aceitação para permitir ao cliente validar todos os requisitos. Conduzido pelo usuário final e
não por engenheiros de software, um teste de aceitação pode variar de um informal teste drive
até uma série de testes planejados e sistematicamente executados (PRESSMAN, 2011).
42
Há erros que o desenvolvedor não consegue descobrir, somente o usuário final que
descobrirá ao utilizar o software, em decorrência disso são feitos testes chamados de teste alfa
e beta.
O teste alfa é conduzido na instalação do desenvolvedor por um grupo representativo
de usuários finais. O software é usado em um cenário natural com o desenvolvedor “espiando
por cima dos ombros” dos usuários, registrando os erros e os problemas de uso. Os testes alfas
são conduzidos em um ambiente controlado (PRESSMAN, 2011).
No caso do teste beta, a participação será somente dos usuários finais, os quais deverão
relatar ao desenvolvedor os erros que encontrarem.
O teste beta é conduzido nas instalações de um ou mais usuários finais. Diferentemente
do teste alfa, o desenvolvedor geralmente não está presente. Portanto, o teste beta é uma
aplicação “ao vivo” do software em um ambiente que não pode ser controlado pelo
desenvolvedor. O cliente registra todos os problemas (reais ou imaginários) encontrados
durante o teste beta e relata esses problemas para o desenvolvedor em intervalos regulares.
Como resultado dos problemas relatados durante o teste beta, os engenheiros de software fazem
modificações e então preparam a liberação do software para todos os clientes (PRESSMAN,
2011).
4.3 DEPURAÇÃO
Durante as fases do ciclo de vida do software diversos erros podem surgir. A depuração
é uma atividade que tem por função rastrear a causa de um erro e elimina-lo.
Segundo Delamaro et al. (2007), a depuração de software é comumente definida como
a tarefa de localização e remoção de defeitos. Normalmente, ela é entendida como o corolário
do teste bem-sucedido, ou seja, ela ocorre sempre que um defeito é revelado.
A depuração é um processo que pode ocorrer durante a codificação, depois do teste e
durante a manutenção do software.
A depuração durante a codificação é uma atividade complementar à de codificação. Já
a depuração depois do teste é ativada pelo teste bem-sucedido, isto é, aquele que revela a
presença de defeitos, podendo beneficiar-se da informação coletada nessa fase. A depuração
durante a manutenção, por sua vez, ocorre por uma necessidade de manutenção no software,
que pode ter sido causada, por exemplo, por um defeito revelado depois de liberado o software
ou pela necessidade de acrescentar novas características a ele (DELAMARO et al., 2007).
43
A depuração não é um teste, mas frequentemente ocorre como consequência do teste. O
processo de depuração começa com a execução de um caso de teste. Os resultados são avaliados
e uma falta de correspondência entre o desempenho esperado e o desempenho real é encontrada.
Em muitos casos, os dados não correspondentes são um sintoma de uma causa subjacente,
embora oculta. O processo de depuração tenta combinar o sintoma com a causa, levando assim
à correção do erro (PRESSMAN, 2011).
Figura 7- O processo de depuração
Fonte: Pressman (2011).
O processo de depuração não é um processo fácil e os erros que serão encontrados
podem variar de nível. Para Pressman (2011), durante a depuração, você encontrará erros que
variam desde levemente desagradáveis (por exemplo, um formato de saída incorreto) até
catastróficos (por exemplo, o sistema falha, causando sérios danos econômicos ou físicos).
Por isso, existem abordagens que poderão ser seguidas, denominadas de estratégias de
depuração cuja função é auxiliar na execução do processo de depuração.
São três estratégias que foram propostas, segundo Myers (1979, apud Pressman, 2011),
as propostas são: (1) força bruta, (2) rastreamento e (3) eliminação da causa. Cada uma dessas
estratégias pode ser conduzida manualmente, mas as modernas ferramentas de depuração
podem tornar o processo muito mais eficaz.
44
Independentemente da abordagem adotada, a depuração tem um objetivo primordial –
encontrar e corrigir a cauda de um erro ou defeito de software. O objetivo é alcançado por uma
combinação de avaliação sistemática, intuição e sorte (PRESSMAN, 2011).
Como o jogo educacional Urihi foi desenvolvido antes da implementação desse projeto,
os testes iniciais não foram documentados, sendo que alguns foram realizados durante a
programação do mesmo, como o teste de unidade e integração, nesse projeto foi focado no teste
de sistema, mais especificamente nos testes de instalação, aceitação e validação.
45
5 JOGO EDUCACIONAL URIHI
Segundo Jeter et al. (2012) Urihi é um jogo educativo em duas dimensões que tem como
objetivo contribuir na educação e preservação do bioma amazônico, conscientizando alunos do
ensino fundamental na aprendizagem da ecologia, aplicada na sustentabilidade e preservação,
retratando de maneira ilustrativa o cotidiano desse ambiente, possibilitando aos utilizadores do
jogo vivenciar de forma virtual diversas situações que seriam difíceis de serem resolvidas e
desfrutadas no mundo real.
Esse jogo tem como objetivo principal sensibilizar as crianças da faixa etária de 9 a 13
anos, abordando questões ambientais e conceitos de meio ambiente e preservação da natureza.
O roteiro do jogo Urihi, até o momento, conta com três níveis dispostos de três cenários,
sendo que cada nível faz uso dos cenários ao todo. Esses níveis são determinados como:
Recuperação, Proteção e Sustentabilidade.
5.1 PARTICIPAÇÃO NO DESENVOLVIMENTO DO JOGO
O jogo educativo foi inicialmente programado por Jeter Campos (2012), desde a fase de
brainstorming, até a implementação. Inicialmente os desenhos dos personagens foram feitos
por Carlos Alberto Pereira Duarte Filho1, e posteriormente, os membros do LCA, juntamente
com o Jeter Campos (2012) fizeram o planejamento de fases para concluir o jogo educativo.
Para a edição das imagens criadas por mim para os novos personagens da versão final do jogo
Urihi, foi utilizado a ferramenta livre GIMP.
5.1.1 GIMP
O GIMP é uma ferramenta de criação e edição de imagens, ele foi criado para preencher
o espaço gerado pela falta de programas gráficos para o sistema UNIX, é uma ferramenta
utilizada para criação de desenhos, edição de fotos, ou seja, manipulação de imagens em geral,
hoje esse programa se estende aos sistemas Windows e o Mac OS (MILAMI, 2008).
1 Discente da turma de 2007, do curso de Bacharel em Sistemas de Informação da Universidade Federal do Pará
– UFPA, Campus de Marabá
46
Figura 8- Interface do GIMP
Fonte: http://www.gimp.org/screenshots/
Os esboços são abertos no GIMP, e editados separando em camadas cada cor que foram
aplicado no desenho, seja sombreamento ou efeito de luz, assim facilitando ao colorir, no fim,
é só mesclar todas as camadas e exportar a imagem. O GIMP também serve na edição da
imagem para a animação do personagem fazendo imagens intermediárias tornando a animação
mais fluida e natural.
Resumindo, o processo de criação dos personagens consistiu nos seguintes passos de
acordo com a figura 9, primeiramente é feito uma idealização do personagem, em seguida é
desenhado a mão o esboço do personagem e seus movimentos e depois digitalizados para serem
tratados no GIMP e finalmente exportados para o Game Maker.
Figura 9- Etapas de criação de um personagem
Idealização de personagem
Esboço desenhado a mão
digitalização da imagem
tratamento de imagem e edição
no GIMP
Exportação das imagens do
personagem para o Game Maker
47
O jogo está dividido em três níveis:
5.2 NÍVEL DE RECUPERAÇÃO
É o primeiro estágio, onde deve ser feita a recuperação de toda uma área degradada, e
para conseguir realizar essa tarefa é necessário cumprir missões ambientais, como coleta
seletiva de lixo e recuperação da mata ciliar e área desmatada.
5.3 NÍVEL DE PROTEÇÃO
Esse nível é baseado em três premissas, a primeira deve combater a ocorrência dos
desastres ambientais, em seguida minimizar os danos de um desastre ambiental e por último
recuperar a área atingida a fim de manter o equilíbrio ecológico. Os riscos ambientais que foram
mapeados consistem em queimadas, poluições e assoreamento dos rios, contaminação do solo,
desmatamento, e extinção de árvores e animais.
5.4 NÍVEL DE SUSTENTABILIDADE
Nesse nível o objetivo central é conseguir utilizar os recursos naturais sem prejudicar o
meio ambiente, assim podendo manter um equilíbrio que proporcione um desenvolvimento
sustentável, sem ter que destruir a natureza para atingir esse crescimento. Para o jogador
concluir esse nível ele deve utilizar as técnicas sustentáveis, como manjo florestal, criação de
peixes, extrativismo sustentável.
5.5 PERSONAGENS
No jogo Urihi, os personagens são divididos em duas categorias, os protetores e
destruidores, eles possuem ideias divergentes e geram conflito durante o decorrer das missões
do jogo.
Os personagens iniciais foram desenvolvidos por Carlos A. P. D. Filho (figuras 10 e 12
–c), os demais foram produtos desse trabalho, desenvolvidos e animados pelo autor para a
versão final do jogo educativo.
Na categoria de personagens protetores destacam-se o Pequeno Agricultor chamado no
jogo de Joãozinho das couves (figura 10) e o Ribeirinho, eles são considerados personagens
principais e podem ser controlados diretamente pelo jogador.
48
Figura 10- Joãozinho das couves
Fonte: Jeter et al. (2012).
Os personagens: Fiscal do IBAMA (figura 11-a), Agente da polícia ambiental, Fiscal do
INCRA, Bombeiro e o Índio (figura 11-b) são coadjuvantes, apenas farão uma interação com o
personagem principal e os demais elementos e personagens no cenário, realizando tarefas
predefinidas.
Figura 11- a) Fiscal do IBAMA, b) Índio
Fonte: Jeter et al. (2012).
Na categoria das personagens destruidores, ela é definida pelos Madeireiros irregulares
(figura 12- a), Fazendeiros irregulares (figura 12- b), Pescadores clandestinos, Caçadores,
Garimpeiros irregulares, Mineradores irregulares e o Turista desleixado (figura 12- c).
a
a) b)
49
Figura 12- a) Madeireiro irregular, b) Fazendeiro irregular c) Turista desleixado
Fonte: Jeter et al. (2012).
Durante esse projeto, desenvolvi as novas personagens e os sprites para a animação
inicialmente foram criados o fazendeiro irregular (figura 13), o madeireiro irregular (figura 14),
o índio (figura 15) e a fiscal do IBAMA (figura 16).
Figura 13- sprites da animação do fazendeiro irregular
O fazendeiro irregular (figura 12) tem como função, fazer queimadas e contratar o
madeireiro ilegal para desmatar árvores nativas, e criação de bois próximo de nascentes, o
personagem principal tem o dever de impedí-lo, e caso seja necessário, denunciá-lo ao IBAMA
ou a polícia ambiental.
a) b) c)
50
Figura 14- Sprites de animação do madeireiro irregular
O madeireiro Irregular (figura 13) é contratado pelo fazendeiro irregular para desmatar
áreas de floresta nativa, o jogador deve conscientizá-lo e caso seja necessário, denunciá-lo ao
IBAMA.
Figura 15- Sprites de animação do Indio
51
O índio (figura 14) ainda não teve sua missão específica planejada, foi feito pra dar
suporte ao jogador em uma missão que poderia incluir sua cultura e os impactos dos impactos
ambientais causados pelo madeireiro e fazendeiro irregular em sua tribo.
Figura 16- Sprites de animação da Fiscal do IBAMA
A fiscal do IBAMA (figura 16) tem o objetivo de multar quem pratica atividades ilegais
no meio ambiente, nesse caso, o madeireiro e fazendeiro irregulares.
Os personagens foram desenhados a mão, escaneados e depois coloridos e editados no
GIMP, na engine2 Game Maker foi feito outros ajustes quanto a tamanho dos sprites e a
animação.
5.6 OS CENÁRIOS
O jogo Urihi é composto por três cenários: a área onde fica a casa do personagem
principal, o segundo cenário corresponde ao rio e por último uma área da floresta devastada.
Estes três cenários possuem fatores em comum, como a grama, o céu e as montanhas ao fundo,
além de alguns outros objetos que fazem a composição desses cenários.
5.7 O PROTÓTIPO
A missão do turista desleixado (figura 17) consiste em conscientizá-lo a não jogar lixo
no chão. E logo após, a missão do madeireiro irregular (figura 18), que tenta derrubar algumas
2 Biblioteca de funcionalidades que são disponibilizadas para facilitar o desenvolvimento de um jogo.
52
árvores, e para impedi-lo o personagem principal terá que dialogar com o madeireiro a fim de
conscientizá-lo, se o diálogo não for o bastante para cumprir a missão, terá que chamar a fiscal
do IBAMA para efetuar a prisão do madeireiro.
Figura 17- Conscientização do turista
Fonte: Jeter et al. (2012).
Figura 18- Evitando o desmatamento
E finalmente temos a presença do fazendeiro irregular que coloca fogo em uma área
para preparar o terreno para o plantio de pasto (figura 19). O fogo pode prejudicar o solo e
coloca em risco a floresta e agricultura local, ao perceber esse risco, o jogador deve controlar o
personagem principal fazendo-o dialogar com o fazendeiro na tentativa de conscientizá-lo, caso
não consiga, é chamado o fiscal do IBAMA para multar o fazendeiro. Terminado essa parte da
missão, o jogador deve apagar o fogo ou então chamar os bombeiros para apagar caso não
consiga.
53
Após o jogador completar todas as missões da versão do jogo, a criança poderá continuar
plantando árvores e realizar pescaria sustentável até atingir os 100% de consciência ambiental,
assim terminando o jogo.
Figura 19- Missão de evitar incêndio
Ainda existiam mais duas missões para a conclusão do jogo, sendo a missão da água e
a missão do fogo. A primeira trata de descrever sobre eventos baseados em preservação de
nascentes e de rios, e a segunda em evitar incêndios e desmatamento. Juntamente com os
membros do LCA, foram feitos o planejamento dessas missões.
A missão da água é composta por duas partes, uma no qual é preciso conscientizar o
mineiro de não desmatar a área ao redor da margem do rio devido o assoreamento, caso o
mineiro se conscientize, ele retira a draga que está no rio e a plantação volta a crescer e o jogador
ganha pontos por isso, caso não ocorra, é chamado o fiscal do IBAMA e que apreende o
mineiro, e o jogador fica responsável pela plantação de árvores e arbustos ao redor do rio, caso
ele falhe ele perde pontos.Como pode ser visto no digrama de atividades da figura 20.
54
Figura 20- Diagrama de atividades da primeira parte da missão da água
A segunda parte dessa missão tem o fazendeiro como antagonista, na qual animais são
colocados na beira do rio pisoteando e se alimentando da plantação, o jogador deve
conscientizar o fazendeiro a retirar os animais, caso consiga, o jogador retira e o jogador ganha
pontos, caso não, é construído uma cerca ao redor do rio e das plantas impedindo os animais de
passarem por cima das plantas, caso não seja feita, o jogador perde pontos. Como pode ser visto
no diagrama de atividades da figura 21.
55
Figura 21- Diagrama de atividades da segunda parte da missão da água
De acordo com o diagrama de atividades da figura 22, a missão do fogo tem como
personagens o fazendeiro, o fiscal do IBAMA e a polícia florestal, na missão o jogador precisa
evitar o incêndio, apagar e alertar o fazendeiro, caso ele não se conscientize e volta a fazer
queimada é alertado ao Fiscal do IBAMA, caso ele se conscientize o jogador ganha pontos, se
após o fiscal do IBAMA alertar o fazendeiro, ainda tem probabilidade das queimadas
56
continuarem, restando assim, o jogador a alertar a polícia florestal, que prende o fazendeiro
evitando a continuação das queimadas.
Figura 22- Diagrama de atividades da missão do fogo
57
Foi elaborado um artigo sobre o desenvolvimento do jogo Urihi, explicando mais a
fundo as suas funcionalidades e sobre os testes iniciais aplicados com o software, o artigo
intitulado “URIHI: JOGO PARA AUXILIAR A EDUCAÇÃO E PRESERVAÇÃO
AMBIENTAL NA AMAZÔNIA” foi publicado na revista Ponto de Partida, periódico e
publicação dissente da universidade federal do sul e sudeste do Pará, e em seguida foi
apresentado e publicado nos anais da sexta edição do Congresso Brasileiro e Extensão
Universitária (CBEU) ocorrido no ano de 2014.
58
6 TESTES E VALIDAÇÃO
Os testes executados foram os de sistema, no qual compõem-se por testes funcionais (ou
de caixa-preta) desempenho, aceitação e instalação, realizado com os integrantes do grupo
LCA.
O testes foram feitos em turmas de ensino fundamental considerando faixa etária de
crianças com 9 a 13 anos de idade, de acordo com o propósito do jogo. Neste caso, alunos do
4º ano do ensino fundamental.
6.1 AMBIENTE
O ambiente escolhido para a realização dos testes foi o laboratório de informática da
Escola Municipal de Ensino Fundamental Salomé Carvalho (figura 23), localizada no
município de Marabá, Estado do Pará. Tal laboratório, à época da pesquisa, era composto por
11 máquinas, com as seguintes configurações:
Quadro 1 – Computadores do laboratório e suas configurações
Fabricante Configuração
AOC Sistema Operacional: Linux Educacional 5.0
Memória: 1,7 RAM
Processador: Athlon Neo x2 Dual Core
Disco Rígido: 300GB
CCE Sistema Operacional: Linux Educacional 4.0
Memória: 1,5 RAM
Processador: Pentium Dual Core 3.20Ghz
Disco Rígido 300GB
Figura 23- Ambiente de testes- Laboratório de informática da escola Salomé Carvalho
Fonte: Dados da pesquisa
59
A versão 8.1 lite do Game Maker não tem suporte ao Linux, o software então foi
executado a versão do jogo para Windows em um emulador, o emulador utilizado foi o Wine.
As máquinas do laboratório utilizavam o Linux Educacional 5.0 que possui a versão 1.4 do
Wine. No momento de executar o jogo no emulador na escola tivemos problema com
redimensionamento da tela, porém o jogo foi executado sem problemas (figura 24).
Figura 24- Urihi emulado no Wine 1.4
Já as máquinas com Linux Educacional 4.0 possuíam a versão 1.2.2 do Wine, no qual o
jogo não executou com sucesso (figura 25), além do software perder elementos visuais, ele
travou várias vezes. Assim, necessitando de uma atualização do emulador para o jogo pudesse
ser executado com sucesso em todas as máquinas do laboratório.
60
Figura 25- Urihi emulado no Wine 1.2.2
6.2 ACEITAÇÃO
Foi desenvolvido um formulário com perguntas sobre o software (Apêndice A) em que
15 alunos da turma de terceiro ano do ensino fundamental eram instigados avaliar por uma hora
a funcionalidade do software. Tal formulário é composto por 7 questões, cada uma com opções
constituídas por uma escala zero a cinco que pretendiam indicar dos alunos a sua avaliação.
A partir dos resultados coletados foi calculada a média das respostas dadas. Tais
informações seriam utilizadas como feedback que nortearia futuras melhorias no software, a
serem novamente avaliados em futuros testes.
Porém, o resultado do teste feito com esse formulário não foi preciso, devido à
complexidade do questionário. Por ser direcionado a crianças do 4º ano, tais sujeitos tiveram
dificuldades de registraram informações que não condiziam com o teste realizado.
Devido a isso, foi elaborado outro questionário mais simples com uma linguagem mais
adequada ao público. Dentre as alterações, foram definidas apenas duas alternativas por
pergunta. Além disso, deixou-se um espaço para as crianças expressarem o que acharam do
jogo, como pode ser observado no Apêndice B.
O segundo questionário foi aplicado em uma turma de 4º ano de 16 alunos da mesma
escola, no dia 10 de Dezembro de 2014, tendo início às 16 horas e encerrando às 17 Horas.
61
Quanto a utilização do jogo, todas as crianças que avaliaram o jogo acharam-no de fácil
utilização. Também consideraram que o mesmo possui uma boa organização, incluindo os
desenhos e elementos distribuídos no jogo. Portanto, avaliaram o jogo como interessante.
Figura 26- Gráfico de dificuldade para jogar o Urihi
Observa-se claramente no Gráfico da figura 26 que 75% dos alunos afirmaram não ter
dificuldades para jogar, ao passo que apenas um quarto deles informaram o contrário. Em
relação a estes últimos, os principais fatores envolvidos dizem respeito aos textos cansativos e
alguns controles do jogo que utilizam teclas específicas do teclado e que confundiam algumas
crianças.
Figura 27- Gráfico de ocorrência de erros no jogo Urihi
De acordo com o gráfico acima (figura 27), mais de um quarto dos alunos tiveram algum
problema durante os testes devido erros ainda existentes nesta versão do jogo, seja na
25%
75%
Sim
Não
31%
69%
Sim
Não
62
jogabilidade do próprio jogo Urihi quanto problemas para executar o software no emulador em
alguns computadores.
6.3 VALIDAÇÃO
Durante o teste foi possível ver que apesar da simplicidade do jogo algumas crianças
tiveram pequenas dificuldades com alguns dos controles de teclado, e com pequenos erros que
ainda existiam, por exemplo: quando o personagem principal (“Joãozinho das Couves”) ficava
preso em algum elemento do cenário (como uma árvore, ou a casa), ou alguma mensagem do
sistema não aparecia devido o jogo estar sendo executado em emulador, precisando assim
reiniciar o jogo. Apesar desses pequenos problemas, todas as crianças conseguiram chegar até
o final do jogo. Esses dados, e as observações feitas durante os testes, foram úteis para fazer as
melhorias a versão final do jogo.
Foi observado durante os testes que as crianças não liam todos os comandos que eram
exibidos em mensagens escritas informado como realizar as atividades propostas no Jogo Urihi,
provavelmente por pressa ou pelos textos serem um pouco extensos, como mostra a figura 28.
Figura 28- Mensagem informativa da primeira missão do jogo Urihi
A figura 28 mostra os comandos da primeira missão. Nota-se também que neste texto
aparecem o verbete do termo “reciclar”, tornando o texto que deveria ser direto e simples para
algo mais complexo e cansativo para uma criança nesta faixa etária ler. Uma solução para isso
seria utilizar hyperlink na palavra “reciclar” que poderia mostrar em pop-up o seu significado.
Outra solução para esse problema seria adotar o uso de textos mais curtosou áudio. Isso
chamaria a atenção da criança e ajudaria a incluir ela na atmosfera lúdica do jogo Urihi.
63
Também seria viável por se contemplar os alunos de baixa visão, já que estes não precisariam
empregar altas doses de esforço para realizar a leitura dos textos escritos na tela do jogo da
versão atual. Seria viável ainda uma nova versão do jogo para este tipo de aluno.
Outra alternativa seria o trabalho pedagógico feito pelos professores no sentido de
estimular os alunos a desenvolver o hábito da leitura antes e/ou durante o jogo. Isto porque não
é incomum alunos dessa série não terem domínio das habilidades de leitura.
No decorrer do jogo, o jogador precisa interagir com os vários objetos. Para obter essa
interação, o jogador deve usar alguns botões do teclado que são informados durante as
instruções do jogo Urihi. Porém, o programador deve ser cauteloso nesse sentido, devem ser
atribuídos comandos intuitivos, que facilitariam o entendimento do funcionamento do jogo.
No jogo Urihi utiliza-se teclas pouco sugestivas em relação às ações para realizar as
atividades propostas.
Figura 29- Exemplo de comando pouco intuitivos
Outro problema observado, porém, durante a instalação do jogo, foi a incompatibilidade
com alguns computadores, devido ao software ter sido programado para Windows e não teve
uma versão para Linux. Uma solução para essa situação seria portar o jogo para outros sistemas
operacionais. A engine Game Maker versão 8.1 lite em que o software foi implementado possui
a opção de portar, porém essa opção é válida apenas na versão paga da engine e para a versão
educacional. Todavia, o processo para portar pode ocorrer erros com o código fonte do
64
software, implicando em grandes modificações. A solução mais viável então foi a atualização
do emulador nas máquinas para que todas pudessem executar a versão Windows compatível.
Um problema relatado durante os testes funcionais foi justamente a jogabilidade. O
personagem principal quando encostava em certos elementos do jogo (como por exemplo, a
casa, árvore ou a cerca no primeiro cenário) como apresentado na figura 30 abaixo, ele parava
e travava o jogo, impossibilitando a criança de prosseguir. A solução seria mudança no código
correspondente a estes elementos do jogo que causavam tais erros.
Figura 30- Personagem preso à casa do cenário da primeira missão
Apesar desses pequenos problemas identificados durante os testes, as crianças puderam
jogar até o final do jogo, no qual atendeu aos requisitos propostos inicialmente: um jogo
interativo com a função de auxiliar no aprendizado de alunos no ensino fundamental sobre
questões ambientais, da abordagem à reciclagem ao reflorestamento de árvores nativas da
região.
Levando em consideração que a validação é uma série de testes que avaliam se o
software atende ou não as exigências do usuário final, com os testes aplicados podemos definir
o jogo Urihi como um software válido no quesito de ser educativo.
7 CONSIDERAÇÕES FINAIS
Os testes de software têm um papel fundamental na área da engenharia de software, uma
forma de aproximar o desenvolvedor e o cliente, mantendo o produto final principal o mais fiel
65
possível da ideia inicial proposta pelo cliente. Assim, também podendo tornar o software mais
polido e melhor para seu usuário. Nesse trabalho foi demonstrado todo o ciclo que vai do
planejamento até a implantação do jogo Urihi na Escola....
Desde a primeira versão, o Urihi se manteve fiel à situações comuns ao bioma
amazônico, mostrando-os de forma lúdica. E a cada missão implementada mais personagens
tiveram que ser criados. As linhas de códigos também se tornaram mais complexas, dando
espaço a possíveis erros na execução, e pra prevenir que esses erros sejam visíveis na versão
definitiva do jogo, foram necessários a realização de testes de software. Os testes iniciais foram
realizados durante a produção do jogo e antes da escrita dessa monografia, muitos ja haviam
sido documentado no trabalho de Jeter (2012), restando apenas o testes de aceitação e a
validação para serem executados nesta monografia, coletando dados dos usuários finais e
aprimorando o jogo para propor um produto final fiel o máximo possível a ideia inicial e
suprindo a necessidade e a função educativa do jogo.
7.1 TRABALHOS FUTUROS
Finalizar o projeto em parceria com os professores da área de ciências e pedagogia. Os
primeiros poderão contribuir com questões específica do tema meio ambiente, ou seja, focar
em questões pontuais que considerem, dentro do ambiente escolar, mais importantes. Os
segundos, para auxiliarem na adaptação do jogo ao público infantil. Por outras palavras, tais
professores terão condições de informar dentre outras possibilidades a adaptação aos níveis de
aprendizagem do aluno, desenvolvimento cognitivo etc.
66
8 REFERÊNCIAS
ANDRADE, P. F. Modelo Brasileiro de Informática Na Educação. Disponível em:
<http://lsm.dei.uc.pt/ribie/docfiles/txt200352152252MODELO%20BRASILEIRO.pdf>.
Acesso em: 21/11/2013.
BARROS, M. S. Estudo de Usabilidade em Jogos Educativos 3d: Um Estudo de Caso. 15
de Junho de 2011. 58 f. Monografia (Bacharelado em Sistemas de Informação) - Universidade
Federal de Lavras, Lavras, Minas Gerais. 2011.
BRASIL. Um computador por aluno. 2008. Disponivel em:
<http://portal.mec.gov.br/index.php?option=com_content&task=view&id=11833>. Acesso
em: 20/01/2014.
CENI, Danielle et. al. Critérios para avaliação de softwares educativos. In: SEMINÁRIO
DE PESQUISA EM EDUCAÇÃO DA REGIÃO SUL, 9.,2012.Caxias do Sul. Anais...Caxias
do Sul: Universidade Federal de Caxias do Sul, 2012. Disponível em: <
http://www.ucs.br/etc/conferencias/index.php/anpedsul/9anpedsul/paper/viewFile/3327/906>.
Acesso em: 06/07/2014
CAMPOS, Jeter. URIHI Jogo para Auxiliar a Educação e Preservação Ambiental na
Amazônia. 2012. 108f. Trabalho de conclusão de curso (Bacharelado em Sistemas de
Informação) - Universidade Federal do Pará, Marabá, Pará. 2012.
DALMON, D. L. et. al. 2012. Uso de Métodos e Técnicas para Desenvolvimento de
Software Educacional em Universidades Brasileiras. Workshop de desafios da
computação aplicada à educação. 2012. Disponível em: < http://www.br-ie.org/pub/index.php/desafie/article/view/2794 >. Acesso em: 22/11/2013.
DELAMARO, M. E. et. al. Introdução ao Teste de Software. Rio de Janeiro: Elsevier,
2007. 394 p.
DIAS, A. C. Introdução a Teste de Software. Engenharia de software magazine. 2007.
Disponível em: <http://www.devmedia.com.br/esm> Acesso em: 13/11/2013.
FNDE - Fundo Nacional de Desenvolvimento da Educação. Programas. 2012. Disponível
em: <http://www.fnde.gov.br/programas/programa-nacional-de-tecnologia-educacional-
proinfo>. Acesso em: 23/11/2013.
GIMP. Disponivel em <http:// http://www.gimp.org/screenshots/> Acesso em: 15/05/2015
MACHADO, R. K. Aplicação da Engenharia da Usabilidade para o Desenvolvimento de
um Software Multimídia. 4 de Agosto de 2004. 95 f. Monografia (Bacharelado em Ciência
da Computação) Universidade Regional de Blumenau, Blumenau, 2004.
MARTINS, N. S.; et al. Software educacional: avaliação com foco no usuário. In:
CONGRESSO BRASILEIRO DE EXTENSÃO UNIVERSITÁRIA (CBEU), 4., 2009.
Dourados (MS). Anais… Dourados (MS), 2009
http://www.ucs.br/etc/conferencias/index.php/anpedsul/9anpedsul/paper/viewFile/3327/906%3e.%20Acesso
67
MATHIS, S. P. B. ESTUDO DE CASO DO USO DOS SOFTWARES EDUCACIONAIS
NA ESCOLA MUNICIPAL EÇA DE QUEIRÓS LUCAS DO RIO VERDE. 15 de Julho
de 2011. 59 f. Monografia (pós-graduação em Informática na Educação) Universidade Aberta
do Brasil - Cuiabá, 2011. Disponível em:
<http://www.ic.ufmt.br:8080/c/documentlibrary/get_file?p_l_id=58070&folde
rId=60483&name=DLFE-2363.pdf> Acesso em: 23/11/2013.
MEC - Ministério da Educação. Programas e Ações. Disponível em: <http://
portal.mec.gov.br/index.php?Itemid=823&id=244&option=comcontent&view=article>.
Acesso em: 22/11/2013.
MILANI, André. GIMP Guia do Usuário. 2008. Disponível em:
<https://novatec.com.br/livros/gimp/capitulo9788575221716.pdf>. Acesso em: 14/06/15
MORAES, M. C. Informática educativa no Brasil: uma história vivida, algumas lições
aprendidas. Revista Brasileira de Informática na Educação. Florianópolis, n. 1, set. 1997.
Disponível em: <http://www.inf.ufsc.br/sbc- ie/revista/nr1/mariacandida.html>Acesso em:
01/08/2014.
MORAIS, R. X. T. Software Educacional: A Importância de sua Avaliação e do Seu Uso
nas Salas de Aula. 52p. Trabalho de Conclusão de Curso (Ciência da Computação),
Faculdade Lourenço Filho. Fortaleza, 2003.
MORATORI, P.B. Por que utilizar jogos educativos no processo de ensino aprendizagem?
.2003. 33f. Trabalho conclusão disciplina (Mestrado de Informática aplicado a educação) -
Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2003.
MYERS, G. The art of software testing. 1. ed. John Wiley and Sons, 1979. 11, 15.
OMORI, M. T. Efetividade nos jogos educativos. 2010. 37 p. Trabalho de Conclusão de
Curso (Graduação em Ciência da Computação) – Universidade Estadual de Londrina,
Londrina, 2010.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo, Prentice
Hall, 2004.
PRESSMAN. R.S. Engenharia de Software. 7ed. São Paulo: McGraw-Hill, 2011.
RODRIGUES, L. S. O uso de software educacional no ensino fundamental de
matemática e a aprendizagem do sistema de numeração decimal por alunos de 3ª série.
Campo Grande, 2006. 175 f. Dissertação (Mestrado em Educação)- Universidade Católica
Dom Bosco. 2006
SANTOS, C., VALE, F. Jogos eletrônicos na educação: um estudo da proposta dos jogos
estratégicos. Universidade Federal de Sergipe, São Cristóvão – SE, Outubro de 2006.
SANTOS, F. M. Avaliação de Software Educativo: Reflexões para uma Análise
Criteriosa. 2011. Disponível em:
<http://www.educacaopublica.rj.gov.br/biblioteca/tecnologia/0001.html>. Acesso em:
09/12/2013.
68
SILVA, Renata. M. A. A importância dos Testes de Qualidade no desenvolvimento de
Software. In Workshop inovação e empreendedorismo.2012. Anais... Faculdade de tecnologia
e ciências. Feira de Santana- Bahia. 2012. Disponível em: < http://portal.ftc.br/eventos/wie/2012/p-trabalhos.php >. Acesso em: 13/11/2013.
SILVEIRA. S. R. Estudo de uma Ferramenta de Autoria Multimídia para a Elaboração
de Jogos Educativos. 1999. Dissertação (Mestrado em Computação) Universidade Federal
do Rio Grande do Sul. Porto Alegre, 1999. Disponível em:
<http://www.lume.ufrgs.br/handle/10183/26551>. Acesso em: 21/11/2013.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. São Paulo: Pearson, 2007.
TAVARES, N. R. B. História da informática educacional no Brasil observada a partir de
três projetos públicos. Disponível em: <http://www.lapeq.fe.usp.br/textos/tics/tics
pdf/neide.pdf> Acesso em 16/03/14.
VALENTE, J. A. O computador na sociedade do conhecimento. Campinas, São Paulo,
1999.
VALENTE, J. A. 1989. QUESTÃO DO SOFTWARE: parâmetros para o
desenvolvimento de software educativo. Disponível em:
<http://www.nied.unicamp.br/ojs/index.php/memos/article/view/79/78>. Acesso em:
20/11/2013.
VALIATI, E. R. A. et. al. Avaliação de Interfaces em Software Educacional:
Comparando Experiências em dois Protótipos Sucessivos. Disponível em <
http://www.geocities.ws/djluckyf/paper146.pdf>. Acesso em 01/08/2014.
VITÓRIA, et. al. 2013. USO DOS JOGOS EDUCATIVOS COMO ENSINO DE
APRENDIZAGEM NA ESCOLA. In Simpósio de excelência em gestão e tecnologia. 10.
2013.Resende (RJ) Anais...Resende (RJ), 2013. Disponível em: < www.aedb.br/seget/arquivos/artigos13/29018401.pdf >
69
APÊNDICE A – PRIMEIRO QUESTIONÁRIO PARA AVALIAÇÃO DO JOGO
EDUCATIVO
70
APÊNDICE B – SEGUNDO QUESTIONÁRIO, MAIS SIMPLIFICADO PARA
AVALIAÇÃO DO JOGO EDUCATIVO
