Usabilidade e Qualidade

Published in

Contexto Delimitado

9 min readAug 13, 2019

Ter a preocupação de entender os fatores humanos e a evolução da interação humano-computador permite, ao projetista, planejar e desenvolver um software adequado para o usuário.

No artigo “A História da Interface”, abordei sobre a evolução da interface entre o homem e o computador sob a ótica da IHC. Neste pretendo avançar um pouco mais, explicando a importância da interface na usabilidade e qualidade de um software.

Esse conhecimento pode ser usado não apenas para alinhar o aplicativo às necessidades computacionais de um usuário, mas também para desenvolver um software que considere a linguagem do usuário e suas limitações, sejam elas físicas ou cognitivas, bem como outras características que influenciam diretamente a forma que ele o utiliza.

Por isso é importante sempre ler a respeito a fim de conhecer a história e a evolução das interfaces. Saiba mais sobre a IHC no artigo “Interface Humano-Computador”. Esse tipo de leitura possibilita ao projetista entender e evitar os erros já cometidos e, ao mesmo tempo, aproveitar as estratégias e os casos de sucesso obtidos anteriormente. Outra vantagem é que, conhecendo o passado, o presente torna-se mais compreensível, e o futuro, menos imprevisível.

A importância da qualidade

A qualidade é um quesito fundamental em todo o processo de desenvolvimento de software e, especialmente, na entrega do produto final.

Devido à importância somada à subjetividade desse assunto, surgiram tentativas comuns em várias áreas da engenharia para, de alguma forma, garantir a qualidade. Uma dessas formas foi a ISO (International Organization for Standardization), uma entidade que estabelece padrões ou normas mundiais que devem ser seguidas para garantir a qualidade (BEVAN, 1999).

Há várias normas estabelecidas, e cada uma é identificada por um número. Por exemplo:

ISO 8402: normas para estabelecer a capacidade de um item desempenhar uma função requerida (BEVAN, 1999);
ISO 14000: um conjunto de atributos que dizem respeito à capacidade do software de manter o seu nível de desempenho (ISO_B, 2010);
Entre outros.

Cada norma é para algo específico, por isso, para o desenvolvimento de um software, diversas delas podem ser consideradas.

A qualidade do Software

A variedade de normas existentes acaba intimidando os profissionais envolvidos, que acabam tendo dificuldade para conhecê-las e aplicá-las. Para facilitar isso, Nigel Bevan publicou uma pesquisa que estabelece uma estrutura agrupada por partes (BEVAN, 1999), onde cada uma representa uma etapa importante no desenvolvimento do software e o conjunto de ISOs que devem ser considerados.

Segundo Bevan (1999), qualidade é um conjunto de características que satisfazem as necessidades implícitas e explícitas de um software. Dessa forma, quando você se preocupa com a qualidade, na verdade deve considerar além das necessidades relatadas pelo usuário.

Em seu framework, Bevan (1999), descreve três tipos de qualidade:

Qualidade Interna (ISO/IEC 9126–3): considera a inspeção nos requisitos e no código fonte. Há a preocupação de avaliar como o programa foi implementado (linguagem, organização, documentação etc.) e, se essa implementação foi realizada considerando os requisitos. Em outras palavras, o que foi implementado deve estar de acordo com o que foi planejado a com as funcionalidades que o usuário solicitou.
Qualidade Externa (ISO/IEC 9126–2 e): considera a análise do comportamento do código quando é executado. Esta análise deve observar: a) se o software gera resultados precisos ou, pelo menos, dentro do esperado; b) se sua capacidade de interagir com os outros sistemas está de acordo com o especificado; c) a frequência de falhas; d) a capacidade de manter determinados níveis de desempenho mesmo na presença de problemas; e) a capacidade do software para recuperar dados em caso de ocorrência de falha, etc.
Qualidade no Uso (ISO/IEC 9126–4): considera a necessidade de observar o comportamento do software em um determinado contexto de uso, envolvendo diretamente o usuário. Ou seja, é preciso verificar a facilidade que o usuário terá para reconhecer as funcionalidades existentes no software e a forma como cada uma delas será utilizada por ele. Também é preciso observar com que facilidade o usuário consegue aprender a utilizar o produto com todas as suas características.

Todas as funcionalidades que o usuário acessa ao interagir com o sistema é proveniente dos requisitos definidos, por isso, todos devem estar implementados no software (Qualidade Interna). Porém, de nada adianta tudo estar implementado se não estiver funcionando da maneira correta (Qualidade Externa). Todas as funcionalidades devem agir de acordo com o esperado e estar visível, para que o usuário. Ao interagir com o sistema, o usuário tem que conseguir identificar as funcionalidades e poder utilizá-las de forma amigável (Qualidade no Uso).

Ao adicionar estas três qualidades, segundo Bevan (1999), cinco características serão agregadas:

Aumento da eficiência: atender todas as necessidades do usuário, garantindo de que o software possua todas as funcionalidades desejadas e observadas durante o levantamento de requisitos;
Melhora na produtividade: estender as capacidades do usuário, de forma que o sistema computacional se torne como qualquer outro instrumento de trabalho, apoiando o usuário na realização de suas atividades. Usando o software, o usuário conseguirá realizar uma determinada tarefa de forma mais fácil, rápida e em menos tempo;
Redução de erros: fazer o usuário realizar uma determinada tarefa de forma correta. Sendo intuitivo, fácil de ser compreendido e possuindo uma interface de qualidade, o software permite ao usuário fazer tudo o que precisa sem dificuldades. Uma boa interface possui uma linguagem comum, fácil de ser entendida, sem inconsistências, ambiguidades, redundâncias ou palavras com duplo sentido;
Redução no treinamento: a capacidade de utilizar o sistema sem esforço cognitivo é uma característica primordial. Antigamente, os projetistas estavam mais preocupados com o tempo e os gastos durante todo o processo de desenvolvimento e poucos se preocupavam em como o sistema seria utilizado ou qual seria a dificuldade do usuário em realizar as tarefas. Isso é uma armadilha, pois quando a interface é difícil de ser compreendida, mesmo que o software tenha todas as funcionalidades, o usuário não conseguirá usá-las. Isso significará a necessidade de treinar o usuário e dar suporte até que ele consiga operar o sistema, o que significa igualmente perda de tempo e dinheiro;
Aumento da aceitabilidade: o usuário tende a gostar mais do software quando há informações e funcionalidades fáceis de serem encontradas e utilizadas. O que o usuário consegue fazer no software, usando a interface, influencia diretamente em sua aceitabilidade. Uma pessoa aceita com mais facilidade aquilo que ela gosta, compreende e se identifica.

Outras informações alarmantes na pesquisa de Bevan (1999), podem ser vistas a seguir:

60% dos problemas encontrados nos softwares são de usabilidade;
Apenas 5% dos erros estão relacionados às funcionalidades;
Uma grande preocupação concentra-se apenas no processo de codificar as necessidades e funcionalidades desejadas pelo usuário;
No geral, os projetistas não têm conseguido mostrar as funcionalidades para o usuário, perdendo mercado por causa da falta de Qualidade de Uso.

Barreiras para a falta de Qualidade no Uso

Para dar um norte aso projetistas de software, Bevan (1999) descreve as barreiras que influenciam a falta de qualidade na usabilidade.

1. Barreira do conhecimento

A falta de conhecimento é um dos fatores principais para essa enorme quantidade de erros na usabilidade.

2. Barreira cultural

Neste contexto, não se trata da cultura do usuário, mas da cultura da empresa que faz o software.

Um dos fatores é que os profissionais desconhecem as metodologias para se desenvolver uma interação centrada no usuário. Outro fator é que essa forma de desenvolvimento não faz parte do dia a dia da empresa, que está frequentemente mais preocupada com as funcionalidades, deixando em segundo plano a questão da interface e da usabilidade.

É importante se preocupar desde o início com esses fatores e, sempre que possível, envolver o usuário nesse processo. Não há ninguém melhor do que ele para dizer se algo está bom ou não.

3. Barreira técnica

É importante criar processos que adicionem metodologias e atividades que ajudem os profissionais a desenvolver softwares de forma adequada, ou seja, incluindo as necessidades da IHC. Algumas vezes, a falha está no próprio processo que não cativa a atenção dos profissionais, pecando por não expôr claramente a sua finalidade e benefícios.

Uma forma de permitir um bom processo para os profissionais é a documentação de tudo o que é feito durante o desenvolvimento. Mesmo que, para alguns seja uma tarefa tediosa, ela permitirá que sejam registrados todos os processos adotados:

A forma como foi feito o levantamento de requisitos;
O planejamento elaborado;
O processo de desenvolvimento;
A metodologia de testes;
Entre outros.

Com tudo documentado, é possível identificar o que aconteceu, bem como as as ações e estratégias certas ou erradas durante todo o projeto. O documento resultante, mesmo como rascunho, se torna um patrimônio precioso da empresa contendo as lições aprendidas e uma base de conhecimento sobre como (e porquê) o processo pode ser aprimorado nos próximos projetos.

A ISO 13407 explica como atingir a Qualidade no Uso adotando as técnicas de IHC como objetivo principal durante todo o clico de desenvolvimento do software. São quatro tarefas que devem fazer parte do ciclo de vida:

Especificar e entender o contexto de uso;
Especificar e entender os requisitos da empresa e dos usuários;
Desenvolver a solução de interação (interface e todas as características da IHC);
Avaliar a interação considerando os requisitos.

Essas tarefas devem se tornar uma sequência a ser mantida, podendo ser repetida indefinidamente a cada novo requisito a ser implementado, fornecendo detalhes suficientes para produzir software de qualidade.

4. Barreira estratégica

A Qualidade no Uso deve ser o principal objetivo durante o desenvolvimento do software, pois quando a estratégia considera a qualidade desde o início, a possibilidade de alcançá-la é muito maior. Essa qualidade deve constar nos requisitos e ser uma prioridade.

Em muitos casos, não há informações precisas sobre a Qualidade no Uso, existindo pouco incentivo e impedindo-a de ser o objetivo principal.

Segundo Bevan (1999), também existem diferenças no que é qualidade para o usuário e para os profissionais. Essas diferenças têm que ser esclarecidas o quanto antes para que essas divergências não atrapalhem a qualidade do software na hora do planejamento e do desenvolvimento.

A ISO 9241–11 (ISO_C, 2010) descreve como a Qualidade no Uso pode ser definida, documentada e avaliada como parte da qualidade do sistema:

Identificar o contexto de uso: informações sobre as características do usuário, tarefas, objetivos e o ambiente em que o usuário trabalha são informações que proveem o contexto de uso;
Especificar qualidade nos requisitos de uso: especificar os critérios para se definir a Qualidade no Uso que o sistema deve atingir. Esses critérios devem ser observados durante os testes, sendo usados para identificar e medir a eficiência, a produtividade, a satisfação e a aceitabilidade do software;
Monitorar a Qualidade no Uso: avaliar a qualidade do software durante as várias etapas do processo de desenvolvimento. As informações obtidas nessas avaliações serão decisivas para identificar as modificações necessárias na interface e em toda a interação;
Avaliar a Qualidade no Uso: é importante estar em um ambiente que faz parte do contexto real, realizando testes no próprio ambiente em que o software será utilizado.

Por enquanto é isso. Em artigos posteriores, tentarei demonstrar as técnicas existentes sobre como testar de qualidade e usabilidade de interfaces.

O Design Centrado no Usuário

A concorrência na indústria de softwares causou um aumento na preocupação em desenvolver aplicativos que atendam as…

medium.com

Leia todos os artigos desta série:

Referências para aprofundamento

BEVAN, N. Quality in Use: meeting user needs for quality. In: Journal of System and Software, 1999.

SOUZA, L. S.; SPINOLA, M. M. Requisitos de usabilidade em projetos de interface centrado no usuário de software de dispositivos móveis. Fortaleza-Brasil In: Associação Brasileira de Engenharia de Produção. ENEGEP, 2006.

ISO_A: INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. About ISO. Disponível em: <http://www.iso.org/iso/about.htm>. Acesso em: 13 jul. 2019.

ISO_B: INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14000 essentials. Disponível em: <https://www.iso.org/iso-14001-environmental-management.html>. Acesso em: 13 jul. 2019.

ISO_C: INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9241–171:20Disponível em: <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39080>. Acesso em: 13 jul. 2019.