Métrica de Software

Prévia do material em texto

MARCELO DE FREITAS PINTAUD
ELISAMARA DE OLIVEIRA
Professor autor/conteudista
Atualizado e revisado por
É vedada, terminantemente, a cópia do material didático sob qualquer 
forma, o seu fornecimento para fotocópia ou gravação, para alunos 
ou terceiros, bem como o seu fornecimento para divulgação em 
locais públicos, telessalas ou qualquer outra forma de divulgação 
pública, sob pena de responsabilização civil e criminal.
SUMÁRIO
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 . Métricas de Software: fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Medição, Medidas, Métricas e Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1 .2 Classificação das Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.3 Métricas de Processo e Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
1.4 Considerações sobre Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
2 . Tipos de Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Métricas de Qualidade e Métricas para o Modelo de Requisitos . . . . . . . . . . . . . . .14
2.1.1 Métricas orientadas a função - Pontos de Função (PF) ou FP (Function 
Points) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
2.1.2 Métricas para qualidade de especificação . . . . . . . . . . . . . . . . . . 19
2.1.3 Métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency 
(DRE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4 Métricas orientadas a Casos de Uso ou Use Cases (UCs). . . . . . . . . . 20
2.2 Métricas para o Modelo de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Métricas para projeto Orientado a Objetos-OO . . . . . . . . . . . . . . . . 21
2.2.2 Métricas orientadas a classes: métricas CK – Chidamber e Kemerer. . . 23
2.3 Métricas para Medição de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Métricas orientadas a tamanho – Lines of Code (LOC) . . . . . . . . . . . 27
2.3.2 Métricas de Halstead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 Métricas Halstead aplicadas ao teste . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Complexidade Ciclomática . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Métricas para Manutenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 . Estimativas de Software – parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Estimativas de Software e Planejamento de Projeto . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Planejamento do Projeto: escopo e viabilidade do projeto. . . . . . . . . . . . . . . . . . . .35
3.3 Planejamento do Projeto: Recursos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Planejamento do Projeto: Estimativas do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.1 Técnica de decomposição: Estimativa Baseada em Problema. . . . . . . 39
3.4.2 Exemplos de Estimativas Baseadas em LOC . . . . . . . . . . . . . . . . . 41
3 .4 .3 Exemplos de Estimativas Baseadas em Pontos de Função (FP) . . . . . 45
4 . Estimativas de Software – parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Modelos de Estimativa Empíricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
4.1.1 Exemplo de Aplicação do Modelo Empírico. . . . . . . . . . . . . . . . . . 51
4.2 Modelo COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Estimativa Baseada em Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Essa técnica baseia a estimativa no processo que será usado. Os passos a serem 
seguidos são: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1 Exemplo de Estimativa Baseada em Processo . . . . . . . . . . . . . . . . 54
4.4 Estimativa com Pontos de Caso de Uso ou Use Case Points (UCPs) . . . . . . . . . . 59
4 .4 .1 Exemplo de Estimativa com UCPs . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Conciliação de Modelos de Estimativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
4.5.1 Exemplo de conciliação de estimativas . . . . . . . . . . . . . . . . . . . . 61
5 . Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1 Conceitos básicos sobre riscos em projetos de software . . . . . . . . . . . . . . . . . . . 62
5.2 Gestão de Riscos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Identificação de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Estimativa, Análise e Priorização de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.1 Avaliação do Impacto do Risco (Exposição ao Risco ou Risk Exposure) . 72
5.4.2 Exemplo de cálculo de Exposição do Risco - ER . . . . . . . . . . . . . . . 73
5.4.3 Exposição ao Risco Total (ERT) . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4.4 Exemplo de cálculo de Exposição ao Risco Total (ERT) . . . . . . . . . . 74
5.5 Mitigação, Monitoramento e Gerenciamento do Risco ou Risk Mitigation, Monitoring 
and Management – RMMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.1 Exemplo de aplicação do RMMM . . . . . . . . . . . . . . . . . . . . . . . 76
6 . Cronograma do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.1 Conceitos Básicos sobre Cronograma de Projeto (Project Schedule) . . . . . . . . . 80
6.2 Cronograma e Controle de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3 EVA – Earned Value Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.1 Exemplo de uma Análise do Valor Agregado . . . . . . . . . . . . . . . . . 84
6.4 Gráfico de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.5 Rede de Atividades: PERT e CPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Glossário de Siglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
BIBLIOGRAFIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Pág. 5 de 99
INTRODUÇÃO
Caroaluno, trataremos de um tema de grande relevância para os profissionais envolvidos na produção 
do software: as Métricas de Software. Este tema é parte fundamental da prática da Engenharia de Software 
e é cada vez mais comum nos requisitos contratuais para dimensionar o software e sua qualidade.
Organizações que criam padrões e modelos para a indústria, como os padrões ISO e CMMI, se 
preocupam com medidas e métricas a fim de apurar e garantir a qualidade de produtos e serviços. 
Empresas e órgãos governamentais, no Brasil e no mundo, estão usando métricas para compreender, 
controlar, prever e melhorar projetos, processos e produtos de software.
Dessa forma, caso você esteja envolvido com a área de desenvolvimento de software, é 
fundamental ter conhecimento sobre os conceitos relativos às métricas. Ao longo desse conteúdo, 
apresentaremos os conceitos básicos sobre métricas, depois veremos como eles se relacionam com 
o produto, o processo e o projeto de software e como podem auxiliar no seu controle e melhoria.
Em seguida, apresentaremos as diferentes categorias de métricas que podem dar suporte a vários 
aspectos ligados à prática da Engenharia de Software.
Em um segundo momento, você terá oportunidade de ver como as métricas desempenham 
um papel fundamental em uma das áreas mais críticas do desenvolvimento de software: a área 
de estimativas de custos, prazos e recursos. Vários modelos de estimativas serão apresentados, 
dando-lhe condições de constatar a importância de se ter um programa bem estabelecido de 
coleta de medidas, cálculo de métricas e armazenamento dessas informações em uma base de 
dados robusta. A qualidade dessa base de dados será fundamental para a precisão das estimativas 
realizadas para cada projeto em andamento na sua empresa.
Trataremos, também, de um assunto que é comum a todo empreendimento, incluindo o desenvolvimento 
de software: a gestão de riscos. Todo projeto está exposto a riscos e é de suma importância que você 
adote uma estratégia proativa em relação a eles. Isso implica conseguir prever a quais riscos o projeto 
está vulnerável, qual a probabilidade desses riscos se tornarem realidade e qual o impacto deles no projeto, 
caso realmente venham a ocorrer. Por fim, finalizaremos discutindo cronogramação. Aqui também as 
medidas desempenham um papel fundamental. Um exemplo disso é a denominada “Análise do Valor 
Agregado”, que pode auxiliá-lo no monitoramento e controle do andamento de um projeto.
Uma vez que você tenha concluído o estudo desses vários tópicos, você estará preparado para 
entender melhor a importância da utilização das métricas no seu trabalho profissional, agora como 
especialista.
Marcelo Pintaud e Elisamara de Oliveira
Pág. 6 de 99
1. MÉTRICAS DE SOFTWARE: FUNDAMENTOS
1.1 Medição, Medidas, Métricas e Indicadores
Figura 1 – Métricas: medidas para o sucesso
Fonte: Kenishirotie/Shutterstock
Métricas de software estão se tornando cada vez mais uma parte importante na prática da 
Engenharia de Software. A cada dia, um número maior de empresas e governos está adotando e 
reportando métricas de qualidade como parte dos requisitos contratuais de desenvolvimento.
Padrões, modelos e normas como ISO (International Organization for Standardization), CMMI 
(Capability Maturity Model Integration), entre outros, consideram as métricas entre as suas práticas 
recomendadas. Empresas estão usando métricas para melhor compreender, mapear, controlar e 
predizer projetos, processos e produtos de software.
De acordo com Maitino Neto (2016, p. 148), a medição é o processo pelo qual “os números são 
atribuídos aos atributos de entidades do mundo real”. O autor exemplifica o conceito dizendo que 
quando medimos a separação entre dois pontos e obtemos 10, o valor 10 é atribuído à grandeza 
física denominada distância. Isso indica que a medição é uma quantificação direta, que utiliza um 
único valor. Mas quando tratamos de métrica, utilizamos uma medição indireta, pois esta envolve 
o cálculo e uso de mais de uma medida. Como exemplo, podemos utilizar a medida de número de 
linhas de código e a medida de número de defeitos encontrados no programa para determinar a 
métrica de quantidade de defeitos por linha de código.
Pág. 7 de 99
Ainda como exemplos de medição, podemos considerar, no campo da Engenharia, medidas 
como consumo de energia, peso, dimensões físicas, temperatura voltagem etc.
Maitino Neto (2016) ainda afirma que é desejável que as métricas sejam capazes de fornecer 
informação relevante para auxiliar a tomada de decisão e ainda contribuir para que se possa realizar 
comparação de desempenhos.
Embora existam métricas referenciais, usadas de forma padronizada pelos desenvolvedores 
de software, métricas podem ser baseadas nos objetivos da organização e na sua necessidade de 
informação para a tomada de decisão.
No contexto da engenharia de software, Pressman e Maxim (2016, p. 654) definem medida 
como um valor que “fornece uma indicação quantitativa da extensão, quantidade, dimensão, 
capacidade ou tamanho de algum atributo de um produto ou processo”. Os autores fazem 
referência ao IEEE Standard Glossary of Software Engineering Terminology que define métrica 
como uma “medida quantitativa do grau em que um sistema, componente ou processo possui 
um determinado atributo”.
Ainda de acordo com os autores, quando um único ponto de dados foi coletado (como, por 
exemplo, o número de erros descoberto em um único componente de software) uma medida foi 
estabelecida. Medição ocorre como resultado da coleção de um ou mais pontos de dados (por 
exemplo, um certo número de revisões de componentes e testes de unidade são investigados para 
coletar medidas do número de erros em cada um). Uma métrica de software relaciona as medidas 
individuais de algum modo, como, por exemplo, o número médio de erros encontrados por revisão 
ou número médio de erros encontrados por teste unitário.
Um engenheiro de software coleta medidas e desenvolve métricas de modo que indicadores 
sejam obtidos. Pressman e Maxim (2016, p. 655) definem um indicador como “uma métrica ou 
combinação de métricas que fornece profundidade na visão do processo, projeto ou produto de 
software”. Um indicador fornece um parâmetro que permite ao gerente do projeto ou engenheiros 
de software ajustarem o processo, projeto ou produto para torná-lo melhor e gerenciável. A figura 
2 ilustra esses conceitos.
Pág. 8 de 99
Figura 2 – Visão geral sobre medidas, métricas e indicadores
Coleta de Dados
Cáculo das Métricas Métricas
Medidas
Avaliação das Métricas
Projeto
Produto
Processo
Indicadores
Fonte: elaborado pelo autor.
De acordo com a figura 2, na Engenharia de Software a medição é útil principalmente quando 
relacionada ao processo, projeto e produto de software.
Pode ser aplicada ao processo de software com o objetivo de melhorá-lo continuamente. 
No caso do projeto de software, as medidas podem auxiliar nas estimativas de prazos e custos, 
no controle de qualidade, na avaliação da produtividade, no controle do projeto e na tomada de 
decisões, conforme o projeto evolui. As medidas relacionadas ao produto de software focalizam 
atributos específicos de artefatos e são coletadas à medida que tarefas técnicas (análise, projeto, 
codificação e teste) são conduzidas.
Meirelles (2008) afirma que uma grande variedade de métricas já foram propostas, mas nem 
todas mostram resultados satisfatórios. Isso ocorre por vários fatores: algumas exigem medições 
muito complexas, outras são muito restritas, limitando sua aplicação, e outras violam as noções 
básicas dos atributos de um software (qualidade, por exemplo).
As métricas de software consideradas efetivas devem possuir alguns atributos que incluem:
• Simples e computáveis: deve ser relativamente fácil aprender como derivar a métrica e seu 
cálculo não deve exigir esforço ou tempo exagerado.
• Empíricas e intuitivamente persuasivas: a métrica deve satisfazer as noções intuitivasdo 
engenheiro de software sobre o atributo do produto que está sendo considerado.
Pág. 9 de 99
• Consistentes e objetivas: a métrica deve produzir sempre resultados que não sejam ambíguos.
• Independentes da linguagem de programação: métricas devem ser baseadas no modelo de 
análise, modelo de projeto ou na estrutura do programa.
• Capazes de atuar como mecanismo efetivo para realimentação de alta qualidade: isto é, a 
métrica deve levar a um produto final da mais alta qualidade.
Enfim, as métricas devem permitir a comparação dos resultados para medir qualidade, eficiência, 
custo, produtividade, entre outros aspectos mensuráveis da análise, desenho, codificação e testes 
de software.
ACONTECEU
Saiba mais sobre a história da ISO acessando o link: 
<https://www.portaleducacao.com.br/conteudo/artigos/cotidiano/a-historia-da-organizacao-iso/40732>.
1 .2 Classificação das Métricas de Software
Existem muitas classificações para métricas de software. Um software pode ser medido 
orientado ao tamanho, a funções, aos objetos, aos recursos humanos envolvidos, a qualidade e 
pela produtividade, entre outras medições.
Apresentamos algumas classificações de métricas a seguir, com base no trabalho de 
Meirelles (2008).
• Classificação quanto ao objeto
◊	Métricas de produto: são relacionadas à complexidade, tamanho, qualidade (confiabilidade, 
manutenibilidade etc.) do software produzido.
◊	Métricas de processo: referem-se ao processo de concepção e desenvolvimento do software, 
medindo por exemplo, o processo de desenvolvimento, o tipo de metodologia usada e o 
tempo de desenvolvimento.
• Classificação quanto ao critério utilizado na sua determinação
◊	Métricas objetivas: são obtidas através de regras bem definidas, sendo a melhor forma de 
possibilitar comparações posteriores consistentes. Nessa categoria, os valores obtidos 
devem ser sempre os mesmos, independentemente do instante, condições ou indivíduos 
que os determinam. A determinação dessas métricas é passível de automatização (por 
exemplo, número de linhas de código).
◊	Métricas subjetivas: podem partir de valores, mas dependem de um julgamento, que também 
é um dado de entrada, para serem levantadas (por exemplo, o modelo de estimativa de 
custo, que depende da classificação do tipo de software).
Pág. 10 de 99
• Classificação quanto ao método de obtenção
◊	Métricas primitivas: são aquelas que podem ser observadas diretamente em uma única 
medida (por exemplo, o número de linhas de código, erros indicados em um teste de unidade 
ou ainda o total de tempo de desenvolvimento de um projeto).
◊	Métricas compostas: são as combinações de uma ou mais medidas (por exemplo, o número 
de erros encontrados a cada mil linhas de código ou ainda o número de linhas de teste por 
linha de código).
Existem outras classificações, como métricas privadas e públicas.
As métricas privadas se aplicam ao indivíduo e as informações e resultados são de divulgação 
restrita. Os dados coletados com base individual devem ser privados e servir como indicadores 
apenas para o indivíduo. Servem para ajudar o engenheiro de software a aperfeiçoar seu trabalho 
individual. Algumas métricas são privadas de uma determinada equipe (por exemplo, proporção 
de defeitos por indivíduo).
As métricas públicas têm origem privada, mas acabam por serem divulgadas para toda a equipe. 
Elas permitem que as organizações realizem mudanças estratégicas para melhorar o processo de 
desenvolvimento do software.
1.3 Métricas de Processo e Projeto
De acordo com Pressman e Maxim (2016, p. 703), métricas de processo e de projeto de software 
são medidas quantitativas que permitem aos engenheiros de software vislumbrar a eficácia tanto 
do processo quanto dos projetos que são conduzidos usando este processo como framework. As 
medições permitem que julgamentos deixem de ser subjetivos e tendências possam ser detectadas 
de forma que estimativas possam ser feitas e aperfeiçoamentos buscados.
Figura 3 – Métricas: busca pelo aperfeiçoamento
Fonte: G7 Stock/Shutterstock
Pág. 11 de 99
As métricas de processo têm finalidade estratégica e objetivam fornecer um conjunto de 
indicadores de processo visando o seu aperfeiçoamento no longo prazo. As métricas de projeto têm 
finalidade tática e permitem ao gerente de projeto avaliar o estado de um projeto em desenvolvimento, 
acompanhar riscos em potencial, descobrir setores que apresentam problemas antes que se tornem 
críticos, ajustar o fluxo de trabalho e ainda avaliar a capacidade da equipe para controlar a qualidade 
do produto e dos artefatos de software.
As medidas que são coletadas com base em dados de qualidade e produtividade são convertidas 
em métricas e analisadas e comparadas com métricas anteriores. Essas métricas podem ser usadas 
durante o projeto para detectar problemas ocorridos no desenvolvimento e serem transmitidas 
para quem tem responsabilidade sobre o aperfeiçoamento do processo de software. Desta forma, 
muitas métricas são usadas tanto no domínio do processo quanto do projeto.
Ainda de acordo com Pressman e Maxim, o processo situa-se no centro de um triângulo (conforme 
ilustra a figura 4) que liga três fatores que influenciam significativamente tanto a qualidade de 
software quanto o desempenho da organização:
• Pessoas: a capacidade e a motivação das pessoas reúnem os fatores individuais que mais 
influenciam a qualidade e o desempenho.
• Produto: a complexidade do produto pode ter um forte impacto sobre a qualidade e o desempenho 
das pessoas que formam a equipe.
• Tecnologia: os métodos e as ferramentas de engenharia de software são fundamentais, pois 
impactam o processo.
Além destes fatores, o triângulo do processo encontra-se dentro de um círculo que inclui o 
ambiente de desenvolvimento (exemplo: ferramentas CASE), condições de negócios (exemplo: 
prazos e regras de negócio) e características do cliente (exemplo: facilidade de comunicação).
Pág. 12 de 99
Figura 4 – Triângulo de fatores que impactam o processo
Pessoas
Processo
Tecnologia
Ambiente de 
desenvolvimento
Condições 
dos negócios
Caracteristicas
 do cliente
Produto
Fonte: Pressman; Maxim (2016, p. 705).
A eficácia de um processo pode ser medida pelas saídas dele derivadas como: medidas dos erros 
descobertos antes da entrega do produto, defeitos relatados pelos usuários finais, produtividade 
da equipe, esforço humano dispendido, tempo gasto, cumprimento do cronograma, entre outras. 
Desta forma, as métricas de processo podem fornecer benefícios significativos na medida em que 
a organização trabalha para corrigir e melhorar seus problemas, buscando maior maturidade de 
processo. Em um nível mais avançado, a organização pode adotar a abordagem SSPI – Statistical 
Software Process Improvement, que usa a análise de falhas de software para coletar informação 
sobre erros e defeitos encontrados no produto em operação.
As métricas de projeto são usadas por um gerente de projeto para adaptar o fluxo de trabalho 
e sua primeira aplicação ocorre, geralmente, durante a estimativa. Métricas usadas em projetos 
anteriores podem ser usadas como base. O gerente utiliza medidas de esforço e tempo dispendidos 
comparadas com as estimativas previstas no cronograma para monitorar e controlar o progresso 
do projeto.
Na medida em que o trabalho técnico prossegue, outras métricas de projeto são utilizadas, 
como taxa de produção, horas de revisão, pontos por função, linhas de código entregues etc. Além 
Pág. 13 de 99
disso, os erros descobertos são registrados e outras métricas técnicas são utilizadas para avaliar 
a qualidade do projeto, o que irá influenciar a abordagem de testes.
As métricas de projeto são usadas tanto para minimizar o tempo do cronograma, buscando 
evitar atrasos e diminuir riscos, quanto para avaliar a qualidade do produto. Na medida em que a 
qualidade é melhorada, os defeitos são reduzidos e a quantidade de retrabalho também é minimizada, 
levando à redução do custo do projeto.
1.4 Consideraçõessobre Métricas
Há um grande número de métricas de software, que normalmente são aplicadas de forma isolada 
e consideradas insatisfatórias por grande parte dos desenvolvedores.
No passado, várias métricas e uma série de processos foram propostos, mas a maioria não 
possuía uma base teórica suficiente e/ou uma significativa validação experimental. Várias delas 
foram definidas e, em seguida, testadas e utilizadas em apenas um ambiente limitado. Apesar de, 
em alguns casos, existirem relatos de validação ou de aplicação dessas métricas, testes ou uso 
em ambientes diferentes produziram resultados não esperados. Essas diferenças acabam por não 
serem surpreendentes, uma vez que faltam definições claras e hipóteses de testes bem definidas.
Assim, existe um grande número de métricas que podem ser utilizadas, mas devemos observar 
quais delas têm sido mais amplamente utilizadas ou aceitas, pois certamente apresentam resultados 
mais efetivos.
Se o desenvolvedor construir uma aplicação apoiada por métricas escolhidas de forma criteriosa, 
elas poderão produzir resultados úteis se forem utilizadas de acordo com o ambiente especificado.
Independentemente das métricas adotadas. é muito importante para as organizações a coleta 
efetiva dessas métricas e o registro histórico dos projetos, formando uma base de conhecimento 
que auxilie nos processos de análise, melhoria e tomada de decisão.
Muitos fatores devem ser levados em consideração para a escolha das métricas. Recomendamos 
que você identifique qual a necessidade de medição do projeto (qualidade, produtividade, erros, 
falhas etc.) para, em seguida, adotar mecanismos que permitam uma medição mais significativa 
e efetiva.
Pág. 14 de 99
2. TIPOS DE MÉTRICAS DE SOFTWARE
2.1 Métricas de Qualidade e Métricas para o Modelo de Requisitos
Figura 5 – Software Metric
Fonte:	Profit_Image/Shutterstock
O desenvolvimento de um projeto inicia-se com a criação do modelo de requisitos e é nesta fase 
que os requisitos são formulados e a base do projeto é estabelecida. Desta forma, as métricas de 
produto que fornecem informação sobre a qualidade do modelo de análise são bastante desejáveis.
A qualidade de um sistema, aplicação ou produto é tão melhor quanto melhor estejam descritos 
os requisitos que o descrevem, o projeto que modela sua solução, o código que o implementa e os 
testes que o exercitam para descobrir defeitos e erros.
Desta forma, métricas como erros por ponto de função, erros descobertos por horas de revisão, 
erros descobertos por horas de teste e eficiência na remoção de defeitos proporcionam informações 
relevantes que ajudam no controle de qualidade do software.
Pág. 15 de 99
2.1.1 Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points)
A métrica Ponto de Função (PF) ou Function Point (FP) pode ser utilizada como forma de medir 
a funcionalidade fornecida por um sistema. Pressman e Maxim (2016, p. 659) indicam que podem 
ser usadas para:
• estimar o custo ou trabalho necessário para projetar, codificar e testar o software;
• prever o número de erros que serão encontrados durantes os testes; e
• prever o número de componentes e/ou o número de linhas de código-fonte projetadas.
Os PFs são derivados de medidas calculáveis do domínio de informações do software com base em:
[1] ExternalInputs-EIs (número de entradas externas): cada entrada externa tem origem em um 
usuário ou é transmitida de outra aplicação. Fornece dados distintos orientados à aplicação ou 
informações de controle.
[2] External Outputs-EOs (número de saídas externas): cada saída externa é formada por dados 
derivados da aplicação e fornece informações para o usuário.
[3] ExternalinQuiries-EQs (número de consultas externas): refere-se a uma entrada online que 
resulta na geração de alguma resposta imediata do software na forma de uma saída online.
[4] InternalLogical Files-ILFs (número de arquivos lógicos internos): cada arquivo lógico interno 
é um conjunto de dados que fica dentro dos limites da aplicação e é mantido por meio de entradas 
externas.
[5] External Interface Files-EIFs (número de arquivos de interface externos): cada arquivo de 
interface externo é um conjunto de dados que fica fora da aplicação, mas fornece dados que podem 
ser usados pela aplicação.
Para o cálculo de Pontos de Função, os passos descritos a seguir devem ser seguidos.
[1] Primeiro passo: preencher as colunas sombreadas da tabela 1. Note que nessa tabela você 
deve preencher apenas os dados da coluna Contagem e fazer o cálculo da coluna Contagem x Fator 
de Peso e totalizar a Contagem Total. As colunas Valor do domínio da informação e Fator de Pesos 
já estão preenchidas, pois são valores são propostos pelo modelo e, a princípio, são fixos. Então, 
Pág. 16 de 99
nesse passo, você terá que estimar a quantidade de cada parâmetro previsto para o software a ser 
desenvolvido e atribuir um fator de peso para cada um deles.
Uma grande questão que surge é como minimizar a subjetividade na atribuição desses fatores de 
ponderação, porque isso pode variar de pessoa para pessoa. O IFPUG – International Function Points 
Users Group – disponibiliza uma série de recomendações visando minimizar essa subjetividade.
Uma vez preenchida a Tabela 1, você terá o valor de Contagem Total, o qual será utilizado no 
terceiro passo do cálculo.
Tabela 1 – Tabela para Pontos de Função
Valor do domínio da informação Contagem Fator de Peso Contagem 
x Fator de 
PesoSimples Médio Complexo
Nº de Entradas Externas (EIs) 3 4 6
Nº de Saídas Externas (EOs) 4 5 7
Nº de Consultas Externas (EQs) 3 4 6
Nº de ArqLóg Internos (ILFs) 7 10 15
Nº de ArqInterf Externos (EIFs) 5 7 10
Contagem Total
Fonte: baseada em Pressman; Maxim (2016, p. 660).
[2] Passo 2: para o cálculo dos pontos de função, você terá que avaliar as 14 questões apresentadas 
no quadro 1, também relacionadas às funcionalidades do software a ser desenvolvido. Para cada 
uma dessas perguntas, você terá que atribuir um fator de ajuste de valor ou Value Adjustment 
Factor – VAF, Fi (i = 1 a 14), obedecendo à escala proposta pelo modelo apresentado no quadro 2.
Pág. 17 de 99
Quadro 1 – 14 perguntas relacionadas às funcionalidades
1. O sistema exige backup e recuperação 
confiáveis
8. Os arquivos são atualizados on-line?
2. É requerida comunicação de dados? 9. Entradas, saídas, arquivos e consultas são 
complexos?
3. Existem funções de processamento 
distribuído?
10. O processamento interno é complexo?
4. O desempenho é crítico? 11. O código é projetado para ser reusável?
5. O sistema funcionará num sistema 
operacional existente e intensamente 
utilizado?
12. A conversão e a instalação estão 
incluídas no projeto?
6. São requeridas entrada de dados on-line? 13. O sistema é projetado para múltiplas 
instalações em diferentes organizações?
7. As entradas on-line requerem que as 
transações de entrada sejam construídas 
com várias telas e operações?
14. A aplicação é projetada de forma a 
facilitar mudanças e o uso pelo usuário?
Fonte: baseado em Pressman; Maxim (2016, p. 661).
Quadro 2 – Escala de VAFs – Value Adjustment Factors
Influência 0 1 2 3 4 5
Nenhuma Pouca Moderada Média Significante Essencial 
Fonte: baseado em Pressman; Maxim (2016, p. 661).
Para evitar o problema da subjetividade ao avaliar a influência de cada funcionalidade, o IFPUG 
desenvolveu recomendações a serem seguidas.
No final desse segundo passo, você terá a soma das influências de cada uma das 14 perguntas. 
O valor dessa soma variará de um mínimo de 0 (todas as 14 perguntas tendo valor 0) a um valor 
máximo de 70 (todas as perguntas tendo valor igual a 5).
[3] Passo 3: neste passo, utiliza-se uma expressão empírica proposta pelo modelo para obtenção 
dos pontos de função:
Pág. 18 de 99
Apenas para ilustrar, vamos apresentar a tabela 2 completamente preenchida, para um determinado 
projeto de software, o que seria feito no passo 1.
Tabela 2 – Tabela completa de Pontos de Função
Valordo domínio da 
informação
 
Contagem
Fator de Peso Contagem 
x 
Fator de PesoSimples Médio Complexo
Nº de Entradas Externas (EIs) 3 3 4 6 9
Nº de Saídas Externas (EOs) 2 4 5 7 8
Nº de Consultas Externas 
(EQs)
2 3 4 6 6
Nº de ArqLóg Internos (ILFs) 1 7 10 15 7
Nº de ArqInterf Externos (EIFs) 4 5 7 10 20
Contagem Total 50
Fonte: Pressman; Maxim (2016, p. 662).
Supondo que no passo 2 foi realizado o cálculo que resultou em
o valor que indica que o produto é moderadamente complexo.
No passo 3 calculamos o PF.
PF = 50 x [0.65+ (0.01 x 46)] = 55.5 => 56
Antes de prosseguir com o estudo, recomendamos que você acesse o site do IFPUG ou BFPUG 
e se familiarize com as recomendações propostas para a utilização do modelo. Leia também o 
material disponibilizado no link. Através dele você tomará conhecimento em detalhes das várias 
etapas que deve seguir para obter essa medida de funcionalidade do software.
SAIBA MAIS
Uma das melhores referências sobre Pontos por Função é o site do IFPUG – International Function 
Point Users Group (<http://www.ifpug.org>), ou sua representação brasileira oficial, BFPUG – Brazilian 
Function Point Users Group (<http://www.bfpug.com.br/>).
Pág. 19 de 99
2.1.2 Métricas para qualidade de especificação
De acordo com Pressman e Maxim (2016, p. 663), há uma lista de características que podem 
ser usadas para avaliar a qualidade do modelo de requisitos e as especificações de requisitos 
correspondentes, como: não ambiguidade, totalidade, exatidão, compreensibilidade, consistência 
interna e externa, disponibilidade, rastreabilidade, modificabilidade, entre outras. Cada uma delas 
pode ser representada usando uma ou mais métricas.
Suponha que há Nr requisitos em uma especificação, entre os quais há Nf requisitos funcionais 
e Nnf requisitos não funcionais, tal que:
Nr = Nf + Nnf
Para se determinar a não ambiguidade dos requisitos, pode ser utilizada uma métrica com base 
na interpretação de cada requisito pelos revisores. Se Nii representa o número de requisitos para os 
quais todos os revisores tiveram a mesma interpretação (ii = interpretação idêntica), temos:
Q1 = Nii / Nr
Quanto mais próximo de 1 for Q1, menos ambiguidades haverá na especificação dos requisitos.
Considerando que Nfu representa o número de requisitos funcionais únicos, Ne representa o 
número de entradas definidas pela especificação e Ns o número de estados especificados, a métrica 
da totalidade dos requisitos funcionais Q2 pode ser obtida por:
Q2 = Nfu / (Ne x Ns)
2.1.3 Métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE)
A métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE), de acordo com 
Pressman e Maxim (2016, p. 718), “é uma medida da capacidade de filtragem das ações de garantia 
de qualidade e controle quando são aplicadas em todas as atividades da estruturas de processo”.
Pág. 20 de 99
Sendo Ea= número de erros encontrados antes que o software seja entregue ao usuário final 
e Dd= número de defeitos encontrados depois que o software foi entregue ao usuário final, o DRE 
pode ser assim definido:
O valor ideal para DRE é 1, ou seja, nenhum defeito é encontrado no software. Mas de forma 
mais realista, Dd será maior que 0. À medida que Ea aumenta é provável que o valor final de Dd 
diminua (erros são removidos antes de se tornarem defeitos) e o valor global de DRE comece a se 
aproximar de 1.
Um dos objetivos desta métrica é incentivar a equipe de desenvolvedores a incorporar técnicas 
para que seja encontrado o maior número de erros possível antes da entrega do software.
2.1.4 Métricas orientadas a Casos de Uso ou Use Cases (UCs)
Os casos de uso ou Use Cases (UCs) são amplamente utilizados como método para descrever 
requisitos no nível dos clientes ou no domínio do negócio. De acordo com Pressman e Maxim (2016, 
p. 714), os UCs são definidos no início do processo de software, permitindo que sejam usados para 
estimativas antes de iniciar atividades de modelagem e construção.
O UC é independente da linguagem de programação e sua quantidade é diretamente proporcional 
ao tamanho do software em LOC e à quantidade de casos de teste que terão de ser projetados para 
exercitar o software.
Vamos tratar desta métrica no capítulo de Estimativas de Software.
2.2 Métricas para o Modelo de Projeto
Apesar de existirem muitas métricas que podem ser usadas como indicadores para orientar 
a forma pela qual um novo projeto deva evoluir, muitos engenheiros de software não as utilizam. 
Como veremos neste tópico, realizar um projeto sem medição é algo inaceitável!
Pág. 21 de 99
2.2.1 Métricas para projeto Orientado a Objetos-OO
Figura 6 – Componentes de um projeto OO
Fonte: Bobicova Valeria/Shutterstock
De acordo com Pressman e Maxim (2016, p. 666), sistemas OO podem ser mensurados a partir 
das características:
• Tamanho: contabiliza as entidades OO como classes ou métodos acoplados à profundidade 
de uma árvore de herança.
• Complexidade: é definida pelas características estruturais do sistema OO, observando-se 
como as classes se inter-relacionam.
• Acoplamento: contabiliza as conexões físicas entre elementos do sistema OO como número 
de mensagens passadas entre objetos.
• Suficiência: responde a pergunta “que propriedades uma classe deve ter para ser útil?”, ou 
seja, se a classe possui as características dela requeridas.
• Totalidade: está relacionada com a suficiência, pois determina se a classe entrega o conjunto 
de propriedades que reflete totalmente as necessidades do domínio do problema.
• Coesão: é definida verificando se todos os métodos trabalham em conjunto para atingir uma 
finalidade única e bem definida.
• Originalidade: reflete o grau segundo o qual um método é atômico. Um método não pode ser 
construído por meio de uma sequência de outros métodos dentro de uma classe.
Pág. 22 de 99
• Similaridade: reflete o grau em que duas ou mais classes são similares em relação à sua 
estrutura, função, comportamento ou finalidade.
• Volatilidade: mede a probabilidade da ocorrência de uma modificação em um componente 
de um sistema OO.
Dentre estas características, as que mais se destacam são acoplamento e coesão. Uma boa 
aplicação OO deve seguir os princípios básicos de manter Baixo Acoplamento e Alta Coesão. 
Collares (2012) apresenta exemplos em Java que mostram soluções que corrigem erros para que 
estes princípios sejam mantidos:
“Elementos muito acoplados dependem muito uns dos outros, assim, se você altera um deverá 
alterar o outro.
Exemplo de Alto Acoplamento:
publicintgetIdade(){
returnUtil.getFuncoes.getFuncoesData.calculaIdade(nascimento);
}
Correção para Baixo Acoplamento:
publicintgetIdade(){
returnUtil.calculaIdade(nascimento);
}
Se uma classe faz mais do que ela deveria fazer, ela está com uma coesão baixa, e isso é ruim.
Exemplo de Baixa Coesão:
publicclass Aluno(){
String nome;
int[] notas;
publicvoidsetNome(String nome){
this.nome=nome;
}
publicStringgetNome(){
return nome;
}
publicvoidsetNotas(int[] notas){
this.notas=notas;
}
publicdoublecalculaMedia(){
//código para calcular média
return media;
}
}
Pág. 23 de 99
Exemplo de Alta Coesão:
publicclass Aluno(){
String nome;
publicvoidsetNome(String nome){
this.nome=nome;
}
publicStringgetNome(){
return nome;
}
}
publicclass Notas{
Aluno aluno;
int[] notas;
public Notas(Aluno aluno){
this.aluno=aluno;
}
publicvoidsetNotas(int[] notas){
this.notas=notas;
}
publicdoublecalculaMedia(){
//código para calcular média
return media;
}
}
”
2.2.2 Métricas orientadas a classes: métricas CK – Chidamber e Kemerer
A classe é a unidade fundamental de um sistema OO e as métricas associadas a uma classe 
individual e às colaborações entre classes podem ajudar na avaliação da qualidade de um projeto 
OO. Chidamber e Kemerer propuseram um conjunto de métricas para sistemas OO, denominado 
CK metrics suite, que é bastante conhecido.
As 6 métricas CK, de acordo com Pressman e Maxim (2016, p. 667-669) são assim definidas:• WWC – Weighted Methods per Class (métodos ponderados por classe): suponha que são 
definidos para uma classe C n métodos de complexidade c1, c2...cn. A métrica específica de 
complexidade escolhida (como complexidade ciclomática, por exemplo) deve ser normalizada 
de forma que a complexidade nominal para cada método assuma o valor 1.0.
• WWC = ∑ci para i de 1 a n
• Podemos concluir que o WWC deve ser mantido o mais baixo possível, pois à medida que o 
número de métodos de uma classe cresce, ela tende a se tornar cada vez mais específica 
daquela aplicação, deixando seu potencial de reutilização muito baixo.
Pág. 24 de 99
• DIT – Depth of the Inheritance Tree (profundidade da árvore de herança): essa métrica se refere 
ao comprimento máximo do nó até a raiz da árvore de hierarquia de classes. Na medida em 
que DIT cresce, é possível que classes de nível inferior herdem muitos métodos. Portanto, um 
DIT baixo mostra-se mais desejável. Um DIT alto leva a uma maior complexidade do projeto, 
mas por outro lado, pode implicar que haja muitos métodos que possam ser reutilizados. Na 
árvore de hierarquia de classes da figura 7, o DIT é 3.
Figura 7 – Diagrama de classes: exemplo de árvore de hierarquia de classes
ParedeCamera
PortaJanelaSegmento Parede 
tipo
paredeDimensão
tipo
ID
posição
campoVisão
anguloPan
de�nirZoom()
determinarTipo()
transladaPosição()
apresentar ID()
apresentarVisso()
apresentarZoom()
tipo
nome
externoDimensão
determinarTipo()
posicaoPlanta()
escala()
mudarCor()
É parte de
É usado
para construir
É usado
para construir
É usado para construir
Planta
É colocada em
determinar Tipo ()
calcularDimensão ()
tipo
inicioCoordenadas
�mCoordenadas
proximaPorta
tipo
inicioCoordenadas
�mCoordenadas
proximajanela
tipo
inicioCoordenadas
�mCoordenadas
proximaParede
determinarTipo()
desenhar()
determinarTipo()
desenhar()
determinarTipo ()
desenhar()
Fonte: Pressman; Maxim (2016, p. 191).
Pág. 25 de 99
• NOC – Number of Children (número de filhas): as subclasses diretamente subordinadas a uma 
classe na hierarquia de classes são chamadas de filhas. Na figura 7 a classe Parede tem 3 
subclasses SegmentoParede, Janela e Porta. Na medida em que o NOC aumenta, a quantidade 
de testes necessários para exercitar cada classe filha também aumenta.
• CBO – Coupling Between Object classes (acoplamento entre objetos de classes): o modelo 
CRC pode ser usado para determinar o valor do CBO, que se refere ao número de colaborações 
para uma classe. Na medida em que o CBO aumenta, as modificações e os testes resultantes 
destas modificações tornam-se mais complexos e a reutilização da classe pode ser reduzida.
Figura 8 – Exemplo de Cartão CRC
Responsabilidade:
De�ne o nome/ tipo da planta
Gerencia o posicionamento na planta
Amplia/reduz a planta para exibição
Amplia/reduz a planta para exibição
Incorpora paredes. portas e janelas
Mostra a posição das câmeras de vídeo
Colaborador:
Parede
Camera
Classe: Planta
Fonte: Pressman; Maxim (2016, p. 192).
Pág. 26 de 99
SAIBA MAIS
Cartão CRC - Class-Responsibility-Collaborations
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir 
responsabilidades durante o projeto OO.
CRC cards foram inventados por Ward Cunningham e Kent Beck. Cartão CRC é um cartão pequeno 
(para só escrever o essencial) para cada classe. Escreve-se o nome da classe, suas responsabilidades 
e colaborações. Só se pensa nas responsabilidades de alto nível. Os cartões são desenvolvidos em 
pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes.
Figura 9 – Exemplo de Cartão CRC
Veri�ca se item está em estoque 
Determina preço
Veri�ca pagamento válido
Envia para endereço destino
Linha Detalhe
Linha Detalhe
Cliente
Pedido
Nome da classeResponsabilidade
Colaboração
Fonte: <http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/proj1/proj5.htm>.
• RFC - Response for a Class (resposta para uma classe): corresponde ao conjunto de métodos 
em potencial que podem ser executados em resposta a uma mensagem recebida por um 
objeto daquela classe. Na medida em que a RFC aumenta, tanto o trabalho de teste quanto a 
complexidade da classe também aumentam.
• LCOM – Lack of Cohesion Methods (falta de coesão em métodos): cada método em uma 
classe pode acessar um ou mais atributos. LCOM corresponde ao número de métodos que 
acessam um ou mais atributos em comum. Se nenhum método acessa os mesmos atributos, 
LCOM = 0. Para exemplificar, considere uma classe com 6 métodos: 4 dos métodos têm um 
ou mais atributos em comum; portanto, LCOM =4. Para manter a coesão alta, é desejável se 
manter LCOM baixo.
Pág. 27 de 99
2.3 Métricas para Medição de Software
As métricas de software podem ser classificadas como diretas e indiretas. As medidas diretas 
do produto incluem linhas de código (Lines of Code – LOC) produzidas, velocidade de execução, 
tamanho da memória e defeitos relatados em certo período de tempo. As medidas indiretas do 
produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade, 
entre outras.
2.3.1 Métricas orientadas a tamanho – Lines of Code (LOC)
De acordo com Pressman e Maxim (2016, p. 709), medidas de software orientadas a tamanho 
são criadas pela normalização das medidas de qualidade e/ou produtividade, considerando-se o 
tamanho do software produzido.
Figura 10 – Linhas de Código (Lines of Code – LOC)
Fonte: Iurii Stepanov/Shutterstock
As linhas de código podem ser escolhidas como valor de normalização, pois são a medida mais 
utilizada para medir o tamanho de um programa. São de fácil definição e precisão, devendo ser 
usadas como um indicador. A partir da medição de LOC ou KLOC (mil linhas de código), as métricas 
podem fornecer:
• erros por KLOC;
• defeitos por KLOC;
• custo por KLOC; e
• páginas de documentação por KLOC.
Pág. 28 de 99
A partir delas, outras métricas podem ser derivadas, como:
• erros por pessoa-mês;
• KLOC por pessoa-mês; e
• custo por página de documentação.
Porém vale lembrar que a qualidade do código-fonte não pode ser medida pela quantidade de 
linhas de código e sim pela organização de tais linhas visando a manutenção e o reúso. Além disso, 
essas métricas não são a melhor maneira de medir os processos de software.
2.3.2 Métricas de Halstead
Figura 11 – Maurice Halstead – Software Science
Fonte: <https://www.cs.purdue.edu/homes/bxd/images/halstead.jpg>.
Maurice Halstead, em sua teoria da Ciência do Software, propôs leis quantitativas para o 
desenvolvimento de software usando um conjunto de medidas, assim definidas de acordo com 
Pressman e Maxim (2016, p. 675):
• n1 = número de operadores distintos que há em um programa
• n2 = número de operandos distintos que há em um programa
• N1 = número total de ocorrências de n1 (operadores)
• N2 = número total de ocorrências de n2 (operandos)
Pág. 29 de 99
Com base nestas medidas, podem ser calculados:
n = n1 + n2(vocabulário do programa)
N = n1 log2n1 + n2 log2n2(tamanho do programa)
V = (N1 + N2) x log2(n1 + n2)(volume do programa)
D = n1/2 x N2/n2 (dificuldade do programa)
Exemplo de aplicação das métricas de Halstead
main() {
int a, b, c, med;
scanf(“%d %d %d”, &a, &b, &c);
med = (a + b + c) / 3;
printf(“med = %d”, med);
}
n1 (operadores únicos)= 12 main, (), {}, int, scanf, &, =, +, /, printf, 
“ , ;
n2 (operandos únicos)= 7 a, b, c, med, “%d %d %d”, 3, “med = %d”
N1= 30
N2= 15
n =n
1
 + n
2
 = 19(vocabulário do programa)
N =n
1
 log
2
n
1
 + n
2
 log
2
n
2
= 12x log
2
12 + 7xlog
2
7
=12x3.58 + 7x2.81 = 42.96 + 19.67 = 62.63(tamanho do programa)
V =(N
1
 + N
2
) x log
2
 (n
1
 + n
2
) = 45 x log
2
19 =45 x 4.25 = 191.25(volume do 
programa)
D =n
1
/2 x N
2
/n
2
=12/2 x 15/7 = 12.85 (dificuldade do programa){\
displaystyle E=D\times V}
2.3.3 Métricas Halstead aplicadas ao teste
O trabalho de testes, de acordo com Pressman e Maxim (2016, p. 676), pode ser baseado com 
base nasmétricas de Halstead, podendo ser obtidas as métricas:
PL = 1/ Dou 1 / [(n1/2) x (N2/n2)]
e = V / PL ou (N1 + N2) x log2 (n1 + n2)/PL
Pág. 30 de 99
A porcentagem de trabalho de teste global a ser dispensado a um determinado módulo k pode 
ser estimada com base na seguinte equação, na qual o denominador é a soma do trabalho de 
Halstead por todos os módulos do sistema:
Porcentagem de trabalho de teste (k) = e (k) / ∑ e(i)
2.3.4 Complexidade Ciclomática
A complexidade ciclomática mede a complexidade de um determinado módulo (classe, método, 
função etc), com base na contagem do número de caminhos independentes que ele pode executar 
até o seu fim. Um caminho independente é o que apresenta pelo menos um desvio de fluxo ou um 
novo conjunto de comandos a serem executados.
Essa métrica parte do princípio de que, medindo a complexidade do programa, é possível saber 
quantos caminhos lógicos devem ser testados. Pode ser representada por um grafo de fluxo de 
controle, no qual os nós representam uma ou mais instruções sequenciais e os arcos orientados 
indicam o sentido do fluxo de controle entre as instruções. Sendo e (edges) o número de arestas 
e n (nodes) o número de nós, a complexidade ciclomática v(G) de um grafo pode ser calculada 
através da fórmula:
v(G) = e - n + 2
Pág. 31 de 99
Um exemplo de um trecho de programa (procedimento) em pseudocódigo e seu correspondente 
grafo de fluxo é mostrado na figura 12.
Figura 12 – Um trecho de programa e seu grafo de fluxo
Procedimento
Então
Fim-Se
9
8
7
13
12
10
11
2
5
3
46
média (valor[])
i=1;
soma=0;
total. entrada=0;
total.válidas=0
Faça-Enquanto
incremente total.válidas de 1; 
soma = soma +valor [i]
incremente total.entrada de 1;
Se (valor[i]≥min E valor[i]≤max)
(valor[i]≠-999Etotal.entrada<100)
Fim-Enquanto
Se total.válidas>0
Então média = soma/total.válidas;
Senão média = -999;
Fim-Se
Fim- média
incremente i de 1;
1
13
1
2
3
4
5
6
7
9
8
11
10
12
Fonte: <https://www.treinaweb.com.br/blog/complexidade-ciclomatica-analise-estatica-e-refatoracao/>.
No grafo da figura acima há 17 arestas e 13 nós. O cálculo da complexidade ciclomática é:
v(G) = e - n + 2 = 17 – 13 + 2 = 6
Mas há outra forma de fazer o cálculo da complexidade ciclomática, que implica o mesmo 
resultado. Considerando que R seja o número de regiões do grafo de fluxo:
v(G) = R
Pág. 32 de 99
Observe a figura a seguir. O grafo de fluxo da figura 13 foi demarcado com as regiões. Como 
são 6 regiões, v(G) continua sendo 6, como no cálculo anterior.
Figura 13 – Grafo de fluxo com regiões do trecho de programa da figura 12
R1
R5
R4
R3
R6
R2
1
5
7
9
8
13
12
1
2
3
410
11
6
Fonte: <https://www.treinaweb.com.br/blog/complexidade-ciclomatica-analise-estatica-e-refatoracao/>.
2.4 Métricas para Manutenção
De acordo com Pressman e Maxim (2016, p. 678), pode ser calculado um SMI – Software Maturity 
Index (índice de maturidade de software) que fornece a indicação da estabilidade de um produto de 
software com base nas alterações que ocorrem em cada versão deste produto. Para este cálculo, 
devem ser obtidas as seguintes medidas:
• MT = número de módulos da versão atual
• Fc = número de módulos da versão atual que foram alterados
• Fa = número de módulos da versão atual que foram acrescentados
• Fd = número de módulos da versão anterior que foram excluídos da versão atual 
 
SMI = [MT – (Fc + Fa + Fd)] / MT
Pág. 33 de 99
3. ESTIMATIVAS DE SOFTWARE – PARTE 1
3.1 Estimativas de Software e Planejamento de Projeto
Quando estamos envolvidos em um projeto de software, antes mesmo de começarmos a realizá-
lo, precisamos lidar com alguns aspectos decisivos para o seu sucesso ou fracasso. Alguns destes 
aspectos, relacionados ao gerenciamento de projetos, são: escopo, custo, recursos e cronograma. 
Mas, de uma maneira mais geral, podemos dizer que o planejamento de um projeto de software 
envolve atividades como: Estimativa, Cronograma, Análise e gestão de risco, Planejamento da gestão 
da qualidade e Planejamento da gestão de mudanças.
Figura 14 – Planejamento do Projeto
Fonte: dizain/Shutterstock
A estimativa é imprescindível para que sejam determinados a demanda de custos, esforço, 
recursos e tempo necessários para a criação do sistema ou artefato de software. Portanto, torna-
se necessária grande dedicação a este assunto.
A estimativa de software é vista tanto como arte quanto como ciência e o desenvolvedor conta 
com várias técnicas úteis para auxiliá-lo. As métricas de processo e projeto coletadas ao longo de 
projetos anteriores fornecem uma base importante para a geração de estimativas quantitativas. 
Mas é importante ressaltar que a experiência do pessoal envolvido pode ajudar imensamente na 
medida em que as estimativas são desenvolvidas e revistas.
Pág. 34 de 99
O planejamento de projeto fornece um guia para a Engenharia de Software bem sucedida. A 
estimativa é importante porque estabelece uma base para todas as outras atividades de planejamento 
de projeto.
Normalmente, as estimativas são feitas dentro de um período de tempo limitado no início do 
projeto e devem ser atualizadas regularmente à medida que o projeto avança. As abordagens 
modernas de Engenharia de Software, como os modelos evolucionários e modelos ágeis, assumem 
uma visão iterativa do desenvolvimento de software. Em tais abordagens, é possível revisitar a 
estimativa à medida que mais informações são conhecidas, permitindo, assim, revisá-la quando o 
cliente solicita modificações nos requisitos.
A estimativa de recursos, de custo e de cronograma exige experiência, acesso às informações 
históricas consistentes e empenho nas previsões quantitativas, quando informação qualitativa, em 
alguns casos, é tudo o que há disponível.
Toda estimativa tem incerteza e isso acaba acarretando riscos ao projeto. Se o escopo do 
projeto é mal entendido ou se os requisitos estão sujeitos a mudanças frequentes, a incerteza e o 
risco podem se tornar perigosamente altos.
Para tratarmos as estimativas de software, precisamos considerar o conjunto de tarefas 
relacionadas ao Planejamento de Projeto. O planejamento do projeto de software objetiva proporcionar 
um framework para que o gerente de projetos possa fazer estimativas adequadas de recursos, custos 
e cronograma. De acordo com Pressman e Maxim (2016, p. 730) as tarefas associadas a um bom 
planejamento de projeto são:
1. Estabelecer o escopo do projeto .
2. Determinar a viabilidade do projeto .
3. Definir os recursos necessários (recursos humanos, softwares reutilizáveis, ambiente de 
desenvolvimento) .
4. Realizar as estimativas do projeto .
5. Fazer a Gestão de Riscos .
6. Desenvolver o cronograma do projeto .
A seguir as tarefas 1, 2, 3 e 4 serão detalhadas, sendo que os modelos de estimativas empíricos 
serão tratados no capítulo subsequente. As tarefas 5 e 6 serão tratadas em outros capítulos 
separadamente.
Pág. 35 de 99
3.2 Planejamento do Projeto: escopo e viabilidade do projeto
Pressman e Maxim (2016, p. 727), fazem uma interessante pergunta sobre estimativas: “Você 
construiria uma casa sem saber quanto iria gastar, que tarefas precisariam ser feitas e quais seriam 
os prazos para executá-las?”. Faço a mesma pergunta a você, caro aluno. Certamente sua resposta 
seria: não. Como a maioria dos sistemas e produtos de software pode custar consideravelmente 
mais do que construir uma casa, é muito razoável fazer uma estimativa antes de se começar a criar 
software.
A primeira atividade de planejamento do projeto de software é a determinação do escopo. O 
escopo do software descreve as funções e características que devem ser ofertadas aos usuários, o 
conjunto de dados de entrada e saída, o desempenho, as restrições, as interfaces e a confiabilidade 
que limitam o sistema. O escopo geralmente é definido por meio de:
• uma descrição narrativa do escopo do software após a comunicação com todos os stakeholders 
(partes interessadas);e
• um conjunto de casos de uso desenvolvido com a participação dos usuários (clientes).
Em ambos os caminhos é necessária uma intensa comunicação entre desenvolvedores e 
clientes. A técnica mais utilizada para isso é conduzir uma reunião preliminar ou uma entrevista, 
mas existem técnicas mais avançadas que visam facilitar essa comunicação. Como exemplo, 
podemos citar o FAST- Facilitated Application Specification Technique que é uma abordagem que 
visa encorajar a criação de uma equipe de clientes e desenvolvedores que trabalham juntos para 
identificar o problema, propor elementos de solução, negociar diferentes abordagens e especificar 
um conjunto preliminar de requisitos.
Pág. 36 de 99
A figura 15 mostra as atividades relacionadas ao processo “Definir o escopo” de acordo com o 
guia PMI/PMBoK 5ª edição.
Figura 15 – Atividades do processo Definir o Escopo
5.3
De�nir
o escopo
4.1
Desenvolver o 
termo de abertura 
do projeto
5.2
Coletar os
requisitos
6.3
Sequenciar
as atividades
6.5
Estimar as durações 
das atividades
6.6
Desenvolver o 
cronograma
• Plano de 
 gerenciamento
 do escopo
• Documentação
 dos requisitos
• Atualizações nos
 documentos do projeto
• Declaração 
 do escopo
 do projeto
• Termo de 
 dabertura do 
 projeto
• Ativos de 
 processos 
 organizacionais
Empresa/
organização
5.1
Planejar o 
gerenciamento 
do escopo
Gerenciamento do escopo do projeto
5.4
Criar a estrutura
analitica do 
projeto (EAP)
Documentos І
do projeto
Fonte: PMI/PMBoK (2013, p. 120).
Uma vez entendido o escopo, é importante determinar a viabilidade do projeto dentro das 
dimensões delimitadas de: tecnologia, orçamento, tempo e recursos. Isso é importante para evitar 
dedicar esforço e dinheiro em um projeto que pode estar condenado ao fracasso desde o início.
Pág. 37 de 99
3.3 Planejamento do Projeto: Recursos do projeto
Uma tarefa importante no planejamento é a estimativa de recursos necessários para o 
desenvolvimento do software. A figura 16 ilustra as três principais categorias de recursos de 
Engenharia de Software com que devemos nos preocupar em um projeto: recursos humanos, 
softwares reutilizáveis e ambiente de desenvolvimento.
Figura 16 – Recursos de Engenharia de Software para o planejamento de estimativas
Ambiente Pessoas
Projeto
Software
reutilizável
Recursos
de rede
Ferramentas
de software
Hardware
Número
Habilidade
Localização
Novos
componentes
Componentes
parcialmente
testados
Componentes
de prateleira
(COTS)
Componentes
completamente
testados
Fonte: Pressman; Maxim (2016, p. 731).
• Recursos humanos: após a avaliação do escopo, é realizada a seleção de habilidades necessárias 
para a conclusão do desenvolvimento, que envolve a especificação de cargos (como gerente 
de projeto, engenheiro de software sênior etc.) e a especialização (como banco de dados, teste, 
arquitetura cliente-servidor etc). Caso o projeto seja grande, a equipe pode estar geograficamente 
dispersa, o que requer a especificação da localização de cada recurso humano.
• Recursos de software reutilizáveis: as práticas de engenharia de software baseadas em 
componentes enfatizam a capacidade de reutilização. Esses componentes devem ser 
Pág. 38 de 99
catalogados, padronizados e validados, podendo ser agrupados em quatro categorias: de 
prateleira (software já existente adquirido de terceiros ou de um projeto anterior), completamente 
testados (especificações, projetos, códigos ou dados de testes já existentes e validados), 
parcialmente testados (idem ao anterior, mas que requerem modificação significativa para 
serem usados) e novos (construídos pela equipe especificamente para o projeto).
• Recursos do ambiente de desenvolvimento: o Software Engineering Environment – SEE incorpora 
hardware e software, ou seja, uma plataforma de hardware que suporta as ferramentas de 
software necessárias para produzir os artefatos que irão compor o produto em desenvolvimento. 
Cada elemento de hardware e software deve ser especificado como parte do planejamento.
3.4 Planejamento do Projeto: Estimativas do projeto
As estimativas de custo e esforço envolvem muitas variáveis como fatores humanos, técnicos, 
ambientais e políticos, que podem afetar o custo final do projeto e o esforço necessário para 
desenvolvê-lo.
Pressman e Maxim (2016, p. 733) indicam as seguintes opções que ajudam na obtenção de 
estimativas de custo e esforço que sejam confiáveis:
1. Adie a estimativa até que o projeto esteja mais adiantado: quanto mais tarde você fizer a 
estimativa, maior a probabilidade de acertar.
2. Baseie as estimativas em projetos semelhantes que já foram concluídos.
3. Use técnicas de decomposição: essas técnicas utilizam uma abordagem do tipo “dividir 
para conquistar”, que seria decompor o projeto em suas funções principais e atividades 
relacionadas.
4. Use um ou mais modelos empíricos para estimativas de custo e esforço.
Infelizmente, apesar de atraente, a opção 1 não é prática pois, normalmente, o cliente exige 
estimativas de custo e prazo logo no início. Desta forma, o adiamento deve ser feito com muito 
bom senso. A opção 2 depende fundamentalmente dos dados históricos usados para alimentar a 
estimativa; mas ainda que existam, nem sempre a experiência passada funciona como um bom 
indicador de estimativas futuras.
Na maioria das vezes, o problema de desenvolver uma estimativa de custo e esforço para um 
determinado projeto é muito complexo para ser considerado como um todo. Devido a isso, as 
técnicas de decomposição indicadas na opção 3, que reduzem o problema em um conjunto de 
Pág. 39 de 99
problemas menores, se mostram atrativas, pois se espera que, com essa divisão, se torne mais 
fácil chegar à solução.
A opção 4 indica o uso de modelos empíricos. Esses modelos podem ser usados para complementar 
as técnicas de decomposição e oferecer uma estratégia valiosa.
A precisão da estimativa de um projeto depende dos seguintes fatores:
• o grau com que o planejador estimou adequadamente o tamanho do produto a ser construído;
• a aptidão para traduzir a estimativa de tamanho em esforço humano, tempo transcorrido e 
dinheiro;
• o grau com que o plano de projeto reflete a capacidade da equipe de software; e
• a estabilidade dos requisitos do produto e do ambiente que apoiam o esforço de Engenharia 
de Software.
Ferramentas automáticas de estimativa implementam uma ou mais técnicas de decomposição 
ou modelos empíricos, fornecendo uma interessante alternativa.
A seguir estudaremos algumas técnicas de decomposição e modelos empíricos.
3.4.1 Técnica de decomposição: Estimativa Baseada em Problema
Como uma estimativa de projeto é tão boa quanto a estimativa do tamanho do trabalho a ser 
realizado, o dimensionamento representa o primeiro grande desafio do planejador de projeto. Para 
a determinação do tamanho do produto a ser construído, as abordagens mais utilizadas são:
• abordagem direta (medido em LOC – Lines of Code, por exemplo);
• abordagem indireta (medido em FP– Function Points, por exemplo).
De acordo com Pressman e Maxim (2016, p. 734), dados de LOC e FP são usados de duas 
maneiras distintas durante a estimativa do projeto de software: 1) como variáveis de estimativa para 
dimensionar cada elemento do software e 2) como métricas de referência coletadas de projetos 
anteriores e usadas em conjunto com variáveis de estimativa para desenvolver projeções de custo 
e esforço.
Pág. 40 de 99
Em relação às técnicas de estimativa baseadas em LOC e FP, elas diferem quanto ao nível de 
detalhe necessário para a decomposição:
• Estimativa LOC: a decomposição considera que todas as funções podem ser decompostas 
em subfunções semelhantes a entradas de uma base de dados histórica (quanto maior for 
o grau de particionamento, mais provável será que estimativas precisas de LOC possam ser 
desenvolvidas)
• Estimativa FP: em vez de focalizar a função, é estimada cada uma das características do 
domíniode informação (entradas, saídas, arquivos de dados, consultas, interfaces externas), 
bem como os 14 valores de ajuste de complexidade.
Como alternativa, o planejador pode escolher outros componentes para dimensionar, como 
classes, objetos, casos de uso, modificações ou processos do negócio afetados.
Métricas referenciais de produtividade (por exemplo, LOC/PM ou FP/PM, onde PM=Pessoa por 
Mês) são então aplicadas à variável de estimativa adequada e o custo ou esforço correspondente 
à função é derivado. Em seguida, as estimativas de função são combinadas para produzir uma 
estimativa global para todo o projeto.
A experiência mostra que, frequentemente, há uma variação nos valores das métricas de 
produtividade de uma organização. Portanto, o uso como referencial de um único valor obtido de 
uma dada métrica não é recomendável.
O ideal é que a média de cada métrica deva ser calculada por domínio de projeto. Os projetos 
devem ser agrupados por tamanho de equipe, área de aplicação, complexidade e outros parâmetros 
relevantes. Em seguida, médias locais dos domínios devem ser calculadas.
No caso de estimativas de um novo projeto, ele deve ser primeiro classificado em um domínio 
e depois a média da métrica do domínio adequado deve ser usada para gerar a estimativa.
Independentemente da variável de estimativa que é usada (LOC, FP, número de classes, número 
de casos de usoetc), o planejador começa estimando um intervalo de valores para cada função 
(LOC, por exemplo) ou o valor do domínio de informação (FP, por exemplo).
Usando dados históricos (ou intuição caso todo o resto falhar), são estimados um valor de tamanho 
otimista (Tot), um mais provável (Tmp)e um pessimista (Tpess)para cada função ou contagem para 
Pág. 41 de 99
cada valor do domínio de informação. Isso possibilita o cálculo de um valor esperado para a variável 
de estimativa tamanho (T), para cada função (LOC) ou valor do domínio de informação (FP).
Um exemplo de cálculo de um valor esperado para T pode ser a média ponderada:
T = ( Tot + 4Tmp + Tpess ) / 6
Uma vez determinado o valor esperado para a variável de estimativa de tamanho T, os dados 
históricos de LOC ou PF são aplicados.
A seguir, por meio de alguns exemplos, vamos ver a aplicação do que descrevemos, adotando 
algumas técnicas de estimativas.
3.4.2 Exemplos de Estimativas Baseadas em LOC
Exemplo 1:
Suponha um determinado software que será desenvolvido. Este software é do tipo CAD – 
Computer-Aided Design, ou seja, tem uma aplicação científica. Após a análise do escopo do software, 
suas funções principais foram identificadas e são relacionadas na tabela 3.
Tabela 3 – Principais funções identificadas no software CAD
Função Estimativa de LOC
Recursos de Visualização 3000
Recursos de Análise 2D 5000
Recursos de Análise 3D 6400
Recursos de Controle e Interface com o usuário 3300
Administração da Base de Dados 6000
Recursos de Controle de Periféricos 1000
Recursos de Análise de Projetos 7700
Estimativa das Linhas de Código (Total) 32400
Fonte: elaborado pelo autor.
Pág. 42 de 99
Em seguida, um intervalo de estimativa de LOC é desenvolvido para cada função. Esse intervalo 
considera as estimativas como otimista, mais provável e pessimista.
Os valores das estimativas apresentados na tabela 3, para cada função, foram obtidos utilizando 
a expressão para T já apresentada (T =(Tot + 4Tmp + Tpess)/6).
Por exemplo, para a função “Recursos de Análise 3D”, foram obtidas: estimativa otimista Tot= 
3800 LOC; mais provável Tmp= 6500 LOC; pessimista TPess= 8600 LOC. Estes valores, aplicados 
na equação T= (3800 + 4x6500 + 8600)/ 6, produzem um valor esperado de T= 6400 LOC.
Após o cálculo das estimativas de LOC para cada função, foi identificada uma estimativa de 
32400 LOC para o sistema a ser desenvolvido.
Considerando que uma análise de dados históricos revelou que a produtividade organizacional 
média para sistemas desse tipo é de 500 LOC/pessoas-mês e que o valor bruto da mão de obra é 
de R$ 4000,00 por pessoa-mês, o custo por linha de código é de aproximadamente:
Custo por LOC = (valor bruto da mão de obra)/(produtividade média)
= (4000 reais/pessoas-mês)/(500 LOC/pessoas-mês)
= 8 reais/LOC
Portanto, o custo total estimado para o projeto é de:
Custo total estimado do projeto = (Estimativa de LOC)*(Custo por LOC)
= (32400 LOC) * (8 reais/LOC)
= 25920.00 reais/mês
O esforço necessário estimado para desenvolver o projeto é de:
Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)
= (32400 LOC)/(500 LOC/pessoas-mês)
≅ 65 pessoas-mês
Pág. 43 de 99
Exemplo 2:
A tabela 4 apresenta as estimativas de tamanho otimista, mais provável e pessimista para 
cada uma das funções a serem implementadas no software CAD do exemplo 1. Considerando que 
a empresa de software responsável em desenvolver o projeto produz 400 LOC/por mês, com um 
valor bruto de mão de obra de R$ 3000,00 por pessoa-mês, podemos, com base nesses dados, 
obter a estimativa de custo e esforço necessários para construir o software usando a técnica de 
estimativa baseada em LOC.
Tabela 4 – Estimativas de Tamanho Otimista, Mais Provável e Pessimista (em LOC)
Função Otimista(Tot) Mais Provável(Tmp) Pessimista(Tpess)
Recursos de Visualização 3000 4400 6000
Recursos de Análise 2D 5000 5500 6500
Recursos de Análise 3D 6400 7000 6900
Recursos de Controle e Interface 
com o usuário 3300 2500 2300
Administração da Base de Dados 6000 4100 2600
Recursos de Controle de 
Periféricos 1000 2800 4200
Recursos de Análise de Projetos 7700 7900 8200
Fonte: elaborado pelo autor.
Pág. 44 de 99
A tabela 5 apresenta o cálculo do tamanho de cada uma das funções (em LOC) utilizando a 
expressão apresentada anteriormente T=(Tot + 4Tmp + Tpess)/6.
Tabela 5 – Cálculo do tamanho de cada função
Função Estimativa de LOC
Recursos de Visualização T1 = ( Tot + 4Tmp + Tpess ) / 6 ≅4433
Recursos de Análise 2D T2 = ( Tot + 4Tmp + Tpess ) / 6 ≅5583
Recursos de Análise 3D T3 = ( Tot + 4Tmp + Tpess ) / 6 ≅6883
Recursos de Controle e Interface com o usuário T4 = ( Tot + 4Tmp + Tpess ) / 6 ≅2600
Administração da Base de Dados T5 = ( Tot + 4Tmp + Tpess ) / 6 ≅4167
Recursos de Controle de Periféricos T6 = ( Tot + 4Tmp + Tpess ) / 6 ≅2733
Recursos de Análise de Projetos T7 = ( Tot + 4Tmp + Tpess ) / 6 ≅7197
Estimativa das Linhas de Código (Total) 34317 LOC
Fonte: elaborado pelo autor.
Utilizando as estimativas de tamanho e os dados do valor bruto da mão de obra e produtividade 
fornecidos anteriormente, podemos calcular as estimativas de esforço e custo total conforme 
indicado a seguir.
Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)
= (34317 LOC)/(400 LOC/pessoas-mês)
≅ 86 pessoas-mês
Custo por LOC = (valor bruto da mão de obra) / (produtividade média)
= (3000 reais/pessoas-mês) / (400 LOC/pessoas-mês)
= 7 .50 reais/LOC
Custo total estimado do projeto=(Estimativa de LOC) * (Custo por LOC)
= (34317 LOC) * (7 .50 reais/LOC)
≅ 257400 .00 reais
Pág. 45 de 99
3 .4 .3 Exemplos de Estimativas Baseadas em Pontos de Função (FP)
No caso de Pontos de Função (PF) ou Function Points (FP), conforme falamos anteriormente, a 
decomposição tem foco nos valores do domínio de informação ao invés das funções do software. 
Neste método, a estimativa é registrada em uma tabela, como a tabela 6.
Tabela 6 – Estimativa de valores do domínio de informações (FP)
Valor do 
domínio da 
informação
Otimista(Tot) Mais 
Provável 
(Tmp)
Pessimista 
(Tpess)
Estimativa 
Contagem
Fator 
de 
Peso
Contagem 
x 
Fator de 
Peso
Nº de 
Entradas 
Externas (EIs)
Nº de Saídas 
Externas 
(EOs)
Nº de 
Consultas 
Externas 
(EQs)
Nº de ArqLóg 
Internos (ILFs)
Nº de 
ArqInterf 
Externos 
(EIFs)
Contagem 
Total –>
Fonte: Pressman; Maxim (2016, p. 739).
ATENÇÃO: para a aplicação de Estimativas Baseadas em FP, é essencial que você consulte a tabela 
1 (Tabela para Pontos de Função), o quadro 1 (14 perguntas relacionadas às funcionalidades) e o quadro2 (Escala de VAFs – Value Adjustment Factors) utilizados no modelo de cálculo de pontos por função.
Uma vez que se tenha obtido a produtividade média da equipe de desenvolvimento para esse 
tipo de projeto e o valor bruto salarial, pode-se, analogamente ao que foi feito para LOC, calcular as 
estimativas para o custo total do projeto e o esforço necessário para concluí-lo.
Pág. 46 de 99
Exemplo 3:
Suponha que a sua empresa foi contratada para desenvolver determinado software. Considere 
que a empresa tem um alto grau de maturidade no desenvolvimento de software. Devido a isso, 
tem procedimentos de coleta de dados, cálculo de métricas e armazenamento desses valores em 
uma base de dados, organizada considerando softwares do mesmo domínio de aplicação.
Após uma análise preliminar na base de dados da empresa, foram obtidos os valores relacionados 
na tabela 7.
Tabela 7 – Valores obtidos na base de dados da empresa
Valor do 
domínio da 
informação
Otimista(Tot) Mais 
Provável 
(Tmp)
Pessimista 
(Tpess)
Estimativa
Contagem
Fator 
de Peso
Contagem 
x Fator de 
Peso
Nº de 
Entradas 
Externas 
(EIs)
26 32 40
Nº de 
Saídas 
Externas 
(EOs)
17 20 26
Nº de 
Consultas 
Externas 
(EQs)
10 15 22
Nº de 
ArqLóg 
Internos 
(ILFs)
6 14 19
Nº de 
ArqInterf 
Externos 
(EIFs)
4 5 7
Contagem Total –>
Fonte: elaborado pelo autor.
Pág. 47 de 99
Utilizando os dados do exemplo 2 proposto e considerando que o fator de peso (conforme tabela 
8) seja simples para todos os parâmetros da tabela 7 e que os valores de ajuste de complexidade 
para os 14 fatores sejam considerados de influência moderada (valor 2), estime o custo e o esforço 
necessários para construir o software usando a técnica de estimativa baseada em FP. Considere 
que a produtividade média para sistemas desse domínio seja de 5 FP/pessoas-mês.
Para facilitar os cálculos que iremos fazer, vamos reproduzir na tabela a seguir os Fatores de 
Peso indicados na tabela 1.
Tabela 8 – Fatores de Peso para Pontos de Função
 
Valor do domínio da informação
Fator de Peso
Simples Médio Complexo
Nº de Entradas Externas (EIs) 3 4 6
Nº de Saídas Externas (EOs) 4 5 7
Nº de Consultas Externas (EQs) 3 4 6
Nº de ArqLóg Internos (ILFs) 7 10 15
Nº de ArqInterf Externos (EIFs) 5 7 10
Fonte: elaborado pelo autor.
Para começarmos a solucionar o problema da empresa, precisamos completar a tabela 7. A 
tabela 8 apresenta a tabela 7 com todas as colunas preenchidas.
Na tabela 9, os valores de Estimativa Contagem apresentados na 5ª coluna foram obtidos através 
da expressão T = (Tot + 4*Tmp + Tpess)/6.
Uma vez obtidos esses valores de Contagem Estimada, foram considerados os fatores de peso 
simples (tabela 8). Esses valores estão relacionados na 6ª coluna – Fator de Peso- da tabela 9.
De posse dos valores de Estimativa Contagem e Fator de Peso, obtemos a sua multiplicação 
que é apresentada na 7ª coluna da tabela 8 – Contagem x Fator de Peso.
A soma dos valores dessa 7ª coluna resulta no valor da Contagem Total que, no caso da empresa, 
foi de 346.
Pág. 48 de 99
Tabela 9 – Tabela completa para o caso da empresa
Valor do 
domínio da 
informação
Otimista(Tot) Mais 
Provável 
(Tmp)
Pessimista 
(Tpess)
Estimativa
Contagem
Fator 
de 
Peso
Contagem 
x Fator de 
Peso
Nº de 
Entradas 
Externas 
(EIs)
26 32 40 32.33 3 97
Nº de Saídas 
Externas 
(EOs)
17 20 26 20.50 4 82
Nº de 
Consultas 
Externas 
(EQs)
10 15 22 15.33 3 46
Nº de ArqLóg 
Internos 
(ILFs)
6 14 19 13.50 7 95
Nº de 
ArqInterf 
Externos 
(EIFs)
4 5 7 5.17 5 26
Contagem 
Total –>
346
Fonte: elaborado pelo autor.
Como no enunciado do exemplo foi dito para considerarmos os valores de ajuste de complexidade 
para os 14 fatores como de influência moderada (igual a 2, conforme quadro 2), isso resultará em 
um somatório: 14 * 2 = 28.
Substituindo os valores de Contagem Total (346) e o somatório dos 14 fatores de ajustes (28) 
na expressão 
obtemos: 
Estimativa de FP = 346 x (0.65 + 0.01 x 28) ≅ 321
Pág. 49 de 99
Dessa forma, podemos calcular as estimativas de Custo Total Estimado do projeto e Esforço 
necessário para desenvolvê-lo, conforme apresentado a seguir.
Custo por FP = (valor bruto da mão de obra)/(produtividade média)
= (3000 reais/pessoas-mês)/ (5 FP/pessoas-mês)
= 600 .00 reais/FP
Esforço necessário estimado=(Estimativa de PF)/(produtividade média)
= (321 FP) / ( 5 FP/pessoas-mês)
= 64 .2 pessoas-mês
Custo total estimado do projeto =(Estimativa de FP)*(Custo por FP)
= (321 FP) * (600 reais/FP)
≅ 192600 .00 reais
4. ESTIMATIVAS DE SOFTWARE – PARTE 2
4.1 Modelos de Estimativa Empíricos
Alguns modelos de estimativa para software usam fórmulas empíricas. Essas fórmulas são 
derivadas usando análise de regressão de dados coletados de projetos anteriores. Normalmente 
usa-se uma amostra limitada de dados de projetos.
Cada modelo de estimativa é adequado para um determinado conjunto de classes de software e 
ambientes de desenvolvimento, ou seja, são dependentes dos dados dos projetos que foram usados 
para obtê-los. Devido a isso, geralmente esses modelos de estimativa devem ser adaptados para 
as condições locais da organização.
É claro que, antes de serem usados na sua empresa, esses modelos devem ser testados usando 
resultados de projetos finalizados. Os dados estimados pelo modelo devem ser comparados aos 
resultados reais e a eficácia do modelo deve ser analisada para as condições locais.
Pág. 50 de 99
De acordo com Pressman e Maxim (2016, p. 744), a estrutura geral dos modelos empíricos tem 
a forma:
E = A + B x (ev)c
Onde:
A, B, c são constantes derivadas empiricamente
E esforço em pessoas-mês
ev variável de estimativa (LOC ou PF)
A maioria dos modelos de estimativa tem alguma forma de fator de ajuste ao projeto. Isso permite 
que a variável E seja ajustada por características específicas do projeto, tais como complexidade 
do problema, experiência da equipe e ambiente de desenvolvimento.
A seguir, apresentamos alguns exemplos de modelos empíricos orientados a FP para esforço (E):
E = -13 .39 + 0 .0545 x (PF) (modelo de Albrecht e Gaffney)
E = 60 .62 + 7 .728 x 10-8 x (PF)3 (modelo de Kemerer)
E = 587 .7 + 15 .12 x (PF) (modelo de Matson, Barnett e Mellichamp)
E agora, alguns exemplos de modelos empíricos orientados a LOC para esforço (E):
E = 5 .2 x (KLOC)0,91 (modelo de Walston-Felix)
E = 5 .5 + 0 .73 x (KLOC)1,16 (modelo de Bailey-Basili)
E = 3 .2 x (KLOC)1,05 (modelo de Boehm simples)
E = 5 .288 x (KLOC)1,047 (modelo de Doty para KLOC > 9)
É importante ressaltar que para os mesmos valores de FP ou LOC, os modelos vão gerar resultados 
diferentes (porque foram gerados, cada qual, em alguns domínios de aplicação específicos). Portanto, 
para utilizar esses modelos, eles devem ser adaptados para as necessidades locais.
Pág. 51 de 99
4.1.1 Exemplo de Aplicação do Modelo Empírico
Como exemplo de aplicação de modelo empírico, vamos utilizar o modelo de Walston-Felix 
para fazer estimativas. Esse modelo apresenta, além da expressão para estimativa de esforço vista 
anteriormente, as seguintes expressões empíricas de estimativa:
Duração do Projeto: D = 4 .1 x (KLOC) 0 .36 (meses)
Tamanho da Equipe: S = 0 .54 x (E)0 .6 (pessoas)
Páginas de Documentação: DOC = 49 x (KLOC) 1 .01(páginas)
Problema:
Suponha que a sua empresa foi contratada para desenvolver o software de CAD já mencionado. 
Considere que a empresa tem um alto grau de maturidade no desenvolvimento de software e que, 
devido a isso, tem procedimentos de coleta de dados, cálculo de métricas e armazenamento desses 
valores em uma base de dados, organizada considerando softwares do mesmo domínio de aplicação. 
Após uma análise preliminar na base de dados da empresa, obtiveram-se, para cada função a ser 
implementada no software, os valores de tamanho otimista, mais provável e pessimista, em LOC, 
relacionados na tabela 10.
Considerando isso e utilizando os dados