 Quanto vale o software que você 
produz ?
 
Quanto vale o software que você 
produz ?
|  | Se você é um desenvolvedor de software , quer como consultor independente quer trabalhando em uma empresa de desenvolvimento de software , com certeza já ouviu muitas vezes as seguintes indagações : | 
Quanto custa o 
desenvolvimento deste sistema ?  
Quanto você cobra para desenvolver este 
sistema ?  
Qual o prazo de 
entrega do sistema ? 
Quanto tempo você leva para desenvolver este sistema ?
Isto é perfeitamente normal e previsível , afinal um cliente tem o direito de saber quanto vai custar e em quanto tempo vai ficar pronto o produto que ele deseja receber.
O que não é normal é o fato de que mesmo convivendo com estas indagações no seu dia dia a tanto tempo , você , quer como gerente de projeto ou desenvolvedor , não ter condições de responder com segurança a nenhuma delas.
Quando você contrata o serviço de um pedreiro, ele, após saber exatamente o que tem que fazer faz alguns cálculos e lhe da o preço final do seu trabalho. O mesmo ocorre nas áreas de engenharia civil , mecânica , etc.
Por que é tão difícil estimar o valor de um projeto de software ? Por que é tão complexo fazer estimativas nesta área ?
Seria porque software não têm peso, nem cheiro ? ou seria o fato de que não vemos e nem sentimos um software ?
Creio que as respostas a estas indagações seriam feitas se você soubesse responder a seguinte pergunta:
 Qual o tamanho 
do sistema?
 
Qual o tamanho 
do sistema?  
Para saber o tamanho do sistema é necessário realizar medições ou medidas. Certo ?
Certo, pois, "não se consegue controlar o que não se consegue medir". (Tom DeMarco)
A métrica é o número que você vincula a uma ideia.
Para o projeto de software comum , os aspectos quantitativos onde mais precisamos usar a métrica são: escopo, tamanho, custo, risco e tempo empregado.[1]
Para que a métrica usada seja útil ela deve possuir as seguintes características: ser mensurável , ser independente, ser explicável e precisa.
Creio que agora você concorda em que há fortes motivos para medir o seu sistema , dentre estes motivos temos:
Fornecer subsídios para determinar o esforço, os recursos, a duração e os custos de desenvolvimento
Avaliar a produtividade do processo de desenvolvimento adotado
Formar uma base histórica para embasar estimativas futuras
Indicar a qualidade do produto
Então qual a medida que você deve usar para determinar o tamanho do seu sistema ?
 Tipos de medidas de tamanho de 
software
Tipos de medidas de tamanho de 
software
1- SLOC - linhas de código
Medir software contando as linhas de código (SLOC) é uma das medidas mais antigas para determinar o tamanho, esforço e produtividade no desenvolvimento de software.
È muito fácil de usar e aplicar; basta contar a quantidade do número de linhas de código de um programa.
A medida de SLOC é considerada uma medida física do tamanho de software por medir o volume de código-fonte de um programa.
Ela tem no entanto as seguintes desvantagens :
Depende da linguagem de programação usada (o número de linhas de um programa Cobol é totalmente diferente de um em Java)
Ausência de padrões de contagem. (Cada linguagem possui suas características de sintaxe e semântica)
Não pode ser aplicada nas fases iniciais de desenvolvimento (No início o programa ainda não esta escrito)
Nota: No site http://sunset.usc.edu/research/COCOMOII/ você pode fazer o download de um aplicativo demo da Softstar para realizar estimativas de tamanho usando SLOC.
 2- 
APF - Análise de Pontos por função
2- 
APF - Análise de Pontos por função
Podemos dizer que atualmente á a técnica mais usada para medir o tamanho de projetos de software. Foi criada por Alan Albrecht na IBM na década de 70 e consiste em determinar o tamanho funcional (o que é entregue) do sistema através da visão do usuário.
Ela possui as seguintes vantagens:
Independe da tecnologia utilizada
É simples de usar e ser entendida pelo usuário e desenvolvedores
é consistente e intercambiável
Pode ser utilizada desde o início do sistema.
A APF (Análise de Pontos por Função) pode ser vista como um técnica que permite dimensionar o tamanho de um software a ser desenvolvido , melhorado ou adquirido; e também um técnica para realizar estimativas de custo e recursos para o desenvolvimento e manutenção de software.
A utilização da APF esta normalizada em um manual de contagem de pontos de função da IFPUG (International Function Point Users Group) constituída em 1996.
Obs: O chapter do IFPUG no Brasil é o BFPUG - Brazilian Function Point Users Group. (Constituído em 1998)
O esquema do processo de contagem de pontos por função é dado na figura abaixo:
| 
 | 
Para que você tenha uma ideia dos PF como medida de volume de software abaixo é apresentada uma tabela que mostra o tamanho aproximado de algumas aplicações tipos em pontos por função.[2]
| Aplicação | PF | Aplicação | PF | 
| 1. Produtos de Software | 
 | 2. Sist. Comerciais Diversos | 
 | 
| Ferramenta CASE IEF (Texas) | 20.000 | Imposto de Renda Pessoal | 2.000 | 
| Compilador Visual Basic (Microsoft) | 3.000 | Contabilidade Geral | 1.500 | 
| SGBD IMS (IBM) | 3.500 | Processamento de Pedidos | 1.250 | 
| Gerenciador de TP CICS (IBM) | 2.000 | Recursos Humanos | 1.200 | 
| Word 7.0 (Microsoft) | 2.500 | Suporte a Vendas | 975 | 
| Excel 6.0 (Microsoft) | 2.500 | Preparação de Orçamento | 750 | 
| MS Project (Microsoft) | 3.000 | 
 | 
 | 
Eu não vou dar detalhes sobre como usar o manual de contagem mas vou dar um exemplo de como você pode usar o resultado obtido usando a APF para estimar esforço , prazo e custo de um software.
Vamos supor que você foi consultado sobre o desenvolvimento de um sistema cadastro de clientes onde é possível realizar as seguintes tarefas:
Listagem por ordem alfabética
exportar o cadastro para outro sistema via arquivo texto
Usando o manual de contagem da APF teríamos:
ALI - 01 ( o arquivo de clientes )
AIE -  0 
EE -  01 ( inclusão de cliente )
SE -  01 ( listagem por ordem alfabética )
CE -  01 ( exportar arquivo texto)
Se considerarmos todos os tipos de função como de complexidade Baixa teremos:
Pontos de função Brutos não ajustados :
PFB = ALI x 7 + AIE x 5 + EE x 3 + SE x 4 + CE x 3 = 1 x 7 + 0 x 5 + 1 x 3 + 1 x 4 + 1 x 3 = 17
Contando os fatores de ajustes teremos um total igual a 45.
Valor de fator de ajuste :
VFA = 0,65 + (0,001 x 45 ) = 1.1
Valor dos pontos de função Ajustados:
PFA = VFA x PFB = 1,1 x 17 = 18,7
Pronto !
Usando APF chegamos ao tamanho do sistema.
O seu tamanho é 18,7 pontos por função.
E agora ?
Nota: Dizer que o tamanho de um projeto é de 1000 PF nada significa. Quando podemos comparar medidas feitas em APF é que as coisas começam a fazer sentido. Assim se temos dois projetos , um com 1000 PF e outro com 2000 PF, podemos concluir que o segundo temo o dobro do tamanho do primeiro.
Assim como dizer que uma construção possui 400 metros quadrados de área construída não nos permite estimar , apenas levando em conta esta medida , valor da mesma; dizer que um projeto possui 3000 PF também não nos dá a idéia do custo do projeto.
Agora podemos estimar esforço , prazo e custo. Para isto iremos usar as seguintes considerações:
1- Considerando que uma produtividade média de 10 hs / PF.
2- Considerando que a média de jornada de trabalho é de 6 horas.
3- Considerando que o valor de uma hora de trabalho é de R$ 25,00.
Concluímos que :
Esforço = 10hs / PF = 10 x 18,7 = 187 horas
Prazo = 187 h / ( 4 x 6 ) = 7,8 dias
Custo = 187 h x R$ 25,00 = R$ 4.675,00
Foram usadas as seguintes fórmulas:
Produtividade no desenvolvimento = Horas 
por PF
Esforço de desenvolvimento = Produtividade(H/PF) * Tamanho(PF)
Custo de software = Tamanho (PF) * Custo(R$/PF)
Neste artigo procurei abordar de forma simples e objetiva a importância da utilização de métricas no desenvolvimento de projetos software com a finalidade de realizar estimativas.
A métrica de software e suas implicações é um assunto muito vasto que você poderá pesquisar nos links dos sites indicados e também em:
NESMA -
http://www.nesma.nl/english/nesma&ifpug.htm
COCOMO -
http://www1.jsc.nasa.gov/bu2/COCOMO.html
FATHO - 
http://www.fattocs.com.br/
Aplicativo para auxiliar na contagem APF -
http://www.bsb.netium.com.br/mecenas/apf.htm
Por enquanto lembre-se sempre que :
"Se você não sabe para onde deseja ir, um mapa não vai lhe ajudar."
Referências
	[1] - DeMarco, Tom - Controle de 
projetos de Software - Editora Campus, 1991. 
[2] - Jones, Capers - Estimating Sofware Costs - McGraw-Hill, 1998. Veja também
	www.spr.com site da empresa do autor.