|
Introdução
A Análise de Pontos de
Função ou FPA (Function
Point Analysis) surgiu em
1979 como resultado de
projetos desenvolvidos pela
IBM. Em 1984, tornou-se
reconhecida mundialmente e
passou a ser de domínio
publico da comunidade e
indústria de softwares em
todo o mundo.
A APF (Análise de Pontos de
Função) compõe-se de um
conjunto de técnicas criadas
com o objetivo de medir
funcionalidades de um
software do ponto de vista
do usuário. Assim sendo, a
APF é uma unidade de medida
dessa técnica que para fins
práticos, não tem relação
direta com a tecnologia
utilizada na construção ou
desenvolvimento de
softwares.
No contexto de um
desenvolvedor, seja uma
pessoa física ou uma
empresa, a AFP torna
possível mensurar o tamanho
do software; o que, por sua
vez, traz excelentes
indicadores na gestão de
projetos sob esse cenário.
O órgão responsável pela
manutenção e divulgação das
diretrizes da APF é o IFPUG
( International Function
Point Users Group -
http://www.ifpug.org/),
através do Manual de
Práticas de Contagem de
Pontos de Função – CPM
(Counting Practices Manual).
No Brasil, o BFPUG (Brazilian Function Point
Users Group -
http://www.bfpug.com.br/) é
o representante oficial da
IFPUG.
Neste artigo, não serão
apresentadas as técnicas
globais da APF para a gestão
de projetos de software. Mas
sim, uma visão geral de sua
proposta enquanto métrica
baseada em padrões e
benefícios que a mesma é
capaz de prover.
Objetivos
“Não é possível gerenciar
adequadamente aquilo que não
temos como medir”
Em linhas gerais, a
engenharia de software,além
de ser uma nova ciência, é
vasta em processos e
técnicas capazes de prover
instrumentos de medidas ao
processo de desenvolvimento
de softwares.
Para um cenário de gestão de
projetos de softwares,
devemos ter em mente que o
“tamanho” do software é um
fator essencial para a
determinação do esforço
necessário a sua construção.
Por conseguinte, sabendo o
seu tamanho, melhores serão
as possibilidades de uma
estimativa dos parâmetros de
esforço, tempo e custo mais
adequadas a realidade dos
projetos envolvendo
sistemas.
São essas as diretrizes que
buscaremos através da
utilização da AFP. Porém,
devo ressaltar que esse
padrão não mede diretamente
os indicadores citados acima
; o tamanho do software,
obtido com o auxílio da APF
e em conjunto a outras
variáveis, é que nos serão
relevantes a uma estimativa
mais precisa da
produtividade, esforço e
custo, insumos estes, de
fundamental importância a
uma gestão de projetos mais
coerente e realista.
Principais Issues Associados
a Projetos de Softwares
Além da dificuldade em
termos medidas
generalizadas, globais e
específicas, importantes na
previsão de estimativas
eficientes para a gestão de
projetos de softwares,
outros fatores podem ser
elencados como variáveis a
este denso universo.
São eles:
• A engenharia de projetos
ainda é uma ciência nova;
• Existem falhas naturais
aos próprios processos da
gestão de projetos, que
também são recentes e de
conhecimento restrito;
• As técnicas disponíveis
são complexas e não
universais;
• O desenvolvimento de
sistemas ainda é uma arte
(Estado de);
• Os
analistas-desenvolvedores
são otimistas natos;
• Prazos de confecção e
entrega sofrem franca
pressão política e
comercial.
Razões para Uso da FPA
Conforme os itens descritos
acima e apesar do universo
do desenvolvimento de
softwares e sua gestão sob o
foco de projeto serem de
grande complexidade, a APF
nos traz enquanto recurso,
um conjunto de abordagens
baseadas em padrões
pré-estabelecidos e que
“independem” tanto da
complexidade do software
quanto da forma com a qual é
desenvolvido.
Podemos assim, citar como
razões para o seu uso:
• Ser uma unidade de medida
padrão para softwares;
• Ser uma técnica que provê
recursos de estimativa de
software;
• Ser independente da
tecnologia e ferramentas de
modelagem/desenvolvimento/construção;
• Ser de simples assimilação
e empregabilidade ;
• Possuir métricas não
técnicas, transparentes e
inteligíveis a todos os
envolvidos no projeto
(Stakeholders);
• Possuir escalabilidade, ou
seja, poder ser utilizada no
início ou em qualquer fase
do processo de
modelagem/construção/desenvolvimento
e manutenção do sistema em
questão;
• Ser consistente e
intercambiável, podendo
atuar em conjunto a outras
métricas.
Considerações Gerais Acerca
da Utilização da FPA em
Projetos de Softwares
A gestão de projetos de
softwares para ser
devidamente efetivada,
necessita do auxílio de um
conjunto de métricas
eficientes que permitam uma
mensuração mais realista
possível das estimativas de
prazos, custos e recursos.
É muito importante sabermos
como obter uma definição
clara do que APF pode nos
trazer para uma medida
eficiente dos aspectos de
produtividade na
modelagem/desenvolvimento de
sistemas.
Vejamos, em linhas gerais,
como podemos definir a
produtividade de sistemas:
|
Produtividade =
Medida do(s)
Produto(s) do
Trabalho
Esforço(s) em
Produzi-lo
|
No intuito de
minimizarmos eventuais
distorções é importante que
a medida do produto do
trabalho seja padronizada e
uniforme para tarefas iguais
ou similares. Não obstante,
o ideal é que o esforço seja
medido em termos de alocação
exclusiva ao(s) trabalho(s)
em questão.
Esse é um dos principais
obstáculos que nos deparamos
nos projetos de
desenvolvimento, manutenção
e expansão de sistemas.
Diante disso, é
imprescindível para a
objetividade dos resultados
(produtividade) que sejam
adotadas unidades de medidas
padronizadas e uniformes na
definição do tamanho de um
projeto.
Por essas razões, a APF em
sua essência, provê o
conjunto de técnicas e suas
respectivas métricas
plenamente associado ao
alcance desse resultado.
Benefícios decorrentes do
Uso da APF
De acordo que o que fora
apresentado até o presente
momento, podemos então
destacar uma grande
diversidade de benefícios
decorrentes da
aplicabilidade da APF.
Dentre os quais, pode-se
citar:
• Atuar como agente de
suporte na análise de
produtividade e qualidade de
sistemas, associada a outras
métricas ;
• Servir como apoio no
gerenciamento de projetos de
software, em quaisquer de
suas fases;
• Servir como instrumento
apontador de quantitativo de
recursos a serem alocadas
para a
modelagem/desenvolvimento e
posterior manutenção dos
produtos gerados;
• Ser utilizada ,sob
diferentes abordagens em
todas as fases de projetos
de sistemas;
• Servir como instrumento de
apoio a gerência de
requisitos durante todo o
projeto, apontando variações
de escopo incontestáveis e
auxiliando aos Gerentes de
Projetos junto aos clientes;
• Prover aos usuários e
gestores de TI a
visibilidade dimensional dos
pacotes e contribuir para
decisões estratégicas de
desenvolvimento próprio ou
outsourcing;
• Servir como ferramenta
auxiliar na negociação de
contratos junto aos seus
gestores ;
• Atuar como indicador
global ao cálculo de preço
de mercado para os produtos
a serem comercializados;
• Atuar como fator
contributivo a um
Benchmarking com sistemas de
mesma familiaridadee compor
base de conhecimento
organizacional de projetos
de sistemas.
Links para Aprofundamento e
Pesquisa
• Practical Software and
Systems Measurement - PSM
http://www.psmsc.com/
• PMI Information Systems
Special Interest Group
http://www.pmi-issig.org/
• Development Support Center
http://www.functionpoints.com/
• Software Productivity
Consortium
http://www.software.org/ssci/default.asp |
