Aulas 01a10

Prévia do material em texto

Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo Chiodi Martins 
Aulas 
01 a 10 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 01 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
Você é um bom desenvolvedor de sistemas? (colocar 
imagem representando desenvolvedor de software) 
 
 
Sim? Não? (colocar imagem representando SIM e Não) 
 
 
Independente da sua resposta, por que você 
respondeu assim? ( colocar imagens de 
questionamento) 
Teste rápido 
3 
Quem é o melhor jogador de basquete? 
Borgues – 1,61 m Manute – 2,31 m 
4 
1) Borgues – menor jogador 
da liga NBA da história. 
2) Recorde do maior número 
de minutos jogados. 
3) Recorde maior número de 
assistências. 
4) Ótima média de acerto de 
sextas de 3 pontos. 
 
Quem é o melhor jogador de basquete? 
5 
1) Manute – maior jogador 
da NBA; 
 
2) Recorde de “tocos”. 
 
Quem é o melhor jogador de basquete? 
6 
Ciências Artes Desenvolvimento 
Vamos lhe ajudar a resolver essa dúvida. 
Como fazer para saber se sou um bom 
desenvolvedor ou não? 
7 
Vamos pensar em três perguntas 
 
A) Qual a diferença entre ciências e artes? 
B) Qual seleção é melhor, a seleção brasileira de 
vôlei ou a de futebol? 
C) Por que o Japão conseguiu se reerguer tão 
rapidamente da Segunda Guerra Mundial? 
A disciplina - Motivação 
8 
Uma se relaciona com a outra .... 
A arte é: 
a) inspiração; 
b) pessoal; 
c) irreproduzível. 
A ciência é: 
a)sistematizada; 
b)reproduzível; 
c)provada. 
A ciência pode 
apoiar a arte 
 
A arte inspira a 
ciência. 
A diferença entre ciência e arte 
9 
Futebol no Brasil 
a) Arte aplicada 
b) Conhecimento tácito 
c) Time de heróis 
Vôlei no Brasil é: 
a)sistematizado; 
b)reproduzível; 
c)PDCA; 
d)método. 
Quem é mais 
vitorioso? 
A diferença entre seleção brasileira de 
vôlei e de futebol 
10 
Qualidade Total 
a) Melhoria contínua de processos 
b) Processos “repetitíveis” 
c) Só melhoramos o que medimos 
Por que os japoneses se reergueram da 2º 
GM tão rapidamente? 
11 
12 
Mas o que essas perguntas tem a ver com o 
gerenciamento de projetos? 
Podemos fazer desenvolvimento de software: 
a) pela arte, dependendo de “artistas” do 
desenvolvimento; 
 
b) sem métodos, técnicas e/ou ferramentas 
padronizadas: todo o conhecimento aplicado no 
esforço de desenvolvimento depende 
exclusivamente das pessoas que estão 
desenvolvendo; 
 
c) não buscar a melhoria contínua: cada artista faz 
a sua forma. 
Mas o que essas perguntas tem a ver com o 
desenvolvimento de software? 
13 
Mas também podemos fazer 
desenvolvimento: 
 
a) como ciência, com a aplicação de: 
técnicas, ferramentas, boas práticas; 
 
b) buscar sistematizar a forma de se 
atuar no desenvolvimento; 
 
c) buscar formas de melhoria contínuas 
do desenvolvimento com indicadores. 
Mas o que essas perguntas tem a ver com o 
gerenciamento de projetos? 
14 
Medidas de Esforço de 
Desenvolvimento de Software 
Atividade 1 
Atividades 
 Como saber se uma determinada equipe esta 
desenvolvendo bem, de forma eficiente e eficaz? 
16 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 02 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
 
Você sabe nos dizer o que é métrica 
de software e medida de software? 
 
Ou qual é a diferença entre 
esses conceitos? 
18 
• Custo de desenvolvimento. 
• Tempo de desenvolvimento. 
• Tempo de processamento. 
• Quantidade de armazenamento. 
Muito bom! Você deve ter pensado em: 
19 
Indicação de uma medida quantitativa que 
medirá o quanto um determinado sistema, 
componente o processo possui de uma 
determinada característica. 
 
 
 
Então vamos definir formalmente: 
métrica: 
20 
Peça para duas pessoas mediar a altura de um quarto: 
Exemplo: 
• Pessoa “A” diz: 
 
 
• Pessoa “B” diz: 98 in 
(polegadas) 
2,40 m 
98 in 
O que aconteceu? 
Quem está certo ? 
21 
Nenhuma métrica foi definida para as pessoas 
que iriam medir, e cada qual mediu ao seu jeito: 
O que houve? 
• Um mediu em metros outro em polegadas. 
 
• Mesmo transformando polegadas em metros a 
pessoa B teria a medida de 2,50 m. 
• A pessoa A mediu do teto ao chão. 
• A pessoa B mediu do chão até a parte superior 
do teto. 
É preciso ESPECIFICAR uma BOA MÉTRICA 
para que uma boa medida seja realizada! 
22 
O que você viu acima é um exemplo de especificação de 
métricas diretas. Porém, uma métrica pode ser composta 
por mais de um procedimento de medidas. 
Talvez algo assim tivesse ajudado! 
Nome da 
métrica Pé direito 
Objetivo da 
métrica 
Determinar o vão entre o chão e o teto interior de uma 
construção 
Descrição da 
métrica 
Diferença de cota entre o piso inferior e o piso superior, 
incluindo a espessura da laje superior e desprezando a espessura 
da laje inferior. (Engenhariacivil.com, 2015) 
Sistema de 
medidas 
Para realizar a medida será utilizado o sistema mks (metro, 
quilômetros e segundos). 
Formas de se 
obter a 
medida 
Realizar e medida de uma linha imaginária que cruza o chão e o 
teto em um ângulo de 90º. A medida deverá se iniciar no chão e 
terminar na parte superior do teto (ou seja, incluindo a espessura 
da laje) 
23 
24 
Exemplo de métrica com mais de um 
procedimento de medida! 
Nome da 
métrica 
Erros em pedaço de software 
Objetivo da 
métrica 
Identificar a qualidade do código que está sendo produzido; 
Descrição 
da métrica 
É um número real com uma casa decimal que determina a 
quantidade de erros “críticos” encontrados por milhares de linha de 
código. 
Sistema de 
medidas 
KLOC = milhares de linha de código (número real com uma casa 
decimal) e “# de erros críticos” (número de erros críticos – número 
inteiro). (Deveria especificar erro crítico) 
Formas de 
se obter a 
medida 
Medida 1 – Linhas de código: Realizar a contagem da quantidade de 
NOVAS linhas de código geradas no pacote que foi testado e dividi-
las por 1000 para gerar KLOCs. 
Medida 2 – Contar a quantidade de novos “erros críticos” somada a 
quantidade de “erros críticos” antigos que deveriam ter sido 
consertados, mas persistiram. 
Realizar a razão: medida 2 / medida 1. 24 
Há formas de se escrever uma boa métrica. 
Ela deve ser clara, simples e objetiva 
25 
Vamos na sequência 
mostrar algumas 
caraterísticas que toda boa 
métrica possui 
Primeiro entenda a necessidade 
daquilo que precisa ser medido, 
depois, crie a métrica. 
1) Atenção ao OBJETIVO da métrica. 
26 
É possível utilizar o GQM: 
 
• Goal: meta que a organização quer atingir. 
 
• Question: Questões relacionadas às 
incertezas que afetam o objetivo. 
 
• Metrics.: medidas que devem ser coletadas 
para responder às questões. 
1) Atenção ao OBJETIVO da métrica. 
27 
As métricas devem sempre ser efetivas em 
atender o objetivo requerido, contudo, devem 
ser o mais simples possível. 
2) Métrica NÃO deve ser COMPLEXA. 
28 
Uma métrica sempre 
deve ter o seu 
benefício maior do 
que o custo de 
produzi-la e mantê-la. 
3) Métrica boa é métrica BARATA. 
29 
Uma boa métrica é 
aquela que dá o 
mesmo resultado 
independente de 
quem faça a medida.4) Métrica deve ser IMPESSOAL. 
30 
Boas Práticas 
Métricas Privadas Métricas Públicas 
• São aquelas coletadas 
utilizando base INDIVÍDUO. 
 
• Exemplo: 
• número de linhas de 
código por 
desenvolvedor; 
• Defeitos por 
desenvolvedor; 
 
• Deve ser exposta apenas ao 
indivíduo que está 
relacionado a ela. 
• São aquelas coletadas SEM a 
utilização da base INDIVÍDUO. 
 
• Podem ser as métricas privadas 
CONSOLIDADAS para o grupo de 
desenvolvedores da empresa. 
 
• Exemplo: 
• Quantidade de defeitos por 
módulo do sistema; 
• Quantidade de defeito por 
milhares de linha de código. 
 
• Podem ser expostas a todos. 
31 
Dicas Sobre Métricas 
Números devem ser interpretados com bom senso e 
sensibilidade empresarial. 
Métricas coletadas, feedback fornecido. 
Métricas não são para avaliação e sim para evolução. 
As métricas devem ser claras e objetivas, e após a sua 
definição busque definir metas a serem alcançadas. 
Medidas de métricas que indicam possíveis problemas 
não devem ser vistas de forma negativa e sim como uma 
oportunidade. (oportunidade de melhoria, crescimento...) 
Uma métrica sozinha não faz verão. 
32 
Entendimento 
Para entender fenômenos que estão acontecendo 
em um processo, produto, recursos e ambientes. 
Base histórica 
Ao medir em diferentes momentos no tempo é 
possível estabelecer base histórica o que permite 
comparação de desempenhos e entender se está 
havendo uma evolução. 
Acompanhamento 
As métricas são utilizadas para entender a 
execução em relação ao que foi planejado. 
Tendência 
Com métricas é possível entender tendências, 
prever futuras situações e proceder com planos 
de ação para ajustar o rumo de projetos e 
produtos de software. 
Melhoria 
contínua 
O entendimento de problemas e causas raízes é 
mais tranquilo de forma que um plano de ação de 
correção possa ser criado. 
33 
Por que utilizar métricas em sw? 
Métricas OK. 
 
E MEDIDAS, você sabe o que são? 
34 
Uma medida é uma tomada de valor de 
algo que se quer avaliar contra um 
padrão estabelecido. 
é o processo por meio do qual 
são associados símbolos ou 
números a atributos de entidades 
de modo que os determinem 
conforme padrões bem definidos. 
35 
Há dois tipos de medidas: Direta e Indireta. 
DIRETA: São aquelas que medem diretamente um 
fenômeno. A altura de uma pessoa pode ser 
conseguida diretamente utilizando uma fita métrica. 
INDIRETA: São medidas conseguidas por 
meio de outras medidas. Por exemplo 
medir a qualidade de um software pelo 
tempo que ele fica sem “travar”. 
Este tipo de medida não nos 
oferece um resultado “tão 
absoluto” quanto aquele da 
medida direta. 
36 
 Descrever uma métrica para verificar a 
quantidade de retrabalho gerada durante 
a release de uma versão de um 
determinado software. 
Atividades 
37 
Nome da 
métrica 
Retrabalho 
Objetivo 
da métrica 
Identificar a quantidade de retrabalho em horas que foi 
necessário durante o desenvolvimento de uma release de um 
software 
Descrição 
da métrica 
É um número, no formato de horas, que acumula a quantidade 
de retrabalho produzida durante uma release 
Sistema 
de 
medidas 
Horas -> HH:mm 
Formas de 
se obter a 
medida 
Medida 1 – Identificar a quantidade de tickets de 
desenvolvimento que foram reabertos pela equipe de teste. 
Para tanto, basta acessar o sistema de controle de tickets por 
meio do endereço [endereço]... 
Medida 2 – Identificar a quantidade de horas que foram 
lançadas para cada um desses tickets e somar. 
38 
Exemplo de métrica com mais de um 
procedimento de medida! 
 
39 
40 
41 
42 
43 
44 
45 
Tot_ponto_func_ajustado = tot_contado * (0,65 + 0,01 * ) 
Observe que o total_contado é multiplicado por um valor que pode variar de 1,35 a 0,65 dependendo 
dos graus de influencia das 14 características analisadas. Este índice é chamado de fator de ajuste. 
Essas notas devem ser somadas. Vamos representar essa soma 
na forma: somatório de i (i variando de 1 a 14) indicando as notas 
dos 14 itens. 
Se todos os itens forem considerados sem importância, o 
somatório é 0 e 70 se todos forem considerados fundamentais. 
São usadas 14 características gerais de sistemas são: 
– 1. Comunicação de Dados 
– 2. Processamento de Dados Distribuído 
– 3. Desempenho 
– 4. Utilização do Equipamento (Restrições de Recursos Computacionais) 
– 5. Volume de Transações 
– 6. Entrada de Dados On-line 
– 7. Eficiência do Usuário Final (Usabilidade) 
– 8. Atualização On-line 
– 9. Processamento Complexo 
– 10. Reusabilidade 
– 11. Facilidade de Implantação 
– 12. Facilidade Operacional (Proc Oper, como Inicialização, Cópia de Segurança,...) 
– 13. Múltiplos Locais e Organizações do Usuário 
– 14. Facilidade de Mudanças (Manutenibilidade) 
Observando pontos a partir de produtos prontos, atribuiu-se que o 
total de ponto função é constituído de 65 % do valor da contagem, 
sendo o restante dependente de um porcento do total da 
contagem. Assim constitiu-se a formula: 
46 
A simples contagem dá o valor de ponto função NÃO AJUSTADO. Muitas empresa usam este 
número para sua gerencia de SW. Dependendo das características necessárias para um 
determinado setor, pode-se estabelecer o fator de ajuste. Isso permite que se compare totais 
de ponto função entre SWs de aplicações diferentes. 
Total de ponto função ajustado= Contagem (ponto função não ajustado) * Fator de ajuste 
Com o uso de análise de ponto função pode-se definir indicadores que permitem comparar SWs 
com características diferentes (o que não era possível com LOC). 
 
A partir da contagem de PF que reflete o 
tamanho de um sistema, é possível se definir 
a produtividade de uma equipe (por exemplo, 
em horas por ponto de função - H/PF), 
desde que se utilize métricas de 
acompanhamento como prazo ou esforço 
para executar uma determinada tarefa. 
Os PF são mapeados em KLOC´s baseado 
no tipo de linguagem. Essas tabelas são 
atualizadas mundialmente pelo IFPG. 
47 
48 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 03 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
O que estudaremos NESTA aula? 
Categorização de 
métricas 
Pontos de 
Função 
Como determinar 
os pontos de 
função 
50 
Categorização de métricas na 
engenharia de software 
Gestão de projeto de software 
 
Engenharia de 
requisitos 
Projeto de 
software 
Implementação 
Processo de desenvolvimento 
de software e outras atividades 
guarda chuva 
Testes 
Manutenção 
 
Software em 
produção -> 
Produto de 
Software 
Baseado 
neste ciclo 
de vida 
sugere-se 
uma 
taxonomia 
para 
métricas 
de 
software. 
51 
Categorização de métricas na 
engenharia de software 
Métricas de 
Produto de 
Software 
Métricas de 
Processo de 
Software 
Métricas de 
Projeto de 
Software 
52 
Categorização de métricas na 
engenharia de software 
Métricas de 
Produto de 
Software 
Métricas de 
Processo de 
Software 
Métricas de 
Projeto de 
Software 
53 
Métricas de Produto de Software 
Métricas para o modelo de análise: são aplicadas 
na análise, antes da codificação e incluem: 
funcionalidades entregues, tamanho do sistema e 
qualidade da especificação 
Métricas para o modelo de projeto: métricas para 
avaliar a qualidade do design (projeto) de software. 
Ex.: métrica arquitetural.Métricas para o código fonte: avaliam a qualidade 
do código fonte no que tange à complexidade. 
Métricas de teste: avaliam o design dos casos de 
teste avaliando o poder dos testes que foram criados. 
54 
Categorização de métricas na 
engenharia de software 
Métricas de 
Produto de 
Software 
Métricas de 
Processo de 
Software 
Métricas de 
Projeto de 
Software 
55 
Métricas de Processo de Software 
Medidas dos erros descobertos antes da 
entrega do software 
Defeitos entregues ao usuário final 
Produtividade 
são medidas criadas para entender e evoluir o 
processo de desenvolvimento. Usados por exemplo 
pelo PDA e IDEAL. 
56 
Categorização de métricas na 
engenharia de software 
Métricas de 
Produto de 
Software 
Métricas de 
Processo de 
Software 
Métricas de 
Projeto de 
Software 
57 
Métricas de Projeto de Software 
Métrica orientada 
ao tamanho. 
Métrica orientada à 
função. 
Métrica orientada a 
casos de uso 
Métricas orientadas 
a objeto 
Métricas de projeto 
de engenharia Web. 
58 
O que são os “Pontos de Função”? 
Uma forma de se medir o tamanho do 
software é a utilização do 
LOC – Lines of Code. 
Porém só podemos medir o LOC depois que 
o software está pronto. Portanto não é uma 
métrica que nos ajuda para o planejamento 
de esforço do software. 
Para tanto podemos utilizar uma métrica de 
COMPLEXIDADE do software que 
INDIRETAMENTE nos indique o tamanho 
que o software terá. Uma das mais famosas é 
 o “Pontos de Função” 
59 
1) Métrica que caracteriza a complexidade das 
funcionalidades do software que será 
desenvolvido. 
2) De forma indireta nos apontará o tamanho do SW. 
3) Há equações que nos permitem transformar a 
medida de pontos de função para LOC em uma 
determinada linguagem. 
 
 
 
Pontos de Função: 
60 
Medidas de Esforço de 
Desenvolvimento de Software 
Atividade 3 
 Classifique as métricas abaixo: 
◦ Usabilidade; 
◦ Manutenibilidade; 
◦ Produtividade; 
◦ Quantidade de erros encontrados antes da entrega para o usuário; 
◦ Quantidade de classes do sistema; 
◦ Quantidade de casos de uso identificados. 
61 
Atividades 
 Classifique as métricas abaixo: 
● Métricas de produto de software 
• Usabilidade; 
• Manutenibilidade; 
● Métricas de processo de software 
• Produtividade; 
• Quantidade de erros encontrados antes da entrega para o usuário; 
●Métricas de projeto de software 
• Quantidade de classes do sistema; 
• Quantidade de casos de uso identificados. 
62 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 04 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
O que estudaremos NESTA aula? 
Categorização 
de métricas 
Pontos de 
Função 
Como 
determinar os 
pontos de 
função 
Até então fizemos duas aulas por capítulo. 
Agora, faremos 3 aulas para falar sobre a 
metade do segundo capítulo. Porque 
aprender a fazer a APF é importante. 
64 
O que estudaremos NESTA aula? 
Então nos organizaremos assim: 
Aula 4 
•PF 
•Processo de contagem 
•Determinar escopo de contagem 
•Determinar tipo de contagem 
Aula 5 
•Contar função tipo dado 
Aula 6 
•Contar função tipo transação 
•Determinar PF não ajustado 
•Determinar fator de ajuste 
•Determinar PF 
65 
O que estudaremos NESTA aula? 
Então nos organizaremos assim? 
Aula 4 
•PF 
•Processo de contagem 
•Determinar escopo de contagem 
•Determinar tipo de contagem 
Aula 5 
•Contar função tipo dado 
Aula 6 
•Contar função tipo transação 
•Determinar PF não ajustado 
•Determinar fator de ajuste 
•Determinar PF 
66 
O que são os “Pontos de Função”? 
Uma forma de se medir o tamanho do software é a 
utilização do LOC – Lines of Code. 
Porém só podemos medir o LOC depois que o 
software está pronto. Portanto não é uma métrica 
que nos ajuda para o planejamento de esforço 
do software. 
Para tanto podemos utilizar uma métrica de 
COMPLEXIDADE do software que INDIRETAMENTE 
nos indique o tamanho que o software terá. Uma 
das mais famosas é o “Pontos de Função”. 
Eng. Requisitos Projeto Implementação Testes 
LOC 67 
1) Métrica que caracteriza a complexidade das 
funcionalidades do software que será 
desenvolvido. 
2) De forma indireta apontará o tamanho do SW. 
3) Há equações que nos permitem transformar a 
medida de pontos de função para LOC em 
uma determinada linguagem. 
 
 
 
Pontos de Função: 
68 
Pontos de Função: 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo de 
contagem e 
fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função 
tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
Como fazer para medir o SW utilizando PF? 
69 
Pode-se utilizar a PF para 3 tipos de software: 
Determinar o tipo de Contagem: 
1) Projetos de desen. de software 
2) Projetos de melhoria 
3) Aplicação 
Conta-se todos os PF mais todas as conversões de dados (importações e 
exportações) da aplicação legada para a nova aplicação (caso de nova versão). 
Conta-se todos os PF do improvement. 
Diferente do primeiro, conta-se apenas os PFs. 
70 
Determinar escopo de contagem 
e fronteira da aplicação. 
É importante entender o que faz parte do sistema e 
o que não faz parte do sistema. Isto é determinar a 
fronteira da aplicação e a contagem: 
71 
Determinar escopo de contagem e 
fronteira da aplicação. 
72 
 Quais os tipos de contagem a PF admite e por 
que a necessidade desses tipos? 
Atividades 
Pode-se utilizar a PF para 3 tipos de SW: 
1) Projetos de 
desen. de 
software 2) Projetos de 
melhoria 
3) Aplicação 
73 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 05 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
O que estudaremos NESTA aula? 
Categorização de 
métricas 
Pontos de Função 
Como determinar 
os pontos de 
função 
Até então fizemos duas aulas por capítulo. 
Agora, faremos 3 aulas para falar sobre a 
metade do segundo capítulo. Por que 
aprender a fazer a APF é importante 
75 
O que estudaremos NESTA aula? 
Então nos organizaremos assim? 
Aula 4 
•PF 
•Processo de contagem 
•Determinar escopo de contagem 
•Determinar tipo de contagem 
Aula 5 
•Contar função tipo dado 
Aula 6 
•Contar função tipo transação 
•Determinar PF não ajustado 
•Determinar fator de ajuste 
•Determinar PF 
76 
Pontos de Função: 
Determinar o 
tipo de 
contagem 
Determinar o 
escopo de 
contagem e 
fronteiras da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF não 
ajustados 
Det. Fator 
de ajuste 
Det. PF 
2: ALI e AIE 
3: Entradas Externas 
 Saídas Externas 
 Consultas Externas 
77 
Contar função tipo dado! 
Funções de dados são funcionalidades 
solicitadas pelo usuário e que representam 
requisitos de dados internos e externos. 
ALI – Arquivo Lógico Interno: 
AIE – Arquivo Interface Externa: 
78 
Contar função tipo dado! 
Grupo lógico de informações de controle 
ou dados identificados pelo usuário e 
mantido dentro dos limites da aplicação. 
CRUDE – CReate, Update, DElete 
ALI 
Arquivo Lógico Interno 
Exemplo:uma tabela do banco de dados que é 
atualizada pela aplicação, dados da aplicação ... 
79 
Contar função tipo dado! 
Grupo lógico de informações de controle ou de 
dados identificados pelo usuário e relacionado com a 
aplicação que está sendo contada, mas atualizados e 
mantidos dentro dos limites de uma outra aplicação. 
AIE 
Arquivo de Interface Externa 
Um AIE de uma aplicação sempre será 
contado como um ALI em uma outra aplicação. 
80 
Além de contar os ALI´s e AIE´s é necessário 
também determinar a COMPLEXIDADE de 
cada um deles. 
 
Como fazer isso? 
Contar função tipo dado! 
81 
É necessário contar quantos TD e TR há no 
ALI ou AIE, sendo que: 
 
TR(tipo de registro lógico) = subgrupo de dados de 
um ALI/AIE reconhecido pelo usuário. 
 
TD(tipo de dado lógico) = campo não repetido, 
único e identificável pelo usuário. 
Contar função tipo dado! 
82 
Exemplo: considere um software que tem o cadastro 
de funcionários em uma clínica dentista sendo que 
o func. pode ser auxiliar ou dentista. 
Consideraremos o cadastro um 
processo elementar do sistema 
contendo um ALI que será o 
funcionário 
O DER ficaria desta forma. Então contamos: 
TR: 3 – funcionário, auxiliar e Dentista. 
TD: 4 – id_func, salario, bolsa, crm. 
Contar função tipo dado! 
83 
Aplicamos a tabela de complexidade abaixo. 
No exemplo, teríamos uma 
complexidade BAIXA. 
Contar função tipo dado! 
84 
Regra geral: Uma dica geral e objetiva, mas 
passível de erro , é contar um arquivo 
lógico ALI ou AIE para cada tabela 
reconhecida pelo usuário. 
Se o usuário não reconhece a tabela, mas 
reconhece os tipos de dados presente na 
mesma, provavelmente essa tabela será 
um tipo de registro 
Contar função tipo dado! 
85 
Contar função tipo dado! 
86 
Contar função tipo dado! (passo a passo) 
1: Faça o modelo lógico de dados do seu projeto. 
2: Identifique as tabelas reconhecidas 
pelo usuário (visão de negócio) 
e classifique-as. 
 
 
 
 
3: Analise as tabelas que não estão na visão do usuário: 
 
a) Caso a tabela não pertença à visão do negócio, mas os seus 
TD pertençam, considere-a uma TR para cada arquivo lógico 
relacionado a ela e atribua os seus tipos de dados a cada um deles. 
 
b) Caso nem a tabela nem os seus TDs pertençam à visão do negócio, 
descarte-a da contagem. 
4: Determine a complexidade 
87 
Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo 
Chiodi Martins 
Atividade 5 
Descrição Tipo TR TD Complexidade 
Arquivo 1 ALI 1 51 
Arquivo 2 ALI 10 21 
Arquivo 3 ALI 1 1 
Arquivo 4 ALI 6 51 
 Dê a complexidade de cada um dos ALI´s abaixo: 
 
 
Atividades 
89 
 Dê a complexidade de cada um dos ALI´s abaixo: 
 
 
Atividades 
Descrição Tipo TR TD Complexidade 
Arquivo 1 ALI 1 51 MÉDIA 
Arquivo 2 ALI 10 21 ALTA 
Arquivo 3 ALI 1 1 BAIXA 
Arquivo 4 ALI 6 51 ALTA 
< 20 20 - 50 > 50 
1 Baixa Baixa Média 
2 - 5 Baixa Média Alta 
> 5 Média Alta Alta T
ip
o
s
 d
e
 
R
e
g
is
tr
o
 
Tipos de Dados 
90 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 06 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
O que estudaremos NESTA aula? 
Categorização de 
métricas 
Pontos de Função 
Como determinar 
os pontos de 
função 
Vamos utilizar esta aula para cobrir o capítulo 3 do 
livro discutindo um estudo de caso de pontos de 
função e introduzindo o conceito de estimativas. 
92 
O que estudaremos NESTA aula? 
Então nos organizaremos assim? 
Aula 4 
•PF 
•Processo de contagem 
•Determinar escopo de contagem 
•Determinar tipo de contagem 
Aula 5 
•Contar função tipo dado 
Aula 6 
•Contar função tipo transação 
•Determinar PF não ajustado 
•Determinar fator de ajuste 
•Determinar PF 
93 
Estudo de caso: Pontos de Função! 
Determinar o 
tipo de 
contagem 
Determinar o 
escopo de 
contagem e 
fronteiras da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF não 
ajustados 
Det. Fator 
de ajuste 
Det. PF 
94 
Contar Função Tipo Transação! 
Funções transacionais são 
as funcionalidades de 
processamento de dados 
providas para o usuário 
através da aplicação. 
95 
Além de contar os EE´s, SE´s e CE´s é necessário também 
determinar a COMPLEXIDADE de cada um deles. 
Sendo que um processo elementar é a menor unidade funcional que 
possui significado no SW que está sendo desenvolvido: 
 
a) é a menor atividade possível e que tenha significado para o usuário. 
b) é “auto-contido” e deixa as regras de negócio em um estado 
consistente. 
Ex: Cadastrar usuário com “Wizard de várias telas”: Conta 1 processo. 
Contar função tipo transação! 
podem ser 
EE – Entrada Externa - é um processo elementar que processa dados 
ou entradas de controle que vêm de fora (da fronteira) da aplicação 
SE– Saída Externa - é um processo elementar que envia dados ou 
informações de controle para fora da fronteira da aplicação. 
CE– Consulta Externa - é um processo elementar que envia 
informações de controle ou dados fora da fronteira do sistema 
96 
Contar os TDs envolvidos: É um campo não recursivo de 
dado, único e reconhecido pelo usuário, ou seja, é cada 
campo preenchido ou apresentado ao usuário. 
Contar função tipo transação! 
(complexidade) 
Contar os AR (arquivos referenciados): é todo arquivo 
lógico lido, pode ser um ALI ou AIE, ou todo arquivo lógico 
mantido, neste caso só pode ser um ALI. 
97 
Contar função tipo transação! 
(complexidade) 
EE 
CE 
SE 
98 
Estudo de caso: Pontos de Função! 
Determinar o 
tipo de 
contagem 
Determinar o 
escopo de 
contagem e 
fronteiras da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF não 
ajustados 
Det. Fator 
de ajuste 
Det. PF 
99 
O significado dos pontos de função não ajustados é um valor 
de complexidade que reflete o sistema no que tange aos 
requisitos específicos de armazenamento e processamento 
Determinar PF não ajustados! 
Basta agora somar a contribuição de cada ALI, AIE, 
EE, SE e CE encontrado, de acordo com a sua 
complexidade, respeitando a seguinte tabela: 
Tipo SIMPLES MÉDIO COMPLEXO 
EE 3 4 6 
SE 4 5 7 
CE 3 4 6 
ALI 7 10 15 
AIE 5 7 10 
100 
Estudo de caso: Pontos de Função! 
Determinar o 
tipo de 
contagem 
Determinar o 
escopo de 
contagem e 
fronteiras da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF não 
ajustados 
Det. Fator 
de ajuste 
Det. PF 
101 
Determinar Fator de Ajuste! 
O PF não ajustado reflete a complexidade do SW segundo 
suas funcionalidades. 
 
Porém há alguns outros fatores técnicos do SW que 
podem afetar a sua complexidade. 
 
Portanto, calculamos um FATOR DE AJUSTE baseado 
nessas características para “afinar” a medida 
Características Gerais do Sistema 
Comunicação de dados Atualização on-line 
Processamento distribuído Processamento complexo 
Desempenho Reutilização de código 
Configuração altamente utilizada Facilidade de implantação 
Volume de transações Facilidade operacional 
Entrada de dados on-line Múltiplos locais 
Eficiência do usuário final Facilidade de mudanças 
1 Nenhuma influência. 
2 Influência mínima. 
3 Influência moderada. 
4 Influência significativa. 
5 Grande influência. 
Para cada uma das características, dar uma notade 1 - 5 
102 
Exemplo! 
CGS Peso 
atribuído 
CGS Peso 
Atribuído 
Comunicação de dados 3 Atualização on-line 2 
Processamento 
distribuído 
2 Processamento complexo 4 
Desempenho 1 Reutilização de código 2 
Configuração altamente 
utilizada 
5 Facilidade de implantação 3 
Volume de transações 4 Facilidade operacional 1 
Entrada de dados on-line 5 Múltiplos locais 5 
Eficiência do usuário final 1 Facilidade de mudanças 1 
 
TOTAL 39 
Determinar Fator de Ajuste! 
103 
Exemplo = VFA = (39 * 0,01)+0,65 = 1,04 
CGS Peso 
atribuído 
CGS Peso 
Atribuído 
Comunicação de dados 3 Atualização on-line 2 
Processamento distribuído 2 Processamento complexo 4 
Desempenho 1 Reutilização de código 2 
Configuração altamente utilizada 5 Facilidade de implantação 3 
Volume de transações 4 Facilidade operacional 1 
Entrada de dados on-line 5 Múltiplos locais 5 
Eficiência do usuário final 1 Facilidade de mudanças 1 
 
TOTAL 39 
Determinar Fator de Ajuste! 
104 
Agora basta aplicar a fórmula abaixo – 
na qual TGI é a soma das notas. 
Determinar Fator de Ajuste! 
105 
Calcular o PF Ajustado 
Para finalizar, é necessário calcular o PF Ajustado. 
Para cada tipo de contagem de PF há uma fórmula 
específica. Aqui, consideraremos o primeiro tipo de 
contagem = desenvolvimento de novo software. 
A fórmula será: 
AjustedeFatorPFNAmentoDesenvolviPF __*_ 
ALI 
AIE 
EE 
SE 
CE 
Complexidade 
de cada um 
1 
2 
3 
... 
14 
1 a 5 
1 a 5 
1 a 5 
... 
1 a 5 
EE 
CE 
SE 
106 
Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo 
Chiodi Martins 
Atividade 6 
Atividades 
 Imagine uma aplicação que possua 10 consultas 
externas, 10 entradas externas, 10 saídas 
externas, 5 arquivos lógicos internos, 5 arquivos 
de interfaces externas todos de complexidade 
média. Qual é o valor dos pontos de função não 
ajustados para este caso considerando uma 
contagem para projetos de desenvolvimento? 
 
 
108 
 
 
 SIMPLES MÉDIO COMPLEXO TOTAL 
ALI 0 7 5 10 0 15 50 
AIE 0 5 5 7 0 10 35 
SE 0 4 10 5 0 7 50 
CE 0 3 10 4 0 6 40 
EE 0 3 10 4 0 6 40 
TOTAL 215 
Tipo SIMPLES MÉDIO COMPLEXO 
EE 3 4 6 
SE 4 5 7 
CE 3 4 6 
ALI 7 10 15 
AIE 5 7 10 
109 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 07 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
Estudo de Caso de PF e Introdução à Estimativa 
O que Estudaremos Nesta Aula? 
Vamos utilizar esta aula para cobrir o capítulo 3 
do livro discutindo um estudo de caso de pontos 
de função e introduzindo o conceito de estimativas. 
Estudo de 
caso 
Introdução 
a métricas e 
estimativas 
usando PF 
Tipos de PF 
111 
O que Estudaremos Nesta Aula? 
Estudo de 
caso 
Introdução 
a métricas e 
estimativas 
usando PF 
Tipos de PF 
112 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
113 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
114 
Determinar o tipo de contagem! 
É um desenvolvimento novo, portanto, utilizaremos 
a primeira forma de PF = Desenvolvimento 
de um novo sist. 
115 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
116 
Escopo de Contagem 
e Fronteira da Aplicação. 
Biblioteca de uma escola. 
117 
Biblioteca de uma escola. 
Escopo de Contagem 
e Fronteira da Aplicação. 
REQ 1 – Incluir 
Aluno – Um aluno 
pode ser incluído 
no sistema para que 
posteriormente ele 
possa pegar livros 
emprestados. 
REQ 2 – Emprestar 
– Um aluno 
cadastrado pode 
emprestar livros 
 
REQ 3 – Verificar 
Atrasos – Verificar 
livros em atraso. 
REQ 4 – 
Cadastrar Livros 
– A bibliotecária 
pode cadastrar 
um livro que 
acabou de 
chegar no acervo 
da biblioteca. 
118 
Escopo de Contagem 
e Fronteira da Aplicação. 
DFD. 
119 
Escopo de Contagem 
e Fronteira da Aplicação. 
Diagrama de auxílio ao DFD. 
120 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
121 
ALI – Arquivo Lógico Interno: grupo lógico de 
informações de controle ou dados identificados pelo 
usuário e mantido dentro dos limites da aplicação. 
AIE – Arquivo de Interface Externa: grupo lógico de 
informações de controle ou de dados identificados 
pelo usuário e relacionado com a aplicação que está 
sendo contada, mas atualizados e mantidos dentro 
dos limites de uma outra aplicação. 
122 
Contar função tipo dado! 
Um ALI pode ser: 
 
• Tabelas de dados mantidos pela aplicação; 
 
• Arq. de configuração e segurança mantidos pela 
aplicação ... 
ALI 
123 
Contar função tipo dado! 
ALI 
124 
4 
por enquanto 
Contar função tipo dado! 
ALI 
125 
Contar função tipo dado! 
ALI 
* Não apareceu no modelo, então estamos fazendo uma estimativa. 
O usuário 
reconhece 
No modelo lógico TR TD 
Aluno válido USUÁRIO 1 4 
Pedido - (assumimos 1 TR e <20 TD) 1* <20* 
Acervo LIVRO,AUTOR,AUTORIA 3 6 7 
Empréstimo EMPRÉSTIMO 1 1 
126 
Contar função tipo dado! 
ALI 
O usuário reconhece TR TD Complexidade 
Aluno válido 1 4 BAIXA 
Pedido 1 <20 BAIXA 
Acervo 3 6 BAIXA 
Empréstimo 1 1 BAIXA 
127 
Contar função tipo dado! 
AIE 
Um AIE pode ser: 
 
• Dados de referência externa utilizados pela 
aplicação 
128 
Contar função tipo dado! 
AIE 
1 
129 
Contar função tipo dado! 
AIE 
O usuário 
reconhece 
TR TD Complexidade 
Sistema 
financeiro 
para as 
multas. 
Considerar 1 Considerar<20 BAIXA 
130 
Contar função tipo dado! 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
131 
podem ser 
EE – EntradaExterna 
- é um processo 
elementar que 
processa dados ou 
entradas de controle 
que vêm de fora (da 
fronteira) da aplicação 
SE– Saída Externa - é 
um processo 
elementar que envia 
dados ou informações 
de controle para fora 
da fronteira da 
aplicação. 
132 
Contar função tipo transação! 
podem ser 
EE 
133 
Contar função tipo transação! 
SE 
Como não temos informações adicionais do dicionário 
de dados ou de outras fontes sobre a complexidade dos 
itens, vamos considerar todos de complexidade BAIXA. 
Estudo de caso: Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
134 
Determinar PF não ajustados! 
Basta agora somar a contribuição de cada ALI, AIE, 
EE, SE e CE encontrado, de acordo com a sua 
complexidade, respeitando a seguinte tabela: 
135 
Determinar PF não ajustados! 
136 
podem ser 
EE 
137 
Contar função tipo transação! 
SE 
Como não temos informações adicionais do dicionário 
de dados ou de outras fontes sobre a complexidade dos 
itens, vamos considerar todos de complexidade BAIXA. 
ALI 
AIE 
Determinar PF não ajustados! 
 
Fator de 
ponderação 
 
Funções tipo 
dado e tipo 
transação 
Contagem 
no sistema 
BAIXO MÉDIO ALTO Total 
EE 3 3 4 6 9 
SE 2 4 5 7 8 
CE 0 3 4 6 0 
ALI 4 7 10 15 28 
AIE 1 5 7 10 5 
TOTAL 50 
138 
Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
139 
Determinar Fator de Ajuste! 
• O software deverá ser de alta performance, ou seja, caso o usuário queira 
consultar um livro ou pega-lo emprestado, o software deve performar as atividades 
em menos de 1 segundo. 
 
• O software terá um volume de transações médio. 
 
• Todas as entradas de dados ocorrerão online. 
 
• O sistema deve ter uma usabilidade alta de forma que qualquer ação deve ser 
performada em no máximo 3 cliques de mouse e todas as ações devem ser 
amparadas por instruções na tela do computador. 
• O software receberá no futuro várias atualizações, uma vez que esta é uma versão 
de desenvolvimento inicial. Desta forma, é importante que ele tenha como uma de 
suas principais características a facilidade de mudança e manutenção. 
 
• As demais características do software como por exemplo configurações, 
atualizações, reutilização e complexidade de processamento influenciam 
minimamente as funções do software e consequentemente a sua complexidade 
funcional e tamanho. 
140 
Subtotal 17 Subtotal 15 
TOTAL 32 
Determinar Fator de Ajuste! 
Exemplo = VFA = (32 * 0,01)+0,65 = 0,97 
141 
CGS 
Peso 
atribuído 
CGS 
Peso 
Atribuído 
Comunicação de dados 1 Atualização online 1 
Processamento distribuído 1 Processamento complexo 1 
Desempenho 5 Reutilização de código 1 
Configuração altamente utilizada 1 Facilidade de implantação 1 
Volume de transações 3 Facilidade operacional 5 
Entrada de dados on-line 5 Múltiplos locais 1 
Eficiência do usuário final 1 Facilidade de mudanças 5 
Pontos de Função! 
Determinar 
o tipo de 
contagem 
Determinar 
o escopo 
de 
contagem 
e fronteiras 
da 
aplicação 
Contar 
função tipo 
dados 
Contar 
função tipo 
transação 
Det. PF 
não 
ajustados 
Det. Fator 
de ajuste 
Det. 
PF 
142 
Calcular o PF Ajustado 
A fórmula será: 
5,48_ mentoDesenvolviPF97,0*50_ mentoDesenvolviPF AjustedeFatorPFNAmentoDesenvolviPF __*_ 
143 
O que Estudaremos Nesta Aula? 
Estudo de 
caso 
Introdução 
a métricas e 
estimativas 
usando PF 
Tipos de PF 
144 
O que o 48,5 quer dizer? 
Esta é uma MEDIDA de tamanho do SW que foi 
retirada por meio da métrica de pontos de função 
baseados no DFD, diagrama de apoio e premissas. 
E como posso fazer estimativa com eles? 
145 
Posso estimar LOCs 
 LOC/PF 
Linguagem de 
programação 
Média 
Median
a 
Baixa Alta 
JAVA 63 53 77 - 
C++ 66 53 29 178 
Visual Basic 47 42 16 158 
C 162 109 33 704 
Ada 154 - 104 205 
Cobol 77 77 14 400 
Clipper 38 39 27 70 
Informix 41 31 24 57 
Lotus Notes 21 22 15 25 
146 
O que o 48,5 quer dizer? 
Supondo que faríamos o software em JAVA – média 
de 63 LOCs/PF 
 
48,5 * 63 = 3055,5 LOCs 
Por meio de uma paramétrica, podemos estimar 
ESFORÇO e CUSTO. 
147 
O que o 48,5 quer dizer? 
Supondo (base histórica) 
11,9 horas/FP 
Este software demoraria 
 
48,5 * 11,9 = 577,19 horas 
Considerando o custo de desenvolvimento 
de R$ 100,00/h 
Este software teria o custo de R$ 57.719,00 
148 
O que Estudaremos Nesta Aula? 
Estudo de 
caso 
Introdução 
a métricas e 
estimativas 
usando PF 
Tipos de PF 
149 
150 
Outros tipos de contagem 
Projeto de melhoria 
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) 
EFP – Número de pontos de função do projeto de melhoria; 
ADD – Número de pontos de função não ajustados 
das funções incluídas pelo projeto de melhoria; 
CHGA – Número de pontos de função não ajustados 
das funções modificadas depois das modificações; 
CFP - Número de pontos de função não ajustados 
adicionados pela conversão; 
VAFA – Valor do fator de ajuste da aplicação depois 
do projeto de melhoria; 
DEL - Número de pontos de função não ajustados 
das funções excluídas pelo projeto de melhoria; 
VAFB – Valor do fator de ajuste da aplicação antes do projeto 
de melhoria. 150 
151 
Para uma aplicação 
AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] * VAFA 
AFP – Número de pontos de função ajustados da aplicação 
UFPB – Número de pontos de função não ajustados 
da aplicação antes do projeto de melhoria; 
ADD – Número de pontos de função não ajustados 
das funções incluídas pelo projeto de melhoria; 
CHGA – Número de pontos de função não ajustados 
das funções modificadas depois do seu término; 
CHGB – Número de pontos de função não ajustados 
das funções modificadas antes do seu término; 
DEL - Número de pontos de função não ajustados das funções 
excluídas pelo projeto de melhoria; 
VAFA – Valor do fator de ajuste da aplicação depois do projeto 
de melhoria. 151 
152 
 
Estimativas Putnam e métodos voltados para PF 
Tipo de Interface Multiplicador 
Não IGI 2 
Interface com usuário baseada em texto 2,25 
IGI 2,5 
IGU Complexa 3 
153 
 
 Um projeto usando um processo de desenvolvimento ágil e feito como um conjunto 
de cenários de usuários. É possível desenvolver uma estimativa com razoável 
significado com os seguintes passos: 
 1- Cada cenário de usuário é considerado separadamente para a estimativa. 
 2- O cenário é composto de um conjunto de funções e tarefas de engenharia de SW. 
 3 a- Cada tarefa é estimada separadamente. 
 3 b- O tamanho do cenário pode ser estimado em LOC, PF ou alguma outra medida 
orientada a volume 
 4.a- As estimativas de cada tarefa são somadas para criar uma estimativa de cenário 
 4.b- O volumede esforço é estimado para cenário é traduzido para esforço baseado 
em dados históricos 
 5- As estimativas de esforço para todos os cenários que devem implementar um 
incremento de software são somadas para definir a estimativa para o incremento. 
Normalmente, a duração do desenvolvimento de um incremento é da ordem de 3-6 
semanas; a estimativa serve para garantir que o número de cenários a ser incluído no 
incremento esteja de acordo com os recursos disponíveis. 
154 
Estimativas Putnam e métodos voltados para PF 
Estimativa usando Caso e USO 
155 
Estimativas Putnam e métodos voltados para PF 
PCU – Pontos por Caso de Uso – 
Foram criados por Gustav Karner, em 1993 como uma 
adaptação específica dos Pontos de Função para medir 
o tamanho de projetos de software orientados a objeto. 
Explora o modelo e descrição do caso de uso, 
substituindo algumas características técnicas proposta 
pelos Pontos de Função. É um método simples e de fácil 
utilização mas ainda esta em fase de pesquisas e não 
existem regras de contagem padronizadas. Tem-se 
estudado a aplicação em conjunto da PCU e APF, tentando 
explorar a relação entre elas existente.(EDMÉIA,2004). 
Considerando que a APF é uma das técnicas funcionais mais antigas que possui um 
dos grupos de usuários mais bem estruturados e atuantes e que a partir de 2002 
passou a condição de padrão internacional, através da norma ISO/IEC 20926. A técnica 
pode ser considerada como uma das melhores alternativas de medição de tamanho do 
projeto de software.APF serve como um instrumento para acompanhar estimativas de 
custo e recursos requeridos para o desenvolvimento e manutenção de software. 156 
Estimativas usando ponto função 
Estimativas Putnam e métodos voltados para PF 
A estimativa de tamanho de um projeto de software é uma atividade crítica, pois, tem um 
impacto, tanto na solução técnica apresentada, como no gerenciamento do projeto de software, 
devendo ser efetuada não somente no início do projeto, mas durante o ciclo de vida do 
projeto.Uma pesquisa realizada pela Secretaria de Política de Informática – SEPIN , em 2001, 
indicou que a utilização da APF vem crescendo no Brasil, conforme mostra a tabela 2.1: 
- O sistema irá permitir o acesso sem restrições para qualquer usuário da empresa , 
não havendo portanto controle de acesso. 
- Não existe qualquer interface com outros sistemas existentes- Deverão ser 
cadastrados os seguintes dados de um cliente: Nome , Endereço, Cidade , Cep , 
Telefone , E.mail e Observações. 
- O nome do cliente , endereço , cidade , cep e email são obrigatórios e deverão ser 
sempre informados. 
157 
Sistema de manutenção de clientes 
Estimativas Putnam e métodos voltados para PF 
Descrição do Sistema: 
Em um sistema de manutenção de clientes um usuário (funcionário de empresa) 
registra as entradas, alterações, exclusões e saídas (relatório) dos dados relativos a um 
cliente da empresa no sistema. Qualquer usuário da empresa poderá acessar o sistema 
e efetuar o cadastramento (não haverá controle de acesso no sistema). Será emitido um 
relatório de todos os clientes cadastrados e dos dados de um determinado cliente. 
Característicasdo Sistema: 
158 
Lista de ator(es): 
Estimativas Putnam e métodos voltados para PF 
Casos de Uso identificados: 
159 
Determinar o tamanho funcional do sistema de manutenção 
Entidades e funções do processo de manutenção de clientes: 
Estimativas Putnam e métodos voltados para PF 
Determinar o tamanho funcional do sistema de manutenção 
Para estimar o tamanho, será feita uma contagem estimativa, segundo o modelo que estudamos 
nas aulas anteriores - IFPUG. Vamos usar o processo de contagem, conforme preconiza o manual 
do IFPUG, para determinar o número de pontos por função de um projeto de software. Vamos usar 
as etapas do processo de contagem da APF, conforme a figura abaixo: 
160 
Conclusão: 
Estimativas Putnam e métodos voltados para PF 
Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo 
Chiodi Martins 
Atividade 7 
Atividades 
Calcule a estimativa de tempo e custo para um 
sistema desenvolvido em C++ considerando as 
características abaixo. 
Produtividade a ser considerada = 15horas/pf. 
Custo de desenvolvimento = R$ 150,00 
162 
 
 
 SIMPLES MÉDIO COMPLEXO TOTAL 
ALI 4 7 1 10 2 15 68 
AIE 10 5 3 7 1 10 81 
SE 6 4 3 5 2 7 53 
CE 10 3 4 4 3 6 64 
EE 13 3 8 4 5 6 101 
TOTAL 367 
• PFNA = 367 
• TGI = 42 -> VFA = (42*0,01)+0,65 = 1,07 
• PF ajustados (proj. de desenvolvimento) 
PFNA*VFA = 367 * 1,07 = 392,69 pontos de função. 
• Esforço = 15 * 392,69 = 5890,35 
• Custo = 5890,35 * 150 = R$ 883.552,50 
 
Atividades 
163 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 08 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
Técnicas de estimativa de custo e esforço 
O que Estudaremos Nesta Aula? 
Vamos utilizar a aula 8 e 9 para cobrir o 
capítulo 4 do livro 
PMI/PMBOK 
Técnicas de 
estimativa 1 
Técnicas 
estimativas 2 
165 
1 
•PMI 
2 
•PMBOK 
3 
•Certificações 
PMI E seus serviços 
166 
PMI - Definição 
Organização sem fins lucrativos, dedicada ao avanço 
do estado da arte em gerenciamento de projetos. 
 
Criado inicialmente na Pensilvânia (EUA) em 1969, 
tem como compromisso promover o profissionalismo 
e a ética em GP. 
167 
Hoje considerada a maior e mais acreditada 
instituição de educação e desenvolvimento de 
padrões em gerência de projetos. 
 
Mais informações no site: 
www.pmi.org www.pmisp.org.br 
O Brasil foi o primeiro país a ter um Chapter fora dos EUA. Esse 
Chapter durou até 1984 e depois foi reaberto na década de 90. 
 
Os Chapters são como filiais agrupadas geograficamente que 
contribuem nas missões e objetivos do PMI, promovendo o 
profissionalismo em gerência de projeto. São 15 no BR em 2017. 
PMI - Organização 
168 
PMI 
Chapter 
RJ 
Chapter 
MG Chapter 
ES 
Chapter 
CE 
Chapter 
+9*… 
Chapter 
SP 
Chapter 
SC 
https://brasil.pmi.org/ 
1 
•PMI 
2 
•PMBOK 
3 
•Certificações 
PMI E seus serviços 
169 
Padrão profissionais 
• Desenvolvimento de padrões para a prática de 
Gerência de Projetos. 
 
• Principal documento é o PMBOK ou A Guide to the 
Project Manager Base of Knowledge. 
 
• O PMBOK é aprovado pela ANS e está na sua quarta 
edição. (2008) 
PMI – Produtos e Serviços 
170 
• O PMBOK apresenta as melhores práticas de gestão de 
projetos estruturado em 10 áreas de conhecimento 
• Ger. de Integração 
• Ger. de Escopo 
• Ger. de Tempo 
• Ger. de Custo 
• Ger. de Qualidade 
 
• Ger. de RH 
• Ger de Comunic. 
• Ger. de Riscos 
• Ger. de Aquisições 
• Ger. Partes Interessadas 
Padrão profissionais - PMBOK 
• Cada uma das 10 grandes áreas são agrupadas 
em 5 grandes grupos de processos, a saber: 
• Iniciação 
• Planejamento 
• Execução 
• Monitoramento & Controle 
• Encerramento 
171 
I P 
E M 
E 
?desvio 
OK 
PMI – Produtos e Serviços 
172 
Tempo 
173 
174 
175 
Técnicas de Estimativas 
Análoga 
Paramétrica 
Análise de reservas 
Estimativa de 3 pontos 
Opinião especializada e técnica de tomada de 
decisão em grupo 
176 
Est. a dur. das atividades–Ferr. Tec: Análoga 
Pode ser feita para o projeto 
como um todo:os últimos 5 
projetos parecidos duraram 
8 meses, então este 
também vai durar 
177 
A mesma coisa pode ser 
feita para uma atividade 
Não é muito preciso – usam 
histórico e opinião especializada. 
Útil no início do projeto 
Técnica 
Análoga 
ou 
top down 
Técnicas de Estimativas 
Análoga 
Paramétrica 
Análise de reservas 
Estimativa de 3 pontos 
Opinião especializada e técnica de tomada de 
decisão em grupo 
178 
• Normalmente utilizamos juntamente com uma 
análise bottom-up. 
 
• Nesta análise as tarefas são estimadas e 
depois, de baixo para cima, compõe-se a 
estimativa do projeto. 
É a estimativa do pedreiro (base histórica): 
observa o relacionamento entre variáveis para 
calcular o tempo 
 
 
 
 
 
Pode ser utilizado em conjunto com 
a estimativa de três pontos 
Paramétrica / bottom-up 
179 
Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo 
Chiodi Martins 
Atividade 8 
Atividades 
A área de uma sala é de 100m2 e é necessário 
colocar piso nesta sala. 
 
O pedreiro consegue colocar 1m2 de piso por hora. 
 
Qual é o esforço estimado no qual 
o pedreiro conseguirá colocar o 
piso em toda a sala? 
181 
 
 
• Utilizando a técnica paramétrica o pedreiro 
colocará o piso em 100 horas. 
 
Atividades 
182 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 09 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
Técnicas de estimativa de custo e esforço 
O que Estudaremos Nesta Aula? 
Vamos utilizar a aula 8 e 9 para cobrir o 
capítulo 4 do livro 
PMI/PMBOK 
Técnicas de 
estimativa 1 
Técnicas 
estimativas 2 
184 
Técnicas de Estimativas 
Análoga 
Paramétrica 
Análise de reservas 
Estimativa de 3 pontos 
Opinião especializada e técnica de tomada de 
decisão em grupo 
185 
Análise de Reserva 
São reservas contingencias de tempo ou buffers 
aplicados para os riscos que restam após o 
processo Planejar Respostas aos Riscos. 
186 
Técnicas de Estimativas 
Análoga 
Paramétrica 
Análise de reservas 
Estimativa de 3 pontos 
Opinião especializada e técnica de tomada de 
decisão em grupo 
187 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Acertar com exatidão uma determinada 
duração do projeto ou então a data final é 
estatisticamente difícil ! 
188 
Por isso é mais interessante estimar por 
meio da definição de um intervalo. 
Então pode-se fazer uma média com a 
técnica PERT. 
Procedimento para a técnica: 
1) Pegue a estimativa OTIMISTA (Ex: 5min) 
2) Pegue uma estimativa PESSIMISTA (30 min) 
3) Pegue uma estimativa MAIS PROVÁVEL (10min -média) 
4) Calcule a DURAÇÃO ESPERADA (ou PERT) 
189 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
5) Também é importante calcular o desvio padrão. 
Desvio Padrão da Atividade 
=[30+(4x10)+5]/6=75/6 
=(30-5)/6=4,17 
6) e a variância 
7) O intervalo de uma atividade será 
 
Intervalo da atividade: 75/6-25/6 a 75/6+25/6= 50/6 a 100/6. 
 8,33 a 16,67 
=[(30-5)/6]²=625/36=17,36 
Resumão: 
DEA 
Desvio 
Padrão 
da Atividade 
Var. da 
Atividade 
Intervalo 
da 
atividade 
190 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Atividade: 
ATV P M O DEA 
D. Pad. 
atv. 
Var 
atv. 
Intervalo 
Estimativa 
A 47 27 14 28,17 
169/6 
5,5 
33/6 
30,25 22,67 a 33,67 
B 89 60 41 
61,67 
370/6 
 
8 64 53,67 a 69,67 
C 48 44 39 
43,83 
169/6 
 
1,5 2,25 42,33 a 45,33 
D 42 37 29 
36,5 
169/6 
 
2,17 4,70 34,33 a 38,67 
191 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Determinar o tempo total do projeto: 
1)Determine a DURAÇÃO ESPERADA DO PROJETO 
a) Ela é a soma de todas as DEAs das atividades 
do caminho crítico. 
 
2)Determine DESVIO PADRÃO DO PROJETO 
b) Basta somar todas as VARIÂNCIAS e depois tirar a raiz 
quadrada 
 
3)Eleve o DESVIO PADRÃO ao quadrado para descobrir a 
VARIÂNCIA DO PROJETO 
192 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Atividade: 
Projeto DEP 
D. Pad. 
Projeto 
Var 
Projeto 
Intervalo 
Estimativa 
Projeto 
Estimativa 
de duração 
do projeto 
170,17 10,06 101,20 
160,11 
a 180,23 
193 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Soma das 
variâncias 
Raiz da 
Soma das 
variâncias 
Consideramos a confiabilidade para 1 SIGMA: 
SIGMA Confiabilidade 
1 SIGMA 68,26% 
2 SIGMA 95,46% 
3 SIGMA 99,73% 
6 SIGMA 99,99985% 
194 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
195 
Estimar a duração das atividades–Ferr. 
Tec: 3 pontos 
Técnicas de Estimativas 
Análoga 
Paramétrica 
Análise de reservas 
Estimativa de 3 pontos 
Opinião especializada e técnica de tomada de 
decisão em grupo 
196 
A opinião especializada não é magia: 
 
• São utilizadas principalmente 
para durações máximas; 
 
• Também utilizadas para propor 
métodos para estimar; 
 
• Ajuda a verificar a qualidade 
de uma estimativa; 
 
• Quase sempre guiada por 
informações históricas 
 
• Brainstorms, TGN e outros 
podem ajudar 
Est. a dur. das atividades–Ferr. Tec: 
Opinião especializada 
197 
Medidas de Esforço de 
Desenvolvimento de Software 
Marcos Danilo 
Chiodi Martins 
Atividade 9 
Atividades 
Qual a vantagem e desvantagem de se utilizar 
uma estimativa análoga top down e uma 
estimativa paramétrica bottom-up? 
199 
Top-down: No começo do projeto, quando não há muitas informações, é a melhor 
indicação pela base histórica e análise análoga. O risco de erro é grande pois não tem 
análise de contingência. A estimativa é para o projeto como um todo e então pode ser 
quebrada para as fases do projeto (TOP > Down) 
 
 
 
Paramétrica: Mais precisa, grau de confiança maior porém precisa de ter as atividades 
já definidas, ou seja, bem mais tarde. 
Medidas de Esforço de 
Desenvolvimento de Software 
Aula 10 
Métricas e medidas 1 e 2 
Determinação de pontos de função 1 e 2 
Métricas utilizando pontos de função 
Técnicas de estimativa de custo e esforço 
Téc de estimat de estimat e estimat com base estatísticas 
Técnicas de estimativa de custo e esforço 
O que Estudaremos Nesta Aula? 
Vamos utilizar esta aula para cobrir o 
capítulo 5 do livro. 
COCOMO COCOMO II 
Estimativa 
de Puttman 
Estimativas 
com métodos 
ágeis 
Pontos de 
caso de uso 
Gestão por 
métricas 
Análise 
do valor 
agregado 
Estimativas 
estatísticas 
201 
Estimativas COCOMO 
202 
Para decidir, se devemos fazer um desenvolvimento para uma nova aplicação, devemos saber quanto tempo 
será necessário e quanto vai custar. Vale a pena? 
As estimativas de custos e prazos em software não são ciência exata, mas temos necessidades de diminuir, 
em nível de erro, das nossas estimativas. Existem muitos aspectos que podem influenciar nas estimativas. 
Um erro na estimativa pode comprometer o projeto e ser desastroso para os desenvolvedores.Estimativas COCOMO 
203 
O gráfico abaixo [sommerville, Ian] mostra o Nível de variação de erro de uma estimativa nas 
diversas fases do projeto. Apenas na fase de codificação se torna mais próxima do real. 
Hierarquia de Modelos 
204 
Modelo 2 (Intermediário): 
Chamado de COCOMO 
intermediário, computa o 
esforço de desenvolvimento 
como uma função do 
tamanho e de um conjunto 
de direcionadores de custo 
(definidos em tabelas) que 
incluem avaliações 
subjetivas do produto, 
hardware, experiência do 
pessoal e dos atributos do 
projeto (Pressman). 
Modelo 3 (Avançado): 
Chamado de COCOMO 
avançado, incorpora a 
versão intermediária e faz 
uma avaliação dos 
impactos nos 
direcionadores de custo 
sobre cada passo do 
processo de 
desenvolvimento (analise, 
projeto, codificação, 
testes...). 
 
Modelo 1 (Básico): 
Chamado de COCOMO 
Básico é um modelo 
estático de valor simples 
que computa o esforço de 
desenvolvimento de 
software como uma função 
do tamanho expresso em 
linhas de código 
(Pressman). 
 
 
 
COCOMO: que significa COnstructive COst MOdel 
(modelo de custo construtivo) foi criado por Barry 
Boehm em 1981 (Boehm, 1981) é de fato uma 
hierarquia de estimativas que busca realizar a 
estimativa de esforço e duração baseada em 
um modelo estatístico de uma só variável. 
205 
Modelo básico 
Modelo 
intermediário 
Modelo avançado 
• modelo simples que 
computa o esforço 
(custo) por meio de uma 
função paramétrica 
baseada apenas no 
tamanho do software 
• computa o esforço 
baseado no tamanho e 
também baseado em 
direcionadores de 
custo que incluem 
avaliações subjetivas 
de: produto, hardware, 
pessoal e outros 
atributos do projeto 
• modelo que é composto 
por pelos modelos 
básicos e intermediários 
e ainda uma avaliação 
do impacto dos 
direcionadores de 
custo sobre cada passo 
do processo de 
engenharia de software 
COCOMO Básico. 
• E = esforço aplicado em pessoas-mês; 
• D = tempo de desenvolvimento em meses cronológicos; 
• KLOC =número estimado de milhares de linhas de código 
do projeto; 
• ab, cb e bb , db = são os coeficientes e expoentes que se 
alteram dependendo do tipo de software que está sendo 
utilizado e que pode ser verificado na próxima tabela 
206 
• E = esforço aplicado em pessoas-mês; 
• D = tempo de desenvolvimento em meses cronológicos; 
• KLOC =número estimado de milhares de linhas de código do projeto; 
• ab, cb e bb , db = são os coeficientes e expoentes que se alteram dependendo do tipo 
de software que está sendo utilizado e que pode ser verificado na próxima tabela 
Modelo de projeto de software ab bb cb db 
Modelo orgânico 2,4 1,05 2,5 0,38 
Modelo semidestacado 3,0 1,12 2,5 0,35 
Modelo embutido 3,6 1,20 2,5 0,32 
207 
COCOMO Básico. 
Modelo orgânico: projetos de software simples, 
pequenos, pequenas equipes com relativa experiência. 
Trabalha-se um conjunto de requisitos não tão rígidos, 
pode exemplificar pequenos sistemas. 208 
COCOMO Básico. 
Modelo de projeto de software ab bb cb db 
Modelo orgânico 2,4 1,05 2,5 0,38 
Modelo semidestacado 3,0 1,12 2,5 0,35 
Modelo embutido 3,6 1,20 2,5 0,32 
Modelo semidestacado: projetos de sw intermediários (em 
tamanho e complexidade), nos quais há equipes com vários 
níveis de experiência, que devem programar uma 
combinação de requisitos rígidos. Por exemplo: um sistema de 
processamento de transações. 
209 
COCOMO Básico. 
Modelo de projeto de software ab bb cb db 
Modelo orgânico 2,4 1,05 2,5 0,38 
Modelo semidestacado 3,0 1,12 2,5 0,35 
Modelo embutido 3,6 1,20 2,5 0,32 
Modelo embutido: Um projeto que deve ser 
desenvolvido dentro de restrições operacionais, 
como por exemplo, sistema de controle de 
telefonia sistemas embutidos ou embarcados. 210 
COCOMO Básico. 
Modelo de projeto de software ab bb cb db 
Modelo orgânico 2,4 1,05 2,5 0,38 
Modelo semidestacado 3,0 1,12 2,5 0,35 
Modelo embutido 3,6 1,20 2,5 0,32 
211 
COCOMO: que significa COnstructive COst MOdel 
(modelo de custo construtivo) foi criado por Barry 
Boehm em 1981 (Boehm, 1981) é de fato uma 
hierarquia de estimativas que busca realizar a 
estimativa de esforço e duração baseada em 
um modelo estatístico de uma só variável. 
Modelo básico 
Modelo 
intermediário 
Modelo avançado 
• modelo simples que 
computa o esforço 
(custo) por meio de uma 
função paramétrica 
baseada apenas no 
tamanho do software 
• computa o esforço 
baseado no tamanho e 
também baseado em 
direcionadores de 
custo que incluem 
avaliações subjetivas 
de: produto, hardware, 
pessoal e outros 
atributos do projeto 
• modelo que é composto 
por pelos modelos 
básicos e intermediários 
e ainda uma avaliação 
do impacto dos 
direcionadores de 
custo sobre cada passo 
do processo de 
engenharia de software 
COCOMO Intermediário 
212 
Projeto de Software a b 
Orgânico 3,2 1,05 
Semidestacado 3,0 1,12 
Embutido 2,8 1,20 
213 
COCOMO Intermediário 
Atributos do projeto 
M
u
ito
 
b
a
ix
o
 
B
a
ix
o
 
N
o
rm
a
l 
A
lto
 
M
u
ito
 
A
lto
 
E
x
tra
 
A
lto
 
Confiabilidade exigida do software 0,75 0,88 1 1,15 1,40 ---- 
Tamanho do banco de dados da aplicação - 0,94 1 1,08 1,16 - 
Complexidade do produto 0,70 0,85 1 1,15 1,30 1,65 
Restrições ao desempenho de run-time - - 1 1,11 1,30 1,66 
Restrições de memória - - 1 1,06 1,21 1,56 
Volatilidade do ambiente de máquina virtual - 0,87 1 1,15 1,30 - 
Tempo de turnaround exigido - 0,87 1 1,07 1,15 
Capacidade de análise 1,46 1,19 1 0,86 0,71 - 
Capacidade em engenharia de software 1,42 1,17 1 0,86 0,70 - 
Experiência em aplicações 1,29 1,13 1 0,91 0,82 0 
Experiência em máquina virtual 1,21 1,10 1 0,9 - - 
Experiência em linguagens de programação 1,14 1,07 1 0,95 - - 
Uso de ferramentas de software 1,24 1,10 1 0,91 0,83 - 
Aplicação de métodos de engenharia de SW 1,24 1,10 1 0,91 0,82 - 
Cronograma de atividades de desenv exigido 1,23 1,08 1 1,04 1,10 - 214 
COCOMO Intermediário 
• modelo que é composto 
por pelos modelos 
básicos e intermediários 
e ainda uma avaliação 
do impacto dos 
direcionadores de 
custo sobre cada passo 
do processo de 
engenharia de software 
215 
COCOMO: que significa COnstructive COst MOdel 
(modelo de custo construtivo) foi criado por Barry 
Boehm em 1981 (Boehm, 1981) é de fato uma 
hierarquia de estimativas que busca realizar a 
estimativa de esforço e duração baseada em 
um modelo estatístico de uma só variável. 
Modelo básico 
Modelo 
intermediário 
Modelo avançado 
• modelo simples que 
computa o esforço 
(custo) por meio de uma 
função paramétrica 
baseada apenas no 
tamanho do software 
• computa o esforço 
baseado no tamanho e 
também baseado em 
direcionadores de 
custo que incluem 
avaliações subjetivas 
de: produto, hardware, 
pessoal e outros 
atributos do projeto 
COCOMO Avançado. 
• Usa a mesma fórmula do COCOMO Avançado, 
porém, distribui esforço e custo pelas fases do 
desenvolvimento de software, conforme a seguir. 
216 
217 
COCOMO Avançado. 
218 
COCOMO Avançado. 
O que Estudaremos Nesta Aula? 
COCOMO COCOMO II 
Estimativa 
de Putman 
Estimativas 
com métodos 
ágeis 
Pontos de 
caso de uso 
Gestão por 
métricas 
Análise 
do valor 
agregado 
Estimativas 
estatísticas 
219 
COCOMO II 
220 
O COCOMO II é uma melhorado COCOMO-81 e leva em 
consideração que há abordagens diferentes para o 
desenvolvimento, incorpora um conjunto de submodelos que 
produzem estimativas detalhadas. 
Os submodelos são: 
 
A– Um modelo de Composição de aplicação. 
B – Um modelo de projeto preliminar. 
C – Um modelo de Reuso. 
D – Um modelo de pós-arquitetura 
COCOMOII: Evolução do COCOMO e leva em 
consideração as abordagens mais modernas 
para o desenvolvimento de software. 
Composição de 
Aplicação 
Projeto 
Preliminar 
Reúso 
• Usado em 
projetos 
nos quais o 
software será 
composto por 
componentes. 
• utilizado antes 
do projeto de 
arquitetura 
detalhada do 
sistema estar 
disponível, mas 
quando já se tem 
acordados os 
requisitos de 
usuário. 
• Este modelo deve 
ser utilizado 
quando o projeto 
utilizará códigos 
reaproveitado de 
outros projetos. 
Pós arquitetura 
• Utilizar quando 
um modelo de 
arquitetura do 
sistema esteja 
disponível e seja 
capaz de 
identificar as 
estruturas de 
subsistemas 
221 
Composição de 
Aplicação 
Projeto 
Preliminar 
Reúso 
• Usado em 
projetos nos 
quais o software 
será composto 
por componentes. 
• utilizado antes 
do projeto de 
arquitetura 
detalhada do 
sistema estar 
disponível, mas 
quando já se 
tem acordados 
os requisitos de 
usuário. 
• Este modelo 
deve ser 
utilizado quando 
o projeto 
utilizará códigos 
reaproveitado 
de outros 
projetos. 
Pós arquitetura 
• Utilizar quando 
um modelo de 
arquitetura do 
sistema esteja 
disponível e 
seja capaz de 
identificar as 
estruturas de 
subsistemas 
222 
COCOMOII: Evolução do COCOMO e leva em 
consideração as abordagens mais modernas 
para o desenvolvimento de software. 
COCOMO II – Composição de aplicação 
PM = esforço pessoas/mês 
NAP = Número total de pontos de aplicação 
PROD = produtividade de pontos de aplicação 
que é dada segundo a tabela abaixo: 
Experiência e 
capacidade do 
desenvolvedor 
Muito 
Baixa 
Baixa Nominal Alta Muito 
Alta 
Capacidade e 
maturidade ICASE 
Muito 
Baixa 
Baixa Nominal Alta Muito 
Alta 
PROD (NAP/mês) 4 7 13 25 50 
Experiência e capacidade 
do desenvolvedor 
Muito 
Baixa 
Baixa Nominal Alta 
Muito 
Alta 
Capacidade e maturidade ICASE Muito Baixa Baixa Nominal Alta 
Muito 
Alta 
PROD (NAP/mês) 4 7 13 25 50 
223 
Modelo de Composição de aplicação 
224 
É usado para estimar o esforço necessário para projetos de prototipação e projetos em que o software é 
desenvolvido pela composição de componentes de software que já estão prontos ou usados de outros 
produtos existentes. A estimativa do software considera a produtividade do programador na linguagem, a 
experiência e capacitação do desenvolvedor e a capacidade de usar ferramentas para apoiar o 
desenvolvimento. O método baseia-se na estimativa de pontos de objetos (número de objetos) 
A composição da aplicação envolve, normalmente, o reuso significativo do software, por isto deve-se ajustar a 
estimativa baseada do uso total ao percentual de reuso esperado. A fórmula de cálculo de esforço é: PM = 
(NAP * ( 1 - %reuso)/100)/PROD Onde:PM é o esforço estimado em pessoa-mês.NAP é o número total de 
pontos de aplicação no sistema PROD é a produtividade em pontos de objeto, consultada na tabela de 
produtividade.(NOP/mês – Número de pontos de Objeto/mês ) 
 
 
Tabela de produtividade: 
O modelo pressupõe que não há esforços adicionais. 
Composição de 
Aplicação 
Projeto 
Preliminar 
Reúso 
• Usado em 
projetos 
nos quais o 
software será 
composto por 
componentes. 
• utilizado antes do 
projeto de 
arquitetura 
detalhada do 
sistema estar 
disponível, mas 
quando já se tem 
acordados os 
requisitos de 
usuário. 
• Este modelo 
deve ser 
utilizado quando 
o projeto 
utilizará códigos 
reaproveitado 
de outros 
projetos. 
Pós arquitetura 
• Utilizar quando 
um modelo de 
arquitetura do 
sistema esteja 
disponível e 
seja capaz de 
identificar as 
estruturas de 
subsistemas 
225 
COCOMOII: Evolução do COCOMO e leva em 
consideração as abordagens mais modernas 
para o desenvolvimento de software. 
Modelo Preliminar 
226 
COCOMO II – Projeto Preliminar 
PM = Esforço pessoas/mês 
Tamanho = dado em KSLOC (kilo source of lines) 
– normalmente uma transformação de pontos 
de função para KSLOC 
A = Coeficiente com o valor 2,94 
B = fator de escala que mostra a economia 
ou “deseconomia” de escala 
M = Multiplicador baseado em sete atributos 
de projeto que veremos mais abaixo. 
227 
Composição de 
Aplicação 
Projeto 
Preliminar 
Reúso 
• Usado em 
projetos 
nos quais o 
software será 
composto por 
componentes. 
• utilizado antes 
do projeto de 
arquitetura 
detalhada do 
sistema estar 
disponível, mas 
quando já se 
tem acordados 
os requisitos de 
usuário. 
• Este modelo 
deve ser 
utilizado quando 
o projeto 
utilizará códigos 
reaproveitado 
de outros 
projetos. 
Pós arquitetura 
• Utilizar quando 
um modelo de 
arquitetura do 
sistema esteja 
disponível e 
seja capaz de 
identificar as 
estruturas de 
subsistemas 
228 
COCOMOII: Evolução do COCOMO e leva em 
consideração as abordagens mais modernas 
para o desenvolvimento de software. 
COCOMO II – Modelo de Reúso 
ASLOC é o número total de linhas de código reusado, 
incluindo o código que é gerado automaticamente. 
AT é a porcentagem de códigos reusados gerados 
automaticamente. 
ATPROD é a produtividade dos engenheiros na 
integração do código, que no COCOMO II foi calculada 
como sendo 2400 declarações-fonte por mês. 
229 
Modelo de Reuso 
230 
Conclusão 
231 
Composição de 
Aplicação 
Projeto 
Preliminar 
Reúso 
• Usado em 
projetos 
nos quais o 
software será 
composto por 
componentes. 
• utilizado antes 
do projeto de 
arquitetura 
detalhada do 
sistema estar 
disponível, mas 
quando já se 
tem acordados 
os requisitos de 
usuário. 
• Este modelo 
deve ser 
utilizado quando 
o projeto 
utilizará códigos 
reaproveitado 
de outros 
projetos. 
Pós arquitetura 
• Utilizar quando 
um modelo de 
arquitetura do 
sistema esteja 
disponível e seja 
capaz de 
identificar as 
estruturas de 
subsistemas 
232 
COCOMOII: Evolução do COCOMO e leva em 
consideração as abordagens mais modernas 
para o desenvolvimento de software. 
COCOMO II – Modelo de Pós Arquitetura 
PM = Esforço pessoas/mês 
Tamanho = dado em KSLOC (kilo source of lines) 
– normalmente uma transformação de pontos 
de função para KSLOC 
A = Coeficiente com o valor 2,94 
B = fator de escala que mostra a economia 
ou “deseconomia” de escala 
M = Multiplicador baseado em 14 atributos 
de projeto que veremos mais abaixo. 
233 
O que Estudaremos Nesta Aula? 
COCOMO COCOMO II 
Estimativa 
de Putman 
Estimativas 
com métodos 
ágeis 
Pontos de 
caso de uso 
Gestão por 
métricas 
Análise 
do valor 
agregado 
Estimativas 
estatísticas 
234 
Estimativa de Puttnam 
235 
O que Estudaremos Nesta Aula? 
COCOMO COCOMO II 
Estimativa