Metodologia - Aval de Qualidade - Soft

Ana Paula Ribeiro Atayde
Orientador: Clarindo Isaías Pereira da Silva e Pádua

Co-orientadora: Adla Betsaida Martins Teixeira
Metodologia de Avaliação de Qualidade de

Software Educacional Infantil - MAQSEI
Dissertação apresentada ao Curso de Pós-

Graduação em Ciência da Computação da
Universidade Federal de Minas Gerais, como
requisito parcial para a obtenção do grau de
Mestre em Ciência da Computação.
Belo Horizonte
11 de julho de 2003
i
AGRADECIMENTOS
Agradeço imensamente a todos os que, com palavras, gestos e ações,

colaboraram durante o desenvolvimento deste trabalho, em especial:
Ao meu orientador, Clarindo Isaías Pereira da Silva e Pádua, pelo

atendimento, pelo acompanhamento e pela condução, mas, principalmente, pela
oportunidade e por acreditar e confiar no meu trabalho;
À minha co-orientadora, Adla Betsaida Martins Teixeira, pelas indicações de

caminhos a serem seguidos na área de educação, por recomendações em
congressos e seminários, pelo ingresso em algumas escolas e, em especial, pela
confiança, pela atenção e pela amizade;
Aos também membros da banca, Antônio Otávio Fernandes, pelo

acompanhamento e pelas contribuições, e Heitor Garcia Carvalho, pelos conselhos
para o trabalho;
A todas as crianças que participaram dos testes e aos pais, que as

autorizaram;
Às instituições Magnum Agostiniano, Rede Coleguium de Ensino, Hilda

Rabello Matta, Arthur Versiane e Caio Líbano, que permitiram minha entrada e a
condução da pesquisa, em especial a todos os funcionários e docentes dessas
escolas que participaram da pesquisa;
Ao grupo de estudos de Usabilidade Gestus, em especial a Daniel Freitas (e

Maria Tereza Diniz), pela ajuda no contato com escolas, Marina Oliveira, por ter
trazido algumas crianças para testes, e Bernardo Pádua, pelo acompanhamento e
pela preparação do equipamento dos testes realizados;
A Henderson V. Oliveira, que contribuiu, por meio da utilização da

metodologia durante o desenvolvimento de um software educacional infantil;
A todos os meus colegas do DCC, entre eles Adriano César, Benício Gontijo,
Bruno Diniz, Diego Nogueira, Guilherme Rocha, Luciana Avelar, Marcelo Werneck,
Rainer Couto e Rodrigo Vieira, pelas conversas e pelo apoio e, em especial, para
ii
minhas amigas Renata Carvalho, por toda a cumplicidade, pela força e pelo carinho,
e Mirian Rubinstein, que, mesmo de longe, esteve presente.
À Litany França Diniz, pela amizade eterna;
Aos novos amigos Flávia, Xú (Cíntia), Hérica, Alê, Paula Amorim e Léo
Viegas.
A todos os meus colegas de trabalho do DCC, em especial a Claúdia, Cida,

Gustavo, Lurdinha, Sheila, Sônia, Stella. A Emília e Renata, pelo atendimento
especial e, principalmente, a Luciana Bicalho e Valéria Paiva, pelo enorme carinho e
ajuda;
A Antônio Mendes, pelos auxílios e compreensões no trabalho;
Aos meus familiares, em especial à minha prima Ana Elisa Ribeiro, pela
revisão de minha dissertação;
À Luana, pelo companheirismo e pelo carinho em todos os momentos;
A Vitor Dantas de Andrade, por toda a compreensão e pela paciência, pelas

esperas, pelos telefonemas e palavras confortantes, pelos estímulos e ajudas, pela
segurança transmitida, mas, principalmente, pelo amor nos momentos mais difíceis.
Muito obrigada!
Aos meus queridos pais José João Atayde e Maria Alice Ribeiro, pelo apoio e
pela ajuda, pelo carinho, pela tolerância, pelos exemplos e ensinamentos, mas,
principalmente, pelo amor incondicional. Amo vocês!
A Deus, que iluminou meu caminho e que colocou todas essas pessoas
especiais em minha vida.
Mais uma vez, obrigada a todos!
iii
RESUMO
Este trabalho apresenta uma Metodologia para Avaliação da Qualidade de

Software Educacional Infantil, denominada MAQSEI, e as heurísticas técnicas e
pedagógicas que a fundamentam. O estudo envolveu conhecimentos em educação
e Engenharia de Usabilidade, que orientaram e forneceram parâmetros
metodológicos visando a melhoria de processos de avaliação de software
educacional infantil. A metodologia e as heurísticas foram validadas por meio de
testes com programas didáticos infantis prontos e em desenvolvimento, em um
processo evolutivo, ajustando-as a cada teste. Elas podem ser utilizadas em
avaliações formativas, colaborando para que o desenvolvedor descubra defeitos e
modificações necessárias no programa, ou em avaliações somativas, com
ferramenta de apoio a escolas, pais ou interessados na escolha do software
educacional infantil a ser utilizado pelas crianças.
Palavras-chave: Metodologia, avaliação, qualidade, avaliador, usabilidade, objetivos

pedagógicos, condutor, software educacional infantil.
iv
ABSTRACT
This study presents a methodology for quality evaluation of children’s

educational software and the heuristics that support it. The work involved a survey of
the literature in Usability and pedagogical studies that guided and gave
methodological foundation to improve the process of quality evaluation of children’s
educational software. The methodology and the heuristics were validated through
tests with children’s didactic programs and through the development of a software
product of the same type. The development of them were carried out gradually,
elaborating, revising and making improvements as they were used. The methodology
and the heuristics can be used in formative evaluations, helping designers to find out
problems and necessary modifications in the program, or in summative evaluations,
as a support tool for schools, parents or anyone interested in choosing educational
software for their children.
Key words: methodology, quality, evaluation, evaluator, Usability, pedagogical

objectives, test monitor, children’s educational software.
v
LISTA DE FIGURAS
FIGURA 1 − EXEMPLO DE AVALIAÇÃO EM PAPEL .............................................................................................................22

FIGURA 2 – M ODELO DE AVALIAÇÃO DE SOFTWARE PROPOSTO POR CAMPOS, 1994........................................36
FIGURA 3 − ESTRUTURA DA ETAPA DE AVALIAÇÃO DE GAMEZ, 1998 .....................................................................38
FIGURA 4 – D IAGRAMA DOS PASSOS SEGUIDOS DURANTE O DESENVOLVIMENTO DA MAQSEI..........................42
FIGURA 5 − D EFINIÇÃO DA FASE DE R ECONHECIMENTO E P ROPOSTA DE AVALIAÇÃO DO SOFTWARE...............54
FIGURA 6 − D EFINIÇÃO DA FASE DE PLANEJAMENTO DOS TESTES ............................................................................55
FIGURA 7 − D EFINIÇÃO DA FASE DE R EALIZAÇAO DOS TESTES ..................................................................................56
FIGURA 8 − D EFINIÇÃO DA FASE DE A NÁLISE DE DADOS E PRODUÇÃO DO R ELATÓRIO FINAL DE AVALIAÇÃO.57
FIGURA 9 − D IAGRAMA DE FASES E ARTEFATOS ............................................................................................................59
FIGURA 10 − PROCESSO DE DESENVOLVIMENTO DA METODOLOGIA .........................................................................64
FIGURA 11 − OS QUATRO TIPOS DE PROCESSO .............................................................................................................66
FIGURA 12 − EXEMPLO DE INTERFACES ...........................................................................................................................73
FIGURA 13 − EXEMPLO DE FORMULÁRIO DE CONSENTIMENTO ...................................................................................84
FIGURA 14 − EXEMPLO DE SCRIPT DE ORIENTAÇÃO.....................................................................................................86
FIGURA 15 − EXEMPLO DE ENTREVISTA COM CRIANÇAS..............................................................................................88
FIGURA 16 − EXEMPLO DE PRÉ E P ÓS- TESTES .............................................................................................................90
FIGURA 17 − EXEMPLO DE FORMULÁRIO DE OBSERVAÇÃO.........................................................................................93
FIGURA 18 − EXEMPLO DE FORMULÁRIO DE Q UESTIONÁRIO COM CRIA NÇAS..........................................................96
FIGURA 19 −AMBIENTE DE TESTE DE SOFTWARE........................................................................................................ 100
FIGURA 20 − FOTO DE AMBIENTE DE TESTE REALIZADO EM ES COLA ...................................................................... 101
FIGURA 21 − LABORATÓRIO DE U SABILIDADE.............................................................................................................. 102
FIGURA 22 − EXEMPLO DE ANÁLISE QUALITATIVA DE ASPECTOS TÉCNICOS E PEDAGÓGICOS .......................... 119
FIGURA 23 − EXEMPLO DE GRÁFICO DE CONFORMIDADE DE SOFTWARE COM CRITÉRIOS DE AVALIAÇÃO...... 122
FIGURA 24 − BOTÃO PARA A SAÍDA NÃ O APARECE DURANTE O JOGO. ................................................................... 136
FIGURA 25 − AS FIGURAS DE MORCEGOS QUE APARECEM EM CIMA DA TELA DO JOGO REPRESENTAM O
NÚMERO DE TEXTOS DO JOGO. MAS EM TODOS OS TESTES REALIZADOS, CRIANÇAS DISSERAM SER “VIDAS”
DO JOGO, OU SEJA , NÚMERO DE VEZES EM QUE SE PODERIA ERRAR. ISSO DEVIDO À ASSOCIAÇÃO COM
OUTROS PROGRAMAS EXISTENTES , EM QUE “VIDAS” SÃO REPRESENTADAS DA MESMA FORMA ................. 144
FIGURA 26 − JOGO DOMINÓ............................................................................................................................................ 158
FIGURA 27 − SOFTWARE FIGURAS GEOMÉTRICAS II ................................................................................................. 159
FIGURA 28 − JOGO DO SOFTWARE DOMINÓ DOS N ÚMEROS .................................................................................... 159
FIGURA 29 − S EGUNDO JOGO DO SOFTWARE DOMINÓ DOS NÚMEROS................................................................. 160
FIGURA 30 − TERCEIRO JOGO DO SOFTWARE DOMINÓ DOS NÚMEROS................................................................. 160
FIGURA 31 − JOGO DA TABUADA .................................................................................................................................... 170
FIGURA 32 − JOGO Q UEBRA -C UCA ............................................................................................................................... 171
FIGURA 33 − JOGO NÚMERO S ECRETO ........................................................................................................................ 171
FIGURA 34 − JOGO Q UADRADO MÁGICO ...................................................................................................................... 172
FÌGURA 35 − JOGO X CH ................................................................................................................................................. 172
FIGURA 36 − JOGO B INGO ............................................................................................................................................... 173
FIGURA 37 − JOGO JG...................................................................................................................................................... 173
FIGURA 38 − JOGO HOMÔNIMOS E PARÔNIMOS .......................................................................................................... 174
FIGURA 39 − JOGO C Ç SS ............................................................................................................................................... 174
FIGURA 40 − JOGO C Ç S SS SC XC ................................................................................................................................ 175
FIGURA 41 − JOGO S X Z .................................................................................................................................................. 175
FIGURA 42 − INTERFACES DO SOFTWARE ODONTO MANIA ....................................................................................... 187
vi
SUMÁRIO
1. INTRODUÇÃO ...............................................................................................................1
1.1. OBJETIVOS DO TRABALHO ......................................................................................................................................1

1.2. JUSTIFICATIVA...........................................................................................................................................................1
1.3. VISÃO GERAL DA PESQUISA ....................................................................................................................................3
1.4. CAPÍTULOS .................................................................................................................................................................6
2. REVISÃO DA LITERATURA.......................................................................................7
2.1. TECNOLOGIA E EDUCAÇÃO ....................................................................................................................................7

2.2. INFORMÁTICA NA EDUCAÇÃO.................................................................................................................................8
2.2.1. A INTEGRAÇÃO DA INFORMÁTICA NA ESTRUTURA CURRICULAR.................................................................9
2.2.2. O(A ) DOCENTE – SUAS CRENÇAS E SEU PAPEL ...........................................................................................10
2.2.3. CONTEXTO APOIADOR ......................................................................................................................................12
2.2.4. TRABALHO EM LONGO PRA ZO..........................................................................................................................13
2.3. A INFORMÁTICA NA EDUCAÇÃO NO BRASIL .......................................................................................................14
2.4. O SOFTWARE EDUCACIONAL................................................................................................................................15
2.5. QUALIDADE DE PRODUTOS ...................................................................................................................................18
2.6. ENGENHARIA DE SOFTWARE................................................................................................................................19
2.7. A ENGENHARIA DE USABILIDADE ........................................................................................................................20
2.7.1. R EGRAS E P RINCÍPIOS ( HEURÍSTICAS)..........................................................................................................24
2.7.2. A ENGENHARIA DE USABILIDADE APLICADA A SOFTWARE EDUCACIONAL INFANTIL .............................27
2.7.3. PROPOSTAS DE ANÁLISE DE U SABILIDADE PARA O DESENVOLVIMENTO DE SOFTWARE
EDUCACIONAL OU INFANTIL ................................................................................................................................................27
2.7.4. AVALIAÇÕES DE QUALIDA DE DE SOFTWARE EDUCACIONAL ......................................................................35
3. DEFINIÇÃO DA METODOLOGIA ........................................................................... 41
3.1. INTRODUÇÃO ...........................................................................................................................................................41

3.2. D EFINIÇÃO E PASSOS DO PROCESSO .................................................................................................................41
3.2.1. D ETERMINAÇÃO DOS ATRIBUTOS DO PRODUTO ..........................................................................................43
3.2.2. D EFINIÇÃO DOS ATRIBUTOS DO PROCESSO .................................................................................................46
3.2.3. D ETERMINAÇÃO DAS TAREFAS E TÉCNICAS DO PROCESSO ......................................................................48
3.2.4. D EFINIÇÃO DAS METAS E DOS CRITÉRIOS DE QUALIDADE DO PROCESSO..............................................49
3.2.5. CARACTERIZAÇÃO DO PROCESSO..................................................................................................................50
3.2.6. ESTRUTURAÇÃO DO PROCESSO .....................................................................................................................51
3.2.7. D EFINIÇÃO DAS FASES DO PROCESSO ..........................................................................................................53
3.2.8. PRODUÇÃO DOS ARTEFATOS ..........................................................................................................................58
3.2.9. VALIDAÇÃO DO PROCESSO ..............................................................................................................................59
3.2.9.1. VALIDAÇÃO DA MAQSEI EM AVALIAÇÕES DE SO FTWARE EDUCACIONAL INFANTIL.........................60
3.2.9.2. VALIDAÇÃO DA MAQSEI DURANTE O DESENVOLVIMENTO DE SOFTWARE EDUCACIONAL INFANTIL
..........................................................................................................................................................................62
3.3. CONSIDERAÇÕES SOBRE O DESENVOLVIMENTO DO PROCESSO ..................................................................63
3.3.1. PROCESSO EVOLUTIVO.....................................................................................................................................63
3.3.2. PERCEPÇÕES POSSÍVEIS DO PROCESSO ......................................................................................................65
4. DESCRIÇÃO DA MAQSEI........................................................................................ 67
4.1. INTRODUÇÃO ...........................................................................................................................................................67

4.2. FASES DA MAQSEI...............................................................................................................................................67
4.2.1. FASE DE R ECONHECIMENTO E PROPOSTA DE AVALIAÇÃO DO SOFTWARE............................................67
4.2.1.1. FORMATO SUGERIDO PARA DOCUMENTO DE RECONHECIMENTO DO SOFTWARE............................68
4.2.1.2. FORMATO SUGERIDO PARA DOCUMENTO DE PROPOSTA DE AVALIAÇÃO DO SOFTWARE...............74
4.2.2. FASE DE PLANEJAMENTO DOS TESTES .........................................................................................................75
4.2.2.1. PERSONALIZAÇÃO DA MAQSEI.................................................................................................................76
4.2.2.2. PREPARAÇÃO DO PLANO DE TESTES ........................................................................................................76
4.2.2.2.1. FORMATO SUGERIDO PARA O DOCUMENTO DO PLANO DE TESTES ................................................77
vii
4.2.2.3. PREPARAÇÃO DE FORMULÁRIO DE CONSENTIMENTO............................................................................83
4.2.2.4. PREPARAÇÃO DE SCRIPT DE ORIENTAÇÃO .............................................................................................85
4.2.2.5. PREPARAÇÃO DE ENTREVISTA COM CRIANÇAS (PRÉ-TESTE) ..............................................................86
4.2.2.6. PREPARAÇÃO DE PRÉ E PÓS-TESTES ......................................................................................................89
4.2.2.7. PREPARAÇÃO DE FORMULÁRIO DE OBSERVAÇÃO ..................................................................................91
4.2.2.7.1. FORMATO SUGERIDO PARA FORMULÁRIO DE OBSERVAÇÃO ............................................................92
4.2.2.8. PREPARAÇÃO DO QUESTIONÁRIO COM CRIANÇAS .................................................................................94
4.2.2.8.1. FORMATO SUGERIDO PARA QUESTIONÁRIO COM CRIANÇAS ...........................................................94
4.2.2.9. PREPARAÇÃO DE LISTA DE VERIFICAÇÃO.................................................................................................97
4.2.2.10. SELEÇÃO DE CRIANÇAS ...........................................................................................................................97
4.2.2.11. PREPARAÇÃO DO AMBIENTE, EQUIPAMENTOS E MATERIAIS.............................................................99
4.2.2.11.1. AMBIENTE E EQUIPAMENTOS ..................................................................................................................99
4.2.2.11.2. MATERIAIS ............................................................................................................................................... 102
4.2.2.12. REALIZAÇÃO DE TESTES DE TODOS OS ITENS.................................................................................. 102
4.2.3. FASE DE R EALIZAÇÃO DOS TESTES ............................................................................................................ 103
4.2.3.1. PREPARAÇÃO DO AMBIENTE E DOS OBSERVADORES.......................................................................... 104
4.2.3.2. CUMPRIMENTOS E APRESENTAÇÃO ........................................................................................................ 104
4.2.3.3. RECOLHIMENTO DOS FORMULÁRIOS DE CONSENTIMENTO................................................................ 105
4.2.3.4. TRANSMISSÃO DAS INFORMAÇÕES CONTIDAS NO SCRIPT DE ORIENTAÇÃO .................................. 105
4.2.3.5. CONDUÇÃO DAS PERGUNTAS DA ENTREVISTA COM CRIANÇAS........................................................ 105
4.2.3.6. APLICAÇÃO DO PRÉ-TESTE...................................................................................................................... 105
4.2.3.7. CONDUÇÃO DO TESTE............................................................................................................................... 106
4.2.3.8. REALIZAÇÃO DO PÓS-TESTE.................................................................................................................... 106
4.2.3.9. CONDUÇÃO DAS PERGUNTAS DO QUESTIONÁRIO COM CRIANÇAS................................................... 107
4.2.3.10. AGRADECIMENTO E GRATIFICAÇÃO .................................................................................................... 107
4.2.3.11. ORGANIZAÇÃO DE PAPÉIS COLETADOS............................................................................................. 107
4.2.3.12. REALIZAÇÃO DE ACERTOS NO TESTE................................................................................................. 107
4.2.4. FASE DE A NÁLISE DOS DADOS E P RODUÇÃO DO R ELATÓRIO FINAL DE AVALIAÇÃO......................... 108
4.2.4.1. OBSERVAÇÃO E ANÁLISE DAS FILMAGENS............................................................................................. 108
4.2.4.2. TRANSCREVER E RESUMIR OS DADOS................................................................................................... 108
4.2.4.2.1. FORMATO SUGERIDO PARA DOCUMENTO DE RESUMO DOS DADOS............................................ 109
4.2.4.3. PRODUÇÃO DO RELATÓRIO FINAL DE AVALIAÇÃO ................................................................................ 114
4.2.4.3.1. FORMATO SUGERIDO PARA RELATÓRIO FINAL DE AVALIAÇÃO...................................................... 115
4.3. CUSTO DA AVALIAÇÃO........................................................................................................................................ 123
4.4. CONCLUSÃO DO CAPÍTULO ................................................................................................................................ 126
5. HEURÍSTICAS ..........................................................................................................128
5.1. INTRODUÇÃO ........................................................................................................................................................ 128

5.2. D ESCRIÇÃO DAS HEURÍSTICAS ......................................................................................................................... 129
5.2.1. PERTINÊNCIA EM RELAÇÃ O A UMA PROPOSTA PEDAGÓGICA ................................................................. 129
5.2.2. UTILIZAÇÃO DE RECURSOS COMPUTACIONAIS .......................................................................................... 129
5.2.3. AVALIAÇÃO DA APRENDIZAGEM .................................................................................................................... 130
5.2.4. INTERAÇÃO....................................................................................................................................................... 130
5.2.4.1. RECONHECIMENTO NO LUGAR DE MEMORIZAÇÃO ............................................................................... 131
5.2.4.2. QUALIDADE DAS OPÇÕES DE AJUDA ....................................................................................................... 131
5.2.4.3. LEGIBILIDADE............................................................................................................................................... 132
5.2.4.4. FEEDBACK.................................................................................................................................................... 132
5.2.4.5. AGRUPAMENTO E DISTINÇÃO DE ITENS.................................................................................................. 133
5.2.5. ADAPTABILIDADE............................................................................................................................................. 133
5.2.5.1. FLEXIBILIDADE............................................................................................................................................. 133
5.2.5.2. NÍVEL DE EXPERIÊNCIA COM O SOFTWARE OU COM COMPUTADORES ............................................ 134
5.2.5.3. AMBIENTE COOPERATIVO ......................................................................................................................... 134
5.2.6. CONTROLE E AUTONOMIA DO USUÁRIO ...................................................................................................... 135
5.2.6.1. ACESSO ........................................................................................................................................................ 135
5.2.6.2. SAÍDA ............................................................................................................................................................ 135
5.2.6.3. PAUSA ........................................................................................................................................................... 136
5.2.6.4. DESFAZER UMA AÇÃO ................................................................................................................................ 136
5.2.7. R ECURSOS MOTIVACIONAIS .......................................................................................................................... 136
viii
5.2.8. GESTÃO DE ERROS ......................................................................................................................................... 138
5.2.8.1. PREVENÇÃO DE ERROS............................................................................................................................. 138
5.2.8.2. AUXÍLIO NO RECONHECIMENTO, NO DIAGNÓSTICO E NA RECUPERAÇÃO DE ERROS .................... 139
5.2.9. CARGA DE TRABALHO .................................................................................................................................... 139
5.2.9.1. CARGA INFORMACIONAL ........................................................................................................................... 140
5.2.9.2. BREVIDADE .................................................................................................................................................. 140
5.2.10. CONTEÚDO .................................................................................................................................................. 140
5.2.11. SIGNIFICADO DE CÓDIGOS E DENOMINAÇÕES ...................................................................................... 142
5.2.12. CONSISTÊNCIA E PADRÕES ...................................................................................................................... 142
5.2.13. CORRESPONDÊNCIA ENTRE O SOFTWARE E O MUNDO REAL............................................................. 143
5.2.13.1. CORRESPONDÊNCIA COM OUTROS PROGRAMAS SIMILARES ........................................................ 143
5.2.14. DOCUMENTAÇÃO........................................................................................................................................ 144
5.2.14.1. DOCUMENTAÇÃO DE DESCRIÇÃO DO PRODUTO (PARA DOCENTES/PAIS)................................... 145
5.2.14.2. DOCUMENTAÇÃO DE USO DO SOFTWARE.......................................................................................... 145
5.2.14.3. DOCUMENTAÇÃO DE USO DO SOFTWARE DIRECIONADA A DOCENTES/PAIS (INSTALAÇÃO,
REGRAS E ASPECTOS PEDAGÓGICOS).......................................................................................................................... 146
5.2.14.4. DOCUMENTAÇÃO DE USO DO SOFTWARE DIRECIONADA A CRIANÇAS (REGRAS)...................... 146
5.3. CONCL USÃO DO CAPÍTULO ................................................................................................................................ 147
6. REALIZANDO A AVALIAÇÃO DE SOFTWARE EDUCACIONA INFANTIL – O

PAPEL DO AVALIADOR ..................................................................................................149
6.1. INTRODUÇÃO ........................................................................................................................................................ 149

6.2. O AVALIADOR........................................................................................................................................................ 149
6.2.1. R ECOMENDAÇÕES PARA A CONDUTA DURANTE OS TESTES .................................................................. 150
6.2.2. R ECOMENDAÇÕES PARA O PERFIL DO AVALIADOR .................................................................................. 153
6.2.3. R ECOMENDAÇÕES PARA MELHORAR AS HABILIDADES DO AVALIADOR/CONDUTOR .......................... 155
7. A EXPERIÊNCIA DE AVALIAÇÃO.......................................................................157
7.1. INTRODUÇÃO ........................................................................................................................................................ 157

7.2. INSTITUIÇÕES DE ENSINO E PROGRAMAS EDUCACIONAIS INFANTIS AVALIADOS..................................... 157
7.2.1. R EDE COLEGUIUM DE ENSINO..................................................................................................................... 157
7.2.1.1. PROGRAMAS AVALIADOS NA REDE COLEGUIUM DE ENSINO............................................................. 158
7.2.1.2. AVALIAÇÃO DOS PROGRAMAS EDUCACIONAIS INFANTIS UTILIZADOS NA REDE COLEGUIUM DE
ENSINO 160
7.2.1.3. PROPOSTAS DE MELHORIAS NA MAQSEI............................................................................................. 168
7.2.2. COLÉGIO MAGNUM A GOSTINIANO ............................................................................................................... 169
7.2.2.1. PROGRAMAS AVALIADOS DO COLÉGIO MAGNUM AGOSTINIANO...................................................... 169
7.2.2.2. AVALIAÇÃO DOS PROGRAMAS DO COLÉGIO MAGNUM AGOSTINIANO .............................................. 176
7.2.2.3. PROPOSTAS DE MELHORIAS NA MAQSEI ............................................................................................ 184
7.2.3. ESCOLA MUNICIPAL H ILDA RABELLO MATTA ............................................................................................ 184
7.3. VALIDAÇÃO DA MAQSEI DURANTE O DESENVOLVIMENTO DE UM SOFTWARE EDUCACIONAL INFANTIL
186
7.3.1. AVALIAÇÕES DO SOFTWARE ODONTOMANIA............................................................................................ 188
7.3.2. OBSERVAÇÕES E PROPOSTAS DE MELHORIA NA MAQSEI ................................................................... 188
8. CONCLUSÕES.........................................................................................................190
8.1. D ISCUSSÕES SOBRE A MAQSEI ..................................................................................................................... 190

8.2. D ISCUSSÕES SOBRE A INFORMÁTICA NA EDUCAÇÃ O ................................................................................... 191
8.3. CONTRIBUIÇÕES DO TRABALHO........................................................................................................................ 192
8.4. PERSPECTIVAS DE TRABALHOS FUTUROS...................................................................................................... 194
9. REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................195
ix
ANEXOS ..............................................................................................................203
ANEXO I: PADRÃO PARA DOCUMENTO DE RECONHECIMENTO DO

SOFTWARE ..............................................................................................................203
ANEXO II: PADRÃO PARA DOCUMENTO DE PROPOSTA DE AVALIAÇÃO DE

SOFTWARE ..............................................................................................................205
PROPOSTA DE AVALIAÇÃO DO SOFTWARE <NOME DO SOFTWARE>.........206
ANEXO III: PADRÃO PARA DOCUMENTO DE PLANO DE TESTES....................207
ANEXO III: PADRÃO PARA DOCUMENTO DE PLANO DE TESTES....................207
ANEXO IV: PADRÃO PARA DOCUMENTO DE PRÉ-TESTE E PÓS-TESTE.......210
ANEXO V: PADRÃO PARA FORMULÁRIO DE OBSERVAÇÃO ............................211
ANEXO VI: PADRÃO PARA QUESTIONÁRIO COM CRIANÇAS ...........................212
ANEXO VII: PADRÃO PARA DOCUMENTO DE RESUMO DE DADOS ................214
ANEXO VIII: PADRÃO PARA DOCUMENTO DE RELATÓRIO FINAL DE

AVALIAÇÃO DE SOFTWARE EDUCACIONAL INFANTIL.......................................215
ANEXO IX: ENTREVISTA COM DOCENTES...............................................................229
ANEXO X: FASES..............................................................................................................234
ANEXO XI : TAREFAS ......................................................................................................235
ANEXO XII: ARTEFATOS ................................................................................................236
ANEXO XIII: RELAÇÃO ENTRE FASES, TAREFAS E ARTEFATOS UTILIZADOS

OU PRODUZIDOS..............................................................................................................237
ANEXO XIV: HEURÍSTICAS............................................................................................238
x
1. INTRODUÇÃO
1.1. Objetivos do trabalho
O objetivo principal deste trabalho é elaborar uma Metodologia de Avaliação

de Qualidade de Software Educacional Infantil, denominada MAQSEI, que seja
fundamentada em um conjunto de heurísticas que abranja os aspectos pedagógico e
técnico do programa. A MAQSEI pode ser aplicada em programas educacionais
infantis prontos, orientando escolas ou pais interessados na escolha dos programas
a serem usados com suas crianças, ou em programas educacionais infantis em
desenvolvimento, ajudando desenvolvedores a descobrir defeitos e modificações
necessárias no programa durante sua produção.
Também são objetivos deste trabalho:
§ A apresentação de padrões para a metodologia que orientem e concorram para a

qualidade da avaliação;
§ Produção das heurísticas pedagógicas e de Usabilidade para o desenvolvedor ou

avaliador de software educacional infantil;
§ Consideração do custo da avaliação de um software educacional infantil;
§ Produção de recomendações de conduta, perfil e habilidades necessárias para

um avaliador de software educacional infantil.
Todos esses objetivos convergem para o desejo comum de que a informática

continue auxiliando a educação, cada vez mais eficientemente.
1.2. Justificativa
Segundo DRUIN (1999), apenas recentemente o desenvolvimento de

software infantil vem obtendo sucesso na indústria comercial. Empresas de
desenvolvimento de software acreditavam que a maioria das escolas não tivesse
recursos para investir em informática, inibindo a produção de programas
educacionais infantis. Hoje, muitas escolas vêm reconhecendo a importância de se
utilizarem as novas tecnologias no aprendizado e sabem que o ensino com o uso
desses recursos pode desenvolver competências duradouras muito importantes,
como a autoconfiança, a independência, a criatividade, a responsabilidade e a
1
cooperação. Lentamente, os computadores passam a ser vistos como ferramentas
educacionais e tornam-se parte do material de muitas escolas, demandando novos,
criativos e excitantes ambientes informatizados para crianças.
O uso de ambientes informatizados nas escolas não é suficiente para

assegurar melhoria no ensino se não for observada sua qualidade. O desejado é
que a criança possa interagir com ambientes educativos informatizados que
acrescentem valor aos meios educativos tradicionalmente utilizados no processo de
ensino/aprendizagem. As novas tecnologias devem concorrer para a construção de
uma base sólida de habilidades fundamentais, de forma a explorar as
potencialidades das crianças. Por isso, é de extrema importância a qualidade das
ferramentas ou dos aplicativos usados pelas escolas.
Grande parte dos materiais informáticos educacionais existentes no mercado,

nomeadamente o software, por serem desenvolvidos somente por especialistas da
área técnica, não tem atendido às especificidades do processo de ensino e
aprendizagem. GONÇALVES (1999) acredita que a utilização de programas
computacionais na escola subordina-se à situação de transferência de uma
tecnologia mercantil para a escola e que a superação dessa subordinação depende
ou de investimento na produção de programas que se adeqüem à realidade das
escolas ou do comprometimento de profissionais na seleção crítica dos programas.
Neste estudo, partiu-se da premissa de que o software deve estar ligado a objetivos
pedagógicos relacionados a um modelo de aprendizagem e à disciplina proposta,
declarando suas possibilidades e limitações de uso. Noutras palavras, para ser
adotado por uma instituição de ensino, esse material deve estar em concordância
com a proposta político-pedagógica da escola. Quanto à avaliação desses
programas, não se deve buscar identificar um software “perfeito/ideal”, mas
selecionar aqueles que melhor se adeqüem às necessidades das crianças, às
especificidades do processo de ensino e à realidade escolar.
BRANDÃO (1998) elenca importantes questões sobre a seleção de software

didático: “O que significa dizer que um software didático é de boa ou de péssima
qualidade? Quais os parâmetros que determinam a qualidade do software didático?
O que torna um software didático adequado ou não a determinadas situações de
ensino/aprendizagem?”
2
Em relação a essas perguntas, a área de estudo de Engenharia de
Usabilidade, quando aplicada a software educacional infantil, fornece respostas
quanto às questões de interação com o usuário proporcionada pela interface do
software, buscando-se a eficácia e a eficiência dessa interação. Mas para a
completa elucidação das questões mencionadas, necessita-se agregar os aspectos
pedagógicos à Usabilidade. Ao avaliar ou desenvolver um software educacional
infantil, deve-se conhecer tanto as situações e especificidades do processo de
ensino/aprendizagem, como os requisitos da Engenharia de Usabilidade aplicada ao
desenvolvimento de programas para usuários mirins.
Segundo CAMPOS (1994), pouco se avançou quanto a procedimentos

sistematizados que unam as questões pedagógicas e tecnológicas para a avaliação
do software educacional infantil. Essas avaliações normalmente ou são realizadas
por um especialista da área da educação, ou por um especialista em Engenharia de
Usabilidade. Em ambos os casos, o julgamento do software será baseado nos
conhecimentos e percepção do avaliador em questão. Por isso a necessidade de
uma metodologia que trate tanto dos aspectos de qualidade técnica quanto da
qualidade pedagógica de software educacional infantil.
No Brasil, pouco se investiu na produção de software que atenda às

necessidades educacionais (GONÇALVES, 1999). As escolas muitas vezes utilizam
programas deficientes existentes no mercado. A preocupação de muitos
desenvolvedores de software educacional ainda se concentra na produção, nos
prazos e custos. Questões como qualidade técnica e pedagógica ficam em segundo
plano.
1.3. Visão geral da pesquisa
A definição da MAQSEI seguiu um método sugerido por HUMPHREY (1995)

para construção de processos. Ele planejou, definiu necessidades, metas e
objetivos, guiou tarefas e ajudou a construir a estrutura da MAQSEI. Essa definição
resultou em uma documentação sobre a MAQSEI que detalha o produto (avaliação
de software educacional infantil), suas fases (em que testes para a avaliação do
software são planejados, conduzidos, analisados e relatados), seus agentes,
artefatos utilizados ou produzidos e resultados.
3
Inicialmente, a MAQSEI foi aplicada e validada em programas educacionais
infantis prontos (avaliações somativas), utilizados por instituições de ensino. Os
testes para avaliação dos programas foram realizados, em sua maioria, nos próprios
laboratórios de informática das instituições, mas alguns foram realizados em um
laboratório de Usabilidade.
Todos os testes contaram com a participação de crianças de 6 a 10 anos.

Essa escolha deveu-se:
§ À existência de uma variedade de programas infantis para essa faixa etária;
§ Ao crescimento da demanda de escolas e pais por programas educacionais

infantis, proporcionando novos meios para o auxílio à educação;
§ À facilidade da participação de crianças nessa faixa etária em testes de avaliação

dos programas. Crianças de 2 a 5 anos apresentam características que dificultam
um processo de avaliação: atenção dispersa, dificuldade em seguir roteiros de
tarefas, dificuldade em expressar o que gostam ou o que não gostam por meio de
palavras, menor coordenação motora (para o uso do mouse, por exemplo), entre
outros. Já crianças de 11 a 14 anos não apresentam muita diferenciação de
comportamento em relação a testes realizados com adultos. Entretanto, crianças
de 6 a 10 anos apresentam comportamento específico da idade e possuem
características que facilitam sua inclusão em testes de avaliação de software
educacional infantil: conseguem seguir tarefas solicitadas por adultos, não se
perturbam muito ao serem observadas, respondem a perguntas e se expressam
com facilidade.
Os resultados observados das avaliações dos programas educacionais

infantis prontos serviram para verificar as modificações necessárias e melhorias
possíveis na MAQSEI. Dessa forma, a MAQSEI foi desenvolvida evolutivamente a
partir de um processo simples, que foi sofrendo modificações e incrementos a cada
aplicação.
Visando a expandir as áreas de aplicação da MAQSEI, um software

educacional infantil em desenvolvimento a utilizou para a realização de seus testes
de Usabilidade (avaliação formativa). Esses testes mostraram que a MAQSEI pode
4
ser aplicada também em protótipos de programas em desenvolvimento, contribuindo
principalmente para o levantamento dos seus problemas técnicos e pedagógicos.
Durante todas as fases da MAQSEI é necessário o que avaliador conheça

profundamente heurísticas direcionadas a software educacional infantil para
embasar e guiar o trabalho. Neste estudo, levantou-se a necessidade de adaptações
e extensões das heurísticas existentes na literatura (CONSTANTINE, 1999;
CRONJE, 2001; GAMEZ, 1998; GARCIA, 2001; NIELSEN, 1993) para utilização na
MAQSEI. Tais heurísticas nem sempre abrangiam todos os aspectos ou se
aplicavam ao contexto de um programa educacional infantil. Portanto, durante o
processo de desenvolvimento e validação da MAQSEI, seguindo o mesmo processo
evolutivo usado para sua definição, também foram desenvolvidas heurísticas
técnicas e pedagógicas para software educacional infantil. Elas podem ser utilizadas
tanto durante a produção de um software educacional infantil, como diretrizes para o
desenvolvedor, quanto para a avaliação de qualidade de programas prontos por
especialistas da área técnica ou pedagógica.
Três papéis são observados durante a avaliação de um software educacional

infantil: avaliador, observador e operador de equipamento. O papel do avaliador
mostrou ser o de maior importância durante a avaliação. Durante todo o estudo,
observou-se que o avaliador, principalmente por ter que lidar com crianças, deve
possuir perfil e conduta específicos. Várias recomendações nesse sentido foram
então sugeridas para que um avaliador possa realizar os testes com mais facilidade
e obter melhores resultados.
Uma pesquisa de opinião e de perfil de docentes foi realizada durante este

estudo. Vários docentes de instituições visitadas, de ensino particular e público,
foram entrevistados. A entrevista objetivou conhecer:
§ A situação das instituições visitadas em relação à informatização (instalações

físicas, programas disponíveis, entre outros);
§ A visão e a posição dos docentes perante as novas tecnologias;
§ Limites e dificuldades enfrentados pelos docentes com o uso das novas

tecnologias;
§ Necessidades e demandas dos docentes em relação às novas tecnologias.
5
1.4. Capítulos
Esta dissertação está dividida em sete capítulos.
No Capítulo 2 é apresentada a revisão da literatura realizada, buscando ligar

as áreas da Computação e da Educação estudadas. Os pontos abordados são:
§ Tecnologia e educação, informática na educação e classificação de software

educacional;
§ Qualidade de software, diretrizes e regras de Usabilidade;
§ Metodologias para desenvolvimento de processos e testes;
§ Tipos de avaliação de software infantil.
O Capítulo 3 apresenta o método de definição de processo utilizado para o

desenvolvimento da MAQSEI, descrevendo seus passos e refinamentos.
Os Capítulos 4, 5, 6 e 7 apresentam os resultados e discussões obtidos neste

trabalho:
No Capítulo 4, é apresentada a forma de utilização da metodologia de

avaliação de software infantil, listando e detalhando todas as suas fases,
exemplificando seus padrões e fornecendo recomendações de uso.
No Capítulo 5, são listadas as heurísticas desenvolvidas para a MAQSEI,

resultantes dos estudos e avaliações de testes realizados.
No Capítulo 6 são apresentadas orientações e recomendações para um

avaliador de software educacional infantil.
O Capítulo 7 descreve as avaliações de software realizadas neste trabalho e

o desenvolvimento de um software educacional infantil utilizando a MAQSEI.
E, finalmente, no Capítulo 8 são explicitadas as conclusões deste trabalho e

possíveis trabalhos futuros.
Nos Anexos I a VIII são apresentados os padrões de documentos

(formulários, scripts, testes, entre outros) utilizados para as avaliações de software
educacional infantil desta pesquisa. Os Anexo IX mostra o questionário utilizado
para pesquisa de opinião com docentes. Os Anexos X a XIII resumem as fases, as
tarefas e os artefatos da MAQSEI. O Anexo XIV mostra a estrutura das heurísticas.
6
2. REVISÃO DA LITERATURA
2.1. Tecnologia e Educação
A incorporação de novas tecnologias na escola não é mais coisa do futuro.

Assim como temos terminais de auto-atendimento nos bancos ou votamos em urnas
eletrônicas, os computadores e outros recursos tecnológicos da comunicação (tevês,
vídeos, celulares) invadem lentamente as escolas, as casas, os carros, enfim, os
vários âmbitos sociais. Presente em quase todo o contexto de vida na sociedade
moderna, não há como negar os benefícios da tecnologia e deixar de explorá-los
também na educação.
O uso dos recursos tecnológicos sempre desafiou a humanidade,

modificando-a, trans formando-a, ajudando-a. A tecnologia é inerente ao ser humano,
pois foi criada por ele. Não podemos enxergá-la como efêmera, sem conexão com a
humanidade (GODOI e TEIXEIRA, 2001). No início eram somente ferramentas
usadas pelo homem para transformar a natureza, depois eram máquinas a vapor, as
indústrias, o computador. Todos trazendo impactos históricos, sociais e culturais.
Segundo FRÓES (1998), as novas tecnologias mudaram as formas de ler, de
escrever, e, conseqüentemente, de pensar e de agir. Mudaram também o ambiente
de aprendizagem. A escola deixa de ser o locus do ensino. Com os novos recursos
tecnológicos aprende-se em casa, no trabalho ou em qualquer lugar. O acesso ao
conhecimento tornou-se diferenciado, talvez mais democrático, deslocando da figura
do(a) docente a centralidade no processo educativo (SANDHOLTZ et al., 1997).
Neste estudo, privilegia-se o uso de computadores como instrumento de

auxílio no processo de ensino. O termo “Tecnologia na Educação” abrange a
informática na educação, mas também o uso da televisão, do vídeo e do rádio no
processo educativo. Por esse motivo, adotou-se o termo “Informática na Educação”
uma vez que trataremos somente do uso de software neste trabalho. As expressões
“Informática Educacional", "Informática Educativa" ou "Informática Pedagógica" não
foram adotadas porque, como explicitado por CHAVES (2002), a informática em si
não é educacional e nem antieducacional. A informática pode ser usada na
educação, proporcionando diferentes formas de ensino.
7
2.2. Informática na Educação
A introdução da informática na escola, assim como tudo que é novo, cria

divergências de opiniões. Pode-se identificar diferentes grupos: aqueles que são
indiferentes (não emitem opinião e aguardam os resultados das transformações para
poderem se definir), os que são contra e os que são a favor da inovação.
Os opositores à introdução dos computadores nas escolas fazem uso

principalmente de dois argumentos. O primeiro alega que ainda existem outros
problemas na escola (baixos salários, falta de material básico) que necessitam ser
resolvidos antes de se pensar na inserção do computador no ensino. Entretanto,
acredita-se que esses problemas possam ser trabalhados em paralelo com a
introdução da informática (VALENTE, 1993). As mudanças físicas e pedagógicas da
escola podem e devem ser articuladas juntas, para que a escola possa usufruir de
todos os recursos tecnológicos disponíveis atualmente. Esperar por condições ideais
para a informatização das escolas pode levá-las à obsolescência. O segundo
argumento baseia-se na crença de que o computador pode desumanizar a
educação, formando indivíduos “robóticos”. Mas sabe-se que esse problema não é
do computador em si, mas do estilo de vida da sociedade atual, podendo ser
estimulado pelos vários aparelhos a que já somos expostos: televisão, celulares,
entre outros. Para VALENTE (1993), acreditar que as novas tecnologias nos tornam
“robóticos” é subestimar a capacidade do ser humano, “é atribuir ao ser humano a
função de mero imitador da realidade que o cerca”.
Os defensores dessa inovação na educação têm vários argumentos. Entre

eles pode-se citar:
§ A informática já faz parte do cotidiano de todos, portanto sua introdução na

escola é inevitável;
§ O computador é somente mais uma estratégia didática, como outras já utilizadas

pelos docentes;
§ O computador ajuda a motivar a criança, propiciando um ambiente desafiador e

estimulante para eles;
§ O computador possibilita simular situações e problemas, ajudando a desenvolver

o raciocínio das crianças;
8
§ O computador proporciona interação multicultural;
§ O computador possibilita a exploração de vários contextos de aprendizagem e a

conexão com outros meios de ensino;
§ O computador possibilita a apresentação de informações de forma interativa.
Apesar de esses argumentos serem sedutores, eles parecem não garantir

que o uso dos recursos da informática melhorem a qualidade do ensino. Há a
necessidade de orientação para uso de suas potencialidades. Segundo
SANDHOLTZ et al. (1997), quando os computadores começaram a ser introduzidos
em sala de aula, havia expectativa de mudança radical no ensino. O mesmo se deu
em outras áreas da ciência. Essa transformação foi confirmada no espaço físico, nas
questões organizacionais e administrativas, mas não na forma de aprendizagem. A
preocupação maior da inovação estava concentrada nas máquinas, ficando a
integração dessas com o discurso escolar em segundo plano. Atualmente sabe-se
que é fator determinante a forma com que a tecnologia é utilizada. Essa poderá ser
uma poderosa ferramenta na construção do conhecimento, na comunicação, na
cooperação, enfim, proporcionando formas de aprendizagem inovadoras e mais
eficazes. É a técnica ganhando espaço sobre o conteúdo (GONÇALVES, 1999), no
sentido de que as mudanças vindas da informática proporcionam novos recursos
para o ensino, estabelecendo novas relações com o conhecimento, compatíveis com
as atuais necessidades sociais.
Mas como utilizar o potencial da informática a favor do ensino e da

aprendizagem? Segundo SANDHOLTZ et al. (1997), quatro condições são
necessárias para o uso bem-sucedido da informática: integração significativa na
estrutura curricular instrucional, mudança das crenças e do papel dos docentes,
formação de um contexto apoiador e ser um empreendimento de longo prazo.
2.2.1. A integração da informática na estrutura curricular
A incorporação da informática na escola deve resultar da reflexão e da

discussão de seu valor, impacto e efeitos nos processos educacionais
(GONÇALVES, 1999). Portanto, a escola deve incluir em seu projeto político-
9
pedagógico1 o uso da informática inteiramente comprometida com seus objetivos
pedagógicos. Todos (docentes, pessoal administrativo e comunidade) devem pensar
como a prática pode ser transformada com o auxílio das inovações tecnológicas.
Não se trata somente de informati zar a parte administrativa da escola, de criar um
laboratório com computadores e ensinar informática às crianças. Trata-se de formar
indivíduos capazes de procura, crítica e seleção das informações facilmente
acessadas com o uso de computadores nas escolas. É preciso incentivar a
pesquisa, o raciocínio sobre os temas, o desenvolvimento de conceitos. Deseja-se
estimular o uso dessas máquinas para a descoberta de novas informações,
aprendendo a aprender de forma autônoma e crítica.
2.2.2. O(a) docente – suas crenças e seu papel
Inicialmente, o receio dos docentes em relação aos computadores era o de

que fossem substituídos pelas máquinas. Hoje em dia sabe-se que tal medo não é
pertinente, pois o(a) docente continua sendo peça fundamental no ensino. No
entanto, novas questões fazem com que se questione a incorporação das novas
tecnologias (SANDHOLTZ, 1997):
§ A relação entre esforços necessários e benefícios adquiridos: os benefícios do

uso da tecnologia são maiores que o esforço adicional necessário
(gerenciamento da sala de aula, tempo adicional necessário, escassez de
recursos) para a inclusão da tecnologia nas práticas de ensino?;
§ Sentimento de inferioridade por parte dos docentes, pois muitas vezes possuem
menos conhecimento em relação à tecnologia que as crianças;
§ Distanciamento entre docentes e criança, devido à “auto-suficiência” da criança;
§ Perda de controle das crianças na sala de aula.
Mas a realidade atual vem mostrando as possibilidades do uso de novas

tecnologias no espaço escolar, ajudando a esclarecer tais questões. Muitas
1
“Projeto político-pedagógico é o conjunto de diretrizes educacionais mais abrangente de uma
instituição de ensino. Seu escopo deve responder às questões da metodologia de planejamento da
instituição: o quê, por quê, para quê, quem, quando e como - dos processos de ensino e
aprendizagem que serão desenvolvidos” (Sant´Anna, 1999).
10
experiências com a inclusão de computadores em ambientes escolares evidenciam
os possíveis ganhos e as modificações positivas advindas dessas inovações.
Em pesquisa realizada por SANDHOLTZ et al. (1997), concluiu-se que a

introdução dos computadores na sala de aula serviu como catalisador para várias
mudanças, entre elas proporcionou aos docentes novas técnicas de ensino a serem
experimentadas. Mas a inserção de máquinas nas escolas pode vir a legitimar
métodos tradicionais de ensino. Freqüentemente nos deparamos com o uso desses
recursos como luxuosos livros eletrônicos ou como simples exercícios de pergunta e
resposta, que privilegiam a repetição ou a mera memorização. Entretanto, quando
seu uso é bem-pensado, as inovações tecnológicas podem trazer mudanças nas
atividades pedagógicas. Suas possibilidades podem fazer com que os docentes
avaliem suas crenças sobre o ato de ensinar, reflitam sobre as possibilidades de
mudança e adotem outras estratégias de ensino.
Na perspectiva transformadora de uso do computador na educação, o papel

do(a) docente também muda. Ele(a) não é mais o detentor de todo o saber. Para
SANDHOLTZ et al. (1997), processos de ensino centrados no(a) docente levam à
baixa autonomia de aprendizagem da criança. Docente e crianças devem caminhar
juntos nesse processo: o(a) docente, orientando e estimulando a criança a buscar
novas informações, novos conhecimentos, esclarecendo seus erros, que ganham
agora novo significado e passam a fazer parte do processo de experimentação para
o aprendizado (FREIRE e VALENTE, 2001). O computador aparece como uma
ferramenta auxiliar nesse processo, possibilitando ao(à) docente realizar simulações
de um problema, criando situações virtuais que incentivem o aprendizado da criança.
THORNBURG (2003) apresenta uma interessante reflexão para os possíveis

ambientes de aprendizagem, que pode representar o que se espera atualmente do
papel do(a) docente na sala de aula. Para o autor, que remete à história do homem
para descrever os ambientes de aprendizagem, três cenários são possíveis:
1. Fogueira: desde os primórdios da humanidade que o homem conta histórias

como forma de ensinar, tipicamente em volta de uma fogueira. A fogueira
representa um local especial, o centro das atenções, onde o sábio irá partilhar
seu conhecimento com alunos, que, no futuro, transmitirão esse mesmo
conhecimento para outra geração.
11
2. Poça d’água: os homens sempre precisaram buscar água em alguma fonte, e
durante a viagem ou na fonte de água, sempre compartilharam suas experiências
com as pessoas que encontravam nesses locais. A poça d’água se tornou um
local onde se aprende com os amigos, com os companheiros, de forma menos
formal. Todos são, ao mesmo tempo, sábios e aprendizes.
3. Caverna2: a importância de momentos de introspecção para o ser humano é

conhecida há tempos. O homem sempre necessitou estar em contato consigo
mesmo para poder refletir. O autor usa a caverna para representar esse cenário,
onde o homem pré-histórico costumava se isolar.
O autor ressalta que os três ambientes vêm sendo experimentados por alunos
ao longo da história de forma balanceada. Um ambiente não invalida o outro: a
fogueira proporciona o contato com conhecedores, a poça d’água, a troca de
experiências e conhecimentos com colegas, e a caverna, o contato consigo mesmo.
Cada cenário tem sua importância e deve -se fornecer ao aluno a oportunidade de
experimentar os três. Assim, descartar qualquer um deles limita as possibilidades de
ensino.
Pode-se aplicar tais modelos de aprendizagem ao ambiente escolar. As

crianças da escola tradicional experimentavam a fogueira, onde somente o(a)
docente detinha o conhecimento e às crianças cabia somente o papel de receptores
das informações. A poça d’água era vivenciada nos momentos de recreação e a
caverna, em casa ou em locais destinados a estudos, como bibliotecas. Hoje, tal
organização é questionada e busca-se a união de todos esses modelos no processo
de ensino/aprendizagem: a poça d’água vem sendo implantada na sala de aula por
meio do ensino cooperativo e a caverna, por meio de laboratórios multimídia para
pesquisa. Cabe aos docentes escolher os modelos de aprendizagem adequados às
várias situações de ensino/aprendizagem.
2.2.3. Contexto apoiador
Nos projetos de informatização de escolas, normalmente, todos os recursos

são investidos na compra de equipamentos de hardware e software, deixando a
capacitação dos docentes em segundo plano. Não obstante, os docentes
2
Os termos Fogueira, Poça d’água e Caverna foram traduzido do inglês.
12
necessitam de um ambiente apoiador na escola onde possam (SANDHOLTZ et. al.,
1997):
§ Ter acesso a computadores e à Internet a qualquer momento;
§ Ter suporte técnico e instrucional para a solução de problemas e aquisição de

conhecimentos sobre a utilização dos computadores;
§ Ter suporte pedagógico para aprender, discutir e trocar experiências sobre as

estratégias alternativas de ensino.
Esse último tópico aparece como o mais importante, pois envolve suporte
emocional, técnico e instrucional. A troca de experiência entre docentes colabora e
estimula o uso das novas estratégias de ensino.
2.2.4. Trabalho em longo prazo
A implantação de um projeto de informática na escola é um processo

demorado e implica várias mudanças. As possibilidades oferecidas com a inclusão
do computador e seus recursos em sala de aula só podem ser vistas a longo prazo,
por meio de mudanças gradativas, pois implicam alterações de valores cristalizados.
Segundo SANDHOLTZ et al. (1997), a evolução instrucional ocorre em cinco
estágios:
1. Exposição: primeiro contato do(a) docente com as máquinas e exploração

de seus recursos;
2. Adoção: primeiras atividades propostas às crianças com o uso do

computador, normalmente relacionadas à forma de utilização;
3. Adaptação: integração dos novos recursos às outras práticas de ensino;
4. Apropriação: marco que delimita a mudança de crença dos docentes.

Nesse momento, passam a ver a nova tecnologia como habitual nas suas
estratégias de ensino e no cotidiano;
5. Inovação: docentes experimentam novos padrões instrucionais e formas

de relacionamento com crianças e docentes. É a confirmação da mudança
no projeto pedagógico da escola.
13
Segundo os mesmos autores, o estágio da inovação só é atingido após longo
e penoso processo, o que confirma o caráter gradual da transformação ocasionada
pela inserção das máquinas no ambiente escolar. Isso ocorre porque não são
apenas mudanças técnicas, mas mudanças de concepções sobre o quê, por quê e
como ensinar (GODOI e TEIXEIRA, 2001).
2.3. A informática na educação no Brasil
Segundo o Censo Escolar de 2000 do MEC/INEP (BRASIL, 2002), do total de

estudantes matriculados no ensino médio, 56% (4,5 milhões) estudam em escolas
que possuem laboratórios de informática. Esses estabelecimentos representam 49%
das escolas nesse nível de ensino. Já no ensino fundamental, 22% (8 milhões) das
crianças estudam em escolas que possuem laboratório de informática. Eles estão
distribuídos em cerca de 16 mil escolas, ou seja, cerca de 9% do total. Em Minas
Gerais (onde este estudo foi realizado), 52% das escolas do ensino médio e apenas
10% das escolas de ensino fundamental possuem laboratório de informática.
Diante dessa situação, vários têm sido os incentivos para a adoção de

computadores nas escolas no Brasil. Dentre eles, dois projetos vêm sendo
implementados pelo governo federal, desde 1997, para informatização e acesso à
Internet em todas as escolas públicas de ensino do país. O primeiro, desenvolvido
em parceria com o Ministério das Comunicações, provê recursos do Fundo de
Universalização dos Serviços de Telecomunicações − FUST. O segundo,
denominado Programa Nacional de Informática na Educação − PROINFO (BRASIL,
2000) − foi proposto pelo MEC e implementado por meio de parcerias com as
Secretarias Estaduais de Educação e Prefeituras Municipais. Seus principais
objetivos são:
§ Melhorar a qualidade do processo de ensino/aprendizagem;
§ Possibilitar a criação de nova ecologia cognitiva nos ambientes escolares

mediante incorporação adequada das novas tecnologias da informação pelas
escolas;
§ Propiciar educação voltada para o desenvolvimento científico e tecnológico;
§ Educar para cidadania global numa sociedade tecnologicamente desenvolvida.
14
Para PRETTO (1997), a questão da educação e a inovação tecnológica no
Brasil estão muito além da inclusão do computador nas escolas. O autor afirma que
as transformações ocorrem sobre uma realidade complexa, e não em espaços
neutros. A compreensão e a implementação dessas transformações pressupõem a
existência de valores e culturas locais com alto nível de visibilidade e flexibilidade.
As transformações só serão alcançadas se, além da parte física estrutural, tivermos
os elementos culturais produzidos e difundidos em nosso país, uma sociedade
preparada. Cabe ainda lembrar que a inserção da tecnologia na educação no Brasil
foi produzida como forma de adequação político-econômica a um modelo global de
desenvolvimento (GONÇALVES, 1999), e não como projeto prioritário para a
melhoria da educação. Assim, os elementos necessários para a sua implantação
não foram construídos. PRETTO (1997:84) ainda afirma, sobre a construção da
educação brasileira, que:
“Uma construção não apenas nas palavras e para os números, mas que atue, na
prática, no país como um todo, que vem clamando por transformações estruturais em
diversas áreas. Este é, sem dúvida, o nosso grande desafio, e estas novas
tecnologias de comunicação e informação podem vir a se constituir em um importante
elemento destas transformações se pudermos vê-las em outra perspectiva que não a
de simples instrumentos metodológicos mais modernos que podem ser implantados
de forma isolada e desarticulada, mantendo crianças, jovens, adolescentes e
professores como meros consumidores de um conhecimento pronto que passa agora
a circular e ser entregue via das ditas novas tecnologias. Em oposição a isso, sem
pensamos nas tecnologias a serviço da produção de conhecimento e cultura,
podemos pensar na inserção do país no mercado dito globalizado, numa outra
perspectiva. Uma perspectiva de efetiva cidadania.”
Para atingir tal objetivo, o mesmo autor acredita que o governo brasileiro
deveria unir e articular universidades, empresas, pesquisadores e outros para um
esforço, de forma a corrigir a rota dos projetos existentes em cada um desses
setores e melhorar a educação brasileira.
2.4. O software educacional
“O software educacional é todo aquele que pode ser usado para algum objetivo
educacional, por docentes ou alunos, qualquer que seja a natureza ou finalidade para a qual
tenha sido criado” (GARCIA, 2001:18).
Os primeiros programas educacionais desenvolvidos refletiam as práticas

pedagógicas tradicionais da educação. O processo de introdução do software na
15
educação repetiu o normalmente ocorrido com a mudança para uma nova
tecnologia, ou seja, a produção de versões computadorizadas do anteriormente
existente (VALENTE, 1993). Inicialmente se reproduz a prática vigente para, depois,
alcançar desenvolvimento e evolução.
Sabe-se que na década de 1960, nos Estados Unidos, os primeiros

programas educacionais foram desenvolvidos baseados na pedagogia da instrução
programada proposta por B. F. Skinner (COUTINHO E MOREIRA, 2001). Eles foram
chamados de computer-aided instruction − CAI3. A instrução programada era usada
na época e tinha como princípio a divisão do conteúdo em módulos, seguindo uma
seqüência lógica, de tal forma que o aprendiz pudesse caminhar em ritmo próprio,
tornando possível o reforço às respostas corretas e punindo os erros ocorridos.
Entretanto, os CAI só foram disseminados com o advento dos microcomputadores. A
difusão dos CAI ocorreu por meio da produção de vários tipos de programas, como
tutoriais, exercício-prática, simulações, jogos, entre outros.
A idéia transmitida pelos CAI foi somente o início da produção dos programas
educacionais, permitindo o desenvolvimento de novas abordagens desses
programas, como ferramentas de solução de problemas ou editores de textos.
Atualmente, dificilmente conseguiríamos dimensionar a variedade e a quantidade de
programas educacionais existentes.
Vários autores (FONTES, 2001; RAMOS, 1991; GAMEZ, 1998; VALENTE,

1993; CAMPOS, 2001) mencionam a existência de dois paradigmas de software
educacional:
§ Software construtivista: programas que possibilitam a expressão e a exploração

individualizada. Essa classe de software deve possibilitar ao aprendiz estabelecer
relações da seguinte forma: descrição-execução-reflexão-depuração. O(a)
aluno(a) é desafiado com um problema e executa-o no computador, visua lizando
seus pensamentos (descrição). Obtém-se então a resposta do computador
(execução). Os acertos e/ou erros cometidos tornam-se objetos de análise
(reflexão) e, então, o(a) aluno(a), por si ou com a ajuda do(a) docente, pode
reformular seus pensamentos e tentar de novo (depuração). Isso promove sua
3
No Brasil, foram conhecidos como programas educacionais por computador – PEC.
16
aprendizagem, trabalhando os planos concreto e abstrato, testando suas idéias.
Nesses programas, o aluno detém o controle sobre o funcionamento.
§ Software behaviorista (conducionista, comportamentalista): possui seqüências

instrutivas fixas, cada passo é constituído por uma unidade limitada de saber. Por
meio de exercícios e práticas em seqüências de crescente complexidade, os
alunos vão cedendo aos níveis do saber. É eficaz e eficiente no ensino e
aprendizagem de operações pouco complexas, susceptíveis a memorização e a
mecanização (FONTES, 2001).
Os programas construtivistas são baseados na metodologia de

ensino/aprendizagem criada por Piaget, denominada construtivismo (COUTINHO E
MOREIRA, 2001). De acordo com o construtivismo, deve-se aproveitar as
possibilidades da informática no ensino: interatividade, simulação da realidade,
integração, armazenamento e organização de informação (REZENDE, 2000). Essas
possibilidades também serviram como base para o desenvolvimento de algumas
propostas construtivistas de utilização de materiais didáticos na educação. A mais
discutida delas é o construcionismo de Saymour Papert, que é uma abordagem pela
qual o aprendiz constrói, por meio do computador, seu próprio conhecimento , num
ciclo contínuo de internalização do que está fora e externalização do que está dentro
(REZENDE, 2000). A interação com o computador possibilita que o aprendiz
manipule e adquira conceitos, desenvolvendo suas estruturas mentais.
Os paradigmas construtivista e behaviorista de software são às vezes usados

para avaliar programas educacionais (CAMPOS 2001; CUPERTINO e OLIVEIRA,
2001; FONTES, 2001; RAMOS, 1991). Essas avaliações, usualmente, classificam os
programas com características construtivistas como de qualidade. Entretanto, outros
fatores também devem ser analisados ao se avaliar a qualidade de um programa
educacional: o uso que se faz do software, a forma como se exploram suas
potencialidades e o contexto em que ele é aplicado na escola (organização, cultura
institucional, filosofia pedagógica). Esses são os principais fatores de sucesso ou
fracasso do uso de um programa educacional. Como ressalta VALENTE (1993):
“(...) a análise de um sistema computacional com finalidades educacionais não pode ser
feita sem considerar o seu contexto pedagógico de uso. Um software só pode ter tido
com bom ou ruim dependendo do contexto e do modo como ele será utilizado. Portanto,
17
para ser capaz de qualificar um software é necessária ter muito clara a abordagem
educacional a partir da qual ele será utilizado e qual o papel do computador nesse
contexto”.
É de relevância ressaltar que as modalidades behaviorista e construtivista de

software educacional podem continuar existindo. Deve-se, entretanto, estar ciente
dos limites e possibilidades de cada uma, selecionando qual software educativo
atende melhor às necessidades da escola, dependendo das suas estratégias de
ensino e do seu projeto político-pedagógico.
2.5. Qualidade de produtos
A qualidade de um produto é fator de grande importância que tem sido

buscado em vários setores (HERBERT E PRICE, 1995). Nos meios acadêmico,
empresarial, industrial, busca-se produtividade associada à qualidade. Além disso, o
consumidor é hoje muito mais exigente e consciente de seus direitos, buscando a
satisfação na escolha de um produto ou serviço. GILLES4, citado por HEBERT
(1995), faz as seguintes considerações sobre a qualidade:
§ “A qualidade não é absoluta. Ela pode ter significados diferentes, em situações diferentes. Ela
não pode ser medida de maneira única, em uma escala quantificável, como propriedades físicas
tais como temperatura e tamanho”;
§ “A qualidade é multidimensional. Há muitos fatores envolvidos em sua determinação.

É muito difícil definir qualidade para pessoas que pensam diferente, e que nem
sempre estão conscientes de seus critérios de qualidade”;
§ “A qualidade pode ser limitada por alguns fatores. O custo é um dos grandes
limitadores do desenvolvimento de produtos com qualidade plena. Por exemplo, na
compra de carros, apesar de preferirem carros mais caros, as pessoas limitam-se a
comprar um carro que seja adequado à sua renda. Neste caso, não é uma questão de
escolha, e sim de disponibilidade de recursos”;
§ “A qualidade está relacionada a acordos aceitáveis. Alguns critérios de qualidade

podem ser sacrificados mais ‘aceitavelmente’ do que outros, dependendo dos
4
GILLES, A. Software Quality – Theory and Management. [s.l.]: Chapman & Hall, 1992.
18
interesses de produtor e consumidor. No exemplo dos carros, conforto pode ser
sacrificado em detrimento de confiabilidade”;
Mas como definir e avaliar a qualidade de um produto? Para HERBERT E

PRICE (1995), o conceito de qualidade é influenciado pelas expectativas e
percepções dos envolvidos, tornando-se subjetivo e local (com grande dimensão
psicológica). Mas a avaliação de qualidade deve ser comum, a mesma para vários
sistemas. Os mesmos autores afirmam que, para avaliar uma característica sem ser
subjetivo, deve-se usar um modelo, um padrão com medidas. Portanto, uma
avaliação de qualidade necessita:
§ Parâmetros objetivos que forneçam argumentos para avaliações posteriores;
§ Metodologia e técnicas para reduzir custos, esforços e aumentar a confiabilidade;
§ Modelos de qualidade – características a serem observadas e mensuradas

(heurísticas). Essas devem ser objetivas, para que pessoas diferentes vejam a
mesma coisa. Entretanto, os critérios de medida de qualidade não são
independentes, eles também interagem entre si, causando conflitos. Por
exemplo: se a qualidade de um carro está definida como sendo afetada pela
economia de combustível e pela sua velocidade, um conflito pode ser criado,
dependendo da tecnologia sendo utilizada na situação. É importante também
ressaltar que a confiabilidade de um produto é, muitas vezes, considerada
sinônima de qualidade, mas outras características precisam ser também
observadas. Por exemplo: um software educacional infantil sem erros de
execução não pode ser considerado de qualidade se não propiciar um ambiente
estimulador, onde a criança possa desenvolver seu conhecimento.
A ciência que estuda a garantia da qualidade de um software é a Engenharia

de Software.
2.6. Engenharia de Software
Na Engenharia de Software, a qualidade de um produto é entendida como

sendo o seu grau de conformidade com seus requisitos 5 (PAULA FILHO, 2001). Um
software de baixa qualidade não atende completamente a todas as suas
5
De acordo com PAULA (2001), “os requisitos são as características que definem os critérios de
aceitação de um produto” (grifo do autor).
19
características necessárias, podendo ser deficiente em relação ao seu desempenho,
à corretude de suas funções, à facilidade de seu uso, entre outros aspectos.
Segundo PAULA FILHO (2001), a garantia da qualidade de um software

decorre diretamente da qualidade do processo6 usado durante seu desenvolvimento.
Usualmente esse processo não é seguido ou é inexistente, podendo produzir
sistemas que não atendem completamente a todos os requisitos6 necessários. A
Engenharia de Software objetiva, portanto, garantir que os produtos possuam as
características necessárias para sua aceitação por meio de processos definidos
durante a produção do software.
Um dos aspectos relacionados à Engenharia de Software que tem merecido

crescente destaque é a qualidade da interação entre o usuário e os programas de
computador, objeto de estudo da Engenharia de Usabilidade. Enquanto a
Engenharia de Software trata dos aspectos construcionais de um programa, a
Engenharia de Usabilidade abrange os aspectos comportamentais.
2.7. A Engenharia de Usabilidade
Para a grande maioria dos domínios de aplicação da tecnologia da

informação, a comunicação dos usuários com os sistemas tornou-se tão importante
quanto a computação realizada pelo sistema (RUBIN, 1994). Por isso, a Engenharia
de Usabilidade, definida na norma ISO 9241-11 (1998) como "a capacidade de um
produto ser usado por usuários específicos para atingir objetivos específicos com
eficácia, eficiência e satisfação em um contexto específico de uso", é uma área que
vem ganhando espaço nos dias atuais. Seu objetivo é desenvolver produtos tais que
os usuários possam realizar as tarefas requeridas com o mínimo de estresse e
máximo de eficiência (RUBIN, 1994).
Por meio dos estudos da interação entre homem e computador, a Engenharia

de Usabilidade vem obtendo interfaces funcionais e de qualidade. Mas o que faz
uma interface ser considerada de qualidade? Para os estudiosos da área, a
propriedade de uma interface ou mesmo de um software que traduz sua qualidade é
a facilidade de uso, a Usabilidade, que pode ser caracterizada pela conjunção dos
6
“Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades,
métodos, práticas e transformações, usado para atingir uma meta” (PAULA FILHO, 2001).
20
seguintes atributos (NIELSEN, 1993):
§ Facilidade de aprendizado: um novo usuário deve aprender a realizar as tarefas

básicas do sistema no tempo mais curto possível;
§ Eficiência: uma vez dominado pelo usuário, o sistema possibilita alta

produtividade;
§ Retenção no tempo: se o usuário ficar sem usar o software por um tempo, deve
ser capaz de reutilizá -lo sem maiores dificuldades;
§ Minimização de erros: as tarefas realizadas pelo usuário devem ter baixa taxa de
erros e possibilitar a correção dos erros que possam acontecer;
§ Satisfação: o software deve ser bem-aceito pelos usuários, proporcionando

satisfação.
Portanto, ao desenvolver um software, esses atributos devem ser levados em

consideração para que se obtenha um sistema de qualidade em termos de
Usabilidade. Métricas associadas a esses atributos podem ser usadas na avaliação
de sistemas quanto à sua Usabilidade e, assim, sugerir eventuais correções e
modificações.
A Engenharia de Usabilidade utiliza-se de conceitos semelhantes aos usados

em desenvolvimento de software, como especificação de requisitos, prototipação,
métricas, testes. No entanto, por tratar com relações humanas, requer um
tratamento diferenciado. O comportamento humano deve ser estudado e levado em
consideração ao se definir uma metodologia específica para a análise de
Usabilidade de um software. E, como esse comportamento não é previsível, deve-se
quantificar os atributos de Usabilidade e estabelecer metas para a qualidade da
interação baseadas nas quantificações. Ainda, RUBIN (1994) identifica como
características da Engenharia de Usabilidade:
§ Foco sempre no usuário e na tarefa: levantamento do perfil, do comportamento e

das tarefas do usuário não deve ser feito somente no início de um projeto de
software. Será necessário contato com os usuários durante todo o ciclo de
desenvolvimento. Como em muitas vezes esse contato se dá de forma não-
21
estruturada, gerando dados sem conexão, necessita-se de metodologia
sistemática e estruturada para a coleta de informações dos usuários;
§ Medidas empíricas do uso do produto: a avaliação de um software deve dar

ênfase a medidas comportamentais e facilidade de uso desde o planejamento do
software até testes do protótipo com o usuário final;
§ Desenvolvimento iterativo: o produto deve ser desenvolvido, modificado, e

testado repetidamente durante toda a sua construção. Assim permite-se a
modelagem do produto pelo processo de desenvolver, testar e refazer.
Existem várias técnicas, métodos e práticas possíveis para avaliar a

Usabilidade durante o ciclo de desenvolvimento de um produto de software. Entre
elas, pode-se citar:
§ Pesquisas de opinião: essa técnica visa ao levantamento de sentimentos e

opiniões de vários usuários sobre conceitos expostos. Podem ser usadas para a
verificação das preferências de um grupo. A pesquisa deve ser expressa em
linguagem clara, para que todos a compreendam;
§ Desenvolvimento participativo: a técnica conta com a participação de um ou mais

usuários representativos na equipe de desenvolvimento do software, opinando
durante todo o seu ciclo de produção. Deve-se ter cuidado para que esse(s)
usuário(s) não comecem a reagir e pensar como um membro da equipe,
escondendo suas opiniões e críticas;
§ Avaliações em papel: nessa técnica é mostrado aos usuários um aspecto do

produto e são realizadas perguntas a seu respeito, como no exemplo da Figura 1,
em que o usuário é questionado sobre o menu de um processador de textos;
Ao lado de cada tarefa do editor de textos abaixo, escreva o nome da opção do menu pull-
down que você espera achar a tarefa:
Arquivo Editar Exibir Inserir Formatar Ferramentas Tabela Janela Ajuda
1 – Procurar por uma palavra _____________

2 – Criar um cabeçalho __________________
3 – Repetir uma anotação ________________
4 – Usar itálico _________________________
5 – Configurar a impressora _______________
...
FIGURA 1 − Exemplo de avaliação em papel
22
§ Avaliações por profissionais de Usabilidade (avaliações heurísticas): são uma
revisão do produto por especialista(s) em Usabilidade, que verificam o produto de
acordo com os princípios e regras de Usabilidade contidos na literatura
(heurísticas). Pode-se também ter a revisão por especialistas em duas áreas: de
Usabilidade e da tecnologia usada no produto em especial;
§ Inspeções com listas de conferência (checklists): realizadas por meio de vistorias

nas quais profissionais, não necessariamente especialistas em Usabilidade,
como, por exemplo, programadores e analistas, diagnosticam rapidamente
problemas gerais e repetitivos das interfaces (CYBIS, 2003). Nesse tipo de
técnica, a qualidade das listas determina as possibilidades de avaliação.
§ Comparações do produto: o produto é comparado com padrões e listas de

verificações retiradas de pesquisas, da literatura ou de critérios de Usabilidade
estabelecidos pela empresa;
§ Testes de Usabilidade: nessa técnica, largamente difundida e usada, um grupo

de usuários representativos do público-alvo do sistema realiza tarefas típicas com
o produto, enquanto observam-se e recolhem-se dados sobre essa atividade. A
análise dos dados recolhidos pode resultar em correções a serem feitas no
software e avaliações sobre sua eficiência e sua aplicabilidade;
§ Estudos de campo (testes beta): são revisões do produto realizadas com o

usuário no ambiente de aplicação do software (escritórios, casas), um pouco
antes do seu lançamento. Os resultados são usados para refinar o produto antes
da sua liberação. Mas como, tipicamente, esses dados são coletados muito tarde
no ciclo de desenvolvimento do software, são muitas vezes aproveitados também
para sua nova versão;
§ Estudos posteriores: são revisões semelhantes aos estudos de campo, mas

realizados após o lançamento do produto. É a coleta de dados para sua próxima
versão. Apesar de serem pouco usados, os estudos posteriores fornecem ótimo
retorno sobre o produto, sendo usados em seu ambiente real.
De acordo com PÁDUA (2003), as técnicas de Usabilidade podem ser

classificadas, dependendo da estratégia utilizada, em analíticas, de pesquisa de
opinião e empíricas. As técnicas analíticas são realizadas por especialistas em
23
desenvolvimento de interface por meio de revisões de protótipos ou do produto final,
buscando avaliar a qualidade da interação proporcionada pela interface (avaliações
heurísticas, inspeções por meio de listas de conferência e comparações do produto).
As técnicas de pesquisa de opinião buscam avaliar a satisfação do usuário por meio
de técnicas de questionários e/ou entrevistas, com o objetivo de se antecipar a
reação do usuário com relação do produto (pesquisas de opinião, desenvolvimento
participativo e avaliações em papel). As técnicas empíricas ou experimentais,
objetivam detectar problemas de Usabilidade por meio da observação do usuário
interagindo com os protótipos ou a interface finalizada, por meio de experimentos
controlados (testes de Usabilidade, estudos de campo e posteriores).
Notam-se, portanto, a variedade e a complexidade das técnicas de

Usabilidade existentes.
2.7.1. Regras e Princípios (heurísticas)
O conhecimento das regras e princípios de Usabilidade para o

desenvolvimento de um software é o primeiro passo para a obtenção de sistemas de
qualidade. Entretanto, devem ser aplicados sempre com bom senso, pois,
dependendo da situação, podem não se aplicar. Segundo CONSTANTINE (1999),
todo desenvolvedor de software deve conhecer as regras de Usabilidade e os
princípios de desenho centrados no usuário descritos a seguir.
Regras de Usabilidade:
§ Acesso: o usuário deve conseguir usar o sistema sem necessitar de nenhum tipo
de ajuda;
§ Eficácia: o sistema não deve interferir ou impedir a eficácia de uso de um usuário

experiente;
§ Progressão: à medida que o usuário vai ganhando experiência, o sistema deve

permitir avanços em seus conhecimentos e habilidades;
§ Suporte: o sistema deve dar suporte a atividade que o usuário esteja realizando,
tornando-a mais simples e fácil;
§ Contexto: o sistema deve ser adequado ao seu ambiente real, ao seu local de
utilização.
24
Princípios de desenho centrados no usuário:
§ Estruturação: organize as interfaces de maneira significativa, consistente e clara,

colocando juntos elementos relacionados e separando os não-relacionados;
§ Simplicidade: simplifique tarefas, comunique com o usuário de forma clara e com

linguagem familiar, faça atalhos significativos para procedimentos longos;
§ Visibilidade: mantenha todas as opções e materiais necessários a uma tarefa

sempre visíveis, sem distrair o usuário com informações extras ou redundantes;
§ Feedback: mantenha os usuários sempre informados sobre ações e

interpretações, mudanças de estado ou condições, erros e exceções que são
importantes para eles, por meio de linguagem familiar, clara, concisa e sem
ambigüidade;
§ Tolerância: seja flexível e tolerante, sempre possibilitando refazer ou desfazer

uma ação e prevenindo a ocorrência de erros;
§ Reutilização: reutilize componentes internos e externos, reduzindo a necessidade

do usuário de relembrar ou repensar.
Já NIELSEN (1993) descreve as seguintes heurísticas como sendo os dez

princípios fundamentais da Usabilidade7:
1. Visibilidade do estado do sistema: o sistema deve sempre manter os usuários

informados sobre o que está ocorrendo, por meio de feedback apropriado, dentro
de um tempo razoável.
2. Correspondência entre o sistema e o mundo real: o sistema deve falar a

linguagem do usuário, com palavras, expressões e conceitos familiares ao
usuário, no lugar de termos orientados para o sistema. Convenções do mundo
real devem ser seguidas, fazendo a informação aparecer numa ordem lógica e
natural.
3. Controle e liberdade do usuário: os usuários freqüe ntemente escolhem funções

por engano e irão precisar de uma “saída de emergência” claramente marcada
para deixar o estado indesejado sem ter que passar por diálogos adicionais.
7
As dez heurísticas descritas foram traduzidas do inglês.
25
Funções undo e redo devem estar disponíveis.
4. Consistência e padrões: o usuário não deve ter dúvidas se palavras, situações ou

ações diferentes do sistema significam ou não a mesma coisa. As convenções da
plataforma devem ser seguidas.
5. Prevenção de erros: melhor que boas mensagens de erro é um desenho

cuidadoso que impeça, desde o começo, a ocorrência do problema.
6. Reconhecimento do lugar de memorização: objetos, ações e opções devem estar

visíveis. O usuário não deve ter que lembrar informações de uma parte do
diálogo para usá-las em outras. Instruções de uso devem estar visíveis ou
facilmente recuperáveis sempre que apropriado.
7. Flexibilidade e eficiência de uso: atalhos − invisíveis para o usuário novato −

podem aumentar a eficiência da interação do usuário de tal forma que o sistema
possa servir tanto a usuários inexperientes quanto a experientes. Deve-se
permitir que o usuário personalize funções freqüentes.
8. Desenho estético e minimalista: os diálogos não devem conter informação

irrelevante ou raramente necessária. Cada unidade extra de informação compete
com as unidades relevantes e diminui sua visibilidade relativa.
9. Auxílio no reconhecimento, no diagnóstico e na recuperação de erros:

mensagens de erro devem ser expressas em linguagem simples (simples
códigos), indicar precisamente o problema e sugerir solução. Ajuda e
documentação: ainda que seja melhor que o sistema possa ser usado sem
documentação, pode ser necessário prover ajuda e documentação. Essa
informação deve ser fácil de pesquisar, deve estar focalizada na tarefa do
usuário, listar passos concretos a se seguir e não ser muito extensa. Essas
regras e esses princípios podem ser utilizados em análises heurísticas tanto durante
o desenvolvimento de um software, quanto para a avaliação de Usabilidade de
programas.
26
2.7.2. A Engenharia de Usabilidade aplicada a software educacional
infantil
Os métodos utilizados na Engenharia de Usabilidade aplicada a software

infantil diferem dos utilizados quando o foco é o público adulto (DRUIN, 1999;
HANNA et al., 1997). As técnicas de desenvolvimento da interação entre usuário e
computador devem ser adaptadas e estendidas ao se tratar com crianças (GARCIA,
2001). DRUIN (1999) afirma que medidas tradicionais de Usabilidade, como índices
de produtividade ou eficiência na realização de tarefas, não se aplicam em
Usabilidade infantil. Já medidas como familiaridade, controle e desafio aparecem
como mais apropriadas em muitas situações. A facilidade de uso é influenciada pelo
nível de entretenimento e de sucesso da criança. Essas mudanças ocorrem porque
uma criança tem seu próprio ritmo, seu próprio comportamento, enfim, um
comportamento psicológico diferenciado. Nesse sentido, é preciso tomar cuidado
para não lhe impor a lógica de um adulto, concorrendo para prejuízos ao caráter e à
capacidade intelectual da criança.
Algumas propostas de análise de Usabilidade durante o desenvolvimento de

software educacional (PLUM e TELL, 2000; CRONJE, 2001) ou software
educacional infantil (GARCIA, 2001) podem ser encontradas na literatura. Também
são encontradas avaliações de programas educacionais prontos (GAMEZ, 1998;
CAMPOS, 1994; VIEIRA, 2002; CUPERTINO, 2001; RAMOS, 1991). Em todas
pode-se perceber a inclusão de questões pedagógicas em razão da necessidade da
conciliação dessas com as questões de Usabilidade na avaliação de software
educacional ou infantil. Algumas delas contribuíram plenamente neste trabalho e
serão descritas nos dois tópicos a seguir.
2.7.3. Propostas de análise de Usabilidade para o desenvolvimento de

software educacional ou infantil
Duas propostas de análise de Usabilidade para programas educacionais ou

infantis em fase de desenvolvimento auxiliaram neste estudo: GARCIA (2001) e
PLUM e TELL (2000).
27
GARCIA (2001) propõe adaptações na metodologia de Engenharia de
Usabilidade para se adequar à participação de crianças no processo de
desenvolvimento de um software infantil. Resumidamente, a autora propõe:
§ As análises de usuário e de tarefas devem ser realizadas em conjunto com um

profissional da área educacional, para o levantamento do perfil das crianças e a
identificação de requisitos do software;
§ O desenvo lvimento do software deve contar com a técnica de desenho interativo

em duas etapas. Na primeira, o protótipo do software é avaliado pelos docentes.
Na segunda, crianças são observadas realizando tarefas no protótipo;
§ A análise heurística do software, realizada por especialistas em Usabilidade,

deve verificar o programa de acordo com heurísticas voltadas para software
infantil educacional.
§ Extensões das heurísticas descritas em NIELSEN (1993), procurando adaptá -las

para uso em avaliações de software educacional infantil. As seguintes
adaptações são sugeridas pela autora:
1. Visibilidade do estado do sistema: para crianças, o feedback deve funcionar

como forma de estímulo, sendo para incentivar, indicar um novo caminho ou
então um novo desafio. A falta do feedback pode acarretar abandono do software
pela criança.
2. Correspondência entre o sistema e o mundo real: além de se preocupar com

a utilização de uma linguagem para o usuário mirim, o software educacional
infantil deve -se preocupar com a utilização de novas palavras. O uso de novas
palavras (novos conceitos) deve ocorrer para que o vocabulário da criança possa
ser ampliado. Essas novas palavras não devem ser simplesmente introduzidas
às crianças por meio do software, é necessário que sempre haja uma exp licação
do novo conceito utilizado.
3. Controle e liberdade do usuário: a liberdade de uso em software para crianças

é muito importante. Muitas vezes ela deixa de utilizar o software pelo fato de não
conseguir ir adiante em uma tarefa. Portanto, as funções devem estar claras, as
indicações de guia pelo software devem ser explícitas, para que a criança não se
28
perca no processo de utilização do software e, conseqüentemente, sinta-se
desestimulada.
4. Consistência e padrões: a busca pelo interesse da criança em utilizar o

software deve ser assegurada. Deixar situações diferentes em telas que realizam
a mesma tarefa podem confundir a criança. Essa confusão com as telas, além de
interferir no andamento do software educacional infantil, pode fazer com que a
criança perca o estímulo de usá-lo.
5. Prevenção de erros: falhas no desenho do software educacional infantil levam

a problemas durante a utilização. Por isso, quanto mais se puder evitar esses
problemas, maior será o interesse da criança no software. O erro ocasionado
durante a execução de um software infantil pode causar seu abandono pela
criança.
6. Reconhecimento no lugar de memorização: a informação que está na

interface deve diminuir a necessidade de memorização por parte das crianças.
No software educacional infantil essa heurística está associada ao fato de que o
software deve mostrar e fazer com que a criança se preocupe mais com seu
objetivo, que, nesse caso, é o auxílio no aprendizado de determinado conteúdo
didático.
7. Flexibilidade e eficiência de uso: como o software educacional infantil é uma

ferramenta de auxílio no processo de ensino/aprendizagem, deve-se levar em
consideração o ritmo que cada criança possui. Dessa forma, o software deve
permitir que diversas fases estejam disponibilizadas em um mesmo módulo para
que a criança possa evoluir conforme seu ritmo.
8. Desenho estético e minimalista: o software educacional infantil não deve

conter grandes textos, que podem fazer com que a criança fique confusa. Ela não
está ali para aprender a utilizar o software, e sim para aprender um novo
conteúdo por meio do computador. Informações adicionais que não dizem
respeito à realização de tarefas podem levar a criança a cometer um erro, devido
à sua curiosidade e à vontade de explorar tudo o que o software proporciona.
9. Auxílio no reconhecimento, no diagnóstico e na recuperação de erros:

analisar, junto aos profissionais da área educacional, qual a melhor forma de
29
indicar erro para uma criança, de forma que ela possa, a partir da mensagem de
erro, evoluir para a solução do problema.
10. Ajuda e documentação: no software educacional infantil a documentação é

mais direcionada aos pais e professores do que aos usuários finais, que, nesse
caso, são crianças. A ajuda para elas deve ser disponibilizada discretamente,
podendo aparecer em forma de dicas espalhadas pelo próprio programa. Formas
animadas ajudam a chamar a atenção da criança.
§ A análise do software infantil educacional pode ser feita de forma colaborativa,

com profissionais da área pedagógica avaliando a interface do sistema e
ajudando na descoberta de problemas relacionados às questões educativas;
§ Os testes de Usabilidade do programa devem ser realizados com a participação

de crianças em ambientes familiares a elas. Durante os testes, as crianças são
observadas realizando tarefas previamente elaboradas.
PLUM e TELL (2000) propõem a análise de software infantil em duas fases:

formativa e somativa. A avaliação formativa ocorre durante o desenvolvimento do
software. Nela são coletados dados que ajudarão a verificar se o programa atingiu
seu objetivo educativo. A fase testa, portanto, o sucesso do programa, investigando
as condições contextuais para que o produto possa obter seu melhor resultado e
provendo modelos de uso. A fase formativa é realizada com um pequeno número de
crianças, em testes mais curtos, mas em maior número, normalmente trabalhando
com pares de crianças, sendo produzidos relatórios freqüentes pelos avaliadores. O
foco fica na interface e no design do produto. Ao planejar uma avaliação formativa,
deve estar claro o objetivo do software, pois esse afetará o planejamento de seus
testes. Ao mesmo tempo, durante a avaliação, deseja-se descobrir do que o
programa é capaz, a forma como ele está realmente sendo usado, se está indo além
ou falhando em seus propósitos. A avaliação somativa ocorre após o término do
desenvolvimento do programa. Essa fase é composta de testes mais longos, com
relatórios ocasionais, focados na implementação do material no contexto escolar. O
objetivo é descobrir as qualidades do software e compará-lo com outras formas de
ensino. Então, nessa fase, é possível descobrir as potencialidades do software,
assim como sua possível integração com outras técnicas de ensino e aprendizagem.
Em geral, os métodos de coleta de dados nas duas fases são os mesmos, com a
30
ressalva de que, na fase somativa, uma maior participação dos docentes é
necessária. A Tabela 1 detalha a relação entre objetivos dos estudos avaliativos e os
métodos de coleta de dados de que necessitarão.
31
TABELA 1 – Objetivos da avaliação X Métodos de coleta de dados
Objetivos da Métodos de Descrição

avaliação coleta de dados
As necessidades das crianças são reveladas por meio da
sua performance e descrições do conteúdo e procedimentos
realizados sobre o assunto. É solicitado que as crianças
Levantamento de realizem uma tarefa (analisar algum dado ou explicar um
Entrevistas/
necessidade das fenômeno). Por meio de perguntas sobre como e por quê as
Questionários
crianças crianças realizaram a tarefa de determinada forma, o
avaliador pode obter bom entendimento de como eles
pensam no assunto, do seu nível de compreensão sobre o
item em questão.
Uma vez que o software esteja pronto para testes, deseja-
se verificar se um usuário novato irá compreendê-lo, de
acordo com as intenções do programa. A observação
Uso (Usabilidade) Observação detalhada de como um usuário utiliza o software, de como
decide o que fazer, de quanto tempo gasta em uma tarefa, se
o ambiente o faz se sentir confortável podem mostrar se o
programa está atendendo às necessidades das crianças.
Se o programa estiver funcionando relativamente bem, é
importante testar se ele atinge seus objetivos. Isso pode ser
testado por meio de Pré/Pós -testes. Mas, às vezes, é por
Pré/Pós-testes, meio de discussões das crianças durante o uso do programa
Entrevistas/ que percebemos a qualidade do aprendizado delas. A
Questionários, observação da performance em tarefas indicará o quanto
Efetividade
Observação, entenderam e aprenderam na tarefa.
Relatos de Docentes que continuarem trabalhando com as crianças
docentes posteriormente, com outros métodos de ensino, podem dar
seu relato sobre o trabalho, possibilitando ao avaliador fazer
julgamentos sobre a aprendizagem com a ferramenta e se ela
está se integrando corretamente no projeto pedagógico.
O valor percebido é importante porque é o que leva a
melhor uso do programa por docentes e crianças. As ações e
atitudes de docentes e crianças podem ser descritas por meio
de perguntas, embora deva-se lembrar que crianças
Entrevistas/ normalmente fornecem respostas positivas em relação a
Questionários, software.
Valor percebido
Relatos de O valor percebido será afetado pelo contexto de ensino (a
docentes forma como as crianças são introduzidas no programa, a
preparação que fazem, o suporte que recebem enquanto
usam, as tarefas pós -trabalho, o quanto usam, se substitui ou
não outras formas de ensino). Então, o valor percebido é uma
avaliação do programa relativo ao seu contexto de uso.
Se um programa está completamente integrado num curso
ou num ambiente de ensino, dentro de um projeto
pedagógico, então é apropriado realizar análise de seu valor
comparado com outros métodos de ensino do mesmo
Relato de conteúdo. Se não está sendo usado adequadamente, então
docentes, não poderá ser julgado em comparação com outras técnicas
Valor comparativo
Medidas de custo já bem-estabelecidas. Condições apropriadas são raras, por
e benefícios isso a falta de informação comparativa sobre informática na
educação. Quando um programa está sendo usado
apropriadamente, faz sentido estudar seus custos e
benefícios comparativos, julgados por meio de medidas de
valor percebido.
32
Os métodos de coleta de dados para a avaliação de software educacional
infantil listados na Tabela 1 estão detalhados a seguir.
§ Observação: técnica de observação das crianças enquanto utilizam o software

para a produção de dados para a avaliação. Podem ser levantadas informações
de como elas trabalham, o que fazem com o programa, se discutem sobre o
tema, se escrevem, se consultam informações fora, fornecendo ao avaliador
grande ajuda na elaboração de um modelo de uso do software em sala de aula;
§ Monitoração: programa que registra todas as ações que a criança realiza no

software educacional infantil. É uma forma informatizada da técnica de
observação.
§ Pré/Pós-testes: testes que comparam o conhecimento da criança antes e depois

do uso do programa, analisando seu aprendizado;
§ Testes on-line: questionários que coletam as respostas das crianças enquanto

realizam tarefas, possibilitando ao avaliador analisar posteriormente os
resultados da sessão. São utilizados quando os Pré/Pós-testes são inapropriados
(por exemplo, em avaliações em que as crianças são desniveladas);
§ Entrevistas/Questionários: coleta do ponto de vista do participante a respeito do

software. Podem ser realizadas por meio de perguntas gerais (entrevistas
desestruturadas), sendo conduzidas num estágio em que o avaliador não está
certo dos assuntos primordiais a serem tratados ou por meio de perguntas
direcionadas (entrevistas estruturadas), revelando as percepções dos
participantes em um tópico que o avaliador acredita ser importante do programa.
Usar entrevistas ao invés de Pré/Pós-testes possibilita que o avaliador pergunte
mais detalhes, para que possa entender completamente o ponto de vista do
participante. Pode-se usar entrevistas com crianças para se descobrir interesses,
tendo o cuidado para que essas sejam adaptadas às suas idades. Perguntas
realizadas após o uso do programa sobre a opinião de crianças são importantes,
pois fornecem retorno quanto às qualidades motivacionais do software, quanto à
sua utilização, quanto à sua adequação a um grupo, mas não necessariamente
relatam a qualidade do software.
33
§ Relato de docentes: questionários ou entrevistas que objetivam retorno dos(as)
docentes sobre o projeto. É uma forma de testar a validade do programa,
especialmente se permitir que seja comparado o programa com outros métodos
de aprendizagem. Os relatos são particularmente importantes nas avaliações
somativas. Também podem ser usados para determinar o contexto de uso do
software: a forma como as crianças são apresentadas ao programa, a
preparação que recebem, o suporte que têm disponível durante seu uso, se
substitui outras formas de ensino, entre outros. Tudo isso contribui para a
descoberta do valor percebido e comparativo do software.
§ Custo: estimativas do custo e dos recursos gastos num projeto, sem

comparações com outras estratégias de ensino. Essa comparação de custos é
tarefa difícil, pois normalmente não são conhecidos os custos referentes às
outras formas de aprendizagem;
§ Benefícios: análises e comparações dos benefícios percebidos de um software

educacional infantil. Os benefícios pedagógicos existem e justificam os estudos
das avaliações formativas e somativas, mas outros vários fatores, como custo e
adequação, também influenciam nestas, devendo, portanto, ser levados em
conta.
Essas duas propostas evidenciam a preocupação da verificação da

Usabilidade de programas infantis educacionais durante a sua produção. Entretanto,
sabe-se que a maioria dos programas existentes no mercado não foi desenvolvida
por meio de processos similares, resultando na falta de garantia de sua qualidade
(CRONJE, 2001). Por isso, muito se tem discutido sobre a avaliação de qualidade de
software educacional infantil (GAMEZ, 1998; CAMPOS, 2001; VIEIRA, 2002; SILVA,
2002; RAMOS, 1991; SILVA, 1998). Surge a necessidade de avaliá-los criticamente
e criteriosamente, pois são eles que determinam as possibilidades de uso dos
computadores na educação. Segundo VIEIRA (2002), “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”. Nessa perspectiva, uma
avaliação bem criteriosa, além de analisar as questões de Usabilidade do software,
34
pode contribuir para indicar se o software é adequado para a proposta pedagógica
desejada.
2.7.4. Avaliações de qualidade de software educacional
Dois modelos de avaliação para programas educacionais prontos

colaboraram mais fortemente durante este estudo (CAMPOS, 1994; GAMEZ, 1998).
Como esses modelos não fazem referência a um público-alvo determinado, conclui-
se que são modelos de avaliações de programas educacionais para adultos ou
crianças. As avaliações foram baseadas no uso de listas de verificação (checklists),
que fornecem perguntas referentes a questões educacionais e de Usabilidade dos
programas.
No modelo de CAMPOS (1994), são apresentados objetivos, fatores,

subfatores, critérios e processos de avaliação para que seja realizada a avaliação da
qualidade. Os objetivos determinam as propriedades gerais que o produto deve
possuir e os fatores determinam a qualidade do ponto de vista dos diferentes
usuários do produto. Os fatores são decompostos em subfatores, que são avaliados
por meio de critérios predeterminados. A Figura 2 representa o modelo proposto.
35
Objetivos Fatores Subfatores
Clareza
Concisão
Legibilidade
Estilo
Confiabilidade da
Representação
Modularidade
Q
U Disponibilidade
A Manipulabilidade
L Estrutura
I
D Rastreabilidade
A Manutenibilidade
D
E Oportunidade
Oparacionalidade
D Amenidade ao uso
E Portabilidade
P Utilizabilidade Reutilizabilidade
R
O Eficiência
G
R Rent abilidade
A
M
Avaliabilidade
A Precisão
S
Fidedignidade Completeza
Confiabilidade
conceitual Necessidade
Robustez
Integridade
Segurança
FIGURA 2 – Modelo de avaliação de software proposto por CAMPOS, 1994.
36
Já o modelo de GAMEZ (1998) é formado por três etapas consecutivas:
classificação, avaliação e contextualização. A etapa de classificação tem como
objetivo determinar a modalidade do software educacional (tutorial, exercício e
prática, simulador, hipertexto) e a identificação de sua abordagem pedagógica. Na
etapa seguinte, avalia-se a conformidade do software educacional em relação aos
critérios e subcritérios definidos por meio de um processo de avaliação de software
educacional. A Figura 3 sintetiza essa etapa. A etapa de contextualização visa a
auxiliar no processo de tomada de decisão sobre uma provável aquisição, mediante
a adequabilidade do produto ao contexto específico da instituição.
37
MÓDULO DE AVALIAÇÃO Presteza
Qualidade das opções

Avaliação da documentação Avaliação da produto de ajuda
Legibilidade
Dados de identificação Presteza
Condução
Feedback imediato
Qualidade da Legibilidade Agrupamento e distinção
informação impressa por localização
Agrupamento e distinção
Densidade Informacional de itens
Agrupamento e distinção
Consistência por formato
Flexibilidade
Adaptabilidade
Significado de códigos e Consideração da
denominações experiência do utilizador
Ações explícitas do
utilizador
Controle explícito
Controle do utilizador
Recursos de apoio à
compreensão dos Correção de erros
conteúdos
Qualidade das
Gestão de erros mensagens de erro
Avaliação da Proteção contra erros

aprendizagem
Carga Informacional
Carga de trabalho Concisão
Brevidade
Significado de códigos e Ações mínimas
Densidade
denominações
informacional
Homogeneidade
Compatibilidade
FIGURA 3 − Estrutura da etapa de avaliação de GAMEZ, 1998

Cabe aqui elencar o comentário de BEGOÑA E SPECTOR 8, citado por SILVA
(2002), sobre as avaliações de programas educacionais prontos. Para os autores,
existem três tipos dessas avaliações: orientada para o produto, orientada para o
usuário e orientada para o contexto.
A avaliação orientada para o produto consiste na inspeção de conformidade

do software educacional em relação a critérios pedagógicos ou de Usabilidade que
são separados em diversas seções, como conteúdo, condução, erros, entre outras.
A avaliação pode ser realizada por um ou mais profissionais por meio de listas de
verificação previamente preparadas para orientar a apreciação do programa. Nessas
avaliações, o software não é avaliado em seu contexto real de aplicação ou com
usuários potenciais. Pode-se dar como exemplo desse tipo de avaliação os modelos
já mencionados de GAMEZ (1998) e CAMPOS (1994).
A avaliação orientada para o usuário promove a interação entre ele e o

software, avaliando os efeitos do programa no usuário. As avaliações deste tipo
comparam a aprendizagem do(a) aluno(a) antes e depois do uso de software, mas
não abrangem outros aspectos importantes, como as interações do aprendiz com
outros aprendizes ou com o(a) docente. Outro ponto crítico seria a falta da análise
dos níveis de motivação e de ansiedade.
A avaliação orientada para o contexto seria a avaliação do software em seu

ambiente de aplicação real. Os resultados desse nível de avaliação podem ser muito
úteis na melhoria da qualidade do software educacional, mas infelizmente esse tipo
de avaliação não é freqüentemente utilizado.
A maioria dos estudos se preocupa apenas com um dos três níveis de

avaliação mencionados (SILVA, 2002). Entretanto, acredita-se que tais níveis não
são completamente independentes, e que uma avaliação completa de software
educacional deve considerar o produto, os usuários, o contexto e as óbvias
interdependências. O software educacional não deve ser visto como um objeto
isolado, mas como uma entidade integrada − um produto usado por pessoas em um
contexto para atingir vários objetivos. Esse tipo de abordagem pode tornar o
8
BEGOÑA, G., SPECTOR, J. M. Evaluating automated instructional design systems: A complex
problem. Educational Technology, New Jersey, v.34, n.5, p.37-46, 1994.
processo de avaliação mais complexo, porém apresenta probabilidade maior de
fornecer resultados mais significativos e, portanto, auxiliar no melhor uso da
tecnologia.
40
3. DEFINIÇÃO DA METODOLOGIA
3.1. Introdução
A Metodologia de Avaliação de Software Educacional Infantil aqui proposta, a

MAQSEI, foi elaborada a partir do método de definição de processo pessoal de
Watts S. Humphrey (HUMPHREY, 1995). A avaliação de software educacional
infantil necessita de um processo 9 bem-definido para sua compreensão, definição de
passos e condução por ser uma atividade reprodutível, como a escrita de um
programa ou a análise de um requisito. “Um processo é definido quando tem
documentação que detalha: o que é feito (produto), quando (passos), por quem
(agentes), as coisas que usa (insumos) e as coisas que produz (resultados)”.(PAULA
FILHO, 2001). Portanto, a definição de processo facilita a sua produção ao planejar,
projetar, guiar suas tarefas e ajudar na melhoria de sua forma por meio de roteiros,
formulários e recomendações. HUMPHREY (1995) oferece um procedimento para o
desenvolvimento de processos de forma clara e objetiva. Executou-se o que foi
proposto por HUMPHREY (1995) para o desenvolvimento do processo de avaliação.
O processo de HUMPREY é genérico, podendo ser utilizado para o desenvolvimento
de processos de natureza variada. Sendo assim, outras revisões de modelos de
avaliação de software (CAMPOS, 1994; GAMEZ, 1998; GARCIA 2001; PLUM e
TELL, 2000 ; HIX, 1993; RUBIN, 1994) também foram estudados e utilizados na
elaboração da MAQSEI. A seguir são descritos os passos adaptados de
HUMPHREY (1995), que foram seguidos para o desenvolvimento da MAQSEI.
3.2. Definição e passos do processo
Na definição da MAQSEI, adaptaram-se os passos sugeridos por

HUMPHREY (1995) para o desenvolvimento de um processo, conforme ilustrado no
diagrama da Figura 4. Cada um dos passos será explicado nas próximas seções.
9
Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades,
métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente está
associada a um ou mais resultados concretos finais, que são os produtos da execução do processo
(PAULA FILHO, 2001).
41
1 - Determinação dos atributos 2 - Determinação dos atributos
do produto do processo
3 - Determinação das tarefas e

técnicas do processo
4 - Definição das metas e dos

critérios de qualidade do
processo
5 - Caracterização do
processo
6 - Estruturação do
processo
7 – Definição das fases

do processo
8 – Produção de
artefatos
9 – Validação do
processo
FIGURA 4 – Diagrama dos passos seguidos durante o desenvolvimento da MAQSEI
42
3.2.1. Determinação dos atributos do produto
A definição de um processo (MAQSEI) deve considerar os objetivos do

produto a ser gerado (avaliação do programa). Para garantir o levantamento correto
de todas as necessidades envolvidas, conforme sugerido por HUMPHREY (1995),
adotou-se um método similar ao denominado quality function deployment method −
QFD (HUMPHREY 1995). Esse método provê um modelo consistente para fazer a
correlação entre os usuários do produto e as características do processo. Uma
simplificação do QFD foi então adotada, para assegurar que as prioridades do
processo fossem levadas em consideração. De acordo com o método, devem ser
levantados:
1. A natureza do produto que o processo irá produzir;
2. Os atributos principais do produto;
3. As prioridades dos atributos do produto que podem ser classificadas

em: Alta Prioridade (AP), Média Prioridade (MP), Necessário (N) ou
Desejável (D);
4. As tarefas ou técnicas do processo necessárias para a produção dos

atributos do produto;
5. As correlações entre as tarefas ou técnicas do processo e atributos do

produto. Essas podem ser classificadas em: Forte (F), Média (M) ou
Baixa (B).
Resumidamente, o método levanta os atributos do produto e suas prioridades,

incluindo as tarefas e técnicas do processo que garantem que tais atributos sejam
contemplados. Ao se definir as prioridades de atributos de um produto, cresce a
probabilidade do desenvolvimento de um processo capaz de gerar um produto de
melhor qualidade.
Para a MAQSEI, foram levantados todos os itens acima (Tabela 2). A

natureza do produto – avaliação de software educacional infantil − foi considerada
um serviço, pois servirá como auxílio na seleção de programas educacionais infantis
por escolas. A primeira linha da Tabela 2 lista os principais atributos do produto e
43
suas prioridades. Os pesos10 10, 7, 4 e 1 foram arbitrariamente selecionados para os
atributos de Alta prioridade (AP), Média Prioridade (MP), Necessários (N) e
Desejáveis (D). A primeira coluna lista as tarefas ou técnicas do processo
necessárias para a produção dos atributos do produto. Em cada cruzamento entre
atributo e tarefa/técnica, foi listada a correlação entre eles. Os pesos 10, 7 e 4 foram
novamente arbitrariamente selecionados para as correlações Forte (F), Média (M) e
Baixa (B), respectivamente. Ainda nos cruzamentos foram listados os valores
obtidos pela multiplicação do valor da prioridade do atributo pelo valor da correlação
entre atributo e tarefa/técnica. Essas multiplicações são somadas linha a linha, o
valor da soma é armazenado na penúltima coluna e o valor percentual, na última
coluna. A partir desses percentuais obteve-se a ordem de importância de cada tarefa
ou técnica do processo necessária para a produção dos objetivos do produto, no
caso, a avaliação de software educacional infantil.
10
Todos os pesos selecionados neste estudo são somente uma sugestão de uso, podendo ser
personalizados para contemplar situações e objetivos específicos.
44
TABELA 2 − Atributos do produto X Tarefas e técnicas do processo
Levantar o
Verificar Verificar
Atributos do Verificar Verificar Produzir Levantar Verificar tempo, a
Verificar heurísticas Levantar valor
produto contexto valor recomenda- necessidade recursos infra-
efetividade técnicas e defeitos compa-
X pedagógico percebido ções das crianças usados estrutura e Total %
(AP) pedagógicas (AP) rativo
Tarefas e técnicas (AP) (AP) (AP) (AP) (MP) custo
Peso 10 (AP) Peso 10 (D)
do processo Peso 10 Peso 10 Peso 10 Peso 10 Peso 7 (N)
Peso 10 Peso 1
Peso 4
Reconhecimento
F/100 B/40 M/70 F/100 B/40 M/70 F/70 M/28 518 8,19%
do software
Entrevistas com
F/100 M/70 B/40 F/100 B/40 B/40 M/70 B/28 B/16 F/10 514 8,13%
docentes
Plano de testes M/70 F/100 B/40 B/40 F/100 B/28 F/40 418 6,61%
Pré e Pós-testes F/100 B/40 M/70 B/16 226 3,57%

Entrevistas com
M/70 B/16 B/4 90 1,42%
crianças
Questionário com
B/40 B/40 M/70 B/40 B/40 B/16 B/4 250 3,95%
crianças
Observação M/70 F/100 F/100 F/100 F/100 F/100 F/100 F/70 F/40 M/7 787 12,45%
Filmagem M/70 F/100 F/100 F/100 F/100 F/100 F/100 F/70 F/40 B/4 784 12,40%
Análise dos
M/70 F/100 F/100 M/70 F/100 F/100 M/70 M/49 F/40 M/7 706 11,17%
dados
Assessoria de
profissionais das
F/100 F/100 F/100 F/100 F/100 F/100 F/100 M/49 M/28 F/10 787 12,45%
áreas técnica e
pedagógica
Participação de
crianças nos B/40 F/100 F/100 F/100 M/70 M/70 F/100 B/28 M/28 F/10 646 10,22%
testes
Realização dos
testes em
F/100 F/100 F/100 B/40 B/40 F/100 F/70 F/40 M/7 597 9,44%
ambiente familiar
às crianças
45
45
3.2.2. Definição dos atributos do processo
Além dos atributos do produto, que contemplam mais as necessidades do

usuário (no caso de escolas, docentes ou pais), um processo deve abranger
também atributos que contemplem as necessidades dos usuários do processo (no
caso dos avaliadores). Para abrangê-los, HUMPHREY (1995) sugere que sejam
definidos:
§ Os atributos do processo;
§ As prioridades desses atributos, que podem ser classificadas em: Alta Prioridade
(AP), Média Prioridade (MP), Necessários (N) e Desejáveis (D);
§ As tarefas ou técnicas do processo necessárias para atingir esses objetivos;
§ As correlações entre tarefas/técnicas do processo e seus atributos. Essas podem

ser classificadas em: Forte (F), Média (M) ou Baixa (B).
A partir dos levantamentos anteriores, similarmente à Tabela construída no

item 3.2.1, foi criada para a MAQSEI uma tabela cruzando os atributos do processo
com as tarefas/técnicas do processo necessárias para sua obtenção (Tabela 3). A
primeira linha da tabela contém os atributos do processo, classificados segundo sua
prioridade. Os pesos 10, 7, 4 e 1 foram arbitrariamente selecionados para Alta
Prioridade (AP), Média Prioridade (MP), Necessários (N) e Desejáveis (D) (apesar
de nenhum atributo ter sido considerado como Necessário). A primeira coluna lista
as tarefas ou técnicas do processo necessárias para a obtenção dos seus atributos.
Em cada cruzamento entre atributo e tarefa/técnicas, foi listada a correlação entre
eles. Os pesos 10, 7 e 4 foram arbitrariamente selecionados para as correlações
Forte (F), Média (M) e Baixa (B). Os cálculos realizados para a obtenção dos
resultados são os mesmos da Tabela 2. A partir desses cálculos produziu-se uma
lista, em ordem de importância, das tarefas ou técnicas do processo necessárias
para a produção dos atributos do processo.
46
TABELA 3 − Atributos do processo X Tarefas e técnicas do processo
Possibilidade de
Possibilidade de Apoiar a Apoio à
acompanhamento
planejamento da avaliação melhoria da melhoria do Redução
Atributos do processo (tempo já gasto,
(estimar custos, prazos, qualidade do próprio de custos
X comparação do Total %
definir número de processo processo (D)
Tarefas e técnicas do processo planejado com o
crianças, entre outros) (AP) (MP) Peso 1
realizado)
(AP) Peso 10 Peso 10 Peso7
(AP) Peso 10
Reconhecimento e Proposta de
F/100 F/100 B/40 B/40 280 9,15%
avaliação do Software
Entrevistas com docentes M/70 F/100 170 5,56%
Plano de testes F/100 M/70 F/100 F/10 280 9,15%
Pré e Pós-testes B/40 M/70 110 3,59%
Entrevistas com crianças B/40 M/70 110 3,59%
Questionário com crianças B/40 M/70 110 3,59%
Observação B/40 F/100 F/100 F/70 310 10,13%
Filmagem F/100 F/100 F/100 F/70 370 12,09%
Análise dos dados F/100 F/100 F/100 M/49 349 11,41%

Assessoria de profissionais das
F/100 B/40 F/100 F/70 310 10,13%
áreas técnica e pedagógica
Participação de crianças nos testes B/40 F/100 140 4,58%
Realização dos testes em ambiente
B/40 F/100 M/7 147 4,80%
familiar às crianças
Uso de processo de definição F/100 F/100 F/100 F/70 B/4 374 12,22%
47
3.2.3. Determinação das tarefas e técnicas do processo
As duas tabelas (Tabelas 2 e 3) produziram dois conjuntos de prioridades das

tarefas e técnicas do processo: um que mapeia as tarefas e técnicas do processo
aos atributos do produto, e o outro que mapeia as tarefas e técnicas do processo
aos atributos do processo. Esses elementos foram então integrados11, produzindo
uma só lista de classificação da importância das tarefas e técnicas necessárias da
MAQSEI, como mostra a Tabela 4.
TABELA 4 – Ranking da integração das prioridades do processo e do produto
Tarefas e técnicas necessárias da Correlação Correlação com Total = produto +

MAQSEI com o produto o processo processo / 2
Filmagem 12,40% 12,09% 12,25 %
Análise dos dados 11,17% 11,41% 11,29 %
Observação 12,45% 10,13% 11,29 %

Assessoria de profissionais das áreas
12,45% 10,13% 11,29 %
técnica e pedagógica
Reconhecimento e Proposta de avaliação
8,19% 9,15% 8,67 %
do Software
Plano de testes 6,61% 9,15% 7,88 %
Participação de crianças nos testes 10,22% 4,58% 7,40%

Realização dos testes em ambiente familiar
9,44% 4,80% 7,12 %
às crianças
Entrevistas com docentes 8,13% 5,56% 6,85 %
Uso de processo de definição - 12,22% 6,11 %
Questionário com crianças 3,95% 3,59% 3,77 %
Pré e Pós-testes 3,57% 3,59% 3,58 %
Entrevistas com crianças 1,42% 3,59% 2,51 %
11
Neste estudo, os atributos do produto foram considerados tão importantes quanto os atributos do
processo, por isso foram somente somados e divididos por 2. Entretanto, dependendo do caso, pode-
se atribuir pesos ao combiná-los.
48
3.2.4. Definição das metas e dos critérios de qualidade do processo
Após a identificação das principais características da MAQSEI, foi necessário

o levantamento de suas melhorias possíveis. Para tanto, foram relacionados as
metas e os critérios para alcançá-las, conforme descrito na Tabela 5. Esses serviram
como base para se saber quando o processo-alvo havia sido atingido.
TABELA 5 − Metas e critérios de qualidade do processo
Nº Meta Critério
Pelo menos um(a) docente de cada escola

Entrevistar docentes deve ser entrevistado sobre opiniões e
necessidades.
Todas as crianças que participaram dos

Entrevistar crianças
testes devem ser entrevistadas.
Estudar uma forma

Realizar testes com Pelo menos um teste de cada software deve
1 melhor de se avaliar crianças na escola ser feito na escola.
software
Usar metodologia para

Todo os testes devem seguir a metodologia.
avaliar
Analisar dados e produzir Todos os testes devem incluir o relatório de

resultados avaliação.
Durante toda a produção da metodologia,

Usar definição de deve-se seguir um método de definição de
processo processo, que guie e oriente o seu
desenvolvimento.
Usar artefatos durante Todos os testes de software devem usar

toda a avaliação. artefatos para coleta e registro dos dados.
Testar e revisar a Produção de várias versões, melhorando a

metodologia metodologia.
Desenvolver uma
Pelo menos um(a) docente de cada escola
metodologia
2 Entrevistar docentes deve ser entrevistado sobre opiniões e
compreensível e de
necessidades.
qualidade
Todas as crianças que participaram dos

Entrevistar crianças
testes devem ser entrevistadas.
Realizar testes com Pelo menos um teste de cada software deve

crianças na escola ser feito na escola
Todos os testes devem seguir a

Usar metodologia para
metodologia e ter todos os artefatos
avaliar
relacionados registrados.
49
Todos os testes devem verificar as
heurísticas pedagógicas e de Usabilidade
de forma qualitativa e analisar cada uma de
Produzir resultados
forma quantitativa, respondendo e
quantitativos e qualitativos
pontuando as questões relacionadas para a
produção de gráfico de conformidade do
software com as heurísticas.
Todos os testes devem utilizar e validar
tanto as heurísticas de Usabilidade quanto
Produzir resultados com
as pedagógicas do software, produzindo
base pedagógica e
resultados baseados nos dois aspectos.
tecnológica
A validação deve comparar os resultados
experimentados com os esperados.
Calcular média de tempo
Em todos os testes, deve-se registrar os
gasto na realização de
tempos gastos em cada tarefa de cada fase.
Custo da tarefas
3 metodologia ser
definido e adequado Propiciar estimativa
O custo deve sempre ser baseado em
adequada de custo de
dados previamente obtidos de tempo gasto.
cada fase da metodologia
3.2.5. Caracterização do processo
Em geral, os esforços para a melhoria de um processo serão mais bem-

sucedidos se forem feitos de forma incremental em vez de uma única e drástica
mudança. Portanto, a definição de um processo deve começar com a definição
simples do trabalho corrente e adicionar melhorias aos poucos. Para o entendimento
do processo até então adotado, houve necessidade de deixar claras as respostas
para as seguintes perguntas:
§ O processo atual é entendido? Seus passos, relações e tempos estão definidos?
§ O processo atual apresenta problemas?
§ Os passos do processo atual têm critérios de entrada e saída?
§ O processo atual é planejado?
§ O processo atual é suficientemente bem-medido para permitir planos de melhora

quantitativa?
§ O processo atual tem uma linha-base?
No caso da MAQSEI, foram consideradas como processo atual dois tipos de

avaliações:
50
§ As avaliações de Usabilidade de software (HIX, 1993), normalmente realizadas
sem considerações para os aspectos pedagógicos e sem adaptações para o
público infantil.
§ As avaliações para programas educacionais (CUPERTINO e OLIVEIRA, 2001;

GAMEZ, 1998), normalmente realizadas com poucas considerações para os
aspectos de Usabilidade e sem adaptações para o público infantil.
Por isso a necessidade da produção de um único processo preciso e detalhado,

que incluísse esses aspectos e adaptações.
3.2.6. Estruturação do processo
A estrutura da MAQSEI foi realizada e começou pela definição de um único

passo, que incluiu múltiplas tarefas. Em seguida, foi definido um subprocesso para
cada tarefa baseado no processo corrente e nas revisões sobre avaliações de
software realizadas (PLUM e TELL, 2000; GAMEZ, 1998; HIX, 1993; RUBIN, 1994;).
Esse refinamento continuou até que se alcançasse um nível razoavelmente
consistente com as metas e necessidades já levantadas do processo.
Foram encontradas as seguintes tarefas e subtarefas para a MAQSEI:
1 – Reconhecer o software e produzir Proposta de avaliação
§ Entrevistar docentes;
§ Familiarizar com o software;
§ Registrar anotações sobre o software;
2 – Planejar os testes para avaliação do software
§ Personalizar a metodologia;
§ Preparar o Plano de testes;
§ Preparar documentos a serem usados:
- Formulário de consentimento;
- Script de orientação;
- Entrevista com crianças;
- Formulário de observação;
51
- Pré e Pós-testes;
- Questionário com crianças;
- Lista de verificação;
§ Selecionar crianças;
§ Preparar ambiente, equipamentos e materiais;
§ Realizar testes de todos os itens;
3 – Realizar os testes
Para cada teste:
§ Preparar o ambiente e os observadores;
§ Cumprimentar e apresentar;
§ Falar o Script de orientação;
§ Aplicar Entrevista com crianças;
§ Aplicar Pré-teste com crianças;
§ Conduzir o teste (ler as tarefas, observar e coletar dados);
§ Aplicar Pós-testes com crianças;
§ Aplicar Questionário com crianças;
§ Agradecer e gratificar as crianças;
§ Organizar dados e papéis;
§ Fazer acertos no teste;
4 - Analisar os dados e Produzir relatório de avaliação do software
§ Assistir às filmagens;
§ Transcrever e resumir os dados;
§ Verificar heurísticas qualitativamente;
§ Verificar heurísticas quantitativamente;
§ Produzir de recomendações e resultados;
52
A partir de então, essas tarefas e subtarefas foram transformadas nas fases
do processo, conforme descrito no próximo passo.
3.2.7. Definição das fases do processo
Para a definição das fases de um processo, deve-se ter pleno conhecimento

do propósito, dos agentes responsáveis, critérios de entrada e saída, tarefas e
relacionamentos de cada uma das fases. Para a descrição das fases da MAQSEI,
utilizou-se o modelo sugerido por HUMPHREY (1995), em que todos esses itens são
discriminados. As Figuras 5, 6, 7 e 8 mostram o preenchimento do modelo para as
fases da MAQSEI.
53
Fase de Reconhecimento e Proposta de avaliação do software
Propósito: Familiarização com software a ser testado e Produção de Proposta de avaliação
Responsável: Avaliador de software
Entrada
Condição Responsabilidade
Conseguir autorização para entrar na escola Avaliador
Ter acesso ao software usado na escola Avaliador
Ter padrão de documento de Reconhecimento do software Avaliador
Ter padrão de Proposta de avaliação do software Avaliador
Itens de entrada Fontes

Padrão de documento de Reconhecimento do software MAQSEI
Padrão de Proposta de avaliação do software MAQSEI
Tarefas
Nome Referências
Entrevistar docentes da escola -
Familiarizar com o software -
Registrar anotações sobre o software Documento de Reconhecimento do software
Estimar prazos e custos Proposta de avaliação do software
Saída
Condição
Término do documento de Reconhecimento do software
Término da Proposta de avaliação do software
Revisão de todos os documentos
Nomes do produto Destinação

Reconhecimento do software Próxima fase
Proposta de avaliação do software Próxima fase e fase de Análise dos dados e
Produção do Relatório final de avaliação
Próximo
Nome Condição
Fase do Planejamento do teste Todas as condições de saída
FIGURA 5 − Definição da fase de Reconhecimento e Proposta de avaliação do software
54
Fase de Planejamento de testes
Propósito: Preparar ambiente, equipamentos e materiais para os testes com o software
Entrada
Ter concluído a fase anterior Avaliador
Ter padrões de documentos necessários Avaliador
Conhecer bem a MAQSEI Avaliador
Reconhecimento do software Fase anterior
Proposta de avaliação do software Fase anterior
Padrão de Plano de testes MAQSEI
Padrão de Formulário de consentimento MAQSEI
Padrão de Script de orientação MAQSEI
Padrão de Entrevista com crianças MAQSEI
Padrão de Formulário de observação MAQSEI
Padrões de Pré e Pós-testes MAQSEI
Padrão de Questionário com crianças MAQSEI
Padrão de Lista de verificação MAQSEI
Tarefas
Nome Referências
Personalizar a metodologia Reconhecimento do software
Preparar o Plano de testes Padrão de Plano de testes
Preparar todos os documentos necessários Padrões de Formulário de consentimento,
Script de orientação, Pré-teste, Pós-teste,
Formulário de observação, Entrevista e
Questionário com crianças
Preparar Lista de verificação -
Selecionar crianças -
Preparar ambiente, equipamentos e materiais -
Testar o teste -
Saída
Condição
Plano de testes concluídos
Todos os documentos preparados
Todos os itens conferidos
Teste testado
Plano de testes Próximas duas fases
Formulário de consentimento Próxima fase
Script de orientação Próxima fase
Entrevista com crianças Próximas duas fases
Formulário de observação Próximas duas fases
Pré/Pós-testes Próximas duas fases
Questionário com crianças Próximas duas fases
Lista de verificação Próxima fase
Próximo
Nome Condição
Fase de Realização dos testes Todas as condições de saída
FIGURA 6 − Definição da fase de Planejamento dos testes
55
Fase de Realização dos testes
Propósito: Realizar testes com o software usando a metodologia

Entrada
Plano de testes concluídos Avaliador
Formulários, testes, script, Entrevista e Questionário com Avaliador
crianças concluídos
Todos os itens conferidos Avaliador
Teste testado Avaliador
Plano de testes Fase anterior
Formulário de consentimento Fase anterior
Script de orientação Fase anterior
Entrevista com crianças Fase anterior
Formulário de observação Fase anterior
Pré/Pós-testes Fase anterior
Questionário com crianças Fase anterior
Lista de verificação Fase anterior
Tarefas
Nome Referências
Realizar os testes. Para cada teste:
§ Preparar o ambiente e os observadores
§ Cumprimentar e apresentar
§ Falar Script de orientação
§ Aplicar Entrevista com crianças
Script de orientação, Entrevista com
§ Aplicar Pré-teste com crianças
crianças, Pré-teste, Formulário de
§ Conduzir o teste (ler tarefas, observar e coletar
observação, Pós-teste, Questionário
dados)
com crianças
§ Aplicar Pós-testes com crianças
§ Aplicar Questionário com crianças
§ Agradecer e gratificar as crianças
§ Organizar dados e papéis
§ Fazer acertos no teste
Registro das propostas de melhoras
Modificar documentos
no processo
Saída
Condição
Ter realizado todos os testes
Ter dados coletados organizados em papéis e fitas
Plano de testes Próxima fase
Formulário de observação Próxima fase
Entrevista com crianças Próxima fase
Pré/Pós-testes Próxima fase
Questionário com crianças Próxima fase
Fitas com filmagem dos testes Próxima fase
Próximo
Nome Condição
Análise dos dados e Produção de Relatório final de Todas as condições de saída
avaliação
FIGURA 7 − Definição da fase de Realizaçao dos testes
56
Fase de Análise de dados e Produção do Relatório final de avaliação
Propósito: Analisar os dados coletados para produção do Relatório final de avaliação do software
Entrada
Ter concluído os testes Avaliador
Ter dados organizados em papéis e fitas Avaliador

Proposta de avaliação do Software Primeira fase
Plano de testes Fase anterior
Formulário de observação Fase anterior
Entrevista com crianças Fase anterior
Pré/Pós-testes Fase anterior
Questionário com crianças Fase anterior
Fitas Fase anterior
Padrão de documento de Resumo de dados MAQSEI
Padrão de documento de Relatório final de
MAQSEI
avaliação
Tarefas
Nome Referências
Assistir a filmagens Fitas e Formulário de observação
Transcrever e resumir dados Padrão de documento de Resumo de dados
Verificar heurísticas qualitativamente Padrão de Relatório final de avaliação e Heurísticas
Verificar heurísticas quantitativamente Padrão de Relatório final de avaliação e Heurísticas
Produzir recomendações e resultados Padrão de Relatório final de avaliação
Saída
Condição
Ter analisado todos os papéis, documentos e fitas referentes ao teste
Ter concluído e revisado o Relatório final de avaliação
Resumo de dados -
Relatório final de avaliação Apresentação a interessados
Próximo
Nome Condição
- -
FIGURA 8 − Definição da Fase de Análise de dados e Produção do Relatório final de avaliação
57
3.2.8. Produção dos artefatos
Definidas as fases, foram produzidos os artefatos para cada uma. Eles foram
elaborados a partir da análise de vários modelos existentes: RUBIN (1994), PLUM e
TELL (2000), GAMEZ (1998), PAULA FILHO (2001) e da adaptação desses à
necessidade do trabalho. Eles podem ser vistos nos Anexos I a VIII. O diagrama da
Figura 9, por meio da notação UML 12, ilustra as fases da MAQSEI e seus artefatos
produzidos ou consumidos. A Tabela 6 explica os símbolos usados no diagrama.
TABELA 6 − Símbolos do diagrama de fases e artefatos

Símbolo Descrição
Retângulo ovalado Fase
Retângulo Artefatos consumidos ou produzidos
Seta cheia Relação de precedência por fase
Seta pontilhada Consumo ou produção de artefato por fase
Pequeno círculo cheio Estado inicial
Círculo cheio dentro de círculo vazio Estado final
12
UML – Unified Modeling Language (RUMBAUGH, et al., 1999)
58
Reconhecimento do software;
Reconhecimento e Proposta de avaliação do software.
Proposta de avaliação
Reconhecimento do software;
Proposta de avaliação do software;
Formulário de consentimento;
Lista de verificação;
Script de orientação;
Planejamento Plano de testes;
dos testes Entrevista com crianças;
Pré e Pós-testes;
Formulário de observação;
Questionário com crianças.
Formulário de consentimento;
Realização Lista de verificação;
dos testes Script de orientação;
Plano de testes;
Entrevista com crianças;
Pré e Pós-testes;
Questionário com crianças.
Análise de dados e Proposta de avaliação do software;

Produção de Plano de testes;
Relatório final de Entrevista com crianças;
avaliação Pré e Pós-testes;
Questionário com crianças,
Resumo de Dados;
Relatório final de avaliação.
FIGURA 9 − Diagrama de fases e artefatos
3.2.9. Validação do processo
A primeira validação de um processo deve ser um teste com protótipo ou

pequeno projeto. Quanto antes problemas na metodologia forem levantados, menor
serão o custo e o esforço para solucioná-los. Por isso, quanto mais bem-realizado
for esse primeiro teste, menores serão as chances de aparecem problemas
futuramente. Concluído esse teste, pode-se utilizar o processo em programas mais
elaborados.
59
A MAQSEI foi pela primeira vez utilizada neste estudo em teste piloto com um
programa educacional infantil simples 13, sem a participação de crianças. Todas as
fases, tarefas e artefatos da metodologia foram revisados, verificando perguntas
mal-entendidas e possíveis defeitos.
Concluído esse primeiro teste, a MAQSEI pôde começar a ser utilizada e

validada em duas situações: aplicando-a em avaliações de vários programas
educacionais infantis e durante o desenvolvimento de software educacional infantil.
Cada uma dessas situações será detalhada a seguir.
3.2.9.1. Validação da MAQSEI em avaliações de software

educacional infantil
A validação da MAQSEI por meio da sua utilização em avaliações de software

educacional infantil começou com a escolha dos programas a serem avaliados.
Primeiramente, tentou-se levantar e classificar os programas educacionais infantis
gratuitos existentes, com o objetivo de selecionar alguns para avaliação. Foram
feitas pesquisas em vários sites nacionais e internacionais e centenas de
exemplares foram encontrados. A maioria desses programas era demasiadamente
simples ou não envolvia aspectos didáticos, o que tornaria o trabalho de avaliação
improdutivo. Por esses motivos, o trabalho mostrou-se inviável e a opção escolhida
foi a avaliação de programas já em uso por escolas, já implantados em sala de aula.
Foi realizada então uma visita a duas escolas públicas da prefeitura, escolas
Arthur Versiane e Caio Líbano, para apresentação do trabalho e possível acordo de
realização de testes. Entretanto, a atual situação dessas escolas públicas mostrou-
se ainda um pouco distante do esperado. Nelas, a implantação dos laboratórios de
informática era recente 14 e seus computadores estavam sendo usados somente
como fonte de acesso a Internet, a serviço de mensagens e uso de aplicativos
comerciais. A utilização de software educacional infantil ainda era uma meta a ser
implementada. Tal fato impossibilitou que o trabalho fosse desenvolvido com a
13
Programa Pintando e Descobrindo − Coleção Educacional Tia Tania − Megafile ltda.
www.megafile.com.br
14
Os laboratórios haviam sido montados por meio do Programa Nacional de Informática na
Educação, PROINFO.
60
parceria dessas escolas. Somente uma pesquisa de perfil e opinião com docentes15
foi realizada nessas instituições.
Então definiu-se como a próxima etapa do trabalho a procura de escolas

particulares para possível realização das avaliações. Foram visitadas duas escolas:
o colégio Magnum Agostiniano e a Rede Coleguium de Ensino. Nessas escolas
foram realizados testes de avaliação de software em seus laboratórios de
informática, além de pesquisa com docentes. Um dos programas avaliados nas
escolas foi escolhido para ser também avaliado em testes em um laboratório de
Usabilidade. A Tabela 7 descreve os locais e programas avaliados com a MAQSEI.
Cada um desses locais e as avaliações realizadas neles estão detalhados no
Capítulo 7.
TABELA 7 − Laboratórios e programas avaliados com a metodologia
Local Software Fabricante Descrição
Software que trabalha com formas

Dominó Informar
geométricas, cores e números.
Rede Coleguium de Formas Software que trabalha com cores e

Informar
Ensino Geométricas II formas geométricas.
Dominó dos Software que trabalha com números e

Informar
Números operações de adição e subtração.
Software que apresenta quatro

Tabuada no Editora
ambientes (jogos) para a exercitação
Tabuleiro Moderna
Colégio Magnum de multiplicação e divisão.
Agostiniano Software que trabalha a grafia de

Casa Mal
SENAC grupos de palavras da língua
Assombrada
portuguesa.
Laboratório de
Software que trabalha a grafia de
Usabilidade do Casa Mal
SENAC grupos de palavras da língua
Gestus/DCC/ICEx/ Assombrada
portuguesa
16
UFMG
15
O questionário usado na pesquisa encontra-se no Anexo IX.
16
Grupo de estudo de Usabilidade, Departamento de Ciência da Computação, Instituto de Ciências
Exatas, Universidade Federal de Minas Gerais
61
Ainda, após a realização dos testes nessas escolas, foi visitada outra escola
pública, escola Hilda Rabello Matta, que possuía um laboratório de informática onde
programas educacionais eram utilizados como apoio ao ensino, mas infelizmente
não puderam ser realizadas avaliações na instituição devido a imprevistos ocorridos
(vide seção 7.2.3). A pesquisa de perfil e opinião com docentes também foi realizada
nessa escola.
3.2.9.2. Validação da MAQSEI durante o desenvolvimento de

software educacional infantil
A MAQSEI pode ter relação próxima com o ciclo de vida de um software e ser
utilizada em diferentes estágios de seu desenvolvimento. AEDO et al., citados por
SILVA (2002), acreditam que a avaliação de software tem dois objetivos principais:
determinar a eficácia de uma aplicação em uso (avaliações somativas do software) e
fornecer meios para sugerir melhorias em programas em desenvolvimento (a
avaliação formativa é considerada atividade central em processos de
desenvolvimento que visam à Usabilidade). Portanto, a MAQSEI pode ser aplicada
em diversos momentos da produção de um software, inclusive em protótipos nos
estágios iniciais, objetivando desenvolvimento iterativo. A partir dos seus resultados,
o desenvolvedor tem retorno sobre defeitos e modificações necessárias ainda
durante a produção do software, quando o custo de realização das alterações é
muito menor, ajudando também na qualidade pedagógica e técnica do produto
desenvolvido.
A MAQSEI também foi utilizada e validada durante o desenvolvimento de um

software educacional infantil17 por meio de um trabalho de conclusão de curso de
graduação em Ciência da Computação (OLIVEIRA, 2003). O trabalho realizou
avaliações nos protótipos do programa desenvolvido utilizando a MAQSEI. Os
seguintes resultados foram relatados a respeito do uso da MAQSEI durante o
desenvolvimento de um software educacional infantil (OLIVEIRA, 2003):
“A MAQSEI mostrou-se bastante eficiente no levantamento de problemas

de Usabilidade presentes nesse tipo de produto. Apesar de ser voltada para a
avaliação somativa, realizada em softwares já concluídos, a metodologia se
17
O software desenvolvido denomina-se OdontoMania e está descrito no Capítulo 7, item 7.3.
62
adequou muito bem ao processo de desenvolvimento de um produto,
demonstrando poder ser aplicada em avaliações formativas, realizadas em
produtos ainda em implementação…. Ela propicia a coleta de dados mais
precisos e detalhados, além de permitir a avaliação tanto técnica quanto
pedagógica do produto”.
A validação da MAQSEI no desenvolvimento de software educacional infantil

foi um dos experimentos visando ao seu aprimoramento: à medida que a
metodologia ia sendo utilizada, modificações iam sendo realizadas, em um processo
iterativo.
3.3. Considerações sobre o desenvolvimento do processo
3.3.1. Processo evolutivo
O desenvolvimento de um processo normalmente começa por um passo

simples e, gradualmente, vai adquirindo substância. Se o processo começar em um
passo muito planejado, normalmente muito trabalho será perdido. Ao usá-lo, muitos
detalhes listados poderão ser desnecessários. Portanto, deve-se descrever
primeiramente os passos já conhecidos e postergar os desconhecidos. Esse
princípio evolutivo aplica-se a praticamente todo processo: produção de padrões,
fases e passos. Produz-se o inicial, revisa-se, testa-se e melhora-se ao se obter
experiência. Algumas idéias serão confirmadas, outras serão revistas.
A construção da MAQSEI seguiu o processo evo lutivo descrito, haja vista que
a avaliação de um software é uma habilidade que é aprendida e praticada. À medida
que a experiência na preparação e na condução dos testes de avaliação ia sendo
adquirida, métodos e ferramentas que funcionam melhor iam sendo descobertos. A
cada teste realizado com a utilização da MAQSEI, novas propostas de melhoria no
processo iam surgindo e sendo registradas para que servissem de guia para a
próxima atualização do processo. No Capítulo 7, podem-se ver as modificações
registradas durante os testes realizados com a MAQSEI. Esses registros de
propostas de melhora no processo (PMP) mostram os problemas e sugestões de
mudanças. Muitos problemas podem ser detalhes, mas que, no entanto, fazem a
diferença entre um processo inadequado e um processo eficiente.
63
A Figura 10 descreve o processo evolutivo do desenvolvimento da MAQSEI,
seguindo os passos já descritos para o desenvolvimento de um processo. A cada
teste realizado com a MAQSEI, verificam-se se novos problemas ou sugestões de
melhoria (PMP) foram registrados. Se for o caso, essas PMP são revistas, visando à
alteração da metodologia. Esse ciclo continua até quando não houverem mais PMP.
Requisitos e
Planejamento
Submissão das
propostas de Revisão das
melhoras no PMP
Processo (PMP)
Definição das
fases e tarefas Padrões
Sim
Teste Registro das propostas de
melhoras no processo
(PMP)
Refinamentos
necessários?
Não
Metodologia Final
FIGURA 10 − Processo de desenvolvimento da metodologia
64
3.3.2. Percepções possíveis do processo
Segundo HUMPHREY (1995), um processo sofre muitas modificações

durante sua definição. Isso porque o próprio esforço despendido durante a definição
modifica o processo. O autor explica essa idéia descrevendo os tipos de ocorrências
possíveis durante a definição de um processo:
§ Processo percebido: é o que acredita-se fazer. Mas se não houver um processo

definido, será, na verdade, a percepção que se tem do processo.
§ Processo real: é aquele que é feito, com todas as omissões e erros.
§ Processo oficial: é aquele que deveria ser feito, registrado em algum relatório ou
livro.
§ Processo-alvo: é o objetivado, que se deseja alcançar.
Ao se definir um processo, deve-se começar por um processo inicial que

represente a realidade e seguir na direção do processo-alvo. Entretanto,
normalmente esse processo inicial é o processo percebido. Quando ele é testado,
suas omissões ou defeitos sobressaem, mostrando o processo real. Ao realizar as
modificações necessárias para ajustá-lo, começa-se a definir o processo oficial,
aquele que deveria ser feito. Após repetir esse ciclo de testes e modificações várias
vezes, o processo então começará a convergir para o verdadeiro processo inicial. É
somente após transformar os processos percebido, real e oficial no inicial que as
modificações começam a visar ao processo-alvo. Não se consegue evoluir um
processo até que ele seja uma representação razoável do que é realmente feito. Por
isso a definição de um processo agrega qualidade a ele: faz com que omissões e
defeitos sejam identificados e solucionados. A Figura 11 ilustra essa idéia.
65
Processo percebido
o que acredita-se fazer
Processo-alvo
o que se quer fazer
Processo inicial
Processo oficial
Processo real o que deveria ser feito
o que é realmente feito
FIGURA 11 − Os quatro tipos de processo
O processo de desenvolvimento da MAQSEI evidenciou a idéia descrita ao

necessitar realizar ajustes no processo em duas etapas:
§ Ajustes no processo até então utilizado, visando a definir o verdadeiro processo

inicial;
§ Ajustes no processo inicial visando ao processo-alvo.
66
4. DESCRIÇÃO DA MAQSEI
4.1. Introdução
Atualmente a informática se expandiu em toda a sociedade provocando

mudanças de comportamento. Na educação, o crescimento acelerado da oferta de
programas educacionais infantis no mercado tornou difícil sua seleção (CAMPOS,
1994). Como garantir que o software selecionado é de qualidade ou que contribui
para o processo de ensino/aprendizagem?
A metodologia aqui descrita foi desenvolvida com o intuito de responder a

essa pergunta e mostrar um procedimento de avaliação de software educacional
infantil que abranja tanto os aspectos da Usabilidade quanto os pedagógicos. Com
alguma orientação, a MAQSEI poderá ser usada por profissionais da área de
educação, informática e afins que desejem avaliar a qualidade de software
educacional infantil.
A MAQSEI é composta de quatro fases:
1. Reconhecimento e Proposta de avaliação do software;
2. Planejamento dos Testes;
3. Realização dos testes;
4. Análise de dados e Produção do Relatório final de avaliação;
Essas fases serão detalhadas a seguir.
4.2. Fases da MAQSEI
4.2.1. Fase de Reconhecimento e Proposta de avaliação do software
A fase do reconhecimento do software consiste no primeiro contato e na

inspeção do programa a ser avaliado. O avaliador deve usar todas as funções do
software, tomando nota de telas, botões, comandos, mensagens, defeitos e
problemas percebidos. Os detalhes observados objetivam:
§ Disponibilidade de acesso a dados do software a todo momento. Nem sempre o

avaliador dispõe de uma cópia do programa (por exemplo, quando o programa só
está instalado na escola), necessitando de documento que detalhe interfaces e
elementos do software para consulta posterior. Caso ele se esqueça de alguma
67
funcionalidade ou característica do programa, terá uma referência. Isso facilitará
o desenvolvimento das fases posteriores, principalmente durante o
planejamentos dos testes;
§ Estimar prazos e custos para a avaliação, propondo um cronograma que poderá

ser apresentado aos interessados. A partir do reconhecimento das interfaces e
da complexidade do software, pode-se estimar o tempo que será gasto para sua
avaliação, bem como seu custo.
Durante essa fase, o avaliador deve ter em mente as heurísticas para

software educacional infantil, descritas no Capítulo 6, para facilitar a identificação de
possíveis defeitos do programa.
Essa fase deve envolver mais do que a familiarização com o software.

Também pode ser incluído o reconhecimento de uma escola, seu plano político-
pedagógico e laboratório de informática onde o software é usado, as conversas com
pais, docentes, funcionários e crianças da escola e a presença em aulas. Quanto
mais contatos com os envolvidos, melhor será a compreensão do contexto em que o
software está ou será inserido.
Vale aqui salientar que, no caso de uso da MAQSEI em programas em

desenvolvimento, muitas vezes o avaliador é o próprio desenvolvedor. Nessa
situação, a tarefa de reconhecimento do software limita-se somente a familiarização
com o contexto em que o programa será inserido, visto que suas funções já são
conhecidas pelo desenvolvedor.
A seguir são descritos os formatos para documento de Reconhecimento do

software e de Proposta de avaliação do software.
4.2.1.1. Formato sugerido para documento de Reconhecimento do

software
As anotações e dados coletados durante a fase de reconhecimento devem

ser registrados em documento que servirá para consulta posterior. Um documento
de reconhecimento de software deve conter os seguintes tópicos:
1 - Escopo: descrição de alguns dados sobre o documento, como:
§ Objetivo do documento;
68
§ Nome(s) do(s) avaliador(es) do software;
§ Documentos relacionados, aos quais ele pode servir como base;
§ Data do preenchimento do documento;
§ Tempo gasto para a produção do documento (para o cálculo posterior do custo

da avaliação);
TABELA 8 − Exemplo de Escopo
Descrição Este documento descreve a primeira inspeção feita no software Casa

Mal Assombrada, listando suas funções e características.
Avaliador(es) Ana Paula Ribeiro Atayde
Documentos relacionados Este documento servirá como base de dados para o Plano de testes
do software
Data 8/9/02
Tempo para produção +/- 2 h
2 - Identificação do software: listagem dos primeiros dados sobre o software

analisado:
§ Nome do software;
§ Empresa que o desenvolveu/distribuiu;
§ Objetivo pedagógico do software;
§ Público-alvo do software;
§ Disciplina(s) envolvida(s);
§ Idioma do software;
§ Preço do software;
§ Forma de armazenagem;
§ Requisitos necessários de hardware/software;
§ Resumo do que o software faz;
§ Escola que está usando o software (se for o caso);
69
TABELA 9 − Exemplo de Identificação do software
Nome Casa Mal Assombrada

Empresa SENAI
Objetivo Trabalhar a grafia correta de grupos de palavras da língua portuguesa
Público-alvo Não especificado no software
Disciplina(s) Português
Idioma Português
Preço Não-especificado no software
Armazenagem CD-Rom
Requisitos
Não-especificado no software
hardware/ software
O software contém vários jogos. Cada jogo trabalha a grafia correta de um
Resumo grupo de palavras da língua portuguesa: X/CH, C/Ç/SS, S/X/Z, homônimos
e parônimos, entre outros.
Escola Magnum Agostiniano
3 – Interfaces: detalhamento de todas as interfaces do software e os seus

elementos. Esse detalhamento é especialmente necessário para que o avaliador
possa ter acesso às informações do programa a qualquer momento. Para cada
interface do software, sugere-se q ue sejam listados:
§ Nome da interface;
§ Imagem da interface;
§ Descrição das características, objetivo ou função da interface;
§ Descrição do relacionamento com outras interfaces, ou seja, quais interfaces dão

acesso a ela e quais ela pode acessar;
§ Listagem dos campos presentes na interface, incluindo as características deles,

como nome, valores possíveis (faixa de valores válidos), tipo do campo (texto,
numérico) e restrição (alterável, obrigatório, calculado, opcional).
§ Listagem dos comandos possíveis na interface, incluindo características como

estilo (botão, link), ação (o que ocorre quando o comando é acionado) e estado
(se muda ao ser acionado, se está sempre habilitado).
§ Listagem das mensagens que podem aparecer a partir de algum comando ou

ação, descrevendo seu tipo (mensagem de erro, acerto, instrução, ajuda), a
imagem, o texto, o relacionamento (se é com a interface ou com algum
comando).
70
§ Listagem dos ícones (imagens que não estão relacionadas a alguma ação, só
representam alguma informação) da interface e suas características, como tipo,
descrição/imagem e representação (o que eles representam);
§ Pontos positivos detectados no software;
§ Pontos negativos detectados no software, de acordo com as heurísticas de

Usabilidade;
§ Verificações a serem feitas durante o teste;
§ Outras anotações e observações do avaliador.
71
Interface Bingo
Imagem da interface
Descrição
Interface contendo o jogo de bingo, onde a criança deve digitar na cartela o nome da figura
mostrada pela caveira.
O jogo possui duas cartelas, que devem ser preenchidas com as palavras:
Bingo 1 – Óculos, Caminhão, Peixe, Serrote, Balança, Sino, Queijo, Xícara, Relógio, Maçã,
Bandeira, Ambulância, Lâmpada, Morcego, Bicicleta, Chapéu, Bússola, tesoura
Bingo 2 – Helicóptero, Compasso, Berinjela, Extintor, Cenoura, Girafa, Capacete, Parafuso,
Salsicha, Abacaxi, Panda, Machado, Seta, Pincel, Âncora, Melancia, Coruja, Hélice
Relacionamentos com outras interfaces

Esta interface é acionada a partir do comando “Bingo” da Tela Principal.
Esta interface possibilita o acesso a Tela Principal por meio do botão “outro?” ou o acesso à tela de
confirmação de saída pelo botão “chega!”
Ao terminar uma cartela do jogo, a interface aciona a interface Resultado.
Campos
Nº Nome Valores válidos Tipo Restrição
1 Cartela Caracteres alfanuméricos Texto Alterável
Comandos
Nº Nome Estilo Ação Estado
1 Outro? Botão Abre a interface Tela Principal Sempre habilitado
Botão Abre a interface Confirmação de Sempre habilitado
2 Chega!
Saída
- Verificação da grafia correta da
palavra
Em caso de acerto: Esqueleto
reluz olhos e passa para a próxima
3 <enter> palavra.
Em caso de erro: Digitação é
apagada. Após terceira tentativa,
aparece a resposta.
72
Mensagens
Nº Tipo Imagem Texto Relacionamento
1 Instrução - “Digite, na cartela, o nome que Mensagem escrita na
aparece no balão e tecle interface
<enter>”
Ícones
Nº Tipo Descrição/Imagem Representação
1 Figura Figuras de caveiras Representam o número de telas do jogo.
Pontos Positivos
Jogo disponibiliza as respostas à criança após três tentativas, minimizando abandonos.
Pontos negativos
Botões não estão posicionados em mesmo local que em outras interfaces.
Verificações a serem feitas no teste

Se a mudança na posição dos botões influi.
Se crianças entendem quando erram a grafia de uma palavra.
Se crianças entendem a representação do número de telas.
Outras Observações
-
FIGURA 12 − Exemplo de interfaces
73
4 - Observações e comentários gerais: caso haja alguma informação relevante não-
listada, como pontos positivos e negativos referentes ao software, essas deverão ser
descritas neste campo.
TABELA 10 − Exemplo de observações e comentários gerais
Software não possui recursos sonoros.

Software não possui tela de configuração.
Software está instalado nos computadores do laboratório de informática do colégio Magnum, à
disposição das crianças.
4.2.1.2. Formato sugerido para documento de Proposta de

Avaliação do software
Pode-se apresentar às escolas ou aos interessados uma proposta de

avaliação do software que estime os prazos e custos para sua realização. Ela deve
basear-se em dados históricos obtidos de outras avaliações e a partir do
reconhecimento do software, em que uma idéia da complexidade do programa pôde
ser obtida. Sugere-se que o documento de Proposta de avaliação do software
contenha os seguintes tópicos:
1 - Escopo: descrição de alguns dados sobre o documento, como:
§ Objetivo do documento;
§ Nome(s) do(s) avaliador(es) do software;
§ Data do documento;
TABELA 11 − Exemplo de Escopo
Descrição Este documento descreve uma estimativa de prazos e custos para

avaliação do software Casa Mal Assombrada.
Avaliador Ana Paula Ribeiro Atayde
Data 8/9/02
2 - Requisitos da avaliação: descrição dos tópicos que a avaliação deverá conter.
TABELA 12 − Exemplo de Requisitos da avaliação
A avaliação do software deverá apresentar os seguintes itens:

- Relação dos problemas encontrados no programa;
- Análise qualitativa e quantitativa de atributos técnicos e pedagógicos do programa;
- Recomendações de uso e conclusões sobre o programa;
3 - Responsabilidades da escola: descrição do que a escola deve disponibilizar para

a realização dos testes de avaliação.
74
TABELA 13 − Exemplo de Responsabilidades da escola
A escola deverá se responsabilizar por:

- Disponibilizar um laboratório de informática da escola para a realização dos testes;
- Selecionar crianças para a participação nos testes;
4 – Cronograma: estimativa de prazos e custos para a avaliação.
TABELA 14 – Exemplo de Estimativas de prazos e custos
A avaliação do software obedecerá ao seguinte cronograma:
1. Fase de Reconhecimento do software e Produção do cronograma: 8 horas.

2. Planejamento dos testes para avaliação do software: 4 dias úteis
3. Realização dos testes: 3 dias úteis
4. Análise de dados e produção do relatório de avaliação: 5 dias úteis
5. Reunião para apresentação da avaliação do software: 2 horas
Estimativa de custo da avaliação: R$ 6.500,00.
Os formatos-padrões para documentos de Reconhecimento do software e

Proposta de avaliação do software estão descritos nos Anexos I e II,
respectivamente.
4.2.2. Fase de Planejamento dos Testes
A etapa de planejamento dos testes é tão importante quanto a própria

realização dos testes. A tarefa de descobrir o que será necessário para a realização
da avaliação torna -se mais simples ao se especificar exatamente o quê e quando
ocorrerá. Um planejamento de avaliação de software deve ser feito com cautela,
pois testes mal-planejados resultam em resultados pobres e duvidosos, causando
desperdício de tempo e dinheiro (RUBIN 1994).
Nessa fase são preparados todos os materiais (formulários, questionários,

scripts), equipamentos e ambientes que serão envolvidos nos testes, além da
seleção dos participantes. O Plano de testes é o documento mais importante
produzido, descrevendo todo o teste e podendo ser apresentado a todos os
interessados na avaliação. Essa fase envolve:
§ Personalização da metodologia (tarefas e artefatos);
§ Preparação do Plano de testes;
§ Preparação de Formulário de consentimento;
§ Preparação de Script de orientação;
75
§ Preparação de Entrevista com crianças;
§ Preparação de Pré e Pós-testes;
§ Preparação de Formulário de observação;
§ Preparação de Questionário com crianças;
§ Preparação de Lista de verificação;
§ Seleção de crianças;
§ Preparação do ambiente, de equipamentos e materiais;
§ Realização de testes de todos os itens do teste;
A preparação de cada um desses tópicos deve ser uma tarefa bem-definida,

organizada e realizada com atenção, pois somente assim produzirão uma avaliação
de software de qualidade. Cada uma dessas tarefas está detalhada a seguir.
4.2.2.1. Personalização da MAQSEI
A personalização da MAQSEI compreende a definição de uma instância da

MAQSEI a ser utilizada em um projeto de avaliação de software educacional infantil
específico. Deve-se verificar a adequação de todas as fases, tarefas e artefatos da
MAQSEI às necessidades do projeto em questão, realizando as alterações
necessárias.
4.2.2.2. Preparação do Plano de testes
O Plano de testes é a base para todos os testes do software que serão

realizados. Ele explica onde, quando, quem, como, quanto e por quê dos testes do
software. De acordo com RUBIN (1994), é muito importante que um Plano de testes
seja bem-escrito, compreens ível e detalhado, pois:
§ O Plano de testes é como a planta de uma casa, descrevendo exatamente o que

será construído;
§ O Plano de testes serve de veículo de comunicação entre avaliadores, docentes,

pais ou qualquer pessoa envolvida na avaliação. É o documento que deve ser
revisto pelos interessados no entendimento dos testes;
76
§ O Plano de testes descreve as fontes necessárias, internas e externas, para se
realizar testes com sucesso;
Durante a produção do Plano de testes, o avaliador deve rever as heurísticas

para software educacional infantil desenvolvidas neste trabalho e descritas no
Capítulo 6, para que possa formular perguntas e tarefas que elucidem problemas
relacionados tanto às questões de Usabilidade quanto às pedagógicas do programa.
O Plano de testes pode ser alterado à medida que informações vão sendo
adquiridas durante a fase de planejamento dos testes, mas deve estar pronto antes
da condução deles.
4.2.2.2.1. Formato sugerido para o documento do Plano de testes
Um Plano de testes pode variar dependendo do tipo do software a ser testado

e dos objetivos da avaliação. Entretanto, os tópicos descritos e exemplificados a
seguir são os mais tipicamente incluídos em um Plano de testes (RUBIN 1994):
1 – Introdução: descrição sucinta do objetivo do documento.
TABELA 15 − Exemplo de introdução
Este documento descreve o Plano de testes para a avaliação do software Casa Mal
Assombrada, que trabalha com a grafia de grupos de palavras da língua portuguesa.
2 - Documentação relacionada: listagem do nome de todos os documentos

necessários para que as fontes de dados usadas na produção do Plano de testes
possam ser recuperadas, caso necessário.
TABELA 16 − Exemplo de documentação relacionada
Nº de ordem Tipo de documento

1 Formulário de reconhecimento do software Casa Mal Assombrada
3 – Propósito (objetivo geral dos testes) : descrição em alto nível da razão da

realização do teste.
TABELA 17 − Exemplo de propósito
Avaliar se o software está conseguindo obter os resultados esperados, se está atingindo suas
metas, e levantar seus pontos positivos e negativos por meio da observação das crianças usando o
software e exercendo as tarefas solicitadas.
77
4 – Aspectos a serem avaliados (objetivos específicos dos testes): listagem das
questões que precisam ser analisadas durantes os testes, separadas por tipo (geral,
específica, sobre hardware, sobre documentação, pedagógicas). Deve ser uma
seção precisa, clara e mensurável/observável. Perguntas vagas, do tipo: “o software
é efetivo?” não identificam o problema e dificilmente poderão ser respondidas. As
questões devem ser diretas, identificando a possível causa do problema, como em
“A mudança na posição do botão causa frustrações nas crianças?”.
TABELA 18 − Exemplo de aspectos a serem avaliados

Tipo Pergunta a ser respondida
1 Crianças confundem o significado dos botões “chega” e ”outro”?
2 Crianças gostam das figuras, personagens, animações?
3 Crianças entendem a linguagem usada no software?
4 Crianças entendem a figura que indica o número de tarefas nos jogos?
5 Crianças gostam das telas de resultado?
Geral 6 Crianças gostariam que o jogo tivesse recursos sonoros?
7 Crianças quiseram aumentar a tela?
8 Crianças lêem telas de entrada dos jogos?
9 Crianças lêem regras nos jogos?
10 Crianças entendem o que fazer nos jogos?
11 Crianças entendem que erraram?
12 Mudança na posição dos botões “outro” e ”chega” influi em algum jogo?
13 No exercício c ç s ss xc sc, crianças clicam somente uma vez na figura?
Específicas
14 No exercício s x z, crianças tentam usar mouse?
de algum jogo
15 No jogo c ç ss tentam clicar na letra?
16 No jogo Homônimos e parônimos, lêem explicação ao errar?
5 - Perfil da criança: descrição das características das crianças que participarão dos
testes.
TABELA 19 − Exemplo de perfil da criança
Característica Necessidade
Quantidade de crianças 8
Idade 6 a 10 anos
Nível escolar Entre 1ª e 4ª séries
Familiaridade com computador Necessária
Familiaridade com o software 50% iniciantes e 50% experientes
Nível da criança na matéria do software 50% crianças inexperientes e 50% crianças experientes
78
6 – Metodologia: descrição de como o teste deverá ser conduzido com as crianças.
Deve-se fazer uma sinopse do teste, formulando uma visão geral desde a chegada
das crianças até a hora em que vão embora. Assim, quem tiver lido o Plano de teste
e estiver assistindo ao teste, saberá exatamente o que esperar em cada momento.
Essa descrição também é útil caso a avaliação do software seja feita por mais de um
condutor 18, garantindo que todos ajam similarmente.
TABELA 20 − Exemplo de metodologia
O teste aqui descrito foi projetado para a coleta de dados pedagógicos e técnicos. Esses serão
obtidos via observação direta e via questionários e testes em papel para a coleta de dados de
preferência e aprendizado. Todas as etapas do teste estão descritas a seguir.
1 – Saudações aos participantes, Formulário de consentimento e entrevista com crianças

Cada criança será cumprimentada pelo condutor do teste para se sentir mais à vontade.
Será solicitado da criança o Formulário de consentimento preenchido pelos pais ou responsável.
Serão feitas à criança perguntas a respeito do seu perfil (nome, idade, série, entre outros) para o
preenchimento da entrevista com crianças.
2 – Orientações e pré-teste
Será falado às crianças um script de orientação, que é uma explicação dada sobre o que vai
ocorrer durante o teste. O script contém apresentações de todos os participantes do teste, as
explicações do porquê do teste, descrição do que é esperado da criança e a descrição do
equipamento usado no teste. Será ressaltado que o centro do teste é o software e não as crianças,
e que eles devem agir da forma mais confortável possível.
Se for o caso, será aplicado um pré-teste, para coleta dos conhecimentos da criança referentes
ao conteúdo do software.
3 – Aplicação do teste
A aplicação do teste consiste em uma lista de tarefas solicitadas pelo condutor que as crianças
deverão realizar enquanto estão sendo observadas.
Durante o teste, erros, acertos e comentários serão registrados para cada tarefa da lista. O
condutor do teste também tomará notas a respeito do comportamento, opiniões e qualquer
circunstância não-usual que ocorrer no teste que tenha importância. Os participantes estarão sendo
gravados para registro permanente e posterior verificação.
4 – Pós-teste, Questionário com crianças e Agradecimentos

Após todas as tarefas serem completadas, poderá ser aplicado o teste igual ou similar ao
aplicado antes do teste, para coleta de dados de aprendizado adquirido pela criança após uso do
software.
Em seguida, cada criança será questionada pelo condutor do teste. Essa discussão tem como
objetivo verificar do que a criança gostou, o que a frustrou e poderá conter:
- Um questionário de preferências e opiniões da criança a respeito do software;
- Perguntas feitas pelo condutor sobre problemas específicos ocorridos durante o teste;
Após o questionário, as crianças serão agradecidas e receberão um agrado antes de serem
liberadas.
Estima-se que cada teste dure aproximadamente uma hora e meia.
18
As palavras condutor e avaliador são usadas no mesmo sentido neste trabalho.
79
7 – Tarefas: listagem das tarefas que serão solicitadas às crianças durante o teste,
incluindo pequena descrição, os requisitos necessários para a sua realização (Req)
e a descrição de uma medida de sucesso da tarefa (CS). As tarefas devem explorar
as possibilidades de defeito e problemas no software, refletindo o que se deseja
descobrir sobre o programa. Só assim conseguirão obter resultados significativos.
TABELA 21 − Exemplo de tarefas
Tarefa nº Descrição Detalhes

1 Entre no primeiro jogo (Tabuada) e veja Req: Software em tela inicial
as regras CS: Acessarem as regras e ouvirem
2 Vá para o jogo e inicie Req: Software em tela inicial do primeiro
jogo
CS: Digitarem nomes e entrarem no jogo
3 Joguem com a tabuada 4, 5 e 6 da Req: Tela do primeiro jogo
multiplicação CS: Conseguirem configurar o jogo como
pedido e jogarem até o fim do jogo
4 Saiam do jogo Req: Tela do primeiro jogo
CS: Saírem pelo botão “saída”
8 - Ambiente dos testes e equipamentos requeridos: descrição do ambiente em que

os testes serão realizados e os equipamentos necessários para sua realização.
TABELA 22 − Exemplo de ambiente dos testes e equipamentos requeridos
O teste será realizado no laboratório de informática da escola.
Estarão presentes durante cada teste:

• condutor dos testes;
• responsável pela filmagem dos testes;
• Observadores (docentes, interessados);
• crianças;
Os equipamentos requeridos são:

• Um microcomputador com o software instalado;
• Câmera de vídeo;
• Microfone conectado a câmera de vídeo (se possível);
9 - Papel do condutor de testes: esclarecimento da função do condutor dos testes,

especialmente para os observadores que forem assistir ao teste e que não
conhecem a metodologia de avaliação de software.
80
TABELA 23 − Exemplo de papel de condutor
O condutor de testes, também chamado de avaliador, é a pessoa que estará com as crianças
durante todo o teste.
Ele sentará com as crianças, iniciará o teste, simulará cenários necessários e solicitará tarefas.
Durante este processo ele também registrará expressões, erros, observações e comentários.
Quando uma criança apresentar dificuldades em alguma tarefa, o condutor evitará fornecer
respostas. Ele procurará incentivar a descoberta, estimulando o aprendizado.
Além do condutor dos testes, poderão existir observadores presentes no teste, não mais que três
pessoas, que poderão fazer anotações sobre o teste também.
10 - Medidas de Avaliação: apresentação dos tipos de medidas que serão coletadas

durante o teste, possibilitando a qualquer interessado no Plano de testes ter certeza
de que estarão coletando o tipo de dado que é esperado do teste. Em avaliações de
programas educacionais infantis, medidas como tempo de realização de tarefa
(eficiência) nem sempre são apropriadas. Outras medidas como controle e nível de
motivação são mais adequadas (HANNA et al., 1997). Podem-se citar alguns tipos
possíveis de medida:
§ Medidas de preferência, que representam opiniões das crianças, respostas a

perguntas e comentários;
§ Medidas de interação, como nível de motivação, contagem de comportamentos

observados, entre outras;
§ Medidas para verificação de efetividade do software, como taxa de realização de

tarefa com sucesso, taxa de erro, comparação entre Pré e Pós-testes, entre
outras.
Todos os tipos de medida podem ser feitas quantitativamente ou

qualitativamente, dependendo dos objetivos do teste. A listagem dessas medidas
garante a quem for usar o Plano de testes que estarão extraindo o tipo de dado
desejado nos testes.
81
TABELA 24 − Exemplo de medidas de avaliação
As seguintes medidas de avaliação serão coletadas e analisadas:
Medidas de preferência:
• Qual jogo gostou mais ou menos
• Facilidade de entendimento do software
• Se gostaram das animações e textos do software
Medidas de interação:
• Nível de motivação
• Contagem de comportamentos semelhantes
Medidas de efetividade:
• Número de tarefas completadas com sucesso com ou sem ajuda
• Número de tarefas completadas erradamente
• Contagem de seleções incorretas
• Contagem de erros
11 – Estimativa de apresentação do Relatório final de ava liação do software:

descrição dos tópicos e data de apresentação aos interessados do relatório dos
resultados obtidos do software.
TABELA 25 − Exemplo de estimativa de apresentação do relatório de avaliação do software
O relatório de avaliação do software conterá as seguintes seções:

1. Relação dos problemas detectados no software
2. Análise qualitativa e quantitativa de atributos técnicos e pedagógicos do software
3. Resultados da análise quantitativa
4. Conclusões e recomendações sobre o software
O relatório de avaliação será concluído e apresentado aos interessados aproximadamente duas
semanas após o teste.
O formato padrão para o documento de Plano de testes está descrito no

Anexo III.
82
4.2.2.3. Preparação de Formulário de consentimento
A avaliação de um software educacional infantil deve envolver testes do

programa com a participação de crianças. Sendo assim, é necessário o
consentimento dos pais ou responsáveis pela criança para a sua realização,
principalmente caso os testes sejam gravados em fitas de vídeo. O propósito é obter
autorização escrita dos pais/responsáveis para a realização das avaliações do
software e filmagem das crianças. O formulário de autorização deve estabelecer
qual será o uso da imagem e da voz gravadas e deixar claro que o uso das fitas está
limitado aos envolvidos no teste. É importante dizer também o tempo de duração do
teste, para que os responsáveis pelas crianças possam planejar quando devem
buscá-las. Se o formulário for entregue a crianças em escolas, é necessário que seja
aprovado pela coordenação da instituição.
Para os pais das crianças que participaram dos testes envolvidos neste
trabalho foi apresentado um formulário contendo breve explicação dos objetivos e
procedimentos do teste e solicitando a autorização para a participação de seus filhos
nos testes. Um exemplo de Formulário de consentimento usado nos testes pode ser
visto a seguir.
83
Formulário de consentimento
Caros Pais,
Eu, Ana Paula Ribeiro Atayde, mestranda em Ciência da Computação pela Universidade
Federal de Minas Gerais, estou trabalhando em uma dissertação para avaliar a qualidade de
software (programa de computador) educativo, buscando contribuir para a criação de critérios de
avaliação de software, assim como na construção de software educativo e orientação do uso pelos
docentes.
Para que meu trabalho seja completo, necessito da participação de crianças em avaliações
de software infantil. Essa participação consiste em levar as crianças até um laboratório com um
computador e pedir para que elas utilizem alguns programas em questão. Nesta utilização elas
estarão avaliando e dando sua opinião sobre interface e funcionamento dos mesmos. A sessão dura
em média uma hora e meia.
O laboratório possui, além do computador, uma filmadora que registrará toda a avaliação.
Esta filmagem é necessária para que possamos fazer uma análise posterior e coletar melhor as
opiniões dadas pelas crianças durante a avaliação dos programas, uma vez que não é possível
documentá-las somente durante a avaliação, devido ao curto espaço de tempo e à rapidez com que
as crianças se expressam.
Obs.: As fitas com a gravação dos testes feitos pelas crianças estarão disponíveis para os pais das
crianças que participarem das avaliações. Estou à disposição para qualquer esclarecimento.
Agradeço a compreensão e a colaboração,

Mestranda em Ciência da Computação UFMG
Coordenadora dos cursos de extensão DCC/UFMG
Tels.: 3499-5574 / 9990-3908
Email: atayde@dcc.ufmg.br
Orientadores:
Adla Betsaida Martins Teixeira Clarindo Isaías Pereira da Silva e Pádua
Faculdade de Educação – UFMG Depto. de Ciência da Computação – UFMG
Autorizo meu filho (minha filha) ___________________________________________

a participar da avaliação de software infantil no laboratório de Usabilidade do departamento de
Ciência da Computação da UFMG.
Belo Horizonte, ____ de ______________ de 2002
____________________________________________
Nome do pai ou responsável (legível)
____________________________________________
Assinatura do pai ou responsável
FIGURA 13 − Exemplo de Formulário de consentimento
84
4.2.2.4. Preparação de Script de Orientação
O Script de orientação é uma ferramenta de comunicação feita para ser lida

ou explicada aos participantes. Muitas vezes as crianças não foram bem-informadas
sobre o que farão durante o teste, possivelmente achando que serão testadas.
Portanto, o Script de orientação deve descrever para a criança o que irá acontecer
durante o teste, deixando-a a par de todos os procedimentos e facilitando a
realização do mesmo pelo condutor.
O Script de orientação deve ser transmitido às crianças um pouco antes do

início das atividades do teste, já no ambiente onde ele será realizado.
Em testes realizados com crianças, o ideal é que o Script de orientação seja

falado em vez de ser lido, para que o ambiente fique mais informal e as crianças se
sintam mais à vontade. Mas o documento que descreve o Script de orientação deve
ser produzido e lido pelo condutor antes de cada teste para que seja mantida a
coerência entre todos os participantes. Esse documento deve ser pequeno, caso
contrário alguma informação poderá não ser assimilada pelas crianças. São
conteúdos típicos do documento Script de orientação:
§ Apresentações (de todos os participantes do teste);
§ Explicações do porquê do teste;
§ Descrição do equipamento utilizado durante o teste;
§ Descrição do que é esperado da criança:
- Que ajam naturalmente;
- Que podem perguntar o que quiserem durante o teste (mas avisando que
nem sempre o condutor dará a resposta);
- Que podem fazer paradas sempre que desejarem;
§ Avisos de que eles não estão sendo testados e, sim, o software (deve-se
ressaltar que o comportamento do condutor durante o teste conta muito também
para que a criança não se sinta testada);
§ Motivações informando as crianças da sua importância para a avaliação;
§ Verificação sobre o entendimento do teste;
85
Cabe aqui o comentário de que no Script de orientação (ou em qualquer outro
momento do teste), deve-se evitar dizer que o jogo é fácil de usar ou que é simples,
pois caso ocorra alguma dificuldade durante o teste, as crianças podem então
concluir que o problema está relacionado a elas.
O Script de orientação ilustrado na Figura 14 foi usado nos testes deste

trabalho.
Script de orientação
“Olá, meu nome é Ana Paula e vou ficar com vocês durante todo o teste. Este é o Bernardo que
vai acompanhar o teste, filmando-o.”
“Bem, vocês estão aqui hoje para nos ajudar a testar alguns programas e joguinhos. Eu chamo
isto de um teste, mas não estou testando vocês de forma alguma. Precisamos da ajuda de
vocês para descobrir se os programas estão realmente ajudando vocês a aprenderem as
matérias e também para descobrir o que crianças na sua idade tem facilidade em fazer e o que
acham difícil de fazer nestes programas.”
“Vou pedir para que vocês façam algumas tarefas nos programas e estarei aqui o tempo todo
que vocês precisarem. Vocês podem falar o que quiserem, perguntar o que quiserem, como se
vocês estivessem em sua casa ou na sua aula de informática na escola. Vocês podem
interromper ou parar o teste a qualquer momento que quiserem.”
“Durante o teste, estaremos observando e fazendo anotações. Todo o teste será filmado por
meio de câmeras para que possamos ver depois. Vocês estarão com microfones para que suas
vozes sejam gravadas. Vocês trouxeram a autorização dos seus pais?”
“Está bem assim? Você(s) têm alguma dúvida?”
FIGURA 14 − Exemplo de Script de orientação
4.2.2.5. Preparação de Entrevista com crianças (pré-teste)
O documento de Entrevista com crianças consiste na coleta da informação

histórica sobre a criança, que irá ajudar na compreensão do seu comportamento e
na desenvoltura durante o teste. Determi nados comportamentos da criança durante
o teste podem ser devidos a algum fato ou dado antecedente. A entrevista utiliza
perguntas que revelam sua experiência, atitudes e preferências em todas as áreas
que possam afetar no teste. Além das razões já citadas, a entrevista também pode
servir para verificar se as crianças têm o perfil desejado para o teste e para fazer
uma sinopse de cada participante para condutor e observadores. A entrevista deve
ser preenchida antes da realização do teste. Abaixo encontram-se algumas
recomendações para a produção da Entrevista com crianças, adaptadas de RUBIN
(1994) para o uso com crianças:
86
§ Deve-se levantar toda a informação histórica da criança que poderia influenciar
no seu comportamento durante o teste (idade, formação, sexo, experiência com
computadores, preferências);
§ Deve-se preparar a entrevista de forma a obter melhores resultados (na análise

das perguntas) e entendimento pelas crianças (perguntas compreensíveis). A
entrevista também deve ser pequena, simples, evitando questões abertas que
são mais difíceis de tabular;
§ Deve-se testar a entrevista com alguma criança antes da situação de teste para
que alguns defeitos sejam identificados e corrigidos.
A seguir encontra-se um exemplo de entrevista usada nos testes realizados

durante este trabalho.
87
Entrevista com crianças
Criança1: Criança2:
Escola: Série: Teste nº: Software (s):
1 _____ Destro _____ Canhoto 2 _____ Destro _____ Canhoto
1 – Quantos anos você tem?

1_______________________________ 2___________________________________
2 - Você tem computador em casa?

1_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
2_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
3 – Você sabe usar o computador?

1_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
2_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
4 – Como aprendeu a usar o computador?

1_____ Sozinho
_____ Alguém ensinou. Quem? ___________________________________________
_____ Outra forma. Qual? _______________________________________________
2_____ Sozinho
_____ Alguém ensinou. Quem? ___________________________________________
_____ Outra forma. Qual? _______________________________________________
5 – Para que você usa o computador em casa?

1_____________________________________________________________________
2_____________________________________________________________________
6 – O que você mais gosta de fazer em um computador?

1 _____ Brincar. De quê? _________________________________________________
_____ Internet. ________________________________________________________
_____ Aprender________________________________________________________
_____ Outros. _________________________________________________________
2 _____ Brincar. De quê? _________________________________________________
_____ Internet. ________________________________________________________
_____ Aprender________________________________________________________
_____ Outros. _________________________________________________________
8 - Já usou este(s) software(s) (falar o nome dos programas) antes? Gostou?

1_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
2_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
9 – Você tem aula de informática ? O que faz nas aulas?

1_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
2_____ Sim ____________________________________________________________
_____Não ____________________________________________________________
Obrigada pela ajuda!

FIGURA 15 − Exemplo de Entrevista com crianças
88
4.2.2.6. Preparação de Pré e Pós-testes
Os Pré e Pós-testes servem para avaliar e comparar a capacidade e o

aprendizado da criança nos tópicos tratados no software antes e após o seu uso. No
Pré-teste, verifica-se o nível de conhecimento da criança no assunto antes do uso do
software. No Pós-teste, verifica-se se algum ou qual aprendizado foi conseguido
após o uso do software. Portanto, o propósito principal é a verificação da efetividade
do software no alcance dos seus objetivos.
Além do propósito já citado, o Pré-teste também pode servir para qualificar

uma criança em um perfil de participantes do teste. Se o teste necessita de crianças
com e sem experiência no conteúdo do software, pode-se usar o resultado do Pré-
teste para separá-las nesses grupos. Outra situação interessante ocorre quando a
seleção das crianças não foi feita com rigor: durante a realização do Pré-teste
consegue-se notar a inadequação de algumas crianças ao teste. O avaliador então
deverá decidir se alguma mudança será necessária no teste.
Como exemplo de utilização de Pré e Pós-testes, pode-se citar uma avaliação

realizada neste trabalho com o software Casa Mal Assombrada, que trabalha a
correta grafia de grupos de palavras da língua portuguesa. Nos Pré e Pós-testes da
avaliação do software, foram feitos ditados com as crianças para verificação da
grafia de algumas palavras usadas no software. Nos Pré-testes eram selecionadas
aleatoriamente algumas palavras do software e nos Pós-testes eram selecionadas
palavras que as crianças haviam errado no Pré-teste ou durante o teste (durante o
teste o condutor anotava essas palavras e as acrescentava no Pós-teste). Assim,
conseguiu-se observar se as crianças haviam memorizado a forma correta da
palavra após o uso do software. Esse exemplo de Pré e Pós-teste está descrito pela
Figura 16. No Anexo III encontra-se o documento padrão sugerido para Pré e Pós-
testes.
89
Pré-teste e Pós-teste de software
1- Escopo
Teste nº 1
Software Casa Mal Assombrada
Data
Crianças
Escola Magnum Agostiniano
Condutor Ana Paula Ribeiro Atayde
2- Descrição
Ditado:
- Entregar uma folha para cada criança e pedir que escrevam as seguintes palavras:
- Marcar as palavras que cada criança errou.
- Acrescentar palavras que erraram durante o teste para perguntar no pós-teste
Nº Palavra Criança 1 errou? Criança 2 errou?

(marcar com X) (marcar com X)
1. Lagartixa
2. Trouxa
3. Rabugento
4. Esforço
5. Pescoço
6. Salsicha
7. Paralisar
8. Desastre
9. Maçã
10. Exibir
11.
12.
13.
14.
15.
FIGURA 16 − Exemplo de Pré e Pós-testes
90
4.2.2.7. Preparação de Formulário de observação
O Formulário de observação é um coletor manual, que deve armazenar todos

os dados pertinentes aos objetivos do teste. Seu propósito é coletar os dados
durante o teste de forma simples, concisa e o mais confiável possível.
Os dados coletados são obtidos da observação durante o teste e da

observação da fita de vídeo gravada após o término do teste. Tais dados consistem
em comportamentos observados, sentimentos e opiniões sobre o software,
interpretações do condutor, entre outros. A coleta de dados não deve ser uma busca
por informações em que elas essas são primeiramente coletadas para depois se
decidir o seu fim. O objetivo e o tipo dos dados que se deseja coletar devem estar
claros para o avaliador.
As seguintes estratégias devem ser seguidas ao se desenvolver um

instrumento de coleta de dados:
§ Rever a listagem dos aspectos a serem avaliados sobre o software descrita no

Plano de testes (objetivos específicos do teste). Eles, assim como os possíveis
problemas do software, devem estar claros para o avaliador. A busca do
esclarecimento dessas questões facilitará a coleta de dados e produzirá
melhores resultados.
§ Rever a lista de tarefas do teste, verificando os critérios de sucesso de cada

uma. Isso ajudará na compreensão de que tipo de informação se deseja coletar.
Deve-se saber o que obter na observação de cada tarefa, listando no formulário
as perguntas relacionadas ou observações a serem feitas;
§ Projetar um coletor (formulário) eficiente e de fácil uso. A idéia é antecipar os

eventos que irão ocorrer no teste e fazer um formulário que facilite a forma de
entrada de dados. Ao observar um teste, o condutor não pode perder muito
tempo com anotações ou poderá perder detalhes sobre o teste. Não deve-se
deixar uma resposta a ser preenchida em aberto quando já são conhecidas as
respostas possíveis. Ao antecipar os dados e ações observadas, o tempo para a
coleta e o armazenamento dos dados reduz significativamente, liberando o
condutor para a observação do teste.
91
4.2.2.7.1. Formato sugerido para Formulário de observação
As anotações e os dados coletados durante a observação devem ser

registrados em um formulário que servirá para consulta na fase de análise dos
dados. Sugere-se que esse documento contenha os seguintes tópicos:
1 – Escopo: descrição sobre as informações do teste, como número do teste, data,

nome do software, escola, nome das crianças, série e condutor;
2 – Tarefas: listagem das tarefas (previamente formuladas no Plano de testes) a

serem solicitadas às crianças durante o teste. Em cada tarefa, listam-se também
quais perguntas ou ações relacionadas podem ser respondidas ou observadas;
3 - Outros comentários e observações: descrição de observações sobre o software,

recomendações de uso ou comentários sobre ações e expressões das crianças
ocorridas durante o teste que não foram anotadas em outra seção.
Um exemplo de preparação do Formulário de observação está descrito a

seguir. Seu formulário-padrão está descrito no Anexo V.
92
Formulário de observação
1 – Escopo
Teste nº
Software
Data
Crianças
Série
Escola
Condutor
2 –Tarefas
Nº Descrição Observar
Acessaram as regras e ouviram? S N
Entrem no primeiro jogo Crianças prestam atenção às regras? S N

(Tabuada) e vejam as
1 regras Gostam dos personagens? S N
Parecem entender? S N
Outras ações e observações:
Iniciem o jogo Digitaram os nomes? S N

2
Conseguiram configurar o jogo como pedido ? S N
Entenderam para que serve o ícone (tabuada)? S N

Joguem com a tabuada
Precisam de explicações para jogar? S N
4, 5 e 6 da multiplicação
3
Tela é confusa para eles? S N
Terminaram o jogo? S N
3 – Outros comentários e observações
FIGURA 17 − Exemplo de Formulário de observação
93
4.2.2.8. Preparação do Questionário com crianças
O Questionário com crianças lista algumas perguntas a serem feitas a elas,

bem como tópicos a serem discutidos após a condução das tarefas do teste. A
utilização de uma pergunta ou um tópico dependerá do desenvolvimento do teste
(não faz sentido o uso de uma pergunta sobre parte do software que não foi
explorada pela criança) ou do perfil da criança (perguntas diferentes para crianças
iniciantes e experientes no uso do software). Pode-se também ter perguntas gerais,
de alto nível, e perguntas específicas, relativas a alguma parte do software.
Durante os testes para avaliação de programas educacionais infantis

realizados neste estudo, o Questionário com crianças mostrou-se de grande valor,
principalmente na compreensão de atitudes ou comportamento das crianças durante
alguma tarefa do programa. Nem sempre era possível que o condutor do teste
compreendesse algumas ações da criança no momento em que ocorriam e a
interrupção para seu esclarecimento podia não ser viável (podendo atrapalhar algum
processo de raciocínio). Nessa situação, o condutor perguntava para a criança sobre
o acontecido após o término das tarefas, durante a condução do questionário. Às
vezes era necessário que o condutor mostrasse a interface do software para que a
criança se recordasse da situação.
4.2.2.8.1. Formato sugerido para Questionário com crianças
Como as anotações e os dados coletados durante o questionário devem ser

registrados, sugere-se o uso de um formulário que está descrito no Anexo VI e que
contém os seguintes tópicos:
1 – Escopo: descrição sobre as informações do teste, como número do teste, data,

nome do software, escola, nome das crianças, série e condutor;
2 – Perguntas gerais: perguntas de alto nível sobre o software, como “o que você
achou?”, formuladas antes do teste. Com crianças, pode-se usar o desenho de uma
escala (HANNA et. al., 1997) para que elas marquem o quanto gostaram do
software, como a usada no exemplo da Figura 18. Iniciando o questionário com esse
tipo de pergunta, o avaliador possibilita à criança dizer o que tem em mente, que é
geralmente sua impressão ou fato ocorrido mais proeminente, provavelmente uma
informação muito importante.
94
3 – Perguntas específicas: perguntas relativas a alguma parte do software. Elas
podem ser formuladas antes do teste, mas a maioria é levantada no decorrer dele,
dependendo de ações e comentários das crianças.
Um exemplo de planejamento de Questionário com crianças está descrito a

seguir.
95
Formulário de Questionário com crianças
1 − Escopo
Data
Crianças
Escola
Software
Teste nº
Condutor
2 − Perguntas gerais
1 -Marque na “tabelinha” abaixo o quanto você gostou do jogo:

Criança 1: Criança 2:
Criança 1 Criança 2 Comentários

ITEM NÃO SIM NÃO NÃO SIM NÃO
SEI SEI
2 Gostariam de ter um jogo
desse em casa?
3 Gostariam de ter aulas
usando o jogo?
4 Acharam o jogo difícil?
5 O que vocês mais gostaram?

Por quê?
6 O que vocês menos
gostaram? Por quê?
7 O que vocês aprenderam no
joguinho?
3 − Perguntas específicas
ITEM NÃO SIM NÃO NÃO SIM NÃO
SEI SEI
1
2
FIGURA 18 − Exemplo de formulário de Questionário com crianças
96
4.2.2.9. Preparação de Lista de verificação
Durante a realização do teste, o condutor deve ter em mente toda a

seqüência de ações a serem feitas e os formulários necessários em cada tarefa.
Para facilitar o processo, o condutor pode preparar uma Lista de verificação para
guiar o teste, prevenindo-o do esquecimento de pontos importantes. Para o
processo desenvolvido neste trabalho, a seguinte Lista de verificação pode ser
seguida durante cada teste de software:
√ Cumprimentar as crianças;
√ Recolher os Formulários de consentimento;
√ Fazer perguntas da Entrevista com crianças;
√ Transmitir informações contidas no Script de orientação;
√ Realizar o Pré-teste;
√ Conduzir o teste, observando as crianças e anotando no Formulário de

observação;
√ Realizar o Pós-teste;
√ Fazer perguntas do Questionário com crianças;
√ Agradecer e dar gratificação;
√ Organizar papéis coletados.
4.2.2.10. Seleção de crianças
Um elemento crucial para a avaliação de um software educacional infantil é a

seleção das crianças que irão participar dos testes. Os resultados da avaliação só
serão válidos se as crianças escolhidas representarem o público-alvo do software.
Se os testes forem conduzidos com crianças de perfil pouco apropriado (faixa etária
diferente, por exemplo), os resultados serão sempre de valor limitado ou
questionável, mesmo com grande esforço no planejamento do teste. Durante
avaliação realizada neste trabalho, detectou-se que as crianças selecionadas não
tinham conhecimento do conteúdo tratado no software. Tal fato impossibilitou a
condução dos testes do software, visto que todo o seu planejamento ficou então
97
inadequado. Com isso, os testes da avaliação foram invalidados, perdendo-se todo o
tempo despendido na sua preparação.
A primeira tarefa para a seleção dos participantes é a definição do perfil das

crianças. O avaliador deve decidir a faixa etária ou a série escolar, o sexo, a
experiência com o computador, a experiência com o software a ser testado, com o
conteúdo tratado no software, assim como outros fatores relevantes sobre as
crianças que participarão do teste. As recomendações a seguir, observadas durante
a seleção de participantes para os testes deste estudo, merecem atenção:
§ Deve-se ter cuidado com informações retiradas do software, pois elas podem não
corresponder à realidade − ao definir a faixa etária desejada das crianças, em
vez de procurar na documentação do software, o ideal é verificar com docentes
qual é a mais adequada;
§ Deve-se ter atenção à experiência no uso de computadores das crianças

selecionadas, ou então, durante o teste, o avaliador poderá gastar tempo
ensinando a criança a lidar, por exemplo, com o mouse ou teclado;
§ O avaliador pode selecionar crianças com e sem experiência no uso do software.

Crianças iniciantes poderão mostrar a facilidade de aprendizagem do uso do
software e crianças experientes, a memorização da sua forma de utilização;
§ Quanto ao conhecimento do conteúdo do software, é interessante selecionar

algumas crianças com pouca experiência ou informação sobre ele, pois se elas
conseguirem fazer determinada tarefa com sucesso, será ótimo indicativo de que
a tarefa foi bem-implementada no software. Além disso, crianças com
dificuldades na disciplina indicam melhor a efetividade no uso do software, pois
podem fornecer um feedback mais garantido sobre a aprendizagem do conteúdo.
Crianças com facilidade no conteúdo normalmente ajudam mais no
reconhecimento de defeitos de Usabilidade, pois, normalmente, exploram mais
funcionalidades do programa.
O número de crianças que participarão do teste também deve ser avaliado.

Deve-se escolher um número adequado, que irá depender do nível de confiança que
se deseja obter no teste e das restrições de tempo e recursos. Segundo RUBIN
(1994), a seleção de quatro a cinco participantes detecta a maioria dos problemas,
98
mas o mesmo autor recomenda a seleção de oito participantes para que nenhum
detalhe passe despercebido. Nas avaliações deste trabalho, foram selecionadas de
seis a 14 crianças para cada software, dependendo da complexidade do programa.
Os mais simples, com menos funções, necessitaram de seis crianças, enquanto nos
mais complexos participaram de dez a 14 participantes.
Os testes do software podem ser realizados com uma ou duas crianças de

cada vez. Duas crianças normalmente é preferível para que elas se sintam mais à
vontade. Outra razão da condução dos testes em duplas seria o fato de, em muitos
testes, procurar-se simular o ambiente escolar, onde normalmente as crianças
trabalham em duplas nos laboratórios de informática.
Todas as características levantadas como requisitos para os participantes do

teste podem ser testadas durante a Entrevista com crianças, verificando se os
selecionados estão dentro do perfil desejado.
Definido o perfil das crianças com que se deseja trabalhar, deve-se passar
para a sua seleção. Se o teste for realizado em escola, essa seleção pode ser feita
com a colaboração de docentes que melhor conhecem o perfil de cada criança. Em
caso de testes realizados fora do ambiente escolar, deve-se checar com os pais ou
responsáveis se as crianças possuem as características desejadas.
4.2.2.11. Preparação do ambiente, equipamentos e materiais
Outro aspecto importante na realização das avaliações é a preparação do

laboratório, dos equipamentos e dos materiais que serão usados durante os testes.
É desejável um ambiente com equipamento para gravação de áudio e vídeo, uma
pessoa que conheça os materiais e metodologias da avaliação e outra responsável
pela filmagem do teste. A seguir, estão algumas recomendações sobre a preparação
dos testes.
4.2.2.11.1. Ambiente e equipamentos
Existem várias combinações de ambiente e equipamentos possíveis para a

realização dos testes.
Eles podem ser realizados em campo, na casa da criança ou na escola,

colocando o produto no seu contexto de uso. Isso ajuda a experimentar com temas
99
que seriam mais difíceis de serem detectados em ambiente não-familiar à criança.
As Figuras 19 e 20 ilustram como alguns ambientes usados nos testes deste
trabalho foram preparados. Eles representam os equipamentos e espaços mínimos
necessários para a condução de um teste em escola ou casa. Na sala onde o teste
será conduzido, as crianças ficam em frente a um computador, juntamente com o
condutor do teste, localizado um pouco atrás. O computador deve ser preparado
com a instalação do software a ser usado (caso ele já não esteja) e conferido antes
do teste. A filmagem é feita por uma câmera, de forma a captar o som e a imagem
das crianças e da tela do computador. Se existirem observadores, eles devem ficar
localizados lateralmente às crianças, evitando interferências. Sugere-se que não
sejam usados muitos observadores para não intimidar os participantes. Os seguintes
equipamentos são, portanto, necessários:
§ Câmera de vídeo pequena;
§ Tripé para a câmera;
§ Se possível, microfone para conectar na câmera;
§ Computador com o software a ser avaliado instalado (normalmente usa-se o da

escola ou da casa);
Vale ressaltar que o ideal seria que a câmera, o tripé e o microfone fossem
levados para o local antes do dia do teste para que, caso algum imprevisto ocorra,
ainda seja possível contorná-lo. Se não for possível, deve-se pelo menos levar os
equipamentos para o local com certa antecedência.
Computador
Participante
Participante
Observadores Condutor
Responsável pela filmagem
FIGURA 19 −Ambiente de teste de software
100
FIGURA 20 − Foto de ambiente de teste realizado em escola
Os testes também podem ser realizados em um laboratório de Usabilidade.

Como esse laboratório será um ambiente novo para as crianças, antes do início do
teste deve -se mostrar todo o laboratório a elas, explicando os equipamentos e
apresentando os envolvidos. Assim, procura-se diminuir o desconforto causado pela
aparelhagem. Algumas avaliações de software deste trabalho foram realizadas no
Laboratório de Usabilidade do Departamento de Ciência da Computação da
Universidade Federal de Minas Gerais. A Figura 21 detalha esse ambiente,
mostrando seus equipamentos e a disposição dos mesmos. O laboratório é formado
por duas salas contíguas – sala de teste e sala de observação –, separadas por uma
parede com um espelho falso, isolando-as acusticamente e visualmente. Tal fato
possibilita que os presentes na sala de observação conversem e discutam durante o
teste sem causar nenhuma interferência. As crianças ficam na sala de teste
juntamente com o condutor, sentadas em frente ao computador. São filmadas três
visões diferentes do teste: a primeira focaliza os participantes e o condutor, a
segunda focaliza os participantes e a tela do computador e a terceira grava somente
a imagem da tela do computador. Durante o teste, essas imagens são transmitidas
na sala de observação, onde estão o responsável pela filmagem e os observadores.
O computador da sala de teste deve ser preparado com a instalação do software a
ser usado. Essa instalação, assim como todos os equipamentos do laboratório, deve
ser conferida antes dos testes.
101
Observadores
Responsável pela filmagem
Monitor Monitor Monitor tela Vídeo Caixa

filmadora 1 filmadora 2 computador cassete de som
Espelho falso
Filmadora 2 Participante
Computador
Condutor
Participante
Microfone
Filmadora 1
FIGURA 21 − Laboratório de Usabilidade
4.2.2.11.2. Materiais
Todos os questionários, formulários e scripts que serão utilizados nos testes

para a avaliação do software devem ser colocados na ordem em que serão usados,
formando um caderno para cada teste. Durante o teste, se o condutor perder tempo
na procura de algum papel, poderá perder alguma ação ou expressão importante da
criança. O primeiro documento do caderno deve ser a Lista de verificação, para que
seja seguida durante o teste.
4.2.2.12. Realização de testes de todos os itens
Assim que todos os materiais, equipamentos, participantes e ambiente dos

testes estiverem preparados, pode-se iniciar o processo de avaliação do software.
Devido ao grande número de itens envolvidos na avaliação, será de grande
importância que eles sejam testados anteriormente, prevenindo possíveis erros ou
defeitos na hora de realização dos testes. Para essa conferência, recomenda-se:
102
§ Realização do teste por um avaliador: o avaliador que planejou o teste deve usar
o próprio teste, colocando-se no lugar de uma criança. Durante o teste, o
avaliador deve procurar por falhas e verificar o tempo gasto, para garantir que ele
poderá ser realizado no tempo previsto. A leitura das perguntas do teste em voz
alta facilita a detecção de erros. Todos os problemas encontrados devem ser
então corrigidos.
§ Condução de um teste-piloto: se for possível, após a revisão feita pelo avaliador,

recomenda-se a condução de um teste-piloto usando uma criança com perfil
similar ao desejado. Um teste-piloto possibilita que o avaliador pratique a
condução do teste e refine seu planejamento por meio da descoberta de falhas.
Assim, evita-se que os primeiros participantes do teste sejam usados para a
descoberta desses erros.
§ Verificação do equipamento: deve-se conferir se o ambiente que será usado está

realmente reservado para o dia do teste, se o equipamento (câmeras, vídeos,
computadores) está disponível e funcionando, se os produtos a serem avaliados
estão corretamente instalados e sem defeitos.
§ Organização dos documentos: deve-se verificar se todos os padrões, formulários

e scripts que serão usados estão organizados por ordem de uso e em cadernos
separados para cada teste.
§ Verificação do status das crianças: deve-se conferir se todas as crianças

necessárias ao teste estão com presença garantida.
4.2.3. Fase de Realização dos testes
Tendo sido completada a fase de planejamento dos testes de avaliação,

pode-se começar os testes propriamente ditos. A ava liação de um software consiste
na aplicação do teste preparado com vários participantes, que, individualmente ou
em duplas, serão observados e questionados pelo condutor durante o teste. A seguir
estão descritas as atividades necessárias para sua realização, relacionadas em
ordem cronológica. Também são descritas algumas, resultado da condução dos
vários testes que foram realizados durante este trabalho.
103
4.2.3.1. Preparação do ambiente e dos observadores
Antes da entrada dos participantes, o avaliador deve:
§ Checar o funcionamento de todo o equipamento;
§ Verificar se os móveis usados no teste não atrapalharam a imagem da criança na

filmagem, tampando seu rosto ou a tela do computador;
§ Verificar se os materiais a serem usados estão presentes e organizados;
§ Instruir eve ntuais observadores sobre sua conduta. Observadores são pessoas
da equipe de avaliação, docentes, pais ou qualquer um que se relacione com a
avaliação e que deseje assistir aos testes. Os observadores devem ficar
afastados das crianças, ser discretos e não devem interferir durante o teste.
Caso queiram fazer alguma pergunta aos participantes, devem fazê-la ao final do
teste;
§ Ler a Lista de verificação preparada para o teste para relembrar-se sobre a

seqüência de eventos;
§ Preparar-se mentalmente, pois a tarefa de condução de um teste querer

concentração e paciência, principalmente ao lidar com crianças. O condutor
também deve estar preparado para o inesperado, podendo ser necessário
desviar um pouco do Plano de testes, caso ocorram eventos imprevistos.
Concluídos esses passos, o avaliador pode então solicitar a entrada das

primeiras crianças.
4.2.3.2. Cumprimentos e apresentação
O condutor deve receber as crianças (de preferência fora do local de

realização do teste), apresentar-se e conduzir uma pequena conversa (com
linguagem familiar) para conhecê-las melhor. Até a escolha da roupa a ser usada
deve ser planejada – deve-se dar preferência a roupas esportes, informais,
parecidas com as que as crianças usam. Assim, poderá tornar o ambiente mais
agradável, deixando as crianças mais confortáveis.
104
4.2.3.3. Recolhimento dos Formulários de consentimento
Se os Formulários de consentimento ainda não tiverem sido entregues por

docentes ou responsáveis, perguntar às crianças se elas estão com os formulários
preenchidos e recolhê-los.
4.2.3.4. Transmissão das informações contidas no Script de

orientação
Já no ambiente de realização do teste, o condutor deve transmitir para as

crianças as informações contidas no Script de orientação, tranqüilamente e em
linguagem de fácil compreensão. Não é recomendado que essas instruções sejam
lidas, pois isso torna o ambiente mais formal.
Se o teste não for conduzido no ambiente escolar ou familiar às crianças,

deve-se também mostrar todo o local à criança, explicando equipamentos e
apresentando os envolvidos no teste. O reconhecimento do ambiente faz com que a
criança confie mais no condutor e sinta-se mais segura.
4.2.3.5. Condução das perguntas da Entrevista com crianças
As perguntas da Entrevista com crianças são feitas no ambiente do teste, pois

em alguma pergunta pode ser necessário que a criança esteja vendo o software
(como na pergunta “Você já jogou este jogo?”, quando normalmente necessita-se
que a criança veja o software para conseguir responder). Caso o teste esteja sendo
realizado com duas crianças simultaneamente, podem ser feitas perguntas ao
mesmo tempo para elas, marcando a resposta de cada um separadamente, no
formulário de Entrevista com crianças.
4.2.3.6. Aplicação do Pré-teste
Antes da aplicação do Pré-teste, deve-se explicar para as crianças o seu

propósito, que é comparar o seu aprendizado antes e após o uso do software. Caso
o teste esteja sendo realizado com uma dupla, deve-se aplicar o Pré-teste com os
dois ao mesmo tempo, fornecendo o material necessário (papel, caneta ou lápis e
105
borracha 19 ), pedindo as tarefas relacionadas e registrando as anotações que forem
importantes.
Terminado o Pré-teste, caso as cri Resumo de dados anças tenham usado

algum formulário ou papel, verificar se eles estão identificados com o nome das
crianças e guardá-los.
4.2.3.7. Condução do teste
O condutor deve então iniciar a condução das tarefas a serem realizadas

pelas crianças. Com o Formulário de observação em mãos, o condutor vai
solicitando as tarefas, observando e anotando as ações, expressões e os
comentários relacionados. Durante cada tarefa, ele também deve estar atento às
perguntas relacionadas que estão listadas no Formulário de observação, procurando
sempre responder a elas.
Existem várias recomendações relacionadas ao comportamento do condutor

durante o teste que foram levantadas neste trabalho. Devido à importância delas
para a realização de testes de qualidade, decidiu-se colocá-las em capítulo a parte.
Elas estão descritas no Capítulo 6.
4.2.3.8. Realização do Pós-teste
Normalmente, o Pós-teste é realizado logo após o término das tarefas do

teste. Entretanto o avaliador pode considerar a opção de realizar o Pós-teste um
tempo depois do teste para verificar a “memorização compreensiva” 20 do
conhecimento.
Novamente, se o teste estiver sendo feito com duas crianças, deve-se aplicar
o Pós-teste simultaneamente, entregando para elas os materiais necessários,
solicitando as tarefas e realizando anotações. Após o término do Pós-teste, o
avaliador deve identificar os formulários com o nome de cada criança.
19
O condutor deve ter disponíveis caneta e lápis, deixando que a criança selecione qual deseja usar.
Algumas crianças estão acostumadas a usar somente lápis na escola e vão preferi-lo.
20
O termo “memorização compreensiva” foi utilizado para esclarecer que não se trata de uma
memorização sem significado. A criança entendeu o significado do conteúdo e depois memorizou-o.
106
4.2.3.9. Condução das perguntas do Questionário com crianças
Após a aplicação do Pós-teste, o condutor então coloca para as crianças as

questões listadas no questionário. Ele deve começar com perguntas gerais sobre o
software, deixando que elas falem de sua impressão mais marcante do programa.
Depois, o condutor passa para as perguntas específicas de algumas partes do
software, inclusive algumas que podem ter surgido durante o teste (o condutor pode
registrar pontos durante o teste para perguntar depois). O questionário é muito
importante para comparar a opinião real da criança com o que foi percebido pelo
condutor.
O condutor deve tentar fazer o questionário parecer mais uma conversa entre
amigos, deixando as crianças livres para falarem o que desejarem. O condutor não
deve, em nenhum momento, tomar parte do programa, pois pode interferir nas
respostas das crianças. Perguntas do tipo: “O jogo foi fácil de entender, não foi?”
não devem ser feitas, pois mesmo que a criança tenha achado o jogo difícil, poderá
concordar com o condutor, temendo ser ava liada negativamente.
4.2.3.10. Agradecimento e gratificação
Terminado o questionário, o condutor deve agradecer às crianças pela

participação, ressaltando que elas foram muito importantes na realização do teste. O
condutor pode então dar alguma gratificação a elas, como presentes, chocolates ou
balas. A gratificação, se permitida 21, demonstra à criança o reconhecimento por sua
participação. A partir daí as crianças poderão ser liberadas.
4.2.3.11. Organização de papéis coletados
Ao fim de cada teste, o condutor deve coletar todos os tipos de documentos

usados, organizá-los por teste e armazená-los em uma pasta, que será a pasta dos
documentos de avaliação do software.
4.2.3.12. Realização de acertos no teste
Durante a realização de um teste, podem ser encontrados alguns pontos em

que modificações são necessárias. Então, ao término da sessão do teste e antes de
21
Deve-se checar com docentes, pais ou responsáveis se a criança pode receber gratificações como
balas ou doces. Pode haver, por exemplo, crianças diabéticas.
107
iniciar a próxima, o avaliador deve fazer as alterações necessárias. Normalmente,
nos dois primeiros testes ocorrem mais alterações. A partir daí, um teste mais
estável é obtido.
4.2.4. Fase de Análise dos dados e Produção do Relatório final de

avaliação
Essa fase consiste na transformação de todos os dados coletados em

resultados e recomendações sobre o software. O trabalho de análise pode durar de
três a oito dias após o término dos testes e deve resultar em um relatório detalhado
da avaliação do software sobre suas questões pedagógicas e de Usabilidade. A
seguir são descritas as etapas envolvidas nessa fase:
4.2.4.1. Observação e análise das filmagens
O avaliador deve assistir às fitas de cada teste, quantas vezes forem

necessárias, detectando detalhes não levantados durante a condução do teste,
como reações das crianças, comentários e expressões. Muitas dessas observações
são perdidas durante o teste enquanto o avaliador faz algum registro, solicita alguma
tarefa ou em algum momento de distração. As anotações devem ser registradas no
Formulário de observação do teste, pois, assim, todos os dados levantados ficam
armazenados em um único documento, facilitando a análise posterior.
4.2.4.2. Transcrever e resumir os dados
O avaliador agora deve compilar, tabular e resumir os dados coletados. O

processo envolve colocar os dados em uma forma que permita a detecção de
padrões.
O primeiro passo a ser feito é a transcrição dos dados coletados em todos os

documentos (Entrevista com crianças, Pré e Pós-testes, Formulário de observação e
Questionário com crianças). O avaliador deve transferir todas as anotações para um
único documento e já tabular os dados quantitativos (como os de perfil da criança
contidos na entrevista). Se os testes durarem mais de um dia, essas transcrições
podem ser feitas inclusive ao final de cada teste, adiantando o trabalho. É importante
que esse passo seja feito assim que os testes terminarem, aproveitando-se do fato
de que os eventos ocorridos durante o teste serão facilmente lembrados pelo
108
avaliador. Mesmo com anotações detalhadas e filmagens, alguns eventos só são
registrados na memória do avaliador, e esses podem ser esquecidos facilmente.
O próximo passo é o resumo de todos os dados coletados. O avaliador deve

recuperar os documentos contendo as transcrições e resumir todos os dados
coletados em tabelas e sumários.
4.2.4.2.1. Formato sugerido para documento de Resumo dos

dados
Sugere-se que um documento de resumo de dados de testes contenha os

seguintes tópicos:
1 – Identificação: descrição do nome do software avaliado, a data do(s) teste(s),

número de crianças envolvidas, local de realização dos testes, avaliador e ambiente.
TABELA 26 − Exemplo de Identificação
Software avaliado Casa Mal Assombrada

Data(s) do teste(s) 19/9/02, 26/9/2002, 17/12/2002 e 18/12/2002
Número de crianças 13
Local Magnum Agostiniano (testes de 1 a 5)
Laboratório de Usabilidade do DCC/ICEx/UFMG
Avaliador Ana Paula Ribeiro Atayde
Testes de 1 a 5: Foram realizados no laboratório de informática da
escola, com crianças de 2ª a 4ª séries, que foram trazidas pela
professora, durante a aula. No laboratório, eles trabalharam em dupla.
Descrição do ambiente Alguns testes foram filmados por uma câmera.
Testes 6 e 7: Foram realizados no laboratório de Usabilidade do
ICEx/UFMG. As crianças foram trazidas pelos pais e trabalharam em
dupla nos testes. Todos foram filmados.
2 – Resumo das tarefas do Plano de testes: listagem das tarefas solicitadas no

Plano de testes e resumo do ocorrido em cada teste. De acordo com RUBIN (1994),
as tarefas representam a visão ou o objetivo dos participantes. Portanto, ao resumir
os dados baseado nas tarefas, o avaliador tem uma visão dos dados do ponto de
vista da criança, que é um dos objetivos da avaliação. Também deve -se resumir os
resultados das tarefas por meio do levantamento da porcentagem de crianças que a
concluíram com sucesso.
109
TABELA 27 – Exemplo de resumo de tarefas do Plano de testes
Nº Descrição Detalhes Teste 1 Teste 2 ... Teste 7 Conclusão

Abra o Não leram Não leram Não leram 70% não leram
1 - ...
jogo tela inicial. tela inicial. tela inicial. tela inicial
Req: 100%
Na tela
Software em Entraram Entraram Entraram acessaram jogo
principal,
tela inicial corretamente, corretamente, corretamente, corretamente.
2 entre no ...
CS: Entrar mas não leram tela não leram tela 70% não leram
jogo X e
no jogo leram tela inicial do jogo. inicial do jogo. tela de
CH
solicitado apresentação.
Req: Tela Como já Como já
do jogo X e haviam haviam
CH jogado antes, jogado, 100%
Faça o CS: Fazer entenderam e entenderam Entenderam e conseguiram
3 ...
exercício as 30 jogaram até o e jogaram. jogaram. jogar sem
palavras e fim. dificuldades
ver tela de
resultado
... ... ... ... ... ... ... ...
Req: Tela
100% saíram
Saia do inicial
20 OK OK … OK corretamente
jogo CS: Sair
do software.
pela “saída”
3 – Respostas do questionário do Plano de teste: tabela contendo as perguntas

sobre o software que foram feitas no Plano de teste e os resultados das respostas
obtidas que podem ser divididas pelo perfil do participante (por exemplo, entre
experientes e novatos).
110
TABELA 28 – Exemplo de respostas das perguntas listadas no Plano de testes
Sim Não
Perguntas sobre o software em geral
E I E I
- Crianças confundem os botões “chega” e ”outro”? 3 2 2
- Crianças gostam das figuras, personagens, animações? 4 2 1
- Crianças entendem a linguagem usada no software? 4 2 2
- Crianças entendem o número de tarefas do jogo? 5 2
- Crianças gostam das telas de resultado? 2 2
- Crianças gostariam que o jogo tivesse recursos sonoros? 5
- Crianças quiseram aumentar a tela? 4
- Melhoraram no pós-teste 3 2 2
Perguntas sobre os jogos
- Crianças lêem telas de entrada dos jogos? 9 5 27 12
- Crianças lêem regras? 9 11 14 3
- Crianças entendem o que fazer nos jogos? 22 14 8 1
- Crianças entendem que erraram? 16 6 2 3
- Criança(a) pensa? (não corresponde a tentativa e erro) 27 8 3 2
- Mudança na posição dos botões “outro” e ”chega” influi? 1 14 8
- No exercício ”c ç s ss xc sc”, crianças clicam somente uma vez? 5 1
- No exercício “s x z”, crianças tentam usar mouse? 3 2 1 1
- No exercício “homônimos e parônimos”, lêem explicação ao errar? 1 1 4 1
Legenda: E – Experientes I – Iniciantes
4 − Erros: identificação dos erros e dificuldades ocorridos durante as tarefas que

causaram performance incorreta ou mesmo alguma frustração da criança. Pode-se
também identificar a fonte de cada erro (aqui o foco muda da tarefa para o produto),
atribuindo uma razão do produto para a dificuldade ou erro ocorrido e qual heurística
o erro/dificuldade viola. Em seguida, classificam-se os erros pela soma da gravidade
do problema com a sua freqüência de ocorrência (RUBIN, 1994):
Classificação do erro = ranking de gravidade + ranking de freqüência
Categoriza-se o erro pela sua gravidade, como sugerido na escala de quatro

valores descrita na Tabela 29.
111
TABELA 29 − Ranking de gravidade dos erros e dificuldades
Descrição da
Ranking Definição
gravidade
A criança estará impossibilitada, não entende ou não desejará

usar/pensar em determinada função do software.
Exemplos:
4 Não-usável
- Software trava em determinada ação da criança;
- Desenho do software possibilita que criança descubra a
resposta sem ter que raciocinar na tarefa.
A criança poderá usar/entender a função em questão, mas

com grande esforço/dificuldade/ajuda.
Exemplos:
- Software não possibilita a reversão de uma ação. Criança
3 Grave tem que esperar terminar o jogo para começar a tarefa
toda novamente, trocando os valores;
- Software não disponibiliza regras claras, criança não sabe
o que fazer em uma tarefa, necessitando de ajuda do
docente ou dos pais.
A criança poderá usar/entender a função, mas com algum

esforço/ajuda.
Exemplos:
- Software usa um padrão para a representação do número
2 Moderado de jogos que é semelhante à forma que outros programas
populares representam possibilidades de erro. Crianças
tendem a associações de padrões previamente usados
nos outros programas.
- Desenho do software contém muita informação, criança
pode se perder e demorar para compreender tarefa.
O erro/dificuldade pode ser revertido facilmente pela criança,

sem ajuda.
Exemplo:
- Software disponibiliza somente uma forma de entrada de
dados: criança tenta clicar em “enter” em vez de selecionar
1 Superficial
objeto com mouse.
- Software tem diferentes feedbacks de erros para os seus
jogos, ou seja, não mantém consistência nos feedbacks.
Crianças às vezes esperam determinado tipo de feedback
e recebem outro.
112
Em seguida, classifica-se o erro pela sua freqüência de ocorrência: somam-se
as ocorrências do erro nos testes e classifica-se como sugerido na Tabela 30.
TABELA 30 − Ranking de freqüência de ocorrência
Ranking de freqüência de Freqüência estimada de ocorrência

ocorrência
4 > 90% das vezes
3 51 a 89% das vezes
2 11 a 50 % das vezes
1 < 10% das vezes
Os erros serão então classificados simplesmente pela soma da gravidade

com ocorrência. Por exemplo, se um erro é superficial (ranking de gravidade 1), mas
ocorre 90% das vezes (ranking de ocorrência 4), terá sua classificação final 5. Da
mesma forma que um que seja não-usável (ranking de gravidade 4) mas que ocorra
somente 5% das vezes (ranking de ocorrência 1). Um exemplo dos erros listados em
um software está descrito na Tabela 31 .
TABELA 31 − Exemplo de erros encontrados em software e suas classificações
Heurística(s) Ranking de Ranking de Classifica-

Nº Erro Fonte
violada(s) freqüência gravidade ção final
Seleção O significado dos
errônea do botões de saída e Significado de 2
1
1 botão para troca de jogo não é códigos e (43% ou em 3
(Superficial)
mudar de claro, causando denominações 3 testes)
jogo. confusão.
Os textos
introdutórios de cada
jogo do software
aparecem e
Não-leitura
desaparecem em Controle e 4
da tela de 3
2 tempo determinado autonomia do (100% ou 7 7
apresentaçã (Severo)
pelo software. Como usuário testes)
o dos jogos
este tempo é rápido,
não dá tempo
suficiente para a
leitura dos mesmos.
Interpretaçã A forma de
o errada do representação do
significado número de telas nos
Correspondência
de figuras jogos é igual à que 3
com outros 2
3 que outros jogos usam (86 % ou 6 5
programas (Moderado)
representam para representar testes)
similares
número de possibilidade de
telas nos erros. As crianças
jogos fazem associação.
... ... ... ... ... ... ...
A listagem e a classificação dos erros são muito importantes para a avaliação

do software, portanto o avaliador deve fazer um trabalho detalhado e minucioso,
113
gastando o tempo que for necessário. Talvez precise rever as fitas, o software, os
princípios de Usabilidade, as heurísticas relacionadas e os documentos dos testes.
5 – Resumo do teste: resumo geral dos testes, ressaltando os pontos mais

importantes.
TABELA 32 − Exemplo de resumo do teste
Resumo
O objetivo do jogo foi atingido, pois muitas crianças acertaram palavras que haviam errado no
pré-teste após jogarem os jogos.
Alguns problemas superáveis foram detectados, como:
- uso do teclado ou mouse deveria ser sempre possível;
- a diferenciação de erro/acerto nos jogos deveria ser mais clara;
- tela com frases introdutórias dos jogos não são lidas, pois o tempo para a leitura é curto;
- identificação do número de telas em alguns jogos não é compreensível para as crianças;
- entre outros (vide erros).
O problema mais sério foi encontrado no jogo JG, em que deve-se arrastar a letra J ou G para
completar as palavras. Mas ao chegar com a letra na palavra, se esta estiver errada, o jogo muda a
forma do mouse para uma bola vermelha cortada, indicando erro. Então, algumas crianças
interpretaram como se o jogo desse a resposta, pois não possibilita que eles coloquem a letra. Ou
seja, o feedback de erro é dado antes que a tarefa seja completada pela criança.
Crianças gostaram dos jogos, principalmente do jogo X CH, devido à animação usada no jogo (uma
flecha acerta a bruxa, saindo sangue).
Outros pontos levantados:

- A localização das regras (escritas na interface) facilitou o acesso quando precisaram delas. O fato
de serem curtas também ajudou.
- Meninos gostam das animações, meninas muitas vezes não.
- No jogo Homônimos e parônimos, normalmente não lêem explicações.
- Várias crianças quiseram aumentar o tamanho da tela, o que o jogo não possibilita.
- Muitas palavras são desconhecidas pelas crianças.
- Crianças gostariam que tivesse recursos sonoros.
- Falta no jogo uma tela para configuração e um “help”.
- O jogo poderia ter um banco de dados com palavras diferentes, para aumentar sua vida útil.
- Tela de resultado não aparece em todos os jogos, não há consistência.
- O software proporciona um ambiente de competição entre as crianças, não influenciando no
raciocínio.
- Crianças gostaram mais dos jogos X CH (gostam das animações usadas neste jogo) e Bingo.
Dizem não gostar dos jogos que são fáceis.
- Uma criança teve dificuldade em arrastar, com o mouse. Ela preferia que fosse por cliques do
mouse.
O documento-padrão para o Resumo de dados está descrito no Anexo VII.
4.2.4.3. Produção do Relatório final de avaliação
A produção de um relatório final de avaliação do software sempre deve ser

feita, mesmo que seja pequeno, somente para o avaliador. O documento serve
como um registro histórico e ferramenta de comunicação do trabalho realizado.
114
O Relatório final de avaliação deve ter uma seqüência lógica, com início, meio
e fim. O início deve conter o dados explicativos sobre a avaliação e sobre o
software; o meio descreve os problemas detectados e as análises qualitativas e
quantitativas realizadas; e o fim apresenta as conclusões e recomendações. O
Relatório final de avaliação não deve ser muito técnico ou cansativo, pois os
interessados devem conseguir lê-lo com facilidade.
Em programas do tipo educacional infantil é importante que o Relatório final

de avaliação contenha análise das questões de Usabilidade e das questões
pedagógicas do software. Sugere-se que o Relatório descreva se o software está de
acordo ou se viola heurísticas pedagógicas e de Usabilidade (como as descritas no
Capítulo 5). Além disso, o relatório também deve descrever qual o tipo de
aprendizagem o software privilegia e em qual contexto pode ser melhor aproveitado.
Assim, uma escola poderá verificar se o software é adequado à sua proposta
pedagógica.
4.2.4.3.1. Formato sugerido para Relatório final de avaliação
A seguir, descreve -se e exemplifica-se uma sugestão para o relatório de

avaliação de um software educacional infantil. Ele deve conter os seguintes tópicos:
1 – Escopo: relação de dados sobre o relatório (descrição e público-alvo) e resumo

dos dados da avaliação, como data de realização dos testes, número de crianças
envolvidas, local de realização, ambiente, tempo para produção do relatório22.
22
O tempo é coletado para cálculo posterior do curso da avaliação.
115
TABELA 33 − Exemplo de escopo
Descrição Este documento descreve a avaliação do software Casa Mal

Assombrada, realizada por meio de vários testes com
crianças, produzindo conclusões e recomendações sobre o
uso do software.
Público-alvo Docentes, pais e interessados no estudo de avaliação de
software educacional infantil.
Data do(s) teste(s) 19/9/02, 26/9/2002, 17/12/2002 e 18/12/2002
Número de crianças envolvidas 13
Local de realização Magnum Agostiniano (testes de 1 a 5) e Laboratório de
Usabilidade do DCC/ICEx/UFMG (testes 6 e 7)
Ambiente Testes de 1 a 5: Foram realizados no laboratório de
informática do colégio Magnum, com crianças de 2ª a 4ª
séries, que foram trazidas em pares pela professora durante
a aula. Alguns testes foram filmados por uma câmera.
Testes 6 e 7: Foram realizados no Laboratório de
Usabilidade do ICEx/UFMG. Crianças foram trazidas pelos
pais e trabalharam em duplas nos testes. Todos foram
filmados.
Tempo para produção do relatório 3 horas
2 – Identificação do software: Descrição dos dados coletados sobre a identificação

do software, como nome, empresa fabricante, objetivo, disciplina, idioma,
armazenagem, preço e resumo.
TABELA 34 − Exemplo de identificação do software
Nome Casa Mal Assombrada

Empresa SENAI
Objetivo Trabalhar a grafia correta de grupos de palavras da língua portuguesa
Disciplina(s) Português
Idioma Português
Armazenagem CD-Rom
Preço Informação não-disponível
O software contém vários jogos. Cada jogo trabalha a grafia correta de um
Resumo grupo de palavras da língua portuguesa: X/CH, C/Ç/SS, S/X/Z,
Homônimos e Parônimos, entre outros
3 – Documentação relacionada: listagem de toda a documentação necessária

(formulários, fitas, relatórios) para que todas as fontes de dados usadas na produção
do relatório de avaliação possam ser recuperadas, caso necessário.
116
TABELA 35 − Exemplo de documentação relacionada

1 Heurísticas
2 Resumos de dados coletados em teste de software
3 Fitas contendo filmagem dos testes
4 – Problemas do software: listagem das fontes de erros detectadas durante a

depuração dos dados (retirados do documento de Resumo de dados). Deve-se listar
o problema (fonte do erro), a classificação final (de 0 a 8) e a heurística violada,
como mostra a Tabela 36.
TABELA 36 − Exemplo de problemas encontrados no software
Classificação Heurística(s)
Nº Problemas
(8-0) violada(s)
Os textos introdutórios de cada jogo do software
aparecem e desaparecem em tempo determinado Controle e liberdade
1 7
pelo software. Como este tempo é rápido, não dá do usuário
tempo suficiente para leitura.
Feedback de erro no jogo “j g” é dado antes que a
tarefa seja completada. Ao tentar colocar uma
Feedback (não é
2 letra errada, o jogo muda o mouse indicando que 6
adequado)
está errado, então a criança entende isso e pára
de pensar no jogo. Vai por tentativa e erro.
A forma de representação do número de telas em
Correspondência com
vários dos jogos é igual à que outros jogos
3 5 outros programas
populares usam para representar possibilidade de
similares
erros. As crianças fazem associação.
Consistência e
Alguns jogos do software têm entrada de dados ou padrões
4 5
seleção de objetos via mouse, outros via teclado.
Flexibilidade
Regras do jogo “c ç ss” não deixam claro para
clicar no quadrado em branco.
Documentação de uso
5 Como o local onde deve-se clicar é um quadrado
5 direcionada a crianças
em branco, criança tem o intuito de clicar onde as
(regras)
letras estão escritas.(Os quadrados em branco
deveriam ter as letras).
A identificação da palavra inicial do jogo “c ç s ss Reconhecimento no
6 4
xc sc” não está clara, confundindo as crianças. lugar de memorização
Se a MAQSEI estiver sendo aplicada para um software em desenvolvimento,

é também interessante que o avaliador, juntamente com o desenvolvedor do
programa, acrescentem uma possível solução a cada um dos problemas,
adicionando-as na tabela, como mostra a Tabela 37.
117
TABELA 37 − Exemplo de problemas encontrados no software
Classificação Heurística(s)
Nº Problemas Solução
(8-0) violada(s)
Como a figura utilizada como
Pouco mais de um terço ícone não tem nenhuma relação
dos participantes tive Significado com a odontologia, sugere-se sua
1 dificuldade na localização 3 de código e substituição por uma que
do ícone de atalho para o denominação identifique a odontologia, como
software. uma escova de dente ou mesmo
somente um dente.
5 − Análise qualitativa dos atributos técnicos e pedagógicos: exame do software em

relação às heurísticas pedagógicas e técnicas também desenvolvidas neste estudo.
Sugere-se que, para cada uma das heurísticas listadas no Capítulo 6, o avaliador
descreva se o software está de acordo ou se a viola de alguma forma. As heurísticas
servem como referência para que o avaliador certifique-se da análise de vários
pontos importantes no programa, que poderiam ser esquecidos. Aqui, pode ser
necessária a revisão de fitas, documentos e até mesmo do software, para recordar-
se de detalhes. Um exemplo de análise qualitativa de algumas das heurísticas está
descrita na Figura 22.
118
Pertinência em relação à proposta pedagógica
O software trabalha com a disciplina Língua Portuguesa, mais especificamente com a grafia de
vários grupos de palavras.
O ambiente do software não é aberto, não dá à criança nenhuma outra possibilidade de criar
outros cenários e outras atitudes frente aos objetos. O processo se desenrola em torno do erro e do
acerto. Não apresenta múltiplos caminhos para solução de problemas, só aceita as respostas
prédeterminadas.
Mas o software é uma ferramenta de auxílio ao docente no ensino de palavras que, normalmente,
causam dúvidas na sua grafia.
Utilização de recursos computacionais
O maior diferencial do software em relação a outros meios de ensino é o uso de animações nos
jogos. O ambiente proporciona interesse das crianças, por se tratar de uma casa “mal assombrada”,
com bruxas, fantasmas, caveiras.
Avaliação da aprendizagem
O único tipo de avaliação da aprendizagem apresentada foram telas com resultados gerais após
término de determinados jogos, mostrando número de acertos e número de erros das crianças.
O software não possibilita nenhum tipo de armazenamento de respostas e/ou ações das crianças.
Interação
O software disponibiliza meios para informar e conduzir a criança na interação (mensagens,
botões, figuras).
O software permite que se saiba, em qualquer momento, o ponto em que se encontra numa
seqüência de interações ou na execução de uma tarefa, mas a identificação dessas em alguns
jogos é falha, devido à correspondência que crianças fizeram com a forma de representação de
número de erros em jogos similares (vide lista dos problemas, item 3).
Reconhecimento no lugar de memorização
O software permite que a criança saiba em que ponto se encontra no software e o que fez para se
encontrar nessa situação.
O software não exige da criança esforços extras para memorizar como utilizá-lo.
Alguns problemas de interface foram encontrados:
- A identificação da palavra inicial do jogo “c ç s ss xc sc” não está clara, confundindo as crianças;
(vide problemas, item 6)
- No jogo “s x z”, como essas letras estão na interface, crianças entendem que são para serem
clicadas, mas na verdade o jogo solicita que essas sejam digitadas.
Qualidade das opções de ajuda
O software não disponibiliza recursos por meio de explicações fornecidas em sistemas de ajuda.
Legibilidade
Os textos do software são claros e bem-redigidos. A linguagem usada é familiar às crianças.
Feedback
O feedback está presente em todos os jogos do software, mas ocorrem vários problemas,
principalmente ligados à diferenciação de feedback de erro ou acerto, falta de sonorização dos
mesmos e feedback transmitidos em momentos inadequados.
Vide problemas, itens 2, 7, 8 e 9.
Agrupamento e distinção de itens
Não foi detectado nenhum problema relacionado ao item, o que indica que os textos, figuras e
botões do software estão bem-organizados.
.....
FIGURA 22 − Exemplo de análise qualitativa de aspectos técnicos e pedagógicos
119
6 − Análise quantitativa dos atributos técnicos e pedagógicos: verificação quantitativa
da conformidade do software com as heurísticas técnicas e pedagógicas. Com base
nas heurísticas listadas no Capítulo 6 e trabalhos relacionados (CRONJE, 2001;
CAMPOS, 1994; GAMEZ, 1998), foi elaborada uma lista de verificação para ajudar
na avaliação quantitativa dos aspectos técnicos e pedagógicos de um software
educacional infantil. A lista é composta por um conjunto de questões a serem
respondidas sobre o programa, listadas por critério (he urística). Esse passo foi
elaborado de forma a proporcionar ao avaliador um instrumento no auxílio à
inspeção de conformidade do software em relação às heurísticas. Em concordância
com GAMEZ (1998), sugere-se, portanto, que o avaliador :
a) Leia todas as questões propostas na lista de verificação para um

determinado critério, identificando se ela se aplica ao software e
atribuindo-lhe um peso referente ao seu grau de comprometimento com o
software. A Tabela 38 apresenta uma sugestão para a atribuição dos
pesos.
TABELA 38 − Grau de importância e peso das questões
Importância Peso
Não se aplica 0.00
É pouco importante 0.33
É Importante 0.66
É muito Importante 1.00
b) Responda a todas as questões consideradas como aplicáveis. O softwa re

pode atender à questão, atender parcialmente ou não atender. Para cada
uma dessas respostas sugere-se um valor, conforme descrito na Tabela
39.
TABELA 39 − Valor de cada questão
Resposta da questão Valor

Sim 1.0
Parcialmente 0.5
Não 0.0
c) Calcule o resultado de cada questão, multiplicando o seu peso (grau de

importância) pelo valor da sua resposta.
d) Calcule a conformidade do software com cada critério: soma-se o

resultado de todas as questões do critério e, para obter a porcentagem,
divide-se pelo número de questões e multiplica-se por 100:
120
n º questões
∑ valor (i ) * peso (i)

i=1
Conformida de(critério ) = * 100
N º questões
Em que i indica o número de ordem da questão. O resultado obtido indica o

percentual de conformidade do software em relação ao critério em avaliação.
O avaliador deve aplicar essa equação a todos os critérios, encontrando os
percentuais de conformidade de cada um. A Tabela 40 exemplifica o cálculo
de conformidade de um software em relação ao critério “Pertinência em
relação a uma proposta pedagógica”.
TABELA 40 − Exemplo de cálculo de conformidade para o critério Pertinência em relação a

uma proposta pedagógica
Critério Atributos /Questões Peso S P N Res

1. Permite a identificação do modelo de
1.0 √ 1.0
aprendizagem que ele privilegia?
2. Permite a realização do ciclo descrição –
0.0 0.0
execução – reflexão – depuração – descrição?
3. O software é adequado e pertinente em relação
1.0 √ 1.0
a uma disciplina específica?
Pertinência 4. O software pode ser integrado no conteúdo

em relação a curricular e outras partes do currículo escolar 1.0 √ 1.0
uma proposta para auxiliar no aprendizado da disciplina?
pedagógica 5. O software realmente auxilia as crianças na
aquisição das habilidades e conteúdos 1.0 √ 1.0
propostos?
6. Os docentes da escola teriam facilidade em
adotar o software como parte das suas 1.0 √ 0.5
atividades?
7. O objetivo do software é claro? 1.0 √ 1.0
Conformidade (5.5 / 7)*100 = 78,6 %

Legenda: S – Sim P – Parcialmente N – Não Res – Resultado
e) Uma vez encontradas as conformidades do software para todos os

critérios, o avaliador poderá construir um gráfico com os valores obtidos,
como exemplificado na Figura 23. A análise do gráfico permite ao
121
avaliador identificar os pontos críticos no software e ainda comparar
resultados entre diferentes programas.
Documentação 22,6
Correspondência entre o software e o mundo real0
Consistência e Padrões 50
Significado de códigos e denominações 66,7
Conteúdo 50
Carga de trabalho 59,6
Gestão de erros 31,4
Recursos motivacionais 48,6
Controle e Autonomia do usuário 43,8
Adaptabilidade 15,3
Interação 41
Avaliação da aprendizagem 29,2
Utilização de recursos computacionais 6,7
Pertinência em relação a uma proposta pedagógica 78,6
0 10 20 30 40 50 60 70 80 90
FIGURA 23 − Exemplo de gráfico de conformidade de software com critérios de avaliação
7- Conclusões e recomendações: descrição das informações mais relevantes

levantadas pelo avaliador sobre o uso do software por crianças. É importante que
sejam descritas quais habilidades, aspectos cognitivos e afetivos podem ser
desenvolvidos com o software, além da melhor forma de ser utilizado. Podem ser
descritos também os principais pontos positivos e negativos do programa. É uma
seção muito importante, pois resume todos os dados levantados e, muitas vezes, é a
única parte realmente lida do Relatório final de avaliação. Portanto, o avaliador deve
ter em mente o que os interessados desejam saber sobre o software ao escrevê-la.
A Tabela 41 descreve um exemplo.
122
TABELA 41 − Exemplo de conclusões e recomendações
Conclusões e recomendações
O software, apesar de ser ter sido considerado como fechado, não possibilitando flexibilidade de
uso para crianças ou docentes, pode ser usado quando o(a) docente está trabalhando a grafia de
grupos de palavras da língua portuguesa.
Foram encontradas algumas falhas (vide problemas), que podem ser corrigidas com o auxílio
do(a) docente, o que é indispensável para que a criança não limite sua capacidade de curiosidade e
busque sempre o conhecimento baseado em discussões sobre determinada dúvida. A maior falha
encontra-se no jogo “j g”: as crianças interpretam o jogo como se ele fornecesse as respostas, ou
seja, elas não precisam raciocinar durante as tarefas, simplesmente completam as palavras por
tentativa e erro. Isso ocorre devido ao feedback antecipado que o jogo fornece sobre a resposta
certa/errada. Em vez de esperar que a criança coloque a resposta para conferi-la posteriormente, o
jogo não possibilita que respostas erradas sejam colocadas. Portanto, recomenda-se que o jogo
somente seja usado se o(a) docente/pai puder acompanhar de perto o processo, verificando se as
crianças estão realmente raciocinando.
Um dos fatores positivos do software foi a simulação de um ambiente com personagens de uma
casa mal assombrada. O uso desses personagens, animações e coloridos despertou a atenção das
crianças, motivando-as.
O formulário-padrão para o Relatório final de avaliação de software

educacional infantil está descrito no Anexo VII.
Durante toda a fase de Análise de dados e Produção do Relatório final de

avaliação, é interessante que o avaliador discuta com representantes das áreas de
educação, psicologia e informática, obtendo outras perspectivas e visões sobre o
uso e a aplicação do programa.
4.3. Custo da avaliação
O custo para a realização da avaliação de um software pode ser calculado

pelo esforço na preparação, na condução e na análise dos testes. Portanto, pode-se
estimá-lo pela contagem do número de horas gastas para a realização de cada fase
da avaliação. Esses tempos dependerão de alguns fatores, como a complexidade do
software e a experiência do avaliador, mas pode-se fazer estimativa baseada na
média de dados previamente obtidos.
Durante todas as avaliações de programas educacionais infantis realizadas

neste trabalho foram coletados os tempos de realização de cada tarefa de cada fase
da MAQSEI. A Tabela 42 resume esses dados, mostrando o tempo médio gasto em
cada uma das tarefas e fases da MAQSEI. O resultado final produz uma estimativa
123
do tempo despendido na avaliação de software educacional infantil de
complexidade23 e experiência24 médias por um avaliador.
23
Neste estudo, adotou-se como medida de complexidade do software o número de tarefas/jogos
existentes no programa. Programas com até duas tarefas foram considerados de complexidade
baixa, de três a cinco tarefas de complexidade média, e a partir de seis tarefas, de complexidade alta.
Como foram avaliados programas de baixa, média e alta complexidade, considerou-se a estimativa
encontrada como referente a software de conformidade média.
24
Como a experiência do avaliador foi evoluindo de baixa para alta no decorrer das avaliações
realizadas, ela foi considerada como média para a estimativa realizada.
124
TABELA 42 − Tempos despendidos nas fases da metodologia
Fase Tarefa Tempo Total
Reconhecimento e Entrevistar docentes (2 ou 3) da escola; 3 horas
proposta de
8h
avaliação do Familiarizar com o software e registrar anotações; 4 horas
software
Preparação do Plano de testes; 8 horas
Preparação de Formulário de consentimento; 30 minutos
Preparação de Script de orientação; 25 minutos
Preparação de Entrevista com crianças; 30 minutos
Preparação de Pré e Pós-testes; 40 minutos
Planejamento dos Preparação de Formulário de observação; 3 horas 18 h e
testes Preparação de Questionário com crianças; 1 hora 50 min
Preparação de Lista de verificação; 15 minutos
Preparação do ambiente, dos equipamentos e dos
3 horas
materiais;
Realização de testes de todos os itens do teste pelo
1 ½ hora
avaliador;
Preparação do ambiente e dos observadores; 45 minutos
Teste 1:
- Cumprimentos e apresentação;
- Recolhimento dos Formulários de consentimento;
- Transmissão das informações contidas no Script de
orientação;
- Condução das perguntas da Entrevista com crianças; 2 horas
- Aplicação do Pré-teste;
- Condução do teste;
- Realização do Pós-teste;
- Condução das perguntas do Questionário com crianças;
- Agradecimento e gratificação;
Organização de papéis coletados; 15 minutos 10 h e
Realização de acertos no teste; 1 hora 10 min
Realização dos Teste 2:
testes - Cumprimentos e apresentação;
- Recolhimento dos Formulários de consentimento
- Transmissão das informações contidas no Script de
orientação;
- Condução das perguntas da Entrevista com crianças; 1 hora e
- Aplicação do Pré-teste; 40 minutos
- Condução do teste;
- Realização do Pós-teste
- Condução das perguntas do Questionário com
crianças;
- Agradecimento e gratificação;
Organização de papéis coletados; 15 minutos
Realização de acertos no teste; 30 minutos
4 horas e
Testes 3 a 5;
30 minutos
Observação e análise das filmagens; 16 horas
Transcrição dos dados; 8 horas
Análise de dados e Resumir dos dados; 6 horas
Produção do 42
Relatório final de Produção do relatório final: horas
avaliação - Verificar heurísticas qualitativamente;
12 horas
- Verificar heurísticas quantitativamente;
- Produzir recomendações e resultados;
Total 79 horas
125
Pode-se concluir então que, para a avaliação de um software educacional
infantil de complexidade e experiência médias por um avaliador, são necessários de
13 a 15 dias (seis a cinco horas de trabalho por dia).
4.4. Conclusão do capítulo
A MAQSEI possui alguns aspectos que merecem atenção:
§ Em todas as fases da MAQSEI (Reconhecimento do software, Planejamento dos

testes, Realização dos testes e Análise dos dados e Produção do relatório final),
é necessário que o avaliador do programa conheça e tenha em mente as
heurísticas desenvolvidas neste trabalho:
- Durante a fase de Reconhecimento de software, o avaliador usa as

heurísticas para facilitar a identificação de possíveis defeitos no programa;
- Durante a fase de Preparação dos testes, o avaliador deve rever as

heurísticas para que possa formular perguntas e tarefas que elucidem
problemas relacionados;
- Durante a fase de Realização do testes, o avaliador precisa conhecê-las para

que possa confirmar os problemas já levantados e detectar outros que
surgirem;
- Especialmente na fase da Análise dos dados e Produção do Relatório final de

avaliação, o avaliador deve examinar o software minuciosamente em relação
a cada uma das heurísticas, tanto qualitativamente (descrevendo se o
software está de acordo ou se as viola de alguma forma), quanto
qualitativamente (respondendo a um conjunto de questões relacionadas e
pontuando-as ). Essas avaliações possibilitam a produção de resultados mais
confiáveis, concretos e concisos (metas previamente estabelecidas para a
MAQSEI), visto que mostram os resultados de forma descritiva e gráfica.
Portanto, as heurísticas são de grande valor para a metodologia, fundamentando

todo o processo.
§ Outro ponto importante da MAQSEI é a observação de crianças utilizando o

software. Pela observação delas, muito é descoberto ou confirmado. Assim como
em outras técnicas de Usabilidade (RUBIN, 1994), somente ao colocar o
126
programa em uso pelo seu público-alvo é que realmente podemos verificar suas
aplicações, falhas e pontos fortes, além de ajudar na descoberta das
necessidades e preferências das crianças.
§ As técnicas e formas de coleta de dados da MAQSEI resultaram de uma

combinação de métodos de avaliação de software existentes (PLUM e TELL,
2000; RUBIN, 1994), com várias adaptações e extensões para atender às
necessidades e metas da metodologia. Apesar de alguns métodos praticamente
não precisarem sofrer alterações (por exemplo, nas técnicas de resumo de
dados), muitos sofreram modificações no sentido de adaptá-los para o público
infantil.
§ Ao analisar um software educacional infantil, a MAQSEI permite a descrição das

características pedagógicas e técnicas a que o programa atende. O atendimento
parcial de alguma característica nem sempre invalida a escolha do produto, mas
pode representar limite para a sua utilização. Cabe aos pais ou docentes a
escolha pela adoção ou não do programa, dependendo do que esperam obter do
mesmo.
Dessa forma, a MAQSEI concorre para a análise de software educacional

infantil, avaliando se ele pode ser considerado de qualidade em termos de
Usabilidade e se apresenta seu conteúdo de acordo com uma proposta pedagógica,
propiciando o aprendizado.
127
5. HEURÍSTICAS
5.1. Introdução
Neste capítulo são apresentadas as heurísticas para avaliação ou

desenvolvimento de software educacional infantil, desenvolvidas para a Metodologia
de Avaliação de Qualidade de Software Educacional Infantil (MAQSEI). As
heurísticas abrangem tanto o aspecto técnico, de Usabilidade do software, quanto o
aspecto pedagógico, da relação de ensino/aprendizagem entre criança e software.
Tal integração foi realizada, pois muitos dos temas abordados mostraram-se
semelhantes ou complementares às duas áreas, com resultados sinergéticos em
sua utilização. As heurísticas podem ser utilizadas tanto durante a produção de um
software educacional infantil, como diretrizes para o desenvolvedor, quanto para a
avaliação de qualidade de programas prontos por especialistas de área técnica ou
pedagógica.
Heurísticas são utilizadas em Usabilidade na forma de diretrizes que,

geralmente, mostram o caminho para a obte nção de melhores produtos. A utilização
de heurísticas é muito difundida e recomendada na literatura (CONSTANTINE, 1999;
NIELSEN, 1993), mas devem ser aplicadas com critério e após uma análise da
situação específica. Se aplicadas com bom senso, podem trazer ótimos resultados,
mas se aplicadas indiscriminadamente, podem ter efeitos indesejados. Por exemplo,
uma heurística propõe o uso de recursos motivacionais em software educacional
para crianças. Apesar de sua utilização ser recomendada, se usados sem cautela
esses recursos podem distrair a criança, atrapalhando na sua reflexão sobre o
conteúdo do software. Portanto, as heurísticas não são aplicáveis em todas as
situações. Há, inclusive, o caso clássico de heurísticas aparentemente
contraditórias, em que cada uma pode ser aplicada em uma situação específica que
a torne mais relevante ou pertinente. Deve-se então estudar e avaliar cada caso
específico na aplicação das heurísticas.
Pouco existe na literatura sobre diretrizes que unam as questões pedagógicas

e tecnológicas para desenvolvimento ou avaliação do software educacional infantil
(CAMPOS, 1994), por isso a necessidade de desenvolvê-las. Em CONSTANTINE
(1999) e NIELSEN (1993), são descritas diretrizes voltadas para o público adulto.
128
GAMEZ (1998) e CRONJE (2001) apresentam diretrizes para programas
educacionais e GARCIA (2001) propõe adaptações de diretrizes para se adequarem
ao público infantil.
Ainda para o desenvolvimento das heurísticas foram também realizadas

revisões bibliográficas da área de Engenharia de Usabilidade (DRUIN, 1999; HIX,
1993; NORMAN, 1998), consultas a normas ISO/IEC (ISO/IEC 12119, 1994;
ISO/IEC 14598-1; ISO/IEC 14598-2, 2000; ISO/IEC 14598-3, 2000; ISO/IEC 14598-
4, 1999; ISO/IEC 14598-5, 1998; ISO/IEC 14598-6, 2001) que dizem respeito à
avaliação de qualidade software, além de revisões nas área de educação
(CAMPOS, 1994; DEVRIES e ZAN, 1998; SANDHOLTZ et al., 1997; VALENTE,
1993) e psicologia infantil (COUTINHO E MOREIRA, 2001).
5.2. Descrição das heurísticas
5.2.1. Pertinência em relação a uma proposta pedagógica
O software educacional infantil deve ser adequado e pertinente em relação a

um tema específico e a um contexto educacional. Em outras palavras, ele deve se
identificar com um modelo pedagógico, compatível com seus objetivos educacionais.
Cada instituição de ensino possui características próprias, expressas em sua
proposta pedagógica: visões de formação de ser humano, de sociedade, de
educação e de escola. Essas visões tomarão forma por meio de condutas
pedagógicas pensadas, ou seja, na definição de objetivos, conteúdos valorizados,
metodologias e tipos de avaliação (MISUKAMI, 1996). Tendo como referência esses
componentes pedagógicos, a identificação do modelo pedagógico que o software
privilegia tem como objetivo auxiliar os responsáveis da instituição nas decisões de
adotar ou não o produto. Sem isso, embora o software possa corresponder à
aprendizagem de um dado conceito, sua utilização pode entrar em conflito com a
proposta pedagógica à qual a instituição se propõe.
5.2.2. Utilização de recursos computacionais
O software educacional infantil deve aproveitar as qualidades únicas do

computador como meio. A simples transferência de conteúdos escolares (muitas
vezes já ultrapassados ou ineficientes) para um programa não traz ganhos para o
processo de aprendizagem. O software educacional infantil deve utilizar os recursos
129
da tecnologia para desenvolver ambientes em que novas estratégias de ensino
possam ser usadas. Alguns recursos permitidos pela tecnologia que podem ser
explorados em um software educacional infantil estão listados a seguir:
§ Possibilidade de apresentar informações de forma interativa;
§ Possibilidade de maior interação multicultural (troca de experiências);
§ Possibilidade de agir com diversos níveis de inteligência adquirida;
§ Possibilidade de viabilizar diferentes níveis de interação entre crianças e entre

crianças e docentes;
§ Possibilidade de utilizar maiores recursos motivacionais;
§ Possibilidade de realizar conexões com outros meios de aprendizagem.
O importante é a diferença que o uso desses recursos traz para a área de

educação, complementando as estratégias de ensino.
5.2.3. Avaliação da aprendizagem
O software educacional infantil deve possibilitar o registro e a consulta às

ações desenvolvidas pelas crianças. Assim permitirá que o(a) docente ou os pais
verifiquem se e quais os conceitos estão sendo aprendidos pelas crianças e que
descubram os processos de aquisição desses conhecimentos. Tendo como
referência esses dados, poderão ajudar as crianças em seus erros e dificuldades
durante o processo de aprendizagem.
5.2.4. Interação
O software educacional infantil deve proporcionar uma boa condução da

criança durante a interação com suas interfaces: facilitando o aprendizado e a
utilização do programa, e diminuindo o número de erros.
a) O software educacional infantil deve disponibilizar meios (mensagens, alarmes)

para aconselhar, orientar, informar e conduzir a criança na sua interação com o
programa:
§ A criança deve saber a qualquer momento se localizar numa seqüência de

interações ou na execução de uma tarefa;
§ A criança deve conhecer as ações permitidas, bem com suas conseqüências;
130
§ A criança deve poder obter informações suplementares (eventualmente a seu
pedido).
Esses aspectos garantem ao software educacional infantil boa interação com

melhores resultados concernentes à rapidez e à eficácia na aquisição do
conhecimento proposto. São consideradas como Interação as heurísticas:
Reconhecimento no lugar de memorização, Qualidade das opções de ajuda,
Legibilidade, Feedback e Agrupamento e distinção de itens.
5.2.4.1. Reconhecimento no lugar de memorização
O software educacional infantil deve servir de guia à criança, poupando-lhe,

por exemplo, a memorização de comandos (NORMAN, 1998). O software deve
facilitar a navegação por meio de interfaces transparentes, que facilitem seu uso e
não interfiram no processo de aprendizagem. A criança não deve necessitar de
esforços extras para recordar como se utiliza o software, e sim em aprender o seu
conteúdo. É importante ressaltar que a memorização do conteúdo educacional pode
e, muitas vezes, deve fazer parte software, somente a memorização necessária para
sua utilização deve ser evitada.
a) Objetos, ações e opções devem estar visíveis. A criança não deve ter que se
lembrar de informações de uma parte anterior do diálogo para seguir adiante nas
tarefas.
5.2.4.2. Qualidade das opções de ajuda
O software educacional infantil deve disponibilizar explicações sobre suas

funções ou utilização por meio de sistemas de ajuda (lista de operações possíveis,
explicações e efeitos de comandos). Esses recursos visam a contribuir para a
superação das dificuldades que as crianças enfrentam na interação com o sistema
ou permitir que encontrem as instruções de utilização desejadas. Os comandos de
ajuda devem estar visíveis ou facilmente utilizáveis sempre que apropriado,
orientando as crianças na busca de informações específicas ou na resolução de
problemas.
131
5.2.4.3. Legibilidade
O software educacional infantil deve apresentar informações claras e

objetivas. As características lexicais das informações apresentadas devem facilitar a
sua leitura (tamanho de fonte, comprimento de linha, entre outras). Uma boa
legibilidade contribui para a compreensão e a assimilação de conteúdos
educacionais.
a) O software educacional infantil deve usar uma linguagem apropriada e familiar às

crianças, com palavras, expressões e conceitos familiares a ela, no lugar de
termos orientados para o software. Assim, a criança conseguirá expressar seus
desejos e interpretar respostas fornecidas pelo software, facilitando a
compreensão e a assimilação dos conteúdos pelas suas estruturas cognitivas.
Nota-se que essa recomendação não é facilmente seguida, pois a informatização
já traz embutida uma diferenciação na realização da tarefa, dos vocabulários.
5.2.4.4. Feedback
O software educacional infantil deve sempre fornecer respostas à ação da

criança, mantendo sua confiança durante a interação.
a) O software educacional infantil deve fornecer feedback de forma rápida, no

momento apropriado e de forma consistente com cada tipo de ação. Essa ação
pode ir do simples pressionar de uma tecla até uma seleção de comando. A
ausência de feedback ou sua demora pode ser incômoda para a criança. A
criança pode, por exemplo, suspeitar de falha no sistema e realizar ações
prejudiciais ao processo em andamento.
b) O software deve emitir feedback diante de interações inadequadas, informando a

criança quando essa comete erro ou encontra dificuldade específica, conduzindo-
a a uma solução. O feedback deve ser positivo e capaz de reforçar as respostas
corretas das crianças.
c) Feedback sonoro pode ser usado, mas sempre com cautela e com a opção de
ser omitido, pois pode provocar irritação nas crianças. Por exemplo, se cada vez
que a criança erra um exercício o software emitir o som de buzina, esse som
poderá provocar nela carga emocional negativa e dificultar a situação de
ensino/aprendizagem. Som ou voz constituem uma forma promissora de
132
interação já que são mecanismos naturais de comunicação para o ser humano.
No caso do usuário infantil, inclusive, pode ser bom recurso motivacional. No
entanto, em interface de computador, esse tipo de solução precisa ser muito
bem-projetada e implementada, justamente pelo risco de não se conseguir
solução que soe natural para o usuário humano.
5.2.4.5. Agrupamento e distinção de itens
O software deve apresentar os objetos da interface (imagens, textos,

comandos) de forma organizada (por ordem alfabética, freqüência de uso, nível de
dificuldade, formato, cor). Essa ordenação deve formar relações entre os elementos
mostrados, indicando se pertencem ou não a uma determinada classe, ou se há
diferenças entre as classes.
5.2.5. Adaptabilidade
Um software educacional infantil não consegue abranger a todo momento

todo o seu público-alvo, mas deve ser capaz de adaptar-se às necessidades e
preferências de diferentes perfis de criança. As heurísticas de Flexibilidade, Nível de
experiência com o software ou com computadores e Ambiente cooperativo
relacionam-se com a Adaptabilidade.
5.2.5.1. Flexibilidade
O software educacional infantil deve ter a capacidade de agir conforme o

contexto, as necessidades ou as preferências da criança.
a) O software educacional infantil deve possuir recursos que permitam ajustar o

nível de complexidade na apresentação da informação. A aprendizagem varia de
criança para criança, uns levam menos tempo, outros necessitam mais. O
software educacional infantil deve ser capaz de prever e acomodar as diferenças
individuais de seus potenciais utilizadores, respeitando que evoluam na aquisição
de conhecimentos conforme seu ritmo.
b) O software educacional infantil deve adaptar-se às experiências e hábitos das

crianças. Devem-se prover diferentes maneiras de se realizar uma tarefa, criando
maiores condições para que a criança consiga dominá-la. Devem-se fornecer
procedimentos, seqüências ou caminhos diferentes para que as crianças
133
possam, por várias maneiras, alcançar um mesmo objetivo. Por exemplo, um
software que permita o uso tanto do mouse quanto do teclado, oferece à criança
a escolha de sua preferência. É preciso cautela, no entanto, para garantir que a
criança não se confunda e consiga, se necessário, identificar que as várias
alternativas são apenas maneiras diferentes de se realizar uma mesma tarefa, do
modo que lhe for mais confortável.
5.2.5.2. Nível de experiência com o software ou com computadores
O software educacional infantil deve ser concebido para lidar com as

variações de nível de experiência das crianças no seu uso. Crianças experientes
com o uso de computadores não têm as mesmas necessidades, do ponto de vista
de soluções de interação, que as iniciantes.
a) Diálogos de iniciativa do software podem entediar os mais experientes.
b) Animações ou sonorizações que são encorajantes e agradáveis para iniciantes

podem se tornar aborrecimento para crianças já experientes.
c) Atalhos podem aumentar a eficiência da interação do usuário esperto de tal

forma que o software possa servir tanto a crianças inexperientes quanto a
experientes.
5.2.5.3. Ambiente cooperativo
O software educacional infantil deve suportar o trabalho cooperativo entre

crianças e/ou entre crianças e docentes. Ambientes cooperativos levam as crianças
a construir significados, compartilhando soluções de conflitos, criando e obedecendo
regras, definindo possibilidades, entre outros (DEVRIES E ZAN, 1998).
a) O software educacional infantil deve, sempre que possível, possibilitar a

interação de mais de uma criança na tarefa;
b) O software educacional infantil deve pedir em vez de ordenar, sugerir em vez de

exigir, persuadir em vez de controlar. Assim, as crianças agem de forma mais
natural, sem pressões;
c) O software educacional infantil deve possibilitar que o(a) docente possa expandir
o conteúdo do programa em seu trabalho;
134
5.2.6. Controle e autonomia do usuário
O software educacional infantil deve possibilitar que a criança tenha controle

sobre o processamento de ações solicitadas e autonomia sobre a utilização dessas
ações.
a) O software educacional infantil deve processar somente aquelas ações

solicitadas e somente quando solicitadas pelas crianças. Ações não-solicitadas
podem interferir no processo de raciocínio da criança: a correção não-solicitada
de um erro em um exercício poderá interromper o processo de reflexão sobre a
resposta, impossibilitando a alteração da mesma, se for o caso.
b) A criança deve sempre ter o controle sobre o software educacional infantil, em

relação a cancelamentos, interrupções, a vanços, retrocessos, entre outros.
Acesso, Saída, Pausa e Desfazer uma ação são heurísticas relacionadas.
5.2.6.1. Acesso
O software educacional infantil deve possibilitar que a criança tenha acesso a

todas as informações a todo momento, salvo quando o acesso seja contra uma
necessidade do conteúdo educacional, como, por exemplo, quando uma atividade
depender da conclusão de outra anterior.
a) O software educacional infantil deve possibilitar que a criança faça chamada de

uma operação a partir de outra e consiga retornar à primeira. Exemplo de
violação dessa heurística: no Bingo do software Casa Mal Assombrada, existem
três possibilidades de jogo (três cartelas). Mas a criança não tem acesso às
segunda e terceira telas diretamente, o acesso é liberado somente se a criança
tiver completado as telas anteriores. Tal restrição é desnecessária do ponto de
vista do conteúdo educacional.
5.2.6.2. Saída
O software educacional infantil deve permitir que a criança o abandone a

qualquer momento ou que altere para outro item do menu. Dependendo da
importância da tarefa, o software deve sinalizar as conseqüências dessa atividade.
Exemplo de violação dessa heurística: No jogo Dominó (Figura 24), o botão “sair”
só aparece quando a criança termina o jogo.
135
FIGURA 24 − Botão para a saída não aparece durante o jogo.
5.2.6.3. Pausa
Se a tarefa for longa, o software educacional infantil deve permitir à criança

que pare a atividade e continue depois. Retardar uma ação se distingue de saída
porque a ação de interromper e retornar ao mesmo ponto depende da memorização
do estado da tarefa não-terminada, o que não é necessário na ação de saída.
5.2.6.4. Desfazer uma ação
O software educacional infantil deve possibilitar que a criança desfaça ações

realizadas. Essa função é muito importante pois:
§ As crianças freqüentemente escolhem funções por engano o cometem algum

erro e irão precisar de uma “saída de emergência” claramente marcada, para
deixar o estado indesejado sem ter que passar por diálogos adicionais;
§ Dá segurança para que a criança possa explorar o software e expandir seu

conhecimento.
5.2.7. Recursos motivacionais
O software educacional infantil deve utilizar recursos motivacionais para

estimular as crianças e proporcionar o aumento da vida útil do programa (ao fazer
com que ela deseje usá-lo por mais tempo). Os recursos motivacionais (figuras,
sons, animações) têm grande importância em software do tipo educacional infantil,
136
visto que fazem com que as crianças se envolvam mais durante a utilização do
programa. As seguintes diretrizes são pertinentes:
a) Os recursos motivacionais utilizados pelo software educacional infantil devem

auxiliar no processo de aquisição de conhecimento, provocando o interesse pelo
assunto ao mesmo tempo em que facilitam a situação de ensino/aprendizagem.
Os recursos devem estimular as crianças, não apenas despertando sua atenção,
mas mantendo-a ao longo da interação.
b) As interfaces do software educacional devem ter alta qualidade gráfica e estética,

pois crianças são exigentes com esse item, podendo esse ser fator de
aceitabilidade e motivação para elas.
c) Uso de animações e ambientes lúdicos trazem humor, descontração e quebram

a monotonia para as crianças. Devem ser usados, mas tendo-se o cuidado para
que não dispersem a criança, atrapalhando-a a refletir sobre os tópicos
envolvidos. Crianças, ao realizarem uma tarefa com sucesso, normalmente
fazem expressões de contentamento ao verem animações de parabenização
pelo feito (mensagens de acerto também causam efeito semelhante).
d) Recursos sonoros podem ser usados, mas sempre com cautela. O gosto de
crianças em relação a sons varia muito e pode depender do nível de experiência
da criança com o software (o uso repetitivo de sons pode irritar crianças
experientes). Portanto, a sonorização de um software educacional infantil sempre
deve ser opcional, como observa a heurística 5.2.5.1 (Feedback), item c.
e) O uso de fases em jogos, além de proporcionar uma forma de aumentar a

complexidade do exercício, desperta motivação nas crianças. Em entrevista
realizada durante este trabalho, um menino disse: “todo jogo bom mesmo tem
fases. E cada fase tem um macete. É bom descobrir macetes!”.
f) O software educacional infantil deve desafiar as criança com atividades

exploratórias, que despertem a curiosidade. Crianças gostam de desafios.
Sentem-se motivadas em continuar a tarefa até alcançarem o objetivo. Após
algumas tentativas frustradas em um jogo, uma frase comum nas crianças é:
“Vou tentar até conseguir”. Mas novamente, cuidado para que a criança não
137
perca o objetivo do software, que é o aprendizado, se entretendo muito com o
programa.
g) A temporização para a realização de tarefas, apesar de aumentar o grau de

desafio para a criança, deve ser empregado com muita cautela, pois pode deixar
as crianças tensas, irritadiças e prejudicar o raciocínio.
5.2.8. Gestão de erros
O software educacional infantil deve tratar os erros que ocorrerem de forma

diferenciada, dependendo da sua classificação: erros de utilização ou erros
conceituais.
Erros de utilização do software (entrada de dados incorreta, comandos

acionados incorretamente, entre outros) correspondem a uma má interpretação dos
comandos ou do significado dos procedimentos. Segundo GAMEZ, (1998) as
interrupções provocadas pelos erros de utilização podem ter conseqüências
negativas sobre a atividade da criança, atrasando-a ou dificultando-a. Erros
conceituais são erros de caráter pedagógico, relacionados à verificação de
aprendizagem de conteúdos do programa. VALENTE (1993) afirma que a análise de
erros conceituais e a sua correção constituem grande oportunidade para a criança
entender o conceito envolvido na resolução de um problema. O erro cometido pode
tornar-se objeto de análise, e então a criança, sozinha ou com a ajuda do(a)
docente, pode reformular seus pensamentos e tentar de novo. Isso promove sua
aprendizagem.
Duas heurísticas estão relacionadas à gestão de erros: Prevenção de erros e

Auxílio no reconhecimento, no diagnóstico e na recuperação de erros. A primeira diz
respeito a erros de utilização do software e a Segunda, aos erros de utilização ou
conceituais.
5.2.8.1. Prevenção de erros
O software educacional infantil deve prevenir a ocorrência de erros de

utilização, pois melhor que boas mensagens de erro é um desenho cuidadoso que
impeça desde o começo a ocorrência do problema (CONSTANTINE, 1999). Erros de
utilização podem ser reduzidos de várias formas, entre elas:
138
a) Campos formatados para determinadas entradas de dados;
b) Flexibilidade de formas de entrada de dados ou seleção de itens;
c) Botões e campos com denominações significativas;
d) Consistência na disposição, no formato e na sintaxe de elementos da interface

do software educacional infantil.
5.2.8.2. Auxílio no reconhecimento, no diagnóstico e na

recuperação de erros
O software educacional infantil deve sempre informar à criança sobre os erros

(de utilização ou conceituais) ocorridos e permitir que ela os corrija, parcialmente ou
totalmente. Exemplo de violação dessa heurística: no jogo Quadrado Mágico, do
software Tabuada no Tabuleiro, deve-se colocar os números em um quadrado, na
posição correta. Se a criança colocar um número na posição errada, não consegue
modificá-lo até que tenha colocado todos os números, ou seja, a criança tem que
finalizar o jogo para poder mudar e tentar de novo. Tal restrição impossibilita que a
criança corrija erros no momento em que são detectados.
a) Mensagens de erro devem:
§ ser assinaladas imediatamente ou o mais rápido possível por causa da

volatilidade da memória de curto tempo (GAMEZ, 1998);
§ ser expressas em linguagem simples (sem códigos);
§ não devem responsabilizar a criança pelo erro;
§ ser informativas, dizendo exatamente o quê e por quê o erro ocorreu;
§ dependendo do caso, sugerir uma solução do erro.
b) O conteúdo de uma mensagem de erro deve estimular a criança a tentar de

novo. A ocorrência de erros conceituais pode ser positiva, levando a criança a
refletir sobre sua resposta e à sua capacidade na superação do erro.
5.2.9. Carga de trabalho
O software educacional infantil deve apresentar informações (de utilização do

software) de forma a reduzir a carga cognitiva e perceptiva da criança e aumentar a
eficiência do diálogo (GAMEZ, 1998). A carga de trabalho refere-se a toda
139
informação contida nas interfaces do software educacional infantil que pode ser
utilizada para a realização de tarefas. As heurísticas Carga informacional e
Brevidade relacionam-se à carga de trabalho.
5.2.9.1. Carga informacional
A carga informacional do software educacional infantil deve ser apresentada

de forma confortável e adequada à criança.
a) Os diálogos/textos não devem conter informação irrelevante ou de pouca

necessidade. Cada unidade extra de informação compete com as unidades
relevantes e diminui sua visibilidade relativa. Quanto menos a criança for
distraída por informação desnecessária, mais ela será capaz de desempenhar as
suas tarefas eficientemente e atingir os objetivos educacionais propostos.
b) Interfaces com muitos objetos, figuras ou textos sobrecarregam o conteúdo

informacional. Os elementos das interfaces devem ser bem-distribuídos, claros e
concisos.
5.2.9.2. Brevidade
O software educacional infantil deve limitar as cargas de ações e

informacional.
a) Por limitação de memória humana, o software educacional infantil não deve

conter numerosas e complexas ações necessárias para se chegar a uma meta,
pois a carga de trabalho aumentará e, com ela, a probabilidade da ocorrência de
erros.
b) O software educacional infantil não deve conter grandes diálogos/textos, que

podem prejudicar a compreensibilidade da informação. A capacidade de memória
de curto tempo é limitada (GAMEZ, 1998), conseqüentemente, textos mais
sucintos apresentam tendência a, além de menor tempo de leitura, maior
facilidade para serem entendidos.
5.2.10. Conteúdo
O software educacional infantil deve apresentar seu conteúdo, ou seja, toda a

informação contida no software que se intenciona transmitir às crianças, de forma
140
objetiva e adequada a uma proposta pedagógica (heurística 5.2.1: Pertinência em
relação a uma proposta pedagógica).
a) O conteúdo do software educacional infantil deve abranger atividades que

permitam estabelecer relações (compreensão), atingindo memorização
compreensiva para, finalmente, aplicar o conhecimento adquirido (ação
transformativa):
§ O conteúdo do software educacional infantil deve ser significativo para a criança.

Ela deve compreendê-lo para poder estabelecer relações e desenvolver um
processo de raciocínio construído.
§ O conteúdo do software educacional infantil deve ser rico em dimensões

exploratórias (lógico, afetivo e social), possibilitando que o(a) docente possa
explorá-las durante a interação das crianças com o programa.
§ O conteúdo do software educacional infantil deve se relacionar com as vivências

das crianças, especialmente com a realidade brasileira, possibilitando que a
criança construa vínculos significativos e que desperte sua necessidade de
conhecer e aprender, de dar sentido.
b) Conforme a heurística de Flexibilidade (1.5.1), o conteúdo deve permitir que a

criança possa avançar no conhecimento, possibilitando diferentes níveis de
aprendizado;
c) Caso o conteúdo do software educacional infantil seja tema de alguma disciplina

iniciada em sala de aula, as explicações sobre ele devem ser feitas com
parcimônia. Por outro lado, as explicações nessas circunstâncias podem ser
necessárias para esclarecimentos relacionados com algum erro cometido pela
criança. Portanto, as explicações sobre um tema dependem da situação.
d) O conteúdo do software pode abranger novas palavras (novos conceitos) para

que o vocabulário da criança possa ser ampliado ou para estimulá-la a novos
conhecimentos. Entretanto, as novas palavras não devem ser simplesmente
introduzidas às crianças por meio do software sem que haja alguma explicação
adequada, caso contrário será necessário que o(a) docente faça um trabalho
prévio em sala sobre as palavras ou conceitos introduzidos;
141
5.2.11. Significado de códigos e denominações
O software educacional infantil deve conter códigos e denominações

significativos, facilitando a memorização e o reconhecimento da criança.
a) Os objetos e informações devem ser adequados à sua referência. Termos pouco

expressivos para a criança podem ocasionar problemas de condução, levá-la à
seleção de uma opção errada ou confundi-la. Exemplo de violação dessa
heurística: no software Casa Mal Assombrada , as crianças têm problema com os
botões “chega” e “outro”. No programa, o botão “chega” é para sair do software e
o botão “outro” é para mudar de jogo. Crianças não entendem a diferença na
função dos botões, acham que servem para a mesma tarefa.
b) Abreviações e siglas devem ser evitadas. Mas caso sejam utilizadas, devem ser
explicadas e identificadas por meio de um glossário de siglas e abreviações.
5.2.12. Consistência e padrões
O software educacional infantil deve manter a uniformidade na apresentação

dos seus elementos, conceitos e informações. A consistência e os padrões
simplificam a utilização do software por facilitar a identificação de aspectos
semelhantes, por exemplo, ao ajudarem a evitar que a criança tenha dúvidas se
palavras, situações ou ações diferentes no software significam ou não a mesma
coisa. Vários outros benefícios poderiam também ser associados à utilização de
padrões, como a diminuição de erros de utilização, a satisfação do usuário, entre
outros.
a) Os elementos da interface do software educacional infantil (procedimentos,

comandos, botões) são melhor reconhecidos, localizados e utilizados quando o
seu formato, posição ou sintaxe são estáveis de um estado para outro, de uma
seção para outra. Assim, o software fica mais previsível e os erros são reduzidos.
Portanto, é necessário escolher opções similares de códigos, procedimentos e
denominações para contextos semelhantes e utilizar os mesmos meios para se
obter os mesmos resultados. Exemplo de violação dessa heurística: a falta de
homogeneidade nos menus de um programa pode aumentar o tempo de procura,
dificultando a intuitividade do software.
142
b) A existência de padrões envolvendo diferentes produtos de software educacional
infantil de uma mesma família de produtos relacionados também é importante e
deve ser utilizada.
5.2.13. Correspondência entre o software e o mundo real
O software educacional infantil deve procurar manter correspondência com o

mundo real em relação à escolha e ao uso de padrões, convenções ou associações
familiares à criança. A utilização dessas convenções faz a informação aparecer de
maneira lógica e natural para a criança, facilitando a compreensão e a utilização do
programa. A associação com outros programas similares está relacionada com esta
heurística.
a) O software educacional infantil deve falar a linguagem da criança, com palavras,

expressões e conceitos familiares, no lugar de termos orientados para o
programa;
b) O software educacional infantil deve, sempre que possível, simular ambientes

familiares às crianças ou utilizar metáforas conhecidas por elas;
5.2.13.1. Correspondência com outros programas similares
O software educacional infantil deve seguir convenções oriundas de outros

programas infantis populares, como jogos infantis existentes no mercado. Como em
todas as áreas de atividades humanas, existe uma cultura e convenções, muitas
vezes não-documentadas, que são criadas ao longo do tempo e acabam se
tornando naturais para as pessoas. Isso ocorre porque as crianças, acostumadas
com algumas características de outros programas, principalmente os jogos, tendem
a realizar associações com padrões já usados nesses programas. Exemplo de
violação dessa heurística: no jogo “c ç ss” do software Casa Mal Assombrada, as
figuras de morcegos que aparecem na tela (Figura 25) indicam o número de textos
presente no jogo. O fato de os jogos existentes no mercado usarem o mesmo
padrão para a representação de “vidas” (possibilidades de erro) leva as crianças a
interpretarem os morcegos dessa mesma forma.
143
FIGURA 25 − As figuras de morcegos que aparecem em cima da tela do
jogo representam o número de textos do jogo. Mas em todos os testes
realizados, crianças disseram ser “vidas” do jogo, ou seja, número de vezes
em que se poderia errar. Isso devido à associação com outros programas
existentes, em que “vidas” são representadas da mesma forma.
5.2.14. Documentação
O software educacional infantil pode fornecer documentação direcionada

tanto para pais/docentes quanto para crianças. No caso de adultos, a documentação
refere-se à descrição do software (identificação, recursos necessários, objetivos,
entre outros) e ao uso (instalação e instrução), enquanto para as crianças, a
documentação refere-se somente ao uso do programa (instrução). Relacionadas à
documentação, muitas diretrizes existentes na literatura (GAMEZ, 1998; ISO/IEC
12119,1994; NIELSEN, 1993) para software em geral são aplicáveis, sem
necessitarem de alterações.
Para todos os tipos de documentação, deve-se lembrar que devem estar

acessíveis a todo momento para o usuário, mas, se não forem solicitadas, podem
ser irritantes.
144
5.2.14.1. Documentação de descrição do produto (para
docentes/pais)
Um software educacional infantil deve informar dados sobre o produto,

descrevendo suas propriedades. Essa documentação deve ajudar um comprador em
potencial na avaliação da adequação do produto à sua necessidade/realidade
(ISO/IEC 12119, 1994).
a) A descrição do produto deve incluir: identificação (nome, versão, data),

fornecedor (nome, endereço), objetivos pedagógicos, público-alvo, pré-requisitos
técnicos necessários (unidade de processamento, memória, ambiente de rede,
entre outros) e outros tópicos que se julgar necessários (suporte e manutenção,
direitos autorais, entre outros).
b) A descrição do produto deve estar sempre disponível, ser compreensível,

completa, estar livre de inconsistências internas (todo termo deve ter o mesmo
significado em todo lugar, conforme heurística 5.2.12: Consistência e padrões).
5.2.14.2. Documentação de uso do software
O software educacional infantil pode disponibilizar informações sobre o uso do

programa destinadas tanto para os pais e docentes (aspectos pedagógicos,
instalação e regras), quanto para crianças (em geral, regras). As diretrizes a seguir
se aplicam aos dois tipos:
a) A documentação deve orientar o usuário para que ele compreenda o software e

tenha as informações necessárias para interagir com o programa. A
documentação deve ser bem-organizada e suscitar o convite à leitura. Ela deve
guiar o usuário, facilitar a navegação no aplicativo e diminuir a ocorrência de
erros.
b) A documentação deve ser de fácil leitura, contribuindo para a sua compreensão e

orientando adequadamente na busca de informações ou na resolução de
problemas. A documentação não deve necessitar de ajuda para ser utilizada.
145
c) Deve-se ter cuidado com a densidade de informação na documentação, pois,
caso ela seja muito alta, poderá dificultar o entendimento e induzir a erros por
parte do usuário na interação com o sistema.
d) A apresentação da documentação deve manter a consistência e a

homogeneidade em todas as suas ocorrências (heurística 5.2.12: Consistência e
padrões).
e) A documentação deve ser de fácil pesquisa, focada nas tarefas a serem

realizadas e listando passos concretos a serem seguidos.
f) Todas as informações contidas em documentações de uso do software devem

ser corretas, livres de ambigüidades, contradições ou erros e compreensíveis
pelo seu público-alvo (docentes/pais) (ISO/IEC 12119, 1994).
5.2.14.3. Documentação de uso do software direcionada a

docentes/pais (instalação, regras e aspectos pedagógicos)
O software educacional infantil deve apresentar documentação de uso

direcionada somente a pais ou docentes que contenha manual de instalação
contendo todas as informações necessárias para que se consiga instalar o software
com sucesso.
a) Na documentação de uso para docentes/pais, podem-se fornecer dados sobre a

utilização do software em que todas as funções possíveis do produto (realizadas
por crianças ou somente por docentes/pais) devem ser completamente descritas.
b) Na documentação de uso para docentes/pais, pode-se também disponibilizar

informações sobre aspectos pedagógicos do programa, como a melhor forma ou
o melhor contexto em que o software pode ser utilizado.
5.2.14.4. Documentação de uso do software direcionada a crianças

(regras)
O software educacional infantil pode utilizar documentação de uso (regras de

utilização) direcionadas para crianças, pois elas são interessantes para que a
criança possa aprender sozinha como usar o software, estimulando-a na descoberta
146
e na exploração do programa. A documentação de uso para crianças pode não
abranger todas as funções do software, visto que algumas podem ser restritas a pais
ou docentes.
a) Documentação de uso direcionada às crianças não deve ser longa (pois crianças
se dispersam), deve ter linguagem adequada ao aprendiz (para que a
compreensão seja garantida) e deve ser opcional, pois só são interessantes para
iniciantes.
b) Nota-se que documentações em que animações sonorizadas (em vez de textos a

serem lidos) são usadas despertam interesse maior das crianças.
c) Regras escritas podem ser usadas, desde que sejam de fácil localização, legíveis
e compreensíveis.
d) Evidentemente, é preciso considerar a idade do usuário mirim na elaboração da

documentação.
Os programas educacionais infantis existentes no mercado atualmente

oferecem uma variedade de opções, mas com baixa qualidade (DRUIN, 1999). Essa
realidade leva a duas necessidades: desenvolvimento de processos que visem à
qualidade durante a produção dos programas e métodos de avaliação de qualidade
dos programas existentes. Heurísticas são diretrizes que colaboram nessas duas
situações por meio de recomendações para o desenvolvimento ou a avaliação de
programas.
Das heurísticas revisadas na bibliografia (CONSTANTINE, 1999; GARCIA,

2001; GAMEZ, 1998; NIELSEN, 1993), muitas puderam ser aplicadas ao infantil
(heurísticas 5.2.1, 5.2.3, 5.2.9, 5.2.11 e 5.2.12), entretanto, muitas também
precisaram ser adaptadas ou incrementadas para o público mirim (heurísticas 5.2.4,
5.2.5, 5.2.6. 5.2.8, 5.2.10, 5.2.13 e 5.2.14) devido ao seu comportamento
diferenciado. Algumas heurísticas, principalmente as que se referem aos aspectos
pedagógicos do software educacional infantil, ainda precisaram ser desenvolvidas
147
(por exemplo, as heurísticas 5.2.2, 5.2.7), pois nenhuma referência sobre o assunto
havia sido encontrada.
As heurísticas apresentadas foram desenvolvidas para dar suporte à

MAQSEI, mas podem ser aplicadas a qualquer processo de avaliação ou
desenvolvimento de software educacional infantil da mesma forma, fornecendo mais
credibilidade ao processo.
Embora uma equipe de avaliação ou desenvolvimento de software

educacional infantil devesse ser formada por profissionais das áreas técnica e
pedagógica, nem sempre isso é possível. As heurísticas aqui mostradas colaboram
nessa situação ao servirem como referência nas duas áreas para os
avaliadores/desenvolvedores. Profissionais de formação técnica poderão se
beneficiar das heurísticas ao utilizarem não só diretrizes técnicas, mas
principalmente pedagógicas, para se informar e avaliar ou desenvolver mais
completamente um produto educacional infantil. Da mesma forma, profissionais da
área de educação poderão utilizar as heurísticas como base para avaliar programas
educacionais infantis não só pedagogicamente, mas também em relação aos seus
aspectos técnicos, especificamente de Usabilidade. Deve -se aqui deixar claro que o
uso das heurísticas não descarta a necessidade da participação de profissionais de
ambas as áreas durante a avaliação ou a produção de um software educacional
infantil. Deseja-se somente que sejam usadas como apoio a desenvolvedores ou
avaliadores de software educacional infantil, colaborando para que os programas
sejam de qualidade e que atinjam os seus objetivos pedagógicos.
148
6. REALIZANDO A AVALIAÇÃO DE SOFTWARE EDUCACIONA INFANTIL – O
papel do avaliador
6.1. Introdução
A realização de uma avaliação de software educacional infantil é uma

atividade difícil, envolvendo várias habilidades e tarefas. A maioria das tarefas é de
responsabilidade do avaliador do software, mas outros papéis também são
envolvidos durante o processo. As funções de cada um dos papéis foram formuladas
de forma a maximizar a coleta e o registro de informações para a avaliação. Os
seguintes papéis e respectivas funções são possíveis durante a avaliação de um
software educacional infantil:
§ Avaliador(es): é o mais importante dos papéis, responsável pela preparação,

condução, análise e produção dos resultados da avaliação, podendo ser
representado ou por um profissional ou por uma equipe das áreas técnica e
pedagógica. Durante a etapa de condução dos testes com crianças, o avaliador
pode ser também chamado de condutor. O termo condutor diferencia o avaliador
que conduzirá os testes (da recepção à liberação das crianças) dos demais
avaliadores (no caso de equipes).
§ Operador(es) do equipamento: é a pessoa encarregada da preparação e do

manuseio dos equipamentos, mixagem, ajuste das câmeras, teste de ângulos,
filmagem dos testes e reprodução e edição das fitas gravadas.
§ Observador(es): na verdade, não representa nenhum papel, pois não tem tarefas
definidas durante o teste. São somente pessoas da equipe de avaliação,
docentes, pais ou qualquer um que se relacione com a avaliação e que deseje
assistir aos testes.
Devido à importância do avaliador, maiores detalhes a seu respeito serão

descritos a seguir.
6.2. O avaliador
O papel do avaliador é o de maior responsabilidade e importância durante a

avaliação de um software educacional infantil. Ele(a) irá realizar todas as fases da
149
avaliação, envolvendo tarefas que devem ser realizadas com cautela. A boa
condução de uma avaliação terá influência direta na obtenção de bons resultados.
Para a avaliação de um software educacional infantil, sugere-se que uma

equipe de avaliadores seja formada, com especialistas em Usabilidade, educação e,
se possível, em psicologia. A participação destes enriquece o processo, fornecendo
embasamento teórico de todas as áreas envolvidas. Cada um desses profissionais
participará de todas as fases da avaliação, mas atuando mais em algumas e menos
em outras. Por exemplo, durante a condução dos testes, sugere-se que estejam
presentes no máximo dois avaliadores, para não inibir a criança (os outros podem
ser observadores). Entretanto, durante a produção do Relatório final, será de grande
valor a participação de todos, analisando os dados sobre várias perspectivas.
Várias recomendações sobre a conduta de um avaliador durante os testes,

seu perfil e possibilidades de melhoria foram desenvolvidas neste trabalho. Elas
basearam-se em revisões bibliográficas (GARCIA, 2001; HANNA et al., 1997;
RUBIN, 1994), mas principalmente em resultados observados em testes para
avaliação de programas educacionais infantis realizados durante a pesquisa.
Descrevem-se, a seguir, essas recomendações.
6.2.1. Recomendações para a conduta durante os testes
A realização da avaliação de um software educacional infantil envolve testes

em que observam-se crianças realizando tarefas no programa. O acompanhamento
e o registro da realização dessas tarefas é de responsabilidade do avaliador, neste
caso também chamado de condutor do teste. Durante este trabalho, foram
registradas várias recomendações para a condução de testes, como se segue.
§ Sentar-se próximo às crianças, observando-as de perto, para que consiga ver

suas reações, comentários e desenvoltura durante o teste.
§ Prestar muita atenção aos sinais que as crianças dão, como risadas, expressões
faciais e olhares. Esses comportamentos são mais confiáveis do que respostas a
perguntas sobre o software. Crianças, principalmente as mais novas, querem
agradar adultos e podem então dizer ao avaliador que gostaram do programa
somente para satisfazê-lo.
150
§ Ser neutro e imparcial. Não deve transmitir suas opiniões ou fazer comentários
sobre o software. Não deve fazer gestos ou palavras que influenciem as
crianças. Não deve fazer expressões de insatisfação quando algo de errado
ocorrer, pois a última impressão normalmente é a mais marcante. Mesmo que o
condutor esteja o tempo todo com feição agradável, se em algum momento
mudá-la, essa impressão ficará registrada para as crianças.
§ Usar do humor para deixar a sessão mais relaxada.
§ Usar roupas informais para parecer amigo das crianças, e não uma autoridade.
§ Tratar todas as crianças de forma igual, independentemente de sexo, instrução

ou facilidade de aprendizado. Nenhuma criança pode sentir-se de alguma forma
discriminada, para que não altere seu comportamento durante o teste.
§ Ter cuidado com o tom de voz e a linguagem corporal. O condutor não pode
parecer uma autoridade, deve parecer uma pessoa familiar à criança.
§ Reagir aos erros cometidos pelas crianças com naturalidade e da mesma forma
que nos acertos.
§ Deixar que as crianças cometam erros, não interrompendo-as caso errem

alguma tarefa. Errar e tentar novamente faz parte da construção do
conhecimento.
§ Estimular as crianças quando algum erro ocorrer, dizendo, por exemplo: “Vamos
tentar novamente?”, e nunca dizendo: “Está errado!”, pois esse comentário gera
insegurança.
§ Tentar descobrir a causa de erros no momento em que ocorrem, questionando a

criança. O condutor não deve deixar para perguntar sobre erros após o teste
porque as crianças podem esquecer do evento.
§ Entender a causa de a criança ter gostado ou não de determinada parte do

software.
151
§ Estimular perguntas e não inibi-las. Se a criança pergunta muito é porque confia
no condutor.
§ Conduzir em vez de “salvar”. Não deve “salvar” dando a resposta para a criança
quando ela fizer uma pergunta, mas também não deve deixá-la sem nenhum
retorno. O condutor deve tentar conduzi-la para a descoberta da resposta, como
no exemplo a seguir:
Criança: “Como eu faço para mudar de jogo?”

Condutor: “Como você acha que é?”
Criança: “Não sei”
Condutor: “Procure na tela, você vê algo que pode ser usado para mudar de
jogo?”
§ Convidar a criança a realizar tarefas em vez de perguntá-la se deseja fazê-las,

pois, no último caso, possibilita-se que a resposta seja negativa. O condutor deve
usar, por exemplo, a frase “Vamos agora entrar no jogo...” .
§ Tentar recuperar a atenção da criança caso ela comece a se dispersar durante o

teste, olhando para o laboratório ou para os equipamentos. O condutor pode
fazer alguns comentários, como: “Está quase acabando, só mais uns
minutinhos”, “Vamos tentar esse jogo agora, vamos ver se é legal!”. Outra forma
de o condutor encorajar as crianças em uma atividade é fingindo que precisa de
ajuda para realizá-la: o condutor pode errar um jogo algumas vezes e passar a
vez para a criança tentar.
§ Manter as crianças motivadas por meio de comentários positivos sobre o seu

desempenho nas atividades.
§ Ter cuidado com palavras e símbolos usados, pois as crianças podem não
conhecer. Em um Pré-teste realizado durante este trabalho, o símbolo “/” foi
usado para representar divisão, mas algumas crianças não o conheciam,
perguntando ao condutor o significado do símbolo.
§ Mostrar elementos em uma interface quando quiser perguntar se a criança viu

determinada função ou figura. A visualização de objetos facilita a recordação da
criança.
152
§ Não se envolver muito com a coleta de dados. O condutor pode perder ações
das crianças se gastar muito tempo com suas anotações. Para isso são feitas as
filmagens. O condutor deve fazer registros pequenos e simples, usando de
abreviações sempre que possível.
§ Não ser muito rígido em relação ao Plano de testes. O condutor deve saber
perceber quando o teste não está atingindo seus objetivos e então modificá-lo
para não desperdiçar o tempo com as crianças.
§ Continuar motivado mesmo se cometer algum erro durante o teste, mantendo

seu comportamento. O erro deve ser usado como forma de aprendizagem para o
condutor, como experiência para aprimorar sua conduta.
§ Ter certeza de que a criança realmente terminou a tarefa antes de prosseguir.

Caso não esteja claro para o condutor, ele pode perguntar para a criança se ela
finalizou a tarefa.
§ Tratar cada nova criança como se fosse o primeiro teste. Não deve deixar que o
comportamento de outros participantes interfira ou influencie na sua conduta.
§ Dar uma pausa entre os testes para breve descanso. Como cada teste não pode
ser desperdiçado, deve-se primar pela qualidade.
6.2.2. Recomendações para o perfil do avaliador
As tarefas desempenhadas pelo avaliador de software educacional infantil

podem ser agradáveis e gratificantes, mas também entediantes e exaustivas já na
primeira vez que as assume. Para que obtenha sempre bons resultados nessas
tarefas, o avaliador deve possuir alguns conhecimentos e habilidades que
determinam seu perfil. Neste trabalho, observou-se que um bom avaliador de
software deve:
§ Conhecer bem heurísticas pedagógicas e de Usabilidade para software

educacional infantil (Capítulo 5), pois elas são diretrizes para a avaliação ou o
desenvolvimento de programas que proporcionam a obtenção de resultados mais
confiáveis e qualificados.
153
§ Conhecer e usar alguma metodologia de avaliação de software educacional
infantil, pois o uso dela facilita o planejamento e o traçado do trabalho, guia as
tarefas a serem realizadas e ajuda a melhorar a forma de sua realização.
§ Ter uma base de conhecimento em Engenharia de Usabilidade, em educação e

em psicologia infantil. Dessa forma, o avaliador poderá detectar mais facilmente
os problemas tanto técnicos quanto pedagógicos do software, poderá levantar
mais precisamente as tarefas a serem conduzidas no testes e conseguirá
produzir resultados mais satisfatórios sobre o programa.
§ Saber lidar com cada tipo de criança e deixá-la à vontade no teste. O condutor
deve ser simpático e tornar-se um amigo da criança para que, durante um teste,
ela aja naturalmente e responda corretamente às atividades solicitadas. Não se
pode “perder” a criança, o que significa a criança realizando o teste sem vontade
e fornecendo pouca informação sobre o software. Numa avaliação com seis
crianças, a perda de uma implica a perda de quase 20% dos dados.
§ Possuir boa memória. O condutor pode precisar lembrar dos eventos ocorridos
durante um teste com crianças para perguntá-las posteriormente, durante um
Pós-teste ou questionário. A memória é importante também para a comparação
de desempenho das crianças nos testes de uma avaliação. Outra razão seria a
ocorrência de algum problema na filmagem − o condutor terá, então, somente os
seus registros do formulário e sua memória como base para a análise dos dados.
§ Ser bom ouvinte. O condutor deve ignorar momentaneamente suas opiniões ou

de outros participantes e ouvir, a cada sessão, o que a criança fala ou expressa.
§ Estar confortável e acostumado com as ambigüidades que podem ocorrer nos

testes. O condutor deve saber que, ao lidar com crianças, situações inesperadas
podem ocorrer, pois cada criança, ou cada ser humano, tem um comportamento,
um ritmo.
§ Ter flexibilidade. O condutor deve saber quando precisa modificar o Plano de

testes ou mesmo interromper um teste, quando, por exemplo, notar que a criança
não tem o perfil indicado para o teste.
154
§ Possuir habilidade de ficar sempre atento. Durante os testes, podem ocorrer
períodos sem que nenhum evento significativo ocorra e o condutor então deve se
monitorar para que não se disperse.
§ Ter sempre em mente o que deseja pesquisar. Só assim fará as perguntas

corretas, registrará os eventos relevantes, obtendo dados conclusivos para a
avaliação. O condutor deve saber coletar os dados de todas as crianças sem
perder detalhes, mas também deve saber generalizar os dados coletados de
todas as sessões, focando nos achados mais importantes (o condutor não deve
focar somente nas últimas sessões observadas).
§ Ser um bom comunicador (fala e escrita). O condutor deve ser bem-entendido

pelas crianças durante as explicações e solicitações de um teste e também deve
saber expressar os resultados obtidos de forma clara, concisa e objetiva no
Relatório final de avaliação de Avaliação de um software educacional infantil.
§ Saber lidar com frustrações. O condutor, ao ver que a criança está frustrada e
não consegue realizar uma tarefa, pode pedir que ela passe para a próxima
tarefa ou então pode ajudá-la a responder. O que não pode ocorrer é a criança
perder sua motivação. O condutor deve encorajá-la a continuar, te ntando mostrar
que o problema encontra-se no programa. É nesses momentos, quando ocorrem
dúvidas ou falhas, que melhor percebem-se os defeitos do software educacional
infantil.
§ Ser organizado e bom coordenador. O condutor deve saber organizar e

coordenar todo o teste e toda a equipe.
6.2.3. Recomendações para melhorar as habilidades do

avaliador/condutor
O perfil descrito anteriormente, requerido para um bom avaliador de software

educacional infantil, não é facilmente atingido. Entretanto, alguns fatores ajudam um
avaliador a obter esse perfil e a realizar suas tarefas com mais facilidade:
155
§ Se possível, aprimorar sua formação nas áreas de educação (informática na
educação, classificação de software educacional, teorias da aprendizagem, entre
outras) e de Usabilidade (desenho, regras, princípios, entre outros);
§ Estudar e conversar com profissionais experientes em psicologia infantil;
§ Aprender observando outros avaliadores;
§ Observar-se nas filmagens. Ao assistir às gravações, o condutor pode ver seus

erros e procurar se aprimorar;
§ Praticar a avaliação de programas educacionais infantis. Nas primeiras

avaliações, o avaliador sempre comete algumas falhas, mas vai adquirindo
experiência com o tempo;
§ Praticar concentração, ter atenção a detalhes, perceber fatos.
A realização da avaliação de um software educacional infantil pode ser feita

por uma equipe treinada no planejamento, na condução e na análise dos testes.
Entretanto, como na maioria das vezes as funções são realizadas por somente um
indivíduo − o avaliador do software −, seu perfil, suas habilidades e sua conduta
tornam-se de grande importância. Em relação à sua conduta durante os testes com
crianças, em geral as mesmas regras que são usadas para a interação com adultos
se aplicam. As adaptações necessárias visam a simplificar as instruções para que
fiquem claras àqueles com vocabulário mais reduzido, propiciar mais conforto para
aqueles que têm mais dificuldade em controlar suas emoções e ritmar o teste para
acomodar diferentes tipos de atenção. Já em relação ao perfil e às habilidades do
avaliador, a busca por conhecimento teórico e a prática para obtenção de
experiência são os fatores primordiais para o aprimoramento de suas qualidades,
para a realização de um trabalho cada vez melhor.
156
7. A EXPERIÊNCIA DE AVALIAÇÃO
7.1. Introdução
A MAQSEI foi aplicada em programas educacionais infantis com o objetivo de

validar o processo. À medida que a metodologia ia sendo utilizada, modificações iam
sendo registradas e realizadas, visando ao seu aprimoramento 25. Durante essa
etapa, a MAQSEI foi utilizada em duas situações: em avaliações de software
educacional infantil de instituições de ensino e no desenvolvimento de um software
educacional infantil. As instituições visitadas, os programas selecionados, as
avaliações realizadas e as propostas de melhoria registradas para a MAQSEI serão
descritos neste capítulo.
7.2. Instituições de ensino e programas educacionais infantis avaliados
7.2.1. Rede Coleguium de Ensino
A Rede Coleguium 26 de Ensino é uma instituição particular que atende aos

níveis de ensino infantil ao ensino médio. Localizada em Belo Horizonte, essa escola
possui laboratório de informática com 17 (dezessete) microcomputadores em rede. A
escola tem convênio com a empresa Informar Educacional27, que empresta os
computadores à escola e faz sua manutenção. Além disso, a empresa disponibiliza
vários programas infantis para o colégio.
As aulas desenvolvidas no laboratório de informática não têm programação

diária, estando dependentes da programação dos conteúdos. O(a) docente
usualmente escolhe um software a ser usado, de acordo com o assunto trabalhado,
e agenda horário no laboratório de informática com as crianças. As crianças também
utilizam o laboratório de informática em seus tempos livres para pesquisas na
Internet, realização de trabalhos ou jogos.
Três aulas 28 utilizando o laboratório de informática foram observadas durante
25
Veja Capítulo 3, item 3.2.9.
26
http://www.coleguium.com.br
27
http://informareducacional.com.br
28
Aulas assistidas em abril de 2002, com alunos de 1ª e 2ª séries do ensino fundamental.
157
este trabalho, o que contribuiu para a familiarização com o ambiente e com o
contexto pedagógico, para o entendimento do comportamento das crianças e
docentes durante uma aula desenvolvida no laboratório de informática e até mesmo
para já elencar alguns pontos a serem analisados nos programas adotados na
escola.
7.2.1.1. Programas avaliados na Rede Coleguium de Ensino
Os programas disponíveis na escola foram analisados com o objetivo de

selecionar quais seriam avaliados conforme a MAQSEI. Decidiu-se selecionar
aqueles que eram mais usados pelos docentes durante as aulas. Foram eles:
1 – Software Dominó: desenvolvido pela empresa Informar Educacional. Trabalha

com números, cores e formas geométricas por meio da simulação de um jogo de
dominó. Para jogar, a criança deve escolher entre as três formas possíveis de
dominó: cores, formas geométricas ou números. Após escolher, o jogo começa e,
usando as setas do teclado e a tecla <enter>, a criança vai selecionando as peças
para serem encaixadas no dominó.
FIGURA 26 − Jogo Dominó
2 – Software Figuras Geométricas II: software da empresa Informar Educacional,

mostra um robô que a criança deve ir pintando de acordo com a legenda
apresentada. Na legenda, cada figura corresponde a uma cor, como mostra a Figura
27.
158
FIGURA 27 − Software Figuras Geométricas II
3 – Software Dominó dos Números: trabalha com contagem numérica e com as

operações da adição de subtração da matemática. O software possui três jogos: no
primeiro a criança deve completar as somas, dando o resultado (Figura 28). No
segundo, deve verificar que operação está sendo feita nas figuras e completar as
lacunas (ex.: tem-se cinco borboletas de um lado e duas do outro. A criança deve
fazer 5 – 2 = 3, como mostra a Figura 29). No terceiro, aparecem várias figuras em
colunas, a criança deve contar quantas em cada coluna e colocar o número
correspondente (Figura 30).
FIGURA 28 − Jogo do software Dominó dos Números
159
FIGURA 29 − Segundo jogo do software Dominó dos Números
FIGURA 30 − Terceiro jogo do software Dominó dos Números
7.2.1.2. Avaliação dos programas educacionais infantis utilizados

na Rede Coleguium de Ensino
Os programas selecionados foram avaliados de acordo com as técnicas da

MAQSEI. Por meio da metodologia foi possível avaliar: se os programas estavam
conseguindo obter os resultados esperados, seus objetivos e a adequação a uma
160
proposta pedagógica. Ainda foi possível identificar aspectos positivos e negativos
dos programas pela observação das crianças exercendo as tarefas solicitadas.
Primeiramente, os programas foram analisados para o reconhecimento de

usas funções e seus detalhes. A partir dessa análise, um Plano de testes foi
preparado, contendo uma listagem das questões que precisam ser avaliadas
durante os testes. A Tabela 43 lista essas questões.
TABELA 43 – Aspectos a serem avaliados
Software Perguntas
As regras são acessadas pelas crianças? Se são, as crianças as lêem?
Entendem?
Crianças clicam no botão “A”? Entendem o que ocorre?
Crianças têm dificuldade de movimentação das peças?

Dominó Crianças têm dificuldade em selecionar as peças?
As mensagens que o software transmite são compreensíveis e agradáveis?
Crianças compreendem quando erram?
Crianças têm problemas ao tentar sair do jogo?
Crianças leram as regras? Crianças entenderam as regras?
Figuras Crianças têm dificuldade em jogar?

Geométricas II Mensagens de erro e acerto são adequadas?
Crianças entendem quando erram?
Crianças conseguem navegar bem entre as telas?
Mensagens de erro/acerto são bem-elaboradas?

Crianças compreendem sempre o que é para ser feito? (principalmente no
Dominó dos segundo jogo)
Crianças conseguem modificar/apagar/voltar nos jogos?
Números
Crianças conseguem terminar os jogos?
Crianças conseguem sair dos jogos?
Crianças lêem e entendem mensagens?
Os testes 29 foram realizados no laboratório de informática da Rede Coleguium

de Ensino, em microcomputadores Intel Pentium 200 MHz, 32 MB de memória RAM,
no ambiente operacional Windows 98. Seis crianças entre seis e oito anos, com
29
Testes realizados em 10/7/2002.
161
familiaridade no uso de computadores, participaram dos testes. As crianças foram
trazidas pela professora em pares. A maioria dos testes foi filmada30.
Cada dupla de crianças foi recepcionada e informada sobre o teste. A seguir,

algumas perguntas sobre o perfil da criança (nome, idade, série, entre outros) foram
preenchidas no formulário de Entrevista com crianças.
O condutor do teste leu para as crianças o Script de orientação, em que foram

apresentados todos os envolvidos, explicados os objetivos, descritas as expectativas
e esclarecido o uso do equipamento do teste.
Foram realizados também Pré-testes com cada software, de acordo com o

conteúdo do programa. Para os programas Dominó e Figuras Geométricas II, o
condutor mostrou figuras, números e cores para as crianças e pediu a elas que as
identificassem. Para o software Dominó dos Números, as crianças deveriam fazer
algumas operações em papel.
O desenvolvimento dos testes consistiu em uma lista de tarefas que as

crianças deveriam realizar enquanto eram observadas. Enquanto executavam as
tarefas solicitadas, o condutor anotava as dificuldades, o que as crianças gostavam
ou não, comentários e reações. Seguem as listas das tarefas31 solicitadas em cada
programa (Tabelas 44, 45 e 46).
30
Alguns testes não foram filmados por falta de fita para filmagem. Como eram os primeiros testes
realizados, calculou-se mal o número de fitas necessárias para a gravação de todos os testes.
31
Essas listas de tarefas foram preparadas no Plano de testes de cada software.
162
TABELA 44 − Lista de tarefas software Dominó

Req: Software aberto
CS: Clicar em “regras”, ler, entender,
1 Entenda como jogar
saber jogar.
TMC: 2 minutos 32
Req: Tela de jogo aberta
CS: Conseguir mover/selecionar objetos
2 Jogue com as cores
sem frustrações até o fim
TMC: 5 minutos
3 Jogue com figuras
TMC: 5 minutos
4 Jogue com os números
TMC: 5 minutos
Req: Ter terminado
5 Saia CS: Conseguir sair
TMC: 10 segundos
Legenda: Req = Requisito CS = Critério de Sucesso TMC = Tempo Máximo para Completar
TABELA 45 − Lista de tarefas software Figuras Geométricas II

Req: Tela aberta
1 Leia as regras CS: Saber o que fazer na próxima tela.
TMC: 1 minuto
Req: Tela aberta
2 Faça o exercício CS: Completar tudo corretamente
TMC: 10 minutos
Req: Tela aberta
3 Saia do jogo CS: Sair do jogo corretamente
TMC: 10 segundos
32
Como esta foi a primeira avaliação realizada, durante seu planejamento medidas de tempo ainda
pretendiam ser usadas. Após esta avaliação, tomou-se então conhecimento da inadequação deste
tipo de medida em testes com crianças e elas não foram mais usadas.
163
TABELA 46 − Lista de tarefas software Dominó dos Números

Req: Tela do primeiro exercício aberto
1 Faça o exercício CS: Completar todas as somas
TMC: 5 minutos
Req: Ter acertado tudo
2 Ir para o próximo exercício CS: Chegar no próximo exercício
TMC: 5 segundos
3 Faça o exercício CS: Chegar na última tarefa
TMC: 10 minutos
Req: Ter acertado tudo
4 Ir para o próximo exercício CS: Chegar no próximo exercício
TMC: 5 segundos
Req: Tela aberta
5 Jogue o exercício CS: Chegar ao fim
TMC: 5 minutos
6 Sair
Após todas as tarefas terem sido completadas, foram realizados Pós-testes

para cada software, contendo os mesmos exercícios dos Pré-testes, mas somente
para as crianças que haviam tido dificuldades. Em seguida, as crianças foram
questionadas pelo condutor do teste sobre suas preferências e opiniões a respeito
do software. Finalizando, as crianças foram agradecidas e liberadas.
Se necessário, alguns ajustes eram feitos no teste entre a realização de cada

sessão.
Terminadas as sessões dos testes, os dados coletados foram então

transcritos, resumidos e analisados, produzindo um relatório final de avaliação para
cada software. Os problemas e conclusões descritos nas Tabelas 47, 48 e 49
foram relatados sobre cada software.
164
TABELA 47 − Problemas e conclusões sobre o software Dominó
Software Dominó
Problema detectado Heurística(s) violada(s)
Impossibilidade do uso do mouse e impossibilidade de movimentação de Adaptabilidade

setas para os dois sentidos no jogo. (Flexibilidade)
As regras referem-se somente ao manuseio do software, não explicam as

táticas referentes a um jogo de dominó. Portanto, pressupõem que as
direcionada a crianças
crianças já tenham conhecimento sobre o jogo de Dominó.
O botão para saída só aparece quando o jogo dominó é completado, Controle e autonomia do
impossibilitando a saída do jogo em qualquer outro momento. usuário (saída)
Controle e autonomia do
Impossibilidade de reverter ação de saída usuário (Desfazer uma
ação)
Mensagens de erro são somente sonoras. Se o computador não tiver

Interação (Feedback)
recursos sonoros, a criança não é informada sobre seu erro.
Mensagens de acerto são fornecidas em caixas de diálogo e as de erro

Consistência e padrões
são informadas por meio de recursos sonoros.
Os botões para legenda (“A”) e sonorização não são compreendidos e,

Interação
portanto, não são usados pelas crianças
Conclusões
O software não possibilita que a criança avance no aprendizado, por isso foi considerado como
limitado: a criança não tem interesse em reutilizar o software por muitas vezes.
Entretanto, o software pode ser usado quando o(a) docente está trabalhando com identificação
de figuras geométricas, cores e números. Pela observação, o(a) docente pode ver se a criança
tomou consciência do que fez, daí a necessidade de o(a) docente acompanhá-lo(a) e discutir
conceitos paralelamente. O auxílio do(a) docente é, portanto, indispensável para que a criança não
limite sua capacidade de curiosidade e busque sempre o conhecimento acerca de discussões sobre
determinada dúvida.
165
TABELA 48 − Problemas e conclusões do software Figuras Geométricas II
Software Figuras Geométricas II
Para alterar a cor selecionada, tem-se somente a opção de clicar na Adaptabilidade

figura. Algumas crianças tentam clicar na legenda escrita. (Flexibilidade)
As regras do software muitas vezes não são lidas ou compreendidas, Documentação de uso
necessitando de explicações do(a) docente sobre o jogo. direcionada a crianças
O software possui somente uma figura (interface) para ser colorida. A Adaptabilidade
criança normalmente se cansa por não ter outra opção. (Flexibilidade)
Gestão de erros
As mensagens de erro do software não informam onde a criança errou. (Auxílio no

reconhecimento)
Software não possui botão de saída.
usuário (saída)
Conclusões
O software pode ser usado quando o(a) docente está trabalhando com identificação de figuras
geométricas e cores. Foram encontradas algumas falhas (vide problemas) que fazem com que o
uso do software seja vinculado ao auxílio do(a) docente durante as tarefas. Ele deve ajudar
principalmente no entendimento do jogo e com o entendimento de erros. O software não
disponibiliza outras interfaces para serem coloridas, limitando seu uso.
Apesar dos problemas listados, o software proporciona relação agradável com a criança, o que
pode ser confirmado pela satisfação delas em jogar o jogo.
166
TABELA 49 − Problemas e conclusões sobre o software Dominó dos Números
Software Dominó dos Números
Incompreensão/Inconsistência da lógica do segundo jogo. Crianças não Significado de códigos e

entendem o que as figuras significam, então muitas vezes se irritam e denominações
acabam por jogar em tentativas e erros.
Ineficácia do terceiro jogo (crianças não contam as figuras, somente
Agrupamento e
listam os números). Se os números não estivessem em ordem, o jogo
distinção de itens
atingiria seus objetivos.
Irreversibilidade de ações no primeiro jogo (não possibilita
usuário (Desfazer uma
modificar/voltar/apagar)
ação)
Jogos não possuem instruções
Software usa padrão diferente de saída de tela (para continuar o jogo),
dificultando a interação da criança. O software, em vez de utilizar
Correspondência com
recursos semelhantes aos de jogos populares para a continuação de uma
outros programas
tarefa (como clicar em <enter> ou na mensagem), solicita que a criança
similares
clique fora da interface. Como as crianças muitas vezes não lêem as
mensagens das telas, a tarefa se torna problemática.
Conclusões
O software foi visto como inapropriado para o uso em ambientes educacionais, visto que, em
muitos casos (jogos dois e três), seus objetivos são dificilmente atingidos. Somente no primeiro jogo
do software, de tabuada, as crianças puderam desenvolver raciocínio. No segundo jogo, devido à
falha da disposição das figuras na tela, as crianças se confundem e não entendem o que fazer,
desistindo do jogo. Para se garantir que o jogo fosse bem-explorado, necessitaríamos de que o(a)
docente estivesse ao lado da criança durante todas as tarefas, explicando cada uma das telas do
jogo. Como isso não é possível num ambiente de sala de aula, onde o(a) docente deve ajudar
várias crianças ao mesmo tempo, não se pode garantir a eficácia do jogo. No terceiro jogo, o
problema ocorre porque as crianças, em vez de contar as figuras do jogo, entendem a priori que os
números das colunas estão em ordem crescente e os colocam sem contagem. Talvez se os
números estivessem em ordem aleatória, se forçasse a contagem pelas crianças.
167
7.2.1.3. Propostas de melhorias na MAQSEI
A MAQSEI foi usada pela primeira vez durante as avaliações da Rede

Coleguium de Ensino. Durante os testes, várias anotações sobre alterações na
metodologia foram registrados (propostas de melhoria no processo – PMP). Foram
elas:
§ Realizar os Pré e Pós-testes com crianças separadamente, entregando uma

folha de respostas para cada uma;
§ Abandonar as marcações de tempo de realização de tarefas, pois essas não

foram adequadas como medida de avaliação de tarefas infantis. Em testes com
crianças há interação maior entre o condutor e as crianças: condutor conversa,
ajuda, pergunta sobre as tarefas, interferindo nos tempos de realização;
§ Em vez de levar os documentos necessários (Pré/Pós-testes, Formulário de

observação, entre outros) em folhas separadas, fazer um “caderno” para cada
teste, facilitando a condução dos mesmos;
§ Fazer somente um formulário de entrevista e um formulário de questionário para

cada teste, usando-os com as duas crianças, simultaneamente 33. Como são as
mesmas perguntas, o condutor deve utilizá-las para as duas crianças e anotar as
respostas na mesma folha (colocar espaço reservado para a resposta de cada
criança nos formulários). Dessa forma, o condutor consegue registrar os dados
com mais facilidade e agilidade;
§ A condução do Pós-teste fica a critério do avaliador durante o teste. Caso as

crianças tenham obtido bons resultados no Pré-teste, talvez não precisem do
Pós-teste. Caso possam melhorar seus resultados, deve-se aplicá-lo.
As alterações descritas foram então realizadas para o uso da MAQSEI nas

próximas avaliações de programas de outras instituições.
33
A condução das entrevistas e questionários, simultaneamente, com duas crianças pode fazer com
que uma criança influencie nas respostas da outra. Entretanto, tal comportamento não foi notado nos
testes realizados neste trabalho.
168
7.2.2. Colégio Magnum Agostiniano
Criado há quatro anos em Belo Horizonte, o colégio Magnum Agostiniano 34 é

um centro particular que atende os níveis da educação infantil ao ensino médio.
A escola possui dois laboratórios de informática: um para educação infantil e

outro para ensinos fundamental e médio (com 25 microcomputadores em rede),
além de uma biblioteca equipada com alguns computadores para pesquisa em
outros horários. Existem quatro profissionais envolvidos, sendo um coordenador, um
técnico e duas docentes. Os laboratórios de informática são usados como apoio
pedagógico, de acordo com o conteúdo que esteja sendo tratado na disciplina.
Normalmente, o(a) docente procura uma das docentes responsáveis pelo laboratório
de informática e discute o que deseja desenvolver em sua disciplina ou projeto. São
mostrados os programas relacionados. Caso nenhum seja adequado, elabora-se
alguma atividade passível de ser realizada com o auxílio do computador (pesquisas
na Internet, atividades em editores de texto, entre outras).
Em entrevistas realizadas com docentes da escola, notou-se a preocupação

na escolha de programas que motivassem e estimulassem as crianças, além de
trazerem algum ganho no seu uso em relação aos métodos tradicionais de
ensino/aprendizagem.
7.2.2.1. Programas avaliados do Colégio Magnum Agostiniano
Os programas que a escola possuía foram analisados, sendo dois deles

selecionados para a condução das avaliações:
1 – Software Tabuada no Tabuleiro: software da editora Moderna, apresenta quatro

ambientes (jogos) para o exercício da multiplicação e da divisão. O primeiro jogo,
jogo da Tabuada (Figura 31), é um ambiente onde trabalham-se multiplicação,
divisão e estratégia. Primeiramente, deve -se configurar o jogo, selecionando com
qual tabuada se quer jogar (multiplicação ou divisão e três números de um a nove).
A partir daí, a criança deve formar uma linha dentro de um quadrado com as figuras
correspondentes. Para tanto, ela precisa resolver os problemas matemáticos
apresentados e usar de estratégia para colocar as figuras no lugar certo, uma vez
34
http://www.magnum.com.br
169
que pode jogar com um colega ou com o computador, que, provavelmente,
colocarão suas fichas em posições que a atrapalharão. O processo de colocação de
fichas é semelhante ao “jogo da velha”, só que em um quadrado com 25 posições e
três figuras.
FIGURA 31 − Jogo da Tabuada
No segundo jogo, Quebra-Cuca (Figura 32), deve-se escolher a configuração

do jogo da mesma forma que no primeiro. A criança deve então selecionar uma
operação em algum objeto e procurar no quadro embaixo da tela qual operação
mostrada é equivalente (2 X 3 = 2 + 2 + 2). Se selecionar a correta, ganhará uma
ficha (quadrado, bola ou retângulo) que deverá então ser levada e posicionada
corretamente no quadro em cima da tela, dependendo da classificação do objeto
previamente selecionado. Dessa forma, a criança estará trabalhando com
multiplicação, divisão, adição, subtração, igualdade e classificação. No final da
atividade, o personagem mostra quais foram as respostas certas e erradas.
170
FIGURA 32 − Jogo Quebra-Cuca
Já no terceiro jogo, Número Secreto (Figura 33), depois de escolhidos a

configuração do jogo e o tempo para sua realização, a criança deve resolver
sentenças matemáticas de divisão ou multiplicação. Em vez de digitar os resultados,
deve preencher os espaços com números disponíveis do lado esquerdo da tela. No
final da atividade, o personagem mostra quais foram as respostas certas e erradas.
FIGURA 33 − Jogo Número Secreto
No último jogo, Quadrado Mágico (Figura 34), novamente escolhe-se a

tabuada a ser trabalhada antes de iniciá-lo. Então, primeiramente a criança deve
171
responder às operações que aparecem. Ao terminar, ganha algumas fichas que
contêm números. Cada ficha então deve ser colocada no quadrado mágico, na
posição correta. O quadrado mágico é um quadro onde a soma de qualquer linha ou
coluna é igual ao número escrito em cima do quadrado.
FIGURA 34 − Jogo Quadrado Mágico
2 – Software Casa Mal Assombrada: o software Casa Mal Assombrada, do SENAC,

é composto de sete jogos que trabalham a grafia de grupos de palavras da língua
portuguesa. No jogo X CH, aparecem palavras para serem completadas com “x” ou
“ch”. A criança deve selecionar uma opção clicando em uma das caixas. Se acertar,
uma faca sai da caixa, acerta o alvo e a mata (bruxa, aranha ou o Frankenstein). Se
errar, a faca passa direto, errando o alvo. O jogo tem 30 palavras para serem
completadas. A Figura 35 mostra a interface do jogo.
FÌGURA 35 − Jogo X CH
172
No jogo Bingo, a criança deve digitar na cartela o nome da figura que a
caveira mostra. O jogo possui três cartelas de Bingo representadas pelas pequenas
caveiras que aparecem no canto superior esquerdo da tela. A Figura 36 ilustra a
interface da segunda cartela do jogo.
FIGURA 36 − Jogo Bingo
No jogo JG, a criança deve completar as palavras do texto arrastando a letra

“j” ou a letra “g” até a palavra. O jogo contém três textos indicados por meio de
pequenas figuras de bruxas na tela. A Figura 37 mostra um desses textos.
FIGURA 37 − Jogo JG
No jogo Homônimos e parônimos, a criança deve clicar na opção adequada

para a frase que aparece. Aparecem duas palavras com grafias e significados
173
diferentes. A criança deve selecionar a palavra cujo significado corresponde ao
esperado na frase. São 22 frases. Se a criança acerta, a caveira faz sinal de acerto,
se erra, mostra o significado das palavras, como na Figura 38.
FIGURA 38 − Jogo Homônimos e parônimos
No jogo c ç s, a criança deve clicar na letra que preencha corretamente as

lacunas do texto. Se acerta, aparece um morcego na coluna, se erra, aparece um
“X” em vermelho. São três textos disponíveis e representados pelas figuras de
morcegos na tela mostrada na Figura 39.
FIGURA 39 − Jogo c ç ss
174
No jogo c ç s ss xc sc, a criança deve clicar na abóbora que contém as letras
que completam corretamente a palavra selecionada na fórmula. São três fórmulas
possíveis. A Figura 40 mostra uma delas.
FIGURA 40 − Jogo c ç s ss sc xc
No jogo s x z, a criança deve completar as palavras do texto digitando “s”, ”x”

ou ”z”. Quando erra, aparece uma aranha na tela que passa por cima da palavra,
corrigindo-a. São três textos disponíveis, representados pelas aranhas no canto
inferior direito da tela ilustrada na Figura 41.
FIGURA 41 − Jogo s x z
175
7.2.2.2. Avaliação dos programas do colégio Magnum Agostiniano
Os programas selecionados foram avaliados de acordo com as técnicas da

MAQSEI. Por meio da metodologia foi possível avaliar: se os programas estavam
conseguindo obter os resultados esperados, seus objetivos e a adequação a uma
proposta pedagógica. Ainda foi possível identificar aspectos positivos e negativos
dos programas pela observação das crianças exercendo as tarefas solicitadas.
Primeiramente, os programas foram analisados para o reconhecimento de

funções e detalhes. A partir dessa análise, um Plano de testes foi preparado,
contendo uma listagem das questões que precisam ser avaliadas durantes os testes
(objetivos específicos da avaliação). A Tabela 50 lista essas questões.
176
TABELA 50 – Lista das perguntas a serem respondidas sobre os programas avaliados
Software Perguntas
Crianças prestam atenção às regras? Entendem?
Telas são confusas?

Tabuada no
Crianças entendem ou docente deve explicar como jogar?
Tabuleiro
Crianças se confundem com os ícones tabuada X/÷?
Crianças ficam tensas com tempo para fazer no jogo do número secreto?
Crianças gostam da linguagem usada no software?
Crianças entendem botões “outro” e ”chega”?
Mudança na posição dos botões “outro” e ”chega” influi?
No exercício X e CH, crianças entendem que erraram?
Casa Mal No exercício c ç s ss xc sc, crianças entendem que erraram?

Assombrada No exercício c ç s ss xc sc, crianças clicam uma vez só?
No exercício s x z, crianças tentam usar mouse?
Crianças entendem a indicação do número de atividades nos exercícios?
Crianças gostam da tela de resultado?
Crianças pensam ou vão por tentativa e erro?
Para o software Tabuada no Tabuleiro, foram realizados cinco testes 35 (quatro

duplas e um individual) com crianças de seis a dez anos. Todos foram realizados no
laboratório de informática do ensino fundamental e médio do colégio Magnum
Agostiniano, em microcomputadores K62 500 MHz, 64 MB de memória RAM, no
ambiente operacional Windows 98.
Para o software Casa Mal Assombrada, foram realizados sete testes:
§ Cinco testes realizados juntamente com os testes do software Tabuada no

Tabuleiro;
§ Dois últimos testes 36 realizados no laboratório de Usabilidade do

DCC/ICEx/UFMG 37 , em microcomputador Intel Pentium III, 500MHz, 256 MB de
memória RAM, no ambiente operacional Microsoft Windows 2000 Professional.
35
Testes realizados em 19/9 e 29/9/2003.
36
Testes realizados em 17 e 18/12/2003.
37
Departamento de Ciência da Computação, Instituto de Ciências Exatas, Universidade Federal de
Minas Gerais.
177
Quatro crianças entre seis e dez anos, trabalhando em duplas, participaram
desses testes.
Todas as crianças participantes das avaliações dos dois programas tinham

familiaridade com o uso de computadores e haviam trazido o Formulário de
consentimento dos pais autorizando a participação nos testes.
Em todos os testes, a seguinte conduta foi seguida:
Cada dupla de crianças foi recepcionada e informada sobre o teste. A seguir,

algumas perguntas sobre o perfil da criança (nome, idade, série, entre outras) foram
preenchidas no formulário de Entrevista com crianças.
O condutor do teste leu para as crianças o Script de orientação, quando foram

apresentados todos os envolvidos no teste, explicados os objetivos, descritas as
expectativas e esclarecido o uso do equipamento.
Foram realizados também Pré-testes com cada software, de acordo com o

conteúdo do programa. Para o software Tabuada no Tabuleiro, foram perguntadas
algumas operações da tabuada e para o software Casa Mal Assombrada foi feito um
ditado com palavras trabalhadas no programa.
O desenvolvimento dos testes consistiu em uma lista de tarefas que as

crianças deveriam realizar enquanto eram observadas. Enquanto executavam as
tarefas solicitadas, o condutor anotava as dificuldades, o que as crianças gostavam
ou não, comentários e reações. Seguem as listas das tarefas38 solicitadas em cada
programa (Tabelas 51 e 52).
38
Essas listas de tarefas foram preparadas no Plano de testes de cada software.
178
TABELA 51 − Lista de Tarefas software Tabuada no Tabuleiro
1 Entrem no primeiro jogo (Tabuada) e Req: Software em tela inicial
vejam as regras CS: Acessar as regras e ouvir
2 Vão para o jogo, digitem os nomes, Req: Software em tela inicial do primeiro
iniciem jogo
CS: Digitar nomes e entrar no jogo
3 Joguem com as tabuadas 4, 5 e 6 da Req: Tela do primeiro jogo
multiplicação CS: Conseguir configurar o jogo como
pedido e jogar até terminar
4 Saiam do jogo Req: Tela do primeiro jogo
CS: Sair pelo botão “saída”
5 Entrem no segundo jogo (Quebra-Cuca) Req: Software em tela inicial
e vejam as regras CS: Acessar as regras e ouvir
6 Vão para o jogo Req: Software em tela inicial do segundo
jogo
CS: Entrar no jogo
7 Joguem com as tabuadas 2, 3 e 4 da Req: Tela do segundo jogo
multiplicação CS: Conseguir configurar o jogo como
pedido e jogar até terminar o jogo
8 Saiam do jogo Req: Tela do segundo jogo
9 Entrem no terceiro jogo (Número Req: Software em tela inicial
secreto) e vejam as regras CS: Acessar as regras e ouvir
10 Vão para o jogo Req: Software em tela inicial do terceiro
jogo
CS: Entrar no jogo
11 Joguem com as tabuadas 4, 5 e 6 da Req: Tela do terceiro jogo
divisão em 180 segundos CS: Conseguir configurar o jogo como
12 Saiam do jogo Req: Tela do terceiro jogo
13 Entrem no quarto jogo (Quadrado Req: Software em tela inicial
Mágico) e vejam as regras CS: Acessar as regras e ouvir
14 Vão para o jogo Req: Software em tela inicial do quarto jogo
CS: Entrar no jogo
15 Joguem com as tabuadas 4, 5 e 6 Req: Tela do quarto jogo
CS: Conseguir configurar o jogo como
16 Saiam do jogo todo Req: Tela do quarto jogo
CS: Sair pelo botão “saída” das duas telas.
179
TABELA 52 − Lista de Tarefas software Casa Mal Assombrada

1 Abram o jogo -
2 Na tela principal, entrem no jogo X e CH Req: Software em tela inicial
CS: Entrar no jogo solicitado
3 Façam o exercício Req: Tela do jogo X e CH
CS: Fazer as 30 palavras e ver tela de
resultado
4 Voltem para a tela inicial e entrem no Req: Software em tela inicial
jogo Bingo CS: Entrar no jogo solicitado
5 Façam o primeiro e/ou o segundo bingo Req: Tela do primeiro jogo de Bingo
CS: Terminar o primeiro Bingo
6 Na tela inicial, entrem no jogo JG Req: Software em tela inicial
7 Completem o(s) texto(s) Req: Tela do primeiro texto
CS: Terminar o primeiro texto
8 Voltem para a tela inicial
9 Entrem no jogo Homônimos e Req: Software em tela inicial
parônimos CS: Entrar no jogo solicitado
10 Façam pelo menos cinco frases Req: Tela do jogo em questão
CS: Completar cinco frases
11 Voltem para a tela inicial
12 Entrem no jogo c ç s Req: Software em tela inicial
13 Completem a(s) tela(s) Req: Tela do jogo em questão
CS: Completar a primeira tela
14 Vão para a tela inicial
15 Entrem no jogo c ç s ss xc sc Req: Software em tela inicial
16 Completem a(s) fórmula(s) Req: Tela do jogo em questão
17 Vão para a tela inicial
18 Entrem no jogo s x z Req: Software em tela inicial
19 Completem o(s) texto(s) Req: Tela do jogo em questão
20 Saiam do jogo Req: Tela inicial
CS: Sair pela “saída”
Após todas as tarefas terem sido completadas, foram realizados Pós-testes

para cada software, contendo os mesmos exercícios dos Pré-testes, mas somente
para as crianças que haviam tido dificuldades. Em seguida, as crianças foram
questionadas pelo condutor do teste sobre suas preferências e opiniões a respeito
do software. Finalizando, as crianças foram agradecidas e liberadas.
Se necessário, alguns ajustes eram feitos no teste entre a realização de cada

sessão.
Terminadas as sessões dos testes, os dados coletados foram então

transcritos, resumidos e analisados, produzindo um relatório final de avaliação para
180
cada software. Os problemas e conclusões descritos nas Tabelas 53 e 54 foram
relatados sobre cada software.
TABELA 53 − Problemas e conclusões do software Tabuada no Tabuleiro
Software Tabuada no Tabuleiro
Problema Detectado Heurística(s) violada(s)
No jogo Tabuada dos números, as ações necessárias para se Reconhecimento no lugar

configurar o jogo para somente um participante não estão claras. de memorização
No jogo tabuada, as cores que discriminam de quem é a vez da Significado de códigos e

jogada não são facilmente diferenciadas denominações
Agrupamento e distinção de
itens
Desenho do jogo Tabuada dos números é confuso (muita
informação)
Carga de trabalho (carga
informacional)
Reconhecimento de erros no jogo Tabuada dos números não é Gestão de erros (Auxílio no
facilmente detectável, pois é realizado somente por meio de reconhecimento)
sonorização
Regras longas, crianças se desinteressam ou não prestam atenção Documentação direcionada

em todos os jogos a crianças
A tabela para a configuração da tabuada em todos os jogos não tem Adaptabilidade

a sua superfície “clicável”, somente em uma região. (Flexibilidade)
Irreversibilidade de ação no jogo Quadrado Mágico e Número Controle e autonomia do

Secreto usuário (Desfazer uma
ação)
Gestão de erros (auxílio na

O software não sugere solução para os erros que ocorrem durante os recuperação)
jogos
Software não permite impressão ou registro de desempenho Avaliação da aprendizagem
Sonorização não é opcional, podendo entediar as crianças ou

impossibilitar que ouçam as regras caso o computador não tenha Recursos motivacionais
caixa de som
181
Conclusões
Os jogos do software Tabuada podem ser usados com crianças que estejam aprendendo a
tabuada de divisão e multiplicação para exercitação dos conceitos. Apesar de serem jogos em
que a criança não tem liberdade de ações, restringindo-se a dar respostas às tarefas, podem ser
utilizados como ferramenta de auxílio no processo de ensino/aprendizagem do conteúdo que
privilegiam.
Pontos negativos:
Foram encontradas algumas falhas (vide problemas) que podem ser corrigidas com o auxílio
do(a) docente ou dos pais. A maior falha apresentada refere-se às regras dos jogos, que
necessitam ser explicadas às crianças, na maioria das vezes. A presença do(a) docente ou dos
pais também será importante para que a criança busque sempre o conhecimento em cima de
discussões sobre determinada dúvida, uma vez que o programa não oferece nenhum feedback e
não permite o registro dos dados.
Pontos positivos:
O software faz uso de personagens que proporcionam diversão, animação, colorido e

sonorização aos jogos, não interferindo no raciocínio da criança, na maioria dos casos (exceto no
jogo Quebra-Cuca, no qual o uso da temporização pode atrapalhar algumas crianças e, portanto,
seu uso deve ser avaliado pelo(a) docente ou pelos pais).
Em cada jogo, a criança pode escolher três números da tabuada para jogar (de 1 a 9), o que
possibilita que exercitem diferentes níveis de conhecimento. O(a) docente pode solicitar que a
criança utilize determinados números, variando o trabalho com as crianças.
TABELA 54 − Problemas e conclusões do software Casa Mal Assombrada
Software Casa Mal Assombrada
Problema Detectado Heurística(s) violada(s)
Os textos introdutórios de cada jogo do software aparecem e Controle e autonomia do

desaparecem em tempo determinado pelo software. Como esse usuário
tempo é rápido, não há tempo suficiente para a leitura dos mesmos.
Feedback de erro no jogo “j g” é dado antes que a tarefa seja

completada. Ao tentar colocar uma letra errada, o jogo muda o Interação (Feedback)
mouse indicando que está errado, então a criança que entende isso
pára de raciocinar no jogo. A partir de então começa a jogar por
tentativa e erro.
A forma de representação do número de telas em vários dos jogos é Correspondência entre o

igual à que outros jogos populares usam para representar software e o mundo real
possibilidade de erros. As crianças fazem associação com outros (Correspondência com outros
jogos e interpretam o significado erroneamente. programas similares)
Alguns jogos do software têm entrada de dados ou seleção de

objetos via mouse, outros, via teclado. Consistência e padrões
Regras do jogo “c ç ss” não deixam claro onde a criança deve clicar
para jogar. Criança tem o intuito de clicar onde as letras estão Documentação de uso
escritas, não compreendendo que deve clicar nos quadrados direcionada a crianças
brancos.(Os quadrados em branco deveriam ter letras, ser mais (regras)
significativos).
A identificação da palavra inicial do jogo “c ç s ss xc sc” não está Reconhecimento no lugar de

clara, confundindo as crianças. memorização
182
O feedback que o jogo “x ch” transmite à criança no caso de
erro/acerto é similar, podendo ser confundido. Gestão de erros (Auxílio no
reconhecimento, no
O feedback no caso de erro/acerto não é sonorizado. diagnóstico e na recuperação
de erros)
O feedback que os jogos “c ç ss” transmite à criança no caso de
acerto, é o aparecimento de um morcego no quadrado marcado Gestão de erros (Auxílio no
pela criança, o que não corresponde a uma identificação positiva reconhecimento, no
para ela. diagnóstico e na recuperação
de erros)
O feedback no caso de erro/acerto não é sonorizado. Significado de códigos e
denominações
O feedback que o jogo “x ch” transmite à criança no caso de
erro/acerto é similar, pode confundir. Gestão de erros (Auxílio no
reconhecimento, no
O feedback no caso de erro/acerto não é sonorizado. diagnóstico e na recuperação
de erros)
O significado dos botões de saída e troca de jogo não é claro, Significado de códigos e
causando confusão. denominações
Algumas figuras do jogo “Bingo” podem parecer representar outras Significado de códigos e
palavras. denominações
O jogo “c ç ss” determina ordem a ser seguida pela criança, não dá usuário
liberdade de escolha. Controle e autonomia do
usuário (Acesso)
Software não permite impressão ou registro de desempenho Avaliação da aprendizagem
Condução
Legibilidade
A localização da instrução do jogo “s x z” não é clara.
Conclusões
Apesar de o software ser formado por jogos em que a criança se restringe a dar respostas às
tarefas, pode ser utilizado quando o(a) docente está trabalhando com a grafia de grupos de
palavras da língua portuguesa.
Foram encontradas algumas falhas (vide problemas) que podem ser corrigidas com o auxílio
do(a) docente, o que é indispensável para que a criança não limite a sua capacidade de
curiosidade. A maior falha encontra-se no jogo “j g”. As crianças interpretam como se o jogo
fornecesse as respostas, ou seja, elas não precisam raciocinar durante o jogo, simplesmente
completam as palavras por tentativa e erro. Isso ocorre devido ao feedback antecipado que o jogo
fornece sobre as respostas certas/erradas. Em vez de esperar que a criança coloque a resposta
para conferi-la, o jogo não possibilita que respostas erradas sejam colocadas. Portanto,
recomenda-se que o jogo somente seja usado se o(a)docente/pais puder acompanhar de perto o
processo, checando se as crianças estão realmente pensando durante o mesmo.
Um dos fatores positivos do software foi a simulação de ambiente com personagens de uma
casa mal assombrada. O uso desses personagens, animações e coloridos despertaram a atenção
das crianças, motivando-as.
183
7.2.2.3. Propostas de melhorIas na MAQSEI
Durante os testes realizados com os programas Tabuada no Tabuleiro e Casa

Mal Assombrada, no colégio Magnum Agostiniano e no Laboratório de Usabilidade
do DCC/ICEx/UFMG, foram feitas alterações na MAQSEI, buscando o
aprimoramento e a validação da metodologia. Várias anotações sobre alterações na
metodologia foram registradas (propostas de melhoria no processo - PMP):
§ Nos Pré e Pós-testes realizados com duas crianças juntas, em vez de o condutor
perguntar individualmente as questões do teste e anotar suas respostas, ele
deve trazer os testes preparados em uma folha para que as crianças possam
preenchê-la ou escrever os resultados ao mesmo tempo. Assim, diminui-se o
tempo de realização e possibilita-se que os mesmos testes sejam aplicados para
as duas crianças;
§ Durante a condução do teste com crianças, o condutor não deve ler o Script de
orientação. A leitura pode tornar o ambiente mais formal. Sugere-se que o
condutor transmita o Script de orientação como se fosse uma conversa com as
crianças.
§ O condutor deve verificar, antes do teste, o perfil da criança na escola, se ela tem
dificuldade no conteúdo do software. Assim poderá comparar o comportamento
de diferentes perfis de crianças diante do programa;
§ Incluir no Script de orientação comentário dizendo que as crianças devem agir

naturalmente, como se fosse uma aula da escola;
§ Incluir no Script de orientação explicações sobre o ambiente do teste e os

equipamentos, para que esses não causem curiosidade nas crianças durante o
teste.
7.2.3. Escola Municipal Hilda Rabello Matta
A escola municipal Hilda Rabello Matta 39, situada em Belo Horizonte, possui
quatro ciclos de formação, além da educação de jovens e adultos (suplência). Essa
estrutura foi implantada a partir da Escola Plural na Rede Municipal. Por meio do
39
http://www.hirama.cjb.net
184
programa PROINFO40 do governo federal, a escola foi equipada com um laboratório
de informática, onde desenvolve vários projetos pedagógicos, envolvendo as
crianças no ambiente computacional.
Durante as visitas realizadas à escola, presenciou-se o projeto com o

software SimCity. O projeto, denominado Projeto Ideal City, teve como finalidade a
construção de conceitos de administração de cidades com qualidade de vida por
meio da simulação com uso da tecnologia. No projeto, as crianças desenvolviam a
construção de uma cidade utilizando os conhecimentos em Ciências, História,
Português, Geografia, Matemática, Artes e Pluralidade cultural. Trabalhavam então
suas competências na administração de cidade (simulação) e na leitura da realidade
(comparação entre as cidades do SimCity e a cidade real).
Nas observações das crianças trabalhando com o software, notou-se o

grande interesse delas no jogo. As crianças perguntavam, refletiam e discutiam
sobre suas cidades, formando conceitos e habilidades em planejamento,
administração e cidadania. O software demonstra ser um programa flexível, em que
as crianças podem construir a cidade da forma que desejarem. Isso possibilita que
elas trabalhem o ciclo descrição, execução, reflexão e depuração sobre o que estão
desenvolvendo. A descrição é realizada quando a criança estrutura a forma de sua
cidade. A execução é desenvolvida quando a criança testa construções da cidade,
como rede elétrica, distribuição de escolas e hospitais. A reflexão vem a partir dos
erros ou problemas detectados que precisam ser resolvidos. E a depuração é
concretizada nas alterações realizadas pelas crianças na sua cidade. Esse projeto
expressa a intenção da escola em trabalhar com programas que proporcionem maior
autonomia para as crianças poderem desenvolver os processos de aprendizagem.
Foram programadas algumas avaliações a serem realizadas na escola 41, mas

alguns fatores impossibilitaram a realização dos testes. Primeiramente, ao iniciar os
testes, verificou-se que o equipamento para a filmagem apresentava problemas,
impossibilitando a gravação dos testes (por isso a importância de sempre conferir o
funcionamento de todo o equipamento antes). Mesmo assim, decidiu-se por tentar
realizar os testes. Mas, ao entrevistar as crianças, percebeu-se que o perfil das que
40
Veja Capítulo 2, item 2.3.
41
Os testes de avaliação haviam sendo programados para dezembro de 2002.
185
haviam sido selecionadas pela escola não era adequado aos testes. Umas não
estavam na faixa etária esperada e outras não tinham conhecimento do uso do
computador. Tal fato invalidou a realização das avaliações preparadas. Para que as
crianças selecionadas a participar dos testes não ficassem frustradas, permitiu-se
que elas usassem o computador livremente (pois estavam esperando participar de
uma atividade especial na escola). Como a escola entraria em período de férias na
semana seguinte, os testes não puderam ser realizados em outra data.
7.3. Validação da MAQSEI durante o desenvolvimento de um software

educacional infantil
A MAQSEI também foi utilizada e validada durante o desenvolvimento de um

software educacional infantil por meio de um trabalho de conclusão de curso de
graduação em Ciência da Computação (OLIVEIRA, 2003). O trabalho desenvolveu o
software educacional infantil denominado OdontoMania, que aborda o tema da
importância da higiene bucal para a conservação da saúde e do bem-estar das
crianças.
A Figura 42 ilustra as interfaces do programa: a tela 1 do software é a

interface de apresentação do programa, representando a sala de espera de um
consultório odontológico. Nessa tela, a criança escolhe um dos personagens (“Ana”
ou “Edson”). Caso seja escolhida a personagem “Ana”, a tela 2 é apresentada à
criança, de onde ela pode dar início a um jogo de perguntas e respostas sobre a
saúde bucal (tela 4). Nesse jogo, cada pergunta respondida corretamente faz com
que a personagem avance uma casa, em direção ao equipamento odontológico.
Caso seja escolhido o personagem “Edson”, a tela 3 é apresentada, de onde pode-
se acessar um jogo de memória (tela 5).
186
Tela 1: Sala de espera
Tela 2: Ana no consultório Tela 3: Edson no consultório
Tela 4: Jogo de perguntas e respostas Tela 5: Jogo da memória

FIGURA 42 − Interfaces do software OdontoMania
A produção do software OdontoMania colaborou para este estudo por meio do

uso da MAQSEI e das heurísticas desenvolvidas. Durante todo o desenvolvimento
do programa, o desenvolvedor utilizou as heurísticas como referência para o
desenho das interfaces e implementação das funções. Posteriormente, foram
realizados alguns testes com protótipos do programa utilizando a MAQSEI. Esses
testes levantaram defeitos e modificações necessárias no programa.
187
7.3.1. Avaliações do software OdontoMania
De acordo com o relatado em OLIVEIRA(2003), os testes para a avaliação de

protótipos do software OdontoMania foram realizados com oito crianças no
laboratório de informática da Escola Estadual Instituto Agronômico, em Belo
Horizonte. As crianças foram recebidas pelo condutor dos testes, que informou a
todos os procedimentos que seriam executados. Depois de recolhidos os
Formulários de consentimento, as crianças foram conduzidas para o local do teste,
que se iniciou com o condutor lendo as perguntas da Entrevista para crianças e
anotando as respostas. O próximo passo foi a execução das tarefas propostas no
Plano de testes pelas crianças. Durante esse passo, o condutor ia anotando no
Formulário de observação todas as ações e comentários que eram relevantes para a
avaliação do sistema. Concluídas as tarefas, as crianças responderam às perguntas
do Questionário para crianças. Antes da liberação das crianças, o condutor
agradeceu a ajuda prestada e agraciou-as com um brinde.
7.3.2. Observações e propostas de melhoria na MAQSEI
As seguintes observações foram relatas a respeito da utilização da MAQSEI

durante o desenvolvimento do software OdontoMania (OLIVEIRA, 2003):
§ A fase de Reconhecimento do software da MAQSEI não foi realizada para as

avaliações do OdontoMania. Como o avaliador era o próprio desenvolvedor, a
identificação das interfaces e funções do programa não necessitaram ser
realizadas, assim como a familiarização com o contexto de uso do programa, que
já havia sido levantado durante a engenharia de requisitos do software;
§ Os modelos de documentos sugeridos pela MAQSEI são detalhados e facilitam a

coleta de dados;
§ A descrição da relação dos aspectos a serem analisados no Plano de testes lista

uma série de perguntas nas quais o teste deve ser focado, tornando-o mais
específico e completo;
§ O Formulário de observação sugerido na MAQSEI, pela inclusão de questões a

serem respondidas durante a realização de uma tarefa do teste, permite ao
avaliador recordar todos os pontos que merecem especial atenção durante a
condução do teste;
188
§ As recomendações para o comportamento e a postura do condutor durante a
realização dos testes facilitou o relacionamento com as crianças;
§ Na fase de análise dos dados e relatório final é necessária a inclusão das

soluções para os problemas técnicos e de Usabilidade levantados pelos testes;
§ As heurísticas propostas pela MAQSEI e aplicadas durante a análise do produto

também auxiliaram no levantamento de problemas do software e permitiram a
observação de certos pontos que poderiam ser alterados.
O resultados obtidos na utilização da MAQSEI durante o desenvolvimento de

um software educacional infantil demonstraram sua aplicação nesse outro contexto.
Este capítulo descreveu programas e avaliações utilizados durante a

validação da MAQSEI e das heurísticas desenvolvidas. A utilização da MAQSEI e
das heurísticas pelos programas serviu para verificar suas aplicações, constatar
eficácia, corrigir defeitos encontrados e aprimorá-las em alguns aspectos.
Cabe aqui ressaltar um aspecto de importância: os programas avaliados pela

MAQSEI eram software educacionais didáticos. Enquanto o software educacional é
todo aquele que pode ser usado para algum objetivo educacional, como um editor de texto
quando utilizado em um ditado, o software didático é aquele específico de um conteúdo ou
tema, como os programas utilizados nas avaliações deste trabalho. Portanto, o termo mais
adequado para classificar os programas utilizados seria didático. Entretanto, como a
metodologia foi elaborada inicialmente visando programas educacionais e pode também ser
aplicada em um contexto mais amplo, a terminologia não foi alterada.
189
8. CONCLUSÕES
8.1. Discussões sobre a MAQSEI
O objetivo deste trabalho foi levantar um conjunto de conhecimentos

baseados em estudos pedagógicos e de Usabilidade que orientassem e
fornecessem parâmetros metodológicos para auxiliar os processos de avaliação de
qualidade de software educacional infantil. Como resultado, apresentou-se uma
metodologia padronizada para avaliação da qualidade de software educacional
infantil, a MAQSEI, e as heurísticas que a fundamentam.
A MAQSEI, incluindo as heurísticas, foi desenvolvida por meio de um

processo para definição de processos pessoais (HUMPHREY, 1995). Isso facilitou a
sua produção, planejando, definindo necessidades, metas e objetivos, guiando suas
tarefas e ajudando a melhorar sua estrutura. Todo esse processo foi desenvolvido
evolutivamente. Iniciou-se com um processo simples, que foi incrementado e
modificado a partir dos resultados dos testes de sua aplicação.
A MAQSEI pode ser personalizada e/ou complementada dependendo da

equipe de avaliação ou até mesmo dependendo do software. Todas as técnicas,
instrumentos e padrões da metodologia devem ser verificados e adaptados para que
cubram aspectos específicos do produto, da tecnologia ou até da cultura e da
formação dos avaliadores.
A MAQSEI integra técnicas de avaliação analíticas, de pesquisa de opinião e

empíricas42. Técnicas analíticas são utilizadas nas análises qualitativas e
quantitativas dos atributos técnicos e pedagógicos do software (fase de Resumo de
dados e Produção do Relatório final de avaliação da MAQSEI). Nessas análises,
o(s) avaliador(es) avaliam o software sem a participação das crianças, de acordo
com as heurísticas e com uma lista de verificação de conformidade desenvolvidas
também neste estudo. Dois comentários são pertinentes aqui:
§ A utilização de listas de conferência geralmente produz resultados mais

uniformes e abrangentes, em termos de identificação de pequenos problemas,
42
Veja a definição dessas técnicas no item 2.7.
190
visto que os avaliadores são conduzidos no exame da interface por meio de uma
lista de questões a responder sobre o produto. No entanto, é importante
considerar que a qualidade da lista influencia a qualidade do resultado final
(PÁDUA, 2003).
§ A avaliação com listas de conferência foi combinada com a avaliação heurística

para se alcançarem as vantagens das duas abordagens. Entretanto, recomenda-
se que a avaliação heurística seja feita primeiramente. Somente após essa
primeira avaliação mais livre os avaliadores devem utilizar a lista de verificação
em uma segunda avaliação. O objetivo dessa separação em duas avaliações é
evitar que os avaliadores sejam dirigidos pelos ou se atenham somente aos itens
que constem na lista de verificação (PÁDUA, 2003).
As técnicas de pesquisa de opinião são utilizadas por meio da aplicação da

Entrevista com crianças, da Entrevista com docentes e do Questionário com
crianças. Essas pesquisas são aplicadas para avaliar a opinião, o grau de satisfação
e necessidade de crianças e/ou docentes em relação ao software. As técnicas
empíricas compreendem os testes realizados com as crianças por meio do
monitoramento da realização de tarefas no software.
A MAQSEI considera, além do produto, contexto de uso e público-alvo em

suas avaliações. O contexto de uso do software foi considerado no reconhecimento
da escola, na simulação dos ambientes reais de aplicação do software durante os
testes e na análise da pertinência e adequação em relação ao contexto identificado.
O público-alvo foi considerado no uso de métodos e técnicas adaptadas para
crianças e na participação delas nos testes. E o produto foi considerado durante
todo o processo, principalmente na verificação da sua conformidade em relação às
heurísticas.
8.2. Discussões sobre a informática na educação
A informática na educação foi apresentada como um instrumento de mudança

na área educacional. Não obstante há preocupações e dificuldades relacionadas à
escolha e ao uso do software educacional infantil. Evidenciou-se a necessidade da
realização de avaliações sistemáticas da qualidade e dos efeitos do software
educacional. O uso de um programa de baixa qualidade pode afetar, de maneira
191
desfavorável, a aprendizagem das crianças. Para amenizar tal fato defendeu-se a
realização de avaliações do software, tornando-as prática comum nas instituições de
ensino. Enfatizou-se também que o fato de um software ser considerado de boa
qualidade na opinião do desenvolvedor (avaliação orientada para o produto) apenas
indica uma possível utilidade no espaço escolar. Este estudo indica que também é
preciso avaliar os efeitos da utilização do software nas crianças (avaliações
orientadas para o usuário) e em ambientes reais de aprendizagem (avaliações
orientadas para o contexto).
As investigações realizadas em escolas para este trabalho mostraram que os

docentes lidam diariamente com as limitações dos programas disponíveis nas
escolas, tendo que criar atividades complementares para aproveitar esses recursos
nos seus trabalhos. Os docentes acreditam no potencial de uso das novas
tecnologias no ensino, seja para estimular ou proporcionar novas estratégias de
aprendizagem. Entretanto, ainda identificam muitas dificuldades quanto ao uso,
principalmente devido às questões de acesso: número limitado de computadores,
acesso restrito à Internet, falta de apoio técnico e pouca variedade de programas
educacionais disponíveis nas escolas.
8.3. Contribuições do trabalho
A MAQSEI pode ser utilizada em avaliações formativas (programas em

desenvolvimento) ou em avaliações somativas (programas prontos). Nas avaliações
formativas, a metodologia colabora para que o desenvolvedor descubra defeitos e
modificações necessárias no programa durante sua produção. Nas avaliações
somativas, a metodologia orienta escolas ou pais interessados na escolha do
software a ser usado com suas crianças.
Para a utilização da MAQSEI, o ideal é que uma equipe formada por

profissionais das áreas de Usabilidade e educação seja formada para realizar as
avaliações. Entretanto, como nem sempre isso é possível, todos os instrumentos de
avaliação utilizados na metodologia consideram os aspectos técnico e pedagógico,
buscando revelar detalhes sobre a interação entre a criança e a interface do
software e sobre a forma de aprendizagem proporcionada pelo programa.
192
A MAQSEI sugere o uso de padrões para os documentos utilizados em uma
avaliação de software educacional infantil. A avaliação de qualidade de um software
tem caráter subjetivo e local porque pode ser influenciada pelas expectativas e
percepções dos envolvidos, assim como das peculiaridades das situações
envolvidas. A adoção dos padrões nas avaliações de software diminui esse caráter,
tornando as avaliações comuns e melhorando sua qualidade e sua confiabilidade.
As heurísticas desenvolvidas neste estudo colaboram como referência técnica

e pedagógica para os avaliadores/desenvolvedores. Especialistas de Usabilidade
poderão utilizar uma base não só técnica, mas também pedagógica para avaliar ou
desenvolver software educacional infantil. Da mesma forma, especialistas em
educação poderão utilizar as heurísticas como base para avaliar programas
educacionais infantis não só pedagogicamente, mas também em relação à
Usabilidade.
Todas as fases da MAQSEI são realizadas principalmente pelo avaliador, que

planeja, conduz, analisa e relata os testes da avaliação do software. Devido à
importância deste papel na avaliação, várias recomendações sobre seu perfil, sua
conduta e suas habilidades foram descritas neste estudo. Elas visam,
principalmente, a descrever quais cuidados devem ser tomados ao se realizar uma
avaliação com crianças.
São, portanto, contribuições deste trabalho:
§ A proposta de Metodologia de Avaliação de Software Educacional Infantil,

denominada MAQSEI;
§ As heurísticas pedagógicas e de Usabilidade desenvolvidas, que fornecem

recomendações para o desenvolvimento e a avaliação de software educacional
infantil, além de fundamentar todas as fases da MAQSEI;
§ Os padrões de documentos propostos pela MAQSEI, que orientam e padronizam

a coleta de dados;
§ A listagem de perguntas a serem respondidas sobre o software durante sua

análise quantitativa (fase de Análise dos dados e Produção do relatório final), que
fornecem a conformidade do software em relação a cada uma das heurísticas
desenvolvidas;
193
§ As recomendações de perfil e conduta para o avaliador de software educacional
infantil;
§ As avaliações de alguns programas que foram utilizados para a validação da

MAQSEI;
8.4. Perspectivas de trabalhos futuros
A MAQSEI foi utilizada e validada somente pela autora deste estudo em

avaliações de programas educacionais infantis e por mais um avaliador em um
projeto de desenvolvimento de software educacional infantil (OLIVEIRA, 2003).
Pretende-se, portanto, reforçar o processo de validação da metodologia, permitindo
que seja conduzida por mais avaliadores.
A MAQSEI foi aplicada somente com programas voltados para crianças de

seis a dez anos. Na continuidade da linha de pesquisa, pretende-se também utilizar
a MAQSEI na avaliação ou no desenvolvimento de programas educacionais infantis
voltados para outras faixas etárias ou níveis de ensino, a fim de se verificar a
necessidade de alterações da metodologia. Caso essas modificações sejam
necessárias, a MAQSEI poderá ser ampliada, possibilitando sua utilização em
modalidades diferentes de software educacional infantil.
Por fim, deseja-se que a MAQSEI seja usada como ferramenta de apoio a
escolas, pais ou interessados na escolha do software educacional infantil a ser
utilizados pelas crianças ou por desenvolvedores de software infantil que primem
pela qualidade técnica e pedagógica dos programas.
194
9. REFERÊNCIAS BIBLIOGRÁFICAS
BEE, Helen. A criança em desenvolvimento. [s.l]: Harbra, [19--?].
BRANDÃO, Edemilson Jorge Ramos. Repensando modelos de avaliação de

software educacional. 3º simpósio investigação e desenvolvimento de
software educativo. Universidade de Évora, set. 1998. Capturado em
2/12/2002. Disponível em: <http://www.minerva.uevora.pt/simposio/
comunicacoes/artigo.html>
BRASIL, Ministério da Ciência e Tecnologia. Sociedade da informação no Brasil;

livro verde. 203f. Setembro 2000.
BRASIL, MEC/INEP/SEEC. Censo Escolar 2000. Capturado em Janeiro 2002

Disponível em: <http://www.inep.gov.br/imprensa/noticias/censo/escolar/
news01_3.htm>
BRAVERNA, H. Trabalho e Capital Monopolista. Rio de Janeiro: Zahar, 1977.
CAMPOS, Gilda Helena Bernardino de Campos. Metodologia para avaliação da

qualidade de software educacional; Diretrizes para desenvolvedores e
usuários. Rio de Janeiro, 1994. 232f. Tese (Doutorado em Engenharia de
Produção) – Universidade Federal do Rio de Janeiro.
CAMPOS, Gilda Helena Bernardino de Campos. Como avaliar um software

educacional. TIMaster, 2001. Capturado em 4/4/2001. Disponível em:
<http://timaster.com.br/revista/colunistas/ler_colunas_emp.asp?cod=331>
CAMPOS, Gilda Helena Bernardino de Campos. O que determina a qualidade de

um software educacional. TIMaster, 2001. Capturado em 4/4/2001.
Disponível em: <http://www.timaster.com.br/revista/colunistas/ler_colunas_
emp.asp?cod=310
CHAVES, Eduardo O. C. Tecnologia na educação, ensino a distância, e

aprendizagem mediada pela tecnologia; conceituação básica. Edutecnet.
Capturado em 6/2/2002. Disponível em: <http://www.edutecnet.com.br/
Textos/Self/EDTECH/EAD.htm>
195
COELHO, Maria de Lourdes. A formação continuada de professores
universitários em ambientes virtuais de aprendizagem; evasão e
permanência. Belo Horizonte, 2001. Dissertação (Mestrado em Educação) –
Faculdade de Educação, UFMG.
CONSTANTINE, Larry L., LOCKWOOD, Lucy A. D. Software for use: a practical

guide to the model and methods of usage-centered design. 2 ed. New York:
ACM Press, August 1999.
COUTINHO, Maria Tereza da Cunha, MOREIRA, Mércia. Psicologia da

educação: um estudo dos processos psicológicos de desenvolvimento e
aprendizagem humanos, voltado para a educação; ênfase nas abordagens
interacionistas do psiquismo humano. Belo Horizonte: Lê, 2001.
CRONJE, Joannes. The process of Evaluating Software and its Effect on Learning.
University of Pretoria. Department of Didactics. 2001. Disponível em:
<http://hagar.up.ac.za/catts/learner/eel/Conc/conceot.htm>
CUPERTINO, Marcelo Rodrigues de Souza, OLIVEIRA, Ronaldo Castro de.

Avaliação de um software educativo; ficha de registro. 2001. Disponível em:
http://www.uber.com.br/silvia/ied/material_teorico/avaliacaogramaticando.html
CYBIS, Walter de Abreu. Abordagem Ergonômica para IHC: Ergonomia de

Interfaces Humano-Computador. Capturado em 25/4/2003. Disponível em:
http://www.labiutil.inf.ufsc.br/Apostila_nvVersao.pdf
DEVRIES, Rheta, ZAN, Betty. A ética na educação infantil: o ambiente sócio-

moral na escola. Porto Alegre: Artes Médicas, 1998.
DIAS, Devanir Marcelo. O professor de ciências e biologia e a internet;

preconceitos, necessidades, capacidades, mudanças e desafios. Belo
Horizonte, [2000?]. (Resumo da monografia de conclusão de curso de
Licenciatura em Ciências Biológicas − Faculdade de Educação, UFMG).
DRUIN, Allison. The design of children’s technology. San Francisco: Morgan

Kaufmann Publishers, [1999].
196
DRUIN, Allison. Children as design partners; an introduction. Human-computer
interaction lab. Capturado em 4/1/2001. Disponível em: <http://www.
cs.umd.edu/hcil/kiddesign/>
EDWARDS, Alistair D. N., HOLLAND, Simon. Multimedia interface design in

education. [s.l] : [s.n], [19--?]. v.7. (NATO ASI Series, Series F : Computer
and Systems Sciences).
FONTANA, Roseli, CRUZ, Nazaré. Psicologia e trabalho pedagógico. [s.l] : Atual,

[19--?].
FONTES, Carlos. Teorias de aprendizagem e software educativo. 2001.

Disponível em: <http://educar.no.sapo.pt/teorias.htm>
FREIRE, Fernanda Maria Pereira, VALENTE, José Armando. Aprendendo para a

vida; os computadores na sala de aula. São Paulo: Cortez, 2001.
FRÓES, J. As Novas Tecnologias e a Formação Profissional - Caderno Técnico

SENAC - Rio de Janeiro,1998.
GALVIS-PANQUEVA, Álvaro H. Software educativo multimídia; aspectos críticos

do seu ciclo de vida. Capturado em 24/5/2001. Disponível em:
<http://www.inf.ufsc.br/sbc_ie/revista/nr1/galvis-p.html>
GAMEZ, Luciano. TICESE: técnica de inspecção de conformidade ergonômica de

software educacional. Portugal: Escola de Engenharia, Universidade do
Minho, 1998. (Dissertação, Mestrado em Engenharia Humana).
GARCIA, Denise Ferreira. Um estudo para adaptação de metodologias de

Usabilidade para o desenvolvimento de software infantil. Belo Horizonte:
Departamento de Ciência da Computação, UFMG, 2001. (Dissertação,
Mestrado em Ciência da Computação).
GODOI, J. S. e TEIXEIRA, A. B. M. Aprender a Ensinar, Ensinar a Aprender. VII

Encontro de Pesquisa da FaE/UFMG. 2001.
GONÇALVES, Irlen Antônio. Informática e educação: um diálogo com a

produção intelectual brasileira dos últimos vinte anos, que discute informática
e educação quanto a temáticas e questões, referenciais teóricos e concepção
197
de ensino. Belo Horizonte: Centro Federal de Educação Tecnológica de
Minas Gerais, 1999. (Dissertação, Mestrado em Tecnologia).
GRAVINA, Maria Alice, SANTAROSA, Lucila Maria. A aprendizagem da

matemática em ambientes informatizados. Capturado em 5/6/2000.
Disponível em: <http://penta.ufrgs.br/edu/telelab/mundo_mat/tecmat/
artigos/artigos.html>
HANNA, Libby, RISDEN, Kirsten, ALEXANDER, Kristin J. Guidelines for

usability testing with children; Methods & tools. Sept. 1997. Disponível em:
<http://www.microsoft.com/usability/UEPostings/p9-hanna.pdf>
HANNAFIN, Michael H., DALTON, David W., HOOPER, Simon. Computers in

education: ten myths and ten needs. Educational Technology, [s.l], v.XXVII,
n.10, p.8 -14, oct. 1987.
HERBERT, Juliana Silva, PRICE, Ana Maria de Alencar. Métodos para a

avaliação da qualidade de software. Porto Alegre: Instituto de Informática da
UFRGs, 1995.
HIX, Deborah, HARSTON, H. Rex. Developing user interfaces: ensuring usability

through product and process. New York : John Wiley & Sons, 1993.
HUMPHREY, Watts S. A discipline for software engineering. 5 ed. United States:

Addison-Wesley Publishing Company, 1995. Chapter 13: Defining the
software process.
ISO 9241 Part 11. Ergonomic requirements for office work with visual display
terminals, Part 11: guidance on usability. 1998.
ISO/IEC 12119, Information technology – Software packages – Quality

requirements and testing, October 1994.
ISO/IEC 14598-1:1999, Information technology – Software product evaluation –

Part 1: General overview.
ISO/IEC 14598-2:2000, Software engineering – Product evaluation – I
ISO/IEC 14598-3:2000, Software engineering – Product evaluation – Part 3:

Process for developers.
198
Process for acquirers.

Process for evaluators.

Documentation of evaluation modules.
KOZMA, Robert B. The implications of cognitive psychology for computer-based

learning tools. Educational Technology, [s.l], v.XXVII, n.11, p.20-25, nov.
1987.
LÉVY, Pierre. As tecnologias da inteligência: o futuro do pensamento na era da

informática. Rio de Janeiro: 34, 1993.
MACHADO, Rogério. Educação no país do futuro. Capturado em 10/8/2001.

Disponível em: <http://www.timaster.com.br/qa.asp?url=390>
MEDEIROS, Zulmira. Informática na educação: informática e as dificuldades de

aprendizagem. Capturado em 7/11/2001. Disponível em: <http://www.
escolanet.com.br/zulmira_03.asp>
MERCADO, Luís Paulo Leopoldo. A internet como ambiente de pesquisa na

escola. Presença Pedagógica, Belo Horizonte, v.7, n.38, p.53-65, mar./abr.
2001.
MILHOMEM, Gumercindo. O computador na escola e as entidades de educação.

Capturado em 7/11/2001. Disponível em: <http://www.moderna.
com.br/escola/prof/art01.html>
MINAYO, Maria Cecília de Souza (Org.), DESLANDES, Suely Ferreira, CRUZ

NETO, Otávio, GOMES, Romeu. Pesquisa social; teoria, método e
criatividade. Petrópolis: Vozes, 2001.
MISUKAMI, Maria da Graça Nicoletti. Ensino: as abordagens do processo.

Temas Básicos de Educação e Ensino. São Paulo: EPU, 1986.
NIELSEN, J. Usability Engineering. MA: Chestnut Hill, 1993.
199
NORMAN, D. A. The Psychology of Everyday Things. New York: Basic Books,
1988.
OLIVEIRA, Henderson Veiga de. Experimento para validação de metodologia de

avaliação de software infantil. Belo Horizonte: Universidade Federal de Minas
Gerais, 2003. (Projeto Orientado em Computação II)
PÁDUA, Clarindo Isaías Pereira da Silva e Pádua. Engenharia de Usabilidade.

Laboratório Synergia, Departamento de Ciência da Computação, Instituto de
Ciências Exatas, Universidade Federal de Minas Gerais. Maio, 2003.
PAPALIA, Diane E., OLDS, Sally Wendkos. O mundo da criança; da infância à

adolescência. [s.l] : McGraw-Hill, [19--?].
PAULA FILHO, Wilson de Pádua. Engenharia de software; fundamentos,

métodos e padrões. Rio de Janeiro: LTC, 2001.
PLUM – the Programme on Learner Use of Media, Institute of Educational

Technology, Open University, United Kindom, and TELL – Technology
Enhanced Language Learning, University of Hull. 2000. Evaluation methods
and procedures for studying learners’ use of media. Disponível em:
<http://iet.open.ac.uk/plum/evaluation/contents.html>
PRETTO, Nelson. Educação e inovação tecnológica: um olhar sobre as políticas

públicas brasileiras. Revista Brasileira da Educação, [s.l], p. 75-85, [1997?].
RAMOS, Edla Mendonça. O fundamental na avaliação da qualidade do software

educacional. Simpósio Brasileiro de Informática Educacional, Porto Alegre,
1991. Disponível em: <http://www.hipernet.ufsc.br/foruns/ine/
documentos/qualid.doc>
REZENDE, Flávia. As novas tecnologias na prática pedagógica sob a perspectiva

construtivista. Ensaio, Belo Horizonte, v.2, n.1, p.75-98, mai.2000.
RUBIN, Jeffrey. Handbook of usability testing; how to plan, design, and conduct
effective test. New York : Wiley, 1994.
RUMBAUGH, James, JACOBSON, Ivar and BOOCH, Grady. Unified Modeling

Language Reference Manual. Addison-Wesley, Reading – MA, 1999.
200
SANDHOLTZ, Judith Haymore, RINGSTAFF, Cathy, DWYER, David C.
Ensinando com tecnologia; criando salas de aula centrada nos alunos. Porto
Alegre: Artes Médicas, 1997.
SANT’ANNA, Tadeu Pissinati. Algumas linhas sobre o Projeto Político-

Pedagógico do Cefetes. 1999. Disponível em: <http://www.etfes.br/
instituicao/proj_pol_pedagogico/tadeu_pissinat.htm>
SÉRIE DE ESTUDOS EDUCAÇÃO A DISTÂNCIA. Salto para o futuro: TV e

informática na educação. Brasília: Coronário Editora Gráfica, v.3, 1998.
SEU FILHO. Desenvolvimento da inteligência; hereditariedade e educação,

evolução da inteligência, os testes. Rio de Janeiro: Globo, [199-?].
SILVA, Christina Marília Teixeira da. Avaliação de software educacional.

Conecta, n.4, Fevereiro, 2002. Disponível em: <http://www.revistaconecta.
com/conectados/christina_avaliacao.html>
SILVA, Cassandra Ribeiro de Oliveira e. Bases pedagógicas e ergonômicas para

concepção e avaliação de produtos educacionais informatizados.
Florianópolis: Universidade Federal de Santa Catarina, 1998. (Dissertação,
Mestrado em Engenharia de Produção).
SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, III, 1992, Rio de

Janeiro.
SOCIEDADE DA INFORMAÇÃO E EDUCAÇÃO, 2001, Belo Horizonte.
SOLOMON, Cynthia. Computer environments for children; a reflection on theories

of learning and education. New York: McGraw-Hill, 1982.
STRUCHINER, Miriam, RICCIARDI, Regina Maria Vieira, VETROMILLE, Vanise

Paraíso. O painel de especialistas no processo de apreciação analítica de
sistemas hipermídia para o ensino de graduação. Capturado em 10/11/2002.
Disponível em: <http://www.c5.cl/ieinvestiga/actas/ribie98/170. html>
THORNBURG, David D. Campfires in Cyberspace: Primordial Metaphors for

Learning in the 21st Century. Capturado em maio, 2003. Disponível em:
<http://www.tcpd.org/thornburg/Handouts.html>
201
VALENTE, José Armando. Computadores e conhecimento: repensando a
educação. Campinas: Universidade Estadual de Campinas — UNICAMP,
1993. Disponível em: <http://www.nied.unicamp.br/publicacoes/pub.php?
classe=separata>
VALIATI, Eliane Regina de Almeida. Elaboração e avaliação de um guia de

recomendações para auxílio no desenvolvimento de interfaces com
Usabilidade em softwares educacionais do tipo hipertexto/hipermídia
informativo. Porto Alegre: Instituto de Informática, UFRS, 2000.
(Dissertação, Mestrado em Ciência da Computação).
VALLIN, Celso. Como usar o computador na escola. Capturado em 7/11/2001.

Disponível em: <http://www.moderna.com.br/escola/prof/ art19.html>
VALLIN, Celso. Como implantar a informática na escola. Capturado em

7/11/2001. Disponível em: <http://www.moderna.com.br/escola/prof/
art18.html>
VIEIRA, Fábia Magali Santos. Avaliação de software educativo: reflexões para

uma análise criteriosa. Capturado em 20/11/2002. Disponível em:
<http://www.connect.com.br/~ntemg7/avasoft.html>
WHITELOCK, Denise. Estruturas para a avaliação de tecnologias de

aprendizagem multimídia; lições aprendidas e futuras direções. Ensaio, Belo
Horizonte, v.2, n.1, p.57-74, Maio, 2000.
202
ANEXOS
ANEXO I: Padrão para documento de Reconhecimento do Software
1. Escopo
Descrição
Avaliador
Documentos relacionados
Data
Tempo para produção
2. Identificação do software
Nome
Empresa
Objetivo
Público-alvo
Disciplina(s)
Idioma
Preço
Armazenagem
Requisitos
hardware/software
Resumo
Escola
3. Interfaces
3.1. Interface < nome ou número da interface >
3.1.1. Imagem
3.1.2. Descrição
3.1.3. Relacionamentos
203
3.1.4. Campos
Nº Nome Valores válidos Tipo Observação
1
2
3
3.1.5. Comandos
Nº Nome Estilo Ação Estado
1
2
3
3.1.6. Mensagens
Nº Tipo Imagem Texto Relacionamento
1
2
3
3.1.7. Pontos Positivos
3.1.8. Pontos negativos
3.1.9. Verificações a serem feitas no teste
3.1.10. Outras Observações
4. Observações e comentários gerais
204
ANEXO II: Padrão para documento de Proposta de avaliação de Software
Belo Horizonte, <dia> de <mês> de <ano>
Ilmo. Sr. <nome a quem o documento será encaminhado>

Escola <nome da escola>
Apresentamos a seguir a Proposta para avaliação do software <nome do software>, conforme

solicitado. O responsável pelo projeto será <nome do responsável>, que poderá ser contatado pelos
seguintes meios:
E-mail: <e-mail do responsável>

Fone: <fone do responsável>
Fax: <fax do responsável>
Aguardando resposta de Vs. Ss., subscrevemo-nos,
Atenciosamente,
<nome do responsável>
205
Proposta de avaliação do Software <nome do software>
1. Escopo
Descrição
Avaliador
Data
2. Requisitos da avaliação
3. Responsabilidades da escola
4. Cronograma
206
ANEXO III: Padrão para documento de Plano de testes
Plano de teste
< Nome do software >
Avaliador: < Nomes dos avaliadores >
< Local >
< Data >
207
PLANO DE TESTES
(INSERIR SUMÁRIO)
1. Introdução
2. Propósito
3. Documentação relacionada

1
2
4. Aspectos a serem avaliados
Tipo Pergunta a ser respondida

1.
2.
1.
2.
5. Perfil da criança
Característica Necessidade
6. Metodologia
208
7. Tarefas
Legenda:
Req = Requisito CS = Critério de Sucesso TMC = Tempo Máximo para Completar
Req:
1 CS:
TMC:
Req:
2 CS:
TMC:
8. Ambiente do teste e equipamentos requeridos
9. Papel do condutor de testes
10. Medidas de avaliação
11. Relatório de avaliação do teste
209
ANEXO IV: Padrão para documento de Pré-teste e Pós-teste
1. Escopo
Teste nº
Software
Data
Crianças
Escola
Condutor
2. Descrição
210
ANEXO V: Padrão para Formulário de observação
3. Escopo
Teste nº
Software
Data
Crianças
Escola
Condutor
4. Tarefas
Nº Descrição Observar
1
2 Outras ações e observações:
3
5. Outros comentários e observações
211
ANEXO VI: Padrão para Questionário com crianças
6. Escopo
Data
Crianças
Escola
Teste nº
Condutor
7. Perguntas gerais
ITEM NÃO NÃO
NÃO SIM NÃO SIM
SEI SEI
1 Você gostou do
jogo/exercício?
2 Gostaria de ter um igual
em casa?
3 Gostaria de ter aulas
usando o jogo?
4 Do que você mais gostou?
Por quê?
5 Do que você menos
gostou? Por quê?
6
7
8. Perguntas específicas
ITEM NÃO NÃO
NÃO SIM NÃO SIM
SEI SEI
1
2
3
4
5
6
212
Você gostou do jogo/exercício? Quanto? Marque na escala abaixo:
Criança 1: Criança 2:
213
ANEXO VII: Padrão para documento de Resumo de dados
1. Identificação
Software avaliado
Data(s) do teste(s)
Número de crianças
Local
Avaliador
Descrição do contexto
instrucional
2. Respostas das perguntas listadas no Plano de testes
3. Tarefas do Plano de testes

Nº Descrição Detalhes Dupla 1 Dupla 2 Dupla 3 Conclusão
4. Erros ocorridos nos testes do software

Heurística(s) Ranking de Ranking de Classificação
Nº Erro Fonte
violada(s) freqüência gravidade final
5. Resumo do teste
214
ANEXO VIII: Padrão para documento de Relatório final de avaliação de
software educacional infantil
Relatório de avaliação
< Nome do software >
Revisão < n >
Avaliador: < Nomes dos avaliadores>
< Local >
< Data >
215
RELATÓRIO DE AVALIAÇÃO
(INSERIR SUMÁRIO)
1. Escopo
Descrição
Público-alvo
Data do(s) teste(s)
Número de crianças envolvidas
Local
Contexto instrucional
Tempo para produção do relatório
2. Identificação do software
Nome
Empresa
Objetivo
Disciplina(s)
Idioma
Preço
Armazenagem
Requisitos hardware/software
Resumo
3. Documentação Relacionada

1
2
3
4. Problemas do software
Heurística(s)
Nº Problemas Classificação (8-0)
violada(s)
5. Análise qualitativa de atributos técnicos e pedagógicos
5.1. Pertinência em relação a uma proposta pedagógica
216
5.2. Utilização de recursos computacionais
5.3. Avaliação da aprendizagem
5.4. Interação
5.4.1. Reconhecimento no lugar de memorização
5.4.2. Qualidade das opções de ajuda
5.4.3. Legibilidade
5.4.4. Feedback
5.4.5. Agrupamento e distinção de itens
5.5. Adaptabilidade
5.5.1. Flexibilidade
217
5.5.2. Nível de experiência com o software ou com computadores
5.5.3. Ambiente cooperativo
5.6. Controle e autonomia do usuário
5.6.1. Acesso
5.6.2. Saída
5.6.3. Pausa
5.6.4. Desfazer uma ação
5.7. Recursos motivacionais
5.8. Gestão de erros
5.8.1. Prevenção de erros
218
5.8.2. Auxílio no reconhecimento, no diagnóstico e na recuperação de erros
5.9. Carga de trabalho
5.9.1. Carga informacional
5.9.2. Brevidade
5.10. Conteúdo
5.11. Significado de códigos e denominações
5.12. Consistência e padrões
5.13. Correspondência entre o software e o mundo real
5.13.1. Correspondência com outros softwares similares
219
5.14. Documentação
5.14.1. Documentação de descrição do produto (para docentes/pais)
5.14.2. Documentação de uso do software
5.14.2.1. Documentação de uso do software direcionada a docentes/pais

(instalação e regras)
5.14.2.2. Documentação de uso do software direcionada a crianças

(regras)
6. Análise quantitativa dos aspectos técnicos e pedagógicos

Legenda: S – Sim P – Parcialmente N – Não R - Resultado
Critério Atributos /Questões Peso S P N Valor
1. Permite a identificação do modelo de
aprendizagem que ele privilegia?
2. Permite a realização do ciclo descrição –
execução – reflexão – depuração – descrição?
3. O software é adequado e pertinente em
relação a uma disciplina específica?
4. O software pode ser integrado ao conteúdo
Pertinência em curricular e a outras partes do currículo
relação a uma escolar para auxiliar no aprendizado da
proposta disciplina?
pedagógica 5. O software realmente auxilia as crianças na
aquisição das habilidades e dos conteúdos
propostos?
6. Os docentes da escola teriam facilidade em
adotar o software como parte das suas
atividades?
7. O objetivo do software é claro?
Conformidade
220
1. O mesmo conteúdo do software seria
dificilmente ensinado sem o uso do recurso
tecnológico do computador?
2. Apresenta informação de forma interativa?
Utilização de
3. Age com diversos níveis de inteligência
recursos
adquirida?
computacionais
4. Viabiliza diferentes níveis de interação?
5. Utiliza recursos motivacionais?
6. Faz conexão com outros meios de
aprendizagem?
Conformidade
1. O software possibilita algum recurso que

permita avaliar o grau de compreensão das
crianças na resolução de problemas?
Avaliação da 2. O software armazena informações relativas à
aprendizagem interação das crianças tais como pontuações,
níveis atingidos ou dificuldades enfrentadas?
3. O software permite a impressão dos registros
de desempenho das crianças?
Conformidade
1. A criança encontra disponíveis meios

(mensagens, alarmes) para aconselhá-la,
orientá-la ou informá-la na sua interação com o
programa?
2. A criança sabe a qualquer momento se
localizar numa seqüência de interações ou na
execução de uma tarefa?
3. A criança conhece as ações permitidas bem
Interação
como suas conseqüências?
4. A criança pode obter informações
suplementares (eventualmente a seu pedido)?
5. O software informa os resultados do estado da
ação, de forma que ele possa acompanhar a
evolução do processamento da informação,
usando recursos como, por exemplo,
ampulhetas, relógio, barra de progressão?
6. Interface do software é simples e transparente,
Interação – não interferindo no processo de aprendizagem?
Reconhecimento 7. Objetos, ações e opções estão visíveis?
no lugar de 8. O software minimiza a necessidade de a
memorização
criança lembrar dados exatos de uma tela para
outra?
221
9. O software disponibiliza comandos de ajuda?
10. Os dispositivos de ajuda abrangem a totalidade
do sistema?
Interação –
Qualidade das 11. O acionamento da opção de ajuda está
opções de ajuda estruturado no contexto da tarefa e da
transação corrente?
12. O software apresenta diferentes formas de
acesso aos conteúdos de ajuda?
13. Os conteúdos apresentados estão livres de
equívocos conceituais ?
14. A redação das informações textual está correta,
livre de erros gramaticais e de erros de
pontuação?
15. Os textos literários favorecem a compreensão
de conteúdos?
Interação – 16. O vocabulário usado propõe uma interpretação
Legibilidade única no seu significado?
17. Os diálogos/textos são de fácil legibilidade?
18. Os diálogos/textos são pequenos?
19. Os ícones são representativos das suas
funções?
20. É usada a linguagem da criança, com palavras,
expressões e conceitos familiares a ela, no
lugar de termos orientados para o software?
21. O software fornece feedback imediato de todas
as entradas de dados das crianças?
22. O software emite feedback encorajador,
variado e isento de carga negativa mediante
respostas inadequadas?
23. O tempo de resposta do software é adequado?
24. O usuário tem sempre a possibilidade de obter
Interação – um feedback informando sobre o sucesso ou o
Feedback fracasso da operação?
25. O software fornece feedback sobre as
mudanças de atributos dos objetos de
interação, ou seja, ao selecionar um botão, ele
muda de estado?
26. O software emite algum feedback sonoro
opcional mediante respostas inadequadas da
criança?
27. O software apresenta distinção visual clara de
áreas que possuem diferentes funções?
28. Os dados que requerem atenção imediata são
Interação – diferenciados de alguma forma?
Agrupamento e 29. Nos agrupamentos de dados e informações, os
distinção de itens itens estão organizados segundo critério lógico
e facilitador?
30. A informação é apresentada numa organização
direcionada para a criança?
Conformidade
222
1. O software abrange crianças em vários níveis
de conhecimento?
2. O software permite que o acesso a qualquer
nível seja feito diretamente, sem ter que passar
pelos anteriores?
3. O software permite diferentes formas para a
realização de tarefas?
4. O software permite a flexibilidade de ações
Adaptabilidade –
(para software construtivista)?
Flexibilidade
5. O software propõe formas variadas de
apresentação das mesmas informações a
diferentes crianças?
6. O docente/pai pode alterar algumas
configurações do software, adequando-o ao
seu interesse?
7. As crianças têm a possibilidade de modificar ou
eliminar itens?
8. A seqüência de apresentação dos conceitos
evolui em grau de complexidade?
9. O software abrange crianças que não têm
Adaptabilidade – familiaridade com computadores?
Nível de
10. O software possui atalhos?
experiência
11. O software possibilita efetuar alterações em
suas estruturas de modo a contemplar a
experiência da criança?
12. O software suporta o trabalho cooperativo entre
criança e/ou entre crianças e docentes?
Adaptabilidade – 13. O software pede em vez de ordenar, sugere em
Ambiente vez de exigir ou persuade em vez de controlar?
cooperativo 14. O software possibilita que o(a) docente possa
expandir o conteúdo do programa em seu
trabalho?
Conformidade
Controle e 1. O processamento das ações é efetuado

autonomia do somente quando solicitado pela criança?
usuário 2. A criança pode controlar o ritmo das tarefas?
3. Há possibilidade de acesso a todas as
Controle e informações a todo momento (salvo em casos
autonomia do contra uma necessidade do conteúdo)?
usuário – Acesso 4. Permite realizar uma chamada de operação a
partir de outra e poder voltar a primeira?
5. Software permite que a criança abandone o
Controle e programa a qualquer momento ou ir para outro
autonomia do item do menu ?
usuário – Saída 6. O software sinaliza as conseqüências da
atividade de saída?
Controle e
7. A criança pode interromper, retomar e reiniciar
autonomia do
uma tarefa a qualquer instante?
usuário – Pausa
223
Controle e
autonomia do 8. Software permite que a criança anule a última
usuário – ação realizada?
Desfazer uma
ação
Conformidade
1. O software possui recursos motivacionais para

despertar e manter a atenção da criança ao
longo da interação?
2. Os recursos motivacionais utilizados
permanecem interessantes ao longo do tempo,
sem tornarem-se irritantes?
3. A qualidade gráfica/estética das interfaces é
alta?
4. Os recursos motivacionais são utilizados de
maneira moderada, sem provocar a distração
da criança no que se refere ao foco principal do
software?
Recursos 5. Software proporciona desafio à criança?
motivacionais 6. São utilizados recursos sonoros para contribuir
para a motivação?
7. Os recursos sonoros são opcionais?
8. O software usa de temporização com cautela?
9. O software estimula a imaginação da criança,
por meio de contexto ou situação?
10. Os recursos propostos pelo software podem
contribuir para a melhoria do relacionamento
professor/criança e colegas/criança?
11. A criança tem vontade de jogar de novo?
12. O software instiga a criança à procura de novos
conhecimentos ou à consulta de outras
referências sobre o assunto?
Conformidade
1. O software faz consistência dos dados,

impedindo que a criança entre com valores
incorretos em campos de dados?
2. O sistema emite sinais sonoros quando
Gestão de erros
ocorrem problemas na entrada de dados?
– Prevenção
3. As teclas de funções “perigosas” encontram -se
agrupadas e/ou separadas das demais?
4. Software previne a ocorrência de erros, por
meio de um desenho cuidadoso?
224
5. A correção de erros durante a execução de
tarefas é otimizada, ou seja, permite que a
criança faça a correção sem ter que refazer
vários passos anteriores?
6. Na ocorrência de erros na resolução dos
exercícios propostos, o software orienta e
oferece à criança a possibilidade de tentar
refazê-los?
7. Persistindo o erro durante uma tarefa, o
software conduz a criança, fornecendo-lhe
explicações para a correção?
8. O software fornece a solução após longa
persistência do erro?
9. O software permite a mudança automática de
exercício se a criança persiste no erro,
conduzindo-a a outro tipo de exercício, com
Gestão de erros menor grau de dificuldade?
– Auxílio no 10. As mensagens de erro são assinaladas
reconhecimento, imediatamente ou o mais rápido possível?
no diagnóstico e 11. As mensagens de erro são expressas em
na recuperação linguagem simples (sem códigos), de uso
de erros comum e são curtas?
12. As mensagens de erro adotam vocabulário
neutro, não-repreensivo e evitam o humor?
13. As mensagens de erro são positivas?
14. As mensagens de erro indicam precisamente o
problema?
15. As mensagens de erro sugerem
construtivamente uma solução?
16. Perante uma dificuldade na resolução dos
exercícios, o software evita a monotonia,
oferecendo mensagens de erro variadas?
17. O software permite que a criança modifique o
erro, corrigindo-o parcialmente ou totalmente?
Conformidade
1. A carga informacional apresentada é

equilibrada e está bem-distribuída em unidades
de informação?
Carga de
2. As informações evitam a poluição visual?
trabalho – Carga
Informacional 3. A carga informacional apresentada está
adequada à disciplina de ensino?
4. Informações dos diálogos/textos são sempre
relevantes?
5. Somente as informações necessárias e
utilizáveis são apresentadas?
Carga de 6. As tarefas são feitas em poucos passos?
trabalho – 7. Textos e diálogos são sucintos?
Brevidade 8. Quando várias telas estiverem envolvidas, o
sistema possibilita ir diretamente para uma tela
sem ter que passar pelas intermediárias?
Conformidade
225
1. O software possui bom grau de coerência no
conteúdo das questões apresentadas em
função da proposta pedagógica a que se
propôs?
2. O conteúdo do software é significativo para a
criança?
3. O conteúdo do software educacional infantil é
rico em dimensões exploratórias?
4. O conteúdo do software possibilita que o(a)
Conteúdo docente possa explorá-los durante a interação
das crianças com o programa?
5. O conteúdo do software se relaciona com as
vivências das crianças, especialmente com a
realidade brasileira?
6. O conteúdo do software permite que a criança
possa avançar no conhecimento, possibilitando
diferentes níveis de aprendizado?
7. As explicações sobre um tema são opcionais?
8. Novas palavras são explicadas?
Conformidade
1. O vocabulário utilizado é familiar à criança?

2. Os códigos e denominações estão de acordo
Significado de com o que representam?
códigos e 3. É evitado o uso de siglas ou abreviaturas?
denominações 4. As palavras, situações, objetos ou ações
diferentes no software significam sempre a
mesma coisa?
Conformidade
1. Palavras, situações ou ações com o mesmo

significado são compreendidas pelas crianças
Consistência e no software?
padrões 2. Os procedimentos, comandos ou botões do
software têm formato, posição ou sintaxe
estáveis no software?
Conformidade
1. O software segue as convenções do mundo

real?
Correspondência 2. O software usa palavras, expressões e
conceitos familiares à criança, no lugar de
com o mundo
termos orientados para o programa?
real
3. O software simula ambientes familiares às
crianças ou utiliza metáforas conhecidas por
elas?
226
Correspondência
com o mundo
real – 4. O software segue convenções oriundas de
Correspondência outros programas infantis populares, como
com outros jogos infantis existentes no mercado?
programas
similares
Conformidade
1. O software fornece documentação direcionada

tanto para pais/docentes quanto para crianças?
Documentação 2. A documentação está acessível a todo
momento para o usuário?
3. A documentação aparece somente quando
solicitada?
4. O software apresenta dados do produto, como
nome, versão e empresa?
5. Os pré-requisitos técnicos estão identificados?
6. Os objetivos pedagógicos do produto estão
identificados?
Documentação –
7. Está discriminada alguma sugestão de trabalho
Documentação
com o software?
de descrição do
produto (para 8. A identificação da faixa etária a que se destina
docentes/pais) é identificada?
9. A documentação de descrição do produto está
sempre disponível?
10. A documentação de descrição do produto é
compreensível, completa e está livre de
inconsistências internas?
11. Existe documentação sobre a instalação do
software?
12. É orientada para docentes/pais?
Documentação – 13. Incluiu dados sobre a utilização do software
Documentação (regras) direcionada a docentes/pais?
de uso do 14. A linguagem é compreensível, bem-organizada
software – e de fácil leitura?
Documentação 15. Os textos são legíveis, sem erros ortográficos?
de uso do
16. É de fácil pesquisa?
software
direcionada a 17. Focaliza a tarefa do usuário?
docentes/pais 18. Lista passos concretos a seguir?
(instalação e 19. Os termos técnicos ou abreviações são
regras) explicados?
20. As informações estão bem-organizadas e
distribuídas?
21. Mantém a consistência e a homogeneidade em
todas as suas ocorrências?
227
22. Existe documentação (regras) direcionada para
a criança?
Documentação – 23. Usa linguagem familiar à criança?
Documentação 24. Estão visíveis ou facilmente recuperáveis?
de uso do
25. Focaliza a tarefa da criança?
software –
26. São curtas?
Documentação
de uso do 27. São compreensíveis?
software 28. São transmitidas por animações?
direcionada a 29. Se forem escritas, são legíveis e sem erros?
crianças (regras) 30. Se forem escritas, são bem-organizadas e
distribuídas?
31. Mantêm a consistência e a homogeneidade em
todas as suas ocorrências?
Conformidade
7. Resultados da Análise quantitativa
7.1. Tabela de critérios e conformidades

Critério Conformidade (%)
1. Pertinência em relação a uma proposta pedagógica
2. Utilização de recursos computacionais
3. Avaliação da aprendizagem
4. Interação
5. Adaptabilidade
6. Controle e autonomia do usuário
7. Recursos motivacionais
8. Gestão de erros
9. Carga de trabalho
10. Significado de códigos e denominações
11. Consistência e padrões
12. Correspondência entre o software e o mundo real
13. Documentação
7.2. Gráfico de critérios X conformidade
(GRÁFICO)
8. Conclusões e recomendações
228
Anexo IX: Entrevista com docentes
Prezado(a),
Meu nome é Ana Paula Ribeiro Atayde. Sou mestranda em Ciência da Computação
pela Universidade Federal de Minas Gerais. Minha dissertação de mestrado propõe avaliar a
qualidade de software educativo, buscando contribuir para a criação de critérios de
avaliação de software, assim como para a construção de software educativo e orientação de
uso pelos docentes.
Gostaria de contar com a colaboração do(a) senhor(a) no preenchimento deste
questionário. Fico à disposição para quaisquer outros esclarecimentos.
1 – Indique sua faixa etária
_____ Entre 20 e 29 anos

_____ Acima de 50 anos
2 – Qual é o seu sexo?
_____ Feminino _____ Masculino
3 - Você tem acesso a computador?
_____ Sim, em casa

_____ Sim, no trabalho
_____ Sim, em casa e no trabalho
_____ Não
Em caso negativo, pule para a questão 7.
4 – Com qual freqüência utiliza o computador?
_____ Diariamente
_____ 3 vezes por semana
_____ 1 vez por semana
_____ Raramente
5 – Como aprendeu a usar o computador?
_____ Não sei usar, peço ajuda a outros

_____ Com ajuda de outros
_____ Método autodidata
_____ Por curso de informática
_____ Outra forma. Qual? _________________________________________________
6 – Para que atividades utiliza o computador?

_____ Atividades pessoais (Internet, e-mail, etc.)
_____ Atividades profissionais
229
_____ Não utilizo
_____ Outras. Quais? _____________________________________________________
7 – Qual das opções abaixo mais se aproxima de seu atual status profissional?
_____ Estagiário
_____ Recém-formado
_____ Profissional
_____ Coordenador
8 - Indique a(s) escola(s) em que trabalha:
_____ escolas públicas

_____ escolas particulares
9 – Indique em qual(s) nível(s) leciona:
_____ Educação Infantil

_____ 1ª a 4ª série do Ensino Fundamental
_____ 5ª a 8ª série do Ensino Fundamental
_____ Ensino Médio
10 – Indique qual disciplina leciona:
_____ Matemática
_____ Português
_____ Inglês
_____ Ciências
_____ História
_____ Geografia
_____ Outra. Qual?_____________
11 – Qual é o seu método preferido de ensino?

(Qual a metodologia de ensino que orienta o seu trabalho em sala de aula? Quais técnicas
de ensino você utiliza com maior freqüência?)
__________________________________________________________________________
________________________________________________________________
12 - Você faz uso de computadores nas atividades de ensino?
_____ Sim
_____ Não
13 - Se sim, em que situações você faz uso desses recursos?

__________________________________________________________________________
________________________________________________________________
14 - A instituição em que você trabalha ofereceu algum curso preparatório para que os
docentes adotassem recursos de informática no trabalho de sala de aula?
_____ Não
_____ Sim. Como? ______________________________________________________
230
15 – Como você enxerga o uso do computador na escola?
_____ Uso operacional da escola (informatização da parte administrativa da escola)

_____ Ferramenta de ensino (auxiliando os métodos já existentes)
_____ Nova metodologia de ensino (diferente das já existentes)
_____ Outro. Qual? ______________________________________________________
16 – Você acha que a introdução da informática na educação modifica

o papel do docente?
_____ Sim
_____ Não
Por quê?
__________________________________________________________________________
________________________________________________________________
17 – Em qual modalidade você acha que a maioria dos programas educacionais se

encaixam?
_____ Tutoriais (a criança obtém as informações, lendo-as ou vendo-as, e testa o

conhecimento por meio de exercícios e práticas)
_____ Processadores de texto (Ex.: Word)
_____ Uso da Internet
_____ Programação (Ex. : Logo)
_____ Jogos
_____ Sistemas de autoria para multimídia e Internet (Ex.: Frontpage, Flash, etc.)
_____ Simulação e Modelagem (oferecem situações para a criança descrever e
implementar ou criança implementa modelo de sistema no computador)
_____ Outra. Qual? ___________________________________________________
18 – Que benefício(s) você percebe com o uso de computadores no processo de

ensino/aprendizagem?
_____ Eficiência no gerenciamento de registros e dados

_____ Feedback rápido das crianças
_____ Instrução individualizada
_____ Crianças mais participantes
_____ Menos problemas de disciplina
_____ Melhor comunicação com os pais
_____ Outro(s). Qual(s)? __________________________________________________
19 - Que limitações você identifica com o uso de computadores no processo de

ensino/aprendizagem?
__________________________________________________________________________
________________________________________________________________
20 – A escola em que trabalha tem laboratório de informática?
_____ Sim
_____ Não
Em caso negativo, pule para a questão 25.
231
21 – Em que situações o laboratório é utilizado?
_____ Aula de informática

_____ Quando necessário, de acordo com o programa do colégio
_____ Somente para acesso a Internet e e-mail
22 – É utilizado software educacional nas aulas?
_____ Não
_____ Sim. Quais? ____________________________________
____________________________________
23 – Há quanto tempo o software é utilizado na escola como recurso didático?
_____ Até um ano

_____ De 1 a 2 anos
_____ De 3 a 5 anos
_____ Mais de 5 anos
_____ Não sei
24 – Como é selecionado o software usado na escola?

_____ Por um responsável da área técnica
_____ Por um responsável da área pedagógica
_____ Por uma equipe da área técnica
_____ Por uma equipe da área pedagógica
_____ Por uma equipe das áreas técnica e pedagógica
_____ Não tem seleção, docente traz o software que quer usar
_____ Não tem seleção, crianças trazem software
_____ Outra. Qual? ______________________________________________________
25 – Qual(s) característica(s) pedagógica(s) você considera de importância num software

educacional?
_____ Adaptabilidade do software (uso por diferentes crianças, em diferentes ambientes)

_____ Adequação ao contexto educacional
_____ Adequação de conteúdos
_____ Correção dos conteúdos
_____ Estímulo (uso de sons, cores, etc.)
_____ Existência de auxílio on-line
_____ Facilidade de utilização
_____ Interatividade com criança
_____ Modelo de aprendizagem que ele privilegia
_____ Motivação oferecida (a procurar novos conhecimentos)
_____ Objetivo educacional
_____ Possuir tratamento de erros
_____ Respeito à individualidade (ex.: não conter fatores de discriminação)
_____ Outras. Quais? _____________________________________________________
232
26 – Qual(s) característica(s) técnica(s) você considera de importância num software
educacional?
_____ Específica os requisitos de hardware / software

_____ Facilidade de instalação / desinstalação
_____ Fornece o manual de uso
_____ É compatível com outro software/hardware (Ex.: possibilita cortar/colar textos)
_____ Funciona em rede
_____ Dispõe de help – desk (suporte)
_____ Tamanho do software
_____Outras. Quais? _____________________________________________________
27 – O que o faz recusar o uso de um software educativo?

__________________________________________________________________________
__________________________________________________________________
28 – Você gostaria que sua escola investisse mais em informática?
_____ Sim
_____ Não
Por quê? Em quê?____________________________________________________

______________________________________________________________________
29 - Como você vê o uso da informática nas escolas daqui a alguns anos?

______________________________________________________________________
______________________________________________________________________
Agradeço pela contribuição,

Mestranda em Ciência da Computação UFMG
Coordenadora dos cursos de extensão DCC/UFMG
Tels.: 3499-5574 / 9990-3908
E-mail: atayde@dcc.ufmg.br
Orientadores:
Adla Betsaida Martins Teixeira Clarindo Isaías Pereira da Silva e Pádua
Faculdade de Educação – UFMG Depto. de Ciência da Computação – UFMG
233
Anexo X: Fases
Fase Descrição
Fase na qual o software a ser avaliado é analisado,
Reconhecimento e Proposta de o suficiente para o avaliador conhecer todas as
avaliação do Software funções e características do programa e estimar
prazos e custos.
Fase na qual são preparados todos os materiais
(formulários, questionários, scripts ), equipamentos
Planejamento dos testes e ambientes que serão envolvidos nos testes, além
da seleção dos participantes, resultando num
documento de Plano de testes.
Fase na qual são aplicados os testes preparados
Realização dos testes
com várias crianças.
Fase na qual todos os dados coletados nos testes
Análise de dados e Produção do são transformados em resultados e recomendações
Relatório final de avaliação sobre o software, resultando em um relatório de
avaliação do software sobre suas questões
pedagógicas e de Usabilidade.
234
Anexo XI : Tarefas
Fase Tarefas
Entrevistar docentes da escola
Reconhecimento e Proposta de Familiarizar com o software
avaliação do software Registrar anotações sobre o software
Estimar prazos e custos
Personalizar a metodologia
Preparar o Plano de testes
Preparar todos os documentos necessários
Planejamento dos testes Preparar Lista de verificação
Selecionar crianças
Preparar ambiente, equipamentos e materiais
Testar o teste
Realizar os testes. Para cada teste:
§ Preparar o ambiente e os observadores
§ Cumprimentar e apresentar
§ Falar Script de orientação
§ Aplicar Entrevista com crianças
§ Aplicar Pré-teste com crianças
§ Conduzir o teste (ler tarefas, observar e coletar
Realização dos testes dados)
§ Aplicar Pós-testes com crianças
§ Aplicar Questionário com crianças
§ Agradecer e gratificar as crianças
§ Organizar dados e papéis
§ Fazer acertos no teste
Assistir às filmagens
Transcrever e resumir dados
Análise de dados e Produção do
Relatório final de avaliação Verificar heurísticas qualitativamente
Verificar heurísticas quantitativamente
Produzir recomendações e resultados
235
Anexo XII: Artefatos
Nome Descrição
Reconhecimento do Documento que descreve as funções e características
do software, servindo como referência para a produção
software
de outros documentos.
Proposta de Documento que estima prazos e custos para a
avaliação do realização da avaliação do software por meio de um
software cronograma.
Documento que descreve e serve como base para os
Plano de testes testes que serão realizados na avaliação, podendo ser
apresentado a todos os interessados.
Formulário de Documento que solicita autorização dos pais ou

consentimento responsáveis para a participação das crianças nos
testes.
Documento que serve como ferramenta de
Script de orientação comunicação entre condutor e crianças durante os
testes, explicando o teste para elas.
Entrevista com Documento que relaciona perguntas a serem
crianças conduzidas com as crianças sobre experiência, atitudes
e preferências antes da condução das tarefas do teste.
Documentos que descrevem um teste a ser aplicado
Pré e Pós-testes antes e após a condução das tarefas, visando a avaliar
e comparar a capacidade e o aprendizado das crianças
nos tópicos tratados no software.
Formulário de Documento que armazena todos os dados que foram
observação observados durante a interação das crianças com o
software.
Questionário com Documento que descreve perguntas a serem feitas e
crianças tópicos a serem discutidos com as crianças após a
condução das tarefas do teste.
Documento que descreve a seqüência de ações a
Lista de verificação serem realizadas durante um teste de avaliação do
software.
Documento de Documento que descreve os dados coletados nos
Resumo de dados testes de forma tabulada e resumida.
Relatório final de
Documento que descreve os resultados da avaliação do
avaliação do
software.
software
236
236
Anexo XIII: Relação entre fases, tarefas e artefatos utilizados ou produzidos
Nº Fase Tarefa Artefatos utilizados (insumos) Artefatos produzidos (resultados)
Entrevistar docentes da escola

Reconhecimento e
1 Proposta de Familiarizar com o software - Reconhecimento do software
-
avaliação do Registrar anotações sobre o software - Proposta de avaliação do software
Software
Estimar prazos e custos
Personalizar a metodologia
Preparar o Plano de testes - Plano de testes
- Formulário de consentimento
Preparar todos os documentos necessários - Script de orientação
Planejamento dos Preparar Lista de verificação - Reconhecimento do software - Entrevista com crianças
2
testes Selecionar crianças - Proposta de avaliação do software - Pré e Pós-testes
- Formulário de observação
Preparar ambiente, equipamentos e
- Questionário com crianças
materiais
- Lista de verificação
Testar o teste
Realizar os testes - Plano de testes
- Formulário de consentimento
- Script de orientação
Realização dos - Entrevista com crianças
3
testes - Pré e Pós-testes
- Formulário de observação
- Questionário com crianças
- Lista de verificação
Assistir às filmagens - Proposta de avaliação do software
Análise de dados e - Plano de testes
Produção do Transcrever e resumir dados - Entrevista com crianças - Resumo de dados
4 Verificar heurísticas qualitativamente
Relatório final de - Pré e Pós-testes - Relatório final de avaliação
avaliação Verificar heurísticas quantitativamente - Formulário de observação
Produzir recomendações e resultados - Questionário com crianças
237
Anexo XIV: Heurísticas
Pertinência em relação a uma proposta pedagógica
Utilização de recursos computacionais
Avaliação da aprendizagem
Reconhecimento no lugar de memorização
Qualidade das opções de ajuda

Interação
Legibilidade
Feedback
Agrupamento e distinção de itens
Flexibilidade
Adaptabilidade Nível de experiência com o software ou com computadores
Ambiente cooperativo
H Acesso
E
Saída
U Controle e autonomia do usuário
R
Pausa
Í
S Desfazer uma ação
T Recursos motivacionais
I
C Prevenção de erros
Gestão de erros
A
S Auxílio no reconhecimento, no diagnóstico e na recuperação de erros
Carga informacional
Carga de trabalho
Brevidade
Conteúdo
Significado de códigos e denominações
Correspondência entre o software e o mundo real Correspondência com outros programas similares
Documentação de descrição do produto (para docentes/pais)

Documentação
Documentação de uso do software
Documentação de uso do software direcionada a docentes/pais
(aspectos pedagógicos, instalação
e regras)
Documentação de uso do software

direcionada a crianças (regras)
238

Metodologia - Aval de Qualidade - Soft

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologia - Aval de Qualidade - Soft

Enviado por

Direitos autorais:

Formatos disponíveis

Ana Paula Ribeiro Atayde

Orientador: Clarindo Isaías Pereira da Silva e Pádua

Metodologia de Avaliação de Qualidade de

Dissertação apresentada ao Curso de Pós-

Agradeço imensamente a todos os que, com palavras, gestos e ações,

Ao meu orientador, Clarindo Isaías Pereira da Silva e Pádua, pelo

À minha co-orientadora, Adla Betsaida Martins Teixeira, pelas indicações de

Aos também membros da banca, Antônio Otávio Fernandes, pelo

A todas as crianças que participaram dos testes e aos pais, que as

Às instituições Magnum Agostiniano, Rede Coleguium de Ensino, Hilda

Ao grupo de estudos de Usabilidade Gestus, em especial a Daniel Freitas (e

A Henderson V. Oliveira, que contribuiu, por meio da utilização da

À Litany França Diniz, pela amizade eterna;

A todos os meus colegas de trabalho do DCC, em especial a Claúdia, Cida,

A Antônio Mendes, pelos auxílios e compreensões no trabalho;

À Luana, pelo companheirismo e pelo carinho em todos os momentos;

A Vitor Dantas de Andrade, por toda a compreensão e pela paciência, pelas

Mais uma vez, obrigada a todos!

Este trabalho apresenta uma Metodologia para Avaliação da Qualidade de

Palavras-chave: Metodologia, avaliação, qualidade, avaliador, usabilidade, objetivos

This study presents a methodology for quality evaluation of children’s

Key words: methodology, quality, evaluation, evaluator, Usability, pedagogical

FIGURA 1 − EXEMPLO DE AVALIAÇÃO EM PAPEL .............................................................................................................22

1.1. OBJETIVOS DO TRABALHO ......................................................................................................................................1

2.1. TECNOLOGIA E EDUCAÇÃO ....................................................................................................................................7

3. DEFINIÇÃO DA METODOLOGIA ........................................................................... 41

3.1. INTRODUÇÃO ...........................................................................................................................................................41

4.1. INTRODUÇÃO ...........................................................................................................................................................67

5.1. INTRODUÇÃO ........................................................................................................................................................ 128

6. REALIZANDO A AVALIAÇÃO DE SOFTWARE EDUCACIONA INFANTIL – O

6.1. INTRODUÇÃO ........................................................................................................................................................ 149

7.1. INTRODUÇÃO ........................................................................................................................................................ 157

8.1. D ISCUSSÕES SOBRE A MAQSEI ..................................................................................................................... 190

ANEXO I: PADRÃO PARA DOCUMENTO DE RECONHECIMENTO DO

ANEXO II: PADRÃO PARA DOCUMENTO DE PROPOSTA DE AVALIAÇÃO DE

PROPOSTA DE AVALIAÇÃO DO SOFTWARE <NOME DO SOFTWARE>.........206

ANEXO III: PADRÃO PARA DOCUMENTO DE PLANO DE TESTES....................207

ANEXO III: PADRÃO PARA DOCUMENTO DE PLANO DE TESTES....................207

ANEXO IV: PADRÃO PARA DOCUMENTO DE PRÉ-TESTE E PÓS-TESTE.......210

ANEXO V: PADRÃO PARA FORMULÁRIO DE OBSERVAÇÃO ............................211

ANEXO VI: PADRÃO PARA QUESTIONÁRIO COM CRIANÇAS ...........................212

ANEXO VII: PADRÃO PARA DOCUMENTO DE RESUMO DE DADOS ................214

ANEXO VIII: PADRÃO PARA DOCUMENTO DE RELATÓRIO FINAL DE

ANEXO IX: ENTREVISTA COM DOCENTES...............................................................229

ANEXO XI : TAREFAS ......................................................................................................235

ANEXO XII: ARTEFATOS ................................................................................................236

ANEXO XIII: RELAÇÃO ENTRE FASES, TAREFAS E ARTEFATOS UTILIZADOS

ANEXO XIV: HEURÍSTICAS............................................................................................238

1.1. Objetivos do trabalho

O objetivo principal deste trabalho é elaborar uma Metodologia de Avaliação

Também são objetivos deste trabalho:

§ A apresentação de padrões para a metodologia que orientem e concorram para a

§ Produção das heurísticas pedagógicas e de Usabilidade para o desenvolvedor ou

§ Consideração do custo da avaliação de um software educacional infantil;

§ Produção de recomendações de conduta, perfil e habilidades necessárias para

Todos esses objetivos convergem para o desejo comum de que a informática

Segundo DRUIN (1999), apenas recentemente o desenvolvimento de

O uso de ambientes informatizados nas escolas não é suficiente para

Grande parte dos materiais informáticos educacionais existentes no mercado,

BRANDÃO (1998) elenca importantes questões sobre a seleção de software

Segundo CAMPOS (1994), pouco se avançou quanto a procedimentos

No Brasil, pouco se investiu na produção de software que atenda às

1.3. Visão geral da pesquisa