Inspeção de Usabilidade Aplicada a Métodos Ágeis.pdf

78
SARAH FIGUEIREDO CAIXETA LEITE INSPEÇÃO DE USABILIDADE APLICADA A MÉTODOS ÁGEIS: UM ESTUDO DE CASO LAVRAS – MG 2013

Transcript of 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, 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