2 considerações sobre qualidade e usabilidade de softwarerangel/ihm/downloads/capitulo2.pdf ·...

“Some designers cannot understand the apparent stupidity of users who have difficulty accessing the

brilliant functions which, at great cost, have been cleverly built into the software. HCI process method

producers need to recognise that they are now in the same situation, with those stupid system designers

failing to use their sophisticated usability design guides and procedures. So how do we set about taking

our own medicine?”

[Brian Shackel]

2 Considerações sobre Qualidade e Usabilidade de Software ..................23

2.1 Qualidade de Software e Satisfação do Usuário ............................................ 25

2.1.1 Qualidade e Qualidade de Software ................................................................... 26

2.3.2 Facetas da Qualidade de Software..................................................................... 34

2.3.2 Qualidade de Software e Satisfação do Usuário ............................................... 39

2.2 Engenharia, Engenharia de Software e Engenharia da Usabilidade ............ 41

2.2.1 Engenharia .......................................................................................................... 41

2.2.2 Engenharia de Software...................................................................................... 43

2.2.3 Engenharia da Usabilidade ................................................................................. 45

2.3 Usabilidade de Software ................................................................................... 47

2.3.1 Visão de Shackel ................................................................................................. 53

2.3.2 Visão de Nielsen .................................................................................................. 55

2.3.3 Visão da ISO (International Standards Organization) .......................................... 57

O presente capítulo discute aspectos relativos à qualidade e usabilidade de produtos de

software e às técnicas de avaliação de processos interativos usuário-computador, suas

potencialidades e limitações.

A seção 2.1 - Qualidade de Software e Satisfação do Usuário – se inicia com definições do

termo qualidade que servem como ponto de partida para uma discussão sobre a qualidade de

software. São apresentadas definições de diversos autores consagrados, assim como modelos

para a mensuração da qualidade de produtos de software. Finalmente, a seção é encerrada

com comentários sobre a relação existente entre a qualidade de software e a satisfação do

usuário.

A seção 2.2 (Engenharia, Engenharia de Software e Engenharia da Usabilidade) se inicia

com um estudo etimológico da palavra engenharia e apresenta definições de diversos autores

para os termos engenharia de software e engenharia da usabilidade, objetivando justificar o

emprego deste último ao longo deste documento.

Considerações sobre Qualidade e Usabilidade de Software

24

A última seção deste capítulo (Usabilidade de Software) retoma a discussão conduzida na

primeira seção, buscando evidenciar o elo existente entre a qualidade e a usabilidade de

software. Adicionalmente, apresenta considerações sobre usabilidade, discute três visões

clássicas da usabilidade enquanto atributo mensurável de produtos e direciona a discussão

para o âmbito da avaliação de interfaces usuário-computador, sendo encerrada com uma breve

menção às técnicas concebidas para este propósito.

2.1 Qualidade de Software e Satisfação do Usuário

É inegável que, no último quarto de século, as tecnologias de hardware e software evoluíram a

passos largos, estimulando o uso de sistemas baseados em computadores nas mais diferentes

atividades do cotidiano e instituindo uma nova ordem em nível mundial. Após décadas de

concentração de esforços direcionados para o desenvolvimento e o aprimoramento de tecnologias

computacionais, as tendências atuais da engenharia de sistemas apontam para estratégias de

concepção e desenvolvimento de projetos que visam cada vez mais a solução de problemas reais

do usuário.

Também é inegável que os sistemas de software tornaram-se praticamente onipresentes

no cotidiano da vida contemporânea, uma vez que a maioria dos equipamentos elétricos incluem

algum tipo de software [Somm97]. Nas duas últimas décadas, em especial, o software vem

assumindo cada vez mais o papel do hardware como componente de planejamento mais difícil,

menos provável de obter sucesso tanto em termos de cumprimento de prazos quanto do

orçamento de custos e mais arriscado de se administrar [Press95, Somm97]. Em suma,

demandando mais atenção e esforços. Em geral, constata-se que os custos envolvidos em

processos de desenvolvimento de software não estão associados a características do produto

relacionadas com a metodologia adotada para implementá-lo, nem tampouco com a confiança dos

resultados que tal metodologia proporciona. Os custos estão associados, sobretudo, a quão

adequadamente o software é projetado, codificado e documentado, no que diz respeito à

manutenção, portabilidade, interoperabilidade e atualização, dentre outros aspectos [McCa79].

Os recursos investidos por grande parte das corporações de desenvolvimento de produtos

de software são cada vez mais vultuosos. Devido ao aumento da complexidade dos produtos, dos

requisitos de qualidade exigidos e das demandas de mercado, muitos dos problemas encontrados

são específicos ao processo de desenvolvimento de software, dentre os quais podem ser citados

dificuldades de planejamento, ausência ou precariedade de bons programas de avaliação da

qualidade dos produtos desenvolvidos, não cumprimento de prazos e, até mesmo e sobretudo,

falta de estruturação das atividades de desenvolvimento e avaliação dos produtos. Esta é uma das

principais razões que têm impulsionado companhias e instituições diversas do mundo inteiro a

continuarem investindo em recursos físicos, materiais, temporais e econômicos em processos de

otimização do desenvolvimento das aplicações de software que produzem e/ou utilizam.

Problemas de desenvolvimento enquadrados neste contexto compõem um quadro

usualmente rotulado por diversos pesquisadores da área (e.g., Gibbs [Gibb94], Sommerville

[Somm97]) como crise de software (software crisis). Uma análise da situação atual do mercado de

desenvolvimento de software conduz à constatação de que tais problemas vêm recebendo uma

atenção sempre crescente e sendo tratados cada vez mais efetivamente no contexto da

Otimização do Processo de Desenvolvimento de Software (SPI19). Como conseqüência, diversas

abordagens, envolvendo modelos, métodos e métricas variadas têm sido concebidas e validadas

por pesquisadores e equipes de desenvolvimento de software.

Em geral, estas abordagens costumam ser enquadradas por alguns autores (e.g., Thomas

e McGarry [Thom94], Pressman [Press95], Sommerville [Somm97], Solingen e Berghout [Soli97])

19 Software Process Improvement.


26

em uma de duas grandes categorias, assim discriminadas:

(i) abordagens top-down, tais como SPICE [Dorl93], BOOTSTRAP [Kuva94] e CMM

[Paul95], fundamentadas na determinação e análise do esforço global de desenvolvimento de

software, segundo características pré-definidas; e

(ii) abordagens bottom-up, tais como AMI [AMI92], GQM [Basi94a] e QIP [Basi94b], que se

fundamentam essencialmente na mensuração de componentes do processo de desenvolvimento,

sem características pré-definidas como fontes de informação básicas.

Em essência, a linha de abordagem top-down aplica um modelo normativo considerado o

melhor modo de desenvolvimento de software, que permite a análise da maturidade de uma

empresa de desenvolvimento de software e a proposição de otimizações relevantes ao contexto do

processo de desenvolvimento [Hump89]. Em contrapartida, a linha de abordagem bottom-up

argumenta que o campo da Engenharia de Software ainda é imaturo, tornando impossível a

definição de tal modelo normativo para desenvolvimento de software [Gibb94]. Portanto, adquire-se

conhecimento empírico através da mensuração de componentes do processo de desenvolvimento

de software, visando o aprimoramento da compreensão do referido processo em contextos

específicos. Nos últimos anos, ambas as linhas de abordagem vêm sendo aplicadas

satisfatoriamente em diversos contextos práticos [Somm97].

Sendo um processo através do qual números ou símbolos são associados a atributos de

entidades do mundo real, possibilitando sua descrição de acordo com regras claramente definidas

[Fent96], a mensuração constitui um auxílio importante em abordagens bottom-up de otimização

de processos de desenvolvimento de software, que sempre incluem algum tipo de plano de

mensuração. Nesse contexto, a qualidade do produto representa um papel de destaque,

exercendo uma forte influência no cotidiano de pesquisadores, projetistas, avaliadores e usuários,

pois dela depende a viabilidade das atividades que estes realizam com o auxílio do produto

[Kitc96]. Atualmente, a motivação para a perseguição da qualidade se afigura evidente, graças à

sua introdução em todos os níveis da produção de bens por técnicos, à sua popularização pela

mídia e à sua elevação de status como critério decisivo na aquisição de bens pelos consumidores.

2.1.1 Qualidade e Qualidade de Software

A busca da qualidade de produtos de software implica a consideração de uma série de

fatores os mais variados, abrangendo questões que vão desde a tomada de decisões por parte dos

empresários até a seleção de métricas mais apropriadas, passando por detalhes de cunho

temporal e econômico concernentes aos investimentos a serem feitos pelas empresas de

desenvolvimento. Um ponto de partida apropriado para uma discussão do assunto pode ser o

questionamento do termo qualidade.

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, mas

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.


27

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 (1) que permite avaliar e,

conseqüentemente, aprovar, aceitar ou recusar qualquer coisa.”

O Oxford Advanced Learner’s Dictionary [Horn90], por sua vez, define o termo equivalente

inglês quality como “1 (a) grau de excelência ou mérito (degree of goodness or worth). (b)

excelência global (general excellence). 2 (a) atributo, característica (attribute, characteristic).

(b) aspecto especial ou distintivo (special or distinguishing feature).”

Percepções de qualidade por diferentes domínios do conhecimento humano, incluindo

filosofia, economia e marketing, foram examinadas e relatadas por Garvin [Garv84, Garv88], que

as encarou como diferentes facetas de um conceito complexo. O autor descreveu as facetas do

termo a partir de cinco perspectivas diferentes, a saber:

(i) Transcendental, 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;

(ii) 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);

(iii) 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);

(iv) Do fabricante, focalizada na qualidade do produto durante o seu desenvolvimento e

após a entrega (ou seja, dependente da especificação);

(v) 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.

Portanto, a definição de qualidade está intimamente atrelada à perspectiva que se adote

para visualizá-la. Mensurá-la significa estabelecer referências, prognosticá-la adequadamente e

monitorar processos que impliquem sua otimização, ou seja, vinculá-la à perspectiva sob a qual é

encarada. Diferentes perspectivas implicam a consideração de diferentes aspectos que exercem

influência sobre a qualidade de um produto e, por conseguinte, a concepção de diferentes modelos

de qualidade. O Quadro 2, adaptado de uma das páginas do site da Tantara Management Services

[TMS00], complementa a discussão sobre qualidade, sintetizando aspectos relativos aos pontos de

vista de seis pesquisadores clássicos da área, a saber: Deming [Demi86, Walt86], Garvin [Garv88,

Flow90], Taguchi [in Roy90], Feigenbaum [Feig91], Crosby [Cros92] e Juran [Jura95].


28

QQuuaaddrroo 22


29

Os Quadros 3, 4 e 5 apresentam, respectivamente o programa de 14 pontos sugerido por

Deming [Demi86], as oito dimensões da qualidade apontadas por Garvin [Garv94] e o programa de

14 etapas sugerido por Crosby [Cros92] para a otimização da qualidade (referidos no Quadro 2).

Quadro 3 – O programa de 14 pontos de Deming [Demi86].

PROGRAMA DE 14 PONTOS DE DEMING

1. Tornar constante o propósito de otimização do produto e do serviço, objetivando a

competitividade, a permanência no mercado e a oferta de empregos.

2. Adotar a nova filosofia, pelo fato de se estar inserido em uma nova era econômica. (A

administração ocidental deve despertar para os novos desafios, apre(e)nder suas

responsabilidades e assumir a liderança através das mudanças.)

3. Romper a dependência da obtenção da qualidade a partir da inspeção, eliminando a

necessidade de inspeção respaldada em primeiro lugar na qualidade no produto.

4. Encerrar a prática de compensação de custos à base da etiquetagem de preços. Ao invés disto,

minimizar o custo total. Adquirir qualquer item necessário de um único fornecedor,

estabelecendo uma relação de longo prazo baseada na lealdade e confiança.

5. Otimizar intermitentemente e sempre o sistema de produção e o serviço, a fim de otimizar a

qualidade e a produtividade e, assim, progressivamente reduzir os custos.

6. Instituir um programa de treinamento.

7. Tornar efetiva a liderança (ver Ponto 12 e Capítulo 8 do Out of the Crisis, de Deming [Demi86]),

instituindo como meta da supervisão o suporte que possibilite o exercício melhor do trabalho

dos empregados, assim como das máquinas e dispositivos. A supervisão da administração

carece de inspeção do mesmo modo que a supervisão dos empregados do setor de produção.

8. Vencer os medos, de forma que todos possam trabalhar efetivamente para a companhia (ver

Capítulo 3 do Out of the Crisis, de Deming [Demi86]).

9. Romper as barreiras setoriais (equipes de pesquisas, projetos, vendas e produção), estimulando

o trabalho em equipe, a fim de preverem conjuntamente problemas na produção e do uso que

possam ser encontrados no produto ou serviço.

10. Eliminar slogans, exortações e metas que exijam da mão-de-obra a ausência de defeitos e novos

níveis de produtividade. Tais exortações só criam relações de adversidade, quando a maior

parte das causas da baixa qualidade e baixa produtividade é inerente ao sistema e, portanto,

transcende o poder da mão-de-obra.

11. a) Eliminar patamares-padrões de trabalho (cotas).

b) Eliminar a gestão a partir do objetivo. Eliminar a gestão através de números e de metas

numéricas.

12. a) Remover barreiras que privem os empregados do direito de se sentirem orgulhosos de seu

trabalho. Alterar a responsabilidade dos supervisores de meros números para qualidade.

b) Remover barreiras que privem o pessoal da administração e da engenharia do direito de se

sentirem orgulho de seu trabalho. Isto significa abolir a compensação anual por mérito e a

gestão a partir do objetivo (ver Capítulo 3 do Out of the Crisis, de Deming [Demi86]).

13. Instituir um programa vigoroso de educação e auto-aperfeiçoamento.

14. Atribuir a todos o encargo de realizar a transformação. A transformação é trabalho de todos.


30

Quadro 4 – As oito dimensões da qualidade [Cros92].

AS OITO DIMENSÕES DA QUALIDADE DE GARVIN

DIMENSÃO DESCRIÇÃO

1. DESEMPENHO (Performance) Características operacionais básicas do produto

2. FACILIDADES SUPLEMENTARES (Features) Características que suplementam o

funcionamento básico do produto

3. CONFIABILIDADE (Reliability)

Probabilidade de apresentação de falhas ou mau

funcionamento em um determinado intervalo de

tempo

4. CONFORMAÇÃO (Conformance) Grau de adequação a padrões pré-estabelecidos

5. DURABILIDADE (Durability) Tempo de vida até a substituição

6. PRESTAÇÃO DE SERVIÇOS (Serviceability) Facilidade de assistência técnica, rapidez e

competência dos serviços de manutenção

7. ESTÉTICA (Aesthetics)

Capacidade de satisfazer aos sentidos

(aparência visual do produto e impressões

auditiva, olfativa ou gustativa por ele causadas)

8. QUALIDADE PERCEBIDA (Perceived quality)

Inferências feitas a partir de aspectos tangíveis e

intangíveis do produto (papel relevante e crítico

da publicidade, da imagem e do rótulo do

produto)

Quadro 5 – O programa de 14 etapas de Crosby [Cros92].

PROGRAMA DE 14 ETAPAS DE CROSBY

1. Evidenciar o comprometimento da administração com a qualidade.

2. Formar equipes de otimização da qualidade com representantes seniores de cada setor.

3. Mensurar processos com o propósito de determinar onde há problemas e/ou onde há

potencialidade para a ocorrência de problemas.

4. Avaliar os custos da qualidade e explicar seu uso como ferramenta de gestão.

5. Estimular a preocupação individual de todos os empregados com a qualidade.

6. Agir no sentido de corrigir os problemas identificados a partir das etapas anteriores.

7. Estabelecer o monitoramento do progresso do processo de otimização (da qualidade).

8. Treinar supervisores a fim de que cumpram ativamente sua parte no programa de otimização da

qualidade.

9. Instituir um “Dia sem Falhas”20

, a fim de que todos se conscientizem da mudança e reafirmem o

comprometimento com o processo de gestão (da qualidade).

10. Encorajar os indivíduos a estabelecerem metas para a otimização em nível pessoal e grupal.

11. Encorajar os empregados a comunicarem aos gerentes os obstáculos defrontados para atingir

suas metas de otimização.

12. Mostrar reconhecimento e apreciar aqueles que participam.

13. Estabelecer conselhos de qualidade que interajam regularmente.

14. Enfatizar que o programa de otimização da qualidade nunca acaba.

20 Zero Defects Day, no original.


31

Dixon et al. [Dixo96] descrevem qualidade como uma associação evidente de

características interrelacionadas 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.

Segundo a visão da European Organisation for Quality [EOQ00], expressa através de um

documento redigido durante a presidência finlandesa da União Européia, em 1999, qualidade é a

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

O documento, que dedica duas seções inteiras discutindo aspectos relativos ao termo qualidade21,

acrescenta que a qualidade é baseada 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. A fim de enfatizar as conotações do termo valores, o documento menciona que

são vários os seus significados, embora apresente apenas os dois empregados na discussão, a

saber: (i) idéias genéricas de preferências em situações onde se dispõe de duas ou mais linhas de

ação; e (ii) 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.

As duas conotações são sintetizadas na Fig. 1, adaptada do original [EOQ00], onde se ilustra do

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.

Fig. 1 – Qualidade e valores, segundo a European Organisation for Quality [EOQ00].

Neste ponto, vale a pena questionar o que vem a ser, afinal de contas, qualidade de

software. Na verdade, várias definições têm sido propostas para o termo na literatura da área. Em

geral, a qualidade de um produto é tratada como uma de suas propriedades [Beva95a]. Assim, do

ponto de vista do produto, a qualidade implica a identificação dos atributos que podem ser

projetados ou avaliados, para que o produto seja otimizado. Na verdade, há quase duas décadas o

termo qualidade de software (software quality) tem recebido uma atenção cada vez maior, tanto

dos desenvolvedores quanto dos avaliadores e da comunidade usuária, tornando-se, por

conseguinte, amplamente divulgado.

21 Seções 1 (The European Quality Vision - a background…) e 2 (Quality – philosophical and practice perspectives)


32

Segundo Solingen et al. [Soli99], quando se visa a qualidade de produtos de software,

distingue-se duas abordagens possíveis, a saber: a abordagem do processo e a abordagem do

produto. Os autores acrescentam que enquanto a primeira abordagem tenta otimizar a qualidade

de produto indiretamente, a partir da otimização do processo, a segunda tenta fazê-lo diretamente.

Todavia, em muitas circunstâncias, conotações vagas e equivocadas do termo, desvinculadas do

processo e do produto, têm provocado uma certa desvirtuação da meta fundamental da indústria

de software: o aprimoramento dos diversos processos envolvidos na geração de seus produtos

finais [Drom96]. No que diz respeito aos usuários, Gentleman [Gent96] acrescenta que é

surpreendente o número de indivíduos que ainda associa o termo qualidade de software

simplesmente à ausência de erros.

Para alguns autores (e.g. Kitchenham e Pfleeger [Kitc96], Bevan [Beva97]), o contexto é

um aspecto de grande significância [Kitc96, Gent96, Beva97, Bond98] para a definição do termo

qualidade de software. O ponto de vista do qual o termo é focalizado representa outro aspecto

relevante a ser considerado, tendo em vista que os resultados de julgamentos feito por diferentes

indivíduos sobre algo que usam são função de seus pontos de vista [Bond98], assim como de suas

necessidades particulares. No âmbito da Engenharia de Software, não poderia ser diferente, tendo

em vista que projetistas, usuários, fabricantes e avaliadores de ferramentas de software

usualmente encaram o termo qualidade de ângulos distintos, ao aplicá-lo ao mesmo produto. São

as chamadas “perspectivas da qualidade”, mencionadas por diversos autores, e.g., Kusters et al.

[Kust97] e Miller [Mill97].

Qualidade de software é freqüentemente 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 apresentada. 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 a facilidade de teste do produto.

Tais considerações parecem conduzir à conclusão que qualidade de software não é

absoluta, mas uma percepção dependente de quem a avalia. Além disso, a qualidade de software

é multifacetada, sendo a importância de cada uma de suas facetas dependente do contexto de

uso, até mesmo para o mesmo indivíduo.

Muitas referências clássicas em Engenharia de Software (e.g., Gilbert [Gilb83], Schach

[Scha90], Hailstone [Hail91]) definem qualidade de software como a implementação correta da

especificação. Tal definição pode ser adequada durante a fase de desenvolvimento de produto,

embora se afigure inadequada quando utilizada para comparar produtos.

Kano et al. [Kano89] definem qualidade de software em três níveis, a saber: (i) qualidade

por excelência (excellent quality), definida como qualquer característica do software que exceda o

nível de desempenho esperado; (ii) qualidade unidimensional, definida como qualquer

característica do software desejada por usuários específicos, porém não inteiramente necessária

para todos as categorias de usuários; e (iii) qualidade esperada, definida como qualquer


33

característica necessária ao funcionamento normal do produto.

Denning [Denn92] focaliza o usuário ao definir qualidade de software e associa o termo ao

grau de satisfação do usuário, afirmando que quanto maior for o grau de satisfação do usuário,

mais provável será que este classifique o produto como confiável e de boa qualidade. Esta visão

também é compartilhada pela ISO, através do padrão 8402 [ISO86], que define a qualidade de

uma entidade (processo, produto ou organização) como a totalidade de características daquela

entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. Tal

definição estará fundamentada nas características do produto se as necessidades dos usuários

forem bem definidas e comuns. Entretanto, partindo do princípio que grupos diferentes de usuários

têm necessidades diferentes, então a qualidade do produto para cada grupo estará associada a

características diferentes. Deste modo, a qualidade do produto, sob o ponto de vista do ISO 8402

torna-se dependente da percepção do usuário.

De um modo abrangente, as organizações nacionais e internacionais de padronização têm

associado o termo qualidade de produtos (que dá margem à inclusão de produtos de software) ao

atendimento de necessidades ou expectativas. O padrão IEEE 10.12–1990 [IEEE90b] define

qualidade de dois modos, a saber: (1) grau segundo o qual um sistema, componente ou processo

satisfaz as exigências especificadas; e (2) grau segundo o qual um sistema, componente ou

processo satisfaz o cliente ou as necessidades ou expectativas do usuário.

Para o termo qualidade de software, a definição do padrão IEEE 1061–1992 [IEEE92] diz

ser o grau segundo o qual o software possui uma combinação desejada de atributos. O padrão ISO

9000 [ISO87] diz respeito à garantia da qualidade de um produto sob o ponto de vista do

preenchimento de um conjunto de requisitos pré-definidos. Segundo Bevan [Beva97], uma

interpretação literal deste ponto de vista torna a qualidade de um produto dependente do

profissional ou da equipe que especifica os requisitos. Dito de outro modo, um produto pode ser

julgado como sendo de boa qualidade mesmo se a especificação dos requisitos não for apropriada

a um dos contextos de uso para o qual foi desenvolvido.

Pressman [Pres95] não define qualidade de software. No entanto, o autor se refere ao

termo como a conformação de todo produto de software profissionalmente desenvolvido a (i)

requisitos funcionais e de desempenho explicitamente declarados, (ii) padrões de

desenvolvimento claramente documentados e (iii) características implícitas almejadas (e.g.,

um elevado nível de portabilidade). O autor acrescenta que a qualidade de software é uma

combinação complexa de fatores, também denominados indicadores de qualidade, que variam

conforme as aplicações consideradas e os clientes que a solicitam.

Nos últimos 25 anos, têm-se concebido e proposto diversos modelos de qualidade

de software que focalizam diferentes características do produto, às quais se tem associado

uma série de fatores de qualidade. Tais modelos têm servido de suporte à compreensão

de como os indicadores da qualidade de um produto se interrelacionam e às

características consideradas, de modo a tornar praticável sua mensuração [Kitc96]. Dentre

os modelos que têm sido propostos, podem ser mencionados o SQM (Software Quality

Metrics) [McCa77, Boeh78], o modelo de Gilb [Gilb87] e o GQM (Goal Question Metric)

[Basi88].


34

2.1.2 Facetas da Qualidade de Software

McCall et al. [McCa77] propuseram um dos primeiros modelos de qualidade de software,

denominado 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.

Fig. 2 – Fatores de qualidade de software definidos por McCall et al. [McCa77].

Os fatores de qualidade de software do SQM focalizam três aspectos relevantes de

um produto de software – características operacionais, capacidade de revisão e capacidade

de adaptação a novos ambientes (Fig. 2).

Cada fator de qualidade representa uma característica comportamental do

produto. Cada critério de qualidade é um atributo do fator de qualidade relacionado

com o projeto e com a produção do software considerado. Cada métrica de qualidade é

uma medida associada a algum aspecto de um critério de qualidade. Uma ou mais

métricas de qualidade poderão estar associadas a cada critério de qualidade. As setas da

Fig. 3 indicam quais dos critérios pré-definidos exercem influência sobre cada um dos

fatores de qualidade contemplados no modelo.


35

Fig. 3 – Critérios e fatores do modelo SQM [McCa77].

(Reusability)

(Correctness)

(Confiability)

(Efficiency)

(Flexibility)

(Integrity)

(Interoperability)

(Maintainability)

(Portability)

(Testability)

(Usability) (Machine Independence)

(Instrumentation)

(Conciseness)

(Communications Commonality)

(Data Commonality)

(Simplicity)

(Access Control)

(Audit Control)

(Generality)

(Modularity)

(Expandability)

(Operability)

(Training)

(Comunicativeness)

(Software-system Independence)

(Traceability)

(Completeness)

(Consistency)

(Accuracy)

(Error Tolerance)

(Execution Efficiency)

(Storage Efficiency)

(Self-descriptiveness)


36

O padrão IS09126 – Software product evaluation – Quality characteristics and

guidelines for their use [ISO92] recomenda a composição de um conjunto básico de seis

características independentes para a descrição da qualidade de um produto, com um mínimo de

superposição de atributos, as quais constituem o alicerce para posterior otimização da qualidade

de software. A Fig. 4 ilustra o refinamento dessas características em sub-características.

Fig. 4 – Características e sub-características do modelo contido no padrão ISO 9126 [ISO92].

(Portability)

(Maintainability)

(Functionality)

(Efficiency)

(Confiability)

(Usability)

(Maturity)

(Fault Tolerance)

(Recoverability)

(Time Behaviour)

(Resources Behaviour)

(Suitability)

(Accuracy)

(Security)

(Interoperability)

(Changeability)

(Analyzability)

(Stability)

(Testability)

(Replaceability)

(Adaptability)

(Installability)

(Conformance)

(Understandability)

(Learnability)

(Operability)


37

O Quadro 6 apresenta as definições das características do ISO 9126, cujo

equivalente brasileiro é a norma da ABNT NBR13596, que aponta igualmente para as

mesmas características de qualidade de software descritas no Quadro 6.

Quadro 6 – Características de qualidade de software do modelo apresentado

no documento do padrão ISO 9126 [ISO92].

(Reliability)

Conjunto de atributos relacionados com a capacidade de

manutenção do grau de desempenho do produto sob

condições pré-estabelecidas, por um período de tempo

pré-fixado.

(Efficiency)

Conjunto de atributos vinculados à relação entre o

desempenho do produto e a quantidade de recursos

empregados, sob condições pré-estabelecidas.

(Functionality)

Conjunto de atributos que implicam a existência de um

conjunto de funções e propriedades correspondentes, cada

função satisfazendo necessidades pré-estabelecidas ou

subentendidas.

(Maintainability)

Conjunto de atributos associados ao esforço necessário para

a realização de alterações especificadas, incluindo desde

correções, otimizações ou adaptações do produto até

alterações de ambiente ou de requisitos e especificações

funcionais.

(Portability)

Conjunto de atributos associados à capacidade de migração

do produto de um ambiente para outro, considerando-se os

contextos organizacional e computacional (hardware e

software básico)

(Usability)

Conjunto de atributos relativos ao esforço associado ao uso

do produto e à avaliação de tal uso por um universo pré-

estabelecido ou subentendido de usuários.

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 sub-características. No entanto, não apresenta diretrizes para a

implementação de um bom sistema de prognósticos.

Tervonen [Terv96] descreveu um modelo de qualidade de software

fundamentado no modelo SQM e no padrão ISO 9126, denominado Síntese do SQM

(SQM-synthesis model). A Fig. 5 mostra uma representação gráfica dos critérios e fatores

do modelo concebido por Tervonen [Terv96], ilustrando também a correspondência dos

critérios da Síntese do SQM ou modelo GRCM (Goal-Rule-Checklist-Metric) com as

características do padrão ISO 9126.


38

Fig. 5 – Critérios e fatores do modelo Sintese do SQM (ou GRCM) [Terv96] e comparação

dos critérios do GRCM com as características do padrão ISO 9126 [ISO92].

(Usability)

(Verifiability)

(Reliability)

(Functionality)

(Maintainability)

(Efficiency)

(Portability)

(Reliability)

(Efficiency)

(Correctness)

(Integrity)

(Interoperability)

(Expandability)

(Maintainability)

(Portability)

(Usability)

(Reusability)

(Nondeficiency)

(Fault Tolerance)

(Availability)

(Likeability)

(Completeness)

(Time Behavior)

(Resource Behavior)

(Audability)

(Survivability)

(Security)

(Compliance)

(Consistency)

(Modularity)

(Readability)

(Instability)

(Generality)

(Maturity)

(Upgradeability)

(Simplicility)

(Stability)

(Conciseness)

(Traceability)

(Adaptability)

(Replaceability)

(Conformance)

(Learnability)

(Ease of Use)

(Usefulness)

(Operability)


39

Os modelos SQM [McCa77, Boeh78] e IS09126 [ISO92] diferem basicamente em dois

aspectos: (i) a terminologia em geral; e (ii) a estruturação dos "indicadores" de qualidade,

totalmente hierárquica no padrão ISO (cada sub-característica se relaciona com uma única

característica). Além do mais, as sub-características estão relacionadas com aspectos de

qualidade visíveis ao usuário e não a propriedades internas ao produto analisado.

Modelos como o SQM [McCa77, Boeh78] e o GQM [Basi88, Basi94a] e padrões como o

IS09126 [ISO92] estabelecem uma terminologia para a qualidade de software, embora tendam 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 avaliatório, bem como o emprego inadequado e

inconsistente de termos de qualidade por projetistas e avaliadores [Terv96].

O GRCM (Goal-Rule-Checklist-Metric), como o autor o denomina, 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. A terminologia e o

vocabulário das regras deve ser adequado 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).

Dromey [Drom96, Kitc96] desenvolveu uma abordagem que tenta compensar problemas

inerentes ao SQM e ao padrão IS09126, no tocante à carência de base lógica, visando a

determinação de quais os fatores que deverão ser incluídos na definição de qualidade de um

produto específico, assim como a identificação de quais os critérios específicos que estão

relacionados a cada fator selecionado.

2.1.3 Qualidade de Software e Satisfação do Usuário

Os usuários tendem a avaliar a qualidade de ferramentas de software em termos de sua interação

com o produto final [Kitc96]. Um dos estimadores do grau de interação usuário-produto,

freqüentemente adotado nos últimos 25 anos, tem sido a satisfação (subjetiva) do usuário, que

vem despertando um interesse cada vez maior de pesquisadores de processos interativos usuário-

computador. Além do mais, o fato de vir sendo empregado como fator avaliatório do sucesso de

processos interativos e do desempenho de sistemas de informação [Meln72] possui uma

explicação bastante convincente: o efeito de um bom projeto de interface usuário-computador, que

implica estratégias de comunicação bem estruturadas, se traduz tanto no aumento da

produtividade do processo interativo [Bail83] quanto na satisfação do usuário e na facilidade de

exploração do potencial global do sistema [Neel90].

A satisfação do usuário, por sua vez, associada à idéia de quão aprazível seja o uso do

sistema [Niel93c], se encontra fortemente atrelada à sua concepção e à avaliação da natureza da

aplicação, bem como da interface de comunicação usuário-aplicação; em suma, está intimamente

ligada à natureza do produto considerado. Assim, atributos de um produto que contribuem para a

satisfação do usuário são um misto de requisitos funcionais (ausência ou presença de funções de


40

seu interesse) e não-funcionais (qualidade), assim como das limitações do produto (i.e., fatores

determinantes de sua aplicabilidade) [Ride91, Kitc96, Kust97]. A distinção entre requisitos

funcionais e não-funcionais também é expressa por outros pesquisadores da área, dentre os quais

vale a pena mencionar Boehm et al. [Boeh78], Cavano e McCall [Cava78], Deutsch e Willis

[Deut87], Bemelmans [Beme91] e Delen e Rijsenbrij [Dele92]. Além do mais, o nível de confiança e

satisfação do usuário relativo ao uso de um produto depende da atenção dada à maturidade de tal

produto, bem como da organização que o desenvolveu, tanto de uma perspectiva externa quanto

do ponto de vista dos processos internos de desenvolvimento [Curt93].

Cyert e March ([Cyer63], in Bailey [Bail83]) argumentaram que o quotidiano de um usuário

de sistemas computacionais impunha uma necessidade de informação que poderia ser atendida ou

frustrada conforme as características apresentadas pelo produto em uso. Dez anos depois, Powers

e Dickens [Powe73] concluíram, em seu artigo, que o sucesso ou o fracasso de um produto de

software e, por conseguinte, do uso de um sistema computacional, era ditado sobretudo pela

satisfação do usuário. Swanson [Swan74] determinou uma estreita correlação entre a apreciação

dos usuários por um produto e a eficiência dos resultados desse produto.

Lucas [Luca75] mostrou uma relação intima entre o desempenho econômico de uma

equipe de vendas e o sistema de informação por esta usado. Evans ([Evan76] in [Bail83]) sugeriu a

existência de um limite abaixo do qual o usuário evitaria qualquer tipo de interação com o sistema,

buscando outras estratégias alternativas de aquisição da informação de interesse. Newman e

Segev [Newm80] estudaram o grau de correlação existente entre a reação dos usuários de uma

filial bancária a aspectos relativos à satisfação e seu desempenho na organização. Penniman e

Dominick [Penn80] sumariaram em um quadro de estudos de coleta de informações para avaliação

da atitude e comportamento do usuário de sistemas de informação, relacionando estratégias

adotadas, trabalhos associados e comentários pertinentes sobre cada estratégia analisada.

Em suma, apesar de nos últimos vinte anos diversos pesquisadores terem investigado a

influência da satisfação do usuário na qualidade de produtos interativos, o que se apreende numa

leitura revisiva da área é que, na maioria dos casos, não existe um estimador de satisfação que

abranja todos os aspectos subjetivos envolvidos pelo contexto, embora se constate em todos eles

que o grau de satisfação com relação a um determinado produto apresenta, de algum modo, uma

correlação com o sucesso do processo interativo. A visão do usuário, além de relacionar a

qualidade de um produto à confiabilidade por ele apresentada, vincula a conotação do termo à

usabilidade do produto, sobretudo no que diz respeito à facilidade de instalação, de aprendizado e

de uso [Kitc96].

Numa perspectiva de usabilidade, há duas categorias possíveis de estratégias de estudo

da relação qualidade de software x satisfação do usuário: (i) indiretas, que não estudam

propriamente o produto e, por conseguinte, sua interface de usuário, mas apenas as opiniões

globais de um universo amostral de usuários sobre o produto em questão; e (ii) diretas, que visam

avaliar a satisfação do usuário mediante a seleção de atributos adequados ao contexto [Niel93c].

O desenvolvimento de software e o projeto de interfaces de usuário, assim como sua

supervisão e avaliação, em termos de qualidade, se inserem em um domínio mais abrangente, em

que projetos e produtos compartilham de características comuns, compondo famílias, atualizadas

numa progressão de versões ao longo do tempo. Decisões de projeto tomadas para versões


41

anteriores provocam efeitos residuais em versões subseqüentes, assim como na concepção de

novos produtos derivados. É nesse contexto que se insere uma área cujo ciclo de vida22 se estende

além do ciclo de vida de qualquer produto, visto que o impacto de suas decisões se projeta na

produção futura e nos ciclos de vida dos produtos subseqüentes: a Engenharia da Usabilidade

[Niel92a].

2.2 Engenharia, Engenharia de Software e Engenharia da

Usabilidade

Antes de chegar ao cerne do assunto tratado ao longo deste capítulo, cujos propósitos

fundamentais são a discussão da relevância da usabilidade como atributo associado à qualidade

de software, vale a pena tentar esclarecer um ponto de vista deixado em aberto no capítulo

introdutório deste documento – a adequação e a pertinência do uso dos termos engenharia de

software e engenharia da usabilidade.

Sem a pretensão de ser original nem de esgotar a discussão dos termos, que per si já

constituem temas polêmicos de discussão (às vezes, acirrada) entre os puristas, esta seção

deverá ser encarada apenas como um exercício de raciocínio, pertinente ao contexto no qual se

insere o tema desta pesquisa, onde se busca apenas esclarecer as conotações em que os termos

em questão são empregados neste documento.

2.2.1 Engenharia

Segundo Leite [Leit99], a construção de um artefato pode ocorrer artesanalmente, a

partir de processos de tentativa-e-erro, através dos quais se manipula diretamente a

matéria-prima com a qual o produto será gerado. Leite [Leit99] acrescenta que os

processos de construção artesanal podem evoluir, à medida que incorporam ferramentas

específicas e técnicas concebidas e validadas em experiências precedentes.

Tendo em vista que o ato de avaliar é inerente aos seres humanos, conforme

discutido no capítulo anterior, a inspeção e identificação de erros e/ou falhas e a

verificação da adequação do funcionamento e da utilidade do artefato ocorrerão cedo

(durante o desenvolvimento) ou tarde (após o desenvolvimento). A incorporação de

ferramentas e técnicas ao desenvolvimento de artefatos facilita o acompanhamento e a

análise do processo e, usualmente, conduz a reflexões sobre a atividade anterior: o projeto

do artefato. A integração da atividade de projeto ao desenvolvimento de artefatos implica

outra etapa de evolução do processo, pois possibilita a visualização do artefato antes

mesmo de sua existência enquanto produto, permitindo estender o raio de ação das

atividades avaliatórias.

Além disto, os artefatos são desenvolvidos, via de regra, mediante o surgimento de

necessidades. Por sua vez, a satisfação de necessidades implica o preenchimento de

requisitos. Assim, a incorporação da atividade de projeto ao desenvolvimento de artefatos

normalmente aponta para a necessidade de inclusão de outra atividade: a análise de

22 Segundo o padrão 100-1988 do IEEE, o termo refere-se ao período compreendido desde a concepção de um produto

até sua retirada do mercado consumidor.


42

requisitos. Esta atividade deve anteceder o projeto e o desenvolvimento do artefato, a fim

de que os objetivos almejados sejam atingidos.

Evidentemente, a evolução do processo de construção de artefatos, traduzida pela

incorporação e ordenação de várias atividades, fatalmente atinge um grau de complexidade que

suscita a proposição de modelos do processo, através dos quais se pode descrever

adequadamente o momento em que cada atividade (análise, especificação, projeto,

implementação e avaliação) deverá ser executada. A modelagem do processo estabelece

procedimentos metodológicos que descrevem detalhadamente o modo como cada atividade será

realizada.

A evolução citada também requer a especialização dos executores de cada atividade

pertinente ao seu contexto, exigindo-lhes o conhecimento de um conjunto de princípios e modelos

teóricos para o desempenho adequado de suas atribuições. Especialistas em diferentes atividades

devem ser agrupados em equipes, lideradas por um gerente, o que exige a análise da estruturação

e das estratégias de gestão das atividades relativas ao processo.

Como cada indivíduo representa um papel no modelo de desenvolvimento adotado,

também surge a necessidade da divisão coerente das atribuições conferidas a cada um

deles ao longo do tempo, ou seja, é necessário o planejamento das tarefas a serem

executadas em cada etapa do processo de construção de artefatos. Tendo em vista que

todas estas atividades demandarão recursos humanos, físicos, materiais e econômicos, o

planejamento deverá incorporar orçamentos de custos, assim como estimativas de prazos

para a execução de cada uma das etapas do processo. Afinal de contas, o cliente sem

dúvida exigirá uma previsão ou mesmo estipulará um prazo para a entrega do artefato

encomendado. Mais uma vez entram em cena os gerentes do processo, a fim de que os

recursos sejam bem empregados e os prazos cumpridos.

Quando o desenvolvimento de um artefato incorpora as atividades de análise,

projeto, implementação e avaliação, regidas por princípios, modelos, técnicas, ferramentas e

métodos específicos e realizadas por equipes de especialistas de acordo com um

planejamento que inclui a gestão de orçamentos de custos e estimativas de prazos em

todas as etapas do desenvolvimento, pode-se caracterizá-lo como uma engenharia [Leit99].

Vale a pena mencionar que o termo engenharia deriva-se do latim ingenerare, que

significa “conceber, planejar, criar, construir”, por sua vez derivado da palavra ingenium,

que significa “talento, inteligência”, mas também “artefato”.

Segundo o Engineers Council for Professional Development 23 dos EUA, engenharia é a

aplicação criativa de princípios científicos (i) no projeto e desenvolvimento de estruturas, máquinas,

equipamentos, processos de manufatura ou produtos que os utilize separada ou conjuntamente; ou

(ii) na construção ou operação dos mesmos com pleno conhecimento de seu projeto; ou (iii) na

previsão de comportamento dos mesmos sob condições específicas de operação, em qualquer um

dos casos com uma função planejada, visando economia na operação e segurança para a vida e a

propriedade [EB99].

23 Conselho de Engenheiros para o Desenvolvimento Profissional.


43

2.2.2 Engenharia de Software

Resta então refletir sobre os processos correntes de desenvolvimento de software

se enquadram ou não, parcial ou totalmente, nesta definição, o que respaldaria o uso do

termo engenharia de software. Obviamente se questionará a maturidade de tais processos

e, implicitamente, os princípios, métodos e modelos teóricos nos quais se fundamentam.

Todavia, é importante não esquecer que vários ramos da engenharia também já estiveram

no nível em que se encontra atualmente a área de desenvolvimento de artefatos de

software, sem contudo deixarem de ser considerados engenharias.

Baber [Babe97] afirma que o desenvolvimento de software atual se encontra, em

muitos aspectos, em uma fase de pré-engenharia, análoga àquela pela qual passaram

outros ramos da engenharia tradicional. O autor comenta que na segunda metade do

século XIX o campo de tecnologia elétrica, em particular a telegrafia e a telefonia,

apresentava problemas análogos àqueles registrados nos processos de desenvolvimento de

software passados e atuais, acrescentando que falhas consideráveis também já foram lugar

comum em muitas outras áreas da engenharia tradicional, e.g., desmoronamento de pontes

sob o peso de locomotivas e afundamento de navios por conta da instabilidade dos

projetos de seus cascos.

No tocante à telegrafia e telefonia antes e durante a virada do século XIX, Baber

[Babe97] comenta que vários fenômenos ainda confundiam os projetistas e limitavam os

avanços da Engenharia Elétrica, aos quais se somavam perdas econômicas consideráveis,

por conta da compreensão ainda insuficiente de diversos aspectos técnicos relevantes dos

sistemas em questão, e.g., a destruição do primeiro cabo transatlântico satisfatoriamente

instalado, em 1858; a condução de experimentos onerosos, freqüentemente com resultados

inconclusivos, em tentativas para entender fenômenos como o efeito das variações de

velocidades de transmissão em circuitos telegráficos bidirecionais e a distorção de sinais de

voz em linhas de transmissão.

Baber [Babe97] ainda menciona as iniciativas teóricas de Oliver Heaviside, que

solucionou muitos destes problemas através de análises e do uso de lápis e papel, vários

anos antes de suas soluções terem sido aceitas e postas em prática pelos “homens da

prática”, aos olhos dos quais teorias eram consideradas inúteis e, até mesmo, absurdas.

Uma delas foi a teoria de Maxwell, que postulava a auto-propagação das ondas

eletromagnéticas, questionada como algo que ninguém jamais observara e, evidentemente,

jamais observaria, imagine pensar em fazer uso prático dela! Alguns anos mais tarde,

Hertz observaria tal fenômeno, fundamentado por considerações teóricas que lhe nortearam

no tocante ao que e como investigar. Alguns décadas depois, estas ondas estariam sendo

empregadas em comunicações transatlânticas comercialmente viáveis.

A discussão de Baber apenas evidencia a constatação (intuitiva) de que os fatores

essenciais responsáveis pela diferença significativa existente entre a precisão dos processos

de projeto de ontem e de hoje nos ramos tradicionais da engenharia são (i) a

fundamentação científica e matemática sedimentada ao longo de décadas, (ii) a aplicação

regular e “natural” desses fundamentos no dia-a-dia e (iii) a capacidade de previsão que


44

incrementa atualmente a facilidade de descrição dos modelos segundo os quais os

artefatos são construídos.

No caso das engenharias civil e mecânica, a fundamentação científica e matemática

anteriormente mencionada é fornecida pelas leis de Newton, enquanto que as leis de Maxwell

fundamentam a engenharia elétrica). Baber [Babe97] argumenta que uma fundamentação análoga

para o desenvolvimento de software pode ser encontrada nos estudos de Floyd, Hoare, Dijkstra e

outros, embora não tenha ainda um uso amplamente difundido na prática, tendo em vista que esta

área do conhecimento ainda vive seus dias de “pré-engenharia”, embora usando explicitamente

como modelo práticas atuais da engenharia tradicional.

Neste ponto, são acrescentadas algumas definições de autores da área e instituições

responsáveis pela padronização de software, com o propósito de enriquecer a reflexão sobre o

assunto. Bauer [Baue72] define engenharia de software como o estabelecimento e uso de

princípios consagrados de engenharia para a produção economicamente viável de software de

qualidade que funcione em máquinas reais.

Na concepção de Fairley [Fair85], engenharia de software é um ramo tecnológico e

gerencial do conhecimento concernente à produção e manutenção sistemática de produtos de

software que são progressivamente desenvolvidos e modificados, dentro de estimativas de prazos

e custos.

Macro e Buxton [Macr87] referem-se à engenharia de software como o estabelecimento e

uso de princípios consagrados de engenharia e de práticas de gestão apropriadas, associados à

evolução de ferramentas e métodos aplicáveis e ao uso apropriado dessas ferramentas para a

obtenção de produtos de software de alta qualidade - no sentido mais explícito, dentro de

limitações de recursos conhecidas e adequadas.

O IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer

Glossaries [IEEE90a] e o padrão IEEE 10.12–1990 [IEEE90b] definem igualmente o termo

engenharia de software como: (1) a aplicação de uma abordagem sistemática, disciplinada

e quantificável no desenvolvimento, operação e manutenção de produtos de software, isto

é, a aplicação da engenharia ao software; e (2) o estudo de abordagens como aquelas

definidas em (1).

O SEI Report on Undergraduate Software Engineering Education de 1990 [Ford90]

diz que enquanto a engenharia é a aplicação sistemática do conhecimento científico para a

criação e construção de soluções econômicas para problemas práticos da humanidade, a

engenharia de software é o ramo da engenharia que aplica os princípios da ciência da

computação e da matemática para obter soluções economicamente viáveis para problemas

de software.

Engenharia de software é definida na Webopedia [Web00] como o ramo da ciência

da computação concernente ao desenvolvimento de aplicações complexas, abrangendo não

só os aspectos técnicos de implementação, mas também questões de gestão, tais como a

supervisão de equipes de programação, o planejamento e o orçamento de sistemas de

software.


45

No tocante aos livros de Engenharia de Software, embora tendam a não

apresentarem definições, dedicam seus capítulos introdutórios à explanação de

características da área, com comentários que sugerem esboços de definições. Pfleeger

[Pfle91] comenta que a engenharia de software lida com o projeto e desenvolvimento de

produtos de software de alta qualidade, sendo responsável pela aplicação de técnicas da

ciência da computação na solução de uma ampla variedade de problemas.

Schach [Scha93], por outro lado, afirma que a engenharia de software é uma área

cujo objetivo é a produção de software de qualidade com prazos e orçamentos pré-

definidos que satisfaça às necessidades dos usuários.

Segundo Sommerville [Somm97] engenharia de software trata da especificação, do

desenvolvimento, da gestão e da evolução de sistemas de software, elaborando teorias e

concebendo métodos e ferramentas aplicáveis ao desenvolvimento de produtos de software.

O autor acrescenta que embora não lidando com materiais regidos por leis físicas ou

processos de manufatura, como outros ramos da engenharia, a engenharia de software se

insere no contexto da engenharia por lidar com o desenvolvimento de modelos do mundo

real.

Gisselquist [Giss98] afirma que desenvolvimento de software é engenharia,

estabelecendo um rápido, mas não menos interessante, paralelo entre as atividades de

gestão, projeto e implementação de produtos nas áreas de desenvolvimento de software e

de edificações.

Enfim, Mayhew [Mayh99] define engenharia de software como um ramo da

engenharia relativo ao desenvolvimento de software que envolve a definição de requisitos

das aplicações, o estabelecimento de metas e atividades de projeto e avaliação em ciclos

iterativos até que as metas tenham sido atingidas.

2.2.3 Engenharia da Usabilidade

No contexto mais abrangente dos processos de desenvolvimento de produtos, não

apenas de software, mas de naturezas as mais diversas, a importância crescente do fator

qualidade nas iniciativas de quantificação tanto do processo quanto do produto tem

estimulado a emergência de um novo campo de estudo, referido na literatura de língua

inglesa como quality engineering (engenharia da qualidade). Em nível da qualidade de

software, a usabilidade tem se tornado uma necessidade competitiva para o sucesso

comercial dos produtos de software, além de vir sendo incorporado cada vez mais

efetivamente nos processos de desenvolvimento, com o propósito de otimizar os produtos

através da otimização dos processos através dos quais são desenvolvidos [Butl96a].

Uma década e meia de amadurecimento e sistematização do estudo da usabilidade

como atributo decisivo para a aceitação de produtos pelo mercado consumidor resultou no

surgimento de uma nova área de investigação, que busca direcionar o processo de

desenvolvimento de software para a usabilidade dos produtos finais, tanto em nível do

processo quanto do produto gerado: a engenharia da usabilidade.


46

Os estudos de Gilb [Gilb84], Shackel [Shac84], Bennett [Benn84, Benn86], Carroll e

Rosson [Carr85a] e Butler [Butl85] apresentam uma abordagem de usabilidade unificada,

posteriormente denominada engenharia da usabilidade por Good et al. [Good86], que a definiram

como um processo fundamentado na engenharia clássica relativo à especificação, quantitativa e

antecipadamente, de quais as características e em que proporções produtos a serem

desenvolvidos deverão apresentar. Segundo Good et al. [Good86], sem tal especificação não há

outro modo de determinar as necessidades de usabilidade de um produto ou de verificar

(qualitativa e quantitativa) se tal produto satisfaz ou não tais necessidades.

A partir desta definição, Good et al. [Good86] deixam explícito que a engenharia da

usabilidade é uma abordagem empregada no desenvolvimento de software através da qual a

usabilidade de um produto é especificada em termos quantitativos e esta especificação antecede o

processo de desenvolvimento do produto. Esta definição também sugere a definição de metas

mensuráveis de usabilidade, sem as quais não é possível para o projetista ou o avaliador verificar

se o produto final atingiu um grau aceitável de usabilidade (caso atinja as metas pré-fixadas). Hix e

Hartson [Hix93] são consonantes com esta definição.

Tyldesley [Tyld88] define engenharia da usabilidade como um processo através do qual a

usabilidade de um produto é especificada quantitativamente, permitindo que se demonstre se um

produto final atinge ou não os níveis exigidos de usabilidade. Este processo inclui medidas

objetivas do processo interativo, definições de modelos de sistemas, do usuário e das interfaces,

bem como as interrelações destas entidades, técnicas de projeto cooperativo, técnicas de projeto

de interfaces gráficas (GUI), desenvolvimento de diretrizes de projeto, guias de estilo e padrões e

atividades de prototipagem [Butl96a].

Butler [Butl96a] comenta que Bennett [Benn84] foi um dos primeiros pesquisadores a

empregar o termo usability engineering, em meados da década de 80, acrescentando que, após

uma década e meia de estudos, a engenharia da usabilidade é área técnica que se dedica ao

estudo de aspectos referentes ao desenvolvimento de interfaces usuário-computador. Nos, dias

atuais, afirma Butler [Butl96a], o processo de desenvolvimento de interfaces é compreendido mais

facilmente, apre(e)ndido mais rapidamente e conduzido mais confiavelmente.

Para Lecerof e Paternò [Lece98], engenharia da usabilidade é uma área no domínio da

interação usuário-computador24 cuja meta fundamental é o desenvolvimento de sistemas usáveis a

partir da aplicação, de forma estruturada e sistemática, de diferentes métodos nos diferentes

estágios do projeto e do processo de desenvolvimento, assim como da integração de iniciativas de

avaliação da usabilidade desde os estágios iniciais do projeto.

Conforme Mayhew [Mayh99], engenharia da usabilidade é um processo através do qual

são aplicados métodos estruturados no projeto de interfaces usuário-computador visando a

usabilidade do produto final.

Como se pôde observar nestes últimos parágrafos, há cerca de quinze anos,

software “amigável" era, grosso modo, qualquer aplicação que interagisse com o usuário

através de uma interface de menu ou que fosse dotada de facilidades de recuperação de

24 Human-Computer Interaction (HCI).


47

erros. Nos dias atuais, a engenharia da usabilidade é uma área do conhecimento na qual

os pesquisadores e desenvolvedores procuram desenvolver e implementar técnicas que

sistematicamente tornem os produtos de software mais usáveis, otimizando o produto

através da otimização do processo.

Em resumo, além de um exercício de reflexão, esta seção teve o propósito de

apresentar diferentes definições encontradas na literatura da área para os termos

engenharia de software e engenharia da usabilidade, além de procurar esclarecer com que

conotação estes termos são empregados ao longo de todo o documento. Após ter

discutido diferentes conotações do termo usabilidade no capítulo introdutório e de ter

mencionado, nas duas últimas seções, a usabilidade como um critério relevante de

mensuração da qualidade dos produtos de software, torna-se conveniente aprofundar a

discussão da importância da usabilidade na aceitação de produtos pelos consumidores,

apresentando modelos concebidos nos últimos quinze anos para a mensuração da

usabilidade de produtos.

2.3 Usabilidade de Software

Os desenvolvedores de tecnologias bem consolidadas, tais como serviços postais, telefones e

televisão alcançaram a meta da usabilidade universal [Shne00]. No entanto, a tecnologia

computacional ainda é muito difícil de usar (ou quase inacessível) para muitos indivíduos [Shne98].

Shneiderman [Shne00] cita que em uma pesquisa realizada em um universo amostral de 6.000

usuários de sistemas computacionais verificou-se uma média 5,1 horas por semana despendidas

na tentativa de usar computadores, concluindo que se passa mais tempo diante de sistemas

computacionais do que ao volante de um automóvel.

Atualmente, as interfaces usuário-computador são entidades muito mais significativas

do que costumavam ser há pouco mais de duas décadas, graças à revolução dos

computadores pessoais e a redução dos custos do hardware que, de um modo geral, vêm

tornando os sistemas computacionais mais acessíveis a um número cada vez maior de

usuários de áreas de concentração as mais variadas [Hart90, Niel93c, Mand97, Hack98].

Apesar disto, segundo Shneiderman [Shne00], a frustração e a ansiedade dos usuários de

sistemas computacionais continua crescendo, enquanto o número de não usuários ainda

permanece elevado. O autor acrescenta que embora o barateamento dos custos do

hardware, do software e das redes computacionais prometa fazer muitos novos usuários, a

otimização do projeto da interface e do processamento da informação são cruciais para

que se atinja graus mais elevados de sucesso.

A diversificação do universo usuário, que implica, sem dúvida, a multiplicidade das

tarefas executadas com o auxílio de sistemas de informação automatizados, vem se aliar

aos progressos alcançados pela ergonomia e pela engenharia da usabilidade, bem como a

oferta de uma diversidade cada vez maior de ferramentas de desenvolvimento e validação

de projetos de interfaces. Tais fatores vêm alterando cada vez mais profundamente os

rumos da especificação e implementação de interfaces [Laws78] e, por extensão, os

alicerces que fundamentam as estratégias avaliatórias destas entidades [Niel89a, Niel89b,

Niel90, Kara92, Niel93c, Niel94a, Dix98].


48

Ao longo das duas últimas décadas, a usabilidade vem sendo cada vez mais considerada

como fator [McCa77], característica [ISO92] ou critério [Terv96] de qualidade de software. Como se

pôde observar na sub-seção 2.1.1, a usabilidade figura como uma das componentes de cada

modelo de qualidade de software apresentado (SQM, ISO9126 e GRCM), por sua vez associada a

conjuntos de atributos através dos quais pode ser mensurada. Vale a pena revisitar as Figs. 3, 4 e

5 e observar o Quadro 7, que sintetiza os atributos da usabilidade de software considerados nos

modelos de McCall et al. [McCa77], ISO9126 [ISO92] e Tervonen [Terv96].

Quadro 7 – Comparação dos atributos de usabilidade considerados

no SQM [McCa77], ISO9126 [ISO92] e GRCM [Terv96].

ATRIBUTO DE USABILIDADE SQM

[McCa77] ISO9126 [ISO92]

GRCM [Terv96]

FACILIDADE DE OPERAÇÃO

(Operability) CAPACIDADE DE TREINAMENTO

(Training) FACILIDADE DE COMUNICAÇÃO

(Communicativeness) COMPREENSIBILIDADE

(Comprehensibility) FACILIDADE DE APRENDIZADO

(Learnability) FACILIDADE DE USO

(Ease of Use) APLICABILIDADE

(Usefulness) CONFORMIDADE

(Conformance)

Uma análise do Quadro 7 mostra que dos oito atributos de usabilidade considerados nos

modelos apresentados na sub-seção 2.1.1 apenas um é compartilhado, a facilidade de operação

(operability). A facilidade de aprendizado (learnability) aparece em segundo lugar, em termos de

atributos compartilhados, já que figura apenas nos modelos do ISO9126 [ISO92] e GRCM [Terv96].

Os demais atributos de usabilidade figuram em apenas um dos modelos analisados. 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.

Independentemente de quais atributos tenham sido associados à usabilidade nos modelos

de qualidade desenvolvidos até então e da indicação (ou da ausência dela) fornecida por seus

conceptores de como mensurar a usabilidade a partir desses atributos, tanto Foley e Van Dam

[Fole82] quanto Sulaiman [Sula96] ressaltam que a importância da usabilidade de diversas

categorias de sistemas se equipara à funcionalidade deles exigida. Percebe-se, de fato, que nos

últimos vinte anos tem-se tentado encorajar os desenvolvedores de software a focalizarem a

usabilidade de seus produtos tanto quanto se focaliza a funcionalidade ao longo de todo o ciclo de

vida de desenvolvimento.


49

Há 14 anos, Goodwin [Good87] já argumentava que embora usabilidade não fosse

um conceito fácil, investir na usabilidade de produtos se afigurava tão importante quanto

investir em sua funcionalidade, reforçando que um sistema pouco usável custaria aos

usuários, na melhor das hipóteses, o dispêndio de tempo e esforço, enquanto na pior das

hipóteses simplesmente não seria usado, visto que a utilidade de suas funções não fora

demonstrada. Passada uma década, Sulaiman [Sula96] afirmou que as tentativas de

encorajamento haviam tido apenas um sucesso limitado, tendo em vista só haverem

atingido algumas companhias, sem alterar fundamentalmente o processo de

desenvolvimento de software como um todo.

Karat [Kara98] acrescenta que o perfil dos usuários de sistemas de hardware e

software tem mudado, enquanto os sistemas e a cultura de desenvolvimento não tem feito

as adaptações necessárias para atender a essas mudanças. Enquanto há uma década

apenas especialistas técnicos desenvolviam sistemas para uso próprio ou de outros

especialistas técnicos, hoje em dia tais sistemas são ferramentas praticamente onipresentes,

desenvolvidas para um segmento crescente de usuários principiantes. Esse contingente de

usuários dotados de habilidades e competências em domínios específicos e diversos

apresenta pouco ou nenhum interesse em como a tecnologia computacional funciona,

desejando apenas ferramentas confiáveis e fáceis de usar, que lhes auxiliem no trabalho

diário.

Sobre essas mudanças, Dray [Dray00] chama a atenção para quatro categorias

abrangentes de efeitos: (i) efeitos de crescimento da internacionalização da tecnologia; (ii) efeitos

da integração crescente da tecnologia; (iii) efeitos demográficos de uso da tecnologia; e (iv) efeitos

das mudanças na definição e “posse” do projeto de interfaces de usuário em organizações.

Na verdade, a importância da avaliação da usabilidade de produtos tem sido reconhecida e

registrada na literatura da área desde o início dos anos 70 [Mart73, Mill81, Shac90]. A pesquisa

sobre a mensuração da usabilidade não só tem contribuído para a elucidação de aspectos relativos

à usabilidade [Ride91, Niel94a], como também para a ampliação do grau de conscientização da

necessidade de sua integração ao ciclo de vida de desenvolvimento [Kara94b, Sula96, Mand97,

Henr98, Mayh99]. Um dos indicadores dessa tomada de consciência é o aumento dos

investimentos de muitas companhias de desenvolvimento de software em ambientes destinados à

avaliação da usabilidade de produtos, equipados com os mais modernos recursos para coleta e

análise de dados. Há também a elevação dos investimentos na formação de equipes

multidisciplinares de avaliação [Ehrl94b, Duma94, Levi96a]. Tais iniciativas também denotam, uma

tomada de consciência do fato de que, embora os ensaios de usabilidade não abranjam todos os

padrões de uso potencial e funcionalidades do produto analisado, as metas da engenharia da

usabilidade dirigem os esforços da equipe de projeto para o usuário e possibilitam a avaliação do

trabalho realizado durante o desenvolvimento do produto [Ride91].

O Quadro 8 apresenta alguns aspectos relativos a organizações que implantaram

programas de usabilidade no ciclo de desenvolvimento de seus produtos. Trata-se de uma

síntese dos estudos de Madsen [Mads99] e Borgholm e Madsen [Borg99], envolvendo

seis companhias, três americanas e três dinamarquesas, que adotaram práticas de

usabilidade no ciclo de desenvolvimento de seus produtos.


50

QQuuaaddrroo 88


51

Em contrapartida, o reconhecimento da importância da engenharia da usabilidade

pela maioria das organizações ainda não é bem definido, visto que muitas dessas

organizações ainda não conseguem mensurar, em termos financeiros, os benefícios

econômicos advindos da adoção de procedimentos e ensaios de usabilidade como

atividades diárias. Este quadro ainda é reforçado pelas dificuldades encontradas por muitos

profissionais como avaliadores de usabilidade para justificar, com argumentos concretos, os

custos conseqüentes de procedimentos que adotam [Kara93, Mayh94]. Acrescente-se a isto

o fato de que, mesmo reconhecendo a necessidade e a importância das práticas de

projeto centradas no usuário e dos programas de usabilidade adotados pelas grandes e

médias corporações de desenvolvimento de software, as pequenas organizações ainda

encaram tais estratégias como proibitivas, o que lhes impede a inclusão de ensaios de

usabilidade no ciclo de desenvolvimento de seus produtos [Rowl94, Brow98].

Neste sentido, diversos pesquisadores (e.g., Aykin [Ayki94], Cox et al. [Cox94],

Ehrlich e Rohn [Ehrl94b], Mayhew [Mayh94, Mayh99], têm demonstrado que os benefícios

advindos das estratégias de usabilidade por eles concebidas são compensadores face aos

custos associados. Karat [Kara93] descreveu procedimentos de análise de dados de dois

projetos, à luz de uma técnica simples de engenharia da usabilidade, que considera o

compromisso custos-benefícios. Nielsen [Niel93c] analisou aspectos envolvidos na

determinação de custos e benefícios, mostrando que a aplicação da engenharia da

usabilidade, em nível empresarial, constitui um bom empreendimento econômico. Rowley

[Rowl94] descreveu uma estratégia de planejamento de ensaios de usabilidade no campo

(in situ), aplicáveis por equipes de desenvolvimento de produtos de software a grupos

consumidores potenciais separados por grandes distâncias do ambiente de desenvolvimento

do produto.

Vários autores (e.g., Nielsen [Niel93b], Beyer e Holtzblatt [Beye94], Brun-Cottan

[Brun95], Dumais [Duma95], Stanney et al. [Stan97a], Henry [Henr98], Mayhew [Mayh99])

têm sugerido ações que traduzem esforços mais simples de condução de projetos

centrados no usuário e, por conseguinte, direcionados para a usabilidade do produto.

Dentre as ações mais simples desta natureza, podem ser citadas: (i) diálogos com

indivíduos da futura comunidade usuária de um sistema de informação computadorizado; (ii)

visitas aos ambientes de trabalho de usuários potenciais e observação/enumeração de

quais as atividades que desenvolvem no cotidiano e de como as realizam; (iii) identificação

de quais os principais problemas que os usuários potenciais enfrentam e como os

solucionam; e (iv) interação mais efetiva com comunidades de usuários potenciais visando

a sondagem de soluções mais adequadas de informatização das ferramentas que utilizam

em tarefas cotidianas.

Esta é a visão da usabilidade como abordagem de projeto. O processo de

desenvolvimento voltado para a usabilidade do produto é indispensável em abordagens de

projeto centrado no usuário ou projeto participativo, pois insere o usuário no contexto do

processo e atenua sua resistência a mudanças tecnológicas que venham a ocorrer em seu

ambiente de trabalho, familiarizando-o progressivamente com o produto desde a etapa de

análise dos requisitos. A principal limitação das abordagens centradas no usuário

reside na escolha de indivíduos representativos da comunidade usuária envolvida no


52

contexto do projeto, já que não é possível recrutar toda a comunidade. Deste

modo, do ponto de vista da maioria dos usuários, o processo de desenvolvimento da

interface é desconhecido, não influenciando portanto a formação de sua opinião sobre o

produto.

Conforme mencionado no capítulo inicial deste documento, a usabilidade é

multifacetada, podendo ser associada a diferentes atributos por indivíduos diferentes,

conforme se pôde constatar anteriormente através do estudo dos modelos de qualidade

apresentados. A usabilidade também pode ser encarada como abordagem de

projeto, atributo de um produto ou medida [Kein99]. Estas três visões apresentam

pontos em comum, como ocorre com as regiões de encontro das faces de um

poliedro.

Segundo Keinonen [Kein99], muitas organizações vêm passando cada vez mais a

encarar a usabilidade por como parte integrante do processo de desenvolvimento de

produtos, ao invés de conceber as atividades de avaliação como algo à parte, conduzido

por um departamento responsável pela inspeção dos produtos projetados e

implementados.

Tal postura tem facilitado a adoção de estratégias de avaliação fáceis de aplicar

desde as etapas iniciais do processo de desenvolvimento e capazes de produzir resultados

satisfatórios a partir dos recursos disponíveis (e.g., Discount usability engineering de

Nielsen [Niel95], Do-it-yourself usability evaluation de Botman [Botm96], Quick and dirty de

Thomas [Thom96]). Estas são estratégias que se adequam bem à abordagem integrada de

projetos, familiar aos projetistas industriais.

A visão da usabilidade como atributo de um produto está associada à

exemplificação de propriedades ou características de sistemas ou produtos intimamente

relacionadas com sua usabilidade. Tal visão é usualmente explicitada sob a forma de (i)

diretrizes de projeto25

; (ii) guias de estilo26

; (iii) padrões27

; e (iv) listas de princípios de

usabilidade28

. Documentos desta natureza são úteis tanto para propósitos de projeto quanto

de avaliação, pois apresentam recomendações, definições, diretivas ou normas de

propriedades de interfaces em nível genérico ou específico, aplicáveis a diferentes tipos de

produtos e contextos de uso. Sua utilização em nível da avaliação de interfaces usuário-

computador será explorada mais adiante, no próximo capítulo.

25 E.g., Shneiderman [Shne79, Shne82, Shne84, Shne87], Galitz [Gali85], Smith e Mosier [Smit86b], Dzida [Dzid89],

Grudin [Grud89, Grud90, Grud91], Mitchell e Shneiderman [Mitc89], Norcio e Stanley [Norc89], Nickerson e Pew

[Nick90], Tognazzini [Togn90], Jeffries et al. [Jeff91], Tetzlaff e Schwartz [Tetz91], Karat et al. [Kara92], Mayhew

[Mayh92], Gillan [Gill93], Gray [Gray93], Queiroz [Quei94], Cohen [Cohe95a], Cohen et al. [Cohe95b], Crow [Crow95],

Dilli e Hoffman [Dill95], Gorny [Gorn95], Iannella [lann95], Ogawa e Ueno [Ogaw95], Vanderdonckt [Vand95].

26 IBM [IBM91a, IBM91b], Apple [Appl92, Appl97], Microsoft [Micr95], Sun Microsystems [Sun99].

27 ISO [ISO97a, ISO97b, ISO98, ISO99].

28 Nielsen [Niel93b, Niel94a], Johnson [John96b].


53

Do ponto de vista do usuário, as únicas conseqüências cruciais desses princípios

são as características implementadas do produto. Obviamente os produtos adquiridos são

avaliados em termos das características apresentadas por suas interfaces, confirmando as

opiniões de Hix e Hartson [Hix93] (a interface é, para os usuários, “o sistema”) e Hackos

e Redish [Hack98] (a interface é o que os usuários vêem ao usar o produto e o meio

através do qual se comunicam com o produto ao usá-lo). Do ponto de vista do projetista

e/ou avaliador, as diretrizes de projeto, os guias de estilo, os padrões (corporativos,

nacionais ou internacionais) e as heurísticas são instrumentos eminentemente analíticos,

que objetivam em primeiro plano servir de respaldo às atividades de projeto ou de

inspeção da usabilidade de produtos.

O terceiro modo de enfocar a usabilidade – como medida - diz respeito à

mensuração do processo interativo homem-máquina como estratégia destinada à otimização

do processo de desenvolvimento ou do produto. Esta é a faceta visualizada na pesquisa

ora apresentada, conforme será visto nos próximos capítulos. Sob este ponto de vista, a

usabilidade é encarada de um modo que torna os resultados do processo de mensuração

o alvo da discussão, o que exige usualmente a adoção de uma abordagem

clássica de engenharia da usabilidade ou a proposição de uma nova abordagem para

usabilidade.

Shackel [Shac86, Shac91], Nielsen [Niel93b] e a Parte 11 do padrão ISO9241

[ISO98] empregaram abordagens que consideram questões sobre usabilidade em um nível

operacional, sobre objetivos de usabilidade e sobre a relação entre a usabilidade, a

utilidade, a aceitação de produtos e questões relativas ao processo interativo.

Segundo Shackel [Shac86], a qualidade de um sistema depende de como

este incorpore e combine vários critérios tradicionalmente vagos e não construtivos

no contexto de projeto e implementação. Por sua vez, a usabilidade é a "medida"

que traduz a concretização de metas especificadas por categorias de usuários interagindo

com ambientes específicos, sujeita a vários critérios de conforto, eficiência, eficácia e

aceitação. Embora esta definição sugira a quantificação da influência dos termos

empregados, tal iniciativa nem sempre constitui uma tarefa trivial ou de resultados

facilmente exprimíveis.

2.3.1 Visão de Shackel

A abordagem de Shackel [Shac86, Shac91] se encontra entre as primeiras a

reconhecerem o caráter relativo do conceito de usabilidade sob diversos aspectos,

tendo sido bastante adotada e modificada (e.g., vide Booth [Boot89], Chapanis

[Chap91]). Shackel [Shac86, Shac91] concebeu um modelo de percepção de

produtos fundamentado na aceitação (acceptance), seu conceito de nível mais

elevado.

Parte-se do pressuposto que o usuário (consumidor) confronta as propriedades

do produto com os esforços necessários para adquirí-lo. Caso decida comprá-lo,

a análise de custos-benefícios do processo de aquisição envolverá, de um lado,


54

a utilidade (utility), a usabilidade (usability) e a capacidade de agradar (likeability) de

um conjunto de produtos de interesse e, do outro, os custos (costs) associados, conforme

ilustra a Fig. 6. A melhor alternativa é selecionada, ou seja, aceita, o que torna a aceitação

dependente da utilidade, da usabilidade, da similaridade e dos custos do produto.

Fig. 6 – Aceitação do produto, conforme Shackel [Shac91], com destaque

para as dimensões e medidas concretas da usabilidade.

Enquanto a utilidade (utility) refere-se à confrontação das necessidades do usuário com a

funcionalidade do produto, a usabilidade (usability) diz respeito à facilidade de utilização prática da

funcionalidade do produto. Por sua vez, a capacidade de agradar (likeability) concerne a

avaliações subjetivas de cunho emocional/sentimental e os custos incluem tanto os encargos

econômicos quanto conseqüências sociais e organizacionais do processo de aquisição.

Shackel [Shac91] acrescenta que a usabilidade de um sistema ou equipamento é a

capacidade de ser usado fácil e efetivamente por um universo especificado de usuários, em termos

humanos funcionais, sendo dados treinamento e suporte especificados, de modo a completar um

conjunto especificado de tarefas em uma série de cenários ambientais especificados. Destaca-se

nesta definição outra mais sucinta - capacidade de ser usado fácil e efetivamente por seres

humanos, que se mostra apropriado do ponto de vista da avaliação do produto pelos

consumidores, já que o contexto de uso será determinado pela situação específica de cada

consumidor. Quanto aos advérbios associados ao modo de uso, facilmente refere-se a um

determinado nível de análise subjetiva, enquanto efetivamente diz respeito a um determinado nível

de desempenho humano.

Na concepção de Shackel, usabilidade é uma propriedade não constante de um sistema

ou equipamento e sua relatividade é função dos usuários, do treinamento e suporte que lhes foram


55

dados, das tarefas executadas e dos ambientes onde as tarefas foram concluídas. Dito de outro

modo, a usabilidade varia conforme o contexto considerado. Assim, um sistema ou um

equipamento será considerado usável se for capaz de atender a uma determinada combinação de

usuários, tarefas e ambientes. Deste ponto de vista, a usabilidade apresenta duas facetas: (i) uma

associada à percepção subjetiva do produto pelo usuário/consumidor; e (ii) outra relacionada à

mensuração objetiva do processo interativo usuário-produto.

Conforme mencionado anteriormente, Shackel apenas sugere os instrumentos, escalas ou

aspectos envolvidos no contexto da mensuração objetiva da usabilidade de um produto, não

fornecendo indicações sobre como conduzi-la. Ciente deste fato, Shackel sugere um conjunto de

critérios operacionais a serem satisfeitos em níveis pré-definidos a fim de que um sistema seja

considerado usável. As escalas sugeridas são apresentadas no Quadro 9.

Quadro 9 – Critérios sugeridos por Shackel [Shac91] para a usabilidade de um sistema.

Efetividade (Effectiveness)

Associada aos resultados da interação em termos de

rapidez (tempos) e erros.

Facilidade de Aprendizado

(Learnability)

Associada à relação entre o desempenho, a quantidade

de treinamento e a freqüência de uso, i.e., o tempo de

aprendizado dos usuários principiantes com um

determinado treinamento e retenção do aprendizado por

parte de usuários esporádicos.

Flexibilidade

(Flexibility)

Associada à possibilidade de adaptação a tarefas e

ambientes, além das duas escalas anteriores.

Atitude Mental e Comportamental (Attitude)

Associada a níveis aceitáveis de esforços humanos em

termos de fadiga, desconforto, frustração e empenho

pessoal.

A concepção de Shackel associa a usabilidade a outros atributos do produto e conceitos

de nível mais alto, fornecendo uma definição descritiva do conceito. Direcionada para o contexto

complexo de avaliação, sugere critérios de usabilidade concretos e mensuráveis, conforme se

pode observar na Fig. 6.

2.3.2 Visão de Nielsen

Nielsen [Niel93b] parte do princípio que, dado um sistema socialmente aceitável, sua aceitabilidade

(acceptability) prática pode ser analisada de diversos ângulos, incluindo aspectos convencionais,

e.g. custo, contabilidade, compatibilidade com outros sistemas existentes, além do aspecto

aplicabilidade29 (usefulness), que ele emprega no sentido de o sistema considerado poder ser

usado para atingir alguma meta entrevista no contexto em questão. Nielsen, assim como Grudin

[Grud92], ainda fraciona a aplicabilidade (usefulness) em duas sub-categorias de análise: utilidade29

29 Mesmo em inglês, os termos usefulness e utility são neologismos neste contexto, cujas definições são pouco distintas,

até em bons dicionários da língua inglesa. Daí, a tentativa de traduzí-los como aplicabilidade e utilidade, palavras

existentes no Novo Dicionário Aurélio da Língua Portuguesa [Holl86], que se enquadram no contexto em questão.


56

(utility) e usabilidade30 (usability). A primeira refere-se ao atendimento de todas as necessidades

do usuário pela funcionalidade do sistema, enquanto que a segunda é relativa ao quão

aproveitável é tal funcionalidade, i.e., quão bem o usuário pode explorar a funcionalidade do

sistema (vide Fig. 7). Este último ponto de vista é consonante com o ponto de vista de Eason

[Easo84].

Fig. 7 – Concepção de Nielsen [Niel93c] para a aceitabilidade de um sistema,

com destaque para as dimensões da usabilidade.

Deste modo, verifica-se que o termo usabilidade pode ser aplicado, no contexto de

Nielsen [Niel90, Niel92a, Niel93b], a quaisquer aspectos de um sistema com os quais

usuários interagem, inclusive procedimentos de instalação e manutenção, de onde se pode

apreender que tal termo não denota apenas uma propriedade unidimensional da interface

de usuário.

30 O termo usability, também referido como useability ou usableness, possui definições genéricas em dicionários correntes

da língua inglesa, do tipo "qualidade do que é aproveitável, usável". A tradução deste termo para a língua portuguesa

como usabilidade, um neologismo técnico, baseou-se em dois fatos: (i) em português, a terminação inglesa -ility se faz

corresponder, em diversas situações, ao sufixo -ilidade; e (ii) da aplicação da regra portuguesa de substantivação de

adjetivos terminados em -ável (e.g., miserável - miserabilidade, afável - afabilidade).


57

Nielsen não apresenta definições descritivas de usabilidade, embora considere um

conjunto de critérios operacionais que emprega para esclarecer adequadamente o conceito.

Os critérios operacionais adotados por Nielsen em seu modelo de usabilidade de produtos

são listados e especificados no Quadro 10.

Quadro 10 – Critérios da usabilidade de um sistema segundo Nielsen [Niel93b].

Facilidade de Aprendizado

(Learnability)

Refere-se à capacidade dos principiantes de atingirem rapidamente um nível

de desempenho razoável. Considerado por Nielsen como o critério mais

básico da usabilidade de produtos, visto que a maioria deles precisa ser fácil

de aprender para que possam ser aceitos no mercado, é fundamental nas

primeiras experiências de qualquer usuário com sistemas interativos. Alguns

sistemas com interfaces difíceis de usar procuram superar tal dificuldade

com um bom treinamento.

Eficiência (de Uso)

(Efficiency)

Associada ao grau de produtividade do usuário, após haver aprendido a

manipular o sistema de informação considerado. Estreitamente relacionada

ao desempenho do usuário experiente, se enquadrando em um contexto

interpretativo subjetivo e complexo, já que alguns sistemas são tão

complexos que exigem de seus usuários vários anos de uso, para que

atinjam o desempenho e a habilidade típicos de um usuário experiente. Além

do mais, enquanto alguns usuários prosseguem indefinidamente o

aprendizado dos sistemas, a maioria normalmente estaciona em um nível de

aprendizado que considera "suficiente" para desempenhar as atividades

cotidianas [Ross84, Carr87, Carr91].

Memorabilidade

(Memorability)

Refere-se à facilidade de memorização dos procedimentos de acesso às

facilidades oferecidas por um sistema considerado, evitando todo o processo

de re-aprendizado, mesmo quando se trata do uso esporádico do sistema. Tal

atributo valoriza não apenas a experiência anterior do contingente de

usuários ocasionais - a terceira maior categoria de usuários, além dos

principiantes e dos experientes - mas também a experiência daqueles

usuários em retorno de qualquer condição temporária que haja interrompido

seu contato cotidiano com o sistema com o qual operam.

Taxa de Erros

(Errors)

Associada ao cometimento de erros pelo usuário ao utilizar um sistema

computacional, assim como aos mecanismos de prevenção contra a

ocorrência de erros e à facilidade de correção de tais erros, caso sejam

cometidos [Shne87, Shac90, Quei94]. Neste contexto, um erro é definido

comumente como qualquer ação que impede o usuário de atingir a meta

desejada [Niel93b].

Satisfação Subjetiva

(Satisfaction)

Refere-se ao fato de quão agradável é usar o sistema ou, dito de outro modo,

quão satisfeito o sistema deixa o usuário ao executar tarefas por este

impostas [Bail83, Shne87, Niel93b, Quei94].

2.3.3 Visão da ISO (International Standards Organization)

O ISO 9241 é um padrão internacional voltado para o estabelecimento de requisitos ergonômicos

para o trabalho empresarial com terminais de visualização. A Parte 1131 deste padrão apresenta

especificações de usabilidade visando (i) especificações de requisitos de produtos e (ii)

avaliação de produtos. Conforme citado no capítulo anterior, a Parte 11 do ISO 9241 [ISO98]

31 Guidance on usability (Especificações de usabilidade)


58

define a usabilidade como a abrangência de ação de um produto, segundo a qual este poderá ser

empregado por usuários específicos para atingir metas especificadas com efetividade32, eficiência

33

e satisfação34, em um contexto específico de uso. Como contexto de uso, a ISO entende usuários,

tarefas, equipamentos (hardware, software e materiais adicionais) e os ambientes físico e social

nos quais um produto é usado. A Fig. 8 apresenta uma síntese gráfica dos conceitos relativos à

usabilidade tratados no padrão ISO 9241, enquanto a Fig. 9 ilustra as relações entre as dimensões

de usablidade segundo a visão da ISO.

Fig. 8 – Concepção de usabilidade da ISO, através do padrão ISO9241-11 [ISO98].

A Fig. 9 ilustra as dimensões da usabilidade segundo o ISO9241-11.

Fig. 9 – Dimensões da usabilidade de acordo com a Parte 11 do ISO 9241 [ISO98].

32 Precisão e completeza com que os usuários atingem metas especificadas.

33 Recursos despendidos em relação à precisão e completeza com que os usuários atingem metas.

34 Ausência de desconforto e exibição de atitudes positivas no tocante ao uso do produto.


59

Apesar do título (Usability guidance), as definições apresentadas nesta parte do padrão

ISO 9241 também se aplicam a outras situações que envolvam a interação de usuários com

produtos com o propósito de atingir determinados objetivos almejados. Esta abrangência torna a

concepção de usabilidade do ISO 9241 um conceito genérico, possibilitando sua aplicação a um

leque amplo de situações além de suas aplicações convencionais no âmbito da tecnologia da

informação. A Parte 11 teve influência do projeto MUSiC do Consórcio Europeu ESPRIT, como se

constata nos trabalhos de Bevan et al. [Beva91, Beva93, Beva94] e Bevan [Beva95a, Beva95b,

Beva97].

Bevan e Macleod [Beva94] discutiram uma abordagem de usabilidade fundamentada nas

diretivas do padrão ISO 9241-11, a qual denominaram qualidade de uso, definindo-a como uma

propriedade do sistema como um todo, o que inclui as práticas de trabalho, a localização e

aparência do produto, diferenças individuais entre usuários e outros aspectos que estão

intimamente relacionados com o contexto de uso do produto. Segundo este ponto de vista, os

atributos de um produto nada mais são do que uma contribuição para a qualidade de uso do

sistema como um todo. Por conseguinte, a usabilidade de um produto é encarada como algo

dependente não apenas dos usuários e do produto, mas também das tarefas, das metas

almejadas, dos equipamentos utilizados e do ambiente de trabalho. Enfim, do contexto de uso.

A Parte 11 do padrão ISO9241 estabelece uma discriminação entre a usabilidade e a

qualidade de trabalho a partir da seleção de um ponto de vista específico. Assim, a usabilidade é

estudada focalizando-se o produto sob o prisma da qualidade de trabalho. É este aspecto que

diferencia fundamentalmente o enfoque do ISO9241 daqueles apresentados por Shackel [Shac86,

Shac91] e Nielsen [Niel93b]. Enquanto estes últimos consideram a usabilidade como uma faceta

da aceitação do produto pelo consumidor, o padrão ISO 9241 concebe a usabilidade de um

produto a partir de um foco especialmente direcionado para a avaliação da qualidade de trabalho.

Isto torna os enfoques de Shackel e Nielsen eminentemente centrados no usuário, o que já não

ocorre com o enfoque da Parte 11 do padrão ISO 9241.

Como já foi mencionado ao longo desta discussão e também graficamente sintetizado nas

Figs. 8 e 9, as dimensões da usabilidade segundo a Parte 11 são: efetividade32, eficiência33 e

satisfação34. Vale salientar que o ISO9241-11 não menciona a experiência prévia do usuário com o

produto nem sugere medidas específicas.

Buie [Buie99] comenta que sendo um padrão internacional de processo, as

recomendações não poderiam deixar de ser genéricas, o que sugere implicitamente a necessidade

de sua adaptação às necessidades de cada organização. Entretanto, o Anexo informativo B do

ISO9241-11 apresenta exemplos de medidas de efetividade, eficiência e satisfação tanto quando

se focaliza a usabilidade global (overall usability) quanto para quando se deseja propriedades

específicas para o produto que contribuam para sua usabilidade. No último caso, as propriedades

desejadas são associadas a objetivos de usabilidade, que por sua vez são condicionados aos

seguintes aspectos: (i) atendimento das necessidades de usuários treinados; (ii) atendimento das

necessidades de acompanhamento e uso; (iii) atendimento das necessidades de uso intermitente

ou infreqüente; (iv) minimização de solicitações de ajuda; (v) facilidade de aprendizado;

(vi) tolerância a erros; e (vii) legibilidade.


60

Para cada um destes objetivos de usabilidade, o Anexo B lista vários exemplos de medidas

de efetividade, eficiência e satisfação. A experiência do usuário e as medidas de usabilidade são

conceitos dissociados no ISO 9241-11. As medidas são categorizadas conforme o aspecto da

interação que descrevem, i.e., uma parte das medidas descreve a produção da interação, sua

qualidade e quantidade, uma segunda parte mensura os recursos dedicados à interação, sob o

ponto de vista da produtividade, enquanto a última parte mensura a percepção subjetiva da

interação do ponto de vista do usuário. As medidas têm uma importância secundária do ponto de

vista da definição, sendo dada aos avaliadores uma grande liberdade de escolha na seleção das

medidas mais apropriadas aos seus propósitos.

Pontos de vista sobre usabilidade à parte, pode-se afirmar que engenharia da usabilidade

é um conjunto de atividades que ocorrem através da vida útil de um produto, como conseqüência

de outra série de atividades significativas realizadas desde antes da concepção da interface

usuário-produto [Goul85, Niel93b], o que só vem reforçar a constatação de Grudin [Grud91]: a

influência de fatores humanos sobre o sucesso de qualquer produto em desenvolvimento ou

mesmo de versões futuras desse produto é um fato.

Thimbleby [Thim94] concorda com a relevância dos critérios de usabilidade da definição de

Shackel [Shac86, Shac91] para acordos contratuais de usuários de sistemas com fabricantes, mas

questiona sua expressividade junto a atividades desenvolvidas pelos projetistas de sistemas,

contrapondo a impossibilidade de uso sistemático de medidas empíricas para a otimização de

projetos num contexto desprovido de teorias. Para a expressão engenharia da usabilidade, o autor

sugere o uso de usabilidade empírica, uma abordagem a ser encarada como complementar de

outra, por ele adotada, a usabilidade formal, embasada em propriedades formais e avaliada por

atividades que constituem a usabilidade de sistematização (formulating usability).

No âmbito de tais definições, o encaminhamento de procedimentos avaliatórios de

interfaces de usuário “engatilha” processos de descobertas e constatações de inúmeros eventos

que ocorrem entre o usuário de teste e o produto sob condições de avaliação, em que o fluxo de

informações de interesse parece assumir um ritmo difícil de acompanhar, sobretudo quando não

foram traçadas metas sobre os tipos de dados que se deseja coletar.

Não é rara a aquisição de extensos volumes de dados virtualmente sem nenhum valor para

o contexto avaliado ou, no melhor dos casos, de contribuição irrisória para a otimização do projeto

e da usabilidade da interface considerada. Daí a necessidade não apenas de planejamento prévio

dos procedimentos metodológicos, mas também da previsão de que tipo de dados contribuirá mais

efetivamente para mensurar e atingir as metas de usabilidade pré-fixadas e como deverão ser

adquiridos. Eis porque, por extensão, a importância do conhecimento das diferentes técnicas de

avaliação consagradas na literatura da área.

Vários métodos formais e informais de avaliação de interfaces usuário-computador têm

sido concebidos e experimentados, principalmente nas duas últimas décadas. Alguns deles

envolvem usuários em sessões individuais ou grupais, outros são centrados em julgamentos e

opiniões de especialistas. Alguns são conduzidos em ambientes onde o alvo da avaliação é usado

em condições reais, outros ocorrem em laboratórios, nos quais o alvo da avaliação é testado a

partir de tarefas simuladas para refletir contextos reais de uso. Uns focalizam a usabilidade como


61

princípio de projeto, outros não lidam necessariamente com este atributo. Alguns conservam os

procedimentos originais, outros resultam de adaptações a contextos mais específicos.

O próximo capítulo tratará de aspectos relativos aos diferentes métodos de avaliação de

processos interativos usuário-computador, destacando suas potencialidades e limitações. O

Capítulo 4 complementará a discussão de aspectos relativos à avaliação da usabilidade do

Capítulo 3, ressaltando tópicos pertinentes ao contexto dos enfoques avaliatórios consagrados na

literatura da área, em especial questões relativas à mensuração da usabilidade e à confrontação

de enfoques quantitativos e qualitativos.

2 considerações sobre qualidade e usabilidade de softwarerangel/ihm/downloads/capitulo2.pdf ·...

Documents