metricas de software

1

Métricas de Software

Adjailton Cabrera

[email protected]

mailto:[email protected]

2

Objetivos

Entender porque medição é importante para avaliação e garantia da qualidade de software

Entender as abordagens principais de métricas e como elas são utilizadas

Conhecer algumas métricas e suas aplicações

Entender o que é um Plano de Métricas e como escrever um

Métricas de Software 2/57

3

Motivação


Um dos objetivos básicos da Engenharia de Software é: a transformação da criação de sistemas software de uma maneira artística, indisciplinada e pouco

entendível para uma forma devidamente controlada, quantificada e previsível

“Métricas de Software” é um assunto discutido há mais de 20 anos na engenharia de software ... e no entanto não é verificada sua utilização, na prática, pela grande maioria

dos projetos de construção de software

Pesquisas realizadas em empresas de software indicam que mais da metade de grandes projetos de software se deparam com algum tipo de atraso,

excesso de custo ou prazo ou algum fracasso na execução quando implantado Falta de

controle dos projetos

4

Motivação

“Não se pode gerenciar o que não se

pode medir”.

Tom De Marco

“Se você não sabe para onde você

quer ir, qualquer caminho você pode

seguir. Se você não sabe onde você

está, um mapa não vai ajudar!”.

Roger Pressman


5

O que são métricas de software?

Uma métrica é a medição de um atributo

(propriedades ou características ) de uma

determinada entidade (produto, processo ou

recursos). Exemplos:

Tamanho do produto de software (ex: Número de Linhas

de código)

Número de pessoas necessárias para implementar um

caso de uso

Número de defeitos encontrados por fase de

desenvolvimento

Esforço para a realização de uma tarefa

Tempo para a realização de uma tarefa

Custo para a realização de uma tarefa

Grau de satisfação do cliente (ex: adequação do

produto ao propósito, conformidade do produto com a

especificação)


6

Por que medir software?

Entender e aperfeiçoar o processo de

desenvolvimento

Melhorar a gerência de projetos e o

relacionamento com clientes

Reduzir frustrações e pressões de cronograma

Gerenciar contratos de software

Indicar a qualidade de um produto de software

Avaliar a produtividade do processo

Avaliar os benefícios (em termos de

produtividade e qualidade) de novos métodos e

ferramentas de engenharia de software

Avaliar retorno de investimento


7

Por que medir software?

Identificar as melhores práticas de desenvolvimento

de software

Embasar solicitações de novas ferramentas e

treinamento

Avaliar o impacto da variação de um ou mais

atributos do produto ou do processo na qualidade

e/ou produtividade

Formar uma baseline para estimativas

Melhorar a exatidão das estimativas

Oferecer dados qualitativos e quantitativos ao

gerenciamento de desenvolvimento de software,

de forma a realizar melhorias em todo o processo

de desenvolvimento de software


8

Propriedades desejáveis de uma métrica

Facilmente calculada, entendida e testada

Passível de estudos estatísticos

Expressa em alguma unidade

Obtida o mais cedo possível no ciclo de vida

do software

Passível de automação

Repetível e independente do observador

Sugere uma estratégia de melhoria


9

Em resumo...

Uma métrica deve ser:

Válida: quantifica o que queremos medir

Confiável: produz os mesmos resultados dadas as

mesmas condições

Prática: barata, fácil de computar e fácil de interpretar

Dois contextos para medição de software

Processo: ex. produtividade

Produto: ex. qualidade


10

Categorização de Métricas

Métricas diretas (fundamentais ou básicas)

Medida realizada em termos de atributos

observados (usualmente determinada pela

contagem)

Ex.: custo, esforço, no. linhas de código, capacidade de memória, no. páginas, no.

diagramas, etc.

Métricas indiretas (derivadas)

Medidas obtidas a partir de outras métricas

Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção


11


Métricas orientadas a tamanho

São medidas diretas do tamanho dos artefatos de

software associados ao processo por meio do qual

o software é desenvolvido.

Ex.: esforço, custo, no. KLOC, no. páginas de documentação, no. erros

Métricas orientadas por função

Consiste em um método para medição de

software do ponto de vista do usuário,

determinando de forma consistente o tamanho e a

complexidade de um software.


12


Métricas de produtividade Concentram-se na saída do processo de engenharia de

software.

Ex.: no. de casos de uso/iteração.

Métricas de qualidade Oferecem uma indicação de quanto o software se

adeqüa às exigências implícitas e explícitas do cliente.

Ex.: erros/fase

Métricas técnicas Concentram-se nas características do software e não no

processo por meio do qual o software foi desenvolvido.

Ex.: complexidade lógica e grau de manutenibilidade


13

Possíveis problemas com métricas

Ex: Comparar a produtividade de engenheiros em termos de linha de código

Está sendo utilizado a mesma unidade de medida?

O que é uma linha de código válida?

O contexto considerado é o mesmo?

Todos os engenheiros são familiarizados com a linguagem

de programação?

O que se quer realmente é o tamanho do código?

E a qualidade do código?

Como o resultado será interpretado?

Produtividade média de um engenheiro?

O que se quer com o resultado?

Comparar a produtividade do processo de software?


14

Teoria da Medição

Teoria sobre métricas pode ajudar a resolver

estes problemas.


15

Relações Empíricas

Ajudam a observar as relações do tipo

verdadeiro/falso entre entidades do mundo

real

Ex. Relações empíricas entre o atributo altura

das pessoas

Binária: O Super-homem é mais alto do que papai

Noel

Unária: O Super-homem é alto

Ternária: O Super-homem é mais alto do que papai

Noel e mamãe Noel


16

Medida

Medida é uma função de mapeamento


Super-homem

Papai Noel

Mamãe Noel

2.10m

1.65m

1.50m

Atributos do mundo

real (domínio)

Um símbolo em um

conjunto com

relações

matématicas

conhecidas

17

Medição

É a atribuição de uma medida (através de

um símbolo) a um atributo do mundo real

Propósito: manipular símbolos na faixa =>

determinar conclusões sobre os atributos do

domínio

Para ser precisa, a medição deve especificar

Domínio: Será medido a largura ou altura das

pessoas?

Faixa: A medida da altura foi feita em m ou cm?

Regras de mapeamento: Será permitido medir altura considerando pessoas calçadas?


18

Escala

Representa os símbolos na faixa de uma

medida mais as manipulações permitidas

Ex. de manipulações:

Mapeamento: transformar símbolos em um

conjunto em outros símbolos em outro conjunto.

{verdadeiro, falso} {1, 0}


19

Tipos de Escala


Kelvin, tamanho, largura Diferença entre qualquer par

consecutivo de valores é

preservada. Possui 0 absoluto.

Ratio

(razão)

Celsius e Fahrenheit Diferença entre qualquer par

consecutivo de valores é

preservada

Intervalar

{simples, médio,

complexo}

Símbolos ordenados Ordinal

{verdadeiro, falso} Símbolos não ordenados Nominal

Exemplos Características Nome

20

Os Quatros papéis de Medição

Segundo Humphrey, são quatro os principais papéis de

Medições de Software:


Processos, Produtos e Serviços de Software

Entender

Avaliar Prever

Controlar

21

Os Quatros papéis de Medição

Entender

Métricas ajudam a entender o comportamento e

funcionamento de processos, produtos e serviços de

software

Avaliar

Métricas podem ser utilizadas para tomar decisões e

determinar o estabelecimento de padrões, metas e

critérios de aceitação

Controlar

Métricas podem ser utilizadas para controlar processos,

produtos e serviços de software

Prever

Métricas podem ser utilizadas para prever valores de

atributos


22

O Paradigma Goal Question Metrics (GQM)

Usado para definir o conjunto de métricas a

ser coletado

Proposto por:

Basili and Rombach’s, Goal-Question-Metrics

Paradigm, IEEE Transactions on Software

Engineering, 1988.

Baseia-se no fato de que deve existir uma

necessidade clara associada a cada

métrica


23


Inicia-se com a identificação dos interessados na

medição.

Com base nos interessados, estabelecem-se os principais objetivos da medição para a organização,

o projeto ou uma tarefa específica. Ex: reduzir

defeitos, aumentar produtividade, etc.

A partir dos objetivos, geram-se perguntas cujas respostas dirão se os objetivos foram ou não

alcançados (ex: Qual a taxa de defeito atual? Qual a

taxa de defeito após a implantação do novo

processo?)

A partir das perguntas, definem-se métricas: que dados serão necessários? Quais os formatos? Como

coletar (fórmula e processo)? Onde armazenar e como utilizar?


24



Goal 1 Goal 2

Questão 1 Questão 2 Questão 3 Questão 4

Métrica 1 Métrica 2 Métrica 3 Métrica 4 Métrica 5

25

Exemplo do uso do GQM

Objetivo: Assegurar que todos os defeitos são corrigidos antes do software ser liberado para uso.

Perguntas: Quantos defeitos temos atualmente?

Qual o status de cada defeito?

Qual a cobertura dos testes?

Métricas: Número de defeitos

Número de defeitos por status

Número de casos de testes planejados x executados

Número de requisitos testados


26

Selecionando Objetivos

Devem estar associados a um período de tempo Aumentar a produtividade em 20% no prazo de 12

meses

Facilita o acompanhamento e a tomada de ações para viabilizar objetivo pois existe um prazo!!!

Estudos indicam que objetivos muito complexos e de longo prazo podem causar impacto na motivação Objetivos menores, a curto prazo, permitem que as

pessoas visualizem o progresso e alcancem sucessos

Com o tempo e com a maturidade da organização, os objetivos devem se tornar mais complexos e mais desafiadores


27

Selecionando Métricas

Seja realista e prático

Considere o processo e o ambiente de desenvolvimento atual Não selecione métricas em que os dados sejam difíceis

de serem coletados na sua realidade

Comece com o que for possível

A equipe não deve ser muito impactada

Utilize a abordagem incremental

Com o tempo, com os benefícios, mais dados estarão disponíveis...


28

Selecionando Métricas

Objetivo: Aumentar satisfação do cliente Que atributos dos nossos produtos e serviços são mais

importantes para os nossos clientes?


Aspectos Relevantes de Produto e Serviço para Clientes

0

5

10

15

20

Qualidade Custo Prazo Visibilidade do

Progresso

Flexbilidade p/

mudanças

Aspectos Relevantes Para os Clientes

Clien

tes q

ue

Co

nsid

era

m o

Asp

ecto

# Clientes

29

O processo de medição

É um processo cíclico que envolve:

Planejar

Medir

Analisar os dados

Tomar decisões baseadas na análise

Implementar as decisões

Voltar a planejar e medir


30

Princípios de um Processo de Medição

Um processo de medição deve:

Fornecer uma base para melhoria contínua do

processo

Quantificar a qualidade e produtividade

Estar integrado com o ciclo de vida de desenvolvimento

Medir o impacto de vários métodos, ferramentas, e

técnicas de melhorias


31


Medições devem ser usadas para medir

processos, não pessoas

O processo de medição deve ter objetivos

claros e bem-definidos

O processo de medição deve ser fortemente

acoplado com o processo de gerência da

qualidade e integrado dentro de planos e

orçamentos


32


O processo de coleta de dados deve ser

simples, e ferramentas automáticas para

extração de dados devem ser usadas

O processo de medição é contínuo e sujeito

a melhoria


33

Características de um programa efetivo de medição

Escolha um conjunto adequado de métricas

Relacione as métricas ao processo de tomada de decisão (suportado pela alta administração)

Avalie processos e não pessoas (explique os objetivos da medição)

Não use as métricas para punir

Envolva várias pessoas na seleção e formulação das métricas

Estabeleça alta prioridade (recursos, ferramentas, etc.)

Integre o programa ao desenvolvimento de software

Alinhe aos objetivos de negócio

Padronize e documente

Compartilhe as métricas obtidas

Institucionalize como parte da cultura da organização

Integre com o programa de melhorias (ilustre o progresso e as melhorias obtidos a partir do programa)

Ofereça planos de ação


34

Plano de Métricas

Para cada objetivo técnico o plano contém

informação sobre:

POR QUE as métricas satisfazem o objetivo

QUE métricas serão coletadas, como elas serão

definidas, e como serão analisadas

QUEM fará a coleta, quem fará a análise, e quem

verá os resultados

COMO será feito: que ferramentas, técnicas e

práticas serão usadas para apoiar a coleta e

análise das métricas

QUANDO no processo e com que frequência as

métricas serão coletadas e analisadas

ONDE os dados serão armazenados


35

Especificando as Medições – Definições

Operacionais Definir e documentar para cada métrica :

Objetivos

Público alvo da métrica

Quem precisa da informação?

Quem irá usar as informações fornecidas pela métrica?

Uma métrica útil sempre tem um cliente

Procedimento de coleta e armazenamento

Quando o dado deve ser coletado? Periodicamente ou por eventos?

Quem é o responsável pela coleta e armazenamento?

Como o dado deve ser coletado? A partir de que ferramentas e produtos de trabalho do projeto / organização?

Onde ele será armazenado? Quando o dado deve ser armazenado?

Avaliar métricas que podem acarretar em muito esforço e pouco valor

Buscar automatizar a coleta dos dados sempre que possível

Ferramentas para controle de tempo, bugtracking, helpdesk, controle de versão, gestão de requisitos


36

Especificando as Medições – Definições

Operacionais Procedimentos de Análise

Necessários para

Entendimento da métrica

Avaliação (critério para tomada de decisão)

A análise dos dados deve endereçar os objetivos das medições

Seleção dos métodos e ferramentas de análise:

Como a métrica será visualmente apresentada?

Gráficos de barras, linhas, colunas, pizza, histogramas, diagramas de scatter, tabelas...

Ferramentas de Ishikawa

A equipe de desenvolvimento deve ser envolvida sempre que necessário

Para métricas de controle:

Estabelecimento de limites de controle

Estabelecimento de thresholds (limiar)

Padrões ou requisitos de mercado de performance

Média de mercado para custo da baixa qualidade = 4%

Temos que correr atrás dessa meta!!!


37

Após todo o planejamento...


Executar as atividades com base no planejamento realizado

Utilizar o plano de medição como base!!

Tomar ações com base nos resultados

Acompanhar os itens de ação

Comunicar os resultados ao público alvo de cada métrica

Ajustar o processo com melhorias a partir dos resultados de sua execução:

Inicialmente vai ser difícil definir todos esses procedimentos da melhor forma

Eles devem ser melhorados a medida em que o processo é executado

Novos objetivos e métricas surgem...

Melhores forma de coleta são identificadas

As orientações para realização da análise vão sendo refinadas a medida

que conhecemos melhor os dados

38

Após todo o planejamento... (2)

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 alguma informação adicional


Dados históricos não são apenas números

39

Cuidado com...

Elaborar um política de controle de acesso

Apenas pessoas autorizadas devem ter acesso a

certos tipos de dados

Evitar o uso indevido dos dados

Avaliação de pessoas

Comparação entre projetos, grupos ou áreas da

empresa de forma indevida

Publicação de informações que foram fornecidas

de forma confidencial


Atenção: O uso indevido dos dados impacta fortemente e negativamente um programa de medições

40

Estimativas de Software


41

Por que é tão difícil estimar?

É difícil conhecer se é possível desenvolver o

produto desejado pelo

cliente antes de

conhecer os detalhes do projeto.


42

Por que é tão difícil estimar?

Desenvolvimento é um processo gradual de

refinamento

Incerteza da natureza do produto contribui para a

incerteza da estimativa

Requisitos e escopo mudam

Defeitos são encontrados e demandam retrabalho

Produtividade varia


43

O Processo de Estimativas

1. Estimar o tamanho do produto

2. Estimar o esforço

3. Estimar o prazo

4. Fornecer estimativas dentro de uma faixa

permitida e refinar essa faixa à medida que

o projeto progride


44

Tipos de Estimativas

Tamanho

Quantidade de software a ser produzida

Ex. no. linhas de código, no. pontos de função, n.o

de requisitos, pontos de casos de uso

Esforço

Derivado da estimativa de tamanho

Ex. dividindo a estimativa de tamanho por

produtividade produz-se o esforço


45

Tipos de Estimativas

Prazo

Geralmente são dirigidos a datas fornecidas pelo

Cliente

Qualidade

Medidas de resultados

Ex. defeitos por fase, esforço de mudanças


46

Evolução Histórica & Tendências


47

A Década de 70: Medição do Código Fonte

Caracterizada por

Métricas para código fonte propostas por Halstead

(ex: número de operadores distintos, número de

operandos distintos, etc.)

Métricas de Complexidade Ciclomática de McCabe

Medida do número de caminhos linearmente

independentes num módulo

Influenciada por:

Aceitação crescente da programação estruturada

Primeiras noções de complexidade cognitiva


48

A Década de 80: Medição no início do ciclo de vida

Estimativas de medição: esforço e custo

Medidas na etapa de projeto

Medidas na etapa de especificação


49

A Década de 90: Um perspectiva mais ampla

Surgimento de relatórios sobre programas de

métricas aplicados em empresas

Benchmarking

Impacto do modelo CMM

Surgimento de ferramentas para medição

Surgimento de uma teoria de medição como

um framework unificado

Surgimento de padrões internacionais de

medição de software (ex: Análise de pontos

de função)


50

Tendências: procura por métricas mais

específicas

Medidas que:

capturem a complexidade cognitiva

capturem a complexidade estrutural

capturem a complexidade funcional

sejam independentes de linguagem

possam ser extraídas nas etapas iniciais do ciclo de

vida


51

ISBSG

International Software Benchmarking

Standards Group

Organização sem fins lucrativos

Mantém um banco de dados de métricas de

projetos de software para auxiliar na melhoria

gerência de recursos de TI


52

Métricas de Software: Resumo

As atividades de medição devem ser

guiadas por objetivos

Plano de Métricas detalham como criar

programas de medição para atender a

objetivos técnicos específicos

Tendências recentes: evolução de métricas

ou modelos específicos para amplos

programas organizacionais de métricas


53

Principais Barreiras


Falta de comprometimento da alta gerência

Medir custa caro

Os maiores benefícios vêm a longo prazo

Má utilização das métricas

Grande mudança cultural necessária

Dificuldade de estabelecer medições apropriadas e úteis

Interpretações dos dados realizadas de forma incorreta

Obter o comprometimento de todos os envolvidos e impactados

Estabelecer um programa de medições é fácil, o difícil é manter!!

54

Mas podemos contornar ...


Foco desde os estágios iniciais da melhoria de processo

Medição faz parte do TODO

Começar Pequeno

Selecionar um conjunto coerente

É importante definir cada detalhe da métrica

Descartar o que não estiver sendo útil

Fornecer as informações corretas, para as pessoas certas

“Agregar valor”, ao invés de gerar apenas dados

55

Mas podemos contornar ...


Incentivar a equipe de desenvolvimento a fazer uso das métricas

Envolvimento de todos os impactados

Estabelecer as expectativas

Educação e Treinamento

Ganhar Confiança

Adotar uma Abordagem Evolucionária

Compreender que a Adoção leva Tempo

56

Referências

Fenton NE and Pfleeger SL, ‘Software Metrics:

A Rigorous & Practical Approach’ (2nd Ed.),

PWS, 1998.

www.csr.city.ac.uk/people/norman.fenton

www.softwaremetrics.com

IFPUG International Function Point Users

Group: www.ifpug.org

Total Metrics: www.totalmetrics.com


57

Referências

Chou, Tim. The Hidden Cost of Software. Maio 29, 2003. Url: http://itmanagement.earthweb.com/entdev/print.php/2214031.

Negulescu, Radu. Software Engineering Practice – Software Metrics II. McGill University, 2002.

Métricas de Software. Url: http://www.internext.com.br/mssa/medidas.html

Haufe, Maria Isabel. Produtividade no Desenvolvimento de Software. Url: http://www.inf.ufgrs.br/pos/SemanaAcademica/Semana99/mariaisabel/mariaisabel.html

Métricas e Estimativas de Software – O início de um rally de regularidade. Url: http://www.apinfo.com/artigo44.htm

Pressman, Roger. S. Engenharia de Software. Makron Books, 1995.


metricas de software

Documents