Qualidade de
Produto de Software
Prof. Leandro Bento Pompermaier
PUCRS, FACIN
leandro.pompermaier@pucrs.br
Crenças
n Mesmo sistemas perfeitos podem falhar
q falhas provocadas por causa exógenas
n falhas provocadas por mau uso, deliberado ou não
n falhas provocadas por falhas de hardware
n falhas provocadas por falhas da plataforma de software usada
n Não é possível antever todas as potenciais causas de
falhas
q exógenas – provocadas por causas externas
q endógenas – provocadas por defeitos no próprio software
n Algumas falhas poderão ser toleradas
q desde que os danos possam ser asseguradamente mantidos
abaixo de um limite estabelecido
3/14/2011
Crenças
n Não se pode esperar que sistemas não contenham
defeitos
q caso um sistema não contenha defeitos não o saberemos
n muitas vezes podemos saber se módulos têm defeitos ou não
q implica a necessidade de medir o desempenho e avaliar a
corretude durante a execução do sistema
n instrumentação do código
n As características de fidedignidade não podem ser
adicionadas a posteriori
q as características precisam ser especificadas, arquitetadas,
projetadas etc. junto com os requisitos funcionais
q para atingir bons níveis de fidedignidade deve-se
n prevenir a inserção de defeitos
n controlar as falhas de causas exógenas
Definições de “qualidade” Modelo da economia da qualidade
n Deming qualidade é a satisfação total do consumidor Custo decorrente de falhas

n Juran qualidade é a adequação ao uso

n Crosby qualidade é a conformidade com os Custo total

requisitos

risco: desenvolvimento correto do problema errado Valor do serviço

n Falconi qualidade é a preferência do consumidor

n NBR 8402/1994 Custo do desenvolvimento

q Totalidade de características de uma entidade que lhe confere a Perda por falta Perda por excesso
de qualidade de qualidade
capacidade de satisfazer as necessidades explícitas e implícitas
C
u
s
t Valor líqüido
o
Qualidade assegurada

Qualidade de Software Qualidade de Processo vs. Qualidade

n A Qualidade de Software é definida por
[PRESSMAN 2001] como:
q Conformidade com requisitos funcionais e de
performance explicitamente estabelecidos,
padrões de desenvolvimento explicitamente
documentados e características implícitas
inerentes a todo o profissional desenvolvedor de
software.
de Produto de Software
n Qualidade de Processo: preocupa-se com a
qualidade nas etapas de desenvolvimento,
ou seja, como se faz o produto
n Qualidade de Produto: preocupa-se com os
atributos de qualidade do resultado do
desenvolvimento de software.

n Pergunta: podemos ter qualidade de produto

sem qualidade de processo? E vice-versa?
3/14/2011 3/14/2011
Teste de Conceitos
Software e
n Fundamentos da Qualidade de SW [PRESSMAN 2001]:
Processo de q Requisitos de software são a base na qual a qualidade é
Desenvolvimento medida. Falta de conformidade com requisitos É falta de
qualidade.
q Padrões especificados definem o conjunto de critérios de
desenvolvimento que guiam a maneira na qual o software
é construído. Se o critério não é seguido, a falta de
qualidade é quase certa.
q Um conjunto de requisitos implícitos são frequentemente
não mencionados (Ex: Facilidade de uso ou manutenção).
Se o SW está de acordo com os requisitos explícitos mas
falha nos implícitos a qualidade do SW é suspeita.

3/14/2011 3/14/2011

Conceitos
n Garantia da qualidade de software:
q Conjunto de atividades técnicas aplicadas durante
todo o processo de desenvolvimento do produto;
q O objetivo é garantir que tanto o processo de
desenvolvimento quanto o produto desenvolvido
atinjam os níveis de qualidade especificados;
Conceitos
n Verificação
q Assegura que o produto atende às especificações
q “Estamos construindo certo o produto?”
n Validação
q Assegura que o produto atende às necessidades
q “Estamos construindo o produto certo?”

3/14/2011 3/14/2011
Para reflexão Teste X Qualidade de SW
n Qual a importância do teste no contexto da n A qualidade não é testável. Se ela não
qualidade de software? existe antes de você começar a testar, ela
n O teste é necessário? não existirá quando o teste estiver
n O teste é suficiente? terminado.
n Por que? n A qualidade é incorporada no SW através
da aplicação de processo de engenharia de
software, tais como:
q Aplicação adequada de métodos e ferramentas;
q Revisões técnicas formais e revisão por pares
efetivas;
q Acompanhamento e gerenciamento sólido;
3/14/2011 3/14/2011

Defeito x Falha x Erro Defeito x Falha x Erro

n Defeito (Fault) faz parte do universo físico, ou
seja, sempre é cometido por um indivíduo e
caracteriza-se por uso incorreto de processo ou
sintaxe. Por exemplo, uma instrução ou
comando incorreto em uma determinada
linguagem de programação.
n Falha (Failure) só é possível perceber no
universo do usuário. A falha é percebida quando
o comportamento da aplicação é diferente dos
requisitos relatados pelo cliente. A falha é
gerada a partir de um ou vários erros.

3/14/2011 3/14/2011
Defeito x Falha x Erro Tipos de defeito
n Erro (Error) se dá no universo da informação e é n Taxonomia definada por Shull (1998) a partir do padrão
conseqüência de um defeito em um artefato IEEE Std 830-1998 para especificação de requisitos:
de software. Um erro é caracterizado pela Tipo de Defeito Definição
diferença do valor processado e o valor Omissão Informação necessária não incluída
esperado. Dessa forma todo valor que seja
Ambigüidade Informação passível de múltiplas interpretações
diferente do esperado é classificado como erro.
Inconsistência Informações conflitantes

Fato Incorreto Informação que não é verdadeira para as

condições especificadas
Inf. Estranha Informação desnecessária

OBS: De acordo com (Travassos et al., 2001) esta taxonomia também é aplicável
a outros artefatos.

3/14/2011 3/14/2011

Omissão Exemplo de omissão

1. Algum requisito importante relacionado à n Requisitos:
funcionalidade, ao desempenho, às restrições de 1. Livros podem ser emprestados para professores,
projeto, a atributos ou a interface externa não foi funcionários e alunos.
incluído; 2. O prazo de devolução para alunos é de 5 dias.
2. Não está definida a resposta do software para 3. O prazo de devolução para professores é de 10
todas as possíveis situações de entrada de dados; dias.
3. Faltam seções na especificação de requisitos; 4. Dependendo da categoria do livro, o prazo
poderá ser maior.
4. Faltam referências de figuras, tabelas e
diagramas; n Quais os defeitos nestes requisitos?
5. Falta definição de termos e unidades de medida. q Qual o prazo de devolução para funcionários?
q Quais as categorias possíveis?
q Quais os prazos diferenciados para cada
3/14/2011 3/14/2011
categoria?
Ambigüidade Exemplo de ambigüidade
n Um requisito tem várias interpretações n Requisitos:
devido a diferentes termos utilizados para q A multa será cobrada apenas de usuários do tipo
uma mesma característica ou vários aluno e professor.
significados de um mesmo termo para um n Qual o defeito neste requisito?
contexto em particular. n Duas interpretações podem ser tiradas deste
requisito devido ao uso incorreto do “e”:
1. A multa será cobrada tanto de professores quanto
de alunos;
2. A multa será cobrada apenas de professores que
também forem alunos;

3/14/2011 3/14/2011

Inconsistência Fato incorreto

n Dois ou mais requisitos são conflitantes. n Um requisito descreve um fato que não é
n Exemplo de inconsistência: verdadeiro, considerando as condições
q É permitido no máximo 20 renovações de um solicitadas para o sistema.
mesmo livro.
q Alunos podem permanecer com o mesmo livro
por no máximo um semestre.
n Qual o defeito nestes requisitos?
q Inconsistências entre os períodos máximos de
empréstimo nos dois requisitos.

3/14/2011 3/14/2011
Informação estranha
n As informações fornecidas no requisito não
são necessárias ou mesmo usadas.
3/14/2011
Verificação e Validação (V&V)
n É uma abordagem disciplinada para avaliar a
qualidade dos produtos de software durante
todo o ciclo de vida do produto. [SWBOK]
n Objetivo:
q Assegurar que o software cumpra com suas
especificações e atenda às necessidades dos
clientes
n Constitui um processo em si
n Deve ser contemplado em todo o ciclo de
vida
q Não apenas na etapa após desenvolvimento
3/14/2011
Origem dos defeitos
n A tradução incorreta de informações entre as
diversas etapas do processo de
desenvolvimento de software é a principal
causa de defeitos em software.
n Quanto mais cedo o defeito for identificado,
menor será o custo de sua correção.
n Solução: Introduzir atividades de VER&VAL
ao longo de todo o processo de
desenvolvimento de software.
3/14/2011
Verificação e Validação (V&V)
n Por que utilizar técnicas de verificação e
validação?
q Resultados de estudos experimentais evidenciam
benefícios da utilização destas técnicas no
desenvolvimento de software.
q A utilização destes métodos na indústria tem
mostrado resultados positivos considerando tanto
produtividade quanto qualidade.
3/14/2011
Alguns fatos sobre VER&VAL
n Inspeções aumentam significativamente a produtividade,
qualidade e estabilidade dos projetos [FARGAN1976]
n Uma combinação de diferentes técnicas de VER&VAL
apresenta melhor desempenho do que qualquer método
isoladamente [HETZEL1976 e MEYER1978]
n Qualidade melhora a produtividade [MILLS1983]
n Corrigir um defeito após a entrega do produto é
frequentemente 100 vezes mais caro que corrigi-lo
durante as atividades de requisitos e projeto do sistema
[BOEHM e BASILI 2001]
n Testes podem provar a presença de erros, não sua
ausência [DIJKSTRA1970]
3/14/2011
Validação
n Assegura que o software atende às
expectativas do cliente
n Importante antecipar a validação dos
requisitos evitando erros e omissões
n Pode não esgotar possíveis problemas
n Alguns aspectos podem ser identificados
apenas durante a implementação
3/14/2011
Verificação
n Avalia se o produto cumpre com:
q Sua especificação
q Requisitos funcionais e não-funcionais
q Padrões estabelecidos
3/14/2011
Meta
n É estabelecer a confiança de que o
produto é adequado a seu propósito
q Não significa que o produto está livre de
defeitos
q Garante que o produto é suficientemente bom
para o uso pretendido
n O nível de confiança dependerá:
q Das expectativas do cliente/usuário
q Do ambiente de mercado para o produto
q Do custo inerente as atividades de V&V
3/14/2011
Exercício
n Por favor, reunir-se em grupos de 3 - 5
pessoas;
n Debater e listar os principais fatores que
dificultam, na sua opinião, a realização de
verificação e validação na empresa onde
vocês trabalham / trabalharam (15min);
n Discutir os resultados com o grande grupo;
3/14/2011
Resultados
n Tempo para Verificação e Validação
n Falta de Documentação
n Documentação incompleta
n Falta de Tempo
n Falta de interesse/motivação
n Falta de padrão e conhecimento
n Prazos acordados
n Profissionais Qualificados
n Custos Financeiros
n Requisitos ruins
n Conteúdo desnecessário

Resultados
n Requisitos deficientes;
n Falta de manutenção e documentação das
alterações de requisitos;
n Falta de planejamento;
n Infra-estrutura deficiente;
n Falta de cultura sobre V&V;