A UTILIDADE DOS PONTOS DE FUNÇÃO
(Originalmente publicado em American
Programmer)
Muitos projetos de reengenharia são conduzidos sem nenhuma
análise de custo / benefício. A análise de custo / benefício procura a melhor razão
entre os benefícios e os custos; isto significa, por exemplo, encontrar os aplicativos
que mais se beneficiarão dos esforços de reengenharia. Para determinar quais aplicativos
mais se beneficiarão da reengenharia, duas perguntas devem ser feitas.
- Como identificamos aplicativos que devem ser objeto de
reengenharia?
- Como calculamos os benefícios potenciais do esforço de
reengenharia?
Identificando aplicações para reengenharia
Uma vez que uma organização tenha completado uma linha de
base (estabelecido o número de pontos de função) de todos os aplicativos em produção,
as horas de manutenção por ponto de função podem ser calculadas para cada aplicativo.
Horas de manutenção por ponto de função podem ser representadas em um gráfico
semelhante ao mostrado abaixo. Ao longo do eixo dos x está o tamanho (medido em
pontos de função) e, sobre o eixo dos y, as horas de manutenção por ponto de
função. Os pontos representam cada aplicativo medido.
No canto superior direito, estão aqueles aplicativos que
são ao mesmo tempo grandes e caros de manter por ponto de função. Esses são os
aplicativos que deveriam ser objeto de projetos de reengenharia. Isto é, esses
aplicativos são os que fornecerão o maior retorno por dólar investido. Após a
realização da reengenharia, a taxa de Horas de Manutenção / Pontos de Função deveria
ser reavaliada, e o gráfico redesenhado. As Horas de Manutenção por ponto de função
desses aplicativos que passaram pela reengenharia deverão cair, passando-os para o
quadrante inferior direito do gráfico.
Estimando benefícios (calculando o retorno)
Poucas informações são necessárias para estimar os
benefícios de um projeto de reengenharia. Tais informações incluem as horas de
manutenção atuais por ponto de função, as horas de manutenção por ponto de função
esperadas após o projeto de reengenharia e o período de retorno desejado. Por exemplo,
seja um aplicativo com 1.000 pontos de função e 10 horas de manutenção por ponto de
função. O valor desejado, para que o aplicativo passe para o quadrante inferior
direito, é 8 horas de manutenção por ponto de função. Isto é, o projeto de
reengenharia deveria reduzir o custo de manutenção em 2 horas por ponto de função. Se
o período de retorno desejado for um ano, então o projeto de reengenharia não deveria
levar mais de 2.000 horas. De forma mais simples, 2.000 horas é a diferença entre as
horas de manutenção por ponto de função antes e depois (2 neste caso), multiplicadas
pelo número de pontos de função (1.000 neste caso).
A mesma análise acima efetuada pode ser executada para
comparar os custos das melhorias aos de desenvolvimento. É um truísmo dizer que os
dólares de melhoria por ponto de função deveriam ser menores que os dólares de
desenvolvimento por ponto de função. Se os dólares de desenvolvimento por ponto de
função fossem inferiores aos de melhoria, isso significaria que seria mais barato
desenvolver um novo aplicativo do que melhorar o existente.
Utilizando Pontos de Função para
Estimar Casos de Teste
Muitas tentativas têm sido feitas para estabelecer uma
relação entre pontos de função e o esforço associado ao desenvolvimento de software.
Grande parte da dificuldade no estabelecimento desta relação é devida ao fato de ser
examinado apenas o relacionamento entre os pontos de função e o ciclo de vida inteiro do
software. Esta seção aborda o relacionamento entre os pontos de função e a atividade
de teste - em particular, a relação entre casos de teste e pontos de função.
A relação entre pontos de função e o número de casos de
teste é muito forte. Capers Jones estima que o número de casos de teste é
aproximadamente igual ao número de Pontos de Função elevado a 1,2 (PF 1,2).
Isto é, os casos de teste crescem a uma taxa mais rápida do que os pontos de função.
Este é um fato intuitivo, porque conforme um aplicativo cresce, os interrelacionamentos
nele contidos tornam-se mais complexos.
Por exemplo, se um aplicativo em desenvolvimento tiver 1.000
pontos de função, deverão existir aproximadamente 4.000 casos de teste. Obviamente, a
equipe de desenvolvimento deveria começar a criar os casos de teste tão rapidamente
quanto possível. Se a equipe esperar até que a codificação tenha terminado,
provavelmente serão criados muito menos do que 4.000 casos de teste.
Entendendo o Potencial de Defeitos
O número de defeitos está relacionado ao número de
resultados possíveis. Este número está relacionado ao número de casos de teste. Há um
grande benefício em estimar o número de casos de teste. Entender o número de casos de
teste leva à análise lógica de comparar os casos reais com os esperados. Se os casos
reais forem em quantidade inferior à esperada, a cobertura de testes será inadequada. A
cobertura de testes é uma indicação direta dos defeitos potenciais e custos futuros com
manutenção. Quão maior for a distância entre a quantidade esperada e a real de casos
de teste, maior o potencial de defeitos não detetados durante a respectiva fase de
testes.
O que se segue é um princípio básico da qualidade de
software: o único caminho para elevar a qualidade do software em produção é se e
somente se todo o software migrado para a produção for de qualidade superior ao software
atualmente em produção. É importante entender tanto os defeitos potenciais do software
de produção, quanto os defeitos potenciais do novo software. Pode ser impossível
estimar o número de defeitos embutidos no software atualmente em produção, mas é
possível estimar o potencial de defeitos para cada nova versão do software. A diferença
nas quantidades real e estimada dos casos de teste é um bom indicador do potencial de
defeitos..
Utilizando Pontos de Função para
Ajudar a Entender Faixas de Produtividade Amplas
Taxas de produtividade inconsistentes entre diferentes
projetos podem ser uma indicação de que não está sendo seguido um processo padrão. A
produtividade é definida como a razão entradas / saídas. No caso de software, a
produtividade é definida como a quantidade de esforço requerida para entregar um certo
conjunto de funcionalidades (medidas em pontos de função).
Muitas organizações sofrem de taxas de produtividade
variando em mais ou menos 100 por cento. Isto é verdade mesmo quando essas organizações
contam os pontos de função corretamente e registram consistentemente os tempos gastos.
As organizações reclamam freqüentemente que a análise de produtividade não oferece
retorno. Na maioria das organizações, o software é criado de muitas formas diferentes,
com a utilização de diversos processos (e, em muitos casos, nenhum processo). Se o
software for desenvolvido de maneira inconsistente, as taxas de produtividade também
serão inconsistentes. O mesmo serve para qualquer processo produtivo. Grandes variações
de produtividade entre diferentes projetos indicam que não está sendo seguido um
processo padrão. À medida que as equipes de desenvolvimento se alinham com um processo
padronizado, as faixas de produtividade deverão se estabilizar e tornarem-se mais
consistentes.
Utilizando Pontos de Função para
Ajudar a Entender o Aumento do Escopo
A Análise de Pontos de Função provê um mecanismo para
acompanhar e monitorar o aumento do escopo ("scope creep") de um projeto. As
contagens de Pontos de Função ao fim do levantamento de requisitos, análise, projeto e
implementação podem ser comparadas. A contagem de pontos de função ao final do
levantamento de requisitos e / ou do projeto pode ser comparada com os pontos de função
realmente entregues. Se o número de pontos de função tiver aumentado, pode-se assumir
que o projeto tornou-se mais bem definido, ou realmente cresceu em tamanho. A quantidade
acrescida é um indicador da qualidade do levantamento dos requisitos e / ou de sua
comunicação à equipe do projeto. O aumento do tamanho dos projetos deve ser acompanhado
em todos os casos. Se o grau de crescimento dos projetos decrescer ao longo do tempo, é
natural assumir que houve melhoria na comunicação com o usuário.
Utilizando Pontos de Função para
Ajudar a Calcular o Custo Real do Software
A maioria das organizações calcula o custo do software a
menor, por larga margem. O verdadeiro custo do software é a soma de todos os custos
durante a vida do projeto, incluindo-se aí todos os custos esperados de melhoria e
manutenção. De fato, o cálculo real seria o valor presente de todos os
desenvolvimentos, melhorias e manutenções no decorrer da vida do projeto. Este tipo de
análise demonstra a recompensa de se investir na fase inicial da análise e projeto.
Quanto mais se investir nas fases iniciais, mais será economizado na redução dos custos
de manutenção e melhoria. É importante ser capaz de calcular o custo unitário, a fim
de avaliar o investimento inicial e compará-lo aos gastos futuros. O custo unitário pode
ser em horas / PF ou $ / PF. Os aumentos no investimento inicial deveriam reduzir
proporcionalmente os custos unitários das futuras melhorias e manutenções.
Utilizando Pontos de Função para
Ajudar a Estimar o Custo, Cronograma e Esforço do Projeto
O sucesso nas estimativas com a utilização de pontos de
função baseia-se em diversas técnicas de estimativa: De Cima Para Baixo
("Top-Down"), Analogia e Opinião de Especialista ("Expert Advice"). A
estimativa De Cima Para Baixo é uma técnica que estima o cronograma inteiro, assim como
o custo e o esforço, utilizando parâmetros de uso genérico. Os parâmetros de uso
genérico e as comparações efetuadas são baseados em dados históricos de benchmark,
com a utilização de técnicas de Analogia. A Opinião de Especialistas pode ser obtida
através de especialistas com experiência em projetos semelhantes ou na utilização de
pontos de função.
A comparação de projetos semelhantes é crítica para o
sucesso nas estimativas. Ao avaliar projetos semelhantes, devem ser efetuadas as seguintes
considerações:
Tipo de Plataforma de Hardware - Mainframe, Client Server, PC
Isolado
Tipo de Linguagem - COBOL, C, C++
Tipo de Projeto - Software Básico, Middleware, Software
Aplicativo
Tipo de Sistema Operacional - MVS, Windows, Unix
Uma vez que tenham sido identificados os projetos
semelhantes, os seguintes dados devem ser coletados:
Taxa de Entrega Histórica (horas por ponto de função) dos
projetos semelhantes
Cronogramas Históricos (duração do cronograma por ponto de
função) dos projetos semelhantes
Custo Histórico (dólares por ponto de função) dos
projetos semelhantes
Uma vez que o tamanho do projeto tenha sido determinado em
pontos de função, as estimativas de horas, custo e cronograma pode ser calculadas. Os
cálculos devem ser efetuados a partir de dados de projetos semelhantes, conforme acima
explanado.
Por exemplo, se for determinado que o tamanho do projeto
atual é 500 pontos de função e que o custo histórico para um projeto semelhante foi
$10 por ponto de função, então o custo total esperado para o projeto seria $10 ($ /
Ponto de Função) x 500 PF = $ 5.000 dólares. Cálculos semelhantes poderiam ser
efetuados para o cronograma, a duração e as horas.
Utilizando Pontos de Função para
Ajudar a Entender os Custos de Manutenção
Muitos orçamentos de manutenção são estabelecidos com
base na performance de anos anteriores. Muitas organizações tentam reduzir os custos de
manutenção e não planejam aumentar seus custos de manutenção de ano a ano, para
nenhum aplicativo em particular. Se a quantidade de nova funcionalidade for determinada e
adicionada ao produto básico, o custo unitário de manutenção pode de fato cair,
enquanto o gasto real permanece constante ou aumenta. Se os custos de manutenção
estiverem crescendo a uma taxa inferior à taxa de crescimento dos pontos de função,
então os custos de manutenção estarão de fato caindo. Por exemplo, se uma
organização gasta $ 100.000 para manter 10.000 pontos de função ($ 10 por ponto de
função), e o número de pontos de função cresce 10 por cento e passa a ser 11.000,
permanecendo constantes os dólares gastos em manutenção, teremos o custo unitário de
manutenção caindo para $ 9 por ponto de função. Muitos executivos de Sistemas de
Informações deixam de compreender este conceito.
Utilizando Pontos de Função para
Ajudar em Negociações Contratuais
Os gerentes de contratos podem utilizar seu conhecimento de
pontos de função para criar e gerenciar projetos com base no preço por ponto de
função, bem como para comparar os preços dos fornecedores. Tais indivíduos estabelecem
a utilização eficaz de terceiros no desenvolvimento, validam propostas com base no
tamanho em pontos de função e podem avaliar o impacto de projetos cancelados.
Os pontos de função podem ser utilizados para ajudar a
especificar os principais produtos a serem recebidos de um fornecedor, para assegurar a
entrega dos níveis adequados de funcionalidade e para desenvolver medidas objetivas de
eficácia em relação ao custo e qualidade. São mais eficazmente utilizados em contratos
de preço fixo, como forma de especificar exatamente o que deve ser entregue. De uma
perspectiva interna, o gerenciamento bem sucedido de contratos de preço fixo depende
completamente da existência de representações acuradas do esforço. A estimativa deste
esforço (ao logo de todo o ciclo de vida) pode acontecer somente quando há a aplicação
de uma métrica normalizada, como é o caso na utilização de pontos de função.
Resumindo, a análise de pontos de função provê o melhor
método objetivo para a avaliação do tamanho de um projeto de software e para o
gerenciamento desse tamanho durante o desenvolvimento. É, por dois motivos, o melhor
método para gerenciar riscos. Primeiro, o cliente (usuário / especificador) pode aceitar
mais facilmente o risco para um dado tamanho de projeto de software (em pontos de
função). Segundo, o desenvolvedor pode aceitar mais facilmente o risco para o custo de
produção (o custo por ponto de função). A adesão a uma forma consistente de contagem
de pontos de função otimiza este relacionamento e facilita o desenvolvimento dentro do
prazo e orçamento estabelecidos.
O estabelecimento de preço para "software externo"
(i.e., projeto para utilização fora da organização) pode ser mais fortemente ligado ao
esforço de produção quando são exigidas métricas funcionais. Se um desenvolvedor de
software sabe exatamente qual o seu custo interno de desenvolvimento de um ponto de
função, ele pode facilmente incorporar a esse custo os algoritmos utilizados para fixar
os preços externos. Sem um claro entendimento do tempo e esforço gastos por ponto de
função, o estabelecimento de preços para pacotes de software vai continuar a ser
difícil.
Utilizando Pontos de Função para
Desenvolver um Conjunto Padrão de Métricas
É claro, os pontos de função precisam ser coletados em
associação com outras medidas. De fato, somente os pontos de função, por si só,
oferecem pouco ou nenhum benefício. Muitas métricas precisam ser reportadas ao nível
organizacional. Por exemplo, tanto métricas de produtividade / custo quanto de qualidade
precisam ser reportadas ao nível da organização. As métricas de Custo / Produtividade
são utilizadas para demonstrar a taxa e o custo da funcionalidade entregue. As métricas
de Qualidade são utilizadas para demonstrar os níveis existentes de qualidade e para
acompanhar os esforços de melhoria no processo de desenvolvimento de software. Tais
métricas devem ser acompanhadas e mapeadas ao longo do tempo.
Métricas de Custo / Produtividade
1. Custo por Ponto de Função: mede o custo
médio para entregar ou manter um ponto de função. Este dado pode ser utilizado para
desenvolver um banco de dados histórico com a finalidade de estimar projetos futuros.
2. Pontos de Função por Mês ou Ano do
Calendário: mede a quantidade média de tempo para entregar um ponto de função à
produção com um dado quantitativo de pessoal.
3. Pontos de Função por Pessoa Mês:
mede o número médio de pontos de função entregue pela aplicação de um mês de
esforço.
Métricas de Qualidade
1. Defeitos por Pontos de Função
Instalados: correlaciona a qualidade do software ao tamanho do aplicativo.
2. Horas de Manutenção por Pontos de
Função Instalados: correlaciona o esforço de suporte ao tamanho do aplicativo, para o
software atualmente instalado, incluindo o legado. Aplicativos com taxas elevadas podem
ser alvo de reengenharia ou substituição.
3. Defeitos por Novos Pontos de
Função Instalados: avalia a qualidade do novo software, para garantir que as melhorias
no processo de entrega estão tendo efeito.
As métricas devem ser indicadores e não medidas exatas de
performance. Elas devem prover granularidade suficiente para mostrar as tendências
gerais, identificar as áreas com problemas e demonstrar progresso. Se a tentativa de
tornar as métricas perfeitas fizer com que elas sejam reportadas dois a três meses
depois de medidas, muito tempo estará sendo gasto com precisão e pouco com ação.
Deve-se evitar tornar as métricas precisas demais.
Resumo
Este artigo começou abordando a utilidade dos pontos de
função. Há muitos usos para pontos de função além de estimar o cronograma, esforço
e custo. Muitos gerentes de projeto não acreditam que os pontos de função possuem
qualquer utilidade. De certa forma, eles estão certos. Muitas organizações estão
utilizando pontos de função e métricas de software para reportar tendências a nível
organizacional. Muitas equipes de projeto enviam dados a um grupo central de métricas e
nunca mais tornam a ver seus dados. Isto é análogo a enviar os dados a um buraco negro.
Se os gerentes de projetos começarem a entender como os pontos de função podem ser
utilizados para estimar casos de teste, calcular custos de manutenção e assim por
diante, eles provavelmente investirão na contagem de pontos de função.
Perguntas ou Comentários? David@softwaremetrics.com
Copyright © 1996-2000 Longstreet Consulting, Inc. All rights reserved. Todos os direitos
reservados.
Traduzido por Mauricio Aguiar, BFPUG. .
|
Brazilian Function Point Users Group