There are seve­ral soft­ware that from a pro­gram model or its source code, cal­cu­late its size in func­tion points. Howe­ver, com­pa­ri­sons between the result pro­du­ced by dif­fe­rent tools for the same sys­tem, fre­quen­tly have an unac­cep­ta­ble vari­a­tion. These num­bers, also often dif­fer gre­a­tly from a manual count.

The answer to this vari­a­tion is in how these tools cal­cu­late the num­ber of func­tion points. Some are based on files, scre­ens, reports and other ele­ments to derive a num­ber. Although there is often a direct rela­ti­onship between these objects and data func­ti­ons and tran­sac­ti­ons func­ti­ons of Func­tion Point Analy­sis (FPA), it must be remem­be­red that the tech­ni­que mea­su­res only the logi­cal func­ti­ons of the sys­tem. And these tools have dif­fi­cul­ties in dif­fe­ren­ti­a­ting logic func­ti­ons from phy­si­cal func­ti­ons. For exam­ple, not every file or table from a pro­gram file cor­res­ponds to an inter­nal logi­cal file or exter­nal inter­face file. Or even an ele­men­tary pro­cess can be imple­men­ted through mul­ti­ple scre­ens. To do the mea­su­re­ment in a cor­rect way, the soft­ware should have enough intel­li­gence to make this judg­ment. That is, this soft­ware would have to have the skill to read the pro­gram and inter­pret the user´s requi­re­ments. Howe­ver, there is no soft­ware with this arti­fi­cial intelligence.

Other tools are based on the back­fi­ring tech­ni­que, which is to derive the num­ber of func­tion points from the pro­gram num­ber of lines of code, based on a pre­vi­ous rela­ti­onship esta­blished between LOC and FP. Howe­ver, this is a tech­ni­que that has been widely cri­ti­ci­zed, and whose appli­ca­tion is restricted.

There are soft­ware to sup­port the pro­cess of coun­ting func­tion points that auto­mate a part of the pro­cess, but the deci­sion and analy­sis of that should be con­si­de­red, remains as the res­pon­si­bi­lity of a human user who enters the data, and not of the software.

Func­tion Point mea­su­res the func­ti­o­nal size of the soft­ware and not the effort invol­ved in its design and cons­truc­tion. The higher the line­a­rity found between func­ti­o­nal size and this effort (pro­duc­ti­vity), higher the prac­ti­cal value of the mea­su­re­ment obtai­ned. The more this rela­ti­onship is linear, more easily other mea­su­res can be extra­po­la­ted from the func­ti­o­nal size, as the cost and effort, for example.

If it’s loo­ked at a micro level, in asses­sing the size of two spe­ci­fic tran­sac­ti­ons, cer­tainly the poten­tial for devi­a­tion in deri­ved pro­duc­ti­vity is high, but as we expand our sam­ple size, we rea­lize that the extreme situ­a­ti­ons com­pen­sate them­sel­ves and, on ave­rage, we can observe higher line­a­rity in the rela­ti­onship between effort and func­ti­o­nal size.

Let’s think about some alter­na­tive metrics to the func­tion point, eva­lu­a­ting the impact of these con­si­de­ra­ti­ons on these metrics, for exam­ple, Lines Of Code. In the Orga­ni­za­tion as a whole, or even in a spe­ci­fic pro­ject, there are also situ­a­ti­ons where the coun­ting of lines of code num­ber is not direc­tly rela­ted to the effort invol­ved in the spe­ci­fi­ca­tion, docu­men­ta­tion and tes­ting of the pro­ject. In other words, there are two pro­jects with dif­fe­rent qua­lity requi­re­ments or incre­a­sed demand in the spe­ci­fi­ca­tion, where in spite of one being more “com­plex” and require more effort of deve­lop­ment, the resul­ting soft­ware has fewer code lines than the other. Not to men­tion the other limi­ta­ti­ons inhe­rent in the LOC metric.

In gene­ral this kind of work invol­ves a very limi­ted scope. As a con­se­quence, it is dif­fi­cult to esta­blish a rela­ti­onship between the func­ti­o­nal size and others metrics such as effort, time and cost. Howe­ver it´s impor­tant to remem­ber that Func­tion Point Analy­sis (FPA) is not sim­ply a tool for gene­ra­ting esti­ma­tes, used in pro­ject plan­ning. The nature of the work invol­ved in this ques­tion is cha­rac­te­ri­zed not as a pro­ject, but as a con­ti­nu­ous operation.

Take as an exam­ple the sys­tems main­te­nance with esti­ma­ted effort up to 200 hours. Sepa­ra­tely, the sizing of orders that repre­sent the requi­re­ments (not always func­ti­o­nal) object main­te­nance may not have a linear rela­ti­onship with the effort invol­ved on its achi­e­ve­ment. Howe­ver, accoun­ting the uni­verse unders­tood by all these requests at a big­ger period of time, we can reach at dif­fe­rent conclusions.

For exam­ple, a given main­te­nance request did not involve the addi­tion, modi­fi­ca­tion or exclu­sion of a cer­tain sys­tem fea­tu­res. In this case, it is use­less to know that the main­te­nance func­ti­o­nal size will have no func­tion points. But the sys­tem that gives main­te­nance has a func­ti­o­nal size. You can moni­tor the amount of main­te­nance hours per func­tion points of this sys­tem. This trend helps to appre­ci­ate if it is time to replace this sys­tem with a new one.

Sup­pose that there is a pro­cess in this orga­ni­za­tion where, after the ser­vice order has been ser­ved by the main­te­nance team, the pro­duct goes through an appro­val pro­cess. The fea­ture set in the appro­val may be sca­led in terms of func­tion points. Likewise, the amount of iden­ti­fied defects in the pro­cess can be docu­men­ted. Moni­to­ring the inter­play of these two metrics — Func­tion Point and Defects — during a period of time can bring out pro­blems in the main­te­nance pro­cess. Based on this trend it is pos­si­ble to take acti­ons to reduce this relation.