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