ÍNDICE ANALÍTICO 1. INTRODUÇÃO OBJETIVOS DESENVOLVIMENTO (MATERIAIS E MÉTODOS) RESULTADOS PARCIAIS E DISCUSSÃO...

Transcrição

1 ÍNDICE ANALÍTICO 1. INTRODUÇÃO OBJETIVOS DESENVOLVIMENTO (MATERIAIS E MÉTODOS) Princípios Básicos de Usabilidade Design Participativo Técnicas, Critérios e Métodos de Avaliação de Usabilidade de IHC s Critérios Ergonômicos Avaliação Heurística Observação do Usuário Ciclo de Vida Estrela Análise do Usuário Projeto Especificação de Usabilidade Atributos de Usabilidade Exemplo de Tabela de Especificação de Usabilidade (TEU) Definição de Níveis na TEU Prototipação Rápida Avaliação Formativa Geração e Coleta de Dados RESULTADOS PARCIAIS E DISCUSSÃO Definição das Classes de Usuários Usuários Conhecedores Somente do Processo de Software Usuários Conhecedores do Processo de Software e da Modelagem P/p Especificações de Usabilidade para a P/pTool Tarefas Definidas para as Sessões de Avaliação da P/pTool Representação das Informações geradas pelo P/pSim CONCLUSÕES PARCIAIS REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS Rápida Descrição da P/pTool iii

2 7.2 Resumo apresentado no III Encontro de Atividades Científicas da UNOPAR Londrina - PR 7.3 Artigo apresentado na V Mostra de Trabalhos de Informática da UEM e II Fórum de Informática e Tecnologia de Maringá 7.4 Artigo aceito para apresentação e publicação nos anais - The 4th European Conference on Software Measurement and ICT Control FESMA/DASMA Alemanha iv

3 ÍNDICE DE FIGURAS FIGURA 1: CICLO DE VIDA ESTRELA [HIX93] FIGURA 2: ABORDAGEM ARTILHARIA PARA PROTOTIPAÇÃO RÁPIDA [HIX93] FIGURA 3: EXEMPLO DE REPRESENTAÇÃO GRÁFICA DE DADOS PARA O P/PSIM ÍNDICE DE TABELAS TABELA 1: EXEMPLO DE TABELA DE ESPECIFICAÇÃO DE USABILIDADE [HIX93] TABELA 2: TABELA DE ESPECIFICAÇÃO DE REQUISITOS DE USABILIDADE DA P/PTOOL.. 29 TABELA 3: TAREFAS BENCHMARK PARA AS SESSÕES DE AVALIAÇÃO DA P/PTOOL TABELA 4: EXEMPLO DE RELATÓRIO DE PRODUTOS PARA O P/PSIM v

4 1. INTRODUÇÃO A P/pTool é uma ferramenta que visa o apoio visual ao processo de desenvolvimento e gerenciamento de software permitindo a aquisição de processos e derivação de produtos de software. Como a ferramenta é baseada no modelo Produto/processo (P/p), e este por sua vez fundamentado na teoria geral dos sistemas, parte-se do princípio de que qualquer usuário leigo na modelagem P/p, mas conhecedor de conceitos básicos sobre processo de software, possa modelar seus processos. Desse modo, o usuário faz uso de um tutor inteligente, que o auxilia e guia na transformação de processos genéricos em processos normalizados, implementado através do módulo de assistência inteligente a derivação de processos (P/pDerive). Além da possibilidade de auxílio assistido na modelagem visual dos processos, a ferramenta ainda possibilita a simulação dos processos derivados atuando sobre os atributos de produtos e processos (módulo de simulação de processos - P/pSim). Dessa forma, desde o início da implementação da P/pTool, muito esforço tem sido demandado no intuito de tornar a ferramenta efetiva e fácil de utilizar. Sendo assim, um dos pontos importantes desde o início de seu desenvolvimento foi a implementação de uma interface gráfica capaz de atender a todas as necessidades dos usuários. Tal interface gráfica, que faz parte do módulo principal da ferramenta, requisitou muito esforço em seu desenvolvimento visto que houve a necessidade de implementar um framework gráfico para a manipulação de objetos. Atualmente a interface gráfica apresenta as funcionalidades pré-determinadas pelo projeto, mas, é necessário que uma avaliação baseada em aspectos mais técnicos da interface seja realizada para aumentar a usabilidade da ferramenta. Desse modo, foram feitos estudos sobre as técnicas de avaliação de interface, baseando-se em metodologias comumente empregadas, visando utilizá-las no desenvolvimento da ferramenta. Este relatório apresenta os estudos realizados sobre avaliação de interface e as técnicas, métodos e critérios utilizados para a avaliação da interface da P/pTool. 6

5 2. OBJETIVOS O objetivo principal da primeira etapa deste projeto é o estudo dos conceitos e da preparação das tarefas e dos recursos necessários para uma avaliação da usabilidade da interface da ferramenta de coleta e avaliação de métricas (P/pTool). Essa avaliação se faz necessária, pois a ferramenta vem sendo desenvolvida desde o início do projeto sem que tenha sido suficientemente avaliada em fases iniciais com relação à usabilidade. Para avaliar a usabilidade da P/pTool pretende-se empregar as técnicas, critérios e métodos disponíveis e comumente empregados para esta tarefa. Como o desenvolvimento da interação com o usuário é um processo evolutivo, é inevitável que pelo menos uma vez, em todo o ciclo de vida do software, a interface seja avaliada, visando melhorar a qualidade e desempenho das funcionalidades disponíveis. Além do estudo dos conceitos de avaliação de usabilidade para a interface da P/pTool, existem outros objetivos que também fazem parte desta primeira fase. Tais objetivos são: a definição do modo de representação das informações geradas pelo módulo de simulação de processos (P/pSim) [Oli00], e a continuação do desenvolvimento do P/pSim e da própria P/pTool. Desta forma, podemos sintetizar os objetivos da primeira parte deste projeto como: estudar as técnicas de avaliação de usabilidade de interfaces para avaliar a interface da P/pTool; preparar as tarefas e recursos necessários para a avaliação da usabilidade da P/pTool; definir o modo de representação das informações geradas pelo P/pSim; continuar a implementação do P/pSim; continuar a implementação da P/pTool; avaliar os resultados parciais obtidos. 7

6 3. DESENVOLVIMENTO (MATERIAIS E MÉTODOS) A usabilidade é definida pela norma ISO 9241 como a capacidade que apresenta um sistema de ser operado, de maneira eficaz, eficiente e agradável, em um determinado contexto de operação, para a realização das tarefas de seus usuários [ISO93]. A avaliação da usabilidade é um processo que se inicia ao mesmo tempo em que concebemos o ciclo de vida do software em desenvolvimento [Hix93]. Por esta razão, o desenvolvimento da interação com o usuário é um processo que precisa evoluir junto com o ciclo de vida do software. A definição dos recursos necessários à avaliação da usabilidade da P/pTool foi o primeiro objetivo deste projeto, pois acreditamos que retardar o início deste processo de avaliação pode acarretar resultados negativos com relação ao uso da ferramenta. Sendo assim, nas próximas seções serão apresentados alguns princípios básicos de usabilidade e de Design Participativo além das principais metodologias de auxílio de usabilidade de IHC (Interação Humano-Computador), tais como Critérios Ergonômicos, Avaliação Heurística, conceitos sobre o processo de desenvolvimento da interação com o usuário e conceitos sobre o processo de avaliação da usabilidade da interface, visando a satisfação do usuário e a busca por problemas de interação. 3.1 PRINCÍPIOS BÁSICOS DE USABILIDADE Para que possamos obter um produto final que proporcione uma boa performance do usuário devemos ter em mente alguns princípios básicos relativos à interface com o usuário [Nie94]. Tais princípios são descritos a seguir. O diálogo simples e natural é o primeiro destes princípios. A interface com o usuário deve ser tão simples quanto possível. O desenho gráfico da interface deve por si só mostrar as relações entre os elementos de diálogo. Apenas a informação relevante para uma determinada tarefa do usuário deve aparecer na tela correspondente [Nie94]. Falar a língua do usuário representa expressar claramente as expressões e os conceitos familiares à comunidade de usuários, não em termos orientados ao sistema. Por exemplo, um aplicativo financeiro não deve exigir que usuários especifiquem o tipo de moeda com códigos, mas sim com termos como "Dólares", "Reais", entre outros [Nie94]. 8

7 Minimizar a carga de memória do usuário é um princípio que visa evitar que o usuário force a memorização de informações ao passar de uma parte do diálogo para outra. É mais fácil para o usuário modificar informações fornecidas pelo computador do que gerar o resultado desejado partindo do zero. Quando os usuários devem proporcionar uma entrada com um formato especial, o sistema deve descrever o formato esperado e, se possível, proporcionar um exemplo válido como padrão [Nie94]. A consistência visa trabalhar para que coisas similares se comportem de maneira semelhante. A consistência baseada em um critério pode se diferenciar da consistência baseada em outro. A consistência é um dos mais significativos fatores que afetam a usabilidade. Os usuários esperam que certos aspectos de uma interface comportem-se de maneira padrão, e quando isto não acontece, o resultado pode ser muito confuso e decepcionante. A mesma informação deve ser apresentada no mesmo local em todas as telas e caixas de diálogo e deve ser formatada da mesma maneira para facilitar o seu reconhecimento [Nie94]. O sistema deve informar ao usuário continuamente sobre o que está sendo feito e como a entrada do usuário está sendo interpretada. O feedback não deve esperar até que um erro ocorra, mas deve prosseguir paralelamente à entrada de informação. O feedback do sistema não deve ser expresso em termos gerais e abstratos, mas deve reescrever a entrada do usuário e indicar o que está sendo feito com ela [Nie94]. As saídas claramente marcadas aumentam o controle do usuário sobre o sistema, proporcionando uma saída fácil e explícita de tantas situações quanto possível. Por exemplo, todas as caixas de diálogo devem ter um botão "Cancelar" ou outra forma de saída para trazer o usuário de volta ao estado anterior [Nie94]. Os atalhos devem ser invisíveis para um usuário novato e estarem disponíveis para o usuário experiente. Os atalhos típicos incluem abreviações de comandos, combinação de teclas que são mapeadas em comandos do sistema, clique duplo do mouse sobre um elemento para realizar sua ação mais comum e menus de botões [Nie94]. Situações de erro em um sistema são críticas do ponto de vista da usabilidade por duas razões. Primeira, elas representam por definição um ponto em que o usuário teve problemas e potencialmente será impedido de atingir seu objetivo original. Segunda, eles apresentam uma oportunidade de ensinar o usuário, pois ele estará motivado a prestar atenção na mensagem apresentada e o sistema tem geralmente o conhecimento do que causou o problema. Deve-se escrever as mensagens de erro em 9

8 linguagem clara e evitar o uso de códigos obscuros. Deve ser possível para o usuário entender a mensagem por si só sem ter que recorrer a manuais ou tabelas de código. No lugar de se pôr toda a informação relevante numa única mensagem, é possível criar mensagens mais curtas desde que o usuário tenha acesso a mais informações sobre a mensagem se assim desejar. Isto pode ser feito através de um botão do tipo "Mais Informações", que chamaria um outro diálogo, ou através de um ponteiro para o sistema de ajuda on-line [Nie94]. A prevenção de erros tenta identificar os pontos em que os erros são mais prováveis e o sistema pode, então, ser adaptado de forma a contornar estas situações. Erros com conseqüências muito graves podem diminuir em freqüência se a confirmação do usuário for explicitamente pedida pelo sistema antes de continuar o processamento de uma operação arriscada [Nie94]. A regra fundamental para a documentação é que a maioria dos usuários simplesmente não lê os manuais. A conseqüência direta desta regra é que quando os usuários recorrem aos manuais, eles estão provavelmente em algum tipo de emergência e precisam de ajuda imediata. Levando-se isso em conta, é essencial que o sistema de ajuda e o manual do usuário sejam orientados por tarefas, listem passos concretos e usem uma linguagem, clara e concisa [Nie94]. Todos estes conceitos apresentados devem estar perfeitamente sincronizados com as fases do Ciclo de Vida Estrela [Hix93], que é formado por etapas que auxiliam o desenvolvimento da interação do usuário. O Ciclo de Vida Estrela e suas respectivas etapas são apresentados na Seção 3.4. A seguir são destacadas as principais características do Design Participativo visto que este método de design vem sendo empregado para o projeto e desenvolvimento da interface da P/pTool. 3.2 DESIGN PARTICIPATIVO O Design Participativo tem ocupado cada vez mais um lugar significativo no campo de desenvolvimento de interfaces. Existem muitas e importantes contribuições nas áreas de pesquisa, prática, implementações e análise [Hel97]. Em termos gerais, Design Participativo é um estilo de desenvolvimento de interface onde o usuário final participa do desenvolvimento da mesma, ou seja, sempre 10

9 que o projetista ou designer consegue concluir uma parte do projeto da interface, consulta ao usuário, ou a uma junta de usuários para os ajustes. Existem três pontos importantes pelos quais os pesquisadores são motivados a utilizar o Design Participativo, são eles [Hel97]: Democracia: este primeiro ponto veio a conceituar o contexto do movimento para um local de trabalho democrático e desenvolvimento de um trabalho competente; Eficiência e Qualidade: este ponto surgiu das práticas norte-americanas. Designers com experiência são requisitados e usuários são envolvidos o mais cedo possível nos projetos. A qualidade e os resultados gerados são mais proveitosos, devido um melhor entendimento entre os designers e usuários; Concordância: este ponto ocorre na área de desenvolvimento organizacional. Neste nível o sistema se adapta mais facilmente a usuários finais (end-users), se estes usuários estiverem mais familiarizados com as atividades do mesmo. A seguir são destacadas as técnicas, métodos e critérios mais comumente empregados para avaliar a usabilidade de IHC s, tais como Avaliação Heurística e Critérios Ergonômicos. 3.3 TÉCNICAS, CRITÉRIOS E MÉTODOS DE AVALIAÇÃO DE USABILIDADE DE IHC S Jakob Nielsen aponta que uma abordagem bastante interessante e que pode apresentar bons resultados no auxílio à tarefa de se avaliar interfaces é a de se empregar abordagens tais como Avaliação Heurística ou Observação do Usuário, já embasadas pela comunidade científica [Nie94]. Tais abordagens podem ser aplicadas de formas diferentes para os diversos domínios de aplicação. Assim, um enfoque diferente para softwares educativos ou para softwares de automação bancária, por exemplo, pode ser empregado para se avaliar a usabilidade desses sistemas interativos. Testar-se as interfaces com usuários reais é um método fundamental de avaliação de usabilidade e, em alguns casos, insubstituível, uma vez que ele fornece informação direta sobre como os usuários estão usando seus computadores (através da execução de seus softwares) e quais são realmente os problemas exatos com relação à interface sendo testada [Nie94]. 11

10 Nielsen ainda aponta que para qualquer tipo de avaliação de usabilidade, os avaliadores devem focar a atenção basicamente em dois pontos cruciais: confiabilidade e validade. Confiabilidade é uma questão relacionada com o fato de obter-se ou não o mesmo resultado da avaliação quando o teste for repetido a posteriori. Já a validade está relacionada com o fato do resultado da avaliação refletir um problema real de usabilidade para o usuário [Nie94]. Para facilitar a obtenção de resultados neste trabalho, pretende-se empregar ensaios de interação basicamente utilizando-se as técnicas de Observação do Usuário e de Avaliação Heurística por serem métodos que apresentam resultados bastante satisfatórios com relação à obtenção de dados sobre a avaliação de interfaces Homem- Máquina. Na subseção são apresentados os Critérios Ergonômicos propostos por Scapin e Bastien [Sca97], como uma abordagem tanto para o projeto quanto para a avaliação de IHC s. Na subseção é apresentada a Avaliação Heurística que será aplicada a avaliação da interface da P/pTool. Já na subseção é apresentada a técnica de Observação do Usuário, muito utilizada durante as sessões de avaliação de IHC s e que também será empregada na avaliação da usabilidade da P/pTool CRITÉRIOS ERGONÔMICOS Como uma forma de fornecer diretrizes para que os designers das interfaces elaborem interfaces ergonomicamente confortáveis de serem acessadas, Scapin e Bastien definiram que o emprego de uma série de critérios pode trazer resultados satisfatórios, de modo a não haver constrangimento do usuário, dificuldades de utilização, erros de manuseio, problemas de feedback ou, até mesmo, desistência de utilização [Sca97]. Esses critérios são: Condução Guidance: refere-se aos mecanismos disponíveis para advertir, orientar, informar, instruir e guiar os usuários durante suas interações com o computador. Este critério é subdividido em: prompting, agrupamento e distinção de itens, feedback imediato e legibilidade; Sobrecarga de trabalho Workload: está relacionado a todos os elementos da interface que têm o papel de reduzir a carga perceptual ou cognitiva do usuário e também de melhorar a eficiência do diálogo com o usuário. Este critério é subdividido em: brevidade e densidade de informação; 12

11 Controle Explícito Explicit Control: refere-se tanto ao processamento do sistema através de ações explícitas do usuário quanto ao controle que os usuários têm no processamento dessas ações na interação com o sistema. Subdivide-se em: ação explícita do usuário e controle do usuário; Adaptabilidade Adaptability: a adaptabilidade de um sistema refere-se à sua capacidade de se comportar contextualmente e de acordo com as necessidades e preferências do usuário. Este critério é subdividido em: flexibilidade e experiência do usuário; Gerenciamento de Erros Error Management: Este critério refere-se aos mecanismos disponíveis para prevenir ou reduzir erros e recuperá-los (se possível) quando ocorrerem. É dividido em: proteção contra erros, qualidade das mensagens de erros e correção de erros; Consistência Consistency: refere-se à forma como as opções da interface (códigos, nomes, formatos, etc.) são mantidas em contextos similares e são diferentes quando aplicadas em contextos diferentes; Significado dos Códigos Significance of Codes: qualifica o relacionamento entre um termo e/ou um sinal e suas referências. Os códigos e nomes são significantes para o usuário quando existe uma forte relação semântica entre esses códigos e os itens ou ações a que eles se referem; Compatibilidade Compatibility: este critério refere-se ao relacionamento entre as características do usuário (memória, percepções, habilidades, expectativas, etc.) e as características da tarefa a ser realizada AVALIAÇÃO HEURÍSTICA Durante uma Avaliação Heurística, os avaliadores procuram por violações de princípios comuns de usabilidade. Basicamente, as avaliações heurísticas envolvem a identificação das heurísticas, o recolhimento das opiniões dos avaliadores sobre a usabilidade da interface, a definição de uma escala de violação dos problemas que foram identificados, e a procura por soluções [Mye98]. Nielsen também elaborou uma série de heurísticas para sistemas computacionais que podem muito bem serem aplicadas para diversos domínios de aplicação de softwares. Abaixo encontram-se algumas delas: 13

12 1. Visibilidade da interação; 2. Controle e liberdade do usuário; 3. Consistência; 4. Feedback; 5. Flexibilidade e eficiência de uso; 6. Prevenção a erros; 7. Correção de possíveis erros; 8. Help e documentação. A Avaliação Heurística envolve o estudo da interface e é uma técnica que deve ser preferencialmente realizada por um grupo pequeno de avaliadores (de 3 a 5) [Nie94]. Esse número foi determinado por estudos prévios que computaram o gasto de se obter mais avaliadores com o possível ganho em resultados. Chegou-se à conclusão de que um maior número de avaliadores torna-se pouco representativo com relação à quantidade de violações encontradas [Nie94]. Uma Avaliação Heurística pode ser uma forma de se considerar cada regra de usabilidade para se tentar impedir a veiculação de interfaces com falhas de usabilidade. Ainda existem, na literatura, outros métodos para se realizar uma avaliação, sendo que os que obtêm maior respaldo da comunidade científica são: cognitive walkthrough ou guidelines (listas de verificação) [Jef91] OBSERVAÇÃO DO USUÁRIO O método de Observação do Usuário interagindo com uma interface pode ser a forma mais representativa de se obter dados da usabilidade da interface e do quão confortável e capaz o usuário está para realizar sua interação [Nie94]. Por ser uma forma bastante eficiente para a coleta de dados sobre o quão satisfeito estaria o usuário interagindo com a interface, este método não pode ser desprezado. Entretanto, trata-se de uma metodologia relativamente cara, demorada e bastante complexa de ser realizada [Nie94]. Para que o usuário possa ser observado de uma forma tão próxima de uma interação cotidiana quanto possível, é necessária a realização de uma série de atividades que percorrem as quatro fases de um teste de usabilidade. Esses estágios são: preparação, introdução, execução e análise dos resultados [Hix93]. Todas essas tarefas exigem um planejamento de atividades com o objetivo de evitar constrangimentos ao 14

13 usuário e garantir sua plenitude psicológica. Por ser uma tarefa tão complexa, apesar de produzir bons resultados finais, pois a observação do usuário é uma tarefa demorada e cara, que exige um alto nível de maturidade do usuário e dos condutores da avaliação (avaliadores), normalmente não é possível de ser realizada para empresas com suporte financeiro pouco significativo. Nielsen aponta que uma observação da interação do usuário teve custo médio de US$ ,00 para diversas avaliações realizadas [Nie94]. A seguir será apresentado o modelo de Ciclo de Vida Estrela, pois seus conceitos enfatizam de forma clara e objetiva o emprego de metodologias que visam projetar e auxiliar a avaliação da usabilidade de IHC s. 3.4 CICLO DE VIDA ESTRELA O Ciclo de Vida Estrela, mostrado na Figura 1, suporta tanto o desenvolvimento top-down quanto o desenvolvimento bottom-up de interfaces. Este ciclo de vida minimiza o número de obstáculos entre as atividades de desenvolvimento, pois, por exemplo, não precisamos necessariamente ter que especificar os requisitos antes de trabalharmos no projeto. De fato, podemos iniciar com o projeto usando, por exemplo, uma ferramenta rápida de prototipação e, durante o processo, aprender muito sobre o que queremos nos requisitos. Todas estas considerações levam a diferentes tipos de ciclos de vida de desenvolvimento devido à sua forma. Os pontos do Ciclo de Vida Estrela não são ligados ordenadamente. Isto significa que o desenvolvedor pode teoricamente iniciar com qualquer atividade do desenvolvimento e mover-se para qualquer outra. As diversas atividades são altamente interconectadas, de qualquer forma, através da avaliação da usabilidade cada atividade é analisada antes de passar para a próxima [Hix93]. 15

14 Figura 1: Ciclo de Vida Estrela [Hix93]. As atividades do desenvolvimento da interação, Sistemas/Análise do Usuário, Especificações de Usabilidade, Projeto/Representação de Projeto, Prototipação Rápida e Avaliação da Usabilidade terão suas características apresentadas a seguir, ressaltando a última que será apresentada de forma mais abrangente, pois é a atividade de maior interesse neste projeto. A área de interesse está principalmente no domínio comportamental. O ciclo de desenvolvimento de software clássico engloba este ciclo. As principais fases do Ciclo de Vida Estrela são apresentadas a seguir ANÁLISE DO USUÁRIO Em todos os projetos de desenvolvimento, e especialmente em um novo domínio de problema, é necessário entrevistar e analisar potenciais usuários para determinar as informações que serão necessárias. Isso também vem de encontro com a idéia apresentada na seção 3.2 que se refere ao Design Participativo. Dessa forma, pode-se ter uma idéia mais concreta a respeito das características que o novo sistema deve apresentar. Um bom exemplo disso é a identificação de uma classe de gerentes de projeto que usariam uma ferramenta para gerenciar seus projetos. Sendo assim, poderíamos usar termos técnicos relacionados a área de produção, o que não seria correto se a classe de usuários fosse, por exemplo, acadêmicos do primeiro ano de faculdades de computação e informática. 16

15 A análise do usuário é fundamental para o desenvolvimento da interação, tornando-se um ponto crucial no sucesso da aplicação. É importante destacar que a atividade da análise do usuário não é uma tarefa simples, visto que mesmo as entrevistas, as pesquisas e os questionários não são suficientes para determinar as informações necessárias. Os usuários muitas vezes podem articular as necessidades reais do sistema, fazendo com que a equipe encarregada da análise do usuário tenha a necessidade de entender como os usuários usarão tal sistema PROJETO Terminada a fase de análise do usuário, a próxima atividade é o projeto. É possível dividir a etapa de projeto em duas: projeto conceitual e projeto detalhado. O projeto conceitual está em um alto nível e faz a síntese de objetos e operações. O projeto detalhado trabalha com atividades como, por exemplo, determinar as mensagens do sistema, rótulos, e menus de escolha, assim como a aparência de objetos na tela, navegação entre telas, entre outros ESPECIFICAÇÃO DE USABILIDADE As especificações de usabilidade são metas quantitativas de usabilidade usadas como guia para se saber quando a interface é boa o suficiente [Hix93]. Estas especificações devem ser estabelecidas o mais cedo possível no processo de desenvolvimento da interação. A especificação de usabilidade trabalha com o conceito de atributos de usabilidade definidos operacionalmente e que são critérios de sucesso para a interface com o usuário [Hix93]. Estes atributos são essenciais já que fornecem parâmetros para se medir a usabilidade de uma versão da interface. A especificação de usabilidade usa também o conceito de Tabela de Especificação de Usabilidade (TEU), que será apresentada na Seção ATRIBUTOS DE USABILIDADE Os atributos de usabilidade são características gerais de usabilidade a serem medidas para uma interface [Hix93]. Alguns atributos são comumente usados como, por exemplo [Hix93]: 17

16 Performance inicial refere-se ao desempenho do usuário durante a primeira vez de uso do sistema; Performance de longo prazo refere-se ao desempenho do usuário em uso mais regular do sistema durante um longo período; Aprendizagem e retenção rapidez e a facilidade com que o usuário aprende a lidar com o sistema e quanto conseguirá reter na memória o que aprendeu em um período de tempo; Uso de características (features) avançadas atributo que ajuda a determinar a usabilidade de funções complexas da interface; Primeira impressão opinião inicial do usuário; Satisfação do usuário em longo prazo opinião do usuário após utilizar o sistema por um período maior de tempo. Ao escolhermos os atributos devemos pensar quem são os usuários do sistema (atividade de análise do usuário), e que tarefas representativas e realistas são usadas por todos os usuários. Se forem identificadas diferentes características de usuários, pode ser interessante a utilização de tarefas diferentes para cada categoria de usuário. Para uma atividade complexa, pode ser também interessante estabelecer diferentes atributos, por exemplo, aprendizado e desempenho em longo prazo objetivando estabelecer qual nível de performance será aceitável, baseando-se nas tarefas do usuário e classes de usuário EXEMPLO DE TABELA DE ESPECIFICAÇÃO DE USABILIDADE (TEU) A Tabela de Especificação de Usabilidade está focada no gerenciamento dos recursos de desenvolvimento do software. Sem especificações mensuráveis, é impossível determinar metas de usabilidade e dizer se o produto final alcança essas metas. 18

17 Tabela 1: Exemplo de Tabela de Especificação de Usabilidade [Hix93]. Atributo de usabilidade Performance inicial Performance inicial Instrumento de Medida Adicionar anotação Remover anotação Valor a ser medido Tempo para adicionar uma anotação corretamente Número de erros na primeira tentativa Nível corrente 15 segundos Pior nível aceitável 30 segundos Nível estabelecido Melhor nível possível 20 segundos 10 segundos 0 erros 4 erros 3 erros 0 erros Considerando que a Tabela 1 exemplifica uma agenda de compromissos, podemos notar que o atributo de usabilidade definifo foi a Performance Inicial. Este atributo visa medir a performance do usuário durante a primeira vez em que este realiza uma tarefa diante da interface. Desse modo, podemos ter uma idéia acerca de quão fácil ou difícil se torna trabalhar com a interface diante às primeiras tentativas. Os valores a serem medidos utilziados no exemplo da Tabela 1 são os mais comumente empregados em avaliações de usabilidade de IHC s. Já os valores para os níveis no exemplo da Tabela 1 foram definidos tomando-se por base uma abstração para cada instrumento de medida, isto é, tentando-se definir valores aproximados para a execução de cada tarefa. O instrumento de medida é uma descrição do método para prover valores para um atributo de usabilidade em particular. Um instrumento de medida para uma especificação de usabilidade é sempre quantitativo (isto é, pode ser numericamente mensurável) e pode ser objetivo ou subjetivo. O valor a ser medido é a métrica para a qual os valores dos dados são coletados durante a sessão de avaliação com um participante. As medidas mais comuns para valores objetivos são [Hix93]: tempo em que se completou uma tarefa e número de erros DEFINIÇÃO DE NÍVEIS NA TEU Visto que os atributos, os instrumentos e os valores a serem medidos não são de extrema dificuldade para serem definidos, devemos saber quais valores podem ser usados para estabelecer uma performance aceitável do usuário e, então, refletir o nível de usabilidade da interface. Para isso, devemos determinar qual nível de comportamento do usuário é suportado pelo sistema. Como já mencionado, um dos instrumentos de medida mais comumente empregado é o tempo para realizar uma tarefa. Quando definimos pela primeira vez 19

18 todos os níveis na TEU, podemos encontrar dificuldade para estabelecer um valor para tarefas sobre um período de tempo. Sob diferentes condições, diferentes intervalos de tempo podem ser razoáveis. Contudo, se uma tarefa será freqüentemente realizada, um longo período de tempo para a realização de tal tarefa não é aceitável, por exemplo, se a tarefa de configuração de um banco de dados tem que ser realizada por um administrador de banco de dados em 500 máquinas em duas semanas, uma hora não é um período de tempo aceitável para a realização da tarefa [Hix93]. Este tipo de dilema sobre a definição dos valores para os níveis da TEU é solucionado definindo-se classes de usuários para um atributo de usabilidade e para a definição da tarefa no instrumento de medida específico o suficiente para limitar os casos em que uma pequena escala de valores de tempo é razoável para cada caso. Em suma, diferentes tarefas e diferentes usuários podem indicar a necessidade de diferentes especificações de usabilidade, ou ao menos diferentes tarefas e diferentes níveis de performance de tarefa. O nível atual é o nível corrente do valor a ser medido para o atributo de usabilidade na presente versão do sistema. Um nível atual pode ser estabelecido enquanto o sistema é automatizado ou está no papel. Medir o nível atual ajuda a garantir que os outros níveis são, de fato, mensuráveis. Medições para o nível atual podem vir de um sistema manual, um sistema existente automatizado, ou mesmo de desenvolvedores com um protótipo do novo sistema [Hix93]. O pior nível aceitável é o pior nível de performance do usuário para cada atributo de usabilidade, não o pior que pode acontecer. Esse limite de falha para usabilidade é a fronteira entre um sistema aceitável e não aceitável para cada atributo específico para a versão corrente da interface. Conforme a tabela de especificação é definida, os piores níveis para todos os atributos na tabela inteira devem ser simultaneamente alcançados. Se o valor observado para um atributo não encontrar um nível pior, então o sistema como um todo é formalmente inaceitável, ao menos em sua versão atual. Sendo assim, níveis mutuamente exclusivos ou contraditórios garantem falha, por isso é preciso ser cuidadoso ao definir atributos e seus níveis. Existem regras simples e rápidas para determinar os piores níveis aceitáveis, mas as seguintes heurísticas podem ajudar: o pior nível aceitável deve, quando possível, estar perto do valor para o nível atual do presente sistema e pode ser maior se o nível atual não é satisfatório. Idealmente, um novo sistema automatizado não deve resultar em 20

19 uma performance mais baixa do usuário do que o sistema atual, mesmo para a performance inicial. O nível estabelecido é o valor estabelecido que indica sucesso de usabilidade para a interface, isto é, o nível que desejamos. É a meta de usabilidade nominal para cada atributo específico. Atributos que ainda não alcançaram seus níveis planejados servem como ponto de foco para melhoramentos através do desenvolvedor. Como o pior nível, os níveis estabelecidos para todos os atributos na tabela inteira devem ser simultaneamente atingidos. Assim como o pior nível, um valor para o nível planejado é determinado heuristicamente. Ele é normalmente definido para ser maior que o nível corrente para o sistema, objetivando melhorar a performance do usuário. Se o nível planejado for alcançado durante testes com usuários, podemos estar confiantes com relação à usabilidade da interface. O melhor nível possível é o limite superior realístico, é considerado o nível de inspiração de um atributo de usabilidade. Este nível mostra o potencial de um atributo e serve como alvo para futuras versões do sistema. Como outros níveis, o melhor nível possível é o melhor nível de performance que podemos esperar sob condições ideais, o que nos leva a seguinte heurística: considerar onde é possível chegar com os melhores usuários, mais bem treinados, nas melhores condições, com o melhor projeto e o melhor uso da tecnologia disponível PROTOTIPAÇÃO RÁPIDA As técnicas de prototipação, especialmente a prototipação rápida, e o projeto iterativo permitem ao processo de desenvolvimento de software compartilhar a essência do esquema de desenvolvimento: refinamento do produto baseado em feedback dos usuários [Hix93]. Com a prototipação rápida, o processo de construção de protótipos é acelerado e, dessa forma, o tempo do início do protótipo para avaliar a interação do usuário diminui suficientemente sobrando tempo para mudanças substanciais, se necessárias, ao produto. O método artilharia [Hix93], como mostra a Figura 2, é muito usado por desenvolvedores da interface com o usuário durante a prototipação rápida. A prototipação rápida tem sido associada a ferramentas automatizadas de software, mas é importante enfatizarmos que a prototipação é uma técnica e não apenas 21

20 uma ferramenta. Tal técnica se inicia, de preferência, com detalhes específicos de um projeto de interação, que estrutura e refina os detalhes de um sistema. Existem várias maneiras para classificar tipos de técnicas de prototipação. A primeira forma de classificação envolve algumas dimensões de um protótipo, como: representação, escopo, executabilidade e maturação. A representação define como os projetos de interação são representados no protótipo. O escopo representa a inclusão do sistema inteiro ou somente da interface. A executabilidade mostra se o protótipo pode ser executado a qualquer tempo. A maturação nos mostra como um protótipo progride até chegar a um produto. Figura 2: Abordagem artilharia para prototipação rápida [Hix93]. Um protótipo horizontal oferece menor profundidade em sua cobertura funcional, mas é muito amplo com relação às características que incorpora. Isto resulta em menos detalhes, porém com mais características. A avaliação de usabilidade com este tipo de protótipo é geralmente menos realística, mas cobre mais funcionalidades do sistema final. Por outro lado, em um protótipo vertical o número de características é reduzido, gerando um protótipo que cobre uma pequena escala de funções possíveis. Estas funções que são incluídas são implementadas em detalhe. A vantagem da prototipação vertical é que a avaliação de usabilidade pode ser quase realística, mas apenas para poucas funções. A prototipação horizontal geralmente se encaixa melhor para protótipos iniciais, pois é mais útil para conceitos gerais ajudando a avaliar a funcionalidade proposta. A 22

21 prototipação vertical se encaixa bem em protótipos mais maduros, quando algumas funções selecionadas podem ser desenvolvidas em mais detalhes para a avaliação de usabilidade. Outra maneira de se classificar os protótipos é baseando-se no seu conteúdo. Um protótipo global é um protótipo onde o usuário pode ter uma noção do produto final. Ele constitui, de preferência, uma instância completa da versão atual de um projeto de interação. Ele é similar à classificação horizontal, mas um protótipo global pode também ter uma boa profundidade (similar ao vertical). Um protótipo local é um protótipo de um detalhe específico da interação, sendo importante o bastante para potencialmente afetar a usabilidade do sistema como um todo. Um protótipo local é usado para avaliar alternativas de projeto para detalhes de interação particulares isolados. O protótipo local normalmente não está conectado ao resto do protótipo, e possui uma amplitude curta de vida. Os protótipos globais são mais úteis durante todo o ciclo de prototipação, desde o início até o fim. Protótipos locais tendem a ser mais úteis somente por um tempo curto, quando detalhes específicos de uma ou duas versões de projetos particulares estão sendo desenvolvidos. Acreditamos que a P/pTool melhor se enquadra na prototipação horizontal, uma vez que este tipo de protótipo cobre uma gama maior de características e funcionalidades da ferramenta ajudando avaliar a usabilidade do protótipo inicial sem que todas as funcionalidades estejam implementadas em detalhe, como é o caso da P/pTool AVALIAÇÃO FORMATIVA A avaliação de usabilidade de um sistema interativo tem como objetivos gerais: validar a eficácia da interação humano-computador frente a efetiva realização das tarefas por parte dos usuários; verificar a eficiência desta interação, frente os recursos empregados (tempo, quantidade de incidentes, passos desnecessários, busca); e obter indícios da satisfação ou insatisfação que ela possa trazer ao usuário [Hix93]. A usabilidade de um sistema está sempre associada às características de determinados tipos de usuários, tarefas, equipamentos e ambientes físicos e organizacionais. Assim, um problema de usabilidade pode se fazer sentir fortemente em determinados contextos de operação a ser menor ou mesmo imperceptível, em outros. 23

22 A avaliação da usabilidade permite obter resultados como [Hix93]: constatar, observar e registrar, problemas efetivos de usabilidade durante a interação; calcular métricas objetivas para eficácia, eficiência e produtividade do usuário na interação com o sistema; diagnosticar as características do projeto que provavelmente atrapalhem a interação por estarem em desconformidade com padrões implícitos e explícitos de usabilidade; prever dificuldades de aprendizado na operação do sistema; prever os tempos de execução de tarefas informatizadas; conhecer a opinião do usuário em relação ao sistema; sugerir as ações de re-projeto mais evidentes frente os problemas de interação efetivos ou diagnosticados. No Ciclo de Vida Estrela, a avaliação da usabilidade é uma etapa interligada a todas as etapas restantes devido à sua relativa importância dentro do ciclo. Além disso, baseia-se na metodologia de avaliação formativa de projeto e interface. A Avaliação Formativa é a avaliação do projeto no começo e durante o processo de desenvolvimento da interface, visando aperfeiçoar um produto. Este tipo de avaliação não se trata de experimentação controlada, com rigor estatístico, de teste de fatores humanos já que se deseja resultados mais rápidos. Além disso, a avaliação formativa não busca significância estatística, mas sim satisfazer as necessidades do usuário para se conseguir um alto grau de usabilidade. A avaliação formativa começa o mais cedo possível no ciclo de desenvolvimento, para que se possa descobrir problemas de usabilidade enquanto ainda resta bastante tempo para que modificações sejam feitas no projeto. A avaliação formativa parte do princípio de que os usuários avaliarão a interface mais cedo ou mais tarde. Deste modo, devemos então avaliar a interface o mais cedo possível em um ambiente controlado e, quando possível, corrigir os defeitos. A Avaliação Formativa é o alvo de estudo para a realização da avaliação da usabilidade da P/pTool durante as próximas atividades da segunda etapa deste projeto. 24

23 3.4.6 GERAÇÃO E COLETA DE DADOS Tão logo seja iniciada uma sessão de avaliação, várias situações interessantes ocorrem entre o participante e a interface que está sendo avaliada. Os dados de interesse do avaliador podem estar chegando de forma incontrolável. Isto é perfeitamente contornável se soubermos o tipo de dados a coletar. Existem tipos de dados que são mais úteis e ajudam a medir e alcançar as metas de usabilidade mais facilmente. Métodos para geração e coleta de dados qualitativos e quantitativos são apresentados a seguir. Técnicas quantitativas são usadas para medir os níveis de usabilidade diretamente observados, com o objetivo de compará-los com o conjunto de níveis na especificação de usabilidade. Existem dois tipos de técnicas de geração de dados quantitativos mais usados na avaliação formativa: tarefas benchmark e questionários de preferências do usuário. Durante a avaliação cada participante realiza as tarefas benchmark prescritas e o avaliador anota dados numéricos dependendo do que está sendo medido. Por exemplo, o avaliador pode medir o tempo que o participante leva para realizar uma tarefa ou contar o número de erros que um participante comete durante uma tarefa em um período de tempo. O questionário de preferências do usuário não possui um custo alto de ser produzido [Hix93], mas é de extrema dificuldade de ser elaborado, uma vez que este deve conter dados válidos e confiáveis. Os questionários são a técnica mais efetiva para produção e coleta de dados quantitativos com relação à opinião subjetiva do usuário quanto a interface. Os dados qualitativos são algumas vezes enganosos, mas muito importantes em avaliações formativas. Os tipos de técnicas mais eficientes para coleta de dados qualitativos são: protocolo verbal concorrente, protocolo verbal retrospectivo, anotação de incidentes críticos e entrevistas estruturadas. O protocolo verbal é também chamado de pensamento em voz alta ou thinkaloud. Esta abordagem é muito efetiva na determinação dos problemas que os participantes estão tendo e o que pode ser feito para solucionar tais problemas. No protocolo verbal concorrente o participante é solicitado a verbalizar tudo que diz respeito à sua impressão sobre o uso de uma interface enquanto a utiliza como, por exemplo, o que está pensando, o que esperava acontecer, dificuldades, entre outros. 25

24 Na técnica de protocolo retrospectivo o participante trabalha sem muita interrupção pelo avaliador. Imediatamente após a sessão, o avaliador e o participante revêem a gravação e procuram analisar o que aconteceu. A avaliação retrospectiva permite a descoberta direta do que o participante queria realmente fazer ou pensava, evitando suposições, que podem ser incorretas, na análise dos dados. Um exemplo de incidente negativo é quando um participante tenta um número excessivo de vezes a execução de uma operação. Isto pode significar que o desenho relacionado com essa operação deve ser melhorado. Um exemplo de incidente positivo é quando o participante demonstra satisfação quando descobre a metáfora relacionada com a manipulação de um objeto gráfico. Isto pode significar que a metáfora pode ser utilizada em outras situações. A entrevista estruturada é realizada através de uma série planejada de perguntas, tipicamente após a sessão de avaliação para coleta de dados qualitativos. Exemplos de perguntas utilizadas na entrevista estruturada: O que você mais gostou na interface? ; O que você menos gostou? ; O que você modificaria? ; Quais as três informações mais importantes que um usuário precisa para começar a usar o sistema?. As respostas podem ser anotadas pelo avaliador e/ou pelo participante. É interessante a participação de um profissional na elaboração das questões de uma entrevista, para que estas não possuam erros ortográficos ou evitem estarem mal elaboradas [Hix93]. 26

25 4. RESULTADOS PARCIAIS E DISCUSSÃO A construção da P/pTool é um projeto que vem sendo desenvolvido sempre focando a efetiva representação das funcionalidades de acordo com o objetivo desta ferramenta. Desde o primeiro protótipo construído para a P/pTool, utilizando o ambiente de desenvolvimento Delphi [Bor98], não houve a preocupação de avaliar a usabilidade da ferramenta, uma vez que os prazos para a implementação desta foram sempre restritos e vários foram os objetivos cumpridos para que a ferramenta pudesse implementar algumas de suas funcionalidades. Dessa forma, pudemos perceber que a ferramenta já se encontra em um estado bastante avançado no que diz respeito a representação e execução de suas principais funcionalidades. Portanto, constatamos que a ferramenta precisava passar pela etapa de avaliação de usabilidade de sua interface evitando, dessa forma, que problemas relativos à usabilidade possam vir à tona durante os próximos estágios de implementação. Como resultados principais desta primeira etapa deste projeto podemos citar: 1. a definição das classes de usuários para as sessões de avaliação de usabilidade; 2. a definição dos requisitos de usabilidade para a P/pTool; 3. a preparação da lista de tarefas que cada participante deverá realizar durante as sessões de avaliação; 4. uma rápida descrição da P/pTool que será introduzida a cada participante antes da realização das tarefas definidas para as sessões; e 5. algumas formas de representação dos dados coletados durante a simulação de processos da P/pTool. O documento contendo a rápida descrição da P/pTool encontra-se em anexo na Seção 7.1. As seções seguintes descrevem os vários passos e recursos que pretendemos empregar na avaliação da usabilidade da P/pTool. A Seção 4.4 apresenta as formas de representação das informações geradas pelo P/pSim, um dos objetivos da primeira etapa deste projeto. 27

26 4.1 DEFINIÇÃO DAS CLASSES DE USUÁRIOS Como já mencionado em seções anteriores, a definição de classes de usuários é de fundamental importância para o progresso da avaliação da usabilidade devido, principalmente, a forma de coleta e interpretação das informações dependendo da classe do usuário. Dessa forma, foram definidas duas classes de usuários que auxiliarão na avaliação da usabilidade da P/pTool. Tais classes são apresentadas a seguir USUÁRIOS CONHECEDORES SOMENTE DO PROCESSO DE SOFTWARE Essa classe se caracteriza por possuir usuários que têm conhecimentos básicos com relação ao processo de software. A P/pTool não representa obrigatoriamente somente o processo de software, mas pode representar qualquer tipo de processo real desde que este seja normalizado de acordo com a modelagem P/p. Sendo assim, estamos enfatizando o processo de software em sua representação horizontal, ou seja, mostrando as várias etapas do ciclo de vida. O usuário dessa classe deve ser capaz de passar por todas as fases do ciclo de vida clássico representando-as através da P/pTool. O conhecimento da modelagem P/p não é obrigatório, pois a P/pTool possui um tutor inteligente (P/pDerive) que auxilia o usuário a transformar um processo real em um processo normalizado de acordo com o modelo P/p USUÁRIOS CONHECEDORES DO PROCESSO DE SOFTWARE E DA MODELAGEM P/P Os usuários dessa classe se caracterizam por terem habilidade na representação de processos seguindo os padrões estabelecidos pela modelagem P/p. Isto torna o procedimento mais rápido e preciso, evitando dessa forma perder tempo fazendo uso do P/pDerive para a representação e especificação dos processos. Esta classe de usuários é bastante restrita, sendo que são poucos os conhecedores do modelo P/p, uma vez que este é muito recente. 28

27 4.2 ESPECIFICAÇÕES DE USABILIDADE PARA A P/PTOOL Esta etapa demandou bastante esforço para que o conjunto de conceitos que medem a usabilidade, tais como atributo e instrumento de medida, pudessem ser definidos de forma possível de ser avaliada através de testes de usabilidade. Como principal resultado desta etapa de especificação de usabilidade temos a Tabela 2 onde são apresentados os requisitos de usabilidade definidos para a P/pTool, incluindo o instrumento de medida, valor a ser medido e os vários níveis para cada requisito, que serão usados na avaliação da usabilidade da P/pTool. Tabela 2: Tabela de Especificação de Requisitos de Usabilidade da P/pTool. Atributo de usabilidade Performance inicial Performance inicial Performance Inicial Performance Inicial Performance Inicial Performance Inicial Performance Inicial Performance Inicial Performance Inicial Performance Inicial Instrumento de medida Representar um processo no painel Representar um processo no painel Configurar os atributos de um elemento Configurar os atributos de um elemento Adicionar um atributo a um elemento Remover um atributo de um elemento Excluir um processo Adicionar um atributo ao painel Adicionar um processo virtual ao painel Cadastrar um responsável Valor a ser medido Tempo para adicionar um processo corretamente Número de ações usadas para realizar a tarefa Tempo para a configuração Número de erros ao configurar Tempo para a adição Tempo para a remoção Tempo para a remoção Tempo para a adição Tempo para a adição Tempo para o cadastro Nível corrente 15 segundos Pior nível aceitável Nível estabelecido Melhor nível possível 20 segundos 10 segundos 5 segundos 4 ações 6 ações 3 ações 2 ações 180 segundos 240 segundos 120 segundos 90 segundos 1 erro 3 erros 1 erro 0 erro 10 segundos 20 segundos 15 segundos 10 segundos 5 segundos 10 segundos 5 segundos 5 segundos 10 segundos 15 segundos 15 segundos 180 segundos 20 segundos 10 segundos 5 segundos 20 segundos 10 segundos 5 segundos 20 segundos 10 segundos 5 segundos 220 segundos 150 segundos 120 segundos O único atributo de usabilidade definido para a Tabela 2 foi a Performance Inicial, uma vez que estamos querendo primeiramente observar como os usuários se comportarão diante da interface da P/pTool durante o primeiro contato e, além disso, nem todas as funcionalidades propostas para a ferramenta estão disponíveis, já que 29