Métricas de Software

Através da MEDIÇÃO:

pode-se obter um entendimento para realizar uma avaliação

objetiva.

Medição pode ser aplicada:

Processo de software, com o objetivo de melhorá-lo de

forma contínua, visão estratégica da organização.

Projeto de software, para auxiliar na estimativa, no

controle de qualidade, na avaliação de produtividade e no

controle de projeto.

Na gestão de projetos há uma preocupação com as métricas de

produtividade e de qualidade, dentre as quais:

- Medidas de saída do desenvolvimento do software: função de

esforço e tempo aplicado, aptidão para uso dos produtos de trabalho.

Para o planejamento e estimativas, é realizado alguns

questionamento:

Qual foi a produtividade em desenvolvimento em projetos

anteriores

Qual a qualidade do software produzido?

Como dados anteriores podem ser extrapolados até o presente?

Como isso pode ajudar a planejar e estimar com mais

precisão?

Há quatro razões para medir software:

Caracterizar

o Caracterizamos para ter entendimento dos processos,

produtos e recursos.

o Estabelecer marcos básicos

o Prever ou aperfeiçoar.

Avaliar

o Avaliamos para determinar o status com referência aos

planos

o Sensores para avaliar quanto os projetos e processos

estão fora de controle.

o Verificar o modo para trazer os projetos de volta ao

controle

o Verificar o cumprimento de metas de qualidade

o Verificar os impactos de melhoramentos de tecnologias

Prever

o Para poder planejar

o Observação de todo o processo e do produto como forma

de utilizar valores observados para prever outros

o Ajudam a extrapolar tendências, onde as estimativas de

custos, prazos e qualidade possam ser atualizadas.

Aperfeiçoar

o Coletar informações quantitativas para ajudar a

identificar bloqueios, causas fundamentais, ineficiências.

o Melhorar a qualidade do produto e o desempenho do

processo

MEDIDAS, MÉTRICAS E INDICADORES

Medida: uma indicação quantitativa da extensão, quantidade,

dimensão, capacidade ou tamanho do produto ou do processo.

Medição: ato de determinação de uma medida.

Indicador: É uma métrica ou a combinação delas, que fornece

compreensão do processo de software, de um projeto ou do produto

Um Eng. Software realiza medidas e desenvolve métricas de modo a

obter indicadores.

Os indicadores permitem:

Avaliar o status de um projeto em andamento

Acompanhar os riscos em potencial

Descobrir áreas problemas antes que elas se tornem críticas

Ajustar fluxo de trabalhos ou tarefas

Avaliar a capacidade da equipe de trabalhar com qualidade

Através de indicadores se consegue ajustar o processo, o projeto ou

o produto.

MÉTRICAS DE PROCESSO E DE PROJETO

Normalmente, tem-se dificuldade em concordar no que medir e

como avaliar o que se mediu.

Métricas de processo são coletadas ao longo de todos os projetos e

durante longos períodos.

Segundo Humphrey, o aperfeiçoamento do processo de software

pode e deve começar no nível individual. Pode-se utilizar

PSP(Personal Software Process).

As métricas podem ser subdivididas em Privadas e Públicas:

Privadas: Se referem ao escopo da equipe do projeto de software.

Exemplos: Defeitos para funções importantes do SW, erros

encontrados durante revisões técnicas formais.

Públicas: Geralmente assimilam informações que anteriormente

eram privadas de uma equipe. Proporções de defeitos de projeto,

esforço, tempo transcorrido e dados relacionados são coletados e

avaliados tentando descobrir indicadores.

As métricas devem sempre fornecer benefícios para a organização

com o intuito de aperfeiçoar o seu nível de maturidade. Segue uma

“etiqueta de métricas”:

Use bom senso e sensibilidade empresarial quando interpretar

dados de métricas

Forneça realimentação aos indivíduos que coletam medidas e

métricas

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

Trabalhe com profissionais e indivíduos para estabelecerem

metas claras e métricas que devem ser usadas para alcança-las.

Nunca use métricas para ameaçar indivíduos

Dados de métricas que indicam uma área problemática não

devem ser considerados negativos.

À medida que uma organização usa métrica, os indicadores simples

vão dando lugar a uma abordagem mais complexa (SSPI- Melhoria

Estatística do processo de Software).

SSPI utiliza uma análise de falhas baseada nos erros e defeitos.

A análise de falhas funciona da seguinte maneira:

Todos os erros e defeitos são categorizados por origem(falha

de especificação, falha de lógica, não atendimento a padrões)

O custo para corrigir cada erro e defeito é registrado.

A quantidade de erros e defeitos de cada categoria é contada e

ordenada de forma decrescente.

O custo total de erros e defeitos de cada categoria é calculado.

Os dados resultantes são contabilizados para se obter a

categoria que produzem mais custos para a organização.

São desenvolvidos planos de ação para modificar o processo,

com o objetivo de eliminar ( ou reduzir a freqüência das)

classes de erros e defeitos mais dispendiosas.

MÉTRICAS DE PROCESSO X MÉTRICAS DE PROJETO

M. Processo – finalidade estratégica

M. Projeto – finalidade tática (usados por um Gerente ou equipe

para adaptar o fluxo de trabalho e as atividades técnicas do projeto).

Primeira aplicação das M. Projeto é nas estimativas do projeto.

- Outros projetos são usados como parâmetros

- Erros descobertos durante cada fase da Eng. Software são

registrados

- A taxa de produção é medida

OBJETIVOS DAS M. PROJETO:

- Minimizar o cronograma, fazendo ajustes para evitar

atrasos e problemas

- Avaliar a qualidade do produto durante a sua evolução

Cada projeto deve medir as Entradas(recursos, pessoal, ambiente),

as Saídas(medida dos produtos intermediários durante o processo de

E.S.) e os resultados(indicam a efetividade dos produtos finais)

MEDIÇÃO DE SOFTWARE

Duas categorias de medições:

Medidas diretas (comprimento do parafuso) e medidas

indiretas(qualidade dos parafusos produzidos).

Relação ao Software:

M. Diretas - linhas de código(LOC) produzidas, velocidade de

execução, defeitos relatados.

M.Indiretas: funcionalidade, qualidade, complexidade,

confiabilidade, manutenibilidade.

Exemplo: A equipe A encontrou 342 erros durante um processo de

software, antes da entrega. A equipe B encontrou 184 erros. Sendo

as outras coisas todas iguais, qual equipe é mais efetiva na

descoberta de erros ao longo do período?

Não sabemos o tamanho nem a complexidade dos projetos....

MÉTRICAS ORIENTADAS A TAMANHO

Consideram o tamanho do software produzido. Referem-se a todas

as atividades da Engenharia(análise, projeto, código , teste).

Valor de normalização: Linhas de código

Cada projeto pode ter as seguintes métricas:

Erros por KLOC

Defeitos por KLOC

$ por LOC

Paginas de documentação por KLOC

Erros por pessoa/mês

LOC por pessoa/mês

$ por pagina de documentação

Métricas orientadas a Tamanho

Projeto LOC Esforço $(000) Pág.Doc Erros Defeitos Pessoas

Alfa 12.100 24 168 365 134 29 3

Beta 27.200 62 440 1.224 321 86 5

Gama 20.200 43 314 1.050 256 64 6

... ... ... ... ... ... ... ...

Não é muito utilizada na estimativa, pois requer um nível de

detalhes difícil de se alcançar.

MÉTRICAS ORIENTADAS POR FUNÇÃO

Usam a funcionalidade como fator de normalização. A medida é

PONTO por FUNÇÃO.

PF – originados usando uma relação empírica baseada em medidas

de contagem do domínio de aplicação do software e avaliação da

complexidade do software

Os valores dos domínios da informação são definidos da seguinte

maneira:

Quantidade de entrada dos usuários

o Cada entrada é contada

Quantidade de saídas do usuário

o Relatórios, telas, mensagens de erros, etc

Numero de consultas do usuário

o É uma entrada on-line, resulta na geração de uma

resposta imediata sob a forma de uma saída on-line

Quantidade de arquivos

o Cada arquivo mestre lógico é contado

Quantidade de interfaces externas

o Toda interface que são usadas para transmitir

informações a outros sistemas

FP = total de contagem X [0,65 + 0,01X∑(Fi)]

Fi – são os valores de ajuste da complexidade, baseados nas

seguintes respostas:

1 O sistema requer salvamento(backup) e recuperação(recovery)?

2 Comunicações de dados são necessárias?

3 Há funções de processamento distribuído?

4 O desempenho é crítico?

5 O sistema vai ser executado em um sistema operacional existente

e muito utilizado?

6 O sistema requer entrada de dados on-line?

7 A Entrada de dados on-line exige que a transação de entrada seja

construída através de varias telas ou oeprações?

8 Os arquivos mestre são atualizados on-line

9 As entradas, saídas arquivos ou consultas ssãocomplexas?

10O processamento interno é complexo?

11O código é projetado para ser reusado?

12A conversão e a instalação estão incluídas no projeto?

13O sistema está projetado para instalações múltiplas em diferentes

organizações?

14A aplicação está projetada para facilitar modificações e para

facilitar o uso pelo usuário?

Cada uma destas questões são respondidas usando uma escala que

varia entre 0 (não aplicável ou não importante) a 5 (absolutamente

essencial).

Uma vez calculados os PF, são usados para definir medidas de

produtividade, tais como:

Erros por FP

Defeitos por FP

$ por FP

Paginas de documentação por FP

FP por pessoa-mês

Métricas de PF estendidas

Pontos por características

o Complexidade algorítmica é elevada. Aplicações de

software em tempo real, controle de processos, softwares

embutidos.

Pontos por função 3D

o Enfatizam a utilização das capacidades de dimensão e

controle

o Enfocam as transições de estados, ex. telefone auto

discagem

MEDIÇÃO DA QUALIDADE DE SOFTWARE

Segundo Gilb estas são as definições e medidas de qualidade de um

software:

Correção

o Grau que o software desempenha sua necessária função.

o Defeitos são contados durante um período padrão, 1 ano

Manutenibilidade

o Facilidade com que um programa pode ser corrigido, se

um erro for encontrado

o Adaptado, se o ambiente for alterado

o Aperfeiçoado, se o cliente deseja modificação

Integridade

o Capacidade do sistema reagir a ataques, tanto acidentais

como intencionais

o Podem afetar tanto programas, quanto dados e

documentos

o Pode ser medida através:

MTTC(Tempo médio para modificação)

Analisar o pedido

Projetar uma modificação

Implementar, testar e distribuir

Utilização

o Uso amigável

o Pode ser medida de acordo com:

aptidão física/intelectual para lidar com o sistema

tempo necessário para se tornar eficiente no uso do

sistema

avaliação subjetiva das atitudes dos usuários

Uma métrica de qualidade é a eficiência na remoção dos defeitos

(DRE)

Para o projeto todo a DRE é definida como:

DRE=E/(E+D)

E – quantidade de erros encontrados

D – Quantidade de defeitos

O valor ideal de DRE é 1, ou seja, nenhum defeito é encontrado no

software.

As atividade de DRE devem ser realizadas ao longo de cada etapa da

Eng. Software

MÉTRICAS PARA UMA PEQUENA ORGANIZAÇÃO

Tempo (horas ou dias) transcorridos entre o momento em que

o pedido foi feito até que a avaliação seja completada

Esforço (pessoas/horas) para realizar a avaliação

Esforço necessário para fazer a modificação(pessoas/horas)

Tempo necessário

Erros descobertos durante o trabalho

Defeitos descobertos.

Coletar dados, calcular e analisar métricas são passos que devem ser

implementados para iniciar um programa de métricas.