José Malcher Jr.

Eng. Software – Analista de Sistemas

Métricas de Software – Fundamentos de métricas e medidas


Métricas para Software

O mercado exige, hoje, a gestão da qualidade, do conhecimento e sabe-se que não se pode gerenciar o que não se pode medir. No entanto, como medir valores como o conhecimento ou a qualidade?

Sabemos que todo processo de engenharia necessita de medições para entender melhor os modelos e avaliar a quantidade dos produtos construídos. No caso da engenharia de software – que não é fundamentada nas medidas quantitativas diretas, como voltagem, temperatura, velocidade – as suas medidas e métricas são na sua maioria indiretas.

Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos às características de uma entidade qualquer, definidos de acordo com regras bem definidas. Na ciência da computação, podemos medir os atributos, antes considerados incomensuráveis – ainda que alguns especialistas em software continuem a argumentar que o software é “incomensurável”.

O que é métrica?

Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software, focalizando atributos específicos e mensuráveis dos artefatos da engenharia de software.

Quem realiza?

Os engenheiros de software usam métricas de produto para ajudá-los a criar software da mais alta qualidade.

Haverá sempre um elemento qualitativo na criação de software. O problema é que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários critérios objetivos para ajudar a direcionar o projeto de dados, arquitetura, interfaces e componentes. Ao testar, necessitamos de orientação quantitativa que nos auxiliará na seleção de casos de teste e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa.


Por que devemos medir?

  • Para sabermos quanto cobrar;
  • Para conseguirmos dar prazos;
  • Para definirmos a equipe;
  • Para definirmos complexidade;
  • Para definirmos tamanho;
  • Para medirmos risco.

Quais são as etapas envolvidas?

  1. O primeiro passo no processo de medição é definir as métricas apropriadas para o software.
  2. Em seguida, coletam-se os dados necessários para aplicar as métricas formuladas.
  3. Uma vez computadas, as métricas são analisadas com base em diretrizes preestabelecidas e dados do passado.
  4. Os resultados das análises são interpretados para obter informações sobre a qualidade do software.
  5. Os dados da interpretação levam à modificação dos requisitos e modelos de projeto, código-fonte ou casos de teste.

Qual é o artefato (produto)?

O produto, no caso, são as métricas computadas por meio de dados coletados dos requisitos e modelos de projeto, código-fonte e casos de teste.


Como garantir que o trabalho seja realizado corretamente?

Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo cada métrica de produto de maneira não ambígua. Defina apenas algumas métricas e, então, use-as para obter informações sobre a qualidade do artefato de software.

Embora as métricas de produto para software sejam imperfeitas, podem proporcionar uma maneira sistemática de avaliar a qualidade com base em um conjunto de regras claramente definidas.

Elas também proporcionam uma visão objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e corrigir problemas potenciais antes que se tomem defeitos catastróficos.


Avaliação dos atributos internos do produto

A seguir, veremos algumas medidas que podem ser usadas para avaliar a qualidade do produto enquanto ele está sendo projetado.

Essas medidas de atributos internos do produto fornecem uma indicação em tempo real da eficácia dos modelos de requisitos, projeto e código, da eficácia dos casos de teste e da qualidade geral do software que será criado.


Qualidade de Software

O desenvolvimento de sistemas de software envolve uma série de atividades em que as oportunidades de falhas são muito grandes.

Os erros podem aparecer no início do processo devido a alguns fatores:

  • Objetivos mal definidos;
  • Erros em fases de projeto e desenvolvimento.

Ninguém tolera erros, por isso o desenvolvimento de software tem que ter garantia de qualidade.

A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação.


Custo do reparo

Quanto mais cedo for verificado o software durante o seu ciclo de vida, menores as chances de elevar os custos de reparo.

Quanto mais cedo for verificado o software durante o seu ciclo de vida, menores as chances de elevar os custos de reparo.

 


Curva de falhas para hardware ou curva da banheira

Curva de falhas para hardware ou curva da banheira

Curva de falhas para hardware ou curva da banheira 2

 


Garantia de qualidade

A garantia de qualidade de software (Software Quality Assurance) não é algo com a qual começamos a nos preocupar depois que o código foi gerado, e sim ao longo de todo o processo de engenharia de software. A SQA ou GQS abrange:

  1. Métodos e ferramentas de análise, projeto, codificação e teste;
  2. Revisões técnicas em cada fase do desenvolvimento;
  3. Estratégia de teste;
  4. Documentação de software e das mudanças efetuadas;
  5. Padrões de desenvolvimento de software;
  6. Mecanismos de medição.

Fatores determinantes para a garantia da qualidade

Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade aos requisitos significa falta de qualidade.

Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade.

Conjunto de requisitos que não são mencionados (ex.: boa manutenibilidade). Caso o software se adéque aos requisitos explícitos, mas não aos implícitos, sua qualidade será suspeita.


Fatores de qualidade de McCall

McCall propõe uma categoria de fatores que afetam a qualidade do software, conforme mostra a figura.

Fatores de qualidade de McCall

 


Características operacionais

Corretude

Refere-se à capacidade de um programa satisfazer sua especificação e cumprir os objetivos visados pelo cliente. Ele faz aquilo que eu quero?

Confiabilidade

Refere-se à capacidade de um programa executar a função pretendida com a precisão exigida. Ele se comporta com precisão o tempo todo?

Usabilidade

Refere-se ao esforço necessário para aprender, operar, preparar a entrada e interpretar a saída de um programa. Ele foi projetado para o usuário?

Corretude

Refere-se à capacidade de controlar o acesso ao software ou a dados por pessoas não autorizadas. Ele é seguro?

Eficiência

Refere-se à quantidade de recursos computacionais e de código exigida para que um programa execute sua função. Ele rodará em meu hardware tão bem quanto possível?


Características de manutenção

Manutenibilidade

Refere-se ao esforço exigido para localizar e reparar erros em um programa. Posso consertá-lo?

Flexibilidade

Refere-se ao esforço demandado para modificar um programa. Posso mudá-lo?

Testabilidade

Refere-se ao esforço exigido para testar um programa a fim de garantir que ele execute a função pretendida. Posso testá-lo?


Características de adaptação a novos ambientes

Portabilidade

Refere-se ao esforço exigido para transferir o programa de um ambiente para outro. Serei capaz de usá-lo em outra máquina?

Reusabilidade

Refere-se à capacidade de um programa, ou partes, ser reusado em outras aplicações. Serei capaz de reutilizar parte do software?

Interoperabilidade

Refere-se ao esforço exigido para se acoplar um sistema a outro. Serei capaz de compor uma interface com outro sistema?


Fatores de Qualidade ISO 9126

Funcionalidade: A funcionalidade diz respeito ao grau com que o software satisfaz as necessidades indicadas pelos seguintes subatributos: adequabilidade, precisão, interoperabilidade, atendibilidade e segurança.

Além da funcionalidade, outros fatores da ISO 9126: confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

SEGUNDO PRESSMAN:

“O teste é o último reduto no qual a qualidade pode ser avaliada”;

“Você não pode testar qualidade. Se ela não estiver lá antes, ela não estará lá quando terminar de testar”;

“Otimismo é o risco ocupacional da programação; teste é o tratamento”;

“A qualidade de um software é função de quanto ele muda o mundo para melhor”.


Métricas de indicadores e de produto

É importante que você entenda as diferenças sutis entre os termos medida, medição e métrica, empregados com frequência.

MEDIDA

Sob o contexto de engenharia de software, medida proporciona uma indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum produto ou processo.

MEDIÇÃO

A medição é o ato de determinar uma medida.

MÉTRICA

Segundo o IEEE (Standard Glossary of Software Engineering Terminology), métrica busca obter uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo.

 

Quando é coletado um único ponto de dado (por exemplo, o número de erros descobertos em um componente de software), foi estabelecida uma medida.

A medição ocorre como resultado da coleção de um ou mais pontos de dados (por exemplo, um conjunto de revisões de componentes e testes de unidade é investigado para coletar medidas do número de erros para cada um).

Uma métrica de software relaciona as medidas individuais de alguma maneira (por exemplo, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade).

Antes que um projeto possa ser planejado, deve-se:

  • Estabelecer os objetivos e o escopo do projeto;
  • Considerar soluções alternativas;
  • Identificar as restrições administrativas e técnicas.

Controle do software

É impossível controlar um software sem medições e feedback. Não se pode controlar o que não se pode medir e a extensão do controle depende da precisão da medição. Qualquer coisa que não se pode medir está fora de controle.

As medições e métricas ajudam a entender o processo usado para se desenvolver um produto de software e o próprio produto.


O produto e o processo em relação à medição

Produto é medido para avaliar a sua qualidade e processo é medido para melhorá-lo. Para efetivar a medição é necessário ter em mãos documentação de efeitos passados e dados estatísticos de quantificação de efeitos futuros.

A medição e a inferência estatística são usadas em várias áreas para projetar o desempenho futuro.

A medição pode levar a controvérsias e discussões como:

  • Que métricas usar?
  • Como os dados compilados devem ser usados?

É justo usar medições para se comparar pessoas, processos e produtos?


As estimativas mais importantes

A estimativa é uma das principais atividades do planejamento de software:

  1. Esforço humano exigido
  2. Duração do projeto
  3. Custo

Métricas são frequentemente classificadas como métricas do processo ou métricas do produto, e são aplicadas durante o processo de desenvolvimento ou ao produto de software desenvolvido.


Métricas do processo

As métricas do processo quantificam atributos do processo de desenvolvimento e do ambiente de desenvolvimento.

Métricas de recursos:

  • experiência do programador
  • custo de desenvolvimento
  • manutenção.

Métricas para o nível de experiência do pessoal:

  • número de anos que uma equipe está usando uma linguagem de programação;
  • número de anos que um programador está na organização.

Outros fatores relacionados ao desenvolvimento incluem:

  • Técnicas de desenvolvimento;
  • Auxílio para programação;
  • Técnicas de supervisão etc.

Métricas do produto

São medidas do produto de software. Podem não revelar nada sobre como o software foi desenvolvido.

Incluem:

  • O tamanho do produto (linhas de código);
  • A complexidade da estrutura lógica (recursão – for, while, repeat, fluxo de controle – ordem das instruções do programa – e profundidade de laços aninhados);
  • A complexidade da estrutura de dados;
  • Funções (tais como tipo de software: comercial, científico etc.).

Nesse caso, é importante que você conheça um exemplo: O número de defeitos descobertos durante o teste formal depende do produto (número de segmentos de código que estão errados) e do processo usado na fase de teste (a extensão do teste).

Métricas do produto

 


Métricas diretas e métricas indiretas

Medidas Diretas do Processo de Software:

  • Custo e esforço aplicados.

Medidas Diretas do Produto:

  • Número de linhas de código produzidas (KLOC – Kilo Lines of Code ou simplesmente “mil linhas de código”);
  • Velocidade de execução;
  • Tamanho de memória;
  • Número de defeitos registrados em um tempo qualquer.

Medidas Indiretas do Produto:

  • Qualidade;
  • Funcionalidade;
  • Complexidade;
  • Eficiência;
  • Confiabilidade;
  • Manutenibilidade.

Métricas orientadas ao tamanho

Linhas de Código (KLOC): uma linha de código é qualquer linha do texto de um programa, exceto comentários e linhas em branco, sem levar em conta o número de comandos ou fragmentos de comandos em uma linha. Estão incluídas na definição de linhas de código todas as linhas que contém cabeçalho do programa, declarações e comandos executáveis.

Vantagens:

  • É fácil de calcular;
  • É o fator mais importante para muitos modelos de estimativa.

Desvantagens:

  • Dependente da linguagem de programação;

Penalizam programas bem estruturados, porém mais curtos.


Métricas orientadas à função

  • São medidas indiretas do software;
  • Concentram-se na funcionalidade ou utilidade do programa;
  • Função: coleção de comandos executáveis que realizam uma determinada tarefa.

Princípios de medição

  • Formulação: criação de medidas e métricas apropriadas para a representação do software.
  • Coleção: no caso, refere-se ao mecanismo usado para acumular dados necessários para criar as métricas formuladas.
  • Análise: é a computação das métricas e a aplicação de ferramentas matemáticas.
  • Interpretação: relacionada à avaliação de métricas que resultam em informações sobre a qualidade da representação.
  • Feedback: são recomendações derivadas da interpretação de métricas de produto transmitidas para a equipe de software.

Atributos de métricas eficazes de software

Centenas de métricas já foram propostas para software, algumas demandam medições muito complexas, outras são tão esotéricas que poucos profissionais do mundo real têm qualquer esperança de entendê-las, e outras ainda violam as noções intuitivas básicas do que é realmente um software de alta qualidade.

  • Planejamento
  • Análise
  • Design
  • Programação

A seguir estão elencados os atributos que devem ser considerados pelas métricas – segundo Pressman (Engenharia de Software):

  • Simples e computáveis – Deverá ser relativamente fácil aprender a derivar a métrica, e sua computação não deve demandar esforço ou tempo fora do normal.
  • Empiricamente e intuitivamente persuasiva – A métrica deverá satisfazer as ideias do engenheiro de software.
  • Consistente e objetiva – A métrica deverá sempre produzir resultados que não sejam ambíguos. Um terceiro independente deverá ser capaz de derivar o mesmo valor da métrica usando as mesmas Informações sobre o software.
  • Consistente no seu uso das unidades e dimensões – A computação matemática da métrica deverá usar medidas que não resultem em combinações bizarras de unidades. Por exemplo, multiplicar número de pessoas nas equipes de projeto pelas variáveis da linguagem de programação no programa resulta em uma mistura duvidosa de unidades que não é claramente convincente.
  • Independente da linguagem de programação – As métricas deverão ser baseadas no modelo de requisitos, modelo de projeto ou na própria estrutura do programa. Elas deverão ser independentes dos caprichos da sintaxe ou semânticas das linguagens de programação.
  • Um mecanismo efetivo para feedback de alta qualidade – A métrica deverá fornecer informações que podem levar a um produto final de melhor qualidade.

Referências

Base: Pós em Engenharia de Software – Estácio (EAD), com várias adaptações e melhorias.

PRESSMAN, Roger S. Engenharia de Software. 7. ed. Mc Graw Hill,2011.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Mc Graw Hill, 2007.

PADUA Filho, Wilson de. Engenharia de Software: Fundamentos, métodos e padrões, 3. ed. Rio de Janeiro: Editora LTC, 2009.

Bibliografia Complementar:

PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.

VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função medição, estimativa e gerenciamento de projetos de software. São Paulo: Editora Érica, 2009.


OUTROS ARTIGOS

Medição de Software para Pequenas Empresas: Uma Solução Baseada na Web:(ftp://ftp.inf.puc-rio.br/pub/docs/techreports/98_32_franca.pdf)


Exercícios de fixação

LINK: http://josemalcher.net/lista-de-exercicios-de-metricas-de-software-lista-1/