bfpug_new.jpg (7052 bytes)Brazilian Function Point Users Group

A UTILIDADE DOS PONTOS DE FUNÇÃO

(Originalmente publicado em American Programmer)

 

Utilizando Pontos de Função para Ajudar a Definir Quando e Onde Fazer Reengenharia

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.

  1. Como identificamos aplicativos que devem ser objeto de reengenharia?
  2. 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.wpe6.jpg (18588 bytes)

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.  .