Métricas de Software Fundamentos

Apresentao
.............................................................................................................................Erro!
Indicador no definido.
Aula 1: Fundamentos de mtricas e medidas ............................................................................
Erro! Indicador no definido.
Introduo ................................................................................Erro! Indicador no definido.
Contedo................................................................................................................................ 7
Mtricas para Software ..................................................................................................... 7
Por que devemos medir? ................................................................................................. 9
Quais so as etapas envolvidas? ..................................................................................... 9
Como garantir que o trabalho seja realizado corretamente? ................................... 9
Avaliao 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
Caractersticas operacionais .......................................................................................... 13
Caractersticas de manuteno .................................................................................... 14
Caractersticas de adaptao a novos ambientes ..................................................... 14
Fatores de Qualidade ISO 9126 ..................................................................................... 15
Mtricas de indicadores e de produto ......................................................................... 15
Controle do software ...................................................................................................... 16
O produto e o processo em relao medio ........................................................ 17
As estimativas mais importantes .................................................................................. 17
Mtricas do processo ...................................................................................................... 17
Mtricas do produto ........................................................................................................ 18
Mtricas diretas e mtricas indiretas............................................................................ 19
Mtricas orientadas ao tamanho .................................................................................. 19
Mtricas orientadas funo ........................................................................................ 20
Princpios de medio .................................................................................................... 20
Atributos de mtricas eficazes de software................................................................ 20
Atividade Proposta........................................................................................................... 22
MTRICAS DE SOFTWARE
Referncias........................................................................................................................... 22
Exerccios de fixao ......................................................................................................... 22
Aula 2: Pontos por Funo ......................................................................................................... 30
Introduo ........................................................................................................................... 30
Contedo.............................................................................................................................. 31
Mtricas baseadas em funo ou Pontos por Funo (PF)...................................... 31
Valores do domnio de informaes ........................................................................... 31
Valores do domnio de informaes Tabela de PF................................................ 32
Exemplo de aplicao de Ponto de Funo No Ajustado (PFNA) ........................ 33
Exemplo de Diagrama de Fluxo de Dados (DFD) simples ........................................ 36
Clculo dos Pontos por Funo .................................................................................... 38
Mtodo para estimativa de custo exemplo SERPRO ............................................. 38
Contagem de Pontos por Funo de Projetos de Manuteno ............................. 40
Pontos de Casos de Uso (PCU) ..................................................................................... 40
Calculando o peso dos Atores do Sistema ................................................................. 41
Aprenda Mais....................................................................................................................... 42
Referncias........................................................................................................................... 42
Aula 3: Determinao de Ponto por Funo .............................................................................. 49

Introduo ........................................................................................................................... 49
Contedo.............................................................................................................................. 50
Contextualizao ............................................................................................................. 50
Fan-out e Fan-in .............................................................................................................. 51

Fan-out e Fan-in: caractersticas .................................................................................. 51
Mtricas de projeto da arquitetura ............................................................................... 53
Indicadores de qualidade de software ........................................................................ 55
Mtricas para projeto orientado a objeto ................................................................... 57
Mtricas orientadas a classe o conjunto de mtricas CK .................................... 59
Referncias........................................................................................................................... 61
Aula 4: Estimativa de esforo e prazo ....................................................................................... 68

Introduo ........................................................................................................................... 68
MTRICAS DE SOFTWARE
Contedo.............................................................................................................................. 69
COCOMO .......................................................................................................................... 69
COCOMO bsico.............................................................................................................. 69
Exemplos de COCOMO bsico ..................................................................................... 70
COCOMO intermedirio ................................................................................................. 73
COCOMO avanado........................................................................................................ 76
COCOMO avanado: Spider-CoCoMo ........................................................................ 76
COCOMO II ....................................................................................................................... 78
Mtodo de Putnam.......................................................................................................... 79
Complexidade ciclomtica ............................................................................................ 79
Complexidade ciclomtica ............................................................................................ 80
Concluses........................................................................................................................ 81
Referncias........................................................................................................................... 81
Conteudista ...........................................................................................................................88
MTRICAS DE SOFTWARE
Qualquer empresa nasce com o sonho de ser bem-sucedida, mas nem todas
so vencedoras, e algumas at morrem antes de completar seu primeiro ano.
Empresas de sucesso so aquelas que trabalham com foco na gesto da
qualidade e do conhecimento.
No caso de PROJETO, verificamos que o gerenciamento necessrio, mas no
podemos gerenciar aquilo que impossvel medir.
A gesto do desenvolvimento, da manuteno e da prestao de servios
relacionados ao software que envolve custo, prazo e qualidade passou,
ento, a ser relevante. Afinal, esses fatores se constituem, hoje, como o
diferencial entre as empresas.
Plataformas como ITIL, CMMI e MPS-BR colocam as mtricas e as medies
como prticas fundamentais para a gesto de software com padro de
qualidade o que tornou sua medio uma obrigao.
Nesse sentido, esta disciplina pretende desenvolver no profissional da rea a
viso gerencial baseada na preocupao com o custo, a produtividade, a
qualidade e novas mtricas, bem como com suas formas de medio e suas
limitaes.
MTRICAS DE SOFTWARE
muito importante que voc conhea as tcnicas de gerenciamento de projeto

de software e saiba estabelecer parmetros para futuras medies.
Sendo assim, esta disciplina tem como objetivos:
1. Definir medida e mtrica de software;
2. Identificar as formas de medio, de estimativa e de acompanhamento de
um projeto de software, bem como os parmetros para futuros projetos;
3. Descrever as mtricas mais usuais para fins de medio do esforo no
desenvolvimento de um software.
MTRICAS DE SOFTWARE
Introduo
Voc ter oportunidade de desenvolver os Conceitos de mtricas e medies
para software, medidas diretas e indiretas, medidas no software pronto (kloc).
Toda empresa j nasce com o sonho de ser bem-sucedida, porm muitas
delas nem chegam a completar seu primeiro ano. Empresas de sucesso so
aquelas que esto trabalhando com foco na gesto da qualidade e do
conhecimento. No entanto, no se pode gerenciar o que no se pode medir.
Assim, plataformas como ITIL, CMMI, MPS-BR e outras, colocam as mtricas e
medies como prticas fundamentais para a gesto de software com padro
de qualidade.
A qualidade tornou a medio do software nos seus diversos aspectos uma
obrigao. Deve-se desenvolver no profissional de software a viso gerencial,
assim como a preocupao com custo, produtividade, qualidade e novas
mtricas, suas formas de medio e suas limitaes. Ele deve conhecer
conceitos para medir o software (produtividade, qualidade, prazo, tamanho
etc.) desde a fase de especificao de requisitos. Para tal, deve conhecer
tcnicas e ferramentas em suas medidas nas diversas fases do projeto.
Preparado para iniciar a aula? Bons estudos!
Objetivo:
1. Compreender os conceitos das mtricas e das medies de software;
2. Entender o que envolve a qualidade de software.
MTRICAS DE SOFTWARE
Contedo
Mtricas para Software
Ento, o prprio mercado exige, hoje, a gesto da qualidade, do conhecimento
e sabe-se que no se pode gerenciar o que no se pode medir. No entanto,
como medir valores como o conhecimento ou a qualidade?
Sabemos que todo processo de engenharia necessita de medies para
entender melhor os modelos e avaliar a quantidade dos produtos construdos.
No caso da engenharia de software que no fundamentada nas medidas
quantitativas diretas, como voltagem, temperatura, velocidade as suas
medidas e mtricas so na sua maioria indiretas.
Medio o processo pelo qual so atribudos valores numricos ou simblicos
s caractersticas de uma entidade qualquer, definidos de acordo com regras
bem definidas. Na cincia da computao, podemos medir os atributos, antes
considerados incomensurveis ainda que alguns especialistas em software
continuem a argumentar que o software incomensurvel.
O que mtrica?
Por sua natureza, a engenharia uma disciplina quantitativa. A mtrica de
produto ajuda os engenheiros de software a visualizar o projeto e a construo
do software, focalizando atributos especficos e mensurveis dos artefatos da
engenharia de software.
Quem realiza?
Os engenheiros de software usam mtricas de produto para ajud-los a criar
software da mais alta qualidade.

Haver sempre um elemento qualitativo na criao de software. O problema
que a avaliao qualitativa pode no ser suficiente. Fazem-se necessrios
critrios objetivos para ajudar a direcionar o projeto de dados,
arquitetura, interfaces e componentes. Ao testar, necessitamos de
MTRICAS DE SOFTWARE
orientao quantitativa que nos auxiliar na seleo de casos de teste

e seus objetivos.
A mtrica de produto proporciona uma base por meio da qual a anlise,
projeto, codificao e teste podem ser conduzidos mais objetivamente e
avaliados de maneira mais quantitativa.
Haver sempre um elemento qualitativo na criao de software. O problema
que a avaliao qualitativa pode no ser suficiente. Fazem-se necessrios
critrios objetivos para ajudar a direcionar o projeto de dados,
arquitetura, interfaces e componentes. Ao testar, necessitamos de
orientao quantitativa que nos auxiliar na seleo de casos de teste
e seus objetivos.
A mtrica de produto proporciona uma base por meio da qual a anlise,
projeto, codificao e teste podem ser conduzidos mais objetivamente e
avaliados de maneira mais quantitativa.
Ateno
Haver sempre um elemento qualitativo na criao de software.
O problema que a avaliao qualitativa pode no ser
suficiente. Fazem-se necessrios critrios objetivos para
ajudar a direcionar o projeto de dados, arquitetura,
interfaces e componentes. Ao testar, necessitamos de
orientao quantitativa que nos auxiliar na seleo de
casos de teste e seus objetivos.
A mtrica de produto proporciona uma base por meio da qual a
anlise, projeto, codificao e teste podem ser conduzidos mais
objetivamente e avaliados de maneira mais quantitativa.
MTRICAS DE SOFTWARE
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 so as etapas envolvidas?

O primeiro passo no processo de medio definir as mtricas apropriadas
para o software.
Em seguida, coletam-se os dados necessrios para aplicar as mtricas
formuladas.
Uma vez computadas, as mtricas so analisadas com base em diretrizes
preestabelecidas e dados do passado.
Os resultados das anlises so interpretados para obter informaes
sobre a qualidade do software.
Os dados da interpretao levam modificao dos requisitos e modelos
de projeto, cdigo-fonte ou casos de teste.
Qual o artefato (produto)?
O produto, no caso, so as mtricas computadas por meio de dados
coletados dos requisitos e modelos de projeto, cdigo-fonte e casos
de teste.
Como garantir que o trabalho seja realizado corretamente?

Estabelea os objetivos da medio antes de iniciar a coleta de dados, definindo
cada mtrica de produto de maneira no ambgua. Defina apenas algumas
MTRICAS DE SOFTWARE
mtricas e, ento, use-as para obter informaes sobre a qualidade do artefato

de software.
Embora as mtricas de produto para software sejam imperfeitas, podem
proporcionar uma maneira sistemtica de avaliar a qualidade com base em um
conjunto de regras claramente definidas. Elas tambm proporcionam uma viso
objetiva, que vai direto ao ponto e no aps o fato. Isso permite descobrir e
corrigir problemas potenciais antes que se tomem defeitos catastrficos.
Avaliao 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 indicao em
tempo real da eficcia dos modelos de requisitos, projeto e cdigo, da
eficcia dos casos de teste e da qualidade geral do software que ser
criado.
Qualidade de Software
O desenvolvimento de sistemas de software envolve uma srie de atividades
em que as oportunidades de falhas so muito grandes.
Os erros podem aparecer no incio do processo devido a alguns fatores:
Objetivos mal definidos;
Erros em fases de projeto e desenvolvimento.
Ningum tolera erros, por isso o desenvolvimento de software tem que ter
garantia de qualidade.
A atividade de teste de software um elemento crtico da garantia de qualidade
de software e representa a ltima reviso de especificao, projeto e
codificao.
MTRICAS DE SOFTWARE
10
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
MTRICAS DE SOFTWARE
11
Garantia de qualidade
A garantia de qualidade de software (Software Quality Assurance) no algo
com a qual comeamos a nos preocupar depois que o cdigo foi gerado, e sim
ao longo de todo o processo de engenharia de software. A SQA ou GQS
abrange:
Mtodos e ferramentas de anlise, projeto, codificao e teste;
Revises tcnicas em cada fase do desenvolvimento;
Estratgia de teste;
Documentao de software e das mudanas efetuadas;
Padres de desenvolvimento de software;
Mecanismos de medio.
Fatores determinantes para a garantia da qualidade

Os requisitos de software so a base a partir da qual a qualidade medida.
A falta de conformidade aos requisitos significa falta de qualidade.
Padres especificados definem um conjunto de critrios de desenvolvimento
que orientam a maneira segundo a qual o software passa pelo trabalho de
engenharia. Se os critrios no forem seguidos, o resultado quase que
seguramente ser a falta de qualidade.
MTRICAS DE SOFTWARE
12
Conjunto
de
requisitos
que
no
so
mencionados
(ex.:
boa
manutenibilidade). Caso o software se adque aos requisitos explcitos, mas

no aos implcitos, sua qualidade ser suspeita.
Fatores de qualidade de McCall

McCall prope uma categoria de fatores que afetam a qualidade do software,
conforme mostra a figura.
Caractersticas operacionais
Corretude
Refere-se capacidade de um programa satisfazer sua especificao e cumprir
os objetivos visados pelo cliente. Ele faz aquilo que eu quero?
Confiabilidade
Refere-se capacidade de um programa executar a funo pretendida com a
preciso exigida. Ele se comporta com preciso o tempo todo?
Usabilidade
Refere-se ao esforo necessrio para aprender, operar, preparar a entrada e
interpretar a sada de um programa. Ele foi projetado para o usurio?
MTRICAS DE SOFTWARE
13
Integridade
Refere-se capacidade de controlar o acesso ao software ou a dados por
pessoas no autorizadas. Ele seguro?
Eficincia
Refere-se quantidade de recursos computacionais e de cdigo exigida para
que um programa execute sua funo. Ele rodar em meu hardware to bem
quanto possvel?
Caractersticas de manuteno
Manutenibilidade
Refere-se ao esforo exigido para localizar e reparar erros em um programa.
Posso consert-lo?
Flexibilidade
Refere-se ao esforo demandado para modificar um programa. Posso mud-lo?
Testabilidade
Refere-se ao esforo exigido para testar um programa a fim de garantir que ele
execute a funo pretendida. Posso test-lo?
Caractersticas de adaptao a novos ambientes

Portabilidade
Refere-se ao esforo exigido para transferir o programa de um ambiente para
outro. Serei capaz de us-lo em outra mquina?
Reusabilidade
Refere-se capacidade de um programa, ou partes, ser reusado em outras
aplicaes. Serei capaz de reutilizar parte do software?
MTRICAS DE SOFTWARE
14
Interoperabilidade
Refere-se ao esforo 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, preciso, interoperabilidade, atendibilidade e segurana.

Alm da funcionalidade, outros fatores da ISO 9126: confiabilidade, usabilidade,
eficincia, manutenibilidade e portabilidade.
SEGUNDO PRESSMAN:
O teste o ltimo reduto no qual a qualidade pode ser avaliada;
Voc no pode testar qualidade. Se ela no estiver l antes, ela no

estar l quando terminar de testar;
Otimismo o risco ocupacional da programao; teste o tratamento";
A qualidade de um software funo de quanto ele muda o mundo

para melhor.
Mtricas de indicadores e de produto

importante que voc entenda as diferenas sutis entre os termos medida,
medio e mtrica, empregados com frequncia.
MEDIDA
Sob o contexto de engenharia de software, medida proporciona uma indicao
quantitativa da extenso, quantidade, capacidade ou tamanho de algum
produto ou processo.
MEDIO
A medio o ato de determinar uma medida.
MTRICAS DE SOFTWARE
15
MTRICA
Segundo o IEEE (Standard Glossary of Software Engineering Terminology),
mtrica 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 nmero de erros
descobertos em um componente de software), foi estabelecida uma medida.
A medio ocorre como resultado da coleo de um ou mais pontos de dados
(por exemplo, um conjunto de revises de componentes e testes de unidade
investigado para coletar medidas do nmero de erros para cada um).
Uma mtrica de software relaciona as medidas individuais de alguma maneira
(por exemplo, o nmero mdio de erros encontrados por reviso ou o nmero
mdio 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 solues alternativas;
Identificar as restries administrativas e tcnicas.
Controle do software
impossvel controlar um software sem medies e feedback. No se pode
controlar o que no se pode medir e a extenso do controle depende da
preciso da medio. Qualquer coisa que no se pode medir est fora de
controle.
As medies e mtricas ajudam a entender o processo usado para se
desenvolver um produto de software e o prprio produto.
MTRICAS DE SOFTWARE
16
O produto e o processo em relao medio

Produto medido para avaliar a sua qualidade e processo medido para
melhor-lo. Para efetivar a medio necessrio ter em mos documentao
de efeitos passados e dados estatsticos de quantificao de efeitos futuros.
A medio e a inferncia estatstica so usadas em vrias reas para projetar
o desempenho futuro.
A medio pode levar a controvrsias e discusses como:
Que mtricas usar?
Como os dados compilados devem ser usados?
justo usar medies para se comparar pessoas, processos e produtos?
As estimativas mais importantes

A estimativa uma das principais atividades do planejamento de software:
Esforo humano exigido
Durao do projeto
Custo
Mtricas so frequentemente classificadas como mtricas do processo ou

mtricas do produto, e so aplicadas durante o processo de desenvolvimento
ou ao produto de software desenvolvido.
Mtricas do processo
As mtricas do processo quantificam atributos do processo de desenvolvimento
e do ambiente de desenvolvimento.
Mtricas
de
recursos:
experincia
do
programador,
custo
de
MTRICAS DE SOFTWARE
17
desenvolvimento e manuteno.
Mtricas para o nvel de experincia do pessoal: nmero de anos que

uma equipe est usando uma linguagem de programao; nmero de anos que
um programador est na organizao.
Outros fatores relacionados ao desenvolvimento incluem:
Tcnicas de desenvolvimento;
Auxlio para programao;
Tcnicas de superviso etc.
Mtricas do produto
So medidas do produto de software. Podem no revelar nada sobre como o
software foi desenvolvido.

Incluem:
O tamanho do produto (linhas de cdigo);
A complexidade da estrutura lgica (recurso for, while, repeat, fluxo

de controle ordem das instrues do programa e profundidade de
laos aninhados);
A complexidade da estrutura de dados;
Funes (tais como tipo de software: comercial, cientfico etc.).
Ateno
Nesse caso, importante que voc conhea um exemplo:
O nmero de defeitos descobertos durante o teste formal
depende do produto (nmero de segmentos de cdigo que esto
errados) e do processo usado na fase de teste (a extenso do
teste).
MTRICAS DE SOFTWARE
18
Mtricas diretas e mtricas indiretas

Medidas Diretas do Processo de Software:
Custo e esforo aplicados.
Medidas Diretas do Produto:
Nmero de linhas de cdigo produzidas (KLOC - Kilo Lines of Code ou
simplesmente mil linhas de cdigo); Velocidade de execuo; Tamanho de
memria; Nmero de defeitos registrados em um tempo qualquer.
Medidas Indiretas do Produto:
Qualidade;
Funcionalidade;
Complexidade;
Eficincia;
Confiabilidade;
Manutenibilidade.
Mtricas orientadas ao tamanho

Linhas de Cdigo (KLOC): uma linha de cdigo qualquer linha do texto de um
programa, exceto comentrios e linhas em branco, sem levar em conta o
nmero de comandos ou fragmentos de comandos em uma linha. Esto
includas na definio de linhas de cdigo todas as linhas que contm cabealho
do programa, declaraes e comandos executveis.
MTRICAS DE SOFTWARE
19
Vantagens:
fcil de calcular;
o fator mais importante para muitos modelos de estimativa.
Desvantagens:
Dependente da linguagem de programao;
Penalizam programas bem estruturados, porm mais curtos.
Mtricas orientadas funo

So medidas indiretas do software;
Concentram-se na funcionalidade ou utilidade do programa;
Funo: coleo de comandos executveis que realizam uma determinada
tarefa.
Princpios de medio
Formulao: criao de medidas e mtricas apropriadas para a

representao do software.
Coleo: no caso, refere-se ao mecanismo usado para acumular dados

necessrios para criar as mtricas formuladas.
Anlise: a computao das mtricas e a aplicao de ferramentas

matemticas.
Interpretao: relacionada avaliao de mtricas que resultam em

informaes sobre a qualidade da representao.
Feedback: so recomendaes derivadas da interpretao de mtricas

de produto transmitidas para a equipe de software.
Atributos de mtricas eficazes de software

Centenas de mtricas j foram propostas para software, algumas demandam
medies muito complexas, outras so to esotricas que poucos profissionais
do mundo real tm qualquer esperana de entend-las, e outras ainda violam
as noes intuitivas bsicas do que realmente um software de alta qualidade.
MTRICAS DE SOFTWARE
20
Pressman (Engenharia de Software) elege atributos que devero ser abrangidos

por mtricas.
Planejamento
Anlise
Design
Programao
A seguir esto elencados os atributos que devem ser considerados pelas

mtricas segundo Pressman (Engenharia de Software):
Simples e computveis Dever ser relativamente fcil aprender a

derivar a mtrica, e sua computao no deve demandar esforo ou
tempo fora do normal.
Empiricamente e intuitivamente persuasiva A mtrica dever satisfazer

as ideias do engenheiro de software.
Consistente e objetiva A mtrica dever sempre produzir resultados

que no sejam ambguos. Um terceiro independente dever ser capaz de
derivar o mesmo valor da mtrica usando as mesmas Informaes sobre
o software.
Consistente no seu uso das unidades e dimenses A computao

matemtica da mtrica dever usar medidas que no resultem em
combinaes bizarras de unidades. Por exemplo, multiplicar nmero de
pessoas nas equipes de projeto pelas variveis da linguagem de
programao no programa resulta em uma mistura duvidosa de
unidades que no claramente convincente.
Independente da linguagem de programao As mtricas devero ser

baseadas no modelo de requisitos, modelo de projeto ou na prpria
estrutura do programa. Elas devero ser independentes dos caprichos da
sintaxe ou semnticas das linguagens de programao.
MTRICAS DE SOFTWARE
21
Um mecanismo efetivo para feedback de alta qualidade A mtrica

dever fornecer informaes que podem levar a um produto final de
melhor qualidade.
Atividade Proposta
Discuta sobre a importncia da adoo de mtricas no processo de qualidade
de software.
Chave de resposta: O processo de desenvolvimento de software deve ter o
foco na qualidade.
Referncias
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, mtodos e
padres, 3. ed. Rio de Janeiro: Editora LTC, 2009.
Bibliografia Complementar:
PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.
VAZQUEZ,C.E. , SIMES,G.S. , ALBERT,R.M. Anlise de ponto de funo
medio, estimativa e gerenciamento de projetos de software. So
Paulo: Editora rica, 2009.
Exerccios de fixao
Questo 1
Segundo Pressman, Qualidade de software a satisfao de requisitos
funcionais
de
desempenho
explicitamente
declarados,
normas
de
desenvolvimento explicitamente documentadas e caractersticas implcitas que

so 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 esto relacionados com operao, reviso
e transio de software;
MTRICAS DE SOFTWARE
22
III. Portabilidade Facilidade com que o software pode ser transposto de um

ambiente para outro.
Agora assinale a alternativa correta:
a) Todas as afirmativas esto corretas
b) Apenas a afirmativa III est correta
c) Apenas a afirmativa II est correta
d) Apenas as afirmativas I e III esto corretas
e) Apenas as afirmativas II e III esto corretas
Questo 2
A avaliao qualitativa no suficiente para medir o esforo do software.
preciso critrios objetivos para direcionar o projeto de dados, arquitetura,
interfaces
componentes.
Ao
testarmos,
necessitamos
de
orientao
quantitativa que nos auxiliar na seleo de casos de teste. A mtrica de

produto proporciona uma base por meio da qual a anlise, projeto, codificao
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) Esto corretas apenas as afirmativas I, III e IV
c) Esto corretas apenas as afirmativas I, II, III e V
d) Esto corretas apenas as afirmativas I, II, III e IV
e) Esto corretas apenas as afirmativas II, III, IV e V
Questo 3
Ningum tolera erros, por isso o desenvolvimento de software tem que ter
garantia de qualidade. Ele envolve uma srie de atividades em que as
oportunidades de falhas so muito grandes e, consequentemente, os erros
MTRICAS DE SOFTWARE
23
podem aparecer no incio 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
Questo 4
A garantia de qualidade de software (Software Quality Assurance) no algo
com a qual comeamos a nos preocupar depois que o cdigo 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 documentao de software e das mudanas efetuadas
b) Mtodos e ferramentas de anlise, projeto, codificao e teste
c) Estratgia de teste
d) Padres de desenvolvimento de software
e) Mecanismos de medio
Questo 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 no pode testar qualidade. Se ela no estiver l antes, ela no estar
l quando terminar de testar;
III. Otimismo o risco ocupacional da programao; teste o tratamento;
IV. A qualidade de um software funo de quanto ele muda o mundo para
melhor.
b) Esto corretas apenas as afirmativas I, III e IV
c) Esto corretas apenas as afirmativas I, II e III
d) Esto corretas apenas as afirmativas I, II e IV
MTRICAS DE SOFTWARE
24
e) Esto corretas apenas as afirmativas II, III e IV

Questo 6
Assinale a alternativa correta:
a) Na engenharia de software no existe diferena entre medio e medida.
b) Considerando o tempo de existncia, a engenharia de software e a
engenharia civil se equivalem em maturidade.
c) Uma mtrica mal especificada no gera qualquer influncia para tomada
de deciso de baixa qualidade.
d) pesar de existirem mtricas de processo e de projeto, no existem
mtricas de produto.
e) Medida diferente de mtrica e pode ser realizada de forma direta ou
indireta.
Questo 7
No contexto de engenhada de software, medida pode ser definida como:
a) O ato de determinar uma medida.
b) Proporciona uma indicao quantitativa da extenso, quantidade,
capacidade ou tamanho de algum produto ou processo.
c) um conceito matemtico relacionado distncia de um mdulo ao
seguinte.
d) a diviso de um software em fragmentos marcados por tempo e custo.
e) um conceito relacionado gerncia de projetos.
Questo 8
O processo de desenvolvimento de software deve ser continuamente medido
durante seu desenvolvimento. Para isso necessrio:
I. Criar uma cultura de medio e mtrica (desenvolvimento com bases
tcnicas);
II. Catalogar em base de dados histricos;
III. Padronizando em metros ou centmetros, cada medida obtida.
a) Completam o enunciado as afirmativas I e II
MTRICAS DE SOFTWARE
25
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
Questo 9
Uma linha de cdigo qualquer linha do texto de um programa, exceto
comentrios e linhas em branco, sem levar em conta o nmero de comandos
ou fragmentos de comandos em uma linha. So medidas em Quilo de Linhas de
Cdigo ou mil linhas (KLOC). Esto includas na definio de linhas de cdigo
todas as linhas que contm cabealho do programa, declaraes e comandos
executveis. Analise as afirmativas sobre KLOC e responda:
I. fcil de calcular;
II. um fator importante para muitos modelos de estimativa;
III. Depende da linguagem de programao;
IV. Penalizam programas bem estruturados, porm mais curtos.
a) Esto corretas as afirmativas I, III e IV
b) Esto corretas as afirmativas I, II e III
c) Esto corretas as afirmativas I, II e IV
d) Esto corretas as afirmativas II, III e IV
e) Todas as afirmativas esto corretas.
Questo 10
A estimativa uma das principais atividades do planejamento de software.
Mtricas so frequentemente classificadas como mtricas do processo ou
mtricas do produto e so aplicadas durante o processo de desenvolvimento ou
ao produto de software desenvolvido. Com relao s estimativas de software
marque a afirmativa correta (forma completa):
a) Para uma aplicao existente ou nova desejamos saber quanto tempo
ser necessrio para o desenvolvimento e tambm quanto o custo.
b) Para uma nova aplicao desejamos saber quanto tempo ser necessrio
para fazer.
MTRICAS DE SOFTWARE
26
c) Para uma aplicao existente desejamos saber quanto tempo ser

necessrio para fazer uma alterao.
d) Para uma aplicao existente desejamos saber qual o custo de uma
alterao.
e) Para uma nova aplicao desejamos saber qual o custo da aplicao.
Aula 1
Exerccios de fixao
Questo 1 - A
Justificativa: Software que no segue os requisitos no oferece qualidade; O
fatores de Mc Call so exatamente operao, reviso e transio de software; A
portabilidade uma exigncia hoje, o que permite que o software possa ser
executado em mais de um sistema operacional.
Questo 2 - A
Justificativa: Para determinarmos o esforo empregado no software devemos
medir custo, prazo, recursos fsicos e pessoas, a complexidade e o tamanho.
Portanto, todas as afirmativas esto corretas.
Questo 3 - A
Justificativa: No incio do desenvolvimento devemos aplicar a caracterstica da
abstrao, isto , nos preocuparmos com o que mais importante para o
momento como, por exemplo, a definio clara dos objetivos e dos requisitos e
a elaborao de um bom planejamento do projeto, e deixar alguns detalhes
para mais adiante. O planejamento de implantao e disponibilizao do
software deve ser feito em outra etapa.
Questo 4 - A
Justificativa: Um dos requisitos da qualidade do software a documentao.
Software sem documentao se distancia das normas de qualidade. Qualidade
MTRICAS DE SOFTWARE
27
de software inclui padres de medio e uso adequado de ferramentas de

desenvolvimento, implementao e teste.
Questo 5 - A
Justificativa: Todas as afirmativas esto registradas em Engenharia de
Software de Roger Pressman (6 Ed. p. 340-350).
Questo 6 - E
Justificativa: Podemos ter medidas diretas como nmero de linhas de cdigo
produzidas ou velocidade de execuo e medidas indiretas como qualidade,
funcionalidade, complexidade.
A opo a est errada, pois medio um processo, j medida usada para
avaliar a qualidade do produto.
A opo b: engenharia civil existe h milnios.
A opo c: mtrica mal especificada afeta a qualidade do produto.
A opo d: Os engenheiros de software usam mtricas de produto para
ajud-los a criar software da mais alta qualidade.
Questo 7 - B
Justificativa: Medida a quantificao de algo que se quer medir. Por exemplo:
o tamanho do software em KLOC ou pontos por funo. um conceito
matemtico, porm, no para medir distncia entre mdulos e nem a diviso de
um software.
Questo 8 - A
Justificativa: Criar uma cultura de medio de software e registrar os dados
histricos para que possam ser utilizados em projetos futuros so contribuies
para a qualidade do software. O software jamais ser medido em metros ou
centmetros.
MTRICAS DE SOFTWARE
28
Questo 9 - E
Justificativa: KLOC uma mtrica orientada ao tamanho e de fcil obteno e
independente da linguagem usada. pois bastar contar o nmero de linhas,
exceto os comentrios. Por outro lado, programas orientados a objetos e bem
estruturados so penalizados por esta mtrica.
Questo 10 - A
Justificativa: Todas as afirmativas so verdadeiras, porm, a mais completa a
que fala em tempo e custo, isto , a opo a.
MTRICAS DE SOFTWARE
29
Introduo
Nesta aula, voc compreender como devem ser usadas as seguintes mtricas:
Pontos por Funo (PF); Ponto por Funo No Ajustado (PFNA); Pontos por
Funo para Diagrama de Fluxo de Dados (DFD) simples; Mtodo para
Estimativa de Custo; Contagem de Pontos por Funo de Projetos de
Manuteno; 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 Funo;
2. Compreender a aplicao dos Pontos por Funo.
MTRICAS DE SOFTWARE
30
Contedo
Mtricas baseadas em funo ou Pontos por Funo (PF)
Para que servem os Pontos por Funo?
Pontos por Funo medem o tamanho funcional do software.
Da mesma forma que somente os metros quadrados so insuficientes para
administrar uma construo, PF so insuficientes para administrar um projeto
de SW.
Para que servem as mtricas Pontos por Funo?
A mtrica Ponto por Funo pode ser usada efetivamente como um meio para
medir a funcionalidade fornecida por um sistema. Por meio de dados histricos,
a mtrica FP pode ser empregada para:
Estimar o custo necessrio para projetar, codificar e testar o software;
Prever o nmero de erros que sero encontrados durante o teste;
Prever o nmero de componentes e/ou o nmero de linhas projetadas

de cdigo-fonte no sistema implementado.
Valores do domnio de informaes

A mtrica Pontos por Funo est baseada em medidas calculveis (diretas) do
domnio do software e avaliaes qualitativas da complexidade do software.
Valores do domnio de informaes so definidos da seguinte maneira:
Entradas externas (number of external inputs - EEs): cada entrada
externa originada de um usurio ou transmitida de outra aplicao e fornece
dados distintos orientados aplicao ou informaes de controle.
Arquivos lgicos internos (internal logic files - ILFs): as entradas devem
ser diferenciadas das consultas, que so contadas separadamente. Cada
MTRICAS DE SOFTWARE
31
arquivo lgico interno um agrupamento lgico de dados que reside dentro das
fronteiras do aplicativo e mantido atravs de entradas externas.
Sadas externas (number of external outputs - EOs): cada sada externa
formada por dados derivados da aplicao e fornece informaes para o
usurio. So relatrios, telas, mensagens de erro etc.
Consultas externas (number of external inquiries - EQs): uma consulta
externa definida como uma entrada online que resulta na gerao de alguma
resposta imediata do software na forma de uma sada online.
Arquivos lgicos internos (number of internal logical files ILFs): cada
arquivo lgico interno um agrupamento lgico de dados que reside dentro das
fronteiras do aplicativo e mantido atravs de entradas externas.
Arquivos de interface externos (number of external interface files EIFs): cada arquivo de interface externo um agrupamento lgico de dados
que reside fora da aplicao, mas fornece informaes que podem ser usadas
pela aplicao.
Valores do domnio de informaes Tabela de PF

Uma vez coletados os dados, a tabela de PF preenchida associando um valor
de complexidade com cada contagem. Organizaes que usam mtodos Ponto
por Funo desenvolvem critrios para definir se determinada entrada
simples, mdia ou complexa. No entanto, a determinao da complexidade de
certo modo subjetivo. Veja o quadro:
MTRICAS DE SOFTWARE
32
Exemplo de aplicao de Ponto de Funo No Ajustado (PFNA)

Um software a ser desenvolvido necessita da aplicao da mtrica Pontos por
Funo. Segundo a equipe de desenvolvimento, a seguinte relao foi
determinada ainda na fase de requisitos em consonncia com o cliente em
funo dos arquivos que faro parte do software e seus respectivos pesos com
relao ao PF total.
Para calcular o PF devemos seguir os seguintes passos:

- Eleger um dos tipos de funo, preferencialmente aqueles que representam
altos percentuais, que so: Arquivos Internos - Entradas Externas - Sadas
Externas.
- Obter o nmero de ocorrncias do tipo de funo eleito.
- Calcular Pontos de Funo No Ajustados (PFNA).
MTRICAS DE SOFTWARE
33
- Utilizar o Fator de Ajuste da Complexidade = 1.

Durante as conversas preliminares com o cliente, verificou-se que os Arquivos
Internos seriam facilmente identificveis, o que os credenciou como melhor
parmetro para as estimativas de pontos de funo.
Verificou-se que o total de Arquivos Internos 13, portanto, complexidade
mdia, segundo a tabela definida pela equipe de desenvolvimento:
Conclumos que o software de complexidade Mdia, pois 13 est na faixa 6

a 19. Considere este nmero e veja a seguir a continuidade dos clculos.
Clculo 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)
Sadas Externas: 28% de 52 = 14,56 (~= 15)
Consultas: 14% de 52 = 7,28 (~= 7)
Obs.: os arredondamentos devem obedecer ao padro.
Tabela do PF
Podemos preencher a tabela de PF usando a coluna Complexidade Mdia.
MTRICAS DE SOFTWARE
34
Clculo do PFA
Ponto de Funo Ajustado (PFA)
Para calcular Pontos por Funo Ajustado, usa-se a seguinte relao:
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) so fatores de ajuste de valor (value adjustment factors VAF) baseados em respostas a 14 questes. Cada uma dessas perguntas
respondida por meio de uma escala que varia de 0 (no importante ou no
aplicvel) a 5 (absolutamente essencial). Observe:
1. O sistema requer salvamento (backup)?
2. So necessrias comunicaes de dados especializadas para transferir
informaes para a aplicao ou da aplicao?
3. H funes de processamento distribudo?
4. O desempenho crtico?
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 transao de entrada seja
composta em mltiplas telas ou operaes?
8. Os ILFs (arquivos lgicos) so atualizados on-line?
9. As entradas, sadas, arquivos ou consultas so complexas?
10. O processamento Interno complexo?
MTRICAS DE SOFTWARE
35
11. O cdigo projetado para ser reutilizvel?

12. A converso e Instalao esto includas no projeto?
13. O sistema projetado para mltiplas Instalaes em diferentes
organizaes?
14. A aplicao projetada para facilitar a troca e o uso pelo usurio?
Clculo do PFA aps respostas
Os valores constantes na Equao e os fatores de peso aplicados aos valores do
domnio de informaes so determinados empiricamente.
Dando prosseguimento ao exerccio, vamos imaginar que aps as respostas s
14 perguntas, Fi totalizou 42.
Ento:
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 aplicao da mtrica Pontos por
Funo. Segundo a equipe de desenvolvimento, a seguinte relao foi
determinada ainda na fase de requisitos em consonncia com o cliente em
funo dos arquivos que faro parte do software e seus respectivos pesos com
relao ao PF total.
MTRICAS DE SOFTWARE
36
O Diagrama de Fluxo de Dados avaliado para determinar um conjunto-chave

de medidas de domnio de informao necessrias para a computao da
mtrica ponto de funo:
entradas
externas
senha,
boto
de
emergncia
ativar/desativar.
2 consultas externas consulta de zona e consulta de sensor.
1 arquivo lgico interno (ILF) arquivo de configurao do

sistema.
2 sadas externas mensagens e estado do sensor.
arquivos
de
interface
externa
(EIF)
sensor
de
teste,
configurao de zona, ativar/desativar e alerta de alarme.
MTRICAS DE SOFTWARE
37
Clculo dos Pontos por Funo
O total da contagem apresentado no quadro Pontos por Funo deve ser

ajustado usando a Equao, supondo que:
(Fi) = 46
Portanto,
FP = 50 X [0,65 X (0,01 X 46)] = 56
Avance e acompanhe o Mtodo para Estimativa de Custo.
Mtodo para estimativa de custo exemplo SERPRO

A estimativa de custo do projeto deve levar em considerao o custo da mo de
obra, considerando o esforo e o custo da hora de todos os profissionais
envolvidos no desenvolvimento da soluo de software.
Alm do custo da mo de obra e recursos computacionais, devem ser
considerados outros custos, tais como:
MTRICAS DE SOFTWARE
38
Treinamento
Consultoria
Viagens
Licenas de software
Custos indiretos etc.
Clculo Custo do Projeto (CP)

Sugere-se a seguinte frmula para calcular o custo relativo mo de obra para
o desenvolvimento da soluo (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 = Esforo para implementar um Ponto por Funo na plataforma

em questo
Clculo Preo Fixo por Ponto por Funo

Caso o contrato seja de preo fixo por Ponto de Funo, ento pode-se
considerar o seguinte:
CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF)
Onde:
VPF = Valor Unitrio do PF para o projeto em questo - Identificado de

acordo com a Tabela de Servio Padro do Sistema de Oramento
Tcnico.
MTRICAS DE SOFTWARE
39
Contagem de Pontos por Funo de Projetos de Manuteno

Para que serve a contagem de Pontos por Funo de Projetos de
Manuteno?
Esta contagem tem como propsito descrever os diversos tipos de projetos de
manuteno e mostrar uma soluo para o seu dimensionamento em Pontos
por Funo, visto que o manual de prticas de contagem no contempla
projetos de manuteno (maintenance), apenas o de melhoria (enhancement).
Quanto documentao de projetos de manuteno pequenos (menores que
100 PF), deve-se registrar a solicitao do cliente e documentar os requisitos da
aplicao impactada pela demanda, de forma detalhada, visando apoiar a
contagem de Pontos de Funo da demanda.
importante tambm documentar as estimativas e a contagem de Pontos por
Funo.
Pontos de Casos de Uso (PCU)

Quais so as caractersticas?
possvel estimar o tamanho do sistema ainda na fase de levantamento de
casos de uso.
Estima a dimenso do sistema de acordo com:
O modo como os usurios o utilizaro;
A complexidade de aes requeridas por tipo de usurio;
A anlise em alto nvel dos passos necessrios para a realizao 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;
MTRICAS DE SOFTWARE
40
Calcular fatores de ajuste;
Calcular o Porte do Sistema.
Calculando o peso dos Atores do Sistema

Aes
Encontrar a mtrica UAW (Unadjusted Actor Weight).
Classificar atores envolvidos em cada caso de uso.
Somar os produtos do nmero de atores de cada tipo pelo respectivo

peso.
Quadro Tipo de autor/peso
Exemplo
Um sistema projetado para dois tipos de usurios (gerente e usurio comum) e
que fosse acessado por um outro sistema utilizando-se de um protocolo de
comunicao, por exemplo, teria um valor de UAW de 8 (2 atores de nvel
complexo e 1 ator de nvel mdio).
UAW = (2 * 3) + (1 * 2)
UAW = 8
Atividade Proposta
Discuta sobre a importncia da adoo de mtricas no processo de qualidade
de software.
MTRICAS DE SOFTWARE
41
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 Funo, acesse o vdeo
disponvel em nossa biblioteca virtual.
Referncias
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, mtodos e
padres. 3. ed. Rio de Janeiro: Editora LTC, 2009.
PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.
VAZQUEZ, C.E. , SIMES, G.S., ALBERT, R.M. Anlise de ponto de funo
Exerccios de fixao
Questo 1
A Mtrica de software baseadas em Pontos por Funo mede:
a) O tamanho funcional do software.
b) A complexidade dos testes de software.
c) A extenso das sub-rotinas.
d) A quantidade de classes.
e) A qualidade do software.
Questo 2
A mtrica Ponto por Funo usa dados histricos para:
I Estimar o custo necessrio para projetar, codificar e testar o software.
MTRICAS DE SOFTWARE
42
II Prever o nmero de erros que sero encontrados durante o teste.

III Prever o nmero de componentes e/ou o nmero de linhas projetadas de
cdigo-fonte no sistema implementado.
a) Todas corretas
b) Apenas I
c) Apenas II
d) Apenas II e III
e) Apenas I e III
Questo 3
A mtrica Pontos por Funo est baseada em medidas calculveis do domnio
do software e avaliaes qualitativas da complexidade do software. Um dos
domnios, Entradas externas, definido como:
a) Originado de um usurio ou transmitido de outra aplicao e fornece
dados distintos aplicao ou informaes de controle.
b) Um agrupamento lgico de dados que reside dentro das fronteiras do
aplicativo.
c) Um agrupamento lgico de dados que reside fora da aplicao, mas
fornece informaes que podem ser usadas pela aplicao.
d) Uma entrada online que resulta na gerao de alguma resposta imediata
do software na forma de uma sada online.
e) Domnio formado por dados derivados da aplicao e que fornece
informaes para o usurio.
Questo 4
A mtrica Pontos por Funo est baseada em medidas calculveis do domnio
do software e avaliaes qualitativas da complexidade do software. Um dos
domnios, Arquivos lgicos internos, definido como:
a) Um agrupamento lgico de dados que reside dentro das fronteiras do
aplicativo.
b) Entrada originada de um usurio ou transmitida de outra aplicao e que
fornece dados distintos aplicao ou informaes de controle.
MTRICAS DE SOFTWARE
43
c) Um agrupamento lgico de dados que reside fora da aplicao, mas

fornece informaes que podem ser usadas pela aplicao.
d) Uma entrada online que resulta na gerao de alguma resposta imediata
do software na forma de uma sada online.
e) Domnio formado por dados derivados da aplicao e que fornece
informaes para o usurio.
Questo 5
Na gesto de escopo de software, trs elementos so essenciais em um projeto
de software. Analise as afirmativas e identifique-as como verdadeiras (V) ou
falsas (F).
( ) Aps a definio do escopo, no comum existirem mudanas no
desenvolvimento de projetos.
( ) A tcnica de reuso de software nunca vai beneficiar a qualidade do
projeto.
( ) A tcnica de reuso de software colabora para a reduo do prazo do
projeto.
( ) Mesmo as pequenas mudanas de escopo devem ser registradas e
analisadas.
( ) Profissionais que dominam a Anlise de Ponto por Funo fazem com
que o clculo da estimativa de esforo e custo seja uma cincia exata.
Questo 6
(CESGRANRIO 2012 Chesf) Um engenheiro de software fez uma contagem
de pontos por funo de um software a ser desenvolvido e levantou as
seguintes informaes:
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)
MTRICAS DE SOFTWARE
44
Considerando as possveis complexidades de cada funo de negcio, os

valores mnimos e mximos da contagem no ajustada de Pontos por Funo
sero respectivamente:
a) 143 e 363
b) 177 e 361
c) 177 e 363
d) 179 e 361
e) 179 e 363
Questo 7
Em que consiste a modalidade preo por PF (Ponto por Funo)?
a) o valor global que uma empresa fornecedora est cobrando para um
determinado servio.
b) o valor unitrio negociado com o qual se far a transao comercial
para um desenvolvimento de software.
c) um valor de referncia 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.
Questo 8
(FCC 2012 TRE-CE) Considere 3 AIEs simples, 5 EEs mdias, 8 CEs
complexas, 3 ALIs complexos e 7 SEs mdias. O clculo 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
MTRICAS DE SOFTWARE
45
d) 163
e) 212
Questo 9
A Anlise de Pontos por Funo (APF) uma tcnica para a medio 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 usurio.
Analise as afirmativas a seguir, relacionadas APF:
I uma ferramenta que permite determinar o tamanho de pacotes de
software adquiridos, atravs da contagem de todos os Pontos por Funo

includos no pacote.
II uma ferramenta que permite estimar custos e recursos envolvidos em
projetos de desenvolvimento e manuteno de software.
III O Ponto por Funo no 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 esto corretas
Questo 10
Uma das boas prticas 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 cobraro o mesmo valor pelo projeto.
b) Todos os fornecedores participaro de todas as propostas.
c) A contratante pode exigir que cada proposta apresente a quantidade de
Pontos por Funo do projeto de forma detalhada, o que tornar mais
fcil comparar as propostas.
MTRICAS DE SOFTWARE
46
d) A contratada pode exigir que cada proposta apresente a quantidade de

fcil comparar as propostas.
e) A contratada pode exigir que cada proposta apresente a quantidade de
difcil comparar as propostas.
Aula 2
Exerccios de fixao
Questo 1 - A
Justificativa: Por definio, Pontos por Funo medem o tamanho funcional do
software.
Questo 2 - A
Justificativa: Por melo de dados histricos, a mtrica FP pode ser empregada
para estimar o custo, prever o nmero de erros que sero encontrados durante
o teste e prever o nmero de componentes e/ou o nmero de linhas projetadas
de cdigo-fonte.
Questo 3 - A
Justificativa: Entrada externa no reside dentro do aplicativo. fornecida pelo
usurio e/ou por outra aplicao.
Questo 4 - A
Justificativa: Arquivo lgico interno, conforme o seu nome diz, reside dentro da
fronteira do software.
MTRICAS DE SOFTWARE
47
Questo 5 - F, F, V, V, F
Justificativa: A maioria dos projetos passa por mudanas ao longo do ciclo de
vida. Mtrica de software no pretende obter medidas exatas, mas uma
estimativa de esforo.
A tcnica de reuso recomendada no desenvolvimento de software e na sua
qualidade. Toda alteraes no software deve ser documentada.
Portanto, a resposta correta F-F-V-V-F
Questo 6 - E
Justificativa: Mnimo: (8 x 3) + (10 x 4) + (0 x 3) + (15 x 7) + (2 x 5) = 179
Mximo: (8 x 6) + (10 x 7) + (0 x 6) + (15 x 15) + (2 x 10) = 363
Questo 7 - B
Justificativa: A tcnica Pontos por funo usado pelos desenvolvedores par
determinar o esforo no desenvolvimento do software. Assim, o custo do
software pode ser estimado.
Questo 8 - D
Justificativa: Soluo: (3 x 5) + (5 x 4) + (8 x 6) + 3 x 15) + (7 x 5) = 163
Questo 9 - D
Justificativa: Pontos por funo ajustado definido pelo produto da contagem
por um fator de ajuste, o que contradiz o item III.
A tcnica Pontos por Funo determina o tamanho do software e os custos
correspondentes.
Questo 10 - C
Justificativa: Nos editais das licitaes pblicas para desenvolvimento de
software, pontos por funo tem sido uma exigncia do contratante.
MTRICAS DE SOFTWARE
48
Introduo
Nesta aula, voc compreender :
Mtricas para modelo de projeto;
Fan-out e Fan-in;
Conectividade;
Mtricas de projeto da arquitetura;
Mtricas para projeto orientado a objeto;
Acoplamento e Mtricas orientadas classe.
Esta abordagem muito importante para determinar o tamanho do software.
Bons estudos!
Objetivo:
1. Compreender as mtricas para o modelo de projeto de acordo com os
parmetros de dimenso do software Fan-out e Fan-in;
2. Entender as mtricas para o modelo de projeto de acordo mtricas de
projeto da arquitetura.
MTRICAS DE SOFTWARE
49
Contedo
Contextualizao
inconcebvel que o projeto de um novo avio, um novo chip de computador
ou um novo edifcio comercial...
... seja conduzido sem a definio de medidas, sem determinar mtricas
para os vrios aspectos de qualidade e sem us-las como indicadores para
orientar a maneira pela qual o projeto evoluir.
E, alm disso, o projeto de sistemas complexos baseados em software muitas
vezes realizado praticamente sem nenhuma medio.
A ironia disso tudo que as mtricas de projeto para software esto
disponveis, mas a grande maioria dos engenheiros de software continua
ignorando sua existncia.
As mtricas de projeto para software de computador, como todas as outras
mtricas de software, no so perfeitas.
Continua o debate sobre sua eficcia e a maneira pela qual deveriam ser
aplicadas.
Muitos especialistas argumentam que necessria mais experimentao para
que as medies de projeto possam ser usadas. E, alm disso, projeto sem
medio uma alternativa inaceitvel.
Examinaremos a seguir algumas das mtricas de projeto mais comuns para
software de computador. Cada uma delas pode proporcionar uma melhor

visualizao, e todas podem ajudar o projeto a evoluir para um nvel maior de
qualidade.
MTRICAS DE SOFTWARE
50
Fan-out e Fan-in
A hierarquia de controle, tambm chamada estrutura de programa, representa
a organizao dos mdulos de programa.
Ela no representa aspectos procedimentais de software, tais como sequncia
dos processos, ocorrncia/ordem das decises ou repetio de operaes.
A notao mais comum para representar a hierarquia mostrada na figura.
Notamos que profundidade e largura constituem uma indicao do nmero de
nveis de controle e do espao de controle global, respectivamente.
Fan-out
uma medida do nmero de mdulos que so diretamente controlados por
outro mdulo, isto , o nmero de subordinados imediatos para aquele mdulo.
Fan-in
Indica quantos mdulos controlam diretamente determinado mdulo, isto , o
Fan-in de um mdulo indica o nmero de superiores imediatos que ele possui.

O relacionamento de controle entre os mdulos expresso da seguinte
maneira: um mdulo que controla outro superordenado a ele e,
inversamente, que um mdulo controlado por outro subordinado ao
controlador.
Na figura, o mdulo X superordenado aos mdulos A, B, C. O mdulo H
subordinado ao mdulo E, que subordinado ao mdulo A.
Fan-out e Fan-in: caractersticas

A hierarquia de controle tambm representa duas caractersticas distintas:
visibilidade e conectividade.
MTRICAS DE SOFTWARE
51
Visibilidade
Indica o conjunto de componentes de programas que pode ser invocado ou
usado como dados por um determinado componente. Por exemplo, um mdulo
de um sistema orientado a objeto pode ter acesso a uma ampla sucesso de
objetos de dados que ele herdou, mas s faz uso de um pequeno nmero
desses objetos de dados.
Conectividade
Indica o conjunto de componentes que diretamente invocado ou usado como
dados por determinado componente. Por exemplo, um mdulo que faa
diretamente outro mdulo iniciar a execuo conectado a ele.
Fan-out
Deve-se ter no mximo 7 subordinados.
Fan-in
Deve-se manter alto o nmero de superiores. Alto Fan-in a recompensa pelo
factoring inteligente e a remoo de mdulos restritivos.

Ter uma funo chamada por muitos superiores evita a necessidade de
codificar a mesma funo em vrios lugares. Portanto, em tempo de
manuteno, a duplicidade de alterao eliminada.
Mdulos com Fan-in devem ter boa coeso: funcional ou, no mnimo,
comunicacional ou sequencial.
Existem duas regras para restringir o uso de Fan-in:
Cada interface para um nico mdulo deve ter os mesmos nmeros e tipos de
parmetros. O exemplo a seguir contraria esta regra.
MTRICAS DE SOFTWARE
52
Mtricas de projeto da arquitetura

As mtricas de projeto da arquitetura focalizam as caractersticas da arquitetura
do programa com nfase na estrutura arquitetnica e na eficcia dos mdulos
ou componentes dentro da arquitetura.
Essas mtricas so uma caixa-preta no sentido de que elas no requerem
qualquer conhecimento do funcionamento interno de um determinado
componente de software.
Card e Glass [Car90] definem trs medidas de complexidade de projeto de
software:
Complexidade estrutural: Para arquiteturas hierrquicas (por exemplo,
arquiteturas de chamada e retorno), a complexidade estrutural de um
mdulo i definida da seguinte maneira:
Complexidade de dados: A complexidade dos dados (data complexity)
proporciona uma indicao da complexidade na interface Interna para um
mdulo i e definida como:
Em que v(i) o nmero de variveis de entrada e sada passadas para o do
mdulo i.
Complexidade de sistema: Por fim, a complexidade de sistema (system
complexity) definida como a soma da complexidade estrutural e de dados,

especificada como:
MTRICAS DE SOFTWARE
53
Ateno
medida que esses valores de complexidade aumentam, a
complexidade
global
da
arquitetura
do
sistema
tambm
aumenta.
Isso leva a uma maior probabilidade de que o trabalho de
integrao e teste tambm aumente.
Fenton [Fen91] sugere um conjunto de mtricas de morfologia simples (isto ,
forma) que permite que diferentes arquiteturas de programa sejam comparadas
usando uma srie de dimenses diretas. Referindo-se arquitetura de chamada
e retorno na Figura apresentada, podem ser definidas as seguintes mtricas:
Tamanho = n + a
em que n o nmero de ns e a o nmero 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 = nmero mximo de ns em qualquer nvel da arquitetura.
Logo, largura = 7
A relao arco para n,

r = a/n
mede a densidade de conectividade da arquitetura:
r= 24/19 = 1,26.
MTRICAS DE SOFTWARE
54
Indicadores de qualidade de software

A fora area americana (U.S. Air Force Systems Command) desenvolveu um
conjunto de indicadores de qualidade de software baseados nas caractersticas
de projeto mensurveis de um programa de computador. Usando conceitos
similares queles propostos na norma IEEE Std. 982.1-1988, a Fora Area usa
informao 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: Nmero total de mdulos definidos na arquitetura do programa.
S2: Nmero de mdulos cuja funo correta depende da origem dos

dados de entrada ou que produzem dados para serem usados em outro
lugar (em geral, mdulos de controle, entre outros, no seriam contados
como parte de S2).
S3: Nmero de mdulos cuja funo correta depende de processamento

anterior.
S4: Nmero de itens de base de dados (inclui objetos dados e iodos os

atributos que definem objetos).
S5: Nmero total de itens nicos de base de dados.
S6: Nmero de segmentos de base de dados (diferentes registros ou

objetos individuais).
S7: Nmero de mdulos com uma nica entrada e sada (processamento

de exceo no considerado mltipla sada).
Uma vez determinados os valores S1 at S7, para um programa de computador

podem ser calculados os seguintes valores intermedirios:
Estrutura de programa
D1, que definido da seguinte maneira:
MTRICAS DE SOFTWARE
55
Se o projeto da arquitetura foi desenvolvido por meio de um mtodo distinto

(por exemplo, projeto orientado a fluxo de dados (DFD) ou projeto orientado a
objeto (OO), ento D1 = 1, caso contrrio D1 = 0.
Independncia modular
D2 = 1 (S2/S1)
Mdulos no 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)
Caracterstica de entrada/sada do mdulo
D6 = 1 (S7/S1)
Clculo do DSQI
Com os valores intermedirios determinados, o DSQI calculado da seguinte
maneira:
DSQI = wi/D
Em que i = 1 a 6, w1 o peso relativo da importncia de cada um dos valores
intermedirios e W1 = 1 (se todos os Di tiverem o mesmo peso, ento w1 =
0,167).
MTRICAS DE SOFTWARE
56
Mtricas 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 viso mais objetiva das caractersticas do
projeto pode favorecer tanto o projetista experiente (que obtm uma viso
adicional) quanto o novato (que obtm uma indicao da qualidade que de
outra forma no estaria disponvel).
Em um tratamento detalhado de mtricas de software para sistemas orientados
a objeto, Whitmire descreve nove caractersticas distintas e mensurveis
de um projeto orientado a objeto:
1. Tamanho. definido em termos de quatro visualizaes: populao,
volume, comprimento e funcionalidade. Populao medida tomando-se
uma contagem esttica das entidades orientadas a objeto, como classes
ou operaes. Medidas de volume so idnticas s medidas de
populao, mas so coletadas dinamicamente - em determinado instante
do tempo. Comprimento a medida de uma cadeia de elementos de
projeto interconectados (por exemplo, a extenso de uma rvore de
herana uma medida do comprimento). As mtricas de funcionalidade
proporcionam uma indicao indireta do valor fornecido ao cliente por
uma aplicao orientada a objeto.
2. Complexidade. Assim como o tamanho, h muitas vises diferentes da
complexidade do software. Whitmire v a complexidade em termos de
caractersticas estruturais examinando como as classes de um projeto
orientado a objeto se inter-relacionam.
MTRICAS DE SOFTWARE
57
3. Acoplamento. As conexes fsicas entre elementos do projeto orientado

a objeto (por exemplo, o nmero de colaboraes entre classes ou o
nmero de mensagens passadas entre objetos) representam o
acoplamento em um sistema orientado a objeto.
4. Suficincia. Whitmire define suficincia como o grau com o qual uma
abstrao possui as caractersticas requeridas para ela, ou o grau com o
qual um componente de projeto possui caractersticas em sua abstrao,
do ponto de vista da aplicao corrente. Em outras palavras,
perguntamos: Que propriedades essa abstrao (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 domnio da aplicao que est modelando isto , que a abstrao (classe) possui as caractersticas necessrias para
ele.
5. Totalidade. A nica diferena entre totalidade e suficincia o
conjunto de caractersticas em relao s quais comparamos a abstrao
ou o componente de projeto. A suficincia compara a abstrao do
ponto de vista da aplicao corrente. A totalidade considera mltiplos
pontos de vista, formulando a pergunta: Que propriedades so
necessrias para representar completamente o objeto de domnio do
problema?. Em virtude do critrio da totalidade considerar diferentes
pontos de vista, ele tem uma implicao indireta no grau com o qual a
abstrao ou o componente de projeto pode ser reutilizado.
6. Coeso. Assim como seu correspondente no software convencional, um
componente orientado a objeto dever ser projetado de maneira que
tenha todas as operaes funcionando em conjunto para atingir um
objetivo nico e bem definido. A coerncia de uma classe determinada
examinando-se o grau segundo o qual o conjunto de propriedades que
ela possui faz parte do domnio do problema ou projeto.
MTRICAS DE SOFTWARE
58
7. Originalidade. Uma caracterstica similar simplicidade, originalidade

(aplicada tanto a operaes quanto a classes) o grau segundo o qual
uma operao atmica - isto , a operao no pode ser construda
por meio de uma sequncia de outras operaes contidas dentro de uma
classe que apresenta um alto grau de originalidade e encapsula apenas
operaes primitivas.
8. Similaridade. O grau segundo o qual duas ou mais classes so
similares em termos de sua estrutura, funo, comportamento ou
finalidade indicado por essa medio.
9. Volatilidade. Conforme j afirmamos multas vezes neste livro, podem
ocorrer alteraes de projeto quando os requisitos so modificados ou
quando acontecem modificaes em outras partes de um aplicativo,
resultando em adaptao obrigatria do componente de projeto em
questo. A volatilidade de um componente orientado a objeto mede a
possibilidade de que uma alterao venha a ocorrer.
Mtricas orientadas a classe o conjunto de mtricas CK

O que classe?
A classe a unidade fundamental de um sistema orientado a objeto. Portanto,
medidas e mtricas para uma classe individual para a hierarquia da classe e
colaboraes entre classes sero valiosas quando tivermos de avaliar qualidade
de projeto orientado a objeto.
Uma classe encapsula dados e a funo manipula os dados. Com frequncia o
pai das subclasses (s vezes chamadas de filhas) que herda seus atributos e
operaes. Muitas vezes elas colaboram com outras classes. Cada uma dessas
caractersticas pode ser usada como base para a medida.
Chidamber e Kemerer propuseram um dos conjuntos mais amplamente
conhecidos de mtricas de software orientado a objeto. Tambm chamado de
MTRICAS DE SOFTWARE
59
conjunto de mtricas CK (CK metrics suite), os autores propuseram seis

mtricas de projeto baseado em classe para sistemas orientados a objeto.
Vejamos uma delas:
Mtodos ponderados por classe (weighted methods per class - WMC).
Suponha que n mtodos de complexidade c1,c2 ,..., cn so definidos para uma
classe C. A mtrica especifica de complexidade escolhida (por exemplo,
complexidade ciclomtica) dever ser normalizada de maneira que a
complexidade nominal para um mtodo assuma o valor 1,0.
WMC = c1
Para i = 1 a n. O nmero de mtodos e sua complexidade so indicadores
razoveis do trabalho necessrio para implementar e testar uma classe.
Ateno
Quanto maior for o nmero de mtodos, mais complexa ser a
rvore de herana (todas as subclasses herdam os mtodos de
seus pais). Por fim, conforme o nmero de mtodos cresce para
uma dada classe, ela tende a se tornar cada vez mais especfica
de aplicao, limitando assim sua potencial reutilizao. Por
todas essas razes, o WMC dever ser mantido o mais baixo
possvel.
Embora pudesse parecer relativamente fcil desenvolver uma
contagem para o nmero de mtodos em uma classe, o
problema na realidade mais complexo do que parece. Dever
ser desenvolvida uma abordagem consistente de contagem.
MTRICAS DE SOFTWARE
60
Atividade Proposta
Discuta com seus colegas a importncia da adoo de mtricas no processo de
projeto de software a importncia do fan-in e fan-out em uma estrutura de
mdulos de projeto de software.
Chave
de
resposta:
FAN-OUT,
FAN-IN,
Complexidade
de
dados,
complexidade estrutural.
Referncias
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, mtodos e
PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.
VAZQUEZ, C.E. , SIMES,G.S., ALBERT, R.M. Anlise de ponto de funo
Exerccios de fixao
Questo 1
A estrutura de programa representa a organizao de seus mdulos. A
profundidade e largura da estrutura constituem uma indicao do nmero de
nveis de controle e do espao de controle global, respectivamente. A medida
que determina o nmero de mdulos que so diretamente controlados por
outro mdulo denominada:
a) Fan-in
b) Fan-out
c) Stubb
d) EAP
e) Hierarquia
MTRICAS DE SOFTWARE
61
Questo 2
A estrutura de programa representa a organizao de seus mdulos. A
profundidade e largura da estrutura constituem uma indicao do nmero de
nveis de controle e do espao de controle global, respectivamente. A medida
que indica quantos mdulos controlam diretamente determinado mdulo, isto ,
indica o nmero de superiores imediatos que ele possui denominado:
a) Fan-in
b) Fan-out
c) Stubb
d) EAP
e) Hierarquia
Questo 3
A caracterstica 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) Extenso
d) Conectividade
e) Navegabilidade
Questo 4
No Fan-out, quantos mdulos subordinados devemos ter, no mximo?
a) 3
b) 5
c) 6
d) 7
e) 8
Questo 5
No Fan-in, quantos mdulos superiores, no mximo, devemos ter?
MTRICAS DE SOFTWARE
62
a) O mnimo possvel
b) Alto nmero de superiores
c) 4
d) 5
e) 6
Questo 6
Em um tratamento detalhado de mtricas de software para sistemas orientados
a objeto, Whitmire descreve algumas caractersticas distintas e mensurveis de
um projeto orientado a objeto. Assinale a opo INCORRETA:
a) Volatilidade
b) Hierarquia
c) Similaridade
d) Originalidade
e) Coeso
Questo 7
As mtricas de projeto focalizam as caractersticas da arquitetura do programa
e so verdadeiras caixa-preta no sentido de que elas no requerem qualquer
conhecimento do funcionamento interno de um determinado componente de
software. So definidas trs medidas de complexidade de projeto de software:

a) Temporal, procedimental e casual.
b) Informacional, de dados e funcional.
c) Procedimental, funcional, hierrquico.
d) Estrutural, de dados e de sistema.
e) Lgica, funcional e de dados.
Questo 8
A complexidade dos dados proporciona uma indicao da complexidade na
interface interna do software para um mdulo i e definida como
D(i) = v(i)/[fout (i) + 1]
MTRICAS DE SOFTWARE
63
Onde fout (i) o Fan-out do mdulo i e v(i) o nmero de variveis de

entrada e sada passadas para o do mdulo i. Calcule a complexidade na
interface para o mdulo com um nmero total de variveis 19 e Fan-out 7.
a) 3,45
b) 6,70
c) 2,37
d) 3,98
e) 0,37
Questo 9
Calcule a complexidade do mdulo de um software com complexidade
estrutural 15 e complexidade dos dados 30.
a) 2
b) 450
c) 0,5
d) 45
e) 15
Questo 10
Uma estrutura de software possui 15 ns e 12 arcos. Qual o seu tamanho?
a) 180
b) 1,25
c) 3
d) 27
e) -3
Aula 3
Exerccios de fixao
Questo 1 - B
MTRICAS DE SOFTWARE
64
Justificativa: stub, em portugus esboo de mtodo, em desenvolvimento de

software, um pedao de cdigo usado para substituir algumas outras. J
STUBB nada, a no ser sobrenome como Alexander Stubb um poltico
finlands.
EAP = Sestrutura Analtica de Projeto, tcnica usada no gerenciamento de
projeto.
Hierarquia a ordenada distribuio dos poderes com subordinao sucessiva.
FAN-IN indica o nmero de superiores imediatos que ele possui denominado.
Fun-OUT a medida que determina o nmero de mdulos que so diretamente
controlados por outro mdulo denominada.
Questo 2 - A
Justificativa: stub, em portugus esboo de mtodo, em desenvolvimento de
software, um pedao de cdigo usado para substituir algumas outras. J
STUBB nada, a no ser sobrenome como Alexander Stubb um poltico
finlands.
EAP = Sestrutura Analtica de Projeto, tcnica usada no gerenciamento de
projeto.
Hierarquia a ordenada distribuio dos poderes com subordinao sucessiva.
FAN-IN indica o nmero de superiores imediatos que ele possui denominado.
Fun-OUT a medida que determina o nmero de mdulos que so diretamente
controlados por outro mdulo denominada.
Questo 3 - D
Justificativa: Conectividade como se mdulos estivessem conectados a
outros para serem chamados durante a execuo. Indica o conjunto de
componentes que diretamente invocado ou usado como dados por
determinado componente. Por exemplo, um mdulo que faa diretamente outro
mdulo iniciar a execuo conectado a ele.
Extenso significa comprimento, ou seja, a medida de uma cadeia de
elementos de projeto interconectados (por exemplo, a extenso de uma rvore
de herana uma medida do comprimento).
MTRICAS DE SOFTWARE
65
Factoring significa fatorar, dividir um mdulo em mdulos mmenores, o uqe

facilita a sua manuteno futura.
Visibilidade caracterstica que torna um aplicativo ou mesmo uma empresa
em algo que passa a ser percebido pelo mercado.
Navegabilidade - ...
Questo 4 - D
Justificativa: Em uma estrutura de mdulos de um programa, o Ideal que
tenhamos mdulos com alto fan-in (muitos mdulos chamando um determinado
mdulo) e baixo fan-out (um detreminado mdulo chamando o menor nmero
possvel de mdulos para evitar maior complexidade na lgica de programao
e futura manuteno do software). Segundo os autores devemos gter nom
mximo 7 fan-out.
Questo 5 - B
Justificativa: No fan-in, devemos ter o maior nmero possvel de mdulos
chamando um determinado mdulo. Isso facilita a lgca da programao e a
manuteno futura. Fan-in conta o nmero de funes que chamam uma
determinada funo.
O fan-in de um mdulo indica o nmero de mdulos que o utilizam, ou seja,
que tem relaes de uso com o modulo. * Um fan-in alto indica que o mdulo
representa uma abstrao bem definida e muito utilizada por outros mdulos.
Questo 6 - B
Justificativa:
Hierarquia
ordenada
distribuio
dos
poderes
com
subordinao sucessiva.
As caractersticas de Whitmire so: Tamanho, Comprimento, Complexidade,
Acoplamento, Suficincia, Totalidade, Volatilidade, Similaridade, Originalidade e
Coeso.
MTRICAS DE SOFTWARE
66
Questo 7 - D
Justificativa: Card e Glass definem trs medidas de complexidade de projeto de
software: complexidade estrutural, complexidade de dados, complexidade de
sistema.
Essas medidas so determinadas mediante frmulas e cculos simples.
Questo 8 - C
Justificativa: Aplicando a frmula, temos:
D = v / (fout + 1)
D = 19 / (7 + 1)
D = 19 / 8 = 2,37
Questo 9 - D
Justificativa: Complexidade de sistema (ou de um mdulo) definida como a
soma da complexidade estrutural e complexidade de dados. Portanto:
C = 15 + 30 = 45
Questo 10 - D
Justificativa: Tamanho = n + a
em que n o nmero de ns e a o nmero de arcos.
Tamanho = 15 + 12 = 27
MTRICAS DE SOFTWARE
67
Introduo
Nesta aula, voc compreender as seguintes tcnicas de estimativa: COCOMO
(bsico, intermedirio e detalhado); COCOMO II (estimativas de prazo, de custo
e de defeitos); mtodo de Putnam e a complexidade ciclomtica.
Objetivo:
1. Compreender as tcnicas de estimativa COCOMO e COCOMO II;
2. Entender o mtodo de Putnam e a complexidade ciclomtica.
MTRICAS DE SOFTWARE
68
Contedo
COCOMO
O que COCOMO?
COnstructive COst MOdel (COCOMO) um algortmico modelo de estimativa

do custo do software criado por Barry Boehm.
O modelo usa uma frmula bsica de regresso, com parmetros que so
derivados dos dados histricos e das caractersticas atuais dos projetos.
O mtodo 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 cdigo em linguagens de
programao Assembly.
O COCOMO consiste em trs implementaes: bsico, intermedirio e
avanado. Avance a tela e compreenda cada uma delas.
COCOMO bsico
COCOMO
bsico
um
modelo
esttico
que
calcula
esforo
de
desenvolvimento de software e seu custo em funo do tamanho de linhas de

cdigos desenvolvidas. Aplica-se s seguintes classes de projetos do software:
Orgnicos: so projetos relativamente pequenos, simples e com pouca
inovao, com equipes de dimenso relativamente pequena. Exemplo: mala
direta.
Semidestacado ou difuso (em tamanho e complexidade): so projetos
intermedirios com caractersticas entre o modo orgnico e o embutido, em que
as equipes de trabalho so heterogneas em termo de experincia, como, por
exemplo, um sistema de processamento de transaes (folha de pagamento).
MTRICAS DE SOFTWARE
69
Embutido ou restrito: aplicvel no desenvolvimento de sistemas complexos

embutidos em hardware, com muitas inovaes, restries severas e/ou
requisitos muito volteis e de confinamentos operacionais; exemplo: sistema de
controle de telefonia.
O COCOMO bsico um modelo esttico de valor simples, que calcula o

esforo do desenvolvimento de software em funo do tamanho deste
software, expresso em linhas de cdigo estimadas. Avance e veja alguns

exemplos.
Exemplos de COCOMO bsico

Uma vantagem do COCOMO bsico a sua rapidez em estimativas de custo
de software; porm, sua exatido limitada devido falta de fatores para
explicar as diferenas entre:
Ferramentas;
Qualidade de pessoal e experincia;
Uso de ferramentas modernas e tcnicas;
Outros atributos de projeto que influenciam nos custos de software.
MTRICAS DE SOFTWARE
70
Exemplo 1: Considere um software com 33,3 Kloc; usando o modelo

semidestacado, temos:
Logo, o nmero 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, aps uma anlise de ponto de funo, detectamos

236 PFs no ajustados e que, alm disso, as frmulas do COCOMO tenham sido
construdas com Kloc. Se a linguagem utilizada for ACCESS, temos:
MTRICAS DE SOFTWARE
71
TAMANHO = 38 x 236 (PF) = 8968 LOC = 8,968 KLOC

Usando o COCOMO bsico, o gerente considerou o projeto como orgnico.
Sendo assim, vamos usar as frmulas.
Logo, o nmero ideal de pessoas no projeto :

N = E/D = 36/4,3 = 8 pessoas
MTRICAS DE SOFTWARE
72
COCOMO intermedirio
O mtodo intermedirio uma extenso do mtodo bsico, porm, 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 Restries de desempenho de run-time;
II - Restries de memria;
III Mudanas do ambiente de software;
IV Tempo de resposta.
Atributos de pessoal
I Capacidade dos analistas;
II Capacidade dos programadores;
III Experincia na aplicao;
IV Experincia no ambiente de hardware;
V Experincia com a linguagem de programao.
Atributos do projeto
I Uso de ferramenta de software;
II Tcnicas modernas de programao;
III Prazo requerido para o desenvolvimento.
MTRICAS DE SOFTWARE
73
O COCOMO intermedirio calcula o esforo de desenvolvimento de software em

funo do tamanho do programa, que inclui custo, avaliao subjetiva do
produto, hardware, pessoal e atributos de projeto. Observe a frmula:
Considere que, no exemplo 2 (COCOMO intermedirio), o gerente considerou

o projeto como orgnico; portanto, usaremos as frmulas:
Clculo do EAF: primeiramente, o gerente analisou os 15 direcionadores da

tabela de multiplicadores de esforo:
MTRICAS DE SOFTWARE
74
Posteriormente, ele concluiu que:
Complexidade do software: Alta
Restries quanto ao uso da memria: Alto
Experincia com a linguagem de programao: Baixa
Capacidade dos programadores: Baixa
Os outros atributos foram considerados normais.

Assim, podemos calcular o EAF:
MTRICAS DE SOFTWARE
75
COCOMO avanado
No
COCOMO
avanado,
so
incorporadas
caractersticas
da
verso
intermediria com uma avaliao 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 necessrios
para cada etapa do ciclo de vida do produto.
COCOMO avanado: 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 construo de uma sute de ferramentas
livres para dar suporte implementao do modelo de qualidade MPS.BR
Melhoria de Processo de Software Brasileiro (SOFTEX, 2009).
Por que foi concebida?
Sua concepo ocorreu pela necessidade de uma forma sistematizada e simples
para realizar estimativas de projetos de software, pois a maioria das empresas
utilizam
planilhas
eletrnicas
e,
com
elas,
no
possvel
atender
completamente s necessidades dos gerentes, tendo em vista que no

possvel obter uma base histrica dos valores estimados nos projetos da
organizao.
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 prticas. Esse
modelo se divide em sete nveis de maturidade, partindo do nvel G, o mais
baixo, at o nvel A, o mais alto. medida que se passa de um nvel para o
MTRICAS DE SOFTWARE
76
outro, o processo entendido como mais maduro; cada nvel possui um

conjunto de atividades, denominados processos. Por fim, cada processo contido
em um nvel possui resultados esperados, que indicam que um determinado
item do processo em questo foi alcanado. A avaliao se d pela anlise de
cada resultado esperado dos processos.
A Spider-CoCoMo est inserida no contexto do processo Gerncia de Projetos,
auxiliando nas estimativas de custo, prazos e nmero 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 mtodos apropriados. A ferramenta necessita que o resultado esperado seja
cumprido, pois ele serve de parmetro para o clculo do CoCoMo. Em particular
para esse resultado esperado, o projeto SPIDER possui duas ferramentas para
medir o tamanho de projeto baseado no mtodo de anlise de pontos por
funo e pontos por casos de uso, que so a Spider-APF e a Spider-UCP
(BALDEZ, 2010).
Caso seja adotado qualquer outro tipo de mtodo que no os citados
anteriormente, o valor pode ser inserido manualmente na Spider-CoCoMo sem
que haja perda nos resultados estimados.
GPR 4
Requer que o esforo e os custos sejam estimados. Esse resultado esperado
totalmente atendido com a utilizao da Spider-CoCoMo tanto nos nveis G e F,
tendo em vista que o mtodo CoCoMo utilizado para estimativas, como dito
anteriormente, como nos nveis superiores ao F, pois os valores estimados so
armazenados em banco de dados, sendo feito um histrico deles. Esse o
grande diferencial da Spider-CoCoMo sobre as planilhas eletrnicas.
MTRICAS DE SOFTWARE
77
COCOMO II
O que o COCOMO II?
O COCOMO II (segunda verso do COCOMO COnstructive COst MOdel) um
modelo objetivo de custos para o planejamento e execuo de projetos de
software. Um modelo de custos fornece estrutura (framework) para a

comunicao
de
decises
de
negcio
entre
os
envolvidos
em
um
empreendimento baseado em software.

Alm disso, oferece suporte a negociaes contratuais, anlises de melhoria de
processo, aquisio de ferramentas, alteraes na arquitetura, decises entre
desenvolvimento e aquisio de componentes, assim como diversas outras
decises sobre retorno do investimento, servindo de base a estimativas plenas
de credibilidade.
Como se processa?
Embora a maioria das organizaes inicie o processo de estimativa utilizando
modelos lineares simples, o amadurecimento do processo de software leva
utilizao 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 indstria, oferece uma soluo aberta,
escalvel e respeitada.
Quais so suas vantagens?
O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um

componente individual;
O COCOMO pode calcular a programao da manuteno anual;
O COCOMO pode examinar a vantagem de dados histricos e, com essas

informaes, criar uma constante da calibrao que pode ser calculada
para estimativas futuras.
MTRICAS DE SOFTWARE
78
Qual a sua desvantagem?

Impreciso: sua preciso pode ser prejudicada no incio do projeto, pois o
modelo depende fortemente de uma estimativa precisa da quantidade de
linhas.
Mtodo de Putnam
O mtodo de Putnam considera mltiplas variveis e o ciclo de desenvolvimento
do projeto.
Com base em anlise estatstica, Putnam relacionou os comportamentos prazo
e esforo.
Equao de Putnam
Complexidade ciclomtica
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 ciclomtica do programa.
Complexidade ciclomtica ou complexidade condicional uma mtrica usada
para indicar a complexidade do software; mede a quantidade de caminhos de
execuo independentes a partir do cdigo fonte.
Como calculada?
calculada a partir de um grafo de fluxo: os ns do grafo correspondem a
grupos indivisveis de comandos, e uma aresta conecta dois ns.
MTRICAS DE SOFTWARE
79
Em que pode ser aplicada?

A complexidade ciclomtica tambm pode ser aplicada a funes, mdulos,
mtodos ou classes individuais de um programa.
Complexidade ciclomtica
Vamos a um exemplo?
Veja como calcular a complexidade ciclomtica para um artefato de software
(VG).
Clculo
V(G) = E N + 2P
Para:
E=8P=1
N=7
V(G) = 8 7 + 2 = 3
V(G) = 3
V(G): Complexidade ciclomtica;
G: Grafo (fluxograma);
MTRICAS DE SOFTWARE
80
E: Nmero de bordas (ligaes);

N: Nmero de ns (instrues);
P: Nmero de componentes conectados ao grfico (assumimos P = 1).
Concluses
No 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 mtodo;
um aspecto estratgico para a empresa.
Atividade Proposta
Discuta com seus colegas a importncia da adoo do modelo de estimativa de
ciusto COCOMO no processo de projeto de software a importncia de se
determinar a complexidade ciclomtica.
Chave de resposta: COCOMO, COCOMO II, Complexidade.
Referncias
PADUA Filho, Wilson de. Engenharia de Software: fundamentos, mtodos 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.; SIMES, G. S.; ALBERT, R. M. Anlise de ponto de funo
Exerccios de fixao
Questo 1
O mtodo COCOMO um modelo de estimativa do tempo de desenvolvimento
de um software, baseado no estudo de vrios projetos, dos quais foram
MTRICAS DE SOFTWARE
81
examinados de 2.000 a 100.000 linhas de cdigo em linguagens de

programao Assembly. Esse mtodo consiste em trs implementaes: bsico,
intermedirio e avanado.
O modelo bsico:
a) um modelo com atributos de controle, como: atributos do produto;
atributos de hardware; atributos pessoais; atributos do projeto. um
modelo com caractersticas da verso intermediria com uma avaliao
de impacto de custo em cada passo do projeto.
b) um modelo esttico que calcula o esforo de desenvolvimento de
software e seu custo em funo do tamanho de linhas de cdigos.

c) um modelo dinmico com caractersticas prprias que calcula o esforo
de cada programador.
d) um modelo sistmico que calcula as horas trabalhadas por cada equipe
do projeto.
Questo 2
O COCOMO bsico se aplica a trs classes de projetos do software; so elas:
a) Bsico, intermedirio e avanado
b) Orgnico, semidestacado e embutido
c) Bsico, semidestacado e restrito
d) Difuso, semidestacado e embutido
e) Orgnico, difuso e semidestacado
Questo 3
O COCOMO ____________________ aplicado no desenvolvimento de
sistemas complexos embutidos em hardware, com muita inovao, com
restries severas e/ou com requisitos muito volteis e de confinamentos
operacionais.
a) Difuso
b) Semidestacado
c) Orgnico
d) Funcional
MTRICAS DE SOFTWARE
82
e) Embutido
Questo 4
O COCOMO ____________________ mede projetos de software relativamente
pequenos, simples e com pouca inovao, com equipes de dimenso
relativamente pequena.
a) Avanado
b) Semidestacado
c) Orgnico
d) Funcional
e) Embutido
Questo 5
O COCOMO ____________________ aplicado quando as equipes de trabalho
so heterogneas em termo de experincia; por exemplo, um sistema de
processamento de transaes, como o controle de estoque.
a) Avanado
b) Semidestacado
c) Orgnico
d) Funcional
e) Embutido
Questo 6
O COCOMO II (segunda verso do COCOMO COnstructive COst MOdel) um
modelo objetivo de custos para o planejamento e execuo de projetos de
software. Um modelo de custos fornece uma estrutura (framework) para a

comunicao
de
decises
de
negcio
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.
MTRICAS DE SOFTWARE
83
c)Sua preciso pode ser prejudicada no inicio do projeto, pois o modelo

depende fortemente de uma estimativa precisa da quantidade de linhas.
d)Pode calcular a programao da manuteno anual.
e)Pode fazer exame da vantagem de dados histricos e criar uma constante
de calibrao que pode ser calculada para estimativas futuras.
Questo 7
O
__________________
considera
mltiplas
variveis
ciclo
de
desenvolvimento do projeto com base em anlise estatstica, relacionando os

comportamentos prazo e esforo.
a) Mtodo de esforo
b) Mtodo COCOMO
c) Mtodo COCOMO II
d) Mtodo de pontos por funo
e) Mtodo de Putnam
Questo 8
A complexidade ciclomtica ou complexidade condicional uma mtrica usada
para indicar a complexidade do software. Mede a quantidade de caminhos de
execuo independentes a partir do cdigo fonte. calculada a partir de um(a):
a) Tabela da arquivos lgicos
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
Questo 9
Analise esta tabela do COCOMO semidestacado.
MTRICAS DE SOFTWARE
84
Semidestacado
3,0
1,12
2,5
0,35
Agora, determine o nmero 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 = Esforo aplicado por pessoa no ms
D = Tempo de desenvolvimento em meses
a) 328 pessoas/ms 12 meses
b) 215 pessoas/ms 16,4 meses
c) 142 pessoas/ms 25,7 meses
d) 115 pessoas/ms 26,4 meses
e) 102 pessoas/ms 18 meses
Questo 10
Determine a complexidade ciclomtica de um software cujo grafo apresenta 12
bordas e 7 ns. Considere o nmero de componentes conectado igual a 1.
a) 5
b) 7
c) 19
d) 14
e) 84
Aula 4
Exerccios de fixao
Questo 1 - B
Justificativa: O modelo COCOMO bsico calcula o esforo do software em
funo das linhas de cdigo estimadas.
MTRICAS DE SOFTWARE
85
Questo 2 - B
Justificativa: Segundo Pressman (Engenharia de Software) as classes de
projetos referentes ao COCOMO bsico so Orgnico, Semi-destacado e
Embutido.
Questo 3 - E
Justificativa: Segundo Pressman (Engenharia de Software) as classes de
projetos referentes ao COCOMO bsico so Orgnico, Semi-destacado e
Embutido.
Questo 4 - C
Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO
Orgnicos representam projetos relativamente pequenos, simples e com pouca

inovao, com equipes de dimenso relativamente pequena. Exemplo: Mala
Direta.
Questo 5 - B
Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO Semi
destacado ou difuso - (em tamanho e complexidade) se refrem a projetos

intermedirios com caractersticas entre o modo orgnico e o embutido, em que
as equipes de trabalho so heterogneas em termo de experincia. Por
exemplo, um sistema de processamento de transaes. Exemplo: Folha de
Pagamento.
Questo 6 - A, B, D, E
Justificativa: Segundo Pressman (Engenharia de Software) as vantagens do
COCOMO II so:
O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um
componente individual.
O COCOMO pode calcular a programao da manuteno anual.
MTRICAS DE SOFTWARE
86
O COCOMO pode fazer exame da vantagem de dados histricos e com esses

dados criar uma constante da calibrao que pode ser calculada para
estimativas futuras.
Questo 7 - E
Justificativa: Segundo Pressman (Engenharia de Software) O mtodo de
Putnam considera mltiplas variveis e o ciclo de desenvolvimento do projeto.
Com base em anlise estatstica Putnam relacionou o comportamento prazo e
esforo.
Questo 8 - D
Justificativa: Segundo Pressman (Engenharia de Software), a complexidade
ciclomtica uma mtrica usada para indicar a complexidade do software.
Mede a quantidade de caminhos de execuo independentes a partir do cdigo
fonte. calculada a partir de um grafo de fluxo.
Questo 9 - B
Justificativa: Basta aplicar a frmula.
E = 3 x 451,12 = 3 x 71,0555 = 215 pessoas/ms
D = 2,5 x 2150,35 = 2,5 x 6,55169 = 16,4
Questo 10 - B
Justificativa: Basta aplicar a frmula.
V (G) = E N + 2P
Onde E = 12
N=7
P=1
Logo: V(G) = 12 7 + 2 = 7
MTRICAS DE SOFTWARE
87
Luiz Roberto Martins Bastos Mestre em Cincias e Computao, com

nfase em Otimizao de Processos, pelo Instituto Militar de Engenharia (IME),
Especialista em Informtica Educativa pelo Centro Universitrio Carioca
(UNICARIOCA), Graduado em Administrao pela Universidade Estcio de S
(UNESA) e em Engenharia Eltrica pela Universidade Federal do Rio de Janeiro
(UFRJ).
Possui
experincia
de
20
anos
nas
reas
de
produo,
desenvolvimento, marketing e gesto de processos. Atualmente, professor e

conteudista dos cursos de Graduao e Ps-Graduao da UNESA nas
modalidades presencial e a distncia. Tambm atua como professor convidado
da Fundao Getulio Vargas (FGV) e do Servio Brasileiro de Apoio s Micro e
Pequenas Empresas (SEBRAE).
Currculo Lattes: http://lattes.cnpq.br/1109935861412082.
MTRICAS DE SOFTWARE
88

Métricas de Software Fundamentos

Enviado por

Dados do documento

Descrição original:

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

Métricas de Software Fundamentos

Enviado por

Direitos autorais:

Formatos disponíveis

Apresentao

Aula 3: Determinao de Ponto por Funo .............................................................................. 49

Fan-out e Fan-in .............................................................................................................. 51

Aula 4: Estimativa de esforo e prazo ....................................................................................... 68

muito importante que voc conhea as tcnicas de gerenciamento de projeto

software da mais alta qualidade.

orientao quantitativa que nos auxiliar na seleo de casos de teste

Por que devemos medir?

Quais so as etapas envolvidas?

Como garantir que o trabalho seja realizado corretamente?

mtricas e, ento, use-as para obter informaes sobre a qualidade do artefato

Avaliao dos atributos internos do produto

Curva de falhas para hardware ou curva da banheira

Mtodos e ferramentas de anlise, projeto, codificao e teste;

Revises tcnicas em cada fase do desenvolvimento;

Documentao de software e das mudanas efetuadas;

Padres de desenvolvimento de software;

Fatores determinantes para a garantia da qualidade

manutenibilidade). Caso o software se adque aos requisitos explcitos, mas

Fatores de qualidade de McCall

Caractersticas de adaptao a novos ambientes

Fatores de Qualidade ISO 9126

adequabilidade, preciso, interoperabilidade, atendibilidade e segurana.

O teste o ltimo reduto no qual a qualidade pode ser avaliada;

Voc no pode testar qualidade. Se ela no estiver l antes, ela no

Otimismo o risco ocupacional da programao; teste o tratamento";

A qualidade de um software funo de quanto ele muda o mundo

Mtricas de indicadores e de produto

O produto e o processo em relao medio

As estimativas mais importantes

Esforo humano exigido

Mtricas so frequentemente classificadas como mtricas do processo ou

Mtricas para o nvel de experincia do pessoal: nmero de anos que

software foi desenvolvido.

O tamanho do produto (linhas de cdigo);

A complexidade da estrutura lgica (recurso for, while, repeat, fluxo

A complexidade da estrutura de dados;

Funes (tais como tipo de software: comercial, cientfico etc.).

Mtricas diretas e mtricas indiretas

Mtricas orientadas ao tamanho

Mtricas orientadas funo

Formulao: criao de medidas e mtricas apropriadas para a

Coleo: no caso, refere-se ao mecanismo usado para acumular dados

Anlise: a computao das mtricas e a aplicao de ferramentas

Interpretao: relacionada avaliao de mtricas que resultam em

Feedback: so recomendaes derivadas da interpretao de mtricas

Atributos de mtricas eficazes de software

Pressman (Engenharia de Software) elege atributos que devero ser abrangidos

A seguir esto elencados os atributos que devem ser considerados pelas

Simples e computveis Dever ser relativamente fcil aprender a

Empiricamente e intuitivamente persuasiva A mtrica dever satisfazer

Consistente e objetiva A mtrica dever sempre produzir resultados

Consistente no seu uso das unidades e dimenses A computao

Independente da linguagem de programao As mtricas devero ser

Um mecanismo efetivo para feedback de alta qualidade A mtrica

desenvolvimento explicitamente documentadas e caractersticas implcitas que

III. Portabilidade Facilidade com que o software pode ser transposto de um

quantitativa que nos auxiliar na seleo de casos de teste. A mtrica de

podem aparecer no incio do processo. Isso se deve a alguns fatores, exceto

e) Esto corretas apenas as afirmativas II, III e IV

b) Completam o enunciado as afirmativas I e III

c) Para uma aplicao existente desejamos saber quanto tempo ser