Inspeção de Usabilidade Aplicada A Métodos Ágeis PDF

SARAH FIGUEIREDO CAIXETA LEITE
INSPEO DE USABILIDADE APLICADA A

MTODOS GEIS:
UM ESTUDO DE CASO
LAVRAS MG
2013
SARAH FIGUEIREDO CAIXETA LEITE
INSPEO DE USABILIDADE APLICADA A MTODOS GEIS:

UM ESTUDO DE CASO
Monografia
de
Graduao
apresentada
ao
Departamento de Cincia da Computao da

Universidade Federal de Lavras como parte das
exigncias do curso de Sistemas de Informao
para obteno do ttulo de Bacharel em Sistemas de
Informao.
Orientador
Prof. DSc. Andr Pimenta Freire
LAVRAS MG
2013
AGRADECIMENTOS
Agradeo em primeiro lugar a Deus, que me deu a oportunidade de
viver e concluir esta fase da minha vida.
Agradeo aos meus pais, Marcos e Monica, pelo apoio incondicional,
pela compreenso, pelas conversas e sucos de laranja.
Agradeo aos amigos que me acompanharam nesta jornada, Vernica,
Ana Paula, Giancarlo, Guilherme, Fred, Gustavo Monteiro, Gustavo
Vale, lvaro, Joo Marcos, Samara, Andr e Brbara, ao quase irmo
Julio e o grande amigo Netto, sem os quais tudo isto seria em vo.
Aos amigos da Mitah Technologies, Mariana, Zanzini, Leandro, Tiago, Gabriel, Nilson, Ricardo, dentre outros, que me acompanharam
tambm no aprendizado profissional, eu agradeo por tudo.
Agradeo ao meu orientador Andr Pimenta por toda a ateno durante o projeto, e tambm Juliana Greghi, que me prestou grande
apoio. Aos amigos Mariana e Urlan, agradeo pelos conselhos na
execuo do projeto.
todos que de alguma forma participaram deste momento, meus
agradecimentos.
RESUMO
Empresas que utilizam mtodos geis de desenvolvimento tm grande preocupao com a qualidade do produto entregue. A usabilidade um requisito importante
da qualidade do software. No entanto, muitas empresas tm dificuldade para integrar processos de usabilidade s prticas geis utilizadas. Poucos estudos j foram
feitos com este tema, e eles mostram que ainda h muito trabalho a ser feito para
chegar integrao adequada dos processos geis e de usabilidade. Este trabalho prope o estudo da utilizao da avaliao heurstica de um sistema Web no
contexto de uma empresa de pequeno porte de desenvolvimento de software que
utiliza o mtodo gil Scrum. Para isto foi realizado um estudo com a aplicao na
empresa de duas verses da avaliao heurstica: a avaliao tradicional e a colaborativa, que foram utilizados por duas equipes da empresa com nveis equivalentes de experincia com usabilidade. A avaliao heurstica colaborativa mostrou
tendncia a encontrar problemas de usabilidade mais srios e tambm teve aceitao pelos participantes do estudo, apesar de no ter encontrado um nmero maior
de problemas do que a avaliao heurstica tradicional. Conclui-se que a abordagem colaborativa da avaliao heurstica adequada para inspeo de usabilidade
em ambientes geis de desenvolvimento, podendo trazer ganhos de produtividade,
bem como de compartilhamento de conhecimento entre membros da equipe de
desenvolvimento e melhor alinhamento para integrao em processos com ciclos
iterativos.
Palavras-Chave: Avaliao Heurstica, Usabilidade, Mtodos geis, Interao
Humano-Computador, Engenharia de Software.
ABSTRACT
Companies using agile development methods are concerned about delivering quality software products. Usability is an important software quality requirement.
However, a number of companies have difficulties integrating usability processes
with agile practices. Few studies have been conducted about this topic. The studies conducted so far have suggested that there is a significant amount of work to
be done in order to achieve the appropriate integration between agile and usability
processes. The present work proposed the study of the use of heuristic evaluation of a Web site in the context of a small software development company that
uses the Scrum agile method. In order to accomplish this goal, a case study was
designed and conduted to compare the use of two versions of the heuristic evaluation method: the standard and the collaborative version, which were performed
by two different teams of evaluators from the company with equivalent usability
expertise levels. The results showed that the collaborative evaluation tended to
find more serious usability problems than the standard version of the method. It
also had good acceptance from the participants, despite the fact that it did not find
more usability problems than the standard evaluation. It was concluded that the
collaborative version of the heuristic evaluation is suitable for usability inspection
in agile development environments. It enabled achieving productivity gains, as
well as knowledge sharing between members of the development team and better
alignment for integration in processes with iterative cycles.
Keywords: Heuristic Evaluation, Usability, Agile Methods, Human-Computer Interaction, Software Engineering.
SUMRIO
Introduo
11
1.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2
Organizao da Monografia . . . . . . . . . . . . . . . . . . . . . . .
14
Referencial Terico
2.1
15
Mtodos geis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1.1
Princpios do Desenvolvimento gil . . . . . . . . . . . . . . . . .
16
2.1.2
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Avaliao de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.1
Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.2
Inspeo de Usabilidade . . . . . . . . . . . . . . . . . . . . . . .
22
2.2.2.1
Avaliao Heurstica . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2.2.2
Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . .
25
2.2.2.3
Percurso Cognitivo . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2.2.4
Inspeo Semitica . . . . . . . . . . . . . . . . . . . . . . . . .
28
Heursticas para sistemas Web de Petrie e Power (2012) . . . . . .
29
Avaliao de Usabilidade em Mtodos geis . . . . . . . . . . . . .
29
2.2
2.2.3
2.3
3
Mtodos
33
3.1
Tipo de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2
Procedimentos Metodolgicos . . . . . . . . . . . . . . . . . . . . .
33
3.2.1
Desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.2
Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3
Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.2.4
Procedimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.4.1
Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.4.2
Avaliao Tradicional . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.4.3
3.2.5
4
Avaliao Colaborativa . . . . . . . . . . . . . . . . . . . . . . .
39
Anlise de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Resultados e Discusso
4.1
42
Violaes das Heursticas nas Avaliaes . . . . . . . . . . . . . . . .
42
4.1.1
Avaliao Heurstica Tradicional . . . . . . . . . . . . . . . . . . .
42
4.1.2
Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . . .
49
4.1.3
Comparao entre as violaes das heursticas nas duas verses de

avaliao heurstica . . . . . . . . . . . . . . . . . . . . .
50
4.2
Nmero de Problemas Encontrados
. . . . . . . . . . . . . . . . . .
51
4.3
Severidades dos problemas encontrados . . . . . . . . . . . . . . . .
52
4.3.1
Avaliao Heurstica Tradicional . . . . . . . . . . . . . . . . . . .
52
4.3.2
Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . . .
53
4.3.3
Comparao entre as severidades dos problemas encontrados nas

duas verses do mtodo . . . . . . . . . . . . . . . . . .
54
4.4
Anlise do Processo de Avaliao . . . . . . . . . . . . . . . . . . .
55
4.5
Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.5.1
Nmero de problemas encontrados nas duas verses do mtodo . .
58
4.5.2
Severidade dos problemas encontrados exclusivamente por um ou

outro mtodo . . . . . . . . . . . . . . . . . . . . . . . .
60
4.5.3
Produtividade da avaliao heurstica tradicional e colaborativa . . .
60
4.5.4
Dificuldades para a atribuio de graus de severidade . . . . . . . .
61
4.5.5
Utilizao das heursticas nas avaliaes . . . . . . . . . . . . . . .
61
4.5.6
Adequao do mtodo de avaliao heurstica colaborativa para mtodos de desenvolvimento gil . . . . . . . . . . . . . . .
Concluses
A Heursticas utilizadas para as avaliaes
62
64
71
B Planilhas utilizadas nas avaliaes
73
B.1 Planilha de identificao de problemas . . . . . . . . . . . . . . . . .
73
B.2 Planilha das severidades dos problemas . . . . . . . . . . . . . . . .
74
C Questionrios Utilizados
75
C.1 Questionrio demogrfico . . . . . . . . . . . . . . . . . . . . . . . .
75
C.2 Questionrio da avaliao tradicional . . . . . . . . . . . . . . . . . .
76
C.3 Questionrio da avaliao colaborativa . . . . . . . . . . . . . . . . .
77
LISTA DE TABELAS
2.1
As Dez Heursticas de Nielsen . . . . . . . . . . . . . . . . . . . . .
23
4.1
Nmero de violaes de heursticas na avaliao realizada pelo AT1 .
44
4.2
46
4.3
47
4.4
Nmero de violaes por grupo de heursticas aps a sesso de consolidao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
48
Nmero de violaes por grupo de heursticas na avaliao colaborativa 50
LISTA DE FIGURAS
2.1
Exemplo de grfico Burndown . . . . . . . . . . . . . . . . . . . . .
2.2
Proporo dos problemas de usabilidade encontrados em uma inter-
20
face em relao ao nmero de avaliadores. Fonte: Nielsen (2000) .
25
4.1
Problemas encontrados nas duas abordagens . . . . . . . . . . . . . .
51
4.2
Severidade dos problemas encontrados na avaliao tradicional . . . .
52
4.3
Severidade dos problemas encontrados na avaliao colaborativa . . .
53
11
1 INTRODUO
Atualmente muitas organizaes tm optado pela adoo de processos e
prticas geis de desenvolvimento. A escolha de uma empresa por mtodos geis
vem principalmente pela sua capacidade de responder mais facilmente s mudanas de requisitos durante o desenvolvimento do software (SOARES, 2004). Esta
competncia de resposta agrega valor ao produto, uma vez que os processos de
uma empresa no so imutveis, e o cliente espera que o sistema que ser entregue
atenda s suas reais necessidades, no as necessidades de quando o contrato foi
assinado.
Alguns motivos do crescimento da adoo de prticas geis podem ser vistos em pesquisa realizada por Ambler (2008) sobre a adoo de desenvolvimento
gil de software. Nesta pesquisa afirmado que, em comparao com equipes tradicionais, em 22% dos casos a produtividade de equipes geis maior, em 29%
dos casos a qualidade melhor e em 31% dos casos os stakeholders esto mais
satisfeitos.
Segundo Crespo et al. (2004), atualmente existe uma demanda por
software de qualidade. Em um ambiente onde os requisitos mudam com grande
freqncia, organizaes sofrem grande presso para atender a esta demanda em
curtos espaos de tempo. Neste contexto, as empresas tendem a optar por processos geis de desenvolvimento.
Para Nerur, Mahapatra e Mangalaraj (2005) na adoo de mtodos geis a
organizao tem que repensar seus objetivos e reorganizar os componentes humanos, gerenciais e tecnolgicos.
Para garantir a qualidade do produto desenvolvido, a avaliao de usabilidade muito importante. A importncia da usabilidade relatada na ISO/IEC
(2005). No entanto Seffah e Metzker (2004) ressaltam que tcnicas de design centrado no usurio ainda so pouco conhecidas, pouco usadas e consideradas difceis
de dominar pelos desenvolvedores de software.
12
Objetivos de usabilidade do sistema incluem desempenho e satisfao do
usurio em determinados contextos de uso (ISO, 2002). Um erro muitas vezes
cometido pensar que usabilidade apenas a decorao do sistema, que fica por
cima do sistema real. Este pensamento leva desenvolvedores a deixar requisitos
de usabilidade para o final do projeto, o que acaba comprometendo o resultado
final. A preocupao com usabilidade deve estar presente em todas as fases do
desenvolvimento do software (SEFFAH; METZKER, 2004).
Seffah e Metzker (2004) apontam que estudos empricos sobre engenharia
de software mostram que, na maioria dos casos, mesmo quando uma empresa desenvolve boas prticas de integrao entre Interface Humano-Computador e Engenharia de Software, estas prticas no so publicadas. As empresas no costumam
ter a preocupao de documentar estas prticas, nem mesmo internamente.
Winter et al. (2011), Barbosa, Furtado e Gomes (2008), Nielsen e Madsen (2012) dentre outros, realizaram estudos sobre a integrao entre processos
de usabilidade e processos geis. Estudos mostram que as empresas ainda tm
dificuldade em integrar estes processos. Nielsen e Madsen (2012) relatam que
os profissionais esto empenhados para fazer os processos geis e de usabilidade
funcionarem em conjunto.
Desta forma, mostrou-se relevante o estudo da aplicao da avaliao heurstica no ambiente de uma empresa de desenvolvimento de software.
Avaliao heurstica um mtodo de anlise de usabilidade onde um nmero de avaliadores apresentado a uma interface para que comentem sobre a
mesma considerando um conjunto de heursticas (NIELSEN; MOLICH, 1990). Avaliao heurstica um mtodo de inspeo muito conhecido e aceito por especialistas, como mostra Buykx (2009). Em sua dissertao, Buykx (2009) apresenta a
avaliao heurstica colaborativa, que uma variao da avaliao heurstica com
foco no trabalho em grupo para diminuio da duplicao e aumento da produtividade.
13
Poucos autores relataram experincias com a avaliao heurstica colaborativa. Dentre eles, pode-se citar Buykx (2009) e Babajo (2012). O conhecimento
sobre a aplicao da avaliao heurstica colaborativa em pequenas empresas
limitado. Alguns estudos mostram a utilizao de mtodos de inspeo de usabilidade em ambientes geis de desenvolvimento. Estes estudos mostraram que em
ambientes onde so utilizados mtodos geis ainda h muitos problemas a serem
resolvidos quanto integrao com prticas de usabilidade.
So raros os estudos de caso mostrando como a avaliao heurstica aplicada em empresas que utilizam metodologias de desenvolvimento geis. Desta
forma, a proposta deste trabalho foi efetuar um estudo de caso comparando a utilizao de mtodos de inspeo baseados em avaliao heurstica, nas suas verses
tradicional e colaborativa, em uma empresa de pequeno porte que utiliza um mtodo gil.
1.1
Objetivos
O objetivo geral deste trabalho analisar a utilizao da avaliao heurs-
tica tradicional e a avaliao heurstica colaborativa em uma pequena empresa de

desenvolvimento de software que utiliza o mtodo gil Scrum.
Entre os objetivos especficos deste trabalho esto:
Observar a quantidade de problemas encontrados na avaliao heurstica tradicional e na avaliao heurstica colaborativa.
Analisar os graus de severidade obtidos na avaliao heurstica colaborativa.
Analisar o tempo gasto para a consolidao de resultados na avaliao heurstica tradicional.
Investigar prs e contras da utilizao da avaliao heurstica tradicional e a
avaliao heurstica colaborativa no desenvolvimento gil.
14
1.2
Organizao da Monografia
No Captulo 2 conceituado o tema do trabalho, apresentando mtodos
geis, com nfase em Scrum, avaliao de usabilidade, tcnicas de inspeo e avaliao de usabilidade em mtodos geis.
O Captulo 3 apresenta o tipo de pesquisa realizada e os procedimentos
metodolgicos, incluindo o desenho da pesquisa e detalhes do procedimento.
O Captulo 4 apresenta os resultados do trabalho, e no Captulo 5 so
relatadas as concluses da monografia.
15
2 REFERENCIAL TERICO
Neste so apresentados conceitos fundamentais para o entendimento do
trabalho desenvolvido.
Na Seo 2.1 so apresentados conceitos de mtodos geis, com enfoque no Scrum, mtodo utilizado na empresa onde o estudo de caso foi executado.
A Seo 2.2 apresenta conceitos de avaliao de usabilidade, mtodos de inspeo de usabilidade e uma descrio aprofundada do mtodo avaliao heurstica,
em suas verses: tradicional e colaborativa. A Seo 2.3 mostra como questes
de usabilidade tm sido tratadas nas empresas atualmente e apresenta estudos da
utilizao de processos de usabilidade no contexto de mtodos geis.
2.1
Mtodos geis
Nesta seo abordada a filosofia e as prticas dos mtodos geis. O foco
desta seo o mtodo Scrum, que foi utilizado no estudo de caso descrito.
Durante o desenvolvimento de um software podem ocorrer mudanas nos
requisitos. A equipe tem que estar preparada para lidar com mudanas. Desta
forma, o processo de desenvolvimento no pode estar engessado, amarrado a um
contrato que no pode ser alterado. necessrio que o mtodo de desenvolvimento seja flexvel para receber bem as alteraes de requisitos durante o desenvolvimento (FOWLER, 2005).
Segundo Fowler (2005) o movimento gil teve incio em 2001, quando
dezessete pessoas que tinham experincia com desenvolvimento de software por
alguns anos se reuniram devido ao seu interesse em uma nova abordagem sobre
a forma de desenvolver software. Eles concordavam que os mtodos tradicionais
de desenvolvimento de software no eram to produtivos, e tinham ideias de como
melhorar esta situao.
16
No workshop organizado em 2001, os dezessete participantes escreveram
o Manifesto gil (BECK et al., 2001), que descreve clara e sucintamente os ideais
do movimento gil. As premissas descritas no manifesto so:
Indivduos e interaes mais que processos e ferramentas.
Software em funcionamento mais que documentao abrangente.
Colaborao com o cliente mais que negociao de contratos.
Responder a mudanas mais que seguir um plano.
2.1.1
Princpios do Desenvolvimento gil

Shore e Warden (2008), descrevem cinco princpios do Extreme Program-
ming, que so vlidos tambm para outros mtodos geis, so eles:

Coragem: para tomar as decises certas e dizer a verdade aos stakehoders
quando necessrio.
Comunicao: para dar s pessoas informaes corretas, para serem usadas
em sua vantagem.
Simplicidade: para descartar coisas que queremos, mas no precisamos.
Feedback: para tirar lies em toda oportunidade que tivermos.
Respeito: tratar uns aos outros com dignidade, reconhecendo suas competncias.
importante entender o projeto, e como o processo de desenvolvimento
o afeta. Para isso, deve-se usar o feedback, para entender o que funciona e o que
no funciona. A integrao do time crucial para isto, quando algum aprender
algo, deve passar para os outros, assim como quando tiver dvidas, deve procurar
algum com conhecimento para ajud-lo.
17
Os indivduos envolvidos nos processos so muito valorizados em ambientes geis. De acordo com Taniguchi & Correa (TANIGUCHI; CORREA, 2009), em
mtodos geis importante que as pessoas sejam competentes e motivadas, para
isto elas participam nas decises e gesto de tarefas. Para produzir bons resultados, necessrio que os envolvidos trabalhem juntos. Ambientes geis incentivam
comunicao e bom relacionamento entre os membros do time (SHORE; WARDEN,
2008).
Na prtica, as reunies dirias so o principal momento onde as informaes so trocadas, alguns ficam sabendo o que os outros esto fazendo, as dificuldades que esto tendo e, assim, podem ajudar e aprender. Estas reunies tambm
so uma forma de incentivar o relacionamento entre a equipe.
De acordo com Taniguchi e Correa (2009), um dos valores principais no
Scrum a caracterstica de se preocupar com a gesto do projeto e no com processos e controles. Assim com o Scrum possvel descobrir pontos falhos nos
processos e como corrigi-los.
Quando se trabalha com mtodos geis, no se deve ter medo de mudanas: se uma alterao necessria, deve ser feita. O ambiente e os requisitos
sofrem mudanas, assim sendo, processo tem que se adaptar (HIGHSMITH, 2002).
Ocasionalmente uma mudana pode tornar o processo pior, mas o mais importante
que o time de desenvolvimento seja flexvel. O time tem a coragem de experimentar, mesmo que em algum momento falhe (SHORE; WARDEN, 2008).
necessrio encontrar um balanceamento entre planejamento e adaptao
(HIGHSMITH, 2002). Num ambiente com muito planejamento e pouca adaptao
a empresa no responde ao ambiente externo, ao passo que na situao inversa h
muita oscilao sem resultado. Este balanceamento uma das maiores barreiras
para empresas que comeam a usar mtodos geis.
O Manifesto gil (BECK et al., 2001) tem dois princpios que dizem respeito previsibilidade e adaptabilidade. Estes princpios dizem que mudanas
18
nos requisitos podem ser feitas, mesmo que num estado avanado do desenvolvimento. Processos geis usam das mudanas para obter vantagem competitiva.
As melhores arquiteturas, requisitos e designs vm de times de desenvolvimento
auto-organizados.
Um dos objetivos dos mtodos geis eliminar perdas, e para isto importante dividir o trabalho em pequenas tarefas. Dividindo o trabalho em partes
menores, a execuo de cada parte mais rpida, e reduz as possibilidades de erros para as alteraes mais recentes(HIGHSMITH, 2002). Tarefas pequenas so de
mais fcil compreenso, desta forma o time no far atividades que estejam fora
do escopo, que so tarefas desnecessrias.
Para eliminar perdas, tambm importante saber quando desistir, ou mudar
o escopo do projeto para algo que possa ser realizado. necessrio estar sempre
a par do andamento do projeto, para que medidas corretivas, se necessrias, sejam
tomadas o mais rpido possvel, diminuindo ao mximo as perdas.
Os mtodos geis mais conhecidos so: Scrum (HIGHSMITH, 2002), Extreme Programming (BECK, 2000), Crystal Methods (COCKBURN, 2004) , Lean
Development (POPPENDIECK; POPPENDIECK, 2003), Dynamic Systems Development (STAPLETON, 1997), Feature-Driven Development (PALMER; FELSING, 2001)
e Adaptive Software Development (HIGHSMITH III, 2000).
2.1.2
Scrum
Highsmith (2002) diz que no desenvolvimento de software no h como
definir um plano exato do que ser entregue, quando, e quanto vai custar, no entanto, possvel definir um processo para monitoramento e gerenciamento, observando de perto o processo de desenvolvimento. A ideia do Scrum definir um
processo onde seja valorizada a comunicao, colaborao e compartilhamento de
conhecimento entre os membros da equipe.
19
Algumas das prticas do Scrum so Backlog e Sprint (NASCIMENTO,
2007). Sprints so iteraes do projeto, que duram por volta de trinta dias, e Backlog consiste em uma lista das atividades a ser realizadas durante o projeto. No
incio de um Sprint feita uma reunio de planejamento, na qual so selecionados
determinados itens do Backlog que sero executados no perodo.
A imprevisibilidade do ambiente de desenvolvimento de software pode
dificultar o trabalho da equipe de desenvolvimento. No Scrum os requisitos selecionados para um Sprint no podem ser alterados no decorrer do mesmo. Os requisitos especificados ao incio do perodo continuam imutveis at que seja entregue
esta parte do produto (HIGHSMITH, 2002). Para uma prxima iterao alteraes
podem ser feitas.
Nos ambientes de desenvolvimento que utilizam Scrum realizada diariamente uma reunio em que o time relata o que foi feito, o que est fazendo,
e quais as dificuldades que est encontrando, desta forma todos ficam cientes do
andamento do desenvolvimento e tambm incentivado o compartilhamento do
conhecimento, medida que cada membro do time tem a oportunidade de auxiliar
e aprender com os outros.
Ao fim de um Sprint realizada uma reunio onde so apresentados os
resultados. Nela analisado o que foi feito no perodo, como anda o projeto de
acordo com o cronograma, e podem ser demonstradas as funcionalidades que foram implementadas (HIGHSMITH, 2002).
O grfico Burndown um artefato utilizado no Scrum para demonstrao
do andamento do projeto. Ele representa o quanto resta do Backlog em relao ao
tempo disponvel para finalizar o projeto (TANIGUCHI; CORREA, 2009). A Figura
2.1 apresenta um exemplo de grfico Burndown.
20
Figura 2.1: Exemplo de grfico Burndown
2.2
2.2.1
Avaliao de Usabilidade
Usabilidade
A ISO 9241 (ISO, 2002) traz definies e orientaes importantes para a
usabilidade. Ela define usabilidade como uma medida na qual um produto pode
ser usado por usurios especficos para alcanar objetivos especficos com eficcia, eficincia e satisfao em um contexto especfico de uso. Esta norma ISO
ainda contm orientaes para aquisio, projeto, desenvolvimento, avaliao e
comunicao da informao sobre usabilidade.
Outra norma que tambm possui contedos sobre usabilidade a ISO
25000 (ISO/IEC, 2005). Ela define usabilidade como a capacidade de um usurio alcanar determinados objetivos com efetividade, eficincia e satisfao em
21
situaes especificadas. Segundo a referida norma ISO, usabilidade constituda,
dentre outros, de apreensibilidade, flexibilidade, acessibilidade, reconhecibilidade,
facilidade de uso, proteo contra erros do usurio, esttica da interface com o
usurio e conformidade com convenes e regulamentaes relacionadas usabilidade.
Apreensibilidade a capacidade de o software ser aprendido pelo usurio.
Flexibilidade a usabilidade e segurana em contextos diferentes dos identificados inicialmente. Acessibilidade a usabilidade e segurana para usurios com
determinadas deficincias. Reconhecibilidade o grau de informao provida que
possibilita ao usurio reconhecer se o software apropriado para as suas necessidades. Facilidade de uso diz respeito possibilidade do usurio operar e controlar
o produto. Proteo contra erros o grau no qual o sistema protege o usurio de
cometer erros. Esttica da interface o quanto o produto de software atraente ao
usurio. Conformidade quanto usabilidade o produto estar de acordo com normas, converses, guias de estilo ou regulamentaes relacionadas usabilidade.
(ISO/IEC, 2005)
Holzinger (2005) menciona algumas outras caractersticas que, para ele,
devem ser parte de qualquer projeto de software: Eficincia: possibilitar que o
usurio tenha alta produtividade; Memorizao: possibilitar que usurio casual retorne ao sistema depois de um longo perodo e no precise reaprender tudo; Baixa
taxa de erro: no possibilitar erros catastrficos ocorram, e quando ocorrerem erros, que eles sejam recuperveis; e Satisfao: fazer o sistema agradvel.
Para avaliar a usabilidade de um sistema podem ser utilizados mtodos
de inspeo ou de observao. Barbosa e Silva (2010) citam como mtodos de
observao o teste com usurios e a avaliao de comunicabilidade. J os mtodos
de inspeo so realizados por especialistas.
Gutwin e Greenberg (2000) descrevem que a realizao de testes observacionais feita atravs da anlise de como as pessoas efetuam determinadas tarefas
22
em um sistema. De acordo com Buykx (2009), por envolverem usurios do sistema, testes com usurios tendem a exigir mais esforos e ser mais caros (BUYKX,
2009). Apesar do alto custo, Holzinger (2005) afirma que testes com usurios
finais so, de certa forma, indispensveis. Testes com usurios provem informaes diretas sobre como as pessoas utilizam o sistema e seus problemas com
determinadas interfaces.
Para Buykx (2009), mtodos de inspeo despertam interesse porque podem aprimorar a usabilidade antes de o sistema ser exposto ao teste com usurios.
2.2.2
Inspeo de Usabilidade
Existem vrios mtodos de inspeo de usabilidade. Alguns conhecidos
so: Avaliao Heurstica, Percurso Cognitivo e Inspeo Semitica. Neste trabalho ser utilizada a avaliao heurstica, portanto os outros mtodos sero descritos
brevemente.
2.2.2.1
Avaliao Heurstica
Segundo Barbosa e Silva (2010), um mtodo de avaliao de Intera-
o Humano-Computador (IHC) criado para encontrar problemas de usabilidade.

Nielsen (1994) explica que na avaliao heurstica um conjunto de avaliadores inspeciona a interface com base em um pequeno conjunto de princpios, chamados de
"heursticas". Esta inspeo sistemtica da interface busca problemas que prejudiquem a usabilidade, e considerada uma alternativa mais rpida e de baixo custo
comparada a mtodos empricos.
Nielsen (1994) apresenta um conjunto de heursticas que representam uma
sntese de vrios outros conjuntos existentes da poca do referido estudo. O objetivo de Nielsen ao elaborar esta lista foi reunir as heursticas de forma a encontrar
um conjunto que melhor explique os problemas existentes em sistemas reais. Ele
23
avaliou 101 heursticas, que descreviam 249 problemas de usabilidade e chegou
uma lista de dez heursticas, descritas na Tabela 2.1.
Tabela 2.1: As Dez Heursticas de Nielsen
Heurstica
Descrio
1. Visibilidade do status do sistema
O sistema deve manter o usurio informado sobre

o que est acontecendo.
2. Relacionamento entre o sistema
Devem ser seguidas converses do mundo real, as
e o mundo
informaes devem aparecer em ordem natural e

lgica.
3. Controle do usurio e liberdade
Se o usurio realizar uma ao indesejada, ele

deve poder desfaz-la.
4. Consistncia e padres
As mesmas aes devem ser nomeadas da mesma

forma, devem ser seguidos padres.
5. Preveno de erros
Deve-se eliminar situaes onde possam ocorrer

erros. Se isto no for possvel, deve-se ter uma
opo de confirmao da ao.
6. Reconhecer ao invs de relem-
Deixar visveis objetos, aes e opes. Instru-
brar
es devem ser visveis e fceis de recuperar.
7. Flexibilidade e eficincia de uso
Usurios especialistas devem ter aes facilitadas.
8. Esttica e design minimalista
Mostrar somente informaes realmente necessrias.
9.
Auxlio aos usurios para re-
Mensagens de erro devem ser mostradas em lin-
conhecer, diagnosticar e recuperar
guagem simples e indicar precisamente qual o
aes erradas
erro.
10. Ajuda e documentao
O sistema deve oferecer alguma forma de documentao e a busca por informaes deve ser facilitada.
24
Em sua concepo inicial a avaliao heurstica determina que cada especialista em usabilidade avalie a interface sozinho. Depois que todos terminarem
os avaliadores participam de uma reunio de consolidao de resultados, onde eles
compartilham as avaliaes (HOLZINGER, 2005). Este formato de avaliao conhecido como avaliao heurstica tradicional.
Durante uma seo de avaliao o avaliador percorre a interface vrias
vezes. Ele inspeciona vrios elementos, comparando-os com princpios de usabilidade reconhecidos. Quando o avaliador encontra um possvel problema de usabilidade, ele o registra. Segundo Babajo (2012) a execuo individual da avaliao
da interface pode contar com a participao de um facilitador, que fica responsvel
por registrar e reunir os problemas e tratar dos nveis de severidade.
Os princpios de usabilidade devem estar adequados ao sistema avaliado,
portanto podem variar na avaliao de sistemas diferentes (HOLZINGER, 2005).
Aps a realizao das sesses de avaliao, as listas de problemas de cada
avaliador so reunidas, com os problemas duplicados identificados e removidos.
Babajo (2012) recomenda que a mesma pessoa que desempenhou o papel de facilitador durante as sesses realize este processo.
Depois que os problemas foram reunidos, todos os avaliadores se renem
para classificao das severidades. Babajo (2012) esclarece que se no for possvel
que todos os participantes estejam presentes, pelo menos quatro devem estar. Nesta
sesso os avaliadores classificam as severidades dos problemas de 1 a 4, onde 1
considerado problema cosmtico e quatro uma catstrofe. A severidade definida
para um problema aquela que todos os avaliadores concordarem.
Vrios autores, como Nielsen e Mack (1994) e Holzinger (2005), consideram que o nmero de avaliadores necessrio entre trs e cinco. A Figura 2.2,
retirada de Nielsen (2000) mostra a relao entre o nmero de avaliadores e os
problemas encontrados em relao ao total. De acordo com Nielsen (2000), na
maioria dos casos a utilizao de mais que cinco avaliadores no apresenta bom
25
custo-benefcio. No necessrio que os avaliadores sejam especialistas, no entanto isto interferir nos resultados.
Figura 2.2: Proporo dos problemas de usabilidade encontrados em uma interface em relao ao
nmero de avaliadores. Fonte: Nielsen (2000)
Dentre as vantagens da avaliao heurstica esto a utilizao de princpios

reconhecidos, intuitividade, usabilidade em todo o processo de desenvolvimento e
identificao efetiva de problemas. Como desvantagens pode-se citar a separao
dos usurios finais e o fato de que no h garantia que todo o design seja avaliado
(HOLZINGER, 2005).
2.2.2.2
Avaliao Heurstica Colaborativa

A avaliao heurstica tambm pode ser realizada de forma colaborativa.
Nesta modalidade, os participantes realizam a avaliao como um time(DANINO,

2001).
Babajo (2012) ressalta que quando um grupo de avaliadores trabalha individualmente no mesmo sistema, h uma tendncia de encontrar problemas duplicados quando uma comparao feita. Ele cita que a realizao de avaliao
26
em conjunto pode ser mais efetiva devido s contribuies de vrios avaliadores
juntos.
Na dissertao de Buykx (2009) utilizada a avaliao heurstica colaborativa. Babajo (2012) considera o mtodo de Buykx (2009) mais efetivo, eficiente e
interessante para avaliadores especialistas. Os resultados da dissertao de Buykx
(2009) mostram que com a utilizao da avaliao colaborativa possvel obter
resultados substancialmente mais confiveis do que com a avaliao heurstica tradicional.
Buykx (2009) descreve a realizao da avaliao heurstica colaborativa.
Nela, utilizado um projetor para que todos os participantes avaliem juntos as
interfaces. Somente um dos participantes, denominado piloto, opera o sistema,
e somente um participante registra os problemas encontrados. Cada participante
preenche uma planilha com as severidades dos problemas.
Todos os participantes tm acesso ao os problemas que so registrados,
e podem opinar sobre a forma que o item registrado. No entanto, no recomendado que os participantes discutam sobre a validade ou no de um problema
encontrado (BUYKX, 2009).
Danino (2001) esclarece que todos os problemas devem ser registrados.
Se um participante considera um item invlido, ele deve atribuir quele item a
severidade zero. Pode ainda ser definida uma regra para a definio da severidade
ao final da avaliao. Por exemplo, que se determinado nmero de avaliadores
atribuir a severidade zero, ento o problema descartado.
Alguns pontos positivos da avaliao heurstica colaborativa, dentre eles
os descritos por Babajo (2012), so:
Maior concordncia entre avaliadores a respeito de problemas.
Maior proporo de problemas severos do que a avaliao tradicional.
Melhor experincia para os avaliadores.
27
Classificao de severidade mais confivel, uma vez que os avaliadores
vem os problemas ao mesmo tempo.
Eliminao da reunio de consolidao, os avaliadores atribuem individualmente as severidades dos problemas.
Reduo da duplicao de esforos.
No entanto, alguns pontos negativos citados so risco de resultados tendenciosos causados por determinado avaliador e restrio do escopo da avaliao
devido ao limite de tempo.
2.2.2.3
Percurso Cognitivo
Percurso cognitivo (cognitive walkthrough) um mtodo orientado a ta-
refas, onde cada analista explora o sistema passo-a-passo para cada tarefa. Ele
d nfase s questes cognitivas, analisando os processos mentais necessrios ao
usurio (HOLZINGER, 2005).
Rieman, Franzke e Redmiles (1995) explicam que os pr-requisitos para o
percurso so:
Uma descrio geral de quem os usurios sero e quais os conhecimentos
relevantes eles possuem.
Uma descrio especfica de uma ou mais tarefas representativas que sero
desempenhadas com o sistema.
Uma lista das aes corretas necessrias para completar cada uma das tarefas
com a interface a ser avaliada.
A avaliao limitada a considerar se o usurio selecionar quais das
aes corretas pelo caminho. Este mtodo requer que o avaliador seja experiente,
uma vez que ele deve simular o processo cognitivo do usurio.
28
Vantagens do percurso cognitivo so o auxlio aos designers para entender
a perspectiva dos usurios, identificao de problemas no sistema e definio dos
objetivos dos usurios. Problemas com este mtodo podem decorrer da seleo
imprpria de tarefas, nfase em detalhes de baixo nvel e no envolvimento do
usurio final (HOLZINGER, 2005).
2.2.2.4
Inspeo Semitica
Barbosa e Silva (2010) definem inspeo semitica como um mtodo que
avalia a comunicabilidade de uma soluo de IHC por meio de inspeo, com

o objetivo de avaliar a qualidade da emisso da metacomunicao do designer
codificada na interface.
O primeiro passo para inspeo semitica definir o propsito da avaliao (BENTO; PRATES; CHAIMOWICZ, 2009). Com isso em mente, o avaliador deve
estudar informalmente o sistema para identificar o foco da avaliao, confirmar os
usurios do sistema e os objetivos e atividades que ele suporta. O avaliador define
o escopo da avaliao atravs de um ou mais cenrios de interao que descrevem
o contexto de uso, os usurios-alvo a serem considerados e qual parte do sistema
ser considerada.
Na execuo da inspeo, realizada anlise de signos metalingusticos,
signos estticos e signos dinmicos, reconstruindo as metamensagens correspondentes (BARBOSA; SILVA, 2010). Em seguida feita a consolidao dos resultados,
onde as metamensagens so contrastadas e comparadas e os problemas de comunicabilidade encontrados so julgados. Para finalizar so relatados os resultados da
avaliao de comunicabilidade da soluo de IHC, sob o ponto de vista do emissor
da metamensagem (BARBOSA; SILVA, 2010).
A inspeo semitica no requer mais de um avaliador. Se houverem mais
avaliadores, eles devem trabalhar em conjunto, ou cada avaliador inspecionar a
interface para determinado perfil de usurio (BARBOSA; SILVA, 2010).
29
2.2.3
Heursticas para sistemas Web de Petrie e Power (2012)

Diferentes conjuntos de heursticas podem ser utilizados em uma avalia-
o, dependendo do sistema a ser avaliado. No estudo de Petrie e Power (2012)

foi desenvolvido um conjunto de heursticas para sistemas Web. Neste estudo foram comparados problemas de usabilidade encontrados em avaliaes de seis sites
governamentais complexos e altamente interativos. Os sites foram avaliados por
quinze usurios potenciais e trs diferentes mtodos de inspeo utilizando times
com trs especialistas.
No estudo de Petrie e Power (2012) os participantes identificaram problemas de usabilidade e os classificaram numa escala de catastrfico a cosmtico. Os
problemas encontrados foram categorizados, de forma a permitir um agrupamento
natural dos mesmos.
Como resultado deste estudo, foi obtido um conjunto de 21 heursticas, divididas nas categorias: Apresentao Fsica, Contedo, Arquitetura da informao
e Interatividade. Estas heursticas so apresentadas detalhadamente no Apndice
A.
2.3
Avaliao de Usabilidade em Mtodos geis

Para que um software atenda os requisitos de usabilidade, necessrio que
profissionais de IHC e engenheiros de software trabalhem juntos. No entanto, tanto

mtodos tradicionais quanto mtodos geis ainda no so integrados de forma adequada com mtodos e processos de IHC (MEMMEL; GUNDELSWEILER; REITERER,
2007).
Para Barbosa e Silva (2010) a utilizao de mtodos geis interessante
para IHC, uma vez que eles buscam interao com o cliente, tm pequenos ciclos
de desenvolvimento e trabalham de forma iterativa e incremental. No entanto,
Barbosa e Silva (2010) ressaltam que preciso cuidado em relao qualidade no
30
uso, pois raramente a comunidade gil cita usurios, ou faz uma distino entre
usurio e cliente.
Em IHC a distino entre cliente e usurio fundamental. Ao contratar o
desenvolvimento do software, o cliente muitas vezes no claro ao informar qual
o conjunto de usurios do sistema e quais as atividades desempenhadas por eles.
No mtodo de desenvolvimento gil Scrum, uma funcionalidade desenvolvida em um Sprint. Assim como no processo de design centrado no usurio,
a funcionalidade desenvolvida, testada e documentada. Nos Sprints seguintes o
design refinado com base na evoluo dos requisitos. Devido s similaridades,
design centrado no usurio pode ser incorporado no desenvolvimento gil sem
grandes impactos no processo (NAJAFI; TOYOSHIBA, 2008).
Winter et al. (2011) apresentam um estudo de caso da utilizao de um pacote para teste de usabilidade. Este pacote chamado de UIQ Technology Usability
Methods (UTUM). O objetivo do estudo de caso foi determinar como balancear
as demandas de resultados geis e formais na execuo de testes de usabilidade
para garantia de qualidade. Os dados do estudo foram obtidos atravs de observao, entrevistas no estruturadas, participao em reunies com stakeholders e
documentos do projeto. Foi concludo que o pacote de testes obteve resultados
satisfatrios para a empresa estudada.
Memmel, Gundelsweiler e Reiterer (2007) mostram a utilizao do CRUISER, um ciclo de vida de interface de usurio multidisciplinar e de Engenharia de
Software. O estudo mostra que o CRUISER apropriado para unir IHC e engenharia de software sob a perspectiva gil.
Barbosa, Furtado e Gomes (2008) propem uma estratgia para institucionalizao da usabilidade com base em conceitos de desenvolvimento e gesto
gil. Foi realizado um workshop para reflexo sobre a importncia em aplicar
novas prticas. Para obteno de informaes sobre a organizao, processos e experincias anteriores foram utilizados questionrios. Os objetivos de negcio e o
31
processo integrado com as prticas de usabilidade foram definidos em trs encontros com a alta direo. Algumas das contribuies obtidas pelos autores foram: a
integrao de prticas de usabilidade em um processo de desenvolvimento gil e
estreitamento da relao entre IHC e o negcio da organizao.
Nielsen e Madsen (2012) relatam um estudo envolvendo doze profissionais em usabilidade de doze diferentes pases. Foram realizadas entrevistas com
os profissionais sobre inovao em negcios e novas prticas. Posteriormente,
as entrevistas foram analisadas em busca de influncias de mtodos geis de desenvolvimento nos testes de usabilidade. Foram informados como benefcios as
decises mais rpidas, flexibilidade e relatos verbais. O estudo concluiu que os
profissionais esto se esforando para conseguir solues para integrar prticas
de usabilidade e mtodos geis, e que eles veem benefcios nas prticas que os
mtodos geis os foram a aplicar.
A utilizao da abordagem de usabilidade gil eXtreme Scenario-based
Design (XSBD) resumida e relatada no estudo de caso de Lee, Judge e McCrickard (2011). Neste trabalho foi concludo que vrios dos desafios que o time
encontrava eram relacionados comunicao, colaborao e compartilhamento de
informao. Como lies tiradas do estudo, foi recomendado ter foco nos aspectos importantes da interface, definir objetivos de alto nvel e definir mecanismos
de comunicao e compartilhamento de informao para incluir os membros distantes.
Wolkerstorfer et al. (2008) mostra adaptaes ao processo clssico do Extreme Programming (XP). Cinco instrumentos de IHC foram integrados com o
processo do XP. Estes instrumentos so: testes de unidade estendidos para avaliao de usabilidade automatizada, Extreme Personas (variao do mtodo clssico
de personas), estudos de usurio para tomar conhecimento sobre o usurio final,
avaliaes feitas por especialistas em usabilidade e testes de usabilidade com usurios.
32
Os trabalhos apresentados mostram avanos da integrao das prticas de
usabilidade nos ambientes geis. No entanto ainda existem poucos estudos sobre
este tema, e ainda h dificuldades a serem estudadas. A integrao entre mtodos de inspeo de usabilidade e mtodos geis de desenvolvimento importante.
Princpios geis podem beneficiar o processo de inspeo de usabilidade, assim
como a inspeo de usabilidade benfica para os resultados do desenvolvimento.
33
3 MTODOS
3.1
Tipo de Pesquisa
O mtodo de pesquisa utilizado neste trabalho a pesquisa observacional,
caracterizada segundo a perspectiva filosfica como positivista e quanto ao estilo

da pesquisa, estudo de caso. Estudos de caso so mais adequados para responder
questes explicativas, onde o pesquisador no interfere diretamente no objeto de
estudo. Este trabalho se trata da anlise da utilizao de dois mtodos de avaliao
no contexto de uma empresa, portanto caracteriza um estudo de caso.
De acordo com Rampazzo (2002), estudo de caso uma pesquisa descritiva que trabalha sobre dados ou fatos colhidos da prpria realidade. Utiliza-se
para isto a observao, entrevista, questionrio e outras tcnicas.
A pesquisa realizada combinou aspectos qualitativos e quantitativos. No
estudo foram coletados dados qualitativos referentes s impresses dos avaliadores
sobre os mtodos. Como resultado da aplicao do estudo de caso foram obtidas
as quantidades de problemas em cada mtodo de avaliao, os graus de severidade
atribudos aos problemas, dentre outros dados quantitativos.
3.2
3.2.1
Procedimentos Metodolgicos
Desenho
De acordo com Yin (2009), desenho da pesquisa pode ser definido como
um plano lgico para que, a partir de um conjunto de perguntas, possa se obter

um conjunto de concluses. Este plano lgico inclui vrios passos, como coleta e
anlise de dados relevantes.
O primeiro passo para este trabalho foi a reviso de literatura. O foco da
pesquisa a avaliao de usabilidade em ambientes que utilizam mtodos geis,
portanto a reviso de literatura envolveu conceitos e prticas de mtodos geis,
34
com foco em Scrum e tambm avaliao de usabilidade, com foco na avaliao
heurstica, que o mtodo de avaliao utilizado no estudo de caso.
Foi realizado um plano de acordo com o perfil da startup a aplicar o estudo
de caso. A empresa de pequeno porte, e a maior parte dos colaboradores no
tinha contato com questes de usabilidade.
Para viabilizar o estudo de caso, foi realizado um treinamento com os colaboradores. Era necessrio que todos os participantes tivessem um nvel mnimo
de conhecimento para que pudessem realizar as avaliaes. O objetivo principal
do treinamento foi explicar os conceitos e prticas necessrios para a realizao da
avaliao heurstica.
Depois que todos tiveram o treinamento as avaliaes foram realizadas.
Para isto os colaboradores foram divididos em duas equipes. As equipes foram
sorteadas, no entanto houve preocupao para que o nvel das duas equipes fosse
o mesmo. Para isto, os dois participantes que j tinham experincia com avaliao
de usabilidade foram atribudos a equipes diferentes. Os demais participantes,
classificados como iniciantes, foram atribudos aleatoriamente a uma das equipes.
As duas equipes analisaram o mesmo produto, um sistema Web desenvolvido pela empresa. Um dos grupos realizou a avaliao heurstica tradicional,
enquanto a outra equipe realizou a avaliao heurstica colaborativa. Foi determinado o tempo de uma hora e trinta minutos para as avaliaes do sistema, e
depois das avaliaes, a equipe da avaliao tradicional realizou uma sesso de
consolidao, onde no foi determinado limite de tempo. Foram utilizadas para as
avaliaes as heursticas de Petrie e Power (2012), que so mais adequadas para
sistemas Web. O conjunto de heursticas est disponvel no Apndice A.
Aps as avaliaes, os participantes responderam dois questionrios. Um
questionrio, comum para todos os participantes, tinha finalidade de obter informaes demogrficas, como idade, gnero, formao acadmica e informaes
profissionais, tais como cargos desempenhados, tempo no mercado de trabalho e
35
experincia. Ainda, os participantes responderam outro questionrio, especfico
para o tipo da avaliao executada, com objetivo de tomar conhecimento da opinio do participante sobre o mtodo utilizado.
O projeto desenvolvido no foi avaliado pelo Comit de tica em Pesquisas com Seres Humanos (COEP), pois, de acordo com a resoluo No 196, de 10 de
outubro de 1996, as pesquisas a ser submetidas COEP so aquelas cujo objetivo
contribuir para o conhecimento generalizvel. Como o objetivo deste trabalho
observar o uso de mtodos de avaliao de usabilidade especificamente em uma
empresa, o conhecimento gerado no generalizvel. Portanto entendeu-se no
ser necessria a submisso no mesmo, de acordo com esclarecimento realizado
pela COEP-UFLA.
Entretanto, o estudo prezou pela observao de todos os princpios ticos
durante sua realizao. Todos os envolvidos participaram voluntariamente do estudo, e os dados coletados foram tratados de maneira confidencial e annima. Os
participantes no foram expostos a nenhum risco excessivo, e foram tomadas todas
as providncias para a mitigao de quaisquer riscos identificados.
3.2.2
Participantes
Participaram do estudo de caso seis colaboradores da empresa, que foram
divididos em dois grupos. Todos os participantes frequentaram ou frequentam a

Universidade Federal de Lavras. Ao separar os participantes houve ateno para
que os grupos tivessem o mesmo nvel de experincia com avaliao de usabilidade.
Na empresa h dois colaboradores que conheciam e j tinham realizado
avaliao heurstica, ambos fazem parte da recm criada equipe de usabilidade da
empresa. Para as avaliaes, eles foram separados para evitar que uma equipe
fosse mais experiente que outra.
36
Um deles mestre em Cincia da Computao, e tem experincia com
desenvolvimento de software, gerncia de projetos e elicitao de requisitos. J
tinha realizado avaliaes heursticas quando acompanhou um projeto de aplicativo mvel e auxiliou na criao de somente algumas interfaces mais complexas
para outros projetos. No tem experincia com teste, no entanto participa da implantao de sistemas e treinamento de usurios, onde observa as dificuldades dos
usurios e reporta as dificuldades para a equipe de usabilidade e desenvolvedores.
A outra integrante da equipe de usabilidade que participou deste estudo
bacharel em Sistemas de Informao. Ela tem experincia como desenvolvedora e
atuou em projetos de ERP e aplicativos para dispositivos mveis Android. Como
membro da equipe de usabilidade participou de avaliaes heursticas nos projetos
da empresa e tambm j participou de uma avaliao heurstica para a monografia
de uma aluna do curso de Sistemas de Informao em 2010. Sua experincia
com testes se limita a testes unitrios, e no possui experincia profissional com
elicitao de requisitos.
Os outros participantes tinham conhecimento bsico sobre usabilidade e
avaliao heurstica adquirido na graduao, na disciplina chamada "Interao
Homem-Mquina". Estes participantes foram sorteados para os grupos, visto que
tinham mesmo nvel de conhecimento.
Um deles bacharel em Cincia da Computao e tem experincia em
desenvolvimento de sistemas na linguagem Java. J realizou elicitao de requisitos no profissionalmente. Tem pouca experincia com testes com usurios, e
nenhuma formao especfica para testes. J fez um curso com o tema de usabilidade, assistiu e participou de simulao de avaliao heurstica, mas nunca aplicou
os conceitos de maneira formal.
Um dos participantes declarou no possuir formao acadmica. Ele tem
experincia com levantamento de requisitos de sistemas junto ao cliente, desenvolvimento de sistemas usando diferentes linguagens e plataformas, como Ruby on
37
Rails, .Net e Java, elaborao e implantao de ambientes de produo de software
e consultoria em redes wireless. J participou de palestras sobre usabilidade em
eventos de desenvolvimento. Tem experincia com Test Driven Development e
Behavior Driven Development e participou de testes com usurios no desenvolvimento de alguns sistemas quando solicitado pelo cliente.
Dois dos participantes esto cursando bacharelado em Sistemas de Informao. Um deles tem experincia em suporte em educao a distncia com moodle, desenvolvimento para a plataforma wordpress, desenvolvimento na linguagem
Java e Ruby utilizando o framework Rails. Declarou j ter participado de duas ou
trs avaliaes heursticas, e tem conhecimento sobre usabilidade adquirido em
artigos na internet. Nunca realizou teste com usurios, somente observou a realizao.
O ltimo participante tem experincia de trs anos e meio de estgio com
desenvolvimento na linguagem Java, gesto de processos e inteligncia de negcios. No estgio, trabalha com desenvolvimento de interfaces, mas sempre seguindo um padro definido e j participou de duas avaliaes heursticas. Tem
experincia com teste de funcionalidade e no possui experincia com testes com
usurios. Declarou ter experincia razovel com elicitao de requisitos, proveniente de discusses com usurios e clientes.
Dois dos participantes tm 28 anos, e os outros quatro tm 24 anos. Desta
forma, a mdia de idades das equipes foi a mesma, de 25,3 anos.
3.2.3
Materiais
O objeto da avaliao foi um sistema Web para gerenciamento de concur-
sos chamado Lactus Contest. O sistema abrange desde o cadastro de empresas

participantes de um concurso at a emisso de relatrios sobre o desempenho das
amostras fornecidas, passando pela avaliao das mesmas em suas diversas cate-
38
gorias e critrios. A interface do sistema foi criada a partir do Twitter Bootstrap
(http://getbootstrap.com/).
Para a realizao das avaliaes foram utilizadas as heursticas para sistemas Web de Petrie e Power (2012). Foi disponibilizada para cada participante uma
lista com as heursticas, em anexo no Apndice A.
Foi disponibilizada uma planilha para registro dos problemas de usabilidade e as heursticas afetadas. O grupo que realizou a avaliao colaborativa
preencheu somente uma planilha, onde todos os problemas, apontados por qualquer membro do grupo, eram registrados, enquanto cada participante da avaliao
tradicional recebeu uma, e ao final ainda foi gerada outra planilha com o resultado
de todos. Esta planilha mostrada no Apndice B.
Cada participante da avaliao tradicional e colaborativa recebeu ainda
uma planilha para registro da severidade dos problemas, apresentada no Apndice
B.
Foram utilizados questionrios para coletar informaes demogrficas,
profissionais e tambm a opinio dos participantes sobre o mtodo executado. Estes questionrios encontram-se no Apndice C.
3.2.4
Procedimento
Esta subseo apresenta os procedimentos realizados para o estudo de
caso.
3.2.4.1
Treinamento
A equipe passou por um treinamento envolvendo interao humano-
computador, experincia do usurio e avaliao de usabilidade.

O treinamento teve duas partes. Na primeira parte foram apresentados
conceitos de usabilidade e interao humano-computador. Foram mostradas aos
39
participantes as heursticas de Nielsen (1994) e os conceitos de avaliao heurstica.
Na segunda parte do treinamento, os participantes realizaram uma avaliao heurstica colaborativa do site de uma companhia area. Desta forma eles
puderam consolidar os conhecimentos adquiridos na parte terica.
3.2.4.2
Avaliao Tradicional
A avaliao heurstica tradicional composta de duas fases: primeiro o
sistema avaliado, e depois os avaliadores se renem e compartilham suas avaliaes, originando um documento com a avaliao de todos a partir das discusses
em uma sesso de consolidao dos resultados.
Os participantes da avaliao tradicional fizeram a avaliao do sistema
individualmente. Depois das avaliaes, a equipe realizou uma reunio de consolidao, onde os problemas encontrados por cada avaliador foram apresentados
aos outros. Os participantes avaliaram a validade e severidade de cada problema,
e foi gerada uma planilha final com todos os problemas. Para a sesso de consolidao no houve limitao de tempo, uma vez que era interessante medir o tempo
gasto.
3.2.4.3
Avaliao Colaborativa
Na avaliao heurstica colaborativa, os participantes se reuniram e avalia-
ram o sistema de forma conjunta. Como a equipe era pequena, o mesmo avaliador
foi piloto, responsvel por operar o sistema, e escrivo, responsvel por registrar
os problemas apontados pelo grupo na planilha de registro de problemas. Todos os
problemas levantados pelos avaliadores foram considerados. Quando um avaliador
considerava um problema invlido, ele simplesmente atribua severidade nula na
sua planilha individual de atribuio de severidade, para evitar perder tempo com
discusses durante a avaliao.
40
Ao final da avaliao, foi entregue uma planilha com todos os problemas
encontrados e trs planilhas de severidade, uma de cada avaliador.
3.2.5
Anlise de Dados
De acordo com Yin (2003) tanto dados qualitativos quanto quantitativos
so relevantes na aplicao de um estudo de caso. Para ele, esta dualidade refora

o posicionamento do estudo de caso como um mtodo que no limitado ao tipo de
dados. O mtodo de estudo de caso possui design, coleta de dados e procedimentos
analticos prprios.
Neste estudo de caso foram utilizados critrios qualitativos e quantitativos
para anlise de dados. Os critrios so descritos a seguir.
A anlise quantitativa do nmero de problemas mostrou o nmero de problemas encontrados em cada abordagem de avaliao heurstica. Na avaliao
tradicional, foram relatados os problemas encontrados em cada avaliao e tambm o resultado final aps a sesso de consolidao, e na avaliao colaborativa,
foram relatados os problemas encontrados pelo grupo.
Foi tambm efetuada uma anlise quantitativa do nmero de violaes
s heursticas de usabilidade. Como os problemas podem violar mais que uma
heurstica, esta anlise se mostrou til para mostrar de forma mais especfica os
pontos falhos do sistema e a cobertura e utilizao das heursticas nos diferentes
tipos de avaliao.
A anlise quantitativa da severidade dos problemas foi utilizada para comparar os nveis de severidade dos problemas encontrados em cada abordagem. Para
determinar a severidade dos problemas encontrados na avaliao colaborativa foi
utilizada a mdia aritmtica das severidades atribudas por cada avaliador. Nos
casos onde a mdia das severidades no foi um nmero inteiro, foi utilizado arredondamento natural.
41
Por fim, a anlise qualitativa das respostas dos questionrios relacionados s impresses dos participantes sobre cada tipo de avaliao foi utilizada para
identificar a adequao de cada mtodo ao ambiente da empresa-alvo do estudo.
Para isto, foi feita uma anlise de contedo sobre as respostas dadas pelos participantes, visando identificar os principais temas relacionados forma de aplicao
e integrao do mtodo no desenvolvimento.
42
4 RESULTADOS E DISCUSSO
Este captulo descreve os dados obtidos com a realizao do estudo de
caso.
Atribuiu-se a nomenclatura de problema de usabilidade aos problemas encontrados na interface pelos avaliadores. Cada problema poderia violar mais de
uma heurstica. Para cada heurstica afetada por um problema foi utilizada a nomenclatura de violao de heurstica. Tambm foi utilizada uma varivel para
identificar o nmero de vezes que cada heurstica foi violada.
Os avaliadores que participaram da avaliao tradicional sero denominados AT1, AT2 e AT3, enquanto os participantes da avaliao colaborativa sero
denominados AC1, AC2 e AC3.
4.1
Violaes das Heursticas nas Avaliaes

Esta seo apresenta o nmero de problemas e as heursticas violadas pe-
los mesmos para cada uma das avaliaes. So descritos os grupos de heursticas
afetados pelos problemas encontrados, de acordo com a diviso realizada por Petrie e Power (2012).
A quantidade de violaes por grupo de heursticas pode exceder a quantidade de problemas encontrados, uma vez que cada grupo pode englobar vrias
heursticas, e cada problema de usabilidade pode violar mais que uma heurstica.
O conjunto completo das heursticas para sistemas Web de Petrie e Power (2012)
encontra-se no Apndice A.
4.1.1
Avaliao Heurstica Tradicional

Cada participante realizou uma avaliao do sistema individualmente. A
seguir so mostrados os resultados destas avaliaes.
43
O avaliador AT1 encontrou dezenove problemas. A Tabela 4.1 mostra o
nmero de pontos em que cada heurstica foi violada, separando por grupos de
heursticas, de acordo com a classificao de heursticas feita por Petrie e Power
(2012).
Foram encontradas dez violaes no grupo de heursticas de interatividade do sistema. Os violaes encontradas foram referentes a instrues e rtulos,
repetio de aes, feedback para as aes do usurio, sequncia de interao e
convenes, apresentao de funcionalidades interativas que o usurio precisa e
espera, distino entre elementos interativos e no-interativos e apresentao de
mensagens de erros informativas.
Nove violaes afetam o grupo de heursticas referentes ao contedo. So
violaes s heursticas que determinam a apresentao de contedo relevante e
apropriado, quantidade adequada de informao e utilizao de termos e abreviaes claras.
Foram encontradas cinco violaes s heursticas de apresentao do sistema. Estas violaes interferem na clareza dos elementos interativos e layout da
pgina e destaque dos principais contedos e mudanas no contedo.
A arquitetura da informao apresentou quatro violaes. A heurstica de
arquitetura da informao diz respeito apresentao de estruturas de informao
claras e bem organizadas.
A heurstica que apresentou mais pontos falhos no sistema foi a heurstica
de nmero sete. Ela faz parte do grupo de heursticas do contedo do sistema e
define que deve-se utilizar termos e abreviaes claras e evitar termos de difcil
entendimento.
A heurstica de nmero oito, de arquitetura da informao, tambm apresentou alto nmero de violaes. Ela orienta o fornecimento de estruturas de organizao de informao claras e bem organizadas.
44
Tabela 4.1: Nmero de violaes de heursticas na avaliao realizada pelo AT1
Heursticas
Nmero de violaes
Apresentao Fsica
H1 - Textos e elementos interativos devem ser grandes e claros
H2 - O layout da pgina deve ser claro
H4 - Os principais contedos e possveis mudanas de contedo devem
ser destacados
Contedo
H5 - Fornea contedo relevante e apropriado para o site
H6 - Fornea contedo em quantidade suficiente, mas no excessiva
H7 - Utilize termos e abreviaes claras
Arquitetura da Informao
H8 - Fornea estruturas de organizao da informao claras e bem or-
ganizadas.
Interatividade
10
H10 - Instrues e rtulos claros
H11 - Evite esforo excessivo e repetio de aes
H13 - Fornea feedback para as aes do usurio e para mostrar o estado
do sistema
H14 - Faa com que a sequncia de interao seja lgica
H16 - Siga convenes para interao
H17 - Fornea as funcionalidades interativas que os usurios precisam
e esperam do sistema
H19 - Elementos interativos e no-interativos devem ser fceis de dis-
tinguir
H21 - Fornea mensagens de erros informativas e que auxiliem os usurios a se recuperar de erros
45
O avaliador AT2 encontrou vinte e nove problemas de usabilidade no sistema. Como apresentado na Tabela 4.2, em trinta e sete pontos, heursticas do
grupo referente interatividade foram violadas. A heurstica que define padres
para o contedo do sistema foi violada em seis pontos, quatro violaes foram
encontradas quanto apresentao fsica e uma violao na arquitetura da informao.
Nesta avaliao, a heurstica que apresentou mais violaes foi a de nmero dez, que integra o grupo de interatividade do sistema. Foram encontradas
nesta avaliao quatorze ocorrncias de violaes a esta heurstica. Nela definido que as instrues e rtulos devem ser claros, e que devem ser utilizados
padres j conhecidos.
O avaliador AT3 encontrou quatro problemas no sistema. A Tabela 4.3
mostra resultados desta avaliao.
Foram encontrados sete pontos onde heursticas referentes interatividade
foram violadas. Foram encontrados trs violaes arquitetura da informao,
uma violao no contedo e uma na apresentao fsica do sistema.
A heurstica que obteve maior nmero de violaes foi a heurstica oito,
com trs ocorrncias. A heurstica oito se trata do fornecimento de estruturas de
organizao de informao claras e bem organizadas. Foram encontradas duas
violaes que afetam as heursticas dez e doze, integrantes das heursticas de interatividade do sistema. A heurstica dez diz respeito a instrues e rtulos claros, e
a heurstica doze orienta que os formatos de entrada de dados sejam claros e fceis.
Aps as avaliaes, foi realizada uma sesso de consolidao dos resultados. Um dos avaliadores havia sado da empresa, portanto foi decidido que somente dois deles participariam da sesso, uma vez que este avaliador o que havia
identificado o menor nmero de problemas entre os trs. Os dois participantes
da reunio incluram nos resultados finais a avaliao do terceiro participante. A
reunio de consolidao durou uma hora e vinte e dois minutos.
46
Heursticas
Nmero de violaes
Apresentao Fsica
Contedo
ganizadas.
Interatividade
37
14
H12 - Faa com que os formatos de entrada de dados sejam claros e
fceis
do sistema
H19 - Elementos interativos e no-interativos devem ser fceis de dis-
tinguir
H21 - Fornea mensagens de erros informativas e que auxiliem os usu-
rios a se recuperar de erros
Na sesso de consolidao foram identificados trinta e oito problemas. A

Tabela 4.4 mostra a quantidade de vezes em que cada heurstica foi violada.
47
Heursticas
Nmero de violaes
Apresentao Fsica
Contedo
ganizadas.
Interatividade
H9 - Fornea informaes claras sobre a interao com o sistema
("como e porque")
fceis
H15 - Fornea um conjunto de opes lgico e completo
Dos resultados consolidados, a heurstica dez, que define a utilizao de

instrues e rtulos claros, teve quatorze violaes. As heursticas oito e treze
tambm obtiveram alto nmero de violaes, respectivamente, oito e sete pontos.
A heurstica oito constitui o grupo da arquitetura da informao, e define a organizao das estruturas de informao. A heurstica treze, integrante do grupo de
interatividade do sistema, define o fornecimento de feedback para as aes realizadas pelo usurio.
Assim como nas avaliaes individuais, o grupo de heursticas mais afetado foi o de interatividade, onde foram encontrados quarenta e uma violaes.
48
Tabela 4.4: Nmero de violaes por grupo de heursticas aps a sesso de consolidao
Heursticas
No de violaes
Apresentao Fsica
10
H4 - Os principais contedos devem ser destacados
Contedo
11
H7 - Utilize termos e abreviaes claras
H8 - Fornea estruturas de organizao claras e bem organizadas.
Interatividade
41
H9 - Fornea informaes claras sobre a interao com o sistema
14
H12 - Faa com que os formatos de entrada de dados sejam claros e fceis
H13 - Fornea feedback para as aes do usurio e estado do sistema
H17 - Fornea as funcionalidades que os usurios precisam e esperam do sis-
tema
H19 - Elementos interativos e no-interativos devem ser fceis de distinguir
H20 - Agrupe elementos interativos de forma lgica e clara
H21 - Fornea mensagens de erros informativas
49
Quanto ao contedo, foram encontrados onze violaes. A apresentao fsica
apresentou dez violaes e a arquitetura da informao, oito.
4.1.2

Como resultado da avaliao heurstica colaborativa foram encontrados
vinte e dois problemas de usabilidade no sistema. A Tabela 4.6 mostra a quantidade de violaes para cada grupo de heursticas.
As heursticas que mais apresentaram violaes no sistema foram as referentes interatividade. Foram encontradas treze violaes relacionadas a este
grupo. As violaes encontradas para este grupo de heursticas foram relacionadas
com formatos de entrada de dados, feedback para as aes do usurio, sequncia de
interao, apresentao de um conjunto de opes lgico, apresentao de funcionalidades interativas que o usurio precisa e espera e fornecimento de mensagens
de erro informativas.
Foram encontradas quatro violaes apresentao fsica do sistema. A
apresentao fsica do sistema teve violaes quanto ao layout da pgina e visibilidade dos elementos interativos.
Trs violaes foram identificadas quanto ao contedo do sistema. As
violaes so relacionadas relevncia e quantidade do contedo da pgina.
Outras trs violaes foram encontradas na arquitetura da informao. Estas violaes dizem respeito estrutura de organizao de informao adequadas
para auxiliar os usurios a completar tarefas.
A heurstica que apresentou mais problemas foi a de nmero treze, que define que deve ser fornecido retorno para as aes realizadas pelo usurio e demonstrado o estado do sistema. A heurstica dezessete apresentou trs problemas. De
acordo com ela, devem ser fornecidas as funcionalidades interativas que o usurio
precisa e espera do sistema.
50
Tabela 4.6: Nmero de violaes por grupo de heursticas na avaliao colaborativa
Heursticas
Nmero de violaes
Apresentao Fsica
H4 - Os principais contedos e possveis mudanas de contedo devem
ser destacados
Contedo
ganizadas.
Interatividade
13
fceis
do sistema
H21 - Fornea mensagens de erros informativas e que auxiliem os usu-
rios a se recuperar de erros
4.1.3
Comparao entre as violaes das heursticas nas duas verses

de avaliao heurstica
Foi feita uma comparao entre o nmero de violaes das heursticas
utilizadas nas duas verses do mtodo de avaliao heurstica. Um teste de ranking
51
com sinais de Wilcoxon mostrou uma diferena significativa entre o nmero de
violaes de heursticas entre a avaliao heurstica tradicional e colaborativa (W+
= -3,024, N=21, p < 0,01).
Foi observado que houve mais violaes no mtodo tradicional. Um nmero maior de heursticas foi mencionado na avaliao tradicional do que na avaliao colaborativa.
4.2
Nmero de Problemas Encontrados

A avaliao tradicional encontrou 38 problemas, enquanto a avaliao co-
laborativa encontrou 22. As duas avaliaes encontraram um total de 60 problemas. Considerando que alguns problemas foram encontrados nos dois mtodos,
foram encontrados 55 problemas nicos. A Figura 4.1 mostra o nmero de problemas em comum encontrados nas avaliaes heursticas tradicional e colaborativa.
Figura 4.1: Problemas encontrados nas duas abordagens
Cinco problemas foram encontrados nas duas modalidades de avaliao.

Outros problemas encontrados foram exclusivamente da avaliao tradicional ou
da avaliao colaborativa.
52
4.3
Severidades dos problemas encontrados

Esta seo apresenta as severidades dos problemas encontrados nas duas
modalidades de avaliao heurstica.
4.3.1
Avaliao Heurstica Tradicional

Na avaliao tradicional foram encontrados trinta e oito problemas de usa-
bilidade. A Figura 4.2 mostra a quantidade de problemas para cada severidade

atribuda.
Figura 4.2: Severidade dos problemas encontrados na avaliao tradicional
A maior parte dos problemas foi de severidade um e dois, que so problemas cosmticos e simples, respectivamente. Quatorze problemas foram considerados cosmticos, e quinze problemas considerados simples. Problemas simples
devem ter prioridade menor no desenvolvimento do sistema e problemas cosmticos s devem resolvidos caso haja tempo disponvel no projeto.
Um problema recebeu a severidade quatro, que definido como catstrofe.
Considerou-se que o sistema no pode ser lanado antes de este problema ser re-
53
solvido. A severidade trs, que so problemas srios, teve oito ocorrncias. Estes
problemas so os de maior prioridade depois dos catastrficos.
4.3.2

Foram encontrados vinte e dois problemas de usabilidade no sistema com
a utilizao da avaliao heurstica colaborativa. A severidade de cada problema

foi obtida a partir da mdia entre as severidades atribudas pelos trs avaliadores
e foi utilizado arredondamento natural. A Figura 4.3 apresenta a severidade dos
problemas encontrados.
Figura 4.3: Severidade dos problemas encontrados na avaliao colaborativa
A avaliao heurstica colaborativa possui a opo de severidade zero, no

existente na avaliao tradicional. Isto ocorre devido avaliao colaborativa no
realizar sesso de consolidao de resultados, portanto um avaliador pode considerar que um problema identificado por outro avaliador no realmente um problema. Na avaliao tradicional os avaliadores discutem e entram em consenso
sobre os problemas, descartando problemas quando necessrio.
54
As severidades dois e trs, que representam problemas simples e srios,
tiveram o mesmo nmero de ocorrncias. importante que problemas srios sejam
corrigidos antes do lanamento do produto. J problemas simples tm prioridade
menor no desenvolvimento de um sistema. Foram registrados nove problemas de
cada um destes nveis de severidade.
Quatro problemas foram identificados com a severidade um, que indica
problemas cosmticos. A correo destes problemas s deve ser realizada se houver tempo disponvel.
As severidades zero e quatro, que representam, respectivamente, pontos
que no foram considerados problemas e problemas catastrficos, no foram registradas.
A severidade mnima atribuda por AC1 foi 1 e a mxima foi 4. A mdia
das severidades atribudas por ele foi de 3,14 e o desvio padro 0,834. Os outros
avaliadores atriburam severidades entre 0 e 3. A mdia das severidades atribudas
por AC2 foi de 1,95 e o desvio padro foi 1,046. A mdia de AC3 foi 1,59 e o
desvio padro foi 0,959.
Um teste de Friedman de duas vias com anlise de varincia por rankings
para amostras relacionadas mostrou evidncias de diferenas significativas entre
as severidades atribudas pelos avaliadores (X2 = 28,261, N=22, df=2, p < 0,001).
Anlises post-hoc com testes de ranking de sinais de Wilcoxon mostraram diferenas significativas entre as severidades dos avaliadores AC1 e AC2 (p < 0,001) e
entre os avaliadores AC1 e AC3 (p < 0,001), no houve diferena significativa entre os avaliadores AC2 e AC3 (p = 0,123). O avaliador AC1 era o mais experiente.
4.3.3
Comparao entre as severidades dos problemas encontrados

nas duas verses do mtodo
Somente cinco problemas foram encontrados em ambas, portanto no foi
possvel realizar uma anlise aprofundada sobre o nvel de concordncia entre as
55
severidades atribudas nos dois mtodos. A anlise dos cinco problemas encontrados nas duas avaliaes verificou que trs deles tinham o mesmo nvel de severidade. Um deles teve severidade 1 na avaliao tradicional e 3 na avaliao
colaborativa e um problema teve severidade 3 na avaliao tradicional e 2 na colaborativa.
Foi feita uma comparao entre os nveis de severidade dos problemas que
foram encontrados exclusivamente na avaliao heurstica tradicional e na avaliao heurstica colaborativa. Um teste de Mann-Whitney para amostras independentes mostrou uma diferena significativa entre a severidade mdia dos problemas
encontrados na avaliao colaborativa e o nvel de severidade da avaliao tradicional (MW = -2.072, N=50, p < 0,05). A mdia das severidades atribudas na
avaliao tradicional foi de 1,89, e a mdia encontrada na avaliao colaborativa
foi de 2,22.
4.4
Anlise do Processo de Avaliao

Os participantes responderam individualmente questionrios sobre utili-
zao de cada verso do mtodo de avaliao. Apenas dois dos participantes da

avaliao tradicional responderam o questionrio sobre a avaliao realizada.
Os participantes da avaliao heurstica tradicional declaram que no tiveram dificuldades para concordar sobre a validade de problemas encontrados.
Segundo eles, a reunio foi tranquila e eles chegaram rapidamente a um consenso.
Tambm no foi relatada dificuldade para identificar problemas iguais descritos
de forma diferente. Para os avaliadores, como o sistema era simples, os problemas eram fceis de identificar e quando um deles reportava um problema existente
em sua lista, os outros eram capazes de dizer que haviam encontrado o mesmo
problema. Em alguns casos foi necessrio reescrever problemas devido aos comentrios dos dois avaliadores serem complementares.
56
Os avaliadores declaram que tiveram dificuldade para entrar em acordo
quanto ao grau de severidade. Os participantes discutiram bastante sobre o assunto. Foi necessrio estabelecer critrios sobre o significado de cada grau no
contexto do sistema e considerando o perfil do usurio. Um deles descreveu que
houve momentos em que cada um sugeria uma severidade diferente e, mesmo no
concordando completamente, uma pessoa teve que ceder. Para ele, este tipo de
situao pode onerar bastante o processo, dependendo do tamanho do sistema.
Quanto s heursticas, no foi relatada dificuldade. Os participantes fizeram observaes sobre os casos de problemas iguais encontrados por diferentes
avaliadores. Um deles relatou que algumas vezes as heursticas no eram as mesmas, no entanto as heursticas atribudas por ambos avaliadores faziam sentido no
contexto do problema. O outro avaliador observou que muitas vezes heursticas se
repetiam nestes problemas.
J quanto ao esquema de severidade eles mostraram que tiveram algumas
dificuldades. Para um deles o esquema de severidade deixou muito espao para
subjetividade. Ele declarou que a maior dificuldade foi parametrizar o que caracterizava severidade dois ou trs. Para a realizao da consolidao foi necessrio
que o grupo definisse melhor o significado de cada grau de severidade.
Um dos avaliadores declarou que considerou o mtodo vlido para ajudar
na identificao de problemas de interface e usabilidade. No entanto, ele declarou
que ficou preocupado com o tempo que as discusses podem tomar. Ele considerou
que, com a possibilidade de um grupo maior, a sesso de consolidao ficaria cada
vez mais complicada e demorada.
O outro participante, que membro da equipe de usabilidade da empresa,
relatou que um ponto desfavorvel do mtodo que ele somente apresenta problemas, e no solues. Ele baseou esta concluso no funcionamento atual da empresa. No processo de criao de uma interface so elaborados diferentes mockups
para a mesma funcionalidade. Estes mockups so avaliados por pelo menos trs
57
membros da equipe de usabilidade, que so notas para cada opo. Ao final, o
mockup que obter maior nota utilizado no desenvolvimento. O mesmo processo
acontece quando um problema encontrado na interface. Neste caso, so elaborados mockups alternativos, que so avaliados juntamente com a interface atual. Se
a interface atual obtiver melhor nota, ela mantida, caso contrrio a interface
alterada. Ele alega que desta forma garantido que a equipe desenvolveu a melhor
interface que conseguiu projetar. Por fim, ele considerou que uma boa soluo seria a fuso entre os dois mtodos. Desta forma, primeiro seria realizada a avaliao
heurstica para apontar os principais problemas que precisam ser corrigidos. Em
seguida, propostas de interface seriam montadas e avaliadas segundo o mtodos j
utilizados na empresa.
Na avaliao heurstica colaborativa nenhum participante declarou ter sentido dificuldade em expressar sua opinio, relatar problemas em voz alta ou entender de qual problema o grupo estava falando. Os participantes declararam no ter
se sentido influenciados em nenhum momento da avaliao. Um deles declarou
que o grupo decidiu os problemas em conjunto e todos respeitaram as opinies
uns dos outros sobre as falhas encontradas no sistema. Tambm foi afirmado que
com o uso do projetor todos podiam ver a tela e era fcil apontar onde estavam os
problemas.
Quanto s heursticas e esquema de severidade, o grupo que realizou a
avaliao colaborativa declarou no ter tido dificuldades. Afirmaram que as heursticas foram bem explicadas no treinamento e que estavam descritas de forma
clara no documento disponibilizado para consulta. Um dos participantes manifestou, entretanto, que os graus do esquema de severidade poderiam ser explicados
mantendo um padro.
Os participantes tambm afirmaram que no tiveram problemas devido ao
fato de apenas uma pessoa operar o sistema, pois o piloto tambm executava o que
era instrudo pelos outros avaliadores.
58
Sobre a adequao do mtodo ao esquema de trabalho da empresa, um
dos participantes opinou que considera a avaliao importante, pois os desenvolvedores no conseguem encontrar todos os problemas da interface. Tambm foi
declarado que seria interessante a aplicao da avaliao de usabilidade a cada iterao do desenvolvimento, pois assim seriam avaliadas partes menores do sistema
e aumentaria a viso crtica da equipe para o desenvolvimento de novas funcionalidades.
Um dos participantes considerou o mtodo vlido por abrir possibilidades
para identificao dos problemas da aplicao, que muitas vezes mais oneroso e
menos produtivo na avaliao individual. Foram consideradas vlidas as discusses entre o grupo, pois ao ouvir a opinio do outro possvel aprender a olhar
diferentes aspectos do sistema, de forma a aperfeioar o prprio desempenho em
avaliaes futuras. No entanto tambm foi julgado que, devido experincia neste
projeto, a avaliao deveria ser executada por profissionais mais experientes na
rea de usabilidade. De acordo com este participante, as discusses levaram tempo
acima do esperado, pois muitas vezes os desenvolvedores no tinham maturidade
para aceitar um problema que foi encontrado, mesmo que fosse considerado um
problema cosmtico. Para ele, esta postura dificulta o andamento da avaliao e
torna discusses menos produtivas.
4.5
4.5.1
Discusso
Nmero de problemas encontrados nas duas verses do mtodo
Ao analisar os resultados das duas modalidades de avaliao heurstica,
observou-se que na avaliao tradicional foram encontrados mais problemas de

usabilidade do que na avaliao colaborativa. possvel identificar alguns fatores
que podem ter levado estes resultados.
59
Um fator o perfil dos avaliadores. Foi dada ateno diviso das equipes quanto experincia dos participantes, no entanto existe a possibilidade de
um avaliador ser mais atencioso ou exigente que os outros, independente da sua
experincia. Outro fator, que foi citado por um dos participantes da avaliao colaborativa, foi o tempo gasto para discusses durante a avaliao. Considerou-se
que o tempo gasto foi maior que o esperado devido ao nvel de maturidade dos
participantes. O fato de alguns dos participantes das avaliaes atuarem como
desenvolvedores no sistema avaliado tambm pode ter influenciado os resultados.
Hornbk e Frkjr (2008) mostram que o chamado "efeito avaliador"
um fator que interfere significativamente nos resultados das avaliaes. O efeito
avaliador pode interferir na comparao de problemas, pois dois problemas podem parecer iguais para um avaliador e diferentes para outro. Hornbk e Frkjr
(2008) tambm afirmam que este efeito existe tanto para a combinao de problemas quanto da identificao dos mesmos.
A existncia do efeito avaliador neste estudo de caso compromete a generalizao dos resultados para outros casos. Mais estudos com diferentes grupos
de avaliadores seriam necessrios para confirmar tendncias sobre o nmero de
problemas encontrados pelas duas verses da avaliao heurstica.
Observou-se que o nmero de problemas em comum entre as avaliaes
foi pequeno. Este resultado pode ter sido obtido devido s reas da aplicao
exploradas por cada avaliao. Os participantes da avaliao colaborativa ficaram focados em uma funcionalidade, enquanto a tradicional mostrou problemas de
usabilidade em diferentes lugares do sistema. Mais estudos so necessrios para
determinar se as reas exploradas em sistemas na avaliao heurstica colaborativa
podem ser diferentes da cobertura da avaliao heurstica tradicional.
60
4.5.2
Severidade dos problemas encontrados exclusivamente por um

ou outro mtodo
Foi mostrado que a severidade mdia dos problemas foi maior na avali-
ao colaborativa, assim como na dissertao de Buykx (2009). Anlises realizadas concluram que a severidade mdia da avaliao colaborativa foi de 2,22,
enquanto a mdia da avaliao tradicional foi de 1,89. A partir destes dados
possvel concluir que a avaliao heurstica colaborativa tende a revelar problemas
de usabilidade mais srios. Isto se mostra como fator favorvel, considerando-se a
necessidade de descobrir os problemas mais graves o mais cedo possvel durante
o desenvolvimento, uma vez que estes podem causar prejuzos maiores no futuro.
Identificou-se que houve diferena entre as mdias das severidades atribudas pelos participantes da avaliao colaborativa. O avaliador AC1 era o mais
experiente da equipe, e a mdia das severidades atribudas por ele foi maior do
que as mdias dos outros avaliadores. A partir destes dados, e levando em conta
que todos os participantes so desenvolvedores, possvel inferir que avaliadores
menos experientes tendem a considerar problemas de usabilidade menos srios do
que um especialista considera.
Estes dados reforam a necessidade de observar cuidadosamente a experincia dos profissionais que efetuam as avaliaes na organizao. de grande
importncia que os avaliadores tenham experincia e conhecimento sobre como
diferentes usurios encontram diferentes tipos de problemas em sistemas e como
podem ser afetados por problemas de usabilidade na realizao de suas tarefas.
4.5.3
Produtividade da avaliao heurstica tradicional e colaborativa

Apesar do nmero de problemas encontrados na avaliao tradicional ter
sido maior, ela consumiu mais tempo, devido necessidade da reunio de consolidao de resultados. Ambas as modalidades tiveram sesses de avaliao de
61
mesma durao: uma hora e trinta minutos. No entanto, a sesso de consolidao
da avaliao tradicional durou uma hora e vinte e dois minutos. Desta forma, a
avaliao tradicional tomou tempo significativamente maior. Se for comparado o
tempo total gasto com as avaliaes juntamente com o tempo para consolidar as
listas individuais de problemas em uma lista nica, a relao entre problemas e
tempo gasto da avaliao tradicional no se mostra to grande em relao avaliao colaborativa.
4.5.4
Dificuldades para a atribuio de graus de severidade

Os participantes da avaliao tradicional tiveram mais dificuldades para
estabelecer as severidades dos problemas. J na avaliao colaborativa no foi

identificada dificuldade. Considera-se favorvel avaliao colaborativa o fato de
os participantes avaliarem as interfaces ao mesmo tempo. Isto torna mais fcil a
argumentao entre eles sobre os problemas existentes e sobre o impacto de cada
problema na usabilidade do sistema.
4.5.5
Utilizao das heursticas nas avaliaes

Quanto s heursticas violadas, observou-se que a avaliao heurstica tra-
dicional teve uma maior cobertura. Mais heursticas foram atribudas para os problemas encontrados. A possvel causa deste resultado que os participantes da
avaliao tradicional tiveram mais preocupao em procurar em todo o grupo de
heursticas as que se aplicavam ao problema encontrado, enquanto na avaliao
colaborativa quando um avaliador encontrava uma heurstica que se aplicava, ela
j era registrada e os avaliadores passavam para o prximo problema. Outra possvel causa deste resultado que os avaliadores da avaliao tradicional podem
ter associado problemas a diferentes heursticas, e na sesso de consolidao eles
atriburam todas elas ao problema. Este resultado da execuo do estudo de caso
levanta questes que devem ser investigadas em estudos futuros, com objetivo de
62
investigar de forma mais aprofundada a relao entre a cobertura das heursticas
utilizadas nos mtodos tradicional e colaborativo.
4.5.6
Adequao do mtodo de avaliao heurstica colaborativa para

mtodos de desenvolvimento gil
A avaliao colaborativa apresenta fatores em comum com os princpios
geis, dentre eles, o compartilhamento de informaes. Shore e Warden (2008)

relatam que a integrao do time crucial, e que o conhecimento deve ser buscado
e compartilhado no ambiente gil. Participantes da avaliao colaborativa consideraram o mtodo vlido por permitir que isso acontea. A participao de membros
com diferentes nveis de conhecimento contribui para a formao dos participantes
medida que os menos experientes tm contato com o mtodo juntamente com os
mais experientes.
A excelncia tcnica e o bom design tambm so focos da filosofia gil.
Estes objetivos so alcanados com mais facilidade quando h integrao entre o
processo de desenvolvimento e as prticas de usabilidade. A avaliao heurstica
colaborativa auxilia na melhoria dos conhecimentos da equipe, uma vez que os
participantes trabalham conjuntamente e acabam trocando experincias.
Empresas que utilizam mtodos geis se preocupam em minimizar a quantidade de trabalho que no precisou ser feito. Com a realizao da avaliao heurstica so identificados os problemas de usabilidade, e eles poder ser corrigidos
antes de o sistema chegar ao usurio. A verso colaborativa do mtodo ainda contribui para encontrar problemas mais srios.
Um dos participantes da avaliao heurstica colaborativa relatou que considera adequado que sejam realizadas avaliaes a cada iterao do desenvolvimento. Desta forma o escopo da avaliao seria menor. Esta ideia compartilhada
com mtodos geis. Highsmith (2002) destaca que utilizando mtodos geis importante dividir o trabalho em pequenas tarefas, para que sejam executadas mais
63
rpido e com menor possibilidade de erros. Este princpio tambm auxilia a evitar
a realizao de atividades fora do escopo.
A avaliao heurstica colaborativa pode ser integrada com desenvolvimento com ciclos iterativos. A cada Sprint pode ser realizada uma avaliao das
funcionalidades implementadas. Com esta prtica, o escopo das avaliaes fica
menor, assim como a durao da sesso de avaliao. O problemas de usabilidade
podem ser corrigidos mais cedo, diminuindo o custo das correes e aumentando
a satisfao do usurio.
64
5 CONCLUSES
Neste trabalho foram abordadas duas modalidades de avaliao heurstica
aplicadas a uma pequena empresa de desenvolvimento de software que utiliza o
mtodo gil Scrum. O objetivo do trabalho foi analisar a utilizao da avaliao
heurstica tradicional e a avaliao heurstica colaborativa no contexto da empresa
e as implicaes do uso das duas verses da avaliao heurstica em uma organizao que utiliza mtodos geis.
Para atingir os objetivos especificados foi efetuado um estudo de caso com
duas etapas: na primeira etapa foi realizado treinamento com a equipe da empresa
para que todos os participantes do estudo tivessem um nvel mnimo de conhecimento sobre usabilidade e avaliao heurstica. Na segunda etapa, foi feita uma
anlise da aplicao das duas verses da avaliao heurstica, dividindo a equipe
em duas. A duas equipes avaliaram o mesmo produto: um sistema Web desenvolvido pela empresa. Uma das equipes realizou a avaliao heurstica tradicional e a
outra realizou a avaliao heurstica colaborativa. Aps a realizao das avaliaes
foram analisados os resultados dos procedimentos.
Este estudo de caso contribuiu para avaliar a utilizao de mtodos de
inspeo de usabilidade no contexto de uma startup. Os resultados obtidos podem
ser utilizados como ponto de partida para a escolha de um mtodo de inspeo de
usabilidade adequado para empresas similares, e em particular para aquelas que
tambm utilizem mtodos geis de desenvolvimento de software.
Os resultados do estudo mostraram que a avaliao tradicional encontrou
mais problemas que a avaliao colaborativa. Tambm foi observado que a avaliao tradicional teve maior cobertura em relao aos tipos de heursticas apontados
pelos avaliadores do que a avaliao colaborativa, os problemas encontrados violavam maior nmero de heursticas do que na avaliao colaborativa.
A mdia das severidades atribudas pelos avaliadores na avaliao heurstica colaborativa foi maior que as severidades atribudas na avaliao tradicional.
65
Isto sugere que a avaliao colaborativa tende a revelar mais problemas srios do
que a avaliao tradicional.
A sesso de consolidao de resultados da avaliao heurstica tradicional
durou uma hora e vinte e dois minutos. Considerando que as sesses de avaliao
tiveram tempo de uma hora e trinta minutos, a avaliao tradicional levou tempo
consideravelmente maior do que a avaliao colaborativa.
Foi observado que a avaliao heurstica colaborativa tem pontos em comum com os princpios geis de desenvolvimento. A avaliao colaborativa auxilia o compartilhamento de informao entre os participantes, contribuindo para o
aumento dos conhecimentos dos iniciantes. Os participantes da avaliao heurstica colaborativa consideraram o mtodo compatvel com as prticas da empresa.
Dentre os principais fatos observados nesse estudo de caso, destacam-se
os seguintes: a avaliao heurstica tradicional pode encontrar mais problemas de
usabilidade que a avaliao colaborativa, dependendo das pessoas alocadas para
realizar cada tipo de avaliao; a avaliao colaborativa tende encontrar problemas de usabilidade mais srios do que a avaliao tradicional; a avaliao tradicional toma tempo significativamente maior do que a avaliao colaborativa e
a avaliao colaborativa apresentou caractersticas que permitem que se encaixe
melhor em ambientes onde so utilizados mtodos geis.
Para explorar em mais profundidade as questes tratadas nessa monografia, trabalhos futuros devero investigar a produtividade das duas modalidades de
avaliao heurstica com a participao de avaliadores experientes, analisar se realmente a avaliao tradicional tem maior cobertura de heursticas e a relao entre
a modalidade de avaliao e a dificuldade encontrada para atribuir graus de severidade problemas de usabilidade. O levantamento de questes de pesquisa referentes aos fatos observados nesse estudo de caso tambm constituem uma importante
contribuio deste trabalho. Sero necessrios estudos empricos mais detalhados
com vistas a investigar cada uma dessas questes de pesquisa individualmente.
66
REFERNCIAS BIBLIOGRFICAS
AMBLER, S. W. Agile Adoption Rate Survey Results: February 2008. February
2008. Disponvel em: <http://www.ambysoft.com/surveys/agileFebruary2008.html>.
BABAJO, A. The effectiveness of Collaborative Heuristic Evaluation. Dissertao
(Mestrado) University of York, 2012.
BARBOSA, D. F.; FURTADO, E. S.; GOMES, A. S. Uma estratgia de apoio
institucionalizao da usabilidade em ambientes de desenvolvimento gil.
Sociedade Brasileira de Computação, Porto Alegre, Brazil, Brazil,
p. 214223, 2008. Disponvel em: <http://dl.acm.org/citation.cfm?id=1497470.1497494>.
BARBOSA, S. D. J.; SILVA, B. S. da. Interao Humano-computador. Elsevier
Brasil, 2010. ISBN 9788535211207. Disponvel em: <http://books.google.com.br/books?id=qk0skwr\ cewC>.
BECK, K. Extreme Programming Explained. [S.l.]: Addison Wesley, 2000.
BECK, K.; BEEDLE, M.; BENNEKUM, A. van; COCKBURN, A.;
CUNNINGHAM, W.; FOWLER, M.; GRENNING, J.; HIGHSMITH, J.; HUNT,
A.; JEFFRIES, R.; KERN, J.; MARICK, B.; MARTIN, R. C.; MELLOR,
S.; SCHWABER, K.; SUTHERLAND, J.; THOMAS, D. Manifesto for Agile
Development. 2001. Disponvel em: <http://agilemanifesto.org/>.
BENTO, L. F. H.; PRATES, R. O.; CHAIMOWICZ, L. Using semiotic inspection
method to evaluate a human-robot interface. 2009 Latin American Web Congress,
p. 7784, 2009.
BUYKX, L. Improving heuristic evaluation through collaborative working.
Dissertao (Mestrado) University of York, 2009.
67
COCKBURN, A. Crystal clear a human-powered methodology for small teams.
First. [S.l.]: Addison-Wesley Professional, 2004. ISBN 0201699478.
CRESPO, A. N.; SILVA, O. J. da; BORGES, C. A.; SALVIANO, C. F.; JUNIOR,
M. de T. A.; JINO, M. Uma metodologia para teste de software no contexto da
melhoria de processo. III Simpsio Brasileiro de Qualidade de Software, p. 115,
2004.
DANINO, N. Heuristic Evaluation - a Step By Step Guide Article. September
2001. Disponvel em: <http://www.sitepoint.com/heuristic-evaluation-guide/>.
FOWLER, M. The New Methodology. 2005. Disponvel em: <http://martinfowler.com/articles/newMethodology.html>.
GUTWIN, C.; GREENBERG, S. The mechanics of collaboration: Developing
low cost usability evaluation methods for shared workspaces. IEEE
Computer Society, Washington, DC, USA, p. 98103, 2000. Disponvel em:
<http://dl.acm.org/citation.cfm?id=647068.715651>.
HIGHSMITH III, J. A. Adaptive software development: a collaborative approach
to managing complex systems. New York, NY, USA: Dorset House Publishing
Co., Inc., 2000. ISBN 0-932633-40-4.
HIGHSMITH, J. Agile Software Development Ecosystems. [S.l.]: Addison
Wesley, 2002.
HOLZINGER, A. Usability engineering methods for software developers.
Commun. ACM, ACM, New York, NY, USA, v. 48, n. 1, p. 7174, jan. 2005. ISSN
0001-0782. Disponvel em: <http://doi.acm.org/10.1145/1039539.1039541>.
HORNBK, K.; FRKJR, E. A study of the evaluator effect in usability
testing. Human-Computer Interaction, Taylor & Francis, v. 23, n. 3, p. 251277,
2008. Disponvel em: <http://dx.doi.org/10.1080/07370020802278205>.
68
ISO. ISO 9241-11: Ergonomic requirements for office work with visual display
terminals. [S.l.: s.n.], 2002.
ISO/IEC. ISO/IEC 25000 - Software engineering - Software product Quality
Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. [S.l.], 2005.
LEE, J. C.; JUDGE, T. K.; MCCRICKARD, D. S. Evaluating extreme scenariobased design in a distributed agile team. ACM, New York, NY, USA, p. 863877,
2011. Disponvel em: <http://doi.acm.org/10.1145/1979742.1979681>.
MEMMEL, T.; GUNDELSWEILER, F.; REITERER, H. Agile human-centered
software engineering. British Computer Society, Swinton, UK, UK, p. 167175,
2007. Disponvel em: <http://dl.acm.org/citation.cfm?id=1531294.1531317>.
NAJAFI, M.; TOYOSHIBA, L. Two case studies of user experience design and
agile development. IEEE Computer Society, Washington, DC, USA, p. 531536,
2008. Disponvel em: <http://dx.doi.org/10.1109/Agile.2008.67>.
NASCIMENTO, G. V. Um modelo de referncia para o desenvolvimento gil
de software. Dissertao (Mestrado) Instituto de Cincias Matemticas e de
Computao - Universidade de So Paulo, So Carlos, 2007. Disponvel em:
<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-07052008-170413>.
NERUR, S.; MAHAPATRA, R.; MANGALARAJ, G. Challenges of migrating to
agile methodologies. Comunications of the ACM, v. 48, p. 7278, 2005.
NIELSEN, J. Enhancing the explanatory power of usability heuristics. ACM,
New York, NY, USA, p. 210, 1994. Disponvel em: <http://doi.acm.org/10.1145/259963.260333>.
NIELSEN, J. Why You Only Need to Test With 5 Users. March 2000. Disponvel
em: <http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/>.
69
NIELSEN, J.; MACK, R. L. Usability inspection methods. [S.l.]: Wiley & Sons,
1994.
NIELSEN, J.; MOLICH, R. Heuristic evaluation of user interfaces. ACM, New
York, NY, USA, p. 249256, 1990. Disponvel em: <http://doi.acm.org/10.1145/97243.97281>.
NIELSEN, L.; MADSEN, S. The usability experts fear of agility: an empirical
study of global trends and emerging practices. ACM, New York, NY, USA,
p. 261264, 2012. Disponvel em: <http://doi.acm.org/10.1145/2399016.2399057>.
PALMER, S. R.; FELSING, M. A Practical Guide to Feature-Driven
Development. 1st. ed. [S.l.]: Pearson Education, 2001. ISBN 0130676152.
PETRIE, H.; POWER, C. What do users really care about?: a comparison
of usability problems found by users and experts on highly interactive
websites. ACM, New York, NY, USA, p. 21072116, 2012. Disponvel em:
<http://doi.acm.org/10.1145/2208276.2208363>.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile
Toolkit. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003.
ISBN 0321150783.
RAMPAZZO, L. Metodologia cientfica para alunos dos cursos de graduao e
ps graduao. [S.l.]: Edies Loyola, 2002.
RIEMAN, J.; FRANZKE, M.; REDMILES, D. Usability evaluation with the
cognitive walkthrough. ACM, New York, NY, USA, p. 387388, 1995. Disponvel
em: <http://doi.acm.org/10.1145/223355.223735>.
SEFFAH, A.; METZKER, E. The obstacles and myths of usability and software
engineering. Commun. ACM, ACM, New York, NY, USA, v. 47, n. 12, p. 7176,
70
dez. 2004. ISSN 0001-0782. Disponvel em: <http://doi.acm.org/10.1145/1035134.1035136>.
SHORE, J.; WARDEN, S. The Art of Agile Development. [S.l.]: OReilly Media,
2008.
SOARES, M. S. Comparao entre metodologias geis e tradicionais de
desenvolvimento de software. Infocomp Journal of Computer Science, p. 813,
2004.
STAPLETON, J. Dynamic Systems Development Method: The Method in
Practice. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.,
1997. ISBN 0201178893.
TANIGUCHI, K.; CORREA, F. E. Metodologias geis e motivao de pessoas
em projetos de desenvolvimento de software. Revista de Cincias Exatas e
Tecnologia, p. 163179, 2009.
WINTER, J.; RNKK, K.; AHLBERG, M.; HOTCHKISS, J. Meeting
organisational needs and quality assurance through balancing agile and formal
usability testing results. Springer-Verlag, Berlin, Heidelberg, p. 275289, 2011.
Disponvel em: <http://dl.acm.org/citation.cfm?id=2040660.2040689>.
WOLKERSTORFER, P.; TSCHELIGI, M.; SEFELIN, R.; MILCHRAHM,
H.; HUSSAIN, Z.; LECHNER, M.; SHAHZAD, S. Probing an agile usability
process. ACM, New York, NY, USA, p. 21512158, 2008. Disponvel em:
<http://doi.acm.org/10.1145/1358628.1358648>.
YIN, R. K. Applications of Case Study Research. [S.l.]: SAGE Publications, Inc,
2003.
YIN, R. K. Case Study Research: Design and Methods, 4th Edition. 4th. ed. [S.l.]:
SAGE Publications, Inc, 2009. ISBN 0761925538.
71
A HEURSTICAS UTILIZADAS PARA AS AVALIAES

Heursticas para sistemas Web de Petrie e Power
Helen Petrie and Christopher Power. 2012. What do users really care about?: a comparison of usability
problems found by users and experts on highly interactive websites. In Proceedings of the 2012 ACM
annual conference on Human Factors in Computing Systems (CHI '12). ACM, New York, NY, USA, 21072116.
Apresentao fsica
Heurstica 1. Faa com que texto e elementos interativos sejam suficientemente grandes e claros
O tamanho em que o texto e elementos interativos so mostrados por padro (sem modificaes pelo
usurio) devem ter tamanho grande o suficiente para que usurios possam ler e manipular com facilidade.
Heurstica 2. Torne o leiaute da pgina claro
Faa com que o leiaute das informaes em cada pgina seja claro, fcil de ler e que reflita a organizao
do material disponibilizado.
Heurstica 3. Evite que o tempo de exibio de informaes ou para completer tarefas seja curto
demais
Permita que o usurio tenha tempo suficiente para completer suas tarefas confortavelmente, e se alguma
informao for exibida por tempo limitado, que seja mostrada por tempo suficientemente longo.
Heurstica 4. Faa com que os principais contedos da pgina e possveis mudanas no contedo
estejam destacados
Faa com que os principais contedos e elementos interativos estejam claramente visveis na pgina, e
que quaisquer mudanas que ocorram na pgina sejam claramente indicadas.
Contedo
Heurstica 5. Fornea contedo relevante e apropriado para o site
Garanta que o contedo mostrado na pgina seja relevante para as tarefas dos usurios e que seja escrito
de maneira apropriada.
Heurstica 6. Fornea contedo em quantidade suficiente, mas no excessiva
Fornea contedo (incluindo de ajuda) que auxilie os usurios a completarem suas tarefas, mas no em
em quantidades excessivas que possam sobrecarregar o usurio.
Heurstica 7. Utilize termos e abreviaes claras, e evite o uso de jarges e palavras de difcil
entendimento
Defina todos os tempos complexos, jarges e explique todas as abreviaturas.
Heurstica 8. Fornea estruturas de organizao de informao claras e bem organizadas
Fora estruturas de informao que organizem o contedo da pgina de maneira adequada e que auxiliem
os usurios a completarem suas tarefas.
Interatividade
Heurstica 9. Como e porque
Fornea para os usurios explicaes claras sobre como a interao do sistema funciona e o motive
porque as coisas acontecem no sistema.
Heurstica 10. Instrues e rtulos claros
Fornea instrues e rtulos de campos claros para todos os elementos interativos. Utilize convenes
comumente utilizadas na Web (como o uso de asterisco para elementos de preenchimento obrigatrio)
Heurstica 11. Evite esforo excessivo e repetio de aes pelos usurios

No pea para o usurio entrar com a mesma informao mais de uma vez, e no exija que o usurio
precise de esforo excessivo para atingir objetivos que poderiam ser desempenhados de maneira mais
eficiente pelo sistema.
Heurstica 12. Faa com que os formatos de entrada de dados sejam claros e fceis
Torne claro de antemo qual o formato exigido para entrada de dados pelos usurios. Utilize formatos
que sejam fceis para os usurios.
Heurstica 13. Fornea feedback para aes realizadas pelo usurio e para demonstrar o estado do
sistema
Fornea feedback para as aes feitas pelo usurio, e indicaes indicando se alguma ao do sistema
est em curso ou se vai levar algum tempo para ser processada.
Heurstica 14. Faa com que a sequncia de interao seja lgica
Faa com que a sequncia da interao seja lgica para os usurios (por exemplo, usurios que utilizam
idiomas indo-europeus, tais como o Portugus, tendem a ler uma pgina do canto esquerdo-superior para
o canto inferior-direito, de forma que um boto Prximo seria mais lgico se estiver no canto inferiordireito).
Heurstica 15. Fornea um conjunto de opes lgico e completo
Garanta que qualquer conjunto de opes dado em operaes no sistema inclua todas as opes que os
usurios necessitem e que o conjunto seja organizado de forma lgica para os usurios.
Heurstica 16. Siga convenes para interao
A no ser que haja algum motive especial, siga convenes utilizadas na Web para interao (por
exemplo, uma sequncia lgica entre a navegao por elementos quando se pressiona o TAB)
Heurstica 17. Fornea as funcionalidades interativas que os usurios precisam e esperam do
sistema
Fornea todas as funcionalidades interativas que os usurios necessitem para efetuar suas tarefas e que
eles esperam encontrar em determinadas situaes (por exemplo, o sistema fornece uma busca?)
Heurstica 18. Indique se os links vo para outra pgina ou para outro website externo
Se um link aponta para outro website ou para outro tipo de recurso (como um arquivo PDF), indique isso
claramente na interface.
Heurstica 19. Elementos interativos e no-interativos devem ser fceis de distinguir
Elementos que fornecem algum tipo de interatividade devem ser claramente indicados como tal, e
elementos que no fornecem interatividade no devem utilizar leiaute que possam sugerir que tem alguma
funcionalidade.
Heurstica 20. Agrupe elementos interativos de forma lgica e clara
Agrupe elementos interativos e seus rtulos e textos associados de forma que seja claro identificar qual
a sua funcionalidade.
Heurstica 21. Fora mensagens de erros informativas e que auxiliem os usurios a se recuperar
dos erros
Fornea mensagens de erro que explique os problemas utilizando a linguagem do usurio e que fornea
informaes que auxiliem os usurios a se recuperar dos erros.
Graus de severidade:
0 = No um problema: no concordo que esse seja um problema de usabilidade
1 = Cosmtico: no precisa ser consertado a no ser que haja tempo extra disponvel no projeto
2 = Simples: a correo deste tipo de problema deve ter prioridade menor
3 = Srio: importante corrigir o problema, por isso dar prioridade maior a ele
4 = Catstrofe: o problema deve ser resolvido impreterivelmente antes do lanamento do produto
73
B PLANILHAS UTILIZADAS NAS AVALIAES

B.1
Planilha de identificao de problemas
Lista de identificao de problemas de usabilidade

N Localizao do problema (pgina/tela) Descrio do problema
Heursticas aplicveis
74
B.2
Planilha das severidades dos problemas
Lista individual de atribuio de grau de severidade

Aplicao:
Tarefa:
Avaliador:
N do problema
Severidade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
75
C QUESTIONRIOS UTILIZADOS
C.1
Questionrio demogrfico
Questionrio Demogrfico
1. Cargo na empresa:
2. Idade:
3. Sexo: (
(
) Masculino
) Feminino
4. Qual a sua formao acadmica?
5. Qual a sua experincia na indstria?
6. Qual a sua experincia com usabilidade?
7. Qual a sua experincia com teste?
8. Voc j teve contato com avaliao heurstica? Se sim, como foi este contato e
de quantas avaliaes j participou?
9. Qual a sua experincia com teste com usurios?
10. Qual a sua experincia com elicitao de requisitos?
76
C.2
Questionrio da avaliao tradicional
Avaliao Tradicional
1. Voc encontrou dificuldades para entrar em acordo com o grupo sobre quais
problemas encontrados realmente caracterizavam problemas?
2. Voc encontrou dificuldade para identificar problemas iguais descritos de forma

diferente por diferentes avaliadores?
3. Voc encontrou dificuldade de entrar em acordo sobre os graus de severidade?
4. Voc teve dificuldade para entender as heursticas?
5. E o esquema de severidade?
6. Qual a sua opinio sobre a adequao do mtodo no esquema de trabalho da

empresa?
77
C.3
Questionrio da avaliao colaborativa
Avaliao Colaborativa
1. Voc teve alguma dificuldade em falar sua opinio ou relatar problemas em voz
alta ou se sentiu, em algum momento, influenciado pelo grupo?
2. Em algum momento voc teve dificuldade para entender de qual problema o

grupo estava falando?
3. Voc teve dificuldade para entender as heursticas?
4. E o esquema de severidade?
5. Voc sentiu dificuldade ao realizar a avaliao da interface devido a somente

uma pessoa estar operando o sistema?
6. Qual a sua opinio sobre a adequao do mtodo no esquema de trabalho da

empresa?

Inspeção de Usabilidade Aplicada A Métodos Ágeis PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Inspeção de Usabilidade Aplicada A Métodos Ágeis PDF

Transféré par

Droits d'auteur :

Formats disponibles

SARAH FIGUEIREDO CAIXETA LEITE

INSPEO DE USABILIDADE APLICADA A

SARAH FIGUEIREDO CAIXETA LEITE

INSPEO DE USABILIDADE APLICADA A MTODOS GEIS:

Departamento de Cincia da Computao da

Princpios do Desenvolvimento gil . . . . . . . . . . . . . . . . .

Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . .

Heursticas para sistemas Web de Petrie e Power (2012) . . . . . .

Avaliao de Usabilidade em Mtodos geis . . . . . . . . . . . . .

Violaes das Heursticas nas Avaliaes . . . . . . . . . . . . . . . .

Avaliao Heurstica Tradicional . . . . . . . . . . . . . . . . . . .

Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . . .

Comparao entre as violaes das heursticas nas duas verses de

Nmero de Problemas Encontrados

Severidades dos problemas encontrados . . . . . . . . . . . . . . . .

Avaliao Heurstica Tradicional . . . . . . . . . . . . . . . . . . .

Avaliao Heurstica Colaborativa . . . . . . . . . . . . . . . . . .

Comparao entre as severidades dos problemas encontrados nas

Anlise do Processo de Avaliao . . . . . . . . . . . . . . . . . . .

Nmero de problemas encontrados nas duas verses do mtodo . .

Severidade dos problemas encontrados exclusivamente por um ou

Produtividade da avaliao heurstica tradicional e colaborativa . . .

Dificuldades para a atribuio de graus de severidade . . . . . . . .

Utilizao das heursticas nas avaliaes . . . . . . . . . . . . . . .

Adequao do mtodo de avaliao heurstica colaborativa para mtodos de desenvolvimento gil . . . . . . . . . . . . . . .

A Heursticas utilizadas para as avaliaes

B Planilhas utilizadas nas avaliaes

B.1 Planilha de identificao de problemas . . . . . . . . . . . . . . . . .

B.2 Planilha das severidades dos problemas . . . . . . . . . . . . . . . .

C.1 Questionrio demogrfico . . . . . . . . . . . . . . . . . . . . . . . .

C.2 Questionrio da avaliao tradicional . . . . . . . . . . . . . . . . . .

C.3 Questionrio da avaliao colaborativa . . . . . . . . . . . . . . . . .

As Dez Heursticas de Nielsen . . . . . . . . . . . . . . . . . . . . .

Nmero de violaes de heursticas na avaliao realizada pelo AT1 .

Nmero de violaes de heursticas na avaliao realizada pelo AT2 .

Nmero de violaes de heursticas na avaliao realizada pelo AT3 .

Nmero de violaes por grupo de heursticas aps a sesso de consolidao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nmero de violaes por grupo de heursticas na avaliao colaborativa 50

Exemplo de grfico Burndown . . . . . . . . . . . . . . . . . . . . .

Proporo dos problemas de usabilidade encontrados em uma inter-

face em relao ao nmero de avaliadores. Fonte: Nielsen (2000) .

Problemas encontrados nas duas abordagens . . . . . . . . . . . . . .

Severidade dos problemas encontrados na avaliao tradicional . . . .

Severidade dos problemas encontrados na avaliao colaborativa . . .

tica tradicional e a avaliao heurstica colaborativa em uma pequena empresa de

Princpios do Desenvolvimento gil

ming, que so vlidos tambm para outros mtodos geis, so eles:

Figura 2.1: Exemplo de grfico Burndown

o Humano-Computador (IHC) criado para encontrar problemas de usabilidade.

1. Visibilidade do status do sistema

O sistema deve manter o usurio informado sobre

2. Relacionamento entre o sistema

Devem ser seguidas converses do mundo real, as

informaes devem aparecer em ordem natural e

3. Controle do usurio e liberdade

Se o usurio realizar uma ao indesejada, ele

As mesmas aes devem ser nomeadas da mesma

Deve-se eliminar situaes onde possam ocorrer

6. Reconhecer ao invs de relem-

Deixar visveis objetos, aes e opes. Instru-

es devem ser visveis e fceis de recuperar.

7. Flexibilidade e eficincia de uso

Usurios especialistas devem ter aes facilitadas.