GQS-medicoes

(1)

Gerência e Qualidade de Software

1

UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL

Curso de Sistemas de Informação

Dourados– MS - 26/08/15

(2)

Ementa

• 1) Introdução a qualidade. • 1.1) Definições

• 1.2) Aspectos Históricos

• _{2) Gerência de Qualidade de Software.} • 2.1) Definição de Qualidade

• _{2.2) Aspectos que afetam a qualidade} • 2.3) Garantia da Qualidade

• 3) Normas de qualidade (ISO). • 3.2) Normas ISO

• 3.2.1) ISO 9126

• 3.2.2) ISO 12207

• 4) Métricas de Qualidade de Software

• 4.2) APF

● 5) Medições

● 6) Qualidade de Produto de Software, Qualidade de Processo de Software e

Maturidade em Qualidade de Software. • _{6.1) CMM}

• 6.2) CMMI

• _{6.3) MPS.BR}

• _{7) Aspectos pessoais em Qualidade de Software.} • 7.1) Gerenciamento da Equipe

• 7.2) Papéis dos desenvolvedores

• 8) Estudo de Caso em Qualidade de Software.

2

(3)

Métricas

3

(4)

4 Dourados – MS - 26/08/15 Objetivo e Motivação O que são? Por que medir? Quatro papéis da medição Categorização das métricas Plano de métricas Métricas de software

(5)

Medições

(Alexandre Bartié – Garantia e Qualidade de Software)

5

(6)

5 – Métricas – Medições

6

Dourados – MS - 26/08/15

• Existe uma infinidade de dúvidas e questões que vem à

tona;

• O objetivo é o sucesso do desenvolvimento do software,

significa minimizar riscos através de um bom processo de

tomada de decisões.

(7)

5 – Métricas – Medições

7

Dourados – MS - 26/08/15

• Tomar decisões baseado em intuições não é o ideal;

(8)

5 – Métricas – Medições

8

Dourados – MS - 26/08/15

• As medições ajudarão nas respostas para as tomadas de

decisões para um projeto;

• Segundo Bartié, para medir um processo de software,

podemos utilizar três indicadores:

•

Cobertura;

•

Eficiência dos testes;

•

Indicadores de defeitos.

(9)

5 – Métricas – Medições

9 Processo de Garantia de Software Processo de Engenharia de Software Cobertura Eficiência dos testes Indicadores de defeitos (Estabelece o grau de abrangência dos testes aplicados ao software como um todo)

(Estabelece uma medida que define o nível de eficiência de todas as atividades relacionadas ao desenvolvimento de software)

(10)

5 – Métricas – Medições

10 Processo de Garantia de Software Processo de Engenharia de Software Cobertura Eficiência dos testes Indicadores de defeitos

Cobertura do Planejamento de Testes Cobertura de Execução dos Testes

Eficiência da Verificação Eficiência da Validação

Eficiência das Etapas dos Testes Distribuição de Defeitos por Categoria

Prioridades dos Defeitos Dist. de Defeitos por Fornecedor Dist. de Defeitos por Componentes

Dist. de Defeitos por Idade Comportamento do Defeito

(11)

5 – Métricas – Medições

(12)

5 – Métricas – Medições - Cobertura

12

Dourados – MS - 26/08/15

• Fornecem o quanto, percentualmente, o produto de

software foi adequadamente testado;

• Esta medida está, na maioria das vezes, relacionadas aos

requisitos de software foram submetidos a testes

(requeriment-based) ou quanto das linhas de código

foram devidamente testadas (code-based);

• Conhecer o nível de cobertura de testes de software é

estabelecer um controle efetivo sobre o produto de

(13)

5 – Métricas – Medições - Cobertura

13

Dourados – MS - 26/08/15

Cobertura de

(14)

5 – Métricas – Medições - Cobertura

14

Dourados – MS - 26/08/15

• Se todos os requisitos estão adequadamente

documentados, uma estratégia baseada em sua

cobertura pode ser suficiente para quantificar o

percentual de abrangência dos testes de software;

• Se aplicarmos os testes baseados no código–fonte,

empregaremos testes que deverão “exercitar” as rotinas

de programação e avaliar o número de linhas testadas

durante o processo, estabelecendo um percentual de

cobertura do código-fonte;

• Em sistemas críticos, a cobertura de código-fonte é

altamente recomendada.

(15)

5 – Métricas – Medições

(16)

5 – Medições – Cobertura do P. de Testes

16

Dourados – MS - 26/08/15

• O nível desta cobertura indica quanto percentualmente

do software possui testes adequadamente planejados e

automatizados;

• Estabelece o grau de risco existente no software;

• Produtos com menor cobertura, apresentam maior

probabilidade de defeitos;

(17)

5 – Medições – Cobertura do P. de Testes

17 Dourados – MS - 26/08/15 Cobertura do Planejamento de Requisitos

Total de Requisitos com Cobertura de Testes Total de Requisitos

=

Cobertura do Planejamento de

Código-fonte

Total de Linhas de Código Cobertura de Testes

Total de Linhas de Código

=

Índice de Cobertura do Planejamento de Requisitos

(18)

5 – Métricas – Medições

(19)

5 – Medições – Cobertura da Exec. de

Testes

19

Dourados – MS - 26/08/15

• Tem por objetivo dimensionar, percentualmente, quanto

dos casos de testes já foram executados;

• Utiliza-se para informar como está evoluindo o processo

de execução dos testes;

• Não está em questão se os casos de testes falharam ou

não, mas se estes já foram aplicados no processo de

validação de software;

• Poderá ser apresentado de forma genérica ou por

categorias: nível de cobertura por requisitos de negócio,

tecnológicos, de segurança, entre outros;

(20)

5 – Medições – Cobertura da Exec. de

Testes

20 Dourados – MS - 26/08/15 Cobertura da Execução de Requisitos

Total de Caso de Testes Executados Total de Caso de Testes dos Requisitos

=

Cobertura da Execução de Código-fonte

Total de Linhas de Código Executadas pelos Testes Total de Linhas de Código a serem Testadas

=

Índice de Cobertura de Execução dos Requisitos

(21)

5 – Métricas – Medições

(22)

5 – Medições – Eficiência dos Testes

22

Dourados – MS - 26/08/15

• É essencial a existência de indicadores que possibilitem

avaliar o volume de erros detectados em cada etapa do

processo;

• Nestes indicadores, o enfoque é avaliar a eficiência dos

testes estáticos (realizados em documentos) e a

eficiência dos testes dinâmicos (realizado em

(23)

5 – Métricas – Medições

(24)

5 – Medições – Eficiência da Verificação

24

Dourados – MS - 26/08/15

• As atividades de verificação são trabalhosas e

introduzem certos custos e esforços. Portanto, é

necessário medir a eficiência da verificação;

• O objetivo é conseguir identificar o maior número de

erros, de forma a reduzir, ao mínimo o número de

incidências nas fases de validação;

• Esse indicador também deverá levar em consideração a

complexidade do software (número de linhas de código

ou total de requisitos), para que se possa comparar o

processo de diferentes projetos.

(25)

5 – Medições – Eficiência da Verificação

25

Dourados – MS - 26/08/15

Eficiência da

Verificação

=

Total de Erros da Validação + Total de Erros em Produção*Total de Linhas de Código ou Total de Requisitos

(26)

5 – Métricas – Medições

(27)

5 – Medições – Eficiência da Validação

27

Dourados – MS - 26/08/15

• É preciso monitorar o ambiente de produção e registrar

todos os erros que ocorrerem nesse ambiente;

• Muitos erros indicam que as atividades de validação

não estão bem planejadas, ou seja, o analista de teste

deverá abstrair mais casos de teste, cobrindo um número

maior de situações.

(28)

5 – Medições – Eficiência da Validação

28

Dourados – MS - 26/08/15

Eficiência da

(29)

5 – Métricas – Medições

(30)

5 – Medições – Eficiência das Etapas dos Testes

30

Dourados – MS - 26/08/15

• Possibilita avaliar quais mecanismos de detecção de

defeitos devem ser melhorados e qual estão

funcionando;

• As etapas iniciais do processo de Engenharia de Software

produzem mais defeitos que as etapas seguintes, pois

são nesse momento que os requisitos são definidos e

toda a concepção de software é criada;

• Cabe ao processo de garantia de qualidade de software

ter procedimentos eficientes de detecção de defeitos,

para que estes sejam detectados mais cedo possível.

(31)

5 – Métricas – Medições

(32)

5 – Medições – Indicadores de Defeitos

32

Dourados – MS - 26/08/15

• A qualidade do software determina o quanto esse

software está próximo dos requisitos e será através dos

defeitos encontrados que são determinados a distância

que deverá se percorrer até atingir um patamar de

qualidade desejado;

• Os defeitos devem ser analisados combinando diversas

técnicas e ferramentas, empregando desde simples

contagens de defeitos até complexas análises estáticas;

(33)

5 – Medições – Indicadores de Defeitos

33

Dourados – MS - 26/08/15

• O volume de defeitos de um software também

proporciona um excelente indicador de confiança do

produto;

• As análises mais comuns de defeitos estão abaixo

representadas:

•

Distribuição de Defeitos por Categorias;

•

Prioridade de Resolução de Defeitos;

•

Severidade dos Defeitos;

•

Defeitos por Fornecedor;

•

Defeitos por Componentes;

•

Idade dos Defeitos;

(34)

5 – Métricas – Medições

(35)

5 – Medições – Distribuição de Defeitos por Categoria

35

Dourados – MS - 26/08/15

• É comum que os defeitos sejam classificados pela ótica

do usuário, uma vez que este é quem realiza o relato

sobre o problema ocorrido;

• Outra categorização poderá ser realizada após posterior

sobre a ocorrência do defeito;

•

Ex: Durante a simulação do problema, avaliou-se que a falha de

execução do software é localizada apenas naquela estação de

trabalho, o que caracteriza como uma falha na instalação local

do produto.

(36)

5 – Medições – Distribuição de Defeitos por Categoria

36

Dourados – MS - 26/08/15

• Essas informações poderão direcionar os esforços da

equipe de qualidade;

• Resultado disso será ações diferenciadas, com novos

treinamentos, revisão de processos, mudança em

documentos, aquisição de ferramentas e terceirização de

determinadas atividades.

(37)

5 – Medições – Distribuição de Defeitos por Categoria

37 Dourados – MS - 26/08/15 41% 15% 8% 21% 5% 10% Falha na Estética falha no Ambiente Erro Fatal Funcionamento Incorreto Não Funcional Falha Operacional

(38)

5 – Medições – Distribuição de Defeitos por Categoria

38

Dourados – MS - 26/08/15

• Erro Fatal:

o software é derrubado durante a execução de uma

funcionalidade;

• Funcionamento Incorreto:

o software não se comporta como o

desejado;

• Não Funcional:

a funcionalidade não está disponível;

• Falha Operacional:

utilização incorreta levou ao erro;

• Falha na Estética:

não está correspondendo à estética desejada;

• Falha no Ambiente:

queda do banco de dados ou da rede

(39)

5 – Métricas – Medições

(40)

5 – Medições – Prioridade de resolução de Defeitos

40

Dourados – MS - 26/08/15

• Cada defeito de software produz impacto diferente no

meio em que o cerca;

• Podemos classificar os defeitos da seguinte forma:

•

Urgente;

•

Alta Prioridade;

•

Média Prioridade;

•

Baixa Prioridade;

(41)

5 – Medições – Prioridade de resolução de Defeitos

41

Dourados – MS - 26/08/15

• A análise dos indicadores de prioridades de defeitos

pode fornecer informações importantes sobre o

comportamento

do

projeto,

facilitando

um

gerenciamento mais produtivo.

Urgente Alta Prioridade Média Prioridade Baixa Prioridade 0 5 10 15 20 25 7 13 21 17

(42)

5 – Métricas – Medições

(43)

5 – Medições – Defeitos por Fornecedor

43

Dourados – MS - 26/08/15

• Pode ser empregado por organizações que empregam

diversos sistemas terceirizados em seus ambientes de

produção.

38% 15% 7% 23% 17% Harware A Hardware B Componente A Componente B Componente C

(44)

5 – Métricas – Medições

(45)

5 – Medições – Defeitos por Componente

45

Dourados – MS - 26/08/15

• Uma solução é composta por um conjunto específico de

componentes de software e hardware;

• Quando um sistema apresenta um volume considerável

de problemas, muitas vezes isso é consequência direta

de má modelagem de um ou mais componentes.

(46)

5 – Medições – Defeitos por Componente

46

Dourados – MS - 26/08/15

• Ao mesmo tempo que identificamos os componentes mais instáveis

do projeto, também localizamos os componentes que apresentam a

menor incidência de defeitos, possibilitando avaliar quais práticas

estão permitindo gerar uma codificação mais eficiente.

25% 10% 5% 15% 11% 33% Harware A Hardware B Componente A Componente B Componente C Componente D

(47)

5 – Métricas – Medições

(48)

5 – Medições – Idade dos Defeitos

48

Dourados – MS - 26/08/15

• Uma forma simples de analisar a eficiência da correção

de defeitos do software é avaliar o tempo que

determinado defeito leva para ser solucionado;

• Este indicador proporciona uma visão sobre o volume de

trabalho das diversas equipes que estão atuando

diretamente no desenvolvimento do software.

(49)

5 – Medições – Idade dos Defeitos

49

Dourados – MS - 26/08/15

• Se um volume de “erros antigos” permanece em

desenvolvimento, isso leva a acreditar que a equipe de

desenvolvimento está muito atarefada.

#1 #2 #3 #4 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4

(50)

5 – Medições – Idade dos Defeitos

50

Dourados – MS - 26/08/15

• Distribuição de defeitos por situação

#1 #2 #3 #4 #5 #6 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 Fechados Em Aberto Novos

(51)

5 – Métricas – Medições

(52)

5 – Medições – Comportamento dos Defeitos

52

Dourados – MS - 26/08/15

• A combinação de indicadores referentes à situação do

defeito pode demonstrar tendência no comportamento

do projeto em descobrir e resolver problemas;

• No início do ciclo de testes, é comum que o volume de

novos erros tenha uma tendência crescente, pois as

atividades de testes são executadas e muitos defeitos

descobertos.

(53)

5 – Medições – Comportamento dos Defeitos

53

Dourados – MS - 26/08/15

• É possível tomar decisões apenas monitorando as

informações de testes.

#1 #2 #3 #4 #5 #6 #7 #8 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4 0,45 0,5 Novos Em Aberto Fechados Axis Title

(54)

4 – Medições – Outros Indicadores

54

Dourados – MS - 26/08/15

• Média de tempo de correção de problemas;

• Custo da investigação por complexidade do sistema;

• Média de custos de um erro:

•

Custo de erro na produção;

•

Custo da investigação e diagnóstico;

•

Custo da correção;

•

Custo de teste;

(55)

5 – Métricas – Após os Resultados

55

Dourados – MS - 26/08/15

• Armazenar os resultados:

•

Tanto os dados, como os resultados, as ações tomadas, tudo que

for relevante.

•

Toda informação que contextualize a métrica ou que forneça

(56)

5 – Medições – Avaliando os Indicadores

56

Dourados – MS - 26/08/15

• É importante avaliar as medições para que os gerentes

possam gerenciar melhor os projetos;

• Interessante sempre ter um histórico de medições e

correções de defeitos;

• Cuidados com as análises (os projetos tem grandezas

diferentes).

(57)

Anexo

57

Dourados – MS - 26/08/15

Projeto de Teste

Documento que especifica os detalhes da abordagem de teste para um requisito do software ou combinação deles e

identifica os casos de testes associados [IEEE]

Projeto de Teste

Documento que especifica os detalhes da abordagem de teste para um requisito do software ou combinação deles e

identifica os casos de testes associados [IEEE]

Casos de Teste

Especificação, usualmente Formal, de um conjunto de de entradas de teste, condição

de execução, resultados esperados, identificados com o

propósito de fazer uma avaliação de algum aspecto em particular [IEEE]

Casos de Teste

Especificação, usualmente Formal, de um conjunto de de entradas de teste, condição

de execução, resultados esperados, identificados com o

propósito de fazer uma avaliação de algum aspecto em particular [IEEE]

(58)

Anexo

58

Dourados – MS - 26/08/15

Modelo de Casos de Teste – Padrão IEEE 829

(59)

É muito comum criar pelo menos um caso de teste para cada requisito e regras do sistema.

Anexo

59

(60)

Recomendado executar em todas as funcionalidades em sistemas críticos.

Anexo

60

(61)

Bibliografia

61

Dourados – MS - 26/08/15

BARTIÉ, A., Garantia da Qualidade de Software. Rio de Janeiro: Editora

Campus, 2002.

(62)

Página

62

Dourados – MS - 26/08/15