Metricas de Software PDF

Apresentação
.............................................................................................................................Erro!
Indicador não definido.
Aula 1: Fundamentos de métricas e medidas ............................................................................
Erro! Indicador não definido.
Introdução ................................................................................Erro! Indicador não definido.
Conteúdo................................................................................................................................ 7
Métricas para Software ..................................................................................................... 7
Por que devemos medir? ................................................................................................. 9
Quais são as etapas envolvidas? ..................................................................................... 9
Como garantir que o trabalho seja realizado corretamente? ................................... 9
Avaliação dos atributos internos do produto............................................................. 10
Qualidade de Software ................................................................................................... 10
Custo do reparo ............................................................................................................... 11
Curva de falhas para hardware ou curva da banheira ............................................. 11
Garantia de qualidade ..................................................................................................... 12
Fatores determinantes para a garantia da qualidade ............................................... 12
Fatores de qualidade de McCall .................................................................................... 13
Características operacionais .......................................................................................... 13
Características de manutenção .................................................................................... 14
Características de adaptação a novos ambientes ..................................................... 14
Fatores de Qualidade ISO 9126 ..................................................................................... 15
Métricas de indicadores e de produto ......................................................................... 15
Controle do software ...................................................................................................... 16
O produto e o processo em relação à medição ........................................................ 17
As estimativas mais importantes .................................................................................. 17
Métricas do processo ...................................................................................................... 17
Métricas do produto ........................................................................................................ 18
Métricas diretas e métricas indiretas............................................................................ 19
Métricas orientadas ao tamanho .................................................................................. 19
Métricas orientadas à função ........................................................................................ 20
Princípios de medição .................................................................................................... 20
Atributos de métricas eficazes de software................................................................ 20
Atividade Proposta........................................................................................................... 22
MÉTRICAS DE SOFTWARE 1
Referências........................................................................................................................... 22
Exercícios de fixação ......................................................................................................... 22
Aula 2: Pontos por Função ......................................................................................................... 30
Introdução ........................................................................................................................... 30
Conteúdo.............................................................................................................................. 31
Métricas baseadas em função ou Pontos por Função (PF)...................................... 31
Valores do domínio de informações ........................................................................... 31
Valores do domínio de informações – Tabela de PF................................................ 32
Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA) ........................ 33
Exemplo de Diagrama de Fluxo de Dados (DFD) simples ........................................ 36
Cálculo dos Pontos por Função .................................................................................... 38
Método para estimativa de custo – exemplo SERPRO ............................................. 38
Contagem de Pontos por Função de Projetos de Manutenção ............................. 40
Pontos de Casos de Uso (PCU) ..................................................................................... 40
Calculando o peso dos Atores do Sistema ................................................................. 41
Aprenda Mais....................................................................................................................... 42
Referências........................................................................................................................... 42
Aula 3: Determinação de Ponto por Função .............................................................................. 49

Introdução ........................................................................................................................... 49
Conteúdo.............................................................................................................................. 50
Contextualização ............................................................................................................. 50
Fan-out e Fan-in .............................................................................................................. 51
Fan-out e Fan-in: características .................................................................................. 51
Métricas de projeto da arquitetura ............................................................................... 53
Indicadores de qualidade de software ........................................................................ 55
Métricas para projeto orientado a objeto ................................................................... 57
Métricas orientadas a classe — o conjunto de métricas CK .................................... 59
Referências........................................................................................................................... 61
Aula 4: Estimativa de esforço e prazo ....................................................................................... 68

Introdução ........................................................................................................................... 68
Conteúdo.............................................................................................................................. 69
COCOMO .......................................................................................................................... 69
COCOMO básico.............................................................................................................. 69
Exemplos de COCOMO básico ..................................................................................... 70
COCOMO intermediário ................................................................................................. 73
COCOMO avançado........................................................................................................ 76
COCOMO avançado: Spider-CoCoMo ........................................................................ 76
COCOMO II ....................................................................................................................... 78
Método de Putnam.......................................................................................................... 79
Complexidade ciclomática ............................................................................................ 79
Complexidade ciclomática ............................................................................................ 80
Conclusões........................................................................................................................ 81
Referências........................................................................................................................... 81
Conteudista ...........................................................................................................................88
Qualquer empresa nasce com o sonho de ser bem-sucedida, mas nem todas
são vencedoras, e algumas até morrem antes de completar seu primeiro ano.
Empresas de sucesso são aquelas que trabalham com foco na gestão da
qualidade e do conhecimento.
No caso de PROJETO, verificamos que o gerenciamento é necessário, mas não

podemos gerenciar aquilo que é impossível medir.
A gestão do desenvolvimento, da manutenção e da prestação de serviços

relacionados ao software – que envolve custo, prazo e qualidade – passou,
então, a ser relevante. Afinal, esses fatores se constituem, hoje, como o
diferencial entre as empresas.
Plataformas como ITIL, CMMI e MPS-BR colocam as métricas e as medições

como práticas fundamentais para a gestão de software com padrão de
qualidade – o que tornou sua medição uma obrigação.
Nesse sentido, esta disciplina pretende desenvolver no profissional da área a

visão gerencial baseada na preocupação com o custo, a produtividade, a
qualidade e novas métricas, bem como com suas formas de medição e suas
limitações.
É muito importante que você conheça as técnicas de gerenciamento de projeto
de software e saiba estabelecer parâmetros para futuras medições.
Sendo assim, esta disciplina tem como objetivos:

1. Definir medida e métrica de software;
2. Identificar as formas de medição, de estimativa e de acompanhamento de
um projeto de software, bem como os parâmetros para futuros projetos;
3. Descrever as métricas mais usuais para fins de medição do esforço no
desenvolvimento de um software.
Introdução
Você terá oportunidade de desenvolver os Conceitos de métricas e medições
para software, medidas diretas e indiretas, medidas no software pronto (kloc).
Toda empresa já nasce com o “sonho de ser bem-sucedida”, porém muitas
delas nem chegam a completar seu primeiro ano. Empresas de sucesso são
aquelas que estão trabalhando com foco na gestão da qualidade e do
conhecimento. No entanto, não se pode gerenciar o que não se pode medir.
Assim, plataformas como ITIL, CMMI, MPS-BR e outras, colocam as métricas e
medições como práticas fundamentais para a gestão de software com padrão
de qualidade.
A qualidade tornou a medição do software nos seus diversos aspectos uma

obrigação. Deve-se desenvolver no profissional de software a visão gerencial,
assim como a preocupação com custo, produtividade, qualidade e novas
métricas, suas formas de medição e suas limitações. Ele deve conhecer
conceitos para medir o software (produtividade, qualidade, prazo, tamanho
etc.) desde a fase de especificação de requisitos. Para tal, deve conhecer
técnicas e ferramentas em suas medidas nas diversas fases do projeto.
Preparado para iniciar a aula? Bons estudos!
Objetivo:
1. Compreender os conceitos das métricas e das medições de software;
2. Entender o que envolve a qualidade de software.
Conteúdo
Métricas para Software
Então, o próprio mercado exige, hoje, a gestão da qualidade, do conhecimento
e sabe-se que não se pode gerenciar o que não se pode medir. No entanto,
como medir valores como o conhecimento ou a qualidade?
Sabemos que todo processo de engenharia necessita de medições para

entender melhor os modelos e avaliar a quantidade dos produtos construídos.
No caso da engenharia de software – que não é fundamentada nas medidas
quantitativas diretas, como voltagem, temperatura, velocidade – as suas
medidas e métricas são na sua maioria indiretas.
Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos

às características de uma entidade qualquer, definidos de acordo com regras
bem definidas. Na ciência da computação, podemos medir os atributos, antes
considerados incomensuráveis – ainda que alguns especialistas em software
continuem a argumentar que o software é “incomensurável”.
O que é métrica?
Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de
produto ajuda os engenheiros de software a visualizar o projeto e a construção
do software, focalizando atributos específicos e mensuráveis dos artefatos da
engenharia de software.
Quem realiza?
Os engenheiros de software usam métricas de produto para ajudá-los a criar
software da mais alta qualidade.
Haverá sempre um elemento qualitativo na criação de software. O problema é

que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários
critérios objetivos para ajudar a direcionar o projeto de dados,
arquitetura, interfaces e componentes. Ao testar, necessitamos de
orientação quantitativa que nos auxiliará na seleção de casos de teste
e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise,

projeto, codificação e teste podem ser conduzidos mais objetivamente e
avaliados de maneira mais quantitativa.
Haverá sempre um elemento qualitativo na criação de software. O problema é

que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários
critérios objetivos para ajudar a direcionar o projeto de dados,
arquitetura, interfaces e componentes. Ao testar, necessitamos de
orientação quantitativa que nos auxiliará na seleção de casos de teste
e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise,

projeto, codificação e teste podem ser conduzidos mais objetivamente e
avaliados de maneira mais quantitativa.
Atenção
Haverá sempre um elemento qualitativo na criação de software.
O problema é que a avaliação qualitativa pode não ser
suficiente. Fazem-se necessários critérios objetivos para
ajudar a direcionar o projeto de dados, arquitetura,
interfaces e componentes. Ao testar, necessitamos de
orientação quantitativa que nos auxiliará na seleção de
casos de teste e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a
análise, projeto, codificação e teste podem ser conduzidos mais
objetivamente e avaliados de maneira mais quantitativa.
Por que devemos medir?
• Para sabermos quanto cobrar;
• Para conseguirmos dar prazos;
• Para definirmos a equipe;
• Para definirmos complexidade;
• Para definirmos tamanho;
• Para medirmos risco.
Quais são as etapas envolvidas?

O primeiro passo no processo de medição é definir as métricas apropriadas
para o software.
Em seguida, coletam-se os dados necessários para aplicar as métricas

formuladas.
Uma vez computadas, as métricas são analisadas com base em diretrizes

preestabelecidas e dados do passado.
Os resultados das análises são interpretados para obter informações

sobre a qualidade do software.
Os dados da interpretação levam à modificação dos requisitos e modelos

de projeto, código-fonte ou casos de teste.
Qual é o artefato (produto)?

O produto, no caso, são as métricas computadas por meio de dados
coletados dos requisitos e modelos de projeto, código-fonte e casos
de teste.
Como garantir que o trabalho seja realizado corretamente?

Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo
cada métrica de produto de maneira não ambígua. Defina apenas algumas
métricas e, então, use-as para obter informações sobre a qualidade do artefato
de software.
Embora as métricas de produto para software sejam imperfeitas, podem

proporcionar uma maneira sistemática de avaliar a qualidade com base em um
conjunto de regras claramente definidas. Elas também proporcionam uma visão
objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e
corrigir problemas potenciais antes que se tomem defeitos catastróficos.
Avaliação dos atributos internos do produto

A seguir, veremos algumas medidas que podem ser usadas para avaliar a
qualidade do produto enquanto ele está sendo projetado.
Essas medidas de atributos internos do produto fornecem uma indicação em

tempo real da eficácia dos modelos de requisitos, projeto e código, da
eficácia dos casos de teste e da qualidade geral do software que será
criado.
Qualidade de Software
O desenvolvimento de sistemas de software envolve uma série de atividades
em que as oportunidades de falhas são muito grandes.
Os erros podem aparecer no início do processo devido a alguns fatores:

• Objetivos mal definidos;
• Erros em fases de projeto e desenvolvimento.
Ninguém tolera erros, por isso o desenvolvimento de software tem que ter
garantia de qualidade.
A atividade de teste de software é um elemento crítico da garantia de qualidade

de software e representa a última revisão de especificação, projeto e
codificação.
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:
 Métodos e ferramentas de análise, projeto, codificação e teste;

 Revisões técnicas em cada fase do desenvolvimento;
 Estratégia de teste;
 Documentação de software e das mudanças efetuadas;
 Padrões de desenvolvimento de software;
 Mecanismos de medição.
Fatores determinantes para a garantia da qualidade

Os requisitos de software são a base a partir da qual a qualidade é medida.
A falta de conformidade aos requisitos significa falta de qualidade.
Padrões especificados definem um conjunto de critérios de desenvolvimento

que orientam a maneira segundo a qual o software passa pelo trabalho de
engenharia. Se os critérios não forem seguidos, o resultado quase que
seguramente será a falta de qualidade.
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 do software
É impossível controlar um software sem medições e feedback. Não se pode
controlar o que não se pode medir e a extensão do controle depende da
precisão da medição. Qualquer coisa que não se pode medir está fora de
controle.
As medições e métricas ajudam a entender o processo usado para se

desenvolver um produto de software e o próprio produto.
O produto e o processo em relação à medição
Produto é medido para avaliar a sua qualidade e processo é medido para
melhorá-lo. Para efetivar a medição é necessário ter em mãos documentação
de efeitos passados e dados estatísticos de quantificação de efeitos futuros.
A medição e a inferência estatística são usadas em várias áreas para projetar

o desempenho futuro.
A medição pode levar a controvérsias e discussões como:

• Que métricas usar?
• Como os dados compilados devem ser usados?
• É justo usar medições para se comparar pessoas, processos e produtos?
As estimativas mais importantes

A estimativa é uma das principais atividades do planejamento de software:
 Esforço humano exigido

 Duração do projeto
 Custo
Métricas são frequentemente classificadas como métricas do processo ou

métricas do produto, e são aplicadas durante o processo de desenvolvimento
ou ao produto de software desenvolvido.
Métricas do processo
As métricas do processo quantificam atributos do processo de desenvolvimento
e do ambiente de desenvolvimento.
Métricas de recursos: experiência do programador, custo de

desenvolvimento e manutenção.
Métricas para o nível de experiência do pessoal: número de anos que
uma equipe está usando uma linguagem de programação; número de anos que
um programador está na organização.
Outros fatores relacionados ao desenvolvimento incluem:

• Técnicas de desenvolvimento;
• Auxílio para programação;
• Técnicas de supervisão etc.
Métricas do produto
São medidas do produto de software. Podem não revelar nada sobre como o
software foi desenvolvido.
Incluem:
 O tamanho do produto (linhas de código);
 A complexidade da estrutura lógica (recursão – for, while, repeat, fluxo
de controle – ordem das instruções do programa – e profundidade de
laços aninhados);
 A complexidade da estrutura de dados;
 Funções (tais como tipo de software: comercial, científico etc.).
Atenção
Nesse caso, é importante que você conheça um exemplo:
O número de defeitos descobertos durante o teste formal
depende do produto (número de segmentos de código que estão
errados) e do processo usado na fase de teste (a extensão do
teste).
Métricas diretas e métricas indiretas
Medidas Diretas do Processo de Software:
Custo e esforço aplicados.
Medidas Diretas do Produto:

Número de linhas de código produzidas (KLOC - Kilo Lines of Code ou
simplesmente “mil linhas de código”); Velocidade de execução; Tamanho de
memória; Número de defeitos registrados em um tempo qualquer.
Medidas Indiretas do Produto:

 Qualidade;
 Funcionalidade;
 Complexidade;
 Eficiência;
 Confiabilidade;
 Manutenibilidade.
Métricas orientadas ao tamanho

Linhas de Código (KLOC): uma linha de código é qualquer linha do texto de um
programa, exceto comentários e linhas em branco, sem levar em conta o
número de comandos ou fragmentos de comandos em uma linha. Estão
incluídas na definição de linhas de código todas as linhas que contém cabeçalho
do programa, declarações e comandos executáveis.
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.
 Planejamento
 Análise
 Design
 Programação
A seguir estão elencados os atributos que devem ser considerados pelas

métricas – segundo Pressman (Engenharia de Software):
 Simples e computáveis – Deverá ser relativamente fácil aprender a

derivar a métrica, e sua computação não deve demandar esforço ou
tempo fora do normal.
 Empiricamente e intuitivamente persuasiva – A métrica deverá satisfazer
as ideias do engenheiro de software.
 Consistente e objetiva – A métrica deverá sempre produzir resultados
que não sejam ambíguos. Um terceiro independente deverá ser capaz de
derivar o mesmo valor da métrica usando as mesmas Informações sobre
o software.
 Consistente no seu uso das unidades e dimensões – A computação
matemática da métrica deverá usar medidas que não resultem em
combinações bizarras de unidades. Por exemplo, multiplicar número de
pessoas nas equipes de projeto pelas variáveis da linguagem de
programação no programa resulta em uma mistura duvidosa de
unidades que não é claramente convincente.
 Independente da linguagem de programação – As métricas deverão ser
baseadas no modelo de requisitos, modelo de projeto ou na própria
estrutura do programa. Elas deverão ser independentes dos caprichos da
sintaxe ou semânticas das linguagens de programação.
 Um mecanismo efetivo para feedback de alta qualidade – A métrica
deverá fornecer informações que podem levar a um produto final de
melhor qualidade.
Atividade Proposta
Discuta sobre a importância da adoção de métricas no processo de qualidade
de software.
Chave de resposta: O processo de desenvolvimento de software deve ter o

foco na qualidade.
Referências
PRESSMAN, Roger S. Engenharia de Software. 7. ed. Mc Graw Hill,2011.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Mc Graw Hill, 2007.
PADUA Filho, Wilson de. Engenharia de Software: Fundamentos, métodos e
padrões, 3. ed. Rio de Janeiro: Editora LTC, 2009.
Bibliografia Complementar:
PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.
VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função
medição, estimativa e gerenciamento de projetos de software. São
Paulo: Editora Érica, 2009.
Exercícios de fixação
Questão 1
Segundo Pressman, “Qualidade de software é a satisfação de requisitos
funcionais e de desempenho explicitamente declarados, normas de
desenvolvimento explicitamente documentadas e características implícitas que
são esperadas em todo software desenvolvido profissionalmente”. Analise as
afirmativas a seguir, relacionadas a software:
I. Falta de conformidade com os requisitos é falta de qualidade;
II. Os fatores de qualidade de Mc Call estão relacionados com operação, revisão
e transição de software;
III. Portabilidade – Facilidade com que o software pode ser transposto de um
ambiente para outro.
Agora assinale a alternativa correta:
a) Todas as afirmativas estão corretas
b) Apenas a afirmativa III está correta
c) Apenas a afirmativa II está correta
d) Apenas as afirmativas I e III estão corretas
e) Apenas as afirmativas II e III estão corretas
Questão 2
A avaliação qualitativa não é suficiente para medir o esforço do software. É
preciso critérios objetivos para direcionar o projeto de dados, arquitetura,
interfaces e componentes. Ao testarmos, necessitamos de orientação
quantitativa que nos auxiliará na seleção de casos de teste. A métrica de
produto proporciona uma base por meio da qual a análise, projeto, codificação
e teste podem ser conduzidos mais objetivamente e avaliados de maneira
quantitativa. Sendo assim, devemos medir:
I. Para sabermos quanto cobrar.
II. Para conseguirmos dar prazos;
III. Para definirmos a equipe;
IV. Para definirmos a complexidade;
V. Para definirmos o tamanho.
b) Estão corretas apenas as afirmativas I, III e IV
c) Estão corretas apenas as afirmativas I, II, III e V
d) Estão corretas apenas as afirmativas I, II, III e IV
e) Estão corretas apenas as afirmativas II, III, IV e V
Questão 3
Ninguém tolera erros, por isso o desenvolvimento de software tem que ter
garantia de qualidade. Ele envolve uma série de atividades em que as
oportunidades de falhas são muito grandes e, consequentemente, os erros
podem aparecer no início do processo. Isso se deve a alguns fatores, exceto
(assinale a alternativa INCORRETA):
a) Bom planejamento de teste
b) Objetivos mal definidos
c) Erros na fase de projeto
d) Planejamento malfeito
e) Requisitos mal definidos
Questão 4
A garantia de qualidade de software (Software Quality Assurance) não é algo
com a qual começamos a nos preocupar depois que o código foi gerado, e sim
ao longo de todo o processo de engenharia de software. A SQA abrange,
exceto (assinale a alternativa INCORRETA):
a) Dispensa de documentação de software e das mudanças efetuadas
b) Métodos e ferramentas de análise, projeto, codificação e teste
c) Estratégia de teste
d) Padrões de desenvolvimento de software
e) Mecanismos de medição
Questão 5
Segundo Roger Pressman, o gerenciamento de testes é um processo
fundamental para obter qualidade no software. Analise as afirmativas:
I. “O teste é o último reduto no qual a qualidade pode ser avaliada”;
II. “Você não pode testar qualidade. Se ela não estiver lá antes, ela não estará
lá quando terminar de testar”;
III. “Otimismo é o risco ocupacional da programação; teste é o tratamento”;
IV. “A qualidade de um software é função de quanto ele muda o mundo para
melhor”.
b) Estão corretas apenas as afirmativas I, III e IV
c) Estão corretas apenas as afirmativas I, II e III
d) Estão corretas apenas as afirmativas I, II e IV
e) Estão corretas apenas as afirmativas II, III e IV
Questão 6
Assinale a alternativa correta:
a) Na engenharia de software não existe diferença entre medição e medida.
b) Considerando o tempo de existência, a engenharia de software e a
engenharia civil se equivalem em maturidade.
c) Uma métrica mal especificada não gera qualquer influência para tomada
de decisão de baixa qualidade.
d) pesar de existirem métricas de processo e de projeto, não existem
métricas de produto.
e) Medida é diferente de métrica e pode ser realizada de forma direta ou
indireta.
Questão 7
No contexto de engenhada de software, medida pode ser definida como:
a) O ato de determinar uma medida.
b) Proporciona uma indicação quantitativa da extensão, quantidade,
capacidade ou tamanho de algum produto ou processo.
c) É um conceito matemático relacionado à distância de um módulo ao
seguinte.
d) É a divisão de um software em fragmentos marcados por tempo e custo.
e) É um conceito relacionado à gerência de projetos.
Questão 8
O processo de desenvolvimento de software deve ser continuamente medido
durante seu desenvolvimento. Para isso é necessário:
I. Criar uma “cultura” de medição e métrica (desenvolvimento com bases
técnicas);
II. Catalogar em base de dados históricos;
III. Padronizando em metros ou centímetros, cada medida obtida.
a) Completam o enunciado as afirmativas I e II
b) Completam o enunciado as afirmativas I e III
c) Completam o enunciado as afirmativas II e III
d) Completa o enunciado apenas a afirmativa I
e) Completa o enunciado apenas a afirmativa II
Questão 9
Uma linha de código é qualquer linha do texto de um programa, exceto
comentários e linhas em branco, sem levar em conta o número de comandos
ou fragmentos de comandos em uma linha. São medidas em Quilo de Linhas de
Código ou mil linhas (KLOC). Estão incluídas na definição de linhas de código
todas as linhas que contêm cabeçalho do programa, declarações e comandos
executáveis. Analise as afirmativas sobre KLOC e responda:
I. É fácil de calcular;
II. É um fator importante para muitos modelos de estimativa;
III. Depende da linguagem de programação;
IV. Penalizam programas bem estruturados, porém mais curtos.
a) Estão corretas as afirmativas I, III e IV
b) Estão corretas as afirmativas I, II e III
c) Estão corretas as afirmativas I, II e IV
d) Estão corretas as afirmativas II, III e IV
e) Todas as afirmativas estão corretas.
Questão 10
A estimativa é uma das principais atividades do planejamento de software.
Métricas são frequentemente classificadas como métricas do processo ou
métricas do produto e são aplicadas durante o processo de desenvolvimento ou
ao produto de software desenvolvido. Com relação às estimativas de software
marque a afirmativa correta (forma completa):
a) Para uma aplicação existente ou nova desejamos saber quanto tempo
será necessário para o desenvolvimento e também quanto é o custo.
b) Para uma nova aplicação desejamos saber quanto tempo será necessário
para fazer.
c) Para uma aplicação existente desejamos saber quanto tempo será
necessário para fazer uma alteração.
d) Para uma aplicação existente desejamos saber qual o custo de uma
alteração.
e) Para uma nova aplicação desejamos saber qual o custo da aplicação.
Aula 1
Questão 1 - A
Justificativa: Software que não segue os requisitos não oferece qualidade; O
fatores de Mc Call são exatamente operação, revisão e transição de software; A
portabilidade é uma exigência hoje, o que permite que o software possa ser
executado em mais de um sistema operacional.
Questão 2 - A
Justificativa: Para determinarmos o esforço empregado no software devemos
medir custo, prazo, recursos físicos e pessoas, a complexidade e o tamanho.
Portanto, todas as afirmativas estão corretas.
Questão 3 - A
Justificativa: No início do desenvolvimento devemos aplicar a característica da
abstração, isto é, nos preocuparmos com o que é mais importante para o
momento como, por exemplo, a definição clara dos objetivos e dos requisitos e
a elaboração de um bom planejamento do projeto, e deixar alguns detalhes
para mais adiante. O planejamento de implantação e disponibilização do
software deve ser feito em outra etapa.
Questão 4 - A
Justificativa: Um dos requisitos da qualidade do software é a documentação.
Software sem documentação se distancia das normas de qualidade. Qualidade
de software inclui padrões de medição e uso adequado de ferramentas de
desenvolvimento, implementação e teste.
Questão 5 - A
Justificativa: Todas as afirmativas estão registradas em “Engenharia de
Software” de Roger Pressman (6ª Ed. p. 340-350).
Questão 6 - E
Justificativa: Podemos ter medidas diretas como número de linhas de código
produzidas ou velocidade de execução e medidas indiretas como qualidade,
funcionalidade, complexidade.
A opção “a” está errada, pois medição é um processo, já medida é usada para
avaliar a qualidade do produto.
A opção “b”: engenharia civil existe há milênios.
A opção “c”: métrica mal especificada afeta a qualidade do produto.
A opção “d”: Os engenheiros de software usam métricas de produto para
ajudá-los a criar software da mais alta qualidade.
Questão 7 - B
Justificativa: Medida é a quantificação de algo que se quer medir. Por exemplo:
o tamanho do software em KLOC ou pontos por função. É um conceito
matemático, porém, não para medir distância entre módulos e nem a divisão de
um software.
Questão 8 - A
Justificativa: Criar uma cultura de medição de software e registrar os dados
históricos para que possam ser utilizados em projetos futuros são contribuições
para a qualidade do software. O software jamais será medido em metros ou
centímetros.
Questão 9 - E
Justificativa: KLOC é uma métrica orientada ao tamanho e de fácil obtenção e
independente da linguagem usada. pois bastar contar o número de linhas,
exceto os comentários. Por outro lado, programas orientados a objetos e bem
estruturados são penalizados por esta métrica.
Questão 10 - A
Justificativa: Todas as afirmativas são verdadeiras, porém, a mais completa é a
que fala em tempo e custo, isto é, a opção “a”.
Introdução
Nesta aula, você compreenderá como devem ser usadas as seguintes métricas:
Pontos por Função (PF); Ponto por Função Não Ajustado (PFNA); Pontos por
Função para Diagrama de Fluxo de Dados (DFD) simples; Método para
Estimativa de Custo; Contagem de Pontos por Função de Projetos de
Manutenção; Pontos de Casos de Uso (PCU); e Peso dos Atores do Sistema.
Essa abordagem é muito importante devido à necessidade de justificar prazos e

custos do software.
Bons estudos!
Objetivo:
1. Identificar os Pontos por Função;
2. Compreender a aplicação dos Pontos por Função.
Conteúdo
Métricas baseadas em função ou Pontos por Função (PF)
Para que servem os Pontos por Função?
Pontos por Função medem o tamanho funcional do software.
Da mesma forma que somente os metros quadrados são insuficientes para

administrar uma construção, PF são insuficientes para administrar um projeto
de SW.
Para que servem as métricas Pontos por Função?
A métrica Ponto por Função pode ser usada efetivamente como um meio para
medir a funcionalidade fornecida por um sistema. Por meio de dados históricos,
a métrica FP pode ser empregada para:
 Estimar o custo necessário para projetar, codificar e testar o software;

 Prever o número de erros que serão encontrados durante o teste;
 Prever o número de componentes e/ou o número de linhas projetadas
de código-fonte no sistema implementado.
Valores do domínio de informações

A métrica Pontos por Função está baseada em medidas calculáveis (diretas) do
domínio do software e avaliações qualitativas da complexidade do software.
Valores do domínio de informações são definidos da seguinte maneira:
Entradas externas (number of external inputs - EEs): cada entrada

externa é originada de um usuário ou transmitida de outra aplicação e fornece
dados distintos orientados à aplicação ou informações de controle.
Arquivos lógicos internos (internal logic files - ILFs): as entradas devem

ser diferenciadas das consultas, que são contadas separadamente. Cada
arquivo lógico interno é um agrupamento lógico de dados que reside dentro das
fronteiras do aplicativo e é mantido através de entradas externas.
Saídas externas (number of external outputs - EOs): cada saída externa

é formada por dados derivados da aplicação e fornece informações para o
usuário. São relatórios, telas, mensagens de erro etc.
Consultas externas (number of external inquiries - EQs): uma consulta

externa é definida como uma entrada online que resulta na geração de alguma
resposta imediata do software na forma de uma saída online.
Arquivos lógicos internos (number of internal logical files ILFs): cada

arquivo lógico interno é um agrupamento lógico de dados que reside dentro das
fronteiras do aplicativo e é mantido através de entradas externas.
Arquivos de interface externos (number of external interface files -

EIFs): cada arquivo de interface externo é um agrupamento lógico de dados
que reside fora da aplicação, mas fornece informações que podem ser usadas
pela aplicação.
Valores do domínio de informações – Tabela de PF

Uma vez coletados os dados, a tabela de PF é preenchida associando um valor
de complexidade com cada contagem. Organizações que usam métodos Ponto
por Função desenvolvem critérios para definir se determinada entrada é
simples, média ou complexa. No entanto, a determinação da complexidade é de
certo modo subjetivo. Veja o quadro:
Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA)
Um software a ser desenvolvido necessita da aplicação da métrica Pontos por
Função. Segundo a equipe de desenvolvimento, a seguinte relação foi
determinada ainda na fase de requisitos em consonância com o cliente em
função dos arquivos que farão parte do software e seus respectivos pesos com
relação ao PF total.
Para calcular o PF devemos seguir os seguintes passos:
- Eleger um dos tipos de função, preferencialmente aqueles que representam

altos percentuais, que são: Arquivos Internos - Entradas Externas - Saídas
Externas.
- Obter o número de ocorrências do tipo de função eleito.
- Calcular Pontos de Função Não Ajustados (PFNA).
- Utilizar o Fator de Ajuste da Complexidade = 1.
Durante as conversas preliminares com o cliente, verificou-se que os Arquivos

Internos seriam facilmente identificáveis, o que os credenciou como melhor
parâmetro para as estimativas de pontos de função.
Verificou-se que o total de Arquivos Internos é 13, portanto, complexidade

média, segundo a tabela definida pela equipe de desenvolvimento:
Concluímos que o software é de complexidade Média, pois 13 está na faixa 6

a 19. Considere este número e veja a seguir a continuidade dos cálculos.
Cálculo do PFNA
a) Como Arquivos Internos representam 25% do total dos PF:

25% ===> 13
100% ===> PF
PF = (13 * 100) / 25 = 52
b) Interfaces Externas: 3% de 52 = 1,56 (~= 2)

Entradas Externas: 30% de 52 = 15,6 (~= 16)
Saídas Externas: 28% de 52 = 14,56 (~= 15)
Consultas: 14% de 52 = 7,28 (~= 7)
Obs.: os arredondamentos devem obedecer ao padrão.
Tabela do PF
Podemos preencher a tabela de PF usando a coluna Complexidade Média.
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. Cada uma dessas perguntas é
respondida por meio de uma escala que varia de 0 (não importante ou não
aplicável) a 5 (absolutamente essencial). Observe:
1. O sistema requer salvamento (backup)?

2. São necessárias comunicações de dados especializadas para transferir
informações para a aplicação ou da aplicação?
3. Há funções de processamento distribuído?
4. O desempenho é crítico?
5. O sistema rodará em um ambiente operacional existente e intensamente
utilizado?
6. O sistema requer entrada de dados on-line?
7. A entrada on-line de dados requer que a transação de entrada seja
composta em múltiplas telas ou operações?
8. Os ILFs (arquivos lógicos) são atualizados on-line?
9. As entradas, saídas, arquivos ou consultas são complexas?
10. O processamento Interno é complexo?
11. O código é projetado para ser reutilizável?
12. A conversão e Instalação estão incluídas no projeto?
13. O sistema é projetado para múltiplas Instalações em diferentes
organizações?
14. A aplicação é projetada para facilitar a troca e o uso pelo usuário?
Cálculo do PFA após respostas

Os valores constantes na Equação e os fatores de peso aplicados aos valores do
domínio de informações são determinados empiricamente.
Dando prosseguimento ao exercício, vamos imaginar que após as respostas às

14 perguntas, Fi totalizou 42.
Então:
PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)]
PFA = 311 x [0,65 + 0,01 x 42]
PFA = 311 x 1,11
PFA = 332,77 ~= 333
Avance a tela para acompanhar um exemplo de Diagrama de Fluxo de

Dados (DFD) simples.
Exemplo de Diagrama de Fluxo de Dados (DFD) simples

Um software a ser desenvolvido necessita da aplicação da métrica Pontos por
Função. Segundo a equipe de desenvolvimento, a seguinte relação foi
determinada ainda na fase de requisitos em consonância com o cliente em
função dos arquivos que farão parte do software e seus respectivos pesos com
relação ao PF total.
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.
Cálculo dos Pontos por Função
O total da contagem apresentado no quadro Pontos por Função deve ser

ajustado usando a Equação, supondo que:
∑ (Fi) = 46
Portanto,
FP = 50 X [0,65 X (0,01 X 46)] = 56
Avance e acompanhe o Método para Estimativa de Custo.
Método para estimativa de custo – exemplo SERPRO

A estimativa de custo do projeto deve levar em consideração o custo da mão de
obra, considerando o esforço e o custo da hora de todos os profissionais
envolvidos no desenvolvimento da solução de software.
Além do custo da mão de obra e recursos computacionais, devem ser

considerados outros custos, tais como:
 Treinamento
 Consultoria
 Viagens
 Licenças de software
 Custos indiretos etc.
Cálculo Custo do Projeto (CP)

Sugere-se a seguinte fórmula para calcular o custo relativo à mão de obra para
o desenvolvimento da solução (CP – Custo do Projeto).
CP = (QHC x VPC) + (QHA x VPA) + (QPF x EPF x VPA) + Outros

Custos
Onde:
 QHC = Quantidade de Horas do Consultor

 VPC = Valor da Hora do Consultor
 QHA = Quantidade de Horas do Analista
 VPA = Valor da Hora do Analista
 QPF = Tamanho do Projeto em PF
 EPF = Esforço para implementar um Ponto por Função na plataforma
em questão
Cálculo Preço Fixo por Ponto por Função
Caso o contrato seja de preço fixo por Ponto de Função, então pode-se
considerar o seguinte:
CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF)
Onde:
 VPF = Valor Unitário do PF para o projeto em questão - Identificado de

acordo com a Tabela de Serviço Padrão do Sistema de Orçamento
Técnico.
Contagem de Pontos por Função de Projetos de Manutenção
Para que serve a contagem de Pontos por Função de Projetos de
Manutenção?
Esta contagem tem como propósito descrever os diversos tipos de projetos de

manutenção e mostrar uma solução para o seu dimensionamento em Pontos
por Função, visto que o manual de práticas de contagem não contempla
projetos de manutenção (maintenance), apenas o de melhoria (enhancement).
Quanto à documentação de projetos de manutenção pequenos (menores que

100 PF), deve-se registrar a solicitação do cliente e documentar os requisitos da
aplicação impactada pela demanda, de forma detalhada, visando apoiar a
contagem de Pontos de Função da demanda.
É importante também documentar as estimativas e a contagem de Pontos por

Função.
Pontos de Casos de Uso (PCU)

Quais são as características?
É possível estimar o tamanho do sistema ainda na fase de levantamento de

casos de uso.
Estima a dimensão do sistema de acordo com:

 O modo como os usuários o utilizarão;
 A complexidade de ações requeridas por tipo de usuário;
 A análise em alto nível dos passos necessários para a realização de cada
tarefa.
O que é preciso para gerar estimativas com PCU?

 Calcular o peso dos Atores do Sistema;
 Calcular o peso dos casos de uso;
 Calcular fatores de ajuste;
 Calcular o Porte do Sistema.
Calculando o peso dos Atores do Sistema

Ações
 Encontrar a métrica UAW (Unadjusted Actor Weight).

 Classificar atores envolvidos em cada caso de uso.
 Somar os produtos do número de atores de cada tipo pelo respectivo
peso.
Quadro Tipo de autor/peso
Exemplo
Um sistema projetado para dois tipos de usuários (gerente e usuário comum) e
que fosse acessado por um outro sistema utilizando-se de um protocolo de
comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível
complexo e 1 ator de nível médio).
UAW = (2 * 3) + (1 * 2)
UAW = 8
Atividade Proposta
Discuta sobre a importância da adoção de métricas no processo de qualidade
de software.
Chave de resposta: O processo de desenvolvimento de software deve ter o
foco na qualidade.
Aprenda Mais
Material complementar
Para saber mais sobre Pontos por Função, acesse o vídeo

disponível em nossa biblioteca virtual.
Referências
PRESSMAN, Roger S. Engenharia de software. 7. ed. Mc Graw Hill, 2011.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. Mc Graw Hill, 2007.
PADUA Filho, Wilson de. Engenharia de software: fundamentos, métodos e
padrões. 3. ed. Rio de Janeiro: Editora LTC, 2009.
PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.
VAZQUEZ, C.E. , SIMÕES, G.S., ALBERT, R.M. Análise de ponto de função
Questão 1
A Métrica de software baseadas em Pontos por Função mede:
a) O tamanho funcional do software.
b) A complexidade dos testes de software.
c) A extensão das sub-rotinas.
d) A quantidade de classes.
e) A qualidade do software.
Questão 2
A métrica Ponto por Função usa dados históricos para:
I — Estimar o custo necessário para projetar, codificar e testar o software.
II — Prever o número de erros que serão encontrados durante o teste.
III — Prever o número de componentes e/ou o número de linhas projetadas de
código-fonte no sistema implementado.
a) Todas corretas
b) Apenas I
c) Apenas II
d) Apenas II e III
e) Apenas I e III
Questão 3
A métrica Pontos por Função está baseada em medidas calculáveis do domínio
do software e avaliações qualitativas da complexidade do software. Um dos
domínios, “Entradas externas”, é definido como:
a) Originado de um usuário ou transmitido de outra aplicação e fornece
dados distintos à aplicação ou informações de controle.
b) Um agrupamento lógico de dados que reside dentro das fronteiras do
aplicativo.
c) Um agrupamento lógico de dados que reside fora da aplicação, mas
fornece informações que podem ser usadas pela aplicação.
d) Uma entrada online que resulta na geração de alguma resposta imediata
do software na forma de uma saída online.
e) Domínio formado por dados derivados da aplicação e que fornece
informações para o usuário.
Questão 4
A métrica Pontos por Função está baseada em medidas calculáveis do domínio
do software e avaliações qualitativas da complexidade do software. Um dos
domínios, “Arquivos lógicos internos”, é definido como:
a) Um agrupamento lógico de dados que reside dentro das fronteiras do
aplicativo.
b) Entrada originada de um usuário ou transmitida de outra aplicação e que
fornece dados distintos à aplicação ou informações de controle.
c) Um agrupamento lógico de dados que reside fora da aplicação, mas
fornece informações que podem ser usadas pela aplicação.
d) Uma entrada online que resulta na geração de alguma resposta imediata
do software na forma de uma saída online.
e) Domínio formado por dados derivados da aplicação e que fornece
informações para o usuário.
Questão 5
Na gestão de escopo de software, três elementos são essenciais em um projeto
de software. Analise as afirmativas e identifique-as como verdadeiras (V) ou
falsas (F).
( ) Após a definição do escopo, não é comum existirem mudanças no
desenvolvimento de projetos.
( ) A técnica de reuso de software nunca vai beneficiar a qualidade do
projeto.
( ) A técnica de reuso de software colabora para a redução do prazo do
projeto.
( ) Mesmo as pequenas mudanças de escopo devem ser registradas e
analisadas.
( ) Profissionais que dominam a Análise de Ponto por Função fazem com
que o cálculo da estimativa de esforço e custo seja uma ciência exata.
Questão 6
(CESGRANRIO – 2012 – Chesf) Um engenheiro de software fez uma contagem
de pontos por função de um software a ser desenvolvido e levantou as
seguintes informações:
COMPLEXIDADE
EE – 3 4 6
SE – 4 5 7
CE – 3 4 6
ALI – 7 10 15
AIE – 5 7 10
Onde:
PF = Contagem total x (0,65 + 0,01 x Soma Fi)
Considerando as possíveis complexidades de cada função de negócio, os
valores mínimos e máximos da contagem não ajustada de Pontos por Função
serão respectivamente:
a) 143 e 363
b) 177 e 361
c) 177 e 363
d) 179 e 361
e) 179 e 363
Questão 7
Em que consiste a modalidade preço por PF (Ponto por Função)?
a) É o valor global que uma empresa fornecedora está cobrando para um
determinado serviço.
b) É o valor unitário negociado com o qual se fará a transação comercial
para um desenvolvimento de software.
c) É um valor de referência de custo e que deve participar de um contrato.
d) É um valor que serve para medir a produtividade de um programador.
e) É um valor que serve para definir o quanto se pode pagar ao profissional
contratado (em regime CLT) em uma empresa.
Questão 8
(FCC – 2012 – TRE-CE) Considere 3 AIEs simples, 5 EEs médias, 8 CEs
complexas, 3 ALIs complexos e 7 SEs médias. O cálculo de PFs bruto é:
COMPLEXIDADE
EE – 3 4 6
SE – 4 5 7
CE – 3 4 6
ALI – 7 10 15
AIE – 5 7 10
a) 136
b) 148
c) 159
d) 163
e) 212
Questão 9
A Análise de Pontos por Função (APF) é uma técnica para a medição de
projetos de desenvolvimento de software que visa estabelecer uma medida de
tamanho, em PFs, considerando a funcionalidade implementada, sob o ponto
de vista do usuário.
Analise as afirmativas a seguir, relacionadas à APF:
I — É uma ferramenta que permite determinar o tamanho de pacotes de
software adquiridos, através da contagem de todos os Pontos por Função
incluídos no pacote.
II — É uma ferramenta que permite estimar custos e recursos envolvidos em
projetos de desenvolvimento e manutenção de software.
III — O Ponto por Função não ajustado é definido pelo produto da contagem
por um fator de ajuste.
a) Apenas a afirmativa III
b) Apenas a afirmativa II
c) Apenas as afirmativas I e III
d) Apenas as afirmativas I e II
e) Todas as afirmativas estão corretas
Questão 10
Uma das boas práticas utilizadas pelas empresas para contratar fornecedores
desenvolvedores de software é homologá-los previamente. Assim, sempre que
houver alguma demanda de software para ser desenvolvido poderemos afirmar
que:
a) Todos os fornecedores cobrarão o mesmo valor pelo projeto.
b) Todos os fornecedores participarão de todas as propostas.
c) A contratante pode exigir que cada proposta apresente a quantidade de
Pontos por Função do projeto de forma detalhada, o que tornará mais
fácil comparar as propostas.
d) A contratada pode exigir que cada proposta apresente a quantidade de
fácil comparar as propostas.
e) A contratada pode exigir que cada proposta apresente a quantidade de
difícil comparar as propostas.
Aula 2
Questão 1 - A
Justificativa: Por definição, Pontos por Função medem o tamanho funcional do
software.
Questão 2 - A
Justificativa: Por melo de dados históricos, a métrica FP pode ser empregada
para estimar o custo, prever o número de erros que serão encontrados durante
o teste e prever o número de componentes e/ou o número de linhas projetadas
de código-fonte.
Questão 3 - A
Justificativa: Entrada externa não reside dentro do aplicativo. Ë fornecida pelo
usuário e/ou por outra aplicação.
Questão 4 - A
Justificativa: Arquivo lógico interno, conforme o seu nome diz, reside dentro da
fronteira do software.
Questão 5 - F, F, V, V, F
Justificativa: A maioria dos projetos passa por mudanças ao longo do ciclo de
vida. Métrica de software não pretende obter medidas exatas, mas uma
estimativa de esforço.
A técnica de reuso é recomendada no desenvolvimento de software e na sua
qualidade. Toda alterações no software deve ser documentada.
Portanto, a resposta correta é F-F-V-V-F
Questão 6 - E
Justificativa: Mínimo: (8 x 3) + (10 x 4) + (0 x 3) + (15 x 7) + (2 x 5) = 179
Máximo: (8 x 6) + (10 x 7) + (0 x 6) + (15 x 15) + (2 x 10) = 363
Questão 7 - B
Justificativa: A técnica Pontos por função é usado pelos desenvolvedores par
determinar o esforço no desenvolvimento do software. Assim, o custo do
software pode ser estimado.
Questão 8 - D
Justificativa: Solução: (3 x 5) + (5 x 4) + (8 x 6) + 3 x 15) + (7 x 5) = 163
Questão 9 - D
Justificativa: Pontos por função ajustado é definido pelo produto da contagem
por um fator de ajuste, o que contradiz o item III.
A técnica Pontos por Função determina o tamanho do software e os custos
correspondentes.
Questão 10 - C
Justificativa: Nos editais das licitações públicas para desenvolvimento de
software, pontos por função tem sido uma exigência do contratante.
Introdução
Nesta aula, você compreenderá :
• Métricas para modelo de projeto;
• Fan-out e Fan-in;
• Conectividade;
• Métricas de projeto da arquitetura;
• Métricas para projeto orientado a objeto;
• Acoplamento e Métricas orientadas à classe.
Esta abordagem é muito importante para determinar o tamanho do software.
Bons estudos!
Objetivo:
1. Compreender as métricas para o modelo de projeto de acordo com os
parâmetros de dimensão do software Fan-out e Fan-in;
2. Entender as métricas para o modelo de projeto de acordo métricas de
projeto da arquitetura.
Conteúdo
Contextualização
É inconcebível que o projeto de um novo avião, um novo chip de computador
ou um novo edifício comercial...
... seja conduzido sem a definição de medidas, sem determinar métricas

para os vários aspectos de qualidade e sem usá-las como indicadores para
orientar a maneira pela qual o projeto evoluirá.
E, além disso, o projeto de sistemas complexos baseados em software muitas

vezes é realizado praticamente sem nenhuma medição.
A ironia disso tudo é que as métricas de projeto para software estão

disponíveis, mas a grande maioria dos engenheiros de software continua
ignorando sua existência.
As métricas de projeto para software de computador, como todas as outras

métricas de software, não são perfeitas.
Continua o debate sobre sua eficácia e a maneira pela qual deveriam ser
aplicadas.
Muitos especialistas argumentam que é necessária mais experimentação para

que as medições de projeto possam ser usadas. E, além disso, projeto sem
medição é uma alternativa inaceitável.
Examinaremos a seguir algumas das métricas de projeto mais comuns para

software de computador. Cada uma delas pode proporcionar uma melhor
visualização, e todas podem ajudar o projeto a evoluir para um nível maior de
qualidade.
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.
Fan-out
Deve-se ter no máximo 7 subordinados.
Fan-in
Deve-se manter alto o número de superiores. Alto Fan-in é a recompensa pelo
factoring inteligente e a remoção de módulos restritivos.
Ter uma função chamada por muitos superiores evita a necessidade de

codificar a mesma função em vários lugares. Portanto, em tempo de
manutenção, a duplicidade de alteração é eliminada.
Módulos com Fan-in devem ter boa coesão: funcional ou, no mínimo,
comunicacional ou sequencial.
Existem duas regras para restringir o uso de Fan-in:
Cada interface para um único módulo deve ter os mesmos números e tipos de
parâmetros. O exemplo a seguir contraria esta regra.
Métricas de projeto da arquitetura
As métricas de projeto da arquitetura focalizam as características da arquitetura
do programa com ênfase na estrutura arquitetônica e na eficácia dos módulos
ou componentes dentro da arquitetura.
Essas métricas são uma “caixa-preta” no sentido de que elas não requerem
qualquer conhecimento do funcionamento interno de um determinado
componente de software.
Card e Glass [Car90] definem três medidas de complexidade de projeto de

software:
Complexidade estrutural: Para arquiteturas hierárquicas (por exemplo,

arquiteturas de chamada e retorno), a complexidade estrutural de um
módulo i é definida da seguinte maneira:
Complexidade de dados: A complexidade dos dados (data complexity)

proporciona uma indicação da complexidade na interface Interna para um
módulo i e é definida como:
Em que v(i) é o número de variáveis de entrada e saída passadas para o do

módulo i.
Complexidade de sistema: Por fim, a complexidade de sistema (system

complexity) é definida como a soma da complexidade estrutural e de dados,
especificada como:
Atenção
À medida que esses valores de complexidade aumentam, a
complexidade global da arquitetura do sistema também
aumenta.
Isso leva a uma maior probabilidade de que o trabalho de

integração e teste também aumente.
Fenton [Fen91] sugere um conjunto de métricas de morfologia simples (isto é,

forma) que permite que diferentes arquiteturas de programa sejam comparadas
usando uma série de dimensões diretas. Referindo-se à arquitetura de chamada
e retorno na Figura apresentada, podem ser definidas as seguintes métricas:
Tamanho = n + a
em que n é o número de nós e a é o número de arcos.
Para a arquitetura mostrada:
 Tamanho = 19 + 24 = 43
 Profundidade = caminho mais longo desde o nó raiz (topo) até o nó da
folha. Logo, a profundidade = 5
 Largura = número máximo de nós em qualquer nível da arquitetura.
 Logo, largura = 7
A relação arco para nó,

r = a/n
mede a densidade de conectividade da arquitetura:
r= 24/19 = 1,26.
Indicadores de qualidade de software
A força aérea americana (U.S. Air Force Systems Command) desenvolveu um
conjunto de indicadores de qualidade de software baseados nas características
de projeto mensuráveis de um programa de computador. Usando conceitos
similares àqueles propostos na norma IEEE Std. 982.1-1988, a Força Aérea usa
informação obtida do projeto de dados e arquitetural para criar um índice de
qualidade da estrutura do projeto (design structure quality index - DSQI) que
varia de 0 a 1.
Os seguintes valores devem ser apurados para calcular o DSQI:
 S1: Número total de módulos definidos na arquitetura do programa.

 S2: Número de módulos cuja função correta depende da origem dos
dados de entrada ou que produzem dados para serem usados em outro
lugar (em geral, módulos de controle, entre outros, não seriam contados
como parte de S2).
 S3: Número de módulos cuja função correta depende de processamento
anterior.
 S4: Número de itens de base de dados (inclui objetos dados e iodos os
atributos que definem objetos).
 S5: Número total de itens únicos de base de dados.
 S6: Número de segmentos de base de dados (diferentes registros ou
objetos individuais).
 S7: Número de módulos com uma única entrada e saída (processamento
de exceção não é considerado múltipla saída).
Uma vez determinados os valores S1 até S7, para um programa de computador

podem ser calculados os seguintes valores intermediários:
Estrutura de programa
D1, que é definido da seguinte maneira:
Se o projeto da arquitetura foi desenvolvido por meio de um método distinto
(por exemplo, projeto orientado a fluxo de dados (DFD) ou projeto orientado a
objeto (OO), então D1 = 1, caso contrário D1 = 0.
Independência modular
D2 = 1 – (S2/S1)
Módulos não dependentes de processamento anterior

D3 = 1 – (S3/S1)
Tamanho da base de dados

D4 = 1 – (S5/S4)
Compartilhamento da base de dados

D5 = 1 – (S6/S4)
Característica de entrada/saída do módulo

D6 = 1 – (S7/S1)
Cálculo do DSQI
Com os valores intermediários determinados, o DSQI é calculado da seguinte
maneira:
DSQI = ∑ wi/D
Em que i = 1 a 6, w1 é o peso relativo da importância de cada um dos valores
intermediários e ∑W1 = 1 (se todos os Di tiverem o mesmo peso, então w1 =
0,167).
Métricas para projeto orientado a objeto
Há muita coisa sobre projeto orientado a objeto que é subjetivo - um
projetista experiente “sabe” como caracterizar um sistema orientado a objeto
de maneira que implemente efetivamente os requisitos do cliente.
Mas, à medida que um modelo de projeto orientado a objeto cresce em

tamanho e complexidade, uma visão mais objetiva das características do
projeto pode favorecer tanto o projetista experiente (que obtém uma visão
adicional) quanto o novato (que obtém uma indicação da qualidade que de
outra forma não estaria disponível).
Em um tratamento detalhado de métricas de software para sistemas orientados

a objeto, Whitmire descreve nove características distintas e mensuráveis
de um projeto orientado a objeto:
1. Tamanho. É definido em termos de quatro visualizações: população,

volume, comprimento e funcionalidade. População é medida tomando-se
uma contagem estática das entidades orientadas a objeto, como classes
ou operações. Medidas de volume são idênticas às medidas de
população, mas são coletadas dinamicamente - em determinado instante
do tempo. Comprimento é a medida de uma cadeia de elementos de
projeto interconectados (por exemplo, a extensão de uma árvore de
herança é uma medida do comprimento). As métricas de funcionalidade
proporcionam uma indicação indireta do valor fornecido ao cliente por
uma aplicação orientada a objeto.
2. Complexidade. Assim como o tamanho, há muitas visões diferentes da

complexidade do software. Whitmire vê a complexidade em termos de
características estruturais examinando como as classes de um projeto
orientado a objeto se inter-relacionam.
3. Acoplamento. As conexões físicas entre elementos do projeto orientado
a objeto (por exemplo, o número de colaborações entre classes ou o
número de mensagens passadas entre objetos) representam o
acoplamento em um sistema orientado a objeto.
4. Suficiência. Whitmire define suficiência como “o grau com o qual uma

abstração possui as características requeridas para ela, ou o grau com o
qual um componente de projeto possui características em sua abstração,
do ponto de vista da aplicação corrente”. Em outras palavras,
perguntamos: “Que propriedades essa abstração (classe) precisa ter
para ser útil para mim?”. Essencialmente, um componente de projeto
(por exemplo, uma classe) é suficiente se refletir totalmente todas as
propriedades do objeto de domínio da aplicação que está modelando -
isto é, que a abstração (classe) possui as características necessárias para
ele.
5. Totalidade. A única diferença entre totalidade e suficiência é “o

conjunto de características em relação às quais comparamos a abstração
ou o componente de projeto”. A suficiência compara a abstração do
ponto de vista da aplicação corrente. A totalidade considera múltiplos
pontos de vista, formulando a pergunta: “Que propriedades são
necessárias para representar completamente o objeto de domínio do
problema?”. Em virtude do critério da totalidade considerar diferentes
pontos de vista, ele tem uma implicação indireta no grau com o qual a
abstração ou o componente de projeto pode ser reutilizado.
6. Coesão. Assim como seu correspondente no software convencional, um

componente orientado a objeto deverá ser projetado de maneira que
tenha todas as operações funcionando em conjunto para atingir um
objetivo único e bem definido. A coerência de uma classe é determinada
examinando-se o grau segundo o qual “o conjunto de propriedades que
ela possui faz parte do domínio do problema ou projeto”.
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.
Atividade Proposta
Discuta com seus colegas a importância da adoção de métricas no processo de
projeto de software a importância do fan-in e fan-out em uma estrutura de
módulos de projeto de software.
Chave de resposta: FAN-OUT, FAN-IN, Complexidade de dados,

complexidade estrutural.
Referências
PRESSMAN, Roger S. Engenharia de software. 7. ed. Mc Graw Hill, 2011.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. Mc Graw Hill, 2007.
PADUA Filho, Wilson de. Engenharia de software: fundamentos, métodos e
PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.
VAZQUEZ, C.E. , SIMÕES,G.S., ALBERT, R.M. Análise de ponto de função
Questão 1
A estrutura de programa representa a organização de seus módulos. A
profundidade e largura da estrutura constituem uma indicação do número de
níveis de controle e do espaço de controle global, respectivamente. A medida
que determina o número de módulos que são diretamente controlados por
outro módulo é denominada:
a) Fan-in
b) Fan-out
c) Stubb
d) EAP
e) Hierarquia
Questão 2
A estrutura de programa representa a organização de seus módulos. A
profundidade e largura da estrutura constituem uma indicação do número de
níveis de controle e do espaço de controle global, respectivamente. A medida
que indica quantos módulos controlam diretamente determinado módulo, isto é,
indica o número de superiores imediatos que ele possui é denominado:
a) Fan-in
b) Fan-out
c) Stubb
d) EAP
e) Hierarquia
Questão 3
A característica da hierarquia de controle da estrutura do software que indica o
conjunto de componentes que é diretamente invocado ou usado como dados
por determinado componente é denominada:
a) Factoring
b) Visibilidade
c) Extensão
d) Conectividade
e) Navegabilidade
Questão 4
No Fan-out, quantos módulos subordinados devemos ter, no máximo?
a) 3
b) 5
c) 6
d) 7
e) 8
Questão 5
No Fan-in, quantos módulos superiores, no máximo, devemos ter?
a) O mínimo possível
b) Alto número de superiores
c) 4
d) 5
e) 6
Questão 6
Em um tratamento detalhado de métricas de software para sistemas orientados
a objeto, Whitmire descreve algumas características distintas e mensuráveis de
um projeto orientado a objeto. Assinale a opção INCORRETA:
a) Volatilidade
b) Hierarquia
c) Similaridade
d) Originalidade
e) Coesão
Questão 7
As métricas de projeto focalizam as características da arquitetura do programa
e são verdadeiras “caixa-preta” no sentido de que elas não requerem qualquer
conhecimento do funcionamento interno de um determinado componente de
software. São definidas três medidas de complexidade de projeto de software:
a) Temporal, procedimental e casual.
b) Informacional, de dados e funcional.
c) Procedimental, funcional, hierárquico.
d) Estrutural, de dados e de sistema.
e) Lógica, funcional e de dados.
Questão 8
A complexidade dos dados proporciona uma indicação da complexidade na
interface interna do software para um módulo “i” e é definida como
D(i) = v(i)/[fout (i) + 1]
Onde fout (i) é o Fan-out do módulo i e v(i) é o número de variáveis de
entrada e saída passadas para o do módulo “i”. Calcule a complexidade na
interface para o módulo com um número total de variáveis 19 e Fan-out 7.
a) 3,45
b) 6,70
c) 2,37
d) 3,98
e) 0,37
Questão 9
Calcule a complexidade do módulo de um software com complexidade
estrutural é 15 e complexidade dos dados é 30.
a) 2
b) 450
c) 0,5
d) 45
e) 15
Questão 10
Uma estrutura de software possui 15 nós e 12 arcos. Qual é o seu tamanho?
a) 180
b) 1,25
c) 3
d) 27
e) -3
Aula 3
Questão 1 - B
Justificativa: stub, em português esboço de método, em desenvolvimento de
software, é um pedaço de código usado para substituir algumas outras. Já
STUBB é nada, a não ser sobrenome como Alexander Stubb é um político
finlandês.
EAP = Sestrutura Analítica de Projeto, técnica usada no gerenciamento de
projeto.
Hierarquia é a ordenada distribuição dos poderes com subordinação sucessiva.
FAN-IN indica o número de superiores imediatos que ele possui é denominado.
Fun-OUT é a medida que determina o número de módulos que são diretamente
controlados por outro módulo é denominada.
Questão 2 - A
Justificativa: stub, em português esboço de método, em desenvolvimento de
software, é um pedaço de código usado para substituir algumas outras. Já
STUBB é nada, a não ser sobrenome como Alexander Stubb é um político
finlandês.
EAP = Sestrutura Analítica de Projeto, técnica usada no gerenciamento de
projeto.
Hierarquia é a ordenada distribuição dos poderes com subordinação sucessiva.
FAN-IN indica o número de superiores imediatos que ele possui é denominado.
Fun-OUT é a medida que determina o número de módulos que são diretamente
controlados por outro módulo é denominada.
Questão 3 - D
Justificativa: Conectividade – é como se módulos estivessem conectados a
outros para serem chamados durante a execução. 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.
Extensão – significa comprimento, ou seja, 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).
Factoring – significa fatorar, dividir um módulo em módulos mmenores, o uqe
facilita a sua manutenção futura.
Visibilidade – característica que torna um aplicativo ou mesmo uma empresa
em algo que passa a ser percebido pelo mercado.
Navegabilidade - ...
Questão 4 - D
Justificativa: Em uma estrutura de módulos de um programa, o Ideal é que
tenhamos módulos com alto fan-in (muitos módulos chamando um determinado
módulo) e baixo fan-out (um detreminado módulo chamando o menor número
possível de módulos para evitar maior complexidade na lógica de programação
e futura manutenção do software). Segundo os autores devemos gter nom
máximo 7 fan-out.
Questão 5 - B
Justificativa: No fan-in, devemos ter o maior número possível de módulos
chamando um determinado módulo. Isso facilita a lógca da programação e a
manutenção futura. Fan-in conta o número de funções que chamam uma
determinada função.
O fan-in de um módulo indica o número de módulos que o utilizam, ou seja,
que tem relações de uso com o modulo. * Um fan-in alto indica que o módulo
representa uma abstração bem definida e muito utilizada por outros módulos.
Questão 6 - B
Justificativa: Hierarquia é a ordenada distribuição dos poderes com
subordinação sucessiva.
As características de Whitmire são: Tamanho, Comprimento, Complexidade,
Acoplamento, Suficiência, Totalidade, Volatilidade, Similaridade, Originalidade e
Coesão.
Questão 7 - D
Justificativa: Card e Glass definem três medidas de complexidade de projeto de
software: complexidade estrutural, complexidade de dados, complexidade de
sistema.
Essas medidas são determinadas mediante fórmulas e cáculos simples.
Questão 8 - C
Justificativa: Aplicando a fórmula, temos:
D = v / (fout + 1)
D = 19 / (7 + 1)
D = 19 / 8 = 2,37
Questão 9 - D
Justificativa: Complexidade de sistema (ou de um módulo) é definida como a
soma da complexidade estrutural e complexidade de dados. Portanto:
C = 15 + 30 = 45
Questão 10 - D
Justificativa: Tamanho = n + a
em que “n” é o número de nós e “a” é o número de arcos.
Tamanho = 15 + 12 = 27
Introdução
Nesta aula, você compreenderá as seguintes técnicas de estimativa: COCOMO
(básico, intermediário e detalhado); COCOMO II (estimativas de prazo, de custo
e de defeitos); método de Putnam e a complexidade ciclomática.
Objetivo:
1. Compreender as técnicas de estimativa COCOMO e COCOMO II;
2. Entender o método de Putnam e a complexidade ciclomática.
Conteúdo
COCOMO
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.
O COCOMO básico é um modelo estático de valor simples, que calcula o

esforço do desenvolvimento de software em função do tamanho deste
software, expresso em linhas de código estimadas. Avance e veja alguns
exemplos.
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.
Exemplo 1: Considere um software com 33,3 Kloc; usando o modelo
semidestacado, temos:
Logo, o número ideal de pessoas no projeto é:
N = E/D = 152/14,5 = 11 pessoas
Suponha que outro software tenha o Kloc igual a 45,3?
Exemplo 2: Considere que, após uma análise de ponto de função, detectamos

236 PFs não ajustados e que, além disso, as fórmulas do COCOMO tenham sido
construídas com Kloc. Se a linguagem utilizada for ACCESS, temos:
TAMANHO = 38 x 236 (PF) = 8968 LOC = 8,968 KLOC
Usando o COCOMO básico, o gerente considerou o projeto como orgânico.

Sendo assim, vamos usar as fórmulas.
Logo, o número ideal de pessoas no projeto é:

N = E/D = 36/4,3 = 8 pessoas
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 de pessoal
I – Capacidade dos analistas;

II – Capacidade dos programadores;
III – Experiência na aplicação;
IV – Experiência no ambiente de hardware;
V – Experiência com a linguagem de programação.
Atributos do projeto
I – Uso de ferramenta de software;

II – Técnicas modernas de programação;
III – Prazo requerido para o desenvolvimento.
O COCOMO intermediário calcula o esforço de desenvolvimento de software em
função do tamanho do programa, que inclui custo, avaliação subjetiva do
produto, hardware, pessoal e atributos de projeto. Observe a fórmula:
Considere que, no exemplo 2 (COCOMO intermediário), o gerente considerou

o projeto como orgânico; portanto, usaremos as fórmulas:
Cálculo do EAF: primeiramente, o gerente analisou os 15 direcionadores da

tabela de multiplicadores de esforço:
Posteriormente, ele concluiu que:
 Complexidade do software: Alta
 Restrições quanto ao uso da memória: Alto
 Experiência com a linguagem de programação: Baixa
 Capacidade dos programadores: Baixa
Os outros atributos foram considerados normais.
Assim, podemos calcular o EAF:
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

O que é 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

livres para dar suporte à implementação do modelo de qualidade MPS.BR –
Melhoria de Processo de Software Brasileiro (SOFTEX, 2009).
Por que foi concebida?

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 que é o MPS.BR?
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 que é o 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.
Como se processa?
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.
Quais são suas vantagens?

 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.
Qual é a sua desvantagem?
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.
Equação de Putnam
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.
Complexidade ciclomática
Vamos a um exemplo?
Veja como calcular a complexidade ciclomática para um artefato de software
(VG).
Cálculo
V(G) = E – N + 2P
Para:
E=8P=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.
Atividade Proposta
Discuta com seus colegas a importância da adoção do modelo de estimativa de
ciusto COCOMO no processo de projeto de software a importância de se
determinar a complexidade ciclomática.
Chave de resposta: COCOMO, COCOMO II, Complexidade.
Referências
PADUA Filho, Wilson de. Engenharia de Software: fundamentos, métodos e
PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.
PRESSMAN, Roger S. Engenharia de Software. 7. ed. McGraw Hill, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. McGraw Hill, 2007.
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de ponto de função
Questão 1
O método COCOMO é um modelo de estimativa do tempo de desenvolvimento
de um software, baseado no estudo de vários projetos, dos quais foram
examinados de 2.000 a 100.000 linhas de código em linguagens de
programação Assembly. Esse método consiste em três implementações: básico,
intermediário e avançado.
O modelo básico:
a) É um modelo com atributos de controle, como: atributos do produto;
atributos de hardware; atributos pessoais; atributos do projeto. É um
modelo com características da versão intermediária com uma avaliação
de impacto de custo em cada passo do projeto.
b) É 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.
c) É um modelo dinâmico com características próprias que calcula o esforço
de cada programador.
d) É um modelo sistêmico que calcula as horas trabalhadas por cada equipe
do projeto.
Questão 2
O COCOMO básico se aplica a três classes de projetos do software; são elas:
a) Básico, intermediário e avançado
b) Orgânico, semidestacado e embutido
c) Básico, semidestacado e restrito
d) Difuso, semidestacado e embutido
e) Orgânico, difuso e semidestacado
Questão 3
O COCOMO ____________________ é aplicado no desenvolvimento de
sistemas complexos embutidos em hardware, com muita inovação, com
restrições severas e/ou com requisitos muito voláteis e de confinamentos
operacionais.
a) Difuso
b) Semidestacado
c) Orgânico
d) Funcional
e) Embutido
Questão 4
O COCOMO ____________________ mede projetos de software relativamente
pequenos, simples e com pouca inovação, com equipes de dimensão
relativamente pequena.
a) Avançado
b) Semidestacado
c) Orgânico
d) Funcional
e) Embutido
Questão 5
O COCOMO ____________________ é aplicado quando as equipes de trabalho
são heterogêneas em termo de experiência; por exemplo, um sistema de
processamento de transações, como o controle de estoque.
a) Avançado
b) Semidestacado
c) Orgânico
d) Funcional
e) Embutido
Questão 6
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 uma estrutura (framework) para a
comunicação de decisões de negócio entre os envolvidos em um
empreendimento baseado em softwares. Marque as vantagens do COCOMO
II:
a)O mesmo processo pode ser aplicado ao projeto inteiro.
b)O mesmo processo pode ser aplicado a apenas um componente
individual.
c)Sua precisão pode ser prejudicada no inicio do projeto, pois o modelo
depende fortemente de uma estimativa precisa da quantidade de linhas.
d)Pode calcular a programação da manutenção anual.
e)Pode fazer exame da vantagem de dados históricos e criar uma constante
de calibração que pode ser calculada para estimativas futuras.
Questão 7
O __________________ considera múltiplas variáveis e o ciclo de
desenvolvimento do projeto com base em análise estatística, relacionando os
comportamentos prazo e esforço.
a) Método de esforço
b) Método COCOMO
c) Método COCOMO II
d) Método de pontos por função
e) Método de Putnam
Questão 8
A 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. É calculada a partir de um(a):
a) Tabela da arquivos lógicos
b) Diagrama de fluxo de dados
Projeto de software ab bb cb db
c) Diagrama de casos de uso

d) Grafo de fluxo
e) Diagrama de Gantt
Questão 9
Analise esta tabela do COCOMO semidestacado.
Semidestacado 3,0 1,12 2,5 0,35
Agora, determine o número de pessoas e o prazo que deve levar o projeto de

um software com 45 Kloc, usando:
E = ab * KLOC bb
D = cb * E db
P = E / D, onde:
E = Esforço aplicado por pessoa no mês
D = Tempo de desenvolvimento em meses
a) 328 pessoas/mês – 12 meses
b) 215 pessoas/mês – 16,4 meses
c) 142 pessoas/mês – 25,7 meses
d) 115 pessoas/mês – 26,4 meses
e) 102 pessoas/mês – 18 meses
Questão 10
Determine a complexidade ciclomática de um software cujo grafo apresenta 12
bordas e 7 nós. Considere o número de componentes conectado igual a 1.
a) 5
b) 7
c) 19
d) 14
e) 84
Aula 4
Questão 1 - B
Justificativa: O modelo COCOMO básico calcula o esforço do software em
função das linhas de código estimadas.
Questão 2 - B
Justificativa: Segundo Pressman (Engenharia de Software) as classes de
projetos referentes ao COCOMO básico são Orgânico, Semi-destacado e
Embutido.
Questão 3 - E
Justificativa: Segundo Pressman (Engenharia de Software) as classes de
projetos referentes ao COCOMO básico são Orgânico, Semi-destacado e
Embutido.
Questão 4 - C
Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO
Orgânicos representam projetos relativamente pequenos, simples e com pouca
inovação, com equipes de dimensão relativamente pequena. Exemplo: Mala
Direta.
Questão 5 - B
Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO Semi
destacado ou difuso - (em tamanho e complexidade) se refrem a 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. Por
exemplo, um sistema de processamento de transações. Exemplo: Folha de
Pagamento.
Questão 6 - A, B, D, E
Justificativa: Segundo Pressman (Engenharia de Software) as vantagens do
COCOMO II são:
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 fazer exame da vantagem de dados históricos e com esses
dados criar uma constante da calibração que pode ser calculada para
estimativas futuras.
Questão 7 - E
Justificativa: Segundo Pressman (Engenharia de Software) 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 o comportamento prazo e
esforço.
Questão 8 - D
Justificativa: Segundo Pressman (Engenharia de Software), a complexidade
ciclomática é 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. É calculada a partir de um grafo de fluxo.
Questão 9 - B
Justificativa: Basta aplicar a fórmula.
E = 3 x 451,12 = 3 x 71,0555 = 215 pessoas/mês
D = 2,5 x 2150,35 = 2,5 x 6,55169 = 16,4
Questão 10 - B
Justificativa: Basta aplicar a fórmula.
V (G) = E – N + 2P
Onde E = 12
N=7
P=1
Logo: V(G) = 12 – 7 + 2 = 7
Luiz Roberto Martins Bastos é Mestre em Ciências e Computação, com
ênfase em Otimização de Processos, pelo Instituto Militar de Engenharia (IME),
Especialista em Informática Educativa pelo Centro Universitário Carioca
(UNICARIOCA), Graduado em Administração pela Universidade Estácio de Sá
(UNESA) e em Engenharia Elétrica pela Universidade Federal do Rio de Janeiro
(UFRJ). Possui experiência de 20 anos nas áreas de produção,
desenvolvimento, marketing e gestão de processos. Atualmente, é professor e
conteudista dos cursos de Graduação e Pós-Graduação da UNESA – nas
modalidades presencial e a distância. Também atua como professor convidado
da Fundação Getulio Vargas (FGV) e do Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE).
Currículo Lattes: http://lattes.cnpq.br/1109935861412082.

Metricas de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metricas de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Apresentação

Aula 3: Determinação de Ponto por Função .............................................................................. 49

Aula 4: Estimativa de esforço e prazo ....................................................................................... 68

No caso de PROJETO, verificamos que o gerenciamento é necessário, mas não

A gestão do desenvolvimento, da manutenção e da prestação de serviços

Plataformas como ITIL, CMMI e MPS-BR colocam as métricas e as medições

Nesse sentido, esta disciplina pretende desenvolver no profissional da área a

Sendo assim, esta disciplina tem como objetivos:

A qualidade tornou a medição do software nos seus diversos aspectos uma

Sabemos que todo processo de engenharia necessita de medições para

Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos

Haverá sempre um elemento qualitativo na criação de software. O problema é

A métrica de produto proporciona uma base por meio da qual a análise,

Haverá sempre um elemento qualitativo na criação de software. O problema é

A métrica de produto proporciona uma base por meio da qual a análise,

Quais são as etapas envolvidas?

Em seguida, coletam-se os dados necessários para aplicar as métricas

Uma vez computadas, as métricas são analisadas com base em diretrizes

Os resultados das análises são interpretados para obter informações

Os dados da interpretação levam à modificação dos requisitos e modelos

Qual é o artefato (produto)?

Como garantir que o trabalho seja realizado corretamente?

Embora as métricas de produto para software sejam imperfeitas, podem

Avaliação dos atributos internos do produto

Essas medidas de atributos internos do produto fornecem uma indicação em

Os erros podem aparecer no início do processo devido a alguns fatores:

A atividade de teste de software é um elemento crítico da garantia de qualidade

Curva de falhas para hardware ou curva da banheira

 Métodos e ferramentas de análise, projeto, codificação e teste;

Fatores determinantes para a garantia da qualidade

Padrões especificados definem um conjunto de critérios de desenvolvimento

Fatores de qualidade de McCall

Características de adaptação a novos ambientes

Fatores de Qualidade ISO 9126

Métricas de indicadores e de produto

Quando é coletado um único ponto de dado (por exemplo, o número de erros

Uma métrica de software relaciona as medidas individuais de alguma maneira

Antes que um projeto possa ser planejado, deve-se:

As medições e métricas ajudam a entender o processo usado para se

A medição e a inferência estatística são usadas em várias áreas para projetar

A medição pode levar a controvérsias e discussões como:

As estimativas mais importantes

 Esforço humano exigido

Métricas são frequentemente classificadas como métricas do processo ou

Métricas de recursos: experiência do programador, custo de

Outros fatores relacionados ao desenvolvimento incluem:

Medidas Diretas do Produto:

Medidas Indiretas do Produto:

Métricas orientadas ao tamanho

Métricas orientadas à função

Atributos de métricas eficazes de software

A seguir estão elencados os atributos que devem ser considerados pelas

 Simples e computáveis – Deverá ser relativamente fácil aprender a

Chave de resposta: O processo de desenvolvimento de software deve ter o

Essa abordagem é muito importante devido à necessidade de justificar prazos e

Pontos por Função medem o tamanho funcional do software.

Da mesma forma que somente os metros quadrados são insuficientes para

Para que servem as métricas Pontos por Função?

 Estimar o custo necessário para projetar, codificar e testar o software;

Valores do domínio de informações

Entradas externas (number of external inputs - EEs): cada entrada

Arquivos lógicos internos (internal logic files - ILFs): as entradas devem

Saídas externas (number of external outputs - EOs): cada saída externa