métricas de software

Prévia do material em texto

50 Engenharia de Software Magazine - Métricas de Software
Thamine Chaves de Abreu 
thamine.abreu@gmail.com
Atualmente cursa especialização em De-
senvolvimento de Aplicações para Web no 
Centro de Ensino Superior de Juiz de Fora 
(CES/JF), Bacharel em Sistemas de Infor-
mação pela Universidade Severino Sombra 
(USS), Desenvolvedor de Sistemas Web na 
Granbery Consultoria Júnior em projeto 
para a Fundação COPPETEC, possui expe-
riência de 4 anos em desenvolvimento de 
sistemas Java (web/desktop).
Leonardo da Silva Mota 
leonardo.smota@hotmail.com
Atualmente cursa especialização em De-
senvolvimento de Aplicações para Web no 
Centro de Ensino Superior de Juiz de Fora 
(CES/JF), Bacharel em Sistemas de Infor-
mação pela Universidade Severino Sombra 
(USS), Desenvolvedor de Sistemas Web na 
Granbery Consultoria Júnior em projeto 
para a Fundação COPPETEC, programa-
dor certificado Java (SCJP), atuou como 
professor assistente no curso de Sistemas 
de Informação da USS e dos cursos de in-
formática da Fundação de Apoio a Escola 
Técnica (FAETEC), possui experiência de 
4 anos em desenvolvimento de sistemas 
Java (web/desktop).
Marco Antônio Pereira Araújo 
maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas 
e Computação pela COPPE/UFRJ, Especialista 
em Métodos Estatísticos Computacionais e 
Bacharel em Matemática com Habilitação em 
Informática pela UFJF, Professor dos cursos de 
Bacharelado em Sistemas de Informação do 
Centro de Ensino Superior de Juiz de Fora e 
da Faculdade Metodista Granbery, Analista de 
Sistemas da Prefeitura de Juiz de Fora e Editor 
da Engenharia de Software Magazine.
De que se trata o artigo?
O artigo trata da utilização de métricas de software 
no gerenciamento de projetos, sendo fortes aliadas 
na estimativa, acompanhamento e apoio em toma-
da de decisões durante a construção de produtos de 
software, visando uma melhor qualidade de todo 
este processo.
Para que serve?
Métricas de software servem para apresentar medi-
das, preferencialmente quantitativas, que re�itam
características especí�cas de processos e de produtos 
em construção, podendo ser utilizadas em diferentes 
dimensões, como esforço, tamanho, complexidade,
dentre outras. 
Em que situação o tema é útil?
A coleta adequada de métricas, com suas res-
pectivas análises, pode auxiliar o Engenheiro
de Software na tomada de decisões ao longo 
do desenvolvimento de um projeto, visando a
melhoria da qualidade do processo e do produto 
em construção.
Métricas de Software 
Como utilizá-las no gerenciamento de projetos de software
A garantia da qualidade é uma das principais preocupações da indústria de desenvolvimento 
de software, pois atualmente a maior 
parte das empresas atuantes no mercado 
utiliza esse tipo de aplicação para gerir 
seus negócios, produtos e relacionamen-
tos com clientes, necessitando maior 
confiabilidade e qualidade. Existem 
diversas medidas de garantia de qua-
lidade fundamentais para o sucesso de 
qualquer tipo de aplicação de software, 
dentre elas, uma das mais simples e 
menos custosa, é a medição de software. 
Nesse sentido, a medição de software 
auxilia a tomada de decisão, pois através 
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Edição 21 - Engenharia de Software Magazine 51
GERÊNCIA DE PROJ ETOS
de dados quantitativos, é capaz de informar que aspectos do 
produto atendem ou não ao padrão de qualidade especificado, 
além de permitir a avaliação dos benefícios de novos métodos 
e ferramentas de engenharia de software, o entendimento e 
aperfeiçoamento do processo de produção, a avaliação do 
retorno do investimento e tornar o gerenciamento de projetos 
baseado em fatos e não “achismos”, por exemplo.
Para medir software, são utilizadas diversas métricas que são 
como tipos de medições aplicadas a um sistema de software, 
documentação ou processo relacionado. Através dessas métri-
cas é possível determinar o esforço ou tempo para realização 
de uma tarefa ou o tamanho do produto, por exemplo. Além 
disso, as métricas de software são facilmente calculadas, en-
tendidas e testadas e independem do observador que as aplica, 
sendo também uma boa fonte para estudos estatísticos acerca 
do ciclo de vida do software.
Dentro desse contexto, este artigo tem por objetivo apresentar 
algumas métricas de software e sua importância no processo 
de desenvolvimento. Para isso, algumas métricas serão aplica-
das em pequenos exemplos, permitindo ao leitor compreender 
e analisar seus benefícios imediatos.
Utilização de métricas
Existem dois tipos de métricas no contexto de desenvolvi-
mento de produtos de software: as métricas diretas, que são 
realizadas em termos de atributos observáveis, como por 
exemplo, esforço, tamanho e custo, e as métricas indiretas ou 
derivadas, que podem ser obtidas através de outras métricas, 
como por exemplo, complexidade, confiabilidade, e facilidade 
de manutenção. Quanto ao contexto, podem ser aplicadas em 
produtos ou em processos. Quando as métricas incidem dire-
tamente no produto de software, são chamadas de métricas de 
predição, quando em processos de software, são comumente 
chamadas de métricas de controle e sua aplicação normalmente 
é realizada em processos já maduros e controlados. 
Para obter resultados significativos, as métricas devem ser 
aplicadas em um ciclo constante, que envolve as etapas de 
planejamento, medição, análise de resultados, tomada de de-
cisão e implementação das decisões. Desta maneira, pode-se 
construir uma base histórica do artefato medido que permitirá 
ao engenheiro de software analisar que processos, ferramentas 
e métodos melhor se aplicam àquele tipo de produto. Alguns 
cuidados também devem ser tomados no processo de medição, 
como o momento e a escolha do conjunto de métricas mais 
relevantes a serem aplicadas, e a comparação entre produtos 
através da aplicação de métricas (pois nenhum produto é igual 
a outro). O escopo, os desenvolvedores e o ambiente são fatores 
que podem influenciar o processo de desenvolvimento. Assim, 
comparações devem ser cuidadosamente analisadas.
As métricas podem e devem ser aplicadas durante as fases 
de desenvolvimento do software, o que garante ainda mais 
seu impacto positivo no produto final.
Segundo alguns especialistas, para medir artefatos de softwa-
re através de métricas significativas, as medições devem ser 
definidas de acordo com objetivos específicos. Nesse sentido, o 
GQM (Goal/Question/Metric), desenvolvido por Basili em 1988, é 
uma abordagem para aplicação de métricas afim de aprimorar 
o processo de desenvolvimento de software (e, consequente-
mente, os produtos de software gerados) enquanto mantém 
os objetivos de negócio e objetivos técnicos da organização 
nivelados. É uma abordagem top-down que estabelece uma 
medição sistemática para objetivos relacionados ao processo 
de desenvolvimento, em que a equipe começa estabelecendo 
os objetivos organizacionais, define metas de medição, insere 
questões com o propósito de abordar os objetivos especifica-
dos e identifica as métricas que fornecem respostas para as 
questões definidas.
O GQM define um modelo de três níveis, ilustrado na Figura 1.
Figura 1.�����������������������
O GQM pode ser aplicado em todo o ciclo de vida de produ-
tos, processos e artefatos de software e é bem alinhado com 
o ambiente organizacional, sendo um meio adequado para 
conseguir dados confiáveis e conhecimento sobre as práticas 
de software da organização para conduzir a melhoria do 
processo. Nesse contexto, é útil para auxiliar na compreensão 
e formar um baseline das práticasaplicadas no desenvolvi-
mento de software, evoluir as atividades de medição, guiar e 
monitorar processos de software e reduzir custos de desen-
volvimento, por exemplo. O GQM pode ser utilizado também 
como base de fundamentação para outras técnicas de medição 
de software.
O GQM pode ser muito útil na definição de quais métricas 
são necessárias de serem coletadas e analisadas para responder 
questões sobre um determinado objetivo. Isso é importante 
para evitar que esforço seja gasto com coleta desnecessária de 
métricas, que provavelmente nunca serão utilizadas.
Algumas métricas comumente utilizadas
Softwares podem ser medidos (ou estimados) baseados em 
diversos tipos de perspectivas, como tamanho e complexidade. 
Além disso, em função da etapa do desenvolvimento, diferen-
tes métricas podem ser colhidas para um mesmo produto. Por 
exemplo, para a medição de tamanho na etapa de levantamento 
de requisitos, podemos utilizar como métrica o número de 
requisitos especificados. Já na fase de projeto, o tamanho pode 
ser medido em função do número de classes e, na fase de codi-
ficação, a partir no número de linhas de código fonte. 
A seguir, serão apresentadas algumas das principais mé-
tricas baseadas nos tipos de medição citados e, para melhor 
52 Engenharia de Software Magazine - Métricas de Software
compreensão, serão utilizados exemplos de códigos e aplicação 
das métricas.
Análise de Pontos de Função (APF): visa estimar o ta-
manho do software baseado em Pontos de Função (PFs).
Seu objetivo é medir as funcionalidades do software, sem
se preocupar com a tecnologia que será utilizada na im-
plementação e, pode ser aplicado já nos estágios iniciais 
do desenvolvimento de software. A Tabela 1 apresenta as 
fases para sua medição.
Número de linhas de código (LOC, KLOC): assim como a
APF, visa estabelecer o tamanho de um sistema, baseando-se
no número de linhas de código. Essa medição pode auxiliar 
o engenheiro de software a determinar o tamanho de uma
aplicação já construída ou estimar o esforço a ser conside-
rado para a obtenção de um produto a ser desenvolvido.
Embora seja bastante objetiva, bastando analisar o código-
fonte de produtos concluídos para obtê-la, ela pode variar
de acordo com a linguagem de programação utilizada e, 
portanto, as estimativas devem considerar dados de projetos 
similares apenas na mesma linguagem.
Complexidade Ciclomática (CC): proposta por McCabe
em 1976, fornece uma medida quantitativa da complexidade
lógica de um programa. Através dessa métrica é possível 
definir o número de caminhos possíveis de um algoritmo
através do seu número de condições (if, for, while, do e
switch) e assim, especificar o quanto um sistema é complexo 
e, por conseqüência, testável, pois apresenta um indício do 
número de casos de teste a serem realizados para cobrir as
possibilidades de um algoritmo. O ideal é que a complexi-
dade ciclomática seja baixa, pois desta forma, as funções 
podem ser mais facilmente entendidas e modificadas. O 
FASE DESCRIÇÃO
Determinar o tipo de contagem de pontos de função Existem três tipos de contagem que podem ser levadas em conta: contagem de PF de projeto de desenvolvimento, de aplicações instaladas e 
de projetos de manutenção.
Determinar o escopo de contagem e a fronteira da aplicação A fronteira da aplicação é definida estabelecendo um limite lógico entre a aplicação que está sendo medida, o usuário e outras aplicações. O 
escopo para a contagem define a parte do sistema (funcionalidades) a ser contada.
Determinar a contagem de pontos de função não ajustados Essa contagem leva em conta dois tipos de função: de dados e transacionais, bem como sua complexidade (simples, média ou complexa).
Contagem das funções de dados Contagem referente às funcionalidades relativas aos requisitos de dados internos e externos à aplicação.
Contagem das funções transacionais Contagem referente às funcionalidades de processamento de dados do sistema fornecidas para o usuário, como entradas e consultas externas.
Determinar o valor do fator de ajuste Baseado em diversas características gerais de sistemas, que avaliam a funcionalidade geral da aplicação que está sendo contada e seus níveis 
de influência que podem ser determinados com base em uma escala de 0 a 5.
Calcular os pontos de função ajustados PFs ajustados são calculados, considerando o tipo de contagem definido no primeiro passo.
Tabela 1. Fases para a medição por pontos de função
SEI (Software Engineering Institute) definiu uma faixa de 
valores para a CC, que indicam o grau de complexidade de
um algoritmo, conforme mostra a Tabela 2.
Para exemplificar o cálculo da complexidade ciclomática,
será utilizado um algoritmo para cálculo de aprovação de
um aluno. Os possíveis caminhos no algoritmo são nume-
rados, conforme mostra a Figura 2.
Figura 2. Numeração de possíveis caminhos em um algoritmo
Existem diversas formas de cálculo da CC, através de fór-
mulas, ou pela contagem de caminhos possíveis. A Tabela 3
ilustra as possíveis formas de cálculo da complexidade
ciclomática para este algoritmo.
Para programas grandes e complexos, calcular a com-
plexidade ciclomática de cada função pode se tornar uma 
tarefa exaustiva. Por este motivo, ferramentas automatizadas
podem ser utilizadas, como o plugin Metrics for Eclipse 
(ver seção Links), um plugin gratuito para a IDE Eclipse
que calcula a complexidade em sistemas desenvolvidos na 
linguagem Java. A Figura 3 ilustra o cálculo realizado pela
ferramenta.
Complexidade Situação
1-10 Programa simples, baixo risco.
11-20 Programa mais complexo, risco moderado.
21-50 Programa complexo, risco alto.
Maior que 50 Programa não testável, risco elevado.
Tabela 2.���������������������������������������������������������������������������������������������������������
Edição 21 - Engenharia de Software Magazine 53
GERÊNCIA DE PROJ ETOS
Métricas de Chidamber & Kemerer (CK): foram propostas 
por Chidamber & Kemerer em 1994, um conjunto de seis mé-
tricas que permitem a análise quantitativa dos artefatos de 
software construídos utilizando o paradigma da orientação a 
objetos. Essas métricas têm o objetivo de salientar as classes 
que possivelmente contém maior número de defeitos, com o 
propósito de direcionar os esforços de teste.
1. WMC (Weighted methods per class - Métodos ponderados 
por classe): cálculo do número de serviços por classe, que 
pode auxiliar o engenheiro de software indicando o esforço 
necessário para o teste de complexidade da classe. Quando 
classes apresentam um alto WMC, significa que tendem ser 
específicas, ou seja, destinando-se a necessidades individuais, 
o que restringe sua reutilização. 
2. DIT (Depth of the inheritance tree - Profundidade da 
árvore de herança): número máximo de superclasses acima
da classe em questão. Um DIT alto pode indicar que (i) a classe 
em questão herdou muitas características comuns a outras 
classes, indicando que suas superclasses estão preparadas
Forma de cálculo Cálculo
Contagem através dos números de 
arcos e nós
CC = E – N + 2
onde:
E= número de arcos
N= número de nós
Contagem através do número de 
nós predicados (que indicam uma 
decisão)
CC = P + 1
onde:
P= número nós predicados (decisões)
Contagem visual Através do número de regiões fechadas do gráfico 
construído, considerando também a região externa
Contagem dos caminhos possíveis CC = 5
1, 2, 10
1, 3, 4, 10
1, 3, 5, 6, 10
1, 3, 5, 7, 8, 10
1, 3, 5, 7, 9, 10
Tabela 3. Formas para cálculo da Complexidade Ciclomática
Figura 3.Cálculo da complexidade ciclomática no plugin Metrics for Eclipse
para reutilização, visto que provavelmente possuem alto 
nível de abstração, (ii) pode indicar que a classe herda mui-
tos serviços, o que pode aumentar consideravelmente sua 
complexidade.
3. NOC (Number ofchildren - Número de filhos): número 
de subclasses posicionadas imediatamente abaixo da classe 
em questão. Um NOC alto indica que uma superclasse possui 
muitos filhos que necessitaram implementar características 
próprias, demonstrando baixo nível de abstração, visto que 
podem existir poucas características em comum entre as 
classes filhas. A Figura 4 exibe uma hierarquia de classes, 
que demonstra um NOC de valor três. Pode-se observar que 
quanto maior o número de métodos e atributos especializados, 
menores são as chances de reutilização das classes filhas e 
mais complexas ficam as operações de polimorfismo. Em uma 
situação simples, como a do exemplo, o valor NOC não tem 
impacto negativo sobre o sistema, porém caso o cenário seja 
um sistema complexo com muitas classes “filhas”, é importante 
acompanhar os valores de NOC, com o propósito de tomar 
medidas que evitem números altos.
Figura 4.������������������������������������������������������
4.CBO (Coupling between object classes - Acoplamento 
entre classes de objetos): é o nível de acoplamento entre as 
classes. Um CBO alto indica que a classe possui muitos rela-
cionamentos, o que dificulta sua reutilização e aumenta sua 
complexidade, visto que a classe torna-se dependente de outras 
para efetuar suas operações. Essa métrica auxilia o engenheiro 
de software a avaliar o nível de reaproveitamento da aplicação 
e o esforço despendido em testes.
5.LCOM (Lack of cohesion in methods - Falta de coesão em 
métodos): Número de acessos a um ou mais atributos em co-
mum pelos métodos da própria classe. Quanto maior o LCOM, 
menos coesa é a classe. A coesão em métodos é a capacidade 
dos métodos realizarem apenas a função a que são destinados 
e, para isso devem acessar apenas atributos essenciais ao seu 
funcionamento. Portanto, é importante que o LCOM seja baixo 
a fim de aumentar a reutilização e diminuir a complexidade 
da classe.
54 Engenharia de Software Magazine - Métricas de Software
6.RFC (Response for a class - Resposta de uma classe): 
Indica a capacidade de resposta que a classe tem ao receber 
mensagens de seus objetos (conjunto resposta). É o número de 
métodos que podem ser chamados em resposta a uma mensa-
gem recebida por um objeto ou por algum método da classe. 
Quanto maior o RFC, maior a possibilidade da classe atender 
às suas funções. Em contrapartida, para obter um RFC alto, 
é necessário projetar uma estrutura de classes adequada que 
possa tender a essa particularidade, o que acaba gerando maior 
complexidade, tornando necessário maior esforço de teste.
Métricas de Lorenz & Kidd: Lorenz & Kidd, também em 1994, 
propuseram um conjunto de quatro métricas, comumente cha-
madas métricas LK, que se baseiam assim como as métricas 
CK, no cálculo quantitativo de alguns aspectos fundamentais 
da Orientação a Objetos, como os atributos, métodos, herança, 
coesão e acoplamento. A diferença entre as métricas LK e as 
métricas CK é em relação à metodologia empregada em seu 
cálculo.
1.CS (Class size - Tamanho da classe): é o número de métodos 
e atributos da própria classe e herdados de suas superclasses. 
Um número alto de CS indica que a classe pode ser muito espe-
cífica, atendendo necessidades privadas, o que pode dificultar 
sua reutilização e aumentar sua complexidade.
2.NOO (Number of operations overriden by a subclass
- Número de operações redefinidas por uma subclasse): 
número de sobrescritas de métodos em subclasses. Os 
métodos herdados de uma superclasse podem ser sobres-
critos, ou seja, redefinidos em subclasses, com o propósito 
de tornar sua funcionalidade mais específica. De certa
forma, essa redefinição de métodos pode ferir a abstração 
implícita da superclasse e um número elevado de NOO 
pode indicar problemas estruturais, pois muitas subclas-
ses do sistema têm métodos redefinidos e possivelmente
estão hierarquicamente mal projetadas. Utilizando ainda 
o exemplo da Figura 4, nas Listagens 1, 2 e 3 pode-se ob-
servar trechos de código das três classes (Gerente, Diarista
e Vendedor), que redefinem o método calculaSalario(). As
classes Gerente e Vendedor também redefinem o método
getCargo(), e ainda,a classe Vendedor redefine o método 
getDepartamento(). Apesar de não representar um risco 
estrutural para o projeto, no caso do exemplo, o número 
de métodos redefinidos indica quais classes devem ter sua 
evolução acompanhada. Em um projeto de grande porte e 
crítico, pode ser complicado reestruturar uma hierarquia
de classes no meio do projeto e o NOC indica que classes
possivelmente devem ser reestruturadas o quanto antes. A
Figura 5 apresenta o resultado da coleta dessa métrica com 
a ferramenta Metrics for Eclipse.
3. NOA (Number of operations added by a subclass - Número 
de operações adicionadas por subclasse): número de métodos 
e atributos definidos em uma subclasse. Um NOA alto quer 
Figura 5. Coleta da Métrica NOO pela ferramenta Metrics for Eclipse, aqui 
chamada de Number of Overridden Methods
Listagem 1.��������������������������������������������������������������������
public String getCargo (){
return “Gerente”;
}
public double calculaSalario(){
double taxaTotal=(getSalario()*taxaDependentes)*numDependentes;
return getSalario()-getDesconto() + taxaTotal; 
}
Listagem 2.������������������������������������������������������
public double calculaSalario(){
return horasTrabalhadas * valorHora;
}
Listagem 3.����������������������������������������������������������
redefinidos na classe Vendedor
public Departamento getDepartamento(){
return new Departamento(Departamento.VENDAS);
}
public String getCargo(){
return “vendedor”;
}
public double calculaSalario(){
return (getSalario()- getDesconto())+(numeroVendas * 
comissaoPorVenda);
}
dizer que a subclasse adicionou muitos métodos e atributos 
em sua definição, o que indica um problema estrutural, já que 
boa parte de seus atributos deveria ser definida em super-
classes. Além de aumentar a complexidade do sistema como 
um todo, um valor elevado de NOA reduz as possibilidades 
de reutilização. 
4. SI (Specialization index - Índice de especialização): nú-
mero de métodos adicionados, eliminados ou redefinidos em 
uma classe. Na verdade, essa métrica complementa as métricas 
NOO e NOA e um valor alto indica também um problema de 
estruturação de classes, já que possivelmente foram realizadas 
alterações para atendimento de necessidades específicas. Clas-
ses muito específicas dificilmente são reaproveitadas, ferindo 
um dos princípios básicos da OO, a reutilização.
A seguir, são apresentadas na Figura 6 as possíveis mé-
tricas coletadas de um fragmento de sistema de controle de
Recursos Humanos, através da ferramenta Metrics for Eclipse, 
para demonstrar como é simples e rápida a coleta de um
conjunto significativo de métricas através de ferramentas 
automatizadas.
Edição 21 - Engenharia de Software Magazine 55
GERÊNCIA DE PROJ ETOS
Alguns outros tipos de métricas
Diversos outros tipos de métricas são largamente utilizados, 
como métricas de confiabilidade e esforço. 
Métricas de confiabilidade são normalmente baseadas em 
número de defeitos apresentados por uma aplicação, poden-
do ser medidas por intervalo de tempo ou por versão de um 
produto em uso. Nessa categoria, ferramentas de apoio como 
BugZilla, Mantis ou Trac são boas aliadas para o registro e 
acompanhamento de defeitos.
Métricas de esforço são importantes no acompanhamento de 
processos de software, sendo comumente utilizada a medição 
de esforço por Homem/Hora, ou alguma derivada desta, como 
Homem/Mês, que refletem a quantidade de recursos humanos 
alocados ao projeto por unidade de tempo.
Conclusão
Métricas de software são medidas quantitativas acerca de 
processos ou produtos de software. O artigo procurou mostrar 
Figura 6. Métricas coletadas pela ferramenta Metrics forEclipse
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê
se
u F
eedback
so
b
re
estaedição
algumas das métricas mais conhecidas e exemplificar o uso 
de algumas delas através de exemplos simplificados, com o 
propósito de acentuar a importância de sua utilização em um 
projeto. As métricas são capazes de indicar pontos em que 
são necessários maiores esforços de teste e acompanhamento. 
Através de ferramentas automatizadas, é possível coletar um 
grande número de métricas com menor esforço, o que viabi-
liza a implantação de processos de medição em qualquer tipo 
de sistema, desde os mais simples até os mais críticos, o que 
contribui para a qualidade do produto final.