Livro - Qualidade e Usabilidade de Software

Christina Paula de Camargo Curcio
Neste livro vamos apresentar os conceitos fundamentais relacionados à quali- QUALIDADE E USABILIDADE
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 DE SOFTWARE
QUALIDADE E USABILIDADE
DE SOFTWARE
a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus Christina Paula de Camargo Curcio
próprios projetos, identificando os requisitos necessários para o desenvolvi-
mento de um software com qualidade.
Tecnologia
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

Qualidade e
Usabilidade de
Software
IESDE BRASIL S/A

Curitiba
2017
© 2017 – IESDE Brasil S/A. É proibida a reprodução, mesmo parcial, por qualquer
processo, sem autorização por escrito da autora e do detentor dos direitos autorais.
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q Curcio, Christina Paula de Camargo

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.
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
Todos os direitos reservados.

Produção
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
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.
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!
– 6 –
1
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.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.
Pessoas e Integração e
definição de requisitos melhoria contínua
Garantia da
qualidade de software
Métodos Ferramentas
Fonte: Elaborada pela autora.

De acordo com a Figura 1, para se garantir a qualidade de um 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
– 8 –
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):
22 Operações de produtos: as características operacionais.
22 Correção: grau em que um programa atende sua especificação e
atinge os objetivos definidos pelo usuário.
22 Confiabilidade: nível de execução esperada de um software para
realizar as funções com precisão.
22 Eficiência: número de computadores e recursos exigidos pelo pro-
grama para executar suas funções com o tempo de resposta adequado.
22 Integridade: medida em que pode ser controlado o acesso ao software
ou dados por usuários não autorizados.
22 Facilidade de uso: esforço necessário para aprender, usar e interpre-
tar a funcionalidade do sistema.
22 Revisão do produto: capacidade de resistir a mudanças de tecnologia.
– 9 –
22 Facilidade de manutenção: necessária para localizar e corrigir um

bug no sistema.
22 Flexibilidade: esforço necessário para modificar um programa.
22 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.
22 Transição do produto: capacidade de adaptação a novos ambientes.
22 Portabilidade: necessária para transferir um programa de um
ambiente de hardware ou software a outra tecnologia.
22 Reutilização: grau em que um componente de programa ou
software pode ser reutilizado em outras aplicações.
22 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):
22 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.
22 Planejamento de projeto: busca refinar e detalhar os objetivos do
projeto e planejar o trabalho necessário para alcançá-los.
– 10 –
22 Monitoramento e controle de projetos: consiste em medir e coletar

informações sobre o desempenho do projeto, assim como informar
os envolvidos.
22 Gestão de fornecedores: é o processo de adoção de boas práticas e
de controle e gestão dos fornecedores.
22 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
– 11 –
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:
22 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.
22 Projeto: é o que concretiza um processo.
22 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
– 12 –
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.
– 13 –
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).
– 14 –
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):
22 desperdício de tempo antes do início do projeto;
22 pressões por prazos otimistas e o não cumprimento destes por
serem impossíveis;
– 15 –
22 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;
22 falha no método de gerir o projeto;
22 pressa para começar a etapa de codificação;
22 falha na subcontratação de serviços; e
22 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
– 16 –
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ça de
tecnologia e a substituição desta no meio de um projeto, falta de automação
de atividades como as de gestão de configurações, ausência de ferramenta de
modelagem e automação de atividades de testes.
1.2.2 Modelos de ciclo de vida

Para a existência de um processo de desenvolvimento de software, é 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.
22 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.
22 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.
– 17 –
22 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.
22 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.
22 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.
22 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.
22 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.
– 18 –
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
– 19 –
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 mapeados e robustos, um projeto de desenvolvimento de software
inicia de forma incorreta, já que aqueles são a base deste. O mesmo se aplica
quando a gestão é deficiente. Mais uma vez, os indicadores dos 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
– 20 –
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
– 21 –
revisões devem ser contínuas ao longo de todo o projeto de desenvolvimento

do software.
Figura 2 – Processos de qualidade do software.
Qualidade do software – conjunto de caracterísiticas de um sistema para atender os requisitos das partes interessadas.
Gestão da qualidade do software – direção e coordenação das atividade de qualidade de software
Melhoria da qualidade do software – processo de melhoria contínua
Revisão dos
processos de
qualidade
Planejamento Controle da Garantia da
da qualidade qualidade qualidade
22 Estabelecer os 22 Cumprir os obje- 22 Garantir que os re-

objetivos, pro- tivos e requisitos quisitos de qualidade
cessos e recursos de qualidade sejam cumpridos

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.
– 22 –
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).
– 23 –
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):
22 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.
22 Projeto: menos significativo que o anterior, mas que não deixa de
produzir impacto no retorno de investimento.
22 Garantia da qualidade: as atividades de garantia da qualidade – as
que mais sofrem devido à pressa para entrega de um produto – dão
retorno quando as necessidades de se refazer as etapas iniciais de
um processo tendem a diminuir.
22 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)
– 24 –
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.
– 25 –
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?
– 26 –
2
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.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):
22 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.
22 Unificar – a ideia é criar um padrão para os produtos, utilizado em
todas as partes do mundo para permitir trocas internacionais.
22 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.
– 28 –
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
– 29 –
Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas Sanitárias e

Fitossanitárias, ao qual todos os membros da OMC devem aderir (CAIÇARA
JR., 2007). Esses acordos são uma tentativa de reduzir o impacto das normas
e regulamentações usadas como barreiras técnicas ao comércio entre os países
(CYBIS et al., 2015).
2.2 Normas ISO e modelos CCMI
2.2.1 ISO
As normas ISO são amplamente respeitadas e aceitas 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
– 30 –
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.
– 31 –
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):
22 Melhorar os processos relacionados com a produção e manutenção
de software;
22 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):
– 32 –
Normas e padrões
22 Uma maneira de integrar os elementos funcionais de uma organização;

22 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;
22 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;
22 Um suporte às empresas em atividades produtivas complexas para
coordenar as suas atividades;
22 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 de avaliação por áreas de resultado-chave ARC (Appraisal Requirements for
CMMI) descreve requisitos para diferentes tipos de avaliação, buscando uma uniformidade
entre os métodos (CARNEGIE MELLON UNIVERSITY, 2006).
– 33 –
Figura 3 – Níveis de maturidade do CMMI.
5 - Otimizado
Processo con-
4 - Gerenciado tinuamente
Processo previ- melhorado
3 - Definido sível e contro-
Processo lado
2 - Repetível consistente e
Processo disci- padronizado
1 - Inicial plinado
Processo im-
previsível e sem
controle
Fonte: Elaborada pela autora, com base em CMMI INSTITUTE, 2017.

Esses níveis de maturidade de processos de uma organização são 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
– 34 –
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
– 35 –
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.
– 36 –
Normas e padrões
O quadro a seguir explica resumidamente o que acontece em cada um

desses níveis.
Quadro 1 – Características dos níveis de maturidade das organizações.
Nível Características
22 Basicamente nenhuma prática forma de gerenciamento de enge-
nharia de software está implantada na organização.
22 Tudo é feito à medida em que vão surgindo as necessidades.
22 O padrão usual é o não cumprimento de prazos e orçamentos estabelecidos.
Inicial
22 A maioria das atividades são respostas a crises e não a tarefas pré-planejadas.
22 O processo de software é imprevisível e depende totalmente da equipe atual.
22 É impossível prever com precisão o tempo necessário para
desenvolver um produto ou o seu custo.
22 Já estão implantadas práticas básicas de gerenciamento
de projetos de software.
22 As técnicas de planejamento e gerenciamento se baseiam em expe-
riências com produtos similares (daí o termo repetível).
Repetível 22 Há o acompanhamento meticuloso dos cronogramas
de prazo e da planilha de custos.
22 Os gerentes identificam problemas à medida que eles vão surgindo e tomam
ações corretivas imediatas para evitar que eles se transformem em crises.
22 Medidas tomadas durante um projeto podem ser usadas para elaborar
cronogramas e orçamentos realistas para projetos futuros.
22 O processo para a produção de software é completamente documentado;
22 Tanto aspectos técnicos quanto gerenciais do
processo são claramente definidos.
Definido 22 São feitos esforços contínuos para melhorar o processo onde for possível.
22 São usadas revisões para atingir as metas de qualidade de software.
22 Há a introdução de novas tecnologias, como as ferramentas CASE
para aumentar a produtividade.
– 37 –
Nível Características
22 A organização estabelece metas de qualidade
e produtividade para cada projeto.
22 A qualidade e a produtividade são medidas continuamente.
Gerenciado 22 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis das metas.
22 Controles estatísticos de qualidade são implantados para a gerência
ser capaz de distinguir o desvio esporádico de um problema
significativo nos padrões de qualidade ou produtividade.
22 Há aperfeiçoamento contínuo do processo.
22 São usadas técnicas de controle estatístico de processos
e qualidade para orientar a organização.
Otimizado
22 O conhecimento adquirido em cada projeto é utilizado em projetos futuros.
22 O processo incorpora uma curva de realimentação positiva, resultando
em uma melhoria contínua na produtividade e na qualidade.
Fonte: Elaborado pela autora, com base em SCHACH, 2010, p. 93-94.
Dependendo do modelo de representação usada em CMMI, existem
duas maneiras de realizar a melhoria de processos. Uma delas é utilizando
a representação contínua e a outra é melhorando toda a organização, de
acordo com os processos definidos. A representação contínua se concentra em
melhorar um procedimento de modo que a organização possa ser certificada
para uma área de processo, em um determinado nível de capacidade. Existem
seis níveis de capacidade ao longo dos quais os processos são associados em
uma área (Quadro 2), e cada um deles é construído sobre o nível anterior –
ou seja, um processo, para chegar a determinado nível de capacidade, deve
necessariamente ter atingido um nível anterior (CAIÇARA JR., 2007).
– 38 –
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
Manejado quantitativamente
Nível 4 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:
22 Nível 0 – Incompleto – um processo é chamado de incompleto
quando um ou mais objetivos da área de processo não estão
em conformidade.
22 Nível 1 – Realizado – é chamado de feito ou realizado o processo
que satisfaz todas as metas específicas da área de processo.
22 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
– 39 –
que tenham recursos adequados para produzir saídas controladas.

É monitorado, controlado, revisto e avaliado de acordo com sua
descrição específica.
22 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.
22 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.
22 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.
Nível de
Área de processo Categoria
maturidade
Análise e resolução das causas Suporte 5
Análise e resolução das decisões Suporte 3
– 40 –
Normas e padrões
Nível de
Área de processo Categoria
maturidade
Assegurando a qualidade dos processos e produtos Suporte 2
Definição de produtos organizacionais Gestão de processos 3
+IPPD (OPD +IPPD)
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
– 41 –
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:
22 operação do produto (usá-lo);
22 revisão do produto (alterando-o);
22 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.
– 42 –
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:
22 Exatidão: é o grau em que o software executa a sua função.
22 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.
22 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.
22 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.
– 43 –
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.
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
– 44 –
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?
– 45 –
3
Influência dos requisitos
na qualidade do software
Introdução
O processo de análise e verificação das necessidades de um
cliente/usuário1 para o desenvolvimento de um sistema é chamado
de engenharia de requisitos. O objetivo da engenharia de requisitos é
entregar um software correto e completo, de acordo com especifica-
ções predeterminadas.
Os requisitos são a peça fundamental para um projeto de
desenvolvimento de software com qualidade, que exige 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).
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).
– 48 –
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
documento formalmente 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):
22 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.
22 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.
– 49 –
documento muito extenso acaba dificultando o processo, pois sua

leitura e interpretação demandam mais tempo.
22 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.
22 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.
22 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.
22 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.
– 50 –
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:
Requisito: Manter
Identificador: RF001
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.
Requisito: Registrar
Identificador: RF003
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.
– 51 –
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
plano de projeto e acompanhamento
Gerência de – escopo, orçamento e prazo
Projetos
necessidades do Análise e projeto da solução
cliente
cliente projeto
projeto do banco de dados

acordos sobre Implementação
a entrega
material de treinamento e de suporte
Implantação ao usuário
Facilita a interação
com o cliente
estimativas e medições
Medição e análise
Testes casos de teste
equipe
Fonte: VASQUEZ; SIMÕES, 2016, p. 12.
– 52 –
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):
22 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.
22 Avaliação e negociação – processo de avaliação e negociação de
melhorias com o cliente ou stakeholder.
22 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.
22 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.
22 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.
22 Princípios de especificação – processo de representação dos requi-
sitos do 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.
– 53 –
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.
– 54 –
22 documentar de forma correta e fidedigna todas as necessidades do

cliente/usuário;
22 obter aprovação (aceite) sobre tudo o que está sendo proposto para
se entregar em termos de produto;
22 ajudar a equipe de desenvolvimento a compreender exatamente o
que os clientes/usuários desejam;
22 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:
22 Visão geral – em que se apresenta os objetivos do projeto,
as partes interessadas e o escopo preliminar com as funções
descritas brevemente.
22 Glossário – definição dos termos técnicos e de siglas usados
no documento.
22 Modelos de sistema – em que se mostra o relacionamento entre os
componentes do sistema.
22 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)”.
22 Lista de requisitos não funcionais – em que se descreve
as restrições impostas sobre o software, relacionando-as aos
requisitos funcionais.
– 55 –
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).
22 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.
– 56 –
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 sem surpresas desagradáveis são
bem maiores.
Para tanto, é preciso que a comunicação entre as partes interessadas flua
sem ruídos, que a entrevista seja direta e planejada, que os gestores estudem
com os analistas as 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.
– 57 –
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.
Esforço
para obter
qualidade
Modelo de Análise e Implemen- Testes de Disponibili-

Requisitos
negócios modelagem tação software zação
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).
– 58 –
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.
Processo de garantia da qualidade de software

Requisitos
Tempo

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.
– 59 –
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.
– 60 –
Quadro 1 – Subcategorias do requisito confiabilidade.

Risco R001 – indisponibilidade do sistema para o usuário
Características Subcaracterísticas Objetivo Questão Métrica
Avaliar a capaci- Quantas falhas foram
dade de preven- detectadas durante Número de falhas
Maturidade ção de falhas do um período definido detectadas/número
sistema do ponto de experimentação? de casos de testes
de vista do usuário.
Número de ocorrências
Quantos padrões de de falhas sérias e críticas
defeitos são man- evitadas conforme os
tidos sob controle casos de testes de indu-
para evitar falhas ção de falhas/número de
críticas e sérias? casos de testes de indu-
ção de falhas executados
Tempo de operação
(tempo de operação +
tempo de reparo)
Total de casos em que o
Quão disponível é
o sistema para uso sistema estava disponível
Confiabilidade e foi utilizado com
durante um período sucesso pelo usuário
Tolerância Avaliar a de tempo específico? número total de casos/
disponibilidade do
a falhas de em que o usuário tentou
recuperabilidade sistema do ponto
de vista do usuário. usar o software durante
um período de tempo.
Qual é o tempo médio
em que o sistema Tempo ocioso total
fica indisponível (indisponível)/número
quando uma falha de quedas do sistema
ocorre, antes da
inicialização?
Soma de todos os
Qual o tempo médio tempos de recuperação
que o sistema leva do sistema inativo em
para completar cada oportunidade/
a recuperação número total de casos
desde o início? em que o sistema entrou
em recuperação
Fonte: WAZLAWICK, 2013, p. 248.
– 61 –
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.
– 62 –
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.
– 63 –
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.
Esforço
para obter
qualidade

Requisitos
Tempo
– 64 –
4
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).
Qualidade e usabilidade de software
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).
– 66 –
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.
22 Estudo de viabilidade – identifica as deficiências atuais, estabelece
objetivos do novo sistema; gera cenários aceitáveis; prepara encar-
gos de projeto.
22 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.
22 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.
22 Implementação – soluciona o próximo módulo; codifica o módulo;
testa o esqueleto do sistema.
22 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.
22 Garantia da qualidade – faz o teste final ou teste de aceite, compa-
rando o produto ao projeto de implementação.
22 Descrição dos procedimentos – faz descrições das atividades opera-
cionais do cliente ou usuário.
22 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.
– 67 –
22 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.
Implementar a
primeira versão
Modificar até que

o cliente fique satisfeito
Manutenção pós-entrega
Desenvolvimento Descontinuação
Manutenção do produto
Fonte: SCHACH, 2010, p. 50.
– 68 –
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.
– 69 –
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
– 70 –
entanto, na realidade o desenvolvimento de um software não ocorre dessa

forma, pois muitas atividades são desenvolvidas paralelamente.
As etapas do modelo em cascata são apresentadas a seguir:
22 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.
22 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.
22 Implementação – é a etapa em que são criados os programas.
22 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.
22 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).
– 71 –
4.1.3 Modelo V
Esse modelo de ciclo de vida foi concebido por Alan Davis e contém as
mesmas etapas do ciclo de vida em cascata, sendo considerado uma variação
deste, como se pode observar na Figura 3.
Figura 3 – Modelo V.
Modelagem Teste
de requisitos de aceitação
Projeto da Teste
arquitetura de sistema
Projeto Teste
de componente de integração
Geração Teste de
de código unidade
Software
executável
Fonte: PRESSMAN; MAXIM, 2016, p. 43.

Segundo a figura, o projeto segue de forma sequencial e linear até a
geração de códigos (lado esquerdo do V) e, a partir daí, a equipe passa para
o outro lado do V, realizando testes que validam cada fase do lado esquerdo.
Segundo Pressman e Maxim (2016, p. 42), “não há nenhuma diferença 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.
– 72 –
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.
Custo acumulativo
Progresso
1. Determinar objetivos 2. Identificar e
resolver riscos
Análise
de riscos
Análise
de riscos
Plano de Análise de riscos
Revisão requeri- Protótipo
mentos Protótipo 1 Protótipo 2 operacional
Conceito Conceito de
de operação Requeri- Requeri-
mentos mentos Esboço
Desenho
Plano de detalhado
desenvolvimento Verificação
e validação
Código
Plano de Verificação
testes e validação Integração
Testes
Entrega Implementação
4. Planejar a próxima iteração 3. Desenvolvimento e testes
Fonte: TORRES, 2014.

No modelo em espiral, as atividades são realizadas no sentido horário,
partindo do centro da espiral e passando por quatro quadrantes. A fase 1 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,
– 73 –
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).
– 74 –
método precisa de equipes disciplinadas e experientes, o projeto deve ser bem

realizado para que a estrutura do produto permaneça confiável ao longo dos
protótipos e ele é mais difícil de ser gerido (WAZLAWICK, 2003).
Figura 5 – Prototipagem evolutiva.
Planejamento
rápido
Comunicação
Modelagem
Projeto rápido
Entrega e
feedback Construção
de protótipo
Fonte: PRESSMAN; MAXIM, 2016, p. 45.

O ciclo da prototipação começa com a fase de comunicação, coleta e
refinamento dos requisitos. As fases seguintes são: o planejamento rápido,
a modelagem rápida (na qual é desenvolvido o protótipo) e a construção do
protótipo. Por fim, a fase de implantação, 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.
– 75 –
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,
– 76 –
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.
Processo de software
Processo de
desenvolvimento
Usuário Desenvolvedor Organização Requisito Padrões
Requisitos Padrões
Software com qualidade atendidos atendidos Software produto

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
– 77 –
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.
– 78 –
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
22 O teste de validação é realizado para checar se há algum erro.
Comparação
22 Compara a saída de um uso específico com um sistema de

dados previamente criado com os mesmos parâmetros.
Testes de usabilidade
22 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):
22 Funcionalidade – O produto satisfaz as necessidades do usuário?
22 Confiabilidade – É imune a falhas?
– 79 –
22 Usabilidade – É fácil de usar?

22 Eficiência – É rápido e simples?
22 Manutenibilidade – É fácil de modificar?
22 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 atributos que 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.
– 80 –
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):
22 Valorização das pessoas e suas interações sobre processos e ferra-
mentas – processos de qualidade com bons relacionamentos trazem
bons resultados.
22 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.
22 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
– 81 –
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):
22 Incerteza – indica a necessidade estratégica da previsão de riscos no
desenvolvimento.
22 Equipes auto-organizadas – não existem funções especializadas na equipe.
22 Autonomia – liberdade para a tomada de decisão.
22 Autoaperfeiçoamento – periodicamente, o produto tem de ser
desenvolvido e avaliado.
22 Autoenriquecimento – conhecimento e transferência de conhecimento.
22 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).
22 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
– 82 –
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.
Daily meeting
24 horas
Tarefas de Backlog
detalhadas
pela equipe 30 dias Produto incremental
a ser entregue
Backlog da Sprint
Backlog
priorizado pelo
Product Owner
Fonte: MOUNTAIN GOAT SOFTWARE, 2017.

A estrutura de processo do Scrum inicia-se com uma visão do produto
que será 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.
– 83 –
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 estrutura da 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.
– 84 –
Esse indicador deve corresponder aos critérios de (PFLEEGER, 2004):

22 adequação – o conjunto de indicadores para assegurar que o con-
teúdo é adequado;
22 precisão, interoperabilidade6 e segurança – sua definição está em
consonância com a função adequada que executa;
22 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):
22 maturidade – deve ser compreendido como a capacidade de se
repetir uma série de resultados de maneira previsível;
22 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;
22 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):
22 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).
– 85 –
22 compreensibilidade – o conjunto de indicadores para assegurar a

compreensão dos elementos que o compõem;
22 operacionalidade – definida de acordo com a função correta que
ele executa;
22 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:
22 comportamento ao longo do tempo – definido em correspondên-
cia com a função adequada que o produto executa;
22 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.
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.
– 86 –
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,
– 87 –
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?
– 88 –
5
Gerência da qualidade
de software
Introdução
A gerência da qualidade do software garante que o nível de
qualidade exigido pelo cliente seja alcançado por meio de melhorias
no processo de desenvolvimento do produto. Esse tipo de gestão
visa desenvolver uma cultura de aprimoramento dentro da equipe e
é visto como responsabilidade de todos.
A gerência de qualidade deve ser independente da gestão do
projeto, para garantir que o software seja elaborado com qualidade
e dentro do prazo e do custo estipulados. Essa gestão afeta dire-
tamente a qualidade do desenvolvimento do processo e, indireta-
mente, a qualidade do produto.
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,
– 90 –
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.
– 91 –
Figura 1 – Dimensões da qualidade segundo Garvin (2015).
Desempenho
Confiabilidade Recurso
Qualidade Dimensões
Conformidade
percebida de qualidade
Facilidade
Durabilidade
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.
– 92 –
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:
22 softwares aplicativos – são programas de computador criados para
ajudar os usuários a desempenhar tarefas específicas;
22 softwares de sistema – programas de sistema operacional que con-
trolam e apoiam todas as operações de um sistema de computador;
22 procedimentos – todas as orientações que o usuário final utiliza
para navegar no sistema operacional.
– 93 –
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 apresenta maior confiabilidade? O sistema 1 é mais
confiável ao usuário, já o sistema 2 apresenta maior disponibilidade, pois as
falhas são corrigidas rapidamente.
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.
– 94 –
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
– 95 –
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
– 96 –
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
– 97 –
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 tornem defeitos após a entrega do
produto. Estudos indicam que as atividades de design2 introduzem entre 50%
e 65% de todos os erros (e, finalmente, todos os defeitos) durante o 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).
– 98 –
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

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

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.
– 99 –
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):
22 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.
– 100 –
22 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.
22 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.
22 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.
22 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
– 101 –
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):
22 controlar e acompanhar mudanças (controle de mudança);
22 registrar a evolução do projeto (controle de versão);
22 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ão
consistentes. 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
– 102 –
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:
22 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.
22 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.
22 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.
22 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.
22 Teste de integração – nele são avaliados vários componentes do
software, combinados e testados em grupo.
22 Teste operacional – nele é verificado se a aplicação responde ao
tempo de execução do sistema.
22 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.
22 Teste de caixa branca – todas as entradas e saídas desejadas do
sistema são testadas e é observado o resultado esperado.
– 103 –
22 Teste de configuração – nele se avalia se a aplicação funciona cor-

retamente em diferentes configurações de hardware e software.
22 Teste de interface – é avaliada a navegabilidade e se cada compo-
nente responde conforme especificado pelo usuário.
22 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.
22 Teste de aprovação do usuário – nele o usuário realiza os testes
operacionais e se sua aplicação é funcional.
22 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.
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.
– 104 –
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.
[...]
– 105 –
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.
– 106 –
6
Fundamentos da interação
homem-computador (IHC)
Introdução
A adaptação às novas ferramentas tecnológicas é complexa.
Para alguns indivíduos, ela acontece rapidamente; outros, no
entanto, devido à heterogeneidade 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.
De modo geral, a IHC estuda as trocas de informações por meio de

software entre pessoas e computadores, “relacionando tudo que estiver
envolvido na interação entre usuários e computadores, seja aspectos físicos,
psicológicos, práticas de trabalho, relações sociais, saúde etc.” (ANDRADE,
2007, p. 36). Essa disciplina é responsável pela concepção, avaliação e
implementação de dispositivos de tecnologia interativa.
O objetivo de se estudar essas interações emerge da necessidade de que
elas sejam mais eficientes, a fim de minimizar erros, aumentar a satisfação do
usuário, reduzindo eventuais frustrações e, finalmente, tornar mais 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
– 108 –
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 Engenharia
organizacional
Psicologia
Design
cognitiva
IHC
Ciência da
Antropologia
computação
Inteligência Sociologia
artificial
Linguística Filosofia
Fonte: PREECE, 1997, apud ANDRADE, 2007, p. 36.

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
– 109 –
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
– 110 –
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).
– 111 –
Figura 3 – Experiência do usuário honeycomb.
Utilidade
Usabilidade Desejo
Valor
Encontrabilidade Acessibilidade
Credibilidade
Fonte: MORVILLE apud MATTHEWS, 2009, p. 85.

A figura da colmeia deixa claro que é preciso pensar a experiência do
usuário além da usabilidade, que é apenas uma das facetas do diagrama.
Segundo Benyon (2011), as sete células do “favo de mel” representam os
parâmetros que devem ser cuidadosamente 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”:
22 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:
– 112 –
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.
22 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?
22 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?
22 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?
22 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?
22 Credibilidade – Um dos pontos fortes do software é a reputação
de ser confiável. Isso significa que ele deve funcionar perfeitamente,
– 113 –
sem travar ou dar mensagens de erro. A pergunta que deve ser feita
é: O usuário pode confiar nesse software?
22 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
– 114 –
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
– 115 –
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
– 116 –
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):
22 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;
22 métodos para avaliar e comparar as interfaces no que diz respeito a
suas propriedades, por exemplo, sua capacidade de uso;
22 métodos para estudar o uso de computadores e suas implicações
socioculturais;
22 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ências que 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
– 117 –
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:
22 janelas;
22 caixas de diálogo;
22 botões;
22 barras de rolagem;
22 menus;
22 caixas de mensagem; etc.
A figura a seguir demonstra a disposição desses objetos em uma interface:
Figura 5 – Objetos de interação.
Caixa de
mensagem
Barra de
rolagem
Botões
Janela
Fonte: IESDE BRASIL S./A.

A Figura 6 traz exemplos de pop-ups, janelas que abrem no navegador
quando uma página é acessada. Geralmente traz publicidade (anúncios) ou
mensagens de redirecionamento de links.
– 118 –
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:
22 a expressão: aquilo que ele representa;
22 o objeto: aquilo que é representado;
22 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
– 119 –
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.
– 120 –
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
– 121 –
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):
22 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.
22 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.
22 Princípios de design de interface – Deve-se considerar em todos os
momentos, ao se projetar a interface para o usuário:
22 a simplicidade (deve ser de fácil utilização);
22 a visibilidade (deve ser visível para facilitar a usabilidade);
22 a viabilidade (deve ter design projetado com orçamento
adequado);
22 a coerência (deve ser feito em conformidade com o requerido
pelos usuários);
22 a estrutura (deve ter uma estrutura que permita a navegabilidade);
– 122 –
22 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.
Domínio do controle Domínio do controle
do homem do computador
Responder Ler-examinar
Ação do usuário gerando Reconhecimento e interpreta-
input para o computador ção dos inputs do usuário
I
N
Pensar
T Pensar
Tomada de deci-
E Processamento
sões (o que fazer
HOMEM R COMPUTADOR de input de
com a resposta
F acordo com os
recebida do
A algoritmos
computador)
C
E
Ler-examinar Responder
Reconhecimento e interpretação Resposta do computador envia-
da informação apresentada pelo da ao usuário
computador
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
– 123 –
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.
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.
– 124 –
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
– 125 –
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?
– 126 –
7
Usabilidade de software
Introdução
A usabilidade é considerada um atributo de qualidade que
avalia a facilidade com que uma interface gráfica de software é 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.
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 de usabilidade 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.
– 128 –
Essas são definições centradas no conceito de qualidade em uso, ou seja,

referem-se à forma como o usuário executa determinadas tarefas em cenários
específicos, de forma eficaz.
Tendo por base esses conceitos dados pela ISO, os princípios básicos
da usabilidade podem ser assim definidos: facilidade de uso, facilidade de
aprendizado, flexibilidade e robustez. O Quadro 1, a seguir, explica cada um
desses princípios:
Quadro 1 – Princípios de usabilidade.
Princípio Característica
Facilidade com que o usuário faz uso da ferramenta,
Facilidade
de uso com menos etapas para chegar a seu objetivo proposto,
estando relacionada à eficiência da ferramenta.
Facilidade de Facilidade com que novos usuários desenvolvem uma interação com o
aprendizado sistema ou produto, relacionada com a familiaridade e a previsibilidade.
Relacionada à diversidade de formas de executar uma deter-
Flexibilidade minada tarefa e otimização entre usuário e sistema.
Facilidade e nível de serviço oferecido de suporte para cum-
Robustez 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.
– 129 –
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:
22 a variedade de itens a organizar é tão grande que nenhuma taxono-
mia existente é aceita como organização dos itens;
22 as semelhanças entre os itens tornam difícil uma divisão clara
em categorias;
– 130 –
22 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.
– 131 –
Essa metodologia de avaliação pode ser usada com:

22 um produto existente que deve ser melhorado ou ampliado;
22 um protótipo ou uma simulação parcial precoce;
22 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
– 132 –
ou problemas de usabilidade. Também abrange requerimentos para uma nova

interface, com base 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.
– 133 –
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.
– 134 –
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
– 135 –
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ção do 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”.
– 136 –
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.
– 137 –
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
– 138 –
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
– 139 –
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ções
funcionam 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.
Às vezes também
Conceito Como utilizar
chamado de
Estabeler critérios de usabilidade para
avaliar a aceitabilidade de um sis-
Metas usabilidade tema (p. ex: “Quanto tempo leva para
a realização de uma tarefa?”)
– 140 –
Às vezes também
Conceito Como utilizar
chamado de
Identificar os aspectos importan-
Metas decorrentes tes da experiência do usuário (p. ex:
da experiência Fatores de satisfação “Como se pode tornar o produto inte-
do usuário rativo divertido e agradável?”)
Como lembretes do que fornecer e do
Heurística, quando
Princípio que evitar durante o design da inter-
utilizado na prática.
de design face (p. ex: “que tipo de feedback
Conceitos de design. você vai fornecer na interface?”)
Avaliar aceitabilidade das interfa-
Princípio de Heurística, quando ces, utilizadas durante a avaliação
usabilidade utilizado na prática. heurística (p. ex: “O sistema oferece
saídas claramente indicadas?”)
Determinar se uma interface adere a uma
regra específica, quando está sendo projetada
Regras 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
– 141 –
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.
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
– 142 –
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
– 143 –
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?
– 144 –
8
Acessibilidade e
inclusão digital
Introduçã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
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,
– 146 –
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.
– 147 –
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.
– 148 –
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
– 149 –
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>.
– 150 –
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):
22 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
– 151 –
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.
22 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.
22 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 desenvolvedor
a 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,
– 152 –
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).
– 153 –
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
– 154 –
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ção
necessá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
– 155 –
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
– 156 –
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:
22 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
– 157 –
realizado em 2004 por Mark Mulcahy, um programador cego que

trabalhou na Sun Microsystems.
Disponível em: <https://wiki.gnome.org/Projects/Orca>.
22 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/>.
22 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>.
22 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>.
22 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>.
22 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>.
– 158 –
Disponível em: <http://www.cstr.ed.ac.uk/projects/festival/>.

22 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>.
22 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>.
22 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/>.
22 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>.
22 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/>.
– 159 –
8.3.2 Deficiência motora

Os softwares destacados a seguir são destinados para aqueles usuários
que apresentam deficiência motora.
22 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/>.
22 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/>
22 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/>.
– 160 –
22 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/>.
22 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/>.
22 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.
– 161 –
É 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”.
– 162 –
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
– 163 –
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 diferentes contextos.
2. O que é exclusão digital e quais são suas consequências?
3. Quais conceitos estão presentes no desenvolvimento de sites acessíveis?
4. Explique a relação entre inclusão digital e inclusão social.
– 164 –
Gabarito
Gabarito
– 165 –
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
– 166 –
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:
22 Melhorar os processos relacionados com a produção e manuten-

ção de software.
22 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:
22 operação do produto (usá-lo);

22 revisão do produto (alterando-o);
22 transição do produto (modificando-o para trabalhar em um
ambiente diferente).
4. Inicial, repetível, definido, gerenciado e otimizado.
– 167 –
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
– 168 –
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.
– 169 –
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 conhecimentos advindos de

áreas diversas. É difícil encontrar um profissional que tenha conhe-
cimento de todas essas áreas, sendo necessária uma equipe multi-
– 170 –
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
– 171 –
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.
– 172 –
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
– 173 –
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).
– 174 –
Referências
Referências
– 175 –
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.
– 176 –
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.
– 177 –
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.
– 178 –
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.
– 179 –
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 s oftware
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.
– 180 –
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 websites desconstruí-
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.
– 181 –
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>.
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
– 182 –
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>.
TORRES, L. F. Fundamentos do gerenciamento de projetos. Rio de

Janeiro: Elsevier, 2014.
VALERIANO, D. Moderno gerenciamento de projetos. São Paulo: Pearson

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.
– 183 –
Neste livro vamos apresentar os conceitos fundamentais relacionados à quali- QUALIDADE E USABILIDADE
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 DE SOFTWARE
QUALIDADE E USABILIDADE
DE SOFTWARE
a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus Christina Paula de Camargo Curcio
próprios projetos, identificando os requisitos necessários para o desenvolvi-
mento de um software com qualidade.
Tecnologia
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

Livro - Qualidade e Usabilidade de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Livro - Qualidade e Usabilidade de Software

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro - Qualidade e Usabilidade de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Christina Paula de Camargo Curcio

Fundação Biblioteca Nacional

CAPA_Qualidade e Usabilidade de Software.indd 1 17/08/2017 10:09:01

IESDE BRASIL S/A

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

C984q Curcio, Christina Paula de Camargo

1. Engenharia de software. 2. Software - Desenvolvimento. I. Título.

17-43661 CDD: 005.1

Direitos desta edição reservados à Fael.

Direção Acadêmica Francisco Carlos Sardo

Todos os direitos reservados.

IESDE BRASIL S/A.

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

No mercado atual existe uma diversidade de softwares para

Neste livro vamos apresentar os conceitos fundamentais relacionados à

1.1 A qualidade de software

Fonte: Elaborada pela autora.

usuário para resolver um problema ou alcançar um objetivo” (REZENDE,

1.1.1 Fundamentos da qualidade de software

22 Facilidade de manutenção: necessária para localizar e corrigir um

Para atingir um nível maduro de produção, métodos específicos devem

22 Monitoramento e controle de projetos: consiste em medir e coletar

1.1.2 Aspectos no desenvolvimento

necessidades do usuário, usando, para isso, um processo definido e discipli-

1.1.2.1 Engenharia dos requisitos

software de acordo com uma situação específica, enquanto os requisitos não

1.1.2.2 Engenharia de gestão de requisitos

O aumento ou a alteração de requisitos acarreta aumentos de prazos e/

1.1.2.3 Engenharia de gestão de configurações

1.2 Processos em qualidade de software

1.2.1 Erros que devem ser evitados

22 falha no planejamento de projetos em que se omitem as estimativas

pessoas; ambiente inadequado ao trabalho, com muito barulho, pouco

1.2.2 Modelos de ciclo de vida

22 Espiral: modelo de ciclo de vida em que um produto é desen-

1.2.3 Processos de desenvolvimento de software

adequado, estressante, o grau de motivação é baixo e os processos são difíceis

inadequados ou uma gerência de projetos despreparada. Os gerentes podem

revisões devem ser contínuas ao longo de todo o projeto de desenvolvimento

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

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

22 Estabelecer os 22 Cumprir os obje- 22 Garantir que os re-

Fonte: Elaborada pela autora.

1.3 Reflexões sobre a qualidade dos softwares

O modelo AOO (análise orientada a objetos) serve para formalizar a

Ampliando seus conhecimentos

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

Quando se trabalha algum tempo com requisitos de software,

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

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

2.1 Normas e seus organismos normativos

Em relação às normas técnicas, é importante conhecer os Organismos

Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas Sanitárias e

Existem vários modelos para a criação e desenvolvimento de um software,