Princípios de Medição. Triângulo de Qualidade de McCall. Métricas de Produtos de Software cap.15, 22 e 23. Medida, Métricas e Indicadores

(1)

1

Métricas de Produtos de Software

cap.15, 22 e 23

02561-5 Engenharia de Software Profa. Rosângela

Aula de 14/09/2006

2

Triângulo de Qualidade de McCall

M a i ta in a b ility M a ina b ility

Flexibility

Testability

T

R

A

N

S

I

Ç

ÃO DO PRODUTO

T

R

A

N

S

REVIS

PRODU

PRODUTO

REVI

SÃO DO

Manutenibilidade Flexibilidade Testabilidade Portabilidade Reutilização Interoperabilidade Correção Confiabilidade Utilização Integridade Eficiência

OPERA

Ç

ÃO DO PRODUTO

3

Medida, Métricas e Indicadores

• Uma

medida

fornece uma indicação quantitativa da

extensão, quantia, dimensão, capacidade ou tamanho

de algum atributo de um produto ou processo

• O glossário do IEEE define uma

métrica

como “uma

medida quantitativa do grau em que um sistema,

componente ou processo possui um determinado

atributo.”

• Um

indicador

é uma métrica ou combinação de métricas

que fornece profundidade (insight) em um processo de

software, um projeto de software ou produto em si.

4

Princípios de Medição

• O objetivo de medição deve ser estabelecido antes de come;ar a coletar os dados;

• Cada métrica técnica deve ser definida de maneira não ambígua;

• Métricas devem ser derivadas com base em uma teoria que é válida para o domínio de aplicação (por ex, métricas para projeto devem formuladas considerando conceitos e princípios básicos de projeto e tentar fornecer uma indicação da presença de um atributo que é considerado desejável);

• Métricas devem ser construídas para melhor acomodar produtos e processos específicos [BAS84].

(2)

5

Processo de Medição

• Formulação.A derivação de medidas e métricas de software adequadas para a representação do software que estão sendo considerado.

• Coleta.Um mecanismo usado para acumular dados necessários para derivar as métricas formuladas.

• Análise.Cálculo de métricas e aplicação de ferramentas matemáticas.

• Interpretação.Avaliação de métricas resulta em um esforço para ganhar profundidade na visão de qualidade de representação. • Realimentação.Recomendações derivadas da interpretação das

métricas de produtos transmitidas à equipe de software.

6

Medições de Software Orientadas a Objetivo

• O Paradigma Objetivo/Questões/Métricas (Goal/Question/Metric - GQM)

– (1) estabelecer um objetivoexplícito de medição que seja específico da atividade de processo ou característico do produto que dee ser avaliado

– (2) definir um conjunto de questõesque deve ser respondido a fim de alcançar o objetivo e

– (3) identificarmétricasbem formuladas que ajudam a responder essas questões.

• Gabarito de definição de objetivo (goal definition template) – Análise{o nome da atividade ou atributo a ser medido} – com a finalidade de{o objetivo global da análise} – com relação a {o tópico da atividade ou atributo que é

considerado}

– do ponto de vista de{o pessoal que tem interesse na medição}

– no contexto de{o ambiente no qual a medida tem lugar}.

Exemplo de GQM

Analise a arquitetura do software do CasaSegura com a finalidade de

avaliar componentes arquiteturais com respeito à habilidade de tornar o CasaSegura mais extensível do ponto de vista dos engenheiros de software que estão realizando o trabalho no

contexto de aperfeiçoamento do produto durante os próximos três

anos.

Q1. Os componentes arquiteturais são caracterizados de um modo que compartimentalize a função e dados relacionados?

Q2. É a complexidade de cada componente dentro dos limites que vai facilitar a modificação e extensão?

Cada uma dessas questões deve ser respondida quantitativamente, usando uma ou mais medidas e métricas.

Métricas de Análise

• métricas baseadas em função :

usam

ponto por função como um fator de

normalização ou como uma medida de

“tamanho” da especificação

• métricas de especificação : usada como

uma indicação da qualidade pela medição

do número de requisitos por tipo

(3)

9

Métricas Baseadas em Função

• A

métrica ponto por função (FP),

proposta por

Albrecht [ALB79], pode ser usada efetivamente

como um meio para medir a funcionalidade

entregue por um sistema.

• Pontos por função são derivados usando uma

relação empírica baseada em medidas de

contagem (direta) do domínio de informação do

software e avaliação da complexidade do

software

10

Métricas Orientadas à Função

• 3 passos

1. Completar a tabela

Valor do Domínio

da informação Contagem simples média complexa Fator de Ponderação

Entradas externas (Eis ) Saídas externas (EOs) Consultas Externas (EQs) Arquivos Lógicos Internos (ILFs) Arquivos de Interface Externa (EIFs)

3 4 6 4 5 7 3 4 6 7 10 15 5 7 10 = = = = = Contagem total X X X X X 11

Sendo:

• Valores do domínio de informação são definidos

do seguinte modo:

– Número de arquivos de interface externa

(EIFs):

agrupamento lógico de dados que

reside externamente à aplicação, mas

fornece dados que podem ser úteis para a

aplicação.

12

RLR DER 1-4 5-15 16 ou mais

0 ou 1 simples simples média

2 simples média complexa

3 ou mais média complexa complexa

DER: Dado Elementar Referenciado (atributo) RLR: Registro Lógico Referenciado (chave)

Número de entradas externas (EIs): entradas de usuário que forneçam dados orientados a aplicações distintas. Diferenciar de consultas.

(4)

13

Número de saídas externas (EOs): saídas de usuário que forneçam informações orientadas a aplicações (relatórios, telas, mensagens de erro). Itens de dados individuais dentro de um relatório não são contados.

RLR DER 1-5 6-19 20 ou mais

0 ou 1 simples simples média

2 ou 3 simples média complexa

4 ou mais média complexa complexa

14

Consultas:entrada on-line que resulta na geração de alguma resposta imediata do software sob a forma de saída on-line.

RLR DER 1-5 6-19 20 ou mais

0 ou 1 simples simples média

2 ou 3 simples média complexa

4 ou mais média complexa complexa

Contar a complexidade da entrada e a complexidade da saída relacionada à consulta, separadamente.

Vale a maior complexidade das duas.

RLR DER 1-19 20-50 50 ou mais

1 simples simples média

2-5 simples média complexa

6ou mais média complexa complexa

Número de arquivos lógicos internos (ILFs): cada arquivo lógico dentro da fronteira da aplicação e mantido por entidades externas

Passo 2) Responder as questões 1-14

considerando a escala de 0 a 5.

influência 0 1 2 3 4 5

nenhuma pouca moderada média significante essencial 1. O sistema exige backup e recuperação

confiáveis?

2. É requerida comunicação de dados? 3. Existem funções de processamento

distribuído? 4. O desempenho é crítico?

5. O sistema funcionará num sistema operacional existente e intensamente utilizado? 6. São requeridas entrada de dados on-line? 7. As entradas on-line requerem que as

transações de entrada sejam construídas com várias telas e operações?

8. Os arquivos são atualizados on-line? 9. Entradas, saídas, arquivos e consultas são

complexos?

10. O processamento interno é complexo? 11. O código é projetado para ser reusával? 12. A conversão e a instalação estão incuídas

no projeto?

13. O sistema é projetado para múltiplas instalações em diferentes organizações? 14. A aplicação é projetada de forma a facilitar

(5)

17

Passo 3- Ajustar os Pontos por

Função

• De acordo com a complexidade do sistema usando a

fórmula

PF = Contagem-Total x 0,65 + 0,01 x (F

i

)

14 i = 1 Fi= valores de ajuste da complexidade

das perguntas 1-14 MÉTRICAS DERIVADAS PRODUTIVIDADE = QUALIDADE = CUSTO = DOCUMENTAÇÃO = PF / pessoas-mês erros / PF $ / PF pags.docum. / PF 18

EXEMPLO

FUNÇÃO INTERAÇÃO COM O USUÁRIO DO CASASEGURA USUÁRIO SENHA Consulta sobre zona Consulta sobre sensor Botão de Pânico Ativar/Desativar SENSORES Teste do Sensor Estabelecimento de zona USUÁRIO Estado do sensor Mensagens SUBSISTEMA DE MONITORAÇÃO E RESPOSTA Ativar/Desativar Alert_{a do} Alar_me

Dados de configuração do sistema Senha, Sensores, ... LEGENDA: ENTRADAS ARQUIVO CONSULTAS SAÍDAS EXTERNAS ARQUIVOS DE INTERFACE EXTERNA 19

Cálculo dos Pontos por Função

Valor do Domínio

da informação Contagem simples média complexa Fator de Ponderação

Entradas externas (Eis ) Saídas externas (EOs) Consultas Externas (EQs) Arquivos Lógicos Internos (ILFs) Arquivos de Interface Externa (EIFs)

3 4 6 4 5 7 3 4 6 7 10 15 5 7 10 = = = = = Contagem total X X X X X 3 2 2 1 4 9 8 6 7 20 50 FP = contagem total x [0,65 + 0,01 x (Fi)] FP = 50 x [0,65 + (0,01 x 46)] = 56 46 = produto moderadamente complexo

FP traduz-se em 60 linhas de código ₂₀

Por que optar por PF?

• Independente da linguagem de programação

• Facilmente usada para contar características

que são determinadas previamente no processo

de software

• Não “penaliza” as implementações criativas

(curtas) que usam poucas LOC que outras

versões mais pesadas

• É mais fácil para medir o impacto dos

componentes reusáveis

(6)

21

Métricas Orientadas à Função

• erros por PF (milhares de linhas de

código)

• defeitos per PF

• $ por PF

• Páginas de documentação por PF

• PF por pessoa-mês

22

Métricas Orientadas à Operação

• Tamanho médio da operação

• Complexidade da operação

• Número médio de parâmetros por

operação

Propostas

por

Lorenz e Kidd [LOR94]:

Uma Boa Gestão de Medição

medi

ç

ão

O

que

usamos

como

uma

base?

•

• tamanho

tamanho

?

•

• fun

fun

ç

ão

?

m

é

tricas

de

projeto

m

é

tricas

de

processo

produto

m

é

tricas

produto

Por que Medir?

• Para avaliar o estado de um projeto em

andamento

• Acompanhar riscos potenciais

• Descobrir áreas-problema antes que elas

se tornem “críticas,”

• Ajustar fluxo de trabalho ou tarefas,

• Avaliar a capacidade da equipe de projeto

de controlar a qualidade dos produtos do

trabalho de software.

(7)

25

Métricas de Processo

• Mede-se a eficácia de um processo de software indiretamente.

– Isto é, originamos um conjunto de métricas baseadas nas saídas que podem ser derivadas do processo

– As saídas incluem:

• Medidas descobertas antes da entrega do software • Defeitos entregues aos usuários finais e por eles relatados • Produtos de trabalho entregues (produtividade) • Esforço humano despendido

• Tempo gasto

• Cumprimento de cronograma • Outras medidas.

• Também originamos métricas do processo medindo as características de tarefas específicas de engenharia de software.

26

Diretrizes para Métricas de Processo

• Use o bom senso e sensibilidade organizacional quando interpretar dados de métricas.

• Forneça regularmente feedback aos indivíduos e equipes que coletam medidas e métricas.

• Não use métricas para avaliar indivíduos.

• Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las.

• Nunca use métricas para ameaçar indivíduos ou equipes.

• Dados de métricas que indicam uma área problemática não devem ser considerados “negativos”. Esses dados são meramente um indicador para melhoria do processo.

• Não fique obcecado com uma única métrica em detrimento de outras importantes.

27

Melhoria de Processo de Software

MPS

Modelo de Processo Objetivos de melhoria Métricas de Processo Recomendações de melhorias de processo 28

Métricas de Processo

• Relacionadas à qualidade

– Enfoque na qualidade dos produtos de trabalhos e artefatos entregues

• Relativas à produtividade

– Produção de produtos de trabalho relacionados ao esforço despendido

• Dados estatísticos de GQS (SQA)

– erros de categorização & análise

• Remoção eficiente de defeitos

– propagação de erros de atividade para atividade do processo

• Reuso de dados

– O número de componentes produzidos e seu grau de reusabilidade

(8)

29

Métricas de Projeto

• Usadas para minimizar o cronograma de desenvolvimento fazendo os ajustes necessários para evitar atrasos, problemas e riscos em potencial.

• Usado para avaliar a qualidade do produto durante sua evolução e, quando necessário, modificar a abordagem técnica para aperfeíçoar a qualidade.

• Todo projeto deve medir:

– Entradas — medição dos recursos (e.g., pessoal,ferramentas) necessárias para fazer o trabalho.

– Saídas — medição dos artefatos ou produtos de trabalhos criados durante o processo de engenharia de software.

– Resultados — medição que indica a efetividade dos artefatos.

30

Métricas Típicas de Projeto

• Esforço/tempo por tarefa de engenharia de software • Erros descobertos na hora de revisão

• Minimizar cronogramas e avaliar a qualidade do produtos

• Modificações (número) e suas características • Distribuição de esforço por tarefas de engenharia de

software

Diretrizes de Métricas

• Use o bom senso e sensibilidade organizacional quando interpretar dados de métricas.

• Forneça regularmente feedback aos indivíduos e equipes que coletam medidas e métricas.

• Não use métricas para avaliar indivíduos.

• Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las.

• Nunca use métricas para ameaçar indivíduos ou equipes.

• Dados de métricas que indicam uma área problemática não devem ser considerados “negativos”. Esses dados são meramente um indicador para melhoria do processo.

• Não fique obcecado com uma única métrica em detrimento de outras importantes.

Métricas para Projeto OO - I

• Whitmire [WHI97] descreve 9 características distintas e mesuráveis

de um projeto OO: – Tamanho

• Tamanho é definido em termos de 4 visões: população, volume, comprimento e funcionalidade

– Complexidade

• Como as classes de um projeto OO estão inter-relacionadas umas com as outras

– Acoplamento

• As conexões físicas entre os elementos de um projeto OO – Suficiência

• “o grau das características exigidas de uma abstração ou o grau das caracterisiticas que um componente de projeto possiu na sua abstração, do ponto de vista da aplicação corrente.”

– Completeza

• Uma implicação indireta sobre o grau em que a abstração ou o componente de projeto pode ser reusado

(9)

33

Métricas para Projeto OO - II

– Coesão

• O grau em que todas as operações trabalham juntas para atingir um propósito único, bem definido.

– Primitividade

• Aplica-se tanto a operações quanto a classes, o grau em que uma operação é atômica

– Similaridade

• O grau em que duas ou mais classes são semelhantes em termos de sua estrutura, função, comportamento e finalidade

– Volatilidade

• Mede a probabilidade de que uma modificação venha a ocorrer

34

Métricas Orientadas a Tamanho

• erros por KLOC (milhares de linhas de código)

• defeitos por KLOC

• $ por LOC

• Páginas de documentação por KLOC

• erros por pessoa-mês

• Erros por hora de revisão

• LOC por pessoa-mês

• $ por página de documentação

35

Métricas Orientadas a Objetos

• Número de

cenários

(casos de uso)

• Número de

classes apoiadas

(necessárias para

implementar o sistema nas não são imediatamente

relacionadas ao domínio do problema)

• Número médio de

classes apoiadas por classe chave

referências (classe de análise)

• Número de

subsistemas

(uma agregação de classes

referências que é visível ao usuário final de um sistema)

36

Medição de Qualidade

• Correção

— o grau em que um programa opera

de acordo a sua especificação

• Manutenabilidade

— o grau de facilidade que

um programa é modificado

• Integridade

— o grau em que um programa é

impenetrável a ataques externos

• Usabilidade

— o grau em que um programa [e

(10)

37

Métricas para Pequenas Organizações

• tempo (horas ou dias) transcorrido entre o momento em que o pedido é feito até que a avaliação seja completada, tfila.

• esforço (pessoa-hora) para realizar avaliação, Waval.

• tempo (horas ou dias) transcorrido desde o término da avaliação até a atribuição da ordem de modificação ao pessoal, taval.

• esforço (pessoas-hora) necessário para fazer a modificação,

Wmodificação.

• tempo necessário (horas ou dias) para fazer a modificação,

tmodificação.

• erros descobertos durante o trabalho para fazer a modificação,

Emoficiação.

• Defeitos descobertos depois que a modificação é entregue ao cliente, Dmodificaçãp.