Profissionais TI - Pra quem respira informação

Estive na semana passada discutindo com meus sócios algo que, eu creio, já tenha sido discutido no mínimo uma vez em qualquer empresa de desenvolvimento de software: quanto vale nosso software?

Buscando na web, encontrei um artigo bacana escrito por José Carlos Macoratti, do 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?
• 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?

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.