Medição e Métricas de Software

O papel da medição de software é quantificar alguns atributos de um produto ou de um processo de software. Comparando essas informações é possível tirar conclusões sobre a qualidade do software. Possibilita ainda mensurar se mudanças organizacionais – adoção de novas ferramentas, metodologias dentre outros – estão sendo positivas ou não para os processos de desenvolvimento da mesma. Nesse caso são feitas medições antes e depois da mudança a fim de verificar se a mesma foi positiva ou não para a organização (SOMMERVILLE, 2008).

Majoritariamente, as métricas têm sido adotadas para melhorar processos de gerenciamento da qualidade. Por esse motivo as métricas são utilizadas para mensurar defeitos de programas e processos de verificação e validação.

Todavia, o uso de métricas ainda é relativamente incomum e muitas organizações relutam em adotá-las pois os benefícios não são bem definidos. Isso acontece por que a organização dos processos de software ainda é precária e ainda não estão aperfeiçoados de forma suficiente para usar métricas. Outro motivo é a falta de padrões para as métricas e o fato de muitas empresas não estarem preparadas para introduzir medições sem que padrões e ferramentas sejam antes criadas.

Nesse sentido, Paula Filho (2000)  afirma que escolher medidas adequadas, e ser capaz de coletar, normalizar e analisar estas medidas requer um grau mais avançado de capacitação. Ressalta também que sem medidas, os processos não podem ser avaliados e muito menos melhorados. Por isso mesmo que as medidas sejam rudimentares elas podem ser úteis.

Uma métrica de software é qualquer tipo de medição que se refira a um sistema de software, processo ou documentação relacionada. Alguns exemplos são a medição do tamanho pela quantidade de linhas de código, grau de facilidade de leitura de um trecho de código, numero de defeitos relatados e numero de pessoas-dia necessárias para desenvolver um software (SOMMERVILLE, 2008).

As métricas podem ser classificadas em de controle ou preditivas e ambas podem influenciar na tomada de decisões. As métricas de controle estão associadas a processos de software, já as preditivas estão associadas a produtos de software. Visto que  é quase impossível medir atributos da qualidade de software como facilidade de manutenção, complexidade e facilidade de compreensão, os engenheiros de software medem então atributos internos como o tamanho. Com essas medidas em mãos eles supõe que existam relações entre o que se pode medir e o que se deseja saber. Além disso para que o processo de medição seja confiável, é exigido também, profissionais com grande experiência em estatística.

1.1 O Processo de Medição

A medição de software muitas vezes pode fazer parte de um processo de controle de qualidade. Componentes de um sistema são analisados separadamente, e os diferentes valores de métricas são comparados entre si e com dados históricos de projetos precedentes. As medições anômalas encontradas nesse processo são usadas para enfatizar o esforço de garantia de qualidade.

De acordo com Sommerville (2008) os principais estágios desse processo são:

  • Escolha das medições a serem feitas onde devem ser formuladas questões as quais as medições se destinam a responder e definir as medições importantes para responder essas questões. Medições não relevantes para responder essas questões não precisam ser coletadas.
  • Seleção dos componentes a serem avaliados nem todos os componentes precisam ser necessariamente avaliados, sendo assim é preciso fazer-se uma seleção representativa de componentes realmente importantes.
  • Medição de características dos componentes os componentes selecionados são medidos e os valores e métricas são computados.
  • Identificação de medições anômalas deve-se então procurar por valores incomuns para cada métrica pois eles sugerem a existência de problemas com o componente        que apresenta esses valores.
  • Analise de componentes anômalos os componentes com valores anômalos devem ser examinados para constatar se a qualidade do componente está ou não comprometida. Apesar disso pode haver ainda outros motivos para essa anomalia mas que não comprometam a qualidade.

Os dados coletados devem ser mantidos como um recurso organizacional assim como os registros históricos dos projetos. Quando um banco de dados de medição se torna suficientemente grande ele passa a servir de base para comparações entre projetos e métricas específicas podem ser aprimoradas, de acordo com as necessidades organizacionais.

1.2 Métricas de Produto

O foco das métricas de produto são as características do próprio software. Pelo fato de as características facilmente mensuráveis do software não terem uma relação clara e universal com os atributos de qualidade, a organização precisa analisar seu banco de dados para descobrir como atributos do produto de software se relacionam com as qualidades desejadas pela organização.

Nesse sentido Sommerville (2008) divide as métricas de produtos em duas classes:

  • Métricas dinâmicas são aquelas coletadas de um programa em execução. Ajudam a avaliar a eficiência e a confiabilidade de um programa. Quase sempre estão relacionadas com atributos da qualidade de software.
  • Métricas estáticas são aquelas coletadas em representações do sistema como projeto, programa ou documentação. Ajudam a mensurar a complexidade e a facilidade de compreensão e manutenção de um sistema de software. Possuem uma relação indireta com os atributos de qualidade.

Um dos maiores problemas da coleta de dados sobre software e projetos de software reside no fato de que os dados podem ser interpretados de forma equivocada levando a resultados incorretos. A interpretação dos dados sobre um produto ou processo é um método incerto. Os elementos focados pela medição não estão isolados de seus ambientes, e mudanças nesse ambiente podem invalidar as comparações de dados. Além disso, as métricas variam de acordo com o projeto, com as metas da equipe de gerencia de qualidade, com o tipo de software que está em desenvolvimento.

Treinamentos relacionados com essa postagem







Referências:

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

PAULA FILHO, Wilson de Pádua. Engenharia de Software:fundamentos, métodos e padrões. São Paulo: LTC Editora, 2000.

Leandro Costa

Sou desenvolvedor de software a desde 2008, além de programar gosto de esportes de aventura como rapel, tirolesa, trilhas de bike, apreciador de cervejas, baladas, motos e do bom e velho Rock’n Roll também gosto de história, ficção científica e de tecnologia. Atualmente sou consultor de Agile Software Delivery na Erudio Training e instrutor na Udemy.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *