GList

UNIVERSIDADE DO SUL DE SANTA CATARINA
RAFAEL ORIVALDO LESSA
Glist Um Checklist Automatizado para Usabilidade
Palhoa(SC)
2006
Monografia submetida Universidade do

Sul de Santa Catarina como requisito
parcial obteno do titulo de Bacharel
em Sistemas de Informao, orientado
pela professora Vera Rejane Niedersberg
Schuhmacher.
Orientadora Vera Rejane Niedersberg Schuhmacher
Palhoa(SC)
2006
Monografia submetida Universidade do

Sul de Santa Catarina como requisito parcial
obteno do titulo de Bacharel em Sistemas de
Informao, orientado pela professora Vera
Rejane Niedersberg Schuhmacher
Universidade do Sul de Santa Catarina
Palhoa, de Junho de 2006.
____________________________________
Msc. Vera Rejane Niedersberg Schuhmacher
____________________________________
Dr. Mauro Notarnicola Madeira
____________________________________
Msc. Flavia Lumi Matuzawa
DEDICATRIAS
Aos meus pais, meu irmo, que me apoiaram,
deram fora e foram compreensivos no perodo
em que estive envolvido com este projeto.
AGRADECIMENTOS
Primeiramente a Deus pela oportunidade mpar
de conceber-nos a vida e iluminar-me nesta
longnqua caminhada em busca do saber.
Aos meus pais Edson e Sandra por tudo o que
fizeram ou deixaram de fazer por minha causa e
por ter-me dado oportunidade de aqui chegar.
minha querida orientadora, professora Vera R.
N. Schuhmacher, por ter aceitado me guiar na
definio e conduo deste trabalho, na
transmisso do seu conhecimento e pela
compreenso nos momentos difceis.
Ao meu irmo Edson Orivaldo Lessa Jnior, pela
contribuio atravs da sua experincia em
desenvolvimento
de
sistemas,
e
pelo
investimento de se tempo em prol deste.
minha namorada Isabel Cristina Hammes que
mesmo estando passando por uma fase difcil de
sua vida me compreendeu nos momentos de
ausncia e pelo apoio, carinho e consolo nas
ocasies de desespero. E aos seus pais, pela fora
dada e pelas oraes em busca de luz e sucesso.
A professora Maria Ins Castieira pelas horas
de conversas, dicas e conselhos.
Aos meus amigos que, mesmo de longe, sempre
estiveram preocupados e interessados em saber
como estava o andamento deste.
Aos meus parentes: tias, tios pelo incentivo e
interesse em saber do andamento do trabalho.
A todas as pessoas que de alguma forma
contriburam para que mais este degrau de minha
vida fosse alcanado.
A todos, o meu muito obrigado!
RESUMO
A usabilidade busca apoiar o processo de interao com o usurio, transmitindo de

forma eficaz e eficiente a interao do usurio com a interface de um sistema computacional.
Pode ser composta por mltiplos componentes estando tradicionalmente associada a atributos
como: facilidade de aprendizagem do sistema; eficincia de uso; capacidade com que o
sistema promove a facilidade de memorizao das aes necessrias para que o usurio atinja
seus objetivos; controle de gesto de erros minimizando e refutando situaes possveis de
ocorrncias; e principalmente promovendo a satisfao do usurio ao ser utilizado. Com o
crescimento da tecnologia a usabilidade comeou a ser fonte de preocupao, uma vez que,
com um mercado to dependente da tecnologia precisamos de produtos que sejam fceis de
aprender e utilizar. O presente projeto tem por objetivo o estudo da usabilidade para interfaces
e o desenvolvimento de uma ferramenta automatizada de avaliao que oferea apoio
usabilidade no design de projetos, para desenvolvedores que necessitam de apoio na avaliao
de interfaces. A avaliao da usabilidade de um produto de software no uma garantia
absoluta da qualidade do produto, mas com certeza um fator que em sua ausncia produz um
alto grau de rejeio por parte dos usurios.
Palavras-chave: usabilidade, checklist, avaliao de usabilidade.
ABSTRACT
The usability aims to support the process of interaction with the user in an effective and
efficient way between the user and the interface of a computational system. It can be
composed by multiple components being traditionally associated with attributes such as:
learnability; efficiency in use; capacity that the system promotes the rememberability of the
necessary actions so that the user reaches his or her objectives; control of management of
errors minimizing and refuting situations that might occur; and mainly promoting the
satisfaction of the user whenever he or she uses it. With the growth of technology, usability
started to be a concerning issue, since, due to a market which highly depends on technology,
we need products that are easy to both learn and use. The present project aims at the study of
the usability for interfaces and the development of an automatized tool of evaluation that
offers support to the usability in designing of projects, for developers who need support in the
evaluation of interfaces. The evaluation of the usability of a software product is not an
absolute guarantee of the product quality, but it certainly is a factor that in its absence
produces a high degree of rejection from the users.
Keywords: usability, checklist, usability evaluation.
LISTA DE FIGURAS
Figura 1: Proposta de metodologia de soluo......................................................................... 16
Figura 2: Atores do Sistema ..................................................................................................... 51
Figura 3: Caso de uso geral ...................................................................................................... 53
Figura 4: Digrama de Robustez (Gerncia de Projeto)............................................................. 58
Figura 5: Digrama de Robustez (Gerncia de Categorias) ....................................................... 59
Figura 6: Digrama de Robustez (Gerncia de recomendaes) ............................................... 60
Figura 7: Digrama de Robustez (Gerncia de testes) ............................................................... 61
Figura 8: Diagrama de Atividades Gerncia de Projeto ........................................................ 63
Figura 9: Diagrama de Atividades Gerncia de Categorias .................................................. 64
Figura 10: Diagrama de Atividades Gerncia de Recomendaes........................................ 65
Figura 11: Diagrama de Atividades Gerncia de Testes ....................................................... 66
Figura 12: Diagrama de Classes de Interfaces.......................................................................... 68
Figura 13: Digrama de Classes Persistentes ............................................................................. 69
Figura 14: Digrama de Classes Persistentes ............................................................................. 70
Figura 15: Tela do sistema Ergolist.......................................................................................... 73
Figura 16: Tela do do sistema Ergolist..................................................................................... 74
Figura 17: Tecnologias utilizadas............................................................................................. 78
Figura 18: Pgina inicial........................................................................................................... 80
Figura 19: Cadastro de categorias ............................................................................................ 81
Figura 20: Cadastro de recomendaes .................................................................................... 82
Figura 21: Cadastro de projetos................................................................................................ 83
Figura 22: Associao de recomendaes ................................................................................ 84
Figura 23: Alterao e excluso de categorias ......................................................................... 85
Figura 24: Alterao de categoria............................................................................................. 86
Figura 25: Alterao e excluso de recomendaes................................................................. 87
Figura 26: Alterao de recomendao .................................................................................... 88
Figura 27: Alterao e excluso de projetos............................................................................. 89
Figura 28: Alterao de projeto ................................................................................................ 89
Figura 29: Avaliao ................................................................................................................ 90
Figura 30: Relatrio de avaliao............................................................................................. 92
Figura 31: Pgina inicial, Mdulo Avaliao........................................................................... 94
Figura 32: Validao do sistema .............................................................................................. 95
Figura 33: Validao do sistema 2 ........................................................................................... 95
LISTA DE QUADROS
Quadro 1: Descrio de componentes ...................................................................................... 16
Quadro 2: Atores do sistema .................................................................................................... 51
Quadro 3: Casos de uso do sistema .......................................................................................... 53
Quadro 4: Gerncia de Projetos................................................................................................ 54
Quadro 5: Gerncia de Categorias............................................................................................ 55
Quadro 6: Gerncia de recomendaes .................................................................................... 56
Quadro 7: Gerncia de Teste .................................................................................................... 57
Quadro 8: Tecnologias utilizadas ............................................................................................. 78
Quadro 9: Grau de impacto ...................................................................................................... 85
Quadro 10: Critrio para avaliao........................................................................................... 90
LISTA DE SIGLAS
ABNT (Associao Brasileira de Normas Tcnicas)

ANSI (American National Standards Institute)
CSS (Cascading Style Sheets)
DHTML: (unio das tecnologias HTML e Javascript)
HTML: (Hypertext Markup Language)
HTTP: (HyperText Transfer ProtocolI)
IEEE (Institute of Electrical and Electronics Engineers)
ISO (International Organization for Standardization)
PDF (Portable Document Format)
PHP (Hypertext Preprocessor)
SGBD: (Sistema de Gerncia de Banco de Dados)
SQL: (Structured Query Language)
URL: (Uniform Resource Locator)
UML: (Unified Modeling Language)
XHTML: (eXtensible Hypertext Markup Language)
W3C (The World Wide Web Consortium)
SUMRIO
1. INTRODUO.................................................................................................................... 12
1.1 O Problema ................................................................................................................... 13
1.2 Justificativa ................................................................................................................... 14
1.3 Objetivos........................................................................................................................ 14
1.3.1 Geral ........................................................................................................................ 14
1.3.2 Especficos............................................................................................................... 15
1.4 Arquitetura da Soluo................................................................................................ 15
1.4.1 Descrio dos Componentes da Arquitetura da Soluo do Problema .................. 16
1.5 Delimitao.................................................................................................................... 17
1.6 Metodologia Cientfica ................................................................................................. 17
1.7 Estrutura da Monografia............................................................................................. 18
2. USABILIDADE ................................................................................................................... 20
2.1 Tcnicas de avaliao ................................................................................................... 24
2.1.1 Preditivas ou analticas ............................................................................................ 25
2.1.2 Objetivas ou empricas ............................................................................................ 27
2.1.3 Prospectivas ............................................................................................................. 28
2.1.4 Mtodos de inspeo ............................................................................................... 28
2.1.5 Mtodos de teste com usurios................................................................................ 32
2.1.6 A escolha da tcnica mais adequada ....................................................................... 34
2.2 Checklist......................................................................................................................... 37
2.3 A formao do contedo de um checklist ................................................................... 38
2.3.1 As Recomendaes do W3C ................................................................................... 38
2.3.2 Heurstica 1: Visibilidade e reconhecimento do estado ou contexto atual, e
conduo do usurio. ........................................................................................................ 39
2.3.3 Heurstica 2 - Projeto esttico e minimalista. .......................................................... 40
2.3.4 Heurstica 3 - Controle do usurio........................................................................... 41
2.3.5 Heurstica 4 - Flexibilidade e eficincia de uso....................................................... 42
2.3.6 Heurstica 5 - Preveno de erros ............................................................................ 43
2.3.7 Heurstica 6 Consistncia ..................................................................................... 44
2.3.8 Heurstica 7 - Compatibilidade com o contexto ...................................................... 45
2.4 Ergolist........................................................................................................................... 46
2.5 Concluso ...................................................................................................................... 48
3. UML ..................................................................................................................................... 50
3.1 Atores............................................................................................................................. 50
3.2 Casos de Uso.................................................................................................................. 52
3.2.1 CSU001 Gerncia de Projetos ................................................................................. 54
3.2.2 CSU002 Gerncia de Categorias ............................................................................. 54
3.2.3 CSU003 Gerncia de recomendaes...................................................................... 55
3.2.4 CSU004 Gerncia de Teste ..................................................................................... 56

3.2.1.1 Diagrama de classes de anlise (Gerncia de Projeto) ......................................... 57
3.2.2.1 Diagrama de classes de anlise (Gerncia de Categoria) ..................................... 58
3.2.3.1 Diagrama de classes de anlise (Gerncia de Recomendaes)........................... 59
3.2.4.1 Diagrama de classes de anlise (Gerncia de teste) ............................................. 60
3.3 Diagrama de atividades................................................................................................ 61
3.3.1 Gerncia de Projeto ................................................................................................. 62
3.3.2 Gerncia de Categorias............................................................................................ 63
3.3.3 Gerncia de Recomendaes ................................................................................... 65
3.3.4 Gerncia de testes .................................................................................................... 66
3.4 Diagrama de Classes de Interfaces.............................................................................. 67
3.5 Diagrama de Classes Persistentes ............................................................................... 68
3.6 Concluso ...................................................................................................................... 70
4 DESENVOLVIMENTO E VALIDAO ........................................................................... 72
4.1 A Coleta de Informaes.............................................................................................. 72
4.2 Anlise de softwares existentes.................................................................................... 73
4.3 Histrico do Desenvolvimento ..................................................................................... 74
4.4 Apresentao do sistema .............................................................................................. 79
4.4.1 Mdulo Gerncia ..................................................................................................... 79
4.4.2 Mdulo Avaliao ................................................................................................... 89
4.5 Validao ....................................................................................................................... 92
4.5.1 Validao de usabilidade ......................................................................................... 92
4.5.2 Validao das funcionalidades ................................................................................ 93
4.6 Concluso ...................................................................................................................... 96
5 CONCLUSO ....................................................................................................................... 97
REFERNCIAS ...................................................................................................................... 99
12
1. INTRODUO
No nenhuma novidade dizer que a internet revolucionou o mundo, quando

permitiu a comunicao entre vrios usurios alm de se tornar a maior rede de informaes
da atualidade.
Com o crescimento da internet comearam a ser oferecidos os mais variados
servios relacionados ao novo mercado, como home page pessoal, sites de comrcio
eletrnico, sites de busca, de entretenimento, institucionais entre muitos outros.
O nmero de domnios, que o nome de uma rea reservada num servidor
Internet que corresponde ao endereo numrico de um website, cadastrados no mundo chega a
impressionante cifra de 82,9 milhes segundo uma pesquisa feita pelo site domaines.info
(2005).
Atrelado a este crescimento comeam a surgir os problemas na utilizao desta
tecnologia. Antes do advento da internet milhares de usurios j padeciam pelo projeto
comprometido das interfaces de seus sistemas, com o uso da rede de informaes pela internet
este problema piorou e tornou-se globalizado.
A usabilidade busca ajudar o processo de interao com o usurio, pois visa
transmitir de forma eficaz e eficiente a interao do usurio com a interface e comea a ser
fonte de preocupao, uma vez que com um mercado to dependente da tecnologia
precisamos de produtos que sejam fceis de aprender e utilizar.
13
Nielsen (1998) definiu usabilidade como uma medida da qualidade da experincia

do usurio ao interagir com alguma coisa - seja um site na Internet, um aplicativo de software
tradicional, ou outro dispositivo que o usurio possa operar de alguma forma.
Apesar de a usabilidade ter surgido no incio da dcada de 80 poucos so os
esforos que permitem disseminar este conhecimento. Conjuntos de recomendaes, normas e
guidelines dificilmente chegam ao conhecimento do projetista de interfaces.
1.1 O Problema
Com a dependncia de tecnologia do mercado, os produtos desenvolvidos so

cada vez mais complexos e difceis. O usurio encontra uma grande dificuldade de interao
com a interface tendo dificuldade em resolver problemas que de certa forma seriam simples se
a interface fosse bem projetada.
H muito tempo so publicadas recomendaes sobre a usabilidade da interface,
mas aplicar estas recomendaes exige do avaliador o conhecimento do especialista em
usabilidade. O processo para fazer uma avaliao caro e depende da competncia no assunto
do avaliador. As recomendaes na forma de listas ou mesmo checklist so normalmente
genricas, em outras palavras o checklist que oferecido poderia ser aplicado em um software
educacional ou mesmo em um produto desenvolvido para automao comercial. Mas cada
segmento de software possui caractersticas prprias e que no sero provavelmente
abordadas durante a avaliao tendo em vista a generalidade da proposta. Nestes casos a
avaliao, mesmo sua eficincia, comprometida, pois os grandes problemas podem residir
exatamente nos detalhes do produto relacionados ao escopo do software.
14
Outro problema que a maioria dos checklists disponveis manual, no

objetivando seu relatrio de aplicao, ficando isto a critrio do avaliador que pode ou no ter
experincia em sua aplicao.
1.2 Justificativa
Este projeto se justifica pela possibilidade de oferecer aos desenvolvedores uma

ferramenta que ir permitir uma avaliao eficiente dos requisitos de usabilidade de interface,
de forma a melhorar a interao do usurio final.
Por outro lado ser possvel a um usurio no especialista aplicar o checklist com
grandes chances de sucesso. O uso de recomendaes voltadas ao tipo de produto deve gerar
um maior grau de alcance nos problemas apresentados, uma vez que poder ser especfico
para o tipo de produto.
Outra questo importante o custo desta avaliao. O mesmo deve ser acessvel,
uma vez que o desenvolvedor mesmo no tendo o conhecimento sobre o assunto, estar
fazendo uso de uma base de recomendaes compiladas para o produto em questo.
Um ponto a salientar que a avaliao na forma de um relatrio, servir como
resultado desta etapa de testes e balizamento para futuras melhorias no projeto.
1.3 Objetivos
A seguir so descritos os objetivos do projeto.
1.3.1 Geral
15
Desenvolvimento de um checklist automatizado para avaliao de usabilidade.
1.3.2 Especficos
Os objetivos especficos deste trabalho so apresentados abaixo:

1. Prover o aprofundamento nos estudos na rea de usabilidade;
2. Apoiar a avaliao de interfaces com foco na usabilidade;
3. Possibilitar que um usurio leigo em usabilidade realize uma avaliao de
usabilidade por meio de uma ferramenta checklist;
4. Diminuir o custo da avaliao por meio do checklis;
5. Possibilitar o uso de um checklist especializado para cada tipo de produto.
1.4 Arquitetura da Soluo
A proposta de soluo apresenta uma ferramenta de apoio a avaliao em

usabilidade, viabilizada a partir de estudos aprofundados e que corresponda s necessidades
existentes no mercado na forma de um checklist.
As figuras abaixo representam soluo arquitetural do problema.
16
Figura 1: Proposta de metodologia de soluo

Fonte: autor do projeto
A arquitetura apresentada mostra de forma simplificada o processo de

funcionamento e utilizao do GLIST.
O GLIST est disponibilizado na Web. Pesquisadores e especialistas na rea (com
permisso para tal) podem fazer a insero de dados no sistema formando a base de
recomendaes que armazenada num banco de dados. Desenvolvedores podem acessar o
sistema atravs da Web e por meio do checklist realizar uma avaliao eficiente e segura. O
GLIST deve est disponvel para qualquer usurio inclusive no especialista proporcionandolhes a possibilidade de avaliar seu produto.
1.4.1 Descrio dos Componentes da Arquitetura da Soluo do Problema
A seguir sero apresentados os componentes da arquitetura:
Componente
Base de Dados
Quadro 1: Descrio de componentes

Fonte: Autor do projeto
Detalhamento
Responsvel pela manuteno e armazenamento dos dados do sistema
17
GLIST
Pesquisador
Usurio Comum
Especialista
Desenvolvedor
Checklist automatizado
Responsvel pela alimentao de dados na base do sistema
Usurio final do checklist sendo sua habilidade exclusivamente
relacionada s tarefas do seu trabalho na empresa.
Usurio que utilizara o GLIST para avaliar as suas interfaces.
Programador ou Analista de sistemas sem conhecimento de usabilidade.
1.5 Delimitao
Este trabalho apresenta as seguintes delimitaes decorrentes:

O desenvolvimento da ferramenta deve ser sobre uma arquitetura open source;
A base de dados ser populada a partir de outros projetos, sendo que este
projeto no prev a pesquisa de recomendaes para popular base de dados;
A ferramenta ser desenvolvida para ser utilizada a partir da internet sendo
disponibilizada ao pblico em geral.
1.6 Metodologia Cientfica
O delineamento da pesquisa quanto ao tipo, segundo a Universidade do Sul de

Santa Catarina (2003, p. 41) [...] consiste em informar qual o desenho que a pesquisa ter, ou
seja, se a pesquisa ser bibliogrfica, ou descritiva, ou experimental, ou estudo de caso, ou
documental, etc..
O estudo desenvolvido neste projeto considerado, do ponto de vista da sua
natureza, uma aplicao prtica a fim de conduzir soluo de um problema especfico. Pela
forma de abordagem do problema classifica-se como uma pesquisa qualitativa, que consiste
pelo pesquisador sendo o instrumento chave da pesquisa. Ressaltando os aspectos
relacionados aos objetivos, considerada exploratrio, tendo em vista a utilizao de estudos
18
de caso e pesquisa bibliogrfica. Pelos procedimentos tcnicos classifica-se como uma

pesquisa bibliogrfica.
1.7 Estrutura da Monografia
Este projeto est subdividido em 5 captulos. A seguir, ser apresentada a

estrutura deste trabalho:
Captulo 1 - Introduo
Este captulo apresenta a introduo, justificativa, objetivos, problemas e a

soluo proposta como trabalho.
Captulo 2 Usabilidade
Foi desenvolvido neste captulo o domnio do problema relacionado
usabilidade e a testes em usabilidade.
Captulo 3 Modelagem
Esto descritos neste captulo os passos realizados durante a modelagem,
apresentando grficos e descries necessrias para a compreenso do sistema.
Captulo 4 Desenvolvimento e Validao
Contem a descrio dos passos que tornaram possvel a implementao do
prottipo bem como os resultados de sua validao.
Captulo 5 Concluso
19
Neste captulo esto apresentadas as concluses e consideraes sobre a

monografia.
20
2. USABILIDADE
A usabilidade definida como a capacidade que um sistema interativo oferece a
seu usurio, em um determinado contexto de operao, para a realizao de tarefas, de
maneira eficaz, eficiente e agradvel (ISO 9241, 1993).
No se pode falar em usabilidade sem pensar na forma como as pessoas se
comunicam e o impacto que um sistema tem para estes indivduos.
Um sistema que ajuda o usurio na conduo de sua tarefa faz com que o
indivduo realize o seu trabalho com mais eficincia, produtividade e satisfao. importante
que o usurio tenha satisfao ao trabalhar com o sistema, assim s pessoas se sentiro bem
em utiliz-lo.
Constantine e Lockwood (et all, 1999) define cinco aspectos fundamentais para a
construo da usabilidade:
o Facilidade na aprendizagem;
o Facilidade de memorizao;
o Eficincia no uso;
o Confiabilidade no uso;
o Satisfao do usurio;
21
Tais caractersticas podem ser vistas como cinco faces da usabilidade, onde se tem
aspectos diferentes do sistema e da sua relao de usurio que juntos contribuem para a
promoo da usabilidade.
No entanto Nielsen (1999) disponibilizou alguns princpios genricos de
usabilidade que so regras gerais para descrever propriedades comuns de interfaces
utilizveis. So eles:
o Visibilidade do estado do sistema o sistema deve manter o usurio sempre
informado sobre o que est acontecendo, por meio de feedbacks apropriados dentro de
um tempo razovel.
o Compatibilidade entre o Sistema e o Mundo real o sistema deve falar o idioma do
usurio, com palavras, frases e conceitos familiares ao usurio. Deve fazer com que a
informao aparea em uma ordem lgica e natural.
o Controle e liberdade do usurio freqentemente o usurio escolhe funes ou
seleciona opes por engano, neste caso necessrio oferecer uma sada de
emergncia, para deixar o estado no desejado sem ter que passar por um dilogo
muito longo. Opes que permitam desfazer ou fazer novamente, cancelar, limpar
tornam o dilogo menos traumtico.
o Consistncia e padro o usurio no deve encontrar palavras, situaes ou aes
diferentes que significam a mesma coisa.
o Preveno de erros boas mensagens e um projeto bem avaliado impedem que um
problema acontea.
o Reconhecimento torna os objetos, aes e opes visveis. O usurio no deve
lembrar-se da mesma informao de uma parte do dilogo para outro, As instrues
devem ser visveis e recuperveis.
22
o Flexibilidade permite o uso de aceleradores de aes. O boto de busca pode

minimizar o tempo de busca de um produto em um site.
o Projeto esttico informaes irrelevantes ao contedo do site devem ser evitadas.
Informaes desnecessrias tiram ateno do usurio de informaes pertinentes.
o Ajuda ao reconhecimento, diagnstico e recuperao de erros mensagens de erro
devem ser expressas em linguagem clara, indicando o problema e propondo uma
soluo.
o Ajuda e documentao oferecer ajuda e documentao fundamental em sites
complexos. Todas as informaes devem ser de fcil acesso e sua apresentao focada
na tarefa de forma concreta e sucinta.
Cybis (2005) define que a usabilidade depende do contexto em que um sistema
operado.
Assim, um sistema pode proporcionar boa usabilidade para um usurio experiente,
mas pssima para novatos, ou vice e versa. Pode ser fcil de operar uma vez l que
outra, mas difcil, se for utilizado no dia a dia. Pode dar prazer se acessado por
conexes rpidas, mas causar ansiedade insuportvel se acessado de casa. Martin
Maguire, em seu artigo publicado em 2001, fala das inter-relaes entre contexto de
operao e usabilidade e da necessidade de especificar o contexto de uso para o qual
uma
interface
est
sendo
concebida,
no
qual
ela
ser
testada.
Mas como conceber algo amigvel em tantas situaes diferentes? A adaptabilidade

uma das boas qualidades de uma interface com o usurio. Isto permitir que
diferentes usurios, em diferentes estgios de competncia, em diferentes tarefas e
em diferentes ambientes fsicos tecnolgicos e organizacionais, possam alcanar
seus objetivos com eficcia, eficincia e satisfao.
Hix (1993) defende que o desenvolvimento de um sistema interativo deve contar

com trs grupos de profissionais integrados:
a) especialistas no domnio do problema: pessoas que possuem um profundo

conhecimento da rea que a aplicao interativa pretende suportar;
23
b) projetistas de software de interface: profissionais da rea de informtica, projetistas

de software, engenheiros de software e programadores;
c) projetistas de interao com usurio: usurios, projetistas de interao, avaliadores,

e especialistas em fatores humanos e em documentao.
Browne (1992) chama a ateno para o fato de que, atualmente, os sistemas tm

sido projetados, desenvolvidos e testados principalmente em relao as suas funcionalidades:
tal filosofia de projeto garante que o software atenda aos requisitos funcionais, mas no
garante que seja utilizvel pelos usurios pretendidos.
Uma interface com as seguintes caractersticas tem grandes possibilidades de
possuir problemas de usabilidade afirma Hix (1993), as caractersticas so: a interface ser
projetada por pessoal de software e no por especialista em interface homem-computador, ser
desenvolvida por decomposio funcional estritamente top-down, no ser desenvolvida para
atender especificaes de usabilidade documentadas e mensurveis, no ser desenvolvida
como foi prototipada, no ser desenvolvida atravs de um processo de refinamentos
interativos e no ser avaliada empiricamente.
Os problemas de usabilidade das interfaces so conseqncias diretas de algumas
caractersticas dos projetistas. Tais como, carecer de conhecimento as tarefas de usurio,
carecer uma metodologia de concepo para interface homem computador, conhecer o
software segundo orientao funcional e no operacional, no prever erros humanos, no
avaliar com preciso as transaes de dilogo combinatrio, homogeneidade na concepo,
considerar o computador como um fim em si mesmo. (SCAPIN, 1986)
Fisher (1989) afirma que o software de hoje to complexo que tcnicas
melhores de comunicao so uma necessidade, e no um luxo.
24
Segundo Hix (1993) a interao homem-computador deve constituir-se como uma

parte integrante da engenharia de software. Em concordncia com esta leria, De Waal (1990)
diz que de grande importncia que o conhecimento e o saber desenvolvidos por
ergonomistas e psiclogos cognitivos sejam embutidos no processo de projetar interfaces.
2.1 Tcnicas de avaliao
Segundo Dix (1993) a avaliao de usabilidade tem trs objetivos principais:

avaliar a extenso das funcionalidades do sistema, avaliar os efeitos da interface dos usurios
(facilidade de aprendizagem, facilidade e eficincia de uso e efetivo suporte a tarefa) e
identificar problemas especficos de usabilidade.
Antes de comear uma avaliao de usabilidade, devemos saber algo sobre a
interface do software, para poder analisar a relao entre software e usurio. No necessrio
saber tudo, mas preciso saber a resposta a poucas perguntas bsicas:
o O que os usurios pretendem realizar?
o Como o sistema ir suprir as necessidades do usurio?
Para desenvolver um sistema que evolui atravs de novas atualizaes ou novas
verses, interessante saber a resposta de algumas perguntas adicionais.
o O que o sistema no est realizando e ineficaz?
o Como o sistema poderia ser feito para ser mais eficiente no suporte
utilizado?
As respostas a essas perguntas podem ser procuradas de vrias maneias,
principalmente com o cliente. (CONSTANTINE e LOCKWOOD et all, 1999).
Para Nilsen (1993) um mtodo de avaliao visa encontrar problemas de
usabilidade. Um problema de usabilidade um aspecto do sistema e/ou da demanda sobre o
25
usurio, que torna o sistema ineficiente, difcil de usar ou impossvel de ser operado pelo
usurio.
Segundo Luzzardi (2003) a avaliao permite:
(a) constatar, observar e registrar problemas efetivos de usabilidade
durante a interao; (b) calcular mtricas objetivas para eficcia, eficincia e
produtividade do usurio na interao com o sistema; (c) diagnosticar as
caractersticas do projeto que provavelmente atrapalham a interao por estarem em
desconformidade com padres implcitos e explcitos de usabilidade; (d) prever
dificuldades de aprendizado na operao do sistema; (e) prever os tempos de
execuo de tarefas informatizadas; (f) conhecer a opinio do usurio em relao ao
sistema e (g) sugerir as aes de re-projeto mais evidentes face aos problemas de
interao efetivos ou diagnosticados.
Durante a ltima dcada, a utilizao de um grande nmero de mtodos de
avaliao de usabilidade tornou o planejamento de um projeto mais curto e mais
barato. Geralmente, o esforo e o custo envolvido no teste com usurios reais tem
sido visto pela comunidade de desenvolvimento como muito proveitoso no
desenvolvimento de um novo software.
Rubin (1994) distingue trs tipos de tcnicas para avaliao de interfaces grficas.
So elas preditivas, objetivas e prospectivas.
2.1.1 Preditivas ou analticas
Rubin (1994) afirma que as tcnicas preditivas buscam prever os erros de projeto
de interfaces sem a participao direta de usurios, ou seja, baseada no conhecimento de um
especialista. As tcnicas deste tipo so:
o
Inspeo cognitiva - nesse mtodo de avaliao o analista desenvolve uma

tarefa especfica seguindo a lgica que um usurio teria para desenvolv-la.
Ele, ento, dever responder a um conjunto de questes para cada ao a fim
de observar se os princpios foram aplicados. Essas aes e o feedback so
comparados com os objetivos e conhecimentos do usurio e as discrepncias
entre as expectativas do mesmo e os passos seguidos pela interface so
26
percebidas, no apenas identificando os problemas, mas tambm sugerindo as

razes para os mesmos. A inspeo cognitiva um mtodo baseado na teoria
cognitiva em que analisado o processo mental do usurio. Esse mtodo que
pode ser realizado durante a construo do software, no requer especialistas
em cincia cognitiva ou experiente designer de interfaces, requer poucos
recursos, demanda pouco tempo e esforo de um prottipo do software.
o
Avaliao heurstica - um mtodo de inspeo sistemtico, cujo objetivo

identificar problemas de usabilidade que, posteriormente, sero analisados e
corrigidos ao longo do processo de desenvolvimento do sistema. realizada
atravs de aproximaes progressivas onde cada estgio do caminho
percorrido e avaliado e, ento, especula-se sobre a natureza dos caminhos a
seguir para se aproximar do objetivo de encontrar o maior nmero possvel de
problemas de usabilidade. Esse mtodo pode ser usado em qualquer estgio do
ciclo de desenvolvimento de um sistema interativo. Esse tipo de avaliao s
pode ser realizada por um especialista em interface. Depende da experincia do
especialista para fazer a avaliao.
Inspeo de conformidade - baseada na confrontao com princpios,

guidelines, recomendaes e normas (aplicao de checklists). O checklist
uma ferramenta para avaliao ergonmica de um software a qual verifica a
conformidade da interface de um sistema interativo com recomendaes
ergonmicas provenientes de pesquisas aplicadas. O checklist trata de aspectos
gerais de uma avaliao ou tambm oportuniza a focalizao de uma lista de
questes especficas e detalhadas que conduzem o avaliador durante o processo
de avaliao. Pode-se desenvolver verses personalizadas ou especializadas de
um checklist a partir de recomendaes genricas. O LabiUtil, Laboratrio de
27
Utilizabilidade da Universidade Federal de Santa Catarina, administra um

servio na Web chamado ErgoList que se constitui de uma base de
conhecimento em ergonomia associada a um checklist para inspeo
ergonmica de interfaces homem-computador.
2.1.2 Objetivas ou empricas
Rubin (1994) afirma que as tcnicas objetivas buscam constatar os problemas a

partir da observao do usurio interagindo com o sistema. Tais tcnicas podem ser de dois
tipos:
o
Sistemas de monitoramento - os sistemas de monitoramento visam uma

observao direta com os usurios. Estes sistemas so utilitrios e permanecem
residentes na mquina do usurio, juntamente ao aplicativo em teste (MS
Camcorder ou Lotus Scren Can). Sua finalidade registrar o usurio em seu
momento real de trabalho, assim observando todos os aspectos de interao do
usurio com o sistema. Existem pontos positivos neste sistema, pois mesmo
que os usurios saibam que esto participando, eles no ficam inibidos e em
contrapartida, no h a possibilidade de incentivar ou gravar verbalizaes dos
usurios. Esses sistemas so limitados tecnicamente em relao s ferramentas
de espionagem, pelo fato da diversidade de ambientes de programao. Para se
evitar dados em excesso, sugere-se que o tempo do teste seja bem planejado
pelos avaliadores.
Ensaios de interao - os ensaios de interao so testes realizados com os

usurios do sistema. uma simulao de uso do mesmo em que so
apresentadas algumas tarefas para o usurio realiz-las. Os mesmos so
28
acompanhados pelos avaliadores que analisaro os comandos dados, os erros

cometidos, e o comportamento do usurio. Os ensaios de interao identificam
problemas de interao de mais alto nvel, dificilmente identificados por outros
mtodos.
2.1.3 Prospectivas
Rubin (1994) afirma que as tcnicas prospectivas buscam a opinio do usurio

sobre a interao com o sistema atravs da aplicao de questionrios.
Para avaliar a usabilidade muitas vezes faz-se necessrio saber o seu real contexto
de uso. Para isso, deve ser feito o levantamento de informaes a respeito do usurio desta
interface, as tarefas a serem realizadas e o ambiente onde ocorre a interao entre usurio e
sistema. Para os instrumentos de coleta de dados so usados questionrios ou entrevistas.
Depois de terem sidos identificados os usurios tpicos, as tarefas tpicas e os

ambientes organizacionais, fsicos e tecnolgicos. O contexto de avaliao deve ser
compatvel com esse contexto de uso. O prximo passo identificar os mtodos de avaliao
de usabilidade mais adequados para o contexto analisado. O conjunto variado de mtodos
existentes na literatura pode ser subdividido em dois grandes grupos: mtodos de inspeo e
mtodos de teste com usurios.
2.1.4 Mtodos de inspeo
A classificao oferecida por Ruben no uma unanimidade no meio cientifico
29
outros autores como Silva (2004) sugere um outro modelo de distribuio das tcnicas de
avaliao.
Segundo Silva (2004) os mtodos de inspeo, ou mtodos analticos ou
prognstico, caracterizam-se pela no participao direta dos usurios do sistema na
avaliao. Os avaliadores que adotam esses mtodos so especialistas em usabilidade ou
projetistas de sistemas, e baseiam-se em regras, recomendaes, princpios e conceitos
previamente estabelecidos para identificar os problemas de usabilidade. Entre os principais
mtodos de inspeo identificados na literatura, esto:
o
Inspeo de usabilidade formal - uma adaptao para a avaliao de

usabilidade, da metodologia tradicional de inspeo de software para
formalizao e registro de problemas. Este mtodo geralmente adotado na
fase preliminar de desenvolvimento do projeto, pois faz a deteco inicial de
problemas em usabilidade.
Inspeo ou percurso pluralstico- a inspeo constitui-se de reunies entre

usurios, projetistas de sistemas e especialistas em usabilidade, onde so
analisados os cenrios das tarefas e avaliados cada um dos elementos da
interao do usurio com o sistema. Os dados coletados representam as
opinies ou preferncias dos participantes. Pode ser usada antes que o sistema
esteja disponvel ou at mesmo antes de um prottipo. Como materiais de
apoio avaliao, so utilizados esquemas, anotaes, desenhos, painis e
cartes para representar as diversas telas do sistema. A inspeo pluralstica
mais usada nos estgios iniciais de desenvolvimento de um sistema.
Inspeo de componentes - analisado apenas um conjunto de componentes,

caractersticas ou mdulos do sistema para realizao de uma determinada
tarefa. A partir de um cenrio preestabelecido, so analisados e identificados os
30
componentes do sistema que seriam utilizados para a realizao da tarefa.

Utilizar essa anlise necessita verificar a disponibilidade, facilidade de
compreenso e utilidade de cada componente. indicado para os estgios
intermedirios de desenvolvimento dos sistemas, sendo necessrio conhecer as
funes do sistema e os componentes utilizados pelos usurios para terminar
determinada tarefa. Esse mtodo de inspeo busca saber se tais componentes
so facilmente utilizveis pelos usurios.
o
Inspeo de consistncia - garante a consistncia de um conjunto de sistemas

relacionados a uma tarefa ou cenrios. A equipe de inspeo se rene para
analisar os pontos fortes e fracos das interfaces de cada sistema, para
identificar as melhores opes para serem implantadas em todo o conjunto.
Conhecida tambm como reviso de projeto, mais utilizada nas fases
preliminares de desenvolvimento, para no ter que fazer uma reestruturao
completa para atingir o padro desejado.
Inspeo ou percurso cognitivo - a tcnica de reviso, onde se constroem

cenrios de tarefa, a partir de uma especificao ou prottipo, e verificam a
interface como se fosse o usurio que estivesse utilizando o sistema pela
primeira vez. Esse mtodo tem o enfoque na avaliao da facilidade de
aprendizado proporcionada pelo sistema e a identificao dos processos
cognitivos que se estabelecem quando o usurio realiza a tarefa pela primeira
vez. indicado para os estgios iniciais de desenvolvimento, porque pode ser
adotado mesmo quando existem apenas especificaes do sistema a ser
avaliado. (SILVA 2004)
Inspeo baseada em padres - verifica a conformidade do sistema em relao

aos padres da empresa, sendo adotado por especialista com conhecimento em
31
cada padro especfico. A inspeo realizada por meio da confrontao de

cada elemento do produto com o padro. Os padres verificados na avaliao
de um sistema interativo podem pertencer a um conjunto de regras ou
recomendaes estabelecidas por organismos internacionais, tais como ISO
(International Organization for Standardization), IEEE (Institute of Electrical
and Electronics Engineers), ABNT (Associao Brasileira de Normas
Tcnicas), ANSI (American National Standards Institute), W3C (The World
Wide Web Consortium), etc. A inspeo adequada para os estgios
intermedirios de desenvolvimento, cujo projeto baseou-se, desde o princpio,
em um ou mais dos padres existentes.
o
Inspeo baseada em guias de recomendaes e guias de estilos - normalmente

utilizado em conjunto com outros mtodos de avaliao, como por exemplo,
a avaliao heurstica e a inspeo de consistncia. Os guias usados como um
conjunto de requisitos, critrios ou princpios bsicos a serem verificados. Os
guias de estilos so publicaes com descries mais detalhadas de elementos
interativos especficos de um sistema, tais como menus, janelas e caixas de
entrada de dados. O guia de recomendaes, por outro lado, um documento
publicado, de carter genrico e pblico, com recomendaes geradas e
validadas a partir de observaes empricas ou da experincia prtica de seu
autor. composta por uma srie de requisitos, considerados desejveis e/ou
necessrios para atingir certo efeito ou objetivo, mais restritos e especficos do
que os itens de um guia de recomendaes. Por atender ao contexto do sistema,
isto , seus usurios, tarefas e ambiente, as listas de verificao so
consideradas mais eficientes na deteco de problemas de usabilidade do que
os guias de recomendaes genricos. Os guias apresentam, portanto,
32
sugestes e/ou recomendaes para melhoria da usabilidade de sistemas com

base em situaes empricas anteriores, na padronizao de produtos ou na
experincia do avaliador ou projetista.
Como j descrito anteriormente por Rubin (1994):
o Avaliao heurstica - um mtodo de inspeo sistemtico, cujo
objetivo identificar problemas de usabilidade que, posteriormente,
sero analisados e corrigidos ao longo do processo de desenvolvimento
do sistema.
2.1.5 Mtodos de teste com usurios
Mtodos de teste com usurios caracterizam-se pela participao direta dos

usurios na avaliao do sistema. Os mtodos podem ser realizados atravs de questionrios e
entrevistas, ou podem ser empricos, ao adotar tcnicas de observao ou monitoramento do
uso do sistema em situaes reais.
o
Entrevistas e questionrios - permitem que o avaliador conhea as

experincias, opinies e preferncias dos usurios ao utilizarem o sistema. A
partir de perguntas formuladas de acordo com o objetivo do teste, o avaliador
interage com os usurios diretamente, facilitando a discusso sobre os temas
sugeridos pelas perguntas, ou envia um questionrio e aguarda suas respostas,
sem interagir com os usurios participantes do teste. As entrevistas so
consideradas tcnicas mais informais, mas so capazes de medir a ansiedade, a
satisfao subjetiva e a percepo dos usurios com maior riqueza de detalhes
do que os questionrios ou outras tcnicas objetivas. Os questionrios so
teis quando se tem uma grande quantidade de usurios, dispersos
33
geograficamente ou segmentados por perfil. Podem-se identificar indcios de

problemas de uso do sistema por certo tipo de usurios, em um determinado
ambiente operacional ou realizando certa tarefa. Tanto as entrevistas quanto os
questionrios podem ser usados em qualquer fase do desenvolvimento do
sistema, dependendo do tipo de perguntas formuladas. Dentre as classes de
entrevistas e questionrios existentes, na rea de usabilidade, destacam-se os
grupos focais (identifica percepes, sentimentos, atitudes e idias dos
participantes a respeito de um determinado assunto, e realizada por meio de
discusses); e os questionrios especficos para medir a satisfao dos usurios
(desenvolvidos a partir de tcnicas psicomtricas).
o
Testes Empricos de Usabilidade - conhecidos tambm como ensaios de

interao, so originrios da psicologia experimental e so capazes de
coletarem dados a partir da observao da interao homem-computador. A
coleta de dados est tendo mais nfase, para os pesquisadores em usabilidade,
usando tcnicas como a verbalizao (os usurios so solicitados a verbalizar
seus pensamentos, sentimentos e opinies enquanto utilizam o sistema para
realizar uma ou mais tarefas no sistema); a co-descoberta (dois participantes
realizam juntos tarefas designadas pelo avaliador e descrevem seus
pensamentos, observa-se tambm a ajuda mutua); e dados coletados por
mtodos de medida de desempenho (coleta dados de desempenho dos usurios
tpicos, utilizando o sistema para a realizao de tarefas especficas).
Segundo Cybis (1999) a usabilidade de um sistema est sempre associada s

caractersticas de determinados usurios. Assim, um problema de usabilidade pode se fazer
sentir fortemente em determinados contextos de operao e ser menor ou mesmo
imperceptvel, em outros.
34
As atividades ligadas a esta perspectiva do ciclo de usabilidade visam identificar,

sejam por prospeco, diagnstico ou observao, os problemas de usabilidade em interfaces
humano-computador e contribuir para a sua eliminao. Entre os objetivos a serem atingidos,
pelas avaliaes pode-se observar e registrar problemas efetivos de usabilidade durante a
interao, calcular mtricas objetivas sobre a eficcia, eficincia e produtividade do usurio
na interao com o sistema, diagnosticar as caractersticas do projeto que provavelmente
atrapalhem a interao por estarem em desconformidade com padres implcitos e explcitos
de usabilidade, prever dificuldades de aprendizado na operao do sistema, prever os tempos
de execuo de tarefas informatizadas, conhecer a opinio do usurio em relao ao sistema;
sugerir as aes de re-projeto mais evidentes face os problemas de interao efetivos ou
diagnosticados (CYBIS, 1999).
2.1.6 A escolha da tcnica mais adequada
Na escolha de tcnicas de avaliao necessrio observar as qualidades de cada

tcnica a partir da comparao dos recursos disponveis e das expectativas de resultados a
serem obtidos a partir da avaliao de usabilidade. Quando se observa as diferentes tcnicas
percebem-se diferenas relacionadas quantidade de problemas que cada uma delas capaz
de detectar, da sistematizao de seus resultados, do quanto cada uma delas oferece de
facilidades para sua aplicao e principalmente do poder de convencimento dos resultados
perante a equipe de projetistas das necessidades de mudanas nas interfaces humanocomputador. Cybis (1999) destaca alguns aspectos a serem observados:
35
o Efetividade: refere-se quantidade de problemas srios (recorrentes, transponveis e

assimilveis) identificados.
o Abrangncia: refere-se quantidade de problemas reais de todos os tipos
identificados. As inspees por checklists e as avaliaes heursticas so as mais
abrangentes;
o
Eficincia: a razo da quantidade de problemas srios (recorrentes, transponveis e

assimilveis) identificados em face de quantidade de problemas reais identificados de
todos os tipos.
Produtividade: refere-se a razo entre a quantidade de problemas reais de todos os

tipos identificados em relao quantidade de recursos financeiros (U$) necessrios;
o Sistematizao: para esta qualidade concorrem dois fatores igualmente importantes:

repetitividade e reproduzibilidade. O primeiro refere-se medida pela quais os
resultados produzidos pela tcnica se repetem quando o mesmo avaliador examina o
mesmo software algum tempo depois da primeira avaliao. O segundo fator se refere
medida pela quais dois avaliadores diferentes examinando um mesmo software
produzem os mesmos resultados. As inspees por checklists so as mais sistemticas.
Apesar do teste de usabilidade resolver grande parte dos problemas de interao

com o usurio, Rubin (1994) afirma que o teste no tudo para usabilidade e sucesso do
produto, e isto importante para compreender suas limitaes. Testes no garantem o sucesso
ou produzem provas que o produto ser usvel. At mesmo o maior rigor conduzindo
formalmente o teste no pode dar cem por cento de certeza, assegurando que o produto ser
utilizvel quando liberado. Aqui esto algumas razes apresentadas por (RUBIN, 1994):
o O teste sempre uma situao artificial. O teste no laboratrio, ou at mesmo o teste
de campo, ainda representa uma descrio de uma situao artificial de uso e no a
situao em si. O ato de conduzir um estudo pode em si afetar o resultados.
36
o Resultado de teste no prova que o produto funciona. Mesmo que um plano de

administrao do tipo de teste que adquire resultados estatisticamente significativo,
isto ainda no prova que um produto eficaz.
O significado da estatstica
simplesmente uma medida de uma probabilidade de que um nico resultado no

acontece acidentalmente. Isto no uma garantia, e depende muito de que modo o
mtodo foi administrado.
o Os participantes so, raramente, representantes do pblico alvo. Participantes so
somente os representantes capacitados para compreender e classificar seu pblico
alvo. O mercado de pesquisa no uma cincia infalvel, e o real usurio fica no final
e freqentemente difcil identific-lo e descrev-lo.
o Testes nem sempre so a melhor tcnica para usar. H muitas tcnicas pretendidas
para avaliar e melhorar os produtos. Por exemplo, em alguns casos que mais tcnicas
so eficazes em termos de custo, tempo e exatido para conduzir uma avaliao
tcnica de um produto ao invs de test-lo.
Entretanto, apesar destas limitaes, testes de usabilidade, quando conduzidos
com cuidado e preciso, para as noes apropriadas, no tempo apropriado do ciclo de vida do
produto, e como a parte de uma aproximao total do usurio no centro da criao, um
indicador quase infalvel de problemas potenciais e o meio de resolv-los minimiza o risco
consideravelmente de liberar um produto instvel ou de difcil aprendizagem.
De acordo com a comparao feita por Silveira (2001) a avaliao por checklist
derivada de guias de recomendaes ou critrios ergonmicos uma boa alternativa
avaliao no incio do processo e, quando for necessrio envolver desenvolvedores. Pelas suas
caractersticas, os guias enriquecem a avaliao, mas no devem ser usados como mtodos
nicos. Para uma aplicao ser completa, seria necessrio usar mais que uma tcnica de
avaliao, escolhidas em funo dos objetivos a serem alcanados.
37
2.2 Checklist
Cybis (1997), utiliza o termo inspeo ergonmica referindo-se a um tipo de

avaliao ergonmica em que o analista realiza vistorias baseadas em guidelines. E ainda
destaca que os resultados produzidos so uniformes, pois inspetores so conduzidos ao exame
da interface por meio de uma anlise da lista de questes a responder sobre a ergonomia do
projeto.
Heemann (1997) diz que o Checklist uma ferramenta para a avaliao da
qualidade ergonmica de um software, que se caracteriza pela verificao da conformidade
da interface de um sistema interativo com recomendaes ergonmicas provenientes de
pesquisas aplicadas..
A avaliao realizada por meio de Checklists apresenta as seguintes
caractersticas, segundo Heemann (1997):
o Possibilidade de ser realizada por projetistas, no exigindo especialistas em interfaces
homem-computador, pois o conhecimento ergonmico est contido no Checklist;
o Sistematizao da avaliao, o que garante resultados mais estveis, mesmo quando
aplicada separadamente por diferentes avaliadores, pois as questes/recomendaes
constantes no Checklist sempre sero efetivamente verificadas;
o Facilidade na identificao de problemas de usabilidade, devido especificidade das
questes do Checklist;
o Aumento da eficcia de uma avaliao, devido a uma considervel reduo da
subjetividade normalmente associada a processos de avaliao;
o Reduo de custo da avaliao, pois um mtodo de rpida aplicao.
38
Segundo Matias (1995), o Checklist uma ferramenta capaz de dar suporte

avaliao preliminar da interface, pois consegue identificar a maior parte dos problemas
detectados por uma anlise ergonmica completa, que envolva a utilizao de outras tcnicas
e aumento da eficcia da avaliao.
2.3 A formao do contedo de um checklist
A tcnica de avaliao de um checklist ergonmico foi desenvolvida para

sistematizar, objetivar e facilitar as avaliaes em usabilidade, permitindo que o resultado
esteja de acordo com os componentes de interfaces humano-computador. Geralmente a base
de conhecimento das questes de um checklist formulada a partir de recomendaes
publicadas, como a W3C e guias de estilos, como o guia de estilos para servios de
informao em cincia e tecnologia via Web (PARIZOTTO, 1997).
Na Web possvel encontrar um checklist baseado nas recomendaes W3C.
2.3.1 As Recomendaes do W3C
O World Wide Web Consortium (W3C), um consrcio de empresas de

tecnologia fundada por Tim Berners Lee em 1994 para levar a web, atravs do
desenvolvimento de protocolos comuns e fruns abertos que promovem sua evoluo e
asseguram a sua interoperabilidade. O W3C desenvolve tecnologias, denominadas Web
Standards (ou Padres Web) para a criao e a interpretao dos contedos para web. Na web
possvel encontrar um checklist baseado nas recomendaes da W3C.
Sites desenvolvidos segundo esses padres, podem ser acessados e visualizados
por qualquer pessoa ou tecnologia independente de hardware ou software utilizados, como
39
celular, PDA, eletrodomsticos, independentemente da plataforma, de maneira rpida e

compatvel com os novos padres e tecnologias que possam surgir com a evoluo da
internet. Apesar de o W3C no ser muito conhecido no Brasil, padres seus como Hyper Text
Markup Language (HTML), eXtensible Hypertext Markup Language (XHTML) e Cascading
Style Sheets (CSS) so muito populares, contudo em, muitos casos, so usados de forma
errnea devido ao no conhecimento da especificao.
So apresentadas a seguir as heursticas que originaram o checklist da W3C onde
Dias (2001) descreve-las como est listada abaixo:
o
o
o
o
o
o
o
Visibilidade e reconhecimento do estado ou contexto atual, e conduo do usurio.

Projeto esttico e minimalista.
Controle do usurio
Flexibilidade e eficincia de uso
Preveno de erros
Consistncia
Compatibilidade com o contexto
2.3.2 Heurstica 1: Visibilidade e reconhecimento do estado ou contexto atual, e

conduo do usurio.
Dias (2001) refere-se aos meios disponveis para informar, orientar e conduzir o
usurio durante a interao com o portal corporativo.
Em virtude da forma hipertextual, no-linear de interao e da quantidade de

pginas disponveis na Internet, um dos maiores problemas identificados em testes com
usurios sua desorientao. Para diminuir os efeitos dessa desorientao, o portal deve
sempre manter o usurio informado quanto pgina em que ele se encontra, como chegou at
essa pgina e quais so suas opes de sada, isto , onde ele se encontra numa seqncia de
40
interaes ou na execuo de uma tarefa. A seguir so relacionadas algumas recomendaes

segundo Dias (2001).
Recomendaes
A pgina principal do portal deve ser capaz de responder s seguintes perguntas:

Onde estou? e O que este portal faz?.
Apresentar em destaque o nome da pgina principal em todas as pginas componentes

do portal, preferencialmente no canto superior esquerdo. Pode-se usar o termo Home
ou o logotipo da empresa/departamento/projeto, por exemplo.
A navegao entre as pginas do portal deve responder s trs perguntas: Onde

estou?, Onde estive? e Para onde posso ir?.
Apresentar a estrutura ou mapa de navegao do portal, ressaltando a pgina atual

onde o usurio se encontra. Por exemplo, o indicativo Voc est aqui!, como nos
mapas tursticos.
2.3.3 Heurstica 2 - Projeto esttico e minimalista.
Refere-se s caractersticas que possam dificultar ou facilitar a leitura e a

compreenso do contedo disponvel no portal. Destacam-se a legibilidade, a esttica e a
densidade informacional. (DIAS, 2001).
Um programa legvel e esteticamente agradvel facilita a leitura da informao
nele apresentada, melhorando inclusive o desempenho do usurio na realizao da tarefa
proposta e influenciando seu nvel de satisfao durante a interao com o portal. A seguir so
relacionadas algumas recomendaes segundo Dias (2001).
41
Recomendaes
Ocupar de 50 a 80% da pgina com contedo (preferencialmente, 80%).
Ocupar no mximo 20% da pgina com informaes sobre a navegao.
Evitar frames, pois diminuem o espao disponvel para apresentao de contedo.
Usar hipertexto para dividir as informaes em vrias pginas ou nveis de

detalhamento.
Usar pequenos pargrafos, subttulos e listas.
Agrupar os diferentes tipos de informaes disponveis na pgina, apresentando as

mais importantes em primeiro lugar.
2.3.4 Heurstica 3 - Controle do usurio
Dias (2001) relaciona o controle que o usurio sempre deve ter sobre o
processamento de suas aes pelo portal. Os usurios de qualquer sistema interativo esperam
deter controle sobre o sistema, fazendo com que este responda a suas solicitaes e
expectativas. Aes inesperadas do sistema, infindveis seqncias de entrada de dados,
incapacidade ou dificuldade em obter a informao necessria e incapacidade em produzir os
resultados desejados contribuem para o aumento da ansiedade e da insatisfao do usurio.
As aes de um sistema devem ser reversveis, o usurio deve ter a possibilidade de desfazer a
ltima ao. Assim diminui a ansiedade do usurio. A seguir so relacionadas algumas
recomendaes segundo Dias (2001).
Recomendaes
Possibilitar o retorno pgina anterior.
42
Possibilitar aos usurios interromper ou cancelar o processamento ou transao atual.
No desviar para outra pgina, a no ser que o usurio digite Enter ou clique com o
mouse.
No abrir janelas adicionais.
Apresentar em todas as pginas os nveis anteriores da estrutura de navegao (em

forma de links) at chegar pgina atual (em formato textual, sem link). Dessa forma,
o usurio poder retornar mais facilmente s pginas anteriores.
2.3.5 Heurstica 4 - Flexibilidade e eficincia de uso
Dias (2001) sugere capacidade do sistema em se adaptar ao contexto e s

necessidades e preferncias do usurio, tornando seu uso mais eficiente.
Em funo da diversidade de tipos de usurios de um portal, necessrio que sua

interface seja flexvel para realizar a mesma tarefa de diferentes maneiras, de acordo com o
contexto e com as caractersticas de cada tipo de usurio. Devem-se fornecer ao usurio
procedimentos e opes diferentes para atingir o mesmo objetivo, da forma que mais lhe
convier.
Outros procedimentos podem ser adotados para tornar o uso do portal mais
eficiente, tais como a eliminao de pginas ou passos desnecessrios em uma seqncia para
a realizao de uma tarefa e o uso de valores padronizados, sem a necessidade de digitao
por parte do usurio. A seguir so relacionadas algumas recomendaes segundo Dias (2001).
Recomendaes
43
No usar pginas sem contedo til, como por exemplo, pginas apenas com
mensagens do tipo "Seja bem-vindo ao portal tal".
Na identificao de links, utilizar termos que exprimam o contedo das pginas

correspondentes. No utilizar nmeros ou cores para isso.
Oferecer servio de busca para pesquisa das pginas do portal, incluindo a

possibilidade de verificao ortogrfica dos termos digitados em sua caixa de entrada
de dados.
Nos resultados de pesquisa do servio de busca, apresentar os melhores em primeiro

lugar, sendo desnecessrio o uso de porcentagens ou graus de acerto.
2.3.6 Heurstica 5 - Preveno de erros
Dias (2001) sugere relacionar-se todos os mecanismos que permitem evitar ou

reduzir a ocorrncia de erros, assim como corrigir os erros que porventura ocorram.
As interrupes provocadas por erros de processamento tm conseqncias
negativas sobre a atividade do usurio, prolongando e perturbando a realizao de suas
tarefas. Quanto menor a probabilidade de erros, menos interrupes ocorrem e melhor o
desempenho do usurio. A seguir so relacionadas algumas recomendaes segundo Dias
(2001).
Recomendaes
No usar pginas com a expresso em construo. O portal deve apresentar apenas o

que j est pronto para ser acessado pelo usurio.
No liberar portal parcialmente pronto.
44
Remover dados/pginas desatualizados, como por exemplo, pginas convidando os

usurios para participarem de eventos que j ocorreram.
Nos servios de busca, no usar operadores booleanos nas pesquisas simples.

recomendvel oferecer a possibilidade de operadores booleanos apenas em pesquisas
avanadas, para serem usadas pelos usurios mais experientes.
2.3.7 Heurstica 6 Consistncia
Dias (2001) refere-se consistncia como a homogeneidade e coerncia na

escolha de opes durante o projeto da interface do sistema (denominao, localizao,
formato, cor, linguagem).
Um projeto consistente facilita o reconhecimento, o aprendizado, a localizao e,
por fim, a utilizao de um portal por seus usurios. A padronizao de formatos, localizaes
e sintaxe tornam o portal mais previsvel, diminuindo a incidncia de erros e as dificuldades
de aprendizado e compreenso. Quando possvel e conveniente padronizar os elementos do
sistema quanto a seu formato cor, localizao e denominao, para que o usurio identifique
mais facilmente situaes e elementos similares e realize suas tarefas com maior rapidez. A
seguir so relacionadas algumas recomendaes segundo Dias (2001).
Recomendaes
Usar sempre a mesma terminologia e a mesma localizao de elementos comuns nas

pginas de contedo, nas pginas de ajuda ao usurio e nas mensagens de erro.
Incluir a caixa de entrada de dados do servio de busca logo no incio de cada pgina,
preferencialmente no canto superior direito.
45
O comportamento do cursor deve ser consistente em todos os campos de entrada de

dados, isto , o cursor deve saltar automaticamente de um campo a outro ou aguardar
Enter ou Tab do usurio.
Verificar se os ttulos ou cabealhos das pginas correspondem exatamente aos termos

utilizados nos links que apontam para essas pginas.
2.3.8 Heurstica 7 - Compatibilidade com o contexto
Dias (2001) refere-se correlao direta entre o portal e seu contexto de

aplicao. As caractersticas do portal devem ser compatveis com as caractersticas dos
usurios e das tarefas que estes pretendem realizar com o sistema.
O desempenho dos usurios de qualquer sistema interativo melhora quando os
procedimentos necessrios ao cumprimento da tarefa so compatveis com as caractersticas
psicolgicas, culturais e tcnicas dos usurios; e quando os procedimentos e as tarefas so
organizados de acordo com as expectativas e costumes dos usurios. O portal deve falar a
linguagem do usurio, com palavras, conceitos familiares, ao invs de termos tcnicos que o
usurio no entende. A seguir so relacionadas algumas recomendaes segundo Dias
(2001).
Recomendaes
Planejar a estrutura do portal de acordo com o contexto das tarefas realizadas pelos
usurios e no com a estrutura organizacional ou com as novidades tecnolgicas. A
estrutura deve ser determinada pelas tarefas que os usurios pretendem realizar por
meio do portal.
46
Evitar estrutura linear (ordem numrica ou alfabtica). As informaes devem ser

apresentadas seguindo uma ordem lgica relacionada tarefa a realizar.
Verificar erros de grafia, tomando como base gramtica do idioma utilizado e o

glossrio de termos tcnicos de uso corrente na instituio.
2.4 Ergolist
O checklist disponibilizado pelo LabUtil 1 chamado de ErgoList, utiliza-se dos

critrios de Bastien e Scapin (1993) na composio de suas questes, descritas na tabela
abaixo.
Presteza- Engloba os meios utilizados para levar o usurio a realizar determinadas

aes, como, por exemplo, entrada de dados. Esse critrio engloba tambm todos os
mecanismos ou meios que permitem ao usurio conhecer as alternativas, em termos de aes,
conforme o estado ou contexto nos quais ele se encontra. O critrio se subdivide em quatro
subcritrios:
Agrupamento por Localizao;
Agrupamento/distino por Formato;
Feedback;
Legibilidade.
Disponvel em http://www.labiutil.inf.ufsc.br/ergolist/index.html
47
Conciso - O critrio conciso diz respeito a todos os elementos da interface que

tm um papel importante na reduo da carga cognitiva e perceptiva do usurio e no aumento
da eficincia do dilogo. O critrio se subdivide em dois subcritrios:
Aes Mnimas;
Densidade Informacional.
Aes Explcitas - O critrio Aes Explcitas do Usurio refere-se s relaes

entre o processamento pelo computador e as aes do usurio. Essa relao deve ser explcita,
isto , o computador deve processar somente aquelas aes solicitadas pelo usurio e apenas
quando solicitado a faz-lo. O critrio se subdivide em um subcritrios:
Controle do Usurio.
Flexibilidade - Trata-se, em outros termos, da capacidade da interface de se

adaptar s variadas aes do usurio.
Experincia do Usurio - Experincia do usurio diz respeito aos meios
implementados que permitem que o sistema respeite o nvel de experincia do usurio.
Proteo contra erros - A proteo contra os erros diz respeito aos mecanismos
empregados para detectar e prevenir os erros de entradas de dados, comandos, possveis aes
de conseqncias desastrosas e/ou no recuperveis. O critrio se subdivide em dois
subcritrios:
Mensagens de erro;
Correo de erros.
48
Consistncia - Refere-se forma na quais as escolhas na concepo da interface

(cdigos, denominaes, formatos, procedimentos, etc.) so conservadas idnticas, em
contextos idnticos, e diferentes, em contextos diferentes.
Significado dos Cdigos - Diz respeito adequao entre o objeto ou a
informao apresentada ou pedida e sua referncia. Cdigos e denominaes significativas
possuem uma forte relao semntica com seu referente. Termos pouco expressivos para o
usurio podem ocasionar problemas de conduo, podendo lev-lo a selecionar uma opo
errada.
Compatibilidade - Refere-se ao acordo que possa existir entre as caractersticas do
usurio (memria, percepo, hbitos, competncias, idade, expectativas, etc.) e as tarefas, de
uma parte, e a organizao das sadas, das entradas e do dilogo de uma dada aplicao.
2.5 Concluso
Neste projeto, foi possvel verificar conceitos de usabilidade e meios de avaliao,

como critrios e recomendao para api-las. Qualquer uma dessas avaliaes, com suas
peculiaridades, resolve problemas relacionados usabilidade. Ainda pouco abordada dentro
das empresas de software.
Deve-se ter em mente que a elaborao e realizao de testes de usabilidade
aplicados a um produto, so bons indicador para expor problemas em potencial. Isto minimiza
o risco de disponibilizar no mercado um produto instvel e de difcil aprendizado. A tcnica
para avaliao do produto deve ser definida por um especialista que est executando o projeto
de usabilidade, ele deve definir o melhor mtodo ou conjunto de mtodos a ser aplicado.
Autores como Nilsen (2000), Shneiderman (1992), Bastien (1993) e Scapin
(1986) formularam recomendaes para apoio avaliao em usabilidade de forma genrica.
49
Quando utilizadas como base para um checklist as recomendaes ou guias de

estilos oferecidos so transformadas em questes onde o avaliador pode responder
objetivamente sim, no e no aplicvel, evitando a subjetividade nas respostas.
O uso de checklists um meio barato e eficiente de capturar problemas de
usabilidade, a usabilidade um elemento crtico de sucesso no mercado de informtica e a
realizao dos testes de usabilidade um elemento imprescindvel no projeto.
50
3. UML
UML (Unified Modeling Language) um padro de linguagem para elaborao
da estrutura de projetos de software, podendo ser empregada para visualizao, a
especificao, a construo e a documentao de sistemas.
A UML no uma linguagem visual de programao, mas capaz de
representar tudo o que possa ser melhor expresso em termos grficos j que a linguagem de
programao representa o que melhor em termos textuais.
Esse tipo de linguagem serve para a documentao da arquitetura do sistema e
de todos os seus detalhes, ela tambm proporciona uma linguagem para expresso de
requisitos para realizao de testes. Para finalizar, a UML oferece uma linguagem para a
modelagem das atividades de planejamento do projeto e de gerenciamento de verses.
(BOOCH, 2000).
3.1 Atores
O ator representa um conjunto coerente de papis que os usurios de casos de

uso desempenham quando interagem com esses casos de uso. Um ator representa o papel
51
do ser humano, um dispositivo de hardware ou outro sistema desempenha com o sistema.
(BOOCH, 2000).
ud Atores
.00 Unregistered Trial Version EA 4.00 Unregiste

Atores

1 - Pesquisador
.00 Unregistered Trial
Version EA 4.00 Unregiste

2 - Especialista
3 - Desenvolvedor
4 - Usurio comum

Figura 2: Atores do Sistema
Fonte: autor do projeto
Nro.
Ator
1
Pesquisador
Especialista
Quadro 2: Atores do sistema

Descrio
Definio: Individuo que realiza a alimentao da base de
dados do Glist
Freqncia de Uso: Diria
Objetivo : avaliar a usabilidade de um determinado produto
ou popular a base de recomendaes.
Conhecimento em informtica: relativamente alto, porque
so pesquisadores na rea da computao.
Conhecimento no Processo: Domina todo o processo.
Grau de escolaridade, Graduado ou em processo de
graduao.
Permisses de acesso: Ter acesso a todas as
funcionalidades do sistema.
Definio: O especialista ser usurio final que poder fazer
avaliao em usabilidade, ou se tiver permisso poder
fazer a alimentao do sistema.
Objetivo : avaliar a usabilidade de um determinado produto
ou popular a base de recomendaes.
52
Desenvolvedor
Usurio comum
Conhecimento em informtica: relativamente alto, so

especialista na rea de usabilidade.
Conhecimento no Processo: Domina todo o processo.
Grau de escolaridade, Doutores, Mestres, Graduados.
Permisses de acesso: Ter acesso a principio somente a
consulta base de dados, mas com uma permisso poder
ter acesso total do sistema atravs de uma senha.
Definio: Usurio alvo do Glist.
Objetivo: melhorar a usabilidade do produto que
desenvolve.
Conhecimento em informtica: relativamente alto, so
programadores.
Conhecimento no Processo: Baixo.
Grau de escolaridade: Graduao, ps-graduado, tcnico.
Permisses de acesso: Ter acesso some a consulta da base
de dados.
Definio: Usurio final.
Objetivo: conhecer a usabilidade do produto que utiliza.
Conhecimento em informtica: mdio, porque o usurio que
deseja fazer uma avaliao de usabilidade j tem um
conhecimento em informtica.
Conhecimento no Processo: Baixo
Grau de escolaridade: Desde fundamental ate psgraduao
Permisses de acesso: Ter acesso somente a consulta.
3.2 Casos de Uso
O caso de uso descreve o que o sistema (ou um subsistema, classe ou interface)

faz, mas ele no especifica como isso e feito. Os Diagramas so importantes para
visualizar, especificar e documentar o comportamento de um elemento. Isso faz com que os
sistemas, subsistemas e classes ficam mais acessveis e compreensveis, por apresentarem a
viso externa sobre como esses elementos podem ser visualizados no contexto. (BOOCH,
2000).
53
ud Casos de Uso do Negcio
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregiste
Caso de Uso Geral
CSU001 Gerncia de
Proj eto
(from Caso de uso)
A 4.00 Unregistered
Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregiste
2 - Especialista
CSU002 Gerncia de
Categorias
(from Atores)
1 - Pesquisador
(from Atores)
A 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00 Unregiste
(from Caso de uso)
A 4.00 Unregistered Trial Version EA
4.00 Unregistered Trial Version EA 4.00 Unregiste
CSU003 -
A 4.00 Unregistered Trial Version EAGerncia

4.00 de
Unregistered Trial Version EA 4.00 Unregiste
Recomendaes

(from Caso de uso)
CSU004 -

4.00deUnregistered
Trial Version EA 4.00 Unregiste
Gerncia
Testes
4 - Usurio comum
3 - Desenv olv edor
Atores)
A 4.00 Unregistered
Trial Version EA 4.00 Unregistered Trial Version (from
EA
4.00 Unregiste
(from Atores)
(from Caso de uso)
A 4 00 U
Cdigo
CSU001
CSU002
CSU003
CSU004
i t
dT i lV
EA 4 00 U
i t dT i lV
Figura 3: Caso de uso geral
EA 4 00 U
Quadro 3: Casos de uso do sistema

Descrio
Gerncia de Projetos
Realiza a insero, alterao, excluso de projetos.
Gerncia de Categorias
Realiza a insero, alterao, excluso de categorias.
Gerncia de Recomendaes
Realiza a insero, alterao, excluso de recomendaes.
Gerncia de Testes
Realiza com base no projeto escolhido, o teste a ser aplicado.
i t
54
3.2.1 CSU001 Gerncia de Projetos
O caso de uso CSU001 Gerncia de Projetos tem por objetivo o cadastro de

projetos na sua base de dados. Um projeto e a rea de atuao que o mesmo estar
abrangendo.
Quadro 4: Gerncia de Projetos
Unregistered
Trial Version
EA 4.00 Unregistered Trial Version EA 4.00 Unreg
ud Caso de Uso - Gerncia
de proj etos
Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unreg
CSU001- Gerncia
de Proj eto

Pesquisador
Especialista

Nome
Identificador
Descrio
Ator Primrio
Pr-condio
Fluxo Principal
Fluxo Alternativo
Ps-condio
Gerncia de Projetos
CSU001
O pesquisador ou especialista cadastra ou altera um projeto no
sistema
Pesquisado e Especialista
Conta e senha do usurio devem ser vlidas
1. O usurio informa o nome do novo projeto.
2. O sistema permite a associao do projeto com as
recomendaes
3. O usurio seleciona a opo.
4. O sistema executa a opo desejada.
1. O usurio do sistema seleciona um projeto j
cadastrado.
2. O sistema exibe a opo para alterar ou excluir o
projeto selecionado
3. O usurio cancela as opes acessando o menu.
Cadastro realizado com sucesso.
3.2.2 CSU002 Gerncia de Categorias
55
O caso de uso CSU002 Gerncia de categorias tem por objetivo o cadastro de
categorias na sua base de dados. As categorias estaro vinculadas aos seus respectivos
projetos.
Quadro 5: Gerncia de Categorias

ud Caso de Uso - Gerncia de Categorias
00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00

CSU002 de Unregistered Trial Version EA 4.00
00 Unregistered Trial Version Gerncia
EA 4.00
Categorias
Especialista
00Pesquisador
Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00
Nome
Identificador
Descrio
Ator Primrio
Pr-condio
Fluxo Principal
Fluxo Alternativo
Ps-condio
Gerncia de Categorias
CSU002
O pesquisador ou especialista cadastra ou altera categorias no
sistema
Conta e senha do usurio devem ser vlidas
1. O usurio informa o nome das categorias.
2. O sistema permite o usurio cadastrar vrias
categorias.
3. O sistema exibe a opo para finalizar o cadastro.
1. O usurio do sistema seleciona categoria j
cadastrada.
2. O sistema exibe a opo para alterar ou excluir a
categoria selecionada.
3.2.3 CSU003 Gerncia de recomendaes
56
O caso de uso CSU003 Gerncia de recomendaes tem por objetivo o
cadastro de recomendaes na sua base de dados. As recomendaes estaro vinculadas as
suas respectivas categorias e projetos.
Quadro 6: Gerncia de recomendaes
ud subsystem Gerencia de recomendaes
egistered Trial Version EA 4.00 Unregistered Trial Version

CSU003 Gerncia
de Unregistered Trial Version
egistered Trial Version Recomendaes
EA 4.00
Pesquisador
egistered
Trial Version EA 4.00 Unregistered TrialEspecialista
Version
Nome
Identificador
Descrio
Ator Primrio
Pr-condio
Fluxo Principal
Fluxo Alternativo
Ps-condio
Gerncia de Recomendaes
CSU003
O pesquisador ou especialista cadastra ou altera recomendaes
no sistema
Conta e senha do usurio devem ser vlidas.
1. O usurio informa o nome das recomendaes.
2. O sistema permite o usurio cadastrar vrias
recomendaes.
3. O sistema exibe a opo para finalizar o cadastro.
1. O usurio do sistema seleciona recomendaes j
cadastradas.
2. O sistema exibe a opo para alterar ou excluir a
recomendao selecionada.
3.2.4 CSU004 Gerncia de Teste
57
O caso de uso CSU004 Gerncia de testes tem por objetivo montar os testes
de acordo com o projeto selecionado pelo usurio, subdivididos por categorias e
recomendaes.
Quadro 7: Gerncia de Teste

Fonte: Autor
do4.00
projeto
EA 4.00 Unregistered Trial Version
EA
Unregistered Trial Versio
ud Caso de Uso
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio

CSU004 -
Gerncia deEA
Testes
4.00 Unregistered Trial Versio
Usurios comuns
Desenv olv edores
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Versio

Nome
Identificador
Descrio
Ator Primrio
Pr-condio
Fluxo Principal
Fluxo Alternativo
Ps-condio
Gerncia de Testes
CSU004
O usurio responde as questes que esto exibidas na tela.
Desenvolvedor e Usurio Comum
O sistema deve possuir projetos, categorias e recomendaes
devidamente cadastrados.
6. O usurio seleciona o projeto desejado.
7. O sistema exibe o projeto, depois de selecionado
mostrada as recomendaes por categoria.
8. O usurio responde as recomendaes.
9. O sistema exibe um relatrio.
1. O usurio cancela as aes pelo boto cancelar na tela.
Exibio do relatrio
3.2.1.1 Diagrama de classes de anlise (Gerncia de Projeto)
Representa a estrutura esttica da classe Entidade projeto, esta por sua vez,
representa os objetos que sero gerenciados pela interface form: Gerncia de Projeto.
58
od CSU001- Gerncia de Proj eto
EA 4.00 Unregistered Trial Version EA 4.00 Unregiste

Pesquisador
EA
EA 4.00 Unregistered
Trial
Version EA 4.00 Unregiste
form: Gerncia
de Projetos
Projeto

Especialista

Figura 4: Digrama de Robustez (Gerncia de Projeto)
O sistema apresenta a tela form: Gerncia de Projeto, o usurio informa o nome

do novo projeto. Os dados so armazenados na classe persistente Projeto.
3.2.2.1 Diagrama de classes de anlise (Gerncia de Categoria)
Representa a estrutura esttica da classe Entidade Categoria, esta por sua vez,
representa os objetos que sero gerenciados pela interface form: Gerncia de Categoria.
59
EA
4.00 Unregistered Trial Version EA 4.00 Unregistered
od CSU002 - Gerncia de Categorias
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered
Pesquisador

form: Gerncia de Categoria
Categoria
Trial Version EA 4.00 Unregistered

Especialista

Figura 5: Digrama de Robustez (Gerncia de Categorias)
O sistema apresenta a tela form: Gerncia de Categoria, o usurio informa o

nome das novas categorias. Os dados so armazenados na classe persistente Categoria.
3.2.3.1 Diagrama de classes de anlise (Gerncia de Recomendaes)
Representa a estrutura esttica da classe Entidade recomendaes, esta por sua

vez, representa os objetos que sero gerenciados pela interface form: Gerncia de
Recomendaes.
60
od CSU003
- Gerncia de Recomendaes
4.00
Unregistered
Trial Version EA 4.00 Unregistered Tri
4.00 Unregistered Trial Version EA 4.00 Unregistered Tri

Pesquisador

form: Gerncia de Recomendao
Recomendao

Especialista
4 00 Unregistered Trial Version EA 4 00 Unregistered Tri

Figura 6: Digrama de Robustez (Gerncia de recomendaes)
O sistema apresenta a tela form: Gerncia de recomendaes, o usurio informa

o nome das novas recomendaes. Os dados so armazenados na classe persistente
Recomendaes.
3.2.4.1 Diagrama de classes de anlise (Gerncia de teste)
Representa a estrutura das classes, esta por sua vez, representa os objetos que
sero gerenciados pela interface form: Gerncia de Testes.
61
od CSU004 - Gerncia de Testes
00 Unregistered Trial Version EA 4.00 Unregistered Trial Version E

00 Unregistered Trial Version EA 4.00 Unregistered
Trial Version E
Projeto
Desenv olv edores
00 Unregistered
Trial Version EA 4.00 Unregistered Trial Version E
00 Unregistered Trial Version EA 4.00 Unregistered Trial Categoria

Version E
form: Gerncia de Teste

Usurio Comum
00 Unregistered
Trial Version EA 4.00 Unregistered Trial Version E

Recomendao

Figura 7: Digrama de Robustez (Gerncia de testes)
O sistema apresenta a tela form: Gerncia de Teste, o usurio seleciona na
entidade Pprojeto os projetos cadastrados, de acordo com o projeto selecionado
relacionado suas respectivas categorias e cada categoria suas respectivas recomendaes.
3.3 Diagrama de atividades
O diagrama de atividades um diagrama de estados, que representa uma

atividade, em vez do estado do objeto. O mesmo pode ser visto como uma extenso de
fluxogramas, que possui notao para representar aes concorrentes, juntamente com a sua
sincronizao. (BEZERRA, 2002).
62
3.3.1 Gerncia de Projeto
Capturados as aes e os resultados obtidos da execuo do caso de uso

Gerncia de Projeto, obteve-se o diagrama a seguir:
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA
ad CSU001 - Gerncia de Proj eto

Incio

4.00 Unregistered Trial Version EAAcessa
4.00 Unregistered
Trial Version EA
o Sistema
Acessa o cadastro de
Acessa
aletrao de
4.00 Unregistered
Triala Version
Trial Version EA
projetos
projetos

Cancelar
4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version

EA
Final
Selecionar um
projeto desejado
[No]

Executa insero de

Trial Version EA
dados no sistema
4.00 Unregistered
Trial Version
EA 4.00 Unregistered Trial Version EA
[Alterar]
[Excluir]
4.00Altera
Unregistered
Version Exclui
EA 4.00
Unregistered Trial Version EA
informaesTrial
do
um projeto
projeto

Final
63
Figura 8: Diagrama de Atividades Gerncia de Projeto
Iniciando o acesso ao cadastro de projeto pode-se optar por cadastrar novo

projeto ou consultar um novo projeto, tendo tambm a opo de sair. A partir do cadastrar
projeto ao finalizar executa o prximo caso de uso. J pela consulta pode-se optar por fazer
alguma alterao e sair ou excluir o projeto consultado e sair do caso de uso.
3.3.2 Gerncia de Categorias
Capturadas as aes e os resultados obtidos da execuo do caso de uso

Gerncia de categorias, obteve-se o diagrama a seguir:
64
ad CSU002 - Gerncia de categorias
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregistered
Incio
Acessa o sistema
EA 4.00 Unregistered Trial
Version EA 4.00 Unregistered Trial Version EA 4.00 Unregistered
Acessa aletrao de
Acessa cadastro de
categorias
categorias
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Cancelar
Version EA 4.00 Unregistered
[Sim]
Final
Seleciona uma
categoria desejada
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version[No]EA 4.00 Unregistered
Executa insero
de Unregistered
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
EA 4.00
dados no sistema
EA
4.00
Unregistered Trial Version EA 4.00 Unregistered
Exclui umaTrial Version EA 4.00 Unregistered
Altera
informaes
da categoria
[Inserir]
[Excluir]
categoria
Final
Figura 9: Diagrama de Atividades Gerncia de Categorias

Iniciando o acesso ao cadastro de categorias pode-se optar por cadastrar uma

nova categoria ou consultar uma nova categoria, tendo tambm a opo de sair. A partir de
cadastrar categorias tem a opo de cadastrar quantas categorias o usurio deseja, ao
finalizar executa o prximo caso de uso. J na consulta pode-se optar por fazer alguma
alterao e sair ou excluir a categoria consultada e sair do caso de uso.
65
3.3.3 Gerncia de Recomendaes

Gerncia de recomendaes, obteve-se o diagrama a seguir:
ad CSU003 - Gerncia de recomendaes
Incio
Acessa o sistema
Acessa alterao de
recomendaes
Acessa o cadastro
de recomendaes
Cancelar
[Sim]
Seleciona a
Trialrecomendao
Version EA
desejada
Final

[No]
Executa insero de
dados no sistema
EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version
Altera informaes
da recomendao
[Alterar]
[Excluir]
Exclui uma
recomendao
Final
EA 4 00 Unregistered Trial Version EA 4 00 Unregistered Trial Version EA 4 00 Unregistered
Figura 10: Diagrama de Atividades Gerncia de Recomendaes

Iniciando o acesso ao cadastro de recomendaes, pode-se optar por cadastrar

uma nova recomendao ou consultar uma recomendao, tendo tambm a opo de sair. A
66
partir de cadastrar recomendaes tem a opo de cadastrar quantas recomendaes o
usurio deseja. Na consulta pode-se optar por fazer alguma alterao e sair ou excluir a
recomendao consultada e sair do caso de uso.
3.3.4 Gerncia de testes

Gerncia de testes, obteve-se o diagrama a seguir:
egistered Trial Version EA 4.00 Unregistered T

ad CSU004 - Gerncia de testes
Fazer Teste
egistered Trial Version EA 4.00 Unregistered
T
Iniciando

Seleciona o Projeto
egistered Trial Version EA 4.00
Unregistered T

Visualizao da interface
Unregistered T
por por categorias

Usurio
responde as
Unregistered
T
reomendaes

Fecha tes
te
egistered
Trial
Version EA 4.00
Unregistered T
Visualizao do relatrio

i t 11:dDiagrama
T i l V de iAtividades
EA400
U
i tTestes
dT
Figura
Gerncia
de
67
Iniciando o acesso ao fazer teste tem a opo de selecionar um projeto j
cadastrado, tambm tem a opo de sair. Aps a visualizao da interface o usurio
responde as questes apresentadas, e visualiza o relatrio, e sai de teste.
3.4 Diagrama de Classes de Interfaces
O diagrama de interfaces permite a viso do relacionamento entre todas as

interfaces existentes no sistema.
68
od Clases de Interfaces

Form: Projeto

Form: Cadastro
Form: Categoria

Form: Recomendao

Form: Teste
Form: Menu
EA 4.00
Unregistered
Trial Version EA 4.00 Unregiste
EA 4.00 Unregistered Trial Version EA 4.00

Unregiste
Form: Projeto
Trial Version EA 4.00
Unregiste
Form: Categoria
Form: Alterao/Excluso
EA 4.00 Unregistered Trial Version EAForm:
4.00
Unregiste
Recomendao
Figura 12: Diagrama de Classes de Interfaces
3.5 Diagrama de Classes Persistentes
Diagrama de classes persistentes so diagramas que mostram um conjunto de

classes importante no s para visualizao mas especificao e a documentao de
modelos estruturais, e tambm para construo dos sistemas executveis por meio de
69
engenharia de produo e reversa. Diagrama de classes persistentes geralmente utilizado
na modelagem do banco de dados (BOOCH, 2000).
Abaixo e mostrado o diagrama lgico das classes do presente projeto:
00odUnregistered
Trial Version EA 4.00 Unregistered Tria
Diagrama logico
00 Unregistered Trial Version EA 4.00 Unregistered Tria
1
00 Unregistered
Trial Version EA 4.00 Unregistered Tria
categorias

Tria
*
recomendacoes
*
Tria

*

*
1
00 Unregistered
Tria
cadastro
projeto

Figura 13: Digrama de Classes Persistentes
70
Abaixo e mostrado o diagrama fsico das classes do presente projeto:
categorias
IDCATEGORIA: int(11)
NOME: varchar(45)
DESCRICAO: varchar(45)
1
N
recomendacoes
IDRECOMENDACAO: int(11)
FKCATEGORIA: int(11)
CODIGO: int(11)
RECOMENDACAO: varchar(255)
BIBLIOGRAFIA: varchar(45)
EXEMPLO: varchar(255)
CRITERIO: varchar(45)
N
cadastro
projeto
IDCADASTRO: int(11)
IDPROJETO: int(11)
NOME: varchar(10)
DESCRICAO: varchar(45)
FKRECOMENDACAO: int(11)
FKPROJETO: int(11)
NIVEL: varchar(100)
Figura 14: Digrama de Classes Persistentes

3.6 Concluso
71
A modelagem permite um bom nvel de entendimento da soluo proposta,
podendo prever erros, antes que esses sejam implementados.
A UML uma linguagem grfica que proporciona visualizao, especificao,
construo e documentao de sistemas, proporcionando um maior detalhamento do
problema para facilitar a manuteno e agilidade na implementao. So vantagens para
realizar um projeto que faz uso da UML.
Segundo Bezerra (2002) um sistema descrito em certo nmero de vises, onde
cada uma representa uma projeo da descrio completa e mostra aspectos particulares do
sistema. Cada viso mostrada por um diagrama que contm informaes que enfatizam os
aspectos particulares do software.
Neste projeto foi realizada a modelagem UML, para proporcionar o maior
entendimento sobre a aplicao.
72
4 DESENVOLVIMENTO E VALIDAO
Neste captulo so descritas as etapas do processo de desenvolvimento do

Checklist automatizado, incluindo o processo de coleta de informaes e anlise para a
obteno dos dados necessrios para a implementao deste projeto at as etapas de
implementao e validao.
4.1 A Coleta de Informaes
No primeiro momento da anlise de requisitos, iniciou-se um processo de

discusso juntamente com o orientador em torno da possibilidade da realizao do projeto.
A idia do projeto surgiu da necessidade do LPU - Laboratrio de Pesquisa em
Usabilidade localizado na UNISUL. O laboratrio realiza avaliao em usabilidade em
empresas parceiras.
A partir das pesquisas realizadas no laboratrio, percebeu-se que um checklist
automatizado ofereceria apoio as avaliaes, pois o mesmo realiza avaliaes em diferentes
reas de conhecimento.
73
4.2 Anlise de softwares existentes
Uma das etapas do projeto foi anlise do estado da arte de ferramentas

disponibilizadas ao pblico aberto. Entre elas estudou-se o checklist oferecido pelo
Laboratrio de Utilizabilidade da Universidade Federal de Santa Catarina o Labutil.
Figura 15: Tela do sistema Ergolist

Fonte: Labutil (2006)
Observou-se na anlise que o referido checklist esttico e no varia por rea

de conhecimento, sendo que o mesmo apesar de gratito oferece aps sua utilizao apenas
um relatrio totalizador de erros e acertos como apresentado abaixo:
74
Figura 16: Tela do do sistema Ergolist

Fonte: Labutil (2006)
O contedo do checklist bastante genrico e classificado pelos critrios

ergonmicos de Bastien e Scapin. A generalidade do mesmo faz com que em muitos casos
torne-se ineficiente, pois no possvel selecionar ou adaptar-se as questes ao tipo de
interface que ser avaliada.
4.3 Histrico do Desenvolvimento
Finalizada a etapa de discusses iniciou-se a modelagem do projeto utilizandose a linguagem unificada UML descrita na integra no captulo 3. Para a definio e uso da
UML utilizou-se a ferramenta Enterprise Arquitect verso 4.00.
75
Aps a modelagem partiu-se para a seleo de tecnologias de desenvolvimento.
A seqncia de utilizao das ferramentas ocorreu conforme apresentado na figura 17.
Utilizou-se o PHP para tornar as pginas dinmicas na realizao de funes de
cadastramento, alterao, excluso, consulta e relatrios de avaliao.
O PHP uma linguagem de programao de computadores interpretada, livre e
muito utilizada para gerar contedo dinmico na Web. uma linguagem de fcil
aprendizado e de uso para scripts dinmicos. O PHP uma linguagem orientada objetos.
A linguagem surgiu por volta de 1994, como um subconjunto de scripts Perl
criados por Rasmus Lerdof. Com as adies de Zeev Suraski e Andi Gutmans, dois
programadores israelitas pertencentes ao Technion, Instituto Israelita de Tecnologia, que
reescreveram o Parser, era lanada em 1997 a PHP 3, hoje j possui a verso 4 e 5.
(WIKIPEDIA, 2006).
A linguagem extremamente modularizada, o que a torna ideal para instalao
e uso em servidores Web. muito parecida em tipos de dados, sintaxe e mesmo funes,
com a linguagem C e com a C++ (WIKIPEDIA, 2006).
O PHP significa: Hypertext Preprocessor, uma linguagem de criao
embutida em HTML no servidor. Ele tem pouca relao com o layout da pgina, a maior
utilizao do PHP invisvel para o usurio final, mas o resultado final do PHP HTML
(CONVERSE; PARK, 2001).
O mecanismo de script do PHP pode ser construdo no prprio servidor Web,
por ele ser um mdulo oficial http Apache, tornando a manipulao dos dados mais eficaz e
rpida, alm disso, o PHP e compatvel com vrias plataformas (CONVERSE, 2001).
A utilizao do Mysql ocorreu para armazenar categorias, recomendaes e
projetos.
76
O MySQL um sistema de gerenciamento de banco de dados (SGBD), que
utiliza a linguagem SQL (Structured Query Language - Linguagem de Consulta
Estruturada) como interface. O MySQL foi criado na Sucia por dois suecos e um
finlands: David Axmark, Allan Larsson e Michael "Monty" Widenius. O desenvolvimento
e manuteno empregam aproximadamente 70 profissionais no mundo inteiro, e mais de
mil contribuem testando o software, integrando-o a outros produtos, e escrevendo a respeito
do mesmo. (WIKIPEDIA, 2006).
O sucesso do MySQL deve-se em grande medida fcil integrao com o PHP
includo, quase que obrigatoriamente, nos pacotes de hospedagem de sites da Internet
oferecidos atualmente. Outra grande vantagem a de ter cdigo aberto e funcionar em
quase, todas as plataformas e sistemas operacionais. reconhecido pelo seu desempenho e
robustez e tambm por ser multi-tarefa e multi-usurio. (WIKIPEDIA, 2006).
O MySQL um servidor multi-usurio e multi-encadeado permitindo assim
que mltiplos usurios trabalhem com os dados ao mesmo tempo, fornecendo acesso rpido
aos dados e assegura que somente o usurio autorizado acesse o sistema SGBD. Alm disso
ele no possui custo, sob uma licena Open Source , e pode ser utilizado e muitos sistemas
UNIX e Windows (WELLING,2001) .
Utilizou-se do JavaScript para validao de campos e para tornar os
cadastramentos mais dinmicos, no sendo necessrio o reload na pgina para cada
insero.
JavaScript uma linguagem de programao criada pela Netscape - em 1995 -,
que a princpio se chamava LiveScript, para atender, principalmente, as seguintes
necessidades: validao de formulrios no lado cliente (programa navegador); interao
77
com a pgina. Javascript tem sintaxe semelhante a do Java, mas totalmente diferente no
conceito e no uso:
Oferece tipagem dinmica - tipos de variveis no so definidos;
interpretada, ao invs de compilada;
Possui timas ferramentas padro para listagens (como as linguagens de script,
de modo geral);
Oferece bom suporte a expresses regulares (caracterstica tambm comum a
linguagens de script).
Sua unio com o CSS (Cascading Style Sheets) conhecida como DHTML.
Usando o Javascript, possvel modificar dinamicamente os estilos dos elementos da
pgina em HTML. (WIKIPEDIA, 2006).
O Javascrpit uma linguagem interpretada onde o navegador executa cada
linha do script como a recebe. Ela inserida dentro de um programa HTML. Podendo
utilizar objetos predefinidos ou ento criar novos objetos de acordo com as necessidades
(MAKRON BOOKS, 2001).
As ferramentas utilizadas tiveram sua seleo a partir do conhecimento do
aluno.
78
Figura 17: Tecnologias utilizadas

O quadro a seguir mostra a verso, o fabricante e a utilizao de cada

ferramenta utilizada:
Ferramenta
Enterprise Arquitect
PHP
MySQL
JAVASCRIPT
Quadro 8: Tecnologias utilizadas

Verso
Fabricante
Utilidade
4.00
Sparx Systems Ferramenta UML
4
Programao
4.1
Banco de dados
Programao
79
4.4 Apresentao do sistema
Sero apresentadas a seguir as seqncias de interao do sistema na forma de

telas. A apresentao realizar-se- na seqncia do menu proposto A cada tela
apresentado um breve descritivo de suas funes.
A apresentao ser realizada a partir de dois mdulos principais:
o O mdulo de gerncia contendo os cadastros e de acesso limitado;
o O mdulo avaliador, de acesso irrestrito na Web.
4.4.1 Mdulo Gerncia
Os cadastros do checklist permitem a incluso, excluso e alterao de

categorias, recomendaes e projetos. O acesso de tais cadastros est limitado equipe do
laboratrio de usabilidade, no estando disponvel ao pblico em geral.
80
Figura 18: Pgina inicial

A pgina inicial apresenta o menu lateral com as opes: Categorias,

Recomendaes, Projetos, Avaliao, Associao projeto/recomendao.
A tela abaixo representa o cadastro de categorias onde cada projeto pode
cadastrar categorias de acordo com o domnio de informao do projeto:
81
Figura 19: Cadastro de categorias

Nesse cadastro o nico campo obrigatrio o nome da categoria. permitido

aos usurios o cadastramento de todas as categorias de seu projeto. A efetivao do
cadastro ocorre aps o clique no boto Enviar.
82
Figura 20: Cadastro de recomendaes

Para realizar o cadastro das recomendaes necessrio que haja uma categoria
cadastrada, pois as recomendaes esto vinculadas mesma. Os campos obrigatrios do
formulrio so: Categorias, Cdigo e a Recomendao. Se o campo obrigatrio no for
preenchido o boto Incluir no ativado. Caso no ocorra a incluso de nenhuma
recomendao o boto Enviar no habilitado. Os demais campos so opcionais para o
usurio.
83
Figura 21: Cadastro de projetos

No cadastro do projeto necessrio o preenchimento dos campos obrigatrios

que so: Cdigo e o Nome do Projeto.
84
Figura 22: Associao de recomendaes

Para proporcionar a reutilizao de recomendaes e categorias cadastradas na

base de dados, optou-se pela associao das recomendaes com um determinado projeto.
Aps o cadastro do projeto o usurio direcionado para essa tela onde seleciona o Projeto
desejado e a Categoria desejada. A partir deste momento so apresentadas ao usurio as
recomendaes daquela categoria selecionada. O usurio decide ento por meio do
checkbox se a recomendao aplicvel ao seu projeto ou no. Aps este passo define o
impacto que essa recomendao ter para o presente projeto. Tal impacto ser utilizado na
avaliao, gerando um relatrio especfico por grau de relevncia do atendimento da
recomendao.
85
Definiu-se para o uso do checklist uma tabela de impacto sobre a interface
conforme o Quadro 9:
Alto
Mdio Alto
Mdio
Mdio Baixo
Baixo
Quadro 9: Grau de impacto

Tem um alto comprometimento no projeto e a alterao
imprescindvel
Tem um alto comprometimento no projeto e a alterao
recomendada
Tem um mdio comprometimento no projeto e a alterao
recomendada
Tem um mdio baixo comprometimento no projeto e a
alterao recomendada mas no interfere no uso.
Tem um baixo comprometimento no projeto e a alterao
no fundamental.
A alterao ou excluso de uma categoria realizada a partir de sua seleo.
Figura 23: Alterao e excluso de categorias

86
Nesta opo so listadas as categorias cadastradas no banco de dados, com
limite de dez por tela. Caso existam mais de dez categorias cadastradas apresenta-se um
cone de avano para a prxima tela. Para a remoo de uma categoria no deve haver
nenhuma recomendao vinculada a ela, caso tenha apresentada uma messagem de
confirmao. Para atualizar uma categoria, deve-se clicar no cone de atualizao
apresentando a tela abaixo.
Figura 24: Alterao de categoria

Para realizar a alterao necessrio preencher os campos obrigatrios e clicar
no boto alterar.
87
Figura 25: Alterao e excluso de recomendaes

Para visualizar as recomendaes necessrio selecionar uma categoria.

Selecionada so apresentadas as recomendaes, com limite de dez por tela, vinculadas a
essa categoria. Para a remoo de uma recomendao a mesma no pode estar vinculada a
nenhum projeto, se estiver apresentada uma mensagem de confirmao. A atualizao da
recomendao ocorre aps o clique no cone de atualizao.
88
Figura 26: Alterao de recomendao


no boto alterar.
A excluso e alterao de projetos ocorrem a partir de sua seleo.
89
Figura 27: Alterao e excluso de projetos
So listadas os projetos cadastrados no banco de dados, com limite de dez por

tela. A seguir apresentada a tela de alterao:
Figura 28: Alterao de projeto

no boto alterar.
4.4.2 Mdulo Avaliao
O mdulo de avaliao est aberto para qualquer usurio, necessrio apenas

que o projeto desejado por esse usurio esteja cadastrado na base de dados. O usurio ao
acessar o sistema desejando realizar uma avaliao deve selecionar o tipo de projeto,
90
ambiente de Ensino a Distncia, Dispositivos Moveis, etc. No processo de uso do checklist
foram adotados os seguintes critrios de aceitao quanto recomendao:
Quadro 10: Critrio para avaliao
Descrio da Ao
a Quando o sistema avaliado atende a recomendao.
Ao
Atende
recomendao
No atende a Quando o sistema avaliado no est atendendo a
recomendao
recomendao.
No aplicvel ao Quando a recomendao no e aplicvel para aquele
projeto
sistema.
Para cada item possvel ao usurio digitar seu comentrio.

A tela abaixo apresenta o processo de avaliao:
Figura 29: Avaliao

91
Ao lado da recomendao apresentado um cone de informaes. Para as
recomendaes so mostrados trs campos:
Bibliografia: Referncia bibliogrfica da recomendao;
Exemplo: Acrescenta um exemplo positivo ou negativo da aplicao

daquela recomendao.
Critrio: O que a recomendao est realmente avaliando na interface.
Ao terminar a avaliao o usurio clica no boto enviar e gerado o relatrio

para aquela avaliao.
O relatrio gerado em arquivo pdf, o relatrio no armazenado pelo projeto,
ao gerar um outro relatrio o ltimo substitudo., ficando a critrio do usurio o
salvamento do pdf.
A tela abaixo apresenta o relatrio:
92
Figura 30: Relatrio de avaliao
apresentado no relatrio o projeto analisado, em seguida so listadas as

recomendaes no atendidas no projeto, seu respectivo comentrio se for digitado, e se
grau de impacto. Em seguida so apresentados os resultados em percentual conforme o
impacto. Finalizando apresentado o percentual por conformidade das recomendaes
atendidas e no atendidas, as que no so aplicveis ao projeto no so analisadas no
relatrio.
4.5 Validao
Segundo Sommerville (2003), a validao de software destina-se a descobrir se

um sistema est de acordo com as especificaes e se atende s expectativas do usurio.
Este procedimento verifica por reviso e inspees, os estgios do desenvolvimento do
software, at o usurio final.
O processo de validao do sistema deu-se em duas etapas distintas.
1) Validao de usabilidade com o autor e a orientadora;
2) Validao das funcionalidades com a equipe do laboratrio e outros
usurios.
4.5.1 Validao de usabilidade
93
Durante a validao de usabilidade, tomou-se como referncia a experincia do
autor do projeto, relacionados avaliao de interfaces web. Como descrita por Rubin
(1994) a tcnica utilizada para avaliao do projeto foi heurstica, j que a mesma
depende da experincia do avaliador.
Foi verificada a consistncia das telas, a preveno de erros, os rtulos e campos.
No primeiro momento foram alterados rtulos e as mensagens de orientao ao usurio
para ficarem mais significativas ao usurio. Aps essa verificao foram analisadas as cores
usadas no site, onde os rtulos foram alterados para preto, melhorando a legibilidade das
telas. Os campos de entrada foram aumentados.
A seqncia do menu foi alterada para melhor atender as expectativas do usurio.
4.5.2 Validao das funcionalidades
O presente trabalho foi submetido equipe do laboratrio de pesquisa em

usabilidade para utiliz-lo, a partir do checklist construdo baseando-se na norma ISO9241.
As recomendaes elaboradas pelo laboratrio foram digitadas no Glist. Ao iniciar-se o
cadastro percebeu-se que a dimenso do site era pequena para as entradas de dados, como
foi utilizado combobox, este no apresentava informaes maiores, foi necessrio ento o
redimensionamento da pgina. Campos single line foram alterados para multiple line para
no encobrirem informaes digitadas.
Finalizada a digitao das recomendaes, a equipe do laboratrio utilizou o sistema
para realizar as avaliaes de uma empresa parceira. Foi utilizado apenas o checklist da
94
parte 17 da norma ISO 9241, foram analisadas 10 telas. A figura 31 apresenta um recorte
desta avaliao.
Figura 31: Pgina inicial, Mdulo Avaliao.

Ao entrar no endereo 2 o usurio pode visualizar o resumo do trabalho, possui a
opo de enviar um e-mail para o autor do projeto, e ainda a opo de avaliao de projetos
cadastrados.
Caso o usurio possua permisso para cadastros e alterao ele acessa o link no
canto esquerdo da pgina onde consta acesso restrito.
Acessando a avaliao o processo o mesmo descrito na figura 29 no presente
projeto.
http://inf.unisul.br/~lpu/checklist
95
Figura 32: Validao do sistema

Figura 33: Validao do sistema 2

96
O uso do checklist automatizado durante a avaliao ocorreu sem problemas
sendo que o relatrio atingiu os resultados esperados. Foram observados todos os quesitos
funcionais e totalizadores sendo que o mesmo apresentou os resultados esperados.
4.6 Concluso
Nesta etapa descreveu a existncia de software na rea de avaliao de

usabilidade, e principalmente as tecnologias necessrias para o funcionamento do Glist.
Foi realizada a apresentao do sistema, na qual foram expostas as telas para
permitir o entendimento de como se d a utilizao da ferramenta. Ainda foram descritos
problemas encontrados na validao e como foram solucionados.
Por fim, encerra-se com a validao da ferramenta pelo laboratrio de pesquisa
em usabilidade, comprovando assim que os objetivos apresentados no incio do projeto
foram atendidos.
97
5 CONCLUSO
Durante o desenvolvimento do trabalho foi uma preocupao constante a
obteno de conhecimento sobre usabilidade e tcnicas de avaliao. Percebeu-se que
existem vrias formas de fazer uma avaliao de usabilidade, qualquer uma dessas
avaliaes, com suas peculiaridades, resolvem problemas relacionados usabilidade. Mas
raramente so utilizadas em empresas de software, por requerer conhecimento, tempo e
custo elevado de execuo.
O uso de checklist, no entanto um meio barato e eficiente de capturar
problemas de usabilidade. importante ratificar que sendo vivel mesmo que o funcionrio
no tenha o conhecimento sobre usabilidade. A usabilidade um elemento crtico para o
sucesso no mercado de informtica e a realizao dos testes de usabilidade um elemento
imprescindvel no projeto.
Ao validar o sistema comprovou-se a credibilidade do uso do checklist como
apoio avaliao em usabilidade realizada pelo laboratrio. Outro ponto a se observar a
democratizao de conceitos por meio de disponibilizao da ferramenta na internet para
avaliaes externas.
98
Alm do trabalho realizado para obteno do ttulo de Bacharel em Sistema de
Informao obteve-se durante o ano sua aprovao na forma de artigo no I Seminrio de
Iniciao Cientifica da ACAFE sendo este uma oportunidade de divulgao do trabalho
realizado.
Importante ainda salientar a satisfao de saber que o Glist atendeu seus
objetivos que est disponvel para o uso no endereo http://inf.unisul.br/~lpu/checklist A
obteno de conhecimento por parte do aluno em uma rea pouco trabalhada durante o
curso abre a oportunidade para a especializao em uma rea profissional emergente no
mercado o Engenheiro em Usabilidade.
Neste momento tratada a questo da continuidade do trabalho. So sugeridas
algumas incorporaes:
o Pesquisas de recomendaes para alimentao do mesmo, formando a base
de dados mais robusta e verstil.
o Incorporar novas funcionalidades, como outros critrios de busca, cadastro e
avaliao, a fim de agilizar os processos.
o Oferta do checklist no site e a validao de seu uso com usurios externos.
99
REFERNCIAS
BASTIEN, Christian, SCAPIN, Dominique. Ergonomic criteria for the evaluation of

human-computer interfaces. Racquencourt, France: INRIA, 1993.
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. Rio de

Janeiro: Campus, 2002.
BOOCH, Grandy. UML: guia do usurio: o mais avanado tutorial sobre Unified
Modeling Language (UML). Rio de Janeiro: Campus, 2000.
BROWNE, Dermot P., SUMMERSGILL, Robert, STRADLING, Phil. The user interface:
the poor relation in structured methods. In: Advances in human-computer interaction:
volume 3. Norwood: Ablex, 1992.
CONSTANTINE, Larry. L., LOCKWOOD, Lucy. A. D. Software for Use: A Practical

Guide to the Models and Methods of Usage-Centered Design, New York: ACM Press,
1999.
CONVERSE, Tim., PARK, Joyce. PHP4 A Bblia. Campus: Rio de Janeiro, 2001.
CYBIS, W. A. Ergonomia de interfaces homem-computador. Labtil, Programa de Psgraduao em Engenharia de Produo da Universidade Federal de Santa Catarina,
Florianpolis,
1999.
Apostila.
Disponvel
em
http://www.labutil.inf.ufsc.br/apostila/apostila.htm, acesso em 15/09/2005.
100
DE WAAL, M. E., VAN DER HEIDEN, Gerard. H. The evaluation of user-friendliness

in the design process of user interfaces. Human factors in information systems analysis
and design. Elsevier Science Publishers B.V., IFIP, p. 93-103, 1990.
DIAS, Cludia. Heursticas para avaliao de usabilidade de portais corporativos.

Disponivel em http://www.geocities.com/claudiaad/heuristicas_web.html. Acessado em 06
de outubro de 2005.
DIAS, Cludia. Usabilidade na web: Criando portais mais acessiveis, Alta Bodas, RS,
2003.
DIAS, Cludia. Mtodos de avaliao de usabilidade no contexto de portais

corporativos: um estudo de caso no Senado Federal. Braslia: Universidade de Braslia,
2001. 229p.
DIX, Alan. et al. Human-computer interaction. Cambridge: University Press, 1993.
ERGOLIST, Disponvel em http://www.labiutil.inf.ufsc.br/ergolist/index.html. Acessado

em 06 de outubro de 2005.
FISHER, G. Human-computer interaction software: lessons learned, challenges ahead.

IEEE Software. v. 6, n. 1, p. 44-52, 1989
HEEMANN, V. Avaliao ergonmica de interfaces de bases de dados meio de cheklist

especializado. Florianpolis, 1997. Dissertao (Mestrado Engenharia de Produo),
Universidade Federal de Santa Catarina.
HIX, Deborah, HARTSON, H. Rex. Developing user interfaces: ensuring usability

through product & process. John Wiley & Sons, 1993.
ISO 9241 Part 1(1993). Ergonomic requirements for office work with visual display
terminals, Part 1 General Introduction ; International Standard ISO 9241-1.
LUZZARDI, Paulo Roberto Gomes. Critrios de Avaliao de Tcnicas de Visualizao

de Informaes. Universidade Federal do Rio Grande do Sul, UFRGS, Porto Alegre.
Doutorado em Cincia da Computao 2003.
101
MATIAS, M. Checklist: uma ferramenta de suporte avaliao ergonmica de interfaces.

Florianpolis, 1995. Dissertao (Mestrado em Engenharia de Produo), Universidade
Federal de Santa Catarina.
NIELSEN, Jakob. Websites. Disponvel em http://www.useit.com. Acesso em 15 de

setembro de 2005.
NIELSEN, Jakob. Projetando websites. Rio de Janeiro: Campus, 2000.
Nielsen, Jakob. Design Web Usability: The Practice of Simplicity. New Riders Publish
1999.
NIELSEN, Jakob. Usability Engineering. New Jersey: Academic Press, 1993.
Ncleo tcnico e Editorial Makron Books. JavaScript Passo a Passo Lite. So Paulo,
Makron Books, 2001.
OLIVEIRA, Elaine Rosangela de. Avaliao ergonmica de interfaces da Scielo

Scientific Electronic Library Online. Florianpolis, 2001. Dissertao (Mestrado)
Universidade Federal de Santa Catarina.
OSF/Motif SYTLE GUIDE. Guia de estilos para interface com padro OSF/Motif,
Cambridge, USA, 1990, Open Software Foundation.
PARIZOTTO, Rosamelia. Guia de Estilos para Servios de Informao em Cincia e

Tecnologia via Web. Florianpolis, 1997. Dissertao (Mestrado) Universidade Federal
de Santa Catarina.
RUBIN, J. Handbook of usability testing: how to plan, design, and conduct effective
tests. New York: J. Wiley, 1994.
SILVA, Gleyson Cezar Leme. Avaliao de usabilidade visando o aumento da

interatividade
de
interfaces
de
web-sites:
2004.
Disponvel
em
http://geocities.yahoo.com.br/guns_gnr/. Acessado em 02 de outubro de 2005.
102
SILVEIRA, Mario Cesar. Checklist ergonmico: tcnica de inspeo de

conformidade ergonmica de software interativo voltado componentes.
Florianpolis,
2001.
Dissertao
(Mestrado)
Universidade
Federal
de Santa Catarina.
SCAPIN, D. L. Guide ergonomique de conception des interfaces home-machine.

Rocquencourt, France: INRIA, 1986.
SHNEIDERMAN, Ben. Designing the user interface - Strategies for effective

humancomputer interaction. 2.ed. Maryland: Addison-Wesley, 1992.
UNIVERSIDADE DO SUL DE SANTA CATARINA. Grupo de Metodologia

Cientfica.Caderno de metodologia: diretrizes para a elaborao e apresentao de trabalhos
acadmicos. 2. ed. rev. Tubaro, 2003. 96 p.
WELLING, Luke., THOMSON, Laura. PHP E MySQL: Desenvolvimento Web. Rio de

Janeiro: Campus, 2001.
WIKIPEDIA. Enciclopdia livre. Disponvel em http://pt.wikipedia.org/wiki. Acessado

em 22 de abril de 2006.
WINDOWS STYLE GUIDE. The Windows interface guidelines - A guide for designing
software, USA, 1995, Microsoft Corporation.

GList

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GList

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE DO SUL DE SANTA CATARINA

RAFAEL ORIVALDO LESSA

Glist Um Checklist Automatizado para Usabilidade

RAFAEL ORIVALDO LESSA

Glist Um Checklist Automatizado para Usabilidade

Monografia submetida Universidade do

Orientadora Vera Rejane Niedersberg Schuhmacher

RAFAEL ORIVALDO LESSA

Glist Um Checklist Automatizado para Usabilidade

Monografia submetida Universidade do

Universidade do Sul de Santa Catarina

Palhoa, de Junho de 2006.

A usabilidade busca apoiar o processo de interao com o usurio, transmitindo de

Palavras-chave: usabilidade, checklist, avaliao de usabilidade.

ABNT (Associao Brasileira de Normas Tcnicas)

3.2.4 CSU004 Gerncia de Teste ..................................................................................... 56

No nenhuma novidade dizer que a internet revolucionou o mundo, quando

Nielsen (1998) definiu usabilidade como uma medida da qualidade da experincia

Com a dependncia de tecnologia do mercado, os produtos desenvolvidos so

Outro problema que a maioria dos checklists disponveis manual, no

Este projeto se justifica pela possibilidade de oferecer aos desenvolvedores uma

A seguir so descritos os objetivos do projeto.

Desenvolvimento de um checklist automatizado para avaliao de usabilidade.

Os objetivos especficos deste trabalho so apresentados abaixo:

1.4 Arquitetura da Soluo

A proposta de soluo apresenta uma ferramenta de apoio a avaliao em

Figura 1: Proposta de metodologia de soluo

A arquitetura apresentada mostra de forma simplificada o processo de

1.4.1 Descrio dos Componentes da Arquitetura da Soluo do Problema

A seguir sero apresentados os componentes da arquitetura:

Quadro 1: Descrio de componentes

Este trabalho apresenta as seguintes delimitaes decorrentes:

1.6 Metodologia Cientfica

O delineamento da pesquisa quanto ao tipo, segundo a Universidade do Sul de

de caso e pesquisa bibliogrfica. Pelos procedimentos tcnicos classifica-se como uma

1.7 Estrutura da Monografia

Este projeto est subdividido em 5 captulos. A seguir, ser apresentada a

Este captulo apresenta a introduo, justificativa, objetivos, problemas e a

Neste captulo esto apresentadas as concluses e consideraes sobre a

o Flexibilidade permite o uso de aceleradores de aes. O boto de busca pode

Mas como conceber algo amigvel em tantas situaes diferentes? A adaptabilidade

Hix (1993) defende que o desenvolvimento de um sistema interativo deve contar

a) especialistas no domnio do problema: pessoas que possuem um profundo

b) projetistas de software de interface: profissionais da rea de informtica, projetistas

c) projetistas de interao com usurio: usurios, projetistas de interao, avaliadores,

Browne (1992) chama a ateno para o fato de que, atualmente, os sistemas tm

Segundo Hix (1993) a interao homem-computador deve constituir-se como uma

2.1 Tcnicas de avaliao

Segundo Dix (1993) a avaliao de usabilidade tem trs objetivos principais:

2.1.1 Preditivas ou analticas

Inspeo cognitiva - nesse mtodo de avaliao o analista desenvolve uma

percebidas, no apenas identificando os problemas, mas tambm sugerindo as

Avaliao heurstica - um mtodo de inspeo sistemtico, cujo objetivo

Inspeo de conformidade - baseada na confrontao com princpios,

Utilizabilidade da Universidade Federal de Santa Catarina, administra um

2.1.2 Objetivas ou empricas

Rubin (1994) afirma que as tcnicas objetivas buscam constatar os problemas a

Sistemas de monitoramento - os sistemas de monitoramento visam uma

Ensaios de interao - os ensaios de interao so testes realizados com os

acompanhados pelos avaliadores que analisaro os comandos dados, os erros

Rubin (1994) afirma que as tcnicas prospectivas buscam a opinio do usurio

Depois de terem sidos identificados os usurios tpicos, as tarefas tpicas e os

2.1.4 Mtodos de inspeo

A classificao oferecida por Ruben no uma unanimidade no meio cientifico