MÉTRICAS DE SOFTWARES

Susiléa Abreu dos Santos

1
Roteiro
 Motivação
 Conceito de métricas
 Métricas x Gerenciamento de Projetos
 Categorização de Métricas
 Principais barreiras
 Métricas para software
 APF

2
Motivação
 Boa parte dos fracassos no que diz
respeito aos projetos de software deve-
se, principalmente, a problemas de
administração ou gerenciamento do
desenvolvimento de software.

3
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

4
Conceitos
 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)

5
Métricas x Gerenciamento de Projetos
As métricas são importantes para o gerenciamento de projetos
para melhorar a qualidade das estimativas e desta forma
conduzir de forma mais realística o controle dos atributos do
projeto.
A medida de um software em si tem pouco valor analisado de
forma isolada. Ele passa a ser relevante quando serve de base
para responder perguntas referentes a outros aspectos.
Exemplo:
◦ Qual o esforço (horas/homem, homem/mês)
◦ Durante quanto tempo
◦ Qual o custo

6
Métricas x Gerenciamento de Projetos
 As métricas também ajudam aos gerentes a:
◦ 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
Métricas x Gerenciamento de Projetos
 As métricas também ajudam aos gerentes a:
◦ 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
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
Categorização de Métricas
 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.
Categorização de Métricas
 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
Métricas de Software
 Quando métricas não são utilizadas
A falta de métricas de projetos prejudica de forma geral seu
acompanhamento, uma vez que, apesar de o problema estar lá,
ele não é percebido por aqueles que podem direcionar
esforços na sua solução. O papel das métricas é permitir uma
rápida identificação e correção de problemas.

Quando os desvios são identificados em tempo, itens de ação

podem ser analisados. Eliminar os fatores que afetam
negativamente a produtividade, negociar mais recursos e
escopo são exemplos de ações que podem ser tomadas.

12
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!!
Métricas para Software

• Métodos mais utilizados:

– Linhas de código - lines of code (Kloc)

– Análise de Pontos de função (APF)
– Constructive Cost Model (COCOMO)
– Metodologias ágeis
– Pontos de casos de uso
 Métricas de Software
 Qual a medida que melhor representa o tamanho?
Linhas de Código – a aparente facilidade na contagem da
quantidade de linhas de código (LOC – Lines of Code) não é tão
simples, pode-se correr risco de utilizar dois pesos duas
medidas se alguns pontos não forem esclarecidos, por exemplo:
◦ A inclusão na contagem da quantidade de linhas de comentário, linhas em
branco ou comandos nulos
◦ A inclusão na contagem de diretrizes de compilação
◦ A contagem de múltiplos comandos ou declarações em uma única linha de
código como várias linhas, uma para cada comando ou declaração
◦ A contagem de uma única linha nos casos em que um único comando ou
declaração é expresso em múltiplas linhas
◦ A inclusão na contagem de delimitadores de blocos
15
Métricas de Software
Em resumo, devem-se destacar alguns reversos na utilização
de LOC como unidade para medir o tamanho do sistema:
◦ Falta de padronização
◦ Falta de significado para os clientes usuários do objeto de medição
◦ Dificuldade de aplicação nas fases iniciais do ciclo de vida
◦ Dependência da linguagem de programação

Apesar de todos os reversos apresentados, esta medida

continua sendo utilizada por centenas de organizações.
Métricas como COCOMO e PUTNAM são exemplos de
modelos baseadas em LOC para medição de softwares.

16
 Modelo de Pontos por Função
 Os fundamentos de pontos de função foram especificados
por Allan J. Albrecht, da IBM, em 1979, tendo sido refinados
e transformados em metodologia formal em 1984.
 Em 1990 o IFPUG (International Function Point Users
Group) lançou a primeira versão do Manual de Práticas de
Contagem, que se tornou padrão reconhecido pela indústria
para pontos de função.
 Em 1998, foi criado o BFPUG (Brazilian Function Point
Users Group) responsável pelo exame de certificação do
IFPUG no Brasil.
 Esta técnica baseia-se nos requisitos lógicos funcionais dos
usuários. Os requisitos não-funcionais, são utilizados para
promover os ajustes (para mais ou para menos) no
tamanho final do aplicativo. 17
 Modelo de Pontos por Função
Processo de Contagem Contar Determinar
funções do contagem
Identificar tipo dados de pontos
escopo da de função
Determinar
contagem não-
o tipo de
e fronteira ajustados
contagem Calcular o
da Contar número de
aplicação funções do pontos de
tipo função
transação ajustados
Determina
r valor do
Tipos de Contagem: fator de
•Contagem de um projeto de desenvolvimento ajuste
•Contagem de um projeto de melhoria
•Contagem de uma aplicação

Ponto de Função Ajustado =

Soma (pontos de função não ajustados) x (0,65 + 0,01 x soma (fator de ajuste))
18
Processo de Contagem
 Determinar o tipo de contagem (pode ser um projeto de novo desenvolvimento,
uma contagem básica de aplicação ou uma contagem de projeto de melhoria)
 Identificar a fronteira da aplicação (i.e., quais funções o software deve executar?)
 Contar os tipos de funções de dados (divididos em: i) Arquivos Lógicos Internos ou
ALIs, que são os grupos lógicos de dados mantidos dentro da fronteira da aplicação,
e ii) Arquivos de Interface Externa ou AIEs, os quais são apenas referenciados pela
aplicação). Cada ALI vale 7, 10 ou 15 PF ,enquanto cada AIE vale 5, 7 ou 10 PF.
 Contar os tipos de funções de transações (divididos em: i) Entradas Externas ou EEs,
que são processos de entrada de dados, b) Saídas Externas ou SEs, por exemplo,
relatórios e c) Consultas Externas ou CEs, por exemplo, Consultar Detalhes de
Empregados). Cada EE ou CE vale 3, 4 ou 6 pontos de função, enquanto cada SE vale
4, 5 ou 7 pontos de função.
 Diversas matrizes simples baseadas nos tipos de elementos de dados (reconhecidos
pelos usuários e não recursivos), juntamente com tipos de registros (subconjunto
dos dados reconhecidos pelos usuários) ou tipos de arquivos referenciados (número
de grupos lógicos de dados necessários à execução completa de um processo) são
utilizados para determinar a complexidade de cada função, Baixa, Média ou Alta

19
Processo de Contagem
 Determinar o Fator de Ajuste de Valor (FAV) baseado na equação (FAV = 0,65 +
(Soma das Características Gerais do Sistema x 0,01) e a avaliação, em uma escala de
1 a 5, das seguintes quatorze Características Gerais do Sistema. Instruções
específicas para avaliação são fornecidas no CPM do IFPUG:
◦ 1. Comunicação de Dados
◦ 2. Processamento Distribuído de Dados
◦ 3. Desempenho
◦ 4. Configuração Intensamente Utilizada
◦ 5. Taxa de Transação
◦ 6. Entrada de Dados On-Line
◦ 7. Eficiência do Usuário Final
◦ 8. Atualização On-Line
◦ 9. Processamento Complexo
◦ 10. Reutilização
◦ 11. Facilidade de Instalação
◦ 12. Facilidade de Operação
◦ 13. Múltiplas Localidades
◦ 14. Facilidade de Alteração

 Calcular a contagem ajustada final de PF (contagem final de PF = contagem não

ajustada * FAV) 20
Cadastro de Pessoas
 Arquivos de dados utilizados:
◦ Pessoas
◦ Cargos
◦ Departamentos
◦ Bairros
◦ Cidades
◦ Estados
Contagem das Funções do Tipo Dado
 Arquivo Interno lógico (AIL)
◦ Um grupo de dados ou informações de
controle mantido e utilizada pela
aplicação
 Arquivo de Interface Externa (AIE)
◦ Um grupo de dados ou informações de
controle a ser utilizado pela aplicação,
mas mantida por outra.
Tabela AIL e AIE
1- 19 20 – 50 >50
TDado TDado TDado
1 TReg BAIXA BAIXA MEDIA

2 – 5 TReg BAIXA MEDIA ALTA

> 5 TReg MEDIA ALTA ALTA

Tabela de Pesos
BAIXA MEDIA ALTA

AIL 7 10 15

AIE 5 7 10

Esta tabela é utilizada para verificar o peso de cada função tipo data
Funções tipo Transação
 Cadastrar cargos
 Cadastrar departamentos
 Cadastrar pessoas
 Consultar pessoas (Dados pessoa + nome
do cargo + nome do departamento + nome
do bairro + nome da cidade + sigla do
Estado)
 Emitir relação de pessoas por Cargo (nome
do cargo, nome da pessoa, total de pessoas
por cargo)
Classificar as funções tipo Transação
 Entrada Externa (EE)
◦ Processamento de dados ou informações de controle que
entram pela fronteira da aplicação. Através de um
processo lógico único, esses dados, atualizam arquivos
lógicos internos e/ou alteram o comportamento do sistema
 Consulta Externa (CE)
◦ O processo onde uma entrada de dados ocasiona uma
recuperação imediata de dados. Os dados exibidos não
envolvem fórmulas, cálculos ou nenhum tipo de dado
derivado.
 Saída Externa (SE)
◦ Envio de dados ou informações de controle para fora das
fronteiras da aplicação (relatórios, dados transferidos para
outra aplicação)
Tabela EE
1- 4 5 – 15 > 15
TDado TDado TDado
0 -1 ARef BAIXA BAIXA MEDIA

2 ARef BAIXA MEDIA ALTA

>2 ARef MEDIA ALTA ALTA

Tabela SE e CE
1- 5 6 – 19 > 19
TDado TDado TDado
0 -1 ARef BAIXA BAIXA MEDIA

2 – 3 ARef BAIXA MEDIA ALTA

>3 ARef MEDIA ALTA ALTA

 Tabela de Pesos

BAIXA MEDIA ALTA

EE 3 4 6

CE 3 4 6

SE 4 5 7
Cálculo do total de PF

 PF = SomaTotal x [0,65 + 0,01 x Soma (Fator de

Ajuste)]

◦ O fator de ajuste deverá ser calculado de

acordo com as características gerais do
sistema

 SomaTotal é o total de PF sem considerar o ajuste

Exercício:
Calcular a quantidade de PF
Funcionalidades
1. Incluir clientes
2. Alterar clientes
3. Consultar clientes
4. Excluir clientes
5. Incluir produtos
6. Alterar dados de produtos
7. Consultar produtos
8. Incluir pedidos
9. Consultar pedidos
10.Consultar pedido por cliente
11.Consultar produtos pedidos por período
12.Emitir relatório de pedido em Aberto por Clientes
13.Emitir relação de clientes
Referências Bibliográficas
 Rocha, Maldonado, Weber. Qualidade de Software,
Teoria e Prática. Ed. Prentice Hall. SP, 2001
 Vazquez, Simões, Albert. Análise de Pontos de Função.
Medição, Estimativas e Gerenciamento de Projetos de
Softwares. Ed. Erica.SP,2004.
 Macenas, Oliveira. Qualidade em Software. Uma
metodologia para homologação de Sistemas. Ed. Alta
Books. RJ, 2005
 Pressman, Roger. S. Engenharia de Software. Makron
Books, 2006.
 Material de aula prof. Heráclito Amâncio
 Material de aula prof. Alexandre Vasconcelos
 http://www.bfpug.com.br/Artigos/Dekkers-
PontosDeFuncaoEMedidas.htm
34