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, confiabilidade, manutenibilidade, etc.

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.

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.

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

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.

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.

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.

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.

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.