Anbefalinger

O teste de usabilidade usa-se como método de verificação da facilidade de uso de um sistema e sua interface, tendo como target os usuários finais. Durante esta verificação não só erros de interface poderão surgir, mas também erros de sistema.

Tipicamente usuários representando os principais grupos de perfis, são incentivados a usar o sistema, sendo a sua interacção com o este gravada e anotada. Com estes poderá estar o avaliador/facilitador, que deverá guiar o usuário pelo teste e incentivar à verbalização dos seus problemas e desconfortos.

A participação de pelo menos cinco usuários representando os principais grupos de perfis é recomendada. Segundo Nielsen e Laundauer (1993), este número de usuários consegue encontrar 85% dos erros de usabilidade, o que se traduz na melhor relação Custo-benefício. Possivelmente se com este mesmo grupo de usuário efectuarmos outro teste, acreditamos que se poderá atingir os 100% de erros encontrados.

A localização do teste depende sempre do rigor que queiramos que este tenha. Poderá ir do mais simples, como uma sala de reuniões, até ao mais complexo, um laboratório de usabilidade, onde é posto à disposição do avaliador/facilitador, ferramentas de hardware e

software com vista a captar com mais rigor comportamentos e frustrações do usuário.

O tempo de duração de um teste deverá ser moderado. Por um lado queremos que este seja rigoroso, mas por outro não queremos cansar o usuário. Recomenda-se que este tenha a duração de uma hora, uma hora e meia no máximo.

Após os testes, todos os dados recolhidos são analisados, agrupados conforme a gravidade e é gerado um relatório contendo as correcções/recomendações para a equipa de projecto. O avaliador/facilitador deverá estar sempre disponível, para com a equipa de projecto encontrar soluções para os problemas encontrados.

O custo de um teste de usabilidade pode ser baixo ou alto, tudo depende do rigor que queiramos adicionar ao processo. Contudo será sempre baixo se comparado ao custo da alteração já numa fase de implementação do projecto.

Na Engenharia de Software, toda a investigação feita resume-se a para além de conhecer os métodos e seus modelos, responder a três perguntas:

Ignorar o cliente e/ou usuário final, é um dos problemas mais críticos que a utilização de uma metodologia pode apresentar. A falta de envolvimento de ambos durante todo o desenvolvimento está a condenar o projecto ao fracasso.

A falta de suporte executivo da organização, tal como a pouca agilidade da equipa para responder às mudanças, influenciam de forma negativa no projecto. Ambos requerem uma boa gestão a nível da equipa de projecto e ambiente externo ao projecto.

Outra causa para o fracasso prende-se com a incapacidade para controlar e mediar conflitos entre vários intervenientes, tais como, a equipa, o cliente, o usuário entre outros. Tais conflitos poderão relacionadas com:

 Objectivos contrários. Não existe uma visão comum entre o que o cliente deseja e o que a equipa de projecto está a desenvolver;

 Falha de comunicação. Existe pouca documentação do produto em construção, originando mal-entendidos;

 Expectativas irrealistas. Conforme os recursos e âmbito de projecto, o cliente pode não estar ciente e compreender os prazos de projecto.

A falta de recursos humanos, de infra-estrutura ou financeiros, assim como estimativas pouco reais de custos e de cronograma, também são apontados como factores que provocam o fracasso de um projecto.

 O que diferencia um método tradicional de um método ágil de desenvolvimento? Nos métodos tradicionais um projecto é encarado como um todo e só faz sentido falar de sucesso quando a totalidade deste é entregue ao cliente. Nos métodos ágeis um conjunto mínimo de funcionalidades já atribui valor para o cliente, o que faz com que mesmo que o projecto seja descontinuado, já houve retorno para o cliente. É verdade que o modelo de prototipagem evolucionária, sendo um método tradicional, já permite a entrega de protótipos durante a fase de desenvolvimento, podendo parecer que entramos numa contradição, mas não. No método tradicional o desenvolvimento baseia-se num crescendo das funcionalidades do produto até à sua entrega, enquanto na metodologia ágil, uma funcionalidade é individualizada, sendo esta entregue ao cliente, podendo este obter um retorno prévio da funcionalidade. Numa metodologia ágil o sucesso é algo progressivo, enquanto na metodologia tradicional este acontece só no final.

Nos métodos ágeis o custo de projecto está associado em 100% ao trabalho realizado, ao contrário dos métodos tradicionais que está associado em 100% aos requisitos especificados

e aprovados pelo cliente. Tal é deveras importante pois o cliente não tem nas metodologias ágeis uma visão geral sobre o custo do projecto, ao contrário da metodologia tradicional. Tais diferenças ajudam na resposta à segunda pergunta.

 Quando devo escolher um método, em detrimento do outro?

Se o âmbito do projecto está bem fechado, os requisitos deste bem delineados e aprovados pelo cliente, não existindo para este sucesso no projecto a não ser que o produto esteja entregue a 100%, então adoptar uma metodologia ágil é complicar o que pode ser bastante simples. É ignorar todos os guias de base já delineados, é ignorar a capacidade de se ter um cronograma de projecto, é transmitir ao cliente desconhecimento.

Se o custo do projecto estiver associado a um âmbito já fechado de projecto, em oposição ao custo associado ao trabalho efectuado, então ir para uma metodologia ágil poderá ser má política. O montante a receber pelo cliente será sempre o mesmo, não recebendo mais por entregarmos funcionalidades.

Nos métodos tradicionais o risco deve ser gerido pela equipa de desenvolvimento, ao contrário dos métodos ágeis, que deve ser pelo cliente.