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:

29
 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).

30
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.
31
 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).

32
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.

33
 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).

34
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.

35
 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.

36
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.

37
 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.

38
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.

39
 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.

40
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
41
 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;

42
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.
43
 Unidade II

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.

44
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:

45
 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.

46
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 esperados sã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;

47
 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.

48
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.

49
 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.

50
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.

51