Evoluindo um Assistente de Apoio à Inspeção de
Usabilidade através de Estudos Experimentais
Fábio Santos2, Tayana Conte1
1Departamento de Ciência da Computação – Universidade Federal do Amazonas 2
Instituto Nokia de Tecnologia – IndT – Manaus, Brazil [email protected], [email protected]
Abstract This paper presents the development of an assistant to support usability inspection for Web applications - APIU. The development was based on the execution and analysis of results of experimental studies. The objectives of this paper are: to explain the experimental studies and the quantitative and qualitative analysis of each study. The qualitative analysis was based on procedures of two complementary techniques – The Technology Acceptance Model (TAM) and Grounded Theory (GT). We also presented the evolution of APIU based on improvements suggested by the studies’ results.
1. Introdução
Usabilidade é um dos aspectos relacionados à qualidade em uso de interfaces de sistemas, sendo um dos mais importantes critérios de aceitação para aplicações interativas em geral, e, em particular, para aplicações Web [10]. Em uma aplicação com boa usabilidade o usuário tem maior produtividade, aprende mais rápido a usar, memoriza as operações e tende a cometer menos erros.
Assim como testes de funcionalidade são importantes para avaliar a implementação, a avaliação de interface é importante para analisar a qualidade de uso de um software. A qualidade de uso está estreitamente relacionada à capacidade e facilidade de os usuários atingirem suas metas com eficiência e satisfação [20].
A aplicação dos conceitos de usabilidade tem como objetivo elaborar interfaces capazes de permitir uma interação fácil, agradável, com eficácia e eficiência [8]. Pesquisas descritas por [2], [3], [8] e [22] focam em elaborar mecanismos que auxiliem a avaliação de usabilidade das aplicações Web.
No contexto de avaliações de usabilidade, os métodos mais comumente adotados podem ser divididos em duas grandes categorias [20]: (1) Inspeções de Usabilidade (ou Métodos Analíticos), nas quais inspetores (normalmente especialistas) examinam aspectos relacionados à usabilidade da aplicação, para detectar violações de princípios de usabilidade estabelecidos; e (2) Métodos de avaliação baseados na participação direta de usuários (também chamados de Testes de Usabilidade), onde os problemas de usabilidade são encontrados através da observação e da interação com os usuários, enquanto os mesmos realizam algumas tarefas ou comentam a interface.
O foco dessa pesquisa está relacionado às inspeções de usabilidade. Várias técnicas e tecnologias têm sido propostas com o intuito de reduzir o custo e o tempo total empregados em uma inspeção e facilitar a execução da mesma, tais como GRIP [12], IBIS [16], ISPIS [14], que são aplicações que apóiam inspeções durante o desenvolvimento de software com foco em artefatos produzidos no processo de desenvolvimento. As inspeções de usabilidade focam na revisão do produto de software em si. Com o objetivo de apoiar o processo de inspeção de usabilidade de
aplicações Web, algumas aplicações específicas foram definidas, tais como: TOWABE [13] e SUIT [1]. Entretanto, estas aplicações utilizam apenas técnicas de inspeção pré-definidas para auxiliar a detecção, o que limita sua utilização.
Este artigo apresenta um assistente para automatização do processo de inspeção de usabilidade de aplicações, que pode ser configurado para utilizar qualquer técnica de inspeção de usabilidade, entre outras características. O artigo descreve a evolução do assistente através de estudos experimentais, são relatadas as análises quantitativas e qualitativas dos estudos, bem como as melhorias realizadas após os estudos. A análise qualitativa nos estudos se baseou em duas técnicas complementares: o modelo de aceitação de tecnologia TAM [7] e análise de questionários de acompanhamento utilizando os procedimentos de Grounded Theory [17].
Este artigo está estruturado da seguinte forma. A Seção 2 apresenta um breve referencial teórico sobre inspeções de usabilidade e o processo de inspeção. A Seção 3 descreve como o Assistente proposto auxilia o processo de inspeção de usabilidade. A Seção 4 apresenta o primeiro estudo de viabilidade realizado para avaliar o assistente proposto, bem como os resultados quantitativos, qualitativos e melhorias realizadas. A Seção 5 expõe o segundo estudo experimental e as análises realizadas e também relata a evolução do assistente. A Seção 6 apresenta as ameaças à valide. Por fim, a Seção 7 apresenta as conclusões, lições aprendidas e trabalhos futuros.
2. Inspeção de Usabilidade e Processo de Inspeção
Segundo [19], os métodos de inspeção de usabilidade não exigem muito esforço de quem pretende utilizá-los e podem ser facilmente integrados com os mais variados esquemas de produção de software, sem ter que modificar a forma como os sistemas são desenvolvidos e gerenciados, de modo a obter grandes benefícios da inspeção de usabilidade. De acordo com [22] em relação às inspeções de usabilidade: “não são necessários equipamentos especiais e um único inspetor pode encontrar vários defeitos de usabilidade em pouco tempo”. São métodos de avaliação executados por especialistas em usabilidade e/ou profissionais de desenvolvimento de software.
A inspeção de usabilidade deve seguir um processo de inspeção que defina a seqüência de passos a ser executada para a realização da avaliação pelos especialistas. O processo tradicional de inspeção de software envolve um moderador que planeja a inspeção, inspetores que revisam um artefato, uma reunião para discussão e registro dos defeitos que são encaminhados ao responsável para correção dos defeitos [8].
Ao longo do tempo várias adaptações do processo de inspeção foram sugeridas. Nesta pesquisa o processo de inspeção utilizado teve por base o processo sugerido por [23], que vem sendo utilizado como base por várias pesquisas recentes em inspeção [3], [10], [15]. As atividades que compõem este processo são descritas a seguir: • Planejamento: Atividade em que se define o escopo da inspeção, a preparação do
roteiro de interações a serem inspecionadas, a seleção e divisão dos inspetores, o treinamento na técnica a ser utilizada e a atribuição de tarefas para cada inspetor; • Detecção: Detecção individual de problemas de usabilidade pelos inspetores; • Coleção: Eliminação de discrepâncias repetidas (encontradas por mais de um
inspetor), gerando uma lista de discrepâncias únicas (sem duplicatas);
• Discriminação: Classificação das discrepâncias em defeitos reais. As discrepâncias não classificadas como defeitos são consideradas falso-positivos.
Para a realização destas atividades, os participantes da inspeção normalmente são compostos por três papéis:
• Moderador: gerencia o processo de inspeção, sendo condutor/ apoio de cada fase; • Inspetor: responsável por identificar e registrar os defeitos, e;
• Responsável pelo sistema: responde pelo sistema e atua decisivamente na classificação das discrepâncias em defeitos ou falso-positivos.
3. APIU
O Assistente APIU (Apoio ao Processo de Inspeção de Usabilidade) se propõe a automatizar as atividades do processo de inspeção de usabilidade, tendo como base o processo proposto por [23].
Na atividade de Planejamento, o APIU possibilita o cadastro de informações necessárias para a inspeção, tais como a criação de uma nova inspeção e a definição de suas atividades, o cadastro de inspetores e sua associação a inspeções, e a definição da técnica de inspeção que será utilizada. Todos os dados provenientes das ações de cadastro/registro (por exemplo: informações dos inspetores, as discrepâncias registradas, a definição da lista única, e a classificação realizada nas fases de Discriminação e Análise e Priorização de Defeitos) são armazenados na base de dados do assistente, servindo como repositório para verificação de histórico, em momentos posteriores. Caso os inspetores já tenham algum registro de inspeções anteriores pode-se verificar o depode-sempenho deles, para auxiliar em tomadas de decisões.
Dentre os requisitos do APIU destacam-se a possibilidade de independência da técnica de inspeção a ser utilizada, a geração automática da lista única de discrepâncias, cadastro dos defeitos sugeridos de acordo com a técnica de inspeção e uma melhor organização dos dados referentes à inspeção. A independência da técnica é importante, pois o Assistente não se limitaria a executar uma inspeção restrita ao escopo de uma técnica específica. No APIU, as técnicas de inspeção são descritas através de arquivos XML, sendo possível acrescentar qualquer técnica para uso.
Na atividade de Detecção, o APIU exibe aos inspetores a técnica definida para a realização da inspeção, o roteiro de atividades e possibilita o registro das discrepâncias. O APIU faz uso de termos de auxílio1 e para cada termo há uma lista de defeitos sugeridos, com o propósito de padronizar a descrição dos defeitos pelos inspetores, o que facilitará a Coleção de dados. Desta forma, no momento em que o inspetor for descrever a discrepância, ele escolhe o termo de auxílio e em seguida escolhe o defeito sugerido que é equivalente à discrepância detectada. Para exemplificar citamos uma heurística de Nielsen [19], que é o termo de auxílio: “Ajuda e documentação” e associado a ele o seguinte defeito sugerido: “Opções de ajuda e documentação não estão claramente visíveis para o usuário”. Dessa forma são sugeridos os possíveis defeitos para cada termo de auxílio relacionado à técnica. Caso o inspetor não encontre o defeito que mais se assemelha ao que ele detectou, ele poderá cadastrar novos defeitos sugeridos e estes serão incluídos na lista de defeitos padrão.
Na atividade de Coleção, o APIU gera automaticamente um relatório com todas as discrepâncias encontradas na inspeção, agrupando-as de acordo com os defeitos sugeridos (geração da lista única de discrepâncias). Adicionalmente, o moderador da
1
inspeção tem a opção de alterar o agrupamento realizado pelo sistema, reorganizando do modo que achar correto, tendo como chave do agrupamento os defeitos sugeridos.
Na atividade de Discriminação, o APIU lista todas as discrepâncias reunidas na fase de Coleção e discute-se em uma reunião se dada discrepância é ou não um defeito real. As imagens coletadas para cada discrepância permitem que os defeitos possam ser avaliados sem a necessidade de acessar a aplicação inspecionada. A classificação das discrepâncias é registrada no assistente e esses dados servirão como base para os relatórios referentes aos defeitos e falso positivos detectados na inspeção.
Para a atividade de Análise e Priorização, o APIU permite a definição da prioridade de correção e a severidade dos defeitos encontrados. Na priorização de defeitos, têm-se as seguintes opções: resolução imediata, resolução postergada (por decisão de projeto) e resolução indefinida (defeitos sem solução prevista). A severidade poderá ser definida como: cosmético, leve, grave e catastrófico, conforme escala descrita em [19]. Além do apoio à cada atividade do processo de inspeção, o APIU disponibiliza também um menu de Relatórios nos quais é possível listar os dados (defeitos e falso-positivos) por inspetor e por inspeção, entre outros relatórios. Os relatórios auxiliam a análise quantitativa dos resultados, reduzindo o tempo gasto na análise.
4. Primeiro Estudo Experimental
De acordo com a metodologia experimental proposta por [18], o primeiro estudo que deve ser realizado para a avaliação de uma nova tecnologia é um estudo de viabilidade, que visa avaliar se a nova tecnologia é viável e se o tempo empregado é bem utilizado. A viabilidade do APIU foi analisada em relação a dois fatores: (1) tempo empregado, onde se verificou o tempo gasto em cada atividade do processo de inspeção em comparação ao tempo quando não se utiliza o APIU e; (2) resultados obtidos, em que foi verificado se o APIU interferia no resultado da inspeção, ou seja, na quantidade de defeitos e falso positivos encontrados. Este estudo foi descrito em detalhes em [9], a seguir é apresentado um resumo da execução e análise dos resultados deste 1º estudo.
Participantes: Participaram do estudo seis profissionais da empresa, sendo cinco
analistas de sistemas e um gerente de projetos. Quatro analistas de sistemas atuaram como inspetores. O quinto analista atuou como responsável pelo sistema e o gerente de projetos foi responsável pela coleção de dados. Todos assinaram um Termo de Consentimento Livre e Esclarecido e preencheram um formulário de caracterização contendo perguntas sobre o seu conhecimento em usabilidade, avaliações e inspeções de software, desenvolvimento de software Web e a relação do profissional com a aplicação a ser inspecionada (participação na análise, programação, design ou teste dos casos de uso da aplicação ou de aplicações similares). Os inspetores foram divididos em dois grupos (A e B), onde cada grupo continha dois inspetores com níveis de experiência balanceados de acordo com as respostas dos formulários de caracterização.
Objeto de estudo: O gerente de projetos indicou o sistema institucional Pós Vendas
(PV), um software institucional utilizado no gerenciamento de chamados realizados pelos clientes da empresa. Foram utilizados dois roteiros de inspeção (1 e 2), cada um com quatro atividades, divididas de modo balanceado em relação à complexidade, com apoio do responsável pelo sistema. A divisão não interfere nos resultados, pois ambos os grupos utilizaram os dois roteiros.
Procedimento: A capacitação dos inspetores foi feita em dois treinamentos. O
primeiro treinamento teve duração de uma hora e incluía os conceitos de usabilidade e a técnica de inspeção WDP-RT [10], adotada neste estudo. O segundo treinamento, com duração de 30 minutos, demonstrava como registrar defeitos no APIU e na planilha de anotação de defeitos. Esse treinamento foi necessário, pois foi realizada a comparação entre o APIU (apoiando o registro de defeitos) e o modo manual (planilha eletrônica). Essa comparação teve como objetivo de verificar qual o ganho ou perda quando se utiliza o APIU para registro de discrepâncias ao invés da planilha. Os parâmetros de comparação foram: o tempo gasto e a quantidade de defeitos registrados. A inspeção constituiu-se de duas partes distintas. Na primeira, os inspetores realizaram as atividades do roteiro 1, sendo que o grupo A utilizou o APIU para registrar os defeitos, e o grupo B registrou os defeitos na planilha. Na segunda parte, os inspetores realizaram as atividades do roteiro 2, sendo que nesta etapa o grupo A utilizou a planilha para registrar os defeitos, enquanto o grupo B utilizou o APIU.
O gerente de projetos recebeu um treinamento separado, com duração de 45 minutos, que consistiu em uma apresentação do objetivo da Etapa de Coleção de Dados e em exercícios de coleção, utilizando tanto a planilha (coleção manual) quanto o APIU, empregando dados reais coletados no estudo apresentado em [10].
Coleção de dados: Após a detecção das discrepâncias o gerente recebeu as planilhas e
teve acesso ao APIU para realizar a coleção. No total foram analisadas as quatro planilhas de discrepâncias, e as discrepâncias registradas no APIU. Foi realizada a coleção das planilhas de discrepâncias e a coleção dos dados registrados no APIU.
As listas de discrepâncias individuais (planilha) foram integradas a uma única lista e o gerente ficou responsável em decidir quais dessas discrepâncias eram únicas e quais eram duplicatas (discrepâncias equivalentes apontadas por mais de um inspetor). O gerente também realizou a coleção para os dados registrados no APIU.
A reunião de discriminação contou com a participação do pesquisador envolvido nesse projeto e com o responsável pelo sistema. Cada discrepância relatada foi avaliada e após a discussão, classificada como defeito ou falso-positivo, sendo o responsável pelo sistema quem classifica o defeito e define a prioridade de correção. O responsável pela coleção não participou, pois o mesmo estava de férias neste período.
4.1 Análise dos Resultados
Para avaliar a viabilidade do Assistente APIU, foi realizada a análise quantitativa e qualitativa. Em [9] são descritos mais detalhes em relação aos dados da análise. Na Análise quantitativa foi medido o tempo empregado pelos participantes do estudo na execução de suas atividades com e sem a utilização do APIU e a quantidade de defeitos registrados pelos inspetores com e sem o auxílio do APIU. Os resultados quantitativos apresentavam indícios negativos em relação à viabilidade do Assistente.
A Análise qualitativa se baseou nos questionários preenchidos pelos inspetores e pelo gerente de projetos com o propósito de verificar suas opiniões sobre o Assistente APIU e como se procedeu a inspeção para cada participante. Após a analise qualitativa foi possível apontar as possíveis causas para os resultados negativos em relação à viabilidade, onde se destacou a baixa interação entre assistente e técnica de inspeção. Nesse primeiro estudo o assistente tratava de forma diferente a relação: termos de auxílio e defeitos sugeridos, sendo que os termos de auxílio eram: “Apresentação de Interface”, “Busca de informações e opções”, “Compreensão de termos”, “Entrada de
dados”, “Estado do sistema”, “Execução de tarefas”, “Mensagens”, “Navegação”, “Opção de ajuda” e “Personalização”, e não estavam associados aos dados da técnica, quando o inspetor ia descrever o defeito encontrava dificuldades e isso interferiu nos resultados relacionados ao tempo e a satisfação de quem realizava a inspeção.
Segue abaixo as melhorias desenvolvidas no assistente a partir da análise qualitativa: • Redução da quantidade de informações na página responsável pelo controle das
discrepâncias inseridas;
• Alteração dos termos de auxílio;
• Disposição da técnica de inspeção na página de cadastro de discrepâncias; • A lista única de defeitos na coleção mais simples de ser alterada;
4.2 Evolução do APIU
O primeiro estudo experimental apresentou resultados negativos do APIU. Foi considerado o tempo gasto pelos inspetores no cadastro de defeitos no assistente em comparação com o cadastro de modo manual. De acordo com os dados da análise, foi apontada como principal melhoria a ser realizada: tornar a interação entre APIU e técnica de inspeção mais simples e que facilite a realização da detecção dos defeitos.
Foi apontado como crítico o momento que o inspetor já havia encontrado o defeito no sistema inspecionado e ia registrá-lo no assistente, então esse era o ponto a ser melhorado. O APIU tem como uma de suas características ser independente de técnica de inspeção, a idéia inicial era ter o mínimo de informação da técnica descrita diretamente no assistente, por esta razão o conceito dos termos de auxílio (mencionados na seção 2) se tornou interessante e foi inserida no assistente. O problema é que os inspetores se baseiam na técnica de inspeção para auxiliar a encontrar os defeitos, e a forma como os termos de auxílio foram definidos não mantinha uma conexão direta com os itens da técnica de inspeção utilizada. Isto tornou o cadastro do defeito uma tarefa cansativa e desestimulante.
Como alternativa para esse problema, os inspetores mencionaram que os termos de auxílio deveriam se basear na técnica de inspeção. Foi modificado o cadastro da técnica, sendo que os termos de auxílio ficaram ligados aos dados da técnica, e associados a esses termos os defeitos sugeridos, com a estrutura conforme a Figura 1.
Figura 1. Associação entre termos de auxílio e defeitos sugeridos.
As modificações referentes às melhorias capturadas pela análise qualitativa do estudo resultaram na segunda versão do assistente, descrita em [9].
5. Segundo Estudo Experimental
No processo de evolução do assistente faz-se necessário avaliar se as mudanças agregadas no primeiro estudo refletem em melhorias para os inspetores e para o gerenciamento do processo de inspeção. Foi realizado um novo estudo de viabilidade, no modelo do primeiro estudo, onde o objetivo era verificar a viabilidade do APIU em relação ao tempo empregado nas fases de detecção, coleção e discriminação e os
resultados de defeitos e falso-positivos coletados. O estudo constituiu-se de uma inspeção de usabilidade utilizando-se a técnica WDP [4] e foi realizado nos meses de julho e agosto de 2010 em ambiente acadêmico.
5.1 Condução do Estudo
Participantes: Participaram desse estudo quatorze inspetores e três moderadores,
sendo os inspetores alunos da disciplina Interação Humano Computador e Engenharia de Software do curso de Ciência da Computação da Universidade Federal do Amazonas, e os moderadores pesquisadores na área de Engenharia de Software e IHC. Todos os participantes assinaram um Termo de Consentimento Livre e Esclarecido e preencheram um formulário de caracterização que continham questões sobre a experiência dos participantes em relação ao seu conhecimento sobre usabilidade, avaliações e inspeções de software e em desenvolvimento de software.
Objeto de estudo: O sistema inspecionado foi o JEMS - Journal and Event
Management System, que tem como objetivo dar suporte ao gerenciamento de submissões e revisão de artigos para eventos científicos e revistas promovidas pela Sociedade Brasileira de Computação (SBC).
Foram utilizados dois roteiros de inspeção (1 e 2), onde o roteiro 1 continha quatro atividades e o roteiro 2 continha três atividades. Os roteiros tiveram como base os roteiros utilizados no estudo de viabilidade visto em [4].
Procedimento: A capacitação dos inspetores consistiu de: (a) treinamento com
duração de uma hora que incluía os conceitos de usabilidade e a técnica de inspeção WDP [4], adotada neste estudo; (b) treinamento, com duração de 30 minutos, que demonstrava como registrar defeitos no APIU e na planilha de anotação de defeitos.
A inspeção constituiu-se de duas partes distintas. Os inspetores foram divididos em dois grupos (A e B), onde cada grupo foi formado por sete inspetores. Primeiramente o Grupo A utilizou o Roteiro 1 e registrou as discrepâncias na Planilha, em paralelo o Grupo B utilizou o Roteiro 2 e registrou as discrepâncias no APIU. No segundo momento os Grupos inverteram o modo de registro das discrepâncias.
Os moderadores receberam um treinamento diferente, com duração de 45 minutos, que consistiu em uma apresentação do objetivo da etapa de Coleção de Dados, da Discriminação de defeitos e Análise e Priorização. Foram realizados alguns exercícios para auxiliar o entendimento de como realizar as etapas do processo de inspeção, utilizando dados reais coletados no estudo apresentado em [10].
Coleção de dados: Após a detecção das discrepâncias os moderadores receberam as
planilhas e tiveram acesso ao APIU para realizar suas atividades. No total, quatorze planilhas de discrepâncias e todas as discrepâncias registradas no APIU foram analisadas. Depois foi realizada a Discriminação dos Defeitos e Análise e Priorização.
As listas de discrepâncias individuais (planilha) foram integradas a uma única lista e os moderadores decidiram quais discrepâncias eram únicas e quais eram duplicatas (discrepâncias equivalentes apontadas por mais de um inspetor). No APIU, que gera a lista única, os moderadores editaram a lista conforme definiram necessário.
A reunião de discriminação utilizou um oráculo de defeitos coletado no estudo realizado em [4]. Cada discrepância relatada foi avaliada e classificada como defeito ou falso-positivo, com base no oráculo foi realizada a Análise e Priorização dos defeitos.
5.2 Resultados Quantitativos
A análise quantitativa teve como objetivo verificar se o tempo empregado nas fases do processo de inspeção, utilizando o assistente, era aceitável em comparação com o modo manual. Os dados quantitativos são visualizados nas Figuras 3, 4, 5, 6, 7, 8 e 9.
Figura 3. Detecção utilizando Planilha e Roteiro 1. Figura 4.Detecção utilizando APIU e Roteiro 1.
Figura 5.Detecção utilizando Planilha e Roteiro 2. Figura 6.Detecção utilizando APIU e Roteiro 2.
As Figuras 7 e 8 representam um resumo das tabelas anteriores, com foco no tempo gasto para realizar a inspeção e a quantidade de defeitos por hora que os inspetores necessitaram para realizar a fase de detecção.
Figura 7.Média: tempo e defeitos/hora-Roteiro 1. Figura 8. Média: tempo e defeitos/hora - Roteiro 2.
As Figuras 7 e 8 apontam que o tempo gasto pelos inspetores utilizando o APIU está relativamente próximo do tempo gasto quando se registra através do modo manual. É preciso notar que quando se utiliza o APIU, há a opção de cadastro de imagens das discrepâncias coletadas, o que tende a gerar mais um acréscimo no tempo de registro das discrepâncias.
Figura 9. Tempo Gasto em minutos nas Fases de Coleção e Discriminação.
A Figura 9 exibe o tempo que os moderadores necessitaram para executarem as fases de Coleção e Discriminação. Era esperado que o Assistente obtivesse menores tempos em relação ao modo manual, e conforme aconteceu no primeiro estudo, isso foi alcançado também nesse segundo estudo. Na coleção se ganha mais tempo, pois o APIU gera a lista única de defeitos, e na discriminação se ganha na melhor organização dos dados e o auxílio da geração dos relatórios sobre a inspeção.
Os dados quantitativos apontam a evolução do Assistente em relação à primeira versão, mas ainda se faz necessário investigar melhor o estudo e para isso é relatada na próxima seção, a Análise Qualitativa.
5.3 Resultados Qualitativos
Segundo [16] investigar a aceitação dos usuários para uma tecnologia requer um modelo que explique as atitudes e comportamentos das pessoas. Para realizar a análise qualitativa foi utilizado o modelo de aceitação de tecnologia (Technology Acceptance Model - TAM) proposto por [7], onde sua estrutura se baseia em dois fatores: (1) Percepção sobre utilidade (Perceived usefulness), definida como “o grau no qual uma pessoa acredita que utilizar uma tecnologia específica melhoraria seu desempenho no trabalho” e (2) Percepção sobre facilidade de uso (Perceived ease of use), definida como “o grau no qual uma pessoa acredita que utilizar uma tecnologia específica seria livre de esforço” [16].
Na análise qualitativa foram utilizados os questionários preenchidos após a inspeção, onde os participantes relataram suas ações e impressões em relação à utilização do APIU. O modelo TAM utilizou uma escala de seis pontos, tendo como base os questionários aplicados por [16] e similar ao aplicado no primeiro estudo experimental, detalhado em [9]. Nesse questionário, os inspetores respondiam qual o seu grau de concordância em relação a utilidade e facilidade de uso do APIU. Outras questões foram adicionadas ao questionário, relacionados ao modo de utilização do assistente, a satisfação no uso, as vantagens e desvantagens, interação entre o APIU e a técnica de inspeção de usabilidade, as melhorias e sugestões referentes à usabilidade do assistente, e sugestões dos participantes para tornar o APIU mais robusto e eficiente.
Figura 10. Questionamentos relacionados à Percepção sobre a facilidade de uso. A Figura 10 exibe as respostas referentes à Percepção sobre facilidade de uso do APIU, onde se destaca a boa avaliação dada ao assistente pelos inspetores. Os dados quantitativos apontam que se gasta um pouco mais de tempo quando se utiliza o assistente em relação à planilha, mas de acordo com a Figura 10 isso não interfere na facilidade de uso do mesmo.
As respostas relacionadas à Percepção sobre utilidade são exibidas na Figura 11. A primeira questão menciona se o APIU auxilia a tornar a inspeção mais rápida, os inspetores escolheram entre as quatro primeiras opções (modelo TAM). Deve-se levar em consideração que o objetivo do Assistente não é tornar a inspeção mais rápida, mas sim gerenciar melhor o processo de inspeção.
Figura 11. Gráficos sobre os questionamentos à Percepção sobre a utilidade do APIU. As questões seguintes relatam sobre o Assistente facilitar a inspeção, melhorar o desempenho do inspetor, ser útil na detecção de defeitos e auxiliar a técnica de inspeção.Os gráficos apontam para resultados similares ao do primeiro gráfico, onde é importante afirmar que o foco do assistente é ser útil nas fases do processo, mas não tem como objetivo interferir diretamente na melhoria da detecção de defeitos. Este objetivo teria uma relação maior com as habilidades dos inspetores e também as facilidades que a técnica de inspeção agrega, quando utilizada. Para a maioria dos participantes, a aceitação ficou entre as duas primeiras categorias (70% a 100%).
Após a análise através do modelo TAM, foi feita uma análise específica dos dados qualitativos contidos nos questionários, tendo por base o método Grounded Theory (GT) [17]. Os dados qualitativos foram analisados utilizando um subconjunto das fases do processo de codificação descrito em [17] para o método GT – as codificações aberta e axial. Conceitos referentes ao método GT são apresentados em [5].
O propósito da análise qualitativa foi entender qual a percepção dos inspetores sobre a experiência de uso e coletar sugestões de melhorias de usabilidade no APIU.
Os questionários tiveram maior direcionamento para as questões relacionadas à melhorias de usabilidade, pontos positivos e pontos negativos do APIU. Os códigos foram criados conforme a leitura dos questionários, a partir de citações do texto. No total foram identificados 26 códigos, divididos nas categorias seguintes: (a) “Problemas Relatados” – Funcionalidades ou pontos que precisam ser revistos e modificados com o intuito de aperfeiçoar o auxílio que o APIU realiza durante a inspeção, (b) “Pontos Positivos” – relata os pontos onde o assistente trouxe benefícios aos usuários durante a inspeção, e (c) “Sugestões de Melhorias de Usabilidade” – Nessa categoria é descrito o que poderia ser melhorado no assistente para o mesmo apresentar melhor usabilidade e também modificações em funcionalidades presentes no assistente para obter-se maior ganho com a utilização do APIU.
Na categoria “Problemas Relatados” foram definidos seis códigos, sem um problema em destaque, mas vários pontos que precisavam ser revistos.
Figura 11. Esquema Gráfico da Categoria: Problemas Relatados.
Na Figura 11, alguns problemas são de fácil correção como os códigos: “Tive dificuldades de encontrar o botão Sair” e “o ambiente tem alguns problemas de navegabilidade como a falta de botões voltar”, já os códigos referentes à navegabilidade e a interface requerem um estudo maior sobre como agregar essas modificações no Assistente. O problema citado referente ao código: “o menu principal devia dar uma ajuda mais detalhada do sistema” é algo já recorrente. Por ocorrer o treinamento sobre como utilizar o assistente, acreditava-se que uma ajuda seria menos relevante, mas com a análise foi constatado que é um problema a ser resolvido.
Figura 12. Esquema Gráfico da Categoria: Pontos Positivos.
Na categoria “Pontos Positivos” os códigos direcionam para a questão dos defeitos sugeridos, da interação entre técnica de inspeção e assistente, e a melhor organização dos dados sobre a discrepância. O código “a ferramenta não ajuda na detecção de erros, mas sim no gerenciamento deles” relata bem o objetivo do Assistente. No primeiro estudo o grande problema apontado pelos inspetores foi a baixa interação entre técnica e APIU, de acordo com os inspetores desse estudo este problema parece ter sido contornado, os dados quantitativos também apontam para isso, onde a média dos tempos ficaram próximos. A Figura 12 exibe os códigos dessa categoria.
A categoria “Sugestões de Melhorias na Usabilidade” representa um dos focos do estudo, que era coletar melhorias ao Assistente e principalmente melhorias de usabilidade, foram obtidos bastante dados, conforme pode ser visto na Figura 13. A categoria obteve no total 11 códigos, onde destacamos os dados referentes à “Ajuda”, “Navegabilidade” e “Reconhecimento de ícones”, onde os dois últimos são relacionados com usabilidade. Há pontos que são mais complicados de serem acrescidos no assistente, como os referente aos códigos “cadastrar vários erros seguidos, sem ter que clicar novamente em cadastrar” e “Apenas que ele poderia ter um contador de minutos que auxiliariam na hora de contar o tempo”. As opções de “Ajuda”, “Navegabilidade” e “Reconhecimento de ícones” serão verificadas para serem inseridas na próxima versão do APIU.
Figura 13. Esquema Gráfico da Categoria: Sugestões de Melhorias na Usabilidade.
6. Ameaças à Validade
As ameaças à validade deste 2º estudo de viabilidade são discutidas a seguir:
Validade Interna: foram consideradas as ameaças: (a) efeitos de treinamento, (b)
medição de tempo. A segunda ameaça foi contornada através do treinamento com o mesmo material (exemplos) e para todos os participantes explicando como registrar as discrepâncias na Planilha e no APIU. A terceira ameaça é um fator dependente dos participantes, onde foi requisitado que eles fossem o mais precisos em sua medição.
Validade Externa: foram consideradas as ameaças: (a) estudantes como inspetores
ao invés de profissionais de usabilidade; (b) normalmente ambientes acadêmicos não simulam totalmente as condições existentes em ambientes industriais. Sobre a questão (a), segundo [6], mesmo estudantes que não possuem experiência em aplicações na indústria podem apresentar habilidades similares a inspetores menos experientes. Em relação à questão (b), o portal JEMS é uma aplicação real e de extenso uso.
Validade de Conclusão: É uma ameaça que está relacionada com o tamanho da
de vista estatístico, limitando as conclusões referentes ao estudo. Com base nisso os resultados somente geram indícios a respeito da tecnologia.
Validade de Constructo: Relacionados a essa ameaça estão os indicadores do estudo.
Os estudos mencionados por [4] e [11] utilizaram indicadores que se baseiam no tempo gasto e na quantidade de defeitos coletados. Neste estudo os indicadores levados em consideração foram: (a) os tempos gastos pelos participantes durante a execução de suas atividades (Ver Figuras 3, 4, 5, 6, 7, 8, 9); (b) e a aceitação da tecnologia tendo como base o modelo TAM (Figuras 10 e 11).
7. Conclusões e Trabalhos Futuros
Este artigo apresentou um Assistente de Apoio ao Processo de Inspeção de Usabilidade – APIU, e os estudos experimentais realizados que serviram como método para a evolução do Assistente. O primeiro estudo apontou resultados negativos em relação à viabilidade do assistente tendo como parâmetro o tempo gasto nas fases de detecção de defeitos, coleção e discriminação, foram realizadas análises quantitativas e qualitativas, e o principal ponto a ser melhorado foi a interação entre técnica de inspeção e APIU. As análises apontaram as melhorias a serem desenvolvidas no Assistente.
O segundo estudo seguiu o mesmo modelo do primeiro e os resultados apontaram para a evolução do Assistente, gerando indícios de que o APIU é uma nova tecnologia a auxiliar o processo de inspeção de usabilidade.
O APIU está seguindo sua evolução através de estudos experimentais, onde as análises indicam os pontos positivos, os pontos negativos e as melhorias que devem ser desenvolvidas na tecnologia. Com base na experimentação ele está sendo desenvolvido de forma sólida, objetivando a transferência da tecnologia da academia para a indústria. De acordo com [20], a experimentação pode apoiar o desenvolvimento, evolução e melhoria dos processos e tecnologias de software.
Como trabalhos futuros, os próximos passos são desenvolver as melhorias sugeridas no segundo estudo experimental e executar novos estudos. Para continuar a avaliar o APIU será realizado um estudo de observação, com uma nova versão do assistente. Este estudo coletará dados da utilização do APIU pelos participantes da inspeção.
Agradecimentos
Os autores agradecem a todos que participaram dos estudos, ao CNPq, à Trópico Telecomunicações S.A. e ao Instituto de Nokia de Tecnologia pelo apoio financeiro.
Referências Bibliográficas
[1] Ardito, C., Lanzilotti, R., Buono, P., Piccinno, A., (2006). “A tool to support usability inspection”, Proceedings of the Working Conference on Advanced visual interfaces, pp.278-281. May 23-26, 2006, Venezia, Italy.
[2] Blackmon, M. H., Polson, P. G., Kitajima, M., Lewis, C., (2002) “Cognitive walkthrough for the web”. In: Proceedings of the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves, v. 5 (1), pp. 463 – 470. Minneapolis, Minnesota, USA.
[3] Conte, T., (2009a) “Técnica de Inspeção de Usabilidade Baseada em Perspectivas de Projeto Web”. Rio de Janeiro: UFRJ/COPPE 194 p. Tese (Doutorado) – UFRJ/ COPPE/ Programa de Engenharia de Sistemas e Computação, 2009.
[4] Conte, T., Massolar, J., Mendes, E., Travassos, G., (2007), “Web Usability Inspection Technique Based on Design Perspectives”, Anais do Simpósio Brasileiro de Engenharia de Software (SBES 2007), v. 1, pp. 394-410, João Pessoa, Brasil. Outubro.
[5] Conte, T., Cabral, R., Travassos, G. H. (2009b) Aplicando Grounded Theory na Análise Qualitativa de um Estudo de Observação em Engenharia de Software: Um Relato de Experiência. In: V Workshop "Um Olhar Sociotécnico sobre a Engenharia de Software" (WOSES 2009), 2009, Ouro Preto - MG. V WOSES - VIII Simpósio Brasileiro de Qualidade de Software. p. 26-37
[6] Kappel, G., Pröll, B., Reich, S., Retschitzegger, W., 2006. “An Introduction to Web Engineering”.In: Kappel, G., Pröll, B., Reich, S., Retschitzegger, W. (eds), Web Engineering: The Discipline of Systematic Development of Web Applications, John Wiley & Sons.
[7] Davis, F., (1989) “Perceived usefulness, perceived ease of use, and user acceptance of information technology.” MIS Quarterly, 1989, v. 13, n. 3, pp. 319-339.
Fagan, M. E., (1976), “Design and Code Inspection to Reduce Errors in Program Development", IBM Systems Journal, vol. 15, nº 3, pp. 182-211.
[8] Gomes, M., Santos, D. V., Chaves, L., Castro, A., Vaz, V. T., Soares, A., Travassos, G. H., Conte, T., (2009a). “WDP-RT: Uma técnica de leitura para inspeção de usabilidade de aplicações Web”. In: VI Experimental Software Engineering Latin American Workshop (ESELAW 2009), v. 1, pp. 124-133, São Carlos, São Paulo.
[9] Santos, F.; Gomes, M.; Oliveira, H.; Conte, T. (2010) “Evolving a Wizard to Support Inspection Process through Qualitative and Quantitative Analysis” SBES' 2010 – Simpósio Brasileiro de Engenharia de Software, no Congresso Brasileiro de Software: Teoria e Prática (CBSoft), Salvador-BA, Setembro, 2010.
[10] Gomes, M. ; Santos, F. ; Santos, D. V. ; Travassos, G. H. ; Conte, T. U. (2010). Evoluindo uma Técnica de Avaliação de Usabilidade através de Estudos In Vitro e In Vivo. In: IX Simpósio Brasileiro de Qualidade de Software, 2010, Belém, PA. Anais do IX Simpósio Brasileiro de Qualidade de Software. Porto Alegre: SBC, 2010. v. 1. p. 229-244..
[11] Halling, M., Biffl, S., and Grünbacher, P., (2002) “A Groupware-Supported Inspection Process for Active Inspection Management”. In: Euromicro Conference. 2002. Dortmund Germany: IEEE CS., pp. 251-258.
[12] Hitz, M., Leitner, G., Melcher, R., (2006). “Usability of Web Applications”.In: Kappel, G., Pröll, B., Reich, S., Retschitzegger, W. (eds), Web Engineering: The Discipline of Systematic Development of Web Applications, Chapter 11, John Wiley \& Sons, 2006.
[13] Itakura, F., Vergilio, S. R., (2002). “Towabe - uma ferramenta para avaliação de usabilidade em aplicações para Web”. SBES 2002, Gramado, RS, Brasil, Outubro.
[14] Kalinowski, M., Spinola, R.O., Travassos, G.H., (2004). “Infra-Estrutura Computacional para Apoio ao Processo de Inspeção de Software”, III Simpósio Brasileiro de Qualidade de Software, Brasília, Brasil, 2004.
[15] Laitenberger, O., Dreyer, H. M., (1998). “Evaluating the Usefulness and the Ease of Use of a Web-based Inspection Data Collection Tool”. IESE, 1998.
[16] Lanubile, F., Mallardo, T., Calefato, F., (2003). “Tool support for Geographically Dispersed Inspection Teams”, Software Process Improvement and Practice, 8: 217-231 (DOI: 10.1002/spip.184). [17] Strauss, A., Corbin, J., (1998). “Basics of Qualitative Research: Techniques and Procedures for
Developing Grounded Theory”. 2 ed. London, SAGE Publications, 1998.
[18] Shull, F., Carver, J., Travassos, G. H., “An empirical methodology for introducing software processes.” ACM SIGSOFT Software Engineering Notes, v. 26, n. 5, pp. 288-296, 2001.
[19] Nielsen, J., (1994). “Guerrilla HCI: using discount usability engineering to penetrate the intimidation barrier” (eds), Cost-justifying usability, Orlando, USA, Academic Press, Inc.
[20] Prates, R. O., Barbosa, S. D. J., (2003). “Avaliação de Interfaces de Usuário - Conceitos e Métodos”. In: Coello, J. M. A., Fabbri, S. C. P. F. (eds), Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação, Capítulo 6, Campinas, SBC.
[21] Travassos, G. H., (2008). "Experimentação em Engenharia de Software: produzindo evidências, desenvolvendo tecnologias e melhorando processos de software" (Apresentação Keynote). VII Simpósio Brasileiro de Qualidade de Software (SBQS 2008).
[22] Triacca L., Inversini A., Bolchini D., (2005). “Evaluating web usability with MiLE+”. In Proceedings of Seventh International Symposium on Web Site Evolution (WSE 2005) Budapest. pp. 22–29. [23] Sauer, C., Jeffery, D. R., Land, L., Yetton, P., (2000). “The Effectiveness of Software Development
Technical Reviews: A Behaviorally Motivated Program of Research.” IEEE Transactions on Software Engineering, v. 26, n. 1, pp. 1-14, 2000.
