Apostila - Métricas de Desenvolvimento de Software

Prévia do material em texto

Métricas de Desenvolvimento de Software
1
Métricas de 
Desenvolvimento de 
Software
Professor Marcelo Freitas Pintaud
Métricas de Desenvolvimento de Software
2
Introdução 5
Capítulo 1 – Métricas de Software 5
Medidas, Métricas e Indicadores 5
Classificação das Métricas de Software 7
Tipos de Métricas de Software 8
Métricas de Dimensão de Software 9
Métricas de Halstead 11
Métricas de Complexidade de Software 11
Métricas de Qualidade de Software 12
Métricas de Orientação a Objetos 14
Medidas Aplicadas à Metodologia Ágil 16
Ferramentas para Extração de Métricas 17
Considerações Sobre Métricas 18
Estimativas de Software 18
Estimativas – conceitos fundamentais 18
Planejamento do Projeto: definição do escopo 19
Planejamento do Projeto: Estimativa de Recursos 19
Técnicas de Estimativas: Decomposição 20
Exemplos de Estimativas Baseadas em LOC 21
Exemplos de Estimativas Baseadas em Pontos Por Função 22
Modelos de Estimativas 24
Modelos de Estimativa Empíricos 24
Exemplo de Aplicação do Modelo Empírico 25
Modelo COCOMO - Conceitos Básicos 26
COCOMO 81 26
Estimativa de esforço de desenvolvimento 27
Estimativa do prazo de desenvolvimento 27
Exemplo de aplicação do COCOMO 27
COCOMO II 28
Modelo Application Composition 28
Modelo Early Design 28
Modelo Post-Achitecture 30
Estimativa Baseada em Processo 30
Exemplo de Estimativa Baseada em Processo 31
Conciliação de Modelos de Estimativas 32
Exemplo de conciliação de estimativas 32
Gerenciamento de Riscos 33
Conceitos básicos sobre riscos em projetos 33
Práticas para Gerenciamento de Riscos 34
SUMÁRIO
Métricas de Desenvolvimento de Software
3
Avaliação e Priorização de Riscos 35
Categorizações de Risco 36
Avaliação do Risco Global do Projeto 37
Matriz de Riscos 37
Exposição ao Risco (ER) 38
Exemplo de cálculo de ER 38
Exposição ao Risco Total (ERT) 39
Exemplo de cálculo de ER 39
RMMM–Risk Mitigation, Monitoring and Management 40
Cronogramação 40
Conceitos Básicos sobre Cronogramação 40
Cronogramação e Planejamento de Projetos 41
Cronogramação e Controle de Projetos 41
EVM - Earned Value Management 42
Exemplo de uma Análise do Valor Agregado 42
Parâmetros para Análise do Valor Agregado 43
Exemplo de uma Análise do Valor Agregado 44
Problema: 44
Diagrama de Gantt 46
Rede de Atividades: PERT/CPM/PDM 47
Considerações Finais 49
Referências 49
Glossário de Siglas 50
Métricas de Desenvolvimento de Software
4
Métricas de Desenvolvimento de Software
5
Introdução
Caro aluno, nesta disciplina 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 in-
dú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 governamen-
tais, no Brasil e no mundo, estão usando métricas para 
compreender, controlar, prever e melhorar projetos, pro-
cessos e produtos de software.
Dessa forma, caro aluno, caso você esteja envolvido com 
a área de desenvolvimento de software, é fundamental ter 
conhecimento sobre os conceitos relativos às métricas. 
Ao longo dessa disciplina, apresentaremos os conceitos 
básicos sobre métricas, depois veremos como elas se 
relacionam com o produto, processo e 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 funda-
mental em uma das áreas mais críticas do desenvolvimen-
to de software: a área de estimativas de custos, prazos e 
recursos. Vários modelos de estimativas serão apresenta-
dos, dando-lhe condições de constatar a importância de 
se ter um programa bem estabelecido de coleta de medi-
das, cálculo de métricas e armazenamento dessas infor-
mações em uma base de dados robusta. A qualidade des-
sa 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, que é a gestão de riscos. Todo projeto está ex-
posto a riscos e é de suma importância que você adote 
uma estratégia pró-ativa em relação a eles. Isso implica 
em conseguir prever a quais riscos o projeto está vulne-
rável, qual a probabilidade desses riscos se tornarem rea-
lidade e qual o impacto deles no projeto, caso realmente 
venham a ocorrer. Por fim, finalizaremos a disciplina dis-
cutindo cronogramação. Aqui também as medidas de-
sempenham 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.
Então é isso, caro aluno. Uma vez que você tenha con-
cluído o estudo desses vários tópicos, você estará prepa-
rado para entender melhor a importância da utilização 
das métricas no seu trabalho profissional como Engenhei-
ro e Arquiteto de Software. 
Marcelo Pintaud 
Capítulo 1 – Métricas de Software
Medidas, Métricas e Indicadores
Métricas de software estão se tornando cada vez mais 
uma parte importante na prática da Engenharia de Softwa-
re. A cada dia, um número maior de empresas e governos, 
estão adotando e reportando métricas de qualidade como 
parte dos requisitos contratuais de desenvolvimento. 
Fonte: http://blog.andrefaria.com/wp-content/uploads/2012/03/metric.
png
Métricas de Desenvolvimento de Software
6
Padrões, modelos e normas como ISO - International Organization for Standardization, CMMI - Capability Maturi-
ty Model Integration, dentre outros, consideram as métricas dentre as suas práticas recomendadas. Empresas estão 
usando métricas para melhor compreender, mapear, controlar e predizer projetos, processos e produtos de software.
Conforme Pressman (2010), medição é comum no campo da Engenharia. Consumo de energia, peso, dimensões 
físicas, temperatura, voltagem e várias outras medidas são utilizadas rotineiramente pelas várias áreas da Engenharia.
Importante!
No campo da 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 relacio-
nadas 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.
Pressman (2010), no contexto da engenharia de software, define medida como um valor que “fornece uma indi-
cação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou 
processo”. 
Na definição mais geral, medição é o ato de determinar uma medida.
O IEEE Standard Glossary define métrica como uma “medida quantitativa do grau em que um sistema, componente 
ou processo possui um determinadoatributo”.
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. Um 
indicador “é uma métrica ou combinação de métricas que fornece profundidade na visão do processo, projeto ou pro-
duto 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 melhores e gerenciáveis.
 
Métricas de Desenvolvimento de Software
7
A figura 1 ilustra esses conceitos.
Figura 1: Visão Geral sobre Medida, Métrica e Indicadores
Fonte: baseado em [PRESSMAN, 2010]
Uma grande variedade de métricas já foram propostas, mas nem todas mostram resultados satisfatórios. 
Isso ocorre por vários fatores: algumas exigem, por exemplo, 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. Dentre eles podemos citar:
• 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 às noções intuitivas do engenheiro de 
software sobre o atributo do produto que está sendo considerado.
• 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.
• 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, produtivi-
dade, dentre outros aspectos mensuráveis da análise, desenho, codificação e testes de software.
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, dentre outras medições. 
Métricas de Desenvolvimento de Software
8
Apresentamos algumas classificações de métricas no 
que se segue.
Classificação quanto ao objeto: 
• métricas de produto: são relacionadas à complexi-
dade, tamanho, qualidade (confiabilidade, manu-
tenibilidade, etc) do software produzido.
• métricas de processo: referem-se ao processo de 
concepção e desenvolvimento do software, me-
dindo por exemplo, o processo de desenvolvimen-
to, tipo de metodologia usada e tempo de desen-
volvimento.
Classificação quanto ao critério utilizado na sua de-
terminaçã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, independente 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 de-
pende da classificação do tipo de software).
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 públicas 
e métricas privadas. 
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.
Tipos de Métricas de Software
Há um grande número de métricas de software, que 
normalmente são aplicadas de forma isolada e considera-
das 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 experi-
mental. Várias delas foram definidas e, em seguida, testa-
das 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 você 
pode utilizar, mas você deve notar que apenas algumas 
têm sido amplamente utilizadas ou aceitas. 
Apesar de tudo, se você construir uma aplicação apoia-
da por algumas das métricas e modelos disponíveis, esco-
lhidas de forma cuidadosa, elas poderão produzir resulta-
dos úteis se forem utilizadas de acordo com o ambiente 
especificado.
Métricas de Desenvolvimento de Software
9
Nos próximos tópicos apresentaremos alguns tipos de 
métricas.
Métricas de Dimensão de Software
Linhas de Código (LOC- Lines of Code)
Podemos dizer que, pelo menos até hoje, essa é a me-
dida mais utilizada para medir o tamanho de um progra-
ma. É de fácil definição e precisão, apesar de que algumas 
dúvidas podem surgir na contagem do que se considera 
linhas de código. 
Por exemplo, podem surgir dúvidas quanto a conside-
rar ou não linhas em branco, comentários, trechos não-
-executáveis, múltiplas declarações por linha e várias li-
nhas por declaração, assim como a questão das linhas de 
código repetidas ou reusadas. 
O mais usual é contar qualquer linha que não seja linha 
em branco ou comentário, independentemente do núme-
ro de declarações por linha.
Métricas calculadas por esse método poderão somente 
ser comparadas se referirem à mesma linguagem de progra-
mação e se o estilo de programação estiver normalizado. 
Porém, caro aluno, vale lembrá-lo que a qualidade do 
código fonte não pode ser medida pela quantidade de li-
nhas de código e sim pela organização de tais linhas visan-
do à manutenção e reuso. 
Pontos por Função (PF ou FP- Function Points)
É uma medida baseada nos modelos e ciclos de vida 
tradicionais de desenvolvimento de software, proposta 
para medir o tamanho estimado do software no início 
do desenvolvimento. Nomodelo proposto para o cálculo 
de Pontos por Função, você tem que seguir três passos, 
conforme descritos a seguir.
[1] No primeiro passo, terá que preencher a Tabela T1, 
apresentada a seguir. Note que nessa tabela há parâmetros 
ligados às funcionalidades do software a ser desenvolvido, 
bem como fatores de ponderação relacionados a cada um 
desses parâmetros. 
Tanto os parâmetros como os fatores de ponderação 
constantes na tabela T1 são propostos pelo modelo e, a 
princípio, são fixos.
Então, nesse passo, você terá que estimar a quantida-
de de cada parâmetro previsto para o software a ser de-
senvolvido e atribuir um fator de ponderação 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 mini-
mizar essa subjetividade. 
Uma vez preenchida a Tabela T1, você terá o valor de 
Contagem Total, o qual será utilizado no terceiro passo do 
cálculo.
Tabela T1: Tabela para Pontos por Função
[2] No segundo passo de cálculo dos pontos por fun-
ção, você terá que avaliar 14 questões (Quadro Q2) tam-
bém relacionadas a funcionalidades do software a ser de-
senvolvidos. 
Para cada uma dessas perguntas, você terá que atri-
buir um valor de influência, obedecendo uma escala pro-
posta pelo modelo (Quadro Q1). 
Quadro Q1: Escala de Influência
Métricas de Desenvolvimento de Software
10
Quadro Q2: 14 perguntas relacionadas às funcionalidades
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] No terceiro passo, faz-se uso de uma expressão empírica proposta pelo modelo para obtenção dos pontos por 
função:
No capítulo 2 voltaremos a falar sobre esse tipo de métrica e veremos sua aplicação em algumas técnicas de 
estimativas de custo e prazo de desenvolvimento.
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 tem que seguir para obter essa medida 
de funcionalidade do software.
Métricas de Desenvolvimento de Software
11
Importante !
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 re-
presentação brasileira oficial, BFPUG - Brazilian Func-
tion Point Users Group (http://www.bfpug.com.br/).
 
System Bag
É uma medida de dimensão total de um software, de-
terminada a partir das funcionalidades descritas em espe-
cificações formais. 
O algoritmo de cálculo se difere por se aplicar a siste-
mas orientados por dados ou orientados por processos. 
Um dos objetivos dessa métrica é maximizar o quociente 
Bag/Custo total no desenvolvimento do projeto.
Métricas de Halstead
É um conjunto de métricas baseadas na teoria da 
informação. Essas métricas se aplicam a vários aspectos do 
software, diferentemente da maior parte das métricas, que 
tratam um aspecto particular, e também são usadas para 
avaliar o esforço global de desenvolvimento do software. 
O Vocabulário (n), Comprimento (N) e Volume (V) são 
métricas que são aplicadas especificamente ao software 
final. Também são especificadas fórmulas para calcular 
o esforço total (E) e tempo de desenvolvimento (T) de 
software.
Vocabulário do Programa
O software é visualizado como uma sequência de sím-
bolos (tokens), sendo cada símbolo classificado em opera-
dores ou operandos. Dessa forma, o vocabulário do pro-
grama (n) é definido como:
onde 
n1 é o número de operadores únicos e 
n2 é o número de operandos únicos do programa.
Comprimento do Programa
 
Enquanto o vocabulário é a soma dos símbolos (tokens) 
diferentes, o comprimento do programa (N) é a soma do 
total de operadores e operandos, sendo dado como:
onde 
N1 é o número total de operadores e 
N2 é o número total de operandos do programa. 
Acredita-se que a métrica de comprimento é mais 
objetiva e eficiente que o LOC.
Volume do Programa
O volume de um programa, medido em bits, é dado em 
função do seu comprimento (N) e do seu vocabulário (n):
Métricas de Complexidade de Software
Assim como as métricas de dimensão de software, as 
métricas de complexidade foram criadas de acordo com 
os modelos tradicionais de desenvolvimento e podem 
ser computadas no início do ciclo de desenvolvimento de 
software, para o maior sucesso na gerência do processo 
de software. São medidas deste tipo de métrica:
• Complexidade Ciclomática - v(G)
A Complexidade Ciclomática parte do princípio que a 
complexidade depende do número de condições (caminhos 
lógicos), correspondendo ao número máximo de percur-
sos linearmente independentes em um software. A ideia 
é que, medindo a complexidade do programa, você sai-
ba quantos caminhos lógicos deve testar. Isso auxilia no 
desenvolvimento e nos testes do software. Essa métrica 
pode ser representada através de um grafo de fluxo de 
controle, onde os nós representam uma ou mais instru-
Métricas de Desenvolvimento de Software
12
ções sequenciais e os arcos orientados indicam o sentido 
do fluxo de controle entre várias instruções. 
A complexidade ciclomática de um determinado grafo 
pode ser calculada através de uma fórmula da teoria dos 
grafos:
onde 
e é o número de arestas 
n é o número de nós do grafo.
A complexidade ciclomática pode ter várias interpre-
tações. Por exemplo, foi verificado que a produtividade 
diminui de forma não linear proporcionalmente ao au-
mento da densidade dos pontos condicionais. Também foi 
relacionada com os esforços de depuração e manutenção, 
podendo ser utilizada para estimar custos a partir do pro-
jeto detalhado dos módulos.
O interesse na métrica de complexidade ciclomática 
levou à sua normalização. Posteriormente, foram defi-
nidas outras cinco métricas: complexidade da unidade 
real, complexidade essencial, complexidade do projeto 
de módulos, complexidade total do projeto e complexi-
dade de integração. Essas métricas foram utilizadas para 
identificar e minimizar a complexidade em códigos não 
estruturados, decidindo sobre o número de testes neces-
sários para uma cobertura total das possíveis execuções, 
eliminando a redundância e restringindo a complexidade 
de módulos produzidos a um nível aceitável.
• Número de Nós
Corresponde ao número de nós em um grafo de fluxo 
de controle que representa a sequência de controle de 
execução de instruções num programa. Um nó é definido 
como uma passagem necessária das linhas direcionais 
(arestas) no grafo, sendo assim uma proposta de métrica 
de complexidade de software.
• Fluxo de Informação
Fluxos de informações na estrutura de um programa 
são considerados medidas de complexidade de software, 
sendo comparados com a complexidade ciclomática e 
métricas de Halstead. Esse método conta o número de 
parâmetros de entradas (fan-in) e saídas (fan-out), sendo 
definido como:
Uma experiência de validação dessa métrica foi reali-
zada na concepção e desenvolvimento de um núcleo para 
o sistema operacional UNIX. Além disso, fluxo de informa-
ção também permite estimar, com uma certa precisão, o 
esforço de manutenção.Métricas de Qualidade de Software
Qualidade é uma característica que, nos modelos 
tradicionais de desenvolvimento de software, pode ser 
medida em cada fase do ciclo de desenvolvimento de 
software. Métricas para a qualidade na fase de projeto, 
por exemplo, foram propostas há décadas.
Os primeiros estudos sobre métricas mostram mais re-
latos e experiências com métricas de dimensão e comple-
xidade; posteriormente algumas áreas que tratam as ca-
racterísticas de qualidade de software foram investigadas.
Corretude, eficiência, portabilidade, confiabilidade, 
usabilidade, modularidade, grau de reutilização e facilida-
de de manutenção (manutenibilidade) são características 
ligadas à qualidade de software. 
• Métricas de Funcionalidade
Funcionalidade pode ser definida como a capacidade 
de um software ser usado com eficiência e satisfação para 
atingir objetivos específicos em um determinado ambien-
te. Podem-se destacar as seguintes características sobre a 
funcionalidade do software:
Métricas de Desenvolvimento de Software
13
• Facilidade de aprendizagem: capacidade de um usu-
ário atingir rapidamente um grau de proficiência ele-
vada;
• Usabilidade: capacidade do software interagir ami-
gavelmente com os usuários;
• Controle: capacidade de um produto em responder 
de uma forma natural e consistente aos comandos e 
entradas de dados fornecidos;
• Utilidade: capacidade de resolver ou ajudar a resol-
ver problemas para os quais o software foi proposto;
• Eficiência: capacidade de resolver problemas de for-
ma rápida e econômica.
Uma questão que é bastante discutida em relação a 
esse tipo de métrica é a subjetividade que pode haver em 
seus cálculos. Esforços tem sido realizados no sentido de 
minimizar essa questão.
• Métricas de Manutenção Corretiva
Algumas métricas foram propostas para medir ou pre-
ver a manutenibilidade do software, já que erros encon-
trados no sistema e a sua eliminação rápida são caracterís-
ticas importantes na avaliação da qualidade do software.
As métricas de Halstead e de complexidade ciclomáti-
ca podem ser utilizadas para prever a complexidade das 
tarefas de manutenção de software. Elas podem ser utili-
zadas de forma eficaz para explicar ou prever a manuten-
ção de software em sistemas distribuídos. Podemos citar, 
por exemplo, as seguintes métricas de complexidade para 
medir as atividades de manutenção em um sistema: 
• Número de erros detectados por aplicação de uma 
bateria de testes;
• Número de erros detectados pelos usuários;
• Tempo médio de resposta na resolução de proble-
mas detectados;
• Número de mudanças de projeto;
• Número de alterações no código fonte.
• Métricas de Confiabilidade
• Métricas de Confiabilidade
São métricas para estimar e dimensionar o esforço de 
depuração, como, por exemplo, a quantidade de testes a 
aplicar, partindo das métricas de manutenção corretiva. 
Métricas típicas dessa categoria são:
• MTTF - Mean Time To Fail (Tempo Médio até a 
Falha): a probabilidade de uma falha ocorrer num 
intervalo de tempo especificado;
• MTBF - Medium Time Between Failures (Tempo 
Médio entre Falhas): o tempo médio entre falhas.
Existem modelos para descrever a ocorrência de erros 
em função do tempo, permitindo definir a confiabilidade 
e o MTTF. Partindo dos seguintes pressupostos:
• Entradas de testes são exemplos aleatórios de 
entradas no sistema;
• Todos os erros de software são observados;
• Intervalos de erros são independentes uns dos ou-
tros;
• MTBF é exponencialmente distribuído.
As seguintes equações são definidas:
onde:
D é o total de número de erros;
b e c são constantes determinadas pelo tipo de softwa-
re ou de um software similar;
d(t) é o número total de erros detectados no tempo
Determinar b, c e D, que não é uma tarefa óbvia, pode 
estabelecer o sucesso da aplicação desse modelo de mé-
trica de confiabilidade.
Existem estudos relacionando a confiabilidade com 
métricas de dimensão e complexidade, como as de Halstead 
e de complexidade ciclomática. Os trabalhos clássicos 
nessa área relacionam as métricas de complexidade com 
a manutenção, medindo a complexidade em cada módulo 
e suas inter-relações. A correlação entre a complexidade 
Métricas de Desenvolvimento de Software
14
e a manutenção pode ser assim explorada no sentido de 
conseguir a redução dos custos de manutenção.
Métricas de Orientação a Objetos
Existem métricas voltadas especificamente aos aspec-
tos relevantes no contexto da programação orientada a 
objetos: métricas de classe, métricas de métodos, métri-
cas de herança, métricas de acoplamento e métricas do 
sistema (características gerais do software orientado a 
objetos), conforme apresentado a seguir.
Métricas de Classes
• Código Orientado a Função (FOC - Function Orien-
ted Code): mede o percentual de código não orien-
tado a objeto usado no programa.
• Coesão de Classe (CCO - Class Cohesion): mede a 
relação entre as classes.
• Dados Públicos (PDA - Public Data): contabiliza o 
número de acessos aos dados protegidos e públi-
cos de uma classe.
• Encapsulamento dos Atributos (AHF - Attribute 
Hiding Factor): razão entre a soma de todos os 
atributos herdados de todas as classes do sistema 
em consideração ao número total de atributos das 
classes disponíveis.
• Encapsulamento dos Métodos (MHF - Method Hi-
ding Factor): razão entre a soma de todos os mé-
todos invisíveis em todas as classes em relação ao 
número total de métodos definidos em um deter-
minado sistema.
• Entropia de Complexidade da Classe (CEC - Class 
Entropy Complexity): mede a complexidade da 
classe, baseada no conteúdo de suas informações.
• Falta de Coesão entre Métodos (LCM - Lack of Co-
hesion between Methods): indica o nível de coesão 
entre os métodos.
• Linhas de comentário por Método (CLM - Com-
ment Lines per Method): mede o percentual de 
comentários no método.
• Medida de Abstração das Funções (MFA - Mea-
sure of Functional Abstraction): razão entre o nú-
mero de métodos herdados por uma classe em 
relação ao número total de métodos acessíveis na 
classe.
• Medida de Abstração dos Atributos (MAA - Mea-
sure of Attribute Abstraction): razão do número de 
atributos herdados por uma classe em relação ao 
número total de atributos nas classes.
• Métodos ponderados por Classe (WMC - Wei-
ghted Methods per Class): soma ponderada de to-
dos os métodos da classe.
• Métodos Reusados (PMR - Percent of Potential 
Method uses actually Reused): percentual de reu-
so dos métodos da classe.
• Métrica de Acesso aos Dados (DAM - Data Access 
Metric): razão do número de atributos privados 
em relação ao número total de atributos declara-
dos na classes.
• Número de Ancestrais (NOA - Number Of Ances-
tors): número total de ancestrais de uma classe.
• Número de Atributos Públicos (NPA - Number of 
Public Attributes): contabiliza o número de atribu-
tos declarados como públicos em uma classe.
• Número de Métodos de Classe em uma Classe 
(NCM - Number of Class Methods): mede os méto-
dos disponíveis em uma classe, mas não em suas 
instâncias.
• Número de Parâmetros por Métodos (NPM - 
Number of Parameters per Method): número mé-
dio de parâmetros por método.
• Número de Referências como Atributo (NRA - 
Number of Reference Attributes): contabiliza o nú-
mero de ponteiros e referências passadas como 
atributos de uma classe.
• Número de Tipos de Dados Abstratos (NAD - Num-
ber of Abstract Data types): número de objetos de-
finidos pelo usuário como atributos de uma classe 
que são necessários para instanciar um objeto da 
referida classe.
• Número de Variáveis de Instância em uma Classe 
(NIV - Number of Instance Variables): mede a rela-
ção de uma classe com outro objetodo programa.
• Percentual de Dados Públicos (PPD - Percentage 
of Public Data): é o percentual de dados públicos 
de uma classe.
Métricas de Desenvolvimento de Software
15
• Ponderação do Tamanho da Classe (WCS - Wei-
ghted Class Size): número de ancestrais mais o ta-
manho total de métodos da classe.
• Porcentagem de Métodos Comentados (PCM - 
Percentage of Commented Methods): percentual 
de métodos com comentários em uma classe.
• Privacidade Interna (INP - Internal Privacy): refere-
se ao uso de funções de acesso à classe, incluindo 
as chamadas da própria classe.
• Respostas para uma Classe (RFC - Response For 
a Class): número de métodos dentre todos os 
métodos que podem ser invocados em resposta 
a uma mensagem enviada por um objeto de uma 
classe.
Métricas de Métodos
• Complexidade do Método (MCX - Method Com-
plexity): relaciona a complexidade com o número 
de mensagens.
• MAG (MAX V(G)): complexidade ciclomática 
máxima dos métodos de uma classe.
• Média de Complexidade dos Métodos (AMC - 
Average Method Complexity): soma da comple-
xidade ciclomática de todos os métodos dividido 
pelo número total de métodos.
• Média do Tamanho dos Métodos (AMS - Average 
Method Size): mede o tamanho médio dos méto-
dos do programa.
Métricas de Acoplamento
• Acoplamento Aferente (AC - Afferent Coupling): 
número total de classes externas de um pacote 
que dependem de classes de dentro desse pacote. 
Quando calculada no nível da classe, essa medida 
também é conhecida como Fan-in da classe, 
medindo o número de classes das quais a classe 
é derivada e, assim, valores elevados indicam uso 
excessivo de herança múltipla.
• Acoplamento Eferente (EC- Efferent Coupling): 
número total de classes dentro de um pacote 
que dependem de classes externas ao pacote. 
Quando calculada no nível da classe, essa medida 
também é conhecida como fan-out da classe, ou 
como Acoplamento entre Objetos (CBO - Coupling 
Between Objects) na família de métricas de CK 
(Chidamber-Kemerer).
• Acoplamento de Classe (CP - Class Coupling): 
mede as relações entre as classes com base em 
suas trocas de mensagens.
• Fator de Acoplamento (CFA - Coupling Factor): 
razão entre o número máximo possível de 
acoplamentos no sistema e o número atual de 
acoplamentos possíveis por herança.
Métricas de Herança
• Construção Efetiva (FEF - Factoring Effectiveness): 
número de métodos únicos dividido pelo número 
total de métodos.
• Potencial de Métodos Sobrescritos (PMO - Percent 
of Potential Method uses Overridden): percentual 
de métodos sobrescritos utilizados.
• Nível de Aninhamento Hierárquico da Classe 
(HNL - Class Hierarchy Nesting Level): mede a 
profundidade de hierarquia em que cada classe 
está localizada.
• Métricas de Reuso de Método (MRE - Method Reu-
se Metrics): indica o nível de reuso dos métodos.
• Número de Métodos Herdados (NMI - Number of 
Methods Inherited): mede o número de métodos 
que uma classe herda.
• Medida de Polimorfismo (PFA - Polymorphism 
Factor ): razão entre o número atual de possibili-
dades de polimorfismo diferentes de uma classe 
e o número máximo de possíveis polimorfismos 
distintos da referida classe.
• Número de Métodos Sobrescritos (NMO - Num-
ber of Methods Overridden): número de métodos 
redeclarados pela classe herdeira.
• Tipo de Especialização (SIX - Specialisation Index): 
indica o tipo de especialização.
• Medida de Herança de Atributos (AIF - Attribute 
Inheritance Factor): razão entre a soma dos atri-
butos herdados em todas as classes do sistema e 
o número total de atributos disponíveis na classe.
Métricas de Desenvolvimento de Software
16
• Profundidade da Árvore de Herança (DIT - Depth 
of Inheritance Tree): mede o número de ancestrais 
de uma classe.
• Número de Filhos (NOC - Number Of Children): 
número total de filhos de uma classe.
• Proporção de Reuso (RER - Reuse Ratio): razão 
entre o número de superclasses dividido pelo 
número total de classes.
• Proporção de Especialização (SPR - Specialisation 
Ratio): razão entre o número de subclasses dividi-
do pelo número de superclasses.
• Medida de Herança de Método (MIF - Method 
Inheritance Factor): razão entre a soma dos 
métodos herdados em todas as classes e o número 
total de métodos disponíveis em todas as classes.
• Proporção entre Profundidade e Largura (RDB - 
Ratio between Depth and Breadth): razão entre a 
profundidade e a largura da hierarquia de classes.
Métricas do Sistema
• Granularidade da Aplicação (APG - Application 
Granularity): número total de objetos dividido 
pelo número total de pontos de função.
• Eficiência da Biblioteca de Objeto (OLE - Object 
Library Effectiveness): razão entre o número total 
de objetos reusados e o número total de objetos 
da biblioteca.
• Complexidade Associada (ASC - Association Com-
plexity): mede a complexidade da estrutura asso-
ciada ao sistema.
• Número de Hierarquias (NOH - Number Of Hierar-
chies): número de hierarquias distintas do sistema.
• Reuso de Classe (CRE - Number of time a Class 
is Reused): mede as referências a uma classe e o 
número de aplicações que reusam tal classe.
• Número de Rejeição de Classe (NCT - Number of 
Classes Thrown away): mede o número de vezes 
que uma classe é rejeitada até que seja aceita.
• Problemas Relatados por Classe (PRC - Problem 
Reports per Class): mede os relatos de erros da 
classe.
• Reuso do Sistema (SRE - System Reuse): percentu-
al de reuso de classes.
• Categorização (CAN - Category Naming): divide as 
classes em um conjunto semanticamente significa-
tivo.
• Profundidade Média de Herança (ADI - Average 
Depth of Inheritance): divisão entre a soma de ní-
veis de aninhamento de todas as classes pelo nú-
mero de classes.
• Média de Ancestrais (ANA - Average Number of 
Ancestors): determina o número médio de ances-
trais de todas as classes.
• Densidade Funcional (FDE - Functional Density): 
razão entre o número de linhas de código e pontos 
de função.
• Modificação de Objetos Reusados (PRO - Percent 
of Reused Objects Modfied): percentual de objetos 
reusados que foram modificados.
Medidas Aplicadas à Metodologia Ágil
Caro aluno, a seguir estão listadas e definidas algumas 
medidas para auxiliar uma equipe na escolha das melhores 
métricas que possam ser utilizadas nas metodologias ágeis. 
Entre as métricas apresentadas estão exemplos daque-
las que podem ser coletadas de forma automatizada, por 
serem compostas de medidas quantitativas e objetivas. 
Dessas, algumas já foram apresentadas anteriormente, 
como: Linhas de Código, Complexidade Ciclomática, 
Métodos Ponderados por Classe, Falta de Coesão dos 
Métodos, Profundidade da Árvore de Herança, Número 
de Filhos, Acoplamento Aferente, Acoplamento Eferente. 
Além das métricas já apresentadas, podemos citar:
• Total de Linhas de Código de Teste (TLCT): repre-
senta o número total de pontos de teste do siste-
ma. Um ponto de teste é considerado como um 
Métricas de Desenvolvimento de Software
17
passo do cenário de um teste de aceitação, auto-
matizado ou como uma linha de código de teste 
de unidade automatizado, descartando linhas em 
branco e comentários.
• Número de Linhas Alteradas: representa o número 
de linhas (não apenas código-fonte) adicionadas, 
removidas e atualizadas no Repositório de Código 
Unificado.
• Número de Commits: representa o número de 
commits efetuados no Repositório de Código Uni-
ficado.
• Estimativas Originais: representa o total de pon-
tos (ou horas) originalmente estimados pela equi-
pe para todas as estórias da iteração.
• Estimativas Finais: representa o total de pontos 
(ou horas) efetivamente reportadas como gastas 
para implementar as estóriasda iteração.
• Número de Estórias Entregues: representa o nú-
mero total de estórias implementadas pela equipe 
e aceitas pelo cliente.
• Número de Pontos Entregues: representa o nú-
mero total de pontos implementados pela equipe 
e aceitos pelo cliente.
• Tempo: utilizado no cálculo de diversas métricas, 
pode ser utilizado como duração (em meses, se-
manas, dias, etc.) ou como número de iterações.
• Tamanho da Equipe: geralmente utilizado no cál-
culo de métricas, representa a quantidade de pes-
soas na equipe.
• Esforço: uma medida que leva em conta o tamanho 
da equipe durante um certo intervalo de tempo, 
geralmente medido em pessoas-mês ou pessoas-
ano.
Ferramentas para Extração de Métricas 
A aplicação manual das métricas é bastante trabalhosa, 
envolvendo uma série de cálculos e anotações, o que 
dificulta e torna essa atividade de medição propensa a 
erros. 
Sob esse prisma, torna-se bastante interessante a 
utilização de ferramentas que automatizem e/ou orientem 
tal processo de medição.
 http://paquimetro.reguaonline.com/
As ferramentas que trabalham com aplicação de mé-
tricas se dividem basicamente nos seguintes grupos:
• Ferramentas de especificação e organização de 
requisitos
• Ferramentas de modelagem
• Ferramentas de estimativa de custo e esforço
• Ferramentas para coleta de métricas específicas
Alguns exemplos de ferramentas para esses propósitos 
são: Rational Requisite Pro, Borland® CaliberRM, Borland® 
Together, IBM Rational Rose®, Costar, Cost Xpert, Estimate 
Easy Use Case, Enterprise Architect.
Assista a um vídeo sobre um caso prático de uso de 
métricas ligadas às Mídias Sociais.
http://youtu.be/9O8D3zY59w4 3’29”
Considerações Sobre Métricas
Métricas de Desenvolvimento de Software
18
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.
Vimos diferentes métricas até o momento, porém mui-
tos fatores devem ser levados em consideração para a es-
colha 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 significati-
va e mais efetiva.
Estimativas de Software
Estimativas – conceitos fundamentais
Caro aluno, quando estamos envolvidos em 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 pontos, estudados em 
gerenciamento de projetos, são: escopo, custo, recursos 
e cronograma. Observe que para lidar com estes pontos 
precisamos conhecer as estimativas de software.
A estimativa é imprescindível para apurar custos, 
alocar recursos e estabelecer cronogramas de trabalho. 
Portanto, torna-se necessário grande dedicação a este 
assunto.
Antes de um projeto iniciar é necessário estimar: 
• o trabalho a ser feito 
• o custo do projeto
• os recursos necessários 
• o tempo de início e fim do projeto
A seguir, é necessário estabelecer um cronograma de 
projeto que:
• defina as tarefas e marcos da engenharia de sof-
tware 
• identifique os responsáveis por cada tarefa 
• especifique as dependências intertarefas que pre-
cisam ter um forte acompanhamento do progresso 
Fonte: http://hostintermex.com/img/slider/female-pushing.jpg 
A estimativa de software é vista tanto como arte quan-
to como ciência e o desenvolvedor conta com várias técni-
cas ú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 quantita-
tivas. Mas é importante ressaltar, caro aluno, que a expe-
riência do pessoal envolvido pode ajudar imensamente à 
medida que as estimativas são desenvolvidas e revistas.
O planejamento de projeto fornece um guia para a en-
genharia de software bem sucedida. A estimativa é impor-
tante 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 sof-
tware, como os modelos evolucionários e modelos ágeis, 
assumem uma visão iterativa do desenvolvimento de 
software. Em tais abordagens, é possível revisitar a esti-
mativa à medida que mais informações são conhecidas 
permitindo, assim, revisá-la quando o cliente solicita mo-
dificações nos requisitos.
A estimativa de recursos, de custo e de cronograma, 
exige experiência, acesso às informações históricas con-
sistentes e empenho nas previsões quantitativas, quando 
Métricas de Desenvolvimento de Software
19
informação qualitativa, em alguns casos, é tudo o que 
pode se ter 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 al-
tos. Discutiremos riscos no próximo capítulo.
Planejamento do Projeto: definição do 
escopo
 
Pressman (2010), faz uma interessante pergunta sobre 
estimativas: “Você construiria uma casa sem saber quanto 
iria gastar?”. E faço a mesma pergunta a você, caro alu-
no. Certamente sua resposta seria: não. Como a maioria 
dos sistemas e produtos de software pode custar consi-
deravelmente mais do que construir uma casa, é muito 
razoável fazer uma estimativa antes de se começar a criar 
software.
 
Pois bem, caro aluno, podemos dizer que o objetivo 
do planejamento de projeto é fornecer uma estrutura que 
permita ao gerente fazer estimativas razoáveis de recur-
sos, custo e cronograma (prazos).
A primeira atividade de planejamento do projeto de 
software é a determinação do escopo. O escopo do sof-
tware descreve os dados e o controle a serem processa-
dos, as funções e desempenho esperados, as restrições, a 
interface e a confiabilidade desejadas.
Normalmente no início de um projeto há uma incer-
teza em relação a estes itens. Uma necessidade foi defi-
nida e metas e objetivos básicos foram enunciados, mas 
a informação necessária para definir o escopo, que é pré-
-requisito para a estimativa, ainda não foi delineada.
Para isso, é necessária uma intensa comunicação entre 
desenvolvedores e clientes. A técnica mais utilizada para 
isso é conduzir uma reunião preliminar ou uma entrevis-
ta. 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 
conjunta 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.
Uma vez entendido o escopo, é importante determinar 
a viabilidade do projeto dentro das dimensões delimitadas 
(tecnológica, financeira, de tempo e de recursos). Isso é 
importante para evitar dedicar esforço e dinheiro em um 
projeto que pode estar condenado ao fracasso desde o 
início.
Planejamento do Projeto: Estimativa de 
Recursos
Uma tarefa importante no planejamento é a estimativa 
de recursos necessários para o desenvolvimento do 
software. A figura 2, proposta por Pressman (2006), ilustra 
os recursos com que devemos nos preocupar.
 
Figura 2: Recursos para o planejamento de estimativas
Fonte: baseado em PRESSMAN [2006]Notamos que o ambiente de desenvolvimento, que in-
clui ferramentas de hardware e de software, fica na base 
da pirâmide. Esse ambiente fornece a infraestrutura para 
apoiar o esforço de desenvolvimento. Na camada inter-
mediária da pirâmide encontramos os componentes de 
software reusáveis, que podem reduzir consideravelmen-
te os custos e o prazo de desenvolvimento. No topo da 
pirâmide está o recurso humano.
Métricas de Desenvolvimento de Software
20
Para cada um dos recursos indicados na pirâmide é 
necessário especificar a sua descrição, uma declaração de 
disponibilidade, a época em que o recurso será necessário 
e o prazo durante o qual ele será utilizado. 
 
Caro aluno, como vimos na disciplina “Engenharia de 
Software e de Requisitos”, no início os maiores custos es-
tavam relacionados ao hardware e não ao software. Na-
queles primeiros tempos, erros na estimativa do custo 
de software tinham um impacto relativamente pequeno. 
Hoje, geralmente, o software é o componente mais caro de 
todos os sistemas baseados em computador. Para sistemas 
complexos, feitos sob encomenda, um erro de estimativa 
grande pode fazer a diferença entre lucro e prejuízo.
 
Infelizmente, a estimativa de custo e esforço para de-
senvolver software não é uma ciência exata. Isso normal-
mente decorre do fato de um grande número de variáveis 
– humanas, técnicas, ambientais e políticas – afetar o custo 
final do software e o esforço necessário para desenvolvê-lo.
 
De qualquer modo, existem opções para auxiliar a con-
seguir estimativas de custo e esforço que sejam confiá-
veis, que segundo Pressman (2010), são:
• Adie a estimativa até que o projeto esteja mais 
adiantado: quanto mais tarde você fizer a estimati-
va, maior a probabilidade de acertar. Infelizmente, 
apesar de atraente, essa opção não é prática. Nor-
malmente, o cliente deseja estimativas de custo e 
prazo o quanto antes.
• Baseie as estimativas em projetos semelhantes, 
que já foram completados. 
• Use técnicas de decomposição: essas técnicas utili-
zam uma abordagem do tipo “dividir para conquis-
tar”, que seria decompor o projeto em suas fun-
ções principais e atividades relacionadas.
• Use um ou mais modelos empíricos.
É importante ressaltar que essas opções dependem 
fundamentalmente dos dados históricos usados para ali-
mentar a estimativa. Se não existem dados históricos, as 
estimativas serão precárias.
Técnicas de Estimativas: Decomposição 
Na maioria das vezes, o problema de desenvolver uma 
estimativa de custo e esforço para um determinado proje-
to é muito complexo para ser considerado como um todo. 
Devido a isso, as técnicas de decomposição do proble-
ma em um conjunto de problemas menores se mostram 
atrativas, pois se espera que, com essa divisão, se torne 
mais fácil chegar à solução.
 
A precisão da estimativa de um projeto depende dos 
seguintes fatores:
1. o grau com que o planejador estimou adequada-
mente o tamanho do produto a ser construído
2. a aptidão para traduzir a estimativa de tamanho em 
esforço humano, tempo transcorrido e dinheiro
3. o grau com que o plano de projeto reflete a capa-
cidade da equipe de software
4. a estabilidade dos requisitos do produto e do ambien-
te que apoiam o esforço de engenharia de software
Como uma estimativa de projeto é tão boa quanto a 
estimativa do tamanho do trabalho a ser realizado, o di-
mensionamento 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, por exemplo)
• abordagem indireta (medido em PF, por exemplo)
Em relação às técnicas de estimativa baseadas em LOC 
e PF, 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 estimati-
vas precisas de LOC possam ser desenvolvidas)
Métricas de Desenvolvimento de Software
21
• Estimativa PF: ao invés de focalizar a função, é es-
timada cada uma das características do domínio 
de informação (entradas, saídas, arquivos de da-
dos, 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, ca-
sos de uso, modificações ou processos do negócio afetados.
Métricas referenciais de produtividade (por exemplo, 
LOC/PM ou PF/PM) são então aplicadas à variável de es-
timativa adequada e o custo ou esforço correspondente 
à função é derivado. A seguir, 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 calcu-
lada por domínio de projeto. Os projetos devem ser agru-
pados por tamanho de equipe, área de aplicação, comple-
xidade e outros parâmetros relevantes. A seguir, médias 
locais dos domínios devem ser calculadas.
No caso de estimativas de um novo projeto, ele deve 
ser primeiro classificado num domínio e depois a média 
da métrica do domínio adequado deve ser usada para ge-
rar a estimativa.
Independente da variável de estimativa que é usada 
(LOC, PF, número de classes, número de casos de uso, 
etc), o planejador começa estimando um intervalo de va-
lores para cada função (LOC, por exemplo) ou o valor do 
domínio de informação (PF, por exemplo).
Usando dados históricos e/ou intuição, são estimados 
um valor de tamanho otimista (Tot), um mais provável 
(Tmp) e um pessimista (Tpess) para cada função (LOC) ou 
contagem (PF - para 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 (PF).
Um exemplo de cálculo de um valor esperado para T 
pode ser a média ponderada:
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écni-
cas de estimativas.
Exemplos de Estimativas Baseadas em LOC 
Exemplo 1
Suponha um determinado software que será desen-
volvido. 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 1.
 
Em seguida, um intervalo de estimativa de LOC é de-
senvolvido para cada função. 
Esse intervalo considera as estimativas como otimista, 
mais provável e pessimista. 
Os valores das estimativas apresentados na tabela 1, 
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 = 3800 LOC; mais prová-
vel= 6500 LOC; pessimista= 8600 LOC.
 Estes valores, aplicados na equação para T, produzem 
um valor esperado de 6400 LOC.
Métricas de Desenvolvimento de Software
22
Tabela 1: Principais funções identificadas
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 organizacionalmédia para 
sistemas desse tipo é de 500 LOC/pessoas-mês e que o 
valor bruto da mão de obra é de R$ 4.000,00 por pessoa-
mês, o custo por linha de código é de aproximadamente:
 
Portanto, o custo total estimado para o projeto é de:
O esforço necessário estimado para desenvolver o pro-
jeto é de:
Exemplo 2 
A tabela 2 apresenta as estimativas de tamanho 
otimista, mais provável e pessimista para cada uma 
das funções a serem implementadas no software CAD 
mencionando no exemplo 1. Considerando que a 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, 
baseado 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 2: Estimativas de Tamanho Otimista, Mais Pro-
vável e Pessimista (em LOC)
A tabela 3 apresenta o cálculo do tamanho de cada 
uma das funções (em LOC) utilizando a expressão apre-
sentada anteriormente T = (Tot + 4.Tmp + Tpess) / 6. 
Tabela 3: Cálculo do tamanho de cada função
Utilizando a estimativa de tamanho obtida na tabela 3 
e os dados do valor bruto da mão de obra e produtividade 
fornecidos anteriormente, podemos calcular as estimati-
vas de esforço e custo total conforme indicado a seguir.
Exemplos de Estimativas Baseadas em 
Pontos Por Função
No caso de pontos por função (PF), conforme falamos 
anteriormente, a decomposição tem foco nos valores do 
Métricas de Desenvolvimento de Software
23
domínio de informação ao invés das funções do software. 
Neste método, a estimativa é registrada numa tabela, 
como a tabela 4, com os valores estimados do domínio de 
informação e com atribuição de valores aos 14 fatores de 
ajuste de complexidade (veja quadro 1).
Tabela 4: Tabela sugerida na análise por ponto de função
Fonte: baseado em PRESSMAN [2010]
Na tabela 5, temos relacionados os Fatores de Ponde-
ração para cada parâmetro utilizado no modelo de cálculo 
de pontos por função. 
Tabela 5: Fatores de Ponderação 
As questões apontadas no quadro 1 são os 14 fatores 
de ajustes propostos quando se utiliza Ponto por Função.
Quadro 1: Fatores de ajustes
Para cada fator de ajuste, um número é atribuído con-
forme sua influência no fator em análise, de acordo com a 
escala mostrada no quadro 2.
Quadro 2: Escala de Influência
Utilizando a expressão empírica proposta pelo mode-
lo, conforme citado no capítulo 1, pode-se determinar a 
quantidade estimada 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 para o esforço necessário para concluí-lo.
Exemplo 3
Suponha que a sua empresa foi contratada para desen-
volver determinado software. Considere que a empresa 
tem um alto grau de maturidade no desenvolvimento de 
software. 
Devido a isso, tem procedimentos de coleta de da-
dos, cálculo de métricas e armazenamento desses valores 
numa base de dados, organizada considerando softwares 
do mesmo domínio de aplicação. 
 Após uma análise preliminar na base de dados da em-
presa, e considerando software do mesmo domínio de 
aplicação do software a ser desenvolvido, obtiveram-se 
os valores relacionados na tabela 6. 
Utilizando os dados do exemplo 2 proposto e consi-
derando que o fator de ponderação (peso) seja simples 
para todos os parâmetros da tabela 6 e que os valores de 
ajuste de complexidade para os 14 fatores de ajustes se-
jam considerados de influência moderada, estime o custo 
e o esforço necessários para construir o software usando 
a técnica de estimativa baseada em PF. 
Métricas de Desenvolvimento de Software
24
Considere que a produtividade média para sistemas 
desse domínio seja de 5 PF/pm.
Tabela 6: Valores obtidos na base de dados da empresa
Na tabela 7, os valores de Contagem apresentados na 
5ª coluna, foram obtidos através da expressão T = (Toti-
mista + 4*Tmais provável + Tpessimista) / 6.
Uma vez obtidos esses valores de Contagem, foram 
considerados os valores de ponderação simples (Peso), 
conforme tabela 5. Esses valores estão relacionados na 6ª 
coluna da tabela 7. 
De posse dos valores de Contagem e Peso, obtemos a 
7ª coluna da Tabela 7, que nada mais é do que a multipli-
cação da Contagem pelo Peso.
A soma dos valores dessa 7ª coluna resultará no valor 
da Contagem Total, que, no caso, foi de 346.
Tabela 7: Obtenção da Contagem Total
Como no enunciado do exemplo foi dito para considerar 
os valores de ajuste de complexidade para os 14 fatores 
de ajustes como de influência moderada (=2, conforme 
Quadro 2), isso resultará numa valor de 14 * 2 = 28.
Substituindo os valores de Contagem Total ( = 346) 
e soma dos 14 fatores de ajustes ( = 28) na expressão , 
obtemos:
Estimativa de PF = 321 PF. Dessa forma, podemos 
calcular as estimativas de Custo Total Estimado do projeto 
e Esforço necessário para desenvolvê-lo, conforme 
apresentado a seguir.
Modelos de Estimativas
Modelos de Estimativa Empíricos 
Alguns modelos de estimativa para software usam fór-
mulas 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 proje-
tos. Cada modelo de estimativa normalmente é 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 empresa.
É claro que, antes de serem usados na sua empresa, 
caro aluno, esses modelos devem ser testados usando re-
sultados de projetos finalizados. Os dados estimados pelo 
modelo devem ser comparados aos resultados reais e a efi-
cácia do modelo deve ser analisada para as condições lo-
cais. A estrutura geral dos modelos empíricos tem a forma:
onde
A, B, c = são constantes derivadas empiricamente 
Métricas de Desenvolvimento de Software
25
E = esforço em pessoas-mês 
ev = variável de estimativa (LOC ou PF)
A maioria dos modelos de estimativa tem alguma for-
ma de fator de ajuste ao projeto. Isso permite que a va-
riável “E” seja ajustada por características específicas do 
projeto, tais como:
• complexidade do problema 
• experiência da equipe 
• ambiente de desenvolvimento 
A seguir, apresentamos alguns exemplos de modelos 
empíricos orientados a PF para esforço (E):
E agora, alguns exemplos de modelos empíricos orien-
tados a LOC para esforço (E):
É importante ressaltar, caro aluno, que para os mes-
mos valores de PF ou LOC, os modelos vão gerar resul-
tados 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.
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 estimativa. 
Esse modelo apresenta, além da expressão para esti-
mativa de esforço vista anteriormente, as seguintes ex-
pressões empíricas de estimativa:
Problema:
Suponha que a sua empresa foi contrata para desen-
volver um software de CAD. 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 numa base de dados, organizada conside-
rando softwares do mesmo domínio de aplicação.Após 
uma análise preliminar na base de dados da empresa, e 
considerando softwares do mesmo domínio de aplicação 
do software a ser desenvolvido, obtiveram-se, para cada 
função a ser implementada no software, os valores de ta-
manho otimista, mais provável e pessimista, em LOC, re-
lacionados na tabela 8. 
Considerando isso e utilizando os dados fornecidos na 
tabela 8, calcule:
• a estimativa de tamanho do software em LOC
• o esforço 
• a duração do projeto 
• o tamanho da equipe 
• o número de páginas de documentação.
Tabela 8: Tamanhos em LOC para cada função a ser 
implementada
Solução 
a. Para calcular a estimativa do tamanho do software em LOC, 
calculamos a estimativa de tamanho para cada função. Para 
isso, utilizamos a expressão da média ponderada apresen-
tada anteriormente: T = ( Tot + 4Tmp + Tpess ) / 6
Métricas de Desenvolvimento de Software
26
Dessa forma, chegamos aos resultados mostrados na 
Tabela 9.
Tabela 9: Cálculo do tamanho de cada função a ser im-
plementada no software
b. Esforço = E = 5,2 x (KLOC)0,91 = 5,2 x (34,317) 0,91 @ 
129,81 PM
c. Duração do Projeto = D = 4.1 x (KLOC) 0.36 = 4,1 x 
(34,317)0,36 @ 14,64 meses 
d. Tamanho da Equipe = S = 0.54 x (E) 0.6 = 0,54 x 
(129,81)0,6 @ 10 pessoas 
e. Páginas de Documentação: DOC = 49 x (KLOC) 1.01 
= 49 x (34,317)1,01 @ 1742 páginas 
Note que nas expressões acima deve-se utilizar KLOC 
(e não LOC) e que PM significa pessoa-mês.
Modelo COCOMO - Conceitos Básicos
COCOMO- COnstructive COst MOdel (Modelo de 
Custo Construtivo) é um modelo empírico de estimativa 
de software que foi derivado através da coleta de dados 
de um grande número de projetos de software. É bem 
documentado, compatível com ferramentas comerciais e 
de domínio público e é amplamente utilizado.
Sua primeira versão data de 1981 e por isso é referen-
ciado como COCOMO 81 (também é conhecido como CO-
COMO básico). A versão atual é denominada COCOMO 2.
Apresentaremos a seguir detalhes desse modelo.
COCOMO 81 
Apresentado por Boehm (1981), o COCOMO é um 
modelo desenvolvido para estimar esforço, prazo, custo 
e tamanho da equipe para um projeto de software. Todas 
as referências ao COCOMO encontradas na literatura 
publicadas até 1995 são citações desse modelo.
O COCOMO 81 é apresentado na forma de um conjunto 
de modelos divididos hierarquicamente em três níveis: 
Básico, Intermediário e Avançado.
• O modelo 1 – COCOMO Básico, calcula o esforço 
do desenvolvimento de software em função do ta-
manho estimado do programa expresso em linhas 
de código estimadas. 
• O modelo 2 – COCOMO Intermediário, calcula o 
esforço de desenvolvimento de software em fun-
ção do tamanho do programa e de um conjunto de 
direcionadores de custo, alternativamente chama-
dos atributos ou fatores de software, que incluem 
avaliações subjetivas do produto, do hardware, do 
pessoal e dos atributos do projeto. 
• O modelo 3 – COCOMO Avançado, incorpora to-
das as características da versão intermediária, in-
cluindo a avaliação do impacto dos atributos do 
software e da equipe desenvolvedora em cada 
passo do processo de engenharia de software.
Depois da análise dos requisitos funcionais do sof-
tware, o tamanho da aplicação deve ser estimado em 
milhares de linhas de código (KLOC) e o projeto deve ser 
classificado em um dos três modos de desenvolvimento, 
identificados por Boehm (1981): orgânico, embutido ou 
semi destacado. 
• No modo orgânico, equipes relativamente peque-
nas desenvolvem sistemas num ambiente alta-
mente “familiar”, in-house. Nesse modo de desen-
volvimento, a maior parte das pessoas engajadas 
no projeto tem experiência prévia com sistemas 
similares na organização e entendimento comple-
to do sistema. Outras características do modo or-
gânico são: ambiente estável de desenvolvimento 
com pouca necessidade de inovação e inexistência 
de requisitos de entrega rígidos; uso de algoritmos 
simples; tamanho relativamente pequeno, com 
projetos na faixa de até 50.000 linhas de código.
• O principal fator que distingue um projeto de sof-
tware de modo embutido ou restrito é a neces-
sidade de seguir restrições rigorosas. O produto 
a ser desenvolvido deverá operar dentro de um 
Métricas de Desenvolvimento de Software
27
contexto complexo de hardware, software e regras 
e procedimentos operacionais. São projetos de 
software caracterizados por serem relativamente 
grandes, com muita necessidade de inovação, que 
demandam altos custos de verificação e validação. 
Caro aluno, podemos citar como exemplos de pro-
jetos do modo embutido: projeto de sistema de 
transferência eletrônica de fundos e projeto de 
sistema de controle de tráfego aéreo.
• O modo semidestacado é aplicado em projetos de 
software com características situadas entre os mo-
dos orgânico e embutido. Suas características bási-
cas são: a equipe mescla grande e pouca experiência 
com a aplicação e com a tecnologia e o tamanho do 
software pode chegar a 300.000 linhas de código.
Estimativa de esforço de desenvolvimento
As equações de estimativa de esforço de desenvolvi-
mento são da forma apresentada na equação:
onde 
S é o tamanho do software expresso em milhares de 
linhas de código, excluídos os comentários
m(X) é um multiplicador composto que depende de 15 
direcionadores de custo
No COCOMO Básico, m(X) = 1 para cada direcionador 
de custo; no COCOMO Intermediário devem ser atribuídos 
valores específicos para cada atributo.
Os modos de desenvolvimento e os valores de ai e bi 
para os níveis Básico e Intermediário são apresentados na 
tabela 10.
Tabela 10: valores de ai e bi para os níveis Básico e 
Intermediário do COCOMO
Fonte: baseado em BOEHM [1981]
Direcionador de custo é uma característica de desen-
volvimento de software que tem efeito aumentativo ou 
diminutivo na quantidade de esforço de desenvolvimento 
final do projeto. Boehm (1981) definiu 15 direcionadores 
de custo para o COCOMO que, segundo ele, provocam im-
pacto significativo na produtividade e nos custos do pro-
jeto. O fator m(X) da equação de estimativa de esforço de 
desenvolvimento é o produto dos 15 direcionadores de 
custo. Definições completas dos direcionadores de custo 
estão descritas no trabalho de Boehm (1981).
Estimativa do prazo de desenvolvimento
Além de estimar o esforço, o COCOMO também apre-
senta equações para estimar o prazo de desenvolvimento 
nominal do projeto em meses e a divisão do esforço por 
fases e atividades do projeto.
Os modos de desenvolvimento Básico e Intermediário 
utilizam as mesmas equações para determinar o prazo. As 
equações de estimativa de prazo de desenvolvimento são 
da forma apresentada na equação: 
onde
 T é o tempo de desenvolvimento, e 
 E é o esforço já calculado.
Os modos de desenvolvimento e os valores de ai e bi 
para os níveis Básico e Intermediário são apresentados na 
Tabela 11.
Tabela 11: valores de ai e bi para os níveis Básico e In-
termediário do COCOMO
Fonte: baseado em BOEHM [1981]
Exemplo de aplicação do COCOMO 
 
Como exemplo de aplicação do modelo COCOMO Bá-
sico, vamos utilizar os dados fornecidos no exemplo da 
Métricas de Desenvolvimento de Software
28
seção 3.1.1 para calcular o esforço necessário para desen-
volver o software proposto naquele exemplo. Suponha 
que o projeto é de nível básico e o modo de desenvolvi-
mento é semidestacado.
Para fazer esse cálculo, fazemos uso da expressão E = 
ai Sbim(X), conforme seção 3.3.1. Como o exemplo é uma 
aplicação do COCOMO Básico, m(X) é igual a 1.
Os valores de ai e bi são obtidos da tabela 10 (ai = 3,0 
e bi = 1,12) e o valor de S, estimativa do tamanho do sof-
tware, é igual a 34.317LOC, ou seja, aproximadamente 34 
KLOC (esse valor foi calculado no exemplo da seção 3.1.1).
 
Substituindo esses valores na equação de esforço aci-
ma, teremos:
COCOMO II
Para atender às necessidades de um modelo de esti-
mativa de custo de projeto de software mais adequado 
às práticas de ciclo de vida de software dos anos 1990 e 
2000, teve início, em 1994, o projeto COCOMO II, com o 
objetivo de desenvolver um modelo de custo mais atuali-
zado que o modelo antecessor. 
Três modelos de estimativa de custo foram apresenta-
dos como resultado do projeto COCOMO II: Composição 
de Aplicação - Application Composition, Projeto Prelimi-
nar - Early Design e o modelo Pós-Arquitetura- Post-Archi-
tecture, que serão explicados no que se segue. 
Modelo Application Composition
O modelo Application Composition - Composição de 
Aplicações foi projetado especificamente para aplicações 
que são desenvolvidas por equipes pequenas em poucas 
semanas ou meses.
O modelo foi projetado para prever o esforço de pro-
totipação envolvido no uso de ambientes integrados de 
composição rápida de aplicações de software auxiliadas 
por computador ou ICASE – Integrated Computer-Aided 
Software Environment.
O modelo prevê a contagem de Pontos de Objeto, 
uma nova abordagem de medição de tamanho de softwa-
re para estimar custo e prazo de projetos. É um tipo de 
contagem funcional de telas, relatórios e de módulos de 
linguagem de terceira geração, em que cada um dos ele-
mentos contados recebe uma classificação em níveis de 
complexidade (simples, média e alta).
Segundo os projetistas do COCOMO II, estimativas 
de Pontos de Objeto foram comparadas a estimativas de 
Pontos de Função e mostraram resultados mais adequa-
dos aos tipos de aplicação a que se destina o modelo Ap-
plication Composition [CSSE, 2012].
Caro aluno, no modelo Application Composition, o es-
forço é computado através da expressão e mais detalhes 
podem ser obtidos em CSSE (2012):
onde:
PM = Esforço em pessoas-mês
NOP = Novos Pontos de Objeto Contados
PROD = Produtividade dos Desenvolvedores
Uma pessoa/mês é a quantidade de tempo correspon-
dente ao gasto por uma pessoa trabalhando em um pro-
jeto de desenvolvimento de software em um mês. Esse 
número não inclui feriados ou férias e considera tempo 
livre nos finais de semana. O número de pessoas-mês é 
diferente do tempo necessário para completar um proje-
to; um projeto pode ser estimado em 50 PM de esforço e 
11 meses de cronograma.
Modelo Early Design
As etapas posteriores às fases iniciais de projetos ou ci-
clos de vida espirais podem requerer a pesquisa de arqui-
Métricas de Desenvolvimento de Software
29
teturas alternativas ou estratégias de desenvolvimento 
incremental. O modelo Early Design foi desenvolvido para 
elaborar estimativas iniciais e apoiar essas atividades. 
As principais variáveis de entrada para o modelo são: o 
tamanho estimado do sistema e os direcionadores de custo. 
O tamanho da aplicação que vai ser desenvolvida é a principal 
variável de entrada para cálculo de esforço e tempo.
 Derivado da estimativa do tamanho dos módulos de 
software que irão constituir a aplicação ou programa, o 
tamanho deve ser expresso em unidade de milhares de 
linhas de código (KLOC).
O modelo Early Design permite que o tamanho da apli-
cação possa ser estimado em pontos de função não ajus-
tados, posteriormente convertidos em linhas de código 
pelo modelo. 
Pontos de função podem ser utilizados como boas es-
timativas porque são baseados em informações que estão 
disponíveis logo no início do ciclo de vida do projeto.
O modelo Early Design utiliza um conjunto reduzido 
de direcionadores de custo. As escalas correspondentes e 
os multiplicadores de esforço desses direcionadores man-
tém relacionamento consistente com os direcionadores 
combinados do modelo Post-Architecture, para assegurar 
a consistência das estimativas dos dois modelos, confor-
me mostra a tabela 12.
Tabela 12: Direcionadores de Custo aplicados no mo-
delo Early Design e Post-Architecture
Fonte: [CSSE, 2012]
A equação seguinte é utilizada para calcular o esforço 
de desenvolvimento em projetos estimados pelo modelo 
Early Design:
onde:
PM = Esforço estimado em pessoas-mês
a = Constante provisoriamente ajustada em 2,5
Tamanho = Tamanho estimado, expresso em milhares 
de linhas de código (KLOC)
b = fator escalar
EM – Multiplicadores de esforço: RCPX, RUSE, PDIF, 
PERS, PREX, FCIL, SCED
PMM = Estimativa de esforço de manutenção
O coeficiente b é calculado através da equação:
 
onde:
SF = fatores de escala: PREC, FLEX, RESL, TEAM, PMAT
Para ajustar o tamanho efetivo do produto de softwa-
re, o COCOMO utiliza várias expressões que levam em 
consideração a volatilidade dos requisitos, o reuso de 
componentes, além de calcular o esforço de manutenção. 
Maiores detalhes sobre essas expressões podem ser en-
contradas no manual do COCOMO II.
 
Para estimar o cronograma de desenvolvimento de 
projetos, os modelos de estimativa do COCOMO II utili-
zam a expressão:
onde:
a = constante, provisoriamente ajustada em 3,0
SCED% = porcentagem de compreensão/expansão do 
multiplicador de esforço SCED
PM = estimativa de pessoas-mês
b = fator escalar
TDEV = tempo de desenvolvimento
Métricas de Desenvolvimento de Software
30
Modelo Post-Achitecture
Quando um projeto se apresenta pronto para ser 
desenvolvido, já deve possuir uma arquitetura de ciclo de 
vida que possa fornecer informações mais precisas para 
as entradas dos direcionadores de custo, proporcionando 
estimativas mais precisas.
Para apoiar esse estágio, o COCOMO II projetou o 
modelo Post-Architecture, um modelo comprometido 
com a forma de desenvolvimento de software utilizada e 
também de manutenção de produtos de software. Esse 
modelo prevê a utilização de linhas de código e/ou pontos 
de função para estimar o tamanho inicial do projeto, 
reuso de software, 17 direcionadores de custo e 5 fatores 
de escala de projeto.
Para estimar pontos de função para o modelo Post-
Architecture, utiliza-se o processo de conversão de pontos 
de função não ajustados em linhas de código sugerido 
pelo modelo Early Design. O COCOMO II permite que 
componentes possam ter seus tamanhos estimados em 
pontos de função e outros, onde pontos de função não 
podem ser bem descritos, tais como aplicações em tempo 
real e computação científica, em linhas de código.
O objetivo da contagem de linhas de código é medir 
a quantidade de trabalho intelectual necessário para de-
senvolver um programa. Uma das dificuldades de conta-
gem aparece quando se tenta definir medições consisten-
tes em diferentes linguagens. 
Definir o que é uma linha de código é difícil devido às 
diferenças conceituais envolvidas no processo de conta-
gem de declarações executáveis e declarações de dados 
em diferentes linguagens.
O modelo COCOMO II sugere o uso de um checklist 
desenvolvido pela SEI para apoiar as medições. O checklist 
completo está disponibilizado no manual do COCOMO II.
Para assegurar a uniformidade de dados coletados no 
projeto COCOMO II, uma ferramenta de coleta de métricas 
automatizada chamada Amadeus foi utilizada.
O modelo Post-Architecture utiliza 17 direcionadores 
de custo para ajuste do esforço nominal, agrupados em 
4 categorias: Produto, Plataforma, Pessoal e Projeto. A 
relação completa desses direcionadores de custo pode 
ser encontrada no manual do COCOMO II.
O esforço de desenvolvimento, segundo o modelo Post-
Architecture é estimado através da seguinte equação, que se 
diferencia da equação do modelo Early Design no número de 
direcionadores de custo, que agora passa a ser 17.
onde: