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
Métricas de Software
Como utilizá-las no gerenciamento de projetos 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).
50 Engenharia de Software Magazine - Métricas de Software
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.
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,
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.
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

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
GERÊNCIA DE PROJ E TOS
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áticas aplicadas 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
Edição 21 - Engenharia de Software Magazine 51
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
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.

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

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. ������ �� ������������ ������������ ������ ��� � �������� ����������� ��������� �������� ����������������

52 Engenharia de Software Magazine - Métricas de Software


Forma de cálculo Cálculo
Contagem através dos números de CC = E – N + 2
arcos e nós onde:
E= número de arcos
N= número de nós
Contagem através do número de CC = P + 1
nós predicados (que indicam uma onde:
decisão) 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
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
GERÊNCIA DE PROJ E TOS
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 of children - 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.
Edição 21 - Engenharia de Software Magazine 53
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
54 Engenharia de Software Magazine - Métricas de Software
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);
}
Figura 5. Coleta da Métrica NOO pela ferramenta Metrics for Eclipse, aqui
chamada de Number of Overridden Methods
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.

Figura 6. Métricas coletadas pela ferramenta Metrics for Eclipse
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
GERÊNCIA DE PROJ E TOS
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.
Feedback
Dê seu feedback sobre esta edição! eu
Dê
s
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 21 - Engenharia de Software Magazine 55