MÓDULO 3 – Gerência de Projeto de Software – Métricas de Software

RESUMO
Este módulo estabelece a primeira atividade da gerência de projeto de software: as
métricas de software.

OBJETIVO
Compreender o que são métricas de software, para que servem e quais são elas.
Ao final deste módulo, o aluno deverá ser capaz de calcular vários tipos de métrica para
um projeto de software.

CONTEÚDO
Como já foi estudado anteriormente, antes que um projeto de software possa ser
planejado, os objetivos e o escopo devem ser estabelecidos, soluções alternativas devem
ser consideradas e as restrições administrativas e técnicas identificadas. Se essas
informações não existem será impossível definir as estimativas de custo, a divisão das
tarefas entre os membros da equipe e o cronograma. Assim que o escopo e os objetivos
forem definidos na etapa de Especificação de Requisitos do ciclo de vida, as soluções
alternativas poderão ser estudadas. Assim, a “melhor” solução poderá ser adotada de
acordo com as restrições de prazos, orçamento, pessoal disponível, entre outros fatores.
Realizar Medidas e estabelecer Métricas do Software é importante uma vez que
ajudam a entender o processo técnico usado para desenvolver um produto. O processo é
medido num esforço para melhorá-lo, enquanto que o produto é medido a fim de melhorar
sua qualidade.
As principais razões para se medir o software são:
Indicação da qualidade do produto;
Avaliação da produtividade dos que desenvolvem o produto;
Determinação dos benefícios derivados de novos métodos e ferramentas de
engenharia de software;
Formação de uma base para as estimativas;
Auxílio na justificativa de aquisição de novas ferramentas ou de treinamentos
adicionais.

As medições podem ser divididas em 2 categorias:

Medidas Diretas: por exemplo, o comprimento de um parafuso;
Medidas Indiretas: por exemplo, a qualidade dos parafusos produzidos, em
função da contagem dos parafusos rejeitados. A Tabela 2 lista exemplos
de medidas Diretas e Indiretas de Software:

Tabela 2: Exemplos de medidas Diretas e Indiretas de Software.

Exemplos Medidas Diretas Exemplos Medidas Indiretas
Custo Funcionalidade
Esforço Qualidade
Linhas de Código (LOC) Complexidade
Velocidade de Execução Eficiência
Memória Confiabilidade
Número de Erros Manutenibilidade

Porém outras classificações podem ser feitas com relação a essas medidas:
 Métricas da Produtividade: enfocam a saída do processo de desenvolvimento
de software;
Métricas da Qualidade: enfocam a conformidade com os requisitos implícitos
e explícitos do usuário;
Métricas Técnicas: enfocam características do software (complexidade,
modularidade);
Métricas Orientadas ao Tamanho: computam medidas diretas do software;
Métricas Orientadas à Função: computam medidas indiretas do software;
Métricas Orientadas a Seres Humanos: consideram a atuação das pessoas;
seus relacionamentos com ferramentas e métodos.
Concentraremos nossas atenções agora nas Métricas Orientadas ao Tamanho e à
Função. As outras métricas serão discutidas mais adiante quando abordarmos os
assuntos Testes e Validação (mais adiante) e Garantia da Qualidade de Software (na
disciplina Engenharia de Software 2).

Métricas Orientadas ao Tamanho

São derivadas de medidas diretas (Ex. LOC – linhas de código,KLOC – milhares de

linhas de código) do software e do processo através do qual ele é desenvolvido. Se uma
empresa mantiver registros simples sobre esses dados, terá um histórico das métricas de
cada projeto de desenvolvimento de software dos últimos anos (Exemplo 1).
A partir dos dados contidos nesses registros é possível derivar várias métricas de
qualidade e produtividade orientadas ao tamanho, contidas na Tabela 3:

Tabela 3: Métricas Orientadas ao Tamanho.

PRODUTIVIDADE = KLOC / pessoas-mês
QUALIDADE = erros / KLOC
CUSTO = $ / KLOC
DOCUMENTAÇÃO = pags.docum. / KLOC

As métricas orientadas ao tamanho possuem vantagens e desvantagens. As

vantagens são:
Fáceis de serem obtidas;
Existem vários modelos de estimativa baseados em LOC ou KLOC.

As desvantagens são:
LOC depende da linguagem de programação;
Penalizam programas bem projetados, mas pequenos;
Não se adaptam às linguagens não procedimentais;
Difíceis de obter em fase de planejamento.

Métricas Orientadas à Função

São derivadas de medidas indiretas (Ex. PF - Pontos por Função) do software e do

processo através do qual ele é desenvolvido
.
 Concentra-se na funcionalidade ou utilidade do software. Os PFs são derivados
usando uma relação empírica baseada em medidas do domínio de informação e da
complexidade do software.
Pontos por Função é aplicado através de 3 passos:
1) Completar uma tabela com a contagem dos Parâmetros de Medida e atribuir um
fator de ponderação a cada um desses parâmetros;

2) Responder uma lista com 14 questões pré-definidas e atribuir uma pontuação da

influência de cada assunto sobre o software em questão, considerando uma escala
de pontuação 0 a 5;

3) Ajustar os Pontos por Função de acordo com a complexidade do14 sistema, através
da seguinte fórmula: PF = Contagem-Total x 0,65 + 0,01 x (Fi)

Onde Fi: valores de ajuste da complexidade

das 14 perguntas

A partir do Ponto por Função calculado é possível derivar várias métricas de

qualidade e produtividade orientadas à função, contidas na Tabela 4:

Tabela 4: Métricas Orientadas à Função.

PRODUTIVIDADE = PF / pessoas-mês
QUALIDADE = erros / PF
CUSTO = $ / PF
DOCUMENTAÇÃO = pags.docum. / PF

As métricas orientadas à função possuem vantagens e desvantagens. As vantagens

são:
 Independentes da linguagem;
 Ideais para aplicações que usam linguagem não procedimental;
 Baseadas em dados mais fáceis de serem conhecidos durante a evolução do
projeto.


As desvantagens são:
 Cálculo baseado em dados subjetivos;
 Não é uma medida direta; é apenas um número.

“A maioria dos desenvolvedores de software não realiza medições e, infelizmente, a

maioria não tem muita vontade de começar a faze-lo. O problema é cultural. Tentar
compilar medidas quando ninguém as compilava no passado freqüentemente provoca
resistências" [Pressman, 1995]. Por que precisamos fazer isso? Por que é tão importante
medir o processo de engenharia de software e o produto (de software) que ele produz?
Porque se não o medirmos não haverá nenhuma maneira real de determinarmos se
estamos ou não melhorando. Observamos anteriormente, que o software é uma questão
estratégica de negócios para muitas empresas. Se o processo por meio do qual ele é
desenvolvido puder ser melhorado, certamente isso acarretará um impacto positivo na
administração e operação dos negócios. Mas para que planos e metas de melhoria
possam ser estabelecidos é preciso conhecer o que está falho e precisa ser melhorado.
Portanto, a medição é usada para estabelecer baselines de processo a partir da qual as
melhorias possam ser avaliadas.
Baselines são um conjunto de dados históricos de projetos passados de
desenvolvimento de software. Podem ser tão simples quanto a tabela apresentada no
Exemplo 1 ou muito mais complexa se assim for necessário.
Quando se estabelece uma baseline de métricas, benefícios podem ser obtidos em
nível estratégico, técnico e de projeto. Contudo, as informações que são coletadas não
precisam ser fundamentalmente diferentes para satisfazer cada um dos diferentes
componentes discutidos anteriormente. A maneira segundo a qual as informações são
apresentadas será diferente, mas métricas idênticas podem servir a muitos dirigentes.
Para que apresentem benefícios, como redução dos riscos das estimativas, elas
devem ser:
precisas ou próximas de um valor real;
coletadas do maior número de projetos possível;
interpretadas da mesma maneira durante todo o projeto;
suas aplicações devem ser similares às do trabalho que se quer estudar.

EXEMPLO 1
projeto esforço pessoas/mês $ KLOC pags.docum. erros pessoas (Projeto)
projA-01 24 168 12.1 365 29 3
projB-04 62 440 27.2 1224 86 5
projC-03 43 314 20.2 1050 64 6
projD-07 13 164 18.4 750 34 4

Figura 1: Métricas orientadas ao tamanho.

Na Figura 1, pode-se observar para o projeto projA-01 que ele exigiu 24

pessoas/mês trabalhando e consumiu 168 mil dólares (durante todo o processo de
desenvolvimento). Além disso, dessas 24 pessoas/mês, 3 foram necessárias para a etapa
de Projeto do Ciclo de Vida. 12 mil e 100 linhas de código foram geradas e após a entrega
do produto ao cliente 29 erros foram encontrados durante o primeiro ano de utilização.
Para finalizar, 365 páginas de documentação foram geradas.

EXEMPLO 2
Para calcular a produtividade do projA-01, que é uma métrica orientada a tamanho:
PRODUTIVIDADE = KLOC / pessoas-mês
PRODUTIVIDADE projA-01 = 12.100/ 24 = 504,17 loc/pessoas-mês

EXERCÍCIO PROPOSTO 1
Calcule todas as outras métricas orientadas a tamanho para todos os projetos.

EXERCÍCIO PROPOSTO 2
Plote todos os cálculos realizados no exercício anterior em gráficos de produtividade,
qualidade, custo e documentação.

EXERCÍCIO PROPOSTO 3
Compare os resultados. Qual projeto foi o mais produtivo, qual foi o mais caro, qual o
projeto que teve uma maior qualidade? De uma maneira geral qual foi o pior projeto? E o
melhor?
CONSULTAS RECOMENDADAS
Referências Básicas:
Capítulo 02- Pressman, R. S. Engenharia de Software – Makron Books, 1995, 3.ed. São
Paulo, pgs 59 - 82.
Slides de Aula: Aula 4.ppt e Aula 5.ppt
Referências Complementares:
Capítulo 24 (pg. 468 a 473) – Sommerville, I. Engenharia de Software, 6ª.ed., Adisson
Wesley, 2003, São Paulo. Disponível em <http://www.aw.com/sommerville_br>.