1 COMPILADO Medidas do Esforco no Desenvolvimento de Software COMPLETO AULAS RESUMOS REVISAO PROVAS AV1 AV2 AV3 SaibaMais EXTRAS Graduacao Dados Programacao Gestao Tecnologia da Informacao

Prévia do material em texto

Medidas do Esforço no
Desenvolvimento de Software
Aula 1
Prof. Horácio Ribeiro
Objetivos da disciplina:
Medidas do Esforço de Desenvolvimento de Software
A disciplina apresenta os conceitos usados 
para se medir e estimar o software. 
As formas de medir, estimar, acompanhar 
um projeto, e como estabelecer parâmetros 
para futuros projetos são apresentadas 
nesta cadeira. 
Apresentar as formas de se medir e estimar 
o software. 
Não se pode gerenciar o que não se pode medir.
Medidas do Esforço de Desenvolvimento de Software
Fazer software é fazer engenharia
Metodologias como ITIL, CMMI, MPS-BR e outras, colocam as 
métricas e medições como práticas fundamentais para a gestão 
e, na maioria delas, como classificadoras da maturidade. 
Os conceitos apresentados permitirão que você estime o esforço 
e prazo necessário para se desenvolver, estimar (prazos, custos e 
esforços) e manter um software.
Medidas do Esforço de Desenvolvimento de Software
Conceito de Métrica
Quando desejamos comparar ou acompanhar alguma 
característica de um objeto ou processo definimos uma 
métrica
Uma métrica é um conceito que nos permite fazer 
comparações
Especificar uma métrica de forma correta, definindo sua forma 
de medir, sua aplicabilidade no projeto e suas limitações na 
tomada de decisões Nos permitirá comparar softwares.
Também estimar prazos, esforço e custos antes de se realizar o 
projeto.
Uma métrica mal especificada pode conduzir a decisões de 
baixa qualidade.
Utilidade das métricas em software:
•Comparar dimensões de softwares diferentes a partir de
métricas.
•Identificar a partir de medidas ações eficazes e eficientes em
projetos que podem ser estabelecidas como padrões.
•definir a linguagem e estrutura de projeto
características de uma Métrica
• Uma métrica é uma definição do que se deseja conhecer, ou 
acompanhar em um produto, seu consumo ou sua produção.
• Para se definir uma métrica deve-se considerar alguns aspectos:
- As métricas devem ser simples de entender e de serem
utilizadas para verificar atingimento de objetivos e para
subsidiar processos de tomada de decisão. 
- As métricas devem ser objetivas visando reduzir ou minimizar a
influência do julgamento pessoal na coleta, cálculo e análise dos
resultados. 
• - O valor da informação obtido como resultado das medições deve
exceder o custo de coletar, armazenar e calcular as métricas. 
• Uma métrica deve conter:
– Nome(representativo) da métrica
– Objetivo da métrica
– Descrição da métrica
– Sistema de medidas
– Forma de se obter a medida
• Nome da métrica
– Deve ser representativo
exemplo: entendibilidade
• Objetivo da métrica
- para que se está definindo esta métrica
(utilidade)
exemplo: medir-se a capacidade de se entender um código 
de programa
• Descrição da métrica
- como se determina a métrica 
• Descrição da métrica
- como se determina a métrica 
Exemplo: consiste em se contar o número de linhas de 
comentários, ou linhas que contenham comentários 
diretamente no código fonte escrito pelo programador
• Sistema de medidas
que sistema devera ser usada para se medir
exemplo: contagem usando números inteiros 
• Formas de medidas
como será feita a medida
exemplo: a medida deverá ser feita diretamente no código que 
for aprovado para compilação 
• Medida:
Medida é diferente de métrica
uma medida é um valor tomado segundo a 
definição de uma métrica 
exemplo: 32 linhas de comentários
1,73 metros de altura
21,3 Gbytes de memória
• Medidas pode ser:
a - diretas:
quando é feita diretamente no processo ou 
objeto
exemplo: O total de linhas de código, no final do projeto, é 
12345 linhas de código objeto.
a altura do prédio é de 18,40 metros 
• Medidas pode ser:
b - medidas indiretas: quando são feitas 
utilizando cálculo a partir de outras medidas:
exemplo: o diâmetro da terra é..... Kms
a distância até o sol é de.....
altura de um prédio baseado em cálculo:
A ??? B
c
d
• Suponha a métrica:
nome: 
complexidade ciclomática
descrição : 
serve pra medir a complexidade do software considerando o 
numero de caminhos lógicos Adicionado de uma unidade
Formas de medir: 
contar o número de expressões lógicas
Unidade: contagem
Como medir: 
contagem no código quando terminado
• A desvantagem da medida direta é que se 
mede no acontecido(depois de pronto).
– “o leite já esta derramado”
• A medida indireta pode ser usada em fases 
de planejamento.
– por isto usa-se plantas em engenharia
– desenhos de circuitos elétricos
• Exercício
utilizar uma definição de métrica
• Código do programa
• Ex#include <stdbool.h>
• inline void troca(int* a, int* b)
• {
• int aux = *a;
• *a = *b;
• *b = aux;
• }
• void bubbleSort (int *primeiro, int *ultimo) 
• {
• bool naoTrocou;
• int *posAtual;
• for (; ultimo > primeiro; --ultimo)
• {
• naoTrocou = true;
• for (posAtual = primeiro; posAtual < ultimo; ++posAtual)
• {
• if (*posAtual > *(posAtual+1))
• {
• troca (posAtual, posAtual+1);
• naoTrocou = false;
• }
• }
• if (naoTrocou) return;
• }
• }
• Código do programa
• Ex#include <stdbool.h>
• inline void troca(int* a, int* b)
• {
• int aux = *a;
• *a = *b;
• *b = aux; Temos 4 instruçoes com expressoes lógicas
• }
• void bubbleSort (int *primeiro, int *ultimo) portanto a resposta é 4 + 1 = 5
• {
• bool naoTrocou; o algoritmo é de complexidade ciclomática de cinco
• int *posAtual;
• for (; ultimo > primeiro; --ultimo) 
• {
• naoTrocou = true;
• for (posAtual = primeiro; posAtual < ultimo; ++posAtual)
• {
• if (*posAtual > *(posAtual+1))
• {
• troca (posAtual, posAtual+1);
• naoTrocou = false;
• }
• }
• if (naoTrocou) return;
• }
• }
• O que medir no software????
– uso de memória?
– tempo de execução?
– número de linhas?
• adotado pela maioria dos estudiosos e 
profissionais foi o número de linhas de 
codigo (line of code ) loc e que se tratando de 
mil linhas estabelece o kloc
• A maioria das métricas eram feitas a partir 
desta medida direta KLOC.
Problemas com a medida baseada em 
KLOC
-O KLOC é uma medida direta, portanto é feita sobre
o fenômeno. E, só podemos contar as linhas de um
software após ele ter terminado.
- Alguns contestam o KLOC por que não privilegia a
boa programação (mais eficiente) ou o uso de
linguagens mais eficientes. Além disto o
acompanhamento de projetos com métricas baseadas
no KLOC compara projetos de características
diferentes nas especificações de funcionalidades e na
sua forma de implementar.
Problemas com a medida baseada em 
KLOC
- LOC conta linhas em qualquer linguagem
independente de sua produtividade, portanto as
comparações não têm sentido.
-
Desafio
-Como medir o software antes de ser
implementado. Definir alguma coisa, como as
“plantas de engenharia” que permita fazer medidas
ainda na fase de projeto, sem a existência da obra.
É este tipo de ferramenta que se necessita para a
gerência e acompanhamento da construção do
software.
????????????????
Desafio
-Fazer modelagem de situações, e a partir das
especificações de funcionalidade, tomar
decisões de projeto do futuro software, estudar
alguns aspectos de gerenciais.
- Comparar projetos de uma forma uniforme.
- Fazer estimativas baseado em registros mais
uniformizados que permitam melhores estimativas,
passou a ser um desafio para os gerentes e
pesquisadores da área de software.
A Solução :
Proposta por Albrecht em 1974.
Apesar de se ainda usar KLOC para algumas 
medidas. Hoje se usa uma métrica chamada PONTO 
FUNÇÃO (PF),
Mas isto é assunto para a nossa próxima aula
Atenção:O seu livro texto tem vários exemplos 
de métricas baseadas em KLOC para 
as mais diversas funcionalidades. 
Estude e faça os exercícios propostos.
Até a próxima aula
Medidas do Esforço no Desenvolvimento de Software
Aula 2
Prof. Horácio Ribeiro
Objetivos da aula:
- Aprender de forma sucinta o modelo de 
Albrecht 
-- Relacionar os conceitos envolvidos na 
proposta de Albrecht,
- Aprender os conceitos em estudo de casos
a partir de um DFD
- Aprender a usar o modelo para um caso e 
uso
- Converter PF em KLOC
- Identificar as limitações do modelo 
DESAFIO:
Modelo de medida indireta que permitisse 
planejar e decidir.
• Albretch em 1974 após estudado mais 5000 
softwares
• É um modelo baseado na funcionalidade 
necessária.
PRINCIPIO:
- Identificar características de um sistema e 
mapear estas características na 
funcionalidade do software definida na 
especificação.
- Albretch identificou que as funcionalidades se 
refletiam nos seguintes seguintes aspectos:
entradas – saídas – consultas – arquivos e 
interfaces
• CONSTRUÇÃO DA FUNÇÃO:
-O Principio é construir uma função que mapeie um número
real.
- O número real representa uma quantidade de medida da
funcionalidade que foi chamado de PONTO FUNÇÃO
- Esta função foi construída por ajuste, baseado em dados
observados em outros softwares. Este método de construir
uma função por observação é muito comum na engenharia
• Elementos da funcionalidade
• Tabela de contagem
• Exemplo de contagem
• Identificação dos elementos
• Aplicando na tabela com software simples
tem-se:
• Definiu que a forma de desenvolver o sistema 
pode provar variações na medida da 
funcionalidade.
• Analisou 14 fatores que podem influenciar na 
medida da funcionalidade
• Estes fatores, alguns subjetivos, são avaliados
com uma nota de zero a cinco, por um 
conjunto de especialistas.
•
•
• 14 aspectos
• técnicos e 
• régua de 
• notas
• A formula construída final ficou:
• As métricas definidas a partir de PF
• Ponto Função Não ajustado:
- É o resultado da contagem * Peso de 
complexidade. (contagem total) das características
• Ponto função ajustado
- é o resultado considerando as características 
de implementação.
- é o produto da contagem por um fator de 
ajuste.
• fator de ajuste.
14
( 0,65 + o,o1 * (NOTA) )
I = 1 i
Observe que: 
65% é da funcionalidade
o fator do somatório pode variar de
zero a 0,7 (todos os itens tirando 5) 
Logo o fator de ajuste pode ser de 1,35 a 0,65
• O fator de ajuste indica o maior ou menor 
esforço para a produção do software.
um software com características complexas de 
implementação o fator de ajuste ´1,35 e um 
s0ftware muito simples 0,65.
para uma contagem de 43 (por exemplo)
Tem-se: 48 PF não ajustados
e 68,05 PF ajustados (se o fator de 
ajuste for 1,35) (1,35*48) 
Mapeamento de PF em KLOC
• Exercício
Faça a previsão de tamanho e prazo para um sistema com 178,45 
PF ajustados. Considere a tabela abaixo
TABELA DE PRODUTIVIDADE DA EQUIPE POR LINGUAGEM DE PROGRAMAÇÃO
PARA 1 PF
PHP 45 LOC - 3 DIAS ÚTEIS
C 72 LOC 8 DIAS ÚTEIS
JAVA 58 LOC 8 DIAS ÚTEIS
C ++ 72 LINHAS 8 DIAS
PYTON 45 LOC............2 DIAS
Decida que linguagem usar se o projeto não pode consumir mais de 450 dias
• Resposta
linguagem tamanho em linhas (LOC) prazo em dias úteis
php 8030,25 535,35
c 12848,4 1427,6
Java 10350,1 535,35
c++ 12848,4 535,35
pyton 8030,25 356,9
• Pode-se estimar um projeto no inicio da 
especificação.
• Neste caso devido a imprecisão poderemos 
ter um erro maior na estimativa.
• Fazer o 
cálculo 
de PF 
para um 
caso e 
uso
• Fazer o 
cálculo 
de PF 
para um 
caso e 
uso
• Fazer o 
cálculo 
de PF 
para um 
caso e 
uso
• Contamos
- 5 arquivos
- 3 entradas
- 1 saída
- 2 consultas
- 0 interfaces
• Aplicando na tabela de contagem
2
5
0
6
35
0
65
• Desafio:
• Calcule quantas linhas em C deve se estimar 
para este sistema?
• E se for em PHP?
• Você pode estudar um pouco mais visitando o 
site:
Análise de 
Pontos de 
Função
O metro quadrado do 
software
• O método de Albrecht tem um problema?
• Como uniformizar o processo de contagem.
• Para as empresas fazerem negócios precisam 
de uma unidade que não varia com a 
subjetividade da contagem.
• Para resolver isto criou-se um organismo 
internacional chamado IPFG – internacional 
Ponto Função GRUPO
• O IPFG
• TEM COMO OBJETIVO DESENVOLVER E PADRONIZAR A 
FORMA DE MEDIR O SOFTWARE
• Produz um manual de contagem que serve 
como padrão
• Tem melhorado a forma de diminuir a 
subjetividade da contagem
• Com isto encerramos nossa aula.
• Na próxima aula
• Vamos verificar como o FPUG definiu o 
processo de contagem.
• Vamos verificar que os princípios do ponto 
função foram preservados mas a forma da 
contagem foi sistematizada.
• Faça os exercícios e estude no nosso livro 
texto
• Até a próxima aula
Medidas do Esforço de Desenvolvimento de Software
Aula 3
Prof. Horácio Ribeiro
• Como uniformizar o processo de contagem?
• Para as empresas fazerem negócios precisam 
de uma unidade que não varia com a 
subjetividade da contagem.
• O IFPUG
• TEM COMO OBJETIVO DESENVOLVER E PADRONIZAR A 
FORMA DE MEDIR O SOFTWARE
• Produz um manual de contagem que serve 
como padrão
• Tem melhorado a forma de diminuir a 
subjetividade da contagem
• Endereços na internet:
Grupo internacional:
• FPUG: International Function Point Users 
Group
• www.ifpug.org/
• A non-profit organization promoting the use 
of function point analysis and other software 
metrics
Grupo brasileiro:
http://www.bfpug.com.br/
http://www.google.com.br/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http://www.ifpug.org/&ei=n-1KTuuQFcfy0gGr2eHrBw&usg=AFQjCNGuAlBHovzBj-iMAJaHBWr5Tj1icg
Contagem dos fatores do software
segundo IFPUG.
Function Point Counting Practices
Manual – Release 4.1.1,
publicado pelo IFPUG
em 1999.
Nesta aula você irá:
• - Relacionar os 14 aspectos sobre requisistos
não funcionais.
• - A Pontuar cada um dos fatores segundo o 
IFPUG
• - analisar aspectos na pontuação dos fatores 
de características do software.
• Estes fatores, alguns subjetivos, são avaliados 
com uma nota de zero a cinco, por um 
conjunto de especialistas.
• Os fatores do software estão relacionados com os requisitos 
não funcionais.
Esses fatores de contagem são bem difíceis de padronizar. 
Por esta razão as regras foram adotados pela ISO como um 
padrão, através das normas:
• ISO/IEC 20926:2003 – Software engineering – IFPUG 4.1 –
Unadjusted Functional Size Measurement Method – Counting 
practices manual
• ISO/IEC 14143 , software Measurement – Functional size
Meassurement. 
O objetivo da análise é
determinar a parte da
formula, cuja parcela
está abaixo:
A nota deve variar de 0 a
5. O IFPUG estabelece
uma tabela para avaliar o
grau de influencia de uma
característica
Níveis ou Graus de Influência
0 – Nenhuma Influência
1 – Influência Mínima
2 – Influência Moderada
3 – Influência Média
4 – Influência Significativa
5 – Grande Influência
Fonte : IFPUG, 1999
As características do sistema que se esta dimensionando e 
para as quais iremos dar nota são:
C1 Comunicação de dados
C2 Processamento distribuído
C3 Performance
C4 Utilização de Equipamento
C5 Volume de transações
C6 Entrada de dados on-line
C7 Eficiência do Usuário Final
C8 Atualização On-Line
C9 Processamento complexo
C10 Reutilização de código
C11 Facilidade de Implantação
C12 Facilidade Operacional
C13 Múltiplos Locais
C14 Facilidade de mudanças
• C1 - Comunicação de dados: 
Verificam-se os recursos a serem utilizados para 
a comunicação de dados do sistema de forma 
global. Estima-se se a aplicação utiliza 
protocolos diferentes para recebimento/envio 
das informações do sistema.
nota característica
0 Aplicação batch ou funciona stand-alone;
1 Aplicação batch, mas utiliza entrada de dadosou impressão 
remota;
2 . Aplicação batch, mas utiliza entrada de dados e impressão 
remota;
3 Aplicação com entrada de dados on-line para alimentar 
processamento batch ou sistema de consulta;
4 Aplicação com entrada de dados on-line, mas suporta apenas um 
tipo de protocolo de comunicação;
5 Aplicação com entrada de dados on-line e suporta mais de um tipo 
de protocolo de comunicação.
Avaliação: 
• A modalidade batch, é uma forma de 
implementar o programa. Nesta situação o 
sistema operacional é quem decide o 
momento de executar o programa, visando 
otimizar o uso de recursos. Esta modalidade 
era muito comum em máquinas Mainframes. 
Mas, ainda existem muitas aplicações que 
ainda hoje “executam” na forma batch.
• C2 - Processamento de Dados Distribuído: 
característica avalia se o sistema utiliza dados 
distribuídos ou tem processamento distribuído, 
valendo-se de diversas CPUs.
nota característica
0 Aplicação não auxilia na transferência de dados ou funções entre 
os processadores da empresa;
1 Aplicação prepara dados para o usuário final utilizar em outro 
processador (do usuário final), tal como planilhas;
2 Aplicação prepara dados para transferência, transfere-os para 
serem processados em outro equipamento da empresa (não pelo 
usuário final)
3 Processamento é distribuído e a transferência de dados é on-line e 
apenas em uma direção;
4 Processamento é distribuído e a transferência de dados é on-line e 
em ambas as direções;
5 As funções de processamento são dinamicamente executadas no 
equipamento (CPU) mais apropriada;
Avaliação:
• C3 – Desempenho (performace)
Verifica se os parâmetros estabelecidos pelo 
usuário como aceitáveis, relativos a tempo de 
resposta.
Avaliação:
0. Nenhum requisito especial de desempenho foi solicitado pelo usuário;
1. Requisitos de desempenho foram estabelecidos e revistos, mas nenhuma
ação especial foi requerida;
2. Tempo de resposta e volume de processamento são itens críticos durante
horários de pico de processamento. Nenhuma determinação especial para a
utilização do processador foi estabelecida. A data limite para a disponibilidade
de processamento é sempre o próximo dia útil;
3. Tempo de resposta e volume de processamento são itens críticos durante
todo o horário comercial. Nenhuma determinação especial para a utilização
do processador foi estabelecida. A data-limite necessária para a comunicação
com outros sistemas é limitante.
4. Os requisitos de desempenho estabelecidos requerem tarefas de análise de
desempenho na fase de planejamento e análise da aplicação.
5. Além do descrito no item anterior, ferramentas de análise de desempenho
foram usadas nas fases de planejamento, desenvolvimento e/ou
implementação para atingir os requisitos de desempenho estabelecidos pelos
usuários.
• C4 - Utilização do Equipamento: 
Observe-se quanto ao nível de utilização de
equipamentos necessários para a execução do
sistema. Este aspecto é observado com vista ao
planejamento de capacidades e custos.
Avaliação:
0. Nenhuma restrição operacional explícita ou mesmo implícita foi
incluída.
1.Existem restrições operacionais leves. Não é necessário esforço
especial para atender às restrições.
2. Algumas considerações de ajuste de desempenho e segurança são
necessárias.
3. São necessárias especificações especiais de processador para um
módulo específico da aplicação.
4. Restrições operacionais requerem cuidados especiais no
processador central ou no processador dedicado para executar a
aplicação.
5. Além das características do item anterior, há considerações
especiais que exigem utilização de ferramentas de análise de
desempenho, para a distribuição do sistema e seus componentes, nas
unidades processadoras.
C5 - Volume de transações:
Consistem na avaliação do nível de
influência do volume de transações no
projeto, desenvolvimento, implantação
e manutenção do sistema.
Avaliação:
0. Não estão previstos períodos de picos de volume de 
transação.
1. Estão previstos picos de transações mensalmente, 
trimestralmente, anualmente ou em certo período do ano.
2. São previstos picos semanais.
3. São previstos picos diários.
4. Alto volume de transações foi estabelecido pelo usuário, ou o 
tempo de resposta necessário atinge nível alto o suficiente 
para requerer análise de desempenho na fase de projeto.
5. Além do descrito no item anterior, é necessário utilizar 
ferramentas de análise de desempenho nas fases de projeto, 
desenvolvimento e/ou implantação
C6 - Entrada de dados on-line:
A análise desta característica permite 
quantificar o nível de influência exercida pela 
utilização de entrada de dados no modo on-line 
no sistema.
Avaliação:
0. Todas as transações são processadas em modo batch.
1. De 1% a 7% das transações são entradas de dados on-line.
2. De 8% a 15% das transações são entradas de dados on-line.
3. De 16% a 23% das transações são entradas de dados on-line.
4. De 24% a 30% das transações são entradas de dados on-line.
5. Mais de 30% das transações são entradas de dados on-line. 
C7 - Usabilidade:
Esta característica permite quantificar o grau de 
influência relativo aos recursos implementados 
com vista a tornar o sistema amigável, 
permitindo incrementos na eficiência e satisfação 
do usuário final, tais como:
•Auxílio à navegação (teclas
de função, acesso direto e
menus dinâmicos)
•Menus Documentação e help
on-line
• Movimento automático do
cursor.
• Movimento horizontal e
vertical de tela.
• Impressão remota (via
transações on-line)
• Teclas de função
preestabelecidas.
•Processos batch submetidos
a partir de transações on-
line
• Utilização intensa de campos com 
vídeo reverso, intensificados, 
sublinhados, coloridos e outros 
indicadores.
• Impressão da documentação das 
transações on-line através de hard
copy
• Utilização de mouse
• Menus pop-up
• O menor número possível de telas 
para executar as funções de 
negócio.
• Suporte bilíngüe (contar como 4 
itens)
• Suporte multilíngüe. (contar como 6 
itens)
Avaliação:
0. Nenhum dos itens descritos.
1. De um a três itens descritos.
2. De quatro a cinco dos itens descritos.
3. Mais de cinco dos itens descritos, mas não há requisitos específicos
do usuário quanto à usabilidade do sistema.
4. Mais de cinco dos itens descritos e foram estabelecidos requisitos
quanto à usabilidade fortes o suficiente para gerarem atividades
específicas envolvendo fatores, tais como minimização da digitação,
para mostrar inicialmente os valores utilizados com mais freqüência.
5. Mais de cinco dos itens descritos e foram estabelecidos requisitos
quanto à usabilidade fortes o suficiente para requerer ferramentas e
processos especiais para demonstrar antecipadamente que os
objetivos foram alcançados.
C8 - Atualizações on-line:
Analisa-se a influência no desenvolvimento do 
sistema face à utilização de recursos que visem à 
atualização dos Arquivos Lógicos Internos, no 
modo online.
Avaliação:
0. Nenhuma. 
1.Atualização on-line de um a três arquivos lógicos internos. O 
volume de atualização é baixo e a recuperação de dados é simples.
2. Atualização on-line de mais de três arquivos lógicos internos. O 
volume de atualização é baixo e a recuperação dos dados é simples.
3. Atualização on-line da maioria dos arquivos lógicos internos.
4. Em adição ao item anterior, é necessário proteção contra perdas de 
dados que foi projetada e programada no sistema.
5. Além do item anterior, altos volumes trazem considerações de custo no 
processo de recuperação. Processos para automatizar a recuperação foram 
incluídos minimizando a intervenção do operador
C9 - Processamento complexo: 
Analisar a complexidade de processamento influencia 
no dimensionamento do sistema, e, portanto, deve ser 
quantificado o seu grau de influência, com base nas 
seguintes categorias:
• * Processamento especial de 
auditoria e/ou processamento 
especial de segurança
foram considerados na aplicação;
• * Processamento lógico 
extensivo;
• *Processamento matemático 
extensivo
• * Processamento gerando muitas
exceções, resultando em
transações incompletas que devem
ser processadas novamente.
Exemplo: transações de auto-
atendimento bancário
interrompidas por problemas de
comunicação ou com dados
incompletos;
• * Processamento complexo para
manusear múltiplas possibilidades
de entrada/saída. Exemplo:
multimídia.
Avaliação:
0. Nenhum dos itens descritos.
1. Apenas um dos itens descritos.
2. Dois dos itens descritos.
3. Três dos itens descritos.
4. Quatro dos itens descritos.
5. Todos os cinco itens descritos.
C10 -Reusabilidade:
Analise do reaproveitamento de parte dos 
programas de uma aplicação em outras 
aplicações implica em cuidados com 
padronização. O grau de influência no 
dimensionamento do sistema é quantificado 
observando-se:
Avaliação:
0. Nenhuma preocupação com reutilização de código.
1. Código reutilizado foi usado somente dentro da aplicação.
2. Menos de 10% da aplicação foi projetada prevendo utilização posterior do
código por outra aplicação.
3. 10% ou mais da aplicação foi projetada prevendo utilização posterior do
código por outra aplicação.
4. A aplicação foi especificamente projetada e/ou documentada para ter seu
código reutilizado por outra aplicação e a aplicação é customizada pelo
usuário em nível de código -fonte.
5. A aplicação foi especificamente projetada e/ou documentada para ter seu
código facilmente reutilizado por outra aplicação e a aplicação é
customizada para uso através de parâmetros que podem ser alterados pelo
usuário.
C11 - Facilidade de implantação:
Quantificação do grau de influência desta 
característica é feita, observando-se o plano de 
conversão e implantação e/ou ferramentas 
utilizadas durante a fase de testes do sistema.
Avaliação:
0. Nenhuma consideração especial foi estabelecida pelo usuário e nenhum procedimento especial é 
requerido na implantação.
1. Nenhuma consideração especial foi estabelecida pelo usuário, mas procedimentos especiais são 
necessários na implementação.
2. Requisitos de conversão e implantação foram estabelecidos pelo usuário e roteiro de conversão e 
implantação foram providos e testados. O impacto da conversão no projeto não é considerado 
importante.
3. Requisitos de conversão e implantação foram estabelecidos pelo usuário e roteiro de conversão e 
implantação foram providos e testados. O impacto da conversão no projeto é considerado 
importante.
4. Além do item 2, conversão automática e ferramentas de implantação foram providas e testadas.
5. Além do item 3, conversão automática e ferramentas de implantação foram providas e testadas.
C12 -Facilidade operacional:
Análise desta característica permite quantificar o 
nível de influência na aplicação, com relação a 
procedimentos operacionais automáticos que 
reduzem os procedimentos manuais, bem como 
mecanismos de inicialização, salvamento e 
recuperação, verificados durante os testes do 
sistema.
•
Avaliação:
0. Nenhuma consideração especial de operação, além do processo normal de salvamento foi 
estabelecida pelo usuário.
1-4. Verifique quais das seguintes afirmativas podem ser identificadas na aplicação. Selecione as 
que forem aplicadas. Cada item vale um ponto, exceto se definido explicitamente:
• Foram desenvolvidos processos de inicialização, salvamento e recuperação, mas a 
intervenção do operador é necessária. 
• Foram estabelecidos processos de inicialização, salvamento e recuperação, e nenhuma 
intervenção do operador é necessária (conte como dois itens)
• A aplicação minimiza a necessidade de montar fitas magnéticas.
• A aplicação minimiza a necessidade de manuseio de papel.
5. A aplicação foi desenhada para trabalhar sem operador, nenhuma intervenção do operador é 
necessária para operar o sistema além de executar e encerrar a aplicação. A aplicação possui 
rotinas automáticas para recuperação em caso de erro.
13 - Múltiplos Locais e Organizações do Usuário: 
Análise da arquitetura do projeto, observando-se 
a necessidade de instalação do sistema em 
diversos lugares.
Avaliação:
0. Os requisitos do usuário não consideraram a necessidade de instalação em mais de um local.
1. A necessidade de múltiplos locais foi considerada no projeto e a aplicação foi desenhada para 
operar apenas em ambientes de software e hardware idênticos.
2. A necessidade de múltiplos locais foi considerada no projeto e a aplicação está preparada 
para trabalhar apenas em ambientes similares de software e hardware.
3. A necessidade de múltiplos locais foi considerada no projeto e a aplicação está preparada para 
trabalhar em diferentes ambientes de hardware e/ou software.
4. Plano de documentação e manutenção foi providos e testados para suportar a aplicação em 
múltiplos locais, além disso, os itens 1 ou 2 caracterizam a aplicação.
5. Plano de documentação e manutenção foi providos e testados para suportar a aplicação em 
múltiplos locais, além disso, o item 3 caracteriza a aplicação.
C 14 - Facilidade de mudanças:
Análise da influencia da manutenção no desenvolvimento do sistema. Esta 
influência deve ser quantificada baseando nos atributos,:
•disponibilidade de facilidades como
consultas e relatórios flexíveis para
atender necessidades simples
(conte como 1 item);
•disponibilidade de facilidades como
consultas e relatórios flexíveis para
atender necessidades de
complexidade média (conte como 2
itens);
•disponibilidade de facilidades como
consultas e relatórios flexíveis para
atender necessidades complexas
(conte 3 itens);
• se os dados de controle são
armazenados em tabelas que são
mantidas pelo usuário através de
processos on-line, mas mudanças
têm efeitos somente no dia seguinte;
• se os dados de controle são
armazenados em tabelas que são
mantidas pelo usuário através de
processos on-line, as mudanças têm
efeito imediatamente (conte como 2
itens).
Avaliação:
0. Nenhum dos itens descritos.
1. Um dos itens descritos.
2. Dois dos itens descritos.
3. Três dos itens descritos.
4. Quatro dos itens descritos.
5. Todos os cinco itens descritos.
Os 14 graus de influência (GI) são então 
somados o que resulta no grau de influência 
total (GIT),:
GIT = 
• O valor do fator de ajuste (VFA) é calculado 
pela seguinte fórmula:
VFA = ( GIT * 0,01) + 0,65 
.Se o fator de ajuste de valor é igual a 1,00 , a 
influência total das características gerais do 
sistema é neutra.
.Lembre-se que na aula passada vimos que o 
VFA pode variar entre 0,65 e 1,35 
• Uma empresa pode ter uma carteira de aplicações para 
determinados segmentos da economia. 
• E estas aplicações têm um conjunto de características 
comuns. 
• Pode-e fazer o trabalho de avaliação e contagem, usando as 
recomendações do IPFUG, e com seus mais experientes 
desenvolvedores e confeccionar uma tabela de fatores de 
ajuste por tipo de aplicação.
• Isto evita que para toda a aplicação se repita a avaliação
• Pode-se fazer uma avaliação dos fatores por 
vários profissionais e deduzimos um valor para 
cada fator, por tipo de aplicação:
avaliação para a aplicação xxxxxxxxx
avaliador
nota
valor total
c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11 c12 c13 c14
analista 1
analista 2
analista 3
analista 4
...
analista n
total 
valor medio
valor 
considerado
valor total 
• Devido a sua subjetividade a utilização do 
fator de ajuste tornou-se opcional ao final do 
ano de 2002.
• Atentou para a subjetividade da pontuação 
dos 14 aspectos do software
• Aprendeu como o IPFUG recomenda que seja 
feita a avaliação
• Atentou como se cria o fator de ajuste
• Não esqueça de fazer o estudo dirigido. Fazer 
os exercícios e ler a bibliografia disponível na 
biblioteca virtual....
• Na próxima aula, vamos estudar como IPFUG 
recomenda que seja feita a contagem das 
funcionalidades a partir de entradas, arquivos, 
consultas, saídas e interfaces.
• ... Até lá..
• Até a próxima aula
• Contactos:
• Professor Horacio ribeiro
• www.espacodoprofessor.com
• Email: profhoracioribeiro@gmail.com• aula3
http://www.espacodoprofessor.c/
mailto:profhoracioribeiro@gmail.com
Medidas do Esforço de Desenvolvimento de Software
Aula 4
Prof. Horácio Ribeiro
Na aula passada vimos como se 
deve tratar os aspectos dos 
requisitos não funcionais buscando 
uma padronização do tratamento
- vimos como se calcula o fator de 
ajuste.
• Nesta aula vamos verificar, baseado no 
Function Point Counting Pratices 
• Manual – Release 4.1.1, - IFPUG - 1999
Como se deve tratar a funcionalidade.
• Houve uma adaptação do modelo proposto 
inicialmente (aula 2 - método de Albrecht) 
para uma nova forma de medir a 
funcionalidade com elementos menos 
subjetivos
Objetivos da aula:
• Identificar o tipo de contagem
• Identificar o número de registros lógicos
• Identificar o número de itens de dados
• Determinar a complexidade de um ALI e um 
AIE
• Determinar a contribuição dos ALI e AIE
Nesta aula você irá:
- determinar o contexto da contagem,
- Aprender definir o tipo de contagem
- definir o que é um ALI e um AIE
- O que é um arquivo lógico e um item de
dados
- determinar a complexidade de um ALI e
AIE
- determinar o total de PF não ajustado
para ALI´s e AIE´s
- conhecer recomendações de características
de contagem de ALI e AIE feita pelo IFPUG
• Processo de contagem 
• O processo de contagem definido pelo IPFUG 
é feito em sete passos, conforme mostrado na 
figura a seguir:
Resolvemos 
o passo 6 na 
aula 3
Procedimento de Contagem de Pontos de Função
(HAZAN, 2001)
Determinar o tipo de Contagem (passo 1)
O primeiro passo a ser seguido para a contagem de PF 
de um projeto de software é determinar o tipo de 
contagem.
São definidos três tipos de contagem.(IFPUG):
•Contagem de projeto de desenvolvimento;
•Contagem de projeto de melhoria (manutenção);
•Contagem de aplicação.(produção)
Projeto de Desenvolvimento
• O número de pontos de função de um projeto de desenvolvimento mede 
a funcionalidade fornecida aos usuários finais quando da primeira
instalação do software.
• Esta contagem também considera as funções de conversão de dados 
necessárias a implantação do software 
• O projeto de migração de dados, povoamento de bases estão incluídos 
nesta contagem. 
• Ou seja a primeira versão do software 
funcionando.
Projeto de melhoria (manutenção)
• Em um projeto de melhoria o número de pontos de função 
mede as modificações para uma aplicação já existente .
• ou seja, as funções adicionais , modificadas ou excluídas do 
sistema, pelo projeto, e as funções de conversões de dados.
• Após a conclusão e implantação do projeto de melhoria , o 
número de pontos de função da aplicação deve ser atualizado 
para refletir as mudanças nas funcionalidades da aplicação. 
(VAZQUEZ,2005)
• Projeto de aplicação
• A contagem de pontos de função de uma aplicação já 
instalada e mede a funcionalidade fornecida ao usuário.
• Ela é iniciada ao final da contagem do projeto de 
desenvolvimento e atualizado no final do projeto de melhoria. 
(VAZQUEZ,2005)
Resolvemos 
o passo 6 na 
aula 3
Passo 2 : definir o escopo
Identificar o escopo da contagem e a fronteira da 
aplicação (passo 2)
• A identificação do escopo visa definir a abrangência da 
contagem estipulando se a contagem vai se referir a um ou 
mais sistemas ou a apenas parte de um sistema. 
• A fronteira da aplicação estabelece o limite do esta sendo 
contado indicando o limite entre a aplicação e os demais 
usuários. 
• No escopo da contagem de uma aplicação pode-s considerar 
todas as funcionalidades disponíveis, ou algumas 
funcionalidades específicas. 
Deve-se considerar as seguintes características e regras
• Os limites entre as funções a serem atendidas pela aplicação 
ou projeto;
• A utilização dos dados considerados no processo de 
contagem;
• O relacionamento entre os processos, com indicação de onde 
eles ocorrem.
• Deve ser considerado o ponto de vista do usuário, ou 
seja, o que o usuário pode entender e descrever 
como função da aplicação.
• A fronteira entre aplicações relacionadas deve considerar a 
funcionalidade das aplicações em termos das funções de 
negócio identificadas pelo usuário, e não sob o ponto de vista das 
interfaces necessárias.
• Dica:
•Para identificar a fronteira da aplicação deve-
se:
• Na documentação do fluxo de dados no sistema desenhar 
uma fronteira em volta para destacar quais partes são 
internas e externas à aplicação
• Identificar áreas funcionais pela atribuição definidas por 
objetos de análise, como entidades e processos;
• Verificar como o grupo de dados são mantidos;
• Verificar como a aplicação é gerenciada
Atenção
• Definir o escopo da contagem (fronteira ) é um dos passos
mais importantes pois se for feita de maneira incorreta a
contagem será incorreta.
• Contagem das 
funções de dados 
(passo3)
As funções de dados são funcionalidades fornecidas ao 
usuário para as necessidades de dados. 
• São chamados de arquivos lógicos internos(ALI)
• e Interface Externa (AIE). 
• Arquivo não significa um arquivo físico no sentido tradicional , mas refere-
se a um grupo de dados logicamente relacionado e 
reconhecido pelo usuário.
O IFPUG complementou os procedimentos e regras
do CPM 4.1.1 com um nova seção denominada
"Práticas de Contagem" onde situações como dados
de código, dados compartilhados e outros casos
devem ser avaliados
Arquivo Lógico Interno (ALI) 
• É um grupo logicamente relacionado de dados ou informação de controle 
cuja manutenção é feita pela própria aplicação. 
• Sua função principal é armazenar dados mantidos dentro da fronteira da 
aplicação através dos processos da aplicação. 
• Um grupo logicamente relacionado de dados refere-se a dados 
relacionados em um nível que o usuário consegue perceber como sendo 
importante para permitir que a aplicação realiza uma atividade definida. 
(IFPUG,1999)
• As informações de controle são dados usados pela aplicação para garantir 
total conformidade com os requisitos das funções do negócio definidas 
pelo usuário.
• Os ALI contribuem para o cálculo de pontos de função com base na sua 
quantidade e complexidade 
Como exemplos de um ou mais ALIs , dependendo da visão do 
usuário , têm-se :
• Dados da aplicação (arquivos mestres como cadastro de clientes ou 
funcionários);
• Arquivos de dados de segurança da aplicação;
• Arquivos de dados de auditoria;
• Arquivos de mensagem de auxílio;
• Arquivos de mensagens de erro;
• Arquivo de cópia de segurança. Considerado somente se for solicitado 
pelo usuário para atender requisitos da aplicação.
• Arquivo que sofra manutenção por mais de uma aplicação.
Não são considerados como ALI:
• Arquivos temporários;
• Arquivos de trabalho;
• Arquivos de classificação;
• Arquivos de cópia de segurança requerido pelo CPD.
• Arquivos introduzidos somente por causa da tecnologia 
usada.
• Ex.: arquivos de parâmetro para um software WFL, JCL,etc.;
• Operações de junção e projeção.
• Arquivos de índices alternativos
• Complexidade de um arquivo lógico Interno 
(ALI) 
a complexidade será usada para calcular o numero de ponto função do 
ALI
• Cada Arquivo Lógico Interno deve ser classificado de acordo 
com sua complexidade funcional relativa, que é baseada:
- no número de Registros Lógicos(RL) = entidades 
- e no número de Itens de Dados (ID) do arquivo.
Identificação do Número de Registros Lógicos 
(RL)
• Um Registro Lógico é um subgrupo de dados reconhecido pelo usuário 
dentro de um ALI. 
• Dependendo da visão do usuário um ALI pode ter mais de um Registro 
Lógico (RL).
Existem dois tipos de subgrupos que podem ser identificados como registros 
lógicos (IFPUG, 1999):
• Mandatórios – São subgrupos de dados que o usuário deve usar pelo 
menos uma vez durante o processo elementar de criação de um item num 
ALI.
• Opcionais – São subgrupos de dados que o usuário tem a opção de usar 
ou não durante o processo elementar de criação de um item em um ALI.
• Exemplo:
empregado( nome, endereço, telefone,(nomedo dependente, sexo), cargo, salário, órgão)
neste ALI, sob o ponto de vista do usuário consideramos grupos 
lógicos de dados:
nome, endereço, telefone, cargo salário, órgão
nome do dependente, sexo
Portanto temos: 2 registros lógicos
Regras que devem ser aplicadas para contagem 
dos registros lógicos:
• Conte um registro lógico para cada subgrupo 
identificado , opcional ou mandatório.
• Considere um registro lógico caso o ALI não possua 
subgrupos.
Identificação do Número de Itens de Dados
• Um item de dados (ID) representa um segmento de um ALI 
que possui um significado único, não repetitivo e pode ser 
reconhecido pelo usuário. Representa um campo de dados 
que formula uma ocorrência de informação completa. 
• Exemplo:
• empregado ( nome, endereço, telefone, cargo, salário)
tem CINCO itens de dados
Regras de contagem para os itens de dados
• Contar um item de dados para cada campo único, não repetitivo, 
reconhecido pelo usuário e mantido em um ALI via execução de um 
processo elementar.
Ex: Um número contábil, ou data que é armazenado em múltiplos campos 
, é contado como um único item de dado.
• Quando duas ou mais aplicações mantêm o mesmo ALI, mas cada uma 
mantém itens de dados separados, contar somente os itens de dados 
usados por cada aplicação para dimensionar o ALI.
• Contar um item de dados para cada parte de dado requisitada pelo 
usuário para definir um relacionamento com outro ALI, ou seja, uma chave 
estrangeira ou uma associação entre objetos. Ex: cod. Aluno (deve ser 
contada uma vez)
Determinar a complexidade de um ALI
Existe uma tabela 
definida pelo IFPUG que 
define a complexidade. 
Nesta tabela classifica-se 
um ALI em simples, 
médio e complexo, 
dependendo do número 
de registros lógicos e o 
número de itens de 
dados (ID) 
Fonte: IFPUG , 1999
TABELA DE COMPLEXIDADE PARA ARQUIVO LÓGICO
INTERNO
1 a 19 ID 20 a 50 ID 51 ou mais ID
1 RL Simples simples media
2 a 5 RL Simples Media Complexa
6 RLou mais Média Complexa Complexa
Fonte: IFPUG , 1999
• Ex: O ALI
Empregado (nome,endereço, cargo, salário 
(dependente,sexo), telefone)
Tem: 2 registros lógicos e 7 itens de dados.
Entrando na tabela 
Com 2 RL---------------------→
E com 7 itens de dados 
temos que o ALI é de complexidade simples
TABELA DE COMPLEXIDADE PARA
ARQUIVO LÓGICO INTERNO
1 a 19 ID 20 a 50 ID 51 ou mais
ID
1 RL Simples simples media
2 a 5 RL Simples Media Complexa
6 RLou mais Média Complexa Complexa
Tipo de Função SIMPLES MÈDIA COMPLEXA
Arquivo Lógico Interno(ALI) 7 PF 10 PF 15 PF
Arquivo de Interface
Externa(AIE)
5 PF 7 PF 10 PF
Tabela de contribuição dos PF não
ajustados das funções de dados
Fonte: IFPUG, 1999
Nosso exemplo o ALI é simples, portanto vale 7 PF
A tabela acima também vale para os ALE que veremos a seguir:
Arquivo de Interface Externa (AIE) 
• Um Arquivo de Interface Externa (AIE) é um grupo de dados 
logicamente relacionados ou informações de controle 
identificadas pelo usuário, referenciados na aplicação para 
fins de recuperação de dados cuja manutenção é feita por 
outra aplicação. 
• Os dados são armazenados fora da fronteira da 
aplicação.(VAZQUEZ
São considerados AIE , conforme a visão do usuário
• Dados de referência (dados externos usados 
pela aplicação ,mas que não são usados para 
manutenção em ALI);
• Arquivos de mensagens de auxílio;
• Arquivos de mensagens de erro.
• Não são considerados AIE:
• Dados recebidos de outra aplicação usados para adicionar, 
alterar ou remover dados em um ALI;
• Dados cuja manutenção é feita pela aplicação que esta sendo 
avaliada mas que são acessados e utilizados por outra 
aplicação;
• Dados formatados e processados para uso por outra 
aplicação.
Classificação da complexidade de um arquivo 
de interface externa (AIE)
• Cada Arquivo de Interface Externa (AIE) deve ser classificado de acordo o 
número de Registros Lógicos (RL) 
• e no número de Itens de Dados(ID) do arquivo.
• Os conceitos são similares aos usados para o ALI
As regras de contagem para itens de dados em 
um AIE são:
• Contar um item de dados para cada campo único , não repetitivo, 
reconhecido pelo usuário e referenciado em AIE via execução de um 
processo elementar.
• Quando duas ou mais aplicações referenciam o mesmo AIE, mas cada uma 
referenciam itens de dados separados, contar somente os itens de dados 
usados por cada aplicação para dimensionar o AIE.
• Contar um item de dados para cada parte de dado requisitada pelo 
usuário para definir um relacionamento com outro AIE, ou seja, uma 
chave estrangeira ou uma associação entre objetos.
• Ex.: Se um AIE é composto por mais de uma tabela em um Banco de 
dados relacional, as chaves usadas para relacionar as tabelas são contadas 
apenas uma vez.
• Um AIE pode ser
classificado como
simples, médio e
complexo conforme
uma tabela fornecida
pelo IFPUG que
relaciona os registros
lógicos com o número
de itens de dados
TABELA DE COMPLEXIDADE DE AIE
REGISTROS 
LOGICOS - RL
Número de itens de dados
1 A 19 ID 20 A 50 ID 51 OU MAIS 
ID
1 RL SIMPLES SIMPLES MEDIA
2 a 5 RL SIMPLES MÉDIA COMPLEXA
6 RL ou mais MÉDIA COMPLEXA COMPLEXA
Fonte: IFPUG
• Estudo de casos:
Primeiro passo: Determinar o escopo da contagem. Foi
dito pelo usuário que receberia a informação de alunos de
outro sistema, portanto, estamos considerando o Usuário
com arquivo de interface externa.
• Estudo de casos:
Segundo passo: O sistema é novo e vamos fazer a contagem para 
desenvolvimento. Não existe migração de dados ou projetos 
auxiliares na implantação:
Processos básicos do usuário são par a manutenção de arquivo de 
empréstimos, autores e livros 
• A classe autoria relaciona autor com livro, portanto tem um registro lógico e 
como já contamos os itens de relacionamento vamos considerar um item de 
dados
•A classe empréstimo associa um elemento externo com o livro. Neste caso só 
contamos o número de livro em livro. Temos um registro lógico e dois itens de 
dados, portanto verificamos na tabela que é simples:
• Temos quatro ALI simples, consultando a tabela de contribuição temos 7 PF por 
ALI, portanto contribui com 4* 7 PF = 28 PF.
Terceiro passo: determinação das contribuições dos ALI.
. A Classe livro é de persistência e 
constitui um ALI = temos um 
registro lógico e quatro itens de 
dados: entrando na tabela temos 
que é de complexidade: simples
. A classe autor é um ALI, com 
um registro lógico e dois itens de 
dados: na tabela de complexidade 
é simples.
• Considerando os AIE temos um registro com 
4 itens, portanto simples, contribuindo com 
mais 5 PF;
• A contribuição dos ALI e AIE são de 28 + 5= 
33 PF não ajustados
• Na próxima aula vamos ver com trabalhar as 
funções.
• Você observou que agora tudo esta sendo 
feito pela contagem dos grupamentos lógicos 
e pelos itens de dados.
• Em um modelo de dados você pode trabalhar 
com as entidades e os atributos.
• É preciso praticar....
• Na biblioteca virtual terá uma lista de 
exercícios... Pratique.
• Com isto encerramos nossa aula.
• Na próxima aula vamos terminar a 
padronização da contagem. 
• Você irá aprender como se deve fazer a 
contagem das entradas, consultas e saída.
• Vamos apresentar uma maneira de definir a 
complexidade destes elementos.
• - Vamos desenvolver um exemplo usando 
estes conceitos. 
• Até a próxima aula
• Contactos:
• Professor Horacio ribeiro
• www.espacodoprofessor.com
• Email: profhoracioribeiro@gmail.com
• Aula 4
http://www.espacodoprofessor.c/
mailto:profhoracioribeiro@gmail.com
Medidas do Esforço de Desenvolvimento de Software
Aula 5
Prof. Horácio Ribeiro
1Prof. Horacio Ribeiro
• Nesta aula vamos verificar, baseado no 
Function Point Counting Pratices 
• Manual – Release 4.1.1, - IFPUG - 1999
Como se deve tratar a funcionalidade.
• na aula passada aprendemos como tratar um 
ALI e um AIE
2Prof. Horacio Ribeiro
O IFPUG complementou os procedimentos e regras
do CPM 4.1.1 com um nova seção denominada"Práticas de Contagem" onde situações como dados
de código, dados compartilhados e outros casos
devem ser avaliados
3Prof. Horacio Ribeiro
Resolvemos 
- o passo 6 
na aula 3
- Os passos 
1, 2 e 3 na 
aula 4
Procedimento de Contagem de Pontos de Função
(HAZAN, 2001)
4Prof. Horacio Ribeiro
Objetivos da aula:
• contagem das funções transacionais
5Prof. Horacio Ribeiro
Objetivos da aula:
Aprender o que é uma transação de entrada
• - como determinar a complexidade de uma EE
Aprender o que é uma saída externa SE
• - Como determinar a complexidade
Aprender o que é uma consulta externa CE
• - como determinar a complexidade
6Prof. Horacio Ribeiro
• Nesta aula vamos completar o modelo 
fazendo a análise para Entradas, Saídas e 
Consultas.
• deve-se considerar o diagrama de contexto
(figura do CPM) 
7Prof. Horacio Ribeiro
• Veja figura abaixo
8Prof. Horacio Ribeiro
Explicar para os três tipos de transações
-conceituar como definir a complexidade da
entrada externa
- conceituar o que é uma saida
-Conceituar como definir a complexidade de uma
saída externa
- Conceituar o que é uma consulta
-Apresentar as tabelas de complexidade das
transações
- Calcular o número de ponto de função ajustados
9Prof. Horacio Ribeiro
• Veja figura abaixo
10Prof. Horacio Ribeiro
Definição:
Um processo elementar é a menor unidade de 
atividade significativa para o usuário final, tem as 
características:
- Ele deve ser completo em si mesmo 
- Deixar a aplicação em um estado consistente.
11Prof. Horacio Ribeiro
Para criar um parâmetro de referencia na
classificação das funções o IFPUG criou
uma tabela que resume os objetivos
primários de cada tipo de função
transacional e a identificação é feita por
este objetivo
Verifica-se a intenção primária da função
12Prof. Horacio Ribeiro
Tipo de Função Transação
tópico (EE) entrada externa (SE) saída extrna (CE) – consulta 
externa
Alterar o 
comportamento 
do sistema
IP - Intenção 
primaria da 
função de 
transação
F - Uma operação que 
pode ser feita pela 
função , mas não é 
sua intenção primária. 
Ela pode existir ou 
não.
NP – Não é 
permitida a 
função 
transacional
Manter um ou 
mais ALIs
IP - Intenção 
primaria da 
função de 
transação
F - Uma operação que 
pode ser feita pela 
função , mas não é 
sua intenção primária. 
Ela pode existir ou 
não.
NP – Não é 
permitida a 
função 
transacional
Apresentar 
Informações
F - Uma operação 
que pode ser feita 
pela função , mas 
não é sua intenção 
primária. Ela pode 
existir ou não.
IP- Intenção 
primaria da 
função de 
transação
IP- Intenção 
primaria da 
função de 
transação
13Prof. Horacio Ribeiro
Entradas Externas
Uma entrada externa é um processo elementar que
processa dados ou informações de controle
recebidos de fora da fronteira da aplicação e cujo
objetivo principal é manter um ou mais Arquivos
Lógicos Internos (ALI) e/ou alterar o
comportamento do sistema.
uma EE provoca uma inclusão, exclusão e/ou
alteração nos dados dos ALI
14Prof. Horacio Ribeiro
Entradas Externas
Uma Função do tipo EE tem um fluxo de informação de
fora da fronteira da aplicação para dentro , ou seja,
transações originadas do usuário ou de outros sistemas e
que de alguma forma são entrada de dados no sistema.
Estes dados, através de um processo lógico atualizam um
ALI, O processamento é um conjunto de críticas, cálculos,
algoritmos e referências/utilização de ALI ou AIE
As informações de controle podem ou não atualizar
diretamente.
• São entradas externas - EE:
- Operações de inclusões e alterações de 
registros em arquivos da aplicação,
- Janela que permite adicionar, excluir e 
alterar registros em arquivos.
Prof. Horacio Ribeiro 15
Não são entradas externas - EE :
• Menus, 
• Telas de Login,
• Telas de filtro de relatórios e consultas,
• Múltiplos métodos de se executar uma 
mesma lógica de entrada
Prof. Horacio Ribeiro 16
Regras para se identifica uma EE – entrada 
externa
- Identificar todos os processos elementares 
que recebem dados de fora da aplicação e que 
fazem a atualização de um ou mais ALIs
segundo as seguintes regras( IFPUG):
Prof. Horacio Ribeiro 17
Regra 1:
• Os dados ou informações devem ser recebidos de fora da fronteira da 
aplicação;
Regra 2: 
• A entrada de dados não for uma informação que modifique o comportamento 
do sistema , deve manter no mínimo um AIE;
Regra 3:
• Um processo elementar identificado para ser contado como uma EE, pelo menos uma 
das opções a seguir devem ser satisfeitas:
- A lógica de processamento deve ser única e diferente das demais entradas 
externas;
– O conjunto de dados elementares identificados é distinto dos conjuntos 
identificados por outras EE;
Prof. Horacio Ribeiro 18
Determinação da complexidade da Entrada 
externa
• Cada EE deve ser classificada conforme sua 
complexidade funcional que é baseada no 
número de Arquivos Referenciados (ALI e AIE) 
e no número de itens de dados (ID).
Prof. Horacio Ribeiro 19
Regras de contagem para os Arquivos 
referenciados (AR) em uma EE (IFPUG):
• Regra 1: Contar um AR para cada ALI mantido;
• Regra 2:Contar um AR para cada ALI ou AIE
lido durante o processo de EE;
• Regra 3:Contar somente um AR para cada ALI
que seja mantido e lido durante o 
processo da EE.
Prof. Horacio Ribeiro 20
Identificação do Número de Itens de Dados na EE
• Um item de dado é um campo único , não repetido, 
identificado pelo usuário e que é atualizado em um ALI 
pela EE.
• Cada item de dado atualizado em um ALI pela EE deve 
ser computado , considerando o seguinte (IFPUG) :
Prof. Horacio Ribeiro 21
Identificação do Número de Itens de Dados na EE
• Regra 1: Contar um item de dados para cada campo único , não 
repetitivo, reconhecido pelo usuário e mantido em um ALI.
• Regra 2: Campo recuperado ou derivado pelo sistema e 
armazenado em um ALI, durante um processo elementar de uma 
EE que não cruzar a fronteira da aplicação não deve ser contado.
• Regra 3:Linhas de comando ou teclas de função que provêem a 
capacidade para definir a ação a ser tomada pela EE. 
• Regra 4:Campos não informados pelo usuário, mas que são 
atualizados em um ALI por uma EE.
• Regra 5:Mensagem de erro ou confirmação ligadas aos processos 
lógicos executados pela EE. (contar como um item)
Prof. Horacio Ribeiro 22
Determinar a complexidade de uma EE
• A complexidade funcional de uma EE é determinada em 
função da quantidade de ALIs e AIEs referenciados e do 
número de itens de dados referenciados conforme 
tabela
23Prof. Horacio Ribeiro
Número de Itens de Dados(ID)
1 a 4 ID 5 a 15 ID 16 ou mais ID
0 ou 1 arquivo
referenciado (AR)
SIMPLES SIMPLES MÉDIA
2 AR SIMPLES MÉDIA COMPLEXA
3 ou mais AR MÉDIA COMPLEXA COMPLEXA
Tabela 3.5 : Tabela de complexidade de Entradas Externas
Fonte : IFPUG , 1999
24Prof. Horacio Ribeiro
saída externa(SE)
- é um processo elementar que envia dados ou informações
de controle para fora da fronteira da aplicação.
- Seu objetivo é exibir informações recuperadas através de
processamento lógico, isto é , processamento que envolva
cálculos ou criação de dados derivados e não apenas uma
simples recuperação de dados.
- São atividades do sistema que transformam dados dos
ALI e geram resultados que são exibidos ao usuário.
25Prof. Horacio Ribeiro
São saídas externas
A identificação de uma saída externa todos os processos e informações de
controle que enviam dados para fora da fronteira da aplicação. Considerar:
•Dados transferidos para outra aplicação : dados de um ALI que são formatados e
processados para uso por uma aplicação externa.
•Relatórios : Cada relatório produzido pode ser considerado uma SE. Para
relatórios de formato idênticos mas que necessitam de lógicas de processamento
ou cálculos distintos devem ser considerados saídas externas diferentes.
•Relatórios on-line : Saída de dados on-line que não seja a parte de saída de uma
consulta Externa.
•Formatos Gráficos: Contados da mesma forma como saída em formato texto,
isto é , cada formato gráfico diferente é contado como uma saída externa.
• Gerador de relatórios : Cada relatório desenvolvido para o usuário via gerador de
relatório deve ser considerado como uma saída externa.
Para identificar as SE deve verificar o 
processamento lógico do processo elementar 
conforme as seguintes regras (IFPUG):
• Regra 1: Se existe pelo menos uma fórmula 
matemática ou cálculo;
• Regra 2: Se cria dados derivados;
• Regra 3: Se mantém pelo menos um ALI;
• Regra 4: Se muda o comportamento do sistema.
Prof. Horacio Ribeiro 26
Prof. Horacio Ribeiro 27
Não devem ser considerados como
saídas externas:
•Telas de Ajuda;
•Literais;
•Data, hora, controles de paginação , etc.;
•Relatórios múltiplos com a mesma lógica e
formato
•Relatórios criados pelo usuário de forma
dinâmica usando um linguagem como SQL.
Prof. Horacio Ribeiro 28
Classificação da complexidade da saída
externa
A classificação da complexidade de uma saída externa
deve ser feita de acordo com o número de Arquivos
Referenciados e no número de itens de dados.
1 Identificação do Número de arquivos referenciados
Um arquivo referenciado é qualquer AIE ou ALI que foi
lido mantido no processamento da Saída Externa
sendo que o número de Arquivos Referenciados é a
soma dos ALI e AIE atualizados ou consultados para
gerar a Saída Externa.
Prof. Horacio Ribeiro 29
Classificação da complexidade da saída
externa
Regras de contagem para AR em uma Saída Externa (
IFPUG):
Regra 1: Contar um AR para cada Ali mantido durante o processo
elementar;
Regra 2:Contar um AR para cada ALI ou AIE lido durante o
processo elementar;
Regra 3:Contar somente um AR quando um ALI é mantido e lido
pelo processo elementar da SE.
Prof. Horacio Ribeiro 30
Um item de dado deverá ser identificado
conforme as seguintes regras (IFPUG):
Regra 1: Contar um item de dado cada campo não repetido
reconhecido pelo usuário. Se o item de dados entra e sai pela
fronteira da aplicação ele será computado apenas uma vez;
Regra 2: Contar um item de dado se aplicação enviar mensagens de
resposta para fora da fronteira, indicando erro ou sucesso no
processamento;
Regra 3:Um campo recuperado ou derivado pelo sistema e
armazenado em um ALI, durante um processo elementar de uma SE,
que não cruzar a fronteira da aplicação não deve ser contado.
Determinar a complexidade de uma SE
• A complexidade funcional de uma SE é determinada 
em função do número de itens de dados e da 
quantidade de arquivos referenciados (ALI + AIE) 
podendo ser classificada conforme a tabela
Prof. Horacio Ribeiro 31
Número de Itens de Dados (ID)
1 a 5 ID 6 a 19 ID 20 ou mais ID
0 ou 1 AR SIMPLES SIMPLES MÉDIA
2 a 3 AR SIMPLES MÉDIA COMPLEXA
4 ou mais AR MÉDIA COMPLEXA COMPLEXA
Consultas Externas - CE
• Uma consulta Externa é uma combinação de entrada/saída de dados onde 
a entrada de dados causa uma saída de dados.
• A lógica de processamento é de consulta a ALI e não deve conter 
fórmula matemática ou cálculo nem criar dados derivados 
ou atualizar nenhum ALI.
Prof. Horacio Ribeiro 32
Prof. Horacio Ribeiro 33
As seguintes regras devem ser satisfeitas para um processo 
elementar ser contado como uma consulta Externa
- O processamento elementar recupera dados ou informações de
controle de um ALI ou AIE;
- A lógica do processo elementar não pode conter cálculos;
- A lógica do processo elementar não cria dados derivados;
- A lógica do processo elementar não mantêm nenhum ALI;
-A lógica do processo elementar não altera o comportamento do
sistema.
Prof. Horacio Ribeiro 34
São consideradas consultas externas
•Um processo de recuperação de dados que seleciona dados com 
base em uma entrada fornecida;
•Telas de Logon;
•Telas de Help;
•Telas de alteração/remoção que mostram o que será alterado ou 
removido antes de sua efetivação.
•Tela de menus que permitem informar parâmetros para a consulta na 
tela escolhida
Prof. Horacio Ribeiro 35
Não são consideras CE:
•Telas de Menus que oferecem somente funcionalidade de seleção 
de telas;
•Dados derivados;
•Documentação On-Line;
•Sistema de Teste;
•Sistema Tutoriais;
•Relatórios e consultas que contenham cálculo ou gerem dados 
derivados
Prof. Horacio Ribeiro 36
Identificação do Número de arquivos
referenciados
Um arquivo referenciado é um arquivo ALI ou AIE lido pela
Consulta Externa.
Regras de contagem para um AR em uma CE (IFPUG) :
Regra 1:Contar um AR para cada ALI lido;
Regra 2:Contar um AR para cada AIE lido.
Prof. Horacio Ribeiro 37
Identificação do Número de Itens de Dados 
Um item de dado é um campo único , não repetitivo, reconhecido pelo usuário. 
Regras de contagem de itens de dados para CE (IFPUG):
Regra 1:Contar um item de dados para cada campo reconhecido pelo usuário e 
não repetitivo que atravessa a fronteira da a aplicação e é requisitado para 
definir quando , o que ou como os dados serão recuperados ou gerados pelo 
processo elementar;
Regra 2:Contar um item de dados para cada campo reconhecido pelo usuário e 
não repetitivo que sai pela fronteira da aplicação;
Regra 3:Se um item de dados entra e sai da aplicação deve ser contado 
somente uma vez;
Regra 4:Contar um item de dados para uma mensagem de resposta para fora 
da fronteira da aplicação indicando um erro ocorrido ou confirmando que um 
processo terminado ou deve continuar.
Prof. Horacio Ribeiro 38
Regras de contagem de itens de dados para CE (IFPUG):
Regra 5:
Contar um item de dados pela habilidade da aplicação em definir que 
uma ação a ser feita, mesmo havendo diversos métodos de chamar o 
mesmo processo lógico;
Regra 6:
Não devem ser contados : literais, paginação, variáveis ou sinalizações 
geradas pelo sistema.
Regra 7:
Um item de dado adicional deve ser computado caso sejam requeridas 
mensagens de erro ou campos de confirmação associados à parte de 
entrada da Consulta Externa
Prof. Horacio Ribeiro 39
Número de Itens de dados(ID)
1 a 5 ID 6 a 19 ID 20 ou mais
ID
0 ou 1 AR SIMPLES SIMPLES MÉDIA
2 a 3 AR SIMPLES MÉDIA COMPLEXA
4 ou mais
AR
MÉDIA COMPLEXA COMPLEXA
Determinar a complexidade de uma CE
A complexidade funcional de uma CE é determinada em
função do número de itens de dados e arquivos
referenciados conforme a tabela
Tabela: Tabela de complexidade de Consultas Externas
Prof. Horacio Ribeiro 40
COMPLEXIDADE
SIMPLES MÉDIA COMPLEXA
EE 3 4 6
SE 4 5 7
CE 3 4 6
Determinação do peso de cada função
Com o tipo de função e a complexidade determinada para
cada função estabelece-se o peso usando a tabela abaixo:
Tabela Contribuição de transação na contagem dos PFs não ajustados
COMPLEXIDADE
SIMPLES MÉDIA COMPLEXA
ALI 7 10 15
AIE 5 7 10
EE 3 4 6
SE 4 5 7
CE 3 4 6
Prof. Horacio Ribeiro 41
Tabela:
Contribuição das Funções de dados e de 
transação na contagem dos PFs não ajustados
Prof. Horacio Ribeiro 42
O cálculo dos pontos de função não ajustados
Para cada um dos cinco tipos de função (ALI, AIE ,
EE, SE e CE), verifica-se a complexidade e o peso
multiplicado pelo número de elementos contados em
uma mesma complexidade.
O total é chamado de pontos de função (TPF).
Prof. Horacio Ribeiro 43
Cálculo de Pontos de Função para um projeto de desenvolvimento
O projeto de desenvolvimento apresenta três componentes em termos de
funções :
1 - Funcionalidades da aplicação incluídas pelos usuários como requisitos
2 - Funcionalidades de conversão incluídas pelos usuários como requisitos
3 - Valor do fator de ajuste da aplicação
Fórmula para cálculo:
DFP = (UFP + CFP) * VAF
Onde :
DFP – Número de pontos de função de desenvolvimento;
UFP – Número de pontos de função brutos apurados;
CFP – Número de pontos de função adicionados por processos de
conversão de dados;
VAF – Valor do fator de ajuste.
• É preciso praticar....
• Na biblioteca virtual terá uma lista de 
exercícios... Pratique.
44Prof. Horacio Ribeiro
• Com isto encerramosnossa aula.
- Na próxima aula vamos aprender a fazer estimativas de 
diversas formas a partir do conhecimento do número de 
ponto função. 
- Vamos estudar como estas estimativas são usadas para 
a gerencia do software, em termos de esforço , 
dimensionamento de equipe e prazo.
45Prof. Horacio Ribeiro
• Até a próxima aula
46Prof. Horacio Ribeiro
• Contactos:
• Professor Horacio ribeiro
• www.espacodoprofessor.com
• Email: profhoracioribeiro@gmail.com
• Aula 4
47Prof. Horacio Ribeiro
http://www.espacodoprofessor.c/
mailto:profhoracioribeiro@gmail.com
Medidas do Esforço de Desenvolvimento de Software
Aula 6
Prof. Horácio Ribeiro
Nas aulas passadas 
estudamos como medir a 
funcionalidade do software
• Na segunda fase vamos estudar como 
fazer estimativas de esforço e prazo e 
acompanhar o desenvolvimento de 
projetos
• Objetivos da aula:
• Aprender a fazer estimativas de prazo e 
esforço utilizando método COCOMO
• Aprender como fazer estimativa com ponto 
função. 
• Classificar o software em grau de dificuldade, 
segundo critérios do COCOMO. 
• Para uma nova aplicação :
–Desejamos saber quanto tempo 
será necessário?
–Quanto vai custar?
–Vale a pena?
• estimativas de custos e prazos em 
software
–não é ciência exata;
–Diminuir o nível de erro da estimativas;
–Um erro na estimativa pode 
comprometer o projeto.
• 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. 
tabela de informações gerais
projet
o
prazo 
(dias) custo (reais)
lingua
gem
PF (não 
ajustado
)
numero 
desenvol
vedores
coruj
a 230 R$ 130.000,00 PHP 380 2
diario 
escol
ar 150 R$ 90.000,00 PHP 278 2
folha 200 R$ 110.000,00 java 315 2
portal 110 R$ 40.000,00 pyton 260 1
projet
o
analise projeto codificação integraçao totais
% 
pf
% 
pra
zo
% 
cus
to % pf
% 
pr
az
o
% 
cus
to
% 
pf
% 
pra
zo
% 
custo % pf
% 
prazo
% 
custo PF prazo custo
coruja
1
8,
2 9 20 13,732 14
46,
7 35 45 21,5 24 21 380 230
R$ 
130.000,00 
diario 
escola
r
1
7,
6 14 23 14,127 17
48,
8 33 42 19,5 26 18 278 150
R$ 
90.000,00 
folha
1
8,
6
19,
6 18 14,430 19
44,
7
32,
4 44 22,3 18 19 315 200
R$ 
110.000,00 
portal
1
8,
4 12 19 12,834
15,
3
43,
6 29 44,3 25,2 25 21,4 260 110
R$ 
40.000,00 
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. 
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
Pmedio é a media dos prazos dados
• Exemplo:
9 técnicos experientes estimaram o prazo:
Tecnico1:10 dias tecnico2:20 dias tecnico3:15 dias
Técnico4:12 dias tecnico5: 8 dias tecnico6:25 dias
Tecnico7:15 dias tecnico8:12 dias tecnico9:15 dias
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 (15 dias + meio dia)
estimativas sendo PMI
projet
o
analise projeto codificação integraçao totais
% pf
% 
praz
o
% 
cust
o % pf
% 
praz
o
% 
cust
o % pf
% 
praz
o
% 
cust
o % pf
% 
praz
o
% 
custo PF prazo custo
media 18,2 13,7 20 13,830,8 16,3 45,9 32,4 43,8 22,1 23,3 19,9 308,3 172,5 92500
maior 18,6 19,6 23 14,4 34 19 48,8 35 45 25,2 26 21,4 380 230 130000
menor 17,6 9 18 12,8 27 14 43,6 29 42 19,5 18 18 260 110 40000
estima
tiva 18,2 13,9 20,2 13,730,7 16,4 46 32,2 43,7 22,2 22,8 19,8 312,2 171,7 90000
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.
Pode-se realizar o cálculo da medida 
em cada fase do desenvolvimento.
• O assunto estimativas e os custos em 
projetos foi estudado Barry Boehm (1981).
–Estudou mais de 5000 projetos de 
software;
–Estes softwares foram classificados 
segundo uma hierarquia de modelos; 
–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. 
COCOMO
Classificação do tipo do software:
• Modelo 2 (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.
COCOMO
Classificação do tipo do software:
• 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...) 
COCOMO
Classificação de classes de projeto (tres):
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-se exemplificar pequenos sistemas. 
COCOMO
Classificação de classes de projeto (tres):
2 - Modo Semi destacado ou difuso:
Projetos de software intermediário (em 
tamanho e complexidade) na qual 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.
COCOMO
Classificação de classes de projeto (três):
3 – Modo Embutido ou restrito:
um projeto que deve ser desenvolvido 
dentro de restrições operacionais, como por 
exemplo sistema de controle de telefonia.
COCOMO básico - equaçoes:
Projeto de
software
ab bb cb db
Orgânico 2,4 1,05 2,5 0,38
Semi
destacado
3,0 1,12 2,5 0,35
Embutido 3,6 1,20 2,5 0,32
E = esforço aplicado em pessoas-mês.
D = tempo de desenvolvimento em meses cronológicos.
Exemplo:
Considere um software com 33,3 Kloc, usando o 
modelo semi destacado temos:
O número ideal de pessoas no projeto
Duração do projeto:
D = 2,5 (E) exp (0,35)
= 2,5 *(152)elevado a 
0,35
= 14 meses 
Esforço:
E = 3,0 (Kloc) exp
(1,12)
= 3,0 (33,3) elevado 
a 1,12
= 152 pessoas-mês
N = E/D = 152/14,5 = 11 pessoas
Exemplo 2:
• Considere que após uma análise de ponto 
função temos 236 PF não ajustado.
• Como as formulas do COCOMO foram 
construídas com KLOC. Se utilizarmos a 
linguagem ACCESS temos:
Exemplo 2
Usando o COCOMO básico,
gerente considerou o projeto como orgânico
E usaremos as formulas:
Duração do projeto:
D = 2,5 (E) exp (0,35)
= 2,5 *(36)elevado a 
0,35
= 4,3 meses 
Esforço:
E = 3,0 (Kloc) exp
(1,12)
= 3,0 (9) elevado a 
1,12
= 36 pessoas-mês
COCOMO intermediário - equações:
NO modelo intermediário o básico é
ampliado considerando-se 4 grandes
categorias de custos:
A – Atributos do produto:
I – Confiabilidade exigida do software
II – Tamanho do Banco de dados.
III – Complexidade do software
COCOMO intermediário - equações:
NO modelo intermediário o básico é ampliado.
considerando-se 4 grandes categorias de custos:
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
COCOMO intermediário - equações:
NO modelo intermediário o básico é ampliado.
considerando-se 4 grandes categorias de custos:
C – Atributos de pessoal
I – Capacidade dos analistas
II – Capacidadedos programadores
III – Experiência na aplicação
IV – Experiência no ambiente de Hardware
V - Experiência com a linguagem de
programação
COCOMO intermediário - equações:
NO modelo intermediário o básico é ampliado.
considerando-se 4 grandes categorias de custos:
D – atributos de projeto
I – Uso de ferramenta de software.
II – técnicas modernas de programação
III – Prazo requerido para o desenvolvimento
equaçoes do modelo intermediário:
O produto dos índices encontrados na tabela torna-se o EAF
E = a (kloc) exp (b) * EAF
Onde:
o coeficiente a e o expoente b são fornecidos pela tabela:
Projeto de software a b
Orgânico 3,2 1,05
Semi destacado 3,0 1,12
Embutido 2,8 1,20
EAF
Considere que, no exemplo 2, 
anterior (COCOMO intermediário) o 
gerente considerou o projeto como 
orgânico
E usaremos as formulas:
exemplo
Calcular EAF:
exemplo
Analisando os 15 direcionadores o gerente concluiu os 
seguintes resultados:
Complexidade do software: alta
Restrições quanto ao uso da memória: Alto
Experiência com a linguagem de programação: Baixa
Capacidade dos programadores: Baixa
Os outros atributos foram considerados normais
• Assim pode-se determinar o EAF 
EAF = (1,15 * 1,06*1,14*1,17) = 1,63
Desta forma pode-se estimar o esforço:
• Prazo: 
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;
• Até a próxima aula
• Contactos:
• Professor Horacio ribeiro
• www.espacodoprofessor.com
• Email: profhoracioribeiro@gmail.com
• Aula 6
http://www.espacodoprofessor.c/
mailto:profhoracioribeiro@gmail.com
Medidas do Esforço de Desenvolvimento de Software
Aula 7
Prof. Horácio Ribeiro
Na aula anterior iniciamos métodos 
de estimativas do software
- Avaliações com base estatística
- cocomo
• Estudo de casos
Sistema de Manutenção de Clientes
• 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.
Estudo de casos com ponto função
Características do sistema:
• - 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 , 
Email e Observações.
• - O nome do cliente, endereço, cidade, CEP e email 
são obrigatórios e deverão ser sempre informados
Casos de uso identificados
A tecnologia usada no sistema 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 Funções do tipo dado
O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que 
possui a seguinte estrutura:
Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas:
É um grupo lógico de dados identificável pelo usuário ? Sim.
É mantido por um processo elementar dentro da fronteira da aplicação ? Sim.
A aplicação possui somente um ALI.
Número de Tipos de Dados (TD) - é um campo único, 
reconhecido pelo usuário, não repetido. (7 tipos de dados )
Número de Tipos de Registros (TR) - é um subgrupo de tipo de 
dados, reconhecido pelo usuário, componente de um ALI ou 
AIE (1 Registro Lógico). 
Determinar Funções do tipo dado
ALI e AIE devemos classificar a função de acordo com sua complexidade funcional
Tipos de Dados
Tipos de Registros < 20 20 - 50 > 50
1 Baixa Baixa Média
2 - 5 Baixa Média Alta
> 5 Média Alta Alta
Tipo de Função Baixa Média Alta
Arquivo Lógico Interno -
ALI
7 PF 10 PF 15 PF
Arquivo de Interface
Externa - AIE
5 PF 7 PF 10 PF
funções do tipo dado para a aplicação é igual a 7 PF
AIE - Arquivo de interface externa - é um grupo de 
dados logicamente relacionados que é usado pela 
aplicação entretanto sofre manutenção a partir de 
outra aplicação.
A aplicação não tem nenhum AIE. Com contribuição de 
0 PF.
Determinar AIE
As funções do tipo transação representam a funcionalidade 
fornecida ao usuário para atender os requisitos da aplicação. São 
classificadas como:
Entradas Externas - EE - Processa as informações e/ou dados 
recebidos de fora da fronteira da aplicação 
Saídas Externas - SE - Envia dados ou informações para fora da 
fronteira da aplicação 
Consultas Externas - CE - Envia dados ou informações de 
controle para fora da fronteira da aplicação. 
Determinar as funções do tipo Transação 
Cada função do tipo transação deve ser 
classificada com relação a sua complexidade 
funcional em:
• Número de Arquivos Referenciados - AR - Um 
ALI lido ou mantido pela função do tipo 
transação ou um AIE lido pela função do tipo 
transação. 
• Número de Tipos de Dado - TD - Um campo 
único, reconhecido pelo usuário, não repetido. 
Após determinar a quantidade de AR e TD da aplicação podemos definir
a sua complexidade de acordo com as seguintes tabelas:
Tabela de complexidade para Entradas Externas:
Tipos de Dados
Arquivos
Referenciados
< 5 5 - 15 > 15
< 2 Baixa Baixa Média
2 Baixa Média Alta
> 2 Média Alta Alta
Tipos de Dados
Arquivos
Referenciados
< 6 6 - 19 > 19
< 2 Baixa Baixa Média
2 - 3 Baixa Média Alta
> 3 Média Alta Alta
Função Tipo AR TD
Cadastro de Clientes
- Incluir EE 1 7
- Alterar EE 1 7
- Excluir EE 1 7
- Listar SE 1 7
- Consultar CE 1 8
Vamos criar uma tabela para indicar as funções do tipo
transação identificada e para cada uma delas a quantidade
de AR e TD.
(listar = 10 td SE - além dos campos de dados estamos estimando ou
contando os comandos botão e mensagem ao usuário) (se não contar não fará
diferença)
Após determinar a complexidade das funções de
transação podemos calcular sua contribuição de
acordo com a tabela abaixo:
Tipo de Função Baixa Média Alta
Entrada Externa - EE 3 PF 4 PF 6 PF
Saída Externa - SE 4 PF 5 PF 7 PF
Consulta Externa - CE 3 PF 4 PF 6 PF
Abaixo temos a tabela que exibe as funções
do tipo Transação para a aplicação
manutenção de clientes.
Função Tipo Complexidade PF
Cadastro de Clientes
- Incluir EE Baixa 3
- Alterar EE Baixa 3
- Excluir EE Baixa 3
- Listar SE Baixa 4
- Consultar CE Baixa 3
Total dos Pontos de função para as funções de tipo
transação da aplicação: 16 PF
O total geral dos pontos de função não ajustados para a
aplicação é de 23 PF ( 16 + 7 )
16 PF
Cálculo do fator de ajuste
O valor do fator de ajuste (VFA) é
baseado em 14 características gerais de
sistema listadas abaixo:
Característic
a
Influência Característica Influência
1 4 8 0
2 0 9 2
3 0 10 0
4 3 11 4
5 0 12 3
6 0 13 0
7 0 14 4
Valor Total => 20
Uma equipe de profissionais respondeu e deu nota para os 14 características:
As notas dadas para os itens foram:
VFA = (20 x 00,1 ) + 0,65 = 0,85
O valor do fator de ajuste é igual a 0,85.
Como estamos usando as regras do manual de
contagem, que também são usadas por outras
empresas.
Isto nos facilita, pois se não tivermos uma base
histórica podemos buscar informações em outras
empresas a fim de subsidiar sua estimativa.
Na nossa empresa O esforço em horas é obtido
pela formula (já por indicadores estatísticos)
Esforço Total (horas ) = PF * índice de
produtividade
(os índices de produtividade