Métricas em Engenharia de Software
PONTOS POR CASO DE USO
PONTOS POR FUNÇÃO
2008-1
TI - Sistemática de Métricas
“Não se consegue controlar
o que não se consegue medir”
Tom DeMarco
Aspectos a discutir







Projetos
O que são métricas de software?
Porque devem ser utilizadas
O que se deve medir?
Como podem ser feitas estas medidas?
Quais os principais métodos para estimar
prazos e custos?
Quais os problemas de cada um?
Projetos

Projeto é um empreendimento não
repetitivo, caracterizado por uma seqüência
lógica e clara de eventos, com início, meio e
fim, que se destina a atingir um objetivo
claro e definido, sendo conduzido por
pessoas dentro de parâmetros predefinidos
de tempo, custo, recursos envolvidos e
qualidade.
Projetos - Porque gerenciá-los?









Competição
Padrões de qualidade
Redução das margens de lucro
Resultados financeiros
Fatores tecnológicos
Aspectos Legais
Aspectos sociais
Fatores políticos
Pressões econômicas
Projetos beneficiados com gerência







De tamanho maior ($, pessoal e tempo)
Mais interdependentes
Com grande importância (grau de risco...)
Afetam a reputação da organização
Envolvem recursos compartilhados
São não-familiares à equipe
Envolvem incerteza do mercado
O projeto bem sucedido







Concluído no tempo previsto
Concluído no orçamento previsto
Com utilização otimizada de recursos
Com qualidade e performance desejadas
Com o mínimo possível de alterações
Com alto grau de aceitação pelo usuário
Com adaptação cultural adequada
Estimulando o sucesso do projeto










Seleção correta da equipe
Alto grau de comprometimento da equipe
Sinergia com parceiros
Identificação precoce de pontos de melhoria
Estimativas (prazos, custo, tamanho) realistas
Planos de contingência
Modificações sob controle
Prioridade para alcance das metas
Linhas de comunicação informais
Inexistência de pressões externas à equipe
Gerenciamento de Projetos
Benefícios










Evitar surpresas durante a execução
Estabelecer diferencial competitivo
Antecipar situações desfavoráveis
Adaptar trabalho ao cliente
Dispor de orçamento antes dos gastos
Agilizar decisões
Aumentar controle gerencial sobre as fases
Facilitar revisões na estrutura do projeto
Otimizar a alocação de recursos
Facilitar novas estimativas
Fracasso de projetos: causas










Externas: mudanças na estrutura, tecnologia, ambiente,
preços e cenário político
Metas e objetivos mal estabelecidos
Pouca compreensão da complexidade
Estimativas deficientes
Planejamento inadequado
Gerência de projeto ineficiente
Falta de treinamento e capacitação
Falta de padronização e metodologias
Avaliação incorreta dos riscos
Clientes com expectativas não atendidas
Gerenciar integradamente...
Escopo
Contratos
Comunicação
Tempo
Custo
Integração
Riscos
RH
Qualidade
O que seria um bom método?


Aquele que fosse capaz de permitir a
realização de previsões com um alto grau de
acerto em relação ao item avaliado.
Aquele que permitisse a realização da
estimativa o mais rápido possível dentro do
ciclo de vida de desenvolvimento.
Principais Métodos

Avaliação sem compromisso técnico

Avaliações por similaridade

Avaliações baseadas em fórmulas.
Dados para avaliação


Para que boas avaliações possam ser realizadas, é
fundamental que existam dados, colhidos de projetos
anteriores.
Os dados relevantes básicos são




tamanho
esforço
distribuição das habilidades na equipe
Muitos aspectos tornam difícil a comparação:






tipo de software
metodologia utilizada
grau de complexidade
ambiente de desenvolvimento
nível cultural da equipe
e mais....

Uma das maiores dificuldades no gerenciamento
de projetos de informática é saber a dimensão do
que esta sendo gerenciado

Muitas aplicações que parecem pequenas,
quando em desenvolvimento, mostram-se
muitas vezes maiores do que o previsto
inicialmente.
Porque Métricas ?
Vamos fazer uma analogia com outra Engenharia
Engenharia Civil
Como se contrata a construção de uma casa ?
OU
Como se compra uma casa ?
Já imaginaram fazer isto sem a unidade m ou m2, ou sem CUB?
Porque Métricas ?
Vamos ver como funciona com Software...
Como se contrata a construção de um aplicativo ?
OU
Como se compra um aplicativo ?
Que métrica utilizamos ?
Qual métrica utilizamos ?
Tipos de Métricas





Contagem de Linhas de Código Fonte (LOCs)
Halstead (operandos e operadores)
Análise de Pontos por Função
Análise por Casos de uso
Outras Técnicas ....
Pontos por Caso de Uso



Foi proposto em 1993 por Gustav Karner;
Baseou-se na Análise por Pontos de Função;
Trata de estimar o tamanho de um sistema
de acordo com:



o modo como os usuários o utilizarão;
a complexidade de ações requerida por cada
tipo de usuário;
uma análise em alto nível dos passos
necessários para a realização de cada tarefa;
Pontos por Caso de Uso


O Método de Use Case Points foi criado para
que seja possível estimar o tamanho de um
sistema já na fase de levantamento de
Casos de Uso;
Ele utiliza-se dos próprios documentos
gerados nesta fase de análise como subsídio
para o cálculo dimensional;
Pontos por Caso de Uso

Sistema que será usado como exemplo:



Site de suporte de produtos para uma grande
companhia de software;
A estimativa foi feita a partir dos casos de uso
de nível muito alto (business modelling), que
foram criados em tempo de levantamento de
requisitos;
Os atores, nessa vez, foram os diferentes tipos
de usuários identificados nesses casos de uso;
Pontos por Caso de Uso

Passo 1: Cálculo do UAW (Unadjusted Actor
Weight)
Tipo de Ator
Peso
Descrição
Ator Simples
1
Outro sistema acessado através de uma
API de programação
Ator Médio
2
Outro sistema acessado interagindo através
da rede
Ator Complexo
3
Um usuário interagindo através de uma
interface gráfica
Pontos por Caso de Uso

No caso do exemplo:
Tipo de Ator
Peso
Nº de atores
Resultado
Ator Simples
1
0
0
Ator Médio
2
0
0
Ator Complexo
3
4
12
Total UAW
12
Valores já calculados: UAW = 12
Pontos por Caso de Uso

Passo 2: Cálculo do UUCW (Unadjusted Use
Case Weight)

Para fins de cálculo, dividimos os casos de uso
em três níveis de complexidade:



Simples (peso 5): Tem até 3 transações, incluindo
os passos alternativos, e envolve menos de 5
entidades;
Médio (peso 10): Tem de 4 a 7 transações,
incluindo os passos alternativos, e envolve de 5 a 10
entidades;
Complexo (peso 15): Tem acima de 7 transações,
incluindo os passos alternativos, e envolve pelo
menos de 10 entidades;
Pontos por Caso de Uso

No caso do exemplo:
Tipo
Peso Nº de Casos de Uso
Resultado
Simples
5
7
35
Médio
10
13
130
Complexo
15
3
45
Total UUCW
210
Valores já calculados: UAW = 12, UUCW = 210
Pontos por Caso de Uso


Passo 3: Cálculo do UUCP (Unadjusted Use
Case Points)
UUCP = UAW + UUCW
No caso do exemplo:
UUCP = 12 + 210 = 222
Valores já calculados: UAW = 12, UUCW = 210, UUCP = 222
Pontos por Caso de Uso

Calculando fatores de ajuste:

O método de ajuste é bastante similar ao
adotado pela Análise por Pontos de Função e é
constituído de duas partes:


Cálculo de fatores técnicos: cobrindo uma série
de requisitos funcionais do sistema;
Cálculo de fatores de ambiente: requisitos nãofuncionais associados ao processo de
desenvolvimento;
Pontos por Caso de Uso

Passo 4: Cálculo do
Tfactor

Para cada requisito
listado na tabela, deve
ser atribuído um valor
que determina a
influência do requisito
no sistema, variando
entre 0 e 5;
Fator
Requisito
Peso
T1
Sistema distribuído
2
T2
Tempo de resposta
2
T3
Eficiência
1
T4
Processamento complexo
1
T5
Código reusável
1
T6
Facilidade de instalação
0.5
T7
Facilidade de uso
0.5
T8
Portabilidade
2
T9
Facilidade de mudança
1
T10
Concorrência
1
T11
Recursos de segurança
1
T12
Acessível por terceiros
1
T13
Requer treinamento especial
1
Pontos por Caso de Uso

No caso do exemplo:
Fator
Requisito
Peso
Influência
Resultado
T1
Sistema distribuído
2
1
2
T2
Tempo de resposta
2
3
6
T3
Eficiência
1
3
3
T4
Processamento complexo
1
3
3
T5
Código reusável
1
0
0
T6
Facilidade de instalação
0.5
0
0
T7
Facilidade de uso
0.5
5
2.5
T8
Portabilidade
2
0
0
T9
Facilidade de mudança
1
3
3
T10
Concorrência
1
0
0
T11
Recursos de segurança
1
0
0
T12
Acessível por terceiros
1
0
0
T13
Requer treinamento especial
1
0
0
Tfactor
19,5
Pontos por Caso de Uso


Passo 5: Cálculo do TCF (Technical
Complexity Factor)
TCF = 0.6 + (0.01  Tfactor)
No caso do exemplo:
TCF = 0.6 + (0.01  19.5) = 0.795
Valores já calculados: UUCP = 222, Tfactor = 19.5, TCF = 0.795
Pontos por Caso de Uso

Passo 6: Cálculo do
Efactor

Para cada requisito
listado na tabela, deve
ser atribuído um valor
que determina a
influência do requisito
no sistema, variando
entre 0 e 5;
Fator
Descrição
Peso
E1
Familiaridade com RUP ou
outro processo formal
1.5
E2
Experiência com a aplicação
em desenvolvimento
0.5
E3
Experiência em Orientação a
Objetos
1
E4
Presença de analista
experiente
0.5
E5
Motivação
1
E6
Requisitos estáveis
2
E7
Desenvolvedores em meioexpediente
-1
E8
Linguagem de programação
difícil
2
Pontos por Caso de Uso

No caso do exemplo:
Fator
Descrição
Peso Influência
E1
Familiaridade com RUP ou outro
processo formal
1.5
5
7.5
E2
Experiência com a aplicação em
desenvolvimento
0.5
0
0
E3
Experiência em Orientação a Objetos
1
5
5
E4
Presença de analista experiente
0.5
5
2.5
E5
Motivação
1
5
5
E6
Requisitos estáveis
2
3
6
E7
Desenvolvedores em meio-expediente
-1
0
0
E8
Linguagem de programação difícil
2
0
0
Efactor
26
Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26
Resultado
Pontos por Caso de Uso


Passo 7: Cálculo do ECF (Environmental
Complexity Factor)
ECF = 1.4 + (-0.03  Efactor)
No caso do exemplo:
ECF = 1.4 + (-0.03  26) = 0.62
Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26, ECF = 0.62
Pontos por Caso de Uso


Passo 8: Cálculo dos UCP (Use Case Points)
UCP = UUCP  TCF  ECF
No caso do exemplo:
ECF = 222  0.795  0.62 = 109.42 ou
109 Use Case Points
Valores já calculados: UUCP = 222, TCF = 0.795, ECF = 0.62
Pontos por Caso de Uso

Passo 9: Cálculo do tempo de trabalho
estimado


Para simplificar, utilizaremos a média de 20
horas por Ponto de Casos de Uso
No caso do exemplo:
Tempo estimado = 109 * 20 = 2180 horas de trabalho
Valores já calculados: UCP = 109
Estimativa de Custo de
Desenvolvimento




O custo da hora-desenvolvimento varia de
acordo com a especialização do profissional
que irá realizar a tarefa.
Para analistas, este valor se situa entre 80 e
100 reais por hora.
Para programadores, entre 30 e 60 reais a
hora.
Na média, para horas de desenvolvimento
de cada caso de uso, pode-se considerar R$
50,00
Estimativa do Custo de
Desenvolvimento.



É obtida a partir da multiplicação do número
de casos de uso estimados, pelo valor médio
da hora de desenvolvimento.
Exemplo: para um sistema de 300 UCP,
teríamos:
300 * 50,00 = 15.000,00
Assim neste caso teríamos um custo de
desenvolvimento de R$ 15.000,00 (quinze
mil reais)
Estimativa do Custo de
Desenvolviemtno


Para cada empresa que desenvolve
software, estes valores devem ser ajustados
em função do que realmente ocorreu nos
projetos já terminados e entregues ao
usuário.
Com o tempo, pode-se chegar a estimativas
da proporcionalidade do envolvimento de
programadores e analistas no projeto,
fazendo-se cálculos mais realistas.
Estimativa de Custo do
Projeto

Devem ser somados todos os custos
envolvidos, desde o início do projeto até o
seu final:





Custo de treinamento
Custo de hw
Custo do sw de apoio (licenças de BD,
Ferramenta CASE, etc.)
Custo do desenvolvimento
Outros
Conclusões - UCP



Devido à amplitude do assunto
tratado, vários temas não foram
abordados;
O método de Use Case Points parece
ser muito bom para quem precisa de
dados de estimativa em um curto
espaço de tempo;
Tanto APF quanto PCU são métricas
muito subjetivas;
Conclusões - UCP


É evidente o problema de que a
granularidade de cada caso de uso
varia muito entre analistas, causando
uma significativa variação nos
resultados de PCU;
As métricas específicas para OO
apresentadas servem mais para
controle de qualidade do que para
cálculo de tamanho.
Análise de Pontos por Função
Medir o software através da quantificação da
funcionalidade solicitada e adquirida pelo cliente,
tendo como base primária o projeto lógico

Medir o desenvolvimento e manutenção de
software independentemente da tecnologia utilizada
na implementação

Medir o desenvolvimento e manutenção de
software consistentemente em todos os projetos e
organizações

Mudanças nos Requisitos
Aplicativo
Entregue
Projeto
Funcional
Requisitos
100 PFs
120 PFs



Impacto
Esforço
Cronograma
Custo
Tela de entrada do
código do estado
alterada (3 PFs)
Acrescentada
interface arquivo
N&A (10 PFs)
Consulta N&A e ao
código do estado
acrescentadas (7
PFs)
+ 1 mês
+ 2 semanas
+ $5000
Projeto
Detalhado
130 PFs
• Nova tabela legal
acrescentada (10
PFs)
+ 0.5 meses
+ 2 semanas
+ $2500
135 PFs
• Relatório resumo
incluído (5 PFs)
+ 0.25 meses
+ 2.5 dias
+ $1250
Como Contar Pontos de Função
Telas
Relatórios
Arquivos
Mestres
Tamanho
Arquivos de
Controle
Arquivos de
Referência
Sinais
Passos na Contagem de PF







Determine o Tipo de Contagem
Identifique o Escopo da Contagem e a
Fronteira da Aplicação
Conte as Funções de Dados
Conte as Funções Transacionais
Determine os Pontos de Função Não
Ajustados
Determine o Fator de Ajuste
Calcule os Pontos de Função Ajustados
Visão Geral da APF:
O Que é Contado
EE
P1
Atualizar Arquivo
Mestre
SE
P2
ALI
Arquivo
Mestre
Produzir Relatório
Relatório
Resumo
Semanal
Semanal
Fronteira
Chave
Detalhes
P3
Detalhes Arquivo
Mestre
Arquivo
Referência
em
Outro
Sistema
CE
do
AIE
Sistema
Tamanho Funcional
(Não Ajustado)
Tipo de Função
Baixa
Média
Alta
EE
x3
x4
x6
SE
x4
x5
x7
CE
x3
x4
x6
ALI
x7
x 10
x 15
AIE
x5
x7
x 10
Diagrama de Funções
Fronteira da Aplicação
Entrada Externa
Saída Externa
Consulta Externa
Aplicativo
Arquivo
Lógico
Interno
Arquivos de
Interface Externa
Entrada Externa
Saída Externa
Consulta Externa
Outros
Aplicativos
Determinação de Pontos de Função Brutos
Tipo de Complexidade
Função Funcional
ALIs
4
0
0
Complexidade
Total do
Tipo
de função
Total
Simples X 7 =
Média X 10 =
Complexa X 15 =
28
0
0
28
AIEs
4
0
0
Simples X 5 =
Média X 7 =
Complexa X 10 =
20
0
0
20
EEs
4
2
1
Simples X 3 =
Média X 4 =
Complexa X 6 =
12
8
6
26
SEs
4
2
0
Simples X 4 =
Média X 5 =
Complexa X 7 =
16
10
0
26
CEs
5
0
0
Simples X 3 =
Média X 4 =
Complexa X 6 =
15
0
0
15
Total de Pontos de Função Brutos = 115
Determinação do Fator de Ajuste
O FA (Fator de Ajuste) é baseado em 14
características gerais de sistema que determina a
funcionalidade geral da aplicação que está sendo
contada.
O nível (grau) de influência varia de 0 a 5.
0 - Nenhuma influência
1 - Influência mínima
2 - Influência moderada
3 - Influência média
4 - Influência significante
5 - Influência forte
Variação máxima de 35 %
Características Gerais de Sistema
1. Comunicação de Dados
2. Processamento de Dados Distribuído (Funções Distribuídas)
3. Performance
4. Configuração do equipamento
5. Volume de Transações
6. Entrada de Dados On-Line
7. Interface com o usuário
8. Atualização On-Line
9. Processamento Complexo
10. Reusabilidade
11. Facilidade de Implantação
12. Facilidade Operacional
13. Múltiplos Locais
14. Facilidade de mudanças.
Procedimento


Classificar os quatorze itens de acordo o
nível de influência.
Aplicar a fórmula


FA = (NI * 0,01) + 0,65
Variação de 0,65 até 1,35
Determinação dos Pontos de Função
Ajustados

Para desenvolvimento


PFD = (PFB + PFC) * FA
Onde:



PFD - Ponto de Função de Desenvolvimento
PFC - Ponto de Função de Conversão
FA - Fator de Ajuste
Para manutenção
PFM = [(INC + ALT + PFC) * FAD] + (EXC * FAA)
Onde:
PFM - Pontosde função do projeto de manutenção
INC - Ponto de função brutos que foram incluídos na aplicação pelo
projeto de manutenção.
ALT - Ponto de função que foram alterados na aplicação pelo projeto
de manutenção.
PFC - Ponto de função que foram adicionados pelo processo de
conversão.
FAD - Fator de ajuste da aplicação depois do projeto de
manutenção.
EXC - Ponto de função brutos que foram excluídos da aplicação pelo
projeto de manutenção.
FAA - Fator de ajuste da aplicação antes do projeto de manutenção.
Para cálculo de uma aplicação
PFA = [(PFB + INC + ALTD) - (ALTA + EXC)] * FAD
Onde:
PFA - Ponto de Função Ajustados da aplicação
PFB - Ponto de Função Bruto da Aplicação antes do projeto de manutenção
INC - Pontos de função brutos que foram adicionados pelo projeto de
manutenção.
ALTD - Pontos de função brutos correspondentes às funções que sofreram
alteração durante o projeto de manutenção. Este número reflete as funções
depois da manutenção.
ALTA - São os Pontos de função brutos correspondentes às funções que
sofreram alteração durante o projeto de manutenção. Esse número reflete as
funções antes da manutenção.
EXC - Pontos de função brutos correspondentes às funções que foram
excluídas da aplicação pelo projeto de manutenção.
FAD - Fator de ajuste da aplicação verificado depois do projeto de
manutenção.
Gerenciando Mudanças nos Requisitos
Aplicativo
Entregue
Requisitos
100 PFs
Projeto
Funcional
120 PFs
Projeto
Detalhado
130 PFs
135 PFs
Quadro comparativo:
APF X PCU
APF
PCU
Mais antiga e mais utilizada no mundo
Relativamente nova e pouco utilizada
Padrão internacional desde 2002
Ainda não alcançou o nível de padronização
e nem foi incorporada em ferramentas
populares
Não requer o uso de notação padrão, mas é
baseada no modelo funcional e independente Baseada no modelo de casos de uso
de tecnologia
Largamente discutida na literatura
Tem aumentado o uso e a publicação de
estudos na literatura
É suportada pelo IFPUG e diversos grupos
Ainda não possui
nacionais de usuários e bases históricas de
produtividade
medidas realizadas
bons
históricos
de
Possui regras de contagem padronizadas
Há dúvidas de qual o nível apropriado de
detalhe que cada caso de uso deve possuir
Alto nível de maturidade
Em fase de amadurecimento
Oferece treinamento e certificação
Ainda
não
certificação
oferece
treinamentos
e
Tipos de Métricas
Características
Linha de
Código
1. Independência de
tecnologia
Não
Sim
Sim
Casos
de Uso
Sim
2. Produção de
resultados
consistentes
3. Avaliação por
usuários sem
conhecimento de PD
4. Significância para
o usuário final
Sim
Sim
Sim
Sim
Não
Não
+-
Sim
Não
Não
Sim
Sim
Não
Não
Sim
Sim
5. Utilizado em
estimativas
Sistema Pontos p/
Halstead Função
Exemplos de Aplicações
Aplicação
PF
1. Produtos de Software
Ferramenta CASE IEF (Texas) 20.000
Compilador Visual Basic (MS) 3.000
3.500
SGBD IMS (IBM)
Gerenciador de TP CICS (IBM) 2.000
Word 7.0 (Microsoft)
2.500
Excel 6.0 (Microsoft)
2.500
Aplicação
PF
2. Sist. Comerciais Diversos
Imposto de Renda Pessoal
Contabilidade Geral
Processamento de Pedidos
Recursos Humanos
Suporte a Vendas
Preparação de Orçamento
2.000
1.500
1.250
1.200
975
750
Região Impossível
Custo do Esforço
Evitando a Região Impossível
Região Impossível
(75% de Td)
Td
To
Tempo de Desenvolvimento
Observações:
1) Td é o tempo ótimo de desenvolvimento.
2) To é o tempo que acarreta o menor custo.
3) To = 2 Td.
4) É impossível terminar em menos que 0,75 * Td.
Os 7 Pecados Capitais¹
•
•
•
•
•
•
Falta de Comunicação (com o seu pessoal)
Confiança Cega (no parceiro)
Cinismo e Desconfiança (com o parceiro)
O Contrato é “a Bíblia” (falta de flexibilidade)
“Ir Dormir Aborrecido” (fazer bola de neve)
Má Prática de Métricas (ambas as partes
devem entender os critérios)
•
Cobiça e Oportunidade
(explorar falhas do
contrato)
¹ Dekkers, C., Management of Outsourcing: How to Avoid Common
Mistakes, Software Management Conference, San Jose, February 2000
O Oitavo Pecado¹
Comprar os seus sapatos com
base no tamanho médio do pé
do brasileiro
¹ Aguiar, M., Contratando o Desenvolvimento com Base em
Métricas, Developers Magazine, setembro de 2000.
Obtenha Suas Próprias Medidas através de
um Programa de Métricas
IFPUG
e
BFPUG
BFPUG