MEDIDAS DE ESFORÇO DE DESENVOLVIMENTO DE SOFTWARE - AULAS 6 a 10

Prévia do material em texto

AULA 6
ESTIMATIVAS DE ESFORÇO E PRAZO
COCO MO/COCO MO II
Nesta aula, você irá:
1.Aprender a fazer estimativas de prazo e 
esforço, utilizando métodos COCOMO.
2.Analisar as limitações de estimativas, 
dependendo da fase do projeto que a 
estimativa é feita (erro estimado).
3.Aprender a utilização dos métodos de 
estimativa com ponto função.
4.Classificar o software em grau de dificuldade, 
segundo critérios do COCOMO, para produzir 
à estimativa.
5.Aprender a diferença do COCOMO II e o 
COCOMO.
6.Como determinar a complexidade.
7.Tratar o fator de ajuste.
8.Definir o número de ponto função por tipo de 
contagem.
Estimativas COCOMO
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. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                1
Existem muitos aspectos que podem influenciar nas 
est imat ivas. Um erro na est imat iva pode 
comprometer o projeto e ser desastroso para os 
desenvolvedores.
As estimativas, normalmente, são feitas a partir de 
uma série histórica, baseada em projetos feitos 
anteriormente. Nesse caso, registraram-se várias 
informações, tempo por fase do projeto, tempo de 
codificação, quantidade de programadores e outras 
informações. Essas informações, após tratadas, são 
a base para estimar e acompanhar a execução de 
novos projetos.
Os dados podem ser colocados em gráficos e estes 
gráficos definem famílias de curvas. Essas curvas 
são ajustadas a funções matemáticas. Essas funções 
matemáticas são usadas para valores que não 
constam nas tabelas.
Quando não se tem nenhuma informação é comum 
fazer as estimativas baseadas na experiência dos 
profissionais. Nesse caso, podem-se registrar as 
estimativas de vários profissionais e trabalharmos 
com valores resultantes destes valores. Pode-se, por 
exemplo, usar o valor segundo a média ponderada, 
segundo a fórmula:
 PM + Pm + 4*Pmedio
Prazo estimado = __________________
 6
 
onde: PM é o maior prazo dado
 Pm é o menor prazo dado
 Pmedio é a média dos prazos dados
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                2
Estimativas, normalmente, são feitas a partir 
de série histórica baseada nos projetos feitos 
anteriormente.
• Registram-se várias informações
(tempo por fase do projeto, de codificação, 
quantidade de programadores e outras 
informações).
• As informações são a base para estimar e 
acompanhar a execução de novos projetos.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                3
Base de informações:
• Os dados são colocados em gráficos e estes 
gráficos definem famílias de curvas.
• Estas curvas são ajustadas a funções 
matemáticas.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                4
Nível de erro aceitável
Depende  da  faixa  de  valores
• Quando não se tem nenhuma informação é 
comum fazer as estimativas baseadas na 
experiência dos profissionais.
- método Delphos
Recomendação do PMI para estimativas de 
prazo
Prazo estimado = PM + Pm + 4*Pmedio 
 6
Onde : PM é o maior prazo dado Pm é o menor 
prazo dado e Pmedio é a media dos prazos 
dados
Exemplo de aplicação:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                5
Nove técnicos experientes deram uma 
estimativa de prazo para uma determinada 
tarefa que não temos nenhum registro.
Tec1: 10 dias tec2: 20 dias tec3: 15 dias
Téc4: 12 dias tec5: 8 dias tec6: 25 dias
Tec7: 15 dias tec8: 12 dias tec9: 15 dias
Para estimar o prazo de projeto devemos 
calcular a média dos prazos:
Prazo médio=
(10+20+15+12+8+25+15+12+15)/9 = 15 
dias
Prazo de projeto =( 25 + 8 + 4*15)/6 = 15,5 
entendendo: 15 dias + meio dia
Se convertermos em horas de trabalho, 
considerando que um dia tem 8 horas de
trabalho, a tarefa está estimada em levar 15*8 
+ 4 =124 horas
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                6
O processo de estimativa envolve basicamente 
quatro atividades:
1.estimar o tamanho do produto a ser gerado;
2.Estimar o esforço empregado na execução do 
projeto;
3.estimar a duração do projeto; 
4.estimar o custo do projeto.
• Nível de variação de erro de uma estimativa 
nas diversas fases do projeto.
• 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.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                7
Para se fazer estimativa, usam-se duas 
unidades básicas: 1000 linhas de código 
(KLOC) e Ponto Função (PF).
 
As estimativas, utilizando o tamanho (KLOC) 
para serem confiáveis, devem estar presentes 
em fases adiantadas do projeto, devido à 
incerteza.
Um dos primeiros pesquisadores de software a 
se preocupar com o assunto de estimativas e 
estudar os custos envolvidos em projetos foi 
Barry Boehm, em seu livro sobre engenharia 
econômica do software em 1891. Nesse 
trabalho foram estudados mais de 5000 
projetos de software.
–Estes softwares foram classificados segundo 
uma hierarquia de modelos;
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                8
–Recebeu o nome de COCOMO.
–(COnstructive COst MOdel - Modelo de Custos 
Construtivos)
COCOMO
Classificação do tipo do software:
• Modelo 1 (básico): é um modelo estático 
de valor simples que computa o esforço de 
desenvolvimento de software.
• Modelo 2 (intermediário): computa o 
esforço de desenvolvimento como uma função 
d o t a m a n h o , e d e u m c o n j u n t o d e 
direcionadores de custo (definidos em tabelas) 
que incluem avaliações subjetivas do produto, 
hardware, experiência do pessoal e dos 
atributos do projeto.
• 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...)
Mais sobre modelos usados para classificar o 
tipo do software
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                9
Usando a terminologia de Boehm, o COCOMO 
pode ser aplicado em três classes de projeto:
1– Modo Orgânico ou Convencional: 
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.
2– Modo Semidestacado ou Difuso: 
Projetos de software intermediário (em 
tamanho e complexidade), nos quais temos 
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.
3– Modo Embutido ou Restrito : 
Um projeto que deve ser desenvolvido dentro 
de restrições operacionais, como por exemplo, 
sistema de controle de telefonia.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                10
As equações para o COCOMO básico são:
Para
N éo número de pessoas recomendadas no 
projeto;
E é o esforço aplicado em pessoas-mês;
D é o tempo de desenvolvimento em meses 
cronológicos;
KLOC é o número estimado de linhas de código 
do projeto (em milhares).
Os coeficientes ab e cb, e as exponenciais bb e 
db são fornecidos de acordo com a tabela 
abaixo:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                11
No modelo intermediário, o básico é ampliado, 
considerando-se 4 grandes categorias 
direcionadoras de custos:
A–Atributos do produto:
I–Confiabilidade exigida do software.
II–Tamanho do Banco de dados.
III–Complexidade do software.
B–Atributos do Hardware
I–Restrições de desempenho de run-time.
II-Restrições de memória.
III–Mudanças do ambiente de software.
IV–Tempo de resposta–turnaround.
C–Atributos de pessoal
I-Capacidade dos analistas.
II–Capacidade dos programadores.
III–Experiência na aplicação.
IV–Experiência no ambiente de Hardware.
V - E x p e r i ê n c i a c o m a l i n g u a g e m d e 
programação.
D–atributos de projeto
I–Uso de ferramenta de software.
II–técnicas modernas de programação.
III–Prazo requerido para o desenvolvimento.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                12
Cada um dos itens acima (15) deve ser 
avaliado (em importância e valor) numa escala 
de 6 pontos:
- Muito baixo
- Baixo
- Normal
- Alto
- Muito alto
- Extra alto
Com esta avaliação para cada um dos 15 itens, 
entra-se na tabela de Multiplicadores de 
Esforço de Desenvolvimento de Software e um 
multiplicador de esforço é determinado para 
cada item:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                13
O produto dos índices encontrados na tabela torna-se 
o EAF
E a fórmula de determinação do esforço (E) fica
(deve-se usar KLOC)
Onde o coeficiente a e a exponencial b são 
fornecidos pela tabela:
Projeto de software !! ! a ! ! ! b 
Orgânico ! ! ! ! ! 3,2 !! ! 1,05
Semidestacado!! ! ! 3,0 !! ! 1,12
Embutido ! ! ! ! ! 2,8 !! ! 1,20
Exemplo de uso do COCOMO 81.
Considere um software com 33,3 Kloc, usando o 
modelo semidestacado, temos:
E = 3,0 (kloc)1,12
= 3,0 (33,3)1,12
= 152 pessoas-mês
Duração do projeto:
D = 2,5 (E)0,35
= 2,5 *(152)0,35
= 14 meses
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                14
O número ideal de pessoas no projeto
N = E/D.
= 152/14,5
= 11 pessoas
Pode-se balancear o número de pessoas, 
variando o prazo de duração.
Exemplo 2:
Considere que se deseja fazer estimativas de 
esforços para um software que irá apoiar o controle 
de equipamentos de uma empresa. Após uma análise 
de ponto função, determinou-se que o tamanho do 
software é de 236 PF não ajustado.
Como as fórmulas do COCOMO81 foram construídas 
com KLOC, devemos buscar, em uma tabela de 
transformação, o número de Linhas para cada função. 
Se utilizarmos a linguagem ACESS, temos:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                15
Usando o COCOMO intermediário, o gerente 
considerou o projeto como orgânico.
E usaremos as fórmulas:
Analisando os 15 direcionadores, o gerente 
concluiu os seguintes resultados:
•Complexidade do software: alta.
•Restrições quanto ao uso da memória: alto.
•E x p e r i ê n c i a c o m a l i n g u a g e m d e 
programação: baixa.
•Capacidade dos programadores: baixa.
Os outros atributos foram considerados 
normais.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                16
Assim, pode-se determinar o EAF
EAF = (1,15 * 1,06*1,14*1,17) = 1,63
Dessa forma, pode-se estimar o esforço:
E o prazo
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                17
Com os dados, pode-se concluir que iremos 
necessitar de: 52,42 / 11,26
- que nos indica 5 profissionais para trabalhar 
no projeto durante 11 meses.
COCOMO II
O COCOMO II é uma melhora do COCOMO- 81
•leva em consideração que há abordagens 
diferentes para o desenvolvimento;
•incorpora um conjunto de sub modelos que 
produzem estimativas detalhadas.
•
Os sub modelos 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;
MODELO DE COMPOSIÇÃO DE APLICAÇÃO
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                18
É 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 
capac i tação do desenvo lvedor 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 compos i ção da ap l i cação envo lve , 
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:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                19
Experiência e 
capacitação do 
desenvolvedor
Muito 
baixa
baixa Nominal alta Muito alta
Maturidade e 
capacitação de 
case
Muito 
baixa
baixa Nominal alta Muito alta
PROD(NOP/
mês)
4 7 13 25 50
O modelo pressupõe que não há esforços 
adicionais.
MODELO PRELIMINAR
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                20
Modelo de reuso
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                21
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                22
CONCLUSÃO
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                23
REGISTRO DE PARTICIPAÇÃO
1. Considere a tabela abaixo, que contém 
dados sobre dez projetos e que será utilizado 
para estima o esforço e o prazo para um novo 
projeto.
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                24
Baseado na recomendação do PMI sobre 
estimativas de prazos, pode-se afirmar:
1) O esforço estimado deve ser de 14,63 
mês*homem e o prazo 10,73 meses. 
2) O esforço estimado deve ser de 14,63 
mês*homem e o prazo 8,00 meses. 
3) O esforço estimado deve ser de 14,70 
mês*homem e o prazo 10,73 meses. 
4) O esforço estimado deve ser de 21,00 
mês*homem e o prazo 16,00 meses. 
5) O esforço estimado deve ser de 8,00 
mês*homem e o prazo 6,00 meses. 
 
2. Considere o Gráfico mostrado abaixo 
(Boehm)
Considere as afirmativas abaixo e assinale a 
afirmativa correta:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                25
1) Ao se estimar o prazo, este valor deve ser 
constante ao longo das fasesdo projeto. 
2) Ao se determinar um valor, por exemplo, 8 
meses, o verdadeiro valor, na fase de 
requisitos, é de 32 meses*homem e para o e 
meses para o prazo. 
3) O gráfico mostra o nível de incerteza 
q u e t e m o s p a r a c a d a f a s e d o 
desenvolvimento. 
4) A Curva mostra que a entrega do software 
pode variar de um a 25 meses. 
5) As estimativas têm dois limites: inferior e 
superior. E, nós devemos escolher o limite 
inferior. 
 
3. Um software do tipo ERP deverá ser 
desenvolvido por várias equipes. Os requisitos 
estão formalizados. Nesse caso, para este 
software de %,8 Kloc. Não temos informações 
sobre a plataforma de hardware, experiência 
das pessoas ou método de desenvolvimento.
 N e s s e c a s o , c l a s s i f i c a r í a m o s o 
desenvolvimento, segundo Boehm, como:
1) Intermediário e semidestacado. 
2) Básico e orgânico. 
3) Intermediário e orgânico. 
4) Intermediário e restrito. 
5) Básico restrito. 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                26
AULA 7
ESTIMATIVAS PUTNAM E MÉTODOS VOLTADO PARA 
PONTO FUNÇÃO
Nesta aula, você irá:
1.Aprender sobre o método de Putnam.
2.Analisar a fórmula do método de Putnam.
3.Aprender sobre outras formas de estimativas 
de projetos orientados a objetos.
4.Aprender sobre estimativas com métodos 
ágeis.
5.Aprender a usar APF para determinar 
estimativas.
ESTIMATIVAS – OUTROS MODELOS E USO DE PF
Esse modelo é um modelo dinâmico de 
múltiplas variáveis que pressupõem a 
distribuição do esforço ao longo da existência 
de um projeto de desenvolvimento. Foi 
construído, analisando-se grandes projetos.
O esforço em grandes projetos é caracterizado 
como mostrado na figura abaixo, reproduzida 
do professor Pressmam: 
Essa figura mostra curvas clássicas que foram 
apresentadas por Lorde Rayleigh e forma 
compilados por Norden, por isto a curva é 
chamada de curva Rayleigh-Nortem. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                27
ESTIMATIVAS PUTNAM E MÉTODOS VOLTADOS PARA O PF
Estimativas de projetos orientado a objetos
O software orientado a objetos deve ter outra 
abordagem:
1.D e s e n v o l v e r e s t i m a t i v a s , u s a n d o 
decomposição de esforço, análise FP que 
seja aplicável a aplicações convencionais.
2.Desenvolver casos, usos e determine uma 
contagem. Reconhecer que o número de 
casos e uso podem modificar à medida que 
se desenvolve o projeto.
3.A partir do modelo de análise, determinar o 
número de classes-chave.
4.Categorizar o tipo de interface para 
aplicação, para as classes de apoio. 
-Multiplicar o número de classes chaves 
pelo multiplicador, para obter uma 
estimativa para o número de classes de 
apoio.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                28
5.Multiplicar o número total de classes (chave 
e apoio) pelo número médio de unidades de 
trabalho por classes. Autores, como Lorenz, 
sugerem entre 15 a 29 pessoas dia por 
classe.
6.Fazer a verificação cruzada em estimativas 
baseadas em classes, multiplicando o número 
médio de unidades por caso e uso.
Tipo de interface Multiplicador
Não IGI 2,0
Interface com o usuário 2,25
baseado em texto
IGI 2,5
IGU Complexa 3,0
Estimativas com métodos ágeis
Um p ro je to usando um p rocesso 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 software.
3 a- Cada tarefa é estimada separadamente.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                29
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 volume de 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ár ios 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.
Estimativa usando Caso e USO
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 e x i s t em r eg ra s d e c on t agem 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                30
padronizadas. Tem-se estudado a aplicação em 
conjunto da PCU e APF, tentando explorar a 
relação entre elas existente.(EDMÉIA,2004). 
Estimativas usando ponto função
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:
Métricas primitivas utilizadas para medir a 
qualidade dos processos de software
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 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                31
condição de padrão internacional, através da 
norma ISO/IEC 20926. A técnica pode ser 
cons iderada 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 
requer idos para o desenvolv imento e 
manutenção de software. 
Sistema de manutenção de clientes
Descrição
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ísticas
- 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
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                32
- 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.
Lista de ator(es):
Usuário (funcionário da empresa).
Caso de uso identificados:
➡Exibir Clientes Cadastrados
➡Efetuar Manutenção de Clientes
Diagrama de casode uso simplificado:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                33
Usando–se Análise de Pontos de Função, que 
tem sido cada vez mais utilizada para 
estimativas de tamanho, esforço e prazo de um 
s i s t e m a d e s o f t w a r e , c o m b a s e n a 
funcionalidade fornecida ao usuário. Vamos 
estimar o preço e prazo para desenvolver o 
sistema de manutenção de clientes.
Suponha que precisamos dar um orçamento 
para desenvolver o sistema.
 Para isto vamos usar APF para:
1.Est imativa do tamanho funcional da 
aplicação.
2.Est imat iva do custo e esforço para 
desenvolvimento.
Determinar o tamanho funcional do sistema de 
manutenção
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                34
Ent idades e funções do processo de 
manutenção de clientes:
A tecno log ia usada no s i s tema para 
manutenção de cliente será de implementação 
em um site (processamento nas nuvens), 
usando a linguagem PHP (com suporte a 
objetos), envolvendo 3 camadas : camada de 
dados , camada de aplicação e camada de 
apresentação.
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:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                35
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                36
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                37
CONCLUSÃO
Nesta aula, você aprendeu: 
•Aprendeu sobre o método de Putnam.
•Analisou a fórmula do método de Putnam.
•Aprendeu sobre outras formas de estimativas 
de projetos orientados a objetos.
•Aprendeu sobre estimativas com métodos 
ágeis.
•Aprendeu a usar APF para determinar 
estimativas.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                38
REGISTRO DE PARTICIPAÇÃO
1.Considere a constante CK na formula 
1) Representa as condições de trabalho da 
empresa ref let ido por projetos já 
realizados 
2) Representa um determinado projeto K para 
os quais devemos analisar as condições 
3) Representa uma função que reflete o 
crescimento de uma empresa 
4) Representa o esforço despendido em 
pessoas-ano 
5) Representa a fase do projeto, refletindo a 
etapa K 
 
2. No Software orientado a objetos, segundo o 
Prof. Pressman, podemos afirmar:
1) Deve-se usar a estimativa de tamanho para 
dimensionar um caso e uso. 
2) Deve-s analisar cada caso e uso e fazer 
estimativas de tamanho somando-os no final 
3) Deve-se usar a estimativa por PF 
usando-se a decomposição de casos e uso 
4) Deve-se definir um caso e uso padrão e o 
resultado aplicado ao longo do projeto 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                39
5) Deve-se modelar as classes principais e 
depois aplicar PF que servirá de unidade para o 
resto do projeto. 
 
3. Considerando a pesquisa realizada pela 
Secretaria de Política de Informática – 
SEPIN , em 2001, cujo resultado é 
apresentado na tabela:
Podemos concluir de forma correta:
1) As empresas que utilizam LOC são todas do 
governo. 
2) As empresas que utilizam Ponto função são 
todas do governo 
3) Todas as empresa do Governo e privadas 
usam LOC ou Ponto função 
4) As estimativas no Brasil ainda são 
feitas, na sua maioria, sem método 
5) As estimativas no Brasil feitas com ponto 
função tem muita rejeição. 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                40
4. A primeira coisa a ser feita em uma empresa 
que vai implementar um processo de 
estimativas confiáveis é:
1) definir um processo e determinar 
valores a serem coletados dos projetos. 
No inicio tentar buscar uma base histórica 
em outra empresa. 
2) Treinar todos os funcionários no uso de 
ponto função 
3) Fazer sessões de avaliação para novos 
projetos, de forma estruturada, para obter 
estimativas 
4) Usar métodos baseado em tamanho, com 
uma linguagem padronizada para uso na 
empresa. 
5 ) E s t i m u l a r o s p r o g ra m a d o r e s e m 
desenvolverem código, sem método, pois 
quanto maior o código melhor para a 
estimativa. 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                41
AULA 8
GESTÃO DE PROJETOS USANDO APF
Nesta aula, você irá:
1.Dimensionar o valor de um PF para uma 
empresa.
2.Utilizar PF para dimensionar o custo no 
processo de desenvolvimento.
3.Controlar custos por ponto função.
4.Controlar e estimar prazos para projetos.
5.Fazer gestão usando APF.
Introdução
A APF tem o seu uso aceito pela maioria das 
empresas, pois, estabelece um padrão e 
uniformidade de contagem, quando se usa o 
manual de contagem. Isso favorece o uso pelas 
e m p r e s a s . A l é m d i s s o , n ã o t e m o s 
inconvenientes que as contagens de LOC 
apresentam. Trabalhar com a funcionalidade, 
liberta o profissional que faz orçamentos, de 
aspectos que só serão definidos na fase de 
desenho do software e esta é uma vantagem 
importante. Imagine você ter que decidir, 
usando a contagem de número de linhas de 
código se ainda nem decidiu que linguagem irá 
utilizar. Outro aspecto importante é que o de 
processo de desenvolvimento seja qualquer 
um. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                42
As empresas, hoje, buscam padronizar o seu 
processo de desenvolvimento ou mais de um, 
dependendo do tipo de produto que pretendem 
utilizar. No nível três do CMM, que é uma 
referência mínima para as empresas que 
desejam trabalhar com qualidade, o processo é 
estabelecido e os profissionais treinados no 
processo. 
Custo de um PF para a empresa
Em empreendedorismo, você deve aprender 
que as empresas têm dois tipos de custo, o fixo 
e o variado. O custo total da empresa, em um 
determinado período ou para uma determinada 
produção, é a soma dos dois custos. Na 
empresa que trabalha com ponto função, deve-
se determinar o valor em termos monetários 
para o total de PF produzido em um 
determinado período.
Vamos supor, para efeitos didáticos, que uma 
empresa entregou no prazo de um mês 180,2 PF. E 
essa mesma empresa tem um custo total de R$ 
27580,00.
Assim o custo dessa empresa, por ponto função é 
de: R$ 27580,00/ 180,2 PF
O Valor, para fins de controle e orçamentos, é de um 
custo de: 1515,38
O valor calculado acima, pode ter sido determinado, 
em determinadas condições, com um valor de 
aluguel, um nível de salário e outros aspectos que 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                43
podem ser alterados, portanto, deve ser revisto 
periodicamente como, por exemplo, mensalmente e 
informado para os gestores. Nesse mês (ou 
período), segundo o cálculo acima, o nosso custo 
será de 1515,38/PF.
Custo de um PF para a empresa
Também, se pode determinar o “BREAK EVENT 
POINT”, ou ponto de equilíbrio, em termos de PF, 
determinar o número de PF que se deve produzir 
para a empresa iniciar a dar lucro. Veja o gráfico 
abaixo:
Pode-se determinar o númerode PF que a empresa 
deve produzir para iniciar a sua fase de lucro. 
A importância de uma base estatística de projetos
É preciso que se mantenha uma base estatística de 
projetos realizados e que a tomada de registros para 
esta base estatística esteja adequada aos processos 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                44
de desenvolvimento da empresa e a metodologia 
usada em cada etapa, ou template estabelecido.
Nesse caso, vamos supor que nossa empresa tem 
registrado por projeto, dividido por caso e uso, as 
fases e registrando os respectivos custos por etapa 
podemos identificar % de utilização valor total para 
cada fase.
A importância de uma base estatística de projetos
Dessa forma registrando – se, para cada caso e uso, 
esses dados, podemos estabelecer um % de 
utilização médio para a empresa. Você poderia ficar 
preocupado com aspectos como complexidade ou 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                45
característica do software, mas isto já esta 
resolvido. Esses aspectos foram considerados, 
quando se fez a análise de ponto função.
Também, determina-se a média de implementar um 
ponto função, no caso estamos considerando a 
unidade como dias, do caso e uso, registrado acima, 
obtém o número de horas pelo total de PF temos: 
234 horas/ 180,2 PF = 1,30 horas /PF
 
O mesmo para o custo por PF:
 
R$ 6834/180,2 = R$ 37,93 /PF
Tabela de distribuição dos pontos funções
Depois de um determinado período de observação, 
pode-se determinar uma tabela de distribuição dos 
pontos funções como abaixo:
ATENÇÃO
Essas tabelas devem ser periodicamente 
ajustadas para refletirem a realidade da 
empresa , de modo que a base 
estatística deve ser ampliada.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                46
Conclusão
A organização de parâmetros de decisão, ao longo 
do processo, é fundamental para se gerar um 
sistema confiável de estimativas e de controle 
gerencial, para o acompanhamento de projetos, em 
termos de custo e prazo.
Estudo de casos de contagem de PF
Contar o números de PF de um sistema com 
as seguintes característica:
Tem uma tela inicial com um botão: iniciar
Tela de logon para identificar usuarios com os 
campos (username, senha)
Tela de seleção com tres botoes (fornecedor, 
produto,sair)
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                47
Quando o usuario é administrador de sistemas 
tem uma tela para controlar usuários com as 
funçoes: criar um novo usuário, bloquear, 
 retirar o usuário, atualizar, trocar senha, listar 
usuários, listar últimos acessos
Definir tipo de contagem
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                48
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                49
TOTAL  DE  CONTRIBUIÇAO  DOS  ALI  E  AIE  =      29  PF
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                50
Tela fornecedor 
Entrada = 3 (incluir, alterar, deletar)
 
Saida = 2(relatorio de fornecedor. 
 relatorio de produtos)
Consulta =2 (cod.prod, cod. Fornecedor)
----------------------------------------------------------
Incluir – 
2 arquivos referenciados
9 itens de dados (não contar as repetiçoes
Alterar –
1 arquivo referencia – proibido alterar cep
 6 itens
Deletar – 1 arquivo referenciado
 9 itens
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                51
Relatorio for. 
1 arquivo referenciado – 9 itens
Rel por cod produto – 1 arquivo - 9 itens
-----------------------------------------------------
Tela produto
Entrada = 3 (incluir, alterar,deletar)
Saida = 2 (rel.estoque)
Consulta = 1 (cod.prod)
-----------------------------------------------------
Entradas
Incluir – 1 arquivo referenado + 4 itens
deletar – 1 arquivo ref. + 4 itens
Alterar – 1 arquivo ref. + 4 itens
-----------------------------------------------------
Saidas
Rel estoque – 1 arquivo + 4 itens
Rel cod produto – 1 arquivo ref + 3 itens 
(cod-pr, descriçao,quantidade)
-----------------------------------------------------
Consulta
1 arquivo ref + 4 itens
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                52
Total por transações: 75 PF
Total por arquivos : 29 PF
Total : 104 PF (não ajustados)
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                53
Nesta aula, você: 
•Aprendeu a dimensionar o valor de um PF 
para uma empresa.
•Aprendeu como utilizar PF para dimensionar o 
custo no processo de desenvolvimento.
•Aprendeu a Controlar custos por ponto 
função.
•Aprendeu como Controlar e estimar prazos 
para projetos.
•Aprendeu a gerenciar usando APF.
REGISTRO DE PARTICIPAÇÃO
1. Trabalhar com APF tem como principal 
vantagem em relação ao KLOC.
1) Não existe vantagem sobre um ou outro, 
são idênticos 
2) Trabalhar com a funcionalidade é mais 
natural pois independe da implementação 
3) Trabalhar com linha de código é mais 
natural pois o código precisa ser implementado 
4) Na fase de analise quando se usa KLOC não 
precisa necessariamente e a previsão é precisa 
5) O KLOC pode-se transforma em PF, 
portanto, pode-se trabalhar com um ou outro, 
em qualquer fase, e é independente da 
linguagem escolhida 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                54
2. Considere uma empresa que entregou no 
mês de outubro de 2010 um total de 980 PF. 
Esta empresa têm um total de 5 analista que 
ganham em média R$ 5000,00 e 8 
programadores que ganham em média R$ 
3000,00, um analista de testes cujo salário é R
$ 6000,00 além de dois documentadores cujo 
salário é R$ 2000,00. O gerente geral de 
produção ganha R$ 9000,00. Determinou-se 
que o custo fixo é de R$ 12 000,00 (alugueis, 
t e l e f o ne , l u z , s e c r e t á r i a s , l impe za , 
condomínio). Os encargos sociais dos 
empregados são de 100%. O total de 
impostos é de 21% sobre a receita bruta.
1) Os dados acima são insuficientes para se 
determinar o custo da empresa por PF. 
2) O custo variável deve incluir todos os dados 
inclusive aluguel, telefone, luz 
3) O custo de gerar um ponto função, na 
empresa acima, deve levar em consideração 
apenas os elementos do setor produtivo 
4) O custo de um ponto função deve 
considerar todos os custos inclusive os 
impostos 
5) O custo depende do gerente que vai definir 
o que pode ou não entrar no custo. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                55
AULA 9
USO DE REGISTROS TABULADOS, INTERPOLAÇÃO E ERRO 
ASSUMIDO
Nesta aula, você irá:
1.Utilizar registros estatísticos para gerar 
estimativas.
2.D e f i n i r o n í v e l d e e s t i m a t i v a 
(linear ,exponencial).
3.Aprender a fazer interpolação linear ou não
4.Definir os riscos nas estimativas.
5.Definir nível de erro.
6.Conhecer outro métodos matemáticos para 
interpolação.
Introdução
Definir um conjunto de dados que permita se 
ter gerência do processo e do produto é 
importante, mas precisamos aprender a 
trabalhar com estes dados. Suponha que 
estamos falando de uma empresa com um 
tempo de vida curto e que entreoutros dados 
registrou-se os apresentados na tabela 
abaixo:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                56
projeto total PF estimado
total PF 
realizado
homem*horas 
trabalhadas
prazo (dias 
uteis)
modulo de ponto 82,45 112,2 2400 40
sistema estoques 180,90 179,34 8400 70
Gestao de vendas 198,20 215 9600 160
controle de trafego 268,30 265,2 7200 180
sistema academico 431,45 420,78 9600 160
Podemos colocar estas informações em um 
gráfico para determinarmos novos esforços 
para uma determinada quantidade de PF. 
Pode-se também tirar da tabela o gráfico que 
mostra o grau de erro da estimativa em 
relação ao realizado, em ponto função. 
Verificou-se uma tendência linear de 45 graus 
o que mostra que a estimativa está muito 
próxima da real izada, com pequenas 
diferenças.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                57
Os p r o j e t o s da no s sa empre sa s ão 
relativamente pequenos e estas distorções são 
absorvidas na margem de segurança que a 
empresa dá em seus orçamentos.
Estes dados, entretanto podem nos levar a 
sérios prejuízos se não forem tratados 
tecnicamente.
 
Os pontos (ou falta deles) podem nos levar a 
uma serie de suposições. Se assumimos que o 
comportamento é próximo de linear, devemos 
saber que esta simplificação poderá nos custar 
caro, pois dificilmente temos este tipo de 
comportamento.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                58
Se desejamos corre menos risco podemos 
considerar que os pontos tem a tendência de 
uma curva de segundo grau:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                59
Ou uma curva logarítmica
Na nossa tabela temos ainda poucos dados 
para definirmos o grau de incerteza e definir 
por uma das curvas.
 
Quando estimados utilizando estas curvas 
introduzimos riscos nas nossas estimativas, 
para valores que ainda não constam na tabela, 
ou estão fora do intervalo existente até o 
momento.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                60
Observe que para um número menor de PF 
usar a tendência linear nos leva a estimar 
valores de forma mais alta que da forma 
exponencial, invertendo-se a tendência a 
partir do momento que os projetos se tornam 
significativos.
Interpolação
Considere que temos um levantamento de um 
produto com 230 PFA e devemos usar a tabela 
para definir o esforço necessário. Se 
analisarmos a tabela não temos como obter a 
informação diretamente, pois nenhum projeto 
até o momento tem 230PFA. Para isto 
precisamos deduzir um valor a partir dos 
dados da tabela. Este processo chama-se de 
interpolação.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                61
Em Matemática é o método que permite 
construir um novo conjunto de dados a partir 
de um conjunto discreto de dados pontuais 
previamente conhecidos.
Em engenharia é comum dispor-se de dados 
pontuais obtidos a partir de uma amostragem 
ou de um experimento 
Tal conjunto de dados pontuais (também 
denominado conjunto degenerado) não 
possui continuidade, e isto muitas vezes 
torna demasiado irreal a representação 
teórica do fenômeno real e observado.
Através da interpolação, pode-se construir 
uma função que se ajuste nestes dados 
pontuais, representando a continuidade 
desejada.
Outra ap l i cação da interpo lação é a 
aproximação de funções complexas por 
funções mais simples.
Suponha que tenhamos uma função, mas que 
seja complicada demais para que seja possível 
avaliá-la de forma eficiente. 
Podemos, então, escolher alguns dados 
pontuais da função complicada e tentar 
interpolá-los com uma função mais simples. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                62
Obviamente, quando utilizamos a função mais 
s imp les pa ra ca l cu l a r novos dados , 
normalmente não se obtém o mesmo 
resultado da função original, mas dependendo 
do domínio do problema e do método de 
interpolação utilizado, o ganho de simplicidade 
pode compensar o erro.
Funções
O desenho mostra que ao se conhecer poucos 
pontos temos uma série de funções que 
podem se ajustar.
O problema da interpolação consiste em 
substituir funções intricadas por um conjunto 
de funções mais simples, de tal forma que 
m u i t a s o p e r a ç õ e s c o m u n s c o m o a 
diferenciação e a integração, possam ser 
realizadas mais facilmente. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                63
A interpolação consiste basicamente em 
encontrar uma função que seja a expressão 
lógica de determinados pontos de uma função 
desconhecida, ou seja, conhecendo-se (x1 , 
y1), (x2 , y2).....(xn , yn) de uma função 
desconhecida poderemos calcular o valor 
numérico intermediário da função num ponto 
não tabelado com certo grau de erro.
O desenho mostra que ao se conhecer poucos 
pontos temos uma série de funções que 
podem se ajustar.
Exemplo de interpolação polinomial de grau 
superior a 1.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                64
Pontos de amarração
Os pontos de amarração são os pontos em que 
a função substituta conterá da função tabela, 
no qual será construída uma função para um 
respectivo intervalo. Para se fazer escolha de 
uma infinidade de funções que venham 
assumir determinados pontos faz-se na 
verdade a escolha de uma função onde se 
possa trabalhar com simplicidade, deste modo 
a função mais simples um polinômio. 
Nos pontos de amarração f(x) é igual a g(x), 
g(x) pode ser chamada função substituta.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                65
2 pontos (polinômio 
de 1º grau)
4 pontos 
(polinômio de 
3º grau)
3  pontos  (polinômio  de  2º  
grau)
Para (n+1) pontos, existe um e somente um 
polinômio de grau não superior a n.
INTERPOLAÇÃO LINEAR, estamos supondo o 
comportamento linear entre o dois pares de 
pontos, E assim, para a tabela inicial tem se o 
seguinte gráfico
Consultando o gráfico, para o nosso exemplo 
de 230PF, verificamos que este valor fica entre 
os pontos conhecidos:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                66
projeto total PF estimado
total PF 
realizado
homem*horas 
trabalhadas
prazo 
(dias 
uteis)
modulo de ponto 82,45 112,2 2400 40
sistema estoques 180,90 179,34 8400 70
Gestao de vendas 198,20 215 9600 160
controle de trafego 268,30 265,2 7200 180
sistema academico 431,45 420,78 9600 160
Do projeto gestão de venda: 
 com 198,20 PF com 9600 homem*hora
 E o projeto controle de trafego:
 com 268,30 PF e 7200 homem*hora
198,20PF 268,30PF
7200  hh
9600  HH
230  PF198,20PF 268,30PF
7200  hh
9600  HH
X
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                67
Considerando os 230 PF e verificando que 
(268,30 – 230 = 38,30) Por semelhança de 
triângulos podemos escrever: 
Assim temos 
X * 70,10 = 2400 * 38,30 donde 
X = 1311,27
Assim por interpolação linear temos um 
acréscimo de 1311,27 acima de 7200 nos 
mostrando um total de 
7200 + 1311,27 = 8511,27 homem*hora
Risco assumido
•Ao assumirum valor estamos assumindo um 
risco, que poderá diminuir assumindo-se outro 
tipo de curva.
•Mas as vezes temos que determinar um valor 
de estimativa além dos limites do domínio de 
nossa tabela
•Neste caso podemos estipular a equação da 
função e usar o novo valor como entrada da 
função. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                68
• Sempre lembrando que estamos assumindo 
um risco que pode ser diminuído a medida que 
vamos aumentando nossa base de dados
Suponha para fins de exemplo que desejamos 
achar o esforço em Homem*hora para um 
novo projeto de 600 PF. 
Observando a tabela este valor está acima do 
maior valor existente.
Neste caso precisamos determinar a função 
que melhor atende. 
Vamos supor que vamos trabalhar com uma 
reta que passa pelos pontos:
 268,30 PF, 7200 H*H
431,45 PF 9600 H*H
Identificar a função
A equação geral da reta é: y = a * x +c
Aplicando os pontos temos:
7200 = a * 268,30 + b
9600 = a * 431,45 + b
Com os dois pontos podemos manipular 
algebricamente para achar a:
7200 = a * 268,30 + 9600 – a *431,45
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                69
7200 – 9600 = a * (268,30 - 431,45) 
a = -2400/-163,15 
donde a= 14,71
Da outra equação tiramos o valor de b 
b = 9600 – 14,71 * 431,45 
donde b = 3253,37
Assim temos a equação da nossa reta: 
y = 14,71 * a + 3253,37
Com a equação da nossa reta:
y = 14,71 * a + 3253,37
Usando a função para acharmos o esforço para 
600 pontos temos:
Y = 14,71*600 + 3253,37
O ESFORÇO ESTIMADO SERÁ: 
12079,31 HOMEM * HORA
ERROS DAS ESTIMATIVAS INTERPOLADAS
Uma vez que entendemos que a partir de uma 
tabela, em geral, não vamos conseguir obter 
uma função que modele o fenômeno de 
maneira exata mas somente uma de uma 
forma aproximada, surge outro problema: 
como escolher o tipo de função que aproxima 
o fenômeno? 
Em outras palavras: que tipo de interpolação 
devemos fazer? 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                70
Veja que o fato da aproximação ser razoável 
(boa) ou não para modelar o fenômeno 
estudado dependerá da resposta a esta 
pergunta. 
Por outro lado, a pista para esta resposta deve 
estar contida na tabela. Os pontos listados na 
tabela podem mostrar uma tendência que 
devemos respeitar se desejamos que a função 
de interpolação represente de forma razoável 
o fenômeno estudado.
A interpolação consiste basicamente em 
encontrar uma função que seja a expressão 
lógica de determinados pontos de uma função 
desconhecida, ou seja, conhecendo-se (x1 , 
y1), (x2 , y2).....(xn , yn) de uma função 
desconhecida poderemos calcular o valor 
numérico intermediário da função num ponto 
não tabelado com certo grau de erro.
Assim o erro em um ponto qualquer é o 
módulo de f(x) – G(x). 
Existem vários processos matemáticos para 
tratar a interpolação e o seu erro. 
De uma maneira simplista podemos definir 
uma curva, no nosso gráfico, que seja limite 
para considerarmos o erro. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                71
A medida que aumentamos nossa base 
estatística podemos ir aproximando as duas 
curvas limites (mínimo e Máximo) pra perto da 
estimativa diminuindo a faixa de erro.
Conclusão
As interpolações de dados devem ser feitos 
com muita técnica, ao se estimar uma valor, 
estamos assumindo um risco.
Pode-se aprofundar a teoria matemática. 
Existe teoria, com métodos bem estabelecidos 
para se trabalhar com segurança. O nível de 
erro não deve ser desprezado, pois pode levar 
a altos prejuízos, quando se tem uma base de 
dados com pouca informação.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                72
Exemplo
Considere que uma empresa deduziu a partir 
de seus dados a seguinte curva:
Calcule para esta tendência qual o valor d 
esforço necessário para 144 PF. 
4690,88
Nesta aula, você: 
•Aprendeu como fazer estimativas para pontos 
fora da tabela de amostragem.
•Aprendeu sobre interpolação linear e de outro 
polinômios.
•Aprender a determinar uma função para 
estimar dados fora do espaço de amostragem.
•Aprendeu a fazer interpolação linear e avaliar 
os riscos.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                73
REGISTRO DE PARTICIPAÇÃO
1. Considere a curva abaixo obtida de um 
conjunto de pontos de uma tabela de ponto 
função por esforça e podemos concluir 
corretamente.
1) A curva é uma função edeveria passar por 
todos os pontos portanto o gráfico está errado. 
2) A curva é uma função, que foi ajustada 
por métodos estatísticos e serve para 
mostrar a tendência entre PF e o esforço 
3) A curva só serve para se estimar valores 
entre 100pf e 500 pf, não podendo se usar por 
exemplo para 700 PF 
4) Acima de 500 PF pode-se afirmar que o erro 
é zero se estimarmos com esta curva 
5) A curva estaá errada pois o númro de 
pontos é suficiente para garantir que o 
comportamento da tendencia é logaritmo 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                74
2. Em relação as estimativas e a medida do 
realizado o gráfico abaixo mostra que podemos 
afirmar de forma correta:
1) que os esforço para se deenvolver um 
software segue a tendência linear 
2) O comportamento linear observado é devido 
ao esforço dispendido em homem*hora 
3) A empresa deve-se limitar a fazer produtos 
até 500 PF e acima de 80 PF 
4) Ada pode-se deduzir observando o gráfico 
5) as estimativas estão sendo feitas com 
um alto nível de acerto 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                75
3. A primeira atividade em uma empresa que 
deseja ter um processo de estimativas para o 
projeto de software é:
1) organizar os projetos por profissionais mais 
experientes. 
2) Estabelecer um processo de software e 
manter o desenvolvimento sobre controle de 
um bom gerente 
3) definir um conjunto de métricas e 
montar uma grande base de dados 
voltados para estimativas 
4) Melhorar o método de desenvolvimento de 
software 
5) Tre inar as pessoas no método de 
desenvolvimento de software 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                76
AULA 10
CONCORRÊNCIAS PÚBLICAS E OUTROS ASPECTOS DE 
CONTRATAÇÃO USANDO PF
Nesta aula, você irá:
1.Aprender sobre fatores que podem afetar um 
contrato.
2.Quais as formas de contratação usando 
ponto função.
3.Como são fe i tas as med ições para 
faturamento.
4.Verificamos em concorrências públicas 
algumas métricas especificas para as 
concorrências.
Concorrências públicas e contratação usando 
PF
O trabalho para produzir , atualizar, testar e 
gerar a documentação pode ser feita na 
empresa interessada ou contratada de uma 
outra empresa. Em qualquer das duas 
situações o controle da produtividade, prazos 
e qualidade precisam ser estabelecidos. 
Assim, as características de acompanhamento 
que vamos desenvolver para uma empresa 
externa, devem ser usada na empresa que 
não contrata com o mesmo ou um pouco 
menos de rigor.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                77
O trabalho de software, quando se trata de 
empresa externa deve levar em consideração 
o risco que a empresa contratante deseja 
correr.Em termos de risco o contratante visa 
minimizá-lo. Se uma empresa contratante não 
se importa com o risco como principio do 
contrato, pode fazer a contratação por 
homem hora ou transferir o risco para o 
fornecedor com outro tipo de contratação.
 
No relacionamento são muitos os fatores que 
introduzem riscos no estabelecimento do 
relacionamento de contratante e contratado, 
alias estes riscos já existem quando se atua 
com profissionais dentro da própria empresa.
São fatores de risco para a determinação do 
trabalho os seguintes fatos, entre outros:
I. O trabalho é mal especificado não definindo 
l imites do que precisa ser fe i to e 
geralmente o contratante pode pedir outros 
“quebra galhos” do contratado o que leva 
ao desentendimento.
II. A falta de clareza ou entendimento dos 
requisitos. Devem-se aplicar metodologias 
que esclareçam os requisitos (analise, 
completude e consistência) para se 
minimizar este aspecto.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                78
III.As estimativas na contratação são feitas 
com nível de erro. Normalmente quem 
contrata sub dimensiona o trabalho para 
minimizar o seu custo.
IV.Pressões feitas por usuários internos devido 
a prazos políticos causando instabilidade 
nos profissionais da empresa contratada.
V. Falta de processo de contro le nas 
modificações solicitada. Uma modificação, 
na maioria das vezes, implica em aumento 
do custo e prazo.
Assim as divergências entre fornecedor e 
c l i e n t e t e n d e m a s e a g r a v a r. O 
estabelecimento de um fator de medida 
comum aceito por fornecedor e cliente já é o 
inicio do estabelecimento de uma forma de 
contratação que minimize estes conflitos. 
Neste caso PF é uma medida que vem se 
tornado padrão de negociação.
1- Contratação por homem hora
Neste t ipo de contratação a empresa 
fornecedora estabelece um preço por hora para 
seus profissionais que são alocados na 
contratante.
O profissional recebe ordens dos gerentes de 
TI da empresa contratante e comporta-se 
como funcionário da contratante.
Este tipo de modelo é simples de ser 
administrado.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                79
Algumas empresas não fazem nenhum controle 
sobre o contratado e outras procuram controlar 
como o recurso esta sendo utilizado e usam 
planilhas que são estabelecidas para controlar 
o trabalho como a mostrada abaixo:
Tabela tempo por projeto (TIME SHEET)
O modelo é flexível pois permite ao contratante 
solicitar modificações e novos serviços, pois 
esta pagando por hora. Os erros também são 
absorvidos pelo contratante.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                80
O que se coloca contra este modelo é como 
controlar a produtividade dos profissionais 
alocados. O estabelecimento do controle por 
ponto função nos permite medir se as horas 
registradas estão compatíveis com o número 
de pon tos f unção t raba lhados pe l o s 
contratados.
Desta forma pode-se acompanhar para cada 
profissional e o número de PF. Pode-se criar a 
métrica:
Produtividade = PF/hora
Pode-se acompanhar a produtividade de cada 
profissional.
A aplicação de PF neste caso traz visibilidade a 
problemas como queda de produtividade.
Deve-se ainda destacar o alto risco deste tipo 
de contratação, pois os profissionais são 
colocados na empresa cumprindo Horário, 
subordinado a outros gerentes e isto gera 
problemas trabalhistas pois podem criar 
vínculos de emprego do terceirizado com o 
contratante.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                81
MODALIDADE DE PREÇO FIXO
Esta modalidade o risco é totalmente 
transferido para o fornecedor. 
O contratante negocia com o contratado um 
preço e as formas de pagamento. 
O contratante estabelece os pontos de 
avaliação e pagamento do projeto. 
Neste caso precisa-se de uma unidade que 
permita medir o quanto já foi feito do trabalho. 
O contratado procura estabelecer controles 
para evitar os riscos, principalmente os 
introduzidos por mudança de requisitos. 
A mudança de um requisito implica em uma 
nova negociação. Muitas vezes se estabelece 
aditivos contratuais para estas modificações 
( ou preços diferenciados). 
Assim PF se aplica para medir o tamanho do 
projeto, e principalmente para acompanhar o 
projeto e liberar o pagamento por fase do 
projeto. 
É comum trabalhar-se com distribuições 
percentuais do total de PF estimado para o 
projeto estabelecidos entre o contratante e 
contratado para se controlar o projeto 
(pagamento, avaliação...). 
As tabelas abaixo mostram estas formas de 
distribuição:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                82
Nesse caso, para um projeto de R$ 200 000,00 
ao se terminar a análise de requisitos deverá 
ser pago o valor de 20 %, portanto, R$ 40 
000,00.
Em outra situação que detalha um outro ciclo 
de vida para um projeto de R$ 100000,00.
Esta estipulado que se pagará R$ 10 000,00 no 
final do levantamento de Dados., conforme 
mostrado na tabela abaixo:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                83
PREÇO POR PONTO FUNÇÃO
Na aula anter ior v imos que podemos 
estabelecer um valor de custo da empresa por 
PF. 
Mas o preço de venda da empresa poderá ter 
valores diferenciados dependendo do tipo de 
profissional envolvido ou mesmo do grau de 
risco que o fornecedor esta assumindo. 
A determinação do preço por ponto função é 
certamente um dos mais importantes aspectos 
para o fornecedor. Pode-se criar uma tabela de 
valores, para fases do ciclo de vida do projeto, 
estes valores podem facilmente serem obtidos 
por engenharia reversa. 
CONTRATAÇÃO POR PREÇO UNITÁRIO
Neste modelo o fornecedor paga por 
elementos do projeto. Um elemento é uma 
tela, um relatório, tabela, caso e uso, linhas 
de código alteradas, store procedure ou um 
ponto função.
 
Este modelo é intermediár io entre a 
contratação por homem hora e o preço fixo.
 
Neste modelo a produtividade é um risco do 
fornecedor, se o contrato é feito por ponto 
função, o prazo, e o recurso dependem do 
fornecedor. 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                84
Por outro lado a modificação de requisitos e os 
pedidos do contratante são transformados em 
PF, portanto o risco de aumento é do 
contratante.
 
Como a Análise de Ponto Função é um método 
padrão de contagem, as empresas e 
profissionais de todo o mundo acompanham a 
padronização de contagem proposta pelo 
IFPUG faz com que se estabeleça uma 
referencia para criar uma unidade de 
contratação - O PF. Assim busca-se 
consistência e uniformidade na aplicação deste 
padrão que tem sido a base de contratação 
das empresas públicas e privadas.
CONCORRÊNCIA PÚBLICA
A lei 8666 determina que se estabeleça a 
análise de serviço e se contrate o menor 
preço. Neste caso as concorrências de 
contratação de software tem estabelecido 
condições de participação baseada em Ponto 
Função.
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                85
Nesta aula, você: 
•Aprendeu as formas de contratação de um 
profissional e como medir o trabalho com PF.
•Aprendeu como se faz o controle em caso de 
serviços fechados.
•Aprendeu sobre os riscos envolvendo uma ou 
outra forma de contratação.
•Constatou como o conceito de pf é usado em 
concorrências.•Analisou partes de uma concorrência pública.
REGISTRO DE PARTICIPAÇÃO
1. Marque a opção que destaque uma 
vantagem de se fazer a contratação homem/
hora
1) Tratamento de ações trabalhistas de forma 
padronizada 
2) A contratação com volume de serviço 
estável e bem definido 
3) O estabelecimento do aumento de 
produtividade do contratado 
4) normalidade na alteração de requisitos 
de software 
5) a aplicação de PF para determinar a 
quantidade de negociação 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                86
2. Quanto aos riscos podemos afirma que:
1) Se os riscos são baixos podemos contratar 
por homem hora 
2) Se não desejamos riscos contratamos 
por Preço unitário em PF 
3) Se contatar por preço fixo assume-se os 
riscos 
4) Se contratar por preço fixo assume-se parte 
dos riscos 
5) Não importa a forma de contratar o 
contratante sempre ficara com os riscos 
 
3. Considere as afirmativas:
 
I. A falta de tratamento correto na definição 
de requisitos é um dos maiores riscos do 
projeto.
II. O Risco introduzido pela falta de tratamento 
correto nos requisitos pode ser eliminada na 
forma de contratação
III.Normalmente a contratação por preço fixo 
conduz ao estabe lec imento de um 
r e l a c i onamen to ha rmon i o so en t r e 
contratante e fornecedor
IV.O maior problema de trabalhar com PF é 
garantir a mesma forma de contar.
 
As afirmativas absolutamente corretas são:
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                87
1) Todas certas 
2) I e IV 
3) todas erradas 
4) I e III 
5) III e IV 
 
                                    MEDIDAS  DE  ESFORÇO  DE  DESENVOLVIMENTO  DE  SOFTWARE                                88