O documento discute vários tipos de métricas para software, incluindo métricas diretas como custo e linhas de código, métricas indiretas como qualidade e complexidade, métricas orientadas a tamanho como erros por linha de código, e métricas orientadas a função e casos de uso.

1. MEDIÇÃO DE SOFTWARE
 Pode-se categorizar em dois tipo.
 Medidas diretas: Custo, esforço aplicados, linhas de
código (lines of code, LOC), velocidade de
execução, tamanho da memória e quantidade de
erros, etc.
 Meditas indiretas:
funcionalidade, qualidade, complexidade, eficiência, conf
iabilidade, manutenibilidade, etc.

2. MEDIÇÃO DE SOFTWARE
 Como desenvolver métricas para serem utilizadas em
diferentes projetos com diferentes indivíduos?
 Exemplo: Equipe A encontrou 184 erros e a equipe B
encontrou 342 erros. Qual equipe é mais efetiva na
descoberta de erros ao longo do processo?
 Se as medidas forem normalizadas , é possível criar
métricas de software que permitam um bom grau de
comparação.

3. MÉTRICAS ORIENTADAS A TAMANHO
 São originadas pela normalização da medidas de
qualidade considerando o tamanho do software.
 Se uma organização mantém registros simples, uma
tabela de medidas orientadas a tamanho pode ser criada.
 A partir dos dados rudimentares contidos na tabela, um
conjunto de métricas simples orientadas a tamanho pode
ser desenvolvido.
 Erros por KLOC, defeitos por KLOC, $ por
KLOC, páginas de documentação por KLOC erros por
pessoa-mês, KLOC por pessoa-mês, etc.

4. MÉTRICAS ORIENTADAS A TAMANHO
Projeto LOC Esforço $(000) Pág. Doc. Erros Defeitos
Alfa 12.100 24 168 365 134 29
Beta 27.200 62 440 1224 321 86
Gama 20.200 43 314 1050 256 64
 Não é universalmente aceita como o melhor modo de medir o processo
de desenvolvimento de software.
 Apesar de ter uma boa documentação ser um artefato de todos os projetos
os LOC São dependentes da linguagem de programação utilizada e também
Penalizam programas curtos, mas bem projetados que requerem um nível de
detalhamento difícil de alcançar

5. MÉTRICAS ORIENTADAS A FUNÇÃO
 Métricas de software orientadas à função usam uma medida da
funcionalidade entregue pela aplicação como valor de
normalização.
 A métrica orientada a função mais utilizada é a pontos por
função (function point – FP)
 O Cálculo dos pontos por função é baseado em características
do domínio de informação e complexidade do software.
 É independente da linguagem de programação e é baseada em
dados que são mais prováveis de ser conhecidos na evolução do
projeto, tornando a melhor numa abordagem de estimativa.

6. MÉTRICAS ORIENTADAS A FUNÇÃO
 Oponentes alegam que o método requer
alguma “mágica”, pois o cálculo é baseado em
dados subjetivos em vez de objetos e que a FP
não tem significado físico – é apenas um
número.
 Métricas baseadas em pontos por função e
LOC têm sido consideradas relativamente
precisas para prever o esforço e o custo de
desenvolvimento de software.

7. MÉTRICAS ORIENTADAS A OBJETOS
 Métricas de software convencional (LOC e FP)
podem ser usadas para estimar projetos de
software orientados a objetos. NO entanto
essas métricas não fornecem disponibilidade
suficiente para ajustes de cronograma e
esforço.
 Algumas métricas sugeridas são:
 Número de scripts de cenário – Interação entre
usuário e aplicação.
 Número de classes-chave – Componentes
altamente independentes.

8. MÉTRICAS ORIENTADAS A OBJETOS
 Número de classes de apoio – Podem ser
classes de IU, de acesso e manipulação a BDs
e classes de cálculo.
 Número médio de classes de apoio por
classe-cave – Número médio de classes de
apoio por classe-chave.
 Número de subsistemas – É uma agregação
de classes que apoia uma função que é visível
ao usuário final.

9. MÉTRICAS ORIENTADAS A CASOS DE USO
 Assim como FP, o caso de uso é definido no início do processo
de software.
 Descrevem (indiretamente) as funções e características visíveis
ao usuário.
 É independente da linguagem de programação.
 O número de casos de uso é diretamente proporcional ao
tamanho da aplicação em LOC.
 Podem ser criados em vários níveis de abstração, ou seja, não
há padronização quanto ao tamanho de um caso de uso. Isso a
torna não muito confiável.