AULA 2: Fatores, mtricas e garantias de qualidade de software

Existe uma imensa variedade de coisas diferentes que podem ser medidas sob vrios
aspectos.
A medio ajuda a tornar visveis caractersticas especficas de processos e produtos.
Sendo assim, os fatores que afetam a qualidade de software podem ser categorizados em
grupos de fatores que podem ser medidos diretamente (unidade de tempo) ou apenas
indiretamente (usabilidade ou manutenibilidade).
A inteno em cada um dos grupos de fatores a medio e a comparao de
software com algum dado e obter uma indicao de qualidade.
A garantia da qualidade de software (Software Quality Assurance SQA) trata-se de
uma atividade guarda-chuva, aplicada ao longo de todo o processo de engenharia de
software.
Abrange uma srie de tarefas vinculadas especificamente a sete atividades que
compem um plano que realiza avaliaes, auditorias, revises, define padres para o
projeto, procedimentos para relato, acompanhamento de erros, documentao necessria
e realimenta a equipe com informaes conclusivas do projeto.

Aplicao de mtodos e ferramentas tcnicas: O estudo dos mtodos e

ferramentas tcnicas de anlise, projeto, codificao e teste so atribudos aos
princpios fundamentais da anlise de requisitos de software de sistemas.
Ajudam o analista e o projetista a produzirem um projeto de elevada qualidade.
Atividade central de reviso tcnica formal (Formal Technical Review
FTR): Tem o propsito nico de descobrir problemas de qualidade. Essa
atividade especfica da equipe tcnica e, em muitas situaes, tem
descoberto que as revises so to efetivas quanto os testes para deteco de
problemas de qualidade.
Atividade de teste de software: Conhecida como rede de segurana de
garantia de software, combina uma srie de mtodos de projetos de casos de
testes que auxiliam a garantir uma deteco de erros efetiva. As atividades de
teste aplicadas de forma cuidadosa revelam a maioria dos erros, aliviando a
necessidade de outras atividades de SQA. Porm, considera-se atualmente que
no seja a mais efetiva para todas as classes de erros.
Padres e procedimentos formais: So aplicados no processo de engenharia
de software e validados pelos desenvolvedores quanto ao cumprimento dos
padres exigidos pelo software. Em alguns casos, o grupo de SQA pode realizar
uma auditoria independente do atendimento aos padres exigidos.
Atividade de controle de mudana: Formaliza pedidos de mudana, avalia a
natureza da mesma e controla o respectivo impacto que ela pode causar. O
controle de mudana aplicado durante o desenvolvimento de software e aps
a manuteno do software.
Medio de software: Coleta um conjunto de medidas tcnicas e orientadas
para a administrao das especificaes do software.
Anotao e manuteno de registros (documentao): essencial para a
garantia da qualidade de software no que diz respeito coleta e disseminao
de informaes de SQA. Os resultados de revises, auditorias, controle de
mudanas, testes e outras atividades de SQA devem torna-se parte de um
registro histrico de um projeto documentado. A documentao deve ser
acessvel a todos que participam da equipe de desenvolvimento de software.

Fatores de qualidade de software:

Alguns fatores afetam a qualidade de software, por isso, determinados aspectos devem ser
considerados em um software tais como: caractersticas operacionais, manutenibilidade de
mudanas e adaptabilidade a novos ambientes.
McCall (1977) considera as seguintes categorizaes sobre os fatores que afetam a
qualidade de software e podem ser descritos da seguinte forma:

Reviso:
o Manutenibilidade: capacidade de reparao de erros no programa de
forma a torn-lo disponvel para uso.

o
o

Flexibilidade: esforo para se modificar um programa operacional.

Testabilidade: tempo necessrio para se testar um programa a fim de
garantir que ele execute a funo pretendida.

Operao:
o Corretitude: o atendimento do programa s especificaes e objetivos
visados pelo cliente.
o Confiabilidade: o quanto um programa executa a funo pretendida com
a preciso exigida.
o Eficincia: quantidade de recursos de computao e de cdigo necessria
para um programa executar a funo desejada.
o Integridade: controle de acesso ao software ou a dados de forma
controlada.
o Usabilidade: esforo para aprender, operar, preparar a entrada e
interpretar a sada de um programa.

Transio:
o Portabilidade: demanda de esforo para transferir um programa de um
ambiente de hardware e/ou software para outro.
o Reusabilidade: propriedade de reutilizar um programa ou partes de um
programa em outras aplicaes (refere-se ao empacotamento e escopo
de funes que o programa executa).
o Interoperabilidade: esforo exigido para se acoplar um sistema a outro.

Por outro lado, segundo Pressman (2002), existe a dificuldade de se desenvolver medidas
diretas dos fatores de qualidade desenvolvidos por McCall (1997) por considerar que muitas das
mtricas s podem ser medidas subjetivamente. Cavano e MCCall (1978), citados por Pressman
(2002), consideram importante a utilizao de uma lista de verificao (checklist) para graduar
outros atributos especficos do software.
McCall (1977) considera relevante a utilizao de uma escala padro que varia de 0 (baixo)
a 10 pontos (elevado), no estabelecimento de mtricas de qualidade para cada fator que altera
a qualidade de software.
Para mais informaes, leia no texto Mtricas de qualidade, como Pressman (2002, pp. 727:729)
apresenta as mtricas usadas no esquema de graduao de McCall (1977).

Pressman (2002) comenta que os fatores e atributos da qualidade descritos anteriormente

podem ser usados para estabelecer mtricas de qualidade para cada etapa do processo de
desenvolvimento de software.
Alm dos fatores evidenciados pelos autores citados, outros tambm interferem na
aquisio de qualidade durante o processo de desenvolvimento de software, tais como:

Falta de um modelo corporativo de qualidade.

Ausncia de procedimentos de testes automatizados.
Ausncia de profissionais capacitados em qualidade.
Deficincia no planejamento e aplicao dos testes.
Qualidade aplicada tardiamente no processo.

Em contrapartida, o predomnio da qualidade no processo de desenvolvimento de software

traz alguns benefcios, como:

Torna o ciclo de desenvolvimento de software confivel.

Garante aes corretivas no ciclo de desenvolvimento.
Evita a ingerncia do projeto de software.
Amplia as chances de sucesso do projeto de software.
Amplia a produtividade do desenvolvimento.
Evita a propagao de erros.
Automao de testes reduz custos do projeto.

Revises de Software:
As revises so mtodos de validao de qualidade de um processo ou produto
amplamente usado pela equipe tcnica do projeto. So consideradas como verdadeiros filtros
de erros e inconsistncias no processo de desenvolvimento de software.
Qualquer reviso uma maneira de usar a diversidade de um grupo de pessoas para
apontar melhorias necessrias ao produto gerado por uma equipe, confirmar partes ou o todo
de um produto que devem ser melhorados (ou no) e realizar um trabalho mais tcnico com
uma qualidade mais uniforme e previsvel, de forma a tornar o trabalho tcnico mais
administrvel.
Alguns bons exemplos de revises so levados em considerao a efeito de contriburem na
garantia da qualidade de software. Por exemplo, um encontro informal em torno da mquina de
caf uma forma de reviso quando tratados problemas tcnicos. Uma apresentao tcnica do
projeto a clientes, administrao e ao pessoal tcnico tambm pode ser considerada uma
forma de reviso.

Custos da qualidade:
Um outro aspecto importante referente aos custos da qualidade. Vrios so os estudos
conduzidos por especialistas da rea de qualidade intencionados em obter um referencial para
os custos reais da qualidade, a fim de poderem identificar maneiras de reduzir custos da
qualidade e fornecer uma base de comparao entre os demais custos envolvidos no processo
de desenvolvimento de software.
Os custos operacionais da funo qualidade podem ser classificados em quatro categorias:
preveno, avaliao, falhas internas e falhas externas. Veja a seguir esses quesitos
detalhadamente:

Custos de preveo (preveno de defeitos 5 a 15%): So controlveis e

caracterizam investimento. Atividades decorrentes:
o planejamento da qualidade
o revises tcnicas formais
o equipamentos de teste
o treinamento

Custos de avaliao (remover do processo produtos com defeitos 20

a 25%): So incontrolveis e caracterizam perdas e prejuzo. Atividades
decorrentes:
o inspeo intra e interprocessos
o calibrao e manuteno do equipamento
o teste

Custos de falha interna (defeitos antes da entrega ao cliente 65 a

70%): So incontrolveis e caracterizam perdas e prejuzo. Atividades
decorrentes:
o trabalho para refazer
o esforo para reparar
o anlise do modo como a falha ocorreu

Custos de falha externa (defeito aps entrega ao cliente 65 a 70%):

So incontrolveis e caracterizam perdas e prejuzo. Atividades decorrentes:
o soluo de queixas

o
o

devoluo e substituio do produto

manuteno da linha de suporte

Interessante ressaltar que na medida em que migramos dos custos de preveno para os
de deteco de falhas internas at os de falhas externas aumentamos significativamente os
custos de identificao e reparo de um defeito.
Uma anlise numrica justifica o impacto de custo de deteco de erros feita
precocemente. Considere que, na descoberta de um erro durante a fase de projeto, o custo seja
de uma (1,0) unidade monetria para ser corrigido. Em relao a esse custo, o mesmo erro,
descoberto logo antes que as atividades de teste se iniciem, custar 6,5 unidades; durante os
testes, 15 unidades; e, aps o lanamento, entre 60 e 100 unidades (PRESSMAN, 2002).
Revies tcnicas formais:
As revises tcnicas formais so consideradas como a principal atividade de um SQA.
Conhecida como walkthroughs, inspees, reunies round - robin e outras avaliaes
tcnicas de software, as revises tcnicas formais tm como objetivos:
1.
2.
3.
4.
5.

descobrir erros de funo, lgica ou implementao do software;

verificar se o software em reviso atende aos requisitos;
garantir que o software est representado de acordo com padres predefinidos;
obter um software desenvolvido de forma uniforme; e
tornar os projetos mais administrveis (SOMMERVILLE, 2007).

Assim como a reviso de software, a reviso tcnica formal (Formal Technical Review - FTR)
deve contar com algumas etapas, segundo Pressman (2002):
Reunio da reviso: entre trs a cinco pessoas com preparao antecipada de 2 horas de
trabalho de cada pessoa para uma durao de no mais que 2 horas.

Comunicao e manuteno de registros de reviso: consiste na atividade de um revisor

atuar durante a FTR para registrar todas as questes que foram levantadas para efeito de
reviso do produto de software em estudo. No final da reunio, um relatrio de reviso resumido
simples concludo e distribudo ao lder do projeto e a outras partes interessadas. O objetivo da
lista de questes de reviso identificar as reas problemticas do produto de software e servir
de conferncia de itens de ao que apiem o produtor nas correes a serem feitas.
Interessante enfatizar que a comunicao deve ser contnua durante o processo de
reviso e por isso, requer um procedimento de resposta aos itens da lista de questes
levantadas para efeito de confirmar a devida correo das questes levantadas.
Diretrizes de reviso: estabelecida antecipadamente e distribuda a todos os revisores para a
concordncia de todos e assim ser encaminhada mantendo a organizao no processo de
reviso tcnica formal. Requer um conjunto de diretrizes necessrias para a perfeita realizao
do processo:

Revisar o produto, no o produtor.

Fixe e mantenha uma agenda.
Limite ao debate e a refutao.
Foco nas reas problemticas.

Registre as anotaes por escrito.

Reduzir nmero de participantes.
Definir uma lista de conferncia (checklist) para cada produto revisado.
Atribuir recursos e uma programao de tempo para as FTRs.
Realizar treinamento para os revisores.
Rever antigas revises.