Metricas de SW

Prévia do material em texto

MÉTRICAS DE SOFTWARE 1 
Apresentação
 .............................................................................................................................Erro! 
Indicador não definido. 
Aula 1: Fundamentos de métricas e medidas ............................................................................ 
Erro! Indicador não definido. 
 ................................................................................Erro! Indicador não definido. Introdução
 ................................................................................................................................ 7 Conteúdo
Métricas para Software ..................................................................................................... 7 
Por que devemos medir? ................................................................................................. 9 
Quais são as etapas envolvidas? ..................................................................................... 9 
Como garantir que o trabalho seja realizado corretamente? ................................... 9 
Avaliação dos atributos internos do produto ............................................................. 10 
Qualidade de Software ................................................................................................... 10 
Custo do reparo ............................................................................................................... 11 
Curva de falhas para hardware ou curva da banheira ............................................. 11 
Garantia de qualidade ..................................................................................................... 12 
Fatores determinantes para a garantia da qualidade ............................................... 12 
Fatores de qualidade de McCall .................................................................................... 13 
Características operacionais .......................................................................................... 13 
Características de manutenção .................................................................................... 14 
Características de adaptação a novos ambientes ..................................................... 14 
Fatores de Qualidade ISO 9126 ..................................................................................... 15 
Métricas de indicadores e de produto ......................................................................... 15 
Controle do software ...................................................................................................... 16 
O produto e o processo em relação à medição ........................................................ 17 
As estimativas mais importantes .................................................................................. 17 
Métricas do processo ...................................................................................................... 17 
Métricas do produto ........................................................................................................ 18 
Métricas diretas e métricas indiretas............................................................................ 19 
Métricas orientadas ao tamanho .................................................................................. 19 
Métricas orientadas à função ........................................................................................ 20 
Princípios de medição .................................................................................................... 20 
Atributos de métricas eficazes de software ................................................................ 20 
Atividade Proposta........................................................................................................... 22 
Erivelto
Realce
Erivelto
Realce
Erivelto
Realce
 
 MÉTRICAS DE SOFTWARE 2 
........................................................................................................................... 22 Referências
 ......................................................................................................... 22 Exercícios de fixação
Aula 2: Pontos por Função ......................................................................................................... 30 
 ........................................................................................................................... 30 Introdução
 .............................................................................................................................. 31 Conteúdo
Métricas baseadas em função ou Pontos por Função (PF)...................................... 31 
Valores do domínio de informações ........................................................................... 31 
Valores do domínio de informações – Tabela de PF ................................................ 32 
Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA) ........................ 33 
Exemplo de Diagrama de Fluxo de Dados (DFD) simples ........................................ 36 
Cálculo dos Pontos por Função .................................................................................... 38 
Método para estimativa de custo – exemplo SERPRO ............................................. 38 
Contagem de Pontos por Função de Projetos de Manutenção ............................. 40 
Pontos de Casos de Uso (PCU) ..................................................................................... 40 
Calculando o peso dos Atores do Sistema ................................................................. 41 
Atividade Proposta........................................................................................................... 41 
 ....................................................................................................................... 42 Aprenda Mais
........................................................................................................................... 42 Referências
Exercícios de fixação ......................................................................................................... 42 
 
Aula 3: Determinação de Ponto por Função .............................................................................. 49 
 ........................................................................................................................... 49 Introdução
 .............................................................................................................................. 50 Conteúdo
Contextualização ............................................................................................................. 50 
Fan-out e Fan-in .............................................................................................................. 51 
Fan-out e Fan-in: características .................................................................................. 51 
Métricas de projeto da arquitetura ............................................................................... 53 
Indicadores de qualidade de software ........................................................................ 55 
Métricas para projeto orientado a objeto ................................................................... 57 
Métricas orientadas a classe — o conjunto de métricas CK .................................... 59 
Atividade Proposta........................................................................................................... 61 
........................................................................................................................... 61 Referências
 ......................................................................................................... 61 Exercícios de fixação
 
Aula 4: Estimativa de esforço e prazo ....................................................................................... 68 
 ...........................................................................................................................68 Introdução
 
 MÉTRICAS DE SOFTWARE 3 
 .............................................................................................................................. 69 Conteúdo
COCOMO .......................................................................................................................... 69 
COCOMO básico .............................................................................................................. 69 
Exemplos de COCOMO básico ..................................................................................... 70 
COCOMO intermediário ................................................................................................. 73 
COCOMO avançado ........................................................................................................ 76 
COCOMO avançado: Spider-CoCoMo ........................................................................ 76 
COCOMO II ....................................................................................................................... 78 
Método de Putnam .......................................................................................................... 79 
Complexidade ciclomática ............................................................................................ 79 
Complexidade ciclomática ............................................................................................ 80 
Conclusões........................................................................................................................ 81 
Atividade Proposta........................................................................................................... 81 
........................................................................................................................... 81 Referências
 ......................................................................................................... 81 Exercícios de fixação
Conteudista ..........................................................................................................................88 .
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 MÉTRICAS DE SOFTWARE 4 
 
 
 
Qualquer empresa nasce com o sonho de ser bem-sucedida, mas nem todas 
são vencedoras, e algumas até morrem antes de completar seu primeiro ano. 
Empresas de sucesso são aquelas que trabalham com foco na gestão da 
qualidade e do conhecimento. 
 
No caso de PROJETO, verificamos que o gerenciamento é necessário, mas não 
podemos gerenciar aquilo que é impossível medir. 
 
A gestão do desenvolvimento, da manutenção e da prestação de serviços 
relacionados ao software – que envolve custo, prazo e qualidade – passou, 
então, a ser relevante. Afinal, esses fatores se constituem, hoje, como o 
diferencial entre as empresas. 
 
Plataformas como ITIL, CMMI e MPS-BR colocam as métricas e as medições 
como práticas fundamentais para a gestão de software com padrão de 
qualidade – o que tornou sua medição uma obrigação. 
 
Nesse sentido, esta disciplina pretende desenvolver no profissional da área a 
visão gerencial baseada na preocupação com o custo, a produtividade, a 
qualidade e novas métricas, bem como com suas formas de medição e suas 
limitações. 
 
 
 MÉTRICAS DE SOFTWARE 5 
É muito importante que você conheça as técnicas de gerenciamento de projeto 
de software e saiba estabelecer parâmetros para futuras medições. 
 
Sendo assim, esta disciplina tem como objetivos: 
1. Definir medida e métrica de software; 
2. Identificar as formas de medição, de estimativa e de acompanhamento de 
um projeto de software, bem como os parâmetros para futuros projetos; 
3. Descrever as métricas mais usuais para fins de medição do esforço no 
desenvolvimento de um software. 
 
 
 MÉTRICAS DE SOFTWARE 6 
 
Introdução 
Você terá oportunidade de desenvolver os Conceitos de métricas e medições 
para software, medidas diretas e indiretas, medidas no software pronto (kloc). 
Toda empresa já nasce com o “sonho de ser bem-sucedida”, porém muitas 
delas nem chegam a completar seu primeiro ano. Empresas de sucesso são 
aquelas que estão trabalhando com foco na gestão da qualidade e do 
conhecimento. No entanto, não se pode gerenciar o que não se pode medir. 
Assim, plataformas como ITIL, CMMI, MPS-BR e outras, colocam as métricas e 
medições como práticas fundamentais para a gestão de software com padrão 
de qualidade. 
 
A qualidade tornou a medição do software nos seus diversos aspectos uma 
obrigação. Deve-se desenvolver no profissional de software a visão gerencial, 
assim como a preocupação com custo, produtividade, qualidade e novas 
métricas, suas formas de medição e suas limitações. Ele deve conhecer 
conceitos para medir o software (produtividade, qualidade, prazo, tamanho 
etc.) desde a fase de especificação de requisitos. Para tal, deve conhecer 
técnicas e ferramentas em suas medidas nas diversas fases do projeto. 
Preparado para iniciar a aula? Bons estudos! 
 
Objetivo: 
1. Compreender os conceitos das métricas e das medições de software; 
2. Entender o que envolve a qualidade de software. 
 
 
 MÉTRICAS DE SOFTWARE 7 
Conteúdo 
Métricas para Software 
Então, o próprio 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 
 
 MÉTRICAS DE SOFTWARE 8 
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. 
 
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. 
 
 
Atenção 
 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. 
 
 
 MÉTRICAS DE SOFTWARE 9 
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? 
O primeiro passo no processo de medição é definir as métricas apropriadas 
para o software. 
 
Em seguida, coletam-se os dados necessários para aplicar as métricas 
formuladas. 
 
Uma vez computadas, as métricas são analisadas com base em diretrizes 
preestabelecidas e dados do passado. 
 
Os resultados das análises são interpretados para obter informações 
sobre a qualidade do software. 
 
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 DE SOFTWARE 10 
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. 
 
 MÉTRICAS DE SOFTWARE 11 
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. 
 
 
 
Curva de falhas para hardware ou curva da banheira 
 
 
 
 MÉTRICAS DE SOFTWARE 12 
 
 
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: 
 
 Métodos e ferramentas de análise, projeto, codificação e teste; 
 Revisões técnicas em cada fase do desenvolvimento; 
 Estratégia de teste; 
 Documentação de software e das mudanças efetuadas; 
 Padrões de desenvolvimento de software; 
 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. 
 
 MÉTRICAS DE SOFTWARE 13 
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. 
 
 
 
 
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? 
 
 
 MÉTRICAS DE SOFTWARE 14 
Integridade 
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? 
 
 
 
 
 MÉTRICAS DE SOFTWARE 15 
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ÉTRICAS DE SOFTWARE 16 
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. 
 
 
 
 
 
 MÉTRICAS DE SOFTWARE 17 
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: 
 
 Esforço humano exigido 
 Duração do projeto 
 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 e manutenção. 
 
 MÉTRICAS DE SOFTWARE 18 
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.). 
 
 
Atenção 
 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 DE SOFTWARE 19 
 
 
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. 
 
 
 
 MÉTRICAS DE SOFTWARE 20 
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. 
 
 MÉTRICAS DE SOFTWARE 21 
Pressman (Engenharia de Software) elege atributos que deverão ser abrangidos 
por métricas. 
 
 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. 
 
 MÉTRICAS DE SOFTWARE 22 
 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. 
 
Atividade Proposta 
Discuta sobre a importância da adoção de métricas no processo de qualidade 
de software. 
 
Chave de resposta: O processo de desenvolvimento de software deve ter o 
foco na qualidade. 
 
Referências 
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çãomedição, estimativa e gerenciamento de projetos de software. São 
Paulo: Editora Érica, 2009. 
 
Exercícios de fixação 
Questão 1 
Segundo Pressman, “Qualidade de software é a satisfação de requisitos 
funcionais e de desempenho explicitamente declarados, normas de 
desenvolvimento explicitamente documentadas e características implícitas que 
são esperadas em todo software desenvolvido profissionalmente”. Analise as 
afirmativas a seguir, relacionadas a software: 
I. Falta de conformidade com os requisitos é falta de qualidade; 
II. Os fatores de qualidade de Mc Call estão relacionados com operação, revisão 
e transição de software; 
 
 MÉTRICAS DE SOFTWARE 23 
III. Portabilidade – Facilidade com que o software pode ser transposto de um 
ambiente para outro. 
Agora assinale a alternativa correta: 
a) Todas as afirmativas estão corretas 
b) Apenas a afirmativa III está correta 
c) Apenas a afirmativa II está correta 
d) Apenas as afirmativas I e III estão corretas 
e) Apenas as afirmativas II e III estão corretas 
 
Questão 2 
A avaliação qualitativa não é suficiente para medir o esforço do software. É 
preciso critérios objetivos para direcionar o projeto de dados, arquitetura, 
interfaces e componentes. Ao testarmos, necessitamos de orientação 
quantitativa que nos auxiliará na seleção de casos de teste. 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 
quantitativa. Sendo assim, devemos medir: 
I. Para sabermos quanto cobrar. 
II. Para conseguirmos dar prazos; 
III. Para definirmos a equipe; 
IV. Para definirmos a complexidade; 
V. Para definirmos o tamanho. 
a) Todas as afirmativas estão corretas 
b) Estão corretas apenas as afirmativas I, III e IV 
c) Estão corretas apenas as afirmativas I, II, III e V 
d) Estão corretas apenas as afirmativas I, II, III e IV 
e) Estão corretas apenas as afirmativas II, III, IV e V 
 
Questão 3 
Ninguém tolera erros, por isso o desenvolvimento de software tem que ter 
garantia de qualidade. Ele envolve uma série de atividades em que as 
oportunidades de falhas são muito grandes e, consequentemente, os erros 
 
 MÉTRICAS DE SOFTWARE 24 
podem aparecer no início do processo. Isso se deve a alguns fatores, exceto 
(assinale a alternativa INCORRETA): 
a) Bom planejamento de teste 
b) Objetivos mal definidos 
c) Erros na fase de projeto 
d) Planejamento malfeito 
e) Requisitos mal definidos 
 
Questão 4 
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 abrange, 
exceto (assinale a alternativa INCORRETA): 
a) Dispensa de documentação de software e das mudanças efetuadas 
b) Métodos e ferramentas de análise, projeto, codificação e teste 
c) Estratégia de teste 
d) Padrões de desenvolvimento de software 
e) Mecanismos de medição 
 
Questão 5 
Segundo Roger Pressman, o gerenciamento de testes é um processo 
fundamental para obter qualidade no software. Analise as afirmativas: 
I. “O teste é o último reduto no qual a qualidade pode ser avaliada”; 
II. “Você não pode testar qualidade. Se ela não estiver lá antes, ela não estará 
lá quando terminar de testar”; 
III. “Otimismo é o risco ocupacional da programação; teste é o tratamento”; 
IV. “A qualidade de um software é função de quanto ele muda o mundo para 
melhor”. 
a) Todas as afirmativas estão corretas 
b) Estão corretas apenas as afirmativas I, III e IV 
c) Estão corretas apenas as afirmativas I, II e III 
d) Estão corretas apenas as afirmativas I, II e IV 
 
 MÉTRICAS DE SOFTWARE 25 
e) Estão corretas apenas as afirmativas II, III e IV 
 
Questão 6 
Assinale a alternativa correta: 
a) Na engenharia de software não existe diferença entre medição e medida. 
b) Considerando o tempo de existência, a engenharia de software e a 
engenharia civil se equivalem em maturidade. 
c) Uma métrica mal especificada não gera qualquer influência para tomada 
de decisão de baixa qualidade. 
d) pesar de existirem métricas de processo e de projeto, não existem 
métricas de produto. 
e) Medida é diferente de métrica e pode ser realizada de forma direta ou 
indireta. 
 
Questão 7 
No contexto de engenhada de software, medida pode ser definida como: 
a) O ato de determinar uma medida. 
b) Proporciona uma indicação quantitativa da extensão, quantidade, 
capacidade ou tamanho de algum produto ou processo. 
c) É um conceito matemático relacionado à distância de um módulo ao 
seguinte. 
d) É a divisão de um software em fragmentos marcados por tempo e custo. 
e) É um conceito relacionado à gerência de projetos. 
 
Questão 8 
O processo de desenvolvimento de software deve ser continuamente medido 
durante seu desenvolvimento. Para isso é necessário: 
I. Criar uma “cultura” de medição e métrica (desenvolvimento com bases 
técnicas); 
II. Catalogar em base de dados históricos; 
III. Padronizando em metros ou centímetros, cada medida obtida. 
a) Completam o enunciado as afirmativas I e II 
 
 MÉTRICAS DE SOFTWARE 26 
b) Completam o enunciado as afirmativas I e III 
c) Completam o enunciado as afirmativas II e III 
d) Completa o enunciado apenas a afirmativa I 
e) Completa o enunciado apenas a afirmativa II 
 
Questão 9 
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. São medidas em Quilo de Linhas de 
Código ou mil linhas (KLOC). 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. Analise as afirmativas sobre KLOC e responda: 
I. É fácil de calcular; 
II. É um fator importante para muitos modelos de estimativa; 
III. Depende da linguagem de programação; 
IV. Penalizam programas bem estruturados, porém mais curtos. 
a) Estão corretas as afirmativas I, III e IV 
b) Estão corretas as afirmativas I, II e III 
c) Estão corretas as afirmativas I, II e IV 
d) Estão corretas as afirmativas II, III e IV 
e) Todas as afirmativas estão corretas. 
 
Questão 10 
A estimativa é uma das principais atividades do planejamento de software. 
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. Com relação às estimativas de software 
marque a afirmativa correta (forma completa): 
a) Para uma aplicação existente ou nova desejamos saber quanto tempo 
será necessário para o desenvolvimento e também quanto é o custo. 
b) Para uma nova aplicação desejamos saber quanto tempo será necessário 
para fazer. 
 
 MÉTRICAS DE SOFTWARE 27 
c) Para uma aplicação existente desejamos saber quanto tempo será 
necessário para fazer uma alteração. 
d) Para uma aplicação existente desejamos saber qual o custo de uma 
alteração. 
e) Para uma nova aplicação desejamos saber qual o custo da aplicação. 
 
Aula 1 
Exercícios de fixação 
Questão 1 - A 
Justificativa: Software que não segue os requisitos não oferece qualidade; O 
fatores de Mc Call são exatamente operação, revisão e transição de software; A 
portabilidade é uma exigência hoje, o que permite que o software possa ser 
executado em mais de um sistema operacional. 
 
Questão 2 - A 
Justificativa: Para determinarmos o esforço empregado no software devemos 
medir custo, prazo, recursos físicos e pessoas, a complexidade e o tamanho. 
Portanto, todas as afirmativas estão corretas. 
 
Questão 3 - A 
Justificativa: No início do desenvolvimento devemos aplicar a característica da 
abstração, isto é, nos preocuparmos com o que é mais importante para o 
momento como, por exemplo, a definição clara dos objetivos e dos requisitos e 
a elaboraçãode um bom planejamento do projeto, e deixar alguns detalhes 
para mais adiante. O planejamento de implantação e disponibilização do 
software deve ser feito em outra etapa. 
 
Questão 4 - A 
Justificativa: Um dos requisitos da qualidade do software é a documentação. 
Software sem documentação se distancia das normas de qualidade. Qualidade 
 
 MÉTRICAS DE SOFTWARE 28 
de software inclui padrões de medição e uso adequado de ferramentas de 
desenvolvimento, implementação e teste. 
 
Questão 5 - A 
Justificativa: Todas as afirmativas estão registradas em “Engenharia de 
Software” de Roger Pressman (6ª Ed. p. 340-350). 
 
Questão 6 - E 
Justificativa: Podemos ter medidas diretas como número de linhas de código 
produzidas ou velocidade de execução e medidas indiretas como qualidade, 
funcionalidade, complexidade. 
A opção “a” está errada, pois medição é um processo, já medida é usada para 
avaliar a qualidade do produto. 
A opção “b”: engenharia civil existe há milênios. 
A opção “c”: métrica mal especificada afeta a qualidade do produto. 
A opção “d”: Os engenheiros de software usam métricas de produto para 
ajudá-los a criar software da mais alta qualidade. 
 
Questão 7 - B 
Justificativa: Medida é a quantificação de algo que se quer medir. Por exemplo: 
o tamanho do software em KLOC ou pontos por função. É um conceito 
matemático, porém, não para medir distância entre módulos e nem a divisão de 
um software. 
 
Questão 8 - A 
Justificativa: Criar uma cultura de medição de software e registrar os dados 
históricos para que possam ser utilizados em projetos futuros são contribuições 
para a qualidade do software. O software jamais será medido em metros ou 
centímetros. 
 
 
 
 
 MÉTRICAS DE SOFTWARE 29 
Questão 9 - E 
Justificativa: KLOC é uma métrica orientada ao tamanho e de fácil obtenção e 
independente da linguagem usada. pois bastar contar o número de linhas, 
exceto os comentários. Por outro lado, programas orientados a objetos e bem 
estruturados são penalizados por esta métrica. 
 
Questão 10 - A 
Justificativa: Todas as afirmativas são verdadeiras, porém, a mais completa é a 
que fala em tempo e custo, isto é, a opção “a”. 
 
 
 MÉTRICAS DE SOFTWARE 30 
 
Introdução 
Nesta aula, você compreenderá como devem ser usadas as seguintes métricas: 
Pontos por Função (PF); Ponto por Função Não Ajustado (PFNA); Pontos por 
Função para Diagrama de Fluxo de Dados (DFD) simples; Método para 
Estimativa de Custo; Contagem de Pontos por Função de Projetos de 
Manutenção; Pontos de Casos de Uso (PCU); e Peso dos Atores do Sistema. 
 
Essa abordagem é muito importante devido à necessidade de justificar prazos e 
custos do software. 
 
Bons estudos! 
 
Objetivo: 
1. Identificar os Pontos por Função; 
2. Compreender a aplicação dos Pontos por Função. 
 
 
 MÉTRICAS DE SOFTWARE 31 
Conteúdo 
Métricas baseadas em função ou Pontos por Função (PF) 
Para que servem os Pontos por Função? 
 
Pontos por Função medem o tamanho funcional do software. 
 
Da mesma forma que somente os metros quadrados são insuficientes para 
administrar uma construção, PF são insuficientes para administrar um projeto 
de SW. 
 
Para que servem as métricas Pontos por Função? 
 
A métrica Ponto por Função pode ser usada efetivamente como um meio para 
medir a funcionalidade fornecida por um sistema. Por meio de dados históricos, 
a métrica FP pode ser empregada para: 
 
 Estimar o custo necessário para projetar, codificar e testar o software; 
 Prever o número de erros que serão encontrados durante o teste; 
 Prever o número de componentes e/ou o número de linhas projetadas 
de código-fonte no sistema implementado. 
 
Valores do domínio de informações 
A métrica Pontos por Função está baseada em medidas calculáveis (diretas) do 
domínio do software e avaliações qualitativas da complexidade do software. 
Valores do domínio de informações são definidos da seguinte maneira: 
 
Entradas externas (number of external inputs - EEs): cada entrada 
externa é originada de um usuário ou transmitida de outra aplicação e fornece 
dados distintos orientados à aplicação ou informações de controle. 
 
Arquivos lógicos internos (internal logic files - ILFs): as entradas devem 
ser diferenciadas das consultas, que são contadas separadamente. Cada 
 
 MÉTRICAS DE SOFTWARE 32 
arquivo lógico interno é um agrupamento lógico de dados que reside dentro das 
fronteiras do aplicativo e é mantido através de entradas externas. 
 
Saídas externas (number of external outputs - EOs): cada saída externa 
é formada por dados derivados da aplicação e fornece informações para o 
usuário. São relatórios, telas, mensagens de erro etc. 
 
Consultas externas (number of external inquiries - EQs): uma consulta 
externa é definida como uma entrada online que resulta na geração de alguma 
resposta imediata do software na forma de uma saída online. 
 
Arquivos lógicos internos (number of internal logical files ILFs): cada 
arquivo lógico interno é um agrupamento lógico de dados que reside dentro das 
fronteiras do aplicativo e é mantido através de entradas externas. 
 
Arquivos de interface externos (number of external interface files - 
EIFs): cada arquivo de interface externo é um agrupamento lógico de dados 
que reside fora da aplicação, mas fornece informações que podem ser usadas 
pela aplicação. 
 
Valores do domínio de informações – Tabela de PF 
Uma vez coletados os dados, a tabela de PF é preenchida associando um valor 
de complexidade com cada contagem. Organizações que usam métodos Ponto 
por Função desenvolvem critérios para definir se determinada entrada é 
simples, média ou complexa. No entanto, a determinação da complexidade é de 
certo modo subjetivo. Veja o quadro: 
 
 
 MÉTRICAS DE SOFTWARE 33 
 
 
Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA) 
Um software a ser desenvolvido necessita da aplicação da métrica Pontos por 
Função. Segundo a equipe de desenvolvimento, a seguinte relação foi 
determinada ainda na fase de requisitos em consonância com o cliente em 
função dos arquivos que farão parte do software e seus respectivos pesos com 
relação ao PF total. 
 
 
 
Para calcular o PF devemos seguir os seguintes passos: 
 
- Eleger um dos tipos de função, preferencialmente aqueles que representam 
altos percentuais, que são: Arquivos Internos - Entradas Externas - Saídas 
Externas. 
 
- Obter o número de ocorrências do tipo de função eleito. 
 
- Calcular Pontos de Função Não Ajustados (PFNA). 
 
 MÉTRICAS DE SOFTWARE 34 
 
- Utilizar o Fator de Ajuste da Complexidade = 1. 
 
Durante as conversas preliminares com o cliente, verificou-se que os Arquivos 
Internos seriam facilmente identificáveis, o que os credenciou como melhor 
parâmetro para as estimativas de pontos de função. 
 
Verificou-se que o total de Arquivos Internos é 13, portanto, complexidade 
média, segundo a tabela definida pela equipe de desenvolvimento: 
 
 
 
Concluímos que o software é de complexidade Média, pois 13 está na faixa 6 
a 19. Considere este número e veja a seguir a continuidade dos cálculos. 
 
Cálculo do PFNA 
 
a) Como Arquivos Internos representam 25% do total dos PF: 
25% ===> 13 
100% ===> PF 
PF = (13 * 100) / 25 = 52 
 
b) Interfaces Externas: 3% de 52 = 1,56 (~= 2) 
Entradas Externas: 30% de 52 = 15,6 (~= 16) 
Saídas Externas: 28% de 52 = 14,56 (~= 15) 
Consultas: 14% de 52 = 7,28 (~= 7) 
Obs.: os arredondamentos devem obedecer ao padrão. 
 
Tabela do PF 
Podemos preencher a tabela de PF usando a coluna Complexidade Média. 
 
 
 MÉTRICAS DE SOFTWARE 35 
 
 
Cálculo do PFA 
 
Ponto de Função Ajustado (PFA) 
Para calcular Pontos por Função Ajustado, usa-se a seguinte relação: 
 
PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)] 
Onde a contagem total é a soma de todas as entradas FP obtidas da Tabela. 
Os Fi (i = 1 a 14) são fatores de ajuste devalor (value adjustment factors - 
VAF) baseados em respostas a 14 questões. Cada uma dessas perguntas é 
respondida por meio de uma escala que varia de 0 (não importante ou não 
aplicável) a 5 (absolutamente essencial). Observe: 
 
1. O sistema requer salvamento (backup)? 
2. São necessárias comunicações de dados especializadas para transferir 
informações para a aplicação ou da aplicação? 
3. Há funções de processamento distribuído? 
4. O desempenho é crítico? 
5. O sistema rodará em um ambiente operacional existente e intensamente 
utilizado? 
6. O sistema requer entrada de dados on-line? 
7. A entrada on-line de dados requer que a transação de entrada seja 
composta em múltiplas telas ou operações? 
8. Os ILFs (arquivos lógicos) são atualizados on-line? 
9. As entradas, saídas, arquivos ou consultas são complexas? 
10. O processamento Interno é complexo? 
 
 MÉTRICAS DE SOFTWARE 36 
11. O código é projetado para ser reutilizável? 
12. A conversão e Instalação estão incluídas no projeto? 
13. O sistema é projetado para múltiplas Instalações em diferentes 
organizações? 
14. A aplicação é projetada para facilitar a troca e o uso pelo usuário? 
 
Cálculo do PFA após respostas 
Os valores constantes na Equação e os fatores de peso aplicados aos valores do 
domínio de informações são determinados empiricamente. 
 
Dando prosseguimento ao exercício, vamos imaginar que após as respostas às 
14 perguntas, Fi totalizou 42. 
 
Então: 
PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)] 
PFA = 311 x [0,65 + 0,01 x 42] 
PFA = 311 x 1,11 
PFA = 332,77 ~= 333 
 
Avance a tela para acompanhar um exemplo de Diagrama de Fluxo de 
Dados (DFD) simples. 
 
Exemplo de Diagrama de Fluxo de Dados (DFD) simples 
Um software a ser desenvolvido necessita da aplicação da métrica Pontos por 
Função. Segundo a equipe de desenvolvimento, a seguinte relação foi 
determinada ainda na fase de requisitos em consonância com o cliente em 
função dos arquivos que farão parte do software e seus respectivos pesos com 
relação ao PF total. 
 
 
 MÉTRICAS DE SOFTWARE 37 
 
 
O Diagrama de Fluxo de Dados é avaliado para determinar um conjunto-chave 
de medidas de domínio de informação necessárias para a computação da 
métrica ponto de função: 
 
 3 entradas externas — senha, botão de emergência e 
ativar/desativar. 
 2 consultas externas — consulta de zona e consulta de sensor. 
 1 arquivo lógico interno (ILF) — arquivo de configuração do 
sistema. 
 2 saídas externas — mensagens e estado do sensor. 
 4 arquivos de interface externa (EIF) — sensor de teste, 
configuração de zona, ativar/desativar e alerta de alarme. 
 
 
 MÉTRICAS DE SOFTWARE 38 
Cálculo dos Pontos por Função 
 
 
O total da contagem apresentado no quadro Pontos por Função deve ser 
ajustado usando a Equação, supondo que: 
 
∑ (Fi) = 46 
 
Portanto, 
 
FP = 50 X [0,65 X (0,01 X 46)] = 56 
 
Avance e acompanhe o Método para Estimativa de Custo. 
 
Método para estimativa de custo – exemplo SERPRO 
A estimativa de custo do projeto deve levar em consideração o custo da mão de 
obra, considerando o esforço e o custo da hora de todos os profissionais 
envolvidos no desenvolvimento da solução de software. 
 
Além do custo da mão de obra e recursos computacionais, devem ser 
considerados outros custos, tais como: 
 
 MÉTRICAS DE SOFTWARE 39 
 Treinamento 
 Consultoria 
 Viagens 
 Licenças de software 
 Custos indiretos etc. 
 
Cálculo Custo do Projeto (CP) 
Sugere-se a seguinte fórmula para calcular o custo relativo à mão de obra para 
o desenvolvimento da solução (CP – Custo do Projeto). 
 
CP = (QHC x VPC) + (QHA x VPA) + (QPF x EPF x VPA) + Outros 
Custos 
Onde: 
 
 QHC = Quantidade de Horas do Consultor 
 VPC = Valor da Hora do Consultor 
 QHA = Quantidade de Horas do Analista 
 VPA = Valor da Hora do Analista 
 QPF = Tamanho do Projeto em PF 
 EPF = Esforço para implementar um Ponto por Função na plataforma 
em questão 
 
Cálculo Preço Fixo por Ponto por Função 
 
Caso o contrato seja de preço fixo por Ponto de Função, então pode-se 
considerar o seguinte: 
CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF) 
Onde: 
 
 VPF = Valor Unitário do PF para o projeto em questão - Identificado de 
acordo com a Tabela de Serviço Padrão do Sistema de Orçamento 
Técnico. 
 
 MÉTRICAS DE SOFTWARE 40 
Contagem de Pontos por Função de Projetos de Manutenção 
Para que serve a contagem de Pontos por Função de Projetos de 
Manutenção? 
 
Esta contagem tem como propósito descrever os diversos tipos de projetos de 
manutenção e mostrar uma solução para o seu dimensionamento em Pontos 
por Função, visto que o manual de práticas de contagem não contempla 
projetos de manutenção (maintenance), apenas o de melhoria (enhancement). 
 
Quanto à documentação de projetos de manutenção pequenos (menores que 
100 PF), deve-se registrar a solicitação do cliente e documentar os requisitos da 
aplicação impactada pela demanda, de forma detalhada, visando apoiar a 
contagem de Pontos de Função da demanda. 
 
É importante também documentar as estimativas e a contagem de Pontos por 
Função. 
 
Pontos de Casos de Uso (PCU) 
Quais são as características? 
 
É possível estimar o tamanho do sistema ainda na fase de levantamento de 
casos de uso. 
 
Estima a dimensão do sistema de acordo com: 
 O modo como os usuários o utilizarão; 
 A complexidade de ações requeridas por tipo de usuário; 
 A análise em alto nível dos passos necessários para a realização de cada 
tarefa. 
 
O que é preciso para gerar estimativas com PCU? 
 Calcular o peso dos Atores do Sistema; 
 Calcular o peso dos casos de uso; 
 
 MÉTRICAS DE SOFTWARE 41 
 Calcular fatores de ajuste; 
 Calcular o Porte do Sistema. 
 
Calculando o peso dos Atores do Sistema 
Ações 
 
 Encontrar a métrica UAW (Unadjusted Actor Weight). 
 Classificar atores envolvidos em cada caso de uso. 
 Somar os produtos do número de atores de cada tipo pelo respectivo 
peso. 
 
Quadro Tipo de autor/peso 
 
 
 
Exemplo 
Um sistema projetado para dois tipos de usuários (gerente e usuário comum) e 
que fosse acessado por um outro sistema utilizando-se de um protocolo de 
comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível 
complexo e 1 ator de nível médio). 
 
UAW = (2 * 3) + (1 * 2) 
UAW = 8 
 
Atividade Proposta 
Discuta sobre a importância da adoção de métricas no processo de qualidade 
de software. 
 
 MÉTRICAS DE SOFTWARE 42 
Chave de resposta: O processo de desenvolvimento de software deve ter o 
foco na qualidade. 
 
Aprenda Mais 
 
Material complementar 
 
Para saber mais sobre Pontos por Função, acesse o vídeo 
disponível em nossa biblioteca virtual. 
 
Referências 
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. 
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. 
 
Exercícios de fixação 
Questão 1 
A Métrica de software baseadas em Pontos por Função mede: 
a) O tamanho funcional do software. 
b) A complexidade dos testes de software. 
c) A extensão das sub-rotinas. 
d) A quantidade de classes. 
e) A qualidade do software. 
 
Questão 2 
A métrica Ponto por Função usa dados históricos para: 
I — Estimar o custo necessário para projetar, codificar e testar o software. 
 
 MÉTRICAS DE SOFTWARE 43 
II — Prever o número de erros que serão encontrados durante o teste. 
III — Prever o número de componentes e/ou o número de linhas projetadas de 
código-fonte no sistema implementado. 
a) Todas corretas 
b)Apenas I 
c) Apenas II 
d) Apenas II e III 
e) Apenas I e III 
 
Questão 3 
A métrica Pontos por Função está baseada em medidas calculáveis do domínio 
do software e avaliações qualitativas da complexidade do software. Um dos 
domínios, “Entradas externas”, é definido como: 
a) Originado de um usuário ou transmitido de outra aplicação e fornece 
dados distintos à aplicação ou informações de controle. 
b) Um agrupamento lógico de dados que reside dentro das fronteiras do 
aplicativo. 
c) Um agrupamento lógico de dados que reside fora da aplicação, mas 
fornece informações que podem ser usadas pela aplicação. 
d) Uma entrada online que resulta na geração de alguma resposta imediata 
do software na forma de uma saída online. 
e) Domínio formado por dados derivados da aplicação e que fornece 
informações para o usuário. 
 
Questão 4 
A métrica Pontos por Função está baseada em medidas calculáveis do domínio 
do software e avaliações qualitativas da complexidade do software. Um dos 
domínios, “Arquivos lógicos internos”, é definido como: 
a) Um agrupamento lógico de dados que reside dentro das fronteiras do 
aplicativo. 
b) Entrada originada de um usuário ou transmitida de outra aplicação e que 
fornece dados distintos à aplicação ou informações de controle. 
 
 MÉTRICAS DE SOFTWARE 44 
c) Um agrupamento lógico de dados que reside fora da aplicação, mas 
fornece informações que podem ser usadas pela aplicação. 
d) Uma entrada online que resulta na geração de alguma resposta imediata 
do software na forma de uma saída online. 
e) Domínio formado por dados derivados da aplicação e que fornece 
informações para o usuário. 
 
Questão 5 
Na gestão de escopo de software, três elementos são essenciais em um projeto 
de software. Analise as afirmativas e identifique-as como verdadeiras (V) ou 
falsas (F). 
( ) Após a definição do escopo, não é comum existirem mudanças no 
desenvolvimento de projetos. 
( ) A técnica de reuso de software nunca vai beneficiar a qualidade do 
projeto. 
( ) A técnica de reuso de software colabora para a redução do prazo do 
projeto. 
( ) Mesmo as pequenas mudanças de escopo devem ser registradas e 
analisadas. 
( ) Profissionais que dominam a Análise de Ponto por Função fazem com 
que o cálculo da estimativa de esforço e custo seja uma ciência exata. 
 
Questão 6 
(CESGRANRIO – 2012 – Chesf) Um engenheiro de software fez uma contagem 
de pontos por função de um software a ser desenvolvido e levantou as 
seguintes informações: 
 
 
 
 
 
 
COMPLEXIDADE 
EE – 3 4 6 
SE – 4 5 7 
CE – 3 4 6 
ALI – 7 10 15 
AIE – 5 7 10 
Onde: 
PF = Contagem total x (0,65 + 0,01 x Soma Fi) 
 
 
 MÉTRICAS DE SOFTWARE 45 
 
Considerando as possíveis complexidades de cada função de negócio, os 
valores mínimos e máximos da contagem não ajustada de Pontos por Função 
serão respectivamente: 
a) 143 e 363 
b) 177 e 361 
c) 177 e 363 
d) 179 e 361 
e) 179 e 363 
 
Questão 7 
Em que consiste a modalidade preço por PF (Ponto por Função)? 
a) É o valor global que uma empresa fornecedora está cobrando para um 
determinado serviço. 
b) É o valor unitário negociado com o qual se fará a transação comercial 
para um desenvolvimento de software. 
c) É um valor de referência de custo e que deve participar de um contrato. 
d) É um valor que serve para medir a produtividade de um programador. 
e) É um valor que serve para definir o quanto se pode pagar ao profissional 
contratado (em regime CLT) em uma empresa. 
 
Questão 8 
(FCC – 2012 – TRE-CE) Considere 3 AIEs simples, 5 EEs médias, 8 CEs 
complexas, 3 ALIs complexos e 7 SEs médias. O cálculo de PFs bruto é: 
 
 
 
 
 
a) 136 
b) 148 
c) 159 
COMPLEXIDADE 
EE – 3 4 6 
SE – 4 5 7 
CE – 3 4 6 
ALI – 7 10 15 
AIE – 5 7 10 
 
 MÉTRICAS DE SOFTWARE 46 
d) 163 
e) 212 
 
Questão 9 
A Análise de Pontos por Função (APF) é uma técnica para a medição de 
projetos de desenvolvimento de software que visa estabelecer uma medida de 
tamanho, em PFs, considerando a funcionalidade implementada, sob o ponto 
de vista do usuário. 
Analise as afirmativas a seguir, relacionadas à APF: 
I — É uma ferramenta que permite determinar o tamanho de pacotes de 
software adquiridos, através da contagem de todos os Pontos por Função 
incluídos no pacote. 
II — É uma ferramenta que permite estimar custos e recursos envolvidos em 
projetos de desenvolvimento e manutenção de software. 
III — O Ponto por Função não ajustado é definido pelo produto da contagem 
por um fator de ajuste. 
a) Apenas a afirmativa III 
b) Apenas a afirmativa II 
c) Apenas as afirmativas I e III 
d) Apenas as afirmativas I e II 
e) Todas as afirmativas estão corretas 
 
Questão 10 
Uma das boas práticas utilizadas pelas empresas para contratar fornecedores 
desenvolvedores de software é homologá-los previamente. Assim, sempre que 
houver alguma demanda de software para ser desenvolvido poderemos afirmar 
que: 
a) Todos os fornecedores cobrarão o mesmo valor pelo projeto. 
b) Todos os fornecedores participarão de todas as propostas. 
c) A contratante pode exigir que cada proposta apresente a quantidade de 
Pontos por Função do projeto de forma detalhada, o que tornará mais 
fácil comparar as propostas. 
 
 MÉTRICAS DE SOFTWARE 47 
d) A contratada pode exigir que cada proposta apresente a quantidade de 
Pontos por Função do projeto de forma detalhada, o que tornará mais 
fácil comparar as propostas. 
e) A contratada pode exigir que cada proposta apresente a quantidade de 
Pontos por Função do projeto de forma detalhada, o que tornará mais 
difícil comparar as propostas. 
 
Aula 2 
Exercícios de fixação 
Questão 1 - A 
Justificativa: Por definição, Pontos por Função medem o tamanho funcional do 
software. 
 
Questão 2 - A 
Justificativa: Por melo de dados históricos, a métrica FP pode ser empregada 
para estimar o custo, prever o número de erros que serão encontrados durante 
o teste e prever o número de componentes e/ou o número de linhas projetadas 
de código-fonte. 
 
Questão 3 - A 
Justificativa: Entrada externa não reside dentro do aplicativo. Ë fornecida pelo 
usuário e/ou por outra aplicação. 
 
Questão 4 - A 
Justificativa: Arquivo lógico interno, conforme o seu nome diz, reside dentro da 
fronteira do software. 
 
 
 
 
 
 MÉTRICAS DE SOFTWARE 48 
Questão 5 - F, F, V, V, F 
Justificativa: A maioria dos projetos passa por mudanças ao longo do ciclo de 
vida. Métrica de software não pretende obter medidas exatas, mas uma 
estimativa de esforço. 
A técnica de reuso é recomendada no desenvolvimento de software e na sua 
qualidade. Toda alterações no software deve ser documentada. 
Portanto, a resposta correta é F-F-V-V-F 
 
Questão 6 - E 
Justificativa: Mínimo: (8 x 3) + (10 x 4) + (0 x 3) + (15 x 7) + (2 x 5) = 179 
Máximo: (8 x 6) + (10 x 7) + (0 x 6) + (15 x 15) + (2 x 10) = 363 
 
Questão 7 - B 
Justificativa: A técnica Pontos por função é usado pelos desenvolvedores par 
determinar o esforço no desenvolvimento do software. Assim, o custo do 
software pode ser estimado. 
 
Questão 8 - D 
Justificativa: Solução: (3 x 5) + (5 x 4) + (8 x 6) + 3 x 15) + (7 x 5) = 163 
 
Questão 9 - D 
Justificativa: Pontos por função ajustado é definido pelo produto da contagem 
por um fator de ajuste, o que contradiz o item III. 
A técnica Pontos por Função determina o tamanho do software e os custos 
correspondentes. 
 
Questão 10 - C 
Justificativa: Nos editais das licitações públicas para desenvolvimento de 
software, pontos por função tem sido uma exigência do contratante. 
 
 
 MÉTRICAS DE SOFTWARE 49 
 
Introdução 
Nesta aula, você compreenderá : 
• Métricas para modelo de projeto; 
• Fan-out e Fan-in; 
• Conectividade; 
• Métricas de projeto da arquitetura; 
• Métricas para projeto orientado a objeto; 
• Acoplamento e Métricas orientadas à classe. 
Estaabordagem é muito importante para determinar o tamanho do software. 
Bons estudos! 
 
Objetivo: 
1. Compreender as métricas para o modelo de projeto de acordo com os 
parâmetros de dimensão do software Fan-out e Fan-in; 
2. Entender as métricas para o modelo de projeto de acordo métricas de 
projeto da arquitetura. 
 
 
 MÉTRICAS DE SOFTWARE 50 
Conteúdo 
Contextualização 
É inconcebível que o projeto de um novo avião, um novo chip de computador 
ou um novo edifício comercial... 
 
... seja conduzido sem a definição de medidas, sem determinar métricas 
para os vários aspectos de qualidade e sem usá-las como indicadores para 
orientar a maneira pela qual o projeto evoluirá. 
 
E, além disso, o projeto de sistemas complexos baseados em software muitas 
vezes é realizado praticamente sem nenhuma medição. 
 
A ironia disso tudo é que as métricas de projeto para software estão 
disponíveis, mas a grande maioria dos engenheiros de software continua 
ignorando sua existência. 
 
As métricas de projeto para software de computador, como todas as outras 
métricas de software, não são perfeitas. 
 
Continua o debate sobre sua eficácia e a maneira pela qual deveriam ser 
aplicadas. 
 
Muitos especialistas argumentam que é necessária mais experimentação para 
que as medições de projeto possam ser usadas. E, além disso, projeto sem 
medição é uma alternativa inaceitável. 
 
Examinaremos a seguir algumas das métricas de projeto mais comuns para 
software de computador. Cada uma delas pode proporcionar uma melhor 
visualização, e todas podem ajudar o projeto a evoluir para um nível maior de 
qualidade. 
 
 
 MÉTRICAS DE SOFTWARE 51 
Fan-out e Fan-in 
A hierarquia de controle, também chamada estrutura de programa, representa 
a organização dos módulos de programa. 
 
Ela não representa aspectos procedimentais de software, tais como sequência 
dos processos, ocorrência/ordem das decisões ou repetição de operações. 
 
A notação mais comum para representar a hierarquia é mostrada na figura. 
Notamos que profundidade e largura constituem uma indicação do número de 
níveis de controle e do espaço de controle global, respectivamente. 
 
Fan-out 
É uma medida do número de módulos que são diretamente controlados por 
outro módulo, isto é, o número de subordinados imediatos para aquele módulo. 
 
Fan-in 
Indica quantos módulos controlam diretamente determinado módulo, isto é, o 
Fan-in de um módulo indica o número de superiores imediatos que ele possui. 
 
O relacionamento de controle entre os módulos é expresso da seguinte 
maneira: um módulo que controla outro é superordenado a ele e, 
inversamente, que um módulo controlado por outro é subordinado ao 
controlador. 
 
Na figura, o módulo X é superordenado aos módulos A, B, C. O módulo H é 
subordinado ao módulo E, que é subordinado ao módulo A. 
 
Fan-out e Fan-in: características 
A hierarquia de controle também representa duas características distintas: 
visibilidade e conectividade. 
 
 
 
 MÉTRICAS DE SOFTWARE 52 
Visibilidade 
Indica o conjunto de componentes de programas que pode ser invocado ou 
usado como dados por um determinado componente. Por exemplo, um módulo 
de um sistema orientado a objeto pode ter acesso a uma ampla sucessão de 
objetos de dados que ele herdou, mas só faz uso de um pequeno número 
desses objetos de dados. 
 
Conectividade 
Indica o conjunto de componentes que é diretamente invocado ou usado como 
dados por determinado componente. Por exemplo, um módulo que faça 
diretamente outro módulo iniciar a execução é conectado a ele. 
 
Fan-out 
Deve-se ter no máximo 7 subordinados. 
 
Fan-in 
Deve-se manter alto o número de superiores. Alto Fan-in é a recompensa pelo 
factoring inteligente e a remoção de módulos restritivos. 
 
Ter uma função chamada por muitos superiores evita a necessidade de 
codificar a mesma função em vários lugares. Portanto, em tempo de 
manutenção, a duplicidade de alteração é eliminada. 
 
Módulos com Fan-in devem ter boa coesão: funcional ou, no mínimo, 
comunicacional ou sequencial. 
 
Existem duas regras para restringir o uso de Fan-in: 
 
Cada interface para um único módulo deve ter os mesmos números e tipos de 
parâmetros. O exemplo a seguir contraria esta regra. 
 
 
 MÉTRICAS DE SOFTWARE 53 
Métricas de projeto da arquitetura 
As métricas de projeto da arquitetura focalizam as características da arquitetura 
do programa com ênfase na estrutura arquitetônica e na eficácia dos módulos 
ou componentes dentro da arquitetura. 
 
Essas métricas são uma “caixa-preta” no sentido de que elas não requerem 
qualquer conhecimento do funcionamento interno de um determinado 
componente de software. 
 
Card e Glass [Car90] definem três medidas de complexidade de projeto de 
software: 
 
Complexidade estrutural: Para arquiteturas hierárquicas (por exemplo, 
arquiteturas de chamada e retorno), a complexidade estrutural de um 
módulo i é definida da seguinte maneira: 
 
Complexidade de dados: A complexidade dos dados (data complexity) 
proporciona uma indicação da complexidade na interface Interna para um 
módulo i e é definida como: 
 
Em que v(i) é o número de variáveis de entrada e saída passadas para o do 
módulo i. 
 
Complexidade de sistema: Por fim, a complexidade de sistema (system 
complexity) é definida como a soma da complexidade estrutural e de dados, 
especificada como: 
 
 
 MÉTRICAS DE SOFTWARE 54 
 
Atenção 
 À medida que esses valores de complexidade aumentam, a 
complexidade global da arquitetura do sistema também 
aumenta. 
 
Isso leva a uma maior probabilidade de que o trabalho de 
integração e teste também aumente. 
 
Fenton [Fen91] sugere um conjunto de métricas de morfologia simples (isto é, 
forma) que permite que diferentes arquiteturas de programa sejam comparadas 
usando uma série de dimensões diretas. Referindo-se à arquitetura de chamada 
e retorno na Figura apresentada, podem ser definidas as seguintes métricas: 
 
Tamanho = n + a 
 
em que n é o número de nós e a é o número de arcos. 
 
Para a arquitetura mostrada: 
 
 Tamanho = 19 + 24 = 43 
 Profundidade = caminho mais longo desde o nó raiz (topo) até o nó da 
folha. Logo, a profundidade = 5 
 Largura = número máximo de nós em qualquer nível da arquitetura. 
 Logo, largura = 7 
 
A relação arco para nó, 
r = a/n 
mede a densidade de conectividade da arquitetura: 
r= 24/19 = 1,26. 
 
 
 MÉTRICAS DE SOFTWARE 55 
Indicadores de qualidade de software 
A força aérea americana (U.S. Air Force Systems Command) desenvolveu um 
conjunto de indicadores de qualidade de software baseados nas características 
de projeto mensuráveis de um programa de computador. Usando conceitos 
similares àqueles propostos na norma IEEE Std. 982.1-1988, a Força Aérea usa 
informação obtida do projeto de dados e arquitetural para criar um índice de 
qualidade da estrutura do projeto (design structure quality index - DSQI) que 
varia de 0 a 1. 
 
Os seguintes valores devem ser apurados para calcular o DSQI: 
 
 S1: Número total de módulos definidos na arquitetura do programa. 
 S2: Número de módulos cuja função correta depende da origem dos 
dados de entrada ou que produzem dados para serem usados em outro 
lugar (em geral, módulos de controle, entre outros, não seriam contados 
como parte de S2). 
 S3: Número de módulos cuja função correta depende de processamento 
anterior. 
 S4: Número de itens de base de dados (inclui objetos dados e iodos os 
atributos que definem objetos). 
 S5: Número total de itens únicos de base de dados. 
 S6: Número de segmentos de base de dados (diferentes registros ou 
objetos individuais). 
 S7: Número de módulos com uma única entrada e saída (processamento 
de exceção não é considerado múltipla saída). 
 
Uma vez determinados os valores S1 até S7, para um programa de computador 
podem ser calculados os seguintes valores intermediários:Estrutura de programa 
D1, que é definido da seguinte maneira: 
 
 MÉTRICAS DE SOFTWARE 56 
Se o projeto da arquitetura foi desenvolvido por meio de um método distinto 
(por exemplo, projeto orientado a fluxo de dados (DFD) ou projeto orientado a 
objeto (OO), então D1 = 1, caso contrário D1 = 0. 
 
Independência modular 
D2 = 1 – (S2/S1) 
 
Módulos não dependentes de processamento anterior 
D3 = 1 – (S3/S1) 
 
Tamanho da base de dados 
D4 = 1 – (S5/S4) 
 
Compartilhamento da base de dados 
D5 = 1 – (S6/S4) 
 
Característica de entrada/saída do módulo 
D6 = 1 – (S7/S1) 
 
Cálculo do DSQI 
Com os valores intermediários determinados, o DSQI é calculado da seguinte 
maneira: 
 
DSQI = ∑ wi/D 
Em que i = 1 a 6, w1 é o peso relativo da importância de cada um dos valores 
intermediários e ∑W1 = 1 (se todos os Di tiverem o mesmo peso, então w1 = 
0,167). 
 
 
 
 MÉTRICAS DE SOFTWARE 57 
Métricas para projeto orientado a objeto 
Há muita coisa sobre projeto orientado a objeto que é subjetivo - um 
projetista experiente “sabe” como caracterizar um sistema orientado a objeto 
de maneira que implemente efetivamente os requisitos do cliente. 
 
Mas, à medida que um modelo de projeto orientado a objeto cresce em 
tamanho e complexidade, uma visão mais objetiva das características do 
projeto pode favorecer tanto o projetista experiente (que obtém uma visão 
adicional) quanto o novato (que obtém uma indicação da qualidade que de 
outra forma não estaria disponível). 
 
Em um tratamento detalhado de métricas de software para sistemas orientados 
a objeto, Whitmire descreve nove características distintas e mensuráveis 
de um projeto orientado a objeto: 
 
1. Tamanho. É definido em termos de quatro visualizações: população, 
volume, comprimento e funcionalidade. População é medida tomando-se 
uma contagem estática das entidades orientadas a objeto, como classes 
ou operações. Medidas de volume são idênticas às medidas de 
população, mas são coletadas dinamicamente - em determinado instante 
do tempo. Comprimento é a medida de uma cadeia de elementos de 
projeto interconectados (por exemplo, a extensão de uma árvore de 
herança é uma medida do comprimento). As métricas de funcionalidade 
proporcionam uma indicação indireta do valor fornecido ao cliente por 
uma aplicação orientada a objeto. 
 
2. Complexidade. Assim como o tamanho, há muitas visões diferentes da 
complexidade do software. Whitmire vê a complexidade em termos de 
características estruturais examinando como as classes de um projeto 
orientado a objeto se inter-relacionam. 
 
 
 MÉTRICAS DE SOFTWARE 58 
3. Acoplamento. As conexões físicas entre elementos do projeto orientado 
a objeto (por exemplo, o número de colaborações entre classes ou o 
número de mensagens passadas entre objetos) representam o 
acoplamento em um sistema orientado a objeto. 
 
4. Suficiência. Whitmire define suficiência como “o grau com o qual uma 
abstração possui as características requeridas para ela, ou o grau com o 
qual um componente de projeto possui características em sua abstração, 
do ponto de vista da aplicação corrente”. Em outras palavras, 
perguntamos: “Que propriedades essa abstração (classe) precisa ter 
para ser útil para mim?”. Essencialmente, um componente de projeto 
(por exemplo, uma classe) é suficiente se refletir totalmente todas as 
propriedades do objeto de domínio da aplicação que está modelando - 
isto é, que a abstração (classe) possui as características necessárias para 
ele. 
 
5. Totalidade. A única diferença entre totalidade e suficiência é “o 
conjunto de características em relação às quais comparamos a abstração 
ou o componente de projeto”. A suficiência compara a abstração do 
ponto de vista da aplicação corrente. A totalidade considera múltiplos 
pontos de vista, formulando a pergunta: “Que propriedades são 
necessárias para representar completamente o objeto de domínio do 
problema?”. Em virtude do critério da totalidade considerar diferentes 
pontos de vista, ele tem uma implicação indireta no grau com o qual a 
abstração ou o componente de projeto pode ser reutilizado. 
 
6. Coesão. Assim como seu correspondente no software convencional, um 
componente orientado a objeto deverá ser projetado de maneira que 
tenha todas as operações funcionando em conjunto para atingir um 
objetivo único e bem definido. A coerência de uma classe é determinada 
examinando-se o grau segundo o qual “o conjunto de propriedades que 
ela possui faz parte do domínio do problema ou projeto”. 
 
 MÉTRICAS DE SOFTWARE 59 
7. Originalidade. Uma característica similar à simplicidade, originalidade 
(aplicada tanto a operações quanto a classes) é o grau segundo o qual 
uma operação é atômica - isto é, a operação não pode ser construída 
por meio de uma sequência de outras operações contidas dentro de uma 
classe que apresenta um alto grau de originalidade e encapsula apenas 
operações primitivas. 
 
8. Similaridade. O grau segundo o qual duas ou mais classes são 
similares em termos de sua estrutura, função, comportamento ou 
finalidade é indicado por essa medição. 
 
9. Volatilidade. Conforme já afirmamos multas vezes neste livro, podem 
ocorrer alterações de projeto quando os requisitos são modificados ou 
quando acontecem modificações em outras partes de um aplicativo, 
resultando em adaptação obrigatória do componente de projeto em 
questão. A volatilidade de um componente orientado a objeto mede a 
possibilidade de que uma alteração venha a ocorrer. 
 
Métricas orientadas a classe — o conjunto de métricas CK 
O que é classe? 
A classe é a unidade fundamental de um sistema orientado a objeto. Portanto, 
medidas e métricas para uma classe individual para a hierarquia da classe e 
colaborações entre classes serão valiosas quando tivermos de avaliar qualidade 
de projeto orientado a objeto. 
 
Uma classe encapsula dados e a função manipula os dados. Com frequência é o 
“pai” das subclasses (às vezes chamadas de filhas) que herda seus atributos e 
operações. Muitas vezes elas colaboram com outras classes. Cada uma dessas 
características pode ser usada como base para a medida. 
 
Chidamber e Kemerer propuseram um dos conjuntos mais amplamente 
conhecidos de métricas de software orientado a objeto. Também chamado de 
 
 MÉTRICAS DE SOFTWARE 60 
conjunto de métricas CK (CK metrics suite), os autores propuseram seis 
métricas de projeto baseado em classe para sistemas orientados a objeto. 
Vejamos uma delas: 
 
Métodos ponderados por classe (weighted methods per class - WMC). 
Suponha que n métodos de complexidade c1,c2 ,..., cn são definidos para uma 
classe C. A métrica especifica de complexidade escolhida (por exemplo, 
complexidade ciclomática) deverá ser normalizada de maneira que a 
complexidade nominal para um método assuma o valor 1,0. 
 
WMC = ∑c1 
Para i = 1 a n. O número de métodos e sua complexidade são indicadores 
razoáveis do trabalho necessário para implementar e testar uma classe. 
 
 
Atenção 
 Quanto maior for o número de métodos, mais complexa será a 
árvore de herança (todas as subclasses herdam os métodos de 
seus pais). Por fim, conforme o número de métodos cresce para 
uma dada classe, ela tende a se tornar cada vez mais específica 
de aplicação, limitando assim sua potencial reutilização. Por 
todas essas razões, o WMC deverá ser mantido o mais baixo 
possível. 
 
Embora pudesse parecer relativamente fácil desenvolver uma 
contagem para o número de métodos em uma classe, o 
problema é na realidade mais complexo do que parece. Deverá 
ser desenvolvida uma abordagem consistente de contagem. 
 
 
 MÉTRICAS DE SOFTWARE 61 
Atividade Proposta 
Discuta com seus colegas a importância da adoção de métricas no processo de 
projeto de software a importância do fan-in e fan-out em uma estrutura de 
módulos de projeto de software. 
 
Chave de resposta: FAN-OUT, FAN-IN, Complexidade