Qualidade de Software
Valdir Sant’Ana……….RA01580/00-5
Sidnei da Silva Padilha….RA03219/00-1
Luiz Ricardo C. Batista….RA 00499/00-4
André de Souza Barbosa….RA02783/00-3
Qualidade de Software
Conjunto de características a serem
satisfeitas em um determinado grau de
modo que o software satisfaça às
necessidades de seus usuários
Usuários de Software
Desenvolvedores
Usuário Final
Suporte
Outra Classe de Usuários
“penumbra”
O software deve ter características que
atendam às necessidades de todos os
seus usuários
Controle da Qualidade de Software
conjunto planejado e sistemático de todas
as ações necessárias para fornecer uma
confiança adequada de que o item ou
produto está de acordo com os requisitos
técnicos estabelecidos
Qualidade de Software
Qualidade do Processo
Qualidade do Produto
Produto e Processo estão fortemente
relacionados e não podem ser separados
quando se analisa a qualidade
A implantação de um Programa de Qualidade
começa pela definição e implantação de um
processo de desenvolvimento
O processo de desenvolvimento de
software deve estar documentado,
compreendido e seguido
Qualidade do Processo
A qualidade do processo é essencial para
se ter qualidade do produto
ISO 9000-3
CMM
ISO 9000-3
 Sistema da Qualidade: Estrutura
 Responsabilidade do fornecedor
 Responsabilidade do comprador
 Análise crítica conjunta
 Atividades do Ciclo de Vida








Análise crítica do contrato
Especificação dos Requisitos do comprador
Planejamento do desenvolvimento
Projeto e implementação
Testes e validação
Aceitação
Cópia, entrega e instalação
Manutenção
ISO 9000-3
 Atividades de Apoio









Gerenciamento da configuração
Controle de documentos
Registros da qualidade
Medição
Regras, convenções
Ferramentas e técnicas
Aquisição
Produto de software incluído
Treinamento
Certificação ISO 9000
• Demonstra que o Sistema de Qualidade
da Organização é efetivo
Fornece evidência de que a Organização é
capaz de produzir produtos e serviços de
qualidade
Não avalia diretamente a qualidade de
nenhum produto ou serviço
CMM - Capability Maturity Model
(Modelo de Maturidade de Capacidade)
• Motivação: Projetos do Departamento de
Defesa
• 5 Níveis de Maturidade para o Processo
CMM - Níveis de Maturidade
5. Otimizado
Gerência de mudanças no processo
Gerência de mudanças na tecnologia
Prevenção de defeitos
4. Gerenciado
Gerência da qualidade de software
Gerência quantitativa do processo
3. Definido
Revisões
Coordenação entre grupos
Engenharia do produto de software
Gerência de software integrada
Programa de treinamento
Definição do processo da organização
Foco no processo da organização
Gerência de configuração
Garantia da qualidade de software
Gerência de contratos de software
Acompanhamento de projetos de software
Planejamento de projetos de software
Gerência de requisitos
2. Repetível
1. Inicial
Comparação entre ISO 9000-3 e CMM
ISO 9000-3
• identifica os requisitos mínimos para um
Sistema da Qualidade
CMM
• tem como filosofia a necessidade de
contínuos aperfeiçoamentos no processo
Qualidade do Produto
 Características de Qualidade
 Técnicas para Avaliação da Qualidade
Dois tipos de Avaliação
Avaliação ao longo do processo
de desenvolvimento
Avaliação de pacotes
Avaliação ao longo do
Desenvolvimento
 qualidade externa
deve estar explicitamente definida
Especificação de Requisitos do Projeto
na
 qualidade interna
atributos que são geralmente acrescentados
pela empresa
QUALIDADE
EXTERNA
QUALIDADE
INTERNA
Características de
Qualidade do Produto
Norma ISO 9126
Características de Qualidade para
Domínios Específicos
Características de Qualidade para
Tecnologias Específicas
ISO 9126
• Define seis características de qualidade e
sub-características associadas a estas
características
Característica da ISO 9126

FUNCIONALIDADE
Conjunto de atributos que evidenciam a
existência de um conjunto de funções e suas
propriedades especificadas
Sub-características:
• adequação
• acurácia
• interoperabilidade
• conformidade
• segurança de acesso
Característica da ISO 9126

CONFIABILIDADE
conjunto de atributos que evidenciam a
capacidade do software de manter seu nível
de desempenho sob condições estabelecidas
durante um período de tempo estabelecido
Sub-características:
• maturidade
• tolerância a falhas
• recuperabilidade
Característica da ISO 9126

USABILIDADE
conjunto de atributos que evidenciam o esforço
necessário para se poder utilizar o software,
bem como o julgamento individual deste uso,
por um conjunto explícito ou implícito de
usuários
Sub-características:
• inteligibilidade
• apreensibilidade
• operacionalidade
Característica da ISO 9126

EFICIÊNCIA
conjunto de atributos que evidenciam o
relacionamento entre o nível de desempenho do
software e a quantidade de recursos usados, sob
condições estabelecidas
Sub-características:
• comportamento em relação ao tempo
• comportamento em relação aos recursos
Característica da ISO 9126

MANUTENIBILIDADE
conjunto de atributos que evidenciam o
esforço necessário para fazer modificações
especificadas no software
Sub-características:
• analisabilidade
• modificabilidade
• estabilidade
• testabilidade
Característica da ISO 9126

PORTABILIDADE
conjunto de atributos que evidenciam a
capacidade do software ser transferido de um
ambiente para outro
Sub-características:
• adaptabilidade
• capacidade para ser instalado
• conformidade
• capacidade para substituir
Necessidades explícitas
ou implícitas
Requisitos
Gerenciais
ISO 9126/NBR13596 e outras
informações técnicas
Especificação dos
Definição dos
requisitos de
qualidade
Requisitos de Qualidade
Seleção de
Métricas
Definição do
nível de
pontuação
Definição dos
critérios de
julgamento
Produtos/Prod.
Desenvolvimento intermediários
de software
Valor medido
Medição
Pontuação
Nível de
pontuação
Julgamento
Resultado
(aceitável ou inaceitável)
Modelo de Processo de Avaliação
Avaliação de pacotes
ISO-12119
estabelece requisitos de qualidade
mostra como testar
Definições
FATOR (CARACTERÍSTICA) DE QUALIDADE
 atributo de software que contribui para a sua qualidade
 orientado ao usuário (o que o usuário espera encontrar no
produto)
MÉTRICA DE QUALIDADE
 função cuja entrada são dados do software e cuja saída é
um valor que pode ser interpretado como o grau em que o
software possui um dado atributo que afeta sua qualidade
ENTENDER
RAZÕES PARA
MEDIR SOFTWARE
PREDIZER
CONTROLAR
“Quando você pode medir o que você está
falando, e expressá-lo em números, você
conhece alguma coisa sobre ele; quando você
não pode expressá-lo em números o seu
conhecimento é imperfeito”
Lord Kelvin
Não podemos gerenciar o que
não podemos medir
Métricas de Software
• Utilizadas para permitir a quantificação do
grau em que as características estão presentes
em um determinado produto de software
 métricas objetivas e subjetivas
 métricas diretas e indiretas
 métricas do produto e do processo
• Dificuldades para o uso de métricas
 falta de experimentos para validação
 falta de ferramentas de apoio
Características de Boas Métricas
CARACTERÍSTICAS ORGANIZACIONAIS
•
•
•
•
•
•
•
•
•
•
•
Aplicação ao processo de software e à gerência do projeto
Alta visibilidade
Consistência na aplicação
Interesse e apoio da gerência
Aceitação na organização
Compatibilidade com a política da organização
Existência de responsabilidade e controle
Disponibilidade de dados históricos
Correspondência ao processo de desenvolvimento
Apoio aos objetivos de melhoria do processo
Paciência
Características de Boas Métricas
CARACTERÍSTICAS TÉCNICAS
•
•
•
•
•
•
Número limitado de métricas
Facilidade de cálculo
Disponibilidade de dados para cálculo da métrica
Precisão da definição
Apoio de ferramentas
Realização de experimentos
Identificação de Métricas Úteis
• A prática de coletar e usar métricas não validadas não
pode ser aceita como Engenharia de Software
• Quando uma métrica parece promissora, a partir de
resultados de pesquisa, ela deve ser validada pelo uso
na Indústria em projetos de grande escala
• O benefício de uma métrica não pode ser avaliado de
forma imediata
São necessários dados históricos para avaliar e
refinar métricas
 Necessidade de Ferramentas
Ferramentas asseguram:
• que as medidas sejam consistentes
• produtividade na coleta de métricas
Gerência da Qualidade de Software
 Planejamento da Qualidade
 Controle da Qualidade
Para avaliar software são necessárias as seguintes
informações:
Características de Qualidade de Interesse
Documentos do Projeto
Informações sobre o Processo
Técnicas de Avaliação
Planejamento do Controle da Qualidade
Identificação das características de qualidade de
interesse para o produto
Definição da importância de cada característica
Definição de processos de avaliação
Definição de marcos e pontos de controle ao longo do
processo de desenvolvimento
Plano de Controle da Qualidade
• Contem a descrição de todos os procedimentos
a serem adotados no projeto
para controle da qualidade de produtos
intermediários ao longo do desenvolvimento
para avaliação do produto final
• Define a equipe de controle da qualidade
Técnicas para Avaliação da Qualidade
 Certificação
• Walkthrough
• Inspeção
• Prova Formal
 Testes
Walkthrough e Inspeções
OBJETIVOS
 detectar erros em qualquer representação do software
 verificar se o software sob avaliação atinge os requisitos
 assegurar que foram obedecidos normas e padrões
 assegurar que o software é desenvolvido de forma uniforme
 tornar o produto gerenciável
 treinar a equipe
CARACTERÍSTICAS
 reunião com grupos de 3 a 5 pessoas
 envolve preparação prévia à reunião
 devem durar em torno de 2 horas
Inspeção
semelhante ao walkthrough embora
mais formal
baseada em critérios previamente
definidos
Procedimentos para tornar eficaz a reunião
 rever o produto e não o desenvolvedor
 estabelecer uma agenda e mantê-la
 limitar o debate
 detectar problemas mas não tentar resolvê-los na reunião
 fazer anotações
 limitar o número de participantes
 elaborar um conjunto de critérios a serem avaliados
 alocar recursos e espaço no cronograma para a reunião
 treinar revisores
 rever revisões anteriores
Inspeção por Fases
A avaliação do produto é feita através de uma
série de avaliações parciais que podem ser
realizadas com inspetores individuais ou com
múltiplos inspetores
Cada avaliação parcial tem o objetivo de
verificar se o produto possui uma ou mais
propriedades
Prova Formal
OBJETIVO
demonstrar matematicamente a correção de um programa
VANTAGEM
percorrer todos os caminhos de um programa
DESVANTAGEM
dificuldade
ausência de ferramentas
Modelos de Confiabilidade
 avaliam a qualidade do software quando o
trabalho de desenvolvimento está completo
 são usados para estimar a taxa de defeitos que
está latente no produto quando este é entregue
 esta estimativa é importante porque:
é uma medida objetiva da qualidade do código
pode indicar quando se deve terminar a fase de
testes
pode ser usada para planejamento de recursos de
manutenção e suporte
Cleanroom
Processo de desenvolvimento onde se enfatiza a
construção correta do programa
Prioridade 1:
Prevenir falhas em vez de remover falhas
Solução: verificação formal
Prioridade 2:
Fornecer uma certificação estatística da
qualidade do software
Solução:
• a medida da qualidade é o tempo entre falhas
do produto em unidades de tempo
• leva em consideração o crescimento da
confiabilidade durante o teste do sistema
Seleção do Nível de Avaliação
NÍVEL
AMBIENTE
PESSOAS
D
Pequeno dano a Sem risco para
propriedades
pessoas
C
Dano a proprie- Poucas pesdades
soas mutiladas
B
A
ECONOMIA
APLICAÇÃO
Perda econômi-  Lazer
ca desprezível
 Uso
doméstico
Perda econômi-  Alarme de
ca significativa
incêndio
 Controle de
processos
Dano recuperá- Risco para
Grande perda
 Sistemas
vel ao ambiente vidas humanas econômica
médicos
 Sistemas
financeiros
Dano irrecupe- Muitas pessoas Desastre finan-  Controle de
rável ao ammortas
ceiro
trens
biente
 Sistemas
nucleares
Técnicas de Avaliação
CARACTERÍSTICA
NÍVEL D
NÍVEL C
NÍVEL B
NÍVEL A
Teste funcional
+ Inspeção de
documentos
+ Teste de
componentes
+ Prova formal
Confiabilidade
Facilidades da
linguagem de
programação
+ Análise da
tolerância a
falhas
+ Modelos de
crescimento da
confiabilidade
+ Prova formal
Usabilidade
Inspeção da
interface com
o usuário
+ Aderência a
padrões de
interface
+ Teste em
laboratório
+ Modelos
mentais do
usuário
Funcionalidade
Técnicas de Avaliação
CARACTERÍSTICA
NÍVEL D
NÍVEL C
NÍVEL B
NÍVEL A
Eficiência
Medição do
tempo de
execução
+ Benchmark
+ Análise da
complexidade de
algorítmos
+ Análise de
desempenho
Manutenibilidade
Inspeção de
documentos
+ Análise
estática
+ Análise do
processo de
desenvolvimento
+ Avaliação da
rastreabilidade
Portatilidade
Análise da
instalação
+ Aderência a
normas de
programação
+ Avaliação das
restrições do
ambiente
+ Avaliação do
projeto de programas
Eficiência das Técnicas para a
Detecção e Correção de Erros
ATIVIDADE
EFICIÊNCIA
Revisões informais de projeto
25% a 40%
Inspeções formais de projeto
45% a 65%
Revisões informais de código
20% a 35%
Inspeções formais de código
45% a 70%
Teste de unidades
15% a 50%
Teste de integração
25% a 40%
Teste do sistema
25% a 55%
Beta-teste (< 10 clientes)
24% a 40%
Beta teste (> 1000 clientes)
60% a 85%
Capers Jones, Software defect-removal efficiency,
IEEE Computer, março 1996
Projeto SEC - Uma Experiência de
Gerência da Qualidade de Software
QUALIDADE DO PROCESSO
Definição do Processo de Desenvolvimento
Uso do processo na construção da 1a. versão do
SEC
Avaliação do processo
Melhorias no processo para construção das
demais versões
Projeto SEC - Uma Experiência de
Gerência da Qualidade de Software
QUALIDADE DO PRODUTO
Identificação de características de qualidade de
sistemas especialistas
Definição dos requisitos de qualidade do SEC
Elaboração do Plano de Qualidade
Avaliação da qualidade ao longo do desenvolvimento
• walkthrough
• inspeções
Testes, depuração e refinamentos
Programa Brasileiro de Qualidade e
Produtividade / Software
 Diagnóstico das Empresas Brasileiras
 Indicadores e Metas
 Projetos
 Eventos
Diagnóstico da Qualidade e
Produtividade em Software
1997 - 589 Empresas
Certificação do Sistema da Qualidade
Empresas Certificadas
Todos os setores
Setor de Informática
Pesquisa da Qualidade em Software
Certificação ISO 9001
Certificação ISO 9002
SW explicitado no escopo certificado
1997
1.788
129
45
36
11
16
Diagnóstico da Qualidade e
Produtividade em Software
1997 - 589 Empresas
Conhecimento dos Modelos CMM e SPICE
Categorias
Conhece e usa
Conhece e começa a usar
Conhece mas não usa
Não conhece
CMM
No
%
7
20
143
419
1,2
3,4
24,3
71,1
SPICE
No
%
1
7
99
482
0,2
1,2
16,8
81,8
Diagnóstico da Qualidade e
Produtividade em Software
1997 - 589 Empresas
Conhecimento de Normas para Qualidade
Categorias
Conhece e usa
Conhece mas não usa
Não conhece
ISO 12207
ISO 9126 ou 12119
No
%
No
%
32
115
441
5,5
19,6
75,0
43
113
443
7,3
19,2
73,5
Diagnóstico da Qualidade e
Produtividade em Software
1997 - 589 Empresas
Avaliação de Produtos Baseada nas Normas de
Qualidade de Produtos de Software
Categorias
Segundo ISO 9126
Segundo ISO 12119
Auto-Avaliação
Em estudo/Preparando-se
Não adota
No de empresas
8
5
177
246
168
%
1,4
0,8
30,1
41,8
28,5