file-17

Prévia do material em texto

Código Logístico
56271
Fundação Biblioteca Nacional
ISBN 978-85-387-6342-0
9 7 8 8 5 3 8 7 6 3 4 2 0
Q
U
A
L
ID
A
D
E
 E
 U
S
A
B
IL
ID
A
D
E
 D
E
 S
O
F
T
W
A
R
E
C
hristina Paula d
e C
am
arg
o
 C
urcio
IESDE BRASIL S/A
2017
Qualidade e Usabilidade 
de Software
Christina Paula de Camargo Curcio
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 – www.iesde.com.br
Capa: IESDE BRASIL S/A.
Imagem da capa: lukutin77/iStockphoto
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q
2. ed. Curcio, Christina Paula de Camargo
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.
17-44416 CDD: 005.1CDU: 004.41
© 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.
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.
6 Qualidade e Usabilidade de Software
SumárioSumá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
Qualidade e Usabilidade de Software 7
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 9
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 de software1
Qualidade e Usabilidade de Software10
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, 
Vídeo
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 siste-
ma 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.
Métodos
Pessoas e 
definição de requisitos
Ferramentas
Integração e 
melhoria contínua
Garantia da 
qualidade de 
software
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.
Qualidade de software
Qualidade e Usabilidade de Software
1
11
1.1.1 Fundamentos da qualidade de software
Originalmente, a qualidade de um programaou 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 de software1
Qualidade e Usabilidade de Software12
• 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.
Qualidade de software
Qualidade e Usabilidade de Software
1
13
• 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.
1.1.2.1 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 de software1
Qualidade e Usabilidade de Software14
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.
1.1.2.2 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).
1.1.2.3 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).
Qualidade de software
Qualidade e Usabilidade de Software
1
15
1.2 Processos em qualidade de software
Para falar sobre qualidade em software, é preciso introduzir uma dis-
cussão sobre os erros aos quais um processo de desenvolvimento de soft-
ware 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.
Vídeo
Qualidade de software1
Qualidade e Usabilidade de Software16
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ênciade 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 
Qualidade de software
Qualidade e Usabilidade de Software
1
17
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 de software1
Qualidade e Usabilidade de Software18
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.
Qualidade de software
Qualidade e Usabilidade de Software
1
19
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-
masda 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 de software1
Qualidade e Usabilidade de Software20
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
 2 Estabelecer os ob-
jetivos, processos 
e recursos
Revisão dos 
processos de 
qualidade
 2 Cumprir os objeti-
vos e requisitos de 
qualidade
 2 Garantir que os re-
quisitos de qualidade 
sejam cumpridos
Planejamento 
da qualidade
Controle da 
qualidade
Garantia da 
qualidade
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, funcio-
nalidade, confiabilidade, manutenibilidade e desempenho. Para que essas 
características de qualidade de software sejam atendidas é importante que sejam respondidas 
questões como: O software satisfaz a necessidade do usuário ou da empresa? Ele é confiável? 
Vídeo
Qualidade de software
Qualidade e Usabilidade de Software
1
21
Tem um bom desempenho? É fácil de usar? Pode ser corrigido com facilidade? Pode ser reutili-
zado em outro projeto?
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.
Qualidade de software1
Qualidade e Usabilidade de Software22
• 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.
 Ampliando seus conhecimentos
O texto a seguir trata sobrea 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.
Qualidade de software
Qualidade e Usabilidade de Software
1
23
 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: <http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-
-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx#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: <https://books.google.com.br/books?id=i-
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 de software1
Qualidade e Usabilidade de Software24
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.
Qualidade e Usabilidade de Software 25
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.
Normas e padrões2
Qualidade e Usabilidade de Software26
2.1 Normas e seus organismos normativos
A normalização é o processo de desenvolvimento, implementação e 
melhoria dos padrões que se aplicam a ordens científica, industrial e eco-
nô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 atividades específicas, visando 
a benefícios e com a cooperação de todos os envolvidos (CYBIS et al., 2015). As grandes so-
mas de dinheiro que os países desenvolvidos investem em organizações nacionais e interna-
cionais 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ércio e 
Vídeo
Normas e padrões
Qualidade e Usabilidade de Software
2
27
a indústria, levando a um aumento acelerado no volume de transações comerciais entre os 
países (SOMMERVILLE, 2011).
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 internacional-
mente 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 organis-
mos nacionais de normalização de todas as regiões do mundo, incluindo países desenvolvi-
dos 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; 
Vídeo
Normas e padrões2
Qualidade e Usabilidade de Software28
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 
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 
Normas e padrões
Qualidade e Usabilidade de Software
2
29
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 
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).
2.2.2.1 Níveis de maturidade e capacidade
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).
Normas e padrões2
Qualidade e Usabilidade de Software30
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 
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.
1 - Inicial
Processo im-
previsível e 
sem controle
2 - Repetível
Processo dis-
ciplinado
3 - Definido
Processo 
consistente e 
padronizado
4 - Gerenciado
Processo previ-
sível e contro-
lado
5 - Otimizado
Processo con-
tinuamente 
melhorado
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, 
ferramentas e métodos. O conjunto de processos padrão da organização é estabelecido e 
Normas e padrões
Qualidade e Usabilidade de Software
2
31
continuamente melhorado, de modo consistente para toda a empresa. Os projetos são esta-
belecidos por meio da adaptação desse conjunto de procedimentos e normas de acordo com 
diretrizes específicas.
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 continuamenterevisados, 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 
Normas e padrões2
Qualidade e Usabilidade de Software32
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.
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
Inicial
 2 Basicamente nenhuma prática forma de gerenciamento de engenharia 
de software está implantada na organização.
 2 Tudo é feito à medida em que vão surgindo as necessidades.
 2 O padrão usual é o não cumprimento de prazos e orçamentos 
estabelecidos.
 2 A maioria das atividades são respostas a crises e não a tarefas 
pré-planejadas.
 2 O processo de software é imprevisível e depende totalmente da equipe 
atual.
 2 É impossível prever com precisão o tempo necessário para desenvol-
ver um produto ou o seu custo.
Repetível
 2 Já estão implantadas práticas básicas de gerenciamento de projetos de 
software.
 2 As técnicas de planejamento e gerenciamento se baseiam em experiên-
cias com produtos similares (daí o termo repetível).
 2 Há o acompanhamento meticuloso dos cronogramas de prazo e da 
planilha de custos.
 2 Os gerentes identificam problemas à medida que eles vão surgindo e 
tomam ações corretivas imediatas para evitar que eles se transformem 
em crises.
 2 Medidas tomadas durante um projeto podem ser usadas para elaborar 
cronogramas e orçamentos realistas para projetos futuros.
Normas e padrões
Qualidade e Usabilidade de Software
2
33
Nível Características
Definido
 2 O processo para a produção de software é completamente 
documentado;
 2 Tanto aspectos técnicos quanto gerenciais do processo são claramente 
definidos.
 2 São feitos esforços contínuos para melhorar o processo onde for 
possível.
 2 São usadas revisões para atingir as metas de qualidade de software.
 2 Há a introdução de novas tecnologias, como as ferramentas CASE 
para aumentar a produtividade.
Gerenciado
 2 A organização estabelece metas de qualidade e produtividade para 
cada projeto.
 2 A qualidade e a produtividade são medidas continuamente.
 2 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis 
das metas.
 2 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.
Otimizado
 2 Há aperfeiçoamento contínuo do processo.
 2 São usadas técnicas de controle estatístico de processos e qualidade 
para orientar a organização.
 2 O conhecimento adquirido em cada projeto é utilizado em projetos 
futuros.
 2 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).
Normas e padrões2
Qualidade e Usabilidade de Software34
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
Nível 4 Manejado quantitativamente Manejado quantitativamente (gerenciado)
Nível 5 Otimizado Otimizado
Fonte: CYBIS et al., 2015. Adaptado.
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 determina-
do 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 
Normas e padrões
Qualidade e Usabilidade de Software
2
35
objetivos 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.
Área de processo Categoria
Nível de 
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 
+IPPD) Gestão de processos 3
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 conformidade comas exigências implícitas e explícitas dos clientes. 
O principal objetivo da engenharia de software é produzir com uma alta 
Vídeo
Normas e padrões2
Qualidade e Usabilidade de Software36
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.
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.
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.
Normas e padrões
Qualidade e Usabilidade de Software
2
37
• 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.
 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.
Normas e padrões2
Qualidade e Usabilidade de Software38
Muitos clientes que prezam por mais confiabilidade nos contratados buscam 
empresas que sejam certificadas na área. Hoje são diversas as certificações, 
onde cada uma atende necessidades específicas do negócio.
As mais conhecidas da área de tecnologia são: CMMI e MPS.BR. Para se certi-
ficar, 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 pro-
cessos 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.
[...]
 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 9001:2000: 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 9001:2008: Sistemas de Gestão da Qualidade: requisitos. Rio de Janeiro, 2008.
______. NBR ISO 9001:2015: 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: <http://www.sei.cmu.edu/library/assets/whitepapers/cmmi-dev_1-2_portuguese.pdf>. Acesso 
em: 3 ago. 2017.
CMMI INSTITUTE. Disponível em: <http://cmmiinstitute.com/capability-maturity-model-integra-
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.
Normas e padrões
Qualidade e Usabilidade de Software
2
39
ISD BRASIL. O que é SCAMPI? Disponível em: <http://www.isdbrasil.com.br/o-que-e-scampi.php>. 
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.
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011. Disponível 
em: <https://revistas.utfpr.edu.br/recit/article/view/4256>.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 41
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).
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software42
3.1 Processos de negócio
As empresas se diferenciam entre si pela sua capacidade de organi-
zação e de processos de negócio. Cada empresa utiliza um procedimento 
específico para chegar ao resultado desejado, 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 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.
Vídeo
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
43
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.
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, juntamentecom 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. 
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software44
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. 
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á 
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
45
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:
Figura 1 – O contexto da engenharia de requisitos.
Requisitos
Gerência de 
Projetos
Análise e 
projeto
Implementação
Implantação
Medição e análise
Testes
cliente necessidades do cliente
plano de projeto e acompanhamento – 
escopo, orçamento e prazo
projeto da solução
projeto do banco de dados
material de treinamento e de 
suporte ao usuário
estimativas e medições
casos de teste
equipe
Facilita a interação 
com o cliente
acordos sobre 
a entrega
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 comportamento 
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software46
desejado do sistema e o modo pelo qual outros componentes do sistema intera-
gem com o 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 proje-
to de desenvolvimento 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 necessidades 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 deproduto;
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.
Vídeo
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
47
• 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.
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 sistema, 
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 quali-
dade que o sistema deve oferecer, como, por exemplo, desempenho, confiabilidade, 
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 (confiabilidade) ou quan-
do 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).
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software48
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.
Vídeo
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
49
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ícitose, 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.
Vídeo 3.3 Qualidade de requisitos de software
Os requisitos de software são a base a partir da qual a qualidade é medi-
da. 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.
Modelo de 
negócios Requisitos
Análise e 
modelagem
Implemen-
tação
Testes de 
software
Disponibi-
lização
Esforço 
para obter 
qualidade
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.
Modelo de 
negócios Requisitos
Análise e 
modelagem
Implemen-
tação
Testes de 
software
Disponibi-
lização
Tempo
Processo de garantia da qualidade de software
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).
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software50
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.
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
51
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
Confiabilidade
Maturidade
Avaliar a 
capacidade 
de prevenção 
de falhas do 
sistema do 
ponto de vista 
do usuário.
Quantas falhas foram 
detectadas durante 
um período definido 
de experimentação?
Número de falhas 
detectadas/número 
de casos de testes
Tolerância 
a falhas de 
recuperabilidade
Avaliar a 
disponibilidade 
do sistema do 
ponto de vista 
do usuário.
Quantos padrões de 
defeitos são mantidos 
sob controle para evitar 
falhas críticas e sérias?
Número de ocorrên-
cias de falhas sérias e 
críticas evitadas confor-
me os casos de testes 
de indução de falhas/
número de casos de 
testes de indução de 
falhas executados
Quão disponível é 
o sistema para uso 
durante um período 
de tempo específico?
Tempo de operação 
(tempo de operação + 
tempo de reparo) 
Total de casos em 
que o sistema estava 
disponível e foi 
utilizado com sucesso 
pelo usuário / número 
total de casos em que 
o usuário tentou usar 
o software durante um 
período de tempo.
Qual é o tempo médio 
em que o sistema fica 
indisponível quando 
uma falha ocorre, antes 
da inicialização?
Tempo ocioso total 
(indisponível)/número 
de quedas do sistema
Qual o tempo médio 
que o sistema leva 
para completar 
a recuperação 
desde o início?
Soma de todos os 
tempos de recuperação 
do sistema inativo em 
cada oportunidade/
número total de ca-
sos em que o sistema 
entrou em recuperação
Fonte: WAZLAWICK, 2013, p. 248.
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software52
 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.
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
53
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?
Influência dos requisitos na qualidade do software3
Qualidade e Usabilidade de Software54
Figura – Ciclo de desenvolvimento no qual a qualidade se resume a testes 
de software.
Modelo de 
negócios Requisitos
Análise e 
modelagem
Implemen-
tação
Testes de 
software
Disponibi-
lização
Esforço 
para obter 
qualidade
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: <http://www.inmetro.gov.br/noticias/conteudo/ac.asp>. 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: <https://www.tiespecialistas.com.br/2015/11/analise-e-levantamento-de-requisitos-
-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.
Influência dos requisitos na qualidade do software
Qualidade e Usabilidade de Software
3
55
 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 57
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).
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software58
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).
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
59
• 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.Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software60
Figura 1 – Modelo de ciclo de vida codifica-remenda.
Descontinuação 
do produto
Manutenção pós-
-entrega
Modificar até que 
o cliente fique satisfeito
Desenvolvimento
Manutenção
Implementar a 
primeira versão
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.
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
61
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.
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software62
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 
de requisitos
Teste 
de aceitação
Projeto da 
arquitetura
Teste 
de sistema
Projeto 
de componente
Teste 
de integração
Geração 
de código
Software 
executável
Teste de 
unidade
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:
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
63
Figura 4 – Modelo em espiral.
1. Determinar obje-
tivos
2. Identificar e 
resolver riscos
4. Planejar a próxima iteração
Custo acumulativo
Progresso
3. Desenvolvimento e testes
Revisão
Plano de 
requeri- 
mentos
Requeri- 
mentos
Conceito de 
Requeri- 
mentos
 Conceito 
de operação
Plano de 
desenvolvimento Verificação 
e validação
Verificação 
e validação
Plano de 
testes
Análise de riscos
Análise 
de riscos
Análise 
de riscos
Protótipo 1
Protótipo 
2
Protótipo 
operacional
Desenho 
detalhado
Esboço
Código
Integração
Testes
Entrega Implementação
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 fasesanteriores, 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.
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software64
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.
Construção 
de protótipo
Comunicação
Planejamento 
rápido
 Modelagem 
 Projeto rápido
 Entrega e 
 feedback
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).
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
65
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.
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software66
Figura 6 – Software com qualidade.
Usuário
Requisitos 
atendidos
Padrões 
atendidosSoftware com qualidade
Desenvolvedor Organização
Processo de 
desenvolvi-
mento
Software 
produto
Requisito Padrões
Processo de 
software
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 suaconformidade 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).
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
67
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
Comparação
Testes de usabilidade
• O teste de validação é realizado para checar se há algum erro.
• Compara a saída de um uso específico com um sistema de dados 
previamente criado com os mesmos parâmetros.
• 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?
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software68
• 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).
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
69
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, 
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software70
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).
4.3.1.1 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.
Tarefas de Backlog 
detalhadas 
pela equipe
Backlog da Sprint
Daily meeting
24 horas
30 dias
Backlog 
priorizado pelo 
Product Owner
Produto incremental 
a ser entregue
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.
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
71
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).
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software72
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 
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
73
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. [...]
Processo de desenvolvimento de software4
Qualidade e Usabilidade de Software74
 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: <https://www.inf.ufes.br/~monalessa/PaginaMonalessa-NEMO/ES_Mestrado/
Artigos/EstendendoScrumSegundoAreasDeGerenciaNoCMMI.pdf>. 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: <http://www.
mountaingoatsoftware.com/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.
Processo de desenvolvimento de software
Qualidade e Usabilidade de Software
4
75
 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 77
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.
Gerência da qualidade de software5
Qualidade e Usabilidade de Software78
5.1 Dimensões da qualidade 
do processo e do produto
A qualidade do processo e do produto decorrentes do desenvolvi-
mento de software está ligada à percepção e às expectativas dos consumi-
dores, em termos das dimensões de qualidade de serviço (PARASURAMAN; ZEITHAML; 
BERRY, 2005).
5.1.1 Dimensões daqualidade 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 
Vídeo
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
79
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
RecursoConfiabilidade
Conformidade
Durabilidade
Qualidade 
percebida
Dimensões 
de qualidade
Facilidade de 
manuseamento
Estética
Fonte: Elaborada pela autora, com base em GARVIN, 2015.
As oito dimensões são explicadas por Garvin conforme exposto a seguir.
5.1.2.1 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 
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.
Gerência da qualidade de software5
Qualidade e Usabilidade de Software80
ou a reputação da empresa. Por isso, muitos contratos ou especificações também incluem os 
danos relacionados ao desempenho inadequado.
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.
5.1.2.2 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.
5.1.2.3 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 
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
81
confiável ao usuário, já o sistema 2 apresenta maior disponibilidade, pois as falhas são 
corrigidas rapidamente.
5.1.2.4 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 aosrequisitos do cliente/usuário.
5.1.2.5 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, 
Gerência da qualidade de software5
Qualidade e Usabilidade de Software82
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.
5.1.2.6 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.
5.1.2.7 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.
5.1.2.8 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 
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
83
de todos os usuários – o desenvolvedor, o cliente, o usuário final e todas as partes inte-
ressadas (stakeholders).
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 impli-
ca 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 
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).
Vídeo
Gerência da qualidade de software5
Qualidade e Usabilidade de Software84
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 relativosque se baseiam em 
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 
encontrados
Quantidade
Custo 
unitário
Total
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 
encontrados
Quantidade
Custo 
unitário
Total
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.
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
85
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. 
Gerência da qualidade de software5
Qualidade e Usabilidade de Software86
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 atividades de apoio que permite a absorção ordenada das mudanças 
inerentes ao desenvolvimento 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.
Vídeo
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
87
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 descritoa 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.
Gerência da qualidade de software5
Qualidade e Usabilidade de Software88
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.
[...]
Gerência da qualidade de software
Qualidade e Usabilidade de Software
5
89
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: <http://gti.projetointegra-
dor.com.br/~152M154200121/Modulo5/Auditoria%20e%20Qualidade%20de%20Software/PI%20-%20
Auditoria%20e%20Qualidade%20de%20Software.pdf>. 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.
Gerência da qualidade de software5
Qualidade e Usabilidade de Software90
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 PrenticeHall, 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.
Qualidade e Usabilidade de Software 91
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.
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software92
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 multidisciplinar, 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 desenvolvimento 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.
ErgonomiaPsicologia 
social e 
organizacio-
nal
Psicologia 
cognitiva
Ciência da 
computação
Inteligência 
artificial
Linguística Filosofia
Sociologia
Engenharia
Design
Antropologia
IHC
Fonte: PREECE, 1997, apud ANDRADE, 2007, p. 36.
Vídeo
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
93
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).
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software94
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
Valor
Usabilidade
Encontrabilidade
Credibilidade
Acessibilidade
Desejo
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).
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
95
Muitos designers de interface web conduzem estudos honeycomb para identificar priori-
dades na fase de projeto, procurando refletir sobre todas as facetasdo 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?
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software96
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.
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
97
6.1.3.1 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).
6.1.3.2 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),
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software98
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.
6.1.3.3 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).
6.1.3.4 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.
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
99
A figura a seguir demonstra a disposição desses objetos em uma interface:
Figura 5 – Objetos de interação.
Janela
Barra de 
rolagem
Caixa de 
mensagem
Botões
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.
6.1.3.5 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:
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software100
• 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.
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
101
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 ner-
vo do próprio corpo). Essa tecnologia pode ajudar pessoas com deficiência visual ou auditi-
va a voltar a enxergar ou a ouvir e pessoas com deficiência física a mover uma prótese me-
câ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, numerosas metodologias de design de software têm sido desenvol-
vidas. A maioria delas é baseada no fato de que os designers têm de captu-
rar a interatividade entre o usuário e o sistema técnico. 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 cog-
nitiva 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çãoproposto 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.
Vídeo
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software102
• 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 
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 de-
senvolvidos 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.
HOMEM
Pensar
Processamento 
de input de 
acordo com os 
algoritmos
Responder
Resposta do computador 
enviada ao usuário
Ler-examinar
Reconhecimento e interpreta-
ção da informação apresenta-
da pelo computador
Pensar
Tomada de deci-
sões (o que fazer 
com a resposta 
recebida do 
computador)
Responder
Ação do usuário gerando 
input para o computador
Ler-examinar
Reconhecimento e interpre-
tação dos inputs do usuário
Domínio do controle 
do computador
Domínio do controle 
do homem
COMPUTADOR
I
N
T
E
R
F
A
C
E
Fonte: MAYHEW, 1992.
Vídeo
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
103
É 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.
Fundamentos da interação homem-computador (IHC)6
Qualidade e Usabilidade de Software104
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?
Fundamentos da interação homem-computador (IHC)
Qualidade e Usabilidade de Software
6
105
 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: <http://www.cs.unc.edu/~azuma/ARpresence.pdf>. Acessoem: 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 107
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.
Usabilidade de software7
Qualidade e Usabilidade de Software108
7.1 Definições de usabilidade 
do software
A capacidade com que as pessoas podem utilizar uma ferramenta é 
chamada de usabilidade, que também pode se referir ao estudo dos princí-
pios da eficácia percebida de um objeto. 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 eficá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 “capaci-
dade do produto de software de ser compreendido, aprendido, operado e atraente 
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 de uso
Facilidade com que o usuário faz uso da ferramenta, com 
menos etapas para chegar a seu objetivo proposto, estan-
do relacionada à eficiência da ferramenta.
Facilidade de 
aprendizado
Facilidade com que novos usuários desenvolvem uma 
interação com o sistema ou produto, relacionada com a 
familiaridade e a previsibilidade.
Flexibilidade Relacionada à diversidade de formas de executar uma de-terminada tarefa e otimização entre usuário e sistema.
Robustez
Facilidade e nível de serviço oferecido de suporte para 
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.
Vídeo
Usabilidade de software
Qualidade e Usabilidade de Software
7
109
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 de-
cisõ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:
7.2.1.1 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;
Vídeo
Usabilidade de software7
Qualidade e Usabilidade de Software110
• os membros do públicoque usam o ambiente diferem significativamente em termos 
de como veem as semelhanças entre os itens e os agrupamentos apropriados destes.
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. 
7.2.1.2 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 
Usabilidade de software
Qualidade e Usabilidade de Software
7
111
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).
7.2.1.3 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. 
7.2.1.4 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). 
7.2.1.5 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).
7.2.1.6 Lista de verificação de recursos/características (feature 
checklists)
Usabilidade de software7
Qualidade e Usabilidade de Software112
Esse método visa avaliar a importância que os participantes dão a determinadas carac-
terísticas de uma interface.
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).
7.2.1.7 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 
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.
Usabilidade de software
Qualidade e Usabilidade de Software
7
113
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.
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 durantea 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.
7.2.1.8 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).
7.2.1.9 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 
Usabilidade de software7
Qualidade e Usabilidade de Software114
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).
7.2.1.10 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.
7.2.2.1 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).
7.2.2.2 Avaliação heurística (heuristic evaluation)
O objetivo principal das avaliações heurísticas é identificar quaisquer problemas as-
sociados 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 
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.
Usabilidade de software
Qualidade e Usabilidade de Software
7
115
e consultoria 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.
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).
7.2.2.3 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).
7.2.2.4 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. 
7.2.2.5 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.
Usabilidade de software7
Qualidade e Usabilidade de Software116
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 expectativasem relação ao produto.
7.3 A importância das 
recomendações de usabilidade
As recomendações de usabilidade, ao serem incorporadas no desenvol-
vimento do software, mensuram a facilidade do uso de um produto. Entre 
elas, pode ser citada a aplicaçã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 tecno-
ló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 softwa-
re ser bem elaborado, tornar-se mais eficiente, com baixa taxa de erros, e de fácil memo-
rizaçã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 
Vídeo
Usabilidade de software
Qualidade e Usabilidade de Software
7
117
recomendações funcionam como um guia importante para os programadores ao desenvol-
verem, testarem e finalizarem um software, apontando os problemas e os erros enquanto 
ainda há tempo de serem solucionados.
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.
Conceito 
Às vezes também 
chamado de 
Como utilizar
Metas usabilidade
Estabeler critérios de usabilidade 
para avaliar a aceitabilidade de um 
sistema (p. ex: “Quanto tempo leva 
para a realização de uma tarefa?”)
Metas decorrentes da ex-
periência do usuário Fatores de satisfação
Identificar os aspectos importantes 
da experiência do usuário (p. ex: 
“Como se pode tornar o produto in-
terativo divertido e agradável?”)
Princípio de design
Heurística, quando 
utilizado na prática. 
Conceitos de design.
Como lembretes do que fornecer e 
do que evitar durante o design da 
interface (p. ex: “que tipo de feedback 
você vai fornecer na interface?”)
Princípio de usabilidade Heurística, quando utilizado na prática.
Avaliar aceitabilidade das interfaces, 
utilizadas durante a avaliação heu-
rística (p. ex: “O sistema oferece saí-
das claramente indicadas?”)
Regras
Determinar se uma interface adere 
a uma regra específica, quando está 
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.
Usabilidade de software7
Qualidade e Usabilidade de Software118
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 
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 
Usabilidade de software
Qualidade e Usabilidade de Software
7
119
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.
Usabilidade de software7
Qualidade e Usabilidade de Software120
 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: <https://www.maxwell.vrac.puc-
-rio.br/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). 
Usabilidade de software
Qualidade e Usabilidade de Software
7
121
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 123
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.
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software124
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 in-
formação, o conceito de acessibilidade evoluiu tendo em conta as novas 
realidades. Na verdade, mobilidade, proximidade e distância já não são as-
pectos 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 deficiên-
cia. Já a infoacessibilidade refere-se a produtos e serviços eletrônicos que podem ser utiliza-
dos por usuários com eficiência e satisfação, em um contexto de uso específico, por exem-
plo: acessibilidade de equipamentos de informática (hardware e software), acessibilidade 
Vídeo
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
125
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).
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).
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software126
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.
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 ins-
tituição que realiza um esforço para melhorar a acessibilidade à web para pessoas com 
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
127
deficiência. Pessoas com necessidades especiais podem encontrar dificuldades ao usar com-
putadores 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 re-
lacionam 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. 
1 Mais informações sobre o Consórcio W3C podem ser encontradas no endereço: <http://www.w3c.
br/Home/WebHome>.
2 Mais informações sobre essas diretrizes estão disponíveis no endereço: <https://www.w3.org/WAI/
guid-tech>.
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software128
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 
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 tecnologias influenciam de forma marcante 
as transformações na sociedade.
Vídeo
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
129
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 sistemasde 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).
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software130
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 
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
131
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 incen-
tivo à inclusão digital, 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 tra-
ta do Regime Especial de Aquisição de Computadores para Uso Educacional (RECOMPE), 
que facilita a compra de computadores para uso educacional.
Vídeo
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software132
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: <https://wiki.gnome.org/Projects/Orca>.
• 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: <https://www.lazarus-ide.org/>.
• 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: <http://www.linaccess.org>.
• 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.
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
133
 Disponível em: <http://www.mozilla.org/access>.
• 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: <http://mielke.cc/brltty/index.html>.
• 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: <http://festvox.org>.
 Disponível em: <http://www.cstr.ed.ac.uk/projects/festival/>.
• 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: <http://www.linuxfromscratch.org/blfs/view/6.3/gnome/gnome-s-
peech.html>.
• 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: <https://directory.fsf.org/wiki/Gnopernicus>.
• 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: <http://kmag.sourceforge.net/>.
• 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: <http://linux.about.com/cs/linux101/g/xzoom.htm>.
• 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: <http://freshmeat.net/projects/svgatextmode/>.
8.3.2 Deficiência motora
Os softwares destacados a seguir são destinados para aqueles usuários que apresentam 
deficiência motora.
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software134
• 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: <http://www.bltt.org/software/dasher/>.
• 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: <http://www.gok.ca/>
• 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: <http://xvoice.sourceforge.net/>.
• 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: <http://freespeech.sourceforge.net/>.
• 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: <https://clic.xtec.cat/>.
• 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 comlimitações motoras, por meio do uso de um ou mais switches 
de comando (comutadores).
 Disponível em: <http://www.bltt.org/software/firefox/hawking.htm>.
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.
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
135
É 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”.
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
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software136
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.
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
137
 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: <http://dspace.
c3sl.ufpr.br/dspace/bitstream/handle/1884/11296/Disserta%C3%A7%C3%A3o%20MARILUCI%20
ZANELA.pdf?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: <http://www.austin.ibm.com/sns/acessweb.
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.
Acessibilidade e inclusão digital8
Qualidade e Usabilidade de Software138
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: <http://emag.governoeletronico.gov.br/
cursodesenvolvedor/desenvolvimento-web/praticas-web-acessivel-marcacao.html>. 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: <http://www.fundap.sp.gov.br/egdialogal/pdf/Apresenta%C3%A7%C3%A3o%20%20texto%20
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: <https://www.governoeletronico.gov.br/documentos-e- 
arquivos/livroverde.pdf>. 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.
Acessibilidade e inclusão digital
Qualidade e Usabilidade de Software
8
139
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).
Código Logístico
56271
Fundação Biblioteca Nacional
ISBN 978-85-387-6342-0
9 7 8 8 5 3 8 7 6 3 4 2 0
Q
U
A
L
ID
A
D
E
 E
 U
S
A
B
IL
ID
A
D
E
 D
E
 S
O
F
T
W
A
R
E
C
hristina Paula d
e C
am
arg
o
 C
urcio
	Página em branco
	Página em branco