Livro - Qualidade e Usabilidade de Software

Prévia do material em texto

QUALIDADE E USABILIDADE 
DE SOFTWARE
Christina Paula de Camargo Curcio
Te
cn
o
lo
g
ia
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
hr
is
tin
a 
P
au
la
 d
e 
C
am
ar
g
o 
C
ur
ci
o
Neste livro vamos apresentar os conceitos fundamentais relacionados à quali-
dade de software, métricas, normas e orientações sobre a gestão da qualida-
de. Após este estudo, esperamos que você tenha facilidade para reconhecer 
a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus 
próprios projetos, identificando os requisitos necessários para o desenvolvi-
mento de um software com qualidade.
Fundação Biblioteca Nacional
ISBN 978-85-387-6296-6
9 788538 762966
CAPA_Qualidade e Usabilidade de Software.indd 1 17/08/2017 10:09:01
Christina Paula de Camargo Curcio
IESDE BRASIL S/A
Curitiba
2017
Qualidade e 
Usabilidade de 
Software
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q Curcio, Christina Paula de Camargo
Qualidade e usabilidade de software / Christina Paula de Camargo 
Curcio. - 1. ed. - Curitiba, PR : IESDE Brasil 2017.
184 p. : il. 
Inclui bibliografia
ISBN 978-85-387-6296-6
1. Engenharia de software. 2. Software - Desenvolvimento. I. Título.
17-43661 CDD: 005.1
 CDU: 004.41
Direitos desta edição reservados à Fael.
É proibida a reprodução total ou parcial desta obra sem autorização expressa da Fael.
© 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.
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
Produção
FAEL
Direção Acadêmica Francisco Carlos Sardo
Coordenação Editorial Raquel Andrade Lorenz
Revisão IESDE
Projeto Gráfico Sandro Niemicz
Capa Vitor Bernardo Backes Lopes
Imagem Capa David M G/Shutterstock.com
Arte-Final Evelyn Caroline dos Santos Betim
Sumário
Carta ao Aluno | 5
1. Qualidade de software | 7
2. Normas e padrões | 27
3. Influência dos requisitos na qualidade do software | 47
4. Processo de desenvolvimento de software | 65
5. Gerência da qualidade de software | 89
6. Fundamentos da interação homem-computador (IHC) | 107
7. Usabilidade de software | 127
8. Acessibilidade e inclusão digital | 145
Gabarito | 165
Referências | 175 
Carta ao Aluno
No mercado atual existe uma diversidade de softwares para 
uso empresarial ou informal.
Os sistemas podem auxiliar bastante os processos de uma 
empresa 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 um software ter de qualidade?
A usabilidade de um software deve ser cuidadosamente 
estudada, pois compreender a interação do homem com o compu-
tador pode definir o sucesso ou o fracasso de uma aplicação. Além 
dos aspectos de usabilidade, se faz necessário reconhecer outros 
aspectos importantes que garantem a qualidade do software, assim 
como as etapas de planejamento e produção que devem ser rigo-
rosamente seguidas.
– 6 –
Qualidade e Usabilidade de Software
Neste livro vamos apresentar os conceitos fundamentais relacionados à 
qualidade de software, métricas, normas e a gestão da qualidade de software. 
Após este estudo, esperamos que você tenha facilidade para gerir e reconhecer 
a qualidade e usabilidade dos softwares disponíveis no mercado e identificar os 
requisitos necessários para o desenvolvimento de um software com qualidade.
Esperamos que seu estudo não termine por aqui. Com base neste mate-
rial, realize as atividades propostas, leia os textos indicados e faça você mesmo 
a sua pesquisa para aprofundar os conhecimentos aqui apresentados.
Bom estudo!
Qualidade de software
Introdução
O dia a dia das organizações demonstra como é frustrante a 
realidade do desenvolvimento de software: produtos mais caros do 
que deveriam ser, gastos desnecessários, cronogramas estourados, 
estresse no trabalho, desenvolvedores desmotivados, erros recorren-
tes nos projetos etc. Todos na organização saem perdendo com isso, 
sem exceção.
Para que os problemas enfrentados pelas organizações pro-
dutoras 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 quali-
dade é possível construir sistemas de computação adequados. Desse 
modo, o objetivo deste capítulo é apresentar uma reflexão sobre a 
qualidade de software (conceito, fundamentos e processo), emba-
sada em pesquisa bibliográfica da área.
1
Qualidade e Usabilidade de Software
– 8 –
1.1 A qualidade de software
Qualidade é a capacidade de um produto ou serviço para atender às neces-
sidades do usuário (BEYON, 2011). No desenvolvimento de software, a qua-
lidade do projeto acompanha os requisitos de qualidade, as especificações e o 
design do sistema. Ela está focada principalmente no aspecto de implementa-
ção, em que é observado se a execução segue o design planejado e se o sistema 
resultante está cumprindo com os objetivos e requisitos de desempenho.
Para garantir a qualidade do software são necessários: envolvimento de 
pessoas, definiçã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 soft-
ware é preciso pessoas (analistas, programadores, webdesigners, gestores etc.) 
que tenham não apenas conhecimento da área, mas que saibam trabalhar em 
equipe e tenham disciplina e comprometimento 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 compreendi-
dos como “as funções ou atividades 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 
– 9 –
Qualidade de software
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 à inte-
gração de todas as funções e recursos de uma empresa, desde a alta admi-
nistraçã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 cor-
reta, e garantem que o software atenda aos propósitos desejados.
1.1.1 Fundamentos da qualidade de software
Originalmente, a qualidade de um programa ou sistema era avaliada de 
acordo com o número de defeitos a cada mil linhas de código. Atualmente, 
com a evolução do conceito, outros fatores determinam a qualidade do 
software (BENYON, 2011):
 2 Operações de produtos: ascaracterísticas operacionais.
 2 Correção: grau em que um programa atende sua especificação e 
atinge os objetivos definidos pelo usuário.
 2 Confiabilidade: nível de execução esperada de um software para 
realizar as funções com precisão.
 2 Eficiência: número de computadores e recursos exigidos pelo pro-
grama para executar suas funções com o tempo de resposta adequado.
 2 Integridade: medida em que pode ser controlado o acesso ao software 
ou dados por usuários não autorizados.
 2 Facilidade de uso: esforço necessário para aprender, usar e interpre-
tar a funcionalidade do sistema.
 2 Revisão do produto: capacidade de resistir a mudanças de tecnologia.
Qualidade e Usabilidade de Software
– 10 –
 2 Facilidade de manutenção: necessária para localizar e corrigir um 
bug no sistema.
 2 Flexibilidade: esforço necessário para modificar um programa.
 2 Facilidade de teste: condição necessária para testar um programa, 
de modo a assegurar que a função desejada não exija esforço.
 2 Transição do produto: capacidade de adaptação a novos ambientes.
 2 Portabilidade: necessária para transferir um programa de um 
ambiente de hardware ou software a outra tecnologia.
 2 Reutilização: grau em que um componente de programa ou 
 software pode ser reutilizado em outras aplicações.
 2 Interoperabilidade: integração entre sistemas e outros aplicativos.
O CMM (Capability Maturity Model) é um modelo de qualidade de 
 software que classifica 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 classificadas em cinco níveis de maturidade:
No nível 1 (inicial), o das organizações mais imaturas, não há 
nenhuma metodologia implementada e tudo ocorre de forma desor-
ganizada: 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 organização consegue até 
absorver mudanças no processo sem prejudicar o desenvolvimento do 
software. (RESENDE, 2005, p. 137).
Para atingir um nível maduro de produção, métodos específicos devem 
ser implementados (WEBER, 2012):
 2 Gerenciamento de requisitos: é o processo contínuo de análise e 
documentação dos requisitos do software. Ocorre durante o pro-
jeto de desenvolvimento de software e envolve os usuários-chave 
ou stakeholders.
 2 Planejamento de projeto: busca refinar e detalhar os objetivos do 
projeto e planejar o trabalho necessário para alcançá-los.
– 11 –
Qualidade de software
 2 Monitoramento e controle de projetos: consiste em medir e coletar 
informações sobre o desempenho do projeto, assim como informar 
os envolvidos.
 2 Gestão de fornecedores: é o processo de adoção de boas práticas e 
de controle e gestão dos fornecedores.
 2 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 desenvolvimento 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 processo de 
desenvolvimento de software definido e disciplinado é a melhoria de sua 
visibilidade, 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 conven-
cional, 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, agricultura, moradia e tantos outros que justifi-
cam a utilização de algum conhecimento científico específico. Ela traz bene-
fí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 
Qualidade e Usabilidade de Software
– 12 –
necessidades do usuário, usando, para isso, um processo definido e discipli-
nado, por meio da tecnologia existente.
Existem três conceitos muito importantes na engenharia de software, 
que se relacionam intrinsecamente:
 2 Processo: trata-se de um conjunto de passos ordenados usado para 
atingir um fim específico, sendo composto por atividades, méto-
dos, práticas e transformações.
 2 Projeto: é o que concretiza um processo.
 2 Produto: é o objetivo do processo.
Esses conceitos podem ser relacionados da seguinte maneira: um pro-
jeto tem um escopo 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 momento em que se percebe a necessidade de sua existên-
cia, 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 engenha-
ria 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 
– 13 –
Qualidade de software
software de acordo com uma situação específica, enquanto os requisitos não 
funcionais quantificam aspectos desse produto, como, por exemplo, desem-
penho, disponibilidade ou portabilidade.
Os requisitos precisam ser especificados em um documento, devendo-se 
detalhar e distinguir os explícitos e os normativos. Os requisitos explícitos são 
aqueles levantados por desenvolvedores com base nas informações dos usuários 
e os requisitos normativos são os provenientes 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 
documentados. Eles são chamados de requisitos implícitos e são totalmente 
indesejados, porém podem ser minimizados por meio de uma boa especifi-
caçã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 requisitos constantes no documento de especificação.A instabilidade onera o projeto de várias formas, 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 algum tipo de gestão, pois eles podem ser alterados mesmo à 
revelia do usuário. Isso constitui 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 atentos 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.
Qualidade e Usabilidade de Software
– 14 –
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 tam-
bém podem sofrer alteração, mas isso não é regra. O bom planejamento de 
projetos tenta equilibrar os componentes dos vértices 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, cha-
mada de controle de projetos, cujo objetivo é acompanhar o progresso dos pro-
jetos, 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 qualificados, 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 
desenvolvimento, a engenharia de software tem a disciplina de gestão de con-
figurações – gerência de configuraçã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 disponham de pessoal suficiente, um membro da equipe 
de desenvolvedores pode ser designado para essa função. Essa é uma disci-
plina em que é fortemente recomendado o uso de ferramentas automatizadas, 
devido ao grande volume de artefatos e de versões destes que são geradas 
durante todo o processo de desenvolvimento (WEBER, 2012).
– 15 –
Qualidade de software
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 software 
está sujeito. As disciplinas da engenharia de software que regem a garantia da 
qualidade dizem respeito ao impacto causado por esses erros.
1.2.1 Erros que devem ser evitados
A qualidade de um produto é definida pelo grau de conformidade com 
os seus requisitos e está diretamente relacionada à qualidade do processo uti-
lizado 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ân-
gulo 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 desenvolvimento. Eles são encontrados de diversas formas, como no 
desempenho aquém do desejado, nas funções que não são executadas correta-
mente 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 processos oficiais rígidos e burocráticos. Os mais comuns são 
(WEBER, 2012):
 2 desperdício de tempo antes do início do projeto;
 2 pressões por prazos otimistas e o não cumprimento destes por 
serem impossíveis;
Qualidade e Usabilidade de Software
– 16 –
 2 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;
 2 falha no método de gerir o projeto;
 2 pressa para começar a etapa de codificação;
 2 falha na subcontratação de serviços; e
 2 entrega do produto sem estar totalmente pronto ou testado.
Entre os requisitos e a codificação existe o projeto, presente em todas as 
fases do processo. Os defeitos de projeto são tão graves como os defeitos pro-
venientes de requisitos. Eles se caracterizam por dificuldade para utilização do 
software, desempenho ruim, defeitos aleató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 for-
mais 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 corri-
gir 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 desenvolvedores 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 desenvolvedores; 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 dependência em relação a determinadas 
– 17 –
Qualidade de software
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 oti-
mista de que muitos problemas podem ser resolvidos por meio de alta tecno-
logia, esquecendo-se de que para utilizá-la em profundidade é necessário trei-
namento e experiência. Assim, pode haver falha na análise para mudançade 
tecnologia e a substituição desta no meio de um projeto, falta de automação 
de atividades como as de gestão de configurações, ausência de ferramenta de 
modelagem e automação de atividades de testes.
1.2.2 Modelos de ciclo de vida
Para a existência de um processo de desenvolvimento de software, é pre-
ciso ter definido o seu modelo de ciclo de vida. Existem vários tipos de mode-
los, que se diferenciam principalmente pelo grau de controle aplicado sobre 
o processo em questão e sua visibilidade para o cliente no seu decorrer, como 
especificado a seguir.
 2 Codifica-Remenda: é o pior de todos os modelos de ciclo de vida 
aqui apresentados e, provavelmente, o mais utilizado. Com base em 
um problema existente, e não um problema modelado ou especifi-
cado, mas sim definido de uma forma qualquer, passa-se imediata-
mente à codificação. Os erros encontrados são corrigidos conforme 
a demanda, daí o termo remenda. Muitas vezes não existe um pro-
cesso definido ou, se existe, ele não é seguido, é impossível de ser 
gerido e, portanto, não se pode assumir compromissos confiáveis.
 2 Cascata: esse modelo de ciclo de vida tem a vantagem de apresen-
tar 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.
Qualidade e Usabilidade de Software
– 18 –
 2 Espiral: modelo de ciclo de vida em que um produto é desen-
volvido em diversas 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 desvantagem é que 
é difícil de ser gerido.
 2 Prototipagem evolutiva: utiliza o modelo de ciclo de vida em espi-
ral para construir o produto em protótipos, cobrindo progressiva-
mente os requisitos até a finalizaçã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.
 2 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 definidos. 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.
 2 Dirigido por prazo: um conjunto de requisitos essenciais é defi-
nido e entregue no prazo programado nesse modelo de ciclo de 
vida. O produto final é, na verdade, um produto parcial e o res-
tante é desenvolvido em processos posteriores, geralmente cha-
mados de manutenção.
 2 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 orga-
nizaçã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 en-
genharia de software, desde análise de requisitos e modelagem, até a programação e os testes.
– 19 –
Qualidade de software
1.2.3 Processos de desenvolvimento de software
Para que a organização possa ser considerada madura, ela precisa ter pro-
cessos de desenvolvimento formalmente definidos e que possam ser melhora-
dos 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, crono-
gramas e defeitos. O projeto é rigoroso tanto para concepção quanto para 
verificação e é realizado utilizando-se orientação a objetos, síntese 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 é dirigido a casos de uso, centrado na 
arquitetura, sendo iterativo e incremental, e usa a UML (Unified Modeling 
Language) como notação para os modelos que o compõe. Ele utiliza um 
modelo de ciclo de vida em espiral e é dividido em fases e fluxos de trabalho. 
Cada fase representa um marco gerencial 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 objetos 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 desenvolvedores e gerentes, clientes e usuá-
rios. Para os profissionais, é ruim porque o ambiente de trabalho é pouco 
Qualidade e Usabilidade de Software
– 20 –
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 pro-
duzir produtos melhores, com baixo custo e dentro do prazo estimado, e 
uma consequência inerente ao refinamento do processo é que os produtos 
são produzidos mais rapidamente. Por outro lado, se a organização erra defi-
nindo um processo rígido e burocrático, ele servirá apenas para formalizar 
uma situação e não será efetivamente usado na prática.
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, anali-
sadas 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 tecnologia e esta não tem retorno; sem processos de 
negócio mapeadose 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 problemas 
da produção recaem nos problemas gerados por um processo mal definido. 
As pessoas erram porque a informação chega até elas de forma incorreta, 
incompleta ou confusa, os recursos disponíveis não são adequados ou não são 
suficientes, o processo é mal definido ou difícil de seguir e falta treinamento 
da área de negócio nos processos e tecnologias utilizados (BENYON, 2011).
Infelizmente, a tendência é acreditar que os erros são do corpo técnico, 
por falta de comprometimento e treinamento, e não devido a processos 
– 21 –
Qualidade de software
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 sem-
pre 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 tecnolo-
gia 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 estima-
dos. 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 problemas 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 é conseguida da noite para o dia – ela é realizada em etapas, com 
marcos para pontos de controle bem definidos.
Assim, os processos de qualidade de software englobam fases que bus-
cam 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 
Qualidade e Usabilidade de Software
– 22 –
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 – 
Gestão da qualidade do software – 
conjunto de caracterísiticas de um sistema para atender os requisitos das partes interessadas.
direção e coordenação das atividade de qualidade de software
Melhoria da qualidade do software – processo de melhoria contínua
 2 Estabelecer os 
objetivos, pro-
cessos e recursos
Revisão dos 
processos de 
qualidade
 2 Cumprir os obje-
tivos 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 obje-
tivos, processos e recursos. Durante o desenvolvimento, o controle de quali-
dade 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, também precisa estar presente em todas as etapas anteriores, num ciclo 
de melhoria contínua.
– 23 –
Qualidade de software
1.3 Reflexões sobre a qualidade dos softwares
Para que o software tenha qualidade, ele deve ter usabilidade, funciona-
lidade, confiabilidade, manutenibilidade e desempenho. Para que essas carac-
terí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? Tem um bom desempenho? É fácil de usar? Pode 
ser corrigido com facilidade? Pode ser reutilizado em outro projeto?
O software deve satisfazer a necessidade do cliente em relação à fun-
cionalidade. 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 organizaçã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 com-
preensão, pois se for muito complicado exigirá vários treinamentos, 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 quali-
dade é aquele que estabelece o comportamento essencial de um sistema, o qual 
pode ser mantido, independentemente 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).
Qualidade e Usabilidade de Software
– 24 –
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 representam o domínio de uma aplicação e as estrutu-
ras organizacionais impostas a tais objetos, bem como a colaboração existente 
entre eles, ou seja, as conexões de mensagens que mostram a forma de comu-
nicação dos objetos com os demais (WEBER, 2012).
Os benefícios trazidos pela melhoria dos processos são muitos. Os prin-
cipais deles são (BENYON, 2011):
 2 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.
 2 Projeto: menos significativo que o anterior, mas que não deixa de 
produzir impacto no retorno de investimento.
 2 Garantia da qualidade: as atividades de garantia da qualidade – as 
que mais sofrem devido à pressa para entrega de um produto – dão 
retornoquando as necessidades de se refazer as etapas iniciais de 
um processo tendem a diminuir.
 2 Prevenção de defeitos: aqui vale o ditado popular “é melhor preve-
nir que remediar”. 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 sobre a importância do trabalho do analista 
de requisitos no desenvolvimento de um software e as princi-
pais dificuldades enfrentadas por esse profissional, cujo traba-
lho muitas vezes é desvalorizado ou incompreendido pelos 
outros colaboradores e até mesmo gestores da organização.
(FAGUNDES, 2011, p. 4-5)
– 25 –
Qualidade de software
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 requi-
sitos entram em ação para atrasar os projetos e que a docu-
mentaçã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 origem 
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 len-
dária mão invisível do processo.
Como resultado desses fatores reais para uma construção ade-
quada 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á questionamentos sobre a forma dos 
requisitos serem especificados ou se a proposta é adequada 
ou não, desviando o foco da atividade em voga no anda-
mento 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 aloca-
das corretamente para realizar a atividade de maneira eficaz 
e eficiente. A adoção de novos processos e técnicas não 
surtirão efeito sem essa revisão.
Qualidade e Usabilidade de Software
– 26 –
Atividades
1. Para se avaliar a qualidade do software, é fundamental medir e moni-
torar 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 recomendado?
Normas e padrões
Introdução
No Brasil, existe um corpo de normas nacionais baseadas 
em normas internacionais, que buscam garantir a proteção do con-
sumidor 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 partes interessadas em suas atividades, em dife-
rentes 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.
2
– 28 –
Qualidade e Usabilidade de Software
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 somas de dinheiro que os países desenvolvidos inves-
tem em organizações nacionais e internacionais de normalização são uma 
prova da importância dada à padronização (VALERIANO, 2005).
A ISO (International Organization for Standardization) desenvolve nor-
mas internacionais para diversos campos da tecnologia, exceto o eletrotécnico, 
coberto pela IEC (International Electrotechnical Comission), e as telecomu-
nicaçõ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 ordenaçã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 destina-
das a simplificar, unificar e especificar produtos (WAZLAWICK, 2013):
 2 Simplificar – procura manter apenas o estritamente necessário, seja 
em documentos, processos, orientações etc. As próprias normas 
também são simplificadas para serem facilmente assimiladas.
 2 Unificar – a ideia é criar um padrão para os produtos, utilizado em 
todas as partes do mundo para permitir trocas internacionais.
 2 Especificar – procura, por meio de uma linguagem clara e pre-
cisa, identificar os produtos, definindo-os, categorizando-os, 
catalogando-os e detalhando suas características, de modo a 
orientar o consumidor.
– 29 –
Normas e padrões
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 geral, possuem um centro de informação sobre nor-
mas. Os NSB têm um arquivo próprio de padronizações de organismos nacio-
nais, 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 organismo 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 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 desen-
volvimento de vários acordos na área, em especial o Acordo sobre Barreiras 
– 30 –
Qualidade e Usabilidade de Software
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ÇARAJR., 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 internacio-
nalmente pelos setores público e privado (CAIÇARA JR., 2007). A 
International Organization for Standardization, ou ISO, é uma organização 
não governamental, uma federação de organismos nacionais de normaliza-
ção de todas as regiões do mundo, incluindo países desenvolvidos e países 
em desenvolvimento (MARSHALL JR. et al., 2012).
Cada membro da ISO possui uma agência principal de normalização em 
seu próprio país. Os países-membros propõem as novas normas, envolvem-se 
em seu desenvolvimento e prestam apoio, divididos em grupos técnicos, em 
conjunto com a Secretaria Geral da ISO, localizada em Genebra, na Suíça 
(PRESSMAN; MAXIM, 2016).
O termo ISO tem raiz grega, significando igual, igualdade, o qual dá 
nome à organização, que também coincide com sua sigla. Esse é um signifi-
cado muito adequado a essa entidade, uma federação internacional indepen-
dente com o propósito de proporcionar sistemas uniformes de segurança, 
qualidade e eficiência do trabalho para trocas simples, entre países e regiões, 
de bens e serviços produzidos (PRESSMAN; MAXIM, 2016).
O ano de 1945 foi fundamental para a história da entidade, pois os 
delegados do Comitê Coordenador de Padronização das Nações Unidas 
(UNSCC) se reuniram em Nova Iorque para tentar criar uma organização 
de padrões, fundando as bases para a ISO (PRESSMAN; MAXIM, 2016). 
Ela foi estabelecida em 1946, com a participação de 64 delegados, de 25 
– 31 –
Normas e padrões
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 industrializaçã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 inicia-
ram-se suas operaçõ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 faci-
litar 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 desempenho, 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 especificamente 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 quali-
dade, e, se a conformidade for constatada, é emitido um certificado à empresa 
(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 internas e a as 
métricas externas – características e subcaracterísticas do produto de software.
– 32 –
Qualidade e Usabilidade 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 consiste em um modelo de garantia de quali-
dade 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 investigação foi chamado de Capability Maturity Model Software 
(SW-CMM), um modelo de maturidade de capacidades desenvolvido para 
processos relacionados com a produção e manutenção de sistemas de software, 
que teve sua versão 1.0 publicada em agosto de 1991 (MARSHALL JR. et al., 
2012). Posteriormente, como resultado do feedback gerado 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):
 2 Melhorar os processos relacionados com a produção e manutenção 
de software;
 2 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 usa-
dos em conjunto dentro de organizações, em prol de melhorias de processo 
(CAIÇARA JR., 2007), como modelos de desenvolvimento de software 
(SW-CMM), sistemas de engenharia (SECM) e desenvolvimento de produ-
tos 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):
– 33 –
Normas e padrões
 2 Uma maneira de integrar os elementos funcionais de uma organização;
 2 Um conjunto de melhores práticas com base em histórias de 
sucesso, comprovadas por organizações com experiência em práti-
cas de melhoria de processos;
 2 Uma ajuda para identificação de metas e prioridades para a melho-
ria dos processos, dependendo dos pontos fortes e fracos da organi-
zação, obtidos por um método de avaliação;
 2 Um suporte às empresas em atividades produtivas complexas para 
coordenar as suas atividades;
 2 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 internos 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 docu-
mentos também foram atualizados como resultado do feedback da comuni-
dade envolvida 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
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:
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 deavaliaçã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).
– 34 –
Qualidade e Usabilidade de Software
Figura 3 – Níveis de maturidade do CMMI.
1 - Inicial
Processo im-
previsível e sem 
controle
2 - Repetível
Processo disci-
plinado
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 defini-
dos 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 organização, e não do uso de proces-
sos comprovados. Apesar desse caos, as organizações pertencentes 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 abandonar processos em tempos de crise e a incapaci-
dade 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 planejados e executados em conformidade com as políticas 
– 35 –
Normas e padrões
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 esta-
belecidos 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, proce-
dimentos, ferramentas e métodos. O conjunto de processos padrão da orga-
nização é estabelecido e continuamente melhorado, de modo consistente para 
toda a empresa. Os projetos são estabelecidos 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 nor-
mas podem ser um pouco diferentes 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 proces-
sos são geralmente descritos de forma mais rigorosa do que no nível 2. Um 
processo definido apresenta claramente 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 
– 36 –
Qualidade e Usabilidade de Software
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 é con-
trolado usando-se técnicas estatísticas e quantitativas, e o processo é quantita-
tivamente previsível; por outro lado, no nível 3 o desempenho do processo é 
previsível apenas qualitativamente.
Nível 5: Otimizado
No nível 5 de maturidade, uma organização melhora continuamente 
seus processos com base no conhecimento das causas comuns de variação 
inerente a processos. Trata-se de melhorias contínuas, incrementais e tecnoló-
gicas. Os objetivos de melhoria de processos quantitativos para a organização 
são estabelecidos e continuamente revisados, sendo utilizados 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 variação e fornecer uma previsão estatística dos resultados. 
No entanto, os resultados podem ser insuficientes para alcançar as metas esta-
belecidas. No nível 5, a organização está focada nas causas comuns de variação 
de processo e modifica os procedimentos afetados para melhorar o desempenho 
deles e atingir os objetivos quantitativos de melhoria de processos.
– 37 –
Normas e padrões
O quadro a seguir explica resumidamente o que acontece em cada um 
desses níveis.
Quadro 1 – Características dos níveis de maturidade das organizações.
Nível Características
Inicial
 2 Basicamente nenhuma prática forma de gerenciamento de enge-
nharia 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 
desenvolver 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 expe-
riências 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.
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.
– 38 –
Qualidade e Usabilidade de Software
Nível Características
Gerenciado
 2 A organização estabelecemetas 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 anterior (CAIÇARA JR., 2007).
– 39 –
Normas e padrões
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:
 2 Nível 0 – Incompleto – um processo é chamado de incompleto 
quando um ou mais objetivos da área de processo não estão 
em conformidade.
 2 Nível 1 – Realizado – é chamado de feito ou realizado o processo 
que satisfaz todas as metas específicas da área de processo.
 2 Nível 2 – Manejado (produzido) – é designado processo de gestão 
quando o projeto apresenta a infraestrutura para suportá-lo. O pro-
cesso é planejado e executado de acordo com a política da empresa, 
envolvendo as partes interessadas, e emprega pessoas qualificadas 
– 40 –
Qualidade e Usabilidade de Software
que tenham recursos adequados para produzir saídas controladas. 
É monitorado, controlado, revisto e avaliado de acordo com sua 
descrição específica.
 2 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.
 2 Nível 4 – Manejado (gerenciado) quantitativamente – é contro-
lado usando-se técnicas quantitativas estatísticas e outras. Metas 
quantitativas para a qualidade e o desempenho do processo são 
estabelecidas e utilizadas como critérios para sua gestão.
 2 Nível 5 – Otimizado – otimização é a melhoria contínua do pro-
cesso, com base no entendimento de causas comuns de variação de 
processo. Esse processo é realizado 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 sistemático, também envolve uma graduação em estágios ou 
níveis. Para atingir determinado nível, a organização precisa ter uma infraes-
trutura 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 objeti-
vos 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
– 41 –
Normas e padrões
Área de processo Categoria Nível de maturidade
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.
– 42 –
Qualidade e Usabilidade de Software
2.3 Métricas de qualidade de software
As métricas de qualidade fornecem uma indicação de que o software 
está em conformidade com as exigências implícitas e explícitas dos clientes. 
O principal objetivo da engenharia de software é produzir com uma alta qua-
lidade. 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 englobam: 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:
 2 operação do produto (usá-lo);
 2 revisão do produto (alterando-o);
 2 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 responsável pelo desenvolvimento do software – identificar se ele 
atende os requisitos de qualidade pré-estabelecidos.
– 43 –
Normas e padrões
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:
 2 Exatidão: é o grau em que o software executa a sua função.
 2 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.
 2 Integridade: mede a capacidade de um sistema para resistir a ata-
ques (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 segurança. Ameaça é a probabilidade de que um ataque 
dê certo em determinado momento. Já a segurança é a probabili-
dade que o sistema tem de repelir um ataque de certo tipo.
 2 Facilidade de uso: é uma tentativa de quantificar o quão amigável 
pode ser o programa para o usuário.
2.3.3 Eliminação dos defeitos
É o entendimento dos principais defeitos presentes nos projetos de 
software – como erros na gestão, prazos curtos, erros de código –, com o obje-
tivo 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).
3 A documentação de software consiste em manuais gerais e técnicos ou mesmo relatórios que 
explicam o funcionamento do programa ou sistema e acompanham o produto, explicando ao 
cliente como utilizá-lo e suas características.
– 44 –
Qualidade e Usabilidade de Software
As métricas de qualidade, portanto, são fundamentais nos processos de 
desenvolvimento de softwares, pois auxiliam no monitoramento e no con-
trole 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 desenvolvimento 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 nor-
matizar e rever periodicamente os conceitos e métodos uti-
lizados 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 lici-
tação de requisitos, análise e designer do projeto, implemen-
taçã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 acha-
rem que o procedimento de certificação de uma empresa de 
tecnologia é muito diferente das empresas industriais, os pro-
fissionais vêm mostrando que não. As fábricas de softwares 
são os grandes exemplos disso, pois as mesmas têm se preo-
cupado com a focalização nos clientes, abordagem dos pro-
cessos, envolvimento dos stakeholders, comprometimento da 
– 45 –
Normas e padrões
liderança, relação com os fornecedores e a melhoria contínua 
dos processos.
Muitos clientes que prezam por mais confiabilidade nos con-
tratados buscam empresas que sejam certificadas na área. Hoje 
são diversas as certificações, onde cada uma atende necessi-
dades específicas do negócio.
As mais conhecidas da área de tecnologia são: CMMI e 
MPS.BR. Para se certificar, a empresa precisa atender algumas 
exigências e demonstrar maturidade nos processos de produ-
ção. Essas certificações além de darem um peso maior ao cur-
rículo da empresa, atraem clientes que buscam por parceiros 
com maior qualidade nos processos.
A área da qualidade se responsabiliza pela garantia do cumpri-
mento dos processos e pela melhoria dos mesmos — melho-
ria contínua. O produto é visto como consequência da exe-
cuçã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?
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 planeja-
mento e recursos. Os líderes do projeto utilizam os requisitos de 
base para estimar os recursos necessários à criação de um software.
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 desen-
volvido 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).
3
Qualidade e Usabilidade de Software
– 48 –
Assim, os requisitos são a base para a decisão sobre como um produto 
será executado, 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.
3.1 Processos de negócio
As empresas se diferenciam entre si pela sua capacidade de organização 
e de processos de negócio. Cada empresa utiliza um procedimento especí-
fico para chegar ao resultado 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 ativida-
des que são executadas de acordo com certas regras relacionadas a determina-
dos 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 necessi-
dade, 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 desenvol-
vê-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 detalhada dos requisitos, por meio de uma entrevista com o cliente/
usuário. Analistas e engenheiros comunicam-se com os clientes/usuários para 
conhecer as ideias destes sobre os resultados que o software deve fornecer e 
quais as características que devem ser incluídas (VALERIANO, 2005).
– 49 –
Influência dos requisitos na qualidade do software
3.1.1 Requisitos de software
Como visto no Capítulo 1, os requisitos incluem necessidades quantificadas 
e documentadas, 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 resolver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que deve ser atendida por uma 
solução para satisfazer 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 pos-
suída por um sistema, produto, serviço, resultado ou compo-
nente para satisfazer um contrato, padrão, especificação ou outro 
documentoformalmente imposto.
Os requisitos devem apresentar uma série de características, tanto indivi-
dualmente como em grupos. Estas são as características mais importantes dos 
requisitos de software (VALERIANO, 2005):
 2 Necessário – Um requisito deve ser necessário. A sua omissão causa 
uma deficiência no sistema, afetando a sua capacidade, suas caracte-
rí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.
 2 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 consul-
tá-lo, sejam os clientes ou outros desenvolvedores, no futuro. Um 
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 
lucrativos, dedicada ao avanço da tecnologia no mundo.
Qualidade e Usabilidade de Software
– 50 –
documento muito extenso acaba dificultando o processo, pois sua 
leitura e interpretação demandam mais tempo.
 2 Completo – Um requisito é completo quando não necessita de 
mais detalhes na sua formulação, ou seja, a informação disponibi-
lizada é suficiente para sua compreensão e para o desenvolvimento 
do software.
 2 Consistente – Os dados apresentados devem ser confiáveis e segu-
ros, 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.
 2 Inequívoco – Os requisitos devem ser claros e não permitir mais 
de uma interpretação (não podem ser ambíguos), pois isso poderia 
acarretar diversos erros no sistema.
 2 Verificável – Um requisito é verificável quando ele é palpável, pode 
ser construí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 funciona-
lidade do objetivo (target) do sistema, de modo a comunicar expectativas dos 
consumidores de produtos de software. Podem ser óbvios ou ocultos, conhe-
cidos ou desconhecidos, esperados ou inesperados (VALERIANO, 2005). 
Isso significa que nem sempre o cliente/usuário tem claros os requisitos, daí 
a necessidade de o gestor do projeto, juntamente com os analistas, orientar 
o cliente/usuário, de modo a conseguir informações mais completas sobre o 
produto que vão desenvolver.
Para expressar os requisitos do software, as sentenças devem ser claras, 
exprimindo objetivamente a ação a ser realizada. 
O exemplo a seguir, apresentado por Vazquez e Simões (2016), demons-
tra 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. 
– 51 –
Influência dos requisitos na qualidade do software
No primeiro caso, o requisito não foi especificado adequadamente, 
visto que não há uma caracterização da ação principal a ser realizada, 
incluindo cláusulas adicionais, em um único texto:
Identificador: RF001 Requisito: Controle de Portaria
Para realizar o controle de entrada e saída na portaria, deve ser realizado o cadas-
tro 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 dife-
rentes 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 garante que os procedimentos sejam seguidos corretamente.
Qualidade e Usabilidade de Software
– 52 –
Desse modo, a engenharia de requisitos é responsável por documentar 
os requisitos, de acordo com as exigências do cliente/usuário, como apresen-
tado 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 é desenvolver 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 identificar e entender o que ele necessita e na obtenção de um acordo 
acerca da solução que será entregue. Assim, ela descreve e integra tarefas, técni-
cas, 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.
– 53 –
Influência dos requisitos na qualidade do software
Desse modo, a engenharia de requisitos contempla uma das partes do 
estudo da engenharia 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 desenvolvimento, 
fazendo a interação entre eles.
O desenvolvimento dos requisitos geralmente passa pelas seguintes fases 
(MARSHALL JR. et al., 2012):
 2 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.
 2 Avaliação e negociação – processo de avaliação e negociação de 
melhorias com o cliente ou stakeholder.
 2 Especificação – processo que tem como objetivo obter produtos de 
software de melhor qualidade, que satisfaçam às reais necessidades 
dos clientes dentro de prazo e orçamento adequados.
 2 Validação – processo que tem como objetivo a validação da con-
sistência e do contexto dos requisitos levantados no processo 
de identificação.
 2 Evolução – processo em que se compreende a situação inicial do 
problema, os requisitos iniciais, o entendimento do problema 
modificado e os requisitos que são alterados ao longo do tempo 
do projeto.
 2 Princípios de especificação – processo de representação dos requi-
sitosdo cliente, especificando a funcionalidade da implemen-
tação, identificando o comportamento desejado do sistema e o 
modo pelo qual outros componentes do sistema interagem com 
o software.
Essas fases não seguem com rigor essa ordem e uma mesma fase pode se 
repetir algumas vezes durante o projeto, mas todas estão presentes quando se 
trata de desenvolvimento de requisitos de software.
Qualidade e Usabilidade de Software
– 54 –
3.2 Os requisitos e a comunicação
Os requisitos são o ponto de concordância entre o cliente e o projeto 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 pro-
duto do sistema (PFLEEGER, 2004).
A especificação de requisitos de software é a atividade em que o docu-
mento é gerado com um nome específico, contendo uma descrição com-
pleta das necessidades e capacidades do sistema que será desenvolvido. Esse 
documento descreve o escopo4 do sistema e como será 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 esclare-
cer 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 corrigidas 
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 satis-
fação do cliente/usuário é maior. Portanto, são objetivos da especificação de 
requisitos (VASQUEZ; SIMÕES, 2016):
4 Escopo é a descrição de tudo o que é preciso ser feito para se alcançar os objetivos do projeto, 
incluindo recursos e funções desejados.
– 55 –
Influência dos requisitos na qualidade do software
 2 documentar de forma correta e fidedigna todas as necessidades do 
cliente/usuário;
 2 obter aprovação (aceite) sobre tudo o que está sendo proposto para 
se entregar em termos de produto;
 2 ajudar a equipe de desenvolvimento a compreender exatamente o 
que os clientes/usuários desejam;
 2 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:
 2 Visão geral – em que se apresenta os objetivos do projeto, 
as partes interessadas e o escopo preliminar com as funções 
descritas brevemente.
 2 Glossário – definição dos termos técnicos e de siglas usados 
no documento.
 2 Modelos de sistema – em que se mostra o relacionamento entre os 
componentes do sistema.
 2 Lista de requisitos funcionais – em que se descreve as tarefas exe-
cutadas pelo sistema e as interfaces externas do software.
	 Os requisitos funcionais “definem as funcionalidades e o compor-
tamento 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)”.
 2 Lista de requisitos não funcionais – em que se descreve 
as restrições impostas sobre o software, relacionando-as aos 
requisitos funcionais.
Qualidade e Usabilidade de Software
– 56 –
	 Os requisitos não funcionais “dizem respeito às características 
e padrões de qualidade 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 quando se propõe a 
imprimir um relatório em até cinco segundos (desempenho).
 2 Especificação detalhada de requisitos – detalhamento dos requi-
sitos funcionais.
Todos os requisitos de hardware e software, diagramas, modelos e quais-
quer outros sistemas 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. É impor-
tante reforçar que a especificação de requisitos é o resultado final das ativida-
des 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 fun-
cionais com base nesse documento. Para o gerente de projeto, os requisitos ser-
vem como referência e controle da evolução do sistema (PFLEEGER, 2004).
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 fon-
tes; 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 manusear; e eles 
nunca são iguais – alguns são mais difíceis, mais arriscados, mais importantes 
ou mais estáveis do que outros.
– 57 –
Influência dos requisitos na qualidade do software
Existem, ainda, dificuldades para quantificá-los, uma vez que cada 
conjunto de requisitos é 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 longo 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 documentados. 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 semsurpresas 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 solicitações feitas pelo cliente/usuário e prevejam todos 
os empecilhos e dificuldades que possam vir a surgir durante o desenvol-
vimento do software. O texto da especificação precisa ter o nível de deta-
lhamento 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 tecnologia. 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 necessá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 necessidades. 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.
Qualidade e Usabilidade de Software
– 58 –
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.
3.3 Qualidade de requisitos de software
Os requisitos de software são a base a partir da qual a qualidade é medida. 
A falta de conformidade5 com os requisitos significa falta de qualidade.
A ISO 9001:2008 especifica requisitos para um sistema de gestão da 
qualidade, quando uma organização (CYBIS et al., 2015):
a) precisa demonstrar sua capacidade de fornecer de forma consis-
tente 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
Disponibili-
zação
Esforço 
para obter 
qualidade
Tempo
Fonte: BARTIÉ, 2002, p. 25.
5 Segundo as ABNT NBR ISO/IEC 17000:2005, conformidade é a “demonstração de que os 
requisitos 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).
– 59 –
Influência dos requisitos na qualidade do software
Embora a qualidade possa ser avaliada durante a fase de testes, é um 
equívoco concentrar 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
Disponibili-
zação
Tempo
Processo de garantia da qualidade de software
Fonte: BARTIÉ, 2002, p. 27.
Qualidade de software é a conformidade a requisitos funcionais e de 
desempenho explicitamente declarados, a padrões de desenvolvimento clara-
mente planejados e comunicados, à especificação e documentação dos requi-
sitos e às características implícitas que são esperadas de todo software desen-
volvido 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 pro-
cesso de descoberta 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 relativa-
mente simples, 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.
Qualidade e Usabilidade de Software
– 60 –
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 complexos com os detalhamentos simples e concisos de documen-
tos, 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 arquite-
tura 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 desenvolvi-
mento 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 quali-
dade 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.
Por exemplo, ao se identificar um risco à qualidade do software (em 
relação à confiabilidade), como a indisponibilidade do sistema ao usuário, é 
possível dividir a análise em subcategorias, como mostra o Quadro 1.
– 61 –
Influência dos requisitos na qualidade do software
Quadro 1 – Subcategorias do requisito confiabilidade.
Risco R001 – indisponibilidade do sistema para o usuário
Características Subcaracterísticas Objetivo Questão Métrica
ConfiabilidadeMaturidade
Avaliar a capaci-
dade 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 man-
tidos sob controle 
para evitar falhas 
críticas e sérias?
Número de ocorrências 
de falhas sérias e críticas 
evitadas conforme 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 casos 
em que o sistema entrou 
em recuperação
Fonte: WAZLAWICK, 2013, p. 248.
Qualidade e Usabilidade de Software
– 62 –
Ampliando seus conhecimentos
Problemas de comunicação afetam o desenvolvimento de 
qualquer projeto. O texto a seguir é uma metáfora de como 
esses problemas podem acarretar interpretações equivo-
cadas 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 produto de software, comparando-a com a instalação de 
um balanço em uma árvore. Trata-se de uma anedota conhe-
cida entre programadores e analistas 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 minutos 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 pes-
soal, 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 modificações para reduzir o cronograma inicial 
e cortar os custos de implementaçã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.
– 63 –
Influência dos requisitos na qualidade do software
Finalmente, o projeto completo é entregue ao programador. 
Ao analisar as especificações, ele descobre estar diante de um 
software que lhe custará 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 pro-
gramas. 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.
Uma vez que cada pessoa envolvida na construção do 
software contribuiu efetuando uma “pequena” modificação, a 
cada estágio a especificaçã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 comu-
nicaçã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 representa 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.
Qualidade e Usabilidade de Software
– 64 –
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 oralmente, há muita possibilidade de que 
sejam compreendidas de diversas maneiras por diferentes indi-
ví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 con-
ta 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 obter qualidade no processo de desenvolvimento de 
um software?
Figura – Ciclo de desenvolvimento no qual a qualidade se resume a testes 
de sottware.
Modelo de 
negócios Requisitos
Análise e 
modelagem
Implemen-
tação
Testes de 
software
Disponibili-
zação
Esforço 
para obter 
qualidade
Tempo
Fonte: BARTIÉ, 2002, p. 25.
Processo de 
desenvolvimento 
de software
Introdução
Desenvolvimento de software contempla todo o processo 
de programação de computadores, documentação, testes, correção 
de bugs1 e de erros envolvidos na criação e na manutenção de aplica-
tivos e estruturas, resultando em um produto de software, que deve 
seguir as especificações documentadas.
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 defeituoso. (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 processamen-
to 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).
4
Qualidade e usabilidade de software
– 66 –
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.
Portanto, esse processo pode incluir pesquisa, desenvolvimento, prototi-
pagem2, modificação, reutilização, reengenharia, manutenção e demais ativi-
dades que resultem na produçã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 espe-
cífico. Assim, supre uma necessidade 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 empresá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 biblio-
grá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).
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 melhor determinar os requerimentos dele.” (REZENDE, 2005, p. 134).
– 67 –
Processo de desenvolvimento de software
O ciclo de desenvolvimento apresentado por Yourdon (1989 apud 
REZENDE, 2005, p. 42) é dividido em etapas, a fim de projetar e desenvol-
ver um produto de software de forma 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; insta-
lação. Essas etapas são apresentadas a seguir.
 2 Estudo de viabilidade – identifica as deficiências atuais, estabelece 
objetivos do novo sistema; gera cenários aceitáveis; prepara encar-
gos de projeto.
 2 Análise de sistemas – desenvolve o modelo ambiental; desenvolve 
o modelo comportamental; estabelece os limites homem-máquina; 
executa a análise custo-benefício; seleciona opção; restringe o sis-
tema; faz a especificação do pacote.
 2 Projeto – aloca especificações para os processadores; aloca especi-
ficações às tarefas; deriva o diagrama estrutural; avalia o diagrama 
estrutural; projeta módulos; projeta banco de dados; faz o empaco-
tamento do projeto.
 2 Implementação – soluciona o próximo módulo; codifica o módulo; 
testa o esqueleto do sistema.
 2 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.
 2 Garantia da qualidade – faz o teste final ou teste de aceite, compa-
rando o produto ao projeto de implementação.
 2 Descrição dos procedimentos – faz descrições das atividades opera-
cionais do cliente ou usuário.
 2 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.
Qualidade e usabilidade de software
– 68 –
 2 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 literatura e se diferenciam pelo grau de controle aplicado sobre 
o processo e por sua visibilidade 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 desen-
volvidos seguindo 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.
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.
– 69 –
Processo de desenvolvimento de software
Ainda segundo Shach (2010), esse ciclo de vida até pode vir a funcionar 
bem em programas menores e mais simples, mas é inviável para programas 
maiores, pois seu custo e seu tempo de desenvolvimento aumentam conside-
ravelmente, além de exaurir a equipe e o cliente em testes sem fim.
Outro problema apontado pelo autor é que a falta de especificações atra-
palha na manutenção do software depois de pronto e entregue ao cliente. 
Embora esse modelo seja considerado 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; contudo, basicamente é um modelo 
pouco flexível, com muitas restrições. Isso porque se caracteriza por progre-
dir de forma sequencial entre uma fase e a seguinte, e essa sequencialidade 
acaba causando diversos problemas ao desenvolvimento do software e afe-
tando sua qualidade.
Um ponto crítico referente ao modelo cascata é que nenhuma fase é 
terminada até que a documentação para essa fase tenha sido comple-
tada 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 tiverem de ser modificado como 
consequência de se seguir uma volta de realimentação, essa fase ante-
rior é 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 
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.
Qualidade e usabilidade de software
– 70 –
do projeto e a manutenção 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 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.
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 pro-
cesso flui de cima para baixo, como uma cascata, e o progresso de uma fase 
para a próxima se dá de forma sequencial. 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 
– 71 –
Processo de desenvolvimento de software
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 apresentadasa seguir:
 2 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. Esta etapa pode ser vista como a etapa de 
concepção de um produto ou software.
 2 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.
 2 Implementação – é a etapa em que são criados os programas.
 2 Verificação – é a etapa de testes do sistema. Após a codificação con-
cluí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.
 2 Produção – etapa de aprovação para que o sistema entre em pro-
duçã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.
Apesar de todos os seus problemas, o modelo cascata foi empre-
gado durante muitos anos. Atualmente, no entanto, tem sido pouco uti-
lizado devido à complexidade cada vez maior dos produtos desenvolvidos 
(SCHACH, 2010).
Qualidade e usabilidade de software
– 72 –
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 fun-
damental 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 evolucioná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.
– 73 –
Processo de desenvolvimento de software
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 desvanta-
gem é que ele é mais difícil de ser gerido (WAZLAWICK, 2003). A Figura 4 
apresenta um exemplo de ciclo de vida em espiral:
Figura 4 – Modelo em espiral.
1. Determinar objetivos 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 cor-
responde à 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ótipos 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 inter-
face de usuário e algoritmos, devendo ser feita a verificação correta. Na fase 4, 
Qualidade e usabilidade de software
– 74 –
de planejar a próxima iteração, estão as revisões das etapas anteriores e o pla-
nejamento da próxima fase. Nessa etapa, dependendo dos resultados obtidos 
nas fases anteriores, pode-se optar por seguir o desenvolvimento no modelo 
cascata, por exemplo, ou optar pela construção de novos protótipos.
Cada circuito em volta da espiral pode representar uma iteração, como 
explicam Pressman e Maxim (2016, p. 48):
O primeiro circuito em volta da espiral pode resultar no desenvolvi-
mento de uma especificação de produto; passagens subsequentes em 
torno da espiral podem ser usada para desenvolver um protótipo e, 
então, progressivamente, versões cada vez mais sofisticadas do soft-
ware. Cada passagem pela região de planejamento resulta em ajus-
tes 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 desenvolvi-
mento de softwares, pois o software evolui aos poucos e os riscos são avalia-
dos a cada nível evolucionário. A prototipação pode ser aplicada em qual-
quer estágio, reduzindo os riscos e solucionando os problemas à medida que 
eles surgem.
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 finalização do produto. Sua vantagem é que possui visibi-
lidade, permitindo a verificação antecipada do produto final e a correção dos 
problemas detectados. Além disso, apresenta alta flexibilidade, por permi-
tir ajustes durante o desenvolvimento do produto. Como desvantagens, esse 
4 Segundo o Dicionário de informática e internet, prototipação consiste na “criação de um 
modelo funcional [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).
– 75 –
Processo de desenvolvimento de software
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, entrega 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 neces-
sita. O protótipo construído ajuda tanto o cliente como a equipe de desen-
volvimento a entender melhor o produto que 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.
Qualidade e usabilidade desoftware
– 76 –
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 estru-
tura 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 recebido, garantindo mais agilidade e qualidade ao 
produto. Segue-se o mesmo ciclo da prototipagem 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 à orga-
nização escolher o melhor modelo para desenvolver um projeto, de acordo 
com as necessidades do cliente/usuário e a capacidade de produção da orga-
nizaçã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 orga-
nizaçã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 qua-
lidade, 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 caracteri-
zam e determinam a sua utilidade e existência. Qualidade é sinônimo de 
eficiência, flexibilidade, precisão, confiabilidade, facilidade de manutenção, 
– 77 –
Processo de desenvolvimento de software
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 demonstrado na Figura 6.
Figura 6 – Software com qualidade.
Usuário
Requisitos 
atendidos
Padrões 
atendidosSoftware com qualidade
Desenvolvedor Organização
Processo de 
desenvolvimento
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, desen-
volvedor e organização devem, em conjunto, traçar os requisitos para o 
desenvolvimento do software, 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 sis-
temáticas e planejadas 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 qua-
lidade. Esses testes foram inicialmente desenvolvidos pela indústria militar 
Qualidade e usabilidade de software
– 78 –
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 qualidade; engenharia de software; revisões técnicas formais aplica-
das 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 neces-
sários sobre a qualidade do produto, por isso a aquisição da qualidade deve 
cumprir sua visão e objetivo (CAIÇARA JR., 2007).
Assim, o SQA dá visibilidade aos processos utilizados pelo projeto e os 
produtos que ele gera. Para Pressman e Maxim (2016), entre os objetivos da 
SQA, estão: realizar atividades de planejamento de garantia de qualidade; 
avaliar e auditar os produtos e atividades para verificar sua conformidade 
com os procedimentos e as normas; e fornecer os resultados dessas 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 objetivos 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).
4.2.1 Vantagens do SQA
Um plano SQA pode tomar uma série de caminhos, testando-se diferen-
tes 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 melhorados, e um bom relaciona-
mento com eles, além do desenvolvimento do software com custo reduzido e 
sem comprometer a qualidade.
– 79 –
Processo de desenvolvimento de software
Sobre a metodologia do SQA, ressalta-se que o teste de software é consi-
derado 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
 2 O teste de validação é realizado para checar se há algum erro.
 2 Compara a saída de um uso específico com um sistema de 
dados previamente criado com os mesmos parâmetros.
 2 Usuários que não estão familiarizados com o software for-
necem 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 consiste 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 seguin-
tes questionamentos (PFLEEGER, 2004):
 2 Funcionalidade – O produto satisfaz as necessidades do usuário?
 2 Confiabilidade – É imune a falhas?
Qualidade e usabilidade de software
– 80 –
 2 Usabilidade – É fácil de usar?
 2 Eficiência – É rápido e simples?
 2 Manutenibilidade – É fácil de modificar?
 2 Portabilidade – É fácil de usar em outro ambiente?
A ISO/IEC 9126 define essas características principais da qualidade do 
produto da seguinte 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 con-
siderado funcional.
Usabilidade – refere-se ao conjunto de atributosque evidenciam o 
esforço necessário para se poder usar o software, assim como o julgamento 
individual desse uso, por um conjunto 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 capa-
cidade 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 possibi-
litar 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.
– 81 –
Processo de desenvolvimento de software
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 decisões em projetos da área, a qual se refere a métodos de enge-
nharia de software. Essa abordagem 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 cola-
boraçã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 docu-
mentaçã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).
A metodologia ágil engloba, segundo Sommerville (2011):
 2 Valorização das pessoas e suas interações sobre processos e ferra-
mentas – processos de qualidade com bons relacionamentos trazem 
bons resultados.
 2 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 contribui ao valor direto do produto/serviço.
 2 Taxa de colaboração com o cliente sobre negociação de contrato 
– embora sejam necessá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 
Qualidade e usabilidade de software
– 82 –
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-vin-
das, 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 medida de progresso, devendo-se enfatizar o foco no grau de 
acabamento e no tempo de conclusão previsto.
As características básicas de projetos geridos com metodologias ágeis são 
as seguintes (SOMMERVILLE, 2011):
 2 Incerteza – indica a necessidade estratégica da previsão de riscos no 
desenvolvimento.
 2 Equipes auto-organizadas – não existem funções especializadas na equipe.
 2 Autonomia – liberdade para a tomada de decisão.
 2 Autoaperfeiçoamento – periodicamente, o produto tem de ser 
desenvolvido e avaliado.
 2 Autoenriquecimento – conhecimento e transferência de conhecimento.
 2 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 disso, as 
fases tradicionais, realizadas por pessoas diferentes, não promovem 
o trabalho em equipe e podem gerar mais desvantagens do que 
vantagens (por exemplo, um atraso de fase afeta todo o projeto).
 2 Controle sutil – pontos de controle local para monitorar adequa-
damente sem limitar a liberdade e a criatividade da equipe.
Além disso, recomenda-se, nesse processo: avaliar o ambiente de traba-
lho, sendo fundamental escolher pessoas que não entrem em conflito entre si; 
compreender os erros como pontos de melhoria e aprendizado; e melhorar a 
– 83 –
Processo de desenvolvimento de software
interação entre a equipe e a organização, para que possam atender às neces-
sidades do projeto. Também é essencial a difusão e transferência de conhe-
cimentos, 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 imprevisíveis, no quais não é possível prever tudo que irá acon-
tecer. 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á desenvolvido, com a apresentação das características definidas pelo 
cliente, das premissas e restrições. Em seguida, é criado o product backlog, a 
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.
Qualidade e usabilidade de software
– 84 –
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 ite-
ração, chamada de Sprint (MARÇAL et al., 2007).
Na execução do Sprint, diariamente a equipe faz reuniões de 15 minu-
tos (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 (representante 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.
4.3.2 Validações e indicadores
Para a determinação da qualidade do software a partir da perspectiva de 
produto acabado, é necessária a avaliação de um conjunto de indicadores que 
respondam a diferentes critérios e fatores consistentes com a estruturada ISO 
9126 – norma padrão que permite 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 apli-
cabilidade, eficiência e relevância.
Para atender a esses itens, os indicadores devem ser testados e devem 
prezar pela seguranç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 indi-
cadores 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 indi-
cadores correspondentes 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.
– 85 –
Processo de desenvolvimento de software
Esse indicador deve corresponder aos critérios de (PFLEEGER, 2004):
 2 adequação – o conjunto de indicadores para assegurar que o con-
teúdo é adequado;
 2 precisão, interoperabilidade6 e segurança – sua definição está em 
consonância com a função adequada que executa;
 2 compliance – o conjunto de indicadores para assegurar que o soft-
ware está descrito de acordo com padrões estabelecidos.
A confiabilidade é definida como um grupo de critérios e indicado-
res correspondentes relacionados com a capacidade de manter o seu nível 
de desempenho sob condições estabelecidas por um período determinado 
(SOMMERVILLE, 2011). Por exemplo, um sistema deve ser seguro e fun-
cionar no tempo requerido. Precisa estar em concordância com os seguintes 
critérios (PFLEEGER, 2004):
 2 maturidade – deve ser compreendido como a capacidade de se 
repetir uma série de resultados de maneira previsível;
 2 capacidade de recuperação – o conjunto de indicadores para asse-
gurar que as propriedades específicas do software, caso sejam perdi-
das, possam ser recuperadas;
 2 tolerância a falhas – o software precisa ser projetado para suportar 
erros e falhas, e mecanismos de restauração devem estar disponíveis.
A usabilidade é o conjunto de critérios e indicadores relacionados com 
o esforço necessário para o uso do software e a avaliação individual de tal 
utilização, por um grupo declarado ou implícito de usuários – como, por 
exemplo, a facilidade de usuários utilizarem dados do sistema por intermédio 
de atalhos. A usabilidade corresponde aos critérios de (PFLEEGER, 2004):
 2 aprendizagem – o conjunto de indicadores para assegurar a apren-
dizagem para o sistema a que se destina;
6 “Uma vez conseguida a conectividade, a interoperabilidade refere-se aos recursos lógicos que 
permitem a comunicação entre programas diferentes (ou com configurações diferentes) e, tam-
bém, a manipulação dos dados, formatos e características diversas.” (SAWAYA, 1999, p. 242).
Qualidade e usabilidade de software
– 86 –
 2 compreensibilidade – o conjunto de indicadores para assegurar a 
compreensão dos elementos que o compõem;
 2 operacionalidade – definida de acordo com a função correta que 
ele executa;
 2 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 indica-
dores correspondentes 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:
 2 comportamento ao longo do tempo – definido em correspondên-
cia com a função adequada que o produto executa;
 2 comportamento do recurso – o conjunto de indicadores para asse-
gurar o fator de acordo com a portabilidade, ou seja, a capacidade 
de ser transferido de uma plataforma para outra.
Como observado, métodos, validações e indicadores devem ser adota-
dos 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 vali-
daçõ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.
– 87 –
Processo de desenvolvimento de software
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 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 resulta-
dos. Funciona mesmo.
[...]
O motivo por que ela funciona é simples. Eu olhei a forma 
como as pessoas 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 diferentes? 
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 trabalha junto para avançar com a bola no 
campo. Alinhamento cuidadoso, unidade de propósito, cla-
reza 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, 
Qualidade e usabilidade de software
– 88 –
de que forma o criaram. A estrutura do Scrum busca aprovei-
tar a maneira como as equipes realmente trabalham, 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 aprimorar 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. [...]
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?
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 elaboradocom qualidade 
e dentro do prazo e do custo estipulados. Essa gestão afeta dire-
tamente a qualidade do desenvolvimento do processo e, indireta-
mente, a qualidade do produto.
5
Qualidade e usabilidade de software
– 90 –
Um gerenciamento de qualidade de software inclui o Software Quality 
Assurance (SQA), ou Garantia de Qualidade de Software, que visa desen-
volver procedimentos e padrões em nível organizacional. Assim, são realiza-
dos o Planejamento da Qualidade, de modo a selecionar os procedimentos 
e padrões aplicáveis a um projeto específico e modificá-los conforme neces-
sá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.
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 consumido-
res, em termos das dimensões de qualidade de serviço (PARASURAMAN; 
ZEITHAML; BERRY, 2005).
5.1.1 Dimensões da qualidade do processo
Parasuraman, Zeithaml e Berry (2005) argumentam que a qualidade 
percebida é uma função da diferença entre expectativa e desempenho ao 
longo de um sistema estabelecido de dimensões de qualidade. De acordo com 
Johnston (1995), é necessário reconhecer os determinantes 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 equipamentos e do material de comunicação.
2. Confiabilidade, que é a capacidade de executar o serviço prome-
tido com precisão e formalidade. No que se refere a essa dimensão, 
– 91 –
Gerência da qualidade de software
Boulding et al. (1993) argumentam 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 manipulador da percepção geral de serviço ao cliente.
3. Sensibilidade, definida como a vontade de ajudar os clien-
tes e fornecer um serviço rapidamente. Sobre essa dimensão, 
Parasuraman, Zeithaml e Berry (2005) relatam que ter sensibi-
lidade 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 fun-
cionários e sua capacidade de inspirar confiança.
5. Empatia, que envolve os cuidados e o atendimento individuali-
zado que a empresa oferece aos seus clientes.
Por meio dessas dimensões, é possível compreender os trade-offs1 viven-
ciados pelos clientes, o que pode ajudar a construir uma vantagem competi-
tiva em relação à concorrência.
5.1.2 Dimensões da qualidade segundo Garvin
David Garvin (2015) propôs oito diferentes dimensões da qualidade: 
desempenho, recursos, confiabilidade, conformidade, durabilidade, faci-
lidade de manuseamento, estética e qualidade percebida (Figura 1). Para 
o autor, algumas dessas dimensões se reforçam mutuamente, enquanto 
outras não.
1 Trade-off é um termo em inglês que significa o ato de escolha de um produto ou serviço em 
detrimento de outro. Muitas vezes é traduzido como “perde-e-ganha”, pois implica um conflito 
de escolha: quem escolhe deve conhecer os pontos positivos e os negativos de um produto ou 
serviço para escolher aquele que atende melhor às suas necessidades. Ele precisa avaliar bem 
cada um para fazer a melhor escolha, pois deixará de usufruir dos benefícios do produto ou 
serviço que não foi escolhido.
Qualidade e usabilidade de software
– 92 –
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 dimensão de qualidade abrange atributos mensuráveis, de 
modo que as empresas geralmente podem ser classificadas objetivamente em 
aspectos individuais de desempenho.
– 93 –
Gerência da qualidade de software
O desempenho é muitas vezes uma fonte de desentendimento entre 
clientes e fornecedores, particularmente quando o que se entrega não está 
adequadamente definido dentro das especificações. O desempenho de um 
produto muitas vezes influencia a rentabilidade ou a reputação da empresa. 
Por isso, muitos contratos ou especificações também incluem os danos rela-
cionados ao desempenho inadequado.
Alguns padrões de desempenho são baseados em preferências subjetivas, 
mas as preferê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 constante 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 caracte-
rísticas, que muitas vezes são um aspecto 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 progra-
mas e procedimentos.
Os programas podem ser compreendidos como um conjunto de ins-
truções que possibilitam 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.
Como exemplos de recursos do software, tem-se:
 2 softwares aplicativos – são programas de computador criados para 
ajudar os usuários a desempenhar tarefas específicas;
 2 softwares de sistema – programas de sistema operacional que con-
trolam e apoiam todas as operações de um sistema de computador;
 2 procedimentos – todas as orientações que o usuário final utiliza 
para navegar no sistema operacional.
Qualidade e usabilidade de software
– 94 –
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 sistema 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 apresentamaior confiabilidade? O sistema 1 é mais 
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 especifi-
cados. A dimensã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 qua-
lidades 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 abordagem é que há pouco interesse 
em saber se as especificações foram cumpridas exatamente como determi-
nado, enquanto os limites de tolerância forem satisfeitos.
– 95 –
Gerência da qualidade de software
As medidas de conformidade normalmente se concentram na precisão 
e na oportunidade e incluem contagens de erros de processamento, atrasos 
inesperados e outros erros frequentes (GARVIN, 2015).
No caso dos softwares, a conformidade verifica se ele foi desenvolvido de 
acordo com padrões, normas, procedimentos e guias de TI e se atendem aos 
requisitos do cliente/usuário.
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 economicamente 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 consumidores devem pesar o custo esperado de futuras 
reparações, em reais e em transtornos pessoais, contra o investimento e as des-
pesas 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 durabilidade e a confiabilidade estão estreitamente ligadas. Um produto 
que muitas vezes falha é susceptível de ser substituído ou retirado do mer-
cado 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 durabilidade 
devem ser interpretados com cuidado. Um aumento na vida do produto pode 
não ser resultado de melhorias técnicas ou do uso de materiais mais duráveis, 
mas, em vez disso, fruto de mudanças no ambiente econômico do qual ele faz 
parte (GARVIN, 2015).
Em relação à durabilidade do software, verifica-se que ela diz respeito ao 
tempo de duração de um software até ele se tornar desatualizado em relação 
ao conteúdo ou obsoleto. Vale ressaltar que a durabilidade, apesar de ser um 
conceito similar, não é a mesma coisa que a confiabilidade. A durabilidade, por 
exemplo, relaciona-se com a vida útil do software, enquanto a confiabilidade 
Qualidade e usabilidade de software
– 96 –
relaciona-se com o período de tempo em que o produto não poderá 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 percepção do cliente.
O atendimento envolve questões como pontualidade e rapidez do ser-
viço, eficiência, presteza, reatividade, resolução de problemas, pouco tempo 
de espera, comunicação adequada, entre outros aspectos implicados no con-
tato entre cliente e fornecedor/empresa.
Como, no caso dos softwares, necessita-se de atendimento para repa-
ros 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, é 
claramente uma questão de julgamento pessoal e um reflexo da preferência 
individual. No entanto, parece haver alguns padrões no ranking dos con-
sumidores 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 reali-
zação de protótipos ajuda no desenvolvimento visual do produto, que pode 
– 97 –
Gerência da qualidade de software
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 exemplo, rara-
mente pode ser observada diretamente, pois é inferida por meio de vários 
aspectos tangíveis e intangíveis do produto. Nessas circunstâncias, imagens, 
propagandas e nomes de marcas – referências sobre a qualidade, em vez da 
própria realidade – podem ser críticos (GARVIN, 2015).
Abordando a questão da qualidade do software, ressalta-se que ela é um 
conjunto de atributos que devem ser satisfeitos de modo que esse produto 
atenda às necessidades de todos os usuários – o desenvolvedor, o cliente, o 
usuário final e todas as partes interessadas (stakeholders).
5.2 Planejamento e controle da 
qualidade do software
O planejamento e o controle da qualidade do software surgem da neces-
sidade de se produzir um produto de alta qualidade, e isso implica a garantia 
de proteção de software ao longo de todo o seu processo de engenharia. 
O controle de qualidade abrange uma série de avaliações e testes utilizados 
para todo o ciclo de desenvolvimento de produto, a fim de garantir que cada 
software atenda aos requisitos que lhe foram atribuídos. Essa variedade de tare-
fas está associada a diferentes 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 planejamento (WAZLAWICK, 2013).
Nesse contexto, o planejamento e o controle formais representam um 
filtro para processos de engenharia de software, pois eles são aplicados em 
Qualidade e usabilidade de software
– 98 –
vários estágios de desenvolvimento e usados para detectar defeitos que pos-
sam 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 tornemdefeitos 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 desenvol-
vimento 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 pas-
sam despercebidos, e a inspeção pode não conseguir descobrir os erros. Em 
alguns casos, erros não identificados a nas etapas iniciais são posteriormente 
amplificados (SOMMERVILLE, 2011).
Para realizar inspeções de controle, a equipe de desenvolvimento 
deve gastar tempo e esforço, e a organização precisa gastar dinheiro. Esses 
testes produzem um custo-benefício demonstrável; portanto, se a empresa 
tem os recursos necessários, eles devem ser realizados (PRESSMAN; 
MAXIM, 2016).
Para ilustrar o impacto sobre o custo de detecção de erros desde o início, 
ou seja, desde o planejamento do projeto, considere uma série de custos rela-
tivos que 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):
2 O design de software “compreende a concepção, especificação e prototipação da partes ‘ex-
ternas’ 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).
– 99 –
Gerência da qualidade de software
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 1230
Após o teste 12 67,0 804
Total 2177
Fonte: CYBIS et al., 2015. Adaptado.
Do exposto, pode-se resumir que os benefícios obtidos por meio da apli-
cação de inspeções (PRESSMAN; MAXIM, 2016) envolvem a redução de 
defeitos no software e da quantidade de recursos de desenvolvimento, espe-
cialmente nas fases de codificação e teste, assim como uma redução dos custos 
de manutenção corretiva.
Um processo de inspeção adequado consiste de seis passos (CYBIS, 2015):
1. Planejamento – Quando o desenvolvedor conclui um “produto de 
trabalho”, uma equipe de inspeção é formada e um moderador é 
designado. O moderador assegura que o produto de trabalho satis-
faç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.
Qualidade e usabilidade de software
– 100 –
2. Resumo – Se os inspetores não estão familiarizados com o pro-
jeto de desenvolvimento, é 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.
3. Preparação – Os inspetores são preparados individualmente para 
avaliação na reunião, estudando os produtos de trabalho e mate-
riais relacionados. Nessa fase, é aconselhável a utilização de listas de 
verificação para ajudar a encontrar defeitos comuns.
4. Comentário – Nessa fase, os inspetores se reúnem para discuti-
rem juntos cada trabalho individual. O moderador deve assegurar 
que todos estejam suficientemente preparados. A pessoa designada 
como leitor apresenta o “produto do trabalho”, interpretando-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 encontra-
dos pelos inspetores.
6. Follow-up (acompanhamento) – O moderador verifica as correções 
feitas pelo desenvolvedor. 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):
 2 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 estabelecimento dessas metas está diretamente 
relacionado com o tipo de projeto, as metodologias e os instrumen-
tos utilizados.
– 101 –
Gerência da qualidade de software
 2 Grupos de inspeção – É recomendado que se formem grupos de 
três a seis indivíduos (IEEE, 1997), incluindo neles o autor/desen-
volvedor dos produtos de trabalho.
 2 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 reu-
niões; e o escriba, que documenta a descrição e a localização dos 
defeitos encontrados.
 2 Os produtos funcionam – O processo de inspeção pode ser apli-
cado 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 especi-
ficação de requisitos, com 200 ou 250 linhas de código cada.
 2 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 ins-
peções de software é a possibilidade de solucionar erros o quanto antes, com 
esforço reduzido e custos menores à empresa. 
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 
Qualidade e usabilidade de software
– 102 –
das mudanças inerentes ao desenvolvimento de software, mantendo a integri-
dade 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):
 2 controlar e acompanhar mudanças (controle de mudança);
 2 registrar a evolução do projeto (controle de versão);
 2 estabelecer a integridade do sistema (integração contínua).
O controle de mudanças acontece ao longo de todo o processo de desen-
volvimento do software. As alterações devem ser registradas, avaliadas e elen-
cadas conforme sua prioridade. 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éscimo 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 importante 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 composição do sistema, ou seja, se seus itens de registro estãoconsistentes. A integração acompanha 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 configuração e que elas estão relacionadas com as demais áreas da 
engenharia de software; assim, esses processos são requisitos de implemen-
tação em diversos modelos de níveis de maturidade 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 regis-
tradas e controladas sob responsabilidade do desenvolvedor, que registra a 
– 103 –
Gerência da qualidade de software
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.
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 aplica-
dos diferentes tipos de testes, como descrito a seguir:
 2 Teste de funcionalidade – nele são avaliados campos, navegação 
entre as telas, botões, links, interface e funcionalidade geral do sis-
tema. Os requisitos iniciais solicitados pelo cliente devem ser testa-
dos e aprovados nesse teste.
 2 Teste de desempenho – é avaliado o desempenho do sistema, se ele 
está atendendo aos requisitos preestabelecidos, e o tempo que cada 
aplicação demora para dar respostas a determinada ação.
 2 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.
 2 Teste de bugs – é avaliada a existência de bugs, erros de programa-
ção e funcionamento do sistema, erros de construção de código ou 
da própria aplicação.
 2 Teste de integração – nele são avaliados vários componentes do 
software, combinados e testados em grupo.
 2 Teste operacional – nele é verificado se a aplicação responde ao 
tempo de execução do sistema.
 2 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.
 2 Teste de caixa branca – todas as entradas e saídas desejadas do 
sistema são testadas e é observado o resultado esperado.
Qualidade e usabilidade de software
– 104 –
 2 Teste de configuração – nele se avalia se a aplicação funciona cor-
retamente em diferentes configurações de hardware e software.
 2 Teste de interface – é avaliada a navegabilidade e se cada compo-
nente responde conforme especificado pelo usuário.
 2 Teste de carga – teste em que se avalia o funcionamento da apli-
cação com simulação de entrada de dados simultâneos em grande 
quantidade, verificando-se a resposta do sistema.
 2 Teste de aprovação do usuário – nele o usuário realiza os testes 
operacionais e se sua aplicação é funcional.
 2 Teste de estresse – caminhos diferentes de uso são avaliados, ten-
tando 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 pro-
jetos de qualidade deve envolver profissionais devidamente preparados. Os 
engenheiros devem entender o raciocínio por trás de cada padrão e as nor-
mas devem ser revistas regularmente, para se evitar problemas de obsolescên-
cia e credibilidade.
O gerenciamento da qualidade do software funciona melhor quando se 
cria uma “cultura de qualidade” nas organizações, ou seja, quando a quali-
dade é vista como responsabilidade de todos.
Ampliando seus conhecimentos
O texto a seguir procura desmistificar a ideia equivocada que 
muitos programadores 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.
– 105 –
Gerência da qualidade de software
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 executa-
dos. O fato é que esses testes não são suficientes para detec-
tar os erros que estão inseridos dentro de uma aplicaçã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 dimen-
são positiva sobre o problema, ou seja, o entendimento 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 fun-
ciona”, o que significa que teremos um menor esforço em 
provar o funcionamento de um software do que o contrário. 
E é exatamente isso que sentimos quando colocamos uma 
equipe independente de qualidade para avaliar determinado 
projeto de software – como essa equipe não está envolvida 
emocionalmente nem politicamente com o projeto, terá um 
comportamento muito mais objetivo e direto, indo exatamente 
aos pontos que inicialmente o projeto deveria atender e por 
motivos desconhecidos foram abandonados ou não atendi-
dos corretamente.
[...]
Qualidade e usabilidade de software
– 106 –
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. É neces-
sário buscar um maior nível de qualidade em todos os produ-
tos (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 clientes 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 deci-
sõ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.
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 cultural, social, econômica e 
cognitiva, têm mais dificuldades para se adequar aos novos proces-
sos tecnológicos. Este capítulo busca uma reflexão sobre os proces-
sos que envolvem a relação entre o homem e o computador.
6
Qualidade e Usabilidade de Software
– 108 –
De modo geral, a IHC estuda as trocas de informações por meio de 
software entre pessoas ecomputadores, “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 produti-
vas as tarefas que envolvem pessoas e computadores.
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 conseguir 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 inves-
tigaçã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 rela-
cionados à concepção e à implementação de interfaces entre seres humanos 
e computadores. Dada a sua natureza 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 
– 109 –
Fundamentos da interação homem-computador (IHC)
disciplinas relacionadas às ciências humanas (ergonomia, psicologia cogni-
tiva, filosofia etc.), como explícito na Figura 1.
Figura 1 – Disciplinas relacionadas à IHC.
Ergonomia
Psicologia 
social e 
organizacional
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.
A palavra interação se refere a uma ação que pode ser realizada formal 
ou informalmente e, portanto, nela são executados processos de troca em 
um sentido amplo (WEBER, 2012). Nas relações entre homens e máquinas 
Qualidade e Usabilidade de Software
– 110 –
propostas pela IHC, entende-se que elas estão ligadas 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 
desempenho 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 huma-
no-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 sistema para manipular objetos gráficos utilizando uma caneta, que 
– 111 –
Fundamentos da interação homem-computador (IHC)
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 presta-
vam muito menos atenção para o problema de tornar os produtos de hardware 
e software usáveis, até porque 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 pesquisadores, que passaram a 
estudá-lo sob o nome de usabilidade (WEBER, 2012).
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 principal-
mente nos parâmetros relacionados à 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.
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).
Qualidade e Usabilidade de Software
– 112 –
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 equilibrados 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.
Muitos designers de interface web conduzem estudos honeycomb para 
identificar prioridades na fase de projeto, procurando refletir sobre todas as 
facetas do diagrama honeycomb, de modo a ter uma visão mais ampla de 
requisitos para satisfazer o usuário do software. Matthews (2009, p. 85), 
explica cada um dos “favos da colmeia”:
 2 Utilidade – é importante ver o produto do ponto de vista do cliente/
usuário, buscando verificar a real necessidade dele e se o software 
atende a essa necessidade. As perguntas que devem ser feitas são: 
– 113 –
Fundamentos da interação homem-computador (IHC)
Esse software vai ser útil ao meu cliente? Ele atende às suas necessi-
dades? Para que ele serve? Quais são as suas funções? A partir desse 
questionamento, é mais claro entender o que é realmente impor-
tante contemplar no software em termos de funcionalidade.
 2 Usabilidade – A facilidade de uso é essencial, porém uma interface 
focada apenas 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?
 2 Desejo – A sensação de conforto e bem-estar é grandemente 
influenciada pelas 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 experiê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?
 2 Encontrabilidade – Os conteúdos devem ser facilmente localizá-
veis para que o usuário encontre rapidamente o que precisa. As 
perguntas que devem ser feitas 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?
 2 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, apresen-
tando soluções que ampliem a acessibilidade das pessoas com defi-
ciê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 
deficiê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?
 2 Credibilidade – Um dos pontos fortes do software é a reputação 
de ser confiável. Isso significa que ele deve funcionar perfeitamente, 
Qualidade e Usabilidade de Software
– 114 –
sem travar ou dar mensagens de erro. A pergunta que deve ser feita 
é: O usuário pode confiar nesse software?
 2 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, efeti-
vamente, a diferença. A pergunta a ser feita é: Esse software satisfaz 
as necessidades do usuário, contribuindo para sua experiência?
As facetas da experiência do usuário servem a vários propósitos, funcio-
nando 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 sistema 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 racioci-
nam 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 representam o objeto ou 
a situação em si; uma de suas características mais importantes é que sua estru-
tura 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 representaçã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 
– 115 –
Fundamentos da interação homem-computador (IHC)
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 significati-
vamente a distância entre os modelos mentais 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 exis-
tente 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 com-
petê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, computador, diálogos, objetos de interação e sistemas de significados.
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 é proces-
sada 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 
Qualidade e Usabilidade de Software
– 116 –
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 importante 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),
O termo interface é aplicado normalmente àquilo que interliga 
dois sistemas. Tradicionalmente, considera-se que uma interface 
– 117 –
Fundamentos da interação homem-computador (IHC)
homem-máquina é a parte de um artefato que permite a um usuário 
controlar e avaliar o funcionamento deste artefato através de dispo-
sitivos sensíveis às suas ações e capazes de estimular sua percepção. 
No processo de interação usuário-sistema a interface é o combinado 
de software e hardware necessário para viabilizar e facilitar os pro-
cessos 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 exigir 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):
 2 métodos para a concepção de novas interfaces de computador e oti-
mização do desenho das propriedades desejadas pelo usuário final, 
como a capacidade de aprendizagem ou a eficiência de utilização;
 2 métodos para avaliar e comparar as interfaces no que diz respeito a 
suas propriedades, por exemplo, sua capacidade de uso;
 2 métodos para estudar o uso de computadores e suas implicações 
socioculturais;
 2 perspectivas para reflexão crítica sobre os valores do design com-
putacional, do uso do computador e da pesquisa de interação 
humano-computador.
6.1.3.3 Diálogos
São as sequênciasque ocorrem entre o sistema e o homem. Os diálo-
gos estão associados às formas com que os objetivos práticos dos usuários se 
efetivam nas interações com o sistema. 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 sis-
tema (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 
Qualidade e Usabilidade de Software
– 118 –
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:
 2 janelas;
 2 caixas de diálogo;
 2 botões;
 2 barras de rolagem;
 2 menus;
 2 caixas de mensagem; etc.
A figura a seguir demonstra a disposição desses objetos em uma interface:
Figura 5 – Objetos de interação.
Botões
Janela
Caixa de 
mensagem
Barra de 
rolagem
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 redirecionamento de links.
– 119 –
Fundamentos da interação homem-computador (IHC)
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 sig-
nificação e comunicação. Já signo é “aquilo que, sob certo aspecto ou modo, 
representa algo para alguém” (PEIRCE, 2005, p. 46), ou seja, o signo substi-
tui 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:
 2 a expressão: aquilo que ele representa;
 2 o objeto: aquilo que é representado;
 2 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 comunicativo entre o designer (emissor da mensagem) e o usuá-
rio (receptor). Esse processo comunicativo entre designer e usuário faz parte 
Qualidade e Usabilidade de Software
– 120 –
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 objeto representado, já a ideia de salvar é a 
expressão (aquilo que ele representa) e o interpretante é 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.
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 direta com o objeto representado. Por exemplo: uma pomba é o símbolo da paz.
– 121 –
Fundamentos da interação homem-computador (IHC)
6.1.4 Interface cérebro-computador
A interface cérebro-computador (ICC) é um caminho comunicativo 
direto entre o cérebro e um dispositivo externo, como se o dispositivo lesse 
as informações que estão na mente 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 funcio-
namento 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 qual-
quer máquina sem usar as mãos (ou qualquer outro meio, ou seja, sem o uso 
de qualquer músculo ou nervo do próprio corpo). Essa tecnologia pode aju-
dar pessoas com deficiência visual ou auditiva a voltar a enxergar ou a ouvir 
e pessoas com deficiência física a mover uma prótese mecânica, por exemplo. 
Também tem sido usada em jogos, como o Brainball, em que os jogadores 
controlam, com as ondas cerebrais, o movimento de uma bola sobre uma 
mesa, podendo manter-se mais concentrados e relaxados. Outro emprego 
dessa tecnologia é no controle de robôs e na possibilidade de se pilotar um 
avião virtual apenas pelo pensamento (ROGERS et. al., 2013, p. 204).
6.2 Interação das atividades de IHC 
com a engenharia de software
Desde 1960, quando o conceito de interatividade homem-computador 
surgiu, numerosas metodologias de design de software têm sido desenvolvi-
das. A maioria delas é baseada no fato de que os designers têm de capturar 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 engenha-
ria de software conta com o auxílio da engenharia cognitiva, que se baseia na 
psicologia cognitiva e na ciência cognitiva para entender como o ser humano 
constrói o conhecimento. A engenharia cognitiva estuda as limitações da 
Qualidade e Usabilidade de Software
– 122 –
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 comuni-
cação entre os usuários, os designers e os engenheiros de software. Para otimizar a 
interação das atividades de IHC no desenvolvimento do software, recomenda-se 
a adoção de (WEBER, 2012):
 2 Teoria da atividade – É usada para definir o contexto no qual a 
interação entre pessoas e computadores ocorre. Essa teoria con-
sidera que as ferramentas tecnológicas servem de instrumentos 
mediadores entre as pessoas e o mundo, partindo do conceito de 
mediação proposto por Vygotsky. Afinal, as pessoas agem como 
sujeitos do mundo por meio da tecnologia. A teoria da atividade 
procura compreender como se dá a interação entre o usuário e a 
tecnologia, fornecendo informações aos desenvolvedores para pro-
jetar o design de interação.
 2 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, é necessário conhe-
cer as limitações dos usuários para se criar um sistema adequado. 
Essa metodologia é semelhante à concepção de participação, a qual 
enfatiza a possibilidade de que os usuários finais devem contribuir 
para a criação do sistema.
 2 Princípios de design de interface – Deve-se considerar em todos os 
momentos, ao se projetar a interface para o usuário:
 2 a simplicidade (deve ser de fácil utilização);
 2 a visibilidade (deve ser visível para facilitar a usabilidade);
 2 a viabilidade (deve ter designprojetado com orçamento 
adequado);
 2 a coerência (deve ser feito em conformidade com o requerido 
pelos usuários);
 2 a estrutura (deve ter uma estrutura que permita a navegabilidade);
– 123 –
Fundamentos da interação homem-computador (IHC)
 2 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-exami-
nar, pensar e responder, como demonstra a Figura 8. Os softwares devem ser 
desenvolvidos de forma a facilitar essa interação entre o homem e a máquina 
(MAYHEW, 1992).
Figura 8 – O computador, o homem e os limites do sistema.
HOMEM
Pensar
Processamento 
de input de 
acordo com os 
algoritmos
Responder
Resposta do computador envia-
da ao usuário
Ler-examinar
Reconhecimento e interpretação 
da informação apresentada 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 interpreta-
çã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.
É 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 
Qualidade e Usabilidade de Software
– 124 –
atividade ou teoria da ação, apresentando um sistema interativo composto 
pelo homem, pelo computador e pelos limites do sistema. As fases ler-exa-
minar, 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 desenvolvedores muitas vezes não levam em conta que o software desen-
volvido 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 trabalho. Isso também engloba 
a compreensão das limitações humanas para a realização do processamento 
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 engenharia cognitiva. Esses conhecimentos auxiliam o 
designer a criar modelos mentais adequados 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.
– 125 –
Fundamentos da interação homem-computador (IHC)
IHC como área multidisciplinar
(BARBOSA, 2011, p. 12)
IHC se beneficia de conhecimento e métodos de outras 
áreas fora da computação para conhecer melhor os fenô-
menos envolvidos no uso de sistemas computacionais inte-
rativos. Á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.
Alguns conhecimentos e técnicas importados de outras áreas 
além da computaçã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 normalmente 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 apresentaçã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 conhe-
cimentos oriundos de diversas áreas. Isso torna muito mais 
difícil que um único profissional tenha conhecimento pro-
fundo 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 
Qualidade e Usabilidade de Software
– 126 –
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, profis-
sionais com formações diferentes podem trabalhar em con-
junto, 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 alter-
nativas de soluções sob pontos de vista bem variados, enri-
quecendo, 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 fatores fundamentais da interação huma-
no-computador?
2. Cite os modelos recentes de IHC com foco no usuário que se desti-
nam a obter a experiê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 pesqui-
sadores e desenvolvedores da área?
Usabilidade de software
Introdução
A usabilidade é considerada um atributo de qualidade que 
avalia a facilidade com que uma interface gráfica de software é utili-
zada. Ela também se refere à aplicação de métodos, durante um pro-
cesso de design, para melhorar essa utilização (NIELSEN, 1993).
Entre os fatores que determinam a usabilidade, pode-se 
mencionar a acessibilidade, a legibilidade, a navegabilidade, a faci-
lidade 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.
7
Qualidade e usabilidade de software
– 128 –
Desse modo, a usabilidade, como abordada neste capítulo, é uma das 
vertentes importantes da qualidade em software.
7.1 Definições de usabilidade do software
A capacidade com que as pessoas podem utilizar uma ferramenta é cha-
mada 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 desenvol-
vimento de um produto focado no usuário.
A usabilidade tem relação com o grau de facilidade de utilização de um sis-
tema e é mensurada por testes relativos e empíricos: o teste empírico baseia-se em 
testes deusabilidade 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) fornece 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 “capacidade 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.
– 129 –
Usabilidade de software
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, 
estando 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 deter-minada tarefa e otimização entre usuário e sistema.
Robustez
Facilidade e nível de serviço oferecido de suporte para cum-
prir os objetivos, estando relacionado com a recupera-
ção de informações e o ajuste de tarefas do usuário.
Fonte: WEBER, 2006. Adaptado.
7.2 Métodos de usabilidade
No centro do processo de criação do software, a usabilidade representa 
um projeto que incorpora os desejos e as necessidades do usuário, os quais são 
especificados desde o início do processo e têm papel importante nas decisões 
sobre o produto. Nesse projeto devem ser envolvidos, em conjunto, os usuá-
rios, os especialistas em teste e os avaliadores. Assim, identificar as demandas 
do usuário, algo essencial para a construção de um software, é a primeira 
etapa no processo de desenvolvimento.
Qualidade e usabilidade de software
– 130 –
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 etno-
grá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 especificados 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 abor-
dagem ú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 pes-
soa que conduz o teste (analista de usabilidade, desenvolvedor, entre outros) 
identifica primeiro os conceitos-chave e os grava em cartões. Geralmente, a 
aplicação é testada individualmente ou em grupos, que podem ser colaborati-
vos (grupos focais); no entanto, na literatura da área não existe um consenso 
sobre o número de indivíduos necessários para produzir resultados confiáveis.
Um cartão é comumente utilizado para projetar uma estrutura de nave-
gação a um ambiente que oferece uma variedade de conteúdos e funções, 
como um site da web. Nesse contexto, os itens a serem organizados são aque-
les 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:
 2 a variedade de itens a organizar é tão grande que nenhuma taxono-
mia existente é aceita como organização dos itens;
 2 as semelhanças entre os itens tornam difícil uma divisão clara 
em categorias;
– 131 –
Usabilidade de software
 2 os membros do público que usam o ambiente diferem significativa-
mente 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 orga-
nização dos conteú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 melho-
rar o uso do produto final. O que distingue esse método é a cooperação que 
ocorre à medida que pesquisador e participantes 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 problemas mais importantes a serem considerados.
Qualidade e usabilidade de software
– 132 –
Essa metodologia de avaliação pode ser usada com:
 2 um produto existente que deve ser melhorado ou ampliado;
 2 um protótipo ou uma simulação parcial precoce;
 2 um protótipo de trabalho completo.
Além disso, para a avaliação ser considerada cooperativa, ela deve especi-
ficar tarefas permitindo que cada participante explore áreas da interface con-
sideradas mais relevantes à pesquisa. Depois da interação, os participantes 
verbalizam os problemas encontrados e o pesquisador registra as observações. 
Por fim, o pesquisador, com base no que foi levantado e anotado, analisa os 
resultados e propõe soluções (PUC-RIO, 2017).
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 pro-
blema encontrado durante a utilização de uma interface.
Geralmente, é solicitado que os indivíduos forneçam uma descrição por 
escrito do problema; 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 pes-
soas é 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 
– 133 –
Usabilidade de software
ou problemas de usabilidade. Também abrange requerimentos para uma nova 
interface, combase nos pontos que, de acordo com os participantes, necessi-
tam 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 mode-
rador/líder do grupo é, principalmente, assegurar que todos os participantes 
exponham suas opiniões a respeito do produto (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 
mudam é medida (JORDAN, 1998).
7.2.1.6 Lista de verificação de recursos/
características (feature checklists)
Esse método visa avaliar a importância que os participantes dão a deter-
minadas caracterí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 qualidade para o software, 
como definido pela ISO 9126. Além disso, a lista de verificação deve ser cons-
truí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.
Qualidade e usabilidade de software
– 134 –
As listas de verificação de características são mais eficazes no caso de 
interfaces finalizadas 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 usabilidade em design e desenvolvimento de produtos, em psicolo-
gia e em diversas ciências sociais (por exemplo, leitura, escrita, pesquisa de 
tradução, processamento e rastreamento de processos). O método foi intro-
duzido no campo de usabilidade por Clayton Lewis1, enquanto 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 necessi-
dades enquanto ainda coletam dados válidos. Por exemplo, eles podem pre-
cisar 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 ati-
vidades. Isso pode incluir o que eles estão olhando, pensando, fazendo e 
sentindo, o que dá aos observadores uma visão dos processos cognitivos dos 
participantes (e não somente do seu produto final), para tornar os mecanis-
mos 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.
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 pen-
samento em voz alta, usado regularmente em organizações de desenvolvimento de software no 
mundo todo.
– 135 –
Usabilidade de software
Em um contexto de teste de usabilidade, os observadores são convi-
dados a tomar notas do que os participantes dizem e fazem, sem tentar 
interpretar suas ações e palavras e, especialmente, 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 verifi-
car 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 procedi-
mentos experimentais. O primeiro é o protocolo de pensamento em voz alta 
simultâneo, coletado durante a tarefa, e o segundo é o retrospectivo think loud 
reunido após a tarefa. Existem benefícios e desvantagens em cada abordagem, 
mas em geral um protocolo simultâneo pode ser mais completo, enquanto 
um protocolo retrospectivo tem menos chance de interferir no desempenho 
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, incluindo 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 
destacar todos os assuntos que considerem importantes em relação à interface 
avaliada. Esse tipo de questionário é, geralmente, mais adequado no caso de 
Qualidade e usabilidade de software
– 136 –
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 estande 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 presença de um entrevistador, quando 
tendem a querer agir mais racionalmente.
Normalmente, a conversa diante de uma câmera privada acontece 
depois de o participante ter lidado com um protótipo de software por um 
tempo, mas pode acontecer também durante o uso de teste. Esse registro de 
conversações pode desencadear dados experienciais mais autênticos do que 
em uma entrevista “cara a cara”. Se dois amigos estiverem juntos no estande, 
por exemplo, a discussão poderá revelar aspectos experienciais interessantes. 
No entanto, o registro não garante que os participantes falarão sobre os temas 
que são de interesse do pesquisador. Além disso, nem todo tipo de partici-
pante 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çãodo produto. Para tanto, é utilizado 
um laboratório de usabilidade, em que duas salas são interligadas por um espe-
lho 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”.
– 137 –
Usabilidade de software
7.2.2 Métodos não empíricos
Na avaliação de usabilidade em interfaces de software, também são utiliza-
dos os métodos 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, determinando o escopo de 
conteúdo apropriado.
A análise de tarefas ajuda a suportar vários outros aspectos do processo 
de design centrado no usuário, incluindo: coleta de requisitos, desenvolvi-
mento de estratégia de conteúdo, prototipagem e execução de testes de usa-
bilidade. Entre as técnicas mais comumente utilizadas, estão: a análise de 
tarefas cognitivas, focada na compreensão de tarefas que requerem 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 
subtarefas (JORDAN, 1998).
7.2.2.2 Avaliação heurística (heuristic evaluation)
O objetivo principal das avaliações heurísticas é identificar quaisquer 
problemas associados ao design de interfaces de usuário. O consultor de usa-
bilidade Jakob Nielsen2 (1993) desenvolveu esse método com base em seus 
vários anos de experiência em ensino e consultoria sobre engenharia de usa-
bilidade. Essas avaliações são um dos métodos mais informais de inspeção da 
usabilidade no campo da interação homem-computador.
2 Cientista da computação com Ph.D. em interação homem-computador. Inventou vários 
métodos de usabilidade, entre eles a avaliação heurística.
Qualidade e usabilidade de software
– 138 –
Existem diversos conjuntos de usabilidade de avaliação heurística, os quais 
não são mutuamente exclusivos e cobrem muitos dos mesmos aspectos do design 
da interface do usuário. Os problemas de usabilidade descobertos são categoriza-
dos, 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 é frequente-
mente realizada no contexto de casos de uso (tarefas típicas do usuário), para for-
necer feedback aos desenvolvedores sobre a medida em que a interface é suscep-
tí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 (especialistas) 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 ins-
pecionar de modo mais aprofundado 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 ergo-
design, asseguram que uma interface é fácil de ser usada. Podem conter itens 
como consistência da interface, compatibilidade, 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 interfaces já finalizadas. 
7.2.2.5 Percurso cognitivo (cognitive walkthroughs)
É um método de avaliação da usabilidade também realizado por peritos. 
No percurso cognitivo, no entanto, como afirma Brandão (2006, p. 191), o 
pesquisador realiza a sua avaliação
– 139 –
Usabilidade de software
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 durante os vários estágios, ou pas-
sos, necessários para completar a tarefa.
Jordan (1998) ressalta que, para essa técnica funcionar, é preciso que o 
perito tenha uma compreensão exata das características dos usuários para os 
quais a interface foi projetada, incluindo suas habilidades e expectativas em 
relação ao produto.
7.3 A importância das 
recomendações de usabilidade
As recomendações de usabilidade, ao serem incorporadas no desenvolvi-
mento 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 usabili-
dade, garantindo que a qualidade seja priori-
zada. Interfaces amigáveis e com adaptação 
para os usuários em diferentes tarefas e 
ambientes tecnoló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 sistema 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 usabili-
dade ineficaz é a razão principal desse tipo de chamada 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 
Qualidade e usabilidade de software
– 140 –
que ajuda a aumentar a produtividade e a probabilidade de recomendação a 
outros possíveis usuários (PFLEEGER, 2004). Portanto, a usabilidade inter-
fere 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 pro-
duto em relaçã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 vantagens 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 resul-
tado, continuará usando-o ou o abandonará. Daí a importância de se testar 
adequadamente o produto antes de lançá-lo no mercado, visto que isso pode 
garantir que a experiência do usuário seja positiva, evitando-se, dessa forma, 
revisões no processo de produção (PRESSMAN; MAXIM, 2016).
As indicações de usabilidade do sistema devem ser obedecidas desde o 
projeto inicial para que ela possa ser atingida. Quando isso ocorre, há uma 
chance maior de o software ser bem elaborado, tornar-se mais eficiente, com 
baixa taxa de erros, e de fácil memorização. Essas características exigirão um 
esforço menor do usuário, que realizará tarefas repetitivas em menos tempo 
e não se perderá na navegação do sistema. Nesse sentido, as recomendaçõesfuncionam como um guia importante para os programadores ao desenvolve-
rem, 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 pro-
jeto de interfaces computacionais, muitos são os termos e conceitos emprega-
dos. O Quadro 2, a seguir, apresenta 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 sis-
tema (p. ex: “Quanto tempo leva para 
a realização de uma tarefa?”)
– 141 –
Usabilidade de software
Conceito Às vezes também chamado de Como utilizar
Metas decorrentes 
da experiência 
do usuário
Fatores de satisfação
Identificar os aspectos importan-
tes da experiência do usuário (p. ex: 
“Como se pode tornar o produto inte-
rativo 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 inter-
face (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 interfa-
ces, utilizadas durante a avaliação 
heurí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 durante 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 hipote-
ticamente outros usuários conseguiriam. Em interfaces de uso frequente e 
profissional, 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 aumen-
tar a qualidade da experiência do usuário. Quanto mais versões e ideias forem 
testadas com as interfaces, melhor será a usabilidade.
A usabilidade é uma condição necessária também para a sobrevivência 
de sites, incluindo o e-commerce, porque se o site falhar, isso pode indicar 
Qualidade e usabilidade de software
– 142 –
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 cresci-
mento considerável devido a sua importância. No caso de intranets, a usabi-
lidade é 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 recomendações de usabilidade vão 
além da fácil utilização de um software, trazendo benefícios aos projetos inter-
nos das empresas. Nesse caso, a ênfase na usabilidade pode representar uma 
redução significativa do orçamento em treinamento e a duplicação de desem-
penho de funcioná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 
implementadas 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 adequada usabilidade para o des-
tinatário do produto, o usuário final. Ao tratar desse assunto, o 
texto apresentado a seguir dá dicas para que o desenvolvedor 
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 
– 143 –
Usabilidade de software
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 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 
permanecer no modo de revisão ortográfica se ele quer ape-
nas 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 comandos de teclado, movimenta-
ção do mouse, caneta digitalizadora, tela multitoque 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 desenhar 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 compe-
tência avançam e permita que a interação possa ser perso-
nalizada. Geralmente os usuários constatam que realizam a 
mesma sequência de interações repetidamente. Vale a pena 
Qualidade e usabilidade de software
– 144 –
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.
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?
Acessibilidade e 
inclusão digitalIntrodução
O avanço da globalização deve assumir um elemento de inte-
graçã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 res-
peito a uma prática inclusiva no desenvolvimento de websites que 
possam ser utilizados por todas as pessoas, independentemente de 
elas terem ou não alguma necessidade especial. Quando os sites são 
corretamente 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 qualidade percebida tem como 
8
Qualidade e usabilidade de software
– 146 –
objetivo principal produzir produtos cada vez melhores e com menos erros, 
para que o usuário final fique satisfeito.
Nessa ótica, o produto software, além de usual, deve ser acessível às pes-
soas, independentemente de idade, necessidades especiais e nível de escolari-
dade. Isso porque o software é, na verdade, um artefato produzido por pes-
soas para pessoas e, portanto, precisa ser acessível a todos, a fim de que atinja 
a função a que se propõe.
Tendo isso em vista, o objetivo deste capítulo é apresentar uma reflexão 
sobre a inclusão digital na atualidade.
8.1 A acessibilidade digital
Acessibilidade refere-se à facilidade de acesso a um lugar, uma pessoa, um 
conhecimento ou um objeto/bem. Com o advento da sociedade da informa-
ção, o conceito de acessibilidade evoluiu tendo em conta as novas realidades. 
Na verdade, mobilidade, proximidade e distância já não são aspectos essenciais 
da definição de acessibilidade, ou melhor, a acessibilidade no espaço físico é 
agora complementada pela disponibilidade do espaço virtual, desafiando 
os princípios de distância, proximidade ou interação espacial (NIELSEN; 
TAHIR, 2002).
A acessibilidade ao ambiente físico está relacionada à qualidade que os 
espaços disponibilizam a todos, inclusive nos casos de deficiência de mobi-
lidade ou comunicação (IBM, 2017), incluindo a possibilidade de chegar a 
todos os lugares e edifícios sem esforço excessivo 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 “con-
dição para utilização, com segurança e autonomia, total ou assistida, dos espa-
ços, mobiliários e equipamentos urbanos, das edificações, dos serviços de trans-
porte 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 conjunto de elementos que facilitam o acesso à informação a 
todas as pessoas, de modo igualitário, usando a tecnologia (computadores, 
– 147 –
Acessibilidade e inclusão digital
tablets, telefones móveis, entre outros) independentemente das necessida-
des 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 distú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 instru-
mento por pessoas com deficiência. Já a infoacessibilidade refere-se a produ-
tos e serviços eletrônicos que podem ser utilizados por usuários com eficiência 
e satisfação, em um contexto de uso específico, por exemplo: acessibilidade de 
equipamentos de informática (hardware e software), acessibilidade 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 domínio dessas ferramentas. Portanto, não é suficiente ter um 
computador conectado à internet, 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 favo-
recidos 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 desenvol-
vimento 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 comunicação para 
permitir a inserção de todos na sociedade da informação.
Qualidade e usabilidade de software
– 148 –
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 movimento 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, particularmente 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 limitaçã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, audi-
tiva, física, cognitiva, problemas neurológicos e da fala, temporárias ou per-
manentes. Há milhares de pessoas com deficiência que ainda não podem usar 
a web, por conta das barreiras de acessibilidade 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, pessoas com deficiência poderiam usar esses serviços 
de forma eficaz (IBM, 2017).
A acessibilidade para esses indivíduos está regulamentada em lei e pre-
sente no ambiente 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.
– 149 –
Acessibilidade e inclusão digital
O decreto n. 3.298/99 (BRASIL, 1999) dispõe sobre a Política Nacional 
para a Integração da Pessoa Portadora de Deficiência, consolidando as nor-
mas 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 reconhecimento de cursos e de credencia-
mento 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 telefones 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 con-
sideravelmente 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 cone-
xã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 desen-
volvedores web contam com ferramentas de autoria (ex. editores de 
páginas web, ferramentas de gerenciamento de conteúdo, wikis, etc.) 
e ferramentas de avaliação (ex. verificadores de linguagem de marca-
ção, ferramentas semiautomáticas de avaliação de acessibilidade) para 
Qualidade e usabilidade de software
– 150 –
desenvolver conteúdo web, usuários da rede mundial de computado-
res podem usar navegadores, media players e tecnologias assistivas, 
entre outros agentes de usuário, para obter informação, produzir con-
teúdo e interagir. A acessibilidade na web depende da interação entre 
esses diferentes componentes 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 instituição que realiza um esforço para melhorar a acessibili-
dade à web para pessoas com deficiência. Pessoas com necessidades especiais 
podem encontrar dificuldades ao usar computadores em geral e acessar con-
teúdos na grande rede. O Consórcio disponibiliza informações, diretrizes, 
relatórios técnicos, materiais educacionais e outros documentos que se rela-
cionam aos diversos componentes de acessibilidade da web. Esses componen-
tes 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 desen-
volvidas pelo W3C que fornece soluções acessíveis para software, como no 
documento Componentes essenciais de acessibilidade na web, que descreve os 
diferentes papéis da acessibilidade (IBM, 2017). Essas diretrizes são considera-
das as normas internacionais para a acessibilidade (NIELSEN; TAHIR, 2002)2.
As diretrizes e técnicas desenvolvidas pelo W3C apontam para a neces-
sidade de se fazer um website levando em conta fatores como o tipo de con-
teúdo, o tamanho e a complexidade 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).
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>.
– 151 –
Acessibilidade e inclusão digital
Ao desenvolver ou redesenhar um site, deve-se avaliar a acessibilidade 
de modo a encontrar possíveis problemas desde o início, quando é mais 
fácil de resolvê-los. Técnicas simples, 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 
ferramentas 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 tradi-
cional (WARSCHAUER, 2006).
Além disso, há também uma questão econômica: a acessibilidade pode 
ser uma ferramenta 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 importante para a acessibilidade é o código HTML – HyperText 
Markup Language. O leitor de tela e outros recursos de Tecnologia 
Assistiva interpretam o código HTML, seus elementos e semântica. 
Por isso, o primeiro passo para garantir 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, recomen-
dações, notas, artigos, tutoriais e afins de caráter técnico, produzidos 
pelo consó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):
 2 Conceito de Camadas: Representa o uso adequado das tecno-
logias, ou seja, cada tecnologia deve ser utilizada com o propó-
sito único ao qual foi criada. Por exemplo, o HTML é utilizado 
Qualidade e usabilidade de software
– 152 –
apenas para a criação de conteúdo, enquanto a apresentação visual 
é criada através do CSS. Já o comportamento é definido pelas lin-
guagens de script.
 2 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 apre-
sentaçã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.
 2 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 desenvolvedora forma de corrigi-lo. O conceito de semântica pode ser observado 
na figura 2.
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 forneci-
das 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 utilizados – é uma vantagem social sobre a con-
corrê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.
No caso do Brasil, que possui uma grande extensão territorial e uma 
intensa desigualdade social, as dificuldades para a inclusão digital são mais 
severas, como afirma Demo (2005), do que em países mais desenvolvidos, 
– 153 –
Acessibilidade e inclusão digital
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 fer-
ramentas digitais gerou um movimento de acesso a diferentes conhecimentos, 
composto por uma comunicação interativa. Hoje o computador está presente 
nos mais variados contextos (empresarial, 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 elaboradas no mundo das telecomunicações e da informática. 
Os sistemas de informação e as redes de computadores avançam velozmente 
e a informatização captura a escrita, a leitura, a visão, a audição, a criação e 
a aprendizagem. O autor também aborda a velocidade dos recursos tecnoló-
gicos e alerta sobre o erro de levarmos tempo demais discutindo suas possi-
bilidades de uso, porque “enquanto discutimos possíveis usos de uma dada 
tecnologia, algumas formas de usar já se impuseram”, tal a velocidade e reno-
vação com que se apresentam (LÉVY, 2000, p. 26).
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 Ci-
dadão (2003), resultado da parceria entre órgãos do Governo Federal (Ministério das Comu-
nicações, do Planejamento, 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 internacio-
nalmente; o Programa Sinergia Digital, criado e mantido pela PUCRS; e o NAVEGAPARÁ – 
Programa de Democratização do Acesso às Tecnologias de Informação e Comunicação (2007).
Qualidade e usabilidade de software
– 154 –
A adaptação às novas ferramentas tecnológicas é complexa: para alguns 
indivíduos ela acontece rapidamente; outros, no entanto, devido à heteroge-
neidade 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 à tecno-
logia da informação e aquelas que são excluídas desse processo. As diferenças 
entre elas podem ser socioeconômicas ou em relação à capacidade de usar a 
tecnologia da informação de forma eficaz, devido aos níveis distintos de alfa-
betizaçã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 ins-
trumentos 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 com-
preensão de processos 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 inclu-
são dos indivíduos na realidade atual, visto que as principais atividades eco-
nô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 
– 155 –
Acessibilidade e inclusão digital
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 ferramentas amplamente difundidas e utilizadas nos processos de 
interação entre os indivíduos, seja nos relacionamentos pessoais, seja nos mais 
diversos contextos profissionais. Isso permite que os sujeitos não só adqui-
ram conhecimentos, mas também os produzam e disseminem, 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 multidirecionais e imprevisíveis de informação, cultura 
e conhecimento, constantemente ressignificados, 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 tradicionais de ensino por não saberem lidar com as novas tecnolo-
gias. No entanto, em grande parte das escolas do país gradativamente é inse-
rida a mediação tecnológica na aprendizagem 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 desenvolvimento de ins-
trumentos 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çãonecessária para um bom desenvolvimento da prática pedagógica, tendo 
como suporte as ferramentas inovadoras 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 educador seja 
Qualidade e usabilidade de software
– 156 –
maleável, tendo em vista que a aprendizagem é reconstrutiva, fazendo com 
que o indivíduo participe dessa realidade. A capacidade de conviver e inter-
ferir 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 
modernidades 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 constante-
mente. 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 pedagó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 planejada, bem estruturada, reconstruída constan-
temente, 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 tradicio-
nais. Portanto, são necessárias mudanças interiores e exteriores na educação, 
para que sejam aplicadas as inovações propostas que compõem a inclusão 
digital, fazendo que o aluno aproveite a multiplicidade de oportunidades ofe-
recidas 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 
– 157 –
Acessibilidade e inclusão digital
por Aluno (ProUCA), amparado pela Lei n. 12.249/2010. Essa lei também 
trata do Regime Especial de Aquisição de Computadores para Uso Educacional 
(RECOMPE), que facilita a compra de computadores para uso educacional.
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 conheci-
mentos 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ância) 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 criados ou desenvolvidos para facilitar o uso e a experiência por parte 
das pessoas com deficiência. 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:
 2 O projeto Orca é um leitor de tela para o software livre flexível 
e extensível, desenvolvido 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 ferramentas que suportam 
provedores de interface de tecnologia assistiva AT-SPI (por exem-
plo, 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 
Qualidade e usabilidade de software
– 158 –
realizado em 2004 por Mark Mulcahy, um programador cego que 
trabalhou na Sun Microsystems.
 Disponível em: <https://wiki.gnome.org/Projects/Orca>.
 2 O projeto Lazarus é uma distribuição Linux para pessoas com defi-
ciê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/>.
 2 O projeto Linaccess-Knoppix é uma distribuição Linux particu-
larmente útil para pessoas com deficiência visual, desenvolvida no 
âmbito do projeto Linacess.
 Disponível em: <http://www.linaccess.org>.
 2 O navegador de internet Mozilla Firefox é um popular programa 
de software livre processado em Windows, Linux e outras platafor-
mas, incluindo recursos de acessibilidade importantes que facilitam 
o uso por pessoas com deficiências visuais.
 Disponível em: <http://www.mozilla.org/access>.
 2 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>.
 2 Festival é um sintetizador de voz que reproduz textos em inglês e 
espanhol, disponíveis em diferentes distribuições. Ele inclui docu-
mentação completa e ferramentas para construir novas vozes, dis-
poníveis por meio do Projeto Festvox de Carnegie Mellon.
 Disponível em: <http://festvox.org>.
– 159 –
Acessibilidade e inclusão digital
 Disponível em: <http://www.cstr.ed.ac.uk/projects/festival/>.
 2 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-speech.html>.
 2 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>.
 2 Kmagnifier é um ampliador de tela para Linux, que funciona 
como uma lupa que amplia uma parte da tela. Ele é usado por pes-
soas 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/>.
 2 XZOOM é uma lupa de aumento disponível para qualquer dis-
tribuição com servidor 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>.2 O SVGATextMode redimensiona linhas de texto em cartões con-
sole SVGA para Linux em modo texto. Modifica o tamanho da 
fonte, o cursor, a sincronização horizontal e vertical etc.
 Disponível em: <http://freshmeat.net/projects/svgatextmode/>.
Qualidade e usabilidade de software
– 160 –
8.3.2 Deficiência motora
Os softwares destacados a seguir são destinados para aqueles usuários 
que apresentam deficiência motora.
 2 Dasher é um software que permite a realização de uma gravação 
escrita por meio de uma previsão baseada no movimento do pon-
teiro do mouse, que possibilita a substituição da escrita do teclado 
pelo movimento do mouse, usando a inteligência artificial.
 Disponível em: <http://www.bltt.org/software/dasher/>.
 2 GOK é um teclado alfanumérico virtual que permite aos usuários 
controlar computadores 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 dina-
micamente teclados para se adaptarem a uma situação específica, 
religando os componentes 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 pre-
cisa 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/>
 2 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/>.
– 161 –
Acessibilidade e inclusão digital
 2 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/>.
 2 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 especiais. Está disponível nas ver-
sões em espanhol e inglês.
 Disponível em: <https://clic.xtec.cat/>.
 2 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 acessíveis a usuários com limitaçõ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 melhorar a acessibilidade de diversos públicos. A liberdade oferecida 
pelos programas desenvolvidos e distribuídos como software é importante tanto 
nos casos das deficiências temporárias quanto das permanentes.
Mesmo assim, apesar dos avanços na área da acessibilidade, um dos gru-
pos menos levados em consideração pelos programadores ainda é o das pes-
soas 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 desenvolvedores deem a atenção merecida à questão da acessibilidade.
Qualidade e usabilidade de software
– 162 –
Ampliando seus conhecimentos
É notório o movimento cada vez mais intenso para que a 
população mundial tenha acesso aos conteúdos e ferramentas 
necessários à inclusão digital. 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 importâ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, uni-
versidades, empresas, escolas. Tanto pelos diferentes signi-
ficados atribuídos ao termo pelos diferentes atores sociais 
envolvidos, 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 chamados 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 ocorrido na socie-
dade contemporânea, em geral, têm enfatizado a difusão cres-
cente das tecnologias da informação e comunicação, em escala 
mundial. Em muitos destes, são enfatizados e criticados os con-
textos políticos nos quais nascem as proposições destinadas a 
construir, em escala mundial, uma “Sociedade da Informação”.
– 163 –
Acessibilidade e inclusão digital
O espaço político-ideológico das políticas de governo nacio-
nais e internacionais para o desenvolvimento do que se con-
vencionou 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 empreendi-
dos 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 desigualda-
des quanto ao acesso de grandes contingentes populacionais 
às Tecnologias da Informação e Comunicação (TIC). Tais 
desigualdades vêm sendo denominadas genericamente como 
digital divide, gap digital, infoexclusão, ou exclusão digital, e 
têm justificado a formulação de numerosas políticas públicas 
com a finalidade de minimizá-las.
[...]
O tema inclusão digital tem, assim, suscitado diversas discus-
sõ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 
Qualidade e usabilidade de software
– 164 –
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.
Atividades
1. Defina a acessibilidade em seus diferentescontextos. 
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. 
– 165 –
Gabarito
Gabarito
Qualidade e Usabilidade de Software
– 166 –
1. Qualidade de software
1. Um produto tem um ciclo de vida em que é concebido, desenvolvi-
do, entra em operaçã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 de-
senvolvido 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.
2. Os requisitos descrevem ou expressam as características de um dado 
produto de software, podendo ser funcionais ou não funcionais. Re-
quisitos 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 re-
quisitos 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 infor-
mais ou processos 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 codificação; falha na subcontratação de serviços; e entrega do produ-
to 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 corretamente. Quando o analista ou o cliente 
identifica um problema, ele é corrigido sem ser analisado, sem que se 
– 167 –
Gabarito
verifique se esse problema está associado a outras questões. Assim, cor-
rige-se um problema visível e cria-se uma trilha de erros no programa.
2. Normas e padrões
1. As normas para os sistemas de gestão ajudam as organizações na ges-
tão de suas atividades. O uso generalizado de normas é um pré-re-
quisito 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 capacidades desenvolvido para processos relacionados 
com a produção e manutenção de sistemas de software. Assim, pode 
ser usado para dois fins:
 2 Melhorar os processos relacionados com a produção e manuten-
ção de software.
 2 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:
 2 operação do produto (usá-lo);
 2 revisão do produto (alterando-o);
 2 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
– 168 –
3. Influência dos requisitos na 
qualidade do software
1. Não. As empresas se diferenciam entre si pela sua capacidade de or-
ganização e processos 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: desem-
penho (tempo e espaço); interfaces de usuário; fiabilidade (robustez, 
disponibilidade de equipamentos); manutenção; segurança; portabi-
lidade e normas; entre outros.
3. Não, pois o correto levantamento de requisitos é um processo coo-
perativo. Para que a especificação gerada seja mais fiel à realidade, é 
necessário haver comprometimento 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 desenvolvimento do software apenas na fase de testes do produto, 
quando deveria estar presente em todas as fases do projeto, inclusive 
na fase de especificação de requisitos.
4. Processo de desenvolvimento de software
1. O ciclo de desenvolvimento de software fornece uma série de etapas, 
a fim de projetar e desenvolver um produto de software de forma 
– 169 –
Gabarito
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 decor-
rer 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 do-
cumentação. Equipes mais ágeis estão localizadas em um único es-
critório aberto, às vezes chamado de plataformas de lançamento. 
O escritório deve incluir revisores, escritores de documentação, de-
signers 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: funcionalida-
de, confiabilidade, usabilidade e eficiência. No funcionalidade estão 
implícitas as seguintes características: adequação, acurácia, interopera-
bilidade, segurança de acesso e conformidade. A confiabilidade precisa 
estar em concordância com os seguintes critérios: maturidade, capaci-
dade de recuperação e tolerância a falhas. Já a usabilidade corresponde 
aos critérios de: aprendizagem, compreensibilidade, operacionalidade e 
atratividade. Por fim, a eficiência se relaciona aos critérios de: compor-
tamento ao longo do tempo e comportamento do recurso.
5. Gerência da qualidade de software
1. Tangibilidade, confiabilidade, sensibilidade, garantia e empatia.
Qualidade e Usabilidade de Software
– 170 –
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 acom-
panhar mudanças (controle de mudança); registrar a evolução do 
projeto (controle de versão); e estabelecer 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 projeto e, em vez de 
apontar os defeitos, acabam defendendo as qualidades do produto.
6. Fundamentos da interação 
homem-computador (IHC)
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, cre-
dibilidade, valor.
4. A IHC articula um grande número de conhecimentosadvindos de 
áreas diversas. É difícil encontrar um profissional que tenha conhe-
cimento de todas essas áreas, sendo necessária uma equipe multi-
– 171 –
Gabarito
disciplinar que trabalhe em conjunto, o que também constitui um 
desafio para toda a equipe e os gestores.
7. Usabilidade de software
1. O termo usabilidade refere-se à facilidade com que as pessoas podem uti-
lizar uma ferramenta. A usabilidade é considerada um atributo de qua-
lidade que avalia a facilidade 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). 
2. Facilidade de aprendizado, facilidade de uso, flexibilidade em relação 
às possibilidades 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 usa-
bilidade são obedecidas desde o projeto inicial do software. Quando 
isso ocorre, o sistema apresenta atributos relacionados à usabilidade, 
como a facilidade de aprendizado, 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 usabilida-
de ajuda na presteza e na redução de custo no desenvolvimento de ati-
vidades. Portanto, as recomendaçõ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 funcionários horistas, o que significaria uma 
duplicação de vendas e o aumento do número de usuários registra-
dos. Os custos com manutenção e revisão também são reduzidos e o 
Qualidade e Usabilidade de Software
– 172 –
produto é mais bem aceito pelos usuários, por todas as qualidades de 
usabilidade que apresenta, aumentando a probabilidade de recomen-
dação a possíveis usuários.
8. Acessibilidade e inclusão digital
1. Acessibilidade ao ambiente físico refere-se à qualidade que os espaços 
disponibilizam a todos, inclusive nos casos de deficiência de mobili-
dade ou comunicação, incluindo a possibilidade de: chegar a todos os 
lugares e edifícios sem esforço excessivo 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 uti-
lização, com seguranç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 in-
formaçã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 conjunto de elementos que facilitam o acesso à informação 
a todas as pessoas, de modo igualitário, usando a tecnologia (compu-
tadores, tablets, telefones móveis, entre outros) 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 Tecno-
logia (TAKAHASHI, 2000), a acessibilidade à informação e ao co-
nhecimento é a variável de maior poder de exclusão ou inclusão dos 
indivíduos no processo político e econômico.
– 173 –
Gabarito
2. Exclusão digital é o termo usado para se referir à consequência dire-
ta 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 podem ser socioeconômicas ou a capacidade 
de usar a tecnologia da informação de forma eficaz, devido aos dife-
rentes 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 exemplo, o HTML é utilizado apenas para a cria-
ção de conteúdo, enquanto a apresentaçã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 tabe-
las 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 uti-
lizado. 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 entendida como algo universal, e essa universalidade deve 
Qualidade e Usabilidade de Software
– 174 –
levar em conta o acesso, por qualquer pessoa, às informações forne-
cidas 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ís-
ticas técnicas dos equipamentos utilizados – é 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 inclu-
são digital está, portanto, inserida no movimento 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).
– 175 –
Referências
Referências
Qualidade e usabilidade de software
– 176 –
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 9241-11: Requisitos ergonômicos para trabalho de escri-
tórios com computadores. Rio de Janeiro, 2002.
______. NBR ISO/IEC 9126-1: Engenharia de software: qualidade de pro-
duto. 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.
ANDRADE, A. Usabilidade de interfaces web: avaliação heurística no jor-
nalismo on-line. Rio de Janeiro: E-papers, 2007.
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.projetointegrador.com.
br/~152M154200121/Modulo5/Auditoria%20e%20Qualidade%20de%20
Software/PI%20-%20Auditoria%20e%20Qualidade%20de%20Software.
pdf>. Acesso em: 2 ago. 2017.
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>. Acesso em: 3 ago. 2017.
BARBOSA, S. D. J. Interação humano-computador. Rio de Janeiro: 
Elsevier, 2011.
BARTIÉ, A. Garantia da qualidade de software: adquirindo maturidade 
organizacional. Rio de Janeiro: Elsevier, 2002.
BENYON, D. Interação humano-computador. 2. ed. São Paulo: Pearson 
Prentice Hall, 2011.
BONILA, M. H. S.; PRETTO, N. de L. (Org.). Inclusão digital: polêmica 
contemporânea. Salvador: EdUFBA, 2011. v. 2.
– 177 –
Referências
BOULDING, E. A. et al. Um modelo de processo dinâmico de qualidade do 
serviço: a partir de expectativas para as intenções comportamentais. Journal 
of Marketing Research,n. 30, p. 7-27, 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.
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 porta-
doras de deficiência ou com mobilidade reduzida, e dá outras providências. 
Diário Oficial da União, Brasília, DF, 20 dez. 2000.
______. Decreto n. 5.296 de 2 de dezembro de 2004. Regulamenta as Leis 
n. 10.048, de 8 de novembro de 2000, que dá prioridade de atendimento às 
pessoas que especifica, e 10.098, de 19 de dezembro de 2000, que estabe-
lece 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, 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%20ZANELA.pdf?se-
quence=1>. Acesso em: 9 fev. 2017.
CAIÇARA JUNIOR, C. Informática, internet e aplicativos. Curitiba: 
Ibpex, 2007.
CAMPOS, F. M. Qualidade, qualidade de software e garantia da quali-
dade de software são as mesmas coisas? Disponível em: <http://www.linha-
decodigo.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.
Qualidade e usabilidade de software
– 178 –
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.
CAVANO, J. P.; MCCALL, J. A. Proceedings of the Software Quality 
Assurance Workshop on Functional and Performance Issues. San Diego, 
1978.
CMMI INSTITUTE. Disponível em: <http://cmmiinstitute.com/capabi-
lity-maturity-model-integration>. Acesso em: 19 jul. 2017.
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 apli-
cações. 3. ed. São Paulo: Novatec, 2015.
DARIVA, R. Gerenciamento de dispositivos móveis e serviços de telecom: 
saiba tudo sobre aplicativos móveis, gerenciamento de dispositivos móveis e 
gerenciamento de custos de telecom. Rio de Janeiro: Elsevier, 2011.
DEMO, P. Pesquisa e construção do conhecimento: metodologia científica 
no caminho de Habermas. 2. ed. Rio de Janeiro: Tempo Brasileiro, 2005.
______. 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. Disponível em: <https://revistas.utfpr.edu.br/recit/article/view/4256>. 
Acesso em: 26 jan. 2017.
ERICSSON, K. A.; SIMON, H. A. Protocol Analysis: verbal reports asdata. 
Cambridge, MA: MIT Press, 1993.
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=i2pIB-
QAAQBAJ&printsec=frontcover&dq=engenharia+dos+requisitos&hl=p-
t-BR&sa=X&ved=0ahUKEwis6MX925PVAhXMIpAKHddiBhcQ6AEIK-
TAB#v=onepage&q&f=false>. Disponível em: 19 jul. 2017.
– 179 –
Referências
GANDARA, F. Qualidade e teste em software. São Paulo: Clube dos 
Autores, 2012.
GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. 
Rio de Janeiro: Qualitymark, 2015.
GODOI NETO et al. A importância do ciclo de vida no desenvolvimento 
de software. Disponível em: <http://revistaconexao.aems.edu.br/wp-con-
tent/plugins/download-attachments/includes/download.php?id=993>. 
Acesso em: 14 ago. 2017.
HAMPSON, P. J.; MORRIS, P. E. Understanding Cognition. Cambridge, 
MA: Blackwell Publishers, 1996.
IBM. Web accessibility for special needs. Disponível em: <http://www.
austin.ibm.com/sns/acessweb.html>. Acesso em: 9 fev. 2017.
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.
INMETRO. Avaliação da conformidade. Disponível em: <http://www.
inmetro.gov.br/noticias/conteudo/ac.asp>. Acesso em: 25 jul. 2017.
ISD BRASIL. O que é SCAMPI? Disponível em: <http://www.isdbrasil.
com.br/o-que-e-scampi.php>. Acesso em: 3 ago. 2017.
JOHNSTON, R. The determinants of service quality: satisfiers and dissatis-
fiers. International Journal of Service Industry Management, v. 6, n. 5, p. 
53-71, 1995.
JORDAN, P. W. An Introduction to Usability. Londres: Taylor & Francis, 
1998.
KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: aprenda as meto-
dologias e técnicas mais modernas para o desenvolvimento de software. 2007.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. São 
Paulo: Pearson Prentice Hall, 2004.
Qualidade e usabilidade de software
– 180 –
LAUDON, Kenneth; LAUDON, Jane. Sistemas de informação gerenciais. 
São Paulo: Pearson Prentice Hall, 2004.
LEITE, J. C. Design conceitual de software. Universidade Federal do Rio 
Grande do Norte, Natal, 2000. Notas de aula. Disponível em: <https://www.
dimap.ufrn.br/~jair/ES/c5.html>. Acesso em: 7 ago. 2017.
LÉVY, P. Cibercultura. Trad. C. I. da Costa. 1. ed. São Paulo: Ed. 34, 2000.
MARÇAL, A. S. C. et al. Estendendo o Scrum segundo as áreas de pro-
cesso 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.
MARINHO, J. J. Análise e desenvolvimento de requisitos em histórias em 
quadrinhos. Parte 2: a obscura diferença entre requisitos funcionais e requisi-
tos 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.
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software 
com PMI, RUP e UML. 5. ed. Rio de Janeiro: Brasport, 2010.
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.
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, p. 49, out. 2010.
– 181 –
Referências
MORIN, E. Os setes saberes necessários à educação do futuro. 2. ed. São 
Paulo: Cortez/Unesco, 1998.
MOUNTAIN GOAT SOFTWARE. The Scrum development process. 
Disponível em: <http://www.mountaingoatsoftware.com/Sc>. Acesso em: 1 
fev. 2017.
NEIL, T. Padrões de design para aplicativos móveis. São Paulo: Novatec, 
2012.
NIELSEN, J. Usability Enginnering. San Francisco, CA: Morgan 
Kaufmann, 1993.
NIELSEN, J.; TAHIR, M. Homepage usabilidade: 50 websitesdesconstruí-
dos. Rio de Janeiro: Campus, 2002.
PARASURAMAN, A.; ZEITHAML, V. A.; BERRY, L. L. Um modelo con-
ceitual de qualidade de serviço e suas implicações para futuras pesquisas. 
Journal of Marketing, n. 49, p. 41-50, 2005.
PEIRCE, C. S. Semiótica. Trad. de J. T. Coelho Neto. 3. ed. São Paulo: 
Perspectiva, 2005.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: 
Pearson Prentice Hall, 2004.
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.
PREECE, J.; ROGERS, Y; SHARP, H. Design de interação: além da inte-
ração homem-computador. Trad. de V. Possamai. Porto Alegre: Bookman, 
2005.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma aborda-
gem profissional. 8. ed. Porto Alegre: 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.
Qualidade e usabilidade de software
– 182 –
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. 
ed. Rio de Janeiro: Brasport, 2005.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interação: além da 
interação homem-computador. Trad. de I. Gasparini. 3. ed. Porto Alegre: 
Bookman, 2013.
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 orien-
tado a objetos. Tradução de A. Griesi. 7. ed. Porto Alegre: AMGH, 2010.
SCHNEIDER, H. N. Ergonomia das interfaces humano-computador 
como princípio de qualidade em EAD. Disponível em: <http://www.
uece.br/endipe2014/ebooks/livro4/23.%20ERGONOMIA%20DAS%20
INTERFACES%20HUMANO-COMPUTADOR%20COMO%20
PRINC%C3%8DPIO%20DE%20QUALIDADE%20EM%20EaD.pdf>. 
Acesso em: 7 ago. 2017.
SCHWABER, K. Agile Project Management with Scrum. Redmond, WA: 
Microsoft Press Books, 2004.
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%20
texto%20Gilson%20Schuartz%2009_06.pdf>. Acesso em: 8 ago. 2017.
SILVA, R. B. C; AZEVÊDO, L. S. L. A importância da engenharia de tes-
tes para a qualidade de software. Revista Eletrônica Científica Inovação e 
Tecnologia, v. 2, n. 12, jul./dez. 2015.
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 inclu-
são digital. Salvador: EdUFBA, 2008.
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson 
Prentice Hall, 2011.
– 183 –
Referências
SOUZA, C. S. de et al. Projeto de interfaces de usuário: perspectivas cognitiva e 
semiótica. In: JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 19., 
CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 
1999, Rio de Janeiro. Anais... Rio de Janeiro, 1999.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do 
tempo. Trad. de N. Gerhardt. São Paulo: LeYa, 2014.
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.
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.
VASQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software 
orientado ao negócio. Rio de Janeiro: Brasport, 2016.
WARSCHAUER, M. Tecnologia e inclusão social: a exclusão digital em 
debate. São Paulo: Senac-SP, 2006.
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. São Paulo: 
Makron Books, 2006.
______. Qualidade e produtividade em software. 4. ed. São Paulo: Makron 
Books, 2012.
QUALIDADE E USABILIDADE 
DE SOFTWARE
Christina Paula de Camargo Curcio
Te
cn
o
lo
g
ia
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
hr
is
tin
a 
P
au
la
 d
e 
C
am
ar
g
o 
C
ur
ci
o
Neste livro vamos apresentar os conceitos fundamentais relacionados à quali-
dade de software, métricas, normas e orientações sobre a gestão da qualida-
de. Após este estudo, esperamos que você tenha facilidade para reconhecer 
a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus 
próprios projetos, identificando os requisitos necessários para o desenvolvi-
mento de um software com qualidade.
Fundação Biblioteca Nacional
ISBN 978-85-387-6296-6
9 788538 762966
CAPA_Qualidade e Usabilidade de Software.indd 1 17/08/2017 10:09:01
	Página em branco
	Página em branco