MODELOS DE ESTIMATIVAS DE SOFTWARE BASEADOS EM DADOS HISTÓRICOS

35Além disso, as variações encontradas nos próprios fatores deconversão publicados por inúmeras organizações no mercado podem chegar a100%! A tabela seguinte apresenta um exemplo dessas variações para a linguagemCOBOL.FonteQuantitative Software ManagementCapers JonesDavid Consulting GroupFator de Conversão (COBOL)77 LOC/PF107 LOC/PF177 LOC/PFTabela de fatores de conversão obtidos do mercado para backfiring em aplicações COBOL.Devido a esses fatores, aplicar backfiring para obter um tamanho empontos de função a partir de linhas de código é uma técnica arriscada e sujeita auma grande margem de erro. Daí, o próprio IFPUG ressalta no FAQ em sua páginana Internet, contagem manual de pontos é inviável na prática e a precisão não sejaum fator crítico. Alguns profissionais advogam que backfiring é uma maneira rápidae barata de obter o tamanho em pontos de função do portfólio de aplicações de umaorganização. Outros argumentam que o barato sai caro; é melhor investir nacontagem manual dos pontos de função e ter confiabilidade desses dados, comcompensação no longo prazo.Por outro lado, muitos modelos de estimativa de software, como oCOCOO II, utilizam como dado primário de entrada de seu processo o tamanho emlinha de código. Nesses casos é muito comum realizar o inverso: obter o número delinhas de código a partir do tamanho em pontos de função. Isso porque nas fasesiniciais de um projeto de software é mais fácil estimar ou medir o seu tamanho empontos de função do que em linhas de código. Mesmo nesse caso, as consideraçõesanteriores sobre backfiring continuam válidas.