Qualidade e Usabilidade de Software

Prévia do material em texto

Código Logístico
56271
Fundação Biblioteca Nacional
ISBN 978-85-387-6342-0
9 7 8 8 5 3 8 7 6 3 4 2 0
Q
U
A
L
ID
A
D
E
 E
 U
S
A
B
IL
ID
A
D
E
 D
E
 S
O
F
T
W
A
R
E
C
hristina Paula d
e C
am
arg
o
 C
urcio
IESDE BRASIL S/A
2017
Qualidade e Usabilidade 
de Software
Christina Paula de Camargo Curcio
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
Capa: IESDE BRASIL S/A.
Imagem da capa: lukutin77/iStockphoto
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q
2. ed. Curcio, Christina Paula de Camargo
Qualidade e usabilidade de software / Christina Paula de 
Camargo Curcio. - 2. ed. - Curitiba, PR : IESDE Brasil, 2017.
140 : il. ; 21 cm.
Inclui bibliografia
ISBN 978-85-387-6342-0
1. Engenharia de software. I. Título.
17-44416 CDD: 005.1CDU: 004.41
© 2017 – IESDE BRASIL S/A. É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito da 
autora e do detentor dos direitos autorais.
Apresentação
No mercado atual existe uma diversidade de softwares para uso 
empresarial ou informal.
Tais sistemas podem auxiliar bastante os processos de uma empre-
sa e otimizar o tempo de trabalho; para isso, necessitam ser de fácil uso, 
com uma interface amigável ao usuário e, principalmente, ter qualidade. 
O que é necessário para um software ter qualidade?
A usabilidade de um software deve ser cuidadosamente estudada, 
pois compreender a interação do homem com o computador pode definir 
o sucesso ou o fracasso de uma aplicação. Além dos aspectos de usabili-
dade, se faz necessário reconhecer outros aspectos importantes que ga-
rantem a qualidade do software, assim como as etapas de planejamento e 
produção que devem ser rigorosamente seguidas.
Neste livro vamos apresentar os temas fundamentais relacionados 
à qualidade de software, como métricas, normas e gestão da qualidade. 
Após este estudo, esperamos que você tenha facilidade para gerir e reco-
nhecer a qualidade e usabilidade dos softwares disponíveis no mercado e 
identificar os requisitos necessários para o desenvolvimento de um soft-
ware com qualidade.
Esperamos que seu estudo não termine por aqui. Com base nes-
te livro, realize as atividades propostas, leia os textos indicados e faça 
você mesmo a sua pesquisa para aprofundar os conhecimentos aqui 
apresentados.
Bom estudo!
Sobre a autora
Christina Paula de Camargo Curcio
Mestre em Desenvolvimento de Tecnologia pelo Institutos Lactec. 
Especialista em Gestão de Projetos pela Fundação Getúlio Vargas (FGV), 
em Project Management pela George Washington University (GWU, 
EUA) e em Redes, com ênfase em Internet pela Universidade Positivo 
(UP). Bacharel em Informática pela UP. Professora no ensino superior.
6 Qualidade e Usabilidade de Software
SumárioSumário
1 Qualidade de software 9
1.1 A qualidade de software 10
1.2 Processos em qualidade de software 15
1.3 Reflexões sobre a qualidade dos softwares 20
2 Normas e padrões 25
2.1 Normas e seus organismos normativos 26
2.2 Normas ISO e modelos CCMI 27
2.3 Métricas de qualidade de software 35
3 Influência dos requisitos na qualidade do software 41
3.1 Processos de negócio 42
3.2 Os requisitos e a comunicação 46
3.3 Qualidade de requisitos de software 49
4 Processo de desenvolvimento de software 57
4.1 Ciclo de desenvolvimento de software 58
4.2 Garantia da qualidade do software 65
4.3 Métodos ágeis, validações e indicadores 68
Qualidade e Usabilidade de Software 7
SumárioSumário
5 Gerência da qualidade de software 77
5.1 Dimensões da qualidade do processo e do produto 78
5.2 Planejamento e controle da qualidade do software 83
5.3 Gerência dos testes de software 86
6 Fundamentos da interação homem-computador (IHC) 91
6.1 Abordagens técnicas da IHC 92
6.2 Interação das atividades de IHC com a engenharia de software 101
6.3 O computador, o homem e os limites do sistema 102
7 Usabilidade de software 107
7.1 Definições de usabilidade do software 108
7.2 Métodos de usabilidade 109
7.3 A importância das recomendações de usabilidade 116
8 Acessibilidade e inclusão digital 123
8.1 A acessibilidade digital 124
8.2 A inclusão digital 128
8.3 Projetos de inclusão digital 131
Qualidade e Usabilidade de Software 9
1
Qualidade de software
Introdução
O dia a dia das organizações demonstra como é frustrante a realidade do desen-
volvimento de software: produtos mais caros do que deveriam ser, gastos desne-
cessários, cronogramas estourados, estresse no trabalho, desenvolvedores desmo-
tivados, erros recorrentes nos projetos etc. Todos na organização saem perdendo 
com isso, sem exceção.
Para que os problemas enfrentados pelas organizações produtoras de software 
possam ser resolvidos, faz-se necessária uma conscientização de que, para desenvolver 
softwares, é preciso muita disciplina, pois somente com um processo ou um modelo 
de qualidade é possível construir sistemas de computação adequados. Desse modo, o 
objetivo deste capítulo é apresentar uma reflexão sobre a qualidade de software (con-
ceito, fundamentos e processo), embasada em pesquisa bibliográfica da área.
Qualidade de software1
Qualidade e Usabilidade de Software10
1.1 A qualidade de software
Qualidade é a capacidade de um produto ou serviço para atender às necessidades 
do usuário (BEYON, 2011). No desenvolvimento de software, a qualidade do projeto 
acompanha os requisitos de qualidade, as especificações e o design do sistema. Ela está 
focada principalmente no aspecto de implementação, em que é observado se a execução 
segue o design planejado e se o sistema resultante está cumprindo com os objetivos e 
requisitos de desempenho.
Para garantir a qualidade do software são necessários: envolvimento de pessoas, defi-
nição de requisitos do software, integração e melhoria contínua dos processos, ferramentas 
atualizadas e métodos de trabalho, conforme observado na Figura 1:
Figura 1 – Qualidade do software.
Métodos
Pessoas e 
definição de requisitos
Ferramentas
Integração e 
melhoria contínua
Garantia da 
qualidade de 
software
Fonte: Elaborada pela autora.
De acordo com a Figura 1, para se garantir a qualidade de um software é preciso pes-
soas (analistas, programadores, webdesigners, gestores etc.) que tenham não apenas conhe-
cimento da área, mas que saibam trabalhar em equipe e tenham disciplina e comprometi-
mento com a organização. Elas têm de ter em mente os objetivos e as restrições do sistema a 
ser desenvolvido, de modo a definir suas propriedades e seus requisitos.
Os requisitos de um software, também chamados de requerimentos de software ou de 
requisitos funcionais de um sistema, podem ser compreendidos como “as funções ou ativida-
des que o software ou sistema faz (quando pronto) ou fará (quando em desenvolvimento)” 
e “condições ou capacitações que devem ser contempladas pelo software, solicitadas pelo 
cliente ou usuário para resolver um problema ou alcançar um objetivo” (REZENDE, 2005, 
p. 123).
Para se atingir a qualidade de software, ela deve ser incorporada à integração de todas 
as funções de todos os e recursos de uma empresa, desde a alta administração. Essa integra-
ção deve estar aliada à melhoria contínua e à revisão dos processos.
Por último, o uso de ferramentas adequadas para o monitoramento da qualidade de 
software auxilia a corporação na mensuração da qualidade. Esse monitoramento pode ser 
feito por meio de métodos estatísticos que são cada vez mais indispensáveis no controle da 
qualidade. Tais métodos são recursos de verificação e validação da qualidade do software 
e controlam se o software foi desenvolvido de acordo com as especificações desejadas, de 
maneira correta, e garantem que o software atenda aos propósitos desejados.
Qualidade de software
Qualidade e Usabilidade de Software
1
11
1.1.1 Fundamentos da qualidade de software
Originalmente, a qualidade de um programaou sistema era avaliada de acordo com o 
número de defeitos a cada mil linhas de código. Atualmente, com a evolução do conceito, 
outros fatores determinam a qualidade do software (BENYON, 2011):
• Operações de produtos: as características operacionais.
• Correção: grau em que um programa atende sua especificação e atinge os objeti-
vos definidos pelo usuário.
• Confiabilidade: nível de execução esperada de um software para realizar as fun-
ções com precisão.
• Eficiência: número de computadores e recursos exigidos pelo programa para exe-
cutar suas funções com o tempo de resposta adequado.
• Integridade: medida em que pode ser controlado o acesso ao software ou dados 
por usuários não autorizados.
• Facilidade de uso: esforço necessário para aprender, usar e interpretar a funciona-
lidade do sistema.
• Revisão do produto: capacidade de resistir a mudanças de tecnologia.
• Facilidade de manutenção: necessária para localizar e corrigir um bug no sistema.
• Flexibilidade: esforço necessário para modificar um programa.
• Facilidade de teste: condição necessária para testar um programa, de modo a asse-
gurar que a função desejada não exija esforço.
• Transição do produto: capacidade de adaptação a novos ambientes.
• Portabilidade: necessária para transferir um programa de um ambiente de hard-
ware ou software a outra tecnologia.
• Reutilização: grau em que um componente de programa ou software pode ser 
reutilizado em outras aplicações.
• Interoperabilidade: integração entre sistemas e outros aplicativos.
O CMM (Capability Maturity Model) é um modelo de qualidade de software que classi-
fica as empresas em níveis de maturidade, ou seja, determina a maturidade dos processos 
realizados para produzir cada software. De acordo o CMM, as organizações podem ser clas-
sificadas em cinco níveis de maturidade:
No nível 1 (inicial), o das organizações mais imaturas, não há nenhuma metodo-
logia implementada e tudo ocorre de forma desorganizada: por sua vez, no nível 
5 (otimizado), o das organizações mais maduras, cada detalhe do processo de 
desenvolvimento está definido, quantificado e acompanhado. Assim, a organi-
zação consegue até absorver mudanças no processo sem prejudicar o desenvol-
vimento do software. (RESENDE, 2005, p. 137)
Para atingir um nível maduro de produção, métodos específicos devem ser implemen-
tados (WEBER, 2012):
Qualidade de software1
Qualidade e Usabilidade de Software12
• Gerenciamento de requisitos: é o processo contínuo de análise e documentação 
dos requisitos do software. Ocorre durante o projeto de desenvolvimento de soft-
ware e envolve os usuários-chave ou stakeholders.
• Planejamento de projeto: busca refinar e detalhar os objetivos do projeto e planejar 
o trabalho necessário para alcançá-los.
• Monitoramento e controle de projetos: consiste em medir e coletar informações 
sobre o desempenho do projeto, assim como informar os envolvidos.
• Gestão de fornecedores: é o processo de adoção de boas práticas e de controle e 
gestão dos fornecedores.
• Garantia de qualidade: consiste no acompanhamento do projeto e na avaliação de 
seus diferentes aspectos para garantir que os padrões de qualidade sejam seguidos.
1.1.2 Aspectos no desenvolvimento do software 
com qualidade
A engenharia de software procura auxiliar a produção de programas e sistemas de boa 
qualidade, com baixo custo e dentro do prazo programado. Ela visa à melhoria de desenvol-
vimento de software ao longo do tempo, considerando que as tarefas relativas ao processo 
podem ser aprimoradas, controladas e medidas. Um dos principais benefícios de um pro-
cesso de desenvolvimento de software definido e disciplinado é a melhoria de sua visibili-
dade, ou seja, as atividades desse processo são gerenciáveis e, por isso, seus prazos e custos 
expressam melhor a realidade.
Aqui, a engenharia de software será discutida de duas formas: a convencional, que 
detalha os aspectos principais desse ramo, e outra, mais específica, que detalha o uso da 
orientação por objeto.
A engenharia de software procura atender uma necessidade humana, da mesma forma 
que outras ramificações da engenharia tratam de assuntos relacionados à mineração, agricul-
tura, moradia e tantos outros que justificam a utilização de algum conhecimento científico es-
pecífico. Ela traz benefícios por meio dos recursos tecnológicos disponíveis para o tratamento 
de informações.
Uma parte dos métodos da engenharia de software vem da ciência da computação e a 
outra da experiência adquirida pelo usuário. A engenharia de software é composta por um 
conjunto de disciplinas específicas relacionadas à ciência da computação e utiliza as abstra-
ções dessa área, como algoritmos e estruturas de dados, para criar sistemas de computador 
que atendam às necessidades do usuário, usando, para isso, um processo definido e disci-
plinado, por meio da tecnologia existente.
Existem três conceitos muito importantes na engenharia de software, que se relacionam 
intrinsecamente:
• Processo: trata-se de um conjunto de passos ordenados usado para atingir um fim 
específico, sendo composto por atividades, métodos, práticas e transformações.
Qualidade de software
Qualidade e Usabilidade de Software
1
13
• Projeto: é o que concretiza um processo.
• Produto: é o objetivo do processo.
Esses conceitos podem ser relacionados da seguinte maneira: um projeto tem um es-
copo delimitado por datas de início e de fim, com pontos de controle, chamados de marcos 
de projeto, para que possa ser acompanhado e gerido. O escopo do projeto é um processo 
constituído de documentação que detalha o que é feito, quando e por quem, tendo por meta 
a concretização do produto especificado.
De modo geral, um produto tem um ciclo de vida em que é concebido, desenvolvido, 
entra em operação e sai de operação. Um produto de software é criado a partir do momen-
to em que se percebe a necessidade de sua existência, e, assim, um conjunto de requisitos 
é determinado e desenvolvido para que seja posto em operação. Quando o produto não é 
mais necessário ou se torna obsoleto, seu ciclo de vida termina e ele é retirado de operação.
A literatura disponível varia muito ao definir as disciplinas da engenharia de software, 
a qual se configura como uma área interdisciplinar que se baseia nos fundamentos de várias 
disciplinas (RESENDE, 2005). Elas podem ser distribuídas entre os aspectos de requisitos, 
planejamento de projetos e qualidade, conforme se discutirá a seguir.
1.1.2.1 Engenharia dos requisitos
Os requisitos descrevem ou expressam as características de um dado produto de 
software, podendo ser funcionais ou não funcionais. Requisitos funcionais são aqueles que 
determinam o comportamento do produto de software de acordo com uma situação especí-
fica, enquanto os requisitos não funcionais quantificam aspectos desse produto, como, por 
exemplo, desempenho, disponibilidade ou portabilidade.
Os requisitos precisam ser especificados em um documento, devendo-se detalhar e dis-
tinguir os explícitos e os normativos. Os requisitos explícitos são aqueles levantados por de-
senvolvedores com base nas informações dos usuários e os requisitos normativos são os pro-
venientes de leis e normas aplicados ao produto de software (PRESSMAN; MAXIM, 2016).
Existem, ainda, os requisitos de expectativa do usuário, os quais não estão documenta-
dos. Eles são chamados de requisitos implícitos e são totalmente indesejados, porém podem 
ser minimizados por meio de uma boa especificação de requisitos, ou seja, detalhando-se 
bem os explícitos e normativos.
Para obter uma boa especificação de requisitos, faz-se necessário o uso de técnicas de 
levantamento, documentação e análise; constitui-se, assim, a engenharia dos requisitos, uma 
disciplina da engenharia de software.
Uma boa engenharia de requisitos aumenta a compreensão do produto para o seu pú-
blico-alvo e também diminui a instabilidade dos requisitos, ou seja, a alteração dos requisi-
tos constantes no documento de especificação.A instabilidade onera o projeto de várias for-
mas, como, por exemplo, no aumento de prazos e custos. Porém, essa alteração de requisitos 
também pode acontecer devido a mudanças em requisitos normativos, sendo inevitável a 
variação do contexto do produto. O controle dos requisitos precisa ser, então, submetido a 
Qualidade de software1
Qualidade e Usabilidade de Software14
algum tipo de gestão, pois eles podem ser alterados mesmo à revelia do usuário. Isso cons-
titui a gestão de requisitos, outra disciplina da engenharia de software.
1.1.2.2 Engenharia de gestão de requisitos
Além de especificar corretamente os requisitos, gerentes de projetos devem estar aten-
tos a outros dois fatores, os prazos e os custos, pois estes, juntamente com os requisitos, 
determinam o sucesso ou o fracasso do projeto de software. Um produto de software deve 
atender aos requisitos e às necessidades dos usuários e também deve ser construído dentro 
do prazo e do custo estimados.
O aumento ou a alteração de requisitos acarreta aumentos de prazos e/ou de custos. No 
caso da redução de requisitos, os prazos e os custos também podem sofrer alteração, mas 
isso não é regra. O bom planejamento de projetos tenta equilibrar os componentes dos vérti-
ces desse triângulo crítico (requisitos, prazos e custos), com base em uma boa especificação 
de requisitos e com técnicas de estimativa e análise de tamanho, esforços, prazos e riscos. 
O planejamento de projetos é a disciplina da engenharia de software que trata desses aspectos.
O planejamento de projetos tem uma disciplina complementar, chamada de controle de 
projetos, cujo objetivo é acompanhar o progresso dos projetos, comparando o previsto com o 
realizado. Busca solucionar os problemas detectados, replanejar os projetos, quando houver 
necessidade, e renegociar os compromissos assumidos.
Também diz respeito à gestão de requisitos a gestão de contratos. As organizações que 
terceirizam a produção de software devem estar capacitadas nessa gestão, porque precisam 
especificar corretamente todos os requisitos do produto, selecionar os candidatos mais qua-
lificados, ter proficiência no acompanhamento do projeto para intervir quando necessário e 
verificar os critérios para a aceitação do produto (BENYON, 2011).
1.1.2.3 Engenharia de gestão de configurações
Para gerir com qualidade todos os artefatos produzidos no processo de desenvolvimen-
to, a engenharia de software tem a disciplina de gestão de configurações – gerência de confi-
guração, ou, ainda, gestão de configuração de software, uma área responsável por fornecer 
o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de 
versão, o controle de mudança e a auditoria das configurações.
Um grupo de pessoas deve ser designado para controlar esses artefatos de software, 
porque todos são passíveis de alterações. Em caso de organizações pequenas que não dispo-
nham de pessoal suficiente, um membro da equipe de desenvolvedores pode ser designado 
para essa função. Essa é uma disciplina em que é fortemente recomendado o uso de ferra-
mentas automatizadas, devido ao grande volume de artefatos e de versões destes que são 
geradas durante todo o processo de desenvolvimento (WEBER, 2012).
Qualidade de software
Qualidade e Usabilidade de Software
1
15
1.2 Processos em qualidade de software
Para falar sobre qualidade em software, é preciso introduzir uma discussão sobre os 
erros aos quais um processo de desenvolvimento de software está sujeito. As disciplinas 
da engenharia de software que regem a garantia da qualidade dizem respeito ao impacto 
causado por esses erros.
1.2.1 Erros que devem ser evitados
A qualidade de um produto é definida pelo grau de conformidade com os seus requi-
sitos e está diretamente relacionada à qualidade do processo utilizado em sua construção. 
Pode-se afirmar, então, que a qualidade é uma relação construída com base em processos, 
pessoas e tecnologia envolvidos na construção de um produto. Esses três elementos formam 
o segundo triângulo crítico da engenharia de software e indicam os fatores da produção 
(BENYON, 2011).
Os defeitos ocorrem em um produto de software em todas as suas fases de desenvol-
vimento. Eles são encontrados de diversas formas, como no desempenho aquém do deseja-
do, nas funções que não são executadas corretamente ou na dificuldade para utilização do 
sofware. Assim, os defeitos estão relacionados à não conformidade com os requisitos explí-
citos, os normativos e os implícitos.
Os erros relativos ao produto estão vinculados a algum desses fatores e são defeitos de 
definição de requisitos ou defeitos introduzidos ao longo do projeto. Os mais comuns são 
a introdução de características desnecessárias aos requisitos, alteração dos requisitos sem 
uma análise de impacto e erro no foco do desenvolvimento, quando ele é voltado para a 
pesquisa e não para a produção em si.
Os erros relativos ao processo estão relacionados com processos informais ou proces-
sos oficiais rígidos e burocráticos. Os mais comuns são (WEBER, 2012):
• desperdício de tempo antes do início do projeto;
• pressões por prazos otimistas e o não cumprimento destes por serem impossíveis;
• falha no planejamento de projetos em que se omitem as estimativas de atividades, 
como as de garantia da qualidade e a omissão da análise de riscos;
• falha no método de gerir o projeto;
• pressa para começar a etapa de codificação;
• falha na subcontratação de serviços; e
• entrega do produto sem estar totalmente pronto ou testado.
Qualidade de software1
Qualidade e Usabilidade de Software16
Entre os requisitos e a codificação existe o projeto, presente em todas as fases do proces-
so. Os defeitos de projeto são tão graves como os defeitos provenientes de requisitos. Eles se 
caracterizam por dificuldade para utilização do software, desempenho ruim, defeitos alea-
tórios de difícil reprodução e dados inconsistentes que comprometem a manutenibilidade e 
a extensão. Um bom projeto deve ser também documentado.
Como todas as fases do desenvolvimento do projeto são passíveis de injetar erros no 
produto, é preciso haver atividades como testes, revisões formais e informais e auditorias, 
que visem garantir a qualidade do software, detectando precocemente cada erro. Estudos 
já demonstraram que o aumento da qualidade reduz o tempo de desenvolvimento, devido 
ao refinamento na detecção e eliminação precoce de defeitos, o que é bem mais barato que 
corrigir o defeito em um estágio avançado do processo (BENYON, 2011).
Os métodos de garantia de qualidade devem levar em consideração o fator humano: é 
mais fácil detectar erros dos outros do que os próprios. Assim, revisões, testes e auditorias 
devem ser realizados por pessoas diferentes daquelas que desenvolveram o produto. Por 
fim, a garantia da qualidade deve ser gerida por um grupo de pessoas independente dos de-
senvolvedores e que não mantenha nível hierárquico com estes ou com o gerente do projeto 
e tenha acesso à alta gerência da organização.
Já os erros relativos a pessoas podem ocorrer por: falta de patrocínio para o projeto; 
ausência de participação dos interessados no produto, como os usuários e desenvol-
vedores; atritos entre as partes envolvidas; defeitos na formação da equipe do projeto, 
como a falha na contratação de pessoas; falta de entrosamento entre funcionários e de-
pendência em relação a determinadas pessoas; ambiente inadequado ao trabalho, com 
muito barulho, pouco espaço e fatores ergonômicos inapropriados, e falta de motivação 
do pessoal (BENYON, 2011).
Os erros relativos à tecnologia podem ocorrer por uma estimativa otimista de que mui-
tos problemas podem ser resolvidos por meio de alta tecnologia, esquecendo-se de que para 
utilizá-la em profundidade é necessário treinamento e experiência. Assim, pode haver falha 
na análise para mudança de tecnologia e a substituição desta no meio de um projeto, falta 
de automação de atividades como as de gestão de configurações, ausência deferramenta de 
modelagem e automação de atividades de testes.
1.2.2 Modelos de ciclo de vida
Para a existência de um processo de desenvolvimento de software, é preciso ter defini-
do o seu modelo de ciclo de vida. Existem vários tipos de modelos, que se diferenciam prin-
cipalmente pelo grau de controle aplicado sobre o processo em questão e sua visibilidade 
para o cliente no seu decorrer, como especificado a seguir.
• Codifica-Remenda: é o pior de todos os modelos de ciclo de vida aqui apresen-
tados e, provavelmente, o mais utilizado. Com base em um problema existente, 
e não um problema modelado ou especificado, mas sim definido de uma forma 
Qualidade de software
Qualidade e Usabilidade de Software
1
17
qualquer, passa-se imediatamente à codificação. Os erros encontrados são corrigi-
dos conforme a demanda, daí o termo remenda. Muitas vezes não existe um proces-
so definido ou, se existe, ele não é seguido, é impossível de ser gerido e, portanto, 
não se pode assumir compromissos confiáveis.
• Cascata: esse modelo de ciclo de vida tem a vantagem de apresentar pontos de 
controle que permitem demarcar as fases do processo, facilitando a sua gestão. 
Porém, ele é rígido e burocrático, porque não permite a correção de erros nas fases 
anteriores e tem baixa visibilidade para o cliente, pois este não recebe feedback nos 
pontos de controle existentes, assim o único resultado que o cliente vê é o final. 
Ele apresenta uma variante que permite a realimentação entre fases, porém esta 
dificulta a gestão de projetos.
• Espiral: modelo de ciclo de vida em que um produto é desenvolvido em diver-
sas iterações (repetições). Uma iteração nova representa uma volta na espiral. Sua 
vantagem é que permite a construção de produtos com prazos curtos e a desvan-
tagem é que é difícil de ser gerido.
• Prototipagem evolutiva: utiliza o modelo de ciclo de vida em espiral para cons-
truir o produto em protótipos, cobrindo progressivamente os requisitos até a fi-
nalização. Sua vantagem é que apresenta visibilidade e alta flexibilidade para o 
cliente. Como desvantagem, ele precisa de equipes disciplinadas e experientes; o 
projeto deve ser robusto para que a estrutura do produto permaneça confiável ao 
longo dos protótipos, além disso, ele é também difícil de ser gerido.
• Entrega evolutiva: esse modelo de ciclo de vida é uma combinação dos modelos 
cascata e prototipagem evolutiva. Apresenta a vantagem de ter alta visibilidade 
para os clientes e facilidade de gestão, por apresentar pontos de controle bem de-
finidos. Sua desvantagem é a necessidade de um projeto que seja robusto para que 
a estrutura do produto permaneça confiável ao longo das liberações programadas.
• Dirigido por prazo: um conjunto de requisitos essenciais é definido e entregue no 
prazo programado nesse modelo de ciclo de vida. O produto final é, na verdade, 
um produto parcial e o restante é desenvolvido em processos posteriores, geral-
mente chamados de manutenção.
• Dirigido por ferramenta: utiliza-se um processo proposto por uma ferramenta 
CASE1 e podem ser adequados a um determinado tipo de produto, porém fica 
restrito ao domínio da aplicação.
Mesmo que uma organização decida por não desenvolver, mas adquirir um produto 
de software, ela tem de ter competência para gerir os processos de aquisição, implantação, 
adaptação e integração com outros sistemas e a organização. Isso pode sair mais caro do que 
o processo de desenvolvimento em si.
1 Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange 
todos os programas (as “ferramentas”) que auxiliam os analistas nas atividades de engenharia de 
software, desde análise de requisitos e modelagem, até a programação e os testes.
Qualidade de software1
Qualidade e Usabilidade de Software18
1.2.3 Processos de desenvolvimento de software
Para que a organização possa ser considerada madura, ela precisa ter processos de de-
senvolvimento formalmente definidos e que possam ser melhorados continuamente, como 
os processos apresentados a seguir.
Processo pessoal de software – PSP: utiliza o modelo de ciclo de vida em entrega 
evolutiva e não há tratamento específico para requisitos. Na fase de planejamento do 
PSP, executam-se as atividades de estimativas de tamanho (com base em modelo de 
orientação a objetos), esforços, cronogramas e defeitos. O projeto é rigoroso tanto para 
concepção quanto para verificação e é realizado utilizando-se orientação a objetos, sín-
tese lógica e máquinas sequenciais.
Processo de software para times – TSP: utilizando um modelo de ciclo de vida em 
espiral, esse processo é uma sequência do PSP. O TSP cobre a área de gestão de requisitos, 
planejamento e controle de projetos, garantia da qualidade e gestão de configurações não 
cobertas pelo PSP.
Processo unificado: esse processo, centrado na arquitetura, é dirigido a casos de uso, 
sendo iterativo e incremental, e usa a UML (Unified Modeling Language) como notação para 
os modelos que o compõem, centrado na arquitetura. Ele utiliza um modelo de ciclo de vida 
em espiral e é dividido em fases e fluxos de trabalho. Cada fase representa um marco geren-
cial do projeto e cada fluxo de trabalho trata de um tema técnico específico. O RUP (Rational 
Unified Process) e o EUP (Enterprise Unified Process) são baseados no processo unificado.
Práxis: é um processo com fins didáticos e baseado em tecnologia de orientação a ob-
jetos e sua notação de análise e projeto também é UML. Apresenta elementos do processo 
unificado, mas com influência do PSP e do TSP. Da mesma forma que o processo unificado, 
o práxis abrange fases e fluxos: uma fase é dividida em uma ou mais iterações, e um fluxo é 
dividido em uma ou mais atividades.
Um dos objetivos de um processo de desenvolvimento de software é capacitar uma 
organização a identificar rapidamente e solucionar facilmente os problemas. Ora, para isso 
ela necessita de maturidade. Uma organização imatura é ruim aos profissionais desenvol-
vedores e gerentes, clientes e usuários. Para os profissionais, é ruim porque o ambiente de 
trabalho é pouco adequado, estressante, o grau de motivação é baixo e os processos são difí-
ceis de gerir. Já para os clientes e usuários, é ruim porque a qualidade do produto final não 
é boa ou porque foram entregues fora do prazo e do custo estimado. Todos esses problemas 
podem ser minimizados, e até mesmo resolvidos, pela definição formal de um processo de 
desenvolvimento de software.
O processo precisa ser definido de forma a auxiliar a organização a produzir produtos 
melhores, com baixo custo e dentro do prazo estimado, e uma consequência inerente ao re-
finamento do processo é que os produtos são produzidos mais rapidamente. Por outro lado, 
se a organização erra definindo um processo rígido e burocrático, ele servirá apenas para 
formalizar uma situação e não será efetivamente usado na prática.
Qualidade de software
Qualidade e Usabilidade de Software
1
19
Um software é baseado em abstrações lógicas, e não em princípios físicos estáveis. 
Como consequência, a disciplina para gerir um processo desse tipo deve ser mais rígida que 
de costume. Assim, um processo de desenvolvimento de software ruim não vai conduzir a 
um produto de qualidade satisfatória.
É um erro imaginar que a qualidade de um software não pode ser medida; ela pode e 
deve ser medida por meio da produtividade ou do número de defeitos encontrados, por 
exemplo. As métricas devem ser coletadas, analisadas e normatizadas para que o processo 
possa ser gerido e melhorado.
Outro erro muito comum em organizações é acreditar que os problemas da produção 
são mais técnicos que gerenciais. Com um processo de negócio ruim, pouco adianta a tec-
nologia e esta não tem retorno; sem processos de negócio mapeados e robustos, um projeto 
de desenvolvimento de software inicia de forma incorreta, já que aqueles são a base deste. 
O mesmo se aplica quando a gestão é deficiente. Mais uma vez, os indicadores dos proble-
masda produção recaem nos problemas gerados por um processo mal definido. As pessoas 
erram porque a informação chega até elas de forma incorreta, incompleta ou confusa, os 
recursos disponíveis não são adequados ou não são suficientes, o processo é mal definido ou 
difícil de seguir e falta treinamento da área de negócio nos processos e tecnologias utilizados 
(BENYON, 2011).
Infelizmente, a tendência é acreditar que os erros são do corpo técnico, por falta de 
comprometimento e treinamento, e não devido a processos inadequados ou uma gerência 
de projetos despreparada. Os gerentes podem não conhecer totalmente o domínio da aplica-
ção e precisam ser treinados em gestão de pessoal. Também precisam estar comprometidos 
com o projeto para se abstrair de paixões pessoais e evitar competições internas que sempre 
existem dentro das organizações, procurando levar ao conhecimento dos desenvolvedores 
as informações corretas, completas e precisas.
A conclusão extraída é óbvia: fatores de produção, pessoas, tecnologia e processos são 
muito dependentes uns dos outros. Não basta ter tecnologia se não há um corpo técnico com 
capacidade de operá-la, e isso requer treinamento e experiência. Não basta ter tecnologia e 
um corpo técnico altamente capacitado se os gerentes acreditam que isso resolverá todos 
os problemas e eles terão o produto desejado dentro do prazo e custo estimados. Para tudo 
isso, é preciso um processo definido.
Para a realização da melhoria de processos, faz-se necessária uma análise em que os pro-
blemas relativos a eles são de responsabilidade dos gerentes de projetos. Ora, isso porque 
os gerentes possuem um universo de variáveis envolvidas, estando capacitados a procurar 
e encontrar as deficiências do processo para interferir quando for preciso. A atuação de um 
gerente de projeto deve ser de forma a estimular melhorias sem procurar efetivamente os 
culpados, porque isso leva ao ocultamento dos problemas reais. De outra forma, o processo 
fatalmente não funcionará. É tarefa do gerente promover aperfeiçoamentos, reduzindo o 
desgaste no ambiente de trabalho, a fim de aumentar a produção. Mas, para isso, é preciso 
que ele conheça o processo para poder agir eficazmente, ter o apoio da alta administração, 
que deve estar ciente do investimento a ser feito, envolver o corpo técnico e, por último, 
mas não menos importante, ele tem de ter em mente que a capacitação no processo não é 
Qualidade de software1
Qualidade e Usabilidade de Software20
conseguida da noite para o dia – ela é realizada em etapas, com marcos para pontos de con-
trole bem definidos.
Assim, os processos de qualidade de software englobam fases que buscam aumentar a 
eficiência e a eficácia dos softwares produzidos, conforme pode ser observado na Figura 2. 
O processo de melhoria contínua envolve os procedimentos de planejamento, controle e 
garantia da qualidade, em que as revisões devem ser contínuas ao longo de todo o projeto 
de desenvolvimento do software.
Figura 2 – Processos de qualidade do software.
Qualidade do software – conjunto de caracterísiticas de um sistema para atender 
os requisitos das partes interessadas.
Gestão da qualidade do software – direção e coordenação das atividade de qualidade de software
Melhoria da qualidade do software – processo de melhoria contínua
 2 Estabelecer os ob-
jetivos, processos 
e recursos
Revisão dos 
processos de 
qualidade
 2 Cumprir os objeti-
vos e requisitos de 
qualidade
 2 Garantir que os re-
quisitos de qualidade 
sejam cumpridos
Planejamento 
da qualidade
Controle da 
qualidade
Garantia da 
qualidade
Fonte: Elaborada pela autora.
A Figura 2 resume o que foi visto até aqui: o processo de melhoria da qualidade do 
software deve ser contínuo e revisado em todos as etapas. Num primeiro momento é feito 
o planejamento, em que se estabelecem os objetivos, processos e recursos. Durante o desen-
volvimento, o controle de qualidade deve estar sempre presente, buscando-se cumprir os 
objetivos e atender aos requisitos de qualidade. A garantia de qualidade é uma etapa final, 
em que é feita uma última avaliação do produto, no entanto, para que ela seja eficaz, tam-
bém precisa estar presente em todas as etapas anteriores, num ciclo de melhoria contínua.
1.3 Reflexões sobre a qualidade dos softwares
Para que o software tenha qualidade, ele deve ter usabilidade, funcionalidade, confia-
bilidade, manutenibilidade e desempenho. Para que essas características de qualidade de 
software sejam atendidas é importante que sejam respondidas questões como: O software satis-
faz a necessidade do usuário ou da empresa? Ele é confiável? Tem um bom desempenho? É fácil 
de usar? Pode ser corrigido com facilidade? Pode ser reutilizado em outro projeto?
Qualidade de software
Qualidade e Usabilidade de Software
1
21
O software deve satisfazer a necessidade do cliente em relação à funcionalidade. Para 
isso, deve se propor a fazer o que é apropriado, de forma correta, ser capaz de interagir com 
os sistemas especificados, estar de acordo com as normas de qualidade de sofware e da or-
ganização e deve ser protegido para evitar acessos não autorizados.
Com relação à confiabilidade o sistema deve ser imune a falhas e ser capaz de recuperar 
dados em caso de falhas. Além disso, deve ser fácil de usar (com navegação intuitiva) para 
atender o critério de usabilidade, ou seja, o sistema deve ter um nível fácil de operação para 
o usuário e ser de fácil compreensão, pois se for muito complicado exigirá vários treinamen-
tos, o que dificultará seu emprego.
Por último, o software deve ser de fácil modificação, adaptação e validação. A eficiência 
do software é outro item de qualidade a ser verificada pois deve ser enxuto, com bom tempo 
de resposta e de processamento na execução de suas funções, utilizando recursos e tempo 
aceitáveis pelo usuário.
No contexto da engenharia de software, o processo de gestão de qualidade é aquele que 
estabelece o comportamento essencial de um sistema, o qual pode ser mantido, independen-
temente de como o sistema é implementado.
Um modelo de análise deve ser confeccionado visando às abstrações que indicam o 
que o sistema vai fazer. Assim, pressupõe-se que uma tecnologia perfeita esteja disponível 
e o analista considere que não haverá restrições de capacidade de memória; a comunicação 
entre os objetos será realizada na velocidade ideal; a adequação do sistema à plataforma de 
computador não será um empecilho; não acontecerão erros e outras questões relacionadas 
às abstrações de como fazer o sistema (BENYON, 2011).
O modelo AOO (análise orientada a objetos) serve para formalizar a visão do mundo 
real no contexto do sistema de computador, estabelecendo os principais objetos que repre-
sentam o domínio de uma aplicação e as estruturas organizacionais impostas a tais objetos, 
bem como a colaboração existente entre eles, ou seja, as conexões de mensagens que mos-
tram a forma de comunicação dos objetos com os demais (WEBER, 2012).
Os benefícios trazidos pela melhoria dos processos são muitos. Os principais deles são 
(BENYON, 2011):
• Engenharia de requisitos e gestão de requisitos: são práticas que produzem um 
retorno de investimento mais significativo porque é mais barato captar o requisito 
certo do que alterá-lo em fases posteriores do processo.
• Projeto: menos significativo que o anterior, mas que não deixa de produzir impac-
to no retorno de investimento.
• Garantia da qualidade: as atividades de garantia da qualidade – as que mais so-
frem devido à pressa para entrega de um produto – dão retorno quando as neces-
sidades de se refazer as etapas iniciais de um processo tendem a diminuir.
• Prevenção de defeitos: aqui vale o ditado popular “é melhor prevenir que reme-
diar”. Entre as atividades de garantia da qualidade, as de prevenção de defeitos 
dão mais retorno do que as de correção.
Qualidade de software1
Qualidade e Usabilidade de Software22
 Ampliando seus conhecimentos
O texto a seguir trata sobre a importânciado trabalho do analista de 
requisitos no desenvolvimento de um software e as principais dificulda-
des enfrentadas por esse profissional, cujo trabalho muitas vezes é des-
valorizado ou incompreendido pelos outros colaboradores e até mesmo 
gestores da organização.
(FAGUNDES, 2011, p. 4-5)
Quando se trabalha algum tempo com requisitos de software, percebe-
-se o quão ingrata é a atividade. Não por ser mais ou menos complexa 
que as outras, mas pela forma como é tratada pelos pares. O Analista 
de Requisitos é tomado na maioria das vezes como um documentador 
(até mesmo pelos próprios trabalhadores de requisitos), corrompendo o 
bem-fazer da atividade e provocando prejuízo aos projetos e degradando 
ainda mais a forma como se percebe a engenharia de requisitos.
A percepção geral que se tem é que os analistas de requisitos entram em 
ação para atrasar os projetos e que a documentação gerada é extensiva 
e de pouca valia. Às vezes parte dessa percepção é correta, mas a razão 
imputada é, na maioria das vezes, distorcida, apontando para uma ori-
gem incorreta. Muito mais vezes os problemas de requisitos se dão pela 
falta de preparação dos analistas, seu perfil e por uma fraca postura na 
relação com o cliente, em vez da lendária mão invisível do processo.
Como resultado desses fatores reais para uma construção adequada de 
requisitos, constrói-se uma escala de retrabalho que a equipe não entende 
exatamente por quê. Por várias vezes durante um projeto há questiona-
mentos sobre a forma dos requisitos serem especificados ou se a proposta 
é adequada ou não, desviando o foco da atividade em voga no andamento 
do projeto.
Para, então, corrigir o prumo e trabalhar requisitos é premente que se faça 
uma revisão de propósitos, motivações, formação, discurso e perfis, para 
que as pessoas corretas estejam alocadas corretamente para realizar a ati-
vidade de maneira eficaz e eficiente. A adoção de novos processos e técni-
cas não surtirão efeito sem essa revisão.
Qualidade de software
Qualidade e Usabilidade de Software
1
23
 Atividades
1. Para se avaliar a qualidade do software, é fundamental medir e monitorar todo o 
ciclo de seu desenvolvimento. Por quê?
2. O que são requisitos de software e como devem ser documentados?
3. Com relação aos processos de qualidade de software, quais são os principais erros 
encontrados?
4. Por que o modelo ciclo de vida codifica-remenda é o mais utilizado e o menos reco-
mendado?
 Referências
BENYON, D. Interação humano-computador. Tradução de Heloisa Coimbra. 2. ed. São Paulo: Pearson 
Prentice Hall, 2011.
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade de software são as mes-
mas coisas? Disponível em: <http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-
-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx#ixzz4WjF9RTkw>. Acesso 
em: 13 jan. 2017.
CAVANO, J. P.; MCCALL, J. A. Proceedings of the Software Quality Assurance Workshop on 
Functional and Performance Issues. San Diego, 1978.
FAGUNDES, R. M. Engenharia de requisitos: do perfil do analista de requisitos ao desenvolvimento de 
requisitos com UML e RUP. Salvador, 2011. Disponível em: <https://books.google.com.br/books?id=i-
2pIBQAAQBAJ&printsec=frontcover&dq=engenharia+dos+requisitos&hl=pt-BR&sa=X&ved=0ahUKE-
wis6MX925PVAhXMIpAKHddiBhcQ6AEIKTAB#v=onepage&q&f=false>. Disponível em: 19 jul. 2017.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto 
Alegre: AMGH, 2016.
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. Rio de Janeiro: Brasport, 2005.
WEBER, K. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, 2012.
 Resolução
1. Um produto tem um ciclo de vida em que é concebido, desenvolvido, entra em ope-
ração e sai de operação. Um produto de software é concebido a partir do momento 
em que se percebe a necessidade da sua existência, então um conjunto de requisitos 
é determinado e desenvolvido para que seja posto em operação. Quando o produto 
não é mais necessário ou tornou-se obsoleto, seu ciclo de vida termina e ele é retirado 
de operação.
Qualidade de software1
Qualidade e Usabilidade de Software24
2. Os requisitos descrevem ou expressam as características de um dado produto de 
software, podendo ser funcionais ou não funcionais. Requisitos funcionais são aque-
les que determinam o comportamento do produto de software de acordo com uma 
situação específica, enquanto os requisitos não funcionais quantificam aspectos des-
se produto, como, por exemplo, desempenho, disponibilidade ou portabilidade. 
Os requisitos precisam ser especificados em um documento específico, no qual se 
deve detalhar os requisitos explícitos e os requisitos normativos.
3. Os erros relativos ao processo estão relacionados com processos informais ou pro-
cessos oficiais rígidos e burocráticos. Os erros mais comuns são: desperdícios de 
tempo antes do início do projeto; pressões por prazos otimistas e o não cumprimento 
destes por serem impossíveis; falha no planejamento de projetos, em que se omitem 
as estimativas de atividades como as de garantia da qualidade e a omissão da análise 
de riscos; falha no método de gerir o projeto; pressa para começar a etapa de codifi-
cação; falha na subcontratação de serviços; e entrega do produto antes da hora, sem 
estar pronto ou testado devidamente.
4. O modelo codifica-remenda é o mais utilizado porque, com muita frequência, um 
software é desenvolvido sem um projeto adequado e sem ser documentado correta-
mente. Quando o analista ou o cliente identifica um problema, ele é corrigido sem ser 
analisado, sem que se verifique se esse problema está associado a outras questões. 
Assim, corrige-se um problema visível e cria-se uma trilha de erros no programa.
Qualidade e Usabilidade de Software 25
2
Normas e padrões
Introdução
No Brasil, existe um corpo de normas nacionais baseadas em normas internacio-
nais, que buscam garantir a proteção do consumidor por meio de produtos e serviços 
adequados. A adoção de padrões internacionais leva a melhores oportunidades de 
comércio global e reduz a produção de itens de baixa qualidade.
Para os sistemas de gestão, a normalização também ajuda as organizações e as par-
tes interessadas em suas atividades, em diferentes níveis, com seus próprios fins. Esse 
é um pré-requisito para a evolução de uma cultura de qualidade.
A seguir, são apresentadas e discutidas diferentes padronizações, suas aplicações 
e sua importância para ordenações em diversos contextos, incluindo o da qualidade 
de software.
Normas e padrões2
Qualidade e Usabilidade de Software26
2.1 Normas e seus organismos normativos
A normalização é o processo de desenvolvimento, implementação e melhoria dos pa-
drões que se aplicam a ordens científica, industrial e econômica diferentes, para organizar 
suas atividades. A Associação Americana de Teste de Materiais define padronização como o 
processo de formulação e implementação de regras, numa abordagem ordenada para ativi-
dades específicas, visando a benefícios e com a cooperação de todos os envolvidos (CYBIS 
et al., 2015). As grandes somas de dinheiro que os países desenvolvidos investem em orga-
nizações nacionais e internacionais de normalização são uma prova da importância dada à 
padronização (VALERIANO, 2005).
A ISO (International Organization for Standardization) desenvolve normas inter-
nacionais para diversos campos da tecnologia, exceto o eletrotécnico, coberto pela IEC 
(International Electrotechnical Comission), e as telecomunicações, abrangidas pela UIT 
(União Internacional de Telecomunicações).
De acordo com a ISO, padronização é a atividade que visa estabelecer os problemas reais 
ou potenciais, provisões para uso comum e repetido, a fim de obter um nível ótimo de orde-
nação em um dado contexto, que pode ser tecnológico, político ou econômico (WEBER, 2012).
A normalização envolve um conjunto de regras convencionais destinadas a simplificar, 
unificare especificar produtos (WAZLAWICK, 2013):
• Simplificar – procura manter apenas o estritamente necessário, seja em documen-
tos, processos, orientações etc. As próprias normas também são simplificadas para 
serem facilmente assimiladas.
• Unificar – a ideia é criar um padrão para os produtos, utilizado em todas as partes 
do mundo para permitir trocas internacionais.
• Especificar – procura, por meio de uma linguagem clara e precisa, identificar os 
produtos, definindo-os, categorizando-os, catalogando-os e detalhando suas ca-
racterísticas, de modo a orientar o consumidor.
Em relação às normas técnicas, é importante conhecer os Organismos Nacionais de 
Normalização (NSB, do inglês National Standards Body) dos países de interesse, que, em ge-
ral, possuem um centro de informação sobre normas. Os NSB têm um arquivo próprio de 
padronizações de organismos nacionais, regionais e internacionais, tais como as do British 
Standards Institution (BSI, ou Instituto Britânico de Normalização) e da Association Française 
de Normalisation (AFNOR – Associação Francesa de Normalização). No Brasil, o organis-
mo responsável pela elaboração de normas técnicas é a Associação Brasileira de Normas 
Técnicas (ABNT).
O papel dos NSB tem evoluído nas últimas décadas, com melhorias na infraestrutura 
física e econômica, avanços na tecnologia da informação, implantação de melhores práticas 
de fabricação, automação, transporte e mudanças em muitos aspectos que afetam o comér-
cio e a indústria, levando a um aumento acelerado no volume de transações comerciais entre 
os países (SOMMERVILLE, 2011).
Normas e padrões
Qualidade e Usabilidade de Software
2
27
Com a globalização, a média das áreas das organizações consideradas sob padroniza-
ção foi estendida para incluir sistemas de gestão, indústrias de serviços e novas tecnologias 
que não existiam até a segunda metade do século XX (PRESSMAN; MAXIM, 2016).
Os padrões são utilizados cada vez mais para apoiar os regulamentos técnicos, e mais 
direcionados para tecnologias convergentes e de rápido desenvolvimento, direcionados a 
uma ampla gama de partes interessadas (PFLEEGER, 2004). Novos produtos reguladores, 
com períodos mais curtos de desenvolvimento, são uma tentativa, por parte da comunidade 
normativa, para responder às exigências de governos, empresas e consumidores em todo o 
mundo (LAUDON; LAUDON, 2004).
Assim, as atividades de padronização tornaram-se mais complexas e mais importantes 
para o desenvolvimento nacional e internacional. A criação da Organização Mundial do 
Comércio (OMC), em 1995, levou ao desenvolvimento de vários acordos na área, em espe-
cial o Acordo sobre Barreiras Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas 
Sanitárias e Fitossanitárias, ao qual todos os membros da OMC devem aderir (CAIÇARA 
JR., 2007). Esses acordos são uma tentativa de reduzir o impacto das normas e regulamenta-
ções usadas como barreiras técnicas ao comércio entre os países (CYBIS et al., 2015).
2.2 Normas ISO e modelos CCMI
2.2.1 ISO
As normas ISO são amplamente respeitadas e aceitas internacionalmente pelos setores 
público e privado (CAIÇARA JR., 2007). A International Organization for Standardization, ou 
ISO, é uma organização não governamental, uma federação de organismos nacionais de 
normalização de todas as regiões do mundo, incluindo países desenvolvidos e países em 
desenvolvimento (MARSHALL JR. et al., 2012).
Cada membro da ISO possui uma agência principal de normalização em seu próprio 
país. Os países-membros propõem as novas normas, envolvem-se em seu desenvolvimento 
e prestam apoio, divididos em grupos técnicos, em conjunto com a Secretaria Geral da ISO, 
localizada em Genebra, na Suíça (PRESSMAN; MAXIM, 2016).
O termo ISO tem raiz grega, significando igual, igualdade, o qual dá nome à organização, 
que também coincide com sua sigla. Esse é um significado muito adequado a essa entidade, 
uma federação internacional independente com o propósito de proporcionar sistemas uni-
formes de segurança, qualidade e eficiência do trabalho para trocas simples, entre países e 
regiões, de bens e serviços produzidos (PRESSMAN; MAXIM, 2016).
O ano de 1945 foi fundamental para a história da entidade, pois os delegados do Comitê 
Coordenador de Padronização das Nações Unidas (UNSCC) se reuniram em Nova Iorque 
para tentar criar uma organização de padrões, fundando as bases para a ISO (PRESSMAN; 
MAXIM, 2016). Ela foi estabelecida em 1946, com a participação de 64 delegados, de 25 
países, em Londres, Inglaterra, na sede do Instituto de Engenheiros Civis. Essas pessoas 
Normas e padrões2
Qualidade e Usabilidade de Software28
decidiram aventurar-se no projeto de uma organização cujo objetivo seria facilitar a indus-
trialização e as regras de unificação e melhoria da coordenação internacional das empresas 
(CAIÇARA JR., 2007).
Em 27 de fevereiro de 1947, a ISO foi finalmente oficializada e iniciaram-se suas ope-
rações. Naquele ano, mais de 19.500 normas foram criadas para todos os setores de produ-
ção, incluindo o setor da saúde, a indústria de alimentos, a de tecnologia etc. (PRESSMAN; 
MAXIM, 2016).
Em 1987, surge a norma ISO 9000, com a finalidade básica de facilitar ainda mais o 
comércio global. Para chegar a um consenso sobre essa legislação, foi necessário o apoio de 
75% dos países que a compõem. Essa política baseia-se em dois pilares: melhoria e desempe-
nho, enraizada em princípios, incluindo mercados, regulação, melhorias, responsabilidade, 
desenvolvimento do intelecto etc. A partir de 1994, foi implementada a versão ISO 9001, 
quando ela se tornou mais interessante para as empresas (CAIÇARA JR., 2007).
A norma passou por um enorme crescimento desde então. A norma de 1994 era es-
pecificamente dirigida a empresas com processos de produção e, portanto, na revisão de 
2000 (ABNT, 2000), ela foi simplificada e tornou-se aplicável a todos os tipos de empresas, 
públicas ou privadas.
A versão atual do padrão é datada de 2015 – a ISO 9001:2015 (ABNT, 2015), um aperfei-
çoamento de sua edição anterior, de 2008 – ISO 9001:2008 (ABNT, 2008). A fim de validar a 
implementação dessa norma, faz-se necessária uma auditoria de certificação e aplicação das 
regras de qualidade, e, se a conformidade for constatada, é emitido um certificado à empre-
sa (MARSHALL JR. et al., 2012).
Em relação à engenharia de software, a NBR ISO/IEC 9126-1 é a atual padronização 
mundial de qualidade de produtos, propondo métricas e atributos para os produtos de 
software (ABNT, 2003). Sob o título geral Engenharia de Software – qualidade do produto, essa 
norma abrange, em suas três partes, o modelo de qualidade a ser adotado, as métricas in-
ternas e as métricas externas – características e subcaracterísticas do produto de software.
2.2.2 CMMI
O Capability Maturity Model Integration (CMMI) foi criado pelo SEI (Software Engineering 
Institute), um órgão de pesquisa da universidade norte-americana Carnegie Mellon, e con-
siste em um modelo de garantia de qualidade com enfoque voltado para a capacidade de 
maturidade de processos de software nas empresas.
Em 1984, o SEI começou a pesquisa para desenvolver um quadro de melhoria e 
avaliação da qualidade das empresas de desenvolvimento de software que fornecem 
serviços para o Departamento de Defesa dos Estados Unidos. O resultado da investi-
gação foi chamado de Capability Maturity Model Software (SW-CMM), um modelo de 
maturidade de capacidades desenvolvido para processos relacionados com a produção 
e manutenção de sistemas de software, que teve sua versão 1.0 publicada em agosto de 
1991 (MARSHALL JR. et al., 2012). Posteriormente, como resultado do feedback gerado 
Normas e padrões
Qualidade e Usabilidade de Software
2
29
pela comunidade de software, novas versões alteraram e acrescentaram uma série de 
elementos na CMM, principalmente em relação a sua institucionalização nas organiza-
ções. Assim, o SW-CMM pode ser usado para dois fins (CAIÇARA JR., 2007):
• Melhorar os processos relacionadoscom a produção e manutenção de software;
• Definir critérios para a determinação do nível de maturidade de uma organização 
que produz e mantém software.
Com o passar do tempo e a evolução do modelo CMM, estabelece-se o CMMI, que teve 
como um de seus propósitos unir vários modelos usados em conjunto dentro de organiza-
ções, em prol de melhorias de processo (CAIÇARA JR., 2007), como modelos de desenvol-
vimento de software (SW-CMM), sistemas de engenharia (SECM) e desenvolvimento de 
produtos integrados (IPD-CMM). O CMMI serve como um guia que auxilia as empresas a 
gerenciar, mensurar e monitorar produtos e serviços e contém as práticas ligadas à gestão 
de projetos e de processos, à engenharia e ao suporte.
Assim, o modelo CMMI busca a melhoria contínua dos processos organizacionais, por 
meio da análise e redesign, fornecendo, de acordo com Caiçara Júnior (2007):
• Uma maneira de integrar os elementos funcionais de uma organização;
• Um conjunto de melhores práticas com base em histórias de sucesso, comprova-
das por organizações com experiência em práticas de melhoria de processos;
• Uma ajuda para identificação de metas e prioridades para a melhoria dos pro-
cessos, dependendo dos pontos fortes e fracos da organização, obtidos por um 
método de avaliação;
• Um suporte às empresas em atividades produtivas complexas para coordenar as 
suas atividades;
• Uma referência para avaliar os processos atuais da organização.
O CMMI for Services fornece orientação para a prestação de serviços aos clientes inter-
nos e externos da organização. Em 2000, foi desenvolvido e publicado o método Requisitos 
de avaliação para o CMMI, que define os elementos considerados essenciais para avaliar o 
CMMI em uma empresa, e o Padrão de avaliação CMMI para melhoria de processos. Esses dois 
documentos também foram atualizados como resultado do feedback da comunidade envol-
vida em CMMI, gerando a versão mais recente 1.2 do SCAMPI1 e ARC2, ambos publicados 
em 2006 (CAIÇARA JR., 2007).
2.2.2.1 Níveis de maturidade e capacidade
O CMMI está dividido em cinco níveis de maturidade, que atestam o grau de evolu-
ção de uma organização em determinado momento e tem como objetivo principal guiar a 
melhoria de processos das empresas. Com ele é possível gerenciar o desenvolvimento e a 
1 Métodos de avaliação SCAMPI (Standard CMMI Appraisal Method for Process Improvement) são os 
métodos geralmente aceitos para avaliar organizações perante os modelos CMMI (ISD BRASIL, 2017).
2 O documento de avaliação por áreas de resultado-chave ARC (Appraisal Requirements for CMMI) 
descreve requisitos para diferentes tipos de avaliação, buscando uma uniformidade entre os métodos 
(CARNEGIE MELLON UNIVERSITY, 2006).
Normas e padrões2
Qualidade e Usabilidade de Software30
produção de software, com base em prazos e custos estabelecidos e com mais qualidade. 
Esses níveis estão demonstrados na Figura 3:
Figura 3 – Níveis de maturidade do CMMI.
1 - Inicial
Processo im-
previsível e 
sem controle
2 - Repetível
Processo dis-
ciplinado
3 - Definido
Processo 
consistente e 
padronizado
4 - Gerenciado
Processo previ-
sível e contro-
lado
5 - Otimizado
Processo con-
tinuamente 
melhorado
Fonte: Elaborada pela autora, com base em CMMI INSTITUTE, 2017.
Esses níveis de maturidade de processos de uma organização são definidos a seguir 
(PRESSMAN; MAXIM, 2016):
Nível 1: Inicial
No nível 1 de maturidade, a maioria dos processos são ad-hoc e caóticos e a organização 
geralmente não fornece um ambiente estável para apoiá-los. Sucessos nesse caso ocorrem 
devido aos esforços para superar a concorrência e de pessoas competentes dentro da orga-
nização, e não do uso de processos comprovados. Apesar desse caos, as organizações per-
tencentes ao nível 1 frequentemente produzem os produtos e serviços que disponibilizam; 
no entanto, frequentemente excedem seus orçamentos e não cumprem os seus planos. Essas 
empresas têm como características a tendência a não honrar os seus compromissos, a aban-
donar processos em tempos de crise e a incapacidade de repetir seus sucessos. Ainda, nesse 
nível os trabalhos são executados de modo redundante por pessoas que não compartilham 
seus métodos de trabalho com toda a organização.
Nível 2: Repetível (Gerenciado)
No nível 2, o caos passa a ser ordenado, e as organizações se concentram em tarefas 
diárias relacionadas com a administração. Cada projeto tem uma série de processos plane-
jados e executados em conformidade com as políticas estabelecidas. São utilizadas pessoas 
qualificadas, que têm os recursos para produzir saídas controladas.
A disciplina de processo refletida pelo nível 2 de maturidade ajuda a garantir práticas 
e projetos de acordo com planos documentados e tanto a produção como a prestação de 
serviços são definidos. Os contratos são estabelecidos entre as partes interessadas e também 
revistos quando necessário. Artefatos e serviços são devidamente controlados, satisfazendo 
suas descrições específicas, padrões e procedimentos.
Nível 3: Definido
No nível 3 de maturidade, os processos são descritos em normas, procedimentos, fer-
ramentas e métodos. O conjunto de processos padrão da organização é estabelecido e con-
tinuamente melhorado, de modo consistente para toda a empresa. Os projetos são estabe-
lecidos por meio da adaptação desse conjunto de procedimentos e normas de acordo com 
diretrizes específicas.
Normas e padrões
Qualidade e Usabilidade de Software
2
31
Uma diferença importante entre os níveis 2 e 3 de maturidade é o escopo das normas: 
a descrição de processos e procedimentos. No nível 2, as normas podem ser um pouco di-
ferentes em cada instância específica do processo (por exemplo, em um projeto particular). 
No nível 3, padrões, descrições de processos e procedimentos em um projeto são adaptados 
com base em um conjunto de processos padrão da organização para determinado projeto ou 
unidade organizacional e, portanto, são mais consistentes.
Outra distinção importante é que no nível de maturidade 3 os processos são geralmente 
descritos de forma mais rigorosa do que no nível 2. Um processo definido apresenta clara-
mente sua finalidade, insumos, critérios de entrada, atividades, papéis, medidas, etapas de 
verificação, saídas e critérios de saída. No nível 3, os procedimentos são geridos de forma 
mais proativa, compreendendo as inter-relações de atividades e medidas detalhadas do pro-
cesso, seus artefatos e serviços.
Nível 4: Gerenciado quantitativamente
No nível 4, a organização e os projetos estabelecem metas quantitativas para medir a 
qualidade e o desempenho dos processos, as quais são utilizadas como critérios na gestão. 
Os objetivos quantitativos são definidos com base nas necessidades de clientes, usuários 
finais, organização, processos e atores. A qualidade e o desempenho das atividades são 
compreendidos em termos estatísticos e tratados em todo o processo de ciclo de vida. Para 
subprocessos selecionados, são recolhidas e analisadas estatisticamente medidas sobre pro-
cessos de execução, as quais são incorporadas nas métricas de repositório da organização, 
para apoiar a tomada de decisão.
As variações dos processos, quando ocorrem, devem ser identificadas e corrigidas na 
causa raiz para prevenir futuras ocorrências de mudanças de processos.
Uma diferença importante entre os níveis 3 e 4 é a previsibilidade do desempenho do 
processo. No nível 4 de maturidade, esse desempenho é controlado usando-se técnicas esta-
tísticas e quantitativas, e o processo é quantitativamente previsível; por outro lado, no nível 
3 o desempenho do processo é previsível apenas qualitativamente.
Nível 5: Otimizado
No nível 5 de maturidade, uma organização melhora continuamente seus processos 
com base no conhecimento das causas comuns de variação inerente a processos. Trata-se 
de melhorias contínuas, incrementais e tecnológicas. Os objetivos de melhoria de processos 
quantitativos para a organização são estabelecidos e continuamente revisados, sendo utili-zados como critério de qualidade em processos.
Uma diferença importante entre os níveis 4 e 5 é o foco da variação do processo. No 
nível 4 de maturidade, a organização direciona-se para encontrar as causas especiais de va-
riação e fornecer uma previsão estatística dos resultados. No entanto, os resultados podem 
ser insuficientes para alcançar as metas estabelecidas. No nível 5, a organização está focada 
nas causas comuns de variação de processo e modifica os procedimentos afetados para me-
lhorar o desempenho deles e atingir os objetivos quantitativos de melhoria de processos.
Normas e padrões2
Qualidade e Usabilidade de Software32
O quadro a seguir explica resumidamente o que acontece em cada um desses níveis.
Quadro 1 – Características dos níveis de maturidade das organizações.
Nível Características
Inicial
 2 Basicamente nenhuma prática forma de gerenciamento de engenharia 
de software está implantada na organização.
 2 Tudo é feito à medida em que vão surgindo as necessidades.
 2 O padrão usual é o não cumprimento de prazos e orçamentos 
estabelecidos.
 2 A maioria das atividades são respostas a crises e não a tarefas 
pré-planejadas.
 2 O processo de software é imprevisível e depende totalmente da equipe 
atual.
 2 É impossível prever com precisão o tempo necessário para desenvol-
ver um produto ou o seu custo.
Repetível
 2 Já estão implantadas práticas básicas de gerenciamento de projetos de 
software.
 2 As técnicas de planejamento e gerenciamento se baseiam em experiên-
cias com produtos similares (daí o termo repetível).
 2 Há o acompanhamento meticuloso dos cronogramas de prazo e da 
planilha de custos.
 2 Os gerentes identificam problemas à medida que eles vão surgindo e 
tomam ações corretivas imediatas para evitar que eles se transformem 
em crises.
 2 Medidas tomadas durante um projeto podem ser usadas para elaborar 
cronogramas e orçamentos realistas para projetos futuros.
Definido
 2 O processo para a produção de software é completamente 
documentado;
 2 Tanto aspectos técnicos quanto gerenciais do processo são claramente 
definidos.
 2 São feitos esforços contínuos para melhorar o processo onde for 
possível.
 2 São usadas revisões para atingir as metas de qualidade de software.
 2 Há a introdução de novas tecnologias, como as ferramentas CASE 
para aumentar a produtividade.
Normas e padrões
Qualidade e Usabilidade de Software
2
33
Nível Características
Gerenciado
 2 A organização estabelece metas de qualidade e produtividade para 
cada projeto.
 2 A qualidade e a produtividade são medidas continuamente.
 2 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis 
das metas.
 2 Controles estatísticos de qualidade são implantados para a gerência ser 
capaz de distinguir o desvio esporádico de um problema significativo 
nos padrões de qualidade ou produtividade.
Otimizado
 2 Há aperfeiçoamento contínuo do processo.
 2 São usadas técnicas de controle estatístico de processos e qualidade 
para orientar a organização.
 2 O conhecimento adquirido em cada projeto é utilizado em projetos 
futuros.
 2 O processo incorpora uma curva de realimentação positiva, resultando 
em uma melhoria contínua na produtividade e na qualidade.
Fonte: Elaborado pela autora, com base em SCHACH, 2010, p. 93-94.
Dependendo do modelo de representação usada em CMMI, existem duas maneiras de 
realizar a melhoria de processos. Uma delas é utilizando a representação contínua e a outra 
é melhorando toda a organização, de acordo com os processos definidos. A representação 
contínua se concentra em melhorar um procedimento de modo que a organização possa ser 
certificada para uma área de processo, em um determinado nível de capacidade. Existem 
seis níveis de capacidade ao longo dos quais os processos são associados em uma área 
(Quadro 2), e cada um deles é construído sobre o nível anterior – ou seja, um processo, para 
chegar a determinado nível de capacidade, deve necessariamente ter atingido um nível an-
terior (CAIÇARA JR., 2007).
Quadro 2 – Níveis de representação contínua e escalonada.
Representação contínua Representação escalonada
Nível de capacidade Nível de maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Manejado Manejado (repetível)
Nível 3 Definido Definido
Nível 4 Manejado quantitativamente Manejado quantitativamente (gerenciado)
Nível 5 Otimizado Otimizado
Fonte: CYBIS et al., 2015. Adaptado.
Normas e padrões2
Qualidade e Usabilidade de Software34
Nos processos de representação contínua, os níveis de capacidade são delimitados da 
seguinte forma:
• Nível 0 – Incompleto – um processo é chamado de incompleto quando um ou mais 
objetivos da área de processo não estão em conformidade.
• Nível 1 – Realizado – é chamado de feito ou realizado o processo que satisfaz todas 
as metas específicas da área de processo.
• Nível 2 – Manejado (produzido) – é designado processo de gestão quando o 
projeto apresenta a infraestrutura para suportá-lo. O processo é planejado e 
executado de acordo com a política da empresa, envolvendo as partes interes-
sadas, e emprega pessoas qualificadas que tenham recursos adequados para 
produzir saídas controladas. É monitorado, controlado, revisto e avaliado de 
acordo com sua descrição específica.
• Nível 3 – Definido – é uma adaptação do conjunto de normas da organização, 
de acordo com as diretrizes da empresa, e fornece dispositivos, medidas e outras 
informações para melhorar os ativos da organização.
• Nível 4 – Manejado (gerenciado) quantitativamente – é controlado usando-se 
técnicas quantitativas estatísticas e outras. Metas quantitativas para a qualida-
de e o desempenho do processo são estabelecidas e utilizadas como critérios 
para sua gestão.
• Nível 5 – Otimizado – otimização é a melhoria contínua do processo, com base no 
entendimento de causas comuns de variação de processo. Esse processo é realiza-
do por meio de aperfeiçoamentos incrementais e usando-se a inovação tecnológica.
Na representação escalonada, um método de melhoria de processo estruturado e sis-
temático, também envolve uma graduação em estágios ou níveis. Para atingir determinado 
nível, a organização precisa ter uma infraestrutura robusta, em termos de processos, para 
se qualificar para o próximo nível. Por isso, a empresa pode ser classificada pelo seu nível 
de maturidade, de 1 a 5, os quais são compostos por áreas de processo em que os obje-
tivos devem ser cumpridos a fim de que a organização possa ser certificada (Quadro 3) 
(PRESSMAN; MAXIM, 2016).
Quadro 3 – Modelo de classificação de áreas de processos organizacionais em níveis de 
maturidade.
Área de processo Categoria
Nível de 
maturidade
Análise e resolução das causas Suporte 5
Análise e resolução das decisões Suporte 3
Assegurando a qualidade dos processos e produtos Suporte 2
Definição de produtos organizacionais +IPPD (OPD 
+IPPD) Gestão de processos 3
Normas e padrões
Qualidade e Usabilidade de Software
2
35
Área de processo Categoria
Nível de 
maturidade
Desenvolvimento de requerimentos Engenharia 3
Treinamento organizacional Gestão de processos 3
Administração quantitativa de projetos Gestão de projetos 3
Administração de acordo com provedores Engenharia 2
Administração de requerimentos Gestão de projetos 3
Administração de riscos Suporte 2
Administração de configuração Gestão de projetos 3
Administração integral do projeto Gestão de projetos 3
Inovação e desenvolvimento organizacional Gestão de processos 5
Integração de produto Engenharia 3
Medição e análise Suporte 2
Monitoração e controle do projeto Gestão de projetos 2
Planejamento do projeto Gestão de projetos 2
Processos orientados às organizações Gestão de processos 3
Rendimento de processos organizacionais Gestão de processos 4
Solução técnica Engenharia 3
Validação Engenharia 3
Verificação Engenharia 3
Fonte: CYBIS et al., 2015. Adaptado.
2.3 Métricas de qualidade de software
As métricas de qualidade fornecem uma indicação de que o software estáem confor-
midade com as exigências implícitas e explícitas dos clientes. O principal objetivo da en-
genharia de software é produzir com uma alta qualidade. A fim de atingir esse objetivo, 
os engenheiros de software devem usar medições técnicas, de modo objetivo, para avaliar 
a qualidade dos modelos de análise, o código-fonte e casos de teste que foram criados por 
meio da aplicação de engenharia de software (MARSHALL JR. et al., 2012).
O primeiro objetivo da equipe de projeto é o de medir os erros e defeitos. As métricas 
que vêm do resultado dessas medidas fornecem uma indicação da eficácia das atividades de 
controle e garantia de qualidade (PRESSMAN; MAXIM, 2016).
De acordo com Marshall Junior et al. (2012), as métricas de qualidade de software en-
globam: o resumo dos fatores que afetam a qualidade, a medida de qualidade e a eliminação 
dos defeitos.
Normas e padrões2
Qualidade e Usabilidade de Software36
2.3.1 Resumo dos fatores que afetam a qualidade
Marshall Jr. et al. (2012), define um conjunto de fatores de qualidade que avaliam o 
software sob três pontos de vista diferentes:
• operação do produto (usá-lo);
• revisão do produto (alterando-o);
• transição do produto (modificando-o para trabalhar em um ambiente diferente).
Assim, se fornece um mecanismo para o operador do produto – ou seja, a pessoa res-
ponsável pelo desenvolvimento do software – identificar se ele atende os requisitos de qua-
lidade pré-estabelecidos.
2.3.2 Medida de qualidade
Exatidão, facilidade de manutenção, integridade e facilidade de utilização são medidas 
de qualidade que fornecem indicadores úteis para a equipe do projeto (MARSHALL JR. et 
al., 2012) e devem ser avaliadas pela equipe de produção e pelos gestores:
• Exatidão: é o grau em que o software executa a sua função.
• Manutenção: é a facilidade com que um programa pode ser corrigido se um erro 
de sistema, seja de código ou de requisitos, for encontrado.
• Integridade: mede a capacidade de um sistema para resistir a ataques (acidentais e 
intencionais) à sua segurança. Os ataques podem ser executados em qualquer um 
dos três componentes de software – programa, dados e documentos3.
 Para medir a integridade, é preciso definir dois atributos adicionais: ameaça e se-
gurança. Ameaça é a probabilidade de que um ataque dê certo em determinado 
momento. Já a segurança é a probabilidade que o sistema tem de repelir um ataque 
de certo tipo.
• Facilidade de uso: é uma tentativa de quantificar o quão amigável pode ser o pro-
grama para o usuário.
2.3.3 Eliminação dos defeitos
É o entendimento dos principais defeitos presentes nos projetos de software – como er-
ros na gestão, prazos curtos, erros de código –, com o objetivo de avaliá-los e eliminá-los, de 
modo a garantir o controle de qualidade em todas as atividades do processo (MARSHALL 
JR. et al., 2012).
As métricas de qualidade, portanto, são fundamentais nos processos de desenvolvi-
mento de softwares, pois auxiliam no monitoramento e no controle da qualidade, por meio 
de testes que ajudam a prever erros e a corrigir defeitos que, por ventura, possam surgir.
3 A documentação de software consiste em manuais gerais e técnicos ou mesmo relatórios que expli-
cam o funcionamento do programa ou sistema e acompanham o produto, explicando ao cliente como 
utilizá-lo e suas características.
Normas e padrões
Qualidade e Usabilidade de Software
2
37
 Ampliando seus conhecimentos
O texto a seguir trata sobre a importância de as empresas de desenvol-
vimento de software terem certificações na área de tecnologia, pois estas 
não apenas garantem qualidade de processos e produtos, como também 
atraem clientes.
Gestão da qualidade
(SILVA; AZEVÊDO, 2015, p. 100-101)
A gestão da qualidade de software tem como objetivo normatizar e rever 
periodicamente os conceitos e métodos utilizados por uma empresa, 
garantindo melhoria e correções nos processos de desenvolvimento, com 
base em estudos e estatísticas minuciosas. A área acompanha todos os 
processos de construção dos softwares: modelagem de negócio, e licita-
ção de requisitos, análise e designer do projeto, implementação, testes, 
implantação, gerenciamento de configuração e mudança, gerenciamento 
de projeto e ambiente.
A área da qualidade trabalha de acordo com as normas da ISO 9001, ISO 
9002 e ISO 9003. Apesar de muitos acharem que o procedimento de certifi-
cação de uma empresa de tecnologia é muito diferente das empresas indus-
triais, os profissionais vêm mostrando que não. As fábricas de softwares 
são os grandes exemplos disso, pois as mesmas têm se preocupado com a 
focalização nos clientes, abordagem dos processos, envolvimento dos sta-
keholders, comprometimento da liderança, relação com os fornecedores e 
a melhoria contínua dos processos.
Muitos clientes que prezam por mais confiabilidade nos contratados bus-
cam empresas que sejam certificadas na área. Hoje são diversas as certifi-
cações, onde cada uma atende necessidades específicas do negócio.
As mais conhecidas da área de tecnologia são: CMMI e 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 currículo da empresa, atraem clientes que buscam por 
parceiros com maior qualidade nos processos.
A área da qualidade se responsabiliza pela garantia do cumprimento dos 
processos e pela melhoria dos mesmos — melhoria contínua. O produto é 
visto como consequência da execução desses processos. Apesar dos esfor-
ços serem voltados para o processo, o principal objetivo é garantir um 
produto final que satisfaça o cliente.
[...]
Normas e padrões2
Qualidade e Usabilidade de Software38
 Atividades
1. Explique em que as normas para os sistemas de informações auxiliam os processos 
e como é seu uso.
2. O que é SW-CMM e como ele pode ser usado?
3. Como é possível avaliar os fatores que afetam a qualidade de software?
4. Quais são os cinco níveis de maturidade de uma organização?
 Referências
ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 9001:2000: Sistemas de Gestão da 
Qualidade: requisitos. Rio de Janeiro, 2000.
______. NBR ISO/IEC 9126-1: Engenharia de Software: qualidade de produto. Rio de Janeiro, 2003.
______. NBR ISO 9001:2008: Sistemas de Gestão da Qualidade: requisitos. Rio de Janeiro, 2008.
______. NBR ISO 9001:2015: Sistemas de Gestão da Qualidade: requisitos. Rio de Janeiro, 2015.
CAIÇARA JUNIOR, C. Informática, internet e aplicativos. Curitiba: Ibpex, 2007.
CARNEGIE MELLON UNIVERSITY. CMMI para Desenvolvimento – versão 1.2. ago. 2006. Disponível 
em: <http://www.sei.cmu.edu/library/assets/whitepapers/cmmi-dev_1-2_portuguese.pdf>. Acesso 
em: 3 ago. 2017.
CMMI INSTITUTE. Disponível em: <http://cmmiinstitute.com/capability-maturity-model-integra-
tion>. Acesso em: 19 jul. 2017.
CYBIS, W. et al. Ergonomia e usabilidade: conhecimentos, métodos e aplicações. 3. ed. São Paulo: 
Novatec, 2015.
ISD BRASIL. O que é SCAMPI? Disponível em: <http://www.isdbrasil.com.br/o-que-e-scampi.php>. 
Acesso em: 3 ago. 2017.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. São Paulo: Pearson Prentice Hall, 
2004.
MARSHALL JR., I. et al. Gestão da qualidade e processos. Rio de Janeiro: Ed. da FGV, 2012.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Pearson Prentice Hall, 2004.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. São 
Paulo: AMGH Bookman, 2016.
SCHACH, S. R. Engenharia de software: os paradigmas clássico e orientado a objetos. Tradução de A. 
Griesi. 7. ed. Porto Alegre: AMGH, 2010.
SILVA, R. B. C; AZEVÊDO, L. S. L. A importância da engenharia de testes para a qualidade de softwa-
re. Revista Eletrônica Científica Inovação e Tecnologia, v. 2, n. 12, jul./dez. 2015.
Normas e padrões
Qualidade e Usabilidade de Software
2
39
SOMMERVILLE, I. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011. Disponível 
em: <https://revistas.utfpr.edu.br/recit/article/view/4256>.