Qualidade de Software - Livro Texto Unidade II

Prévia do material em texto

29
QUALIDADE DE SOFTWARE
Unidade II
3 QUALIDADE DE SOFTWARE
3.1 Introdução
Segundo Molinari (2003), a norma internacional ISO 9126, publicada em 1991, e que na versão 
brasileira de agosto de 1996 recebeu o número NBR 13596, define qualidade de software como sendo 
a totalidade de características de um produto de software que lhe confere a capacidade de satisfazer 
necessidades explícitas e implícitas.
Necessidades explícitas são as condições e os objetivos propostos por aqueles que produzem o 
software. São, portanto, fatores relativos à qualidade do processo de desenvolvimento do produto e 
percebidos somente pelas pessoas que trabalham no seu desenvolvimento.
Necessidades implícitas são subjetivas dos usuários (inclusive operadores, destinatários dos 
resultados do software e mantenedores do produto), e são também chamadas de fatores externos, 
podendo ser percebidas tanto pelos desenvolvedores quanto pelos usuários. As necessidades implícitas 
são ainda chamadas de qualidade em uso, e devem permitir aos usuários atingir metas com efetividade, 
produtividade, segurança e satisfação em um contexto de uso especificado.
De acordo com Côrtes e Chiossi (2001), hoje em dia muita gente fala em qualidade de software, 
mas nem sempre as pessoas têm uma noção clara desse conceito. Pode-se considerar qualidade sob 
diferentes pontos de vista e, portanto, existem várias definições. Listamos a seguir as mais comuns: 
• qualidade de software é software sem defeitos;
• qualidade de software é software adequado ao uso, conforme a definição de qualidade de Juran 
(2002);
• qualidade de software é software que atende às especificações, conforme a definição de qualidade 
de Crosby (1979);
• qualidade de software é software produzido por uma empresa que possui certificado ISO 9000 
para seu sistema de qualidade;
• qualidade de software é software que possui confiabilidade, usabilidade e manutenibilidade.
Razões que devem ser levadas em conta com relação à qualidade de software:
30
Unidade II
• A única maneira de diferenciar o produto do competidor é pela qualidade do software e do 
suporte fornecido juntamente. 
• Com o amadurecimento do mercado, os clientes ou usuários não querem apenas que a empresa 
fale que tem qualidade, mas que mostre a todos a sua qualidade por meio de certificação nacional 
ou internacional (CMMI, MPsBR, ISO15504 etc.). Uma certificação pode acarretar vantagem 
competitiva.
• Qualidade é essencial para a sobrevivência. Clientes estão exigindo qualidade; se a empresa 
não tiver habilidade de sobreviver em um mercado altamente competitivo, ela está em risco no 
mercado. 
• A maioria das grandes organizações, principalmente fora do Brasil, está reduzindo o número de 
fornecedores, e um meio de escolher é verificar quais deles têm certificações de qualidade. 
• O mercado brasileiro é vulnerável a produtos importados, que, normalmente, têm mais qualidade.
• Qualidade é custo/benefício. Um sistema de qualidade direciona para o aumento da produtividade 
e permanentemente reduz custos, habilitando o gerenciamento para reduzir a correção de defeitos 
e dar ênfase à prevenção. 
• Todas as empresas sabem que corrigir defeitos após o desenvolvimento do software é mais 
dispendioso do que corrigi-los antes. Preveni-los primeiramente pode resolver muita coisa e 
economizar bastante.
• Qualidade retém consumidores e aumenta lucros. Pouca qualidade normalmente custa muito 
mais do que contratar mais desenvolvedores e ainda continuar sem qualidade. 
• A maioria dos consumidores não tolera falta de qualidade e irá procurar outros desenvolvedores. 
Mais qualidade aumenta a satisfação dos consumidores e assegura os que já são clientes há mais 
tempo.
A qualidade de software resulta de um conjunto completo de atividades interdependentes, entre 
as quais a análise e os testes necessários, mas que não são suficientes. As atividades de análise e 
teste ocorrem ao longo do desenvolvimento e da evolução de sistemas de software, desde o início da 
engenharia de requisitos até a entrega e subsequente evolução. 
A qualidade depende de cada parte do processo de software, não apenas da análise e do teste. 
Nenhuma quantidade de teste pode compensar a baixa qualidade causada por outras atividades do 
processo. Por outro lado, uma característica essencial dos processos de software, que geram produtos 
de alta qualidade, é que o teste e a análise estão profundamente integrados ao processo, e não são 
pensados a posteriori (PEZZÉ; YOUNG, 2008).
31
QUALIDADE DE SOFTWARE
 Observação
Existem diversas certificações, tanto para as empresas quanto para os 
profissionais de software, como: Certificação em Teste de Software, do 
Instituto IBQTS, certificações das normas ISO para as empresas em processos 
de qualidade de software, como CMMI-DEV e MPS.BR. 
3.2 Garantia de produto de software
Segundo Guerra e Colombo (2009), pode-se definir qualidade de produto de software como 
a conformidade com requisitos funcionais e de desempenho declarados explicitamente, padrões de 
desenvolvimento claramente documentados e características implícitas que são esperadas de todo 
software desenvolvido profissionalmente. 
As definições de qualidade podem variar em alguns aspectos, mas o que se refere à satisfação do 
cliente ou usuário não deve ser esquecido.
De acordo com Capovilla (1999), existem diferenças importantes entre produtos de software e 
produtos manufaturados que não podem deixar de ser notadas. Veremos a seguir quais são elas. 
Complexidade
Normalmente, um produto de software tem muitas regras a serem cumpridas, muitas linhas de 
código implantadas; e, frequentemente, diversos desenvolvedores envolvidos, que têm ideias diferentes 
e algumas vezes divergentes, mas que podem levar à mesma solução.
Invisibilidade e intangibilidade
O software é invisível para o usuário ou cliente. O que se vê são as consequências da execução, 
diferente de um produto manufaturado. 
Os desenvolvedores necessitam utilizar modelos para representar o sistema de software. Essa 
intangibilidade causa grandes dificuldades de comunicação, tanto entre os elementos da equipe de 
desenvolvimento como entre a equipe e o cliente, podendo acarretar problemas no produto de software.
Conformidade e modificabilidade
O software é a interface entre diversas entidades do meio no qual é utilizado.
Produção sob medida
Para software não existe produção em série, cada usuário é um cliente que usa o produto a sua 
maneira, com ênfase em partes diferentes.
32
Unidade II
Não se desgasta com o uso
No software, os componentes lógicos são duráveis. A falha resulta de erros humanos cometidos 
durante o processo de desenvolvimento.
Não tem prazo de validade
O software não é sensível a problemas ambientais, nem sofre qualquer tipo de defeito devido ao uso 
cumulativo. O custo final é basicamente o custo do projeto e do desenvolvimento. Trata-se do único 
produto que, quando apresenta defeito, é o cliente quem paga para corrigir.
As qualidades do produto são as metas da qualidade de software, e a qualidade do processo constitui 
os meios para se atingir essas metas. Por exemplo, processos de desenvolvimento com um alto grau de 
visibilidade são necessários para a criação de produtos de alta confiança. 
As qualidades de um produto de software podem ser divididas entre aquelas que são diretamente 
visíveis para o cliente e aquelas que afetam principalmente o desenvolvimento de software. 
A confiabilidade de um produto é diretamente visível pelo cliente, já a manutenibilidade afeta 
basicamente a área de desenvolvimento, embora suas consequências possam afetar o cliente de forma 
indireta, aumentando o tempo entre a liberação de novas versões, por exemplo. 
Propriedades que são diretamente visíveis pelos usuários do produto de software, como confiança, 
latência, usabilidade e taxa de atendimento, são chamadas externas. 
Propriedades que não são diretamente visíveis por usuários finais, como manutenibilidade, 
reusabilidade e rastreabilidade,são chamadas internas, mesmo quando seu impacto no processo 
de desenvolvimento e evolução do software pode afetar os usuários indiretamente (PEZZÉ; 
YOUNG, 2008).
 Saiba mais
Para um estudo profundo do processo de teste e das diversas técnicas 
que permitem a melhoria na qualidade de um software, consulte:
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processos, princípios 
e técnicas. Porto Alegre: Bookman, 2008.
Apesar de todas as iniciativas em relação à melhoria da qualidade de software, infelizmente, a 
realidade das empresas, tanto as nacionais como as internacionais, está distante do ideal, e os problemas 
de qualidade nos produtos persistem (GUERRA; COLOMBO, 2009).
33
QUALIDADE DE SOFTWARE
Rocha (2001) aponta diversas iniciativas e modelos que foram desenvolvidos detalhando as 
características de qualidade de um produto de software em subcaracterísticas, e estas em atributos. 
Entre elas, destacam-se os subcomitês de software da ISO/IEC, que vêm trabalhando desde a década de 
1990 na elaboração de normas e relatórios técnicos que permitam especificar e avaliar a qualidade dos 
produtos de software, consolidando as diversas visões de qualidade.
 Saiba mais
No endereço <http://www-di.inf.puc-rio.br/~julio/Slct-pub/Livro-qualidade.
pdf>, encontra-se disponível um ensaio denominado Gerenciando a qualidade de 
software com base em requisitos, de Julio Cesar Sampaio do Prado Leite. O ensaio 
discute a obtenção da qualidade no desenvolvimento de software. 
3.3 Garantia da qualidade de software
A história da garantia da qualidade no desenvolvimento de software tem paralelo com a história 
da qualidade na manufatura de hardware. Durante os primórdios da computação, a qualidade era uma 
responsabilidade exclusiva do programador. 
Padrões de garantia de qualidade foram introduzidos no desenvolvimento de software sob 
contrato militar nos Estados Unidos, durante a década de 1970, e espalharam-se rapidamente para o 
mundo comercial.
A garantia de qualidade de software (Software Quality Assurance - SQA) é um conjunto de atividades 
que assegura que todos os esforços serão feitos para garantir que os produtos de software tenham a 
qualidade desejada. Essas atividades devem, de acordo com Côrtes e Chiossi (2001), minimizar o número 
de defeitos; criar mecanismos para controlar o desenvolvimento e a manutenção, de forma a preservar 
prazos e custo; garantir que o produto possa ser usado no mercado e melhorar a qualidade de versões 
futuras do produto ou de novos produtos.
A SQA é uma atividade aplicada ao longo de todo o processo de engenharia de software, abrangendo 
métodos e ferramentas de análise, projeto, codificação e teste; revisões técnicas formais que são 
aplicadas durante cada fase de engenharia de software; uma estratégia de testes de múltiplas fases; 
controle da documentação de software e das mudanças feitas nela; um procedimento para garantir 
a adequação aos padrões de desenvolvimento de software e mecanismos de medição e divulgação. 
Enfatiza três pontos importantes:
• Requisitos
Os requisitos de software são a base a partir da qual a qualidade é medida. Assim, a falta de 
conformidade aos requisitos significa falta de qualidade.
34
Unidade II
• Padrões
Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a 
maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem 
seguidos, o resultado quase que seguramente será a falta de qualidade.
• Requisitos implícitos
Há um conjunto de requisitos implícitos que frequentemente não são mencionados. Se o software 
se adequar aos seus requisitos explícitos, mas deixar de cumprir os implícitos, a qualidade será 
suspeita.
O processo de requisitos deve identificar e definir as características de um produto em particular que 
é de necessidade do cliente, distinguindo daquelas menos relevantes. 
É importante que, na entrega do produto final, o sistema tenha pouquíssimos ou nenhum defeito, 
que não falhe em produção e seja fácil de utilizá-lo. 
A comunicação entre o desenvolvedor e o cliente é a chave para a definição correta dos requisitos. O 
desenvolvedor deverá trabalhar em conjunto com o cliente para definir corretamente as especificações 
do software, o que se define como escopo do sistema.
 Observação
A grande ênfase na participação do cliente nos processos de 
desenvolvimento, atualmente, encontra-se nas propostas dos métodos ágeis, 
como o Xtremme Programming - XP, SCRUM, TDD, Lean Software etc.
Dessa forma, o desenvolvimento de software deve:
• utilizar as melhores práticas da engenharia de software (técnicas de reuniões, modelagem de 
requisitos, documentação padronizada, inspeção, revisões etc.);
• ser executado por pessoal treinado com responsabilidades e instruções (pessoas qualificadas e um 
processo padronizado de trabalho);
• dar ênfase na prevenção de defeitos assim que forem detectados (aplicação de um processo de 
detectar e corrigir defeitos);
• gerar registros para demonstrar efetividade e eficiência (registros permitem a geração de bases 
históricas e determinam as lições aprendidas);
• utilizar os registros para aumentar a performance no futuro (melhoria contínua de processos).
35
QUALIDADE DE SOFTWARE
A garantia da qualidade de software compreende uma variedade de tarefas. A seguir, são apresentadas 
as sete grandes atividades da SQA.
I. Aplicação de métodos técnicos comprovados (uso de normas tipo ISO e modelos de qualidade).
II. Realizações de revisões técnicas formais utilizando técnicas de reunião, revisão por pares, inspeção, 
reuniões do tipo walkthrougs etc.
III. Atividades de testes de software, realizadas por desenvolvedores ou por especialistas.
IV. Aplicações de padrões e normas preestabelecidos pela organização, aderência a padrões 
reconhecidos no mercado.
V. Controle de mudanças, práticas bem-sucedidas na gestão de mudanças e manutenção evolutiva.
VI. Medição do processo e da qualidade do produto, métricas e processo de medição.
VII. Manutenção de registros e relatórios para feedback superior (feedback e rastreabilidade).
 Lembrete
Software Quality Assurance (SQA) é um grupo de especialistas em 
qualidade de software que tem como objetivo principal monitorar 
os métodos e padrões que os desenvolvedores de software usam no 
desenvolvimento do produto.
A atividade de SQA inicia-se de fato com o conjunto de métodos e ferramentas técnicas que ajudam o 
desenvolvedor a conseguir uma especificação de elevada qualidade e a desenvolver um projeto também 
de qualidade. Assim que uma especificação e um projeto tiverem sido criados, seus artefatos devem ser 
avaliados quanto à qualidade. 
A atividade central que leva a efeito a avaliação da qualidade é a revisão técnica formal (inspeção 
da qualidade). Trata-se um encontro realizado pelo pessoal técnico com o propósito único de descobrir 
problemas de qualidade.
De acordo com Weinberg (1997), na resolução de falhas, as maiores perdas podem vir de 
efeitos colaterais ou falhas introduzidas ao se resolver outras falhas. As equipes devem ser 
treinadas para trabalhar na prevenção de efeitos colaterais, na correção de falhas ou defeitos; 
uma equipe adequadamente estruturada consegue prever melhor do que um indivíduo sozinho 
os efeitos colaterais. O autor apresenta um relato sobre a eficiência das revisões técnicas em uma 
organização americana em grandes projetos de software que possuem pelo menos 2,5 milhões de 
linhas de código de alto nível.
36
Unidade II
Pode-se encontrar aproximadamente um defeito para cada homem-hora investido. Cada hora gasta 
em inspeções evita uma média de 33 horas de manutenção subsequente. As inspeções podem ser até 
vinte vezes mais eficientes que os testes.
O grau em que padrões e procedimentos formais são aplicados no processo de engenharia de 
software varia de empresa para empresa e, em muitos casos, são determinados pelos clientes ou por 
imposições reguladoras. 
Em outras situações, os padrões são autoimpostos.Se existirem padrões formais, uma atividade de 
SQA deve ser estabelecida para garantir que eles sejam seguidos. 
Uma grande ameaça à qualidade de software vem de uma fonte aparentemente benigna: as 
mudanças. Toda mudança no software tem potencial para introduzir erros ou criar efeitos colaterais 
que os propagam. 
O processo de controle de mudanças contribui diretamente para a qualidade do software ao 
formalizar pedidos, avaliar a natureza da mudança e controlar o seu impacto. 
A aplicação de modelos de gestão de serviços, como o modelo ITIL, contribui para organizar as 
mudanças necessárias oriundas de defeitos registrados nos softwares em produção. 
 Lembrete
Modelo ITIL ou framework ITIL significa Information Technology 
Infrastructure Library, um conjunto de livros que busca promover a gestão 
da TI com foco no cliente e na qualidade de serviços prestados.
Um objetivo importante da SQA é rastrear a qualidade e avaliar o impacto das mudanças 
metodológicas e procedimentais sobre a qualidade do software, por meio de uma métrica de software 
que deve ser coletada.
 A anotação e a manutenção de registros para a garantia de qualidade de software oferecem 
procedimentos para coleta e disseminação de informações de SQA. 
Os resultados de revisões, auditorias, controle de mudanças, testes e outras atividades SQA devem 
tornar-se parte do registro histórico de um projeto e ser levados ao conhecimento do pessoal de 
desenvolvimento. 
Os modelos de qualidade de software, como o CMMI e a ISO 15504, que serão apresentados nas 
próximas unidades, possuem processos específicos e práticas para atender a essas demandas pela 
qualidade.
37
QUALIDADE DE SOFTWARE
3.4 Evolução da qualidade de software
 No início, o software era produzido de maneira que ninguém tinha compromisso com o que estava 
sendo feito: iniciativas isoladas procuravam melhorar o produto final. 
De acordo com Molinari (2003), na década de 1980, o importante era descobrir “bugs” de software. 
Na década de 1990, o enfoque voltou-se para os negócios: o software deveria suportar o negócio, isto 
é, se o caminho usado sempre funcionasse, as exceções eram desprezadas.
Qualidade de software, que veio à tona no final da década de 1990, passa por um processo de 
evolução que busca tornar o desenvolvimento garantido e assistido por todas as etapas de um processo 
efetivo de software.
Os testes de software passaram a ser uma parte importante desse processo, e muitas empresas estão 
descobrindo na prática que teste é fundamental, ainda mais dependendo do negócio. 
A atividade de teste de software combina uma estratégia de múltiplos passos com uma série de 
métodos de projeto, casos de testes e aqueles que ajudam a garantir uma detecção de erros e defeitos.
 Saiba mais
No endereço a seguir, encontra-se disponível material de consulta do 
Dr. James Whittaker, diretor de Engenharia de Testes do Google, que discute 
o tema: O futuro do teste de software. A leitura é importante devido à 
ênfase dada às pessoas envolvidas com os testes de software.
<http://blogs.msdn.com/b/james_whittaker/archive/2008/09/09/the-
future-of-software-testing-part-4.aspx>
3.5 Fatores de qualidade de software
Os fatores que afetam a qualidade de software podem ser categorizados em dois amplos grupos:
• Fatores que podem ser medidos diretamente
Por exemplo: número de erros/KLOC (quantidade de linhas de código/unidade de tempo);
• Fatores que podem ser medidos apenas de forma indireta
Por exemplo: usabilidade ou manutenibilidade.
Em cada caso, deve ocorrer medição, ou seja, deve-se comparar o software com algum dado presente 
ou histórico e chegar a uma indicação de qualidade. 
38
Unidade II
Os fatores que afetam a qualidade de um software podem ser descritos da seguinte forma:
• Corretude: quando um sistema satisfaz sua especificação e cumpre os objetivos visados pelo 
cliente.
• Confiabilidade: a medida que se pode esperar que um sistema execute a função pretendida com 
a precisão exigida.
• Eficiência: a quantidade de recursos de computação e de código exigida para que um programa 
ou software execute sua função.
• Integridade: quando o acesso ao software ou a dados por pessoas não autorizadas pode ser 
controlado.
• Usabilidade: o esforço para aprender, operar, preparar a entrada e interpretar a saída de um 
programa ou software.
• Manutenibilidade: o esforço exigido para localizar e reparar erros num programa ou em um 
software.
• Flexibilidade: o esforço exigido para modificar um programa/sistema operacional.
• Testabilidade: o esforço exigido para testar um programa a fim de garantir que ele execute sua 
função pretendida.
• Portabilidade: o esforço exigido para transferir o programa de um ambiente de sistema de 
hardware e/ou software para outro.
• Reusabilidade: quando um programa/componente pode ser reusado em outras aplicações; 
relacionada ao empacotamento e escopo das funções que o programa executa.
• Interoperabilidade: o esforço exigido para se acoplar um sistema a outro.
 Saiba mais
Encontra-se disponível no endereço <http://www.testexpert.com.
br/?q=node/669> artigo do prof. Fábio Martinho Campos. Nele, há uma 
abordagem interessante sobre qualidade de software, questionando se 
garantia da qualidade de software e qualidade de software são iguais, e 
uma discussão sobre os fatores que afetam a qualidade de software, sob o 
ponto de vista das diversas normas e modelos de qualidade.
39
QUALIDADE DE SOFTWARE
3.6 Indicadores de qualidade de software
Dentro dos diversos indicadores criados ao longo do tempo, o IEEE Standard (The Institute of 
Electrical and Eletronics Engineers, INC) sugere um índice de maturidade de software (SMI) que fornece 
uma indicação da estabilidade de um software (baseada em mudanças que ocorreram em cada versão 
do produto). 
As seguintes informações são determinadas:
SMI = [Mt – (Fa + Fc + Fd)] / Mt
Onde:
Mt = número de módulos da versão atual.
Fc = número de módulos da versão atual que foram mudados.
Fa = número de módulos da versão atual que foram adicionados.
Fd = número de módulos da versão anterior que foram suprimidos da liberação atual.
O índice da maturidade de software é computado da seguinte maneira: quando o SMI se aproxima 
de 1,0, o produto começa a se estabilizar. O SMI também pode ser usado como métrica para planejar as 
atividades de manutenção do software. 
O tempo médio para produzir um software pode estar relacionado com o SMI, e os modelos 
empíricos para o esforço de manutenção podem ser desenvolvidos. Os indicadores da qualidade 
permitem o surgimento da garantia estatística de qualidade, que reflete uma crescente tendência de 
toda a indústria para se tornar mais quantitativa em relação à qualidade. Para o software, implica os 
seguintes passos:
• coleta das informações sobre os defeitos; essas informações devem ser organizadas por 
categorias;
• rastrear cada defeito até suas causas subjacentes (por exemplo, não conformidade às especificações, 
erros de projeto, comunicação ruim com o cliente);
• usando o Princípio de Pareto, que diz que 80% dos defeitos podem remeter-se a 20% de todas as 
causas possíveis, esses 20% devem ser mitigados;
• uma vez que as causas pouco vitais tenham sido identificadas, tome providências para corrigir os 
problemas que causaram os defeitos.
40
Unidade II
4 CONFIABILIDADE DE SOFTWARE
Não há dúvida de que a confiabilidade de um software de computador é um elemento importante 
de sua qualidade global. Se um programa ou software deixar de funcionar repetida e frequentemente, 
pouco importa se outros fatores da qualidade são aceitáveis.
A confiabilidade de software, ao contrário de muitos outros fatores de qualidade, pode ser medida 
diretamente e estimadamente usando-se dados históricos e de desenvolvimento. É definida em termos 
estatísticos como a probabilidade de operação livre de falhas de um programa de computador num 
ambiente específico durante determinado tempo.
Conforme Pezzé e Young (2008), a confiabilidadeé uma aproximação estatística da corretude, no 
sentido de que uma confiabilidade de 100% é indistinguível de corretude. 
Simplificando, a confiabilidade é uma medida da probabilidade de funcionamento correto em 
alguma unidade de comportamento, que pode ser uma única execução ou um período de tempo. 
A confiabilidade é relativa a uma especificação que determina se uma unidade de comportamento 
será contada como sucesso ou falha. É também relativa a um perfil de uso específico. O mesmo programa 
ou software pode ser mais ou menos confiável, dependendo de como é utilizado.
 Observação
A definição de confiabilidade, de acordo com a NBR ISO 9126, significa 
basicamente um software imune a falhas durante a sua execução. 
4.1 Medidas de confiabilidade de software
Considerando o sistema computadorizado, uma medida simples da confiabilidade é o tempo médio 
entre a ocorrência de falha (MTBF), onde MTBF = MTTF + MTTR. 
Muitos pesquisadores afirmam que o MTBF é uma medida bem mais útil do que os defeitos/KLOC. 
As siglas utilizadas nas medidas de confiabilidade significam:
• Mean Time between Failures - MTBF, tempo médio entre falhas.
• Mean Time to Repair - MTTR, tempo médio de reparo de uma falha ou defeito.
• Mean Time to Fail - MTTF, tempo médio até a ocorrência de falha. 
41
QUALIDADE DE SOFTWARE
 Observação
Um usuário final está preocupado com a ocorrência de falhas, não 
com a contagem total de erros. Daí a importância da disponibilidade em 
software.
Uma vez que cada erro contido num programa ou software não apresenta o mesmo índice de 
falhas, a contagem total de erros oferece poucos indícios da confiabilidade de um sistema. Por exemplo, 
consideremos um programa que tenha estado em operação durante quatorze meses. Muitos erros desse 
programa permanecem sem ser detectados durante décadas antes de serem revelados. O MTBF de tais 
erros obscuros poderia ser de 50 ou até mesmo 100 anos. Outros erros, ainda não revelados, poderiam 
ter um índice de falha de 18 ou 24 meses. Mesmo se todos os erros de primeira categoria fossem 
removidos, o impacto sobre a confiabilidade do software seria significante. 
De acordo com Pezzé e Young (2008), a disponibilidade é uma métrica apropriada quando uma falha 
pode durar um período de tempo. 
A partir de uma medida de confiabilidade, pode-se desenvolver uma medida de disponibilidade. A 
disponibilidade de software é a probabilidade de que um programa esteja operando de acordo com os 
requisitos em determinado período de tempo, e é definida como:
Disponibilidade = (MTTF * 100%) / (MTTF + MTTR)
4.2 Controle de qualidade
De acordo com Molinari (2003), controle de qualidade é definido como os processos e métodos 
usados para monitorar o trabalho e os requerimentos envolvidos. É focado nas revisões e remoção 
de defeitos antes da entrega do produto. Deve ser responsabilidade da unidade de produção dentro 
da organização. É possível ter um mesmo grupo que construa o produto e execute a função de 
controle de qualidade, ou ter um grupo de controle de qualidade ou um departamento na unidade 
de produção.
Consiste em verificações do produto bem definidas e que sejam especificadas dentro do plano de 
garantia de qualidade. Para produtos de software, controle de qualidade inclui revisões de especificação, 
inspeções de códigos e documentos e verificações de entrega ao usuário.
Segundo Pressman (2006), o controle de qualidade envolve a série de inspeções, revisões e testes 
usada ao longo do processo de software para garantir que cada produto de trabalho satisfaça os 
requisitos para ele estabelecidos. 
Inclui um ciclo de realimentação no processo de trabalho que criou o produto. A combinação de 
medida e realimentação permite ajustar o processo quando os produtos de trabalho criados deixam de 
satisfazer suas especificações. Um conceito-chave do controle de qualidade é que todos os produtos de 
42
Unidade II
trabalho têm especificações definidas e mensuráveis com as quais se pode comparar o resultado de cada 
processo. O ciclo de realimentação é essencial para minimizar os defeitos produzidos.
Inspeções de documentos e produtos são conduzidas dentro de marcos no ciclo de vida, para 
demonstrar que itens produzidos são especificados através de critérios no plano de garantia de qualidade. 
Esses critérios são normalmente providenciados por meio de especificações de requisitos, seja em nível 
conceitual ou detalhado e em casos de teste. Esses documentos gerados aos usuários são requisitos, 
resultado dos testes de aceitação dos usuários, código do software, guia de usuário de manutenção e 
operação de sistema.
Existe uma subárea de controle de qualidade que assumiu a gerência de requisitos. O maior desafio 
é controlar os requisitos, vendo se foram definidos, elaborados, validados, detalhados, implementados e 
realmente testados no ambiente que representa a realidade.
 Observação
A gerência ou gestão de requisitos são partes importantes dos modelos 
e normas de qualidade de software, como o CMMI-DEV, o MPS.BR e as 
normas ISO de qualidade, que serão apresentados nas próximas unidades 
deste livro-texto.
4.3 Prevenção versus detecção
Segundo Molinari (2003), qualidade não pode ser alcançada pelo acesso a um produto já pronto e 
completo. Entretanto, em primeiro lugar, deve-se prevenir os defeitos ou as deficiências e fazer com 
que o produto possa ter uma garantia de qualidade através de medições. Somente é possível gerenciar 
aquilo que se consegue medir e vice-versa. 
Algumas medidas de qualidade incluem a estruturação de um processo de desenvolvimento com 
métodos, técnicas e ferramentas. 
Em adição à preparação do produto, um processo de preparação é importante num programa de 
gerência de qualidade, e inclui:
• documentação de padrões de códigos;
• descrição de uso de padrões;
• métodos e ferramentas;
• procedimentos de recuperação de dados;
• gerência de mudanças ou gerência de configuração, como é mais conhecida;
43
QUALIDADE DE SOFTWARE
• documentação dos defeitos encontrados; e 
• reconciliação ou rastreabilidade.
O gerenciamento da qualidade diminui os custos porque, quando um defeito é encontrado logo 
cedo e corrigido, o custo será menor ao longo do tempo. 
Um investimento inicial deve ser significativo, de modo a garantir ao longo do tempo produtos 
de alta qualidade e com custos de manutenção reduzidos. O custo total efetivo do gerenciamento de 
qualidade é a soma dos quatro fatores: 
prevenção + inspeção + falha interna + falha externa
Prevenir custos consiste no conjunto de ações tomadas para evitar os defeitos antes que eles 
apareçam primeiro. 
Custos de inspeção consistem em medir, avaliar e auditar produtos ou serviços para determinar a 
conformidade com os padrões e especificações. 
Custos de falhas internas consistem em corrigir defeitos dos produtos antes de serem “entregues”. 
Custos de falhas externas consistem nos custos descobertos depois que os produtos foram entregues 
e liberados. Quanto mais falhas externas forem encontradas, mais desastroso será para a reputação da 
organização ou resultará em perda de faturamento. 
O grande retorno “de investimento” é com prevenção. Incrementando a ênfase na prevenção, 
origina-se uma redução do número de defeitos encontrados pelo usuário, melhoria da qualidade e 
redução do custo de produção e manutenção.
 Observação
O ditado popular “é melhor prevenir do que remediar” é totalmente 
aplicável ao desenvolvimento de software na área de TI das organizações.
4.4 Verificação e validação
Segundo Molinari (2003), os termos verificação e validação são usados de forma indiscriminada, o 
que é um erro típico da maioria dos analistas e consultores na área de teste de software.
• Verificação prova que o produto vai ao encontro dos requisitos especificados durante as preciosas 
atividades executadas corretamente em seu desenvolvimento.
• Validação verifica se o sistema vai ao encontro dos requisitos do consumidor/cliente/usuário ou 
stakeholders.
44
UnidadeII
A criação de um teste de produto está muito mais perto de validação do que de verificação. 
Tradicionalmente, teste de software é considerado um processo de validação, isto é, uma fase do 
ciclo de desenvolvimento do produto. Depois que o software é terminado, o sistema é validado ou 
testado para determinar sua funcionalidade e performance operacional.
Quando a verificação é incorporada ao teste, este corre durante o desenvolvimento também. É uma 
prática combinar verificação com validação no processo de testes. 
A verificação inclui procedimentos sistemáticos de revisão, análise e testes empregados durante 
o desenvolvimento, começando com as fases de requisitos de software e continuando por meio da 
codificação do produto. E garante a qualidade do software na produção e na manutenção e impõe um 
organizado e sistemático desenvolvimento, de tal forma que um software qualquer possa ser facilmente 
compreendido e avaliado de modo independente. 
Esse conceito emergiu anos atrás como resultado das necessidades da indústria aeroespacial 
americana, de modo que garantisse extrema confiabilidade de software nos sistemas. Um mínimo erro 
no software poderia resultar em falha da missão e em enorme tempo e atraso financeiro, ou em simples 
ameaças em quaisquer situações. 
Inclui dois critérios fundamentais:
• O software tem de executar todas as funções desejadas.
• O software, durante sua execução, não deve passar por nenhum caminho que não tenha sido 
testado em alguma combinação com as outras funções; em outras palavras, todas as possibilidades, 
caminhos e funções têm de estar mapeados, codificados e testados.
A meta global de verificação é garantir, por meio do desenvolvimento do software, que ele vai ao 
encontro das necessidades dos requisitos documentados. 
A verificação estabelece uma rastreabilidade entre várias seções do software documentado e 
associado às devidas partes das especificações dos requisitos. 
Uma compreensiva verificação garante que a performance do software e a qualidade dos requisitos 
sejam adequadamente testadas e os resultados dos testes possam ser repetidos, mesmo depois de 
qualquer mudança. Trata-se de um processo de melhoria que não tem fim. Deve ser usado para garantir 
a operação e manutenção do sistema. 
Quando procedimentos de verificação são usados, o gerenciamento pode assegurar que os 
desenvolvedores sigam um processo formal e sequencial de desenvolvimento, com um mínimo de 
atividades que garanta a qualidade do sistema. 
45
QUALIDADE DE SOFTWARE
 Observação
Alguns profissionais de TI dizem que a verificação aumenta o custo de 
desenvolvimento. Todavia, tem-se comprovado que ela reduz o custo geral 
do software na prevenção, se for usado adequadamente no processo de 
desenvolvimento. Os dados obtidos na prática mostram uma redução de 
defeito de 4 para 1 e diminui-se os custos do retrabalho, pois um defeito 
encontrado em produção custa de 20 a 100 vezes mais do que se fosse 
encontrado antes.
4.5 Revisões Técnicas Formais (RTF)
O objetivo principal das revisões técnicas formais é achar erros durante o processo de desenvolvimento 
do software, de modo que eles não se transformem em defeitos depois da entrega. 
O benefício óbvio das revisões técnicas formais é a descoberta antecipada de erros para que eles 
não se propaguem ao passo seguinte do processo de software. Vários estudos da indústria (TRW, Nippon 
Electric, Mitre Corp., entre outros) indicam que as atividades de projeto introduzem entre 50% e 65% de 
todos os erros (e em última análise de todos os defeitos) durante o processo de software. 
Todavia, foi mostrado que as revisões técnicas formais são 75% efetivas na descoberta de erros 
de projeto. Detectando e removendo uma alta porcentagem desses erros, o processo de revisão 
reduz substancialmente o curso dos passos subsequentes de desenvolvimento e manutenção 
(PRESSMAN, 2006).
Independentemente da técnica escolhida (walkthrougs, inspeções, revisões etc.), cada reunião de 
revisão deve atender às seguintes restrições:
• entre três e cinco pessoas devem ser envolvidas na revisão (o autor do trabalho, um 
registrador dos resultados – um escriba, um especialista do assunto, um desenvolvedor 
mais experiente etc.);
• preparativos devem ser feitos e não devem exigir mais de duas horas de trabalho de cada pessoa; 
• a duração da reunião de revisão deve ser inferior a duas horas;
• uma RTF focaliza uma parte específica e pequena de todo o software; restringindo-se o foco à RTF, 
há maior probabilidade de descobrir erros;
• como resultado, um relatório resumido ou ata da revisão é confeccionado e deve responder a três 
questões:
46
Unidade II
— o que foi revisado? 
— quem fez a revisão?
— quais foram as descobertas e conclusões?
 Saiba mais
O seguinte artigo de Juliana Jenny, Revisão Técnica Formal (Formal 
Technical Review - FTR), dá uma visão completa da organização dessas 
reuniões formais de revisão nas atividades de garantia da qualidade de 
software.
<http://julianakolb.com/2012/03/16/revisao-tecnica-formal-ftr/>
4.6 Testes de software
Embora durante todo o processo de desenvolvimento de software sejam utilizados métodos, 
técnicas e ferramentas, a fim de evitar erros introduzidos no produto, a atividade de teste 
continua sendo de fundamental importância para a eliminação dos erros que persistem, 
conforme Maldonado (1991). Por isso, de acordo com Pressman (2002), o teste de software é um 
elemento crítico para a garantia de qualidade do produto e representa a última revisão, projeto 
e codificação.
Teste é o processo de execução de um programa, sistema ou software com a finalidade de encontrar 
erros. Um bom caso é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto. Se 
o teste for conduzido de maneira bem-sucedida, descobrirá erros no software.
Há muitos tipos de testes. Eles têm como foco a detecção de erros cometidos no processo de 
desenvolvimento, e existem muitos meios de tornar mais eficientes e efetivos os esforços relacionados a 
eles, já que o teste é considerado um elemento crítico da garantia de qualidade de software e representa 
a revisão final da especificação, projetos e geração de código (MOLINARI, 2003; PRESSMAN, 2006; RIOS 
et al., 2007; PEZZÉ; YOUNG, 2008).
As técnicas de teste de software fornecem diretrizes sistemáticas para projetar testes que exercitam a 
lógica interna dos componentes e também os domínios de entrada e saída dos programas para descobrir 
erros na função, comportamento e desempenho do software.
Durante os primeiros estágios, um engenheiro de software realiza todos os testes. No entanto, se os 
processos progridem, os especialistas podem ser envolvidos. 
47
QUALIDADE DE SOFTWARE
 Lembrete
Os testes são importantes para encontrar o maior número possível de 
erros; devem ser conduzidos sistematicamente e projetados utilizando-se 
técnicas disciplinadas.
Um plano de testes deve contemplar as técnicas existentes mais adequadas à realidade da empresa 
que desenvolve o software. 
Segundo Pfleeger (2003), um erro pode ser o resultado de: 
• uma especificação errada ou de falta de um requisito; 
• a especificação pode conter um requisito impossível de se implementar, considerando o hardware 
e o software estabelecidos;
• o projeto do sistema pode conter um defeito de banco de dados e de linguagem de programação 
escolhida; 
• o projeto do software pode conter um erro ou o código do programa pode estar errado.
O software deve ser testado de duas perspectivas diferentes: 
• a lógica interna do programa é exercitada usando técnicas de projeto de casos de teste caixa-
branca; 
• requisitos de software são exercitados usando técnicas de projeto de casos de teste caixa-preta. 
Em ambos os casos, o objetivo é encontrar o maior número de erros com a menor quantidade de 
esforço e tempo. 
Um conjunto de casos de teste planejado para exercitar tanto a lógica interna quanto os requisitos 
externos é projetado e documentado, os resultados esperadossão definidos e os reais são registrados.
Para garantir que os testes sejam executados corretamente, deve-se modificar o ponto de vista, tentando 
quebrar arduamente o software e projetar casos de teste de modo disciplinado, revisando os casos criados. 
Os princípios envolvidos com os testes de software, segundo Pressman (2002), são:
• todos os testes devem ser relacionados aos requisitos do cliente;
• os testes devem ser planejados muito antes do início;
48
Unidade II
• o Princípio de Pareto aplica-se ao teste de software, isto é, 80% de todos os erros descobertos 
durante o teste vão provavelmente ser relacionados a 20% de todos os componentes do software;
• o problema é isolar os componentes suspeitos e testá-los;
• o teste deve começar “no varejo”, isto é, nos componentes individuais, para depois progredir até 
o teste “no atacado”, em todo o sistema;
• teste completo não é possível, mas pode-se cobrir adequadamente a lógica do programa e 
garantir que todas as condições no projeto, no que diz respeito ao componente, tenham sido 
exercitadas.
A testabilidade de software é a facilidade com que um programa de computador pode ser testado. 
Um software é testável quando possui as características apresentadas a seguir.
• Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado.
• Observabilidade: o que se vê é o que se testa.
• Controlabilidade: quanto mais se pode controlar o software, mais o teste pode ser automatizado 
e otimizado.
• Decomponibilidade: controlando o escopo do teste, podem-se isolar problemas mais rapidamente 
e realizar uma retestagem mais racionalmente.
• Simplicidade: quanto menos há a testar, mais rápido se pode testar.
• Estabilidade: quanto menos modificações, menos interrupções no teste.
• Compreensibilidade: quanto mais informações se têm, mais racionalmente o software será testado.
Por fim, Pressman (2002) sugere os seguintes atributos para um bom teste:
• tem alta probabilidade de encontrar um erro;
• não é redundante;
• em um grupo de teste que tem um objetivo semelhante, as limitações de tempo e recursos podem 
ser abrandadas no sentido da execução de apenas um subconjunto desses testes;
• não deve ser muito simples, nem muito complexo.
49
QUALIDADE DE SOFTWARE
 Resumo
Nesta unidade, foi possível apresentar e discutir os principais conceitos 
envolvidos com a Qualidade de Software. Esses conceitos abrangeram tanto 
os processos como os produtos de software.
Com as afirmações dos diversos autores utilizados no texto da unidade, 
foi possível dar uma visão resumida e abrangente da problemática 
envolvida com a qualidade no desenvolvimento e na manutenção dos 
sistemas de informação, formados pelos softwares produzidos na área de 
TI das organizações.
Diversas facetas da qualidade de software foram mostradas, como: 
os fatores da qualidade, o controle da qualidade de software, a garantia 
necessária que envolve os processos e os produtos resultantes.
Fica claro ao longo do texto que somente se pode gerenciar a qualidade 
de um processo e dos produtos de software se os mesmos puderem ser 
medidos e acompanhados durante todo o processo de especificação e 
desenvolvimento.
Outra contribuição relevante dos autores e especialistas analisados e 
pesquisados é que corrigir defeitos de software é uma atividade muito cara e 
que todas as ações necessárias para a prevenção devem ser implementadas.
A unidade encerra-se com a apresentação da filosofia envolvida 
com os testes de software e sua importância para as empresas que 
desenvolvem soluções computadorizadas para o negócio e para a 
sociedade como um todo.
 Exercícios
Questão 1. Pode-se dizer que um software de qualidade:
• está em conformidade com os requisitos dos clientes;
• antecipa e satisfaz os desejos dos clientes;
• escreve tudo o que se deve fazer e faz tudo o que foi escrito;
• soma as características de uma entidade em sua totalidade, o que satisfaz as necessidades 
explícitas e implícitas dos clientes.
50
Unidade II
Conceitos sobre o que é a qualidade e como ela pode ser alcaçada e avaliada podem ser aplicados 
aos produtos de software e ao seu desenvolvimento. Inicialmente, isso será um grande problema, já que, 
de acordo com vários autores, muitas pessoas acham que criar softwares ou sistemas de informação é 
uma arte que não pode seguir regras, normas ou padrões.
Analise as alternativas a seguir e indique a que contém uma afirmação incorreta. A qualidade de um 
software:
A) É definida pelo conjunto de processos e de produtos que seguem métodos e práticas reconhecidos 
no mercado.
B) Depende de cada parte do processo de desenvolvimento, e não somente de uma boa análise e de 
bons testes.
C) Pode apresentar variações em algumas de suas definições; porém, o aspecto que se refere à 
satisfação do cliente ou stakeholder não deve ser esquecido.
D) É invisível para o usuário ou para o cliente: daí a dificuldade de inserção de propostas de melhoria 
na qualidade de produto.
E) É constante, pois ele não se desgasta com o uso e não tem prazo de validade.
Resposta correta: alternativa D.
Justificativa geral: é necessário entender que o problema da qualidade dos softwares não está nesses 
produtos, mas na forma como as pessoas os têm desenvolvido até os dias de hoje. Ao longo do tempo, 
temos ouvido frases do tipo: “Se os engenheiros construíssem prédios ou outras edificações como os 
desenvolvedores constroem softwares, todo dia teria desabamento”. Deixando de lado exageros desse 
tipo, a comunidade de softwares precisa se conscientizar de que deve aplicar urgentemente os conceitos 
de qualidade, que são fundamentais em outras áreas do conhecimento, na indústria de softwares. 
Atualmente, muitas instituições e muitos órgãos normativos preocupam-se em criar modelos e guias para 
permitir a correta avaliação de qualidade tanto de produtos quanto de processos de desenvolvimento 
de softwares.
Análise das alternativas
A) Alternativa correta.
Justificativa: a qualidade de um software resulta de um conjunto completo de atividades 
interdependentes, entre as quais as revisões técnicas e os testes que garantem a qualidade do produto 
desenvolvido.
B) Alternativa correta.
51
QUALIDADE DE SOFTWARE
Justificativa: nenhuma quantidade de testes, por maior que seja, pode compensar a baixa qualidade 
causada por outras atividades do processo de desenvolvimento de um software.
C) Alternativa correta.
Justificativa: a maioria dos consumidores, na atualidade, não tolera a falta de qualidade e procura 
outros fornecedores. Mais qualidade aumenta a satisfação dos consumidores e assegura a fidelidade 
daqueles que já são clientes há mais tempo.
D) Alternativa incorreta.
Justificativa: devido à invisibilidade e à intangibilidade dos softwares, os desenvolvedores utilizam 
diversas técnicas para representar um sistema de software, incluindo modelos, desenhos e gráficos. Isso 
diminui as dificuldades da busca pela qualidade desses produtos.
E) Alternativa correta.
Justificativa: a ausência de desgastes e de prazos de validade é característica importante dos produtos 
de software que os diferenciam dos produtos manufaturados, e não pode deixar de ser notada.
Questão 2. De acordo com o professor Fábio Martinho de Campos, com várias certificações em 
qualidade de software, um dos grandes erros cometidos por pessoas e empresas é confundir os conceitos 
e a aplicação dos termos “controle da qualidade” e “garantia da qualidade”. Esses erros também são 
cometidos por desenvolvedores de software, embora tenham propósitos totalmente diferentes.
Analise as alternativas a seguir e indique a que contém uma afirmação incorreta. A garantia da 
qualidade de softwares:
A) Permite que o processo de desenvolvimento de softwares de uma organização seja definido e 
apropriado.
B) Tem como exemplos os métodos, as metodologias e os padrões de desenvolvimento.
C) Focaliza as atividades iniciais do ciclo de vida do desenvolvimento de softwares.
D) É orientada à prevenção.
E)É orientada à detecção de erros ou defeitos nos produtos.
Resolução desta questão na plataforma.