Buscando na web, encontrei um artigo bacana escrito por José Carlos Macoratti no qual estarei abaixo compartilhando com vocês com o consentimento do próprio autor.

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? ou Quanto você cobra para desenvolver este sistema?

Qual o prazo de entrega do sistema? ou 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?

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 idéia. 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

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

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 idéia 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]

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.