trabalho metricas de software

Prévia do material em texto

1. Introdução
A métrica Pontos de Função (PF), definida por Allan Albrecht em 197 9, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (Internacional Function Point Uses Grou), criado em 1986, é responsável pela atualização das regras de C montagem de Pontos de Função, descritas no CPM (Continha Pratiques Manual), que se encontra na versão 4.3, está baseada principalmente na Release 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em conta agem de Pontos de Função, denominada CFPS (Certified Function Point Specialist). A métrica Pontos De Função é uma medida de tamanho funcional de projetos de software, considerando as Funcionalidades implementadas, sob o ponto de vista do usuário. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” (Dekkers, 2003). Pontos por função são a medida do tamanho das aplicações de computados e os projetos que os constroem. A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, recomenda a utilização da métrica por Pontos de Função nas estimativas de tamanho dos projetos de software. Também é utilizada a métrica para estimar os projetos dos clientes, onde se obtém excelentes resultados.
Definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do 
usuário” (Dekkers, 2003).
2. Sumário
Então, o próprio mercado exige, hoje, a gestão da qualidade, do conhecimento e sabe-se que não se pode gerenciar o que não se pode medir. No entanto, como medir valores como o conhecimento ou a qualidade?
Sabemos que todo processo de engenharia necessita de medições para entender melhor os modelos e avaliar a quantidade dos produtos construídos. No caso da engenharia de software – que não é fundamentada nas medidas quantitativas diretas, como voltagem, temperatura, velocidade – as suas medidas e métricas são na sua maioria indiretas. 
Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos às características de uma entidade qualquer, definidos de acordo com regras bem definidas. Na ciência da computação, podemos medir os atributos, antes considerados incomensuráveis – ainda que alguns especialistas em software continuem a argumentar que o software é “incomensurável”.
2.1 O que é métrica?
Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software, focalizando atributos específicos e mensuráveis dos artefatos da engenharia de software.
2.2Quem realiza?
Os engenheiros de software usam métricas de produto para ajudá-los a criar software da mais alta qualidade.
Haverá sempre um elemento qualitativo na criação de software. O problema é que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários critérios objetivos para ajudar a direcionar o projeto de dados, arquitetura, interfaces e componentes. Ao testar, necessitamos de orientação quantitativa que nos auxiliará na seleção de casos de teste e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa.
Por que devemos medir?
• Para sabermos quanto cobrar;
• Para conseguirmos dar prazos;
• Para definirmos a equipe;
• Para definirmos complexidade;
• Para definirmos tamanho;
• Para medirmos risco.
Quais são as etapas envolvidas?
1-O primeiro passo no processo de medição é definir as métricas apropriadas para o software. 
2-Em seguida, coletam-se os dados necessários para aplicar as métricas formuladas.
3-Uma vez computadas, as métricas são analisadas com base em diretrizes preestabelecidas e dados do passado.
4-Os resultados das análises são interpretados para obter informações sobre a qualidade do software.
5-Os dados da interpretação levam à modificação dos requisitos e modelos de projeto, código-fonte ou casos de teste.
2.3 Qual é o artefato (produto)?
O produto, no caso, são as métricas computadas por meio de dados coletados dos requisitos e modelos de projeto, código-fonte e casos de teste.
Como garantir que o trabalho seja realizado corretamente?
Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo cada métrica de produto de maneira não ambígua. Defina apenas algumas métricas e, então, use-as para obter informações sobre a qualidade do artefato de software.
Embora as métricas de produto para software sejam imperfeitas, podem proporcionar uma maneira sistemática de avaliar a qualidade com base em um conjunto de regras claramente definidas. Elas também proporcionam uma visão objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e corrigir problemas potenciais antes que se tomem defeitos catastróficos.
3. EXEMPLO. 
	VAMOS USAR ESTE ESTUDO DE CASO PARA SIMPLIFICAR NOSSO ENTEDIMENTO DO ÓPICO EXEMPLO DE CÁLCULO DE PONTOS DE FUNÇÃO (PF) 
	DESCRIÇÃO DO SISTEMA:
	O restaurante STOP Salgadinho deseja implantar um sistema para controlar suas atividades principais, desde a contratação de funcionários até o controle de estoque, passando pelo atendimento ao cliente. O sistema funcionará da seguinte forma: Cada mesa estará equipada com um terminal ligado a um computador central, que fará o controle de todas as transações. Quando o cliente chegar, o garçom fará a “abertura" da mesa. A partir deste momento, o cliente pode fazer pedidos, chamar o garçom e pedir a conta. Cada pedido deverá ser validado pelo cozinheiro assim que o mesmo estiver pronto, caracterizando a baixa definitiva no estoque. A correção do pedido é feita pelo gerente, que também é responsável pelo encerramento d a conta e por fazer requisições aos fornece dores. Quando o fornecedor entrega a requisição, o gerente informa a chegada de mercadoria ao sistema.
3.1 INICIANDO O PROCESSO PARA DEFINIÇÃO DOS OBJETIVOS E METAS 
	OBJETIVOS:
	1
	Acelerar o atendimento;
	2
	Evitar erros e acelerar a entrega de pedidos e emissão da conta;
	3
	Estimular o consumo;
	4
	Diminuir o número de garçons por mesa; 
	5
	Facilitar o controle do estoque.
	METAS:
	1
	Instalação de terminais nas mesas, que enviam o pedido diretamente para a cozinha;
	2
	Passar a responsabilidade do pedido para o cliente, e a da conta para o sistema;
	3
	Fazer propaganda dos pratos oferecidos pelo restaurante nos terminais;
	4
	Diminuir o número de garçons por mesa; 5 Facilitar o controle do estoque.
	5
	Integrar todas as funcionalidades do restaurante no mesmo sistema.
3.2 LISTANDO TODOS OS EVENTOS ESSENCIAIS 
	ID
	EVENTOS
	CLASSIFICAÇÃO 
	1
	Gerente cadastra fornecedor
	Externo, não esperado 
	2
	Gerente cadastra mesa
	Externo, não esperado 
	3
	Gerente cadastra produto
	Externo, não esperado 
	4
	Gerente cadastra prato 
	Externo, não esperado 
	5
	Gerente cadastra funcionário
	Externo, não esperado 
	6
	Garçom faz a abertura da mesa
	Externo, não esperado
	7
	Cliente faz pedido 
	Externo, esperado 
	8
	Cozinheiro valida pedido 
	Externo, esperado 
	9
	Cliente chama garçom
	Externo, esperado 
	10
	Gerente faz correção do pedido
	Externo, esperado 
	11
	Cliente pede nota 
	Externo, esperado 
	12
	Gerente encerra conta
	Externo, esperado 
	13
	Sistema gera relatório final do dia
	Temporal, esperado 
	14
	Gerente faz requisição aos fornecedores
	Externo, não esperado 
	15
	Fornecedor entrega requisição e gerente informa ao sistema
	Externo, esperado
3.3 DESCRIÇÃO INDIVIDUAL DOS EVENTOS 
	ID
	INICIADOR
	TRANSPORTADOR
	ESTÍMULO
	RESPOSTA
	SAÍDA
	1
	Gerente
	Gerente
	Mudança nas mesas
	Escreve em mesa
	-
	2
	Gerente
	Gerente
	Mudança nos fornecedores
	Escreve em fornecedor-
	3
	Gerente
	Gerente
	Mudança nos pro dutos
	Escreve em estoque
	-
	4
	Gerente
	Gerente
	Mudança nos pratos
	Escreve em menu
	-
	5
	Gerente
	Gerente
	Mudança nos funcionários
	Escreve em funcionários
	-
	6
	Cliente
	Garçom
	Chegada de cliente
	Abertura da mesa
	Exibição do menu
	7
	Cliente
	Cliente
	Pedido do cliente
	Escreve em pedido e menu
	Exibição do pedido no visor da cozinha e atualização dos terminais
	8
	Cozinheiro
	Cozinheiro
	Pedido pronto
	Escreve em estoque e pedido
	Eliminação do pedido do visor da cozinha
	9
	Cliente
	Cliente
	Chamada do cliente
	-
	Exibição da chamada no visor da cozinha
	10
	Cliente
	Gerente
	Solicitação do cliente
	Escreve em pedido e menu
	Exibição do pedido no visor da cozinha e atualização dos terminais
	11
	Cliente
	Cliente
	Fim dos pedidos
	-
	Mensagem para o gerente
	12
	Gerente
	Gerente
	Solicitação do cliente
	Escreve em nota e mesa
	Fechamento da mesa
	13
	-
	-
	Fim do expediente
	Escreve em relatório
	Relatório
	14
	Gerente
	Gerente
	Limite crítico de estoque
	Escreve em requisição
	Identificação da requisição
	15
	Fornecedor
	Gerente
	Chegada de requisição
	Escreve em estoque e requisição
	-
 
3.4 AVALIANDO O TAMANHO DO SISTEMA 
	ITEM
	ENTRADAS
	SAÍDAS
	CONSULTAS
	ARQUIVOS
	INTERFACE COM OUTRO SISTEMA
	1
	1
	-
	-
	1
	-
	2
	1
	-
	-
	1
	-
	3
	1
	-
	-
	1
	-
	4
	1
	-
	-
	1
	-
	5
	1
	-
	-
	1
	-
	6
	1
	-
	-
	-
	-
	7
	1
	-
	-
	1
	-
	8
	1
	-
	-
	-
	-
	9
	1
	1
	-
	-
	-
	10
	1
	-
	-
	-
	-
	11
	1
	1
	-
	-
	-
	12
	1
	1
	-
	1
	-
	13
	-
	1
	-
	-
	-
	14
	1
	-
	1
	-
	-
3.5 TABELA DE COMPLEXIDADE DO PONTO FUNÇÃO (IFPUG) 
São utilizados para determinar a complexidade de cada função, baixa, média ou alta, a seguinte tabela do IFPUG, sintetiza o número de pontos de função atribuídos a cada tipo de função. 
	TIPO DE FUNÇÃO
	BAIXA
	MÉDIA
	ALTA
	EE (ENTRADAS EXTERNAS)
	3
	4
	6
	SE (SAÍDAS EXTERNAS)
	4
	5
	7
	CE (CONSULTAS EXTERNAS)
	3
	4
	6
	ALI (ARQUIVOS LÓGICOS INTERNOS)
	7
	10
	15
	AIE (ARQUIVOS DE INTERFACES EXTERNAS)
	5
	7
	10
3.6 SISTEMA MÉDIO 
	ITENS
	Nº DE ITENS
	MULTIPLICADORES
	RESULTADO
	Entradas
	13
	X4
	52
	Saídas
	5
	X5
	25
	Consultas
	0
	X4
	0
	Arquivos
	8
	X10
	80
	Interface com outro sistema
	0
	X7
	0
	TOTAL
	157
3.7 CÁLCULANDO O NÚMERO DE PONTO DE FUNÇÃO CÁLCULO DE PF OBS: Para finalizarmos o cálculo de PF, devemos somar os resultados das perguntas através da seguinte legenda. ID DESCRIÇÃO DA LEGENDA 0 Não tem influência 1 Influência incidental 2 Influência moderada 3 Influência média 4 Influência significativa 5 Influência essencial PERGUNTAS RESPOSTAS O sistema necessita de backup e recuperação confiável? 2 É necessário utilizar comunicação de dados? 5 Existe processamento distribuído de funções? 2 A performance é critica? 3 O sistema vai funcionar em um ambiente operacional já existente e fortemente utilizado? 0 O sistema exige entrada de dados online? 5 A entrada de dados exige que a transação seja realizada por meio de várias telas ou operações? 4 Os arquivos são atualizados online? 5 As entradas , saídas e consultas são complexas? 2 O processamento interno é complexo? 2 O código deve ser projetado para ser reutilizado? 5 TOTAL 35 E só substituir os dados na seguinte equação: PF = ( 166 x (0,65 + (0,01 x Somatório(perguntas))) PF = 157 x 1 = 157
3. Objetivo
5. Conclusão
6. Referências
7. Dificuldades encontradas
8. Lições aprendidas
Então, o próprio mercado exige, hoje, a gestão da qualidade, do conhecimento e sabe-se que não se pode gerenciar o que não se pode medir. No entanto, como medir valores como o conhecimento ou a qualidade?
Sabemos que todo processo de engenharia necessita de medições para entender melhor os modelos e avaliar a quantidade dos produtos construídos. No caso da engenharia de software – que não é fundamentada nas medidas quantitativas diretas, como voltagem, temperatura, velocidade – as suas medidas e métricas são na sua maioria indiretas. 
Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos às características de uma entidade qualquer, definidos de acordo com regras bem definidas. Na ciência da computação, podemos medir os atributos, antes considerados incomensuráveis – ainda que alguns especialistas em software continuem a argumentar que o software é “incomensurável”.
O que é métrica?
Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software, focalizando atributos específicos e mensuráveis dos artefatos da engenharia de software.
Quem realiza?
Os engenheiros de software usam métricas de produto para ajudá-los a criar software da mais alta qualidade.
Haverá sempre um elemento qualitativo na criação de software. O problema é que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários critérios objetivos para ajudar a direcionar o projeto de dados, arquitetura, interfaces e componentes. Ao testar, necessitamos de orientação quantitativa que nos auxiliará na seleção de casos de teste e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa.
Por que devemos medir?
• Para sabermos quanto cobrar;
• Para conseguirmos dar prazos;
• Para definirmos a equipe;
• Para definirmos complexidade;
• Para definirmos tamanho;
• Para medirmos risco.
Quais são as etapas envolvidas?
1-O primeiro passo no processo de medição é definir as métricas apropriadas para o software. 
2-Em seguida, coletam-se os dados necessários para aplicar as métricas formuladas.
3-Uma vez computadas, as métricas são analisadas com base em diretrizes preestabelecidas e dados do passado.
4-Os resultados das análises são interpretados para obter informações sobre a qualidade do software.
5-Os dados da interpretação levam à modificação dos requisitos e modelos de projeto, código-fonte ou casos de teste.
Qual é o artefato (produto)?
O produto, no caso, são as métricas computadas por meio de dados coletados dos requisitos e modelos de projeto, código-fonte e casos de teste.
Como garantir que o trabalho seja realizado corretamente?
Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo cada métrica de produto de maneira não ambígua. Defina apenas algumas métricas e, então, use-as para obter informações sobre a qualidade do artefato de software.
Embora as métricas de produto para software sejam imperfeitas, podem proporcionar uma maneira sistemática de avaliar a qualidade com base em um conjunto de regras claramente definidas. Elas também proporcionam uma visão objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e corrigir problemas potenciais antes que se tomem defeitos catastróficos.
Avaliação dos atributos internos do produto
A seguir, veremos algumas medidas que podem ser usadas para avaliar a qualidade do produto enquanto ele está sendo projetado.
Essas medidas de atributos internos do produto fornecem uma indicação em tempo real da eficácia dos modelos de requisitos, projeto e código, da eficácia dos casos de teste e da qualidade geral do software que será criado.]
Qualidade de software
O desenvolvimento de sistemas de software envolve uma série de atividades em que as oportunidades de falhas são muito grandes.
Os erros podem aparecer no início do processo devido a alguns fatores:
• Objetivos mal definidos;
• Erros em fases de projeto e desenvolvimento.
Ninguém tolera erros, por isso o desenvolvimento de software tem que ter garantia de qualidade.
A atividade de teste de software é um elemento crítico da garantiade qualidade de software e representa a última revisão de especificação, projeto e codificação.
Custo do reparo
Quanto mais cedo for verificado o software durante o seu ciclo de vida, menores as chances de elevar os custos de reparo.
Curva de falhas para hardware ou curva da banheira
Garantia de qualidade
A garantia de qualidade de software (Software Quality Assurance) não é algo com a qual começamos a nos preocupar depois que o código foi gerado, e sim ao longo de todo o processo de engenharia de software. A SQA ou GQS abrange:
1 Métodos e ferramentas de análise, projeto, codificação e teste;
2 Revisões técnicas em cada fase do desenvolvimento;
3 Estratégia de teste;
4 Documentação de software e das mudanças efetuadas;
5 Padrões de desenvolvimento de software;
6 Estratégia de teste;
Fatores determinantes para a garantia da qualidade
Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade aos requisitos significa falta de qualidade.
Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade.
Conjunto de requisitos que não são mencionados (ex.: boa manutenibilidade). Caso o software se adéque aos requisitos explícitos, mas não aos implícitos, sua qualidade será suspeita.
Fatores de qualidade de McCall
McCall propõe uma categoria de fatores que afetam a qualidade do software, conforme mostra a figura.
Características operacionais
Corretude
Refere-se à capacidade de um programa satisfazer sua especificação e cumprir os objetivos visados pelo cliente. Ele faz aquilo que eu quero?
Confiabilidade
Refere-se à capacidade de um programa executar a função pretendida com a precisão exigida. Ele se comporta com precisão o tempo todo? 
Usabilidade
Refere-se ao esforço necessário para aprender, operar, preparar a entrada e interpretar a saída de um programa. Ele foi projetado para o usuário?
Integridade
Refere-se à capacidade de controlar o acesso ao software ou a dados por pessoas não autorizadas. Ele é seguro?
Eficiência
Refere-se à quantidade de recursos computacionais e de código exigida para que um programa execute sua função. Ele rodará em meu hardware tão bem quanto possível?
Características de manutenção
Manutenibilidade
Refere-se ao esforço exigido para localizar e reparar erros em um programa. Posso consertá-lo?
Flexibilidade
Refere-se ao esforço demandado para modificar um programa. Posso mudá-lo?
Testabilidade
Refere-se ao esforço exigido para testar um programa a fim de garantir que ele execute a função pretendida. Posso testá-lo?
Características de adaptação a novos ambientes
Portabilidade
Refere-se ao esforço exigido para transferir o programa de um ambiente para outro. Serei capaz de usá-lo em outra máquina?
Reusabilidade
Refere-se à capacidade de um programa, ou partes, ser reusado em outras aplicações. Serei capaz de reutilizar parte do software?
Interoperabilidade
Refere-se ao esforço exigido para se acoplar um sistema a outro. Serei capaz de compor uma interface com outro sistema?
Fatores de Qualidade ISO 9126
Funcionalidade: A funcionalidade diz respeito ao grau com que o software satisfaz as necessidades indicadas pelos seguintes subatributos: adequabilidade, precisão, interoperabilidade, atendibilidade e segurança.
Além da funcionalidade, outros fatores da ISO 9126: confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
SEGUNDO PRESSMAN:
“O teste é o último reduto no qual a qualidade pode ser avaliada”;
“Você não pode testar qualidade. Se ela não estiver lá antes, ela não estará lá quando terminar de testar”;
“Otimismo é o risco ocupacional da programação; teste é o tratamento";
“A qualidade de um software é função de quanto ele muda o mundo para melhor”.
Métricas de indicadores e de produto
É importante que você entenda as diferenças sutis entre os termos medida, medição e métrica, empregados com frequência.
MEDIDA
Sob o contexto de engenharia de software, medida proporciona uma indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum produto ou processo. 
MEDIÇÃO
A medição é o ato de determinar uma medida. 
MÉTRICA
Segundo o IEEE (Standard Glossary of Software Engineering Terminology), métrica busca obter uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo.
Quando é coletado um único ponto de dado (por exemplo, o número de erros descobertos em um componente de software), foi estabelecida uma medida.
A medição ocorre como resultado da coleção de um ou mais pontos de dados (por exemplo, um conjunto de revisões de componentes e testes de unidade é investigado para coletar medidas do número de erros para cada um). 
Uma métrica de software relaciona as medidas individuais de alguma maneira (por exemplo, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade).
Antes que um projeto possa ser planejado, deve-se:
• Estabelecer os objetivos e o escopo do projeto;
• Considerar soluções alternativas;
• Identificar as restrições administrativas e técnicas. 
Controle de software
É impossível controlar um software sem medições e feedback. Não se pode controlar o que não se pode medir e a extensão do controle depende da precisão da medição. Qualquer coisa que não se pode medir está fora de controle.
As medições e métricas ajudam a entender o processo usado para se desenvolver um produto de software e o próprio produto.
O produto e o processo em relação à medição
Produto é medido para avaliar a sua qualidade e processo é medido para melhorá-lo. Para efetivar a medição é necessário ter em mãos documentação de efeitos passados e dados estatísticos de quantificação de efeitos futuros.
A medição e a inferência estatística são usadas em várias áreas para projetar o desempenho futuro.
A medição pode levar a controvérsias e discussões como:
• Que métricas usar?
• Como os dados compilados devem ser usados?
• É justo usar medições para se comparar pessoas, processos e produtos?
As estimativas mais importantes
A estimativa é uma das principais atividades do planejamento de software:
1 Esforço humano exigido
2 Duração do projeto
3 Custo
Métricas são frequentemente classificadas como métricas do processo ou métricas do produto, e são aplicadas durante o processo de desenvolvimento ou ao produto de software desenvolvido.
Métricas do processo
As métricas do processo quantificam atributos do processo de desenvolvimento e do ambiente de desenvolvimento.
Métricas de recursos: experiência do programador, custo de desenvolvimento e manutenção.
Métricas para o nível de experiência do pessoal: número de anos que uma equipe está usando uma linguagem de programação; número de anos que um programador está na organização. 
Outros fatores relacionados ao desenvolvimento incluem: 
• Técnicas de desenvolvimento;
• Auxílio para programação;
• Técnicas de supervisão etc.
Métricas do produto
São medidas do produto de software. Podem não revelar nada sobre como o software foi desenvolvido.
Incluem:
• O tamanho do produto (linhas de código);
• A complexidade da estrutura lógica (recursão – for, while, repeat, fluxo de controle – ordem das instruções do programa – e profundidade de laços aninhados);
• A complexidade da estrutura de dados;
• Funções (tais como tipo de software: comercial, científico etc.). 
Nesse caso, é importante que você conheça um exemplo: O número de defeitos descobertos durante o teste formal depende do produto (número de segmentos de código que estão errados) e do processo usado na fase de teste (a extensão do teste).
Métricas diretas e métricas indiretas
Medidas Diretas do Processo deSoftware:
Custo e esforço aplicados.
Medidas Diretas do Produto:
Número de linhas de código produzidas (KLOC - Kilo Lines of Code ou simplesmente “mil linhas de código”); Velocidade de execução; Tamanho de memória; Número de defeitos registrados em um tempo qualquer.
Medidas Indiretas do Produto:
Qualidade;
Funcionalidade;
Complexidade;
Eficiência;
Confiabilidade;
Manutenibilidade.
Métricas orientadas ao tamanho
Linhas de Código (KLOC): uma linha de código é qualquer linha do texto de um programa, exceto comentários e linhas em branco, sem levar em conta o número de comandos ou fragmentos de comandos em uma linha. Estão incluídas na definição de linhas de código todas as linhas que contém cabeçalho do programa, declarações e comandos executáveis.
Vantagens:
• É fácil de calcular;
• É o fator mais importante para muitos modelos de estimativa.
Desvantagens:
• Dependente da linguagem de programação;
• Penalizam programas bem estruturados, porém mais curtos.
Métricas orientadas à função
• São medidas indiretas do software;
• Concentram-se na funcionalidade ou utilidade do programa;
• Função: coleção de comandos executáveis que realizam uma determinada tarefa. 
Princípios de medição
• Formulação: criação de medidas e métricas apropriadas para a representação do software.
• Coleção: no caso, refere-se ao mecanismo usado para acumular dados necessários para criar as métricas formuladas.
• Análise: é a computação das métricas e a aplicação de ferramentas matemáticas.
• Interpretação: relacionada à avaliação de métricas que resultam em informações sobre a qualidade da representação.
• Feedback: são recomendações derivadas da interpretação de métricas de produto transmitidas para a equipe de software.
Atributos de métricas eficazes de software
Centenas de métricas já foram propostas para software, algumas demandam medições muito complexas, outras são tão esotéricas que poucos profissionais do mundo real têm qualquer esperança de entendê-las, e outras ainda violam as noções intuitivas básicas do que é realmente um software de alta qualidade.
Pressman (Engenharia de Software) elege atributos que deverão ser abrangidos por métricas. abaixo para conhecer esses atributos, na íntegra.
Atributos de métricas eficazes de software
 A seguir estão elencados os atributos que devem ser considerados pelas métricas – segundo Pressman (Engenharia de Software):
 • Simples e computáveis – deverá ser relativamente fácil aprender a derivar a métrica, e sua computação não deve demandar esforço ou tempo fora do normal. 
• Empiricamente e intuitivamente persuasiva – a métrica deverá satisfazer as ideias do engenheiro de software. 
• Consistente e objetiva – a métrica deverá sempre produzir resultados que não sejam ambíguos. Um terceiro independente deverá ser capaz de derivar o mesmo valor da métrica usando as mesmas informações sobre o software. 
• Consistente no seu uso das unidades e dimensões – a computação matemática da métrica deverá usar medidas que não resultem em combinações bizarras de unidades. Por exemplo, multiplicar número de pessoas nas equipes de projeto pelas variáveis da linguagem de programação no programa resulta em uma mistura duvidosa de unidades que não é claramente convincente. 
• Independente da linguagem de programação – as métricas deverão ser baseadas no modelo de requisitos, modelo de projeto ou na própria estrutura do programa. Elas deverão ser independentes dos caprichos da sintaxe ou semânticas das linguagens de programação. 
• Um mecanismo efetivo para feedback de alta qualidade – a métrica deverá fornecer informações que podem levar a um produto final de melhor qualidade.
Da mesma forma que somente os metros quadrados são insuficientes para administrar uma construção, PF são insuficientes para administrar um projeto de SW.
Para que servem as métricas Pontos por Função?
A métrica Ponto por Função pode ser usada efetivamente como um meio para medir a funcionalidade fornecida por um sistema. Por meio de dados históricos, a métrica FP pode ser empregada para:
Estimar o custo necessário para projetar, codificar e testar o software; 
Prever o número de erros que serão encontrados durante o teste;
Prever o número de componentes e/ou o número de linhas projetadas de código-fonte no sistema implementado.
Valores do domínio de informações
A métrica Pontos por Função está baseada em medidas calculáveis (diretas) do domínio do software e avaliações qualitativas da complexidade do software. Valores do domínio de informações são definidos da seguinte maneira:
Entradas externas (number of external inputs - EEs): cada entrada externa é originada de um usuário ou transmitida de outra aplicação e fornece dados distintos orientados à aplicação ou informações de controle.
Arquivos lógicos internos (internal logic files - ILFs): as entradas devem ser diferenciadas das consultas, que são contadas separadamente. Cada arquivo lógico interno é um agrupamento lógico de dados que reside dentro das fronteiras do aplicativo e é mantido através de entradas externas.
Saídas externas (number of external outputs - EOs): cada saída externa é formada por dados derivados da aplicação e fornece informações para o usuário. São relatórios, telas, mensagens de erro etc.
Consultas externas (number of external inquiries - EQs): uma consulta externa é definida como uma entrada online que resulta na geração de alguma resposta imediata do software na forma de uma saída online.
Arquivos lógicos internos (number of internal logical files ILFs): cada arquivo lógico interno é um agrupamento lógico de dados que reside dentro das fronteiras do aplicativo e é mantido através de entradas externas.
Arquivos de interface externos (number of external interface files - EIFs): cada arquivo de interface externo é um agrupamento lógico de dados que reside fora da aplicação, mas fornece informações que podem ser usadas pela aplicação.
PERGUNTA FORUM PORQUE NO SLIDE 3 DO CAP 2 ESTA EXPLICANDO IFL 2X
Valores do domínio de informações – Tabela de PF
Uma vez coletados os dados, a tabela de PF é preenchida associando um valor de complexidade com cada contagem. Organizações que usam métodos Ponto por  Função desenvolvem critérios para definir se determinada entrada é simples, média ou complexa. No entanto, a determinação da complexidade é de certo modo subjetivo. Veja o quadro a seguir:
Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA)
Um software a ser desenvolvido necessita da aplicação da métrica Pontos por Função. Segundo a equipe de desenvolvimento, a seguinte relação foi determinada ainda na fase de requisitos em consonância com o cliente em função dos arquivos que farão parte do software e seus respectivos pesos com relação ao PF total.
Arquivos Internos             25% do total de PF 
 
Interfaces Externas         3% do total de PF 
  
Entradas Externas          30% do total de PF
 
Saídas Externas              28% do total de PF
 
Consultas                       14% do total de PF
Para calcular o PF devemos seguir os seguintes passos:
1 Eleger um dos tipos de função, preferencialmente aqueles que representam altos percentuais, que são: Arquivos Internos - Entradas Externas - Saídas Externas.
2 Obter o número de ocorrências do tipo de função eleito.
3 Calcular Pontos de Função Não Ajustados (PFNA).
4 Utilizar o Fator de Ajuste da Complexidade = 1.
Durante as conversas preliminares com o cliente, verificou-se que os Arquivos Internos seriam facilmente identificáveis, o que os credenciou como melhor parâmetro para as estimativas de pontos de função.
Verificou-se que o total de Arquivos Internos é 13, portanto, complexidade média, segundo a tabela definida pela equipe de desenvolvimento:
de 1a 5 arquivos                                       Simples
de 6 a 19 arquivos                                    Médio
19 arquivos                                               Complexo
Concluímosque o software é de complexidade Média, pois 13 está na faixa 6 a 19. Considere este número e veja a seguir a continuidade dos cálculos.
Cálculo do PFNA
a) Como Arquivos Internos representam 25% do total dos PF:
25% ===> 13
100% ===> PF
PF = (13 * 100) / 25 = 52
b) Interfaces Externas: 3% de 52 =  1,56 ( ~= 2)
Entradas Externas: 30% de 52 = 15,6  ( ~= 16)
Saídas Externas: 28% de 52 = 14,56 ( ~= 15)
Consultas: 14% de 52 =  7,28 ( ~= 7)
Obs.: os arredondamentos devem obedecer o padrão.
Tabela do PF
Podemos preencher a tabela de PF usando a coluna Complexidade Média.
Cálculo do PFA
Ponto de Função Ajustado (PFA)
Para calcular Pontos por Função Ajustado, usa-se a seguinte relação:
PFA = Total de contagem x [0,65 + 0,01 x  ∑ (Fi)]
Onde a contagem total é a soma de todas as entradas FP obtidas da Tabela.
Os Fi (i = 1 a 14) são fatores de ajuste de valor (value adjustment factors - VAF) baseados em respostas a 14 questões. Clique aqui para visualizá-las.
Cada uma dessas perguntas é respondida por meio de uma escala que varia de 0 (não importante ou não aplicável) a 5 (absolutamente essencial).
Questões para definição dos fatores de ajuste de valor (value adjustment factors – VAF) 1. O sistema requer salvamento (backup)? 2. São necessárias comunicações de dados especializadas para transferir informações para a aplicação ou da aplicação? 3. Há funções de processamento distribuído? 4. O desempenho é crítico? 5. O sistema rodará em um ambiente operacional existente e intensamente utilizado? 6. O sistema requer entrada de dados online? 7. A entrada online de dados requer que a transação de entrada seja composta em múltiplas telas ou operações? 8. Os ILFs (arquivos lógicos) são atualizados online? 9. As entradas, saídas, arquivos ou consultas são complexas? 10. O processamento interno é complexo? 11. O código é projetado para ser reutilizável? 12. A conversão e instalação estão incluídas no projeto? 13. O sistema é projetado para múltiplas instalações em diferentes organizações? 14. A aplicação é projetada para facilitar a troca e o uso pelo usuário? 
Cálculo do PFA após respostas
Os valores constantes na Equação e os fatores de peso aplicados aos valores do domínio de informações são determinados empiricamente.
 
Dando prosseguimento ao exercício, vamos imaginar que após as respostas às 14 perguntas, Fi totalizou 42.
Então:
PFA = Total de contagem x [0,65 + 0,01 x  ∑ (Fi)]
PFA = 311 x [0,65 + 0,01 x 42]
PFA = 311 x 1,11
PFA = 311 x 1,07 = 332,77 ~= 333
Avance a tela para acompanhar um exemplo de Diagrama de Fluxo de Dados (DFD) simples.
Exemplo de Diagrama de Fluxo de Dados (DFD) simples
Um software a ser desenvolvido necessita da aplicação da métrica Pontos por Função. Segundo a equipe de desenvolvimento, a seguinte relação foi determinada ainda na fase de requisitos em consonância com o cliente em função dos arquivos que farão parte do software e seus respectivos pesos com relação ao PF total.
O Diagrama de Fluxo de Dados é avaliado para determinar um conjunto-chave de medidas de domínio de informação necessárias para a computação da métrica ponto de função:
3 entradas externas — senha, botão de emergência e ativar/desativar.
2 consultas externas — consulta de zona e consulta de sensor. 
1 arquivo lógico interno (ILF) — arquivo de configuração do sistema.
2 saídas externas — mensagens e estado do sensor.
4 arquivos de interface externa (EIF) — sensor de teste, configuração de zona, ativar/desativar e alerta de alarme.
Vejamos a seguir o cálculo dos Pontos por Função.
O total da contagem apresentado no quadro Pontos por Função deve ser ajustado usando a Equação, supondo que: 
Método para estimativa de custo – exemplo SERPRO
A estimativa de custo do projeto deve levar em consideração o custo da mão de obra, considerando o esforço e o custo da hora de todos os profissionais envolvidos no desenvolvimento da solução de software. 
Além do custo da mão de obra e recursos computacionais, devem ser considerados outros custos, tais como:
Método para estimativa de custo – exemplo SERPRO
Cálculo Custo do Projeto (CP)
Sugere-se a seguinte fórmula para calcular o custo relativo à mão de obra para o desenvolvimento da solução (CP – Custo do Projeto).
CP = (QHC x VPC) + (QHA x VPA) + (QPF x EPF x VPA) + Outros Custos
Onde:
QHC = Quantidade de Horas do Consultor
VPC = Valor da Hora do Consultor
QHA = Quantidade de Horas do Analista
VPA = Valor da Hora do Analista
QPF = Tamanho do Projeto em PF
EPF = Esforço para implementar um Ponto por Função na plataforma em questão
Cálculo Preço Fixo por Ponto por Função
Caso o contrato seja de preço fixo por Ponto de Função, então pode-se considerar o seguinte:
CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF)
Onde:
VPF = Valor Unitário do PF para o projeto em questão - Identificado de acordo com a Tabela de Serviço Padrão do Sistema de Orçamento Técnico.
A seguir entenda a Contagem de Pontos de Função de Projetos de Manutenção. 
Contagem de Pontos por Função de Projetos de Manutenção
Para que serve a contagem de Pontos por Função de Projetos de Manutenção?
Esta contagem tem como propósito descrever os diversos tipos de projetos de manutenção e mostrar uma solução para o seu dimensionamento em Pontos por Função, visto que o manual de práticas de contagem não contempla projetos de manutenção (maintenance), apenas o de melhoria (enhancement).
Quanto à documentação de projetos de manutenção pequenos (menores que 100 PF), deve-se registrar a solicitação do cliente e documentar os requisitos da aplicação impactada pela demanda, de forma detalhada, visando apoiar a contagem de Pontos de Função da demanda.
É importante também documentar as estimativas e a contagem de Pontos por Função.
Pontos de Casos de Uso (PCU)
Quais são as características?
É possível estimar o tamanho do sistema ainda na fase de levantamento de casos de uso.
Estima o dimensão do sistema de acordo com:
• O modo como os usuários o utilizarão;
• A complexidade de ações requeridas por tipo de usuário;
• A análise em alto nível dos passos necessários para a realização de cada tarefa.
O que é preciso para gerar estimativas com PCU?
• Calcular o peso dos Atores do Sistema;
• Calcular o peso dos casos de uso;
• Calcular fatores de ajuste;
• Calcular o Porte do Sistema.
Avance a tela e veja como calcular o peso dos Atores do Sistema.
Calculando o peso dos Atores do Sistema
Ações 
Encontrar a métrica UAW (Unadjusted Actor Weight).
Classificar atores envolvidos em cada caso de uso.
Somar os produtos do número de atores de cada tipo pelo respectivo peso.
Quadro Tipo de autor/peso
Exemplo
Um sistema projetado para dois tipos de usuários (gerente e usuário comum) e que fosse acessado por um outro sistema utilizando-se de um protocolo de comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível complexo e 1 ator de nível médio).
UAW = (2 * 3) + (1 * 2)
UAW = 8
Boa noite, Milton!
Nesta aula, você compreenderá :
• Métricas para modelo de projeto;
• Fan-out e Fan-in;
• Conectividade;
• Métricas de projeto da arquitetura;
• Métricas para projeto orientado a objeto;
• Acoplamento e Métricas orientadas à classe.
Esta abordagem é muito importante para determinar o tamanho do software.
Bons estudos!
Contextualização 
É inconcebível que o projeto de um novo avião, um novo chip de computador ou um novo edifício comercial seja conduzido sem a definição de medidas, sem determinar métricas para os vários aspectos de qualidade e sem usá-las como indicadores para orientar a maneira pela qual o projeto evoluirá.
E, além disso, o projeto de sistemas complexos baseados em software muitas vezes é realizado praticamente sem nenhuma medição.
A ironia disso tudo é que as métricas de projeto para software estão disponíveis, mas a grande maioria dos engenheiros de software continua ignorando sua existência.
As métricasde projeto para software de computador, como todas as outras métricas de software, não são perfeitas.
Continua o debate sobre sua eficácia e a maneira pela qual deveriam ser aplicadas.
Muitos especialistas argumentam que é necessária mais experimentação para que as medições de projeto possam ser usadas. E, além disso, projeto sem medição é uma alternativa inaceitável.
Examinaremos a seguir algumas das métricas de projeto mais comuns para software de computador. Cada uma delas pode proporcionar uma melhor visualização, e todas podem ajudar o projeto a evoluir para um nível maior de qualidade.
Fan-out e Fan-in
A hierarquia de controle, também chamada estrutura de programa, representa a organização dos módulos de programa.
Ela não representa aspectos procedimentais de software, tais como sequência dos processos, ocorrência/ordem das decisões ou repetição de operações.
A notação mais comum para representar a hierarquia é mostrada na figura.
Notamos que profundidade e largura constituem uma indicação do número de níveis de controle e do espaço de controle global, respectivamente.
Fan-out
É uma medida do número de módulos que são diretamente controlados por outro módulo, isto é, o número de subordinados imediatos para aquele módulo.
Fan-in
Indica quantos módulos controlam diretamente determinado módulo, isto é, o Fan-in de um módulo indica o número de superiores imediatos que ele possui.
O relacionamento de controle entre os módulos é expresso da seguinte maneira: um módulo que controla outro é superordenado a ele e, inversamente, que um módulo controlado por outro é subordinado ao controlador.
Na figura, o módulo X é superordenado aos módulos A, B, C. O módulo H é subordinado ao módulo E, que é subordinado ao módulo A.
Fan-out e Fan-in: características
A hierarquia de controle também representa duas características distintas: visibilidade e conectividade.
Visibilidade
Indica o conjunto de componentes de programas que pode ser invocado ou usado como dados por um determinado componente.
Por exemplo, um módulo de um sistema orientado a objeto pode ter acesso a uma ampla sucessão de objetos de dados que ele herdou, mas só faz uso de um pequeno número desses objetos de dados.
Conectividade
Indica o conjunto de componentes que é diretamente invocado ou usado como dados por determinado componente.
Por exemplo, um módulo que faça diretamente outro módulo iniciar a execução é conectado a ele.
Métricas de projeto da arquitetura
As métricas de projeto da arquitetura focalizam as características da arquitetura do programa com ênfase na estrutura arquitetônica e na eficácia dos módulos ou componentes dentro da arquitetura.
Essas métricas são uma “caixa-preta” no sentido de que elas não requerem qualquer conhecimento do funcionamento interno de um determinado componente de software.
Card e Glass [Car90] definem três medidas de complexidade de projeto de software:
Complexidade estrutural:
Para arquiteturas hierárquicas (por exemplo, arquiteturas de chamada e retorno), a complexidade estrutural de um módulo i é definida da seguinte maneira:
Complexidade de dados
A complexidade dos dados (data complexity) proporciona uma indicação da complexidade na interface Interna para um módulo i e é definida como:
Em que v(i) é o número de variáveis de entrada e saída passadas para o do módulo i.
Complexidade do sistema
Por fim, a complexidade de sistema (system complexity) é definida como a soma da complexidade estrutural e de dados, especificada como:
Atenção
À medida que esses valores de complexidade aumentam, a complexidade global da arquitetura do sistema também aumenta.
Isso leva a uma maior probabilidade de que o trabalho de integração e teste também aumente.
Métricas de projeto da arquitetura
Fenton [Fen91] sugere um conjunto de métricas de morfologia simples (isto é, forma) que permite que diferentes arquiteturas de programa sejam comparadas usando uma série de dimensões diretas. Referindo-se à arquitetura de chamada e retorno na Figura apresentada, podem ser definidas as seguintes métricas:
Para a arquitetura mostrada na Figura:
Tamanho = 19 + 24 = 43
Profundidade = caminho mais longo desde o nó raiz (topo) até o nó da folha. Logo, a profundidade = 5
Largura = número máximo de nós em qualquer nível da arquitetura.
Logo, largura = 7
A relação arco para nó,
r = a/n
mede a densidade de conectividade da arquitetura:
r= 24/19 = 1,26.
em que n é o número de nós e a é o número de arcos.
Indicadores de qualidade de software
A força aérea americana (U.S. Air Force Systems Command) desenvolveu um conjunto de indicadores de qualidade de software baseados nas características de projeto mensuráveis de um programa de computador. Usando conceitos similares àqueles propostos na norma IEEE Std. 982.1-1988, a Força Aérea usa informação obtida do projeto de dados e arquitetural para criar um índice de qualidade da estrutura do projeto (design structure quality index - DSQI) que varia de 0 a 1.
 Os seguintes valores devem ser apurados para calcular o DSQI:
S1 Número total de módulos definidos na arquitetura do programa.
S2 Número de módulos cuja função correta depende da origem dos dados de entrada ou que produzem dados para serem usados em outro lugar (em geral, módulos de controle, entre outros, não seriam contados como parte de S2).
S3 Número de módulos cuja função correta depende de processamento anterior.
S4 Número de itens de base de dados (inclui objetos dados e iodos os atributos que definem objetos).
S5 Número total de itens únicos de base de dados.
S6 Número de segmentos de base de dados (diferentes registros ou objetos individuais).
S7 Número de módulos com uma única entrada e saída (processamento de exceção não é considerado múltipla saída).
Indicadores de qualidade de software
Uma vez determinados os valores S1 até S7, para um programas de computador podem ser calculados os seguintes valores intermediários:
Métricas para projeto orientado a objeto
	
Há muita coisa sobre projeto orientado a objeto que é subjetivo - um projetista experiente “sabe” como caracterizar um sistema orientado a objeto de maneira que implemente efetivamente os requisitos do cliente.
Mas, à medida que um modelo de projeto orientado a objeto cresce em tamanho e complexidade, uma visão mais objetiva das características do projeto pode favorecer tanto o projetista experiente (que obtém uma visão adicional) quanto o novato (que obtém uma indicação da qualidade que de outra forma não estaria disponível).to2
Em um tratamento detalhado de métricas de software para sistemas orientados a objeto, Whitmire descreve nove características distintas e mensuráveis de um projeto orientado a objeto:
1.Tamanho. É definido em termos de quatro visualizações: população, volume, comprimento e funcionalidade. População é medida tomando-se uma contagem estática das entidades orientadas a objeto, como classes ou operações. Medidas de volume são idênticas às medidas de população, mas são coletadas dinamicamente - em determinado instante do tempo. Comprimento é a medida de uma cadeia de elementos de projeto interconectados (por exemplo, a extensão de uma árvore de herança é uma medida do comprimento). As métricas de funcionalidade proporcionam uma indicação indireta do valor fornecido ao cliente por uma aplicação orientada a objeto.
2. Complexidade. Assim como o tamanho, há muitas visões diferentes da complexidade do software. Whitmire vê a complexidade em termos de características estruturais examinando como as classes de um projeto orientado a objeto se inter-relacionam.
3. Acoplamento. As conexões físicas entre elementos do projeto orientado a objeto (por exemplo, o número de colaborações entre classes ou o número de mensagens passadas entre objetos) representam o acoplamento em um sistema orientado a objeto.
4. Suficiência. Whitmire define suficiência como “ograu com o qual uma abstração possui as características requeridas para ela, ou o grau com o qual um componente de projeto possui características em sua abstração, do ponto de vista da aplicação corrente”. Em outras palavras, perguntamos: “Que propriedades essa abstração (classe) precisa ter para ser útil para mim?”. Essencialmente, um componente de projeto (por exemplo, uma classe) é suficiente se refletir totalmente todas as propriedades do objeto de domínio da aplicação que está modelando - isto é, que a abstração (classe) possui as características necessárias para ele.
5. Totalidade. A única diferença entre totalidade e suficiência é “o conjunto de características em relação às quais comparamos a abstração ou o componente de projeto”. A suficiência compara a abstração do ponto de vista da aplicação corrente. A totalidade considera múltiplos pontos de vista, formulando a pergunta: “Que propriedades são necessárias para representar completamente o objeto de domínio do problema?”. Em virtude do critério da totalidade considerar diferentes pontos de vista, ele tem uma implicação indireta no grau com o qual a abstração ou o componente de projeto pode ser reutilizado.
6. Coesão. Assim como seu correspondente no software convencional, um componente orientado a objeto deverá ser projetado de maneira que tenha todas as operações funcionando em conjunto para atingir um objetivo único e bem definido. A coerência de uma classe é determinada examinando-se o grau segundo o qual “o conjunto de propriedades que ela possui faz parte do domínio do problema ou projeto”.
7. Originalidade. Uma característica similar à simplicidade, originalidade (aplicada tanto a operações quanto a classes) é o grau segundo o qual uma operação é atômica - isto é, a operação não pode ser construída por meio de uma sequência de outras operações contidas dentro de uma classe que apresenta um alto grau de originalidade e encapsula apenas operações primitivas.
8. Similaridade. O grau segundo o qual duas ou mais classes são similares em termos de sua estrutura, função, comportamento ou finalidade é indicado por essa medição.
9. Volatilidade. Conforme já afirmamos multas vezes neste livro, podem ocorrer alterações de projeto quando os requisitos são modificados ou quando acontecem modificações em outras partes de um aplicativo, resultando em adaptação obrigatória do componente de projeto em questão. A volatilidade de um componente orientado a objeto mede a possibilidade de que uma alteração venha a ocorrer.
Métricas orientadas a classe — o conjunto de métricas CK
O que é classe?
A classe é a unidade fundamental de um sistema orientado a objeto. Portanto, medidas e métricas para uma classe individual para a hierarquia da classe e colaborações entre classes serão valiosas quando tivermos de avaliar qualidade de projeto orientado a objeto.
Uma classe encapsula dados e a função manipula os dados. Com frequência é o “pai” das subclasses (às vezes chamadas de filhas) que herda seus atributos e operações. Muitas vezes elas colaboram com outras classes. Cada uma dessas características pode ser usada como base para a medida.
Chidamber e Kemerer propuseram um dos conjuntos mais amplamente conhecidos de métricas de software orientado a objeto. Também chamado de conjunto de métricas CK (CK metrics suite), os autores propuseram seis métricas de projeto baseado em classe para sistemas orientados a objeto. Vejamos uma delas:
Métodos ponderados por classe (weighted methods per class - WMC).
Suponha que n métodos de complexidade c1,c2 ,..., cn são definidos para uma classe C. A métrica especifica de complexidade escolhida (por exemplo, complexidade ciclomática) deverá ser normalizada de maneira que a complexidade nominal para um método assuma o valor 1,0.
WMC = c1
Para i = 1 a n. O número de métodos e sua complexidade são indicadores razoáveis do trabalho necessário para implementar e testar uma classe.
Atenção
Quanto maior for o número de métodos, mais complexa será a árvore de herança (todas as subclasses herdam os métodos de seus pais). Por fim, conforme o número de métodos cresce para uma dada classe, ela tende a se tornar cada vez mais específica de aplicação, limitando assim sua potencial reutilização. Por todas essas razões, o WMC deverá ser mantido o mais baixo possível.
Embora pudesse parecer relativamente fácil desenvolver uma contagem para o número de métodos em uma classe, o problema é na realidade mais complexo do que parece. Deverá ser desenvolvida uma abordagem consistente de contagem.
O que é COCOMO?
COnstructive COst MOdel (COCOMO) é um algorítmico modelo de estimativa do custo do software criado por Barry Boehm.
O modelo usa uma fórmula básica de regressão, com parâmetros que são derivados dos dados históricos e das características atuais dos projetos.
O método COCOMO é um modelo de estimativa do tempo de desenvolvimento de um software e está baseado no estudo de 63 projetos, dos quais foram examinados de 2.000 a 100.000 linhas de código em linguagens de programação Assembly.
O COCOMO consiste em três implementações: básico, intermediário e avançado. Avance a tela e compreenda cada uma delas.
COCOMO básico
COCOMO básico é um modelo estático que calcula o esforço de desenvolvimento de software e seu custo em função do tamanho de linhas de códigos desenvolvidas. Aplica-se às seguintes classes de projetos do software:
Orgânicos: são projetos relativamente pequenos, simples e com pouca inovação, com equipes de dimensão relativamente pequena. Exemplo: mala direta.
Semidestacado ou difuso (em tamanho e complexidade): são projetos intermediários com características entre o modo orgânico e o embutido, em que as equipes de trabalho são heterogêneas em termo de experiência, como, por exemplo, um sistema de processamento de transações (folha de pagamento).
Embutido ou restrito: aplicável no desenvolvimento de sistemas complexos embutidos em hardware, com muitas inovações, restrições severas e/ou requisitos muito voláteis e de confinamentos operacionais; exemplo: sistema de controle de telefonia.
Exemplos de COCOMO básico
Uma vantagem do COCOMO básico é a sua rapidez em estimativas de custo de software; porém, sua exatidão é limitada devido à falta de fatores para explicar as diferenças entre:
• Ferramentas;
• Qualidade de pessoal e experiência;
• Uso de ferramentas modernas e técnicas;
• Outros atributos de projeto que influenciam nos custos de software.
COCOMO intermediário
O método intermediário é uma extensão do método básico, porém, com mais categorias de controle, como: atributos do produto; atributos de hardware; atributos pessoais; atributos do projeto.
Atributos do produto
I – Confiabilidade exigida do software;
II – Tamanho do banco de dados;
III – Complexidade do software.
Atributos do hardware
I – Restrições de desempenho de run-time;
II - Restrições de memória;
III – Mudanças do ambiente de software;
IV – Tempo de resposta.
Atributos pessoais 
I – Restrições de desempenho de run-time;
II - Restrições de memória;
III – Mudanças do ambiente de software;
IV – Tempo de resposta.
Atributos do projeto
I – Uso de ferramenta de software;
II – Técnicas modernas de programação;
III – Prazo requerido para o desenvolvimento.
COCOMO avançado
No COCOMO avançado, são incorporadas características da versão intermediária com uma avaliação de impacto de custo em cada passo do projeto.
Nele, pode ser empregado software interativo auxiliar para a estimativa de custos e prazos. A partir de um conjunto de atributos, premissas e modos de desenvolvimento, o COCOMO estima os prazos, custos e recursos necessários para cada etapa do ciclo de vida do produto.
COCOMO avançado: Spider-CoCoMo
É uma ferramenta oriunda das pesquisas do projeto SPIDER da Universidade Federal do Pará (OLIVEIRA, 2010).
Esse projeto tem como objetivo a construção de uma suíte de ferramentas livrespara dar suporte à implementação do modelo de qualidade MPS.BR – Melhoria de Processo de Software Brasileiro (SOFTEX, 2009).
Sua concepção ocorreu pela necessidade de uma forma sistematizada e simples para realizar estimativas de projetos de software, pois a maioria das empresas utilizam planilhas eletrônicas e, com elas, não é possível atender completamente às necessidades dos gerentes, tendo em vista que não é possível obter uma base histórica dos valores estimados nos projetos da organização.
O MPS.BR (SOFTEX, 2009) é um programa que busca avaliar processos de desenvolvimento de software por meio de um conjunto de boas práticas. Esse modelo se divide em sete níveis de maturidade, partindo do nível G, o mais baixo, até o nível A, o mais alto. À medida que se passa de um nível para o outro, o processo é entendido como mais maduro; cada nível possui um conjunto de atividades, denominados processos. Por fim, cada processo contido em um nível possui resultados esperados, que indicam que um determinado item do processo em questão foi alcançado. A avaliação se dá pela análise de cada resultado esperado dos processos.
A Spider-CoCoMo está inserida no contexto do processo Gerência de Projetos, auxiliando nas estimativas de custo, prazos e número de pessoas. A ferramenta está indiretamente ligada com o resultado esperado do GPR 2 e diretamente ligada com o GPR 4, dois dos resultados esperados desse processo.
GPR 2
Visa garantir que tarefas e produtos de trabalho sejam dimensionados por meio de métodos apropriados. A ferramenta necessita que o resultado esperado seja cumprido, pois ele serve de parâmetro para o cálculo do CoCoMo. Em particular para esse resultado esperado, o projeto SPIDER possui duas ferramentas para medir o tamanho de projeto baseado no método de análise de pontos por função e pontos por casos de uso, que são a Spider-APF e a Spider-UCP (BALDEZ, 2010).
Caso seja adotado qualquer outro tipo de método que não os citados anteriormente, o valor pode ser inserido manualmente na Spider-CoCoMo sem que haja perda nos resultados estimados.
GPR 4
Requer que o esforço e os custos sejam estimados. Esse resultado esperado é totalmente atendido com a utilização da Spider-CoCoMo tanto nos níveis G e F, tendo em vista que o método CoCoMo é utilizado para estimativas, como dito anteriormente, como nos níveis superiores ao F, pois os valores estimados são armazenados em banco de dados, sendo feito um histórico deles. Esse é o grande diferencial da Spider-CoCoMo sobre as planilhas eletrônicas.
COCOMO II
O COCOMO II (segunda versão do COCOMO – COnstructive COst MOdel) é um modelo objetivo de custos para o planejamento e execução de projetos de software. Um modelo de custos fornece estrutura (framework) para a comunicação de decisões de negócio entre os envolvidos em um empreendimento baseado em software.
Além disso, oferece suporte a negociações contratuais, análises de melhoria de processo, aquisição de ferramentas, alterações na arquitetura, decisões entre desenvolvimento e aquisição de componentes, assim como diversas outras decisões sobre retorno do investimento, servindo de base a estimativas plenas de credibilidade.
Embora a maioria das organizações inicie o processo de estimativa utilizando modelos lineares simples, o amadurecimento do processo de software leva à utilização de modelos mais sofisticados, capazes de melhor descrever os fatores que influenciam os projetos de software.
O COCOMO II é uma excelente escolha nesse sentido. Desenvolvido em uma universidade e fortemente apoiado pela indústria, oferece uma solução aberta, escalável e respeitada.
• O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um componente individual;
• O COCOMO pode calcular a programação da manutenção anual;
• O COCOMO pode examinar a vantagem de dados históricos e, com essas informações, criar uma constante da calibração que pode ser calculada para estimativas futuras.
Imprecisão: sua precisão pode ser prejudicada no início do projeto, pois o modelo depende fortemente de uma estimativa precisa da quantidade de linhas.
Método de Putnam
O método de Putnam considera múltiplas variáveis e o ciclo de desenvolvimento do projeto.
Com base em análise estatística, Putnam relacionou os comportamentos prazo e esforço.
Complexidade ciclomática
O que é?
Em 1976, McCabe criou uma maneira de testar cada caminho independente de um programa, de forma que a quantidade de casos de teste será a complexidade ciclomática do programa.
Complexidade ciclomática ou complexidade condicional é uma métrica usada para indicar a complexidade do software; mede a quantidade de caminhos de execução independentes a partir do código fonte.
Como é  calculada?
É calculada a partir de um grafo de fluxo: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta conecta dois nós.
Em que pode ser aplicada
A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa.
V(G) = E – N + 2P
Para:
E = 8 P = 1
N = 7
V(G) = 8 – 7 + 2 = 3
V(G) = 3
V(G): Complexidade ciclomática;
G: Grafo (fluxograma);
E: Número de bordas (ligações);
N: Número de nós (instruções);
P: Número de componentes conectados ao gráfico (assumimos P = 1).
Conclusões
• Não existe um modelo único;
• Deve-se desenvolver o modelo mais adequado à empresa;
• O modelo deve ser periodicamente revisto;
• Deve-se validar por mais de um método;
• É um aspecto estratégico para a empresa.