Apresentação da aula

QUALIDADE DE SOFTWARE

INTRODUÇÃO

É consenso e inegável que, nos últimos anos, as tecnologias tanto hardware como software tiveram uma evolução assombrosa, e a cada dia mais somos estimulados/motivados ao uso de sistemas baseados em computadores, em praticamente todas as atividades do cotidiano, até a simples abertura de uma cortina pode ser controlada por um computador. Durante muitos anos, esforços foram concentrados para o desenvolvimento e o aprimoramento das máquinas em si, mas atualmente o foco está na engenharia de sistemas, que apontam para estratégias de concepção e desenvolvimento de projetos. Outra preocupação refere-se à qualidade dos sistemas, a solução de problemas reais do usuário e a sua satisfação.

Vale lembrar que, para que um sistema seja usado por um número cada vez maior de pessoas e especialmente com satisfação e baixa frustação, um item de grande necessidade, que deve ser observado além da segurança e da qualidade da aplicação, é a qualidade da interface. Talvez por alguns desenvolvedores esse item não seja muito observado, sendo deixado de lado durante a construção da interface, mas é importante observarmos que para obtê-la a qualidade deve ser focada durante todo o processo de análise e desenvolvimento, e constantemente avaliadas, permitindo assim a identificação e os ajustes de possíveis problemas de interação antes da conclusão do projeto.

Dessa maneira, a interface não deve ser apenas agradável aos olhos, mas possuir essencialmente funcionalidades que minimizem a carga cognitiva do usuário, incluindo conhecimento de como as pessoas resolvem problemas. Como vimos na anteriormente, temos modelos mentais diferentes e conseguir encontrar uma maneira de agradar uma maioria é essencial.

A equipe de desenvolvimento de software, para garantir uma alta qualidade de uso de seu produto, não deve pensar que basta seguir uma lista de métodos e princípios de projeto definidos e desenvolvê-lo conforme as especificações do negócio em questão. Como já mencionamos, uma falha muito comum é imaginar que todos os usuários que utilizarão o sistema têm a mesma visão do projeto que o designer possui, uma vez que, por estarem mergulhados em regras e conceitos do negócio, imaginam que todos estejam no mesmo nível, o que normalmente não é verdade. Os analistas e os desenvolvedores devem ter sempre em mente que alguém, em algum momento, avaliará as regras, as funções e, principalmente, a qualidade de uso do seu sistema, o que provavelmente será feito pelo usuário final.

Caso o usuário não concorde ou não compreenda bem como o sistema funciona, ou se ele tenha que se esforçar muito para conseguir lembrar os comandos, o sistema corre o risco de não ser bem aceito e de cair em desuso.

CONCEITUANDO QUALIDADE

A qualidade é muito importante no desenvolvimento de uma interface, mas um grande questionamento surge, o conceito de qualidade, que detalharemos a seguir:

Sem dúvida, a definição do termo qualidade constitui um tema controverso. Uma discussão interessante do significado do termo pode ser encontrada em Kitchenham e Walker [Kitc86]. Hyatt e Rosenberg [Hyat96] comentam que, embora todos concordem que a qualidade é importante, ninguém concorda com o que qualidade significa. Kitchenham [Kitc96] afirma que qualidade é difícil de definir e impossível de medir, porém fácil de reconhecer. Gillies [Gill92] acrescenta que a qualidade é transparente quando presente, porém facilmente reconhecida em sua ausência. Por outro lado, as definições dos dicionários são excessivamente vagas ou sujeitas a uma grande diversidade de interpretações para servirem de respaldo para uma discussão. O Novo Dicionário da Língua Portuguesa [Holl86], por exemplo, define qualidade como “1. Propriedade, atributo ou condição das coisas ou das pessoas capaz de distingui-las das outras e de lhes determinar a natureza. 2. Numa escala de valores, qualidade que permite avaliar e, consequentemente, aprovar, aceitar ou recusar qualquer coisa” (QUEIROZ, 2001, p. 26-27).

Ainda segundo o autor, as percepções de qualidade são verificadas por diferentes domínios do conhecimento humano, incluindo filosofia, economia e marketing, e foram examinadas e relatadas por diversos autores, que as encararam como diferentes facetas de um conceito complexo, e a partir de cinco perspectivas diferentes, a saber:

• • • Transcendental, que é baseada na descrição platônica do ideal e no conceito aristotélico de forma, este ponto de vista encara a qualidade como algo que pode ser reconhecido, mas não definido.
    • Do ponto de vista do usuário, é embasada no compromisso entre as suas necessidades e as características do produto (altamente personalizada e inerente ao contexto de modelagem de desempenho e confiabilidade, visto que se avalia comportamentos de produtos com relação à funcionalidade esperada e aos padrões de uso).
    • Da perspectiva do produto, é fundamentada em características inerentes ao produto, assumindo que a mensuração e o controle de suas propriedades intrínsecas (denominadas indicadores de qualidade internos) resultam na otimização de seu comportamento externo (qualidade em uso).
    • Segundo o fabricante, essa está focalizada na qualidade do produto durante o seu desenvolvimento e após a entrega (ou seja, dependente da especificação).
    • Qualidade baseada no custo, é respaldada no montante que o consumidor se dispõe a pagar pelo produto, o que implica a avaliação e revisão dos requisitos de produção à luz de relações de custos e benefícios (QUEIROZ, 2010, p. 27).

Como percebemos, o conceito de qualidade é muito variável e está atrelado a quem e como está sendo observado.

[a qualidade é] uma associação evidente de características inter-relacionadas que refletem adequadamente exigências específicas e implícitas de um produto, processo ou serviço que são relevantes em um dado contexto atual e sua circunvizinhança, ou seja, o que foi solicitado e em que momento isso foi solicitado (QUEIROZ, 2010, p. 31).

EUROPEAN ORGANIZATION FOR QUALITY (EOQ)

Segundo a visão da European Organization for Quality (EOQ), expressa através de um documento redigido durante a presidência finlandesa da União Europeia, em 1999, qualidade é a relação entre requisitos e resultados reais, a diferença entre o que se espera e o que se consegue. Ele ainda afirma que o documento dedica duas seções inteiras discutindo aspectos relativos ao termo qualidade, a qual se baseia em valores e se expressa em escolhas, sendo um atributo valioso na distinção entre o bom e o ruim, o aceitável e o inaceitável, os sem iniciativa e os empreendedores. Queiroz (2010, p. 31) ainda ressalta que, com o objeto de enfatizar as conotações do termo valores, o documento menciona serem vários os seus significados, embora apresente apenas os dois empregados na discussão, a saber:

• • • Ideias genéricas de preferências em situações em que se dispõe de duas ou mais linhas de ação; e
    • No contexto de transações envolvendo produtos e serviços, atributo associado à percepção individual de utilidade e do grau de importância que cada indivíduo confere à transação (QUEIROZ, 2010, p. 31).

Queiroz (2010) ainda apresenta as duas conotações que são sintetizadas na figura a seguir, adaptada do original, que ilustra no lado esquerdo o primeiro significado dado ao termo pela EOQ, enquanto o lado direito ilustra a segunda conotação que a EOQ dá ao termo.

Qualidade é a relação entre requisitos e resultados reais, a diferença entre o que se espera e o que se consegue.

A qualidade se baseia em valores e expressa em escolhas, sendo um atributo valioso na distinção entre o bom e o ruim, o aceitável e o inaceitável, os sem iniciativa e os empreendedores.

Como percebemos, a qualidade é muito complexa e, em termos de qualidade de software e interface, sua complexidade também é grande.

Qualidade de software é frequentemente definida em termos da adequação do produto aos propósitos segundo os quais foi desenvolvido. Entretanto, há de se considerar que diferentes usuários têm propósitos diferentes para o mesmo produto. Um usuário principiante esporádico provavelmente estará mais interessado na facilidade de aprendizagem e na tolerância a erros exibidas pelo produto do que na eficiência por este apresentado. Por outro lado, um gerente de redes que planeja incorporar o produto a algum sistema maior estará mais interessado na capacidade de detecção e de recuperação de falhas que o produto apresenta do que na facilidade de instalação deste. Uma empresa de treinamento e manutenção do produto se preocupará com questões relativas à documentação técnica e à facilidade de teste do produto (QUEIROZ, 2010, p. 31).

Como percebemos, esse assunto demanda muita atenção e conhecimento dos nossos usuários para conseguirmos realizar a tarefa de buscar a qualidade nos softwares, especialmente nas interfaces, e obter por parte dos usuários a aceitação do sistema.

SQM (SOFTWARE QUALITY METRICS – MÉTRICAS DE QUALIDADE DE SOFTWARE)

McCall et al. (apud QUEIROZ, 2010) propuseram um dos primeiros modelos de qualidade de software, que é chamado de SQM (Software Quality Metrics – Métricas de Qualidade de Software), no qual as qualidades almejadas para o produto são estruturadas em uma hierarquia de fatores, critérios e métricas.

Para Queiroz (2010), os fatores de qualidade de software do SQM têm seu foco em três aspectos relevantes de um produto de software, que são as características operacionais, capacidade de revisão e capacidade de adaptação a novos ambientes, conforme apresentado na figura a seguir. Cada fator de qualidade representa uma característica comportamental do produto e cada critério de qualidade é um atributo do fator de qualidade relacionado com o projeto e com a produção do software considerado.

ISO 9126

Queiroz (2010, p. 37) faz uma reflexão importante em relação ao padrão ISO9126:

Vale a pena mencionar que o padrão ISO9126, apesar de recomendar a mensuração direta das referidas características, não sugere métricas nem indica claramente como fazê-lo. Apenas sugere que, caso a característica desejada não possa ser mensurada diretamente (especialmente durante a fase de desenvolvimento do produto), deve-se procurar medir algum outro atributo que possa auxiliar o avaliador a prognosticá-la. Além disto, apresenta em um de seus anexos uma indicação de como as características podem ser decompostas em subcaracterísticas. No entanto, não apresenta diretrizes para a implementação de um bom sistema de prognósticos.

Podemos analisar como é a definição de qualidade, segundo a ISO, com base na característica esperada, conforme apresentado na figura a seguir.

COMPARANDO OS MODELOS

Queiroz (2010) afirma que modelos como o SQM e padrões como o IS09126 estabelecem uma nomenclatura para a qualidade de software, mesmo eles tendendo a ser rígidos ou abstratos. Além do mais, não podem assegurar o aprendizado e o uso da terminologia a eles associada, o que pode acarretar a definição insuficiente de estimativas de qualidade dentro de um determinado contexto avaliativo, bem como o emprego inadequado e inconsistente de termos de qualidade por projetistas e avaliadores.

[O GRCM (Goal-Rule-Checklist-Metric)] constitui um refinamento do ISO 9126, apresentando metas (goals) que se fazem corresponder a fatores e regras (rules), correspondentes a critérios. As listas de inspeção (checklists) explicam aos avaliadores quais as regras a serem discutidas com os projetistas e quais são as métricas (metrics) que deverão ser empregadas para implementar a inspeção na prática (QUEIROZ, 2010, p. 39).

A terminologia e o vocabulário das regras devem ser adequados para o desenvolvimento orientado ao objeto. As listas de inspeção são empregadas pelos avaliadores para analisar se o projetista realmente seguiu a(s) regra(s).

A usabilidade, como percebemos, é uma constante nos processos de avaliação de qualidade e, ao longo das duas últimas décadas, vem sendo cada vez mais considerada como fator, característica ou critério de qualidade de software (QUEIROZ, 2010). Como podemos observar nas figuras anteriormente apresentadas, ele aparece como um dos componentes de cada modelo de qualidade de software apresentado, seja na SQM, na ISO9126 e na GRCM. Também podemos verificar sua associação a conjuntos de atributos através dos quais pode ser mensurada.

Verificando a figura anterior, percebemos que dos oito atributos de usabilidade considerados nos modelos apresentados, apenas um é compartilhado por todas as formas de avaliação apresentada, a facilidade de operação (operability). E temos na segunda posição e não menos importante a facilidade de aprendizado (learnability).

Diferente dos outros atributos de usabilidade que não aparecem em todos os modelos analisados, para Queiroz (2010, p. 48), “Quanto aos pares de atributos (i) capacidade de treinamento (training) e facilidade de aprendizado (learnability); e (ii) facilidade de operação (operability) e facilidade de uso (ease of use), estes apresentam similaridades entre si, apesar de não serem exatamente equivalentes.

Outro padrão para aplicação de usabilidade, além dos que já apresentamos, é a ISO-9241. Como todas as outras apresentadas, ela também tem sua especificidade, essa regra trata do trabalho de escritório informatizado, através de planilhas eletrônicas e processamentos de textos, entre outros aplicativos.

Discussão

Falaremos um pouco mais de usabilidade, apresentando perspectivas de avaliação da usabilidade.

A norma ISO 9241 trata do trabalho de escritório informatizado através do uso de planilhas eletrônicas e de processadores de textos, entre outros aplicativos. Não estão incluídos os aplicativos de projeto auxiliado por computador e de controle de processos (CAD-CAM), bem como as interfaces que usem estereoscopia ou realidade virtual. Não são abordados aspectos da emissão de radiações ou segurança elétrica dos equipamentos, cobertos pelas normas IEC.

Esta norma internacional se destina aos profissionais encarregados de garantir um trabalho de escritório seguro e efetivo com os computadores. Seu objetivo é promover a saúde e a segurança de usuários de computadores e garantir que eles possam operar estes equipamentos com eficiência e conforto. Isso requer um projeto cuidadoso dos terminais de computadores, dos locais de trabalho e do ambiente nos quais eles são usados, assim como da organização e do gerenciamento do próprio trabalho. As considerações da ergonomia são importantes no projeto de qualquer equipamento usado por seres humanos, mais especialmente quando este uso é intensivo ou se a precisão e a velocidade forem fatores críticos. Os computadores e seus terminais de vídeo formam uma parte significativa do trabalho de escritório e muito frequentemente determinam o desempenho do usuário em suas atividades.

De uma maneira geral, as recomendações que constam da ISO 9241 foram definidas por evidência empírica e a partir da revisão da literatura existente, sendo então generalizadas e formuladas em termos de requisitos para o uso de projetistas e avaliadores de interfaces. O comitê técnico TC-159, que se ocupa de ergonomia, e em particular o subcomitê SC 4, que se ocupa da ergonomia da interação homem-sistema, organizaram a ISO 9241 em um conjunto de 17 partes, cada uma lidando com diferentes aspectos do trabalho em escritórios informatizados.

No que se refere ao equipamento, as recomendações tratam somente dos fatores que afetem o desempenho dos usuários e estejam menos sujeitos às variações do estado da tecnologia. Para medir este desempenho, a ISO 9241 fornece indicações sobre as características do equipamento que são importantes sob o ponto de vista ergonômico, como medir ou avaliar estas características, que equipamento de teste utilizar, como formar uma amostra de usuários apropriada, que condições experimentais montar e qual o nível de desempenho esperar. Como nem sempre é possível realizar estes testes, a ISO 9241 traz recomendações que podem ser utilizadas de modo prescritivo, simplesmente auxiliando na busca dos níveis esperados de desempenho humano.

As 8 partes que se referem às interfaces de software já são normas internacionais e encontram-se em fase de tradução para compor uma norma brasileira correspondente. De fato, a Comissão de Estudos da ABNT para ergonomia de software foi instalada em julho de 1999 e prepara-se para lançar a parte 1 da norma brasileira.

A parte 10 define os 7 princípios de projeto que, segundo o comitê técnico que elaborou esta norma ISO, podem levar a uma interface humano-computador ergonômica. São eles a adequação à tarefa, a autodescrição, a controlabilidade, a compatibilidade com as expectativas do usuário, a tolerância a erros, a adequação para a individualização e a adequação para a aprendizagem. Para cada princípio de projeto são apresentadas recomendações gerais com exemplos específicos.

Adaptabilidade à tarefa: um diálogo é adaptável à tarefa quando dá suporte ao usuário na realização efetiva e eficiente da tarefa.

ADAPTABILIDADE À TAREFA

Aplicações	Exemplos
O diálogo deve ser apresentado ao usuário somente com informações relacionadas a realização da tarefa.	Informações sobre formatação, tais como cores, datas etc., são apresentadas somente se facilitam a realização da tarefa.
Informação de ajuda deve ser dependente da tarefa.	Quando o usuário solicita ajuda o sistema de diálogo apresenta informação relevante a tarefa corrente (ex: lista de comandos de edição, se em estado de edição). Quando uma caixa de diálogo particular é mostrada e o usuário solicita ajuda, a interface do software apresenta informação relevante na caixa de diálogo.
Monthly savings Quaisquer ações que possam ser executadas automaticamente de forma apropriada devem ser legadas a efeito pelo software sem envolvimento do usuário.	O cursor é automaticamente posicionado na primeira entrada do campo relevante para a tarefa. Procedimentos de inicialização do sistema são automaticamente processados.
Quando do projeto do diálogo considerar as habilidades e capacidades do usuário face à complexidade da tarefa.	Num sistema de acesso público, onde existe um conjunto de alternativas de entradas, um menu é utilizado para apresentar as escolhas possíveis.

 

AUTODESCRIÇÃO

Aplicações	Exemplos
Se for apropriado, depois de qualquer ação do usuário, o diálogo deve oferecer feedback. Se consequências graves possam resultar das ações dos usuários, o sistema deve oferecer explicação e solicitar confirmação antes de efetuar a ação.	O eco da digitação e a modificação do status do dado são necessários para ajudar o usuário a compreender o que acontece com o aplicativo e o que ele pode controlar. Se o diálogo pode ser revertido, o aplicativo deve indicar de forma explicita o que pode ser revertido. Se a supressão não pode ser revertida, o sistema deve demandar uma confirmação.
O feedback ou as explanações devem ser apresentados numa terminologia adequadamente derivada do ambiente da tarefa e não da tecnologia do sistema.	Os termos técnicos usados no diálogo são os empregados no campo específico do aplicativo. Adicionalmente, o usuário pode solicitar a explicação sobre um termo através de um procedimento específico. Assim, após entrar o termo “mudança de escala” o usuário recebe uma explicação da tarefa envolvida com uma referência ao comando relevante e a informação suplementar disponível no manual do usuário.

 

Controle: o diálogo é controlável quando o usuário é capaz de iniciar e controlar a direção e o ritmo da interação até que seu objetivo seja atingido.

CONTROLE

Aplicações	Exemplos
A velocidade da interação não deveria ser ditada pelo sistema. Ela deve estar sempre sob o controle do usuário, de acordo com suas necessidades e características.	Nenhum campo de dado deve ser limpo, modificado ou não disponibilizado ao usuário antes que ele complete a entrada de dados, por exemplo, pressionando a tecla ENTER.
Ao usuário deveria ser dado o controle sobre como continuar o diálogo.	O sistema posiciona o cursor sobre o próximo campo, mas oferece ao usuário a possibilidade de selecionar outro campo diferente.
Quando da retomada do diálogo após uma interrupção, o usuário deveria ter a habilidade de determinar o ponto de reinício, se a tarefa o permitir.	É possível ao usuário decidir após uma interrupção (com base em resultados provisórios) se o diálogo deveria ser continuado desde o ponto de interrupção, se alguma interação deveria ser revertida ou se todo o diálogo deveria ser cancelado com a possibilidade de definir certas condições para reiniciá-lo.
Se existem interações reversíveis e a tarefa permite, deveria ser possível desfazer no mínimo o último passo do diálogo.	O sistema oferece a possibilidade de acessar o último objeto suprimido.

Conformidade com as expectativas do usuário: o diálogo adapta-se às expectativas do usuário quando ele é consistente e corresponde a suas características, tais como conhecimento da tarefa, educação, experiência e convenções.

CONFORMIDADE COM AS EXPECTATIVAS DO USUÁRIO

Aplicações	Exemplos
O comportamento e a aparência do diálogo no sistema deveriam ser consistentes.	Mensagens de status do sistema aparecem sempre na mesma linha da tela. A mesma tecla é sempre usada para encerrar um diálogo.
Ações de mudança de estado deveriam ser implementadas consistentemente.	A tecla F1 é sempre reservada para a ajuda.
O aplicativo deveria usar um vocabulário que fosse familiar ao usuário na execução de uma tarefa.	Os termos técnicos empregados no diálogo são os mesmos utilizados no contexto da tarefa do usuário.

Tolerância a erros: um diálogo é tolerante a erros se a despeito de erros evidentes de entrada o resultado esperado puder ser alcançado com mínimas ou nenhuma ação corretiva por parte do usuário.

TOLERÂNCIA À ERROS

Aplicações	Exemplos
O aplicativo deveria apoiar o usuário na detecção, evitando os erros de entrada. O sistema deveria prevenir qualquer entrada do usuário que instabilizem o sistema ou que ocasionem falhas no diálogo.	Se uma sequência de ações é necessária, a interface é projetada de maneira a que o próximo passo na sequência possa ser determinado a partir da informação apresentada. Por exemplo, no preenchimento de formulários os rótulos do próximo campo a ser preenchido é apresentado claramente.
Os erros devem ser explicados de maneira a ajudar os usuários e corrigi-los.	O sistema apresenta uma mensagem de erro contendo informação sobre a ocorrência do erro, o tipo de erro e sobre possíveis métodos de correção (na medida em que o sistema seja capaz de fazê-lo).
Dependendo da tarefa pode ser desejável aplicar esforço especial na apresentação de técnicas para melhorar o reconhecimento de situações de erro e a sua recuperação.	O sistema detecta um erro que relacionado com um campo em particular. Esse campo é salientado e o cursor posicionado automaticamente no início do campo. As entradas aceitáveis são mostradas.

Adequação à individualização: o sistema é capaz de individualização quando a interface pode ser modificada para se adaptar às necessidades da tarefa, às preferências individuais e às habilidades dos usuários.

ADEQUAÇÃO À INDIVIDUALIZAÇÃO

Aplicações	Exemplos
Mecanismos deveriam ser fornecidos para permitir ao sistema se adaptar à linguagem e cultura dos usuários, assim como seu conhecimento individual, a experiência no domínio da tarefa, habilidades perceptivas, senso-motoras e cognitivas.	Aumento do tamanho das fontes para usuários com problemas de visão, corrigir o uso de cores para usuários com problemas de detecção de cores, diferentes atribuições para teclas para diferentes culturas. O mouse pode ser adaptado para usuários destros e canhotos.
O sistema deveria permitir que o usuário escolha entre modos alternativos de apresentação de acordo com suas preferências individuais e de acordo a complexidade da informação a ser processada.	O usuário pode alterar a apresentação e/ou o formato das saídas de acordo com preferências pessoais.

Adequação ao aprendizado: o sistema é adequado ao aprendizado quando apoia e conduz o usuário no aprendizado do sistema.

ADEQUAÇÃO AO APRENDIZADO

Aplicações	Exemplos
Regras e conceitos subjacentes que são úteis para o aprendizado deveriam estar disponíveis para o usuário, permitindo que ele construa seus próprios grupos de estratégia e regras de memorização de atividades.	O usuário é capaz de obter informação sobre qual modelo o aplicativo está baseado. As combinações de teclas de aceleradores, quando possível, devem usar a primeira letra do comando de menu correspondente e indicá-lo claramente.
Estratégias relevantes de aprendizado (compreensão orientada, aprendizado pela ação, aprendizado por exemplos) deveriam ser fornecidos.	O usuário pode sempre navegar livremente entre a informação de ajuda e a obtenção de feedback de exemplos (O usuário pode solicitar uma explicação sobre uma certa função e pode executá-la em um modo condicional). O aprendizado pela ação é apoiado pelo encorajamento do usuário a experimentar, percorrer exemplos durante várias situações, aplicando alternativas condicionais (permitir correção de erros sem o perigo de causar resultados catastróficos).

A parte 11 refere-se à especificação da usabilidade dos sistemas, definida como aquelas características que permitem que o usuário alcance seus objetivos e satisfaça suas necessidades dentro de um contexto de utilização determinado. Desempenho e satisfação do usuário são especificados e medidos a partir do grau de realização de objetivos perseguidos na interação (eficácia), pelos recursos alocados para alcançar estes objetivos (eficiência) e pelo grau de aceitação do produto pelo usuário (satisfação). Esta parte da norma ISO 9241 reforça a ideia de que a usabilidade depende do contexto de utilização, e que o nível de usabilidade atingido será função das circunstâncias particulares de utilização do produto. O contexto de utilização compreende os usuários, as tarefas, o equipamento (hardware, software e documentos) e os ambientes físicos e sociais suscetíveis de influenciar a usabilidade de um produto dentro de um sistema de trabalho. As medidas de desempenho e de satisfação dos usuários avaliam a qualidade do sistema de trabalho com todas as suas interligações. Qualquer mudança como treinamento adicional ou melhoria de iluminação forçam uma reavaliação da usabilidade do sistema.

A norma ISO 9241-12 lida com a apresentação visual das informações através de terminais de vídeo. Ela traz princípios gerais para a apresentação da informação e se refere tanto à organização da informação nas telas quanto ao uso de técnicas de codificação individual. Suas recomendações referem-se a janelas, áreas de entradas e saídas, grupos, listas, tabelas, rótulos, campos, cursores, aspectos sintáticos e semânticos de códigos alfanuméricos, abreviaturas, codificação gráfica, códigos de cores e outras técnicas de codificação visual.

A parte 13 se refere à condução ao usuário, vista como o conjunto de informações suplementares, portanto adicionais ao diálogo habitual entre homem-máquina, que são fornecidas sob comando do usuário ou automaticamente pelo sistema. Os elementos do sistema de condução incluem os convites, o feedback, as informações sobre o estado do sistema, a gestão de erros e a ajuda em linha. Eles auxiliam a interação do usuário com o sistema, evitando a carga de trabalho mental inútil, fornecendo aos usuários um meio de gestão de erros, além de uma assistência adequada ao seu nível de competência. As recomendações contidas nesta norma se referem a situações típicas, envolvendo necessidades específicas de informações e de ações.

As partes 14 a 17 se referem a estilos de diálogo; por menu, por linguagem de comandos, por manipulação direta e por preenchimento de campos. As normas fornecem uma estrutura de recomendações referentes à pertinência destes estilos de diálogo, sobre como realizá-los em seus diferentes aspectos e como avaliá-los.

Assim, por exemplo, os diálogos por menus, tratados pela parte 14, são aplicáveis quando o uso da aplicação não é frequente e quando o conjunto de opções de comandos é muito grande para confiá-lo à memória de um usuário com um mínimo de treinamento, sem prática de digitação e com pouca ou nenhuma experiência com o sistema. As recomendações ergonômicas que estão incluídas nesta parte da norma se referem à estrutura dos menus, à navegação dentro desta estrutura, à seleção e à execução de opções de menu.

A parte 15 trata dos diálogos por linguagem de comandos, que se aplicam quando a tarefa requerer um rápido acesso a funções específicas do sistema, em que é impossível fazer prognósticos em termos das escolhas das ações que o usuário precisará e onde os dados ou opções de comandos possam ser introduzidos em ordem arbitrária. Por seu lado, o usuário precisa receber um treinamento formal, fazer uso frequente do sistema e mostrar habilidades de datilógrafo. As recomendações referem-se à estrutura e à sintaxe dos comandos, a suas representações e as entradas e saídas com este estilo de diálogo.

Os diálogos por manipulação direta, assunto tratado pela parte 16, aplicam-se quando as entradas forem de difícil descrição e onde possa existir a possibilidade de construir metáforas com os objetos do mundo físico que facilitem a visualização do sistema. Os recursos dos equipamentos, em termos de resolução e velocidade de tratamentos gráficos, devem permitir apresentações e feedback eficientes. O usuário a quem se destina este tipo de diálogo não apresenta habilidades de digitação e prefere as representações gráficas às textuais. As recomendações da norma se referem à aparência e à manipulação de objetos gráficos, de texto, de controle e de janelas.

A parte 17 trata dos diálogos por preenchimento de formulários, aplicáveis quando as entradas do sistema forem predominantemente de dados, com uma estrutura rígida e com poucos comandos. Os usuários deste tipo de diálogo não precisam de treinamento específico, e suas habilidades de datilógrafo podem ser moderadas. As recomendações se referem à estrutura dos formulários, às entradas, ao feedback e à navegação pelos campos.

Verificando as qualidades ergonômicas através da ISO-9241

Para realizar uma avaliação segundo as partes desta norma internacional, os analistas devem, antes de tudo, ler a norma e suas correlatas, conhecer o produto de software, o usuário, a tarefa, o ambiente e o sistema de trabalho que o produto pretenda apoiar. O próximo passo é estabelecer uma lista de tarefas a serem usadas na avaliação (as mais importantes e as mais frequentes, por exemplo) e aplicar a norma. Para tanto, duas abordagens são examinadas. Na abordagem aconselhada, o avaliador utiliza o produto para escolher uma lista de tarefas e observa o usuário realizando estas tarefas. Cada elemento do sistema em análise será verificado contra as recomendações desta norma (ex.: condução ao usuário: convites, informações sobre o estado, feedback, mensagens de erros e ajuda em linha). Convém que os resultados sejam registrados segundo as rubricas: requisitos inaplicáveis, aplicáveis e seguidos, aplicáveis, mas não seguidos. Na outra abordagem sugerida, o próprio avaliador utiliza o produto e estuda os elementos do sistema durante esta utilização.

A conformidade à norma ISO 9241 é definida a partir dos resultados de duas análises; a de aplicabilidade do quesito e a de aderência do sistema ao quesito. Muitos dos quesitos propostos pelas diversas partes desta norma de ergonomia de software são condicionais, isto é, devem ser seguidas somente dentro de um contexto específico no qual elas são aplicáveis: tipos particulares de usuários, tarefas, ambientes e tecnologia. A norma prevê uma sistemática para justificar a definição da aplicabilidade de um quesito, que pode se dar pela evidência documentada sobre a tarefa, ou a partir da descrição do sistema ou por sua simples observação. A aplicabilidade pode ainda ser decidida com base na avaliação de um expert (avaliação analítica) ou a partir de procedimentos de testes com usuários finais (avaliação empírica). Por seu lado, uma decisão sobre a aderência do sistema ao quesito deve ser justificada através de diferentes métodos: por medição, evidência documentada, observação, avaliação analítica, avaliação empírica ou outro método.

Fim da aula.