Qualidade Software

Prévia do material em texto

QUALIDADE DE 
SOFTWARE
Aline Zanin
Qualidade de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Conceituar qualidade de software.
  Identificar os benefícios da qualidade de software.
  Aplicar os conceitos de qualidade.
Introdução
Ao adquirir um produto ou serviço, o cliente deseja que esse produto 
seja entregue em pleno funcionamento, de acordo com aquilo que foi 
solicitado e livre de falhas. No contexto de software, essa realidade é 
exatamente a mesma: quando o cliente solicita um software, cria-se uma 
expectativa e, por isso, faz-se necessário garantir que o software atenda 
a ela. O produto deve ser entregue em funcionamento e deve atender 
aos requisitos solicitados pelo cliente.
O responsável pela garantia dessa entrega eficaz é o setor de qua-
lidade de software. A qualidade de software atua em dois segmentos 
distintos: qualidade de produto e qualidade de processo. Neste capítulo, 
você vai estudar os conceitos fundamentais desses dois segmentos, bem 
como conhecer os benefícios da qualidade de software e como aplicá-la 
nos projetos de desenvolvimento de sistemas.
Conceitos 
A palavra qualidade parece ter um signifi cado bastante óbvio, contudo, trata-
-se de um elemento complexo e de difícil mensuração, dado que a qualidade 
é relativa e pode assumir diversos valores, de acordo com a pessoa que a 
observa. Nesse sentido, a qualidade do software pode ser medida de acordo 
com o quanto ele está em conformidade com o que o cliente solicitou. Ou seja, 
mensura-se se o software está em conformidade com os requisitos funcionais 
e não funcionais especifi cados explicitamente pelo cliente, conforme leciona 
Basu (2015).
Façamos uma analogia: suponha que você tenha preferência por chocolate do tipo 
meio amargo, e seu irmão tenha preferência por chocolate ao leite; ao chegar em 
casa, se seu pai trouxer um chocolate ao leite, muito provavelmente seu irmão dirá 
que esse chocolate é de alta qualidade, enquanto você dirá que o chocolate não tem 
qualidade, porque não atende ao seu gosto, à sua expectativa.
Embora a qualidade do software seja uma prática recente, que ganhou evi-
dência com o advento da tecnologia, a qualidade, no geral, é uma preocupação 
bem antiga. Existem registros de que há mais de quatro mil anos os egípcios 
estabeleceram um padrão de medida para realizar seus trabalhos de forma 
apurada, chamado de cúbito, que equivalia ao tamanho do braço do faraó 
reinante, conforme Koscianski e Soares (2007). 
Entretanto, mesmo a qualidade sendo um conceito tão antigo, os projetos 
de software contam com vários desafios para entregar o software em perfeito 
funcionamento, devido a uma série de fatores — em especial, a complexi-
dade. Isso porque construir um sistema envolve diversas habilidades, como 
comunicação e interpretação, para conseguir entender o que o cliente deseja, 
além de habilidades específicas para as etapas de programação, análise da 
qualidade, entre outras, que são de grande complexidade.
Dada a multidisciplinariedade envolvida no processo de desenvolvimento 
de software e a complexidade de todo o processo, o segmento de qualidade se 
divide em duas áreas relacionadas, porém distintas: qualidade de processos 
e qualidade de produtos. A área de qualidade de processos trata da organi-
zação sistemática dos processos da empresa, visando ao melhor andamento 
dos projetos de desenvolvimento de sistemas, otimizando o tempo, tornando 
os processos repetitivos e evitando problemas em situações críticas para os 
projetos, por exemplo: estimativa, custo, entrada e saída de recursos humanos.
Ao buscar garantir a qualidade de um software, estamos diante do desafio 
de estabelecer uma cultura de não tolerância a erros, por meio de processos 
que objetivem inibir ou impedir falhas, segundo Bartié (2002). É a área de 
qualidade de processos que se responsabiliza pela definição da metodologia ou 
Qualidade de software2
do ciclo de vida de software que a equipe utilizará, podendo optar, por exemplo, 
por trabalhar com métodos ágeis ou métodos tradicionais. Independentemente 
da metodologia escolhida, o importante é que um processo seja seguido, para 
que a equipe tenha um padrão para se basear. Isso melhora a comunicação e 
influencia na qualidade dos produtos desenvolvidos pela equipe. 
A área de qualidade de produtos tem por objetivo garantir a qualidade do 
produto tecnológico gerado durante o ciclo de desenvolvimento. Para esse fim, 
são realizadas atividades com o objetivo de estressar as funcionalidades do 
sistema, identificando o comportamento dele nesse contexto. Essas atividades 
são chamadas de testes de software. Essa área possui algumas divisões, sendo 
a mais importante a subdivisão entre testes que fazem uso do código-fonte do 
programa, chamados de caixa branca, e testes que não fazem uso do código-
-fonte do programa, chamados de caixa preta. Além disso, os testes podem 
ser feitos de forma manual ou automatizada e fazendo uso das mais diversas 
técnicas, conforme Bartié (2002). 
A eficiência de um processo de testes é afetada diretamente por alguns 
fatores, que devem ser considerados para evitar problemas nas organizações, 
aponta Bartié (2002): falta de planejamento das atividades de testes, ausência 
de testes que validem funcionalidades antigas e ausência de processos de 
automação de testes.
Uma terminologia bastante importante e comum na área de testes de quali-
dade de software é o conceito de bug, que abrange erros, defeitos e falhas. Por 
curiosidade, o termo bug corresponde à palavra inseto em inglês e começou a ser 
utilizado justamente quando um inseto causou uma falha em um equipamento. 
É importante entender que os termos erro, defeito e falha se referem a coisas 
distintas. Defeito é um comportamento inesperado de um produto. O defeito está 
em uma parte do produto e, em geral, refere-se a uma funcionalidade que está 
implementado no código de maneira incorreta. Erro é aquilo que foi cometido 
pelo programador e que gerou um código defeituoso, enquanto a falha se dá 
quando o programa defeituoso é executado e interfere no funcionamento do 
sistema para o usuário final. Falhas também podem ocorrer por fatores externos 
ao programa, como corrupção de bases de dados ou invasões de memória por 
outros programas, conforme Koscianski e Soares (2007).
Considere, por exemplo, o código a seguir, conforme Koscianski e Soares 
(2007):
a = input (); 
c = b/a;
d = a ? b/a : 0;
3Qualidade de software
A linha de código que calcula o valor para a variável c pode apresentar 
um problema, dado que não é feita uma verificação para validar se o valor 
de a é 0. Dessa forma, pode acontecer um erro ao tentar realizar uma divisão 
por zero. O comportamento anormal do programa, que provavelmente gera 
um bug ou uma interrupção da execução, é provocado pela divisão b/a. Em 
um primeiro momento, podemos dizer que essa linha de código é defeituosa.
Existe, entretanto, outra hipótese: o defeito pode estar na rotina input (). 
Imagine que a especificação dessa rotina estabeleça que ela não deve jamais 
retornar um valor nulo. Nesse caso, o erro foi cometido pelo programador 
responsável por essa rotina. Essa segunda hipótese é bastante razoável, pois, 
para a maioria dos programas, não é recomendado preceder cada operação 
de divisão com um teste if. Nesse caso, um erro cometido pelo programador 
na rotina input fez com que o programa apresentasse um defeito ao executar 
a divisão de a por b.
Benefícios
Inúmeros são os benefícios que as empresas podem ter ao demandar uma 
atenção especial para a área de qualidade de software. Os benefícios vão muito 
além de valores fi nanceiros, podendo estar relacionados inclusive com evitar 
transtornos legais ou preservar vidas.
Empresas que desenvolvem sistemas de semáforos têm uma responsabilidade muito 
grande, uma vez que um erro de programação pode causar um grande acidente de 
trânsito ou, na melhor das hipóteses, um transtorno no trânsito.É por isso que o controle de qualidade é totalmente importante e benéfico 
nos dias atuais. A qualidade de software possui diversos benefícios que ajudam 
os usuários a não sofrerem com falhas de software e as empresas a oferecerem 
produtos melhores, impedindo até mesmo grandes catástrofes. Vamos verificar 
alguns dos benefícios da qualidade de software, com base em Basu (2015):
Qualidade de software4
1. Economiza dinheiro — quanto dinheiro um projeto de software 
defeituoso lhe custa? Custa usuários e clientes. E é bem sabido que, 
quanto mais tempo leva para um bug ser detectado em seu software, 
mais difícil e caro é consertá-lo. Ao empregar testes de controle de 
qualidade durante o processo de desenvolvimento do software, você 
economizará tempo e dinheiro após a implantação.
2. Impede emergências corporativas catastróficas — com o software 
corporativo, as apostas são ainda maiores. Bugs no software corporativo 
podem levar a blecautes do sistema, falta de dados e falhas de comu-
nicação. Se você estiver empregando software em toda a empresa ou 
lidando com informações confidenciais, é melhor ter certeza de que o 
software funcionará exatamente como ele precisa funcionar. Não há 
margem para erro.
3. Inspira a confiança do cliente — ao tornar o teste de software de 
controle de qualidade uma prioridade clara para o desenvolvimento de 
software, você está enviando uma mensagem para seus clientes de que 
deseja que o software deles seja o mais bem-sucedido possível. Isso 
é extremamente importante quando você busca oferecer qualidade e 
criar relacionamentos de longo prazo.
4. Mantém o nível de experiência do usuário elevado — está se tornando 
cada vez mais claro hoje em dia que a experiência do usuário pode que-
brar ou impulsionar um negócio. Se o software estiver com problemas 
ou estiver lento, isso impedirá a experiência do usuário com o produto. 
Má experiência do usuário resulta em insatisfação e frustração. A boa 
experiência do usuário, que você obtém quando testa meticulosamente 
um produto de software, resulta em um usuário satisfeito — que tem 
muito mais probabilidade de recomendar o produto e sua empresa a 
outras pessoas.
5. Traz mais lucro — se você está criando um software para comercializar 
ou vender, investir em qualidade de software significa que você pode 
vender seu produto a uma taxa maior. Não há nada pior do que um 
usuário irritado que pagou por um produto que não funciona.
6. Aumenta a satisfação do cliente — relacionado ao ponto anterior, esse 
benefício está focado na reputação que a satisfação do cliente traz à sua 
empresa, não apenas no lucro. Ao oferecer um software de qualidade, 
que funciona quando e como você quer que ele funcione, você estará 
aumentando sua reputação, produzindo clientes satisfeitos. Não sobre-
carregue a paciência dos seus clientes com um software defeituoso, 
5Qualidade de software
que você precisa consertar constantemente. Dê-lhes qualidade desde 
o início, e eles lhe recompensarão com lealdade.
7. Promove organização, produtividade e eficiência — o que você menos 
deseja é o caos de um software defeituoso, uma comunicação frenética 
e correções apressadas. Ser organizado com o teste de controle de qua-
lidade, desde o início de sua estratégia de desenvolvimento, permitirá 
que você trabalhe em paz e seja mais produtivo com seu tempo. Ao 
utilizar metodologias ágeis, nas quais os desenvolvedores de software 
criam e entregam pequenos trechos de um produto em uma linha do 
tempo clara, você pode começar a testar o software à medida que ele 
é criado, em vez de sempre esperar até o final. 
Existe uma regra que vigora desde os princípios do teste de software, 
chamada regra 10 de Myers. Essa regra estipula que o custo de encontrar um 
defeito no sistema aumenta 10 vezes a cada etapa do processo em que esse 
erro avançar, conforme aponta Myers (1979). Essa regra é mais aplicada para 
o contexto de projetos com ciclo de vida em cascata, em que as etapas são 
executadas sequencialmente, dado que, em equipes ágeis, não existe essa 
divisão exata de etapas. A Figura 1 ilustra essa regra.
Figura 1. Regra 10 de Myers.
Fonte: MPT… (2010, p. 8).
12.000
10.000
8.000
6.000
4.000
2.000
0
De
se
nh
o
Es
pe
cifi
ca
çã
o
Co
ns
tru
çã
o
Te
ste
Pro
du
çã
o
Fases do processo de desenvolvimento
Cu
st
o 
em
 U
S$
Qualidade de software6
Aplicando a qualidade de software
Conforme vimos anteriormente, a área de qualidade de software pode ser 
dividida em qualidade de produtos e qualidade de processos e é uma im-
portante área no desenvolvimento de sistemas. Para a garantia da qualidade 
de processos, as empresas podem buscar certifi cações. Essas certifi cações 
fazem com a empresa seja, de certa forma, obrigada a seguir um processo 
que implemente a qualidade de processos de forma prática. As principais 
certifi cações são CMMI e MPS.BR.
O CMMI, sigla para Capability Maturity Model Integration, é um mo-
delo de maturidade utilizado para medir a maturidade dos processos de uma 
empresa. Ele serve também como um guia para a melhoria dos processos das 
organizações. Esse modelo classifica as empresas em cinco níveis, conforme 
Koscianski e Soares (2007), sendo eles:
 Inicial: processos caóticos; em geral, não existe um ambiente propício
para o desenvolvimento de software.
 Gerenciado: nesse nível, já é perceptível uma melhoria em relação ao
nível 1. Aqui já existem requisitos gerenciados e processos planejados,
medidos e controlados.
 Definido: nesse nível, a maturidade da empresa já está em um nível
considerável. Aqui os processos são caracterizados e entendidos.
 Gerenciado quantitativamente: nesse nível, os processos são controlados
usando métodos estatísticos e outras técnicas quantitativas.
 Otimizado: nesse nível, os processos são continuamente melhorados
com base em análises feitas pela equipe.
O MPS.BR — sigla para Melhoria do Processo de Software Brasileiro 
— também é um modelo de maturidade, similar ao CMMI e com o mesmo 
objetivo. O MPS.BR foi proposto no Brasil e é utilizado por empresas 
brasi-leiras. Esse modelo considera sete níveis, sendo eles:
 A: processo em otimização.
 B: processo gerenciado quantitativamente.
 C: processo definido.
 D: processo largamente definido.
 E: processo parcialmente definido.
 F: processo gerenciado.
7Qualidade de software
  G: processo parcialmente gerenciado.
Já para a qualidade de produto, diversas são as técnicas que podem ser 
empregadas. A área de testes de software é bastante abrangente e completa, 
sendo sempre recomendado que o trabalho de testes seja feito em conjunto 
com o desenvolvedor e durante o desenvolvimento do sistema, isto é, sem 
esperar que o sistema seja concluído para, então, testar. Vamos falar aqui de 
alguns tipos de testes e como aplicá-los, com base em Graham et al. (2008).
Teste unitário — é um tipo de teste realizado diretamente no código fonte 
do programa em teste. Nesse tipo de teste, são criadas funcionalidades de testes 
que validam o comportamento dos métodos ou funções implementadas pelo 
programador. No teste unitário, são identificados os primeiros erros e, quando 
obtido sucesso nos testes (ou seja, quando não forem localizadas falhas), as 
funcionalidades principais do programa devem estar funcionando. Um exemplo 
de técnica para teste unitário é o TDD — test driven development —, que tem 
por objetivo o desenvolvedor criar primeiro o código de teste, para depois criar 
a funcionalidade e, então, executar o teste que valida essa funcionalidade.
Teste funcional — é um tipo de teste realizado após o desenvolvimento do 
sistema ou de um módulo do sistema. O teste funcional pode ser automatizado 
ou manual. No caso de teste automatizado, são utilizados scripts de teste, que 
simulam o comportamento de um usuário no sistema, por exemplo, clicando em 
botões e inserindo valores em campos, e verificam a resposta do sistema para 
esses comportamentos. Para testes automatizados, esses scripts são executados 
automaticamente,e os defeitos localizados são sinalizados também de forma 
automática. No caso de testes manuais, os scripts são substituídos por casos 
de teste. Caso de teste é um documento em que é descrita a ação do usuário 
e a resposta esperada do sistema para ela. Nesse caso, a execução do caso de 
teste é feita manualmente, e o registro dos defeitos também.
Teste de aceitação — esse teste é realizado junto com o cliente e visa a 
verificar se o sistema que foi ou está sendo construído é realmente o que foi 
solicitado. 
Teste exploratório — esse tipo de teste é muito comum, mais rápido 
de ser realizado e se torna uma alternativa para projetos com cronograma 
apertado. Nesse tipo de teste, o testador usa a sua experiência para navegar no 
sistema visando a localizar erros. A principal vantagem desse tipo de testes é 
localizar defeitos que não seriam localizados nos demais testes; por exemplo, 
casos em que o usuário tem um comportamento incomum, como clicar duas 
vezes em um botão de salvar. Para organizar esses testes e garantir que as 
funcionalidades principais sejam testadas, é comum criar um checklist, que 
Qualidade de software8
nada mais é do que uma lista que registra os principais pontos que devem ser 
testados nas telas do sistema.
BARTIE, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002. 
BASU, A. Software quality assurance, testing and metrics. India: PHI Learning, 2015.
GRAHAM, D. et al. Foundations of software testing: ISTQB certification. United Kingdom: 
Cengage Learning EMEA, 2008.
KOSCIANSKI, A.; SOARES, M. Qualidade de software: aprenda as metodologias e técnicas 
mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007.
MPT – Melhoria de processo de teste brasileiro. 2010. Disponível em: <http://www.
mpt.org.br/wp-content/uploads/2010/12/MPT_BR_Nivel_1_v_2.2.pdf>. Acesso em: 
23 jan. 2019.
MYERS, G. J. Art of software testing. New York: John Wiley & Sons, 1979.
Leitura recomendada
LEWIS, W. E. Software testing and continuous quality improvement. Boca Raton: CRC 
Press, 2016.
9Qualidade de software
QUALIDADE DE 
SOFTWARE
Aline Zanin 
Garantias da qualidade 
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Definir as garantias da qualidade de software.
  Analisar as garantias da qualidade de software.
  Aplicar os métodos das garantias de software.
Introdução
A garantia da qualidade de software, do inglês quality assurance, pode ser 
definida como as atividades que dão suporte aos processos continua-
mente estabelecidos, visando a fornecer confiabilidade a esses processos. 
Para esse fim, os processos estão em contínua revisão, melhoria e adap-
tação, para produzir produtos que atendam aos requisitos estipulados 
pelo cliente e que sejam adequados para o uso pretendido.
A garantia de qualidade de software está associada com todas as 
atividades que formam o ciclo de desenvolvimento de um software, 
desde o primeiro contato com o cliente até a programação do software 
em si. Dessa forma, a área de garantia da qualidade se preocupa com a 
verificação e a validação do software, a verificação quanto aos processos 
e às definições (garantia da qualidade de processos) e a validação quanto 
ao produto (garantia da qualidade de produto). Para esse fim, diversas são 
as técnicas, os modelos e as atividades empregadas, conforme Campos 
([2019]). 
Neste capítulo, você vai estudar o conceito de garantia da qualidade e 
vai analisar algumas das técnicas que podem ser utilizadas para a garantia 
da qualidade. Por fim, algumas dessas técnicas serão demonstradas por 
meio de exemplos de aplicação.
Garantias da qualidade de software
A garantia da qualidade de software, ou os modelos de garantia da qualidade de 
software, como o próprio nome diz, tem como objetivo garantir que o software 
seja entregue ao cliente fi nal com qualidade e que o processo de verifi cação 
dessa qualidade seja conduzido de forma organizada.
Para que esse processo de garantia de qualidade de software tenha êxito 
em seu objetivo e possa ser executado pela equipe sem causar um consumo 
excessivo de tempo ou uma desmotivação do time, é necessário que esteja 
completamente integrado ao processo de desenvolvimento de software. Um 
bom processo de garantia de qualidade pode ser visto como uma relação de 
um para um com cada fase do processo de desenvolvimento de software; ou 
seja, realiza-se uma etapa de garantia da qualidade de software para cada etapa 
de desenvolvimento. Todo esse processo deve ser feito visando e reforçando 
a colaboração entre as áreas e a ciência por parte dos profissionais de um 
objetivo comum no time, segundo Bartié (2002).
Garantia de qualidade e controle de qualidade são áreas diferentes da engenharia de 
software. A área de controle de qualidade age diretamente sobre o produto e realiza 
a execução dos processos, enquanto a área de garantia da qualidade estrutura tanto 
o controle de processos quanto o controle de produtos e garante que estes estejam 
sendo executados.
Diversos são os modelos que podem ser utilizados para a garantia da 
qualidade. Esses processos incluem garantia da qualidade de processos e 
garantia da qualidade de produtos, verificação e validação. Um dos processos 
é o modelo de qualidade de software em U, que será descrito a seguir.
Modelo de qualidade de software em U
As fases do modelo de qualidade de software podem ser organizadas em um 
formato de U, sendo, nesse caso, o modelo de qualidade de software chamado 
de modelo U. Nesse modelo, as fases são executadas sequencialmente. O 
objetivo é garantir que durante o ciclo de desenvolvimento de software sejam 
Garantias da qualidade de software2
produzidos efetivamente todos os produtos previstos na metodologia empregada 
e que o software entregue esteja de acordo com o requisito esperado.
Esse modelo considera dois tipos de testes de software: testes de verificação 
e testes de validação. Os testes de verificação validam o processo de engenha-
ria de software, e os testes de validação garantem a qualidade do produto de 
software. Analisando a Figura 1, podemos verificar a divisão das etapas do 
modelo U conforme esses dois tipos de testes. As etapas que compreendem 
o modelo U são as seguintes:
Testes de verificação:
  Verificação do modelo de negócios — aqui, os testes verificam se 
foram levantadas informações suficientes sobre o modelo de negócios 
do cliente e como essas informações foram levantadas.
  Verificação da especificação de requisitos — aqui, os testes verificam 
se a partir do modelo de negócio do cliente foram definidos requisitos 
compatíveis, que vão agregar valor ao cliente por meio do produto de 
software.
  Verificação da análise e da modelagem — nessa etapa é verificado se 
a modelagem do sistema atende ao especificado nos requisitos e como 
essa modelagem é feita.
  Verificação da implementação — aqui se inicia a etapa de implemen-
tação; é verificada a estrutura para realização da implementação do 
sistema e o processo que será seguido para a implementação.
Testes de validação:
  Validação da unidade especificada ou modificada — nessa etapa é 
validada uma pequena unidade ou um componente de software que foi 
desenvolvido ou modificado.
  Validação da integração da unidade especificada ou modificada 
— nessa etapa é validada a integração dessa pequena unidade, ou 
componente de software, que foi desenvolvida ou modificada com o 
restante do sistema ou com sistemas externos, conforme a necessidade.
  Validação do sistema especificado ou modificado — aqui é realizada 
a validação do sistema como um todo, de suas funcionalidades imple-
mentadas e seus requisitos.
  Validação da disponibilização da solução — nessa etapa, o software 
já foi entregue ao cliente por meio de sua implementação; aqui é acom-
panhado se a implementação foi feita de forma correta e se o software 
3Garantias da qualidade de software
apresenta no cliente o mesmocomportamento que apresentou no am-
biente de testes.
Figura 1. Modelo de processo de qualidade de software em U.
Fonte: Adaptada de Bartie (2002).
5
Implementação
Verificação
da 
implementação
3
Análise e
modelagem
Verificação,
análise e
modelagem
5
Unidade
especificada ou
modificada
Validação
da
unidade
6
Integração
especificada
ou modificada
Validação
da
integração
7
Sistema
especificado ou
modificado
Validação
da
integração
8
Disponibilização
da
solução
Validação
do
aceite
1
Modelo
de
negócios
Verificação
de
negócios
2
Especificação
de
requisitos
Verificação
de
requisitos
TESTE DE VERIFICAÇÃO TESTES DE VALIDAÇÃO
Clientes
patrocinadores
usuários
Testes de verificação
O processo de desenvolvimento de software considera duas etapas principais, 
sendo elas: planejamento, em que são coletadas as informações e é planejada a 
arquitetura do software, e desenvolvimento, em que o sistema é de fato desen-
volvido. Os testes de verifi cação são realizados na etapa de planejamento e têm 
como objetivo avaliar se a documentação e o processo utilizado nessa etapa 
estão sendo feitos de forma correta. Nesse momento, não existem componentes 
tecnológicos, mas, sim, documentos que especifi cam o comportamento do 
software a ser construído. 
Os testes de verificação são aplicados de acordo com o estágio de desen-
volvimento. São realizados testes:
  na etapa de levantamento das necessidades do cliente e das caracterís-
ticas específicas para o software;
Garantias da qualidade de software4
  na etapa de identificação de requisitos funcionais e não funcionais do 
software;
  na etapa de definição do modelo de arquitetura e da solução tecnológica;
  na etapa de construção do software.
Testes de validação
Os testes de validação são um processo formal de avaliação de software e 
podem ser aplicados em componentes isolados, em módulos ou em funciona-
lidades já implementadas no sistema, ou mesmo no sistema como um todo. O 
objetivo desses testes é avaliar a conformidade do software com os requisitos 
especifi cados nas etapas iniciais do projeto. A principal característica desses 
testes é a necessidade de o software já estar em execução para ser testado 
devidamente. Diversas são as categorias de testes que podem ser aplicados 
durante o processo de desenvolvimento de software, sendo que as atividades de 
planejamento, modelagem, execução e conferência dos testes deverão ocorrer 
em paralelo às atividades de construção do software.
As validações serão aplicadas respeitando-se os estágios de desenvolvi-
mento. São realizados:
  testes em componentes executáveis;
  testes de interface entre componentes;
  testes em sistemas ou módulos completos;
  aceite de um sistema ou módulo pelo cliente.
Testes de verificação e testes de validação fazem parte do modelo U de 
qualidade, sendo que cada um desses tipos de teste compreende diversas 
atividades que precisam ser executadas, visando a garantir a qualidade do 
software. Na próxima seção, vamos analisar algumas das técnicas de garantia 
de qualidade de software, tanto de verificação quanto de validação.
Análise das garantias de qualidade de software
O processo de garantia da qualidade considera um olhar detalhado para a qua-
lidade tanto do processo quanto do produto. No processo, podemos quantifi car 
a sua qualidade por meio de métricas e, nos produtos, por meio de técnicas de 
verifi cação e validação. Todo esse processo de garantia da qualidade pode ser 
5Garantias da qualidade de software
avaliado, por exemplo, pela normativa ISO 9000, por auditorias, por inspeções 
formais ou por testes de software, conforme Campos ([2019]).
A área de garantia da qualidade tem alguns papéis fundamentais, conforme 
aponta Bastos et al. (2007):
  ajuda a estabelecer processos;
  determina programas de medida para avaliar processos;
  identifica fraquezas de medida para avaliar processos;
  é uma responsabilidade de gerenciamento;
  está relacionada com todos os produtos que serão gerados por um 
processo;
  avalia se o controle de qualidade está funcionando.
Conforme citado, uma das principais formas de garantia da qualidade é 
por meio de auditorias. Vamos analisar algumas das principais auditorias que 
podem ser feitas em processos de desenvolvimento de software, considerando 
os cenários em que cada uma pode ser aplicada.
A normativa ISO 9000 é utilizada para a garantia da qualidade de processos 
nos mais diversos aspectos. Empresas de todos os segmentos utilizam a ISO 
9000, inclusive como estratégia de marketing para seus produtos. Essa norma 
teve origem na norma britânica BS 570, publicada em 1979 pelo SBI (British 
Standards Institute), baseada em padrões militares. Em 1987, a norma foi 
revisada, mudando seu foco de exclusivamente empresas de manufatura para 
outras empresas prestadoras de serviços. No ano seguinte, o documento foi 
aceito pela ISO como padrão mundial.
A ISO 9000 é um conjunto de normas genéricas que serve a qualquer 
organização, de qualquer ramo de atividade, que queira realizar o controle 
de qualidade de seus produtos e serviços. Essa norma é mais conhecida pela 
sua versão 9001. A ISO 9001 descreve exigências para o sistema de gerência 
de qualidade da empresa. A qualidade de produtos e serviços não é estabele-
cida pela norma, mas, sim, pela própria empresa e pelas exigências de seus 
clientes. A norma ISO 9001 define processos que descrevem como a empresa 
deve realizar determinadas atividades (ASSOCIAÇÃO BRASILEIRA DE 
NORMAS TÉCNICAS, 2015). Os documentos que definem os processos são 
chamados pela ISO 9000 de procedimentos.
Garantias da qualidade de software6
Uma empresa que tem ISO 9001 para os seus processos terá, por exemplo, um pro-
cedimento que define como a telefonista deve atender ao telefone, isto é, qual frase 
deve ser dita ao receber uma ligação.
Já o CMM e o CMMI são dois dos principais modelos para melhoria de 
processos especificamente para software, criados pelo Software Engineering 
Institute — SEI. CMM é o acrônimo de capability maturity model ou modelo 
de capacidade de maturidade. Por esse modelo ser focado especificamente em 
software, ele não avalia outras áreas da empresa, como recursos humanos ou 
setor financeiro, conforme lecionam Koscianski e Soares (2007).
O CMM busca que as empresas conheçam e melhorem os seus processos 
de desenvolvimento de software com a implementação de práticas bem de-
finidas. Ele define uma escala para a maturidade da empresa, que se divide 
em cinco passos. Cada nível do CMM define áreas-chave que identificam um 
conjunto de objetivos que a empresa precisa cumprir para atingir esse nível 
de maturidade. Os níveis são:
1. Inicial.
2. Gerenciado.
3. Definido.
4. Gerenciado quantitativamente.
5. Otimizado.
No nível 1, nenhum processo está definido, e, no nível 5, todos os processos 
estão definidos, são seguidos e estão apenas sendo otimizados constantemente, 
conforme lecionam Koscianski e Soares (2007).
Com a evolução do CMM, foram criados modelo semelhantes para diversas 
áreas das empresas, por exemplo: P-CMM para gestão de recursos humanos, 
SA-CMM para aquisição de software, SE-CMM para engenharia de sistemas. 
Para integrar todos esses modelos, surgiu o CMMI, ou capability maturity 
model integration. O CMMI mantém os mesmos cinco níveis do CMMI, 
contudo, amplia as áreas de foco de cada nível, exceto o nível 1, que não tem 
objetivos específicos, por ser a ausência de processos. As áreas definidas para 
cada nível do CMMI são mostradas nos Quadro 1.
7Garantias da qualidade de software
 Fonte: Adaptado de Koscianski e Soares (2007). 
Nível de maturidade 2 — gerenciado
  Gerência de requisitos
  Planejamento do projeto
  Gerência e controle do projeto
  Gerência e acordos com fornecedores
  Medição e análise
  Garantia da qualidade do processo e do produto
  Gerencia de configuração
Nível de maturidade 3 — definido
  Desenvolvimento de requisitos
  Solução técnica
  Integração do produto Verificação
  Validação
  Foco no processo organizacional
  Treinamento organizacional
  Gerência de projeto integrada
  Gerência de risco
  Análise de decisão e resolução
  Desempenho no processo organizacional
  Definição do processo organizacional
Nível de maturidade 4 — gerenciado quantitativamente
  Desempenho do processo organizacional
  Gerência quantitativa do projeto
Nível de maturidade 5 — otimizado
  Inovação e implementação na organização
  Análise e resolução de causas
 Quadro 1. Níveis de maturidade e processos do modelo MPS.BR 
Garantias da qualidade de software8
Por sua vez, o modelo MPS.BR, um acrônimo de “melhoria de processo de 
software brasileiro”, teve seu desenvolvimento iniciado no ano de 2003 pelas 
instituições SOFTEX, Riosoft, COPPE/UFRG, CESAR, CenPRA e CELE-
PAR. Esse modelo tem foco em empresas de micro, pequeno e médio porte e 
objetiva ser um modelo de qualidade com um custo inferior ao modelo CMMI. 
Esse modelo foi criado para adequar os processos de engenharia de software 
para a realidade brasileira, baseando-se nas abordagens internacionais para 
avaliação e melhoria de processos de software, conforme abordam Koscianski 
e Soares (2007). As bases do modelo MPS.BR são as normas ISO/IEC 12207, 
ISO/IEC 15504 e o CMMI. Esse modelo se divide em três componentes, sendo 
eles: modelo de referência (MR-MPS), método de avaliação (MA-MPS) e 
modelo de negócios (MN-MPS). Ele classifica as empresas de acordo com sete 
níveis de maturidade e, assim como o CMMI, também estabelece objetivos 
para cada nível. Os níveis estipulados para o MPS.BR são os seguintes:
a) Em otimização.
b) Gerenciado quantitativamente.
c) Definido.
d) Largamente definido.
e) Parcialmente definido.
f) Gerenciado.
g) Parcialmente gerenciado.
Nesse modelo, o nível A é o nível mais avançado, que considera os processos 
sendo executados e apenas em etapa de inovação e otimização, e o nível G 
é o início da organização dos processos da empresa, conforme Koscianski e 
Soares (2007). O Quadro 2 demonstra os níveis de maturidade e os processos 
gerenciados por cada nível do modelo MPS.BR.
9Garantias da qualidade de software
 Fonte: Adaptado de Koscianski e Soares (2007). 
A
  Inovação e implantação na organização
  Análise de causas e resolução
B
  Desempenho do processo organizacional
  Gerência quantitativa do projeto
C
  Análise de decisão e resolução
  Gerência de riscos
D
  Desenvolvimento de requisitos
  Solução técnica
  Integração de produto
  Instalação de produto
  Liberação de produto
  Verificação
  Validação
E
  Treinamento
  Avaliação e melhoria do processo organizacional
  Definição do processo organizacional
  Adaptação do processo para gerência do projeto
F
  Medição
  Gerência de configuração
  Aquisição
  Garantia da qualidade
G
  Gerência de requisitos
  Gerência de projetos
 Quadro 2. Níveis de maturidade e processos do modelo MPS.BR 
Outra técnica de garantia de qualidade de software que tem sua utilização 
recomendada é a organização dos processos de testes de software. Os testes são 
Garantias da qualidade de software10
uma medida de controle de qualidade, e a organização e o acompanhamento 
do processo de testes são garantia da qualidade do software. O principal 
documento que norteia a organização do processo de testes e é utilizado para 
monitorar se os testes estão sendo realizados de acordo com o planejado é 
um documento chamado de plano de testes. De acordo com a International 
Software Testing Qualifications Board (ISTQB), em seu glossário de termos, 
o plano de testes é a “documentação descrevendo os objetivos do teste a serem 
alcançados, os meios para realizá-lo, e o cronograma para atingi-lo, organizados 
para coordenar as atividades de teste” (ISTQB, 2018, p. 22).
O plano de teste não é um documento estático; ele pode ser modificado 
durante todo o ciclo de vida do produto, caso novas necessidades sejam identi-
ficadas. O feedback de cada atividade do ciclo de vida pode ser utilizado como 
parâmetro para incluir ou remover itens do plano de testes. O planejamento 
dos testes de um projeto pode ser feito em um plano de teste principal e em 
planos de teste separados para cada nível de teste.
Por exemplo, cria-se um plano de testes para os testes de sistema, que serão feitos 
logo após a conclusão do desenvolvimento da primeira funcionalidade, e outro plano 
de testes para o teste de aceitação, que será feito juntamente com o cliente ou repre-
sentante dele, conforme exemplifica o ISTQB (2018).
O plano de testes é personalizável conforme as necessidades de cada em-
presa, mas, em geral, conforme aponta o ISTQB (2018), ele deve:
  determinar o escopo, os objetivos e os riscos do teste; 
  definir a abordagem geral do teste;
  integrar e coordenar as atividades de teste nas atividades do ciclo de 
vida do software;
  tomar decisões sobre o que testar, as pessoas e outros recursos necessá-
rios para realizar as várias atividades de teste e como essas atividades 
serão realizadas;
  programar as atividades de análise, projeto, implementação, execução e 
avaliação de testes, em datas específicas (p. ex., desenvolvimento sequen-
cial) ou no contexto de cada iteração (p. ex., desenvolvimento iterativo);
11Garantias da qualidade de software
  selecionar as métricas para monitoramento e controle de testes;
  orçar as atividades de teste;
  determinar o nível de detalhes e a estrutura da documentação de teste 
(p. ex., fornecendo modelos ou exemplos de documentos). 
O conteúdo dos planos de teste varia e pode se estender além dos tópicos 
identificados acima. Uma amostragem de planos de teste pode ser encontrada 
nos documentos do padrão ISO (ISO/IEC/IEEE 29119-3).
Métodos de garantia de qualidade de software
Diversas são as estratégias que podem ser utilizadas para a garantia da qua-
lidade de software; algumas foram descritas na seção anterior. Nesta seção, 
essas estratégias são apresentadas com uma abordagem mais aplicada. Como 
se preparar para uma auditoria? Como estruturar um plano de testes?
Auditoria ISO
A auditoria é o momento de verifi car se os processos que foram defi nidos 
para a empresa estão sendo cumpridos. É por meio da auditoria que as em-
presas recebem o almejado selo ISO 9001, e é também por meio dela que, 
periodicamente, as empresas renovam esse selo. Contudo, para obter êxito nas 
auditorias, é necessário saber como elas funcionam e executar alguns passos 
importantes, os quais serão descritos a seguir, com base em Oliveira (2018).
O primeiro passo para se preparar para uma auditoria ISO é estudar as 
normas, os padrões definidos pela sua empresa. Toda a empresa que almeja 
uma certificação ISO obrigatoriamente tem seus procedimentos definidos pelo 
SGQ — Sistema Gerenciador de Qualidade. O profissional que vai acompanhar 
a auditoria precisa conhecer esses processos.
Além do responsável pela qualidade da empresa, os demais colaboradores 
precisam também estar preparados para a auditoria. Dessa forma, é necessário 
preparar a equipe, apresentar a todos os procedimentos, uma vez que o auditor 
poderá conversar com qualquer pessoa para confirmar se os processos são 
executados conforme o determinado.
Além disso, a organização é fundamental para o processo de auditoria. O 
responsável pela qualidade da empresa, que acompanha a auditoria, precisa 
saber onde estão arquivados todos os documentos que são utilizados diaria-
mente e que constam nos procedimentos. É importante que todas as evidências 
Garantias da qualidade de software12
de que os processos definidos são cumpridos sejam apresentadas de forma 
organizada para o auditor.
Para garantir que nenhuma surpresa acontecerá quando a auditoria oficial 
com a certificadora da ISO acontecer, é aconselhável a realização de uma 
auditoria interna. Na auditoria interna, será possível para a empresa identifi-
car pontos fracos que podem ser melhorados para a auditoria externa. Além 
disso, a auditoria internaaumenta a confiança da equipe, o que faz com que, 
na auditoria externa, a equipe esteja tranquila e não cause transtornos apenas 
por nervosismo.
Segundo Oliveira (2018), uma auditoria ISO é constituída basicamente por:
  Reunião de abertura — em que o responsável pela qualidade da empresa 
e o auditor se reúnem pela primeira vez e é definido o cronograma da 
auditoria.
  Auditoria dos processos — nessa etapa, é feita a análise dos procedi-
mentos, dos documentos que comprovam a sua execução e, quando 
necessário, ocorre uma conversa com os profissionais da empresa, para 
garantir que o processo está sendo executado corretamente. 
  Reunião de conclusão — é o momento em que o auditor analisa a 
auditoria junto com todos os gestores da empresa envolvida e faz re-
comendações com base no resultado da auditoria.
Preparando seu plano de testes
Agora, vamos analisar cada parte do plano de testes e discutir como preencher 
esse plano e como identifi car as informações que devem constar em cada parte.
  Determinar o escopo, os objetivos e os riscos do teste: o escopo e os 
objetivos do teste dizem respeito a quais funcionalidades do sistema 
serão testadas. Os riscos dizem respeito a situações que podem impedir 
a realização dos testes. Por exemplo: para testar o sistema de uma ope-
radora telefônica, podem ser necessários dados de números de telefones 
válidos para entrada de dados no sistema; entretanto, a operadora pode 
atrasar a disponibilidade desses dados, e o teste pode atrasar; ou então 
a equipe pode ter um limite mínimo de colaboradores, e alguém pode 
pedir demissão durante o projeto, e, por isso, as demandas da equipe 
acabam atrasando.
  Definir a abordagem geral do teste: quais tipos e níveis de testes serão 
empregados no projeto? Os testes serão manuais ou automatizados? 
13Garantias da qualidade de software
Essas perguntas precisam ser definidas no plano de testes; é necessário 
especificar se a equipe vai realizar teste unitário, teste funcional, teste 
de performance, teste de segurança, entre outros. Essas definições são 
de extrema importância para a organização do ambiente de desenvol-
vimento e do cronograma.
  Integrar e coordenar as atividades de teste nas atividades do ciclo de 
vida do software: em que momento do ciclo de desenvolvimento os 
testes serão iniciados? Será possível iniciar a análise de testes junto 
com a análise do sistema? 
  Tomar decisões sobre o que testar, as pessoas e outros recursos neces-
sários para realizar as várias atividades de teste e como essas atividades 
serão realizadas: de acordo com o escopo que foi definido para o pro-
jeto, toda a funcionalidade será testada ou apenas a parte fundamental 
dela? O projeto dispõe de recursos humanos e financeiros para testar 
a funcionalidade por completo?
  Programar as atividades de análise, projeto, implementação, execução 
e avaliação de testes, em datas específicas (p. ex., em desenvolvimento 
sequencial) ou no contexto de cada iteração (p. ex., no desenvolvimento 
iterativo): nessa etapa, define-se como o projeto de testes será estrutu-
rado, em que momento será feita a análise de testes e de quanto tempo 
se dispõe para isso? Em que momento será feita a implementação dos 
testes e quanto tempo se dispõe para isso?
  Selecionar as métricas para monitoramento e controle de testes: qual é 
o parâmetro para que um projeto de testes seja considerado concluído 
com êxito? 
  Orçar as atividades de teste: qual será o custo do projeto para cumprir 
com o cronograma estabelecido e atingir todo o escopo de testes?
  Determinar o nível de detalhes e a estrutura da documentação de teste 
(p. ex., fornecendo modelos ou exemplos de documentos): serão criados 
casos de testes? As falhas serão reportadas em alguma ferramenta?
Cada uma dessas etapas é fundamental para o projeto e pode ser adaptada, 
dependendo das necessidades da equipe. Em síntese, um plano de testes 
precisa conter, obrigatoriamente, o escopo do projeto, os tipos de testes que 
serão executados, o cronograma, o orçamento disponível, as ferramentas que 
serão utilizadas e a definição dos documentos entregáveis que serão gerados 
ao final do projeto.
Garantias da qualidade de software14
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO 9001: sistemas de 
gestão da qualidade: requisitos. Rio de Janeiro, 2015. 
BARTIE, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002. 
BASTOS, A. et al. Base de conhecimento em testes de software. 2. ed. São Paulo: Martins 
Fontes, 2007. 
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade de software são 
mesma coisa? [2019]. Disponível em: <http://www.linhadecodigo.com.br/artigo/1712/
qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mes-
mas-coisas.aspx#ixzz5bar4W0yD>. Acesso em: 23 jan. 2019. 
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD (ISTQB). Glossário de 
termos de teste: CTFL foundation level: versão 3.2br. 2018. Disponível em: <https://www.
bstqb.org.br/uploads/glossario/glossario_ctfl_3.2br.pdf>. Acesso em: 23 jan. 2019.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software: aprenda as metodologias e técnicas 
mais modernas para desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007.
OLIVEIRA, G. Como se preparar para uma auditoria ISO e o que esperar dela. 2018. Dispo-
nível em: <https://blog.softexpert.com/como-se-preparar-para-uma-auditoria-iso/>. 
Acesso em: 23 jan. 2019.
Leitura recomendada
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD (ISTQB). Certified tester: 
CTFL foundation level syllabus: 3.2. 2018. Disponível em: <https://www.bstqb.org.br/
uploads/syllabus/syllabus_ctfl_2018br.pdf>. Acesso em: 23 jan. 2019.
15Garantias da qualidade de software
Conteúdo:
QUALIDADE DE 
SOFTWARE
Paulo Antonio Pasqual Júnior
Revisão das técnicas 
formais e de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Classificar as técnicas formais.
  Analisar as técnicas formais e de software.
  Ordenar as principais técnicas formais e de software.
Introdução
Entregar para o cliente um produto de qualidade é fundamental para 
qualquer desenvolvedor ou empresa de desenvolvimento de software. 
Existem muitas formas de buscar a qualidade durante todas as fases da 
produção de um software.
Encontrar erros precocemente é fundamental para que, no fim, o 
produto possa ser entregue ao cliente com o mínimo de falhas possíveis, 
além, é claro, de minimizar os custos de correção de defeitos. As técnicas 
de revisão formal (RTF) consistem em metodologias que reservam certo 
formalismo e que, por seu rigor, ajudam na detecção de erros que possam 
se transformar em defeitos.
Neste capítulo, você vai classificar, analisar e ordenar as principais 
técnicas formais. 
Por que a revisão é importante?
As técnicas formais são recursos de revisão de software que utilizam uma 
série de metodologias de verifi cação, geralmente baseadas em regras rígidas. 
Esses métodos contribuem signifi cativamente para a identifi cação de possíveis 
falhas de sistemas. 
À primeira vista, a revisão técnica formal (RTF) pode parecer uma parte 
da fase de testes, uma vez que, por meio dela, são encontradas as falhas no 
software. Contudo, a revisão técnica vem muito antes da fase de testes. Ela 
pode ser realizada para cada artefato do software construído. Se a RTF fosse 
realizada durante a fase de testes do software, significaria que o produto já 
estaria pronto, e, nesse caso, todas as falhas de cada artefato já teriam se 
transformado em defeitos. Imagine fazer a RTF de um sistema extremamente 
complexo apenas no final do processo de desenvolvimento?
Apesar de ser uma forma importante de manter a qualidade de um produto 
de software, esses métodos não são muito utilizados, na prática, para qualquer 
software, pois são processos lentos, caros e que demandam muita energia 
para sua execução.
Sommerville (2007) explica que, apesar de essas técnicasserem extrema-
mente onerosas e se tornarem infinitamente mais complexas à medida que 
o tamanho e a complexidade do software aumentam, elas são fundamentais 
para sistemas críticos. 
Um sistema crítico é aquele que não pode apresentar falhas, pois falhas em 
certos sistemas podem acarretar danos graves e até a perda de vidas, conforme 
Sommerville (2007). Imagine, por exemplo, um software que controla trens 
em uma ferrovia. Esse software não pode falhar ao verificar se outro trem 
está vindo. Assim, o autor aponta que a confiança é um atributo fundamental 
desse tipo de sistema. 
O autor define esses sistemas críticos em três categorias:
  Sistema crítico de segurança, que se refere aos sistemas que podem 
resultar em perda de vidas humanas ou dano ambiental.
  Sistema crítico de missão, que se refere a sistemas que podem levar à 
falha em relação a metas, como o sistema de navegação de aeronaves.
  Sistema crítico de negócios, que se refere a sistemas que, ao falharem, 
podem acarretar em perdas financeiras e fracasso em negócios. 
Sommerville (2007) exemplifica esse tipo de situação com um acidente 
envolvendo um avião em processo de pouso. Na ocasião, o sistema de freio 
não foi ativado no momento necessário, porque o software entendeu que o 
avião ainda não havia pousado. Isso acarretou na colisão do avião com um 
prédio e em dezenas de mortos e feridos. De acordo com o autor, uma inves-
tigação apontou que o software se comportou exatamente como ele havia sido 
programado para fazer, ou seja, o emprego dos testes não foi suficiente para 
identificar e corrigir o erro do sistema.
Outro exemplo de software de risco seria um sistema que controlasse todos 
os carros no trânsito. Nós já sabemos que, muito em breve, os carros poderão 
Revisão das técnicas formais e de software2
andar sozinhos nas ruas, desviar de outros, traçar percursos, reconhecer a 
sinalização e evitar muitos acidentes. Também sabemos que esses sistemas 
já existem, mas ainda precisam evoluir para que esse sonho se materialize. 
Agora, a pergunta é: esse tipo de sistema está totalmente livre de falhas? É 
óbvio que a probabilidade de um sistema falhar e causar uma colisão é muito 
menor do que a probabilidade de um motorista se atrapalhar e colidir o carro 
com outro. Para um sistema como esse ser eficaz, ele necessitará de muita 
qualidade, e o emprego de técnicas formais será fundamental para a redução 
das possibilidades de erros. 
Existem métodos formais para praticamente todas as fases do software, 
desde o início do processo de concepção. As técnicas formais de revisão são 
recursos que podem ser aplicados aos softwares após certa fase do desenvol-
vimento, uma vez que se busca encontrar possíveis erros no desenvolvimento 
do software.
O processo de revisão de um software pode ser feito de muitas maneiras. 
Imagine que dois amigos iniciaram um software para ajudar no controle do 
estoque do negócio e desenvolveram um sistema sem nenhum tipo de norma. 
Ao final, o sistema faz basicamente o que eles precisavam, mas é provável que 
a quantidade de erros seja enorme. Para ajudar em um processo de revisão, 
eles podem fazer testes junto com clientes, ou pedir a ajuda para outros colegas 
programadores tentarem encontrar erros. Esse processo seria, então, uma 
abordagem informal. Fazer a revisão de maneira informal é bastante simples 
e não exige métodos rígidos para a verificação de possíveis erros.
Ao contrário desse exemplo, os métodos de revisão formal exigem conhe-
cimento e rigidez durante o processo de revisão. Existe uma série de formas de 
realizar a RTF; dentre as mais comuns, podemos citar: walkthrough, peer review 
e inspeção. Na próxima seção deste capítulo, detalharemos cada uma delas. 
Análise das técnicas formais
Qualquer tipo de revisão, seja ela formal ou não, é fundamental para o reco-
nhecimento de falhas que podem se tornar defeitos após a entrega do produto. 
Descobrir erros precocemente assegura que o sistema possa ser corrigido o 
mais rápido possível, garantindo um baixo custo, tanto fi nanceiro quanto 
temporal, para a correção do produto. Pressman e Maxin (2016) ressaltam 
que a não descoberta e correção no início do processo acarreta em levar 
esses erros para outras etapas, e isso, geralmente, amplia a falha, o que vai 
tornando o problema cada vez mais difícil de encontrar e mais complexo para 
3Revisão das técnicas formais e de software
solucionar. O autor ressalta que a empresa precisa investir tempo e dinheiro; 
caso não invista, terá de fazer um investimento muito maior para a correção 
de problemas muito mais graves após a entrega do produto. 
Uma grande questão no âmbito da revisão do produto de software é o 
tempo. De acordo com Pressman e Maxin (2016), muitas empresas consideram 
não ter o tempo necessário para a realização de um processo minucioso de 
revisão, o que acarreta na entrega de um software com muitos erros. Essa 
postura faz com que o custo em tempo para manutenção e correção de erros 
seja muito maior do que se fosse utilizada uma metodologia de revisão do 
software durante o processo de desenvolvimento do produto. 
Sommerville (2007) explica que não encontrar um erro a tempo acarreta 
em um efeito cascata, que levará à ampliação do erro, transformando-o, mais 
tarde, em um defeito. Ou seja, a correção de falhas em cada artefato de software 
revisado garante que esses erros não sejam maximizados e transformados em 
defeitos, que demandariam muito mais energia para a correção. 
Apesar de haver uma relutância na aplicação de métodos de revisão formal 
para encontrar e minimizar erros, a Figura 1 mostra que, no final do processo, 
o custo de tempo em projetos que não possuíam processos de revisão é muito 
maior do que naqueles que aplicaram a RTF. Isso significa que, à primeira 
vista, pode parecer que aplicar uma revisão seja algo banal e um desperdício 
de tempo e, consequentemente, de dinheiro, mas, no médio prazo, esse custo 
é totalmente maximizado, se comparado a projetos que não aplicaram RTF.
Figura 1. Custo de tempo relacionado à aplicação ou não da revisão técnica formal.
Fonte: Pressman e Maxin (2016 , 437).
Esforço
Tempo
Sem a realização
de inspeções
Com a realização
de inspeções
Entrega
TesteCódigoProjeto
Requisitos
Planejamento
Revisão das técnicas formais e de software4
Na seção anterior, exemplificamos o teste informal de software ao apre-
sentar uma situação hipotética em que dois amigos tentam encontrar erros no 
sistema sem nenhum tipo de norma ou regra. Uma abordagem formal significa 
que é necessário o uso de formalidade para encontrar o erro. Essas metodo-
logias pressupõem, portanto, um certo rigor, que não está presente em uma 
revisão não formal. A seguir, apresentamos algumas possibilidades de RTF.
Walkthrough
Walkthrough é uma técnica bastante comum de revisão, em que é executado 
passo a passo um procedimento ou programa com vistas a encontrar erros. 
Nesse processo, um testador disponibilizará um conjunto de casos, e os in-
tegrantes da equipe de revisão buscarão simular a execução de um artefato. 
O tempo de duração desse procedimento é de aproximadamente duas horas, 
envolvendo equipes pequenas, normalmente de três a cinco pessoas. 
Peer review
Peer review ou revisão em pares consiste em um método de revisão em que 
dois programadores são responsáveis por revisar o código um do outro, de 
forma que essa revisão possa apontar inconsistências. Esse método é bastante 
utilizado e relativamente fácil de ser aplicado. As regras desse método de 
revisão podem ser estipuladas pela própria equipe de revisão, ou pela dupla 
responsável pela revisão do artefato. 
De maneira geral, um dos integrantes da dupla é responsável por programar, 
enquanto o outro fica responsável pela revisão. A cada ciclo, previamente 
definido, invertem-se os papéis, para que ambos possam tanto programar 
como revisar o código do colega. É importante ressaltar que o formalismo da 
revisão se caracteriza pelas normas que serão previamentedefinidas dentro 
do processo de revisão. Ou seja, uma revisão em pares, se for realizada sem 
nenhum tipo de formalismo, pode não caracterizar uma RTF. 
Inspeção
A inspeção é um tipo de RTF que envolve a revisão em equipe de um determi-
nado artefato. Geralmente, uma inspeção se baseia na distribuição do artefato 
analisado ou de parte dele para equipes distintas, seguida de reuniões de 
revisão em que são mencionados os erros encontrados para o autor do artefato. 
5Revisão das técnicas formais e de software
Nessa situação, o autor geralmente fi ca responsável pela correção dos erros 
encontrados. Em detalhes, a inspeção pode apresentar as seguintes etapas: 
1. Planejamento.
2. Apresentação.
3. Preparação.
4. Reunião de revisão.
5. Retrabalho.
6. Análise final do moderador.
Pressman e Maxin (2016) ressaltam que o momento da reunião de revisão 
precisa ser muito bem planejado e que é importante deixar claro que a revisão 
é do artefato, e não do programador. Algumas situações durante o processo 
de revisão podem afetar os egos dos participantes; por esse motivo, é sempre 
importante deixar esse processo o mais neutro possível, para que não haja 
problemas futuros na equipe. 
Esse tipo de revisão pode ser aplicado a todos os artefatos do software, 
desde a fase de requisitos. A Figura 2 detalha esse processo de inspeção. 
Figura 2. Inspeções de software.
Fonte: Adaptada de Ackerman, Buchwald, Lewski (1989).
Requisitos Projeto dealto-nível
Projeto
detalhado Código
Execução
dos testes
= Inspeção
Plano de
testes
Caso de
testes
Como podemos perceber, o processo de inspeção pode ser realizado após 
cada fase do processo de desenvolvimento de software, inclusive após a de-
finição do modelo de requisitos. É importante ressaltar que, quanto antes um 
erro for encontrado e corrigido, menor será o custo para o reparo. 
Após ser aplicado qualquer um dos processos de revisão, a equipe poderá 
levantar dados que poderão ser úteis para dar indicativos sobre a qualidade dos 
artefatos e, inclusive, para supor a situação de outros artefatos não analisados, 
baseando-se no que foi descoberto acerca dos artefatos analisados. A exemplo 
Revisão das técnicas formais e de software6
disso, temos o cálculo da densidade de erros. A seguir, detalhamos essa forma 
de complementar a RTF. 
Encontrando a densidade de erros
Independentemente da metodologia de revisão, encontrar a densidade de 
erros de um projeto pode ser importante. Existe uma série de métricas que, 
segundo Pressman e Maxin (2016), podem ser usadas para nos dar indicativos 
importantes acerca do software que está em processo de revisão. O Quadro 
1 especifi ca essas métricas. 
 Fonte: Adaptado de Pressman e Maxin (2016). 
Métrica Definição
Esforço de preparação, E
p
Esforço (em pessoas/hora) exigido 
para revisar um artefato antes 
da reunião de revisão.
Esforço de avaliação, E
a
Esforço (em pessoas/hora) que é 
despendido durante a revisão em si.
Esforço de reformulação, E
r
Esforço (em pessoas/hora) 
dedicado à correção dos erros 
revelados durante a revisão.
Tamanho do artefato 
de software, TAS
Uma medida do tamanho do artefato de 
software que foi revisto (por exemplo, o 
número de modelos UML — do inglês 
unified modeling language, ou linguagem 
de modelagem unificada —, o número 
de páginas de documento, ou, então, 
o número de linhas de código).
Erros secundários 
encontrados, Err
sec
O número de erros encontrados que 
podem ser classificados como secundários 
(exigindo menos para serem corrigidos 
do que algum esforço pré-especificado).
Erros graves 
encontrados, Err
graves
O número de erros encontrados que 
podem ser classificados como graves 
(exigindo mais para serem corrigidos do 
que algum esforço pré-especificado).
 Quadro 1. Métricas de revisão 
7Revisão das técnicas formais e de software
Estimar a densidade de erros em um projeto é importante para que se possa 
ter uma ideia de quantos erros serão encontrados em outros artefatos de um 
projeto, ou mesmo para poder estimar, de forma induzida, a possibilidade de 
erros que poderão ser encontrados em um novo projeto. A densidade de erros 
é calculada da seguinte forma: 
Densidade de Erros = Err
tot
 / TAS
Onde: Err
tot
 = Err
sec
 + Err
graves
Suponha o seguinte caso: um modelo de requisitos contém 14 erros secundários e 
dois erros graves distribuídos em 20 diagramas UML e 35 páginas. Qual é a densidade 
de erros por diagrama UML e por página?
Nesse caso, temos: 
Err
tot 
= 14 + 2 = 16
Densidade de erros por diagrama UML = 16/20 = 0,8
Densidade de erros por página = 16/35 = 0,46
Quando utilizar as revisões técnicas formais?
Podemos dizer que, no âmbito das técnicas formais de revisão, algumas apre-
sentam mais formalidade do que outras. Se fossemos estipular uma ordem 
para os métodos de revisão apresentados na seção anterior, podemos defi nir a 
peer review como a menos formal, seguida da revisão walkthrough; por fi m, 
a técnica de inspeção seria o mais formal dos métodos. 
Podemos traduzir a formalidade como o rigor que esses métodos trazem. 
Para entender melhor, pense que um método de revisão em pares pode ser feito 
de maneira aleatória, sem nenhum tipo de regra. Um colega revisa o código de 
outro e aponta deliberadamente os erros dos sistemas. Esse tipo de processo 
é um processo de revisão, mas não formal. Se o mesmo colega executar um 
processo de revisão sistematicamente definido e com procedimentos especí-
ficos, seguindo uma metodologia rígida, podemos dizer que ele aplicou uma 
revisão com certa formalidade. 
Revisão das técnicas formais e de software8
As técnicas de revisão formal são fundamentais para diminuir a possibili-
dade de defeitos no software. Como já mencionado, em especial em software 
críticos, elas são fundamentais para evitar falhas que venham a causar sérios 
danos às pessoas ou à sociedade. 
Escolher a melhor técnica de revisão dependerá dos recursos disponíveis e 
da natureza do software que está sendo desenvolvido. Um software de gestão 
empresarial certamente não demandará as mesmas necessidades de revisão se 
comparado à um software de gerenciamento de linhas ferroviárias. 
A escolha do método normalmente está relacionada ao tempo e ao orça-
mento disponível para a execução. O método de peer review pode ser executado 
rapidamente por uma dupla de programadores, sem que seja necessário deman-
dar tanto tempo, se comparado a um método de inspeção. Contudo, é sabido 
que a inspeção, por ser um método mais rígido, apresenta melhores chances 
de identificar uma quantidade superior de erros do que os outros métodos. 
O método de revisão walkthrough também exige menos tempo e possui 
menos formalidade do que as inspeções. O que determinará o melhor método 
para revisão será, certamente, a disponibilidade temporal e financeira da equipe 
para buscar uma maior qualidade, do ponto de vista do desenvolvimento do 
software. 
Revisão por amostragem
Conforme detalhamos anteriormente, o tempo e o custo são fatores críticos no 
decorrer do projeto e do desenvolvimento de um software. Muitas vezes, não 
é possível realizar a RTF para todos os artefatos do software. O problema é 
que, no caso dos softwares críticos, a revisão é imprescindível e não pode ser 
simplesmente descartada por falta de tempo ou recursos fi nanceiros. 
Nesse sentido, temos uma alternativa que pode ser benéfica em um con-
texto em que o software precisa de revisão, mas a equipe de desenvolvimento 
não possui o tempo e os recursos necessários. Essa alternativa consiste em 
estimar por amostragem a quantidade de erros em uma parte de um artefato. 
Essa estimativa pode servir como elemento para a indução dos erros no arte-
fato completo; ou, ainda, uma amostra de vários artefatos poderia indicar a 
quantidade de erros em todo o projeto. 
Basicamente, a indução é uma metodologia de pesquisa em que se ana-
lisa uma amostra significativa, encontra-se um padrão e aplica-se uma 
generalização. 
9Revisão das técnicas formais e de softwarePara você entender melhor a revisão por amostragem, pense em casos em que é 
utilizado o princípio da indução para se chegar a um possível resultado. Na nossa vida, 
podemos ver exemplos de amostragem em várias situações. Um exemplo é a maneira 
como são feitas as pesquisas eleitorais. Em linhas gerais, um número relativamente 
significativo de pessoas é entrevistado — são, geralmente, pessoas de várias regiões 
que dizem em quem elas pretendem votar. Após a tabulação desses resultados, é 
feita uma estimativa de quem poderia ganhar as eleições. Esse raciocínio se baseia 
no princípio da indução: se a maioria das pessoas vai votar em um candidato X, é 
possível que todas as outras também votem, o que caracteriza um raciocínio indutivo. 
O grande problema da indução é que ela pode revelar uma realidade distinta 
do real, se a amostra não for significativa. Ou seja, quanto maior for a amostra, 
melhores são as chances de a indução estar correta. 
Vamos considerar o seguinte exemplo: uma equipe de desenvolvimento pre-
cisa revisar um artefato em um tempo ligeiramente curto e terá a possibilidade 
de revisar no máximo ¼ (25%) do artefato. Para ganhar tempo, a equipe optou 
por revisar apenas 20%, encontrando 15 erros secundários e 2 erros graves. 
Qual é a probabilidade de erros que poderão ser encontrados no artefato todo? 
A revisão por amostragem é uma possibilidade, mas ela nos dá um indicativo da 
quantidade total de erros de um artefato ou projeto de software. É importante sempre 
considerar que a indução pode não ser real, principalmente se a amostra não for 
significativa. 
Considerando-se que 20% representa 1/5 do artefato, temos: 15 × 5 + 2 × 5 
= 85. Dessa forma, podemos estimar que o artefato todo terá aproximadamente 
85 erros. É importante ressaltar que a análise por amostragem nos dá indícios 
da quantidade de erros, mas não garante uma informação totalmente confiável. 
Para se ter um resultado muito confiável, é necessário que a amostra seja 
bastante significativa. Aplicar revisões por amostragem é uma possibilidade 
Revisão das técnicas formais e de software10
em um cenário em que não se possuem todos os recursos necessários para 
a revisão completa e que envolve um software que não pode simplesmente 
não ser revisado. 
A revisão por amostragem se encaixa nos métodos de RTF mencionados 
anteriormente. A questão, nesse caso, é que apenas uma parte do software ou 
do artefato é revisada, com as mesmas técnicas e rigidez dos métodos de RTF. 
ACKERMAN, A., BUCHWALD, L., LEWSKI, F. Software inspections: an effective verification 
process. IEEE Software, v. 6, n. 3, p. 31–37, jun. 1989.
PRESSMAN, R. S.; MAXIN, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016. 
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Addison Wesley, 2007.
Leitura recomendada
REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro: Bras-
port, 2005. 
11Revisão das técnicas formais e de software
QUALIDADE 
DE SOFTWARE
Priscila Gonçalves 
Abordagens formais e 
garantia estatística de 
qualidade de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Conceituar as abordagens formais e a garantia estatística de qualidade 
de software.
  Classificar as abordagens formais e as garantias estatísticas de quali-
dade de software.
  Demonstrar as principais abordagens formais e garantias estatísticas 
de qualidade de software.
Introdução
A garantia da qualidade de software envolve uma série de atividades 
predefinidas que atribuem confiança ao produto, garantindo que as 
exigências sejam atendidas e que o software esteja em conformidade 
com as normas especificadas. Para tanto, deve-se criar um processo de 
software que seja adaptável e no qual as mudanças sejam realizadas 
visando à melhoria dos elementos do processo que introduzem os pro-
blemas. Tais problemas devem ser identificados previamente, por meio 
de métricas; é a partir delas que será possível aplicar a garantia estatística 
da qualidade de software.
Neste capítulo, você vai estudar o conceito de abordagens formais 
e garantia estatística de qualidade de software, verificando como se dá 
a classificação dessas abordagens e quais são os principais métodos 
empregados nesse âmbito.
Conceitos essenciais
A palavra qualidade possui diferentes signifi cados para diversas áreas. Segundo 
a norma NBR ISO 9000:2005, “[...] qualidade é o grau no qual um conjunto de 
características inerentes satisfaz aos requisitos” (ASSOCIAÇÃO BRASILEIRA 
DE NORMAS TÉCNICAS, 2005, p. 8). Dessa forma, pode-se dizer que se 
algum produto atende às especifi cações que constam nos requisitos, ele possui 
a qualidade desejada. Essa qualidade pode ser medida a partir da satisfação 
do cliente; porém, para algumas pessoas, o produto pode estar em um nível 
satisfatório, enquanto, para outras, esse produto pode ser insatisfatório. Essa 
subjetividade torna a avaliação de qualidade uma difícil tarefa.
O termo qualidade em relação ao software geralmente é mal interpretado, 
pois está ligado ao termo excelência, que não o objetivo primário dos enge-
nheiros de software. O que geralmente ocorre em empresas de software é 
fazer com que o software funcione conforme o esperado, ou seja, sem bugs.
É sabido que todo profissional de software deve primar pela alta quali-
dade, e que esta deve ser pensada desde o princípio pelos desenvolvedores 
de software. Para que fosse possível projetar softwares que tivessem uma 
garantia de qualidade, surgiu a necessidade de concentrar esforços em métodos 
de SQA (do inglês software quality assurance, ou garantia da qualidade de 
software). Nesses métodos, membros do grupo de SQA devem verificar se a 
entrega dos desenvolvedores está correta, para que o trabalho seja executado 
corretamente. Essa garantia se aplica a todo o processo de software, verificando 
se foram elaborados padrões nos quais o software deve ser desenvolvido e 
se os procedimentos de monitoramento foram estabelecidos, garantindo a 
qualidade do produto entregue.
A garantia da qualidade de software envolve vários aspectos, dentre eles:
  adoção de normas e padrões internacionais (ISO e IEEE);
  revisões técnicas e testes de software para encontrar erros;
  análise e coleta dos erros;
  auditorias, para assegurar que as diretrizes estão sendo seguidas;
  utilização de gerenciamento de mudanças;
  educação continuada de seus engenheiros de software;
  gerência dos fornecedores; e
  adoção de políticas de segurança e gestão de riscos.
Abordagens formais e garantia estatística de qualidade de software2
Nas últimas três décadas, percebeu-se que era necessária uma abordagem 
mais formal, utilizando provas matemáticas para demonstrar a adequação do 
programa às suas especificações, conforme Pressman e Maxim (2016).
O princípio de Pareto, segundo seu criador, Joseph Moses Juran, afirma que, para uma 
determinada quantidade de eventos, aproximadamente 80% dos problemas decorrem 
de apenas 20% das causas. Acesse o link abaixo e saiba mais.
https://goo.gl/5VyRZn
Abordagens formais e garantias estatísticas
A garantia estatística da qualidade de software aborda uma tendência que 
cresce na indústria de software, que busca que a análise de qualidade seja 
mais quantitativa em relação à frequência em que os erros ocorrem e às in-
consistências nos softwares que são verifi cadas por certo período de tempo. 
As etapas apresentadas abaixo fazem parte da garantia estatística de qualidade 
de software:
  coletar e classificar informações sobre erros e defeitos de software;
  realizar tentativas de associar cada erro e defeito à causa subjacente;
  utilizar o princípio de Pareto;
  no momento em que as causas forem identificadas, dá-se andamento à 
correção dos problemas que provocaram os erros ou defeitos.
Diante dessa informação, pode-se criar um processo de software que seja 
adaptável e no qual as mudanças sejam realizadas visandoà melhoria dos 
elementos do processo que introduzem os problemas. Antes que o produto de 
software seja desenvolvido, medições devem ser realizadas durante a análise 
de requisitos, determinando qual o tempo máximo que o software poderá 
demorar a dar retorno sobre uma ação executada.
A utilização de métricas se refere à influência de fatores subjetivos, utiliza-
dos para julgar a qualidade de um produto e que servem para detectar áreas do 
3Abordagens formais e garantia estatística de qualidade de software
software que necessitam de um olhar mais atento. Pressman e Maxim (2016) 
descreveram algumas metas que devem ser seguidas para atingir a quali-
dade. Essas metas, mostradas no Quadro 1, focam a correção, a completude 
e a consistência dos requisitos, dos indicadores da qualidade do projeto, do 
código-fonte e da eficiência do controle de qualidade.
Meta Atributo Métricas
Qualidade dos 
requisitos
Ambiguidade Nú mero de modificadores ambí guos 
Completude Nú mero de TBA, TBD
Compreensibilidade Nú mero de seç õ es/subseç õ es
Volatilidade Nú mero de mudanç as por requisito
Tempo (por atividade) quando 
é solicitada a mudanç a
Rastreabilidade Nú mero de requisitos nã o 
rastreá veis ao projeto/có digo
Clareza do modelo Nú mero de modelos UML 
Número de pá ginas 
descritivas por modelo
Qualidade 
do projeto
Integridade da 
arquitetura
Existê ncia do modelo de arquitetura
Completude dos 
componentes
Nú mero de componentes mapeados 
no modelo de arquitetura
Complexidade do projeto procedural
Complexidade 
da interface
Nú mero mé dio de cliques para chegar 
a uma funç ã o ou conteú do tí pico
Adequaç ã o do layout
Padrõ es Nú mero de padrõ es usados
 Quadro 1. Metas, atributos e métricas para qualidade de software 
(Continua)
Abordagens formais e garantia estatística de qualidade de software4
Segundo Koscianski e Soares (2007), as métricas devem:
  ter significância, isto é, os resultados obtidos devem agregar informação 
útil à avaliação de qualidade;
  ter custo e complexidade de aplicação compatíveis com a avaliação 
que deverá ser realizada;
  ser repetíveis, pois se uma medição é realizada várias vezes e nenhuma 
condição for alterada, os resultados devem ser sempre os mesmos 
(caso não possam ser repetíveis, um tratamento estatístico poderá ser 
utilizado);
  ser reproduzíveis, pois isso significa que os resultados de uma medição 
devem ser os mesmos para diferentes avaliadores;
 Fonte: Adaptado de Pressman e Maxim (2016). 
Meta Atributo Métricas
Qualidade 
do có digo
Complexidade Complexidade ciclomá tica
Facilidade de 
manutenção
Fatores de projeto
Compreensibilidade Porcentagem de comentá rios internos
Convenç õ es de atribuiç ã o de variá veis
Reutilizaç ã o Porcentagem de componentes 
reutilizados
Documentaç ã o Índice de legibilidade
Eficiê ncia do 
controle de 
qualidade
Alocaç ã o de 
recursos
Porcentagem de horas de 
pessoal por atividade
Taxa de 
completude
Tempo de conclusã o real versus previsto
Eficá cia da revisã o Métricas de revisão
Eficá cia dos testes Nú mero de erros encontrados 
e gravidade 
Esforç o exigido para corrigir um erro
Origem do erro 
 Quadro 1. Metas, atributos e métricas para qualidade de software 
(Continuação)
5Abordagens formais e garantia estatística de qualidade de software
  ser objetivas, pois a opinião de pessoas envolvidas deve ser limitada 
ou ainda evitada em sua totalidade;
  ser imparciais, principalmente com relação à maneira como as avaliações 
são realizadas (uma escolha criteriosa de parâmetros do ambiente de 
execução pode levar a resultados diferentes, favorecendo ou não um 
dado produto);
  prover evidência para sua validação, uma vez que o resultado de uma 
avaliação é uma curva de tendência.
Também há critérios mais quantitativos utilizados para as métricas, que 
são sugeridos por Weyuker (1988) e citadas por Koscianski e Soares (2007) 
em seu livro Qualidade de software:
  Significância de permutação: uma entidade de um programa A consiste 
em um rearranjo de outra entidade B, então m (A) # m (B), e esse 
resultado depende do “rearranjo” que tenha sido feito.
  Significância de implementação: duas entidades diferentes, A e B, 
produzem a mesma saída para a mesma entrada, cujo critério deveria 
ser válido para métricas que analisassem a estrutura, e não o funcio-
namento do software.
  Monotonicidade: dadas duas entidades de programa diferentes, A e B, 
m (A) ≤ m (A+B) e m (B) ≤ m (A+B).
  Complexidade de interação: dadas duas entidades A e B, m (A) + m (B) 
≤ m (A##B), cujos símbolos ## significam concatenação.
Dentre as métricas que devem ser realizadas, a métrica de funcionalidade 
pode ser concebida no início do desenvolvimento do software, quando esti-
ver na fase de arquitetura do projeto de software, o que ocorre, na maioria 
das vezes, em forma de revisões. Ainda sobre a métrica de funcionalidade, 
pode-se programá-la junto à fase de revisão de coleta de dados, na qual é 
projetada a lógica do sistema. Na funcionalidade, existe a subcaracterística 
de interoperabilidade; esta é avaliada de forma estática, em que é verificado 
se a arquitetura de software projetada contemplará a implementação das 
funcionalidades necessárias.
Contemplando o tópico métricas, falaremos sobre a acurácia, que pode ser 
obtida por meio de contagens realizadas com testes do software, cujos resulta-
dos dependem do funcionamento de componentes internos e de interações com 
o ambiente. A métrica de manutenibilidade pode ser realizada para prever o 
esforço para realizar modificações no software ou para criar uma base de dados 
Abordagens formais e garantia estatística de qualidade de software6
que contenha o histórico para que se possa acompanhar o desenvolvimento. 
A manutenção do software pode ser classificada em quatro tipos:
  Corretiva: modificações são realizadas com a finalidade de corrigir 
defeitos ou não conformidades.
  Adaptativa: utilizada para responder a modificações de requisitos, 
quando as partes de um produto de software já foram projetadas e 
implementadas.
  Incremental: são acrescidas às especificações as funções que não foram 
previstas.
  Preventiva: o software é alterado de maneira que ajude na realização 
de outros três tipos de manutenções.
As medidas de tamanho também podem contribuir como indicadores para 
diversas características de um software — por exemplo, o tempo tomado por 
desenvolvedores para escrever softwares grandes, levando em consideração 
um maior custo para sua produção e uma maior complexidade de escrita.
Dentre as métricas abordadas, temos também a métrica de complexidade 
estrutural, a qual faz a avaliação da construção interna do programa, como 
número de componentes, quantidade e relação entre eles. Não menos impor-
tantes, também existem as métricas de complexidade ciclomática, a métrica 
de Halstead, e as métricas baseadas em fluxo de dados, acoplamento e 
coesão, UML e orientação a objetos.
A usabilidade é medida por fatores não quantificáveis, como itens de 
interface. Já a confiabilidade é medida pela probabilidade de ocorrência de 
falhas, ou seja, a contagem de defeitos, também muito difícil de quantificar 
com precisão, assim como ocorre na usabilidade.
As métricas de disponibilidade estão relacionadas à fração de tempo 
durante a qual um software pode ser utilizado; geralmente são medidas do 
tempo médio entre falhas e o tempo médio para falhar. Para o cálculo da 
disponibilidade de um sistema, utilizamos a seguinte fórmula: divisão do 
tempo médio de falhas pelo tempo médio entre falhas, multiplicados por 
100; o resultado será o percentual de disponibilidade de software. Exemplo:
1 falha de 7 horas por dia
(7/24) *100 = 29,16%
Falhas de 1h a cada 7h
(1/7) *100 = 14,28%
7Abordagens formais e garantia estatística de qualidade de software
Pode-se citar a classificação de falhas, o que ajuda a equipe de desenvol-
vedores a tratar os defeitos da melhor maneira possível. Essas falhas podem 
ser classificadas