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, Ti-
ago, 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 du-
rante 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 preocupa-
o com a qualidade do produto entregue. A usabilidade um requisito importante
da qualidade do software. No entanto, muitas empresas tm dificuldade para inte-
grar 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 traba-
lho 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 cola-
borativa, que foram utilizados por duas equipes da empresa com nveis equivalen-
tes de experincia com usabilidade. A avaliao heurstica colaborativa mostrou
tendncia a encontrar problemas de usabilidade mais srios e tambm teve aceita-
o pelos participantes do estudo, apesar de no ter encontrado um nmero maior
de problemas do que a avaliao heurstica tradicional. Conclui-se que a aborda-
gem 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 qua-
lity 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 stu-
dies 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 evalua-
tion 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 evalu-
ation 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 In-
teraction, Software Engineering.
SUMRIO
1 Introduo 11
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Organizao da Monografia . . . . . . . . . . . . . . . . . . . . . . . 14
2 Referencial Terico 15
2.1 Mtodos geis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Princpios do Desenvolvimento gil . . . . . . . . . . . . . . . . . 16
2.1.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 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
2.2.3 Heursticas para sistemas Web de Petrie e Power (2012) . . . . . . 29
2.3 Avaliao de Usabilidade em Mtodos geis . . . . . . . . . . . . . 29
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 Avaliao Colaborativa . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.5 Anlise de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Resultados e Discusso 42
4.1 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 m-
todos de desenvolvimento gil . . . . . . . . . . . . . . . 62
5 Concluses 64
A Heursticas utilizadas para as avaliaes 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 Nmero de violaes de heursticas na avaliao realizada pelo AT2 . 46
4.3 Nmero de violaes de heursticas na avaliao realizada pelo AT3 . 47
4.4 Nmero de violaes por grupo de heursticas aps a sesso de conso-
lidao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Nmero de violaes por grupo de heursticas na avaliao colaborativa 50
LISTA DE FIGURAS
2.1 Exemplo de grfico Burndown . . . . . . . . . . . . . . . . . . . . . 20
2.2 Proporo dos problemas de usabilidade encontrados em uma inter-
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 mudan-
as 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 vis-
tos em pesquisa realizada por Ambler (2008) sobre a adoo de desenvolvimento
gil de software. Nesta pesquisa afirmado que, em comparao com equipes tra-
dicionais, 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 proces-
sos 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 huma-
nos, gerenciais e tecnolgicos.
Para garantir a qualidade do produto desenvolvido, a avaliao de usabi-
lidade muito importante. A importncia da usabilidade relatada na ISO/IEC
(2005). No entanto Seffah e Metzker (2004) ressaltam que tcnicas de design cen-
trado 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 de-
senvolve boas prticas de integrao entre Interface Humano-Computador e Enge-
nharia 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 Mad-
sen (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 heu-
rstica no ambiente de uma empresa de desenvolvimento de software.
Avaliao heurstica um mtodo de anlise de usabilidade onde um n-
mero de avaliadores apresentado a uma interface para que comentem sobre a
mesma considerando um conjunto de heursticas (NIELSEN; MOLICH, 1990). Ava-
liao heurstica um mtodo de inspeo muito conhecido e aceito por especia-
listas, 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 produtivi-
dade.
13
Poucos autores relataram experincias com a avaliao heurstica colabo-
rativa. 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 usabi-
lidade 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 apli-
cada em empresas que utilizam metodologias de desenvolvimento geis. Desta
forma, a proposta deste trabalho foi efetuar um estudo de caso comparando a utili-
zao de mtodos de inspeo baseados em avaliao heurstica, nas suas verses
tradicional e colaborativa, em uma empresa de pequeno porte que utiliza um m-
todo 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 tra-dicional 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 heu-rstica tradicional.
Investigar prs e contras da utilizao da avaliao heurstica tradicional e aavaliao 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 ava-
liao 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 enfo-
que 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 inspe-
o 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 desenvolvi-
mento seja flexvel para receber bem as alteraes de requisitos durante o desen-
volvimento (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 stakehodersquando necessrio.
Comunicao: para dar s pessoas informaes corretas, para serem usadasem 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 compe-tncias.
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 ambi-
entes 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 resulta-
dos, 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 informa-
es so trocadas, alguns ficam sabendo o que os outros esto fazendo, as dificul-
dades 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 pro-
cessos 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 mudan-
as: 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 experi-
mentar, 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 res-
peito previsibilidade e adaptabilidade. Estes princpios dizem que mudanas
18
nos requisitos podem ser feitas, mesmo que num estado avanado do desenvol-
vimento. 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 im-
portante dividir o trabalho em pequenas tarefas. Dividindo o trabalho em partes
menores, a execuo de cada parte mais rpida, e reduz as possibilidades de er-
ros 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), Ex-
treme Programming (BECK, 2000), Crystal Methods (COCKBURN, 2004) , Lean
Development (POPPENDIECK; POPPENDIECK, 2003), Dynamic Systems Develop-
ment (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 en-
tanto, possvel definir um processo para monitoramento e gerenciamento, obser-
vando 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 Bac-
klog 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 seleci-
onados para um Sprint no podem ser alterados no decorrer do mesmo. Os requi-
sitos 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 dia-
riamente 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 fo-
ram 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 Avaliao de Usabilidade
2.2.1 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 efic-
cia, 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 usu-
rio 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 usabi-
lidade.
Apreensibilidade a capacidade de o software ser aprendido pelo usurio.
Flexibilidade a usabilidade e segurana em contextos diferentes dos identifica-
dos 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 necessi-
dades. 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 nor-
mas, 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 re-
torne ao sistema depois de um longo perodo e no precise reaprender tudo; Baixa
taxa de erro: no possibilitar erros catastrficos ocorram, e quando ocorrerem er-
ros, 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 observa-
cionais feita atravs da anlise de como as pessoas efetuam determinadas tarefas
22
em um sistema. De acordo com Buykx (2009), por envolverem usurios do sis-
tema, 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 infor-
maes diretas sobre como as pessoas utilizam o sistema e seus problemas com
determinadas interfaces.
Para Buykx (2009), mtodos de inspeo despertam interesse porque po-
dem 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 traba-
lho 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 ins-
peciona a interface com base em um pequeno conjunto de princpios, chamados de
"heursticas". Esta inspeo sistemtica da interface busca problemas que prejudi-
quem 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 obje-
tivo 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
e o mundo
Devem ser seguidas converses do mundo real, as
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-
brar
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.
8. Esttica e design minimalista Mostrar somente informaes realmente necess-
rias.
9. Auxlio aos usurios para re-
conhecer, diagnosticar e recuperar
aes erradas
Mensagens de erro devem ser mostradas em lin-
guagem simples e indicar precisamente qual o
erro.
10. Ajuda e documentao O sistema deve oferecer alguma forma de docu-
mentao e a busca por informaes deve ser faci-
litada.
24
Em sua concepo inicial a avaliao heurstica determina que cada espe-
cialista 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 co-
nhecido 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 usabili-
dade reconhecidos. Quando o avaliador encontra um possvel problema de usabi-
lidade, 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 faci-
litador 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), consi-
deram 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 en-
tanto 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 in-
dividualmente no mesmo sistema, h uma tendncia de encontrar problemas du-
plicados 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 colabo-
rativa. 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 tra-
dicional.
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 reco-
mendado 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 avaliadoresvem os problemas ao mesmo tempo.
Eliminao da reunio de consolidao, os avaliadores atribuem individual-mente as severidades dos problemas.
Reduo da duplicao de esforos.
No entanto, alguns pontos negativos citados so risco de resultados ten-
denciosos 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 conhecimentosrelevantes eles possuem.
Uma descrio especfica de uma ou mais tarefas representativas que serodesempenhadas com o sistema.
Uma lista das aes corretas necessrias para completar cada uma das tarefascom 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 avalia-
o (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 correspon-
dentes (BARBOSA; SILVA, 2010). Em seguida feita a consolidao dos resultados,
onde as metamensagens so contrastadas e comparadas e os problemas de comuni-
cabilidade 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 fo-
ram 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 proble-
mas 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, di-
vididas 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 ade-
quada 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 desen-
volvida 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 pa-
cote 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 obser-
vao, 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 CRUI-
SER, 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 enge-
nharia de software sob a perspectiva gil.
Barbosa, Furtado e Gomes (2008) propem uma estratgia para institu-
cionalizao 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 ex-
perincias anteriores foram utilizados questionrios. Os objetivos de negcio e o
31
processo integrado com as prticas de usabilidade foram definidos em trs encon-
tros 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 profissio-
nais 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 de-
senvolvimento 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 Mc-
Crickard (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 aspec-
tos importantes da interface, definir objetivos de alto nvel e definir mecanismos
de comunicao e compartilhamento de informao para incluir os membros dis-
tantes.
Wolkerstorfer et al. (2008) mostra adaptaes ao processo clssico do Ex-
treme Programming (XP). Cinco instrumentos de IHC foram integrados com o
processo do XP. Estes instrumentos so: testes de unidade estendidos para avalia-
o 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 usu-
rios.
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 mto-
dos 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 descri-
tiva 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 Procedimentos Metodolgicos
3.2.1 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 co-
laboradores. 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 desen-
volvido pela empresa. Um dos grupos realizou a avaliao heurstica tradicional,
enquanto a outra equipe realizou a avaliao heurstica colaborativa. Foi deter-
minado 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 infor-
maes 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 opi-
nio do participante sobre o mtodo utilizado.
O projeto desenvolvido no foi avaliado pelo Comit de tica em Pesqui-
sas 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 es-
tudo, 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 usabili-
dade.
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 aplica-
tivo mvel e auxiliou na criao de somente algumas interfaces mais complexas
para outros projetos. No tem experincia com teste, no entanto participa da im-
plantao 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 requi-
sitos no profissionalmente. Tem pouca experincia com testes com usurios, e
nenhuma formao especfica para testes. J fez um curso com o tema de usabili-
dade, 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, desenvol-
vimento 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 desenvolvi-
mento de alguns sistemas quando solicitado pelo cliente.
Dois dos participantes esto cursando bacharelado em Sistemas de Infor-
mao. Um deles tem experincia em suporte em educao a distncia com moo-
dle, 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 reali-
zao.
O ltimo participante tem experincia de trs anos e meio de estgio com
desenvolvimento na linguagem Java, gesto de processos e inteligncia de neg-
cios. No estgio, trabalha com desenvolvimento de interfaces, mas sempre se-
guindo 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, proveni-
ente 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 siste-
mas 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 usabi-
lidade e as heursticas afetadas. O grupo que realizou a avaliao colaborativa
preencheu somente uma planilha, onde todos os problemas, apontados por qual-
quer 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. Es-
tes 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 heurs-
tica.
Na segunda parte do treinamento, os participantes realizaram uma avali-
ao 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 avali-
aes, 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 con-
solidao, 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 consoli-
dao 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 pro-
blemas encontrados em cada abordagem de avaliao heurstica. Na avaliao
tradicional, foram relatados os problemas encontrados em cada avaliao e tam-
bm 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 com-
parar 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 arre-
dondamento natural.
41
Por fim, a anlise qualitativa das respostas dos questionrios relaciona-
dos 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 partici-
pantes, 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 en-
contrados na interface pelos avaliadores. Cada problema poderia violar mais de
uma heurstica. Para cada heurstica afetada por um problema foi utilizada a no-
menclatura 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 denomina-
dos 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 Pe-
trie e Power (2012).
A quantidade de violaes por grupo de heursticas pode exceder a quan-
tidade 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 interativi-
dade 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 abrevia-
es claras.
Foram encontradas cinco violaes s heursticas de apresentao do sis-
tema. 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 apre-
sentou alto nmero de violaes. Ela orienta o fornecimento de estruturas de or-
ganizao 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 5
H1 - Textos e elementos interativos devem ser grandes e claros 1
H2 - O layout da pgina deve ser claro 2
H4 - Os principais contedos e possveis mudanas de contedo devem
ser destacados
2
Contedo 9
H5 - Fornea contedo relevante e apropriado para o site 3
H6 - Fornea contedo em quantidade suficiente, mas no excessiva 1
H7 - Utilize termos e abreviaes claras 5
Arquitetura da Informao 4
H8 - Fornea estruturas de organizao da informao claras e bem or-
ganizadas.
4
Interatividade 10
H10 - Instrues e rtulos claros 1
H11 - Evite esforo excessivo e repetio de aes 1
H13 - Fornea feedback para as aes do usurio e para mostrar o estado
do sistema
1
H14 - Faa com que a sequncia de interao seja lgica 2
H16 - Siga convenes para interao 1
H17 - Fornea as funcionalidades interativas que os usurios precisam
e esperam do sistema
1
H19 - Elementos interativos e no-interativos devem ser fceis de dis-
tinguir
2
H21 - Fornea mensagens de erros informativas e que auxiliem os usu-
rios a se recuperar de erros
1
45
O avaliador AT2 encontrou vinte e nove problemas de usabilidade no sis-
tema. 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 infor-
mao.
Nesta avaliao, a heurstica que apresentou mais violaes foi a de n-
mero dez, que integra o grupo de interatividade do sistema. Foram encontradas
nesta avaliao quatorze ocorrncias de violaes a esta heurstica. Nela de-
finido 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 inte-
ratividade 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 resul-
tados. Um dos avaliadores havia sado da empresa, portanto foi decidido que so-
mente 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
Tabela 4.2: Nmero de violaes de heursticas na avaliao realizada pelo AT2
Heursticas Nmero de violaes
Apresentao Fsica 4
H2 - O layout da pgina deve ser claro 4
Contedo 6
H5 - Fornea contedo relevante e apropriado para o site 2
H6 - Fornea contedo em quantidade suficiente, mas no excessiva 4
Arquitetura da Informao 1
H8 - Fornea estruturas de organizao da informao claras e bem or-
ganizadas.
1
Interatividade 37
H10 - Instrues e rtulos claros 14
H11 - Evite esforo excessivo e repetio de aes 1
H12 - Faa com que os formatos de entrada de dados sejam claros e
fceis
1
H13 - Fornea feedback para as aes do usurio e para mostrar o estado
do sistema
7
H14 - Faa com que a sequncia de interao seja lgica 3
H16 - Siga convenes para interao 3
H17 - Fornea as funcionalidades interativas que os usurios precisam
e esperam do sistema
1
H19 - Elementos interativos e no-interativos devem ser fceis de dis-
tinguir
6
H21 - Fornea mensagens de erros informativas e que auxiliem os usu-
rios a se recuperar de erros
1
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
Tabela 4.3: Nmero de violaes de heursticas na avaliao realizada pelo AT3
Heursticas Nmero de violaes
Apresentao Fsica 1
H1 - Textos e elementos interativos devem ser grandes e claros 1
Contedo 1
H5 - Fornea contedo relevante e apropriado para o site 1
Arquitetura da Informao 3
H8 - Fornea estruturas de organizao da informao claras e bem or-
ganizadas.
3
Interatividade 7
H9 - Fornea informaes claras sobre a interao com o sistema
("como e porque")
1
H10 - Instrues e rtulos claros 2
H11 - Evite esforo excessivo e repetio de aes 1
H12 - Faa com que os formatos de entrada de dados sejam claros e
fceis
2
H15 - Fornea um conjunto de opes lgico e completo 1
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 orga-
nizao das estruturas de informao. A heurstica treze, integrante do grupo de
interatividade do sistema, define o fornecimento de feedback para as aes reali-
zadas pelo usurio.
Assim como nas avaliaes individuais, o grupo de heursticas mais afe-
tado 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
H1 - Textos e elementos interativos devem ser grandes e claros 2
H2 - O layout da pgina deve ser claro 6
H4 - Os principais contedos devem ser destacados 2
Contedo 11
H5 - Fornea contedo relevante e apropriado para o site 5
H6 - Fornea contedo em quantidade suficiente, mas no excessiva 1
H7 - Utilize termos e abreviaes claras 5
Arquitetura da Informao 8
H8 - Fornea estruturas de organizao claras e bem organizadas. 8
Interatividade 41
H9 - Fornea informaes claras sobre a interao com o sistema 1
H10 - Instrues e rtulos claros 14
H11 - Evite esforo excessivo e repetio de aes 2
H12 - Faa com que os formatos de entrada de dados sejam claros e fceis 3
H13 - Fornea feedback para as aes do usurio e estado do sistema 7
H14 - Faa com que a sequncia de interao seja lgica 3
H15 - Fornea um conjunto de opes lgico e completo 1
H16 - Siga convenes para interao 2
H17 - Fornea as funcionalidades que os usurios precisam e esperam do sis-
tema
2
H19 - Elementos interativos e no-interativos devem ser fceis de distinguir 5
H20 - Agrupe elementos interativos de forma lgica e clara 1
H21 - Fornea mensagens de erros informativas 1
49
Quanto ao contedo, foram encontrados onze violaes. A apresentao fsica
apresentou dez violaes e a arquitetura da informao, oito.
4.1.2 Avaliao Heurstica Colaborativa
Como resultado da avaliao heurstica colaborativa foram encontrados
vinte e dois problemas de usabilidade no sistema. A Tabela 4.6 mostra a quanti-
dade de violaes para cada grupo de heursticas.
As heursticas que mais apresentaram violaes no sistema foram as re-
ferentes 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 funcio-
nalidades 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 visibi-
lidade 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. Es-
tas 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 de-
fine que deve ser fornecido retorno para as aes realizadas pelo usurio e demons-
trado 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 4
H2 - O layout da pgina deve ser claro 2
H4 - Os principais contedos e possveis mudanas de contedo devem
ser destacados
2
Contedo 3
H5 - Fornea contedo relevante e apropriado para o site 2
H6 - Fornea contedo em quantidade suficiente, mas no excessiva 1
Arquitetura da Informao 3
H8 - Fornea estruturas de organizao da informao claras e bem or-
ganizadas.
3
Interatividade 13
H12 - Faa com que os formatos de entrada de dados sejam claros e
fceis
2
H13 - Fornea feedback para as aes do usurio e para mostrar o estado
do sistema
5
H14 - Faa com que a sequncia de interao seja lgica 1
H15 - Fornea um conjunto de opes lgico e completo 1
H17 - Fornea as funcionalidades interativas que os usurios precisam
e esperam do sistema
3
H21 - Fornea mensagens de erros informativas e que auxiliem os usu-
rios a se recuperar de erros
1
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 n-
mero maior de heursticas foi mencionado na avaliao tradicional do que na ava-
liao 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 proble-
mas. Considerando que alguns problemas foram encontrados nos dois mtodos,
foram encontrados 55 problemas nicos. A Figura 4.1 mostra o nmero de proble-
mas 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 proble-
mas cosmticos e simples, respectivamente. Quatorze problemas foram conside-
rados cosmticos, e quinze problemas considerados simples. Problemas simples
devem ter prioridade menor no desenvolvimento do sistema e problemas cosmti-
cos 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 Avaliao Heurstica Colaborativa
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 consi-
derar que um problema identificado por outro avaliador no realmente um pro-
blema. 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 hou-
ver tempo disponvel.
As severidades zero e quatro, que representam, respectivamente, pontos
que no foram considerados problemas e problemas catastrficos, no foram re-
gistradas.
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 dife-
renas 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 en-
tre 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 encon-
trados nas duas avaliaes verificou que trs deles tinham o mesmo nvel de se-
veridade. 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 cola-
borativa.
Foi feita uma comparao entre os nveis de severidade dos problemas que
foram encontrados exclusivamente na avaliao heurstica tradicional e na avali-
ao heurstica colaborativa. Um teste de Mann-Whitney para amostras indepen-
dentes mostrou uma diferena significativa entre a severidade mdia dos problemas
encontrados na avaliao colaborativa e o nvel de severidade da avaliao tradi-
cional (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 ti-
veram 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 proble-
mas 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 co-
mentrios 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 as-
sunto. 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 fize-
ram observaes sobre os casos de problemas iguais encontrados por diferentes
avaliadores. Um deles relatou que algumas vezes as heursticas no eram as mes-
mas, 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 carac-
terizava 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 proble-
mas, e no solues. Ele baseou esta concluso no funcionamento atual da em-
presa. 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 elabora-
dos 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 se-
ria 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 sen-
tido dificuldade em expressar sua opinio, relatar problemas em voz alta ou enten-
der 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 heu-
rsticas foram bem explicadas no treinamento e que estavam descritas de forma
clara no documento disponibilizado para consulta. Um dos participantes manifes-
tou, 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 desenvol-
vedores no conseguem encontrar todos os problemas da interface. Tambm foi
declarado que seria interessante a aplicao da avaliao de usabilidade a cada ite-
rao do desenvolvimento, pois assim seriam avaliadas partes menores do sistema
e aumentaria a viso crtica da equipe para o desenvolvimento de novas funciona-
lidades.
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 discus-
ses entre o grupo, pois ao ouvir a opinio do outro possvel a
Top Related