QUALIDADE E USABILIDADE DE SOFTWARE

Christina Paula de Camargo Curcio

Código Logístico

56271

Fundação Biblioteca Nacional

ISBN 978-85-387-6342-0

9 788538 763420
Qualidade e Usabilidade
de Software

Christina Paula de Camargo Curcio

IESDE BRASIL S/A

2017
© 2017 – IESDE BRASIL S/A. É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito da
autora e do detentor dos direitos autorais.

CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q
Curcio, Christina Paula de Camargo
2. ed.
Qualidade e usabilidade de software / Christina Paula de
Camargo Curcio. - 2. ed. - Curitiba, PR : IESDE Brasil, 2017.
140 : il. ; 21 cm.

Inclui bibliografia
ISBN 978-85-387-6342-0

1. Engenharia de software. I. Título.

CDD: 005.1
17-44416
CDU: 004.41

Capa: IESDE BRASIL S/A.

Imagem da capa: lukutin77/iStockphoto

Todos os direitos reservados.

IESDE BRASIL S/A.

Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200
Batel – Curitiba – PR
0800 708 88 88 – [Link]
 Apresentação

No mercado atual existe uma diversidade de softwares para uso

empresarial ou informal.

Tais sistemas podem auxiliar bastante os processos de uma empre-

sa e otimizar o tempo de trabalho; para isso, necessitam ser de fácil uso,
com uma interface amigável ao usuário e, principalmente, ter qualidade.
O que é necessário para um software ter qualidade?

A usabilidade de um software deve ser cuidadosamente estudada,

pois compreender a interação do homem com o computador pode definir
o sucesso ou o fracasso de uma aplicação. Além dos aspectos de usabili-
dade, se faz necessário reconhecer outros aspectos importantes que ga-
rantem a qualidade do software, assim como as etapas de planejamento e
produção que devem ser rigorosamente seguidas.

Neste livro vamos apresentar os temas fundamentais relacionados

à qualidade de software, como métricas, normas e gestão da qualidade.
Após este estudo, esperamos que você tenha facilidade para gerir e reco-
nhecer a qualidade e usabilidade dos softwares disponíveis no mercado e
identificar os requisitos necessários para o desenvolvimento de um soft-
ware com qualidade.

Esperamos que seu estudo não termine por aqui. Com base nes-
te livro, realize as atividades propostas, leia os textos indicados e faça
você mesmo a sua pesquisa para aprofundar os conhecimentos aqui
apresentados.

Bom estudo!
 Sobre a autora

Christina Paula de Camargo Curcio

Mestre em Desenvolvimento de Tecnologia pelo Institutos Lactec.

Especialista em Gestão de Projetos pela Fundação Getúlio Vargas (FGV),
em Project Management pela George Washington University (GWU,
EUA) e em Redes, com ênfase em Internet pela Universidade Positivo
(UP). Bacharel em Informática pela UP. Professora no ensino superior.
 Sumário

1 Qualidade de software 9
1.1 A qualidade de software 10
1.2 Processos em qualidade de software 15
1.3 Reflexões sobre a qualidade dos softwares 20

2 Normas e padrões 25
2.1 Normas e seus organismos normativos 26
2.2 Normas ISO e modelos CCMI 27
2.3 Métricas de qualidade de software 35

3 Influência dos requisitos na qualidade do software 41

3.1 Processos de negócio 42
3.2 Os requisitos e a comunicação 46
3.3 Qualidade de requisitos de software 49

4 Processo de desenvolvimento de software 57

4.1 Ciclo de desenvolvimento de software 58
4.2 Garantia da qualidade do software 65
4.3 Métodos ágeis, validações e indicadores 68

6 Qualidade e Usabilidade de Software

 Sumário

5 Gerência da qualidade de software 77

5.1 Dimensões da qualidade do processo e do produto 78
5.2 Planejamento e controle da qualidade do software 83
5.3 Gerência dos testes de software 86

6 Fundamentos da interação homem-computador (IHC) 91

6.1 Abordagens técnicas da IHC 92
6.2 Interação das atividades de IHC com a engenharia de software 101
6.3 O computador, o homem e os limites do sistema 102

7 Usabilidade de software 107

7.1 Definições de usabilidade do software 108
7.2 Métodos de usabilidade 109
7.3 A importância das recomendações de usabilidade 116

8 Acessibilidade e inclusão digital 123

8.1 A acessibilidade digital 124
8.2 A inclusão digital 128
8.3 Projetos de inclusão digital 131

Qualidade e Usabilidade de Software 7

 1
Qualidade de software

Introdução

O dia a dia das organizações demonstra como é frustrante a realidade do desen-

volvimento de software: produtos mais caros do que deveriam ser, gastos desne-
cessários, cronogramas estourados, estresse no trabalho, desenvolvedores desmo-
tivados, erros recorrentes nos projetos etc. Todos na organização saem perdendo
com isso, sem exceção.

Para que os problemas enfrentados pelas organizações produtoras de software

possam ser resolvidos, faz-se necessária uma conscientização de que, para desenvolver
softwares, é preciso muita disciplina, pois somente com um processo ou um modelo
de qualidade é possível construir sistemas de computação adequados. Desse modo, o
objetivo deste capítulo é apresentar uma reflexão sobre a qualidade de software (con-
ceito, fundamentos e processo), embasada em pesquisa bibliográfica da área.

Qualidade e Usabilidade de Software 9

 1 Qualidade de software

1.1 A qualidade de software

Qualidade é a capacidade de um produto ou serviço para atender às necessidades

do usuário (BEYON, 2011). No desenvolvimento de software, a qualidade do projeto
acompanha os requisitos de qualidade, as especificações e o design do sistema. Ela está
focada principalmente no aspecto de implementação, em que é observado se a execução
segue o design planejado e se o sistema resultante está cumprindo com os objetivos e
requisitos de desempenho.
Para garantir a qualidade do software são necessários: envolvimento de pessoas, defi-
nição de requisitos do software, integração e melhoria contínua dos processos, ferramentas
atualizadas e métodos de trabalho, conforme observado na Figura 1:

Figura 1 – Qualidade do software.

Pessoas e Integração e
definição de requisitos melhoria contínua

Garantia da
qualidade de
software

Métodos Ferramentas

Fonte: Elaborada pela autora.

De acordo com a Figura 1, para se garantir a qualidade de um software é preciso pes-

soas (analistas, programadores, webdesigners, gestores etc.) que tenham não apenas conhe-
cimento da área, mas que saibam trabalhar em equipe e tenham disciplina e comprometi-
mento com a organização. Elas têm de ter em mente os objetivos e as restrições do sistema a
ser desenvolvido, de modo a definir suas propriedades e seus requisitos.
Os requisitos de um software, também chamados de requerimentos de software ou de
requisitos funcionais de um sistema, podem ser compreendidos como “as funções ou ativida-
des que o software ou sistema faz (quando pronto) ou fará (quando em desenvolvimento)”
e “condições ou capacitações que devem ser contempladas pelo software, solicitadas pelo
cliente ou usuário para resolver um problema ou alcançar um objetivo” (REZENDE, 2005,
p. 123).
Para se atingir a qualidade de software, ela deve ser incorporada à integração de todas
as funções de todos os e recursos de uma empresa, desde a alta administração. Essa integra-
ção deve estar aliada à melhoria contínua e à revisão dos processos.
Por último, o uso de ferramentas adequadas para o monitoramento da qualidade de
software auxilia a corporação na mensuração da qualidade. Esse monitoramento pode ser
feito por meio de métodos estatísticos que são cada vez mais indispensáveis no controle da
qualidade. Tais métodos são recursos de verificação e validação da qualidade do software
e controlam se o software foi desenvolvido de acordo com as especificações desejadas, de
maneira correta, e garantem que o software atenda aos propósitos desejados.

10 Qualidade e Usabilidade de Software

 Qualidade de software 1
1.1.1 Fundamentos da qualidade de software
Originalmente, a qualidade de um programa ou sistema era avaliada de acordo com o
número de defeitos a cada mil linhas de código. Atualmente, com a evolução do conceito,
outros fatores determinam a qualidade do software (BENYON, 2011):
• Operações de produtos: as características operacionais.
• Correção: grau em que um programa atende sua especificação e atinge os objeti-
vos definidos pelo usuário.
• Confiabilidade: nível de execução esperada de um software para realizar as fun-
ções com precisão.
• Eficiência: número de computadores e recursos exigidos pelo programa para exe-
cutar suas funções com o tempo de resposta adequado.
• Integridade: medida em que pode ser controlado o acesso ao software ou dados
por usuários não autorizados.
• Facilidade de uso: esforço necessário para aprender, usar e interpretar a funciona-
lidade do sistema.
• Revisão do produto: capacidade de resistir a mudanças de tecnologia.
• Facilidade de manutenção: necessária para localizar e corrigir um bug no sistema.
• Flexibilidade: esforço necessário para modificar um programa.
• Facilidade de teste: condição necessária para testar um programa, de modo a asse-
gurar que a função desejada não exija esforço.
• Transição do produto: capacidade de adaptação a novos ambientes.
• Portabilidade: necessária para transferir um programa de um ambiente de hard-
ware ou software a outra tecnologia.
• Reutilização: grau em que um componente de programa ou ­software pode ser
reutilizado em outras aplicações.
• Interoperabilidade: integração entre sistemas e outros aplicativos.
O CMM (Capability Maturity Model) é um modelo de qualidade de ­software que classi-
fica as empresas em níveis de maturidade, ou seja, determina a maturidade dos processos
realizados para produzir cada software. De acordo o CMM, as organizações podem ser clas-
sificadas em cinco níveis de maturidade:
No nível 1 (inicial), o das organizações mais imaturas, não há nenhuma metodo-
logia implementada e tudo ocorre de forma desorganizada: por sua vez, no nível
5 (otimizado), o das organizações mais maduras, cada detalhe do processo de
desenvolvimento está definido, quantificado e acompanhado. Assim, a organi-
zação consegue até absorver mudanças no processo sem prejudicar o desenvol-
vimento do software. (RESENDE, 2005, p. 137)
Para atingir um nível maduro de produção, métodos específicos devem ser implemen-
tados (WEBER, 2012):

Qualidade e Usabilidade de Software 11

 1 Qualidade de software

• Gerenciamento de requisitos: é o processo contínuo de análise e documentação

dos requisitos do software. Ocorre durante o projeto de desenvolvimento de soft-
ware e envolve os usuários-chave ou stakeholders.
• Planejamento de projeto: busca refinar e detalhar os objetivos do projeto e planejar
o trabalho necessário para alcançá-los.
• Monitoramento e controle de projetos: consiste em medir e coletar informações
sobre o desempenho do projeto, assim como informar os envolvidos.
• Gestão de fornecedores: é o processo de adoção de boas práticas e de controle e
gestão dos fornecedores.
• Garantia de qualidade: consiste no acompanhamento do projeto e na avaliação de
seus diferentes aspectos para garantir que os padrões de qualidade sejam seguidos.

1.1.2 Aspectos no desenvolvimento do software

com qualidade
A engenharia de software procura auxiliar a produção de programas e sistemas de boa
qualidade, com baixo custo e dentro do prazo programado. Ela visa à melhoria de desenvol-
vimento de software ao longo do tempo, considerando que as tarefas relativas ao processo
podem ser aprimoradas, controladas e medidas. Um dos principais benefícios de um pro-
cesso de desenvolvimento de software definido e disciplinado é a melhoria de sua visibili-
dade, ou seja, as atividades desse processo são gerenciáveis e, por isso, seus prazos e custos
expressam melhor a realidade.
Aqui, a engenharia de software será discutida de duas formas: a convencional, que
detalha os aspectos principais desse ramo, e outra, mais específica, que detalha o uso da
orientação por objeto.
A engenharia de software procura atender uma necessidade humana, da mesma forma
que outras ramificações da engenharia tratam de assuntos relacionados à mineração, agricul-
tura, moradia e tantos outros que justificam a utilização de algum conhecimento científico es-
pecífico. Ela traz benefícios por meio dos recursos tecnológicos disponíveis para o tratamento
de informações.
Uma parte dos métodos da engenharia de software vem da ciência da computação e a
outra da experiência adquirida pelo usuário. A engenharia de software é composta por um
conjunto de disciplinas específicas relacionadas à ciência da computação e utiliza as abstra-
ções dessa área, como algoritmos e estruturas de dados, para criar sistemas de computador
que atendam às necessidades do usuário, usando, para isso, um processo definido e disci-
plinado, por meio da tecnologia existente.
Existem três conceitos muito importantes na engenharia de software, que se relacionam
intrinsecamente:
• Processo: trata-se de um conjunto de passos ordenados usado para atingir um fim
específico, sendo composto por atividades, métodos, práticas e transformações.

12 Qualidade e Usabilidade de Software

 Qualidade de software 1
• Projeto: é o que concretiza um processo.
• Produto: é o objetivo do processo.
Esses conceitos podem ser relacionados da seguinte maneira: um projeto tem um es-
copo delimitado por datas de início e de fim, com pontos de controle, chamados de marcos
de projeto, para que possa ser acompanhado e gerido. O escopo do projeto é um processo
constituído de documentação que detalha o que é feito, quando e por quem, tendo por meta
a concretização do produto especificado.
De modo geral, um produto tem um ciclo de vida em que é concebido, desenvolvido,
entra em operação e sai de operação. Um produto de software é criado a partir do momen-
to em que se percebe a necessidade de sua existência, e, assim, um conjunto de requisitos
é determinado e desenvolvido para que seja posto em operação. Quando o produto não é
mais necessário ou se torna obsoleto, seu ciclo de vida termina e ele é retirado de operação.
A literatura disponível varia muito ao definir as disciplinas da engenharia de software,
a qual se configura como uma área interdisciplinar que se baseia nos fundamentos de várias
disciplinas (RESENDE, 2005). Elas podem ser distribuídas entre os aspectos de requisitos,
planejamento de projetos e qualidade, conforme se discutirá a seguir.

[Link] Engenharia dos requisitos

Os requisitos descrevem ou expressam as características de um dado produto de
software, podendo ser funcionais ou não funcionais. Requisitos funcionais são aqueles que
determinam o comportamento do produto de software de acordo com uma situação especí-
fica, enquanto os requisitos não funcionais quantificam aspectos desse produto, como, por
exemplo, desempenho, disponibilidade ou portabilidade.
Os requisitos precisam ser especificados em um documento, devendo-se detalhar e dis-
tinguir os explícitos e os normativos. Os requisitos explícitos são aqueles levantados por de-
senvolvedores com base nas informações dos usuários e os requisitos normativos são os pro-
venientes de leis e normas aplicados ao produto de software (PRESSMAN; MAXIM, 2016).
Existem, ainda, os requisitos de expectativa do usuário, os quais não estão documenta-
dos. Eles são chamados de requisitos implícitos e são totalmente indesejados, porém podem
ser minimizados por meio de uma boa especificação de requisitos, ou seja, detalhando-se
bem os explícitos e normativos.
Para obter uma boa especificação de requisitos, faz-se necessário o uso de técnicas de
levantamento, documentação e análise; constitui-se, assim, a engenharia dos requisitos, uma
disciplina da engenharia de software.
Uma boa engenharia de requisitos aumenta a compreensão do produto para o seu pú-
blico-alvo e também diminui a instabilidade dos requisitos, ou seja, a alteração dos requisi-
tos constantes no documento de especificação. A instabilidade onera o projeto de várias for-
mas, como, por exemplo, no aumento de prazos e custos. Porém, essa alteração de requisitos
também pode acontecer devido a mudanças em requisitos normativos, sendo inevitável a
variação do contexto do produto. O controle dos requisitos precisa ser, então, submetido a

Qualidade e Usabilidade de Software 13

 1 Qualidade de software

algum tipo de gestão, pois eles podem ser alterados mesmo à revelia do usuário. Isso cons-
titui a gestão de requisitos, outra disciplina da engenharia de software.

[Link] Engenharia de gestão de requisitos

Além de especificar corretamente os requisitos, gerentes de projetos devem estar aten-
tos a outros dois fatores, os prazos e os custos, pois estes, juntamente com os requisitos,
determinam o sucesso ou o fracasso do projeto de software. Um produto de software deve
atender aos requisitos e às necessidades dos usuários e também deve ser construído dentro
do prazo e do custo estimados.
O aumento ou a alteração de requisitos acarreta aumentos de prazos e/ou de custos. No
caso da redução de requisitos, os prazos e os custos também podem sofrer alteração, mas
isso não é regra. O bom planejamento de projetos tenta equilibrar os componentes dos vérti-
ces desse triângulo crítico (requisitos, prazos e custos), com base em uma boa especificação
de requisitos e com técnicas de estimativa e análise de tamanho, esforços, prazos e riscos.
O planejamento de projetos é a disciplina da engenharia de software que trata desses aspectos.
O planejamento de projetos tem uma disciplina complementar, chamada de controle de
projetos, cujo objetivo é acompanhar o progresso dos projetos, comparando o previsto com o
realizado. Busca solucionar os problemas detectados, replanejar os projetos, quando houver
necessidade, e renegociar os compromissos assumidos.
Também diz respeito à gestão de requisitos a gestão de contratos. As organizações que
terceirizam a produção de software devem estar capacitadas nessa gestão, porque precisam
especificar corretamente todos os requisitos do produto, selecionar os candidatos mais qua-
lificados, ter proficiência no acompanhamento do projeto para intervir quando necessário e
verificar os critérios para a aceitação do produto (BENYON, 2011).

[Link] Engenharia de gestão de configurações

Para gerir com qualidade todos os artefatos produzidos no processo de desenvolvimen-
to, a engenharia de software tem a disciplina de gestão de configurações – gerência de confi-
guração, ou, ainda, gestão de configuração de software, uma área responsável por fornecer
o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de
versão, o controle de mudança e a auditoria das configurações.
Um grupo de pessoas deve ser designado para controlar esses artefatos de software,
porque todos são passíveis de alterações. Em caso de organizações pequenas que não dispo-
nham de pessoal suficiente, um membro da equipe de desenvolvedores pode ser designado
para essa função. Essa é uma disciplina em que é fortemente recomendado o uso de ferra-
mentas automatizadas, devido ao grande volume de artefatos e de versões destes que são
geradas durante todo o processo de desenvolvimento (WEBER, 2012).

14 Qualidade e Usabilidade de Software

 Qualidade de software 1
1.2 Processos em qualidade de software

Para falar sobre qualidade em software, é preciso introduzir uma discussão sobre os
erros aos quais um processo de desenvolvimento de software está sujeito. As disciplinas
da engenharia de software que regem a garantia da qualidade dizem respeito ao impacto
causado por esses erros.

1.2.1 Erros que devem ser evitados

A qualidade de um produto é definida pelo grau de conformidade com os seus requi-
sitos e está diretamente relacionada à qualidade do processo utilizado em sua construção.
Pode-se afirmar, então, que a qualidade é uma relação construída com base em processos,
pessoas e tecnologia envolvidos na construção de um produto. Esses três elementos formam
o segundo triângulo crítico da engenharia de software e indicam os fatores da produção
(BENYON, 2011).
Os defeitos ocorrem em um produto de software em todas as suas fases de desenvol-
vimento. Eles são encontrados de diversas formas, como no desempenho aquém do deseja-
do, nas funções que não são executadas corretamente ou na dificuldade para utilização do
sofware. Assim, os defeitos estão relacionados à não conformidade com os requisitos explí-
citos, os normativos e os implícitos.
Os erros relativos ao produto estão vinculados a algum desses fatores e são defeitos de
definição de requisitos ou defeitos introduzidos ao longo do projeto. Os mais comuns são
a introdução de características desnecessárias aos requisitos, alteração dos requisitos sem
uma análise de impacto e erro no foco do desenvolvimento, quando ele é voltado para a
pesquisa e não para a produção em si.
Os erros relativos ao processo estão relacionados com processos informais ou proces-
sos oficiais rígidos e burocráticos. Os mais comuns são (WEBER, 2012):
• desperdício de tempo antes do início do projeto;
• pressões por prazos otimistas e o não cumprimento destes por serem impossíveis;
• falha no planejamento de projetos em que se omitem as estimativas de atividades,
como as de garantia da qualidade e a omissão da análise de riscos;
• falha no método de gerir o projeto;
• pressa para começar a etapa de codificação;
• falha na subcontratação de serviços; e
• entrega do produto sem estar totalmente pronto ou testado.

Qualidade e Usabilidade de Software 15

 1 Qualidade de software

Entre os requisitos e a codificação existe o projeto, presente em todas as fases do proces-

so. Os defeitos de projeto são tão graves como os defeitos provenientes de requisitos. Eles se
caracterizam por dificuldade para utilização do software, desempenho ruim, defeitos alea-
tórios de difícil reprodução e dados inconsistentes que comprometem a manutenibilidade e
a extensão. Um bom projeto deve ser também documentado.
Como todas as fases do desenvolvimento do projeto são passíveis de injetar erros no
produto, é preciso haver atividades como testes, revisões formais e informais e auditorias,
que visem garantir a qualidade do software, detectando precocemente cada erro. Estudos
já demonstraram que o aumento da qualidade reduz o tempo de desenvolvimento, devido
ao refinamento na detecção e eliminação precoce de defeitos, o que é bem mais barato que
corrigir o defeito em um estágio avançado do processo (BENYON, 2011).
Os métodos de garantia de qualidade devem levar em consideração o fator humano: é
mais fácil detectar erros dos outros do que os próprios. Assim, revisões, testes e auditorias
devem ser realizados por pessoas diferentes daquelas que desenvolveram o produto. Por
fim, a garantia da qualidade deve ser gerida por um grupo de pessoas independente dos de-
senvolvedores e que não mantenha nível hierárquico com estes ou com o gerente do projeto
e tenha acesso à alta gerência da organização.
Já os erros relativos a pessoas podem ocorrer por: falta de patrocínio para o projeto;
ausência de participação dos interessados no produto, como os usuários e desenvol-
vedores; atritos entre as partes envolvidas; defeitos na formação da equipe do projeto,
como a falha na contratação de pessoas; falta de entrosamento entre funcionários e de-
pendência em relação a determinadas pessoas; ambiente inadequado ao trabalho, com
muito barulho, pouco espaço e fatores ergonômicos inapropriados, e falta de motivação
do pessoal (BENYON, 2011).
Os erros relativos à tecnologia podem ocorrer por uma estimativa otimista de que mui-
tos problemas podem ser resolvidos por meio de alta tecnologia, esquecendo-se de que para
utilizá-la em profundidade é necessário treinamento e experiência. Assim, pode haver falha
na análise para mudança de tecnologia e a substituição desta no meio de um projeto, falta
de automação de atividades como as de gestão de configurações, ausência de ferramenta de
modelagem e automação de atividades de testes.

1.2.2 Modelos de ciclo de vida

Para a existência de um processo de desenvolvimento de software, é preciso ter defini-
do o seu modelo de ciclo de vida. Existem vários tipos de modelos, que se diferenciam prin-
cipalmente pelo grau de controle aplicado sobre o processo em questão e sua visibilidade
para o cliente no seu decorrer, como especificado a seguir.
• Codifica-Remenda: é o pior de todos os modelos de ciclo de vida aqui apresen-
tados e, provavelmente, o mais utilizado. Com base em um problema existente,
e não um problema modelado ou especificado, mas sim definido de uma forma

16 Qualidade e Usabilidade de Software

 Qualidade de software 1
qualquer, passa-se imediatamente à codificação. Os erros encontrados são corrigi-
dos conforme a demanda, daí o termo remenda. Muitas vezes não existe um proces-
so definido ou, se existe, ele não é seguido, é impossível de ser gerido e, portanto,
não se pode assumir compromissos confiáveis.
• Cascata: esse modelo de ciclo de vida tem a vantagem de apresentar pontos de
controle que permitem demarcar as fases do processo, facilitando a sua gestão.
Porém, ele é rígido e burocrático, porque não permite a correção de erros nas fases
anteriores e tem baixa visibilidade para o cliente, pois este não recebe feedback nos
pontos de controle existentes, assim o único resultado que o cliente vê é o final.
Ele apresenta uma variante que permite a realimentação entre fases, porém esta
dificulta a gestão de projetos.
• Espiral: modelo de ciclo de vida em que um produto é desenvolvido em diver-
sas iterações (repetições). Uma iteração nova representa uma volta na espiral. Sua
vantagem é que permite a construção de produtos com prazos curtos e a desvan-
tagem é que é difícil de ser gerido.
• Prototipagem evolutiva: utiliza o modelo de ciclo de vida em espiral para cons-
truir o produto em protótipos, cobrindo progressivamente os requisitos até a fi-
nalização. Sua vantagem é que apresenta visibilidade e alta flexibilidade para o
cliente. Como desvantagem, ele precisa de equipes disciplinadas e experientes; o
projeto deve ser robusto para que a estrutura do produto permaneça confiável ao
longo dos protótipos, além disso, ele é também difícil de ser gerido.
• Entrega evolutiva: esse modelo de ciclo de vida é uma combinação dos modelos
cascata e prototipagem evolutiva. Apresenta a vantagem de ter alta visibilidade
para os clientes e facilidade de gestão, por apresentar pontos de controle bem de-
finidos. Sua desvantagem é a necessidade de um projeto que seja robusto para que
a estrutura do produto permaneça confiável ao longo das liberações programadas.
• Dirigido por prazo: um conjunto de requisitos essenciais é definido e entregue no
prazo programado nesse modelo de ciclo de vida. O produto final é, na verdade,
um produto parcial e o restante é desenvolvido em processos posteriores, geral-
mente chamados de manutenção.
• Dirigido por ferramenta: utiliza-se um processo proposto por uma ferramenta
CASE1 e podem ser adequados a um determinado tipo de produto, porém fica
restrito ao domínio da aplicação.
Mesmo que uma organização decida por não desenvolver, mas adquirir um produto
de software, ela tem de ter competência para gerir os processos de aquisição, implantação,
adaptação e integração com outros sistemas e a organização. Isso pode sair mais caro do que
o processo de desenvolvimento em si.

1 Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange
todos os programas (as “ferramentas”) que auxiliam os analistas nas atividades de engenharia de
software, desde análise de requisitos e modelagem, até a programação e os testes.

Qualidade e Usabilidade de Software 17

 1 Qualidade de software

1.2.3 Processos de desenvolvimento de software

Para que a organização possa ser considerada madura, ela precisa ter processos de de-
senvolvimento formalmente definidos e que possam ser melhorados continuamente, como
os processos apresentados a seguir.
Processo pessoal de software – PSP: utiliza o modelo de ciclo de vida em entrega
evolutiva e não há tratamento específico para requisitos. Na fase de planejamento do
PSP, executam-se as atividades de estimativas de tamanho (com base em modelo de
orientação a objetos), esforços, cronogramas e defeitos. O projeto é rigoroso tanto para
concepção quanto para verificação e é realizado utilizando-se orientação a objetos, sín-
tese lógica e máquinas sequenciais.
Processo de software para times – TSP: utilizando um modelo de ciclo de vida em
espiral, esse processo é uma sequência do PSP. O TSP cobre a área de gestão de requisitos,
planejamento e controle de projetos, garantia da qualidade e gestão de configurações não
cobertas pelo PSP.
Processo unificado: esse processo, centrado na arquitetura, é dirigido a casos de uso,
sendo iterativo e incremental, e usa a UML (Unified Modeling Language) como notação para
os modelos que o compõem, centrado na arquitetura. Ele utiliza um modelo de ciclo de vida
em espiral e é dividido em fases e fluxos de trabalho. Cada fase representa um marco geren-
cial do projeto e cada fluxo de trabalho trata de um tema técnico específico. O RUP (Rational
Unified Process) e o EUP (Enterprise Unified Process) são baseados no processo unificado.
Práxis: é um processo com fins didáticos e baseado em tecnologia de orientação a ob-
jetos e sua notação de análise e projeto também é UML. Apresenta elementos do processo
unificado, mas com influência do PSP e do TSP. Da mesma forma que o processo unificado,
o práxis abrange fases e fluxos: uma fase é dividida em uma ou mais iterações, e um fluxo é
dividido em uma ou mais atividades.
Um dos objetivos de um processo de desenvolvimento de software é capacitar uma
organização a identificar rapidamente e solucionar facilmente os problemas. Ora, para isso
ela necessita de maturidade. Uma organização imatura é ruim aos profissionais desenvol-
vedores e gerentes, clientes e usuários. Para os profissionais, é ruim porque o ambiente de
trabalho é pouco adequado, estressante, o grau de motivação é baixo e os processos são difí-
ceis de gerir. Já para os clientes e usuários, é ruim porque a qualidade do produto final não
é boa ou porque foram entregues fora do prazo e do custo estimado. Todos esses problemas
podem ser minimizados, e até mesmo resolvidos, pela definição formal de um processo de
desenvolvimento de software.
O processo precisa ser definido de forma a auxiliar a organização a produzir produtos
melhores, com baixo custo e dentro do prazo estimado, e uma consequência inerente ao re-
finamento do processo é que os produtos são produzidos mais rapidamente. Por outro lado,
se a organização erra definindo um processo rígido e burocrático, ele servirá apenas para
formalizar uma situação e não será efetivamente usado na prática.

18 Qualidade e Usabilidade de Software

 Qualidade de software 1
Um software é baseado em abstrações lógicas, e não em princípios físicos estáveis.
Como consequência, a disciplina para gerir um processo desse tipo deve ser mais rígida que
de costume. Assim, um processo de desenvolvimento de software ruim não vai conduzir a
um produto de qualidade satisfatória.
É um erro imaginar que a qualidade de um software não pode ser medida; ela pode e
deve ser medida por meio da produtividade ou do número de defeitos encontrados, por
exemplo. As métricas devem ser coletadas, analisadas e normatizadas para que o processo
possa ser gerido e melhorado.
Outro erro muito comum em organizações é acreditar que os problemas da produção
são mais técnicos que gerenciais. Com um processo de negócio ruim, pouco adianta a tec-
nologia e esta não tem retorno; sem processos de negócio mapeados e robustos, um projeto
de desenvolvimento de software inicia de forma incorreta, já que aqueles são a base deste.
O mesmo se aplica quando a gestão é deficiente. Mais uma vez, os indicadores dos proble-
mas da produção recaem nos problemas gerados por um processo mal definido. As pessoas
erram porque a informação chega até elas de forma incorreta, incompleta ou confusa, os
recursos disponíveis não são adequados ou não são suficientes, o processo é mal definido ou
difícil de seguir e falta treinamento da área de negócio nos processos e tecnologias utilizados
(BENYON, 2011).
Infelizmente, a tendência é acreditar que os erros são do corpo técnico, por falta de
comprometimento e treinamento, e não devido a processos inadequados ou uma gerência
de projetos despreparada. Os gerentes podem não conhecer totalmente o domínio da aplica-
ção e precisam ser treinados em gestão de pessoal. Também precisam estar comprometidos
com o projeto para se abstrair de paixões pessoais e evitar competições internas que sempre
existem dentro das organizações, procurando levar ao conhecimento dos desenvolvedores
as informações corretas, completas e precisas.
A conclusão extraída é óbvia: fatores de produção, pessoas, tecnologia e processos são
muito dependentes uns dos outros. Não basta ter tecnologia se não há um corpo técnico com
capacidade de operá-la, e isso requer treinamento e experiência. Não basta ter tecnologia e
um corpo técnico altamente capacitado se os gerentes acreditam que isso resolverá todos
os problemas e eles terão o produto desejado dentro do prazo e custo estimados. Para tudo
isso, é preciso um processo definido.
Para a realização da melhoria de processos, faz-se necessária uma análise em que os pro-
blemas relativos a eles são de responsabilidade dos gerentes de projetos. Ora, isso porque
os gerentes possuem um universo de variáveis envolvidas, estando capacitados a procurar
e encontrar as deficiências do processo para interferir quando for preciso. A atuação de um
gerente de projeto deve ser de forma a estimular melhorias sem procurar efetivamente os
culpados, porque isso leva ao ocultamento dos problemas reais. De outra forma, o processo
fatalmente não funcionará. É tarefa do gerente promover aperfeiçoamentos, reduzindo o
desgaste no ambiente de trabalho, a fim de aumentar a produção. Mas, para isso, é preciso
que ele conheça o processo para poder agir eficazmente, ter o apoio da alta administração,
que deve estar ciente do investimento a ser feito, envolver o corpo técnico e, por último,
mas não menos importante, ele tem de ter em mente que a capacitação no processo não é

Qualidade e Usabilidade de Software 19

 1 Qualidade de software

conseguida da noite para o dia – ela é realizada em etapas, com marcos para pontos de con-
trole bem definidos.
Assim, os processos de qualidade de software englobam fases que buscam aumentar a
eficiência e a eficácia dos softwares produzidos, conforme pode ser observado na Figura 2.
O processo de melhoria contínua envolve os procedimentos de planejamento, controle e
garantia da qualidade, em que as revisões devem ser contínuas ao longo de todo o projeto
de desenvolvimento do software.

Figura 2 – Processos de qualidade do software.

Qualidade do software – conjunto de caracterísiticas de um sistema para atender

os requisitos das partes interessadas.

Gestão da qualidade do software – direção e coordenação das atividade de qualidade de software

Melhoria da qualidade do software – processo de melhoria contínua

Revisão dos
processos de
qualidade
Planejamento Controle da Garantia da
da qualidade qualidade qualidade

22 Estabelecer os ob- 22 Cumprir os objeti- 22 Garantir que os re-

jetivos, processos vos e requisitos de quisitos de qualidade
e recursos qualidade sejam cumpridos

Fonte: Elaborada pela autora.

A Figura 2 resume o que foi visto até aqui: o processo de melhoria da qualidade do
software deve ser contínuo e revisado em todos as etapas. Num primeiro momento é feito
o planejamento, em que se estabelecem os objetivos, processos e recursos. Durante o desen-
volvimento, o controle de qualidade deve estar sempre presente, buscando-se cumprir os
objetivos e atender aos requisitos de qualidade. A garantia de qualidade é uma etapa final,
em que é feita uma última avaliação do produto, no entanto, para que ela seja eficaz, tam-
bém precisa estar presente em todas as etapas anteriores, num ciclo de melhoria contínua.

1.3 Reflexões sobre a qualidade dos softwares

Para que o software tenha qualidade, ele deve ter usabilidade, funcionalidade, confia-
bilidade, manutenibilidade e desempenho. Para que essas características de qualidade de
software sejam atendidas é importante que sejam respondidas questões como: O software satis-
faz a necessidade do usuário ou da empresa? Ele é confiável? Tem um bom desempenho? É fácil
de usar? Pode ser corrigido com facilidade? Pode ser reutilizado em outro projeto?

20 Qualidade e Usabilidade de Software

 Qualidade de software 1
O software deve satisfazer a necessidade do cliente em relação à funcionalidade. Para
isso, deve se propor a fazer o que é apropriado, de forma correta, ser capaz de interagir com
os sistemas especificados, estar de acordo com as normas de qualidade de sofware e da or-
ganização e deve ser protegido para evitar acessos não autorizados.
Com relação à confiabilidade o sistema deve ser imune a falhas e ser capaz de recuperar
dados em caso de falhas. Além disso, deve ser fácil de usar (com navegação intuitiva) para
atender o critério de usabilidade, ou seja, o sistema deve ter um nível fácil de operação para
o usuário e ser de fácil compreensão, pois se for muito complicado exigirá vários treinamen-
tos, o que dificultará seu emprego.
Por último, o software deve ser de fácil modificação, adaptação e validação. A eficiência
do software é outro item de qualidade a ser verificada pois deve ser enxuto, com bom tempo
de resposta e de processamento na execução de suas funções, utilizando recursos e tempo
aceitáveis pelo usuário.
No contexto da engenharia de software, o processo de gestão de qualidade é aquele que
estabelece o comportamento essencial de um sistema, o qual pode ser mantido, independen-
temente de como o sistema é implementado.
Um modelo de análise deve ser confeccionado visando às abstrações que indicam o
que o sistema vai fazer. Assim, pressupõe-se que uma tecnologia perfeita esteja disponível
e o analista considere que não haverá restrições de capacidade de memória; a comunicação
entre os objetos será realizada na velocidade ideal; a adequação do sistema à plataforma de
computador não será um empecilho; não acontecerão erros e outras questões relacionadas
às abstrações de como fazer o sistema (BENYON, 2011).
O modelo AOO (análise orientada a objetos) serve para formalizar a visão do mundo
real no contexto do sistema de computador, estabelecendo os principais objetos que repre-
sentam o domínio de uma aplicação e as estruturas organizacionais impostas a tais objetos,
bem como a colaboração existente entre eles, ou seja, as conexões de mensagens que mos-
tram a forma de comunicação dos objetos com os demais (WEBER, 2012).
Os benefícios trazidos pela melhoria dos processos são muitos. Os principais deles são
(BENYON, 2011):
• Engenharia de requisitos e gestão de requisitos: são práticas que produzem um
retorno de investimento mais significativo porque é mais barato captar o requisito
certo do que alterá-lo em fases posteriores do processo.
• Projeto: menos significativo que o anterior, mas que não deixa de produzir impac-
to no retorno de investimento.
• Garantia da qualidade: as atividades de garantia da qualidade – as que mais so-
frem devido à pressa para entrega de um produto – dão retorno quando as neces-
sidades de se refazer as etapas iniciais de um processo tendem a diminuir.
• Prevenção de defeitos: aqui vale o ditado popular “é melhor prevenir que reme-
diar”. Entre as atividades de garantia da qualidade, as de prevenção de defeitos
dão mais retorno do que as de correção.

Qualidade e Usabilidade de Software 21

 1 Qualidade de software

Ampliando seus conhecimentos

O texto a seguir trata sobre a importância do trabalho do analista de

requisitos no desenvolvimento de um software e as principais dificulda-
des enfrentadas por esse profissional, cujo trabalho muitas vezes é des-
valorizado ou incompreendido pelos outros colaboradores e até mesmo
gestores da organização.
(FAGUNDES, 2011, p. 4-5)

Quando se trabalha algum tempo com requisitos de software, percebe-

-se o quão ingrata é a atividade. Não por ser mais ou menos complexa
que as outras, mas pela forma como é tratada pelos pares. O Analista
de Requisitos é tomado na maioria das vezes como um documentador
(até mesmo pelos próprios trabalhadores de requisitos), corrompendo o
bem-fazer da atividade e provocando prejuízo aos projetos e degradando
ainda mais a forma como se percebe a engenharia de requisitos.

A percepção geral que se tem é que os analistas de requisitos entram em

ação para atrasar os projetos e que a documentação gerada é extensiva
e de pouca valia. Às vezes parte dessa percepção é correta, mas a razão
imputada é, na maioria das vezes, distorcida, apontando para uma ori-
gem incorreta. Muito mais vezes os problemas de requisitos se dão pela
falta de preparação dos analistas, seu perfil e por uma fraca postura na
relação com o cliente, em vez da lendária mão invisível do processo.

Como resultado desses fatores reais para uma construção adequada de

requisitos, constrói-se uma escala de retrabalho que a equipe não entende
exatamente por quê. Por várias vezes durante um projeto há questiona-
mentos sobre a forma dos requisitos serem especificados ou se a proposta
é adequada ou não, desviando o foco da atividade em voga no andamento
do projeto.

Para, então, corrigir o prumo e trabalhar requisitos é premente que se faça

uma revisão de propósitos, motivações, formação, discurso e perfis, para
que as pessoas corretas estejam alocadas corretamente para realizar a ati-
vidade de maneira eficaz e eficiente. A adoção de novos processos e técni-
cas não surtirão efeito sem essa revisão.

22 Qualidade e Usabilidade de Software

 Qualidade de software 1
Atividades
1. Para se avaliar a qualidade do software, é fundamental medir e monitorar todo o
ciclo de seu desenvolvimento. Por quê?

2. O que são requisitos de software e como devem ser documentados?

3. Com relação aos processos de qualidade de software, quais são os principais erros
encontrados?

4. Por que o modelo ciclo de vida codifica-remenda é o mais utilizado e o menos reco-
mendado?

Referências
BENYON, D. Interação humano-computador. Tradução de Heloisa Coimbra. 2. ed. São Paulo: Pearson
Prentice Hall, 2011.
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade de software são as mes-
mas coisas? Disponível em: <[Link]
-[Link]#ixzz4WjF9RTkw>. Acesso
em: 13 jan. 2017.
CAVANO, J. P.; MCCALL, J. A. Proceedings of the Software Quality Assurance Workshop on
Functional and Performance Issues. San Diego, 1978.
FAGUNDES, R. M. Engenharia de requisitos: do perfil do analista de requisitos ao desenvolvimento de
requisitos com UML e RUP. Salvador, 2011. Disponível em: <[Link]
2pIBQAAQBAJ&printsec=frontcover&dq=engenharia+dos+requisitos&hl=pt-BR&sa=X&ved=0ahUKE-
wis6MX925PVAhXMIpAKHddiBhcQ6AEIKTAB#v=onepage&q&f=false>. Disponível em: 19 jul. 2017.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto
Alegre: AMGH, 2016.
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. Rio de Janeiro: Brasport, 2005.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2012.

Resolução
1. Um produto tem um ciclo de vida em que é concebido, desenvolvido, entra em ope-
ração e sai de operação. Um produto de software é concebido a partir do momento
em que se percebe a necessidade da sua existência, então um conjunto de requisitos
é determinado e desenvolvido para que seja posto em operação. Quando o produto
não é mais necessário ou tornou-se obsoleto, seu ciclo de vida termina e ele é retirado
de operação.

Qualidade e Usabilidade de Software 23

 1 Qualidade de software

2. Os requisitos descrevem ou expressam as características de um dado produto de

software, podendo ser funcionais ou não funcionais. Requisitos funcionais são aque-
les que determinam o comportamento do produto de software de acordo com uma
situação específica, enquanto os requisitos não funcionais quantificam aspectos des-
se produto, como, por exemplo, desempenho, disponibilidade ou portabilidade.
Os requisitos precisam ser especificados em um documento específico, no qual se
deve detalhar os requisitos explícitos e os requisitos normativos.

3. Os erros relativos ao processo estão relacionados com processos informais ou pro-

cessos oficiais rígidos e burocráticos. Os erros mais comuns são: desperdícios de
tempo antes do início do projeto; pressões por prazos otimistas e o não cumprimento
destes por serem impossíveis; falha no planejamento de projetos, em que se omitem
as estimativas de atividades como as de garantia da qualidade e a omissão da análise
de riscos; falha no método de gerir o projeto; pressa para começar a etapa de codifi-
cação; falha na subcontratação de serviços; e entrega do produto antes da hora, sem
estar pronto ou testado devidamente.

4. O modelo codifica-remenda é o mais utilizado porque, com muita frequência, um

software é desenvolvido sem um projeto adequado e sem ser documentado correta-
mente. Quando o analista ou o cliente identifica um problema, ele é corrigido sem ser
analisado, sem que se verifique se esse problema está associado a outras questões.
Assim, corrige-se um problema visível e cria-se uma trilha de erros no programa.

24 Qualidade e Usabilidade de Software

 2
Normas e padrões

Introdução

No Brasil, existe um corpo de normas nacionais baseadas em normas internacio-

nais, que buscam garantir a proteção do consumidor por meio de produtos e serviços
adequados. A adoção de padrões internacionais leva a melhores oportunidades de
comércio global e reduz a produção de itens de baixa qualidade.

Para os sistemas de gestão, a normalização também ajuda as organizações e as par-

tes interessadas em suas atividades, em diferentes níveis, com seus próprios fins. Esse
é um pré-requisito para a evolução de uma cultura de qualidade.

A seguir, são apresentadas e discutidas diferentes padronizações, suas aplicações

e sua importância para ordenações em diversos contextos, incluindo o da qualidade
de software.

Qualidade e Usabilidade de Software 25

 2 Normas e padrões

2.1 Normas e seus organismos normativos

A normalização é o processo de desenvolvimento, implementação e melhoria dos pa-

drões que se aplicam a ordens científica, industrial e econômica diferentes, para organizar
suas atividades. A Associação Americana de Teste de Materiais define padronização como o
processo de formulação e implementação de regras, numa abordagem ordenada para ativi-
dades específicas, visando a benefícios e com a cooperação de todos os envolvidos (CYBIS
et al., 2015). As grandes somas de dinheiro que os países desenvolvidos investem em orga-
nizações nacionais e internacionais de normalização são uma prova da importância dada à
padronização (VALERIANO, 2005).
A ISO (International Organization for Standardization) desenvolve normas inter-
nacionais para diversos campos da tecnologia, exceto o eletrotécnico, coberto pela IEC
(International Electrotechnical Comission), e as telecomunicações, abrangidas pela UIT
(União Internacional de Telecomunicações).
De acordo com a ISO, padronização é a atividade que visa estabelecer os problemas reais
ou potenciais, provisões para uso comum e repetido, a fim de obter um nível ótimo de orde-
nação em um dado contexto, que pode ser tecnológico, político ou econômico (WEBER, 2012).
A normalização envolve um conjunto de regras convencionais destinadas a simplificar,
unificar e especificar produtos (WAZLAWICK, 2013):
• Simplificar – procura manter apenas o estritamente necessário, seja em documen-
tos, processos, orientações etc. As próprias normas também são simplificadas para
serem facilmente assimiladas.
• Unificar – a ideia é criar um padrão para os produtos, utilizado em todas as partes
do mundo para permitir trocas internacionais.
• Especificar – procura, por meio de uma linguagem clara e precisa, identificar os
produtos, definindo-os, categorizando-os, catalogando-os e detalhando suas ca-
racterísticas, de modo a orientar o consumidor.
Em relação às normas técnicas, é importante conhecer os Organismos Nacionais de
Normalização (NSB, do inglês National Standards Body) dos países de interesse, que, em ge-
ral, possuem um centro de informação sobre normas. Os NSB têm um arquivo próprio de
padronizações de organismos nacionais, regionais e internacionais, tais como as do British
Standards Institution (BSI, ou Instituto Britânico de Normalização) e da Association Française
de Normalisation (AFNOR – Associação Francesa de Normalização). No Brasil, o organis-
mo responsável pela elaboração de normas técnicas é a Associação Brasileira de Normas
Técnicas (ABNT).
O papel dos NSB tem evoluído nas últimas décadas, com melhorias na infraestrutura
física e econômica, avanços na tecnologia da informação, implantação de melhores práticas
de fabricação, automação, transporte e mudanças em muitos aspectos que afetam o comér-
cio e a indústria, levando a um aumento acelerado no volume de transações comerciais entre
os países (SOMMERVILLE, 2011).

26 Qualidade e Usabilidade de Software

 Normas e padrões 2
Com a globalização, a média das áreas das organizações consideradas sob padroniza-
ção foi estendida para incluir sistemas de gestão, indústrias de serviços e novas tecnologias
que não existiam até a segunda metade do século XX (PRESSMAN; MAXIM, 2016).
Os padrões são utilizados cada vez mais para apoiar os regulamentos técnicos, e mais
direcionados para tecnologias convergentes e de rápido desenvolvimento, direcionados a
uma ampla gama de partes interessadas (PFLEEGER, 2004). Novos produtos reguladores,
com períodos mais curtos de desenvolvimento, são uma tentativa, por parte da comunidade
normativa, para responder às exigências de governos, empresas e consumidores em todo o
mundo (LAUDON; LAUDON, 2004).
Assim, as atividades de padronização tornaram-se mais complexas e mais importantes
para o desenvolvimento nacional e internacional. A criação da Organização Mundial do
Comércio (OMC), em 1995, levou ao desenvolvimento de vários acordos na área, em espe-
cial o Acordo sobre Barreiras Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas
Sanitárias e Fitossanitárias, ao qual todos os membros da OMC devem aderir (CAIÇARA
JR., 2007). Esses acordos são uma tentativa de reduzir o impacto das normas e regulamenta-
ções usadas como barreiras técnicas ao comércio entre os países (CYBIS et al., 2015).

2.2 Normas ISO e modelos CCMI

2.2.1 ISO
As normas ISO são amplamente respeitadas e aceitas internacionalmente pelos setores
público e privado (CAIÇARA JR., 2007). A International Organization for Standardization, ou
ISO, é uma organização não governamental, uma federação de organismos nacionais de
normalização de todas as regiões do mundo, incluindo países desenvolvidos e países em
desenvolvimento (MARSHALL JR. et al., 2012).
Cada membro da ISO possui uma agência principal de normalização em seu próprio
país. Os países-membros propõem as novas normas, envolvem-se em seu desenvolvimento
e prestam apoio, divididos em grupos técnicos, em conjunto com a Secretaria Geral da ISO,
localizada em Genebra, na Suíça (PRESSMAN; MAXIM, 2016).
O termo ISO tem raiz grega, significando igual, igualdade, o qual dá nome à organização,
que também coincide com sua sigla. Esse é um significado muito adequado a essa entidade,
uma federação internacional independente com o propósito de proporcionar sistemas uni-
formes de segurança, qualidade e eficiência do trabalho para trocas simples, entre países e
regiões, de bens e serviços produzidos (PRESSMAN; MAXIM, 2016).
O ano de 1945 foi fundamental para a história da entidade, pois os delegados do Comitê
Coordenador de Padronização das Nações Unidas (UNSCC) se reuniram em Nova Iorque
para tentar criar uma organização de padrões, fundando as bases para a ISO (PRESSMAN;
MAXIM, 2016). Ela foi estabelecida em 1946, com a participação de 64 delegados, de 25
países, em Londres, Inglaterra, na sede do Instituto de Engenheiros Civis. Essas pessoas

Qualidade e Usabilidade de Software 27

 2 Normas e padrões

decidiram aventurar-se no projeto de uma organização cujo objetivo seria facilitar a indus-
trialização e as regras de unificação e melhoria da coordenação internacional das empresas
(CAIÇARA JR., 2007).
Em 27 de fevereiro de 1947, a ISO foi finalmente oficializada e iniciaram-se suas ope-
rações. Naquele ano, mais de 19.500 normas foram criadas para todos os setores de produ-
ção, incluindo o setor da saúde, a indústria de alimentos, a de tecnologia etc. (PRESSMAN;
MAXIM, 2016).
Em 1987, surge a norma ISO 9000, com a finalidade básica de facilitar ainda mais o
comércio global. Para chegar a um consenso sobre essa legislação, foi necessário o apoio de
75% dos países que a compõem. Essa política baseia-se em dois pilares: melhoria e desempe-
nho, enraizada em princípios, incluindo mercados, regulação, melhorias, responsabilidade,
desenvolvimento do intelecto etc. A partir de 1994, foi implementada a versão ISO 9001,
quando ela se tornou mais interessante para as empresas (CAIÇARA JR., 2007).
A norma passou por um enorme crescimento desde então. A norma de 1994 era es-
pecificamente dirigida a empresas com processos de produção e, portanto, na revisão de
2000 (ABNT, 2000), ela foi simplificada e tornou-se aplicável a todos os tipos de empresas,
públicas ou privadas.
A versão atual do padrão é datada de 2015 – a ISO 9001:2015 (ABNT, 2015), um aperfei-
çoamento de sua edição anterior, de 2008 – ISO 9001:2008 (ABNT, 2008). A fim de validar a
implementação dessa norma, faz-se necessária uma auditoria de certificação e aplicação das
regras de qualidade, e, se a conformidade for constatada, é emitido um certificado à empre-
sa (MARSHALL JR. et al., 2012).
Em relação à engenharia de software, a NBR ISO/IEC 9126-1 é a atual padronização
mundial de qualidade de produtos, propondo métricas e atributos para os produtos de
software (ABNT, 2003). Sob o título geral Engenharia de Software – qualidade do produto, essa
norma abrange, em suas três partes, o modelo de qualidade a ser adotado, as métricas in-
ternas e as métricas externas – características e subcaracterísticas do produto de software.

2.2.2 CMMI
O Capability Maturity Model Integration (CMMI) foi criado pelo SEI (Software Engineering
Institute), um órgão de pesquisa da universidade norte-americana Carnegie Mellon, e con-
siste em um modelo de garantia de qualidade com enfoque voltado para a capacidade de
maturidade de processos de software nas empresas.
Em 1984, o SEI começou a pesquisa para desenvolver um quadro de melhoria e
avaliação da qualidade das empresas de desenvolvimento de software que fornecem
serviços para o Departamento de Defesa dos Estados Unidos. O resultado da investi-
gação foi chamado de Capability Maturity Model Software (SW-CMM), um modelo de
maturidade de capacidades desenvolvido para processos relacionados com a produção
e manutenção de sistemas de software, que teve sua versão 1.0 publicada em agosto de
1991 (MARSHALL JR. et al., 2012). Posteriormente, como resultado do feedback gerado

28 Qualidade e Usabilidade de Software

 Normas e padrões 2
pela comunidade de software, novas versões alteraram e acrescentaram uma série de
elementos na CMM, principalmente em relação a sua institucionalização nas organiza-
ções. Assim, o SW-CMM pode ser usado para dois fins (CAIÇARA JR., 2007):
• Melhorar os processos relacionados com a produção e manutenção de software;
• Definir critérios para a determinação do nível de maturidade de uma organização
que produz e mantém software.
Com o passar do tempo e a evolução do modelo CMM, estabelece-se o CMMI, que teve
como um de seus propósitos unir vários modelos usados em conjunto dentro de organiza-
ções, em prol de melhorias de processo (CAIÇARA JR., 2007), como modelos de desenvol-
vimento de software (SW-CMM), sistemas de engenharia (SECM) e desenvolvimento de
produtos integrados (IPD-CMM). O CMMI serve como um guia que auxilia as empresas a
gerenciar, mensurar e monitorar produtos e serviços e contém as práticas ligadas à gestão
de projetos e de processos, à engenharia e ao suporte.
Assim, o modelo CMMI busca a melhoria contínua dos processos organizacionais, por
meio da análise e redesign, fornecendo, de acordo com Caiçara Júnior (2007):
• Uma maneira de integrar os elementos funcionais de uma organização;
• Um conjunto de melhores práticas com base em histórias de sucesso, comprova-
das por organizações com experiência em práticas de melhoria de processos;
• Uma ajuda para identificação de metas e prioridades para a melhoria dos pro-
cessos, dependendo dos pontos fortes e fracos da organização, obtidos por um
método de avaliação;
• Um suporte às empresas em atividades produtivas complexas para coordenar as
suas atividades;
• Uma referência para avaliar os processos atuais da organização.
O CMMI for Services fornece orientação para a prestação de serviços aos clientes inter-
nos e externos da organização. Em 2000, foi desenvolvido e publicado o método Requisitos
de avaliação para o CMMI, que define os elementos considerados essenciais para avaliar o
CMMI em uma empresa, e o Padrão de avaliação CMMI para melhoria de processos. Esses dois
documentos também foram atualizados como resultado do feedback da comunidade envol-
vida em CMMI, gerando a versão mais recente 1.2 do SCAMPI1 e ARC2, ambos publicados
em 2006 (CAIÇARA JR., 2007).

[Link] Níveis de maturidade e capacidade

O CMMI está dividido em cinco níveis de maturidade, que atestam o grau de evolu-
ção de uma organização em determinado momento e tem como objetivo principal guiar a
melhoria de processos das empresas. Com ele é possível gerenciar o desenvolvimento e a

1 Métodos de avaliação SCAMPI (Standard CMMI Appraisal Method for Process Improvement) são os
métodos geralmente aceitos para avaliar organizações perante os modelos CMMI (ISD BRASIL, 2017).
2 O documento de avaliação por áreas de resultado-chave ARC (Appraisal Requirements for CMMI)
descreve requisitos para diferentes tipos de avaliação, buscando uma uniformidade entre os métodos
(CARNEGIE MELLON UNIVERSITY, 2006).

Qualidade e Usabilidade de Software 29

 2 Normas e padrões

produção de software, com base em prazos e custos estabelecidos e com mais qualidade.
Esses níveis estão demonstrados na Figura 3:

Figura 3 – Níveis de maturidade do CMMI.

5 - Otimizado
Processo con-
4 - Gerenciado tinuamente
Processo previ- melhorado
3 - Definido sível e contro-
Processo lado
2 - Repetível consistente e
Processo dis- padronizado
1 - Inicial ciplinado
Processo im-
previsível e
sem controle

Fonte: Elaborada pela autora, com base em CMMI INSTITUTE, 2017.

Esses níveis de maturidade de processos de uma organização são definidos a seguir

(PRESSMAN; MAXIM, 2016):
Nível 1: Inicial
No nível 1 de maturidade, a maioria dos processos são ad-hoc e caóticos e a organização
geralmente não fornece um ambiente estável para apoiá-los. Sucessos nesse caso ocorrem
devido aos esforços para superar a concorrência e de pessoas competentes dentro da orga-
nização, e não do uso de processos comprovados. Apesar desse caos, as organizações per-
tencentes ao nível 1 frequentemente produzem os produtos e serviços que disponibilizam;
no entanto, frequentemente excedem seus orçamentos e não cumprem os seus planos. Essas
empresas têm como características a tendência a não honrar os seus compromissos, a aban-
donar processos em tempos de crise e a incapacidade de repetir seus sucessos. Ainda, nesse
nível os trabalhos são executados de modo redundante por pessoas que não compartilham
seus métodos de trabalho com toda a organização.
Nível 2: Repetível (Gerenciado)
No nível 2, o caos passa a ser ordenado, e as organizações se concentram em tarefas
diárias relacionadas com a administração. Cada projeto tem uma série de processos plane-
jados e executados em conformidade com as políticas estabelecidas. São utilizadas pessoas
qualificadas, que têm os recursos para produzir saídas controladas.
A disciplina de processo refletida pelo nível 2 de maturidade ajuda a garantir práticas
e projetos de acordo com planos documentados e tanto a produção como a prestação de
serviços são definidos. Os contratos são estabelecidos entre as partes interessadas e também
revistos quando necessário. Artefatos e serviços são devidamente controlados, satisfazendo
suas descrições específicas, padrões e procedimentos.
Nível 3: Definido
No nível 3 de maturidade, os processos são descritos em normas, procedimentos, fer-
ramentas e métodos. O conjunto de processos padrão da organização é estabelecido e con-
tinuamente melhorado, de modo consistente para toda a empresa. Os projetos são estabe-
lecidos por meio da adaptação desse conjunto de procedimentos e normas de acordo com
diretrizes específicas.

30 Qualidade e Usabilidade de Software

 Normas e padrões 2
Uma diferença importante entre os níveis 2 e 3 de maturidade é o escopo das normas:
a descrição de processos e procedimentos. No nível 2, as normas podem ser um pouco di-
ferentes em cada instância específica do processo (por exemplo, em um projeto particular).
No nível 3, padrões, descrições de processos e procedimentos em um projeto são adaptados
com base em um conjunto de processos padrão da organização para determinado projeto ou
unidade organizacional e, portanto, são mais consistentes.
Outra distinção importante é que no nível de maturidade 3 os processos são geralmente
descritos de forma mais rigorosa do que no nível 2. Um processo definido apresenta clara-
mente sua finalidade, insumos, critérios de entrada, atividades, papéis, medidas, etapas de
verificação, saídas e critérios de saída. No nível 3, os procedimentos são geridos de forma
mais proativa, compreendendo as inter-relações de atividades e medidas detalhadas do pro-
cesso, seus artefatos e serviços.
Nível 4: Gerenciado quantitativamente
No nível 4, a organização e os projetos estabelecem metas quantitativas para medir a
qualidade e o desempenho dos processos, as quais são utilizadas como critérios na gestão.
Os objetivos quantitativos são definidos com base nas necessidades de clientes, usuários
finais, organização, processos e atores. A qualidade e o desempenho das atividades são
compreendidos em termos estatísticos e tratados em todo o processo de ciclo de vida. Para
subprocessos selecionados, são recolhidas e analisadas ​​estatisticamente medidas sobre pro-
cessos de execução, as quais são incorporadas nas métricas de repositório da organização,
para apoiar a tomada de decisão.
As variações dos processos, quando ocorrem, devem ser identificadas e corrigidas na
causa raiz para prevenir futuras ocorrências de mudanças de processos.
Uma diferença importante entre os níveis 3 e 4 é a previsibilidade do desempenho do
processo. No nível 4 de maturidade, esse desempenho é controlado usando-se técnicas esta-
tísticas e quantitativas, e o processo é quantitativamente previsível; por outro lado, no nível
3 o desempenho do processo é previsível apenas qualitativamente.
Nível 5: Otimizado
No nível 5 de maturidade, uma organização melhora continuamente seus processos
com base no conhecimento das causas comuns de variação inerente a processos. Trata-se
de melhorias contínuas, incrementais e tecnológicas. Os objetivos de melhoria de processos
quantitativos para a organização são estabelecidos e continuamente revisados, sendo utili-
zados como critério de qualidade em processos.
Uma diferença importante entre os níveis 4 e 5 é o foco da variação do processo. No
nível 4 de maturidade, a organização direciona-se para encontrar as causas especiais de va-
riação e fornecer uma previsão estatística dos resultados. No entanto, os resultados podem
ser insuficientes para alcançar as metas estabelecidas. No nível 5, a organização está focada
nas causas comuns de variação de processo e modifica os procedimentos afetados para me-
lhorar o desempenho deles e atingir os objetivos quantitativos de melhoria de processos.

Qualidade e Usabilidade de Software 31

 2 Normas e padrões

O quadro a seguir explica resumidamente o que acontece em cada um desses níveis.

Quadro 1 – Características dos níveis de maturidade das organizações.

Nível Características

22 Basicamente nenhuma prática forma de gerenciamento de engenharia

de software está implantada na organização.

22 Tudo é feito à medida em que vão surgindo as necessidades.

22 O padrão usual é o não cumprimento de prazos e orçamentos

estabelecidos.
Inicial 22 A maioria das atividades são respostas a crises e não a tarefas
pré-planejadas.

22 O processo de software é imprevisível e depende totalmente da equipe

atual.

22 É impossível prever com precisão o tempo necessário para desenvol-

ver um produto ou o seu custo.

22 Já estão implantadas práticas básicas de gerenciamento de projetos de

software.

22 As técnicas de planejamento e gerenciamento se baseiam em experiên-

cias com produtos similares (daí o termo repetível).

22 Há o acompanhamento meticuloso dos cronogramas de prazo e da

Repetível planilha de custos.

22 Os gerentes identificam problemas à medida que eles vão surgindo e

tomam ações corretivas imediatas para evitar que eles se transformem
em crises.

22 Medidas tomadas durante um projeto podem ser usadas para elaborar

cronogramas e orçamentos realistas para projetos futuros.

22 O processo para a produção de software é completamente

documentado;

22 Tanto aspectos técnicos quanto gerenciais do processo são claramente

definidos.

Definido 22 São feitos esforços contínuos para melhorar o processo onde for
possível.

22 São usadas revisões para atingir as metas de qualidade de software.

22 Há a introdução de novas tecnologias, como as ferramentas CASE

para aumentar a produtividade.

32 Qualidade e Usabilidade de Software

 Normas e padrões 2
Nível Características

22 A organização estabelece metas de qualidade e produtividade para

cada projeto.
22 A qualidade e a produtividade são medidas continuamente.

Gerenciado 22 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis

das metas.
22 Controles estatísticos de qualidade são implantados para a gerência ser
capaz de distinguir o desvio esporádico de um problema significativo
nos padrões de qualidade ou produtividade.

22 Há aperfeiçoamento contínuo do processo.

22 São usadas técnicas de controle estatístico de processos e qualidade
para orientar a organização.
Otimizado 22 O conhecimento adquirido em cada projeto é utilizado em projetos
futuros.
22 O processo incorpora uma curva de realimentação positiva, resultando
em uma melhoria contínua na produtividade e na qualidade.
Fonte: Elaborado pela autora, com base em SCHACH, 2010, p. 93-94.

Dependendo do modelo de representação usada em CMMI, existem duas maneiras de

realizar a melhoria de processos. Uma delas é utilizando a representação contínua e a outra
é melhorando toda a organização, de acordo com os processos definidos. A representação
contínua se concentra em melhorar um procedimento de modo que a organização possa ser
certificada para uma área de processo, em um determinado nível de capacidade. Existem
seis níveis de capacidade ao longo dos quais os processos são associados em uma área
(Quadro 2), e cada um deles é construído sobre o nível anterior – ou seja, um processo, para
chegar a determinado nível de capacidade, deve necessariamente ter atingido um nível an-
terior (CAIÇARA JR., 2007).

Quadro 2 – Níveis de representação contínua e escalonada.

Representação contínua Representação escalonada

Nível de capacidade Nível de maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Manejado Manejado (repetível)
Nível 3 Definido Definido
Manejado quantitativamente
Nível 4 Manejado quantitativamente
(gerenciado)
Nível 5 Otimizado Otimizado
Fonte: CYBIS et al., 2015. Adaptado.

Qualidade e Usabilidade de Software 33

 2 Normas e padrões

Nos processos de representação contínua, os níveis de capacidade são delimitados da

seguinte forma:
• Nível 0 – Incompleto – um processo é chamado de incompleto quando um ou mais
objetivos da área de processo não estão em conformidade.
• Nível 1 – Realizado – é chamado de feito ou realizado o processo que satisfaz todas
as metas específicas da área de processo.
• Nível 2 – Manejado (produzido) – é designado processo de gestão quando o
projeto apresenta a infraestrutura para suportá-lo. O processo é planejado e
executado de acordo com a política da empresa, envolvendo as partes interes-
sadas, e emprega pessoas qualificadas que tenham recursos adequados para
produzir saídas controladas. É monitorado, controlado, revisto e avaliado de
acordo com sua descrição específica.
• Nível 3 – Definido – é uma adaptação do conjunto de normas da organização,
de acordo com as diretrizes da empresa, e fornece dispositivos, medidas e outras
informações para melhorar os ativos da organização.
• Nível 4 – Manejado (gerenciado) quantitativamente – é controlado usando-se
técnicas quantitativas estatísticas e outras. Metas quantitativas para a qualida-
de e o desempenho do processo são estabelecidas e utilizadas como critérios
para sua gestão.
• Nível 5 – Otimizado – otimização é a melhoria contínua do processo, com base no
entendimento de causas comuns de variação de processo. Esse processo é realiza-
do por meio de aperfeiçoamentos incrementais e usando-se a inovação tecnológica.
Na representação escalonada, um método de melhoria de processo estruturado e sis-
temático, também envolve uma graduação em estágios ou níveis. Para atingir determinado
nível, a organização precisa ter uma infraestrutura robusta, em termos de processos, para
se qualificar para o próximo nível. Por isso, a empresa pode ser classificada pelo seu nível
de maturidade, de 1 a 5, os quais são compostos por áreas de processo em que os obje-
tivos devem ser cumpridos a fim de que a organização possa ser certificada (Quadro 3)
(PRESSMAN; MAXIM, 2016).

Quadro 3 – Modelo de classificação de áreas de processos organizacionais em níveis de

maturidade.

Nível de
Área de processo Categoria
maturidade
Análise e resolução das causas Suporte 5
Análise e resolução das decisões Suporte 3
Assegurando a qualidade dos processos e produtos Suporte 2
Definição de produtos organizacionais +IPPD (OPD
Gestão de processos 3
+IPPD)

34 Qualidade e Usabilidade de Software

 Normas e padrões 2
Nível de
Área de processo Categoria
maturidade
Desenvolvimento de requerimentos Engenharia 3
Treinamento organizacional Gestão de processos 3
Administração quantitativa de projetos Gestão de projetos 3
Administração de acordo com provedores Engenharia 2
Administração de requerimentos Gestão de projetos 3
Administração de riscos Suporte 2
Administração de configuração Gestão de projetos 3
Administração integral do projeto Gestão de projetos 3
Inovação e desenvolvimento organizacional Gestão de processos 5
Integração de produto Engenharia 3
Medição e análise Suporte 2
Monitoração e controle do projeto Gestão de projetos 2
Planejamento do projeto Gestão de projetos 2
Processos orientados às organizações Gestão de processos 3
Rendimento de processos organizacionais Gestão de processos 4
Solução técnica Engenharia 3
Validação Engenharia 3
Verificação Engenharia 3
Fonte: CYBIS et al., 2015. Adaptado.

2.3 Métricas de qualidade de software

As métricas de qualidade fornecem uma indicação de que o software está em confor-

midade com as exigências implícitas e explícitas dos clientes. O principal objetivo da en-
genharia de software é produzir com uma alta qualidade. A fim de atingir esse objetivo,
os engenheiros de software devem usar medições técnicas, de modo objetivo, para avaliar
a qualidade dos modelos de análise, o código-fonte e casos de teste que foram criados por
meio da aplicação de engenharia de software (MARSHALL JR. et al., 2012).
O primeiro objetivo da equipe de projeto é o de medir os erros e defeitos. As métricas
que vêm do resultado dessas medidas fornecem uma indicação da eficácia das atividades de
controle e garantia de qualidade (PRESSMAN; MAXIM, 2016).
De acordo com Marshall Junior et al. (2012), as métricas de qualidade de software en-
globam: o resumo dos fatores que afetam a qualidade, a medida de qualidade e a eliminação
dos defeitos.

Qualidade e Usabilidade de Software 35

 2 Normas e padrões

2.3.1 Resumo dos fatores que afetam a qualidade

Marshall Jr. et al. (2012), define um conjunto de fatores de qualidade que avaliam o
software sob três pontos de vista diferentes:
• operação do produto (usá-lo);
• revisão do produto (alterando-o);
• transição do produto (modificando-o para trabalhar em um ambiente diferente).
Assim, se fornece um mecanismo para o operador do produto – ou seja, a pessoa res-
ponsável pelo desenvolvimento do software – identificar se ele atende os requisitos de qua-
lidade pré-estabelecidos.

2.3.2 Medida de qualidade

Exatidão, facilidade de manutenção, integridade e facilidade de utilização são medidas
de qualidade que fornecem indicadores úteis para a equipe do projeto (MARSHALL JR. et
al., 2012) e devem ser avaliadas pela equipe de produção e pelos gestores:
• Exatidão: é o grau em que o software executa a sua função.
• Manutenção: é a facilidade com que um programa pode ser corrigido se um erro
de sistema, seja de código ou de requisitos, for encontrado.
• Integridade: mede a capacidade de um sistema para resistir a ataques (acidentais e
intencionais) à sua segurança. Os ataques podem ser executados em qualquer um
dos três componentes de software – programa, dados e documentos3.
Para medir a integridade, é preciso definir dois atributos adicionais: ameaça e se-
gurança. Ameaça é a probabilidade de que um ataque dê certo em determinado
momento. Já a segurança é a probabilidade que o sistema tem de repelir um ataque
de certo tipo.
• Facilidade de uso: é uma tentativa de quantificar o quão amigável pode ser o pro-
grama para o usuário.

2.3.3 Eliminação dos defeitos

É o entendimento dos principais defeitos presentes nos projetos de software – como er-
ros na gestão, prazos curtos, erros de código –, com o objetivo de avaliá-los e eliminá-los, de
modo a garantir o controle de qualidade em todas as atividades do processo (MARSHALL
JR. et al., 2012).
As métricas de qualidade, portanto, são fundamentais nos processos de desenvolvi-
mento de softwares, pois auxiliam no monitoramento e no controle da qualidade, por meio
de testes que ajudam a prever erros e a corrigir defeitos que, por ventura, possam surgir.

3 A documentação de software consiste em manuais gerais e técnicos ou mesmo relatórios que expli-
cam o funcionamento do programa ou sistema e acompanham o produto, explicando ao cliente como
utilizá-lo e suas características.

36 Qualidade e Usabilidade de Software

 Normas e padrões 2
Ampliando seus conhecimentos

O texto a seguir trata sobre a importância de as empresas de desenvol-

vimento de software terem certificações na área de tecnologia, pois estas
não apenas garantem qualidade de processos e produtos, como também
atraem clientes.

Gestão da qualidade
(SILVA; AZEVÊDO, 2015, p. 100-101)

A gestão da qualidade de software tem como objetivo normatizar e rever

periodicamente os conceitos e métodos utilizados por uma empresa,
garantindo melhoria e correções nos processos de desenvolvimento, com
base em estudos e estatísticas minuciosas. A área acompanha todos os
processos de construção dos softwares: modelagem de negócio, e licita-
ção de requisitos, análise e designer do projeto, implementação, testes,
implantação, gerenciamento de configuração e mudança, gerenciamento
de projeto e ambiente.

A área da qualidade trabalha de acordo com as normas da ISO 9001, ISO

9002 e ISO 9003. Apesar de muitos acharem que o procedimento de certifi-
cação de uma empresa de tecnologia é muito diferente das empresas indus-
triais, os profissionais vêm mostrando que não. As fábricas de softwares
são os grandes exemplos disso, pois as mesmas têm se preocupado com a
focalização nos clientes, abordagem dos processos, envolvimento dos sta-
keholders, comprometimento da liderança, relação com os fornecedores e
a melhoria contínua dos processos.

Muitos clientes que prezam por mais confiabilidade nos contratados bus-
cam empresas que sejam certificadas na área. Hoje são diversas as certifi-
cações, onde cada uma atende necessidades específicas do negócio.

As mais conhecidas da área de tecnologia são: CMMI e [Link]. Para se

certificar, a empresa precisa atender algumas exigências e demonstrar
maturidade nos processos de produção. Essas certificações além de darem
um peso maior ao currículo da empresa, atraem clientes que buscam por
parceiros com maior qualidade nos processos.

A área da qualidade se responsabiliza pela garantia do cumprimento dos

processos e pela melhoria dos mesmos — melhoria contínua. O produto é
visto como consequência da execução desses processos. Apesar dos esfor-
ços serem voltados para o processo, o principal objetivo é garantir um
produto final que satisfaça o cliente.
[...]

Qualidade e Usabilidade de Software 37

 2 Normas e padrões

Atividades
1. Explique em que as normas para os sistemas de informações auxiliam os processos
e como é seu uso.

2. O que é SW-CMM e como ele pode ser usado?

3. Como é possível avaliar os fatores que afetam a qualidade de software?

4. Quais são os cinco níveis de maturidade de uma organização?

Referências
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO [Link] Sistemas de Gestão da
Qualidade: requisitos. Rio de Janeiro, 2000.
______. NBR ISO/IEC 9126-1: Engenharia de Software: qualidade de produto. Rio de Janeiro, 2003.
______. NBR ISO [Link] Sistemas de Gestão da Qualidade: requisitos. Rio de Janeiro, 2008.
______. NBR ISO [Link] Sistemas de Gestão da Qualidade: requisitos. Rio de Janeiro, 2015.
CAIÇARA JUNIOR, C. Informática, internet e aplicativos. Curitiba: Ibpex, 2007.
CARNEGIE MELLON UNIVERSITY. CMMI para Desenvolvimento – versão 1.2. ago. 2006. Disponível
em: <[Link] Acesso
em: 3 ago. 2017.
CMMI INSTITUTE. Disponível em: <[Link]
tion>. Acesso em: 19 jul. 2017.
CYBIS, W. et al. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 3. ed. São Paulo:
Novatec, 2015.
ISD BRASIL. O que é SCAMPI? Disponível em: <[Link]
Acesso em: 3 ago. 2017.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. São Paulo: Pearson Prentice Hall,
2004.
MARSHALL JR., I. et al. Gestão da qualidade e processos. Rio de Janeiro: Ed. da FGV, 2012.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São
Paulo: AMGH Bookman, 2016.
SCHACH, S. R. Engenharia de software: os paradigmas clássico e orientado a objetos. Tradução de A.
Griesi. 7. ed. Porto Alegre: AMGH, 2010.
SILVA, R. B. C; AZEVÊDO, L. S. L. A importância da engenharia de testes para a qualidade de softwa-
re. Revista Eletrônica Científica Inovação e Tecnologia, v. 2, n. 12, jul./dez. 2015.

38 Qualidade e Usabilidade de Software

 Normas e padrões 2
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011. Disponível
em: <[Link] Acesso em: 26 jan. 2017.
VALERIANO, D. Moderno gerenciamento de projetos. São Paulo: Pearson Prentice Hall, 2005.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2012.

Resolução
1. As normas para os sistemas de gestão ajudam as organizações na gestão de suas ati-
vidades. O uso generalizado de normas é um pré-requisito para a evolução de uma
cultura de qualidade. A normalização inclui o desenvolvimento e o estabelecimento
de padrões e fornece informações sobre eles para as partes interessadas, em vários
níveis. Empresas, associações profissionais e consórcios podem desenvolver padrões
para os seus próprios fins.

2. SW-CMM (Capability Maturity Model Software) é um modelo de maturidade de capa-

cidades desenvolvido para processos relacionados com a produção e manutenção de
sistemas de software. Assim, pode ser usado para dois fins:

• Melhorar os processos relacionados com a produção e manutenção de software.

• Definir critérios para a determinação do nível de maturidade de uma organização
que produz e mantém software.

3. Sob três pontos de vista:

• operação do produto (usá-lo);
• revisão do produto (alterando-o);
• transição do produto (modificando-o para trabalhar em um ambiente diferente).

4. Inicial, repetível, definido, gerenciado e otimizado.

Qualidade e Usabilidade de Software 39

 3
Influência dos requisitos na
qualidade do software

Introdução

O processo de análise e verificação das necessidades de um cliente/usuário1 para

o desenvolvimento de um sistema é chamado de engenharia de requisitos. O objetivo da
engenharia de requisitos é entregar um software correto e completo, de acordo com
especificações predeterminadas.

Os requisitos são a peça fundamental para um projeto de desenvolvimento de

software com qualidade, que exige planejamento e recursos. Os líderes do projeto utili-
zam os requisitos de base para estimar os recursos necessários à criação de um software.

Assim, os requisitos são a base para a decisão sobre como um produto será execu-
tado, ou seja, a base do ciclo de vida de um projeto. Disso decorre a sua importância na
definição e gestão de processos.
1 Em alguns casos, cliente e usuário são a mesma pessoa, mas também podem ser pessoas diferentes. Cliente é
a pessoa ou grupo que requisita o software a ser desenvolvido e fornece os requisitos básicos do produto, além
de coordenar os recursos financeiros para o projeto. Já usuário é uma pessoa ou grupo que vai realmente usar o
software construído (PRESSMAN; MAXIM, 2016, p. 111).

Qualidade e Usabilidade de Software 41

 3 Influência dos requisitos na qualidade do software

3.1 Processos de negócio

As empresas se diferenciam entre si pela sua capacidade de organização e de processos

de negócio. Cada empresa utiliza um procedimento específico para chegar ao resultado de-
sejado, relacionando-o ao produto-fim da empresa. Para um desenvolvimento de software,
por exemplo, é fundamental o levantamento dos processos do negócio da empresa para que,
no futuro, sejam desenvolvidas tecnologias que auxiliem em sua gestão.
Um processo de negócio consiste em um conjunto de tarefas ou atividades que são
executadas de acordo com certas regras relacionadas a determinados objetivos. Trata-se de
uma série de tarefas individuais, e cada uma delas é executada em uma ordem específica.
Para entender a importância do processo de negócio para a construção de um software,
é importante primeiro avaliar com o cliente a sua necessidade, saber exatamente o que ele
deseja no produto solicitado para se ter uma ideia aproximada das funções que o software
deverá apresentar (WEBER, 2006). Com essa informação, os analistas preparam um estudo
detalhado sobre a viabilidade do sistema desejado e avaliam a possibilidade de desenvolvê-
-lo (VALERIANO, 2005).
Esse estudo de viabilidade centra-se no objetivo do projeto, pois analisa os requisitos
do software para a sua implementação, a contribuição do projeto para a organização e os
limites de custo, sempre de acordo com os valores da empresa (VALERIANO, 2005).
Se esse estudo de viabilidade for positivo, a próxima fase começa com a coleta deta-
lhada dos requisitos, por meio de uma entrevista com o cliente/usuário. Analistas e enge-
nheiros comunicam-se com os clientes/usuários para conhecer as ideias destes sobre os re-
sultados que o software deve fornecer e quais as características que devem ser incluídas
(VALERIANO, 2005).

3.1.1 Requisitos de software

Como visto no Capítulo 1, os requisitos incluem necessidades quantificadas e documen-
tadas, desejos e expectativas do patrocinador, dos stakeholders2 e dos clientes (VASQUEZ;
SIMÕES, 2016) em relação ao software encomendado.
De acordo com a definição do glossário do IEEE3, os requisitos do software são
(VASQUEZ; SIMÕES, 2016, p. 18):
1. Uma condição ou capacidade do sistema, solicitada por um usuário, para re-
solver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que deve ser atendida por uma solução para sa-
tisfazer um contrato, especificação, padrão ou quaisquer outros documentos
formais impostos.

2 Stakeholders são as partes interessadas no negócio, todas as pessoas ou grupos que atuam direta ou
indiretamente na gestão e/ou nos resultados da organização.
3 Instituto de Engenheiros Eletricistas e Eletrônicos: organização fundada nos EUA, sem fins lucrati-
vos, dedicada ao avanço da tecnologia no mundo.

42 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
3. Documentação da representação das condições ou capacidades apresentadas
nos dois itens anteriores.
4. Uma condição ou capacidade que deve ser alcançada ou possuída por um sis-
tema, produto, serviço, resultado ou componente para satisfazer um contrato,
padrão, especificação ou outro documento formalmente imposto.
Os requisitos devem apresentar uma série de características, tanto individualmente
como em grupos. Estas são as características mais importantes dos requisitos de software
(VALERIANO, 2005):
• Necessário – Um requisito deve ser necessário. A sua omissão causa uma defi-
ciência no sistema, afetando a sua capacidade, suas características físicas. Quando
o cliente/usuário aponta a necessidade de um requisito, é preciso verificar quão
necessário ele realmente é ao software. Se for um elemento apenas estético, por
exemplo, não se trata de um requisito.
• Conciso – Um requisito é conciso se é fácil de ler e compreender. A sua redação
deve ser simples e clara para aqueles que vão consultá-lo, sejam os clientes ou ou-
tros desenvolvedores, no futuro. Um documento muito extenso acaba dificultando
o processo, pois sua leitura e interpretação demandam mais tempo.
• Completo – Um requisito é completo quando não necessita de mais detalhes na
sua formulação, ou seja, a informação disponibilizada é suficiente para sua com-
preensão e para o desenvolvimento do software.
• Consistente – Os dados apresentados devem ser confiáveis e seguros, possíveis de
serem realizados e integrados de forma consistente, ou seja, um requisito não pode
contradizer outro nem se propor a fazer a mesma coisa.
• Inequívoco – Os requisitos devem ser claros e não permitir mais de uma inter-
pretação (não podem ser ambíguos), pois isso poderia acarretar diversos erros
no sistema.
• Verificável – Um requisito é verificável quando ele é palpável, pode ser cons-
truído, testado, rastreado e homologado; não é apenas uma ideia que só pode
existir no papel.
Os requisitos de software são a descrição das características e funcionalidade do
objetivo (target) do sistema, de modo a comunicar expectativas dos consumidores de
produtos de software. Podem ser óbvios ou ocultos, conhecidos ou desconhecidos, es-
perados ou inesperados (VALERIANO, 2005). Isso significa que nem sempre o cliente/
usuário tem claros os requisitos, daí a necessidade de o gestor do projeto, juntamente
com os analistas, orientar o cliente/usuário, de modo a conseguir informações mais com-
pletas sobre o produto que vão desenvolver.
Para expressar os requisitos do software, as sentenças devem ser claras, exprimindo
objetivamente a ação a ser realizada.
O exemplo a seguir, apresentado por Vazquez e Simões (2016), demonstra o caso de
especificação de requisitos para um software voltado ao controle de entradas e saídas de
visitantes em um edifício/condomínio.

Qualidade e Usabilidade de Software 43

 3 Influência dos requisitos na qualidade do software

No primeiro caso, o requisito não foi especificado adequadamente, visto que não há
uma caracterização da ação principal a ser realizada, incluindo cláusulas adicionais, em um
único texto:

Identificador: RF001 Requisito: Controle de Portaria

Para realizar o controle de entrada e saída na portaria, deve ser realizado o cadastro do
visitante através dos seguintes atributos: Nome, Registro Geral e Imagem. Caso a visita
tenha sido liberada pelo condomínio, então podem ser registradas a data e a hora em que
o visitante acessou a portaria. Ao sair do condomínio, devem ser registradas a data e a
hora em que o visitante saiu, mas só deve ser permitido para visitante com registro de
entrada e sem registro de saída.
Fonte: VAZQUEZ; SIMÕES, 2016, p. 203.

Já no segundo caso, o mesmo texto foi reformulado e dividido em diferentes sentenças,

que especificam o passo a passo das ações a serem cumpridas:

Identificador: RF001 Requisito: Manter Cadastro de Visitante

O condômino cadastra o visitante registrando Nome e Registro Geral.

Identificador: RF002 Requisito: Liberar Acesso de Visitante
O condômino cadastra a liberação de acesso selecionando um visitante já cadastrado e
indica o período (data e hora e início e data e hora de fim) para realizar a visita.

Identificador: RF003 Requisito: Registrar Entrada de Visitante

O porteiro ou guarda verifica se a documentação apresentada pelo visitante confere com

dados apresentados na liberação de aceso (Nome do Visitante e Registro Geral) e registra
a data e a hora em que o visitante entrou no condomínio.
Fonte: VAZQUEZ; SIMÕES, 2016, p. 204.

Verifica-se, assim, que esse detalhamento dos requisitos realizado no segundo caso ga-
rante que os procedimentos sejam seguidos corretamente.
Desse modo, a engenharia de requisitos é responsável por documentar os requisitos, de
acordo com as exigências do cliente/usuário, como apresentado a seguir.

3.1.2 Engenharia de requisitos

O processo de análise e levantamento das necessidades dos clientes é conhecido como parte
integrante da engenharia de requisitos. O objetivo dessa área da engenharia de software é desen-
volver e manter um sistema documentado de especificação de requisitos que contemple todas as
informações necessárias, de forma concisa, clara e descritiva (VALERIANO, 2005).
A engenharia de requisitos facilita a interação com o cliente/usuário em termos de iden-
tificar e entender o que ele necessita e na obtenção de um acordo acerca da solução que será
entregue. Assim, ela descreve e integra tarefas, técnicas, orientações, papéis e responsabilidades
em fluxos de trabalho, que têm início com o entendimento da necessidade do cliente e passa pelo
acordo sobre a solução que será construída, conforme apresentado na Figura 1:

44 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
Figura 1 – O contexto da engenharia de requisitos.

Requisitos
plano de projeto e acompanhamento –
Gerência de escopo, orçamento e prazo
Projetos
necessidades do Análise e projeto da solução
cliente
cliente projeto

projeto do banco de dados

acordos sobre Implementação
a entrega
material de treinamento e de
Implantação suporte ao usuário
Facilita a interação
com o cliente
estimativas e medições
Medição e análise

Testes casos de teste

equipe

Fonte: VASQUEZ; SIMÕES, 2016, p. 12.

Desse modo, a engenharia de requisitos contempla uma das partes do estudo da enge-
nharia de software, sendo necessária às etapas de gerência de projetos, análise de projeto,
implementação, implantação, medição e análise e testes. Como se pode observar na Figura 1,
a engenharia de requisitos medeia todo o processo entre o cliente/usuário e a equipe de de-
senvolvimento, fazendo a interação entre eles.
O desenvolvimento dos requisitos geralmente passa pelas seguintes fases (MARSHALL
JR. et al., 2012):
• Análise de problemas – identificar stakeholders, obter concordância em relação ao
problema que eles possuem, identificar fronteiras e restrições ao sistema e elaborar
o documento de visão.
• Avaliação e negociação – processo de avaliação e negociação de melhorias com o
cliente ou stakeholder.
• Especificação – processo que tem como objetivo obter produtos de software de me-
lhor qualidade, que satisfaçam às reais necessidades dos clientes dentro de prazo
e orçamento adequados.
• Validação – processo que tem como objetivo a validação da consistência e do con-
texto dos requisitos levantados no processo de identificação.
• Evolução – processo em que se compreende a situação inicial do problema, os re-
quisitos iniciais, o entendimento do problema modificado e os requisitos que são
alterados ao longo do tempo do projeto.
• Princípios de especificação – processo de representação dos requisitos do cliente,
especificando a funcionalidade da implementação, identificando o comportamen-
to desejado do sistema e o modo pelo qual outros componentes do sistema inte-
ragem com o software.

Qualidade e Usabilidade de Software 45

 3 Influência dos requisitos na qualidade do software

Essas fases não seguem com rigor essa ordem e uma mesma fase pode se repetir algu-
mas vezes durante o projeto, mas todas estão presentes quando se trata de desenvolvimento
de requisitos de software.

3.2 Os requisitos e a comunicação

Os requisitos são o ponto de concordância entre o cliente e o projeto de desenvolvimen-

to de software. Esse entendimento é necessário para construir um software que atenda às
necessidades do cliente/usuário. Se os requisitos são descritos de forma a focar nas neces-
sidades do cliente/usuário, então é preciso que o gestor do projeto primeiro obtenha essa
informação, por meio de entrevistas ou recolhendo documentação que descreva o software
desejado pelo cliente/usuário (PRESSMAN; MAXIM, 2016).
As necessidades dos clientes evoluem com o tempo, e toda mudança envolve um custo.
Por isso é necessário ter uma cópia da documentação do sistema original e de cada revisão
ou alterações feitas nesse documento. Como todas as necessidades são tratadas de forma
diferente, é necessário classificá-las para saber qual delas vai ser satisfeita pelo software ou
algum outro produto do sistema (PFLEEGER, 2004).
A especificação de requisitos de software é a atividade em que o documento é gerado
com um nome específico, contendo uma descrição completa das necessidades e capacidades
do sistema que será desenvolvido. Esse documento descreve o escopo4 do sistema e como
serão suas funções, como, por exemplo, definir os requisitos funcionais e não funcionais
(PRESSMAN; MAXIM, 2016).

3.2.1 Especificação de requisitos

Segundo Vasquez e Simões (2016, p. 18), “a especificação de requisitos é um contrato entre
clientes e equipe de desenvolvimento. Ela deve esclarecer aos clientes o que será entregue como
produto do trabalho da equipe de desenvolvimento”. Com base na especificação, os clientes/
usuários devem ser capazes de entender o projeto e apontar falhas nele para que sejam corrigi-
das imediatamente, antes que o produto comece a ser produzido com defeitos. Desse modo, os
riscos de erros na execução são menores e a garantia de satisfação do cliente/usuário é maior.
Portanto, são objetivos da especificação de requisitos (VASQUEZ; SIMÕES, 2016):
• documentar de forma correta e fidedigna todas as necessidades do cliente/usuário;
• obter aprovação (aceite) sobre tudo o que está sendo proposto para se entregar em
termos de produto;
• ajudar a equipe de desenvolvimento a compreender exatamente o que os clientes/
usuários desejam;
• servir de base para o trabalho de manutenção futura no sistema.

4 Escopo é a descrição de tudo o que é preciso ser feito para se alcançar os objetivos do projeto, incluin-
do recursos e funções desejados.

46 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
A especificação de requisitos, portanto, é um importante instrumento de comunicação
entre os clientes/usuários e a equipe de desenvolvimento. Contudo, ela deve ser orientada
ao cliente e não à equipe, embora seja útil também para esta. A especificação nem sempre é
um único documento, mas a composição de vários documentos.
Segundo Vasquez e Simões (2016), uma especificação de requisitos geralmente apresenta:
• Visão geral – em que se apresenta os objetivos do projeto, as partes interessadas e
o escopo preliminar com as funções descritas brevemente.
• Glossário – definição dos termos técnicos e de siglas usados no documento.
• Modelos de sistema – em que se mostra o relacionamento entre os componentes
do sistema.
• Lista de requisitos funcionais – em que se descreve as tarefas executadas pelo
sistema e as interfaces externas do software.
• Os requisitos funcionais “definem as funcionalidades e o comportamento do siste-
ma, mediante cada entrada, ou seja, é aquilo que descreve o que o sistema tem que
fazer a cada ação de um usuário ou outro sistema” – por exemplo, o sistema deve
“cadastrar médicos profissionais (entrada)” ou “emitir um relatório de clientes
(saída)”.
• Lista de requisitos não funcionais – em que se descreve as restrições impostas
sobre o software, relacionando-as aos requisitos funcionais.
Os requisitos não funcionais “dizem respeito às características e padrões de qua-
lidade que o sistema deve oferecer, como, por exemplo, desempenho, confiabili-
dade, segurança, robustez, portabilidade, usabilidade, entre outros” (MARINHO,
2015). Desse modo, seriam exemplos de requisitos não funcionais casos em que
o sistema avisa o usuário quando ele tenta fazer uma operação ilegal (confia-
bilidade) ou quando se propõe a imprimir um relatório em até cinco segundos
(desempenho).
• Especificação detalhada de requisitos – detalhamento dos requisitos funcionais.
Todos os requisitos de hardware e software, diagramas, modelos e quaisquer outros sis-
temas de informação contemplados na especificação servem como um suporte e guia para as
fases subsequentes desse processo, como o desenvolvimento propriamente dito do produto
e os testes finais. É importante reforçar que a especificação de requisitos é o resultado final
das atividades de análise e avaliação de requisitos; desse modo, o documento resultante
será usado como fonte básica de comunicação entre clientes, usuários finais, analistas de
sistemas, testadores e todos os envolvidos na implementação do sistema (PFLEEGER, 2004).
Assim, os clientes e usuários usam as especificações de requisitos para comparar se
o que está sendo proposto está de acordo com as necessidades da empresa. Analistas e
programadores usam os requisitos para determinar o produto a ser desenvolvido, e a
equipe de desenvolvimento prepara testes funcionais com base nesse documento. Para o
gerente de projeto, os requisitos servem como referência e controle da evolução do sistema
(PFLEEGER, 2004).

Qualidade e Usabilidade de Software 47

 3 Influência dos requisitos na qualidade do software

3.2.2 Dificuldades na definição de requisitos

Segundo Pressman e Maxim (2016), entre as dificuldades na definição de requisitos,
estão: suas exigências não são óbvias e podem vir de várias fontes; os requisitos são difíceis
de expressar em palavras (a linguagem é ambígua); não são muitos os tipos de requisitos e
há diferentes níveis de detalhe; o número de requisitos em um projeto pode ser difícil de ma-
nusear; e eles nunca são iguais – alguns são mais difíceis, mais arriscados, mais importantes
ou mais estáveis do que outros.
Existem, ainda, dificuldades para quantificá-los, uma vez que cada conjunto de requi-
sitos é específico para cada projeto, e cada requisito tem propriedades únicas que incluem
áreas funcionais específicas. Muitas vezes eles estão relacionados uns aos outros, e, assim,
referem-se a outras partes do processo. Além disso tudo, um requisito pode mudar ao lon-
go do ciclo de desenvolvimento, sendo necessário rever o projeto como um todo, devido à
integração de requisitos.
Também há os requisitos que estão na expectativa do usuário, porém não estão docu-
mentados. Esses requisitos são chamados de requisitos implícitos e, como visto no Capítulo 1,
são totalmente indesejados, porém podem ser minimizados por meio de uma boa especifica-
ção – ou seja, detalhando-se bem os requisitos explícitos e normativos (VALERIANO, 2005).
O segredo para que todas as falhas do processo sejam minimizadas está na elaboração
da especificação de requisitos. Se essa fase for bem realizada e documentada, se o cliente/
usuário tiver claros os requisitos funcionais e os não funcionais e fizer uma boa análise das
falhas existentes na especificação, as chances de o software ser desenvolvido sem surpresas
desagradáveis são bem maiores.
Para tanto, é preciso que a comunicação entre as partes interessadas flua sem ruídos,
que a entrevista seja direta e planejada, que os gestores estudem com os analistas as solici-
tações feitas pelo cliente/usuário e prevejam todos os empecilhos e dificuldades que possam
vir a surgir durante o desenvolvimento do software. O texto da especificação precisa ter o
nível de detalhamento adequado (sem exageros, mas também não tão conciso a ponto de
gerar ambiguidades) e ser escrito tendo em vista o cliente/usuário e não um expert de tecno-
logia. Portanto, o documento precisa ser escrito em uma linguagem adequada, sem jargões
técnicos que dificultam a compreensão de um leitor leigo. No caso de termos técnicos ne-
cessários, precisam vir sempre acompanhados de um glossário. Esse documento precisa ser
compreendido sem interferência externa, de modo que o cliente possa lê-lo e interpretá-lo
sem auxílio e se sinta à vontade para interferir nele a ajustá-lo de acordo com as suas ne-
cessidades. O uso de uma linguagem inadequada, muito técnica, pode frustrar e assustar o
cliente, impedindo-o de interagir com o projeto de forma adequada.
A relação com o cliente/usuário precisa ser construída com respeito e confiança entre
as partes. É preciso ter muito tato com o cliente para não criar barreiras na comunicação.
Para tanto, é preciso que o gestor de projetos seja um bom ouvinte e esteja em sintonia com
o cliente para compreender suas necessidades em relação ao projeto.

48 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
3.3 Qualidade de requisitos de software

Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de

conformidade5 com os requisitos significa falta de qualidade.
A ISO 9001:2008 especifica requisitos para um sistema de gestão da qualidade, quando
uma organização (CYBIS et al., 2015):
a. precisa demonstrar sua capacidade de fornecer de forma consistente produtos6 que
atendam aos requisitos do cliente e requisitos regulamentares aplicáveis; e
b. pretende aumentar a satisfação do cliente por meio da aplicação eficaz do sistema,
incluindo processos para sua melhoria contínua e a garantia de conformidade com
os requisitos do cliente.
Nesse contexto, os requisitos são o primeiro passo para se atingir a qualidade e serão
avaliados durante os testes, nos quais é possível verificar se estão sendo atendidos ou não.
A Figura 2 aponta um grande equívoco em relação ao esforço para se obter qualidade no
processo de desenvolvimento de um software.

Figura 2 – Ciclo de desenvolvimento no qual a qualidade se resume a testes de software.

Esforço
para obter
qualidade

Modelo de Análise e Implemen- Testes de Disponibi-

Requisitos
negócios modelagem tação software lização

Tempo
Fonte: BARTIÉ, 2002, p. 25.

Embora a qualidade possa ser avaliada durante a fase de testes, é um equívoco concen-
trar os esforços para obtenção da qualidade apenas nessa fase do projeto, tendo em vista que
a qualidade deve percorrer todas as etapas de desenvolvimento. Se isso não for feito desde
o início, os erros tendem a migrar de uma etapa para a outra, onerando todo o processo.
Portanto, a “qualidade não é uma fase do ciclo de desenvolvimento de software [...] é parte
de todas as fases” (BARTIÉ, 2002, p. 25), como representado na Figura 3.

Figura 3 – Garantia da qualidade de software em todo o ciclo de desenvolvimento.

Processo de garantia da qualidade de software

Modelo de Análise e Implemen- Testes de Disponibi-

Requisitos
negócios modelagem tação software lização

Tempo
Fonte: BARTIÉ, 2002, p. 27.

5 Segundo as ABNT NBR ISO/IEC 17000:2005, conformidade é a “demonstração de que os requisi-

tos especificados relativos a um produto, processo, sistema, pessoa ou organismo são atendidos”
(INMETRO, 2017).
6 Nessa norma, o termo produto aplica-se apenas para o produto destinado a um cliente ou por ele
solicitado, ou, nesse caso em específico, o software (PFLEEGER, 2004).

Qualidade e Usabilidade de Software 49

 3 Influência dos requisitos na qualidade do software

Qualidade de software é a conformidade a requisitos funcionais e de desempenho ex-

plicitamente declarados, a padrões de desenvolvimento claramente planejados e comuni-
cados, à especificação e documentação dos requisitos e às características implícitas que são
esperadas de todo software desenvolvido por profissionais (PRESSMAN, 2016).
Assim, os padrões especificados definem um conjunto de critérios de desenvolvimento que
orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se tais crité-
rios não forem definidos, o resultado muito provavelmente será a falta de qualidade do software.
Desse modo, como observado, a tarefa de análise de requisitos é um processo de desco-
berta e refinamento; assim, durante o sistema de engenharia, os softwares são melhorados
em cada detalhe.
A análise e especificação de requisitos podem parecer uma tarefa relativamente sim-
ples, mas requerem muito detalhamento e trabalho. Uma vez que o conteúdo da comunica-
ção é muito diversificado, há muitas alterações devido a equívocos ou falta de informação.
Os requisitos de um sistema de software, quando vistos como um todo, são extensos e
contêm múltiplas relações. Para se obter a capacidade de especificar esses sistemas comple-
xos com os detalhamentos simples e concisos de documentos, o novo sistema deve ser capaz
de realizar a sua classificação e organização.
Na busca da qualidade, o engenheiro deve refinar o mapeamento do software e, a partir
desse ponto, desenvolver a estrutura dos dados, a arquitetura e o design processual. Finalmente,
a especificação de requisitos fornece apoio à equipe de desenvolvimento e ao cliente/usuário,
assim como dispõe os meios para avaliar a qualidade dos sistemas, uma vez já construídos.

3.3.1 Requisitos de qualidade

A especificação, independentemente da forma como é feita, pode ser vista como um
processo de fusão dos requisitos dos clientes com os requisitos do software e os requisitos
de qualidade. Os requisitos são representados de modo a levar a uma implementação bem-
-sucedida do software.
Definir com precisão os requisitos de um software permite que todos os recursos
da empresa e a energia da equipe de desenvolvimento sejam direcionados a um
fim claro. Sem uma definição precisa daquilo que se pretende construir, perde-
-se tempo, mais erros são cometidos e a qualidade do produto final é incerta.
(KOSCIANSKI; SOARES, 2007, p. 172)
Os requisitos de qualidade de software, segundo Wazlawick (2013), devem fazer parte
da própria especificação do produto. Geralmente são requisitos definidos para o software
todo – são suplementares – e não para cada função específica. Eles precisam ser avaliados
de acordo com o grau de necessidade do produto e depois de uma análise financeira do
projeto, para se verificar se o investimento compensa. Afinal, a qualidade também tem um
custo, e o investimento compensa quando ela baixa os custos com falhas, por exemplo. Isso
não significa que a qualidade deixará de ser uma meta em todas as etapas do processo, mas
é preciso considerar que existem níveis de qualidade e que qualidade não é sinônimo de
perfeição, mas de algo que atende às necessidades do cliente/usuário de forma satisfatória.

50 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
Por exemplo, ao se identificar um risco à qualidade do software (em relação à confia-
bilidade), como a indisponibilidade do sistema ao usuário, é possível dividir a análise em
subcategorias, como mostra o Quadro 1.

Quadro 1 – Subcategorias do requisito confiabilidade.

Risco R001 – indisponibilidade do sistema para o usuário

Características Subcaracterísticas Objetivo Questão Métrica
Avaliar a
capacidade
Quantas falhas foram
de prevenção Número de falhas
detectadas durante
Maturidade de falhas do detectadas/número
um período definido
sistema do de casos de testes
de experimentação?
ponto de vista
do usuário.
Número de ocorrên-
cias de falhas sérias e
Quantos padrões de críticas evitadas confor-
defeitos são mantidos me os casos de testes
sob controle para evitar de indução de falhas/
falhas críticas e sérias? número de casos de
testes de indução de
falhas executados
Tempo de operação
(tempo de operação +
tempo de reparo)
Total de casos em
Confiabilidade Quão disponível é que o sistema estava
o sistema para uso disponível e foi
Avaliar a durante um período utilizado com sucesso
Tolerância disponibilidade de tempo específico? pelo usuário / número
a falhas de do sistema do total de casos em que
recuperabilidade ponto de vista o usuário tentou usar
do usuário. o software durante um
período de tempo.

Qual é o tempo médio

em que o sistema fica Tempo ocioso total
indisponível quando (indisponível)/número
uma falha ocorre, antes de quedas do sistema
da inicialização?
Soma de todos os
Qual o tempo médio tempos de recuperação
que o sistema leva do sistema inativo em
para completar cada oportunidade/
a recuperação número total de ca-
desde o início? sos em que o sistema
entrou em recuperação
Fonte: WAZLAWICK, 2013, p. 248.

Qualidade e Usabilidade de Software 51

 3 Influência dos requisitos na qualidade do software

Ampliando seus conhecimentos

Problemas de comunicação afetam o desenvolvimento de qualquer pro-

jeto. O texto a seguir é uma metáfora de como esses problemas podem
acarretar interpretações equivocadas e soluções inadequadas e até mesmo
estranhas para projetos muito simples. Nesse sentido, uma especificação
bem-feita e documentada de requisitos pode evitar muitos mal-entendidos.
(KOSCIANSKI; SOARES, 2007, p. 172- 173)

Há uma ilustração que conta a história de desenvolvimento de um pro-

duto de software, comparando-a com a instalação de um balanço em uma
árvore. Trata-se de uma anedota conhecida entre programadores e analis-
tas de sistemas.

Tudo começa quando um cliente procura uma empresa dizendo precisar

de um software. O analista de sistemas o escuta com toda a atenção e faz
uma série de perguntas. Posteriormente, ele escreve durante alguns minu-
tos e faz um primeiro esboço do que o cliente descreveu. Supondo que
este não consiga expressar corretamente suas necessidades em relação ao
programa, o analista acrescenta um toque pessoal, de maneira a cobrir
certas lacunas. Afinal, por falta de conhecimentos de informática, o cliente
tem dificuldades para explicar o que precisa.

Posteriormente, em uma reunião com a equipe da empresa, o analista

expõe suas anotações. O gerente do projeto decide fazer algumas modi-
ficações para reduzir o cronograma inicial e cortar os custos de imple-
mentação. A documentação toda passa, em seguida, para o analista. Ele
percebe que algumas das simplificações efetuadas pelo gerente retiraram
funções que seriam provavelmente essenciais para o cliente. Assim, faz
algumas adaptações com base em sua própria experiência sobre o assunto
e projeta a solução a ser implementada.

Finalmente, o projeto completo é entregue ao programador. Ao analisar

as especificações, ele descobre estar diante de um software que lhe cus-
tará muito trabalho. Um dos princípios de bom projeto é a reutilização
de código: partes de programas que foram anteriormente desenvolvidos
e estão funcionando corretamente podem ser empregadas para construir
novos programas. O programador efetua, então, alguns pequenos ajustes
nas especificações, permitindo que partes de outros projetos possam ser
aproveitadas. Com isso, o trabalho será concluído antes e o programador
terá mais tempo para efetuar testes.

52 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
Uma vez que cada pessoa envolvida na construção do software contri-
buiu efetuando uma “pequena” modificação, a cada estágio a especifi-
cação do produto acabou diferente da existente no estágio anterior. Tal
situação é ilustrada na figura. O projeto seria um balanço em uma árvore.
Cada parte da figura mostra como uma das pessoas envolvidas pensava
no produto: não existia um acordo entre elas. Por erros de comunicação
e falta de rigor ao seguir aquilo que foi estabelecido na etapa anterior, o
produto acabou diferente a cada nova fase. A sequência da figura repre-
senta o que foi pedido ao analista pelo cliente, o que o gerente do projeto
planejou, o que o analista projetou e o que foi realmente implementado
pelo programador.
Figura – Uma caricatura dos problemas de comunicação na produção
de software.

Fonte: Autoria desconhecida.

Considerando a situação em que as características de um produto não

estão escritas em nenhum documento e são transmitidas apenas oral-
mente, há muita possibilidade de que sejam compreendidas de diversas
maneiras por diferentes indivíduos. O pior é que é muito provável que as
informações sejam simplesmente esquecidas.

[...]

Atividades
1. As empresas possuem processos de negócios iguais? Justifique sua resposta.

2. Defina requisitos funcionais e não funcionais.

3. O levantamento de requisitos é um processo isolado de TI que conta com a participa-

ção apenas dos profissionais dessa área? Justifique sua resposta.

4. Qual é o equívoco representado na figura a seguir em relação ao esforço para se ob-

ter qualidade no processo de desenvolvimento de um software?

Qualidade e Usabilidade de Software 53

 3 Influência dos requisitos na qualidade do software

Figura – Ciclo de desenvolvimento no qual a qualidade se resume a testes

de software.
Esforço
para obter
qualidade

Modelo de Análise e Implemen- Testes de Disponibi-

Requisitos
negócios modelagem tação software lização

Tempo

Fonte: BARTIÉ, 2002, p. 25.

Referências
BARTIÉ, A. Garantia da qualidade de software: adquirindo maturidade organizacional. Rio de
Janeiro: Elsevier, 2002.
CAIÇARA JUNIOR, C. Informática, internet e aplicativos. Curitiba: Ibpex, 2007.
CYBIS, W. et al. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 3. ed. São Paulo:
Novatec, 2015.
GANDARA, F. Qualidade e teste em software. São Paulo: Clube dos Autores, 2012.
INMETRO – Instituto Nacional de Metrologia, Qualidade e Tecnologia. Avaliação da conformidade.
Disponível em: <[Link] Acesso em: 25 jul. 2017.
KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: aprenda as metodologias e técnicas
mais modernas para o desenvolvimento de software. São Paulo: Novatec, 2007.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. São Paulo: Pearson Prentice Hall,
2004.
MARINHO, J. J. Análise e desenvolvimento de requisitos em histórias em quadrinhos. Parte 2: a obs-
cura diferença entre requisitos funcionais e requisitos não funcionais. TI Especialistas, 18 nov. 2015.
Disponível em: <[Link]
-em-historias-em-quadrinhos-parte-2-obscura-diferenca-entre-requisitos-funcionais-e-requisitos-nao-
-funcionais/>. Acesso em: 7 ago. 2017.
MARSHALL JUNIOR, I. et al. Gestão da qualidade e processos. Rio de Janeiro: Ed. da FGV, 2012.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São
Paulo: AMGH Bookman, 2016.
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011.
VALERIANO, D. Moderno gerenciamento de projetos. São Paulo: Pearson Prentice Hall, 2005.
VASQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado ao negócio. Rio de
Janeiro: Brasport, 2016.
WAZLAWICK, R. S. Análise de sistemas de informações orientados a objetos. Rio de Janeiro:
Elsevier, 2011.
______. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2006.

54 Qualidade e Usabilidade de Software

 Influência dos requisitos na qualidade do software 3
Resolução
1. Não. As empresas se diferenciam entre si pela sua capacidade de organização e pro-
cessos de negócio. Cada empresa utiliza um processo de negócio para chegar ao seu
resultado e assim tem seus processos otimizados e relacionados aos seu produto-fim.

2. Os requisitos funcionais definem as funções que o sistema será capaz de executar e

descrevem as transformações que o sistema executa nas entradas para produzir saí-
das. Requisitos não funcionais têm a ver com as características que podem limitar o
sistema, tais como: desempenho (tempo e espaço); interfaces de usuário; fiabilidade
(robustez, disponibilidade de equipamentos); manutenção; segurança; portabilidade
e normas; entre outros.

3. Não, pois o correto levantamento de requisitos é um processo cooperativo. Para que

a especificação gerada seja mais fiel à realidade, é necessário haver comprometimen-
to de todas as partes envolvidas em um projeto de desenvolvimento de software.

4. O erro apontado na figura é que há um esforço para obter qualidade no desenvolvi-

mento do software apenas na fase de testes do produto, quando deveria estar pre-
sente em todas as fases do projeto, inclusive na fase de especificação de requisitos.

Qualidade e Usabilidade de Software 55

 4
Processo de
desenvolvimento de
software

Introdução

Desenvolvimento de software contempla todo o processo de programação de com-

putadores, documentação, testes, correção de bugs1 e de erros envolvidos na criação e
na manutenção de aplicativos e estruturas, resultando em um produto de software,
que deve seguir as especificações documentadas.

O desenvolvimento de software envolve escrever e manter o código fonte, mas,

em um sentido mais amplo, inclui todas as etapas envolvidas entre a concepção do
software desejado até o produto final, dentro de um processo planejado e estruturado.
1 “Bug – erro, defeito, falha de funcionamento. (1) Erro de software ou hardware. O termo vem dos primórdios da
informática, quando um defeito em computador era causado por um inseto. (2) Equívoco ou funcionamento defeituo-
so. (3) Equívoco ou erro cometido durante a fase de elaboração de um programa. Pode ser do tipo sintático ou lógico.
No primeiro caso tem origem na codificação defeituosa na linguagem simbólica de programação utilizada e costuma
ser detectado durante o processamento de compilação, que permite determinar a natureza do erro e corrigi-lo por
diversos métodos. Os erros de tipo lógico obedecem a um planejamento errôneo da solução do problema e não são
detectáveis pela máquina que realiza corretamente os cálculos, embora os resultados obtidos não sejam válidos.”
(SAWAYA, 1999, p. 60).

Qualidade e Usabilidade de Software 57

 4 Processo de desenvolvimento de software

Portanto, esse processo pode incluir pesquisa, desenvolvimento, prototipagem2, modi-

ficação, reutilização, reengenharia, manutenção e demais atividades que resultem na pro-
dução do software.
O software pode ser desenvolvido para uma variedade de propósitos, sendo o mais
comum atender às necessidades de um cliente ou negócio específico. Assim, supre uma ne-
cessidade percebida de algum conjunto de usuários potenciais de software de código aberto,
ou, então, para uso pessoal, por exemplo, no caso de um pesquisador ou, então, de um em-
presário que precisa de um software específico para automatizar uma tarefa. O software do
sistema está implícito nas aplicações e no próprio processo de programação, sendo muitas
vezes desenvolvido em paralelo.

4.1 Ciclo de desenvolvimento de software

O desenvolvimento de software, também chamado de ciclo de vida de desenvolvimento de

software, é aplicado especificamente para produtos de estrutura de software (WEBER, 2006).
Umas das partes cruciais de um projeto de software é a boa escolha de seu ciclo
de vida, pois não sabendo escolhê-lo bem, o projeto pode acabar em decadência.
Portanto, esta etapa do levantamento bibliográfico é dedicada a esse assunto,
lembrando que para a escolha do ciclo de vida, ele deve atender no mínimo as
características principais do projeto. (GODOI NETO et al., 2017, p. 4)
Existem vários modelos para a criação e desenvolvimento de um ­software, e cada um
deles descreve uma abordagem diversa para diferentes atividades que ocorrem durante o
processo (WAZLAWICK, 2013).
O ciclo de desenvolvimento apresentado por Yourdon (1989 apud REZENDE, 2005,
p. 42) é dividido em etapas, a fim de projetar e desenvolver um produto de software de for-
ma eficiente: estudo de viabilidade; análise de sistemas; projeto; implementação; geração do
teste de aceite; garantia da qualidade; descrição de procedimentos; conversão de banco de
dados; instalação. Essas etapas são apresentadas a seguir.
• Estudo de viabilidade – identifica as deficiências atuais, estabelece objetivos do
novo sistema; gera cenários aceitáveis; prepara encargos de projeto.

2 “A prototipagem é o processo de construir um sistema experimental rapidamente e a baixo custo

para demonstração e avaliação, de modo que os futuros clientes ou usuários do sistema possam me-
lhor determinar os requerimentos dele.” (REZENDE, 2005, p. 134).

58 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
• Análise de sistemas – desenvolve o modelo ambiental; desenvolve o modelo com-
portamental; estabelece os limites homem-máquina; executa a análise custo-bene-
fício; seleciona opção; restringe o sistema; faz a especificação do pacote.
• Projeto – aloca especificações para os processadores; aloca especificações às tare-
fas; deriva o diagrama estrutural; avalia o diagrama estrutural; projeta módulos;
projeta banco de dados; faz o empacotamento do projeto.
• Implementação – soluciona o próximo módulo; codifica o módulo; testa o esque-
leto do sistema.
• Geração do teste do aceite – gera plano de teste; prepara testes de performance;
prepara testes de vias normais; prepara testes de vias de erro; empacota os testes.
• Garantia da qualidade – faz o teste final ou teste de aceite, comparando o produto
ao projeto de implementação.
• Descrição dos procedimentos – faz descrições das atividades operacionais do
cliente ou usuário.
• Conversão de banco de dados – pode envolver mais trabalho e planejamento do
que desenvolvimento de programas para o novo sistema e, em outros casos, pode
não haver uma base de dados para ser convertida.
• Instalação – atividade final; suas entradas são o manual do usuário, o banco de
dados convertido e o sistema de aceite.
Modelos de ciclo de vida de desenvolvimento de software são muito discutidos na lite-
ratura e se diferenciam pelo grau de controle aplicado sobre o processo e por sua visibilida-
de ao cliente (CYBIS et al., 2015). A seguir, vejamos os ciclos de vida mais usados e de que
modo eles influenciam na qualidade do software a ser desenvolvido.

4.1.1 Codifica-remenda ou codificar-e-corrigir

Segundo Schach (2010), infelizmente, ainda muitos produtos são desenvolvidos seguin-
do esse ciclo de vida. É o modelo menos profissional de todos, em que o software vai sendo
desenvolvido sem que haja um projeto nem o levantamento das necessidades do cliente/
usuário e das especificações.
Nesse modelo, a equipe de desenvolvimento faz o software da forma como acredita que
deve ser feito e depois o retrabalha quantas vezes forem necessárias até que o cliente fique
satisfeito (SHACH, 2010). Na Figura 1 é possível verificar a ausência do levantamento de
necessidades e especificações.

Qualidade e Usabilidade de Software 59

 4 Processo de desenvolvimento de software

Figura 1 – Modelo de ciclo de vida codifica-remenda.

Implementar a
primeira versão

Modificar até que

o cliente fique satisfeito

Manutenção pós-
-entrega

Desenvolvimento Descontinuação
Manutenção do produto

Fonte: SCHACH, 2010, p. 50.

Ainda segundo Shach (2010), esse ciclo de vida até pode vir a funcionar bem em pro-
gramas menores e mais simples, mas é inviável para programas maiores, pois seu custo e
seu tempo de desenvolvimento aumentam consideravelmente, além de exaurir a equipe e o
cliente em testes sem fim.
Outro problema apontado pelo autor é que a falta de especificações atrapalha na manu-
tenção do software depois de pronto e entregue ao cliente. Embora esse modelo seja consi-
derado o mais fácil para desenvolver software, é, de longe, o pior deles.

4.1.2 Cascata
Esse modelo de ciclo de vida, também chamado de clássico ou linear, foi proposto por
Winston Royce, no ano de 1970. É um ciclo de vida que eventualmente suporta iterações3; con-
tudo, basicamente é um modelo pouco flexível, com muitas restrições. Isso porque se caracteriza
por progredir de forma sequencial entre uma fase e a seguinte, e essa sequencialidade acaba
causando diversos problemas ao desenvolvimento do software e afetando sua qualidade.
Um ponto crítico referente ao modelo cascata é que nenhuma fase é terminada
até que a documentação para essa fase tenha sido completada e os produtos
dessa fase tenham sido aprovados pelo grupo de SQA (garantia da qualidade de
software). Isso acarreta modificações; se os produtos de uma fase anterior tive-
rem de ser modificado como consequência de se seguir uma volta de realimen-
tação, essa fase anterior é considerada completa apenas quando a documentação
para ela tiver sido modificada e as modificações tiverem sido verificadas pelo
grupo de SQA. (SCHACH, 2010)
O modelo de ciclo de vida cascata tem a vantagem de possuir pontos de controle que
permitem demarcar as fases do processo, facilitando a gestão do projeto e a manutenção

3 Iterações são ciclos curtos, que têm duração de poucas semanas, garantindo dessa forma feedbacks
frequentes e respostas rápidas às mudanças. Segundo Martins (2010), “em cada iteração, uma parte
do software é produzida. Ao final de cada iteração é possível avaliar o progresso do projeto e, dessa
forma, o software é produzido incrementalmente, à medida em que as iterações ocorrem.

60 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
do software depois de pronto, devido ao controle da documentação. Porém, ele é rígido e
burocrático, porque não permite a correção de erros nas fases anteriores e possui baixa visi-
bilidade para o cliente, pois este não recebe feedback nos pontos de controle existentes; assim,
o único resultado que o cliente vê é o final.

Figura 2 – Exemplo típico de modelo em cascata.

Requerimentos

Desenvolvimento

Implementação

Verificação

Produção

Fonte: TORRES, 2014.

Como mostra a Figura 2, no modelo em cascata o andamento do processo flui de cima

para baixo, como uma cascata, e o progresso de uma fase para a próxima se dá de forma se-
quencial. Somente quando uma fase está completa e perfeita pode-se seguir para a próxima,
não existindo sobreposição de fases ou mesmo a possibilidade de pular a execução de uma
fase. No entanto, na realidade o desenvolvimento de um software não ocorre dessa forma,
pois muitas atividades são desenvolvidas paralelamente.
As etapas do modelo em cascata são apresentadas a seguir:
• Requisitos – etapa na qual se estabelecem os requisitos do produto que se deseja
desenvolver, os serviços a serem fornecidos, limitações e objetivos do software. Essa
etapa pode ser vista como a etapa de concepção de um produto ou software.
• Desenvolvimento – é o processo de passos do projeto que representa os requisitos
de uma forma que permita a codificação do produto. É o projeto documentado
para que se transforme em software.
• Implementação – é a etapa em que são criados os programas.
• Verificação – é a etapa de testes do sistema. Após a codificação concluída, começa a
fase de testes e verificação do sistema. Essa fase examina se foram solucionados os
erros de software e assegura que as entradas produzam resultados reais conforme
os requisitos que foram descritos.
• Produção – etapa de aprovação para que o sistema entre em produção; para isso,
todas as fases e testes devem ter sido realizados e a coleta de aprovações dos usuá-
rios e envolvidos no projeto deve ser feita para se colocar o sistema em produção.

Qualidade e Usabilidade de Software 61

 4 Processo de desenvolvimento de software

Apesar de todos os seus problemas, o modelo cascata foi empregado durante muitos
anos. Atualmente, no entanto, tem sido pouco utilizado devido à complexidade cada vez
maior dos produtos desenvolvidos (SCHACH, 2010).

4.1.3 Modelo V
Esse modelo de ciclo de vida foi concebido por Alan Davis e contém as mesmas etapas
do ciclo de vida em cascata, sendo considerado uma variação deste, como se pode observar
na Figura 3.

Figura 3 – Modelo V.

Modelagem Teste
de requisitos de aceitação

Projeto da Teste
arquitetura de sistema

Projeto Teste
de componente de integração

Geração Teste de
de código unidade

Software
executável
Fonte: PRESSMAN; MAXIM, 2016, p. 43.

Segundo a figura, o projeto segue de forma sequencial e linear até a geração de códigos
(lado esquerdo do V) e, a partir daí, a equipe passa para o outro lado do V, realizando testes
que validam cada fase do lado esquerdo. Segundo Pressman e Maxim (2016, p. 42), “não há
nenhuma diferença fundamental entre o ciclo de vida clássico e o modelo V”.
Além das abordagens clássicas, há outros modelos de ciclo de vida chamados evolu-
cionários, que são basicamente iterativos e possibilitam o desenvolvimento de versões mais
completas dos softwares. O ciclo de vida em espiral e o modelo de prototipagem evolutiva
são os mais comuns.

4.1.4 Espiral
Modelo de ciclo de vida em que um produto é desenvolvido em diversas iterações.
Uma iteração nova representa uma volta na espiral. Sua vantagem é que permite a constru-
ção de produtos com prazos curtos e a sua desvantagem é que ele é mais difícil de ser gerido
(WAZLAWICK, 2003). A Figura 4 apresenta um exemplo de ciclo de vida em espiral:

62 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
Figura 4 – Modelo em espiral.
Custo acumulativo
Progresso
1. Determinar obje- 2. Identificar e
tivos resolver riscos

Análise
de riscos
Análise
de riscos
Plano de Análise de riscos
Revisão requeri- Protótipo Protótipo
mentos Protótipo 1 2 operacional
Conceito Conceito de
de operação Requeri- Requeri-
mentos mentos Esboço Desenho
Plano de detalhado
desenvolvimento Verificação
e validação
Código
Plano de Verificação
testes e validação Integração
Testes
Entrega Implementação

4. Planejar a próxima iteração 3. Desenvolvimento e testes

Fonte: TORRES, 2014.

No modelo em espiral, as atividades são realizadas no sentido horário, partindo do

centro da espiral e passando por quatro quadrantes. A fase 1 corresponde à determinação
dos objetivos e soluções alternativas, além das restrições do sistema. Na fase 2, devem ser
analisados os riscos das decisões da fase anterior, quando podem ser construídos protóti-
pos e realizadas simulações do software. Na fase 3, de desenvolvimento de testes, estão as
atividades de desenvolvimento, incluindo design, especificação, codificação e verificação.
A principal característica dessa fase é que cada especificação vai ressurgindo a cada ciclo
– especificação de requisitos, do software, da arquitetura, da interface de usuário e algorit-
mos, devendo ser feita a verificação correta. Na fase 4, de planejar a próxima iteração, estão
as revisões das etapas anteriores e o planejamento da próxima fase. Nessa etapa, dependen-
do dos resultados obtidos nas fases anteriores, pode-se optar por seguir o desenvolvimento
no modelo cascata, por exemplo, ou optar pela construção de novos protótipos.
Cada circuito em volta da espiral pode representar uma iteração, como explicam
Pressman e Maxim (2016, p. 48):
O primeiro circuito em volta da espiral pode resultar no desenvolvimento de
uma especificação de produto; passagens subsequentes em torno da espiral po-
dem ser usada para desenvolver um protótipo e, então, progressivamente, ver-
sões cada vez mais sofisticadas do software. Cada passagem pela região de pla-
nejamento resulta em ajustes no planejamento do projeto. Custo e cronograma
são ajustados de acordo com o feedback (a realimentação) obtido do cliente após a
entrega. Além disso o gerente de projetos faz um ajuste no número de iterações
planejadas para concluir o software.
Para esses autores, o modelo espiral é mais realista para o desenvolvimento de
softwares, pois o software evolui aos poucos e os riscos são avaliados a cada nível evolucionário.
A prototipação pode ser aplicada em qualquer estágio, reduzindo os riscos e solucionando os
problemas à medida que eles surgem.

Qualidade e Usabilidade de Software 63

 4 Processo de desenvolvimento de software

4.1.5 Prototipagem evolutiva

Também chamada de prototipação4, utiliza o modelo de ciclo de vida em espiral para
construir o produto em protótipos, que cobrem progressivamente os requisitos até a finali-
zação do produto. Sua vantagem é que possui visibilidade, permitindo a verificação ante-
cipada do produto final e a correção dos problemas detectados. Além disso, apresenta alta
flexibilidade, por permitir ajustes durante o desenvolvimento do produto. Como desvan-
tagens, esse método precisa de equipes disciplinadas e experientes, o projeto deve ser bem
realizado para que a estrutura do produto permaneça confiável ao longo dos protótipos e ele
é mais difícil de ser gerido (WAZLAWICK, 2003).

Figura 5 – Prototipagem evolutiva.

Planejamento
rápido
Comunicação

Modelagem
Projeto rápido

Entrega e
feedback Construção
de protótipo

Fonte: PRESSMAN; MAXIM, 2016, p. 45.

O ciclo da prototipação começa com a fase de comunicação, coleta e refinamento dos

requisitos. As fases seguintes são: o planejamento rápido, a modelagem rápida (na qual é
desenvolvido o protótipo) e a construção do protótipo. Por fim, a fase de implantação, en-
trega e feedback finaliza o ciclo.
Segundo Pressman e Maxim (2016), esse modelo funciona bem quando o cliente não
tem claros os requisitos e os detalhes do software de que necessita. O protótipo construído
ajuda tanto o cliente como a equipe de desenvolvimento a entender melhor o produto que

4 Segundo o Dicionário de informática e internet, prototipação consiste na “criação de um modelo fun-

cional [protótipo] de um novo sistema de computador ou programa, para testes e refinamentos.
A prototipação costuma ser utilizada no desenvolvimento de novos sistemas de hardware e softwares,
e também em novas aplicações de gerenciamento de informações. As ferramentas utilizadas nos dois
primeiros casos incluem equipamentos e programas de apoio.” (SAWAYA, 1999, p. 375).

64 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
vão criar. Esse protótipo pode ser descartado por não representar o desejo do cliente ou
pode evoluir até se transformar no produto final.

4.1.6 Entrega evolutiva

Esse modelo de ciclo de vida é uma combinação dos modelos cascata e prototipagem
evolutiva. Apresenta a vantagem de ter alta visibilidade para os clientes e facilidade de
gestão, por possuir pontos de controle bem definidos. Sua desvantagem é a necessidade
de um projeto robusto para que a estrutura do produto permaneça confiável ao longo das
liberações programadas (CYBIS et al., 2015).
O objetivo da entrega evolutiva é obter o máximo de feedback do cliente sobre o que foi
entregue, de modo que a próxima entrega seja planejada de acordo com esse feedback recebi-
do, garantindo mais agilidade e qualidade ao produto. Segue-se o mesmo ciclo da prototipa-
gem evolutiva, com a diferença que as entregas referem-se a partes do software ou sistema.
Conhecer os diversos ciclos de vida de software existentes permite à organização esco-
lher o melhor modelo para desenvolver um projeto, de acordo com as necessidades do clien-
te/usuário e a capacidade de produção da organização. Mesmo que a empresa decida por
não desenvolver, mas terceirizar a produção de software, ela tem que ter competência para
gerir os processos de aquisição, implantação, adaptação e integração desses sistemas com
a organização. Isso pode sair mais caro do que o processo de desenvolvimento em si, daí a
importância de entender esses processos para fazer a melhor escolha (VALERIANO, 2005).

4.2 Garantia da qualidade do software

A garantia de qualidade do software é obtida por meio de processos de engenharia de

software de monitorização e aplicação de métodos de qualidade, que ocorrem por meio de
intervenções da gestão de qualidade no sistema de software que está sendo criado. Essas
intervenções são apoiadas por uma ou mais normas, geralmente a ISO 9000 (WAZLAWICK,
2003).
A qualidade do software é o conjunto de qualidades que caracterizam e determinam a
sua utilidade e existência. Qualidade é sinônimo de eficiência, flexibilidade, precisão, con-
fiabilidade, facilidade de manutenção, portabilidade, usabilidade, segurança e integridade.
A qualidade do software é, portanto, mensurável e varia de um sistema para outro ou de
um programa para outro. Como afirma Valeriano (2005, p. 88), “a qualidade do software é o
grau em que um sistema, componente ou processo atende aos requisitos especificados e às
necessidades e expectativas do cliente ou do usuário”.
A qualidade do software engloba os requisitos e os padrões atendidos, como demons-
trado na Figura 6.

Qualidade e Usabilidade de Software 65

 4 Processo de desenvolvimento de software

Figura 6 – Software com qualidade.

Processo de
software
Processo de
desenvolvi-
Usuário Desenvolvedor Organização Requisito mento Padrões

Requisitos Padrões Software

Software com qualidade atendidos atendidos produto

Fonte: Elaborada pela autora.

De acordo com a Figura 6, verifica-se que os elementos usuário, desenvolvedor e

organização devem, em conjunto, traçar os requisitos para o desenvolvimento do soft-
ware, que deve atender a alguns padrões (normas) para que possa ser considerado um
software de qualidade.
O Software Quality Assurance, ou SQA, é um conjunto de atividades sistemáticas e pla-
nejadas para garantir que os processos de software e produtos cumpram com os requisitos,
as normas e os procedimentos de processo de produtos, design de software, documentação
de codificação, suporte de teste e manutenção (SOMMERVILLE, 2011).
Com o SQA, a qualidade não é apenas responsabilidade da equipe de desenvolvimento
do projeto, mas é medida por uma série de testes de qualidade. Esses testes foram inicial-
mente desenvolvidos pela indústria militar durante a década de 1970, nos Estados Unidos,
e foram se difundindo e aprimorando até se tornar o SQA (PRESSMAN; MAXIM, 2016).
Segundo Pressman e Maxim ( 2016), o SQA inclui: uma abordagem de gestão da qua-
lidade; engenharia de software; revisões técnicas formais aplicadas durante o processo de
software; um teste de estratégia multiescalada; um software de controle de documentos e
mudanças; e um procedimento para garantir um ajuste ao desenvolvimento de padrões
de software.
A finalidade da garantia de qualidade é dotar a gestão com dados necessários sobre a
qualidade do produto, por isso a aquisição da qualidade deve cumprir sua visão e objetivo
(CAIÇARA JR., 2007).
Assim, o SQA dá visibilidade aos processos utilizados pelo projeto e os produtos que
ele gera. Para Pressman e Maxim (2016), entre os objetivos da SQA, estão: realizar atividades
de planejamento de garantia de qualidade; avaliar e auditar os produtos e atividades para
verificar sua conformidade com os procedimentos e as normas; e fornecer os resultados des-
sas revisões ou auditorias de relatórios de gestão.
Cabe aos gestores trabalhar com a equipe do projeto desde o início; eles devem ser obje-
tivos e independentes e ajudar no projeto, em vez de apenas controlar as atividades.
O processo de verificar se as normas estão sendo aplicadas corretamente pode ser feito
pela equipe de desenvolvimento, no caso de pequenos projetos, mas, nos grandes projetos,
um grupo específico deve se dedicar a essa função (ISNARD, 2012).

66 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
4.2.1 Vantagens do SQA
Um plano SQA pode tomar uma série de caminhos, testando-se diferentes capacidades
e análises de execução, dependendo das exigências do projeto, dos usuários e do software.
Deve buscar (PRESSMAN; MAXIM, 2016) a maior satisfação dos clientes, com métodos me-
lhorados, e um bom relacionamento com eles, além do desenvolvimento do software com
custo reduzido e sem comprometer a qualidade.
Sobre a metodologia do SQA, ressalta-se que o teste de software é considerado uma
arte e uma ciência que requer a adoção de aplicações complexas para o desenvolvimento de
diferentes sistemas operacionais.
Várias aplicações de software requerem diferentes abordagens quando estão na fase
de teste, mas algumas das tarefas mais comuns de controle de qualidade incluem os passos
elencados na Figura 7:

Figura 7 – Teste de software.

Validação do teste

• O teste de validação é realizado para checar se há algum erro.

Comparação

• Compara a saída de um uso específico com um sistema de dados

previamente criado com os mesmos parâmetros.

Testes de usabilidade

• Usuários que não estão familiarizados com o software fornecem

feedback para os desenvolvedores sobre o que eles acharam difícil
de fazer. Essa é a melhor forma de realizar melhorias em uma
interface.

Fonte: SOMMERVILLE, 2011. Adaptado.

As atividades de qualidade do produto englobam a norma ISO/IEC 9126, que consis-

te na atual padronização mundial para a qualidade de software. Essa norma está baseada
em três níveis: características, subcaracterísticas e métricas, sendo que cada característica é
formada por um conjunto de subcaracterísticas e cada subcaracterística é avaliada por um
conjunto de métricas.
As características de qualidade do software devem responder aos seguintes questiona-
mentos (PFLEEGER, 2004):
• Funcionalidade – O produto satisfaz as necessidades do usuário?
• Confiabilidade – É imune a falhas?
• Usabilidade – É fácil de usar?
• Eficiência – É rápido e simples?
• Manutenibilidade – É fácil de modificar?

Qualidade e Usabilidade de Software 67

 4 Processo de desenvolvimento de software

• Portabilidade – É fácil de usar em outro ambiente?

A ISO/IEC 9126 define essas características principais da qualidade do produto da se-
guinte maneira (PFLEEGER, 2004):
Funcionalidade – trata-se de um conjunto de atributos que evidenciam a existência
de funções e suas propriedades especificadas. As funções devem satisfazer as necessidades
explícitas e implícitas para que o software seja considerado funcional.
Usabilidade – refere-se ao conjunto de atributos que evidenciam o esforço necessário
para se poder usar o software, assim como o julgamento individual desse uso, por um con-
junto explícito ou implícito de usuários. Nesse sentido, o software apresenta usabilidade se
faz com que o usuário tenha sucesso na execução das tarefas propostas pelo sistema.
Confiabilidade – é o conjunto de atributos que evidenciam a capacidade do software
de manter seu nível de desempenho, sem que ocorram falhas ou interrupções, sob condições
estabelecidas durante certo período de tempo.
Eficiência – trata-se de um conjunto de atributos que evidenciam o relacionamento
entre o nível de desempenho do software e a quantidade de recursos usados, sob condições
estabelecidas. Um software é eficiente quando atende seu objetivo sem ser complicado, de
forma simples e objetiva.
Manutenibilidade – é o conjunto de atributos que evidenciam o esforço necessário para
fazer modificações especificadas no software. Ele deve possibilitar correções e alterações
sempre que for preciso, mesmo depois de entregue ao cliente.
Portabilidade – diz respeito ao conjunto de atributos que evidenciam a capacidade do
software de ser transferido de um ambiente para outro, sem haver a necessidade de criação
de um programa semelhante para ser usado em outra plataforma.

4.3 Métodos ágeis, validações e indicadores

4.3.1 Métodos ágeis

O desenvolvimento ágil de software envolve uma abordagem para a tomada de deci-
sões em projetos da área, a qual se refere a métodos de engenharia de software. Essa aborda-
gem diz respeito a um grupo de metodologias utilizadas na criação de programas que baseia
o seu desenvolvimento em um ciclo iterativo, no qual os requisitos e as soluções evoluem
por meio da colaboração entre diferentes equipes envolvidas no projeto. Assim, o trabalho
é feito por colaboração, sendo auto-organizado por equipes multidisciplinares, envolvidas
em um processo de tomada de decisão compartilhada no curto prazo (PFLEEGER, 2004).
Métodos ágeis enfatizam mais a comunicação face a face do que a documentação em
si. Equipes mais ágeis estão localizadas em um único escritório aberto, às vezes chamado
de plataforma de lançamento. O escritório (ou a equipe) deve incluir revisores e responsáveis
pela documentação, além de designers de iteração e gerentes de projeto (PFLEEGER, 2004).

68 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
A metodologia ágil engloba, segundo Sommerville (2011):
• Valorização das pessoas e suas interações sobre processos e ferramentas – proces-
sos de qualidade com bons relacionamentos trazem bons resultados.
• Avaliação da documentação – a documentação é necessária porque permite a
transferência de conhecimento, mas sua redação deve ser limitada ao que contri-
bui ao valor direto do produto/serviço.
• Taxa de colaboração com o cliente sobre negociação de contrato – embora sejam ne-
cessários, os contratos não acrescentam valor aos produtos/serviços. Metodologias
ágeis ao cliente integram e mantêm o projeto com o objetivo de proporcionar o
maior valor possível em cada iteração.
Dos valores básicos, é possível extrair vários princípios que qualificam a filosofia da
gestão ágil (PFLEEGER, 2004), dentre os quais se destaca a busca pela satisfação do cliente
por intermédio da entrega inicial e contínua de valor, em períodos de 15 a 60 dias.
As mudanças de requisitos dentro do período mencionado são bem-vindas, para que
haja melhor integração do projeto. Uma boa comunicação entre usuário, desenvolvedor e
cliente também é essencial para o desenvolvimento do produto.
Além disso, o produto funcional (por exemplo, software operacional) é a principal me-
dida de progresso, devendo-se enfatizar o foco no grau de acabamento e no tempo de con-
clusão previsto.
As características básicas de projetos geridos com metodologias ágeis são as seguintes
(SOMMERVILLE, 2011):
• Incerteza – indica a necessidade estratégica da previsão de riscos no
desenvolvimento.
• Equipes auto-organizadas – não existem funções especializadas na equipe.
• Autonomia – liberdade para a tomada de decisão.
• Autoaperfeiçoamento – periodicamente, o produto tem de ser desenvolvido e
avaliado.
• Autoenriquecimento – conhecimento e transferência de conhecimento.
• Fases de desenvolvimento que se sobrepõem – as fases não existem como tal, mas
as tarefas/atividades são realizadas de acordo com a evolução das necessidades ao
longo do projeto. Na verdade, muitas vezes não é possível fazer um projeto técnico
detalhado antes de se começar a desenvolvê-lo e ver alguns resultados. Além dis-
so, as fases tradicionais, realizadas por pessoas diferentes, não promovem o traba-
lho em equipe e podem gerar mais desvantagens do que vantagens (por exemplo,
um atraso de fase afeta todo o projeto).
• Controle sutil – pontos de controle local para monitorar adequadamente sem limi-
tar a liberdade e a criatividade da equipe.
Além disso, recomenda-se, nesse processo: avaliar o ambiente de trabalho, sendo fun-
damental escolher pessoas que não entrem em conflito entre si; compreender os erros como
pontos de melhoria e aprendizado; e melhorar a interação entre a equipe e a organização,

Qualidade e Usabilidade de Software 69

 4 Processo de desenvolvimento de software

para que possam atender às necessidades do projeto. Também é essencial a difusão e trans-
ferência de conhecimentos, controlando a alta rotatividade dos membros da equipe entre os
diferentes projetos (PFLEEGER, 2004).
Atualmente, a metodologia ágil mais popular para gerenciamento de projetos é o
Scrum5 (MELO et al., 2013).

[Link] Scrum
O Scrum é uma metodologia cujas práticas são aplicadas em um processo iterativo e
incremental. Assume-se que os projetos em que o Scrum se insere são complexos e imprevi-
síveis, no quais não é possível prever tudo que irá acontecer. Por essa razão, ele oferece um
conjunto de práticas que torna tudo isso visível (SCHWABER, 2004), como um ciclo de vida
específico (Figura 8).

Figura 8 – Ciclo de vida do Scrum.

Daily meeting

24 horas

Tarefas de Backlog
detalhadas
pela equipe 30 dias Produto incremental
a ser entregue
Backlog da Sprint

Backlog
priorizado pelo
Product Owner

Fonte: MOUNTAIN GOAT SOFTWARE, 2017.

A estrutura de processo do Scrum inicia-se com uma visão do produto que será desen-
volvido, com a apresentação das características definidas pelo cliente, das premissas e restri-
ções. Em seguida, é criado o product backlog, a lista contendo todos os requisitos conhecidos
do produto. O product backlog é então priorizado e dividido em releases, e cada um deles
contém um conjunto de requisitos, denominado sprint backlog, que será desenvolvido em
uma iteração, chamada de Sprint (MARÇAL et al., 2007).
Na execução do Sprint, diariamente a equipe faz reuniões de 15 minutos (Daily Scrum
Meeting) para acompanhar o andamento do projeto. Ao final do Sprint, é realizado o Sprint
Review Meeting, de modo que o time apresente o resultado alcançado ao Product Owner (re-
presentante do cliente). Esse resultado recebe o nome de Increment of Potentially Shippable
Product Functionality. Em seguida, o Scrum Master, o gestor do projeto, conduz o Sprint
Retrospective Meeting, com o objetivo de melhorar a equipe, o processo ou o produto para o
próximo Sprint.

5 O livro Scrum: a arte de fazer o dobro do trabalho na metade do tempo, de Jeff Sutherland (2014), cocriador
do Scrum, é a melhor referência para ficar por dentro dessa metodologia de projetos.

70 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
4.3.2 Validações e indicadores
Para a determinação da qualidade do software a partir da perspectiva de produto aca-
bado, é necessária a avaliação de um conjunto de indicadores que respondam a diferen-
tes critérios e fatores consistentes com a estrutura da ISO 9126 – norma padrão que per-
mite a melhor adaptação e padronização dos vários processos de qualidade de software
(SOMMERVILLE, 2011).
Assim, a fim de serem validados, os indicadores devem apresentar aplicabilidade, efi-
ciência e relevância.
Para atender a esses itens, os indicadores devem ser testados e devem prezar pela segu-
rança e pela qualidade. Uma vez que o processo de avaliação foi concluído, de acordo com
diferentes fatores e critérios, os principais indicadores da qualidade do software podem ser
elencados como descrito a seguir (PFLEEGER, 2004).
A funcionalidade pode ser definida como o conjunto de critérios e indicadores cor-
respondentes relacionados com as propriedades específicas que atendem às necessidades
do cliente. A funcionalidade do software deve ter as seguintes características: adequação,
acurácia, interoperabilidade, segurança de acesso e conformidade. Por exemplo, o usuário
deve ter facilidade para utilizar o software com segurança.
Segundo Pfleeger (2004), esse indicador deve corresponder aos critérios de
• adequação – o conjunto de indicadores para assegurar que o conteúdo é adequado;
• precisão, interoperabilidade6 e segurança – sua definição está em consonância com
a função adequada que executa;
• compliance – o conjunto de indicadores para assegurar que o software está descrito
de acordo com padrões estabelecidos.
A confiabilidade é definida como um grupo de critérios e indicadores correspondentes
relacionados com a capacidade de manter o seu nível de desempenho sob condições esta-
belecidas por um período determinado (SOMMERVILLE, 2011). Por exemplo, um sistema
deve ser seguro e funcionar no tempo requerido. Precisa estar em concordância com os se-
guintes critérios (PFLEEGER, 2004):
• maturidade – deve ser compreendido como a capacidade de se repetir uma série
de resultados de maneira previsível;
• capacidade de recuperação – o conjunto de indicadores para assegurar que as pro-
priedades específicas do software, caso sejam perdidas, possam ser recuperadas;
• tolerância a falhas – o software precisa ser projetado para suportar erros e falhas,
e mecanismos de restauração devem estar disponíveis.

6 “Uma vez conseguida a conectividade, a interoperabilidade refere-se aos recursos lógicos que per-
mitem a comunicação entre programas diferentes (ou com configurações diferentes) e, também, a
manipulação dos dados, formatos e características diversas.” (SAWAYA, 1999, p. 242).

Qualidade e Usabilidade de Software 71

 4 Processo de desenvolvimento de software

A usabilidade é o conjunto de critérios e indicadores relacionados com o esforço neces-

sário para o uso do software e a avaliação individual de tal utilização, por um grupo declara-
do ou implícito de usuários – como, por exemplo, a facilidade de usuários utilizarem dados
do sistema por intermédio de atalhos. Segundo Pfleeger (2004), a usabilidade corresponde
aos critérios de
• aprendizagem – o conjunto de indicadores para assegurar a aprendizagem para o
sistema a que se destina;
• compreensibilidade – o conjunto de indicadores para assegurar a compreensão
dos elementos que o compõem;
• operacionalidade – definida de acordo com a função correta que ele executa;
• atratividade – o conjunto de indicadores para assegurar que seja atraente do ponto
de vista dos usuários a quem se destina.
Por fim, a eficiência é definida como um conjunto de critérios e indicadores corres-
pondentes que dizem respeito ao desempenho da quantidade de recursos necessários sob
condições estabelecidas (SOMMERVILLE, 2011). Como exemplo, menciona-se a capacidade
de o sistema realizar uma função em menos tempo. A eficiência deve estar relacionada a
critérios de:
• comportamento ao longo do tempo – definido em correspondência com a função
adequada que o produto executa;
• comportamento do recurso – o conjunto de indicadores para assegurar o fator de
acordo com a portabilidade, ou seja, a capacidade de ser transferido de uma pla-
taforma para outra.
Como observado, métodos, validações e indicadores devem ser adotados no processo
do desenvolvimento do software, sempre buscando-se uma melhoria na qualidade.
Os métodos e os indicadores são baseados em critérios que buscam validações, com o
intuito de se atingir uma boa funcionalidade, confiabilidade, usabilidade e eficiência.

Ampliando seus conhecimentos

No texto a seguir, Jeff Sutherland, cocriador do método Scrum, explica em

que se baseou para criá-lo, compara-o com o método cascata e apresenta
suas principais características.

Uma nova forma de pensar

(SUTHERLAND, 2014, p. 15-16)

Esta nova abordagem se chama Scrum. Eu a criei vinte anos atrás. Agora
essa é a única maneira comprovada de ajudar projetos desse tipo. Existem
duas forma de fazer as coisas: o método antigo da “cascata” que gasta

72 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
centenas de milhões de dólares e não entrega nenhum resultado, ou a
nova forma, que, com menos gente e em menos tempo, consegue mais
resultados com mais qualidade e menos custos. Sei que soa bom demais
para ser verdade, mas a prova está nos resultados. Funciona mesmo.

[...]

O motivo por que ela funciona é simples. Eu olhei a forma como as pes-
soas realmente trabalham, em vez de como elas dizem que trabalham.
Analisei uma pesquisa realizada por décadas e as melhores práticas de
empresas em todo o mundo e analisei mais a fundo as melhores equipes
nessas empresas. O que as tornava superiores? O que as tornava diferen-
tes? Por que algumas equipes atingem resultados excepcionais e outras
apenas resultados medíocres?

[...] eu chamei de “Scrum” essa estrutura de desempenho de equipe.

O termo vem do jogo de rúgbi e se refere à maneira como um time tra-
balha junto para avançar com a bola no campo. Alinhamento cuidadoso,
unidade de propósito, clareza de objetivo, tudo se unindo. Trata-se de
uma metáfora perfeita para o que uma equipe deseja fazer.

[...]

O Scrum acolhe a incerteza e a criatividade. Coloca uma estrutura em

volta do processo de aprendizagem, permitindo que as equipes avaliem o
que já criaram e, o mais importante, de que forma o criaram. A estrutura
do Scrum busca aproveitar a maneira como as equipes realmente traba-
lham, dando a elas as ferramentas para se auto-organizar e, o mais impor-
tante, aprimorar rapidamente a velocidade e a qualidade de seu trabalho.

Em essência, o Scrum tem como base uma ideia simples: ao começar um

projeto, por que não fazer paradas regulares para verificar se o que está
sendo feito está seguindo na direção certa e se, na verdade, os resultados
são os que as pessoas desejam? E verificar se existem maneiras de apri-
morar a forma como se está trabalhando para obter resultados melhores e
executados mais rapidamente, e quais seriam os obstáculos que impedem
as pessoas de obtê-los.

[...]

Os resultados finais do Scrum – ou o objetivo do projeto, se preferir – são

equipes que melhoram drasticamente a produtividade. [...]

Qualidade e Usabilidade de Software 73

 4 Processo de desenvolvimento de software

Atividades
1. O que diferencia um modelo de ciclo de vida de desenvolvimento de software?

2. Em que situação a prototipagem evolutiva deve ser empregada? Por quê?

3. O que os métodos ágeis de desenvolvimento de software enfatizam?

4. Quais são os principais indicadores da qualidade do software?

Referências
CAIÇARA JUNIOR, C. Informática, internet e aplicativos. Curitiba: Ibpex, 2007.
CRAIG, R. D., JASKIEL, S. P. Systematic software testing. Boston: Artech House Publishers, 2002.
CYBIS, W. et al. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 3. ed. São Paulo:
Novatec, 2015.
LAUDON, K. LAUDON, J. Sistemas de informação gerenciais. São Paulo: Pearson Prentice Hall, 2004.
MARÇAL, A. S. C. et al. Estendendo o Scrum segundo as áreas de processo de gerenciamento de projetos
do CMMI. Disponível em: <[Link]
Artigos/[Link]>. Acesso em 28 jul. 2017.
MARSHALL JUNIOR, I. et al. Gestão da qualidade e processos. Rio de Janeiro: Ed. da FGV, 2012.
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML.
5. ed. Rio de Janeiro: Brasport, 2010.
MOUNTAIN GOAT SOFTWARE. The Scrum development process. Disponível em: <[Link]
[Link]/Sc>. Acesso em: 1 fev. 2017.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São
Paulo: AMGH Bookman, 2016.
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. Rio de Janeiro: Brasport,
2005.
SAWAYA, M. R. Dicionário de informática e internet. São Paulo: Nobel, 1999.
SCHACH, S. R. Engenharia de software: os paradigmas clássico e orientado a objetos. Trad. de A.
Griesi. 7. ed. Porto Alegre: AMGH, 2010.
SCHWABER, K. Agile Project Management with Scrum. Microsoft Press Books, 2004.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. Trad. de N.
Gerhardt. São Paulo: LeYa, 2014.
TORRES, L. F. Fundamentos do gerenciamento de projetos. Rio de Janeiro: Elsevier, 2014.
VALERIANO, D. Moderno gerenciamento de projetos. São Paulo: Pearson Prentice Hall, 2005.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2006.

74 Qualidade e Usabilidade de Software

 Processo de desenvolvimento de software 4
Resolução
1. O ciclo de desenvolvimento de software fornece uma série de etapas, a fim de proje-
tar e desenvolver um produto de software de forma eficiente. Existem vários tipos de
modelos de ciclo de vida, que se diferenciam principalmente pelo grau de controle
aplicado sobre o processo em questão e pela visibilidade deste para o cliente no de-
correr do projeto.

2. A prototipagem evolutiva deve ser empregada quando o cliente não tem claros os
requisitos do sistema, sendo incapaz de detalhá-lo. Ao realizar o protótipo, a equipe
de desenvolvimento torna o projeto mais concreto, facilitando a sua compreensão.

3. Métodos ágeis enfatizam a comunicação face a face, em vez de documentação. Equi-

pes mais ágeis estão localizadas em um único escritório aberto, às vezes chamado de
plataformas de lançamento. O escritório deve incluir revisores, escritores de documen-
tação, designers de iteração e gerentes de projeto. Métodos ágeis também enfatizam
que o software seja funcional.

4. Os principais indicadores, segundo Pfleeger (2004) são: funcionalidade, confiabili-

dade, usabilidade e eficiência. No funcionalidade estão implícitas as seguintes ca-
racterísticas: adequação, acurácia, interoperabilidade, segurança de acesso e confor-
midade. A confiabilidade precisa estar em concordância com os seguintes critérios:
maturidade, capacidade de recuperação e tolerância a falhas. Já a usabilidade cor-
responde aos critérios de: aprendizagem, compreensibilidade, operacionalidade e
atratividade. Por fim, a eficiência se relaciona aos critérios de: comportamento ao
longo do tempo e comportamento do recurso.

Qualidade e Usabilidade de Software 75

 5
Gerência da qualidade
de software

Introdução

A gerência da qualidade do software garante que o nível de qualidade exigido

pelo cliente seja alcançado por meio de melhorias no processo de desenvolvimento do
produto. Esse tipo de gestão visa desenvolver uma cultura de aprimoramento dentro
da equipe e é visto como responsabilidade de todos.

A gerência de qualidade deve ser independente da gestão do projeto, para garantir

que o software seja elaborado com qualidade e dentro do prazo e do custo estipulados.
Essa gestão afeta diretamente a qualidade do desenvolvimento do processo e, indire-
tamente, a qualidade do produto.

Um gerenciamento de qualidade de software inclui o Software Quality Assurance

(SQA), ou Garantia de Qualidade de Software, que visa desenvolver procedimentos e
padrões em nível organizacional. Assim, são realizados o Planejamento da Qualidade,
de modo a selecionar os procedimentos e padrões aplicáveis a um projeto específico
e modificá-los conforme necessário, e o Controle de Qualidade, para assegurar que
as melhores práticas e padrões (vistos no capítulo 2) sejam seguidos pela equipe de
desenvolvimento de software, resultando em produtos de alta qualidade.

Qualidade e Usabilidade de Software 77

 5 Gerência da qualidade de software

5.1 Dimensões da qualidade do

processo e do produto

A qualidade do processo e do produto decorrentes do desenvolvimento de software

está ligada à percepção e às expectativas dos consumidores, em termos das dimensões de
qualidade de serviço (PARASURAMAN; ZEITHAML; BERRY, 2005).

5.1.1 Dimensões da qualidade do processo

Parasuraman, Zeithaml e Berry (2005) argumentam que a qualidade percebida é uma
função da diferença entre expectativa e desempenho ao longo de um sistema estabelecido de
dimensões de qualidade. De acordo com Johnston (1995), é necessário reconhecer os deter-
minantes ou as dimensões do projeto para se poder especificar, medir, controlar e melhorar
a qualidade do serviço percebida pelos clientes, identificando-se os problemas que possam
influenciar o julgamento geral destes em relação ao produto.
Segundo Parasuraman, Zeithaml e Berry (2005), são cinco as dimensões que avaliam a
qualidade no desenvolvimento de serviços:
1. Tangibilidade, entendida como a aparência das instalações físicas, dos equipamen-
tos e do material de comunicação.
2. Confiabilidade, que é a capacidade de executar o serviço prometido com precisão
e formalidade. No que se refere a essa dimensão, Boulding et al. (1993) argumen-
tam que, embora a qualidade do serviço seja multidimensional, a confiabilidade é
fundamental na determinação global da qualidade percebida do serviço. Ou seja,
no modelo dinâmico de qualidade de serviço, a confiabilidade é o principal mani-
pulador da percepção geral de serviço ao cliente.
3. Sensibilidade, definida como a vontade de ajudar os clientes e fornecer um serviço
rapidamente. Sobre essa dimensão, Parasuraman, Zeithaml e Berry (2005) relatam
que ter sensibilidade significa servir os clientes de forma ágil e responder rapi-
damente às suas solicitações ou reclamações. Outro aspecto da sensibilidade diz
respeito à pontualidade no serviço de campo e ao tempo de reparação técnica.
4. Garantia, que compreende o conhecimento e a cortesia dos funcionários e sua ca-
pacidade de inspirar confiança.
5. Empatia, que envolve os cuidados e o atendimento individualizado que a empresa
oferece aos seus clientes.
Por meio dessas dimensões, é possível compreender os trade-offs1 vivenciados pelos
clientes, o que pode ajudar a construir uma vantagem competitiva em relação à concorrência.
1 Trade-off é um termo em inglês que significa o ato de escolha de um produto ou serviço em detri-
mento de outro. Muitas vezes é traduzido como “perde-e-ganha”, pois implica um conflito de esco-
lha: quem escolhe deve conhecer os pontos positivos e os negativos de um produto ou serviço para
escolher aquele que atende melhor às suas necessidades. Ele precisa avaliar bem cada um para fazer a
melhor escolha, pois deixará de usufruir dos benefícios do produto ou serviço que não foi escolhido.

78 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
5.1.2 Dimensões da qualidade segundo Garvin
David Garvin (2015) propôs oito diferentes dimensões da qualidade: desempenho, re-
cursos, confiabilidade, conformidade, durabilidade, facilidade de manuseamento, estética e
qualidade percebida (Figura 1). Para o autor, algumas dessas dimensões se reforçam mutua-
mente, enquanto outras não.

Figura 1 – Dimensões da qualidade segundo Garvin (2015).

Desempenho

Confiabilidade Recurso

Qualidade Dimensões
Conformidade
percebida de qualidade

Facilidade de
manuseamento Durabilidade

Estética

Fonte: Elaborada pela autora, com base em GARVIN, 2015.

As oito dimensões são explicadas por Garvin conforme exposto a seguir.

[Link] Desempenho
Refere-se às principais características operacionais de um produto ou serviço. Essa di-
mensão de qualidade abrange atributos mensuráveis, de modo que as empresas geralmente
podem ser classificadas objetivamente em aspectos individuais de desempenho.
O desempenho é muitas vezes uma fonte de desentendimento entre clientes e fornece-
dores, particularmente quando o que se entrega não está adequadamente definido dentro
das especificações. O desempenho de um produto muitas vezes influencia a rentabilidade
ou a reputação da empresa. Por isso, muitos contratos ou especificações também incluem os
danos relacionados ao desempenho inadequado.

Qualidade e Usabilidade de Software 79

 5 Gerência da qualidade de software

Alguns padrões de desempenho são baseados em preferências subjetivas, mas as prefe-

rências no geral são tão universais que têm a força de um padrão objetivo (GARVIN, 2015).
O desempenho do software pode estar associado, por exemplo, à existência de ferramentas
que facilitam a navegação ou a um sistema operacional que permita a monitoração constan-
te do hardware, como memória, rapidez do sistema e inexistência de bugs.

[Link] Recursos
São as características adicionais que realçam o apelo do produto ou serviço ao usuário.
Pensamento semelhante pode ser aplicado às características, que muitas vezes são um as-
pecto secundário do desempenho (GARVIN, 2015).
Os recursos do software englobam todos os conjuntos de instruções que possibilitam o
processamento de informações e, portanto, englobam programas e procedimentos.
Os programas podem ser compreendidos como um conjunto de instruções que possibi-
litam ao computador realizar determinada tarefa. Já os procedimentos são um conjunto de
instruções usadas por usuários para a finalização de uma tarefa.
São exemplos de recursos do software
• softwares aplicativos – são programas de computador criados para ajudar os usuá-
rios a desempenhar tarefas específicas;
• softwares de sistema – programas de sistema operacional que controlam e apoiam
todas as operações de um sistema de computador;
• procedimentos – todas as orientações que o usuário final utiliza para navegar no
sistema operacional.

[Link] Confiabilidade
É a probabilidade de um produto não falhar em um período de tempo específico, sendo
um elemento-chave para os usuários que precisam dele. Entre as medidas mais comuns de
confiabilidade estão: o tempo médio até a primeira falha, o tempo médio entre falhas e a
taxa de falha por unidade de tempo. Como essas medidas exigem que o produto esteja em
uso por um período especificado, elas são mais relevantes para bens duráveis do
​​ que para
produtos e serviços consumidos instantaneamente. A confiabilidade normalmente se torna
mais importante para os consumidores conforme o tempo de inatividade e a manutenção do
produto se tornam mais caros (GARVIN, 2015).
Dessa forma, verifica-se que a confiabilidade do software não depende diretamente da
disponibilidade do produto, porém ela tem relação com o tempo decorrido até que o siste-
ma operacional se torne indisponível, sendo necessária a reparação dos defeitos. Exemplo:
O sistema 1 apresenta falha uma vez por ano, porém a cada falha leva dois dias para
reiniciar, enquanto o sistema 2 falha uma vez por mês, mas a cada falha demora dois
minutos para reiniciar. Qual deles apresenta maior confiabilidade? O sistema 1 é mais
confiável ao usuário, já o sistema 2 apresenta maior disponibilidade, pois as falhas são
corrigidas rapidamente.

80 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
[Link] Conformidade
É a precisão com que o produto ou serviço atende aos padrões especificados. A dimen-
são da conformidade descreve até que ponto o projeto de um produto e suas características
operacionais atendem aos padrões estabelecidos e se tais características se devem mais a
abordagens tradicionais do que a qualidades pioneiras.
Quando os produtos são desenvolvidos, suas especificações são definidas e um alvo,
por exemplo, os materiais utilizados ou a dimensão do produto, assim como uma tolerância
(o intervalo de desvio permitido do alvo), são estabelecidos. Um problema com essa abor-
dagem é que há pouco interesse em saber se as especificações foram cumpridas exatamente
como determinado, enquanto os limites de tolerância forem satisfeitos.
As medidas de conformidade normalmente se concentram na precisão e na oportuni-
dade e incluem contagens de erros de processamento, atrasos inesperados e outros erros
frequentes (GARVIN, 2015).
No caso dos softwares, a conformidade verifica se ele foi desenvolvido de acordo com
padrões, normas, procedimentos e guias de TI e se atendem aos requisitos do cliente/usuário.

[Link] Durabilidade
Mede a duração da vida de um produto. Quando o produto pode ser reparado, estimar
sua durabilidade é mais complicado, pois o item será usado até que não seja mais econo-
micamente viável operá-lo. Isso acontece quando a taxa de reparo e os custos associados
aumentam significativamente.
Tecnicamente, a durabilidade pode ser definida como a quantidade de uso que se obtém
de um produto antes de ele se deteriorar (GARVIN, 2015). Em alguns casos, os consumido-
res devem pesar o custo esperado de futuras reparações, em reais e em transtornos pessoais,
contra o investimento e as despesas operacionais com um modelo mais novo e mais confiá-
vel – ou seja, se uma substituição é preferível à continuação da reparação. Essa abordagem
da durabilidade tem duas implicações importantes. Em primeiro lugar, sugere que a dura-
bilidade e a confiabilidade estão estreitamente ligadas. Um produto que muitas vezes falha
é susceptível de ser substituído ou retirado do mercado mais cedo do que um que é mais
confiável, pois seus custos de reparo serão mais altos e a compra de uma marca concorrente
parecerá muito mais desejável ao cliente. Em segundo lugar, implica que os dados de dura-
bilidade devem ser interpretados com cuidado. Um aumento na vida do produto pode não
ser resultado de melhorias técnicas ou do uso de materiais mais duráveis, mas, em vez disso,
fruto de mudanças no ambiente econômico do qual ele faz parte (GARVIN, 2015).
Em relação à durabilidade do software, verifica-se que ela diz respeito ao tempo de
duração de um software até ele se tornar desatualizado em relação ao conteúdo ou obsoleto.
Vale ressaltar que a durabilidade, apesar de ser um conceito similar, não é a mesma coisa
que a confiabilidade. A durabilidade, por exemplo, relaciona-se com a vida útil do software,
enquanto a confiabilidade relaciona-se com o período de tempo em que o produto não po-
derá apresentar defeitos, por exemplo, no período da garantia dada pelo fabricante.

Qualidade e Usabilidade de Software 81

 5 Gerência da qualidade de software

[Link] Atendimento
Essa dimensão diz respeito aos fatores do produto ou serviço que podem afetar a per-
cepção do cliente.
O atendimento envolve questões como pontualidade e rapidez do serviço, eficiência,
presteza, reatividade, resolução de problemas, pouco tempo de espera, comunicação ade-
quada, entre outros aspectos implicados no contato entre cliente e fornecedor/empresa.
Como, no caso dos softwares, necessita-se de atendimento para reparos ou manutenção
dos produtos, essa dimensão de atendimento adequado influencia a visão do usuário final,
inclusive no que diz respeito à decisão sobre o uso futuro do software em questão.

[Link] Estética
É a dimensão subjetiva que indica a impressão que o usuário tem em relação a um
produto. As propriedades estéticas de um produto contribuem para a identidade de uma
empresa ou marca, e falhas ou defeitos que o diminuem, mesmo quando não reduzem ou
alteram outras dimensões de qualidade, são muitas vezes causa de rejeição. Assim, a estética
refere-se a como o cliente vê e sente produto, seus sons, gostos ou cheiros, ou seja, é clara-
mente uma questão de julgamento pessoal e um reflexo da preferência individual. No en-
tanto, parece haver alguns padrões no ranking dos consumidores de produtos com base em
gostos. Um estudo sobre a qualidade em 33 categorias de alimentos, por exemplo, descobriu
que a alta qualidade era frequentemente associada a “sabor rico e cheio”, sabores “naturais”
e “frescos”, bom aroma e aparência (GARVIN, 2015).
No desenvolvimento do software, a estética é um requisito que pode ser satisfeito com
a adoção de prototipação da interface do aplicativo, por meio da qual é possível verificar
como será o software quando finalizado. A realização de protótipos ajuda no desenvolvi-
mento visual do produto, que pode receber a opinião não somente de desenvolvedores, mas
também do cliente e de potenciais usuários.

[Link] Qualidade percebida

É a qualidade atribuída a um bem ou serviço baseada em medidas indiretas. A percep-
ção nem sempre reflete a realidade, pois os consumidores muitas vezes possuem informa-
ções incompletas sobre os atributos de um produto/serviço. As medidas indiretas podem
constituir a única base dos clientes para a comparação de marcas. A durabilidade, por exem-
plo, raramente pode ser observada diretamente, pois é inferida por meio de vários aspectos
tangíveis e intangíveis do produto. Nessas circunstâncias, imagens, propagandas e nomes
de marcas – referências sobre a qualidade, em vez da própria realidade – podem ser críticos
(GARVIN, 2015).
Abordando a questão da qualidade do software, ressalta-se que ela é um conjunto
de atributos que devem ser satisfeitos de modo que esse produto atenda às necessidades
de todos os usuários – o desenvolvedor, o cliente, o usuário final e todas as partes inte-
ressadas (stakeholders).

82 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
5.2 Planejamento e controle da
qualidade do software

O planejamento e o controle da qualidade do software surgem da necessidade de se

produzir um produto de alta qualidade, e isso implica a garantia de proteção de software ao
longo de todo o seu processo de engenharia.
O controle de qualidade abrange uma série de avaliações e testes utilizados para
todo o ciclo de desenvolvimento de produto, a fim de garantir que cada software atenda
aos requisitos que lhe foram atribuídos. Essa variedade de tarefas está associada a dife-
rentes sujeitos: os engenheiros de software, que realizam o trabalho técnico, e o grupo
de SQA (Software Quality Assurance), responsável pela garantia de qualidade e planeja-
mento (WAZLAWICK, 2013).
Nesse contexto, o planejamento e o controle formais representam um filtro para pro-
cessos de engenharia de software, pois eles são aplicados em vários estágios de desenvol-
vimento e usados para detectar defeitos que possam ser eliminados (WAZLAWICK, 2013).
Esses processos envolvem a verificação da necessidade de melhorias no produto de
software, inclusive confirmando as partes dele em que não sejam necessárias ou desejá-
veis modificações, adotando-se um trabalho baseado em critérios de correção e integridade
(MARSHALL JR. et al., 2012).

5.2.1 Detecção e controle de erros

O principal objetivo das revisões técnicas formais é encontrar erros durante o processo
de desenvolvimento do software, impedindo que eles se propaguem em etapas posteriores
e que se tornem defeitos após a entrega do produto. Estudos indicam que as atividades de
design2 introduzem entre 50% e 65% de todos os erros (e, finalmente, todos os defeitos)
durante o desenvolvimento do software. No entanto, as inspeções dessas atividades são
eficazes em 75% dos casos (SOMMERVILLE, 2011).
Durante cada etapa de desenvolvimento, pode haver problemas que passam desper-
cebidos, e a inspeção pode não conseguir descobrir os erros. Em alguns casos, erros não
identificados a nas etapas iniciais são posteriormente amplificados (SOMMERVILLE, 2011).
Para realizar inspeções de controle, a equipe de desenvolvimento deve gastar tempo e
esforço, e a organização precisa gastar dinheiro. Esses testes produzem um custo-benefício
demonstrável; portanto, se a empresa tem os recursos necessários, eles devem ser realizados
(PRESSMAN; MAXIM, 2016).
Para ilustrar o impacto sobre o custo de detecção de erros desde o início, ou seja, des-
de o planejamento do projeto, considere uma série de custos relativos que se baseiam em

2 O design de software “compreende a concepção, especificação e prototipação da partes ‘exter-

nas’ e ‘internas’ do software. A parte externa compreende o modelo conceitual da aplicação e a
interface de usuário. A parte interna compreende a arquitetura de componentes de software e os
algoritmos e estruturas de dados que implementam estes componentes” (LEITE, 2000).

Qualidade e Usabilidade de Software 83

 5 Gerência da qualidade de software

dados recolhidos em grandes projetos de software, com e sem a realização de processos de

inspeção (Tabelas 1 e 2):

Tabela 1 – Com realização de inspeções/controle.

Erros Custo
Quantidade Total
encontrados unitário
Durante o projeto 22 1,5 33
Antes do teste 36 6.5 234
Durante o teste 15 15,0 315
Após o teste 3 67,0 201
Total 783
Fonte: CYBIS et al., 2015. Adaptado.

Tabela 2 – Sem realização de inspeções/controle.

Erros Custo
Quantidade Total
encontrados unitário
Antes do teste 22 6,5 143
Durante o teste 82 15,0 1.230
Após o teste 12 67,0 804
Total 2.177
Fonte: CYBIS et al., 2015. Adaptado.

Do exposto, pode-se resumir que os benefícios obtidos por meio da aplicação de inspe-
ções (PRESSMAN; MAXIM, 2016) envolvem a redução de defeitos no software e da quanti-
dade de recursos de desenvolvimento, especialmente nas fases de codificação e teste, assim
como uma redução dos custos de manutenção corretiva.
De acordo com Cybis et al. (2015), um processo de inspeção adequado consiste de
seis passos
1. Planejamento – Quando o desenvolvedor conclui um “produto de trabalho”, uma
equipe de inspeção é formada e um moderador é designado. O moderador assegu-
ra que o produto de trabalho satisfaça os critérios de inspeção. Ele atribui papéis
diferentes para os membros da equipe de inspeção, bem como estabelece o tempo
de planejamento e os recursos.
2. Resumo – Se os inspetores não estão familiarizados com o projeto de desenvol-
vimento, é necessário dar a eles uma visão geral do processo. Esse é um passo
opcional, mas não menos importante, porque nessa fase será dado aos inspetores o
contexto a ser coberto por meio das inspeções.

84 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
3. Preparação – Os inspetores são preparados individualmente para avaliação na
reunião, estudando os produtos de trabalho e materiais relacionados. Nessa fase,
é aconselhável a utilização de listas de verificação para ajudar a encontrar defei-
tos comuns.
4. Comentário – Nessa fase, os inspetores se reúnem para discutirem juntos cada tra-
balho individual. O moderador deve assegurar que todos estejam suficientemente
preparados. A pessoa designada como leitor apresenta o “produto do trabalho”, in-
terpretando-o, enquanto cada participante se atenta para possíveis defeitos. Após
a conclusão da reunião, o grupo determina se o produto será aceito ou se deve ser
reformulado para inspeção posterior.
5. Retrabalho – O desenvolvedor corrige todos os defeitos encontrados pelos
inspetores.
6. Follow-up (acompanhamento) – O moderador verifica as correções feitas pelo de-
senvolvedor. Se o moderador está satisfeito, a inspeção é formalmente completa e
o “produto de trabalho” é colocado sob controle de configuração.
Para cumprir essas seis etapas, surge a necessidade do estabelecimento dos objetivos
da inspeção, dos participantes e de que papéis eles terão, dos produtos de trabalho a serem
inspecionados e do que deve ser o resultado das reuniões de inspeção (CYBIS et al., 2015):
• Objetivos – O objetivo principal é encontrar defeitos no “produto de trabalho”, e,
para isso, é preciso definir quais serão as metas a serem alcançadas. O estabeleci-
mento dessas metas está diretamente relacionado com o tipo de projeto, as meto-
dologias e os instrumentos utilizados.
• Grupos de inspeção – É recomendado que se formem grupos de três a seis indiví-
duos (IEEE, 1997), incluindo neles o autor/desenvolvedor dos produtos de trabalho.
• Funções – Além do autor, devem ser definidos: o moderador, que liderará a inspe-
ção e que deve ter mais experiência do que o resto do grupo; o leitor, que apresenta
os produtos de trabalho nas reuniões; e o escriba, que documenta a descrição e a
localização dos defeitos encontrados.
• Os produtos funcionam – O processo de inspeção pode ser aplicado a diferentes
tipos de produtos de trabalho encontrados em um desenvolvimento de software,
incluindo requisitos, projeto, código, testes, guia de usuário e outras documenta-
ções. O padrão IEEE – Práticas Recomendadas para Especificação de Requisitos de
Software (IEEE, 1998) – não especifica um tamanho, mas os produtos de trabalho
têm, normalmente, 10 a 20 folhas de especificação de requisitos, com 200 ou 250
linhas de código cada.
• Resultado de reuniões de inspeção – Os dois principais resultados devem ser a
lista de defeitos a serem corrigidos e um relatório de inspeção, que descreve o que
foi inspecionado, quem inspecionou e o número de defeitos encontrados.
Assim, verifica-se que um dos maiores benefícios da realização de inspeções de
software é a possibilidade de solucionar erros o quanto antes, com esforço reduzido e custos
menores à empresa.

Qualidade e Usabilidade de Software 85

 5 Gerência da qualidade de software

5.3 Gerência dos testes de software

Alterações durante o desenvolvimento de software são inevitáveis, por isso é preciso

garantir que esse processo não seja desordenado.
A área da engenharia de software que trata desse assunto é a gerência de testes do
software (PRESSMAN; MAXIM, 2016), que pode ser entendida como “um conjunto de ati-
vidades de apoio que permite a absorção ordenada das mudanças inerentes ao desenvolvi-
mento de software, mantendo a integridade e a estabilidade durante a evolução do projeto”
(ARANTES; FIDELIS; AZEVEDO, 2017, p. 1).
As atividades da gestão de testes de software envolvem (CYBIS et al., 2015):
• controlar e acompanhar mudanças (controle de mudança);
• registrar a evolução do projeto (controle de versão);
• estabelecer a integridade do sistema (integração contínua).
O controle de mudanças acontece ao longo de todo o processo de desenvolvimento do
software. As alterações devem ser registradas, avaliadas e elencadas conforme sua priorida-
de. Isso permite o acompanhamento do escopo, dos prazos e dos custos de cada etapa.
No controle de versão, sempre que ocorrer uma solicitação de mudança, há um acrés-
cimo na evolução do projeto, que deve ser registrado no histórico de desenvolvimento.
O registro de controle de versões assegura cada etapa do desenvolvimento de software, pois
possibilita a edição paralela dos arquivos, e a criação de diferentes versões é muito impor-
tante para a gestão e o controle do produto.
A integração contínua de um sistema tem como principal objetivo a verificação da com-
posição do sistema, ou seja, se seus itens de registro estão consistentes. A integração acom-
panha o controle de versão e dispara scripts que automatizam a construção, os testes e a
coleta de métricas de qualidade.
Pressman e Maxim (2016) citam que a gerência dos testes faz parte da gestão de configu-
ração e que elas estão relacionadas com as demais áreas da engenharia de software; assim,
esses processos são requisitos de implementação em diversos modelos de níveis de maturi-
dade de desenvolvimento de software.
Verifica-se, desse modo, que a realização de testes está relacionada à gestão de projeto,
à garantia da qualidade de software e à gerência de configuração.
Ainda de acordo com os mesmos autores (PRESSMAN; MAXIM, 2016), as solicitações
de mudanças de desenvolvimento de software são registradas e controladas sob responsabi-
lidade do desenvolvedor, que registra a solicitação, seus resultados, dispara a execução dos
testes e realiza a coleta das métricas de qualidade do sistema como um todo e de cada código
criado. Os resultados devem ser apresentados para a equipe de desenvolvimento, com base
nos quais são então realizadas as alterações, as correções e os ajustes necessários, criando
assim uma nova versão e seu respectivo registro.

86 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
5.3.1 Tipos de testes
Existem ferramentas de software que auxiliam nos gerenciamentos dos testes a serem
realizados, permitindo o acompanhamento e o controle de casos e atividades específicas.
Dependendo da necessidade, podem ser aplicados diferentes tipos de testes, como descrito
a seguir:
• Teste de funcionalidade – nele são avaliados campos, navegação entre as telas,
botões, links, interface e funcionalidade geral do sistema. Os requisitos iniciais so-
licitados pelo cliente devem ser testados e aprovados nesse teste.
• Teste de desempenho – é avaliado o desempenho do sistema, se ele está atenden-
do aos requisitos preestabelecidos, e o tempo que cada aplicação demora para dar
respostas a determinada ação.
• Teste unitário – são avaliadas pequenas unidades de software, uma parte do có-
digo construído, como as rotinas, com o objetivo de verificar funções diferentes
dentro do sistema.
• Teste de bugs – é avaliada a existência de bugs, erros de programação e funciona-
mento do sistema, erros de construção de código ou da própria aplicação.
• Teste de integração – nele são avaliados vários componentes do software, combi-
nados e testados em grupo.
• Teste operacional – nele é verificado se a aplicação responde ao tempo de execu-
ção do sistema.
• Teste de regressão – é realizado logo após a alteração de um código e, assim, toda
a aplicação deve ser testada novamente.
• Teste de caixa branca – todas as entradas e saídas desejadas do sistema são testa-
das e é observado o resultado esperado.
• Teste de configuração – nele se avalia se a aplicação funciona corretamente em
diferentes configurações de hardware e software.
• Teste de interface – é avaliada a navegabilidade e se cada componente responde
conforme especificado pelo usuário.
• Teste de carga – teste em que se avalia o funcionamento da aplicação com simu-
lação de entrada de dados simultâneos em grande quantidade, verificando-se a
resposta do sistema.
• Teste de aprovação do usuário – nele o usuário realiza os testes operacionais e se
sua aplicação é funcional.
• Teste de estresse – caminhos diferentes de uso são avaliados, tentando simular um
erro ou uma ação inesperada, submetendo o software a situações extremas.
Nesse contexto de avaliação dos softwares, o desenvolvimento de projetos de qualida-
de deve envolver profissionais devidamente preparados. Os engenheiros devem entender
o raciocínio por trás de cada padrão e as normas devem ser revistas regularmente, para se
evitar problemas de obsolescência e credibilidade.

Qualidade e Usabilidade de Software 87

 5 Gerência da qualidade de software

O gerenciamento da qualidade do software funciona melhor quando se cria uma “cul-

tura de qualidade” nas organizações, ou seja, quando a qualidade é vista como responsabi-
lidade de todos.

Ampliando seus conhecimentos

O texto a seguir procura desmistificar a ideia equivocada que muitos pro-

gramadores têm sobre os testes de software, além de defender a existência
de uma equipe de qualidade que não participou do desenvolvimento do
software para poder avaliá-lo de forma objetiva.

Definindo qualidade de software

(BARTIÉ, 2002, p. 20-21)

Definição comum de testes

De forma geral, todas as equipes de desenvolvimento aplicam testes em

seus softwares, independentemente se os testes são bem planejados, bem
estruturados e de como são executados. O fato é que esses testes não são
suficientes para detectar os erros que estão inseridos dentro de uma apli-
cação. Um dos motivos básicos para que isso ocorra é na forma com que
esses profissionais encaram os testes de software.

[...]

Todos enxergam os testes como uma forma de provar que tudo está bem
e funcionando conforme o estabelecido. Todas as definições difundidas
sobre testes dão uma dimensão positiva sobre o problema, ou seja, o enten-
dimento sobre testes é sempre colocado sob o prisma de avaliar se tudo
está funcionando adequadamente. O fato é que é mais fácil provar que
“algo funciona” do que provar que “algo não funciona”, o que significa
que teremos um menor esforço em provar o funcionamento de um soft-
ware do que o contrário. E é exatamente isso que sentimos quando colo-
camos uma equipe independente de qualidade para avaliar determinado
projeto de software – como essa equipe não está envolvida emocional-
mente nem politicamente com o projeto, terá um comportamento muito
mais objetivo e direto, indo exatamente aos pontos que inicialmente o pro-
jeto deveria atender e por motivos desconhecidos foram abandonados ou
não atendidos corretamente.

[...]

88 Qualidade e Usabilidade de Software

 Gerência da qualidade de software 5
A definição correta sobre testes

Entender que o objetivo dos testes é “provar que algo não funciona” é
um avanço significativo na compreensão de um processo de qualidade de
software. Não adianta termos documentações incompletas, imprecisas e
ambíguas. É necessário buscar um maior nível de qualidade em todos os
produtos (sejam documentos ou softwares) produzidos em todas as fases
do ciclo de desenvolvimento. Esses documentos auxiliarão as equipes a
tomarem decisões mais corretas sobre o projeto de software que refletirá
em um produto com maior conformidade com as necessidades dos clien-
tes e usuários. Portanto, os testes em documentos deverão não somente
analisar se as definições foram registradas, mas se estas foram escritas de
forma a não dar margens a dúvidas e se estão em conformidade com as
demais. Se o documento registra decisões que foram analisadas, devemos
avaliar se tais decisões estão apoiadas em informações e análises objetivas
e não por dados infundados ou meras suposições.

[...]

Atividades
1. Cite as dimensões que avaliam a qualidade no desenvolvimento de produtos e serviços.

2. O que é controle de qualidade de software?

3. Quais são as atividades da gestão de testes de software?

4. Explique a importância de a gerência de qualidade ser independente da gestão

do projeto.

Referências
ARANTES, I. L. V.; FIDELIS, I. S.; AZEVEDO, W. A. Projeto Integrador 2017/1. Tecnologia em Gestão
de TI, Faculdade de Tecnologia Senac-GO, Goiânia, 2017. Disponível em: <[Link]
[Link]/~152M154200121/Modulo5/Auditoria%20e%20Qualidade%20de%20Software/PI%20-%20
Auditoria%20e%20Qualidade%20de%[Link]>. Acesso em: 2 ago. 2017.
BARTIÉ, A. Garantia de qualidade de software: as melhores práticas de engenharia de software apli-
cadas à sua empresa. Rio de Janeiro: Elsevier, 2002.
BOULDING, E. A. et al. Um modelo de processo dinâmico de qualidade do serviço: a partir de expec-
tativas para as intenções comportamentais. Journal of Marketing Research, n. 30, p. 7-27, 2003.
CYBIS, W. et al. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 3. ed. São Paulo:
Novatec, 2015.

Qualidade e Usabilidade de Software 89

 5 Gerência da qualidade de software

GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. Rio de Janeiro:

Qualitymark, 2015.
GRÖNROOS, C. Em direção a uma terceira fase na investigação de qualidade de serviço: desafios e
direções futuras. In: SWARTZ, T. A.; BOWEN, D. E.; BROWN, S. W. (Ed.). Avanços em marketing de
serviços e gestão. Greenwich: JAI Press, 2003. v. 2. p. 49-64.
IEEE. IEEE Standard for Software Reviews. Washington, DC: IEEE Computer Society, 1997.
______. Std. 830-1998: práticas recomendadas para especificação de requisitos de software. Washington,
DC: IEEE Computer Society, 1998.
JOHNSTON, R. The determinants of service quality: satisfiers and dissatisfiers. International Journal
of Service Industry Management, v. 6, n. 5, p. 53-71, 1995.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. São Paulo: Pearson Prentice Hall,
2004.
MARSHALL JUNIOR, I. et al. Gestão da qualidade e processos. Rio de Janeiro: Ed. da FGV, 2012.
PARASURAMAN, A.; ZEITHAML, V. A.; BERRY, L. L. Um modelo conceitual de qualidade de serviço
e suas implicações para futuras pesquisas. Journal of Marketing, n. 49, p. 41-50, 2005.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Pearson Prentice Hall,
2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São
Paulo: AMGH Bookman, 2016.
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011.

Resolução
1. Tangibilidade, confiabilidade, sensibilidade, garantia e empatia.

2. O controle de qualidade é uma série de avaliações e testes utilizados para todo o

ciclo de desenvolvimento do produto, a fim de garantir que ele atenda aos requisitos
que lhe foram atribuídos.

3. As atividades da gestão de testes de software são: controlar e acompanhar mudanças

(controle de mudança); registrar a evolução do projeto (controle de versão); e estabe-
lecer a integridade do sistema (integração contínua).

4. A gerência de qualidade deve ser independente da gestão do projeto porque ela

pode avaliar de forma objetiva os problemas que existem no software. A gestão do
projeto e a equipe de desenvolvedores não têm o distanciamento para fazer uma
avaliação eficaz dos problemas, pois estão envolvidas emocionalmente com o proje-
to e, em vez de apontar os defeitos, acabam defendendo as qualidades do produto.

90 Qualidade e Usabilidade de Software

 6
Fundamentos da interação
homem-computador (IHC)

Introdução

A adaptação às novas ferramentas tecnológicas é complexa. Para alguns indiví-

duos, ela acontece rapidamente; outros, no entanto, devido à heterogeneidade cultu-
ral, social, econômica e cognitiva, têm mais dificuldades para se adequar aos novos
processos tecnológicos. Este capítulo busca uma reflexão sobre os processos que envol-
vem a relação entre o homem e o computador.

De modo geral, a IHC estuda as trocas de informações por meio de software entre
pessoas e computadores, “relacionando tudo que estiver envolvido na interação entre
usuários e computadores, seja aspectos físicos, psicológicos, práticas de trabalho, rela-
ções sociais, saúde etc.” (ANDRADE, 2007, p. 36). Essa disciplina é responsável pela
concepção, avaliação e implementação de dispositivos de tecnologia interativa.

O objetivo de se estudar essas interações emerge da necessidade de que elas sejam

mais eficientes, a fim de minimizar erros, aumentar a satisfação do usuário, reduzindo
eventuais frustrações e, finalmente, tornar mais produtivas as tarefas que envolvem
pessoas e computadores.

Qualidade e Usabilidade de Software 91

 6 Fundamentos da interação homem-computador (IHC)

Embora a pesquisa nesse campo ainda seja muito recente, a recompensa alcançada é
gratificante. Assim, é importante que os sistemas de informação sejam eficazes, eficientes,
simples e agradáveis, e muito cuidado deve ser tomado na elaboração dos softwares, porque
quanto mais os sistemas forem agradáveis, maior será a possibilidade de o usuário conse-
guir explorar todos os comandos de um software.

6.1 Abordagens técnicas da IHC

A relação entre os seres humanos e os computadores é uma área de investigação multi-

disciplinar, e o termo mais genérico para se referir a ela é interação humano-computador (IHC),
que engloba as interfaces dos usuários num sistema de fabricação ou controle de desenvol-
vimento de softwares (WEBER, 2012).
Em outras palavras, a IHC investiga e aborda todos os aspectos relacionados à concep-
ção e à implementação de interfaces entre seres humanos e computadores. Dada a sua na-
tureza e seus objetivos, a IHC envolve várias disciplinas das ciências de computação (como
processamento de imagem, visão computacional, linguagens de programação e similares),
bem como disciplinas relacionadas às ciências humanas (ergonomia, psicologia cognitiva,
filosofia etc.), como explícito na Figura 1.

Figura 1 – Disciplinas relacionadas à IHC.

Ergonomia
Psicologia
social e
Engenharia
organizacio-
nal

Psicologia
Design
cognitiva

IHC
Ciência da
Antropologia
computação

Inteligência Sociologia
artificial

Linguística Filosofia

Fonte: PREECE, 1997, apud ANDRADE, 2007, p. 36.

92 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
A palavra interação se refere a uma ação que pode ser realizada formal ou informalmen-
te e, portanto, nela são executados processos de troca em um sentido amplo (WEBER, 2012).
Nas relações entre homens e máquinas propostas pela IHC, entende-se que elas estão liga-
das a processos internos automáticos do ser humano, como o processamento de rotina de
informações. Desse modo, as máquinas seriam algoritmos que buscam melhorar o desem-
penho do indivíduo e aumentar sua inteligência, assim como os seus níveis de consciência
(WEBER, 2012).
O desenho e a especificação de interfaces para melhorar a relação humano-máquina
pode incluir diferentes aspectos, como uma melhor interface para utilização de dispositivos
móveis (Figura 2).

Figura 2 – Relação homem-computador.

Fonte: grinvalds/iStockphoto

6.1.1 Evolução da IHC

Estudos sobre IHC remontam ao ano de 1963, quando Ivan Sutherland criou um sis-
tema para manipular objetos gráficos utilizando uma caneta, que permitia pegar objetos,
mover e redimensioná-los. No mesmo ano, Elgerbart projetou o primeiro mouse. Em 1968, o
MIT Lincoln Labs criou um modelo para interfaces incluindo janelas, menus, ícones, botões
etc. Foi o prelúdio para as interfaces que hoje conhecemos, como as utilizadas na manipula-
ção direta de dispositivos.
No início da ciência da computação, designers e desenvolvedores prestavam muito me-
nos atenção para o problema de tornar os produtos de hardware e software usáveis, até por-
que as interfaces continham apenas texto. No entanto, com o advento das interfaces gráficas
começou a haver a necessidade de estudos de IHC e pedidos provenientes de um conjunto
crescente de usuários para um melhor uso de dispositivos chamou atenção dos pesquisado-
res, que passaram a estudá-lo sob o nome de usabilidade (WEBER, 2012).

Qualidade e Usabilidade de Software 93

 6 Fundamentos da interação homem-computador (IHC)

Muitas organizações passaram a encomendar softwares que auxiliassem os usuários a

serem mais produtivos, o que exigiu também muitos estudos de ergonomia1, uma área que
interfere na usabilidade, pois busca o bem-estar e a saúde do usuário. A ergonomia não se
limita apenas aos móveis e ao ambiente de trabalho, mas também diz respeito à forma como
o usuário interage com o computador. Nesse sentido, até o número de “clics” que o usuário
precisa dar até chegar a seu objetivo, quando usa um aplicativo computacional, é avaliado
pela ergonomia.
Outro conceito importante associado à IHC a partir da década de 1990 foi o de user
experience, ou experiência do usuário (EU), centrado principalmente nos parâmetros rela-
cionados à satisfação dos usuários. Nos últimos anos, o EU tem sido ampliado e mais bem
definido em algumas áreas de pesquisa.
Peter Moville, conhecido como um dos pais da arquitetura da informação de websites,
criou um diagrama para ilustrar as facetas da experiência do usuário, no formato de uma
colmeia, que ficou conhecida como The User Experience Honeycomb (colmeia da experiência
do usuário), representada na figura a seguir.

Figura 3 – Experiência do usuário honeycomb.

Utilidade

Usabilidade Desejo

Valor

Encontrabilidade Acessibilidade

Credibilidade

Fonte: MORVILLE apud MATTHEWS, 2009, p. 85.

A figura da colmeia deixa claro que é preciso pensar a experiência do usuário além da
usabilidade, que é apenas uma das facetas do diagrama. Segundo Benyon (2011), as sete
células do “favo de mel” representam os parâmetros que devem ser cuidadosamente equi-
librados para fornecer aos usuários uma experiência de qualidade satisfatória, garantindo
que a interface seja útil, usável, desejável, encontrável, acessível, confiável e valiosa.

1 “Ciência que estuda a adequação do trabalho às características do ser humano, de modo a conferir
efetividade nas atividades laborais e de lazer desenvolvidas pelo homem, preservando a sua saúde
física e mental, e dando-lhe satisfação ao executá-las” (SHNEIDER, 2017).

94 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
Muitos designers de interface web conduzem estudos honeycomb para identificar priori-
dades na fase de projeto, procurando refletir sobre todas as facetas do diagrama honeycomb,
de modo a ter uma visão mais ampla de requisitos para satisfazer o usuário do software.
Matthews (2009, p. 85), explica cada um dos “favos da colmeia”:
• Utilidade – é importante ver o produto do ponto de vista do cliente/usuário, bus-
cando verificar a real necessidade dele e se o software atende a essa necessidade.
As perguntas que devem ser feitas são: Esse software vai ser útil ao meu cliente?
Ele atende às suas necessidades? Para que ele serve? Quais são as suas funções?
A partir desse questionamento, é mais claro entender o que é realmente importan-
te contemplar no software em termos de funcionalidade.
• Usabilidade – A facilidade de uso é essencial, porém uma interface focada ape-
nas na boa interação homem-computador não atende a todas as necessidades do
usuário. Ou seja, a usabilidade é necessária, mas não suficiente. A pergunta que
deve ser feita é: O usuário consegue entender o que deve ser feito sem nenhuma
explicação? Ou: A navegação é intuitiva?
• Desejo – A sensação de conforto e bem-estar é grandemente influenciada pe-
las cores e pela estética do software como um todo. O usuário precisa sentir-se
bem ao interagir com ele, por isso é importante cuidar da organização visual do
software, buscando trabalhar em conjunto com webdesigners, para que a expe-
riência do usuário seja gratificante. As perguntas a se fazer são: O usuário vai
gostar da aparência do software? Ele vai ter vontade de navegar novamente nele?
Vai ser uma experiência gratificante?
• Encontrabilidade – Os conteúdos devem ser facilmente localizáveis para que o
usuário encontre rapidamente o que precisa. As perguntas que devem ser fei-
tas são: O usuário consegue encontrar as informações que precisa rapidamente?
As informações estão visíveis, de modo que ele não precise ficar procurando por elas?
• Acessibilidade – Assim como os edifícios e calçadas são pensados para atender
pessoas com deficiência (mais de 10% da população), os sites e softwares também
devem ter essa preocupação, apresentando soluções que ampliem a acessibilidade
das pessoas com deficiência, além de crianças e idosos. As perguntas que devem
ser feitas são: Que ferramentas são necessárias para auxiliar uma pessoa com defi-
ciência (visual, auditiva, motora etc.) a utilizar esse software? No caso de crianças
ou idosos, que adaptações são necessárias ao software para que esses públicos
possam utilizá-lo adequadamente?
• Credibilidade – Um dos pontos fortes do software é a reputação de ser confiável.
Isso significa que ele deve funcionar perfeitamente, sem travar ou dar mensagens
de erro. A pergunta que deve ser feita é: O usuário pode confiar nesse software?
• Valor – O software deve dar um retorno real ao cliente/usuário. Deve ser uma
experiência marcante, que traga soluções e faça, efetivamente, a diferença. A per-
gunta a ser feita é: Esse software satisfaz as necessidades do usuário, contribuindo
para sua experiência?

Qualidade e Usabilidade de Software 95

 6 Fundamentos da interação homem-computador (IHC)

As facetas da experiência do usuário servem a vários propósitos, funcionando como

uma ferramenta que ajuda a pensar além da usabilidade e dos limites convencionais. Ao
perceber como todas essas facetas se integram de forma harmoniosa, é fácil concluir que
uma simples mudança no layout não é suficiente para solucionar os problemas de um siste-
ma ou um software.

6.1.2 Os modelos mentais e a IHC

O conhecimento sobre modelos mentais humanos, área de estudo da engenharia semió-
tica, é outro aspecto importante da IHC. As pessoas raciocinam com modelos mentais, os
quais podem ser compreendidos como blocos de construção cognitivos que são combinados
e recombinados conforme a necessidade. “Como quaisquer outros modelos, eles represen-
tam o objeto ou a situação em si; uma de suas características mais importantes é que sua es-
trutura capta a essência (se parece analogicamente) dessa situação ou objeto” (HAMPSON;
MORRIS, 1996, p. 243). Assim, um modelo mental pode ser entendido como uma represen-
tação interna de informações que corresponde de forma análoga a uma representação do
mundo real ou que está o mais próximo possível do mundo real.
Usuários de tecnologia digital aprendem e mantêm o conhecimento e as habilidades
de diferentes formas, muitas vezes influenciados por sua idade, bem como por fatores de
seu contexto cultural e social. Assim, estudos da engenharia semiótica apontam para uma
lacuna entre os usuários e as novas tecnologias, que agora surgem muito mais rapidamente
do que no passado. Isso ocorre porque, muitas vezes, os desenvolvedores e os usuários têm
uma visão distinta da aplicação, ou seja, os desenvolvedores veem o software “por dentro”
– visão obtida a partir de linguagens de programação que descrevem o funcionamento do
sistema –, enquanto os usuários têm uma visão externa, da interface de usuário. Por isso,
é importante inserir no desenvolvimento do software a atividade de design, de modo que
desenvolvedores e usuários possam compartilhar a mesma visão do produto.
As formas naturais eficientes e eficazes da IHC podem reduzir o nível das habilidades
necessárias para utilizar dispositivos complexos. Uma interface natural, intuitiva, eficiente,
robusta e configurável pode diminuir significativamente a distância entre os modelos men-
tais e os computadores e máquinas (WEBER, 2012).
Assim, é possível minimizar as potenciais desigualdades entre as pessoas, para ajudá-
-las a resolver um problema como o “fosso digital” – o abismo existente entre os indivíduos
que têm acesso às tecnologias digitais (tecnologias da informação e comunicação – TICs) e
possuem as habilidades necessárias para utilizá-las e aqueles que não têm acesso a elas ou
não possuem tais competências (WEBER, 2012).

6.1.3 Componentes básicos do sistema de IHC

Segundo Weber (2012), os componentes básicos do sistema de IHC são: usuário, com-
putador, diálogos, objetos de interação e sistemas de significados.

96 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
[Link] Usuário
O ser humano tem uma capacidade limitada para processar informações (WEBER,
2012), e saber disso é muito importante na elaboração do design de um software.
A comunicação humana se dá por meio de quatro canais de entrada/saída: visão, audi-
ção, tato e movimento (WEBER, 2012). A informação que uma pessoa recebe é armazenada
na memória sensorial, na memória de curto prazo e na memória de longo prazo. Assim
que recebida, ela é processada racionalmente pelo indivíduo e decodificada em função das
habilidades adquiridas por este, como, por exemplo, ser capaz de resolver problemas ou
erros. Por isso mesmo, um fato a ser destacado é que todos os usuários terão habilidades
em comum, mas haverá outras que irão variar de indivíduo para indivíduo (WEBER, 2012).

[Link] Computador
Os dispositivos computacionais utilizados podem afetar de diferentes maneiras o usuá-
rio. Os dispositivos permitem a inserção de texto, como no caso do teclado do computador,
do tablet e do smartphone, seja um discurso oral ou um manuscrito, de desenho, seleções na
tela com o mouse ou as mãos etc.
Sistemas de realidade virtual e visualização em 3D desempenham um papel muito im-
portante na interatividade homem-computador. E esse recurso tende a ser cada vez mais
utilizado, como mostra a Figura 4.

Figura 4 – Realidade virtual e visualização em 3D.

Fonte: aurielaki/iStockphoto.

O processo de IHC se baseia no hardware e no software que, juntos, fazem o diálogo

entre o sistema e o usuário, compondo a interface. Segundo Souza et al. (1999),

Qualidade e Usabilidade de Software 97

 6 Fundamentos da interação homem-computador (IHC)

O termo interface é aplicado normalmente àquilo que interliga dois sistemas.

Tradicionalmente, considera-se que uma interface homem-máquina é a parte de
um artefato que permite a um usuário controlar e avaliar o funcionamento deste
artefato através de dispositivos sensíveis às suas ações e capazes de estimular
sua percepção. No processo de interação usuário-sistema a interface é o combi-
nado de software e hardware necessário para viabilizar e facilitar os processos
de comunicação entre o usuário e aplicação. A interface entre usuários e sistemas
computacionais diferencia-se das interfaces de máquinas convencionais por exi-
gir dos usuários um maior esforço cognitivo em atividades de interpretação e
expressão das informações que o sistema processa.
Grande parte da investigação da IHC visa melhorar a usabilidade e as outras facetas da
experiência do usuário, concentrando-se principalmente em (BENYON, 2011):
• métodos para a concepção de novas interfaces de computador e otimização do de-
senho das propriedades desejadas pelo usuário final, como a capacidade de apren-
dizagem ou a eficiência de utilização;
• métodos para avaliar e comparar as interfaces no que diz respeito a suas proprie-
dades, por exemplo, sua capacidade de uso;
• métodos para estudar o uso de computadores e suas implicações socioculturais;
• perspectivas para reflexão crítica sobre os valores do design computacional, do
uso do computador e da pesquisa de interação humano-computador.

[Link] Diálogos
São as sequências que ocorrem entre o sistema e o homem. Os diálogos estão associados
às formas com que os objetivos práticos dos usuários se efetivam nas interações com o siste-
ma. Um componente básico do diálogo é a ação que pode ser entendida como uma interação
elementar, em que a entrada significativa do usuário deverá ser acompanhada de feedback do
sistema (NIELSEN, 2000).

[Link] Objetos de interação

São objetos de software que geram imagens que devem ser apresentadas ao usuário
com o qual haverá uma interação. Esses objetos devem ter ligação com as interfaces, bem
como com o ambiente, incluindo o primeiro plano, o pano de fundo e as bordas (NIELSEN,
2000). Alguns objetos de interação são:
• janelas;
• caixas de diálogo;
• botões;
• barras de rolagem;
• menus;
• caixas de mensagem; etc.

98 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
A figura a seguir demonstra a disposição desses objetos em uma interface:

Figura 5 – Objetos de interação.

Caixa de
mensagem

Barra de
rolagem

Botões

Janela
Fonte: IESDE BRASIL S./A.

A Figura 6 traz exemplos de pop-ups, janelas que abrem no navegador quando uma
página é acessada. Geralmente traz publicidade (anúncios) ou mensagens de redireciona-
mento de links.

Figura 6 – Exemplos de pop-ups.

Fonte: Gal_Istvan/iStockphoto.

[Link] Sistemas de significados

A semiótica é uma ciência que estuda os signos e seus processos de significação e co-
municação. Já signo é “aquilo que, sob certo aspecto ou modo, representa algo para alguém”
(PEIRCE, 2005, p. 46), ou seja, o signo substitui uma coisa por outra coisa, produzindo um
efeito interpretativo. O signo é o mediador entre o objeto e o interpretante. Segundo Peirce,
o signo é produto de três elementos:

Qualidade e Usabilidade de Software 99

 6 Fundamentos da interação homem-computador (IHC)

• a expressão: aquilo que ele representa;

• o objeto: aquilo que é representado;
• o interpretante: a capacidade mental empregada no contexto de processo do signo.
A engenharia semiótica estuda a relação do design e da interação no processo comuni-
cativo entre o designer (emissor da mensagem) e o usuário (receptor). Esse processo comu-
nicativo entre designer e usuário faz parte do processo de design. A engenharia semiótica
está presente no processo de design quando o designer busca adequar a mensagem por
meio de signos que o usuário compreenda, ou seja, ele precisa “traduzir” a linguagem de
programação em signos que fazem sentido para o usuário. Contudo, não há garantias de
que o usuário vai interpretar os signos da mesma forma que o designer. Por exemplo: um
usuário experiente sabe que o ícone abaixo (Figura 7) significa “salvar”. O disquete é o obje-
to representado, já a ideia de salvar é a expressão (aquilo que ele representa) e o interpretan-
te é a capacidade mental que o usuário emprega para processar o objeto em signo.

Figura 7 – Ícone salvar.

Fonte: Panptys/iStockphoto.

O disquete foi usado como disco de armazenamento de informações até o ano 2000,
depois disso seu uso foi abandonado. Pela sua função, acabou se tornando o ícone de vá-
rios aplicativos para a função salvar. Contudo, para um jovem que nunca teve contato com
um disquete na vida, esse ícone não lhe diz absolutamente nada por si só. O jovem precisa
aprender o significado desse ícone, que se tornou cultural. Portanto, não é possível prever o
modo como todos os usuários vão interpretar um signo, mas o designer deve refletir sobre o
modo como sua mensagem pode ser interpretada a fim de escolher a forma mais adequada
de transmiti-la2.

6.1.4 Interface cérebro-computador

A interface cérebro-computador (ICC) é um caminho comunicativo direto entre o cére-
bro e um dispositivo externo, como se o dispositivo lesse as informações que estão na mente

2 O ícone mantém uma estreita relação com o objeto que ele representa, como o ícone salvar, porque
ele representa um disquete, cuja função era de salvar arquivos. Já o símbolo não tem uma relação di-
reta com o objeto representado. Por exemplo: uma pomba é o símbolo da paz.

100 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
do usuário. O termo mente diz respeito à intenção do participante na pesquisa de IHC, visto
que suas ondas neuroelétricas são gravadas por um eletroencefalograma (EEG), ligado por
meio de eletrodos colocados sobre sua cabeça (WEBER, 2012).
Segundo Rogers et al. (2013), o dispositivo capta alterações no funcionamento do cé-
rebro. Os neurônios tornam-se ativos toda vez que pensamos, falamos, nos movemos etc.,
emitindo sinais elétricos que são detectados pelos eletrodos colocados no couro cabeludo ou
embutidos em fones de ouvido, toucas ou bonés especiais.
É desse modo que uma pessoa pode dominar um computador ou qualquer máquina
sem usar as mãos (ou qualquer outro meio, ou seja, sem o uso de qualquer músculo ou
nervo do próprio corpo). Essa tecnologia pode ajudar pessoas com deficiência visual ou
auditiva a voltar a enxergar ou a ouvir e pessoas com deficiência física a mover uma prótese
mecânica, por exemplo. Também tem sido usada em jogos, como o Brainball, em que os
jogadores controlam, com as ondas cerebrais, o movimento de uma bola sobre uma mesa,
podendo manter-se mais concentrados e relaxados. Outro emprego dessa tecnologia é no
controle de robôs e na possibilidade de se pilotar um avião virtual apenas pelo pensamento
(ROGERS et. al., 2013, p. 204).

6.2 Interação das atividades de IHC

com a engenharia de software

Desde 1960, quando o conceito de interatividade homem-computador surgiu, numero-

sas metodologias de design de software têm sido desenvolvidas. A maioria delas é baseada
no fato de que os designers têm de capturar a interatividade entre o usuário e o sistema téc-
nico. Nesse processo de criação, é preciso considerar o processo cognitivo do usuário. Nesse
aspecto, a engenharia de software conta com o auxílio da engenharia cognitiva, que se baseia
na psicologia cognitiva e na ciência cognitiva para entender como o ser humano constrói o
conhecimento. A engenharia cognitiva estuda as limitações da mente e a sua capacidade
para criar sistemas interativos que sejam fáceis de usar e agradáveis.
Assim, os modelos teóricos mais recentes focam em um feedback na comunicação entre
os usuários, os designers e os engenheiros de software. Para otimizar a interação das ativi-
dades de IHC no desenvolvimento do software, recomenda-se a adoção de (WEBER, 2012):
• Teoria da atividade – É usada para definir o contexto no qual a interação entre pes-
soas e computadores ocorre. Essa teoria considera que as ferramentas tecnológicas
servem de instrumentos mediadores entre as pessoas e o mundo, partindo do con-
ceito de mediação proposto por Vygotsky. Afinal, as pessoas agem como sujeitos
do mundo por meio da tecnologia. A teoria da atividade procura compreender
como se dá a interação entre o usuário e a tecnologia, fornecendo informações aos
desenvolvedores para projetar o design de interação.
• Design centrado no usuário – Sua filosofia é a ideia de que o usuário é o centro do
projeto em qualquer sistema de computador. Usuários, designers e equipe técnica

Qualidade e Usabilidade de Software 101

 6 Fundamentos da interação homem-computador (IHC)

trabalham em conjunto com o objetivo de articular o que é desejado; assim, é ne-

cessário conhecer as limitações dos usuários para se criar um sistema adequado.
Essa metodologia é semelhante à concepção de participação, a qual enfatiza a pos-
sibilidade de que os usuários finais devem contribuir para a criação do sistema.
• Princípios de design de interface – Deve-se considerar em todos os momentos, ao
se projetar a interface para o usuário:
◦◦ a simplicidade (deve ser de fácil utilização);
◦◦ a visibilidade (deve ser visível para facilitar a usabilidade);
◦◦ a viabilidade (deve ter design projetado com orçamento adequado);
◦◦ a coerência (deve ser feito em conformidade com o requerido pelos usuários);
◦◦ a estrutura (deve ter uma estrutura que permita a navegabilidade);
◦◦ e o feedback (deve possibilitar o contato entre usuários e desenvolvedor).

6.3 O computador, o homem e

os limites do sistema

A interação homem-computador ocorre por uma alternância de controle da situação,

ora pelo usuário, ora pelo computador, em três fases: ler-examinar, pensar e responder,
como demonstra a Figura 8. Os softwares devem ser desenvolvidos de forma a facilitar essa
interação entre o homem e a máquina (MAYHEW, 1992).

Figura 8 – O computador, o homem e os limites do sistema.

Domínio do controle Domínio do controle

do homem do computador

Responder Ler-examinar
Ação do usuário gerando Reconhecimento e interpre-
input para o computador tação dos inputs do usuário

I
N
Pensar
T Pensar
Tomada de deci-
E Processamento
sões (o que fazer
HOMEM R COMPUTADOR de input de
com a resposta
F acordo com os
recebida do
A algoritmos
computador)
C
E

Ler-examinar Responder
Reconhecimento e interpreta- Resposta do computador
ção da informação apresenta- enviada ao usuário
da pelo computador

Fonte: MAYHEW, 1992.

102 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
É possível perceber na Figura 8, que a interface faz a intermediação entre o homem e o
computador. O modelo de Mayhew se baseia na teoria da atividade ou teoria da ação, apre-
sentando um sistema interativo composto pelo homem, pelo computador e pelos limites
do sistema. As fases ler-examinar, pensar e responder são cíclicas e interligam as ações do
usuário às reações do computador e vice-versa. A engenharia cognitiva foca nessas ques-
tões, procurando auxiliar o designer a entender como o usuário constrói o conhecimento, de
modo a criar interfaces que sejam adequadas ao seu perfil e ao ambiente de uso, facilitando
ainda mais o aprendizado.
Uma das causas de problemas na interação homem-computador é que os desenvol-
vedores muitas vezes não levam em conta que o software desenvolvido não é um produto
independente – ao contrário, pois pertence a um sistema maior, que terá diferentes tipos de
usuários e fará parte de vários subsistemas (MAYHEW, 1992).
Mayhew (1992) alerta que qualquer sistema novo que utilize a IHC deveria iniciar com
a definição de um sistema interativo; assim, decisões sobre usabilidade e funcionabilidade
deveriam partir da compreensão clara dos objetivos da organização, do usuário e do traba-
lho. Isso também engloba a compreensão das limitações humanas para a realização do pro-
cessamento das informações, bem como o perfil, a habilidade e o conhecimento específico
dos usuários. Nesse modelo, os computadores são pensados para suprir as dificuldades do
usuário, de modo que a interação seja o mais simples possível, devido ao esforço da enge-
nharia cognitiva. Esses conhecimentos auxiliam o designer a criar modelos mentais adequa-
dos ao sistema, que sejam mais próximos das expectativas dos usuários.

Ampliando seus conhecimentos

O texto a seguir explica de que modo a interação homem-computador

envolve outras áreas do conhecimento e se beneficia dessas áreas para
melhorar a experiência do usuário com as novas tecnologias.

IHC como área multidisciplinar

(BARBOSA, 2011, p. 12)

IHC se beneficia de conhecimento e métodos de outras áreas fora da com-

putação para conhecer melhor os fenômenos envolvidos no uso de sis-
temas computacionais interativos. Áreas como Psicologia, Sociologia e
Antropologia contribuem para aquisição de conhecimento sobre a cultura
e o discurso dos usuários e sobre seus comportamentos no ambiente onde
realizam suas atividades, sejam elas individuais ou em grupo. A definição
da interface com usuário faz uso de conhecimentos e técnicas de áreas
como: Design, Ergonomia, Linguística e Semiótica.

Qualidade e Usabilidade de Software 103

 6 Fundamentos da interação homem-computador (IHC)

Alguns conhecimentos e técnicas importados de outras áreas além da com-

putação são adaptados às necessidades de IHC. Por exemplo, a Psicologia
utiliza extensamente entrevistas para ter acesso às concepções, emoções
e subjetividade das pessoas. Isso é muito mais profundo e complexo que
a utilização mais frequente de entrevistas em IHC, através das quais nor-
malmente investigamos a compreensão sobre um domínio, opiniões sobre
certos sistemas interativos e o que ocorreu durante uma experiência de
uso para avaliação da interface com usuário. Algumas técnicas de apre-
sentação de conteúdos estáticos, como as utilizadas em jornais, revistas e
livros, foram adaptadas em IHC, para lidar com a dinâmica da interface,
bem como conteúdos hipermídias.

A área de IHC articula uma grande quantidade de conhecimen-

tos oriundos de diversas áreas. Isso torna muito mais difícil que um
único profissional tenha conhecimento profundo de todos os objetos
de estudo de IHC. Se um único profissional dificilmente conhece em
profundidade todos os assuntos relacionados com a interação entre
pessoas e sistemas computacionais, como é possível cuidarmos das
questões relacionadas com a IHC de forma adequada? Idealmente, a
responsabilidade de cuidar de IHC deve ser atribuída a uma equipe
multidisciplinar. Dessa forma, profissionais com formações diferentes
podem trabalhar em conjunto, concebendo e avaliando a interação de
pessoas com sistemas computacionais.

Esse ambiente heterogêneo de profissionais com diferentes formações

facilita o surgimento de ideias, a criatividade e a inovação, bem como
auxilia a análise do problema e de alternativas de soluções sob pontos
de vista bem variados, enriquecendo, assim, o resultado do trabalho. [...]

Atividades
1. A interação ser humano-computador envolve desde requisitos para a criação de uma
aplicação até as análises das reações dos usuários ao utilizarem-na. Quais são os fa-
tores fundamentais da interação humano-computador?

2. Cite os modelos recentes de IHC com foco no usuário que se destinam a obter a ex-
periência deste.

3. Quais são as facetas da experiência do usuário presentes no honeycomb?

4. Quais os desafios que a multidisciplinaridade da IHC traz aos pesquisadores e de-

senvolvedores da área?

104 Qualidade e Usabilidade de Software

 Fundamentos da interação homem-computador (IHC) 6
Referências
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 9241-11: Requisitos Ergonômicos para
Trabalho de Escritórios com Computadores. Rio de Janeiro, 2002.
ANDRADE, A. Usabilidade de interfaces web. Avaliação heurística no jornalismo on-line. Rio de
Janeiro: E-papers, 2007.
AZUMA, R. A Survey of Augmented Reality. Presence: Teleoperators and Virtual Environments, v. 6,
n. 4, p. 355-385, Aug. 2007. Disponível em: <[Link] Acesso
em: 3 ago. 2017.
BARBOSA, S. D. J. Interação humano-computador. Rio de Janeiro: Elsevier, 2011.
BENYON, D. Interação humano-computador. 2. ed. São Paulo: Pearson Prentice Hall, 2011.
CASTELLS, M. O poder da comunicação. São Paulo: Paz e Terra, 2013.
COSTA, R. Por um novo conceito de comunidade: redes sociais, comunidades pessoais, inteligência
coletiva. Interface – Comunicação, Saúde, Educação, v. 9, n. 17, p. 235-48, mar./ago. 2005.
HAMPSON, P. J.; MORRIS, P. E. Understanding cognition. Cambridge, MA: Blackwell Publishers,
1996.
MATTHEWS, J. R. The customer-focused library: re-inventing the library from the outside-in. Santa
Barbara, CA: Libraries Unlimited, 2009.
MAYHEW, D. J. Principles and guidelines in software user interface design. New Jersey: PTR
Prentice Hall, 1992.
NIELSEN, J. Usability Enginnering. San Francisco, CA: Morgan Kaufmann, 1993.
THOMPSON, J. B. A mídia e a modernidade: uma teoria social da mídia. 7. ed. Petrópolis: Vozes, 2005.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2012.

Resolução
1. Usabilidade, viabilidade e acessibilidade.

2. Teoria da atividade, design centrado no usuário, além dos princípios do design

de interface.

3. Utilidade, usabilidade, desejo, encontrabilidade, acessibilidade, credibilidade, valor.

4. A IHC articula um grande número de conhecimentos advindos de áreas diversas.

É difícil encontrar um profissional que tenha conhecimento de todas essas áreas, sen-
do necessária uma equipe multidisciplinar que trabalhe em conjunto, o que também
constitui um desafio para toda a equipe e os gestores.

Qualidade e Usabilidade de Software 105

 7
Usabilidade de software

Introdução

A usabilidade é considerada um atributo de qualidade que avalia a facilidade

com que uma interface gráfica de software é utilizada. Ela também se refere à apli-
cação de métodos, durante um processo de design, para melhorar essa utilização
(NIELSEN, 1993).

Entre os fatores que determinam a usabilidade, pode-se mencionar a acessibili-

dade, a legibilidade, a navegabilidade, a facilidade de aprendizado, a eficiência do
usuário e os índices de erros.

A expansão da usabilidade tem forçado uma simplificação nos sistemas de

software. Compreender e pesquisar a interação entre o usuário e o especialista em
usabilidade pode antecipar e identificar a funcionalidade do produto que está sendo
desenvolvido, levando em conta o perfil do usuário a que se destina.

Desse modo, a usabilidade, como abordada neste capítulo, é uma das vertentes
importantes da qualidade em software.

Qualidade e Usabilidade de Software 107

 7 Usabilidade de software

7.1 Definições de usabilidade do software

A capacidade com que as pessoas podem utilizar uma ferramenta é chamada de usabi-
lidade, que também pode se referir ao estudo dos princípios da eficácia percebida de um ob-
jeto. Esse modelo conceitual engloba o desenvolvimento de um produto focado no usuário.
A usabilidade tem relação com o grau de facilidade de utilização de um sistema e é
mensurada por testes relativos e empíricos: o teste empírico baseia-se em testes de usabili-
dade ou em trabalho em campo, já o relativo depende das metas estabelecidas ou de uma
comparação com outro guia de sistemas similares.

A International Organization for Standardization (ISO) for-

nece duas definições de usabilidade:
A ISO/IEC 9241 afirma que a usabilidade se refere à “medida na qual um produto
pode ser usado por usuários específicos para alcançar objetivos específicos com efi-
cácia, eficiência e satisfação em um contexto específico de uso” (ABNT, 2002, p. 3).
Já a ISO 9126-1, ampliando esse conceito, define a usabilidade como a “capa-
cidade do produto de software de ser compreendido, aprendido, operado e atra-
ente ao usuário, quando usado sob condições especificadas” (ABNT, 2003, p. 9).
Então, essa concepção abrange um conjunto de critérios, tais como segurança e
utilidade, que estão relacionados principalmente aos sistemas de computador.

Essas são definições centradas no conceito de qualidade em uso, ou seja, referem-se à

forma como o usuário executa determinadas tarefas em cenários específicos, de forma eficaz.
Tendo por base esses conceitos dados pela ISO, os princípios básicos da usabilidade
podem ser assim definidos: facilidade de uso, facilidade de aprendizado, flexibilidade e
robustez. O Quadro 1, a seguir, explica cada um desses princípios:

Quadro 1 – Princípios de usabilidade.

Princípio Característica
Facilidade com que o usuário faz uso da ferramenta, com
Facilidade de uso menos etapas para chegar a seu objetivo proposto, estan-
do relacionada à eficiência da ferramenta.
Facilidade com que novos usuários desenvolvem uma
Facilidade de
interação com o sistema ou produto, relacionada com a
aprendizado
familiaridade e a previsibilidade.
Relacionada à diversidade de formas de executar uma de-
Flexibilidade
terminada tarefa e otimização entre usuário e sistema.
Facilidade e nível de serviço oferecido de suporte para
Robustez cumprir os objetivos, estando relacionado com a recupe-
ração de informações e o ajuste de tarefas do usuário.
Fonte: WEBER, 2006. Adaptado.

108 Qualidade e Usabilidade de Software

 Usabilidade de software 7
7.2 Métodos de usabilidade

No centro do processo de criação do software, a usabilidade representa um projeto que

incorpora os desejos e as necessidades do usuário, os quais são especificados desde o início
do processo e têm papel importante nas decisões sobre o produto. Nesse projeto devem
ser envolvidos, em conjunto, os usuários, os especialistas em teste e os avaliadores. Assim,
identificar as demandas do usuário, algo essencial para a construção de um software, é a
primeira etapa no processo de desenvolvimento.
A abordagem do usuário para investigação de suas necessidades possui duas variantes
distintas. Ela pode ser uma abordagem contextual, com uma entrevista estruturada para
compreensão do seu contexto no processo de design, determinando um foco na sua aplica-
ção, ou uma abordagem etnográfica, na qual é observado o usuário e sua interação com o
produto em seu ambiente habitual.

7.2.1 Métodos empíricos

Os métodos empíricos para avaliar a usabilidade das interfaces do ­software podem ser
realizados com ou sem a participação dos usuários. Entre esses métodos, estão os especifi-
cados a seguir:

[Link] Arranjo de cartões (card sorting)

É uma técnica realizada por um grupo de especialistas que fazem testes com usuários
para gerar um dendograma (árvore de categorias), com uma abordagem útil para projetar
uma arquitetura de informações, o fluxo de trabalho, a estrutura de menus ou os caminhos
de navegação do site (JORDAN, 1998).
A classificação de cartões utiliza uma técnica relativamente simples. A pessoa que conduz o
teste (analista de usabilidade, desenvolvedor, entre outros) identifica primeiro os conceitos-cha-
ve e os grava em cartões. Geralmente, a aplicação é testada individualmente ou em grupos, que
podem ser colaborativos (grupos focais); no entanto, na literatura da área não existe um consen-
so sobre o número de indivíduos necessários para produzir resultados confiáveis.
Um cartão é comumente utilizado para projetar uma estrutura de navegação a um am-
biente que oferece uma variedade de conteúdos e funções, como um site da web. Nesse con-
texto, os itens a serem organizados são aqueles mais significativos nesse ambiente, de uma
forma que faça sentido para o público-alvo. Como o campo da arquitetura de informação
se baseia no estudo da estrutura das informações, a classificação de cartões é útil quando:
• a variedade de itens a organizar é tão grande que nenhuma taxonomia existente é
aceita como organização dos itens;
• as semelhanças entre os itens tornam difícil uma divisão clara em categorias;
• os membros do público que usam o ambiente diferem significativamente em termos
de como veem as semelhanças entre os itens e os agrupamentos apropriados destes.

Qualidade e Usabilidade de Software 109

 7 Usabilidade de software

Figura 1 – Técnica card sorting de categorização de informações.

Fonte: Abscent84/iStockphoto.

O card sorting, como ilustrado na Figura 1, ajuda na classificação e organização dos con-
teúdos de um website sob o ponto de vista dos usuários.

[Link] Avaliação cooperativa (cooperative evaluation)

É um procedimento para obter dados sobre problemas experimentados na utilização
de um software, de modo que é aplicado com o intuito de melhorar o uso do produto final.
O que distingue esse método é a cooperação que ocorre à medida que pesquisador e partici-
pantes avaliam, juntos, uma interface (JORDAN, 1998).
O objetivo da técnica não é fornecer uma lista exaustiva de todos os problemas que
poderiam ser identificados, mas sim ajudar a identificar, com o mínimo de esforço, os pro-
blemas mais importantes a serem considerados.
Essa metodologia de avaliação pode ser usada com:
• um produto existente que deve ser melhorado ou ampliado;
• um protótipo ou uma simulação parcial precoce;
• um protótipo de trabalho completo.
Além disso, para a avaliação ser considerada cooperativa, ela deve especificar tarefas
permitindo que cada participante explore áreas da interface consideradas mais relevantes
à pesquisa. Depois da interação, os participantes verbalizam os problemas encontrados e o
pesquisador registra as observações. Por fim, o pesquisador, com base no que foi levantado
e anotado, analisa os resultados e propõe soluções (PUC-RIO, 2017).

110 Qualidade e Usabilidade de Software

 Usabilidade de software 7
[Link] Diários de incidentes (incident diaries)
Segundo Jordan (1998), os diários de incidentes são miniquestionários emitidos para
os participantes, a fim de que tomem notas de qualquer problema encontrado durante a
utilização de uma interface.
Geralmente, é solicitado que os indivíduos forneçam uma descrição por escrito do pro-
blema; depois, pergunta-se como eles resolveriam tal problema e de que forma essa situação
os incomodava. Esse método é apropriado para utilização no caso de interfaces finalizadas
e que já estão em uso, sendo que os diários registram informações sobre os problemas que
ocorrem durante o ciclo de vida da interface em questão. Os dados coletados podem ser
aplicados para avaliar a usabilidade da interface atualmente utilizada ou para a tomada de
decisões sobre projetos futuros.

[Link] Grupo focal (focus group)

Essa é uma técnica de pesquisa qualitativa em que um grupo de pessoas é reunido para
discutir um assunto particular em relação ao produto de software, seguindo um roteiro de
questões proposto e coordenado por um moderador (JORDAN, 1998).
Essa discussão pode ser, por exemplo, sobre experiências dos usuários na utilização de
uma interface, com informações em relação a tarefas específicas ou problemas de usabilida-
de. Também abrange requerimentos para uma nova interface, com base nos pontos que, de
acordo com os participantes, necessitam de melhorias.
Em geral, a investigação de problemas de usabilidade envolve grupos de, em média,
cinco ou seis indivíduos. Nesse processo, o trabalho do moderador/líder do grupo é, princi-
palmente, assegurar que todos os participantes exponham suas opiniões a respeito do pro-
duto (PUC-RIO, 2017).

[Link] Experimentos controlados (controlled experiments)

Um experimento controlado é aquele em que tudo é mantido constante, exceto uma
variável. Geralmente, um conjunto de dados é tomado para um grupo de controle – que é
comumente o estado normal ou usual –, e um ou mais grupos são examinados, com condi-
ções idênticas a esse grupo controle, exceto a variável. Às vezes é necessário alterar mais de
uma variável, mas todas as condições experimentais são controladas, de modo que apenas
as variáveis que estão sendo examinadas mudam e a quantidade ou a maneira em que mu-
dam é medida (JORDAN, 1998).

[Link] Lista de verificação de recursos/características (feature

checklists)
Esse método visa avaliar a importância que os participantes dão a determinadas carac-
terísticas de uma interface.

Qualidade e Usabilidade de Software 111

 7 Usabilidade de software

A primeira coisa a se fazer na construção de uma lista de verificação de recursos é

a definição dos tipos de software (programas ou componentes deles). A segunda etapa é
definir atributos úteis para cada tipo de objeto de avaliação. Como o principal princípio de
organização é ser orientado para o usuário, é importante seguir as características de quali-
dade para o software, como definido pela ISO 9126. Além disso, a lista de verificação deve ser
construída sob o princípio de métodos de ensaio rigorosos: atributos são incluídos apenas
se eles se baseiam em valores formais bem definidos.
As listas de verificação de características são mais eficazes no caso de interfaces finali-
zadas que estão sendo utilizadas há algum tempo. Assim, é possível usar os dados obtidos
para a fase de requisitos do projeto de uma nova interface (JORDAN, 1998).

[Link] Protocolos “pensar alto” (think aloud protocols)

O protocolo de pensamento em voz alta é usado para coletar dados em testes de usa-
bilidade em design e desenvolvimento de produtos, em psicologia e em diversas ciências
sociais (por exemplo, leitura, escrita, pesquisa de tradução, processamento e rastreamento
de processos). O método foi introduzido no campo de usabilidade por Clayton Lewis1, en-
quanto ele trabalhava na IBM, e desenvolvido com base nas técnicas de análise de protocolo
de Ericsson e Simon (1993).
No entanto, existem algumas diferenças significativas entre a forma como Ericsson e
Simon propõem que os protocolos sejam conduzidos e como isso é realmente feito na prá-
tica, devido às necessidades específicas e ao contexto dos testes de usabilidade. Assim, os
profissionais devem estar cientes dessas diferenças e ajustar seu método para atender às
suas necessidades enquanto ainda coletam dados válidos. Por exemplo, eles podem precisar
solicitar informações adicionais com mais frequência do que Ericsson e Simon permitiriam,
mas devem tomar cuidado para não influenciar o que os participantes dizem e fazem.
Os protocolos think aloud envolvem participantes “pensando em voz alta” enquanto
executam um conjunto de tarefas especificadas, ou seja, eles são convidados a dizer o que
vêm à sua mente enquanto completam atividades. Isso pode incluir o que eles estão olhan-
do, pensando, fazendo e sentindo, o que dá aos observadores uma visão dos processos cog-
nitivos dos participantes (e não somente do seu produto final), para tornar os mecanismos
de pensamento tão explícitos quanto possível durante o desempenho de cada tarefa. Em
um protocolo formal de pesquisa, todas as verbalizações são transcritas e depois analisadas.
Em um contexto de teste de usabilidade, os observadores são convidados a tomar notas
do que os participantes dizem e fazem, sem tentar interpretar suas ações e palavras e, espe-
cialmente, observando em que pontos eles encontram dificuldade. As sessões de teste são
frequentemente gravadas em áudio e vídeo, para que os desenvolvedores possam verificar
posteriormente o que os participantes fizeram e como reagiram. Um método de coleta de
dados relacionado, mas ligeiramente diferente, é o protocolo de conversa em voz alta, que
envolve os participantes apenas descrevendo suas ações, mas não outros pensamentos.

1 Clayton Lewis é professor de Informática conhecido por suas pesquisas sobre métodos de avaliação
no design da interface do usuário. Ele deu grandes contribuições ao método de pensamento em voz
alta, usado regularmente em organizações de desenvolvimento de software no mundo todo.

112 Qualidade e Usabilidade de Software

 Usabilidade de software 7
O think aloud pode ser distinguido em dois tipos diferentes de procedimentos experi-
mentais. O primeiro é o protocolo de pensamento em voz alta simultâneo, coletado durante
a tarefa, e o segundo é o retrospectivo think loud reunido após a tarefa. Existem benefícios
e desvantagens em cada abordagem, mas em geral um protocolo simultâneo pode ser mais
completo, enquanto um protocolo retrospectivo tem menos chance de interferir no desem-
penho da tarefa.

[Link] Questionário (questionnaires)

Segundo Eduardo Brandão,
a palavra ‘questionário’ é utilizada para distinguir um arranjo de questões, in-
cluindo algumas perguntas, listas de checagem, técnicas projetivas, escalas de
avaliação e uma variedade de outros métodos. A função deste arranjo de questões
é estabelecer (obter gradualmente) uma comunicação particular. (BRANDÃO,
2006, p. 182)
Essas questões são compiladas pelo pesquisador e propostas aos participantes.
Os questionários podem conter listas de perguntas abertas ou fechadas e deve-se evitar
linguagem muito técnica, complexa (JORDAN, 1998). No caso de questionários fechados, as
questões precisam ser bem elaboradas para fazer com que as categorias de respostas sejam
significativas para a pesquisa. Assim, as alternativas apresentadas ao participante devem
cobrir uma ampla gama de respostas possíveis para cada situação. Os questionários abertos,
por sua vez, necessitam de perguntas mais abrangentes, permitindo aos respondentes desta-
car todos os assuntos que considerem importantes em relação à interface avaliada. Esse tipo
de questionário é, geralmente, mais adequado no caso de interfaces que se encontram em
estágios iniciais, antes de elementos específicos de usabilidade serem claramente definidos
(PUC-RIO, 2017).

[Link] Registro de conversações (private camera conversations)

Para evitar a interferência do pesquisador, nesse método o participante vai a um estan-
de e conversa em frente a uma câmera sobre os tópicos dados a ele(a). A gravação de vídeo
pode fazer com que os participantes tragam à tona aspectos mais intuitivos do que na pre-
sença de um entrevistador, quando tendem a querer agir mais racionalmente.
Normalmente, a conversa diante de uma câmera privada acontece depois de o partici-
pante ter lidado com um protótipo de software por um tempo, mas pode acontecer também
durante o uso de teste. Esse registro de conversações pode desencadear dados experienciais
mais autênticos do que em uma entrevista “cara a cara”. Se dois amigos estiverem juntos no
estande, por exemplo, a discussão poderá revelar aspectos experienciais interessantes. No
entanto, o registro não garante que os participantes falarão sobre os temas que são de inte-
resse do pesquisador. Além disso, nem todo tipo de participante se sente confortável para
conversar em frente a uma câmera de vídeo (JORDAN, 1998; PUC-RIO, 2017).

Qualidade e Usabilidade de Software 113

 7 Usabilidade de software

[Link] Registro de uso (logging use)

Nesse método, softwares gravam interações entre os usuários, permitindo a coleta de
informações sobre a utilização do produto. Para tanto, é utilizado um laboratório de usabili-
dade, em que duas salas são interligadas por um espelho translúcido, proporcionando uma
observação livre. Uma câmera de vídeo registra a expressão facial e a fala dos usuários ao
longo do teste. De acordo com Brandão (2006, p. 186), a utilização de um método de registro
de uso “resulta na informação sobre a extensão da interação de um participante com um
aspecto da interface, ou o número de vezes que um comando particular foi utilizado. No
entanto, esta informação necessita de interpretação”.

7.2.2 Métodos não empíricos

Na avaliação de usabilidade em interfaces de software, também são utilizados os méto-
dos não empíricos, como os descritos na sequência.

[Link] Análise da tarefa (task analyses)

É o processo de aprendizagem sobre os usuários comuns, observando-os em ação para
entender em detalhes como eles executam suas tarefas e atingem seus objetivos pretendidos.
Esse tipo de análise ajuda a identificar as tarefas que sites e aplicativos devem oferecer e
também pode ajudar a refinar ou redefinir a navegação ou a pesquisa de um site, determi-
nando o escopo de conteúdo apropriado.
A análise de tarefas ajuda a suportar vários outros aspectos do processo de design cen-
trado no usuário, incluindo: coleta de requisitos, desenvolvimento de estratégia de conteú-
do, prototipagem e execução de testes de usabilidade. Entre as técnicas mais comumente
utilizadas, estão: a análise de tarefas cognitivas, focada na compreensão de tarefas que re-
querem tomada de decisão, resolução de problemas, memória, atenção e julgamento; e a
análise de tarefas hierárquicas, focada na decomposição de tarefas de alto nível em subtare-
fas (JORDAN, 1998).

[Link] Avaliação heurística (heuristic evaluation)

O objetivo principal das avaliações heurísticas é identificar quaisquer problemas asso-
ciados ao design de interfaces de usuário. O consultor de usabilidade Jakob Nielsen2 (1993)
desenvolveu esse método com base em seus vários anos de experiência em ensino e consul-
toria sobre engenharia de usabilidade. Essas avaliações são um dos métodos mais informais
de inspeção da usabilidade no campo da interação homem-computador.

2 Cientista da computação com Ph.D. em interação homem-computador. Inventou vários métodos de

usabilidade, entre eles a avaliação heurística.

114 Qualidade e Usabilidade de Software

 Usabilidade de software 7
Existem diversos conjuntos de usabilidade de avaliação heurística, os quais não são mu-
tuamente exclusivos e cobrem muitos dos mesmos aspectos do design da interface do usuário.
Os problemas de usabilidade descobertos são categorizados, muitas vezes em uma escala numé-
rica, de acordo com seu impacto estimado no desempenho ou na aceitação do usuário. Esse tipo
de avaliação é frequentemente realizada no contexto de casos de uso (tarefas típicas do usuário),
para fornecer feedback aos desenvolvedores sobre a medida em que a interface é susceptível de
compatibilidade com as necessidades dos usuários (JORDAN, 1998).

[Link] Avaliação de peritos (expert appraisals)

Nesse método, a interface é avaliada por meio da opinião de um ou mais peritos (espe-
cialistas) da área, que pode trabalhar individualmente ou em conjunto.
É uma avaliação geralmente utilizada para verificação de designs iniciais e protótipos.
O grupo de especialistas selecionados tem know-how para inspecionar de modo mais apro-
fundado os princípios de usabilidade, oferecendo meios/soluções para eventuais inadequa-
ções (JORDAN, 1998).

[Link] Lista de verificação de propriedades (property checklists)

As listas de verificação/checklist relacionam uma série de propriedades de projeto que,
de acordo com as teorias do design, da ergonomia e do ergodesign, asseguram que uma
interface é fácil de ser usada. Podem conter itens como consistência da interface, compatibi-
lidade, padrões, retorno ao usuário (feedback), posição de displays e controles, nomenclatura
de botões, tamanho de caracteres na tela, entre outras propriedades (PUC-RIO, 2017).
Os participantes da avaliação devem marcar, na lista, as características utilizadas na
interface em questão. Para Jordan (1998), os checklists são mais eficazes para análise de inter-
faces já finalizadas.

[Link] Percurso cognitivo (cognitive walkthroughs)

É um método de avaliação da usabilidade também realizado por peritos. No percur-
so cognitivo, no entanto, como afirma Brandão (2006, p. 191), o pesquisador realiza a sua
avaliação
de acordo com o ponto de vista de um usuário típico da interface. Desta forma,
o investigador tenta desempenhar uma tarefa como se fosse o próprio usuário,
buscando predizer se este usuário pode enfrentar algum tipo de dificuldade du-
rante os vários estágios, ou passos, necessários para completar a tarefa.
Jordan (1998) ressalta que, para essa técnica funcionar, é preciso que o perito tenha uma
compreensão exata das características dos usuários para os quais a interface foi projetada,
incluindo suas habilidades e expectativas em relação ao produto.

Qualidade e Usabilidade de Software 115

 7 Usabilidade de software

7.3 A importância das recomendações

de usabilidade

As recomendações de usabilidade, ao serem incorporadas no desenvolvimento do

software, mensuram a facilidade do uso de um produto. Entre elas, pode ser citada a apli-
cação dos testes que determinam quanto o usuário demora para encontrar determinado
recurso e os erros cometidos durante esse caminho.

A acessibilidade do usuário é o principal ponto de estudo das indicações de

usabilidade, garantindo que a qualidade seja priorizada. Interfaces amigá-
veis e com adaptação para os usuários em diferentes tarefas e ambientes tec-
nológicos são uma tendência no desenvolvimento de produtos e sistemas.

Assim, a usabilidade determina a preocupação com a interação do usuário com o sis-

tema por meio de uma interface. O teste com usuários reais é a única maneira confiável de
determinar suas necessidades, o que pode ajudar na redução no número de chamadas de
suporte, tendo em vista que uma usabilidade ineficaz é a razão principal desse tipo de cha-
mada por parte dos usuários. (PRESSMAN; MAXIM, 2016).
A usabilidade também ajuda na redução do custo com treinamentos. Um software fácil
de se aprender evita custos de manutenção e revisão de produtos e versões. Além disso, o
produto é mais bem aceito pelo usuário, o que ajuda a aumentar a produtividade e a proba-
bilidade de recomendação a outros possíveis usuários (PFLEEGER, 2004). Portanto, a usabi-
lidade interfere na utilidade e na aceitação do produto e na fidelidade do cliente.
Assim, a usabilidade também influi no processo de diferenciação do produto em re-
lação aos concorrentes, ou seja, se dois produtos têm a mesma utilidade, o que tiver maior
usabilidade será considerado superior. O usuário vai preferir o produto que apresentar van-
tagens em relação à usabilidade, mesmo que as diferenças sejam pequenas. Ele irá testar o
produto cada vez que o utiliza, comparando-o com o da concorrência, e, dependendo do
resultado, continuará usando-o ou o abandonará. Daí a importância de se testar adequa-
damente o produto antes de lançá-lo no mercado, visto que isso pode garantir que a expe-
riência do usuário seja positiva, evitando-se, dessa forma, revisões no processo de produção
(PRESSMAN; MAXIM, 2016).
As indicações de usabilidade do sistema devem ser obedecidas desde o projeto inicial
para que ela possa ser atingida. Quando isso ocorre, há uma chance maior de o software ser
bem elaborado, tornar-se mais eficiente, com baixa taxa de erros, e de fácil memorização.
Essas características exigirão um esforço menor do usuário, que realizará tarefas repetitivas
em menos tempo e não se perderá na navegação do sistema. Nesse sentido, as recomen-
dações funcionam como um guia importante para os programadores ao desenvolverem,
testarem e finalizarem um software, apontando os problemas e os erros enquanto ainda há
tempo de serem solucionados.

116 Qualidade e Usabilidade de Software

 Usabilidade de software 7
Para abordar as recomendações de melhoria da usabilidade de um projeto de interfaces
computacionais, muitos são os termos e conceitos empregados. O Quadro 2, a seguir, apre-
senta e explica alguns desses termos:

Quadro 2 – Termos empregados para usabilidade de software.

Às vezes também
Conceito Como utilizar
chamado de
Estabeler critérios de usabilidade
para avaliar a aceitabilidade de um
Metas usabilidade
sistema (p. ex: “Quanto tempo leva
para a realização de uma tarefa?”)
Identificar os aspectos importantes
Metas decorrentes da ex- da experiência do usuário (p. ex:
Fatores de satisfação
periência do usuário “Como se pode tornar o produto in-
terativo divertido e agradável?”)
Como lembretes do que fornecer e
Heurística, quando
do que evitar durante o design da
Princípio de design utilizado na prática.
interface (p. ex: “que tipo de feedback
Conceitos de design.
você vai fornecer na interface?”)
Avaliar aceitabilidade das interfaces,
Heurística, quando utilizadas durante a avaliação heu-
Princípio de usabilidade
utilizado na prática. rística (p. ex: “O sistema oferece saí-
das claramente indicadas?”)
Determinar se uma interface adere
a uma regra específica, quando está
Regras sendo projetada e avaliada (p. ex:
“Sempre oferecer um botão backward
e forward em um navegador?”)
Fonte: PREECE; ROGERS; SHARP, 2005. p. 60.

A facilidade de utilização do software envolve um processo iterativo, e isso significa

que os testes devem ser ininterruptos, pois, se houver a aplicação de apenas um teste duran-
te o seu desenvolvimento, torna-se difícil corrigir todos os problemas. O desenvolvedor de
software deve refletir sobre o fato de que o usuário, quando tem uma experiência negativa
no uso de uma interface deficiente, sente-se frustrado por não conseguir realizar tarefas
que hipoteticamente outros usuários conseguiriam. Em interfaces de uso frequente e pro-
fissional, os aborrecimentos podem levar à ansiedade e ao estresse, devido à sequência de
experiências negativas e da pressão pela obrigação do uso.
Assim, é recomendável executar pequenos testes e rever a concepção de cada software
em específico, de modo que os defeitos identificados possam ser reparados. Nesse contexto,
o projeto iterativo é a melhor maneira de aumentar a qualidade da experiência do usuário.
Quanto mais versões e ideias forem testadas com as interfaces, melhor será a usabilidade.
A usabilidade é uma condição necessária também para a sobrevivência de sites, incluin-
do o e-commerce, porque se o site falhar, isso pode indicar que a empresa oferece informa-
ções difíceis de ler ou que não atendam às questões-chave do usuário. Embora na teoria

Qualidade e Usabilidade de Software 117

 7 Usabilidade de software

muitas empresas reconheçam a importância da usabilidade para o desenvolvimento de seus

sistemas, na prática elas parecem não saber como agir para atingi-la.
Contudo, a área de usabilidade de software tem apresentado um crescimento consi-
derável devido a sua importância. No caso de intranets, a usabilidade é um elemento de
produtividade dos funcionários; o tempo que eles gastam à procura de informações, sem
encontrá-las, é custoso para a empresa. A facilidade de leitura das informações ajuda na
presteza e na redução de custo no desenvolvimento de atividades. Portanto, as recomen-
dações de usabilidade vão além da fácil utilização de um software, trazendo benefícios aos
projetos internos das empresas. Nesse caso, a ênfase na usabilidade pode representar uma
redução significativa do orçamento em treinamento e a duplicação de desempenho de fun-
cionários horistas, o que significaria uma duplicação de vendas e o aumento do número de
usuários registrados.

Ampliando seus conhecimentos

A maioria das características e restrições de interface de software imple-

mentadas pelos desenvolvedores destinam-se a simplificar o modo de
interação. No entanto, é preciso que o projetista esteja atento ao fato de
que essa facilidade de interação não necessariamente significa uma ade-
quada usabilidade para o destinatário do produto, o usuário final. Ao tra-
tar desse assunto, o texto apresentado a seguir dá dicas para que o desen-
volvedor proporcione a melhor experiência possível ao usuário.

Deixar o usuário no comando

(PRESSMAN; MAXIM, 2016, p. 318-319)

[...]

Como projetista, talvez sejamos tentados a introduzir restrições e limites

para simplificar a implementação de interface. O resultado pode ser uma
interface fácil de ser construída, mas frustrante sob o ponto de vista do
usuário. Mandel define uma série de princípios de projeto que permitem
ao usuário manter o controle:

Defina modos de interação para não forçar o usuário a realizar ações

desnecessárias ou indesejadas. Modo de interação é o estado atual da
interface. Por exemplo, se for escolhido o comando de correção ortográfica

118 Qualidade e Usabilidade de Software

 Usabilidade de software 7
no menu de um processador de texto, o software entra no modo de corre-
ção ortográfica. Não há nenhuma razão para forçar o usuário a permane-
cer no modo de revisão ortográfica se ele quer apenas fazer uma pequena
edição de texto no meio do caminho. O usuário deve ser capaz de entrar e
sair desse modo com pouco ou nenhum esforço.

Proporcione interação flexível. Pelo fato de diferentes usuários terem

preferências de interação diversas, deve-se fornecer opções. Por exemplo,
um software poderia permitir a um usuário interagir por meio de coman-
dos de teclado, movimentação do mouse, caneta digitalizadora, tela mul-
titoque ou por comandos de reconhecimento de voz. Mas nem toda ação
é suscetível a todo mecanismo de interação. Considere, por exemplo, a
dificuldade de usar comandos via teclado (ou entrada de voz) para dese-
nhar uma forma complexa.

Possibilite que a interação de usuário possa ser interrompida e desfeita.

Mesmo quando envolvido em uma sequência de ações, o usuário deve
ser capaz de interromper a sequência para fazer alguma outra coisa (sem
perder o trabalho que já havia feito). O usuário também deve ser capaz de
“desfazer” qualquer ação.

Simplifique a interação à medida que os níveis de competência avan-

çam e permita que a interação possa ser personalizada. Geralmente os
usuários constatam que realizam a mesma sequência de interações repe-
tidamente. Vale a pena criar um mecanismo de “macros” que permita a
um usuário avançado personalizar a interface para facilitar sua interação.

Oculte os detalhes técnicos de funcionamento interno do usuário

casual. A interface do usuário deve levá-lo ao mundo virtual da aplicação.
O usuário não deve se preocupar com o sistema operacional, as funções
de arquivos ou alguma outra tecnologia computacional enigmática.

Projete para interação direta com objetos que aparecem na tela. O usuá-
rio tem a sensação de controle quando lhe é permitido manipulara os
objetos necessários para realizar uma tarefa de maneira similar ao que
ocorreria caso o objeto fosse algo físico. Por exemplo, a interface de uma
aplicação que permita a um usuário arrastar um documento para o “lixo”
é uma implementação de manipulação direta.

Qualidade e Usabilidade de Software 119

 7 Usabilidade de software

Atividades
1. Defina o termo usabilidade.

2. Com base no conceito dado pela ISO, quais são os princípios básicos da usabilidade?

3. Quando a usabilidade de um sistema é atingida?

4. De que modo a usabilidade pode contribuir na redução de custos de um produto de

software, na aceitação do produto e na fidelidade do cliente?

Referências
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 9241-11: Requisitos Ergonômicos para
Trabalho de Escritórios com Computadores. Rio de Janeiro, 2002.
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 9126-1: Engenharia de Software:
qualidade de produto. Rio de Janeiro, 2003.
BRANDÃO, E. R. Publicidade on-line, ergonomia e usabilidade: o efeito de seis tipos de banner
no processo humano de visualização do formato do anúncio na tela do computador e de lembrança
da sua mensagem. 2006. 400 f. Dissertação (Mestrado) – Departamento de Artes & Design, Pontifícia
Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2006.
ERICSSON, K. A.; SIMON, H. A. Protocol analysis: verbal reports asdata. Cambridge, MA: MIT Press,
1993.
JORDAN, P. W. An introduction to usability. Londres: Taylor & Francis, 1998.
NIELSEN, J. Usability Engineering. San Francisco: Morgan Kauffman, 1993.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PREECE, J.; ROGERS, Y; SHARP, H. Design de Interação: além da interação homem-computador.
Trad. V. Possamai. Porto Alegre: Bookman, 2005.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São
Paulo: AMGH Bookman, 2016.
PUC-RIO. Técnicas para avaliação de usabilidade. Disponível em: <[Link]
-[Link]/21839/21839_4.PDF>. Acesso em: 8 ago. 2017.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2006.

Resolução
1. O termo usabilidade refere-se à facilidade com que as pessoas podem utilizar uma
ferramenta. A usabilidade é considerada um atributo de qualidade que avalia a faci-
lidade com que uma interface gráfica de software é utilizada. Ela também se refere à
aplicação de métodos, durante um processo de design, para melhorar essa utilização
(NIELSEN, 1993).

120 Qualidade e Usabilidade de Software

 Usabilidade de software 7
2. Facilidade de aprendizado, facilidade de uso, flexibilidade em relação às possibilida-
des que o usuário e o sistema têm de trocar informações e robustez.

3. A usabilidade de um sistema é atingida quando recomendações de usabilidade

são obedecidas desde o projeto inicial do software. Quando isso ocorre, o sistema
apresenta atributos relacionados à usabilidade, como a facilidade de aprendi-
zado, a eficiência de uso, a facilidade de memorização, a baixa taxa de erros e a
satisfação subjetiva.

4. A facilidade de leitura das informações proporcionada pela usabilidade ajuda na

presteza e na redução de custo no desenvolvimento de atividades. Portanto, as re-
comendações de usabilidade vão além da fácil utilização de um software, trazendo
benefícios aos projetos internos das empresas. Nesse caso, a ênfase na usabilidade
pode representar uma redução significativa do orçamento em treinamento e a dupli-
cação de desempenho de funcionários horistas, o que significaria uma duplicação de
vendas e o aumento do número de usuários registrados. Os custos com manutenção
e revisão também são reduzidos e o produto é mais bem aceito pelos usuários, por
todas as qualidades de usabilidade que apresenta, aumentando a probabilidade de
recomendação a possíveis usuários.

Qualidade e Usabilidade de Software 121

 8
Acessibilidade e
inclusão digital

Introdução

O avanço da globalização deve assumir um elemento de integração das pessoas.

Não há como pensarmos em uma sociedade da informação onde as tecnologias não
proporcionem acessibilidade aos usuários.

Nesse contexto, a acessibilidade pode ser compreendida de diferentes maneiras.

Em relação à acessibilidade na web, ela diz respeito a uma prática inclusiva no desen-
volvimento de websites que possam ser utilizados por todas as pessoas, independen-
temente de elas terem ou não alguma necessidade especial. Quando os sites são cor-
retamente concebidos, desenvolvidos e editados, todos os usuários podem ter igual
acesso à informação e à funcionalidade.

Todas as inspeções, normas, métricas e métodos de software são voltados para a

produção em conformidade com padrões de qualidade. Desse modo, a busca pela qua-
lidade percebida tem como objetivo principal produzir produtos cada vez melhores e
com menos erros, para que o usuário final fique satisfeito.

Qualidade e Usabilidade de Software 123

 8 Acessibilidade e inclusão digital

Nessa ótica, o produto software, além de usual, deve ser acessível às pessoas, indepen-
dentemente de idade, necessidades especiais e nível de escolaridade. Isso porque o software
é, na verdade, um artefato produzido por pessoas para pessoas e, portanto, precisa ser aces-
sível a todos, a fim de que atinja a função a que se propõe.
Tendo isso em vista, o objetivo deste capítulo é apresentar uma reflexão sobre a inclusão
digital na atualidade.

8.1 A acessibilidade digital

Acessibilidade refere-se à facilidade de acesso a um lugar, uma pessoa, um conhecimento

ou um objeto/bem. Com o advento da sociedade da informação, o conceito de acessibilidade
evoluiu tendo em conta as novas realidades. Na verdade, mobilidade, proximidade e distân-
cia já não são aspectos essenciais da definição de acessibilidade, ou melhor, a acessibilidade
no espaço físico é agora complementada pela disponibilidade do espaço virtual, desafiando
os princípios de distância, proximidade ou interação espacial (NIELSEN; TAHIR, 2002).
A acessibilidade ao ambiente físico está relacionada à qualidade que os espaços dispo-
nibilizam a todos, inclusive nos casos de deficiência de mobilidade ou comunicação (IBM,
2017), incluindo a possibilidade de chegar a todos os lugares e edifícios sem esforço excessi-
vo e acessar as instalações de uso público e serviços fornecidos com segurança e autonomia.
O Decreto n. 5.296 do governo federal define a acessibilidade como “condição para
utilização, com segurança e autonomia, total ou assistida, dos espaços, mobiliários e equi-
pamentos urbanos, das edificações, dos serviços de transporte e dos dispositivos, sistemas e
meios de comunicação e informação, por pessoa portadora de deficiência ou com mobilida-
de reduzida” (BRASIL, 2004).
Em paralelo, no caso da web e da internet em geral, a acessibilidade se refere ao con-
junto de elementos que facilitam o acesso à informação a todas as pessoas, de modo iguali-
tário, usando a tecnologia (computadores, tablets, telefones móveis, entre outros) indepen-
dentemente das necessidades especiais dos usuários (físicas, mentais, sensoriais e outras)
(NIELSEN; TAHIR, 2002). Assim, a acessibilidade digital se refere a uma democratização do
acesso as redes independentes de qualquer barreira física, cognitiva ou a qualquer outro dis-
túrbio pré-existente. Faz-se referência a um projeto que permita que as pessoas percebam,
compreendam, naveguem e interajam com a web (IBM, 2017), inclusive os mais velhos, que
viram o mundo mudando e agora precisam se adequar às novas tecnologias.
Para Kidal Weber (2006), a acessibilidade é a facilidade de uso de uma forma eficiente
e bem-sucedida de um produto, serviço, ambiente ou o instrumento por pessoas com de-
ficiência. Já a infoacessibilidade refere-se a produtos e serviços eletrônicos que podem ser
utilizados por usuários com eficiência e satisfação, em um contexto de uso específico, por
exemplo: acessibilidade de equipamentos de informática (hardware e software), acessibili-
dade da web, da televisão digital, da telefonia móvel, de produtos e serviços de automação
e de outros serviços característicos da sociedade da informação (WEBER, 2006).

124 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
A inclusão digital requer três instrumentos básicos: computador, acesso à rede e o do-
mínio dessas ferramentas. Portanto, não é suficiente ter um computador conectado à inter-
net, sendo também necessário saber o que fazer com essas tecnologias (IBM, 2017).
De acordo com o Livro Verde do Ministério da Ciência e Tecnologia (TAKAHASHI, 2000),
a acessibilidade à informação e ao conhecimento é a variável de maior poder de exclusão
ou inclusão dos indivíduos no processo político e econômico, ressaltando que as políticas
públicas de universalização de acesso, como o Fundo de Universalização dos Serviços de
Telecomunicações (FUST), também devem se preocupar com a inclusão digital dos menos
favorecidos economicamente (2000, p. 220).
Entre as estratégias e ações inclusivas, há projetos que facilitam o acesso de pessoas
de baixa renda às tecnologias de informação, além do desenvolvimento de tecnologias que
estendem a acessibilidade para usuários com deficiência (NIELSEN; TAHIR, 2002). Nesse
quadro, a inclusão digital é a democratização do acesso às tecnologias de informação e co-
municação para permitir a inserção de todos na sociedade da informação.
Assim, toda a sociedade pode ter acesso a informações disponíveis na internet, e, com
isso, produzir e disseminar conhecimento. A inclusão digital está, portanto, inserida no mo-
vimento de inclusão social, sendo ela um dos principais objetivos partilhados por vários
governos ao redor do mundo nas últimas décadas (WARSCHAUER, 2006).

8.1.1 Acessibilidade para todos

A acessibilidade é também uma condição necessária para a participação social de
pessoas com diferentes limitações funcionais. Em uma sociedade em que cada vez mais a
Tecnologia da Informação e Comunicação (TIC) é usada para aprender, estudar, socializar,
divertir e trabalhar, garantir a acessibilidade das novas tecnologias de mídia, particularmen-
te a internet, é uma prioridade (VALERIANO, 2005).
Acessibilidade digital trata de aspectos relacionados com a codificação e apresentação
das informações na concepção de um site, permitindo que pessoas com algum tipo de li-
mitação possam perceber, compreender, navegar e interagir eficazmente com a rede, bem
como criar e contribuir com conteúdos (NIELSEN; TAHIR, 2002).
A acessibilidade abrange muitos tipos de deficiência, como visual, auditiva, física, cog-
nitiva, problemas neurológicos e da fala, temporárias ou permanentes. Há milhares de pes-
soas com deficiência que ainda não podem usar a web, por conta das barreiras de acessibi-
lidade existentes em sites e softwares. Assim, quanto mais softwares e sites acessíveis forem
disponibilizados, mais pessoas poderão usar a web e contribuir de forma mais efetiva na
sociedade (NIELSEN; TAHIR, 2002).
Ainda hoje, grande parte dos sites e softwares apresentam barreiras de acessibilidade,
tornando difícil ou mesmo impossível o seu uso. No entanto, se eles fossem acessíveis, pes-
soas com deficiência poderiam usar esses serviços de forma eficaz (IBM, 2017).
A acessibilidade para esses indivíduos está regulamentada em lei e presente no am-
biente organizacional. A Lei n. 8.213, de 24 de julho de 1991, determina que empresas com
mais de cem funcionários precisam reservar vagas para pessoas com necessidades especiais.

Qualidade e Usabilidade de Software 125

 8 Acessibilidade e inclusão digital

O decreto n. 3.298/99 (BRASIL, 1999) dispõe sobre a Política Nacional para a Integração
da Pessoa Portadora de Deficiência, consolidando as normas de proteção para esses indiví-
duos no convívio em sociedade. E a Lei n. 10.098/00 (BRASIL, 2000) estabelece normas gerais
e critérios básicos para a promoção da acessibilidade das pessoas com deficiências ou com
mobilidade reduzida. Já a Portaria MEC n. 679/99 (BRASIL, 1999) dispõe sobre os requisitos
de acessibilidade a pessoas com deficiência para instruir processos de autorização e de reco-
nhecimento de cursos e de credenciamento de instituições. Os princípios de acesso ao ensino
e de “igualdade de condições de acesso e permanência na escola” estão dispostos na Lei de
Diretrizes e Bases (LDB), afirmando, no art. 208, que o “dever do Estado com a educação
será efetivado mediante a garantia de acesso aos níveis mais elevados de ensino, da pesquisa
e da criação artística segundo a capacidade de cada um” (BRASIL, 1996).
Além dos usuários com deficiências, há também aqueles usuários que têm conexões
lentas de internet, ou acessam a rede via laptops e PDAs (Personal Digital Assistant) ou tele-
fones móveis com telas gráficas reduzidas, os quais também podem se aproveitar do design
acessível. Em geral, de uma forma ou de outra, todos os usuários podem se beneficiar com
a acessibilidade na web (WARSCHAUER, 2006).
As dificuldades de acesso ao conteúdo da web podem ser reduzidas consideravelmente
se os responsáveis pelas organizações de gerenciamento de websites, os desenvolvedores
e os gerentes de conteúdo levarem em conta as necessidades das pessoas, a diversidade de
formas de acesso (condicionada pelos diferentes tipos de terminais existentes, softwares,
velocidade de conexão e muitos outros fatores) e se respeitarem algumas estruturas simples
de páginas web (IBM, 2017).
De acordo com Melo (2007, p. 98):
A acessibilidade na web depende do entrosamento de diferentes componentes
relacionados ao desenvolvimento de seu conteúdo e também à interação dos
usuários com suas páginas. Enquanto desenvolvedores web contam com ferra-
mentas de autoria (ex. editores de páginas web, ferramentas de gerenciamento
de conteúdo, wikis, etc.) e ferramentas de avaliação (ex. verificadores de lingua-
gem de marcação, ferramentas semiautomáticas de avaliação de acessibilidade)
para desenvolver conteúdo web, usuários da rede mundial de computadores
podem usar navegadores, media players e tecnologias assistivas, entre ou-
tros agentes de usuário, para obter informação, produzir conteúdo e interagir.
A acessibilidade na web depende da interação entre esses diferentes componen-
tes e, quando um deles falha, a experiência do usuário com páginas e aplicações
web fica comprometida.
Na busca pela acessibilidade na web, o Consórcio World Wide Web (W3C) é uma insti-
tuição que realiza um esforço para melhorar a acessibilidade à web para pessoas com defi-
ciência. Pessoas com necessidades especiais podem encontrar dificuldades ao usar computa-
dores em geral e acessar conteúdos na grande rede. O Consórcio disponibiliza informações,
diretrizes, relatórios técnicos, materiais educacionais e outros documentos que se relacionam

126 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
aos diversos componentes de acessibilidade da web. Esses componentes incluem conteúdo
da web, navegadores e players de mídia, ferramentas de autoria e ferramentas de avaliação1.
O Web Accessibility Initiative é a elaboração de diretrizes e técnicas desenvolvidas pelo
W3C que fornece soluções acessíveis para software, como no documento Componentes essen-
ciais de acessibilidade na web, que descreve os diferentes papéis da acessibilidade (IBM, 2017).
Essas diretrizes são consideradas as normas internacionais para a acessibilidade (NIELSEN;
TAHIR, 2002)2.
As diretrizes e técnicas desenvolvidas pelo W3C apontam para a necessidade de se
fazer um website levando em conta fatores como o tipo de conteúdo, o tamanho e a comple-
xidade do site, bem como as ferramentas de desenvolvimento e meio ambiente. Muitos dos
recursos acessíveis de um site podem ser facilmente implementados se forem planejados
desde o início de seu desenvolvimento ou de sua reformulação. Modificar sites com recursos
de baixa acessibilidade pode exigir um esforço significativo, especialmente aqueles que não
são “rotulados” adequadamente com marcação XHTML padrão e locais com determinados
tipos de conteúdo, tais como multimídia (NIELSEN; TAHIR, 2002).
Ao desenvolver ou redesenhar um site, deve-se avaliar a acessibilidade de modo a en-
contrar possíveis problemas desde o início, quando é mais fácil de resolvê-los. Técnicas sim-
ples, como mudar as configurações em um navegador, podem determinar se uma página
da web atende às diretrizes de acessibilidade. Uma avaliação abrangente para determinar o
cumprimento das orientações é bastante complexa (WARSCHAUER, 2006). Existem ferra-
mentas de avaliação que ajudam nesse processo; no entanto, para determinar se um website
é realmente acessível, é necessária uma avaliação humana (NIELSEN; TAHIR, 2002).
A acessibilidade melhora a capacidade de gerenciamento dos sites, garantindo que as
páginas sejam mais facilmente navegáveis e que possam ser acessados por uma variedade
de dispositivos, e não apenas do desktop tradicional (WARSCHAUER, 2006).
Além disso, há também uma questão econômica: a acessibilidade pode ser uma ferra-
menta poderosa para a fidelidade do cliente. Do mesmo modo, empresas e desenvolvedores
podem perder clientes potenciais, se estes tiverem dificuldades para navegar e interagir nos
sites e acessar determinados serviços (IBM, 2017).
De acordo com o Portal Brasil (2017, p. 1),
Quando falamos em Web acessível, é preciso ter em mente que o mais impor-
tante para a acessibilidade é o código HTML – HyperText Markup Language.
O leitor de tela e outros recursos de Tecnologia Assistiva interpretam o códi-
go HTML, seus elementos e semântica. Por isso, o primeiro passo para garan-
tir acessibilidade ao conteúdo Web é utilizar código semanticamente correto,
ou seja, cada elemento para o seu propósito, seguindo-se os Padrões Web ou

1 Mais informações sobre o Consórcio W3C podem ser encontradas no endereço: <[Link]
br/Home/WebHome>.
2 Mais informações sobre essas diretrizes estão disponíveis no endereço: <[Link]
guid-tech>.

Qualidade e Usabilidade de Software 127

 8 Acessibilidade e inclusão digital

Web Standards do W3C - World Wide Web. Os Padrões de Desenvolvimento

Web ou Web Standards são um conjunto de normas, diretrizes, recomenda-
ções, notas, artigos, tutoriais e afins de caráter técnico, produzidos pelo con-
sórcio W3C, com a finalidade de atingir uma padronização e a criação de uma
“Web universal”.
Alguns conceitos devem ser considerados no desenvolvimento de sites acessíveis
(PORTAL BRASIL, 2017, p. 1):
• Conceito de Camadas: Representa o uso adequado das tecnologias, ou seja,
cada tecnologia deve ser utilizada com o propósito único ao qual foi criada.
Por exemplo, o HTML é utilizado apenas para a criação de conteúdo, enquan-
to a apresentação visual é criada através do CSS. Já o comportamento é defini-
do pelas linguagens de script.
• Conceito Tableless: As tabelas devem ser usadas apenas para dados tabulares
e não para fins de layout. Esse conceito surgiu devido ao uso excessivo de
tabelas para apresentação visual do site. O uso de tabelas para a estruturação
da página prejudica a apresentação da página em determinadas resoluções de
tela, deixa a página mais pesada, tem como consequência um código de difícil
manutenção, além de causar problemas de acessibilidade.
• Conceito de Semântica: Representa o uso correto das tags HTML, pois cada
tag possui um objetivo específico e para tal deve ser utilizado. Após a cria-
ção do site seguindo-se esses conceitos, o desenvolvedor deve validar todas as
páginas do site no validador do W3C. Essa validação encontrará os erros de
concordância entre o código criado e as recomendações e fornecerá ao desen-
volvedor a forma de corrigi-lo.
Outro aspecto e, possivelmente, o mais importante, é a consciência social: a web deve
ser entendida como algo universal, e essa universalidade deve levar em conta o acesso, por
qualquer pessoa, às informações fornecidas on-line. As empresas devem se atentar a esse
contexto de inclusão social, porque o fato de ter um site acessível a todas as pessoas – inde-
pendentemente de conhecimento pessoal ou deficiências dos usuários e das características
técnicas dos equipamentos utilizados – é uma vantagem social sobre a concorrência e um
diferenciador (NIELSEN; TAHIR, 2002).

8.2 A inclusão digital

Segundo Pedro Demo (2007), a inclusão digital deve ser entendida como uma política
social do conhecimento e relevante alavanca contra a desigualdade social. As novas tecnolo-
gias influenciam de forma marcante as transformações na sociedade.

128 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
No caso do Brasil, que possui uma grande extensão territorial e uma intensa desi-
gualdade social, as dificuldades para a inclusão digital são mais severas, como afirma
Demo (2005), do que em países mais desenvolvidos, onde adultos/idosos são inseridos
na sociedade digital com mais autonomia, utilizando a tecnologia a seu favor, e não
apenas como consumidores.
Esse cenário, no entanto, vem mudando3; desde meados dos anos 2000, observa-se uma
popularização dos aparelhos eletrônicos, influenciados pelo barateamento dos preços.
A democratização do acesso aos computadores, à internet e a outras ferramentas digi-
tais gerou um movimento de acesso a diferentes conhecimentos, composto por uma comu-
nicação interativa. Hoje o computador está presente nos mais variados contextos (empresa-
rial, acadêmico, domiciliar). A informática veio para inovar e facilitar a vida das pessoas, e
não é mais possível ignorar essa realidade tecnológica.
Para Edgar Morin (1998), é visível a relevância da inclusão das novas tecnologias como
meio de se adquirir saber. A inclusão digital serve de suporte cultural, científico e tecnoló-
gico, apoiando a educação, ampliando a participação social, promovendo a interatividade e
auxiliando no percurso do longo caminho da formação de cidadãos críticos, conscientes de
seus direitos e deveres.
Segundo Pierre Lévy (2000), novas maneiras de pensar e de conviver estão sendo ela-
boradas no mundo das telecomunicações e da informática. Os sistemas de informação e as
redes de computadores avançam velozmente e a informatização captura a escrita, a leitura,
a visão, a audição, a criação e a aprendizagem. O autor também aborda a velocidade dos
recursos tecnológicos e alerta sobre o erro de levarmos tempo demais discutindo suas pos-
sibilidades de uso, porque “enquanto discutimos possíveis usos de uma dada tecnologia,
algumas formas de usar já se impuseram”, tal a velocidade e renovação com que se apresen-
tam (LÉVY, 2000, p. 26).
A adaptação às novas ferramentas tecnológicas é complexa: para alguns indivíduos ela
acontece rapidamente; outros, no entanto, devido à heterogeneidade cultural, social, econô-
mica e cognitiva, têm mais dificuldades para se adequarem a esses processos. Para Demo
(2007), o computador pode ser uma ferramenta de inclusão ou exclusão social, visto que a
sociedade contemporânea exige a inclusão digital para todos, porém algumas pessoas ainda
não têm acesso a essas tecnologias.
Exclusão digital é o termo usado para se referir à consequência direta do abismo tecnoló-
gico que existe entre as comunidades que têm acesso à tecnologia da informação e aquelas
que são excluídas desse processo. As diferenças entre elas podem ser socioeconômicas ou

3 Em diversos estados brasileiros, lançam-se movimentos em prol da inclusão digital. Dentre estes,
destacam-se: o Programa GESAC – Governo Eletrônico-Serviço de Atendimento ao Cidadão (2003),
resultado da parceria entre órgãos do Governo Federal (Ministério das Comunicações, do Planejamen-
to, da Educação, da Defesa e Instituto de Tecnologia da Informação); o Programa Telecentros (2007);
o Programa Acessa São Paulo, o qual foi premiado internacionalmente; o Programa Sinergia Digital,
criado e mantido pela PUCRS; e o NAVEGAPARÁ – Programa de Democratização do Acesso às Tec-
nologias de Informação e Comunicação (2007).

Qualidade e Usabilidade de Software 129

 8 Acessibilidade e inclusão digital

em relação à capacidade de usar a tecnologia da informação de forma eficaz, devido aos

níveis distintos de alfabetização e disponibilidade de recursos.

8.2.1 Inclusão digital na sociedade

Existe uma relação dialética entre a adesão e a crítica aos novos instrumentos tecnoló-
gicos, com muitos argumentos a favor e outros que se opõem à inserção das Tecnologias de
Informação e Comunicação (TICs) na comunidade.
Os conteúdos disponibilizados por meio das TICs favorecem a compreensão de proces-
sos culturais e sociais, sendo que a tecnologia facilita a conexão e comparação com diversas
realidades, criando novas oportunidades.
A universalização do uso da tecnologia digital, assim, permite uma inclusão dos in-
divíduos na realidade atual, visto que as principais atividades econômicas e boa parte da
produção cultural e das ações governamentais estão migrando para a web (SILVEIRA, 2008).
Assim, hoje em dia, quanto mais demorado for o processo global de inclusão digital, maior
será a desigualdade socioeconômica entre diferentes grupos.
Ao tratar de políticas específicas para inclusão nessa sociedade em rede, Bonilla e Pretto
(2011) alegam que o mais adequado seria colocar em prática iniciativas que proporcionem “a
inclusão de cidadãos, não como meros consumidores, seja de produtos ou de informações,
mas como sujeitos plenos que participam do mundo contemporâneo enquanto seres éticos,
autônomos e com poder de decisão”. A disponibilização, pelo governo, de cursos básicos de
informática para a população de baixa renda seria uma medida básica para garantir o acesso
digital a um número cada vez maior de pessoas, assim como programas para aquisição de
equipamentos a preços mais baixos/subsidiados.
Nesse cenário tecnológico, as redes sociais e diversos aplicativos (apps) já são hoje ferra-
mentas amplamente difundidas e utilizadas nos processos de interação entre os indivíduos,
seja nos relacionamentos pessoais, seja nos mais diversos contextos profissionais. Isso per-
mite que os sujeitos não só adquiram conhecimentos, mas também os produzam e disse-
minem, de modo descentralizado. Esse processo em direção à chamada emancipação digital
(SCHWARTZ, 2010), no entanto, envolve um longo caminho de apropriações socioculturais
e educativas.
Desse modo, a criação de ambientes de rede multidirecionais, em que usuários estão
constantemente em comunicação, conectados e interconectados, amplia, dia após dia, os
limites antes impostos pelas barreiras físicas. “Estamos, portanto, frente a fluxos multidi-
recionais e imprevisíveis de informação, cultura e conhecimento, constantemente ressigni-
ficados, de onde emerge um processo dinâmico [...] marcado pela tensão entre tradição e
modernidade, necessidade e liberdade” (BONILLA; PRETTO, 2011, p. 104).

8.2.2 Inclusão digital e educação

No contexto educacional brasileiro, muitos professores ainda utilizam métodos tradi-
cionais de ensino por não saberem lidar com as novas tecnologias. No entanto, em grande

130 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
parte das escolas do país gradativamente é inserida a mediação tecnológica na aprendiza-
gem de alunos e na capacitação dos docentes para a utilização desses novos recursos. De
acordo com Meneguelli (2010), com a democratização do uso da internet e o desenvolvi-
mento de instrumentos tecnológicos e digitais, não há mais como a escola utilizar somente
quadro e giz.
A soma dos métodos tradicionais aos novos promove a adequação necessária para um
bom desenvolvimento da prática pedagógica, tendo como suporte as ferramentas inovado-
ras que apoiam a pesquisa, o conteúdo pedagógico, a dinâmica do professor e os demais
componentes do ambiente educacional. Para ocorrer essa integração, é necessário que o edu-
cador seja maleável, tendo em vista que a aprendizagem é reconstrutiva, fazendo com que o
indivíduo participe dessa realidade. A capacidade de conviver e interferir na realidade está
presente no conhecimento, é preciso saber inovar e acompanhar as crescentes e constantes
inovações científicas e tecnológicas que surgem na sociedade contemporânea.
Portanto, aluno e professor são capazes de se adequar a esse universo de modernida-
des que invadem as salas de aula, os laboratórios, as residências, não há como isolar-se ou
ignorar a onda tecnológica que se renova constantemente. Docentes e discentes deverão
aproveitar a velocidade, a interatividade e todos os benefícios fornecidos pelas redes, pelas
conexões e mídias digitais, para evoluírem no saber e na cidadania.
Assim como o domínio do professor e a apropriação dos alunos das novas técnicas pe-
dagógicas, é indispensável também que a escola possua uma boa estrutura física e material,
possibilitando o uso desses equipamentos durante as aulas. São visíveis hoje as melhorias
na educação nos diferentes níveis de ensino, com um melhor rendimento escolar, a elevação
na qualidade da aprendizagem, uma maior sincronia na relação professor-aluno e metodo-
logias que apresentam flexibilidade para inserção de constantes atualizações e novas ideias.
No entanto, essa inclusão de métodos novos, de geração de novos saberes, precisa ser pla-
nejada, bem estruturada, reconstruída constantemente, para que possa render bons frutos.
Entrelaçar os fios entre a comunicação, o mundo virtual, a escola e a sociedade exige
uma transformação do pensamento individual e coletivo, assim como leva professores e
alunos a romper com alguns padrões tradicionais. Portanto, são necessárias mudanças inte-
riores e exteriores na educação, para que sejam aplicadas as inovações propostas que com-
põem a inclusão digital, fazendo que o aluno aproveite a multiplicidade de oportunidades
oferecidas pelas novas tecnologias.

8.3 Projetos de inclusão digital

Com a elaboração de projetos e programas governamentais de incentivo à inclusão di-

gital, foram criados o Programa Nacional de Tecnologia Educacional (ProInfo Integrado)
e, em seguida, o Projeto Um Computador por Aluno (ProUCA), amparado pela Lei n.
12.249/2010. Essa lei também trata do Regime Especial de Aquisição de Computadores para
Uso Educacional (RECOMPE), que facilita a compra de computadores para uso educacional.

Qualidade e Usabilidade de Software 131

 8 Acessibilidade e inclusão digital

Algumas instituições públicas de ensino conseguiram implementar em seu currículo

esses programas e muitos alunos foram beneficiados, aprenderam com e sobre a tecnologia,
criaram blogs educativos, grupos para pesquisa de temas significativos e contextualizados
com o século XXI e ampliaram seus conhecimentos de informática, Português, Matemática,
entre outras disciplinas. Assim, gradativamente, as escolas públicas brasileiras, em todos os
seus segmentos de ensino, são levadas a incluírem o uso das TICs em suas práticas pedagó-
gicas como ferramenta facilitadora de ensino-aprendizagem e inclusão social.
Da década de 1970 até a atualidade, além das redes do governo, também se observou a
inserção gradativa e a utilização da telemática (transmissão de informação a longa distân-
cia) nas instituições de ensino privadas e em outras áreas profissionais, inclusive no que diz
respeito a pessoas com deficiência.
Nesse contexto de inclusão e acesso às tecnologias, muitos softwares livres foram cria-
dos ou desenvolvidos para facilitar o uso e a experiência por parte das pessoas com deficiên-
cia. A seguir, são apresentados alguns desses projetos.

8.3.1 Deficiência visual

Hoje já são vários os projetos de softwares que visam à acessibilidade por parte dos
usuários que apresentam algum tipo de deficiência visual. Alguns desses sistemas podem
ser destacados:
• O projeto Orca é um leitor de tela para o software livre flexível e extensível, de-
senvolvido pelo projeto Gnome para pessoas cegas ou com deficiência visual. Pelo
uso combinado de voz e/ou braile, o Orca fornece acesso a aplicativos e ferra-
mentas que suportam provedores de interface de tecnologia assistiva AT-SPI (por
exemplo, Gnome aplicações, OpenOffice, Mozilla Firefox/Thunderbird, entre
outros). O desenvolvimento do Orca foi iniciado pelo Escritório do Programa de
Acessibilidade da Sun Microsystems Inc. (atual Oracle). O conceito original e o
primeiro protótipo foi realizado em 2004 por Mark Mulcahy, um programador
cego que trabalhou na Sun Microsystems.
Disponível em: <[Link]
• O projeto Lazarus é uma distribuição Linux para pessoas com deficiência visual,
que incorpora várias ferramentas e aplicativos para facilitar seu acesso. Pode ser
baixado por meio da imagem do “Live CD”, e, por isso, não é necessário instalá-lo
no disco rígido do computador para usá-lo.
Disponível em: <[Link]
• O projeto Linaccess-Knoppix é uma distribuição Linux particularmente útil para
pessoas com deficiência visual, desenvolvida no âmbito do projeto Linacess.
Disponível em: <[Link]
• O navegador de internet Mozilla Firefox é um popular programa de software livre
processado em Windows, Linux e outras plataformas, incluindo recursos de aces-
sibilidade importantes que facilitam o uso por pessoas com deficiências visuais.

132 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
Disponível em: <[Link]
• Brltty é um processador de computador interativo que roda em segundo plano e
permite ao usuário se conectar e usar um teclado em braile para a porta serial e no
console de texto, para os sistemas operacionais Linux e Unix.
Disponível em: <[Link]
• Festival é um sintetizador de voz que reproduz textos em inglês e espanhol, dis-
poníveis em diferentes distribuições. Ele inclui documentação completa e ferra-
mentas para construir novas vozes, disponíveis por meio do Projeto Festvox de
Carnegie Mellon.
Disponível em: <[Link]
Disponível em: <[Link]
• Gnome-Speech é uma biblioteca geral API simples que faz a programação de
software com base em bibliotecas Gnome, com funções para produzir voz por meio
de texto. Ele suporta várias interfaces, mas atualmente só está ativa nesse pacote a
interface Festival, exigindo Java ou outro software proprietário para sua utilização.
Disponível em: <[Link]
[Link]>.
• O Gnopernicus permite aos usuários com visão limitada, ou nenhuma visão, usar
o desktop Gnome e suas aplicações. Fornece um pacote de utilidade que consiste
de um ampliador de tela, tela de leitura de voz utilizando o sintetizador Festival e
o uso de um teclado em braile para exibir o texto de saída.
Disponível em: <[Link]
• Kmagnifier é um ampliador de tela para Linux, que funciona como uma lupa que
amplia uma parte da tela. Ele é usado por pessoas com deficiência visual, além de
indivíduos que trabalham no campo da análise de imagem, de desenvolvimento
web etc.
Disponível em: <[Link]
• XZOOM é uma lupa de aumento disponível para qualquer distribuição com ser-
vidor gráfico, que atualiza continuamente a área ampliada. É rápido o suficiente
para exibir pequenas animações.
Disponível em: <[Link]
• O SVGATextMode redimensiona linhas de texto em cartões console SVGA para
Linux em modo texto. Modifica o tamanho da fonte, o cursor, a sincronização ho-
rizontal e vertical etc.
Disponível em: <[Link]

8.3.2 Deficiência motora

Os softwares destacados a seguir são destinados para aqueles usuários que apresentam
deficiência motora.

Qualidade e Usabilidade de Software 133

 8 Acessibilidade e inclusão digital

• Dasher é um software que permite a realização de uma gravação escrita por meio
de uma previsão baseada no movimento do ponteiro do mouse, que possibilita a
substituição da escrita do teclado pelo movimento do mouse, usando a inteligên-
cia artificial.
Disponível em: <[Link]
• GOK é um teclado alfanumérico virtual que permite aos usuários controlar com-
putadores sem um teclado ou mouse padrão. Os usuários especificam teclados e
métodos de acesso em XML, o que lhes permite modificar métodos existentes e
criar novos, definindo a largura, a altura e o espaçamento das teclas, bem como
o ­feedback visual e auditivo sobre realce e seleção. O GOK também cria dinamica-
mente teclados para se adaptarem a uma situação específica, religando os com-
ponentes de interface do usuário de aplicativos em execução diretamente dentro
do sistema. O usuário então tem acesso eficiente aos elementos da interface de
usuário e não precisa navegar indiretamente através da interface de aceleradores
de teclado. O GOK também suporta a redefinição de menus de aplicativos e barras
de ferramentas e inclui um teclado ativador de janela que lista as janelas atuais e
permite que os usuários alternem entre elas.
Disponível em: <[Link]
• O Xvoice possibilita que o usuário utilize a sua própria voz para controlar o uso de
aplicativos. Ele reconhece a voz do usuário e permite tanto executar ordens como
controlar os comandos por meio de algumas aplicações do servidor gráfico.
Disponível em: <[Link]
• OpenMindSpeech é um aplicativo de reconhecimento de voz que pretende ser
compatível com KDE, Gnome e todas as aplicações existentes para Linux.
Disponível em: <[Link]
• O Clic é um software educativo que conta com diversas atividades como caça-
-palavras, palavras-cruzadas, exercícios de texto etc. Esse software possibilita que
atividades sejam propostas também para o público que possui necessidades espe-
ciais. Está disponível nas versões em espanhol e inglês.
Disponível em: <[Link]
• A Hawking Toolbar é um plug-in de código aberto gratuito para o navegador
Firefox. Ele adiciona uma barra de ferramentas que torna as páginas da web aces-
síveis a usuários com limitações motoras, por meio do uso de um ou mais switches
de comando (comutadores).
Disponível em: <[Link]
Como se pode observar, atualmente já existem várias ferramentas disponíveis para me-
lhorar a acessibilidade de diversos públicos. A liberdade oferecida pelos programas desen-
volvidos e distribuídos como software é importante tanto nos casos das deficiências tempo-
rárias quanto das permanentes.

134 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
Mesmo assim, apesar dos avanços na área da acessibilidade, um dos grupos menos le-
vados em consideração pelos programadores ainda é o das pessoas com deficiência.
Atualmente, um dos importantes recursos incorporados em aplicações de software é a
personalização, permitindo que os usuários as adaptem ao seu uso, de acordo com as suas
próprias necessidades. E sistemas personalizáveis são particularmente importantes no caso
da acessibilidade aos usuários que apresentam algum tipo de deficiência.
Somente com essa visão e conhecimento é possível que, no futuro, mais e mais desen-
volvedores deem a atenção merecida à questão da acessibilidade.

Ampliando seus conhecimentos

É notório o movimento cada vez mais intenso para que a população mun-
dial tenha acesso aos conteúdos e ferramentas necessários à inclusão digi-
tal. O texto apresentado a seguir problematiza justamente o significado do
que vem a ser a inclusão digital na atualidade.

Inclusão digital: ambiguidades em curso

(BONILA; PRETTO, 2011, p. 23-25)

A compreensão e problematização do termo inclusão digital tem impor-

tância crucial no contexto contemporâneo, uma vez que tem se constituído
em pauta das políticas públicas e objeto das ações de diferentes institui-
ções – ONGs, universidades, empresas, escolas. Tanto pelos diferentes
significados atribuídos ao termo pelos diferentes atores sociais envolvi-
dos, quanto pelas resultantes socioculturais e políticas que emergem das
ações e interações relacionadas. A percepção dos sentidos construídos em
torno da inclusão digital torna-se fundamental.

Numa análise em nível global, constata-se que o termo inclusão digital

entra em cena na dinâmica social e política da implantação dos chama-
dos Programas Sociedade da Informação, nos diversos países, em especial
naqueles que compõem a União Europeia (UE). Diversos estudos sociais,
políticos, culturais e econômicos sobre as transformações que têm ocor-
rido na sociedade contemporânea, em geral, têm enfatizado a difusão
crescente das tecnologias da informação e comunicação, em escala mun-
dial. Em muitos destes, são enfatizados e criticados os contextos políticos
nos quais nascem as proposições destinadas a construir, em escala mun-
dial, uma “Sociedade da Informação”.

Qualidade e Usabilidade de Software 135

 8 Acessibilidade e inclusão digital

O espaço político-ideológico das políticas de governo nacionais e inter-

nacionais para o desenvolvimento do que se convencionou denominar,
portanto, “Sociedade da Informação” consolida-se na década de 90 do
século passado. Na esteira desse movimento surgem os denominados
“Programas para a Sociedade da Informação”, notadamente aqueles
empreendidos pelos EUA, EU e Organismos Internacionais, entre os quais
a União das Nações Unidas (ONU) e a União dos Estados Americanos
(OEA).

O Brasil incorpora a nova pauta em sua agenda política no ano de

2000, quando lança o Livro Verde – Sociedade da Informação no Brasil
(TAKAHASHI, 2000). É justamente no âmbito dessas iniciativas que se
identificam as desigualdades quanto ao acesso de grandes contingen-
tes populacionais às Tecnologias da Informação e Comunicação (TIC).
Tais desigualdades vêm sendo denominadas genericamente como digi-
tal divide, gap digital, infoexclusão, ou exclusão digital, e têm justifi-
cado a formulação de numerosas políticas públicas com a finalidade de
minimizá-las.

[...]

O tema inclusão digital tem, assim, suscitado diversas discussões. Os

significados e objetivos atribuídos ao termo têm motivado intensos
debates na comunidade acadêmica. Treinar pessoas para o uso dos
recursos tecnológicos de comunicação digital seria inclusão digital?
Para alguns autores, tais iniciativas não seriam suficientes para incluir
digitalmente. Democratizar o acesso a tais tecnologias seria, então,
incluir digitalmente? Não há consensos para tais questões. No entanto,
em vista da relevância do fenômeno social relacionado, torna-se neces-
sário que o problematizemos.

Inicialmente, analisando os discursos comumente associados ao tema,

podemos perceber, sem muita dificuldade, que o termo inclusão digital
tem relação direta com o seu antagônico exclusão digital. O dualismo
inclusão/exclusão digital compõe os principais sentidos atribuídos aos
referidos termos. Para minimizar ou combater a exclusão das pessoas de
uma dinâmica social caracterizada pelo uso intensivo das tecnologias de
base digital, empreende-se ações de inclusão digital.

136 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
Atividades
1. Defina a acessibilidade em seus diferentes contextos.

2. O que é exclusão digital e quais são suas consequências?

3. Quais conceitos estão presentes no desenvolvimento de sites acessíveis?

4. Explique a relação entre inclusão digital e inclusão social.

Referências
BONILLA, M. H. S.; PRETO, N. de L. (Org.). Inclusão digital: polêmica contemporânea. Salvador:
EdUFBA, 2011. v. 2.
BRASIL. Lei n. 10.098, de 19 de dezembro de 2000. Estabelece normas gerais e critérios básicos para a
promoção da acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida, e dá
outras providências. Diário Oficial da União, Brasília, DF, dez. 2000.
BRASIL. Decreto n. 5.296 de 2 de dezembro de 2004. Regulamenta as Leis nos 10.048, de 8 de novem-
bro de 2000, que dá prioridade de atendimento às pessoas que especifica, e 10.098, de 19 de dezembro
de 2000, que estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pes-
soas portadoras de deficiência ou com mobilidade reduzida, e dá outras providências. Diário Oficial
da União, Brasília, DF, 3 dez. 2004.
BRITO, G. S. Uma análise sobre a implantação de laboratórios de informática nas escolas de 1º
grau. 1997. 122 f. Dissertação (Mestrado em Tecnologia) – Programa de Pós-graduação em Tecnologia,
Centro Federal de Educação Tecnológica do Paraná, Curitiba, 1997. Disponível em: <[Link]
[Link]/dspace/bitstream/handle/1884/11296/Disserta%C3%A7%C3%A3o%20MARILUCI%20
[Link]?sequence=1>. Acesso em: 9 fev. 2017.
DARIVA, R. Gerenciamento de dispositivos móveis e serviços de telecom: saiba tudo sobre aplica-
tivos móveis, gerenciamento de dispositivos móveis e gerenciamento de custos de telecom. Rio de
Janeiro: Elsevier, 2011.
DEMO, P. Marginalização digital: Digital Divide. Boletim Técnico do Senac: a Revista da Educação
Profissional, Rio de Janeiro, v. 33, n. 2, p. 5-19, 2007.
______. Pesquisa e construção do conhecimento: metodologia científica no caminho de Habermas.
2. ed. Rio de Janeiro: Tempo Brasileiro, 2005.
IBM. Web accessibility for special needs. Disponível em: <[Link]
html>. Acesso em: 9 fev. 2017.
LÉVY, P. Cibercultura. Trad. C. I. da Costa. 1. ed. São Paulo: Ed. 34, 2000.
MELO, A. M. Design inclusivo de sistemas de informação na web. 2007. 339 f. Tese (Doutorado em
Ciência da Computação) – Instituto de Computação, Universidade Estadual de Campinas, Campinas,
2007.
MENEGUELLI, F. O novo perfil do professor: usar as novas tecnologias. Nova Escola, São Paulo, ano
25, n. 236, out. 2010.
MORIN, E. Os setes saberes necessários à educação do futuro. 2. ed. São Paulo: Cortez/Unesco, 1998.

Qualidade e Usabilidade de Software 137

 8 Acessibilidade e inclusão digital

NIELSEN, J.; TAHIR, M. Homepage usabilidade: 50 websites desconstruídos. Rio de Janeiro:

Campus,2002.
NEIL, T. Padrões de design para aplicativos móveis. São Paulo: Novatec, 2012.
PORTAL BRASIL. Práticas web acessíveis. Disponível em: <[Link]
cursodesenvolvedor/desenvolvimento-web/[Link]>. Acesso em: 9 fev.
2017.
SCHWARTZ, G. Educação como produção colaborativa de conteúdo. In: ENCONTRO NACIONAL
DAS ESCOLAS DE GOVERNO, 11., 2010, São Paulo. Anais... São Paulo: Fundap, 2010. Disponível
em: <[Link]
Gilson%20Schuartz%2009_06.pdf>. Acesso em: 8 ago. 2017.
SILVEIRA, S. A. A noção de exclusão digital diante das exigências de uma cibercidadania. In:
HETKOWSKI, T. M. (Org.). Políticas públicas e inclusão digital. Salvador: EdUFBA, 2008.
TAKAHASHI, T. (Org.) Sociedade da informação no Brasil: Livro Verde. Brasília: Ministério da
Ciência e Tecnologia, 2000. Disponível em: <[Link]
arquivos/[Link]>. Acesso em: 4 ago. 2017.
VALERIANO, D. Moderno gerenciamento de projetos. São Paulo: Pearson Prentice Hall, 2005.
WARSCHAUER, M. Tecnologia e inclusão social: a exclusão digital em debate. São Paulo: Senac-SP,
2006.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2006.

Resolução
1. Acessibilidade ao ambiente físico refere-se à qualidade que os espaços disponibi-
lizam a todos, inclusive nos casos de deficiência de mobilidade ou comunicação,
incluindo a possibilidade de: chegar a todos os lugares e edifícios sem esforço ex-
cessivo e autonomia; acessar as instalações de uso público e serviços fornecidos com
segurança e autonomia.

O Decreto n. 5.296 define a acessibilidade como “condição para utilização, com se-
gurança e autonomia, total ou assistida, dos espaços, mobiliários e equipamentos
urbanos, das edificações, dos serviços de transporte e dos dispositivos, sistemas e
meios de comunicação e informação, por pessoa portadora de deficiência ou com
mobilidade reduzida” (BRASIL, 2004).

Em paralelo, no caso da web e da internet em geral, a acessibilidade se refere ao con-

junto de elementos que facilitam o acesso à informação a todas as pessoas, de modo
igualitário, usando a tecnologia (computadores, tablets, telefones móveis, entre ou-
tros) independentemente das necessidades especiais dos usuários (físicas, mentais,
sensoriais e outras) (NIELSEN; TAHIR, 2002).

Já de acordo com o Livro Verde do Ministério da Ciência e Tecnologia (TAKAHASHI,

2000), a acessibilidade à informação e ao conhecimento é a variável de maior poder
de exclusão ou inclusão dos indivíduos no processo político e econômico.

138 Qualidade e Usabilidade de Software

 Acessibilidade e inclusão digital 8
2. Exclusão digital é o termo usado para se referir à consequência direta do abismo tec-
nológico que existe entre as comunidades que têm acesso à tecnologia da informação
e aquelas que são excluídas desse processo. As diferenças podem ser socioeconômi-
cas ou a capacidade de usar a tecnologia da informação de forma eficaz, devido aos
diferentes níveis de alfabetização e deficiência.

3. Conceito de camadas, conceito de tableless e conceito de semântica.

Conceito de camadas: Representa o uso adequado das tecnologias, ou seja, cada

tecnologia deve ser utilizada com o propósito único ao qual foi criada. Por exem-
plo, o HTML é utilizado apenas para a criação de conteúdo, enquanto a apre-
sentação visual é criada por meio do CSS. Já o comportamento é definido pelas
linguagens de script.

Conceito de tableless: As tabelas devem ser usadas apenas para dados tabulares e
não para fins de layout. Esse conceito surgiu devido ao uso excessivo de tabelas para
apresentação visual do site. O uso de tabelas para a estruturação da página prejudica
a apresentação da página em determinadas resoluções de tela, deixa a página mais
pesada, tem como consequência um código de difícil manutenção, além de causar
problemas de acessibilidade.

Conceito de semântica: Representa o uso correto das tags HTML, pois cada tag pos-
sui um objetivo específico e para tal deve ser utilizado. Essa validação encontrará
os erros de concordância entre o código criado e as recomendações e fornecerá ao
desenvolvedor a forma de corrigi-lo.

4. Um aspecto importante nessa relação é a consciência social: a web deve ser enten-
dida como algo universal, e essa universalidade deve levar em conta o acesso, por
qualquer pessoa, às informações fornecidas on-line.

As empresas devem se atentar a esse contexto de inclusão social, porque o fato de ter
um site acessível a todas as pessoas – independentemente de conhecimento pessoal
ou deficiências dos usuários e das características técnicas dos equipamentos utiliza-
dos – é uma vantagem social sobre a concorrência e um diferenciador (NIELSEN;
TAHIR, 2002).

Assim, toda a sociedade pode ter acesso ao conteúdo disponível na internet, e, com
isso, produzir e disseminar conhecimento. A inclusão digital está, portanto, inserida
no movimento de inclusão social, sendo ela um dos principais objetivos partilha-
dos por vários governos ao redor do mundo nas últimas décadas (WARSCHAUER,
2006).

Qualidade e Usabilidade de Software 139

 QUALIDADE E USABILIDADE DE SOFTWARE
Christina Paula de Camargo Curcio
Código Logístico

56271

Fundação Biblioteca Nacional

ISBN 978-85-387-6342-0

9 788538 763420