Using Function Points as a: 


 Software Development Company 



Software Recruiting Company 



IT Practitioner



                Function Point Training Course                   


Function Point Analysis: Fundamentals, Benefits and Implementation



Function Point Analysis Training: Software Measurement and Estimation

  Function Point Mentoring: The bridge from theory to practice

Online / Presencial


Online / Presencial


Read More

  Read More
  Read More 



         FAQ About FPA             Get more Information


We have a complete list of our frequently asked questions about Function Point Analysis. Click here.



Our Company:  

Learn more about our company: Our Company, Career, Our Team. Clients.                   



SCOPE™ - Project Sizing Software.



We appreciate your participation in our draw to take our Function Point Analysis online training.






FPA Quick Reference


Click HERE here to download our Quick Reference Guide.



1. What is Function Point Analisys? What is Function Point?


Func­tion Point Analy­sis (FPA) is a functionality measurement tech­ni­que pro­vi­ded by soft­ware based on its users point of view. Func­tion Point (FP) is the mea­su­ring unit, which has as an objective to become independent of the technology being used to build the software. In other words, FPA looks to measure what the software does and not how the software was developed.

This being said, the mea­su­rement pro­cess (also cal­led func­tion point coun­ting) is based on a stan­dard eva­lu­a­tion of the user’s func­ti­o­nal requi­re­ments. This stan­dard pro­ce­dure is des­cri­bed by IFPUG in the Coun­ting Prac­tices Manual.


The main techniques used for software development projects assume that the soft­ware size is an impor­tant dri­ver for the esti­ma­tion of its deve­lop­ment effort. Thus, knowing its size is one of the first steps in the effort, duration and cost estimation. 

At this point it is impor­tant to know that func­tion points do not mea­sure effort, pro­duc­ti­vity nor cost direc­tly. It is exclu­si­vely a soft­ware func­ti­o­nal size unit. This size, along with other vari­a­bles, is what could be used to derive pro­duc­ti­vity, esti­mate effort and cost of the soft­ware project.



2. Who created Function Points Analysis (FPA)? Why it was created?


Func­tion Point Analy­sis (FPA) was published in 1979 as a result of a pro­ject deve­lo­ped by the rese­ar­cher Allan Albre­cht of IBM. His job invol­ved a pro­duc­ti­vity ana­lisys for soft­ware pro­jects deve­lo­ped by a ser­vice unit of IBM.The goal was to find a tech­ni­que for esti­ma­ting soft­ware deve­lop­ment effort that was inde­pen­dent of the pro­gram­ming lan­guage used, chec­king only the exter­nal aspects of the soft­ware. This mea­su­ring unit, Func­tion Points, is inde­pen­dent of the pro­gram­ming lan­guage or any other aspect rela­ted to the soft­ware imple­men­ta­tion, since it is based on the user's vision.


You can read the com­plete and ori­gi­nal work in which Func­tion Point Analy­sis was pre­sen­ted in Octo­ber of 1979:  Mea­su­ring Appli­ca­tion Deve­lop­ment Pro­duc­ti­vity — Allan J. Albre­cht. This arti­cle is much more than just a his­to­ri­cal curi­o­sity, and is still applicable today.





3. Is the Function Point Analysis (FPA) technique owned by some company?


No. Des­pite having emer­ged in IBM, the result of this pro­ject was ope­ned to the whole soft­ware com­mu­nity in 1984.


The pat­tern recog­ni­zed by the Func­tion Point Analy­sis (FPA) soft­ware indus­try is the Coun­ting Prac­ti­ces Manual (CPM) kept by the IFPUG — Inter­na­ti­o­nal Func­tion Point Users Group.


The IFPUG is a non­pro­fit entity com­po­sed by peo­ple and com­pa­nies from all over the world, with the pur­pose of pro­mo­ting a bet­ter mana­gement of the deve­lop­ment pro­ces­ses and soft­ware main­tance by the use of the Func­tion Point Analysis.


The BFPUG — Bra­zi­lian Func­tion Point Users Group is the ofi­cial IFPUG repre­sen­ta­tive in Brazil.






4. What are Function Point Analysis (FPA) benefits?


We can high­light seve­ral bene­fits on applying func­tion point analy­sis in organizations:


- A tool for deter­mi­ning the size of a purchased pac­kage by coun­ting all the func­ti­ons included.


- Pro­vi­des assis­tance to users in deter­mi­nation of benefits of a package for their organization, by coun­ting the func­ti­ons that spe­ci­fi­cally match their requi­re­ments. When asses­sing the cost of the pac­kage, the size of the func­ti­ons that will be effec­ti­vely used, the pro­duc­ti­vity and cost of the staff is pos­si­ble to per­form a “make or buy” analysis.


- Sup­ports the analy­sis of pro­duc­ti­vity and qua­lity, either direc­tly or in con­junc­tion with other metrics such as effort, cost and defects. But if the deve­lop­ment method of the orga­ni­za­tion is cha­o­tic (each pro­ject is deve­lo­ped in a dif­fe­rent way), even if the func­tion points coun­ting of the pro­ject and the effort record have been made cor­rec­tly, the analy­sis of pro­duc­ti­vity among the pro­jects would have been impaired.


- Sup­ports the pro­ject scope mana­ge­ment. A chal­lenge of any pro­ject mana­ger is to con­trol “scope creep”, or the incre­ase of the scope. To make esti­ma­tes and mea­su­re­ments of func­tion points of the pro­ject at every stage of its life cycle is pos­si­ble to deter­mine whether the func­ti­o­nal requi­re­ments incre­a­sed or decre­a­sed, and whether this vari­a­tion cor­res­ponds to new requi­re­ments or requi­re­ments that alre­ady exist and were just more detailed.


- Com­ple­ments requi­re­ments mana­ge­ment to assist in verifying the sound­ness and completeness of the spe­ci­fied requi­re­ments. The pro­cess of coun­ting func­tion points favors a struc­tu­red and sys­te­ma­tic analy­sis of the requi­re­ments spe­ci­fi­ca­tion and brings similar bene­fits to that of that of the peer review process.


- A device for esti­ma­ting costs and resour­ces for deve­lo­ping and main­tai­ning soft­ware. By car­rying out a count or esti­mate func­tion points early in the lifecy­cle of a soft­ware pro­ject, it’s pos­si­ble to deter­mine its func­ti­o­nal size. This mea­surement can be used as input for many models of effort, time and cost estimation.


- A tool to sup­port con­tract nego­ti­a­tion. Func­tion points can be used to gene­rate seve­ral ser­vice level indi­ca­tors (SLA – Ser­vice Level Agre­e­ment) in deve­lop­ment and sys­tem main­te­nance con­tracts. Besi­des that, it allows con­tract esta­blish­ments by using unit price – func­tion points – where a unit repre­sents a tan­gi­ble asset to the cli­ent. This moda­lity allows for a bet­ter risk dis­tri­bu­tion between the cli­ent and provider.


- A nor­ma­li­za­tion fac­tor for soft­ware com­pa­ri­son or for com­pa­ri­son of pro­duc­ti­vity in the use of dif­fe­rents methods. Seve­ral orga­ni­za­ti­ons, such as ISBSG, pro­vide a data repo­si­tory of soft­ware pro­jects that ena­ble the imple­men­ta­tion of ben­ch­mar­king with simi­lar pro­jects in the market.



5. Is it necessary to be a software developer (systems analyst, programmer, etc.) to use the Function Point Analysis (FPA)?


No. The great advan­tage of the Func­tion Point Analy­si­sis that it is based on the USERVIEW, allowing its con­cepts to be unders­tood by the deve­lo­per and the user. The aim of the tech­ni­que is to mea­sure the func­ti­o­na­lity that the soft­ware pro­vi­des to the user regar­dless of tech­no­logy used for imple­men­ta­tion. This mea­su­re­ment is based only on the requi­re­ments that the soft­ware must attend.




6. Is there an entity or organization responsible for the standardization of FPA?

The standard recognized by the software industry for FPA is the Counting Practice Manual (CPM) maintained by the IFPUG (International Function Point Users Group).


The IFPUG is a non-profit entity composed by people and companies of various countries whose purpose is to promote better development process management and maintenance of software through FPA.




7. Has there been any enhancements in Function Point Analysis (FPA) after its creation?


Yes, since the publi­ca­tion of Func­tion Point Analysis’s pro­po­sal in 1979 seve­ral refi­ne­ments were incor­po­ra­ted to the tech­ni­que over the years. And this pro­cess con­ti­nues. But the essence of the tech­ni­que has chan­ged very lit­tle. This results from the fact that the tech­ni­que is ori­en­ted to mea­sure the func­ti­o­na­lity that the soft­ware pro­vi­des to the user, regar­dless of the tech­no­lo­gi­cal plat­form on which the soft­ware will run, deve­lop­ment metho­do­logy or pro­gram­ming lan­guage used for its construction.


After the foun­ding of IFPUG in 1986, a sys­te­ma­ti­cally for con­sis­tent deve­lop­ment of the Func­tion Point Analy­sis was cre­a­ted. IFPUG has a com­mit­tee res­pon­si­ble for edi­tion and update the Coun­ting Prac­ti­ces Manual, which cur­ren­tly is at ver­sion 4.3, this ver­sion was published in Janu­ary 2010.


There is no defi­ned fre­quency for IFPUG to publish upda­tes to its manual. And the upda­tes do not seek radi­cal chan­ges. They have the inten­tion to pro­vide further cla­ri­fi­ca­ti­ons regar­ding the defi­ni­ti­ons and coun­ting rules, thus impro­ving the con­sis­tency of mea­su­re­ments and redu­cing the sub­jec­ti­vity in the interpretations.





8. What is the IFPUG’s CFPS (Certified Function Point Specialist) certification?


The CFPS cer­ti­fi­ca­tion pro­gram — Cer­ti­fied Func­tion Point Spe­ci­a­list — aims to for­mally recog­nize pro­fes­si­o­nals capa­ble of per­for­ming the func­tion point counts accu­rate and con­sis­tent and also know the IFPUG’s latest coun­ting uses.


To be cer­ti­fied, the pro­fes­si­o­nal must be appro­ved in an exam pre­pa­red by IFPUG whose mini­mum hit rate is 90%. This exam con­sists on appro­xi­ma­tely 150 mul­ti­ple choice ques­ti­ons based on their Coun­ting Prac­ti­ces Manual. The test is 3 hours long. It is a hard exam to be appro­ved depen­ding on the time avai­la­ble and also the requi­re­ment of high accu­racy rate, but unfor­tu­na­tely the IFPUG does not dis­close any infor­ma­tion con­cer­ning the rate to be appro­ved in the exam.

The cer­ti­fi­cate is valid for three years, after this the owner must sub­mit to another exam for cer­ti­fi­ca­tion renewal or par­ti­ci­pate in the cer­ti­fi­ca­tion exten­sion pro­gram (regar­dless of whether there was any change in the ver­sion of the manual). This pro­gram (not imple­men­ted in Bra­zil yet) allows to extend in two years the cer­ti­fi­ca­tion vali­dity through the accu­mu­la­tion of cre­dits in vari­ous acti­vi­ties such as: per­form func­tion point counts, tea­ching, wri­ting arti­cles or books, volun­te­e­ring in some of the IFPUG’s com­mit­tees. Howe­ver, this renewal can only be per­for­med twice in suc­ces­sion, after this the pro­fes­si­o­nal will be requi­red to undergo exa­mi­na­tion to renew his cer­ti­fi­ca­tion.

By early 2008 the cer­ti­fi­ca­tion exa­mi­na­tion was con­duc­ted on paper, with manual cor­rec­tion, being taught in Bra­zil twice a year by the end of each semes­ter, with the pro­mo­tion of BFPUG. From July 2008 the exam was auto­ma­ted and can be applied by any Pro­me­tricaccre­di­ted cen­ter in the world, on the date sche­du­led by the inte­res­ted party. You can cho­ose between having the test in English or in Por­tu­guese. To search the list of autho­ri­zed cen­ters to admi­nis­ter the CFPS exam, visit

There is no requi­re­ment for higher edu­ca­tion, evi­dence of expe­ri­ence with Func­tion Point Analy­sis (FPA) or have atten­ded any course to attempt the cer­ti­fi­ca­tion. The only pre­re­qui­site to take the CFPS exam is to be affi­li­a­ted the IFPUG. But without pro­per pre­pa­ra­tion, the chance of appro­val is low. Even for the pro­fes­si­o­nal who is doing the exam to renew the cer­ti­fi­ca­tion, pre­pa­ra­tion is nee­ded and study and exer­ci­ses are essen­cial. Our course CFPS Exam Pre­pa­ra­tion (in Por­tu­guese only) is desig­ned spe­ci­fi­cally to sup­port the can­di­date to take the IFPUG’s exam on his jour­ney of pre­pa­ring for cer­ti­fi­ca­tion (or recertification).







9. What are the tips for the IFPUG’s CFPS exam?


One of the ques­ti­ons the can­di­da­tes have for cer­ti­fi­ca­tion is the ideal time for pre­pa­ra­tion to the exam. There is not an exact period to all, since there is a big vari­a­tion between each per­son. If the pro­fes­si­o­nal works using Func­tion Point Analy­sis (FPA) on daily basis, cer­tainly he will need less time than one who does so only spo­ra­di­cally. But in gene­ral, a period of one to three months of pre­pa­ra­tion is sufficient.

Regar­ding the study mate­ri­als, the fun­da­men­tal refe­rence text is the Coun­ting Prac­ti­ces Manual (CPM) itself, which is where the exam is based on. There is no need to memo­rize it, but it is impor­tant to read all of it care­fully and make sure there is no doubts remai­ning. Some exam ques­ti­ons are based on its many exam­ples. Although all con­tent is extrac­ted from the Manual, it does not address anything rela­ted to the cer­ti­fi­ca­tion pro­cess. Because of that it is impor­tant to seek other sour­ces of study. The best pre­pa­ra­tion indi­ca­tors are the simu­la­ted exercises.


An interesting(free) alter­na­tive to keep the mat­ter of func­tion points in mind during the pre­pa­ra­tion for the exam, is to par­ti­ci­pate in dis­cus­sion forums such as IFPUG’s,BFPUG’s, and “Func­tion Point Analy­sis : Mea­su­re­ment, Esti­ma­tes and Pro­ject Mana­ge­ment Soft­ware. ” rea­ders group.

The book Aná­lise de Pon­tos de Fun­ção: Medi­ção, Esti­ma­ti­vas e Geren­ci­a­mento de Pro­je­tos de Soft­ware (Func­tion Point Analy­sis: Mea­su­re­ment, Esti­ma­tes and Soft­ware Pro­ject Mana­ge­ment, avai­a­ble only in Por­tu­guese) con­tains a chap­ter devo­ted to the IFPUGcer­ti­fi­ca­tion pro­cess with tips and pre­sen­ta­tion of the cer­ti­fi­ca­tion pro­cess and also a simu­la­ted exam.

The FATTO’s course CFPS Exam Pre­pa­ra­tion offers more than 1,000 ques­ti­ons in the exam style as a resource to sup­port the can­di­date, besi­des the ins­truc­tor sup­port until the exam date. In the Demo Ver­sion CFPS Exam Pre­pa­ra­tion is pos­si­ble to per­form some exer­ci­ses, and access other resour­ces rela­ted to the exam for free, inclu­ding a small simu­la­tion with 30 ques­ti­ons. Always in Portuguese.





10. How much does IFPUG CFPS certification cost?


Since 2004 only IFPUG mem­bers can apply for the CFPS/CFPP exam. More­o­ver, those appro­ved in the exa­mi­na­tion must keep their mem­bership regu­lar throughout the dura­tion of the cer­ti­fi­ca­tion. The­re­fore, costs for cer­ti­fi­ca­tion should be analy­sed con­si­de­ring IFPUG mem­bership dues also.


Regar­ding to the mem­bership dues, see:


There are seve­ral types of regu­lar membership:

  • Indi­vi­dual — US$ 185.00
  • Cor­po­rate (only one geo­graphic region) — $ 625.00
  • World Wide Cor­po­rate — US$ 1,850.00

The Coun­ting Prac­ti­ces Manual, the body of kno­wledge for the test, is avai­la­ble for free down­load only for IFPUG members.


For com­pa­nies inte­res­ted in cer­tifying at least 3 peo­ple, Cor­po­rate Affi­li­a­tion may be the most inte­res­ting. Otherwise, the best option is the indi­vi­dual membership.


The Pro­me­tric vou­cher for the exam is US$ 250.00. It’s impor­tant to notice that you may also have tra­vel expen­ses if you dont’t live in a city whith a Pro­me­tric tes­ting site.


Howe­ver, it is stron­gly recom­men­ded that you look for a good pre­pa­ra­tion for the exam, with avai­la­ble time for studying, taking pre­pa­ra­tory cour­ses, if pos­si­ble, and/or pur­cha­sing addi­ti­o­nal mate­rial. The­re­fore, it is also impor­tant to con­si­der these addi­ti­o­nal expenses.





11. Who uses Function Point Analysis (FPA) in the world?


The IFPUG has affiliates in more than 40 countries around the world, having a strong presence in Germany, Australia, Brazil, Canada, Korea, United States, India, England, Italy, Colombia, Uruguay, Mexico, Argentina and the Netherlands.

Companies such as IBM, Unisys, Xerox, HP, CitiGroup, Tata Consulting Services, Lockheed Martin EIS, Booz Allen & Hamilton, Nielsen Media Research, Banco do Brasil, Citibank, HSBC, Indra , Bank of Canada, Ralston Purina Co., Banco de la República (Central Bank of Colombia), Northrop Grumman Corp, Samsung SDS Co Ltd, BASF Corporation, Banco Central de Chile, Accenture, IBM, Petrobras, Pepsi Co, Compuware, Pricewaterhouse Cooper, Vale, Banco Santander, Petrobras and Telefonica, among others, are using function points for software project management.  



12. Is it possible to use Function Point Analysis (FPA) in an Object-oriented design?


Yes. Func­tion Point Analy­sis (FPA) is an inde­pen­dent tech­no­logy tech­ni­que used to model or imple­ment soft­ware. So a soft­ware has the same size in func­tion points, either being deve­lo­ped using OO tech­no­logy or another appro­ach.

What may be dif­fe­rent in the two appro­a­ches is that in OO design, pro­duc­ti­vity (hours/FP) may be bet­ter due to reuse. Making an ana­logy with a buil­ding cons­truc­tion: we can build a house of 100m2 in the con­ven­ti­o­nal way or using pre­fa­bri­ca­ted modu­les. In both cases, the size of the house will be the same, only the cons­truc­tion time or cost may be different.



13. What’s the size to consider that a software project is small, medium or large?


It is desi­ra­ble in an orga­ni­za­tion that the pro­ject mana­ge­ment pro­cess be sca­la­ble in accor­dance with the pro­ject size. Big pro­jects need more seve­rity and for­ma­lism on its mana­ge­ment than small pro­jects. Using the same appro­ach to any size of pro­ject means over­tax small pro­jects with a higher cost of mana­ge­ment, in other words, was­ting of resour­ces. There is no indus­try stan­dard defi­ni­tion to prove if a pro­ject is small, medium or large. This is a rela­tive con­cept and it must be sol­ved by each orga­ni­za­tion. In fact, it’s not usu­ally neces­sary to define a pro­ject in 3 levels (small, medium and large). For orga­ni­za­ti­ons that usu­ally work in a simi­lar way, that clas­si­fi­ca­tion could be unne­ces­sary and using the same mana­ge­ment pro­cess to all pro­jects might be the best appro­ach. Some orga­ni­za­ti­ons have a mana­ge­ment tac­tics for just two types of pro­jects (small and large). Also, it is not prohi­bi­ted if an orga­ni­za­tion wants to define more than 3 levels for the pro­ject size; (for exam­ple: small, medium, large and extra large). But this is not usual. 


In short, the con­cept of small, medium or large is very rela­tive; each orga­ni­za­tion can esta­blish it own cri­te­ria to appoint a pro­ject in rela­tion to its size.





14. What is the price of one function point ($/FP)?


The value of $/FP will vary in accor­dance with the work requi­red for the deli­very of soft­ware func­ti­o­na­lity, in accor­dance with the tech­ni­cal stan­dard and qua­lity requi­red by cus­to­mers, as well as the amount of deli­ve­ra­bles (arti­facts, docu­ments, models, etc) requi­red by the cus­to­mer. In short, everything that affects sig­ni­fi­can­tly the cost but has no direct rela­tion to the size mea­su­red by the Func­tion Point Analy­sis (FPA), is com­pu­ted on the func­tion point price.


Exam­ple 1: when you hire a com­pany just for coding and tes­ting a sys­tem, it is expec­ted that the func­tion point price is lower than if you hire the same firm to con­duct the entire lifecy­cle of a soft­ware deve­lop­ment, from requi­re­ments sur­vey through deve­lop­ment.


Exam­ple 2: the func­tion point price only for soft­ware deli­very is cer­tainly les­ser than the func­tion point price where, besi­des the soft­ware, must be deli­ve­red seve­ral papers (sub­pro­ducts) as : UML models, user’s manual, online help­desk, pro­toty­pes, test plans and cases, etc.


Exam­ple 3: Nowa­days the range of avai­la­ble tech­no­lo­gies for deve­lo­ping sys­tems is huge, and each one can direc­tly influ­ence in the pro­duc­ti­vity (either posi­ti­vely or nega­ti­vely) of the work to be done. Thus it is quite com­mon in the mar­ket the dif­fe­ren­ti­a­tion of $/FP accor­ding to the tech­no­lo­gi­cal plat­form (main­frame, web, client-server, etc) and/or pro­gram­ming lan­guage (COBOL, C, Java,. Net, etc).


Exam­ple 4: Func­tion Point Analy­sis, accor­ding to the IFPUG stan­dard, mea­su­res the main­te­nance igno­ring the size of the main­te­nance that the func­tion will suf­fer. Usu­ally the effort to main­tain a func­tion tends to be lower than to deve­lop it. Thus, there may be func­tion point price dif­fe­ren­ti­a­tion in impro­ve­ment pro­jects for new, modi­fied and dele­ted fea­tu­res.


In sum­mary, there is not a uni­que price for func­tion point and also there is no public upda­ted price list avai­la­ble, where the func­tion point price could be seen. Even because this infor­ma­tion is con­si­de­red pro­pri­e­tary or stra­te­gic for most orga­ni­za­ti­ons. But it is pos­si­ble to obtain price infor­ma­tion from govern­ment con­tracts through a rese­arch on the bid­dings that occur­red, in the bra­zi­lian offi­cial gazette or direc­tly with the govern­ment organ .


Another pos­si­bi­lity to get this price list is using orga­ni­za­ti­ons that main­tain the his­to­ri­cal basis of soft­ware pro­jects (e.g. ISBSG — and do a deli­very rate indi­ca­tors con­ver­sion (H/PF) to price ($/FP). But even if we could get a list of $/FP value, the vari­a­tion in num­bers is so sig­ni­fi­cant that it is easy to find a range of values whose vari­a­tion between mini­mum and maxi­mum can be up to 10 times, for exam­ple $ 100/FP to $ 1.000/FP.


For a more rea­lis­tic price infor­ma­tion (or cost) of the FP is bet­ter to get this in the pro­jects alre­ady under­ta­ken. For pro­jects alre­ady com­ple­ted, a infor­ma­tion that is cer­tainly avai­la­ble is how much was paid or char­ged for each pro­ject and what acti­vi­ties were inclu­ded. If the pro­jects func­ti­o­nal size (FP) is not avai­la­ble, it could be got­ten through a mea­su­re­ment or an esti­mate, just revi­ewing the requi­re­ments. Having the price of the pro­ject and its size in func­tion points, could be got­ten the price per func­tion point ($/FP). Howe­ver it is likely that your orga­ni­za­tion under­ta­kes pro­jects of dif­fe­rent types. In this case, an analy­sis of the $/FP should be done for each cate­gory of pro­jects, cause a sin­gle price is har­dly repre­sen­ta­tive for pro­jects of dif­fe­rent types.







15. Is it possible to apply the Function Point Analysis (FPA) on tasks that are not organized as projects?


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.






16. Two functions, that are significantly different in the implementation effort, are scaled with the same number of function points. Doesn´t it


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.



17. Why are there no tools for automatic function points counting of a system?


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.







18. What is backfiring?


This method con­sists in deri­ving the num­ber of func­tion points accor­ding to the appli­ca­tion from its phy­si­cal size, mea­su­red in lines of code (LOC), using a cons­tant con­ver­sion fac­tor depen­ding on the pro­gram­ming lan­guage. The idea has much appeal, since the coun­ting of lines of code can be done through auto­ma­tic tools and con­se­quen­tly, the num­ber of func­tion points could be deri­ved imme­di­a­tely. For exam­ple, using a con­ver­sion fac­tor of 80 LOC / FP for Java and having an appli­ca­tion writ­ten in 8,000 lines of Java code, we get to 1,000 func­tion points for that same application.


Howe­ver, often, this tech­ni­que has con­si­de­ra­ble errors when con­fron­ted with a manual count of func­tion points of an appli­ca­tion. This is because it assu­mes a linear rela­ti­onship between func­ti­o­nal size (in func­tion points) and the phy­si­cal size of the pro­gram (in lines of code), which are dif­fe­rent con­cepts. Other aspect is that there is no con­sen­sus in the vari­ous orga­ni­za­ti­ons that publish these rela­ti­onships. The num­bers shown may dif­fer as much as 100%. 


When you have a deve­lo­ped sys­tem sce­na­rio with a mix of pro­gram­ming lan­gua­ges, the issue is more com­pli­ca­ted. The fol­lowing table pro­vi­des an exam­ple of these vari­a­ti­ons for the COBOL language.



Con­ver­sion Fac­tor (COBOL)

Quan­ti­ta­tive Soft­ware Management


Capers Jones

107 LOC/PF

David Con­sul­ting Group

177 LOC/PF


Some of the rea­sons for this wide vari­a­tion are: dif­fe­rent assump­ti­ons in defi­ning what is a line of code, and pro­jects data­ba­ses with many dif­fe­rent fea­tu­res. Hence the neces­sity to cali­brate the con­ver­sion fac­tor for the rea­lity of the pro­jects deve­lo­ped by the orga­ni­za­tion. Howe­ver, to make this adjust­ment, there must be a repre­sen­ta­tive sam­ple of pro­jects deve­lo­ped by the orga­ni­za­tion in a par­ti­cu­lar lan­guage and an expe­ri­en­ced and qua­li­fied pro­fes­si­o­nal to inter­pret the results and unders­tand the rea­sons for this pos­si­ble dis­tor­tion for this con­ver­sion fac­tor.

Due to these fac­tors, apply back­fi­ring to obtain the size in func­tion points from lines of code is a risky tech­ni­que and cha­rac­te­ri­zed by a large mar­gin of error. Hence, IFPUGhigh­lights in their FAQ, that it can even be used (with cau­tion) in legacy sys­tems, where a manual count is unwor­ka­ble in prac­tice and accu­racy is not a cri­ti­cal fac­tor. Some pro­fes­si­o­nals argue that back­fi­ring is a quick and cheap way to get the size in func­tion points of an orga­ni­za­tion appli­ca­ti­ons port­fo­lio. Others, argue that cheap comes out expen­sive: it is bet­ter to invest in a manual coun­ting of func­tion points and have reli­a­bi­lity of these data, with com­pen­sa­tion in a long term.


 On the other hand, many models of soft­ware esti­ma­ting such as COCOMO II, use as pri­mary data their size in lines of code. In these cases, it is very often to do the oppo­site: get the num­ber of lines of code from the size in func­tion points. This is because in the early sta­ges of a soft­ware pro­ject, is easier to esti­mate or mea­sure its size in func­tion points than in lines of code. Even then, the above con­si­de­ra­ti­ons remain valid on back­fi­ring.




19. What does functional size mean in relation to the ISO/IEC standard?


Aiming to solve the incon­sis­ten­cies between vari­ous methods ari­sing from the model of Func­tion Point Analy­sis, pro­po­sed by Allan Albre­cht, and to esta­blish a more rigo­rous method of mea­su­ring func­ti­o­nal size, was for­med a group cal­led WG12 (Wor­king Group 12), sub­ject to SC7 ( Sub-Committee Seven) of JTC1 (Joint Tech­ni­cal Com­mit­tee One) esta­blished by ISO (Inter­na­ti­o­nal Orga­ni­za­tion for Stan­dar­di­za­tion) in con­junc­tion with theIEC (Inter­na­ti­o­nal Engi­ne­e­ring Consortium).


As a result of the work of WG12, was esta­blished the stan­dard 14.143, which is spli­ted into five parts:

14143–1: Con­cepts Defi­ni­tion 
14143–2: Con­for­mity Asses­s­ment of Soft­ware Mea­su­re­ment Methods in Rela­tion to ISOIEC 14.143–1

14143–3: Veri­fi­ca­tion of a Func­ti­o­nal Size Mea­su­re­ment Method
14143–4: Refe­rence Model for Func­ti­o­nal Size Mea­su­re­ment
14143–5: Deter­mi­na­tion of Func­ti­o­nal Domains for use with Func­ti­o­nal Size Measurement


ISO / IEC 14.143 was deve­lo­ped to ensure that all the func­ti­o­nal size mea­su­re­ment methods are based on simi­lar con­cepts and can be tes­ted to ensure that they behave simi­larly and as expec­ted by a method of mea­su­re­ment, depen­ding on the func­ti­o­nal domains that they are applied.

At the end of 2002 the tech­ni­que of Func­tion Point Analy­sis, as defi­ned in ver­sion 4.x ofIFPUG manual, was appro­ved (under the stan­dard 20.926) as a Func­ti­o­nal Size Mea­su­re­ment Method, adhe­ring to ISO / IEC 14143.





20. In addition to the IFPUG function points, are there any other methods of functional measurement?


Yes, there are three others stan­dard methods of func­ti­o­nal measurement:


NESMA — The asso­ci­a­tion of metrics from Nether­lands has its own coun­ting manual, cur­ren­tly at ver­sion 2.0, whose the first ver­sion in 1990 was based on IFPUG manual. It uses the same phi­lo­sophy, con­cepts, terms and rules of IFPUG, with some dif­fe­rent gui­de­li­nes. The mea­su­re­ment of a deve­lop­ment pro­ject or an appli­ca­tion pro­du­ces results very simi­lar under both appro­a­ches – IFPUG and NESMA. Howe­ver, both orga­ni­za­ti­ons have dif­fe­rent appro­a­ches to func­tion point analy­sis appli­ca­tion in soft­ware impro­ve­ment projects.


Mark II — was cre­a­ted by Char­les Symons in the mid-80s. Its spread has been ham­pe­red ini­ti­ally because the method was owned by KPMG con­sul­tant for seve­ral years. Today is a public domain metrics method main­tai­ned by the UK Asso­ci­a­tion of Metrics —UKSMA. It’s a method wich its appli­ca­tion is res­tric­ted to the UK.


COSMIC-FFP — In 1997 a group of rese­ar­chers from the Uni­ver­sity of Que­bec has deve­lo­ped a new method for mea­su­ring func­ti­o­nal real-time sys­tems, cal­led Full Func­tion Points (FFP). In 1998 a group of experts in soft­ware mea­su­re­ment cons­ti­tu­ted theCOSMIC (Com­mon Soft­ware Mea­su­re­ment Inter­na­ti­o­nal Con­sor­tium) in order to deve­lop a new method of mea­su­ring func­ti­o­nal size based on the best fea­tu­res of exis­ting methods and incor­po­ra­ting new ideas. This new method pro­po­sed in 2000, cal­ledCOSMIC-FFP, in prac­tice was a refi­ne­ment of the FFP method. It is not yet a tech­ni­que so wides­pread as the IFPUG, but there is much rese­arch being con­duc­ted on this method. We could say that the mar­ket fol­lows care­fully its footsteps.





21. What are the first steps towards implementation of the Function Point Analysis (FPA) in my organization?


The first step is to cle­arly iden­tify what are the goals of the orga­ni­za­tion. Func­tion Point Analy­sis can be used for seve­ral pur­po­ses: esti­ma­tion of soft­ware pro­jects, unit of con­tracts mea­su­re­ment, sup­port for qua­lity and pro­duc­ti­vity con­trol, ben­ch­mar­king and metrics program.


Each appro­ach has its spe­ci­fic pecu­li­a­ri­ties; howe­ver there are aspects com­mon to all them, high­ligh­ted below:

1. Gain the sup­port of the organization’s direc­tion. Keep in mind that the results of the use of Func­tion Point Analy­sis in the orga­ni­za­tion are not always imme­di­ate and that the suc­cess of its use will depend on the dedi­ca­tion and use of human and finan­cial resour­ces, as well as any pro­gram that focu­ses on pro­ces­ses improvement.


2. Take advan­tage of exis­ting oppor­tu­ni­ties in the orga­ni­za­tion that may have some com­mon goals. Exam­ples of these ini­ti­a­ti­ves are: ISO, Six Sigma, CMMPMI, Balan­ced Sco­re­card. Taking these ini­ti­a­ti­ves and knowing to relate (and show to spon­sors) how Func­tion Point Analy­sis may con­tri­bute to some of the organization´s goals, will make it easier to accept.


3. Empower your­self. Knowing the cor­rect tech­ni­que is essen­tial. It’s ama­zing the num­ber of cases that Func­tion Point Analy­sis has being applied incor­rec­tly, and that, inva­ri­a­bly ends in fai­lure. The offi­cial refe­rence of the tech­ni­que is the IFPUG — CPM (Coun­ting Prac­ti­ces Manual). Inte­res­ting acti­ons in this regard can be:


- Hire a clo­sed class of a course for the whole team invol­ved, so you can adjust the load or sum­mary of the course with the objec­ti­ves of the pro­cess and the rea­lity of the orga­ni­za­tion. In this case, FATTO usu­ally hold a ser­vice pac­kage with one week dura­tion: two days to teach the course Trai­ning Func­tion Point Analy­sis; and three days for con­sul­ting the begin­ning of the pro­cess and men­to­ring on the appli­ca­tion of the tech­ni­que in organization’s prac­ti­cal cases.


- Subs­cribe peo­ple in the pro­cess in open cour­ses on the tech­ni­que of func­tion points.FATTO regu­larly tea­ches open cour­ses in seve­ral cities in Bra­zil. See our course sche­dule for more information.


4. Set modest ini­tial goals. Start with a pilot pro­ject in a sim­ple sys­tem. Eva­lu­ate results, make adjust­ments, review the objec­ti­ves and move on.


5. Be aware of tech­ni­que limi­ta­ti­ons. There are domains pro­blem where Func­tion Point Analy­sis is not indi­ca­ted. For exam­ple, in sys­tems opti­mi­za­tion, the tech­ni­que is not sui­ta­ble for mea­su­ring parts with high algo­rith­mic complexity.


6. In doubt, make the ana­logy with the square meter. In gene­ral, it is suf­fi­ci­ent to solve the issue.


7. Seek help if neces­sary. An out­side con­sul­tant can avoid unne­ces­sary trou­bles, has­ting the pro­cess, brin­ging expe­ri­ence and hel­ping to cor­rect the directions.


8. Do not com­pare apples with oran­ges. Com­pa­ri­sons should only be made between pro­jects that have simi­la­ri­ties (deve­lop­ment pro­cess, tech­no­logy plat­form, busi­ness area, etc).





22. What is the initial guidance for the application of Function Point Analysis (FPA) in software projects estimations?


Besi­des the gene­ral con­si­de­ra­ti­ons pre­sen­ted in the pre­vi­ous post, the fol­lowing are some spe­ci­fic gui­de­li­nes to use the func­tion point in estimates.


Although some authors quote the use of func­tion points direc­tly to derive ini­tial esti­ma­tes of term, defects and team size, the most com­mon is use it for effort esti­ma­tion (usu­ally amount of hours).


The pro­cess to esti­mate effort is very sim­ple: Given a pro­duc­ti­vity (hours per func­tion point) in a given deve­lop­ment envi­ron­ment, sim­ply mul­ti­ply it by the func­ti­o­nal size of soft­ware to obtain the desi­red estimate.


Howe­ver, the key ques­tion is: which pro­duc­ti­vity should be employed? Many peo­ple use mar­ket indi­ca­tors published by vari­ous orga­ni­za­ti­ons. But many of these peo­ple are frus­tra­ted with the outcome.


The answer is: there are no magic num­bers. The pro­duc­ti­vity to be employed is spe­ci­fic to each orga­ni­za­tion and not a mar­ket ave­rage. It must reflect the rea­lity of the deve­lop­ment pro­cess of the orga­ni­za­tion in a par­ti­cu­lar con­text: deve­lop­ment tool, busi­ness area or tech­no­logy platform.


To obtain it own num­bers, the orga­ni­za­tion may use the data from pre­vi­ous pro­jects and reco­ver it infor­ma­tion effort and size in func­tion points. Grou­ping simi­lar pro­jects, is pos­si­ble to obtain a reli­a­ble indi­ca­tor of productivity.



23. What is the initial guidance for the application of Function Point Analysis (FPA) in systems development contracts?


Besi­des the gene­ral con­si­de­ra­ti­ons pre­sen­ted in pre­vi­ous posts, are pre­sen­ted below some spe­ci­fic gui­de­li­nes for the use of func­tion points in the three main models used for hiring: Man-Hour, Glo­bal Fixed Price and Unit Price.

In case of the con­trac­ting model used is man-hours, where the pro­vi­der remu­ne­ra­tion is not based on the results pre­sen­ted, but in work hours esta­blished in a period, you can use Func­tion Point Analy­sis (FPA), for exam­ple, to moni­tor the team’s pro­duc­ti­vity. To do so, just mea­sure the result data (func­tion points) and the effort data (hours) together and make eva­lu­a­ti­ons rela­ting both information.


When hiring is based on glo­bal fixed price, the Func­tion Point Analy­sis (FPA) can be used as a nor­ma­li­za­tion fac­tor of price in order to ensure that the amount char­ged for addi­ti­o­nal func­ti­o­na­lity not pro­vi­ded, or during the main­te­nance phase, is con­sis­tent with the amount char­ged at the time that the ser­vice was hired.


The project’s size is mea­su­red in func­tion points, and from the total amount char­ged by the sup­plier for the pro­ject, the value of the func­tion point is cal­cu­la­ted. The new pro­po­sals are mea­su­red regar­ding its size and then apply the value of the func­tion point to obtain the amount of new fea­tu­res. Then this value can be com­pa­red to the value pro­po­sed by the supplier.


Howe­ver, the model that can bet­ter balance the defi­ci­en­cies in hiring man-hours and the glo­bal fixed price is based on unit price (func­tion points). If the sup­plier deli­vers a low pro­duc­ti­vity, he will not be paid for the extra time con­su­med. Otherwise will enjoy a bet­ter pro­fi­ta­bi­lity on ser­vice. If there is an incre­ase in scope of ser­vice will not be requi­red stres­s­ful nego­ti­a­ti­ons to esta­blish a value for the addi­ti­o­nal service.


In this mode, an impor­tant fac­tor is to define pro­perly the value of the func­tion point, as we can see in this post.


In any of the types of con­tracts adop­ted, must be care­ful with inte­rest con­flicts: the mea­su­re­ment of ser­vice in func­tion points should never be per­for­med only by the sup­plier, because it will be paid pre­ci­sely by the mea­su­ring result! You can observe this unde­si­ra­ble prac­tice in some orga­ni­za­ti­ons (inclu­ding govern­ment). Inter­nal staff can be used to per­form the mea­su­re­ment, or at worst vali­date the mea­su­re­ments made by sam­pling. Another option is to hire an out­side com­pany for this service.



24. What are the general guidelines for the use of Function Point Analysis (FPA) in the process of benchmarking of the productivity in software d


The pro­cess of ben­ch­mar­king of the pro­duc­ti­vity of soft­ware deve­lop­ment, as well as any other indi­ca­tor, depends fun­da­men­tally on the fol­lowing ques­tion: does your orga­ni­za­tion have inter­nally valid data, which will be com­pa­ra­ble with those obtai­ned in the market?


Indeed, the impor­tance of this ques­tion can be per­cei­ved when one says ” can­not per­form ben­ch­mar­king of a data that was not col­lec­ted.” Although it seems obvi­ous, the sim­pli­city of this sta­te­ment disap­pe­ars when eva­lu­a­ting the effort requi­red to obtain reli­a­ble inter­nal data, which reflect the rea­lity of the organization.


The pro­cess begins, then, by col­lec­ting these data. We should have in mind that it is not suf­fi­ci­ent to write a ques­ti­on­naire and deli­ver it to the peo­ple to answer it. It’s neces­sary to have a plan to ensure that the defi­ni­ti­ons of the vari­a­bles of inte­rest and the pos­si­ble answers are clear, before star­ting the data col­lec­tion. A lon­ger time spent on such plan­ning redu­ces the risk of erro­ne­ous data col­lec­tion and the effort spent on data validation.


Now, by ana­logy and knowing the con­cept of pro­duc­ti­vity, we can say that it is not pos­si­ble to per­form the ben­ch­mar­king of the pro­duc­ti­vity of soft­ware deve­lop­ment without the kno­wledge of the data size and effort of the organization’s pro­jects. The size is usu­ally mea­su­red in Func­tion Points (FP) and the effort, in Hours (H). As alre­ady men­ti­o­ned, the col­lec­tion of these data should be con­duc­ted in a way that can be com­pa­red with the indi­ca­tors obtai­ned in the mar­ket. The key to a suc­ces­s­ful ben­ch­mar­king is the data stra­ti­fi­ca­tion. It is essen­tial that col­lec­ti­ons are car­ried out accor­ding to the simi­la­rity of the pro­jects, since the pro­duc­ti­vity can be highly vari­a­ble depen­ding on the busi­ness sec­tor of the pro­ject, the hard­ware and soft­ware plat­form, the time when the pro­ject star­ted, etc.


The ben­ch­mar­king is done, then, under the same stra­ti­fi­ca­tion adop­ted at the time of the data col­lec­tion inside the orga­ni­za­tion. Howe­ver, at this moment is still neces­sary to observe care­fully some other issues in an attempt to explore the ade­quacy level of the indi­ca­tor for a par­ti­cu­lar pro­ject or environment:


a) Are the cri­te­ria of col­lec­tion of hours used in the pre­pa­ra­tion of mar­ket indi­ca­tors con­sis­tent with those used in the organization? For exam­ple: How many hours are con­si­de­red in a wor­king month (126, 160, 168, etc)? What is the daily hours of work (4, 6, 8, etc)?


b) Is the func­ti­o­nal size coun­ting method used in esta­blishing the mar­ket indi­ca­tor com­pa­ti­ble with the organization? For exam­ple, did we use the adjust­ment fac­tor defi­ned by the IFPUG method?


c) Do The acti­vi­ties invol­ved, the pro­ducts gene­ra­ted, the metho­do­logy adop­ted involve the same use of resour­ces that the con­text in analy­sis requires? For ins­tance, what pro­ject tem­pla­tes and dia­grams are used? Are there defi­ned roles for each acti­vity, inclu­ding that to imple­ment the pro­jects qua­lity control?


d) Although being dif­fe­rent, is the risk of this vari­a­bi­lity acceptable?


Another fac­tor to be con­si­de­red is the impor­tance of upda­ting the data used in ben­ch­mar­king. At most, it is noteworthy that how much more pro­jects are used in the ben­ch­mar­king pro­cess, bet­ter is. After taken all the neces­sary pre­cau­ti­ons, if there are still doubts about the results obtai­ned for the pro­duc­ti­vity of soft­ware deve­lop­ment, use a range rather than an exact value for the indicator.





25. Is the estimate of effort (in hours) from the size (in function points) is related only to construction activities or the whole software proj


The main ques­ti­ons that a soft­ware esti­ma­ting pro­cess tries to answer are rela­ted to the time requi­red to com­plete a pro­ject and the cost of its deve­lop­ment. The answers can only be con­si­de­red reli­a­ble if all the acti­vi­ties invol­ved in the soft­ware pro­duc­tion are esti­ma­ted as the fac­tors that affect the vari­a­bles of time and cost. Such acti­vi­ties involve from requi­re­ments defi­ni­tion to pro­duct deploy­ment and testing.


The Func­tion Point Analy­sis is a method used to iden­tify one of these fac­tors, the size of the soft­ware. In a pro­cess of soft­ware esti­ma­ting, the size is the first gre­at­ness to be analy­zed. Without it, the other esti­ma­tes (such as effort, term, cost and num­ber of defects) can­not be deter­mi­ned without having added a high degree of sub­jec­ti­vity to the results.


Based on the amount of func­tion points is pos­si­ble to obtain indi­ca­tors such as deli­very rate (H / FP), cost (US$ / FP) and qua­lity indi­ca­tors (Defects / FP) of pro­jects alre­ady under­ta­ken. These infor­ma­tion could be extra­po­la­ted for appli­ca­tion in esti­ma­tes pro­ces­ses of new projects.


Sim­plifying, if it is known HOW MUCH is to be pro­du­ced, we can extra­po­late what will be the effort, time and cost invol­ved in this work. Then these values could be dis­tri­bu­ted between the vari­ous sta­ges of the life cycle of soft­ware deve­lop­ment, pro­vi­ded that are known the effort dis­tri­bu­tion per­cen­ta­ges deter­mi­ned by the pro­cess of soft­ware pro­du­cing adop­ted by the organization.



26. In what situations can be interesting to outsource the function points counting?


The eva­lu­a­tion made to out­source the func­tion point coun­ting invol­ves basi­cally the same ques­ti­ons to out­source any other acti­vity. There are high­ligh­ted below spe­ci­fic situ­a­ti­ons where the out­sour­cing may be favo­ra­ble to the con­trac­tor organization:


- In the ini­tial period of imple­men­ta­tion of the tech­ni­que in the orga­ni­za­tion, the coun­ting of some pro­jects by an expe­ri­en­ced pro­fes­si­o­nal with the trac­king of a part of the cli­ent team can haste the pro­cess and also help in absorp­tion of prac­ti­cal kno­wledge by the team. It is also a men­to­ring indeed.


- An expe­ri­en­ced pro­fes­si­o­nal has more agi­lity in the coun­ting pro­cess. If the orga­ni­za­tion does not have anyone with this pro­file, and when the coun­ting scope is too large and the time to do it is res­tric­ted, it could be inte­res­ting to hire an out­side expert in coun­ting acting together with a pro­fes­si­o­nal from inside the orga­ni­za­tion that knows the sys­tems to be counted.


- When the count is a spo­ra­dic need, the cost-benefit to train a pro­fes­si­o­nal in-home and keep it upda­ted may be disad­van­tage regar­ding to hiring a expe­ri­en­ced professional.


- When the func­tion point coun­ting is a sys­te­ma­tic need, is impor­tant to have inter­nal pro­fes­si­o­nals trai­ned for the task. In this case, out­sour­cing can be con­ve­ni­ent during a peak demand for this activity.


- When it is neces­sary that the coun­ting must be done (or audi­ted) by a cer­ti­fied pro­fes­si­o­nal (CFPS).


FATTO has a team of cer­ti­fied experts that can help your orga­ni­za­tion not only in the pro­cess of func­tion point coun­ting , but also in the cor­rect appli­ca­tion of the Func­tion Point Analy­sis (FPA) on esti­ma­tes, the mea­su­re­ment pro­gram and hiring soft­ware. Ple­ase con­tact us for more information.





27. What are the Use Case Points?


Until a few years ago (early 90s) there was a false notion that Func­tion Point Analy­sis (FPA) was not ade­quate to mea­sure object-oriented sys­tems. Those who sha­red this con­cept, in prac­tice, don´t really know Func­tion Point Analysis.


With the spread of cons­truc­tion and design of object-oriented sys­tems, there was also a change in the way of spe­cifying and mode­ling sys­tems. The UML and Use Cases quic­kly became stan­dard in the indus­try of software.

Within this con­text, in 1993 Gus­tav Kar­ner pro­po­sed in an aca­de­mic paper the metho­do­logy of the Use Case Points (based on Func­tion Point Analy­sis) with a view of esti­ma­ting resour­ces for soft­ware pro­jects  using object-oriented deve­lo­ped and using the Objec­tory pro­cess.

The PCU mea­su­re­ment pro­cess is sum­ma­ri­zed in:


1 — Count the Actors and iden­tify their com­ple­xity
2 — Count the Use Cases and iden­tify their com­ple­xity
3 — Cal­cu­late the unad­jus­ted PCU
4 — Deter­mine the Tech­ni­cal Com­ple­xity Fac­tor
5 — Deter­mine the Envi­ron­men­tal Com­ple­xity Fac­tor
6 — Cal­cu­late the adjus­ted PCU


With the results of these mea­su­re­ments and knowing the ave­rage pro­duc­ti­vity of the orga­ni­za­tion to pro­duce a PCU, the total effort for the pro­ject could be estimated.



28. What are the advantages of Function Point Analysis (FPA) in relation to Use Case Points (UCP)?


Firs­tly, it is neces­sary to demys­tify that only the UCP tech­ni­que is sui­ta­ble for mea­su­ring sys­tems whose requi­re­ments are expres­sed through Use Cases. The Func­tion Point Analy­sis (FPA) can be used nor­mally to these situ­a­ti­ons as well as for mea­su­ring sys­tems whose requi­re­ments were docu­men­ted using a dif­fe­rent methodology.


Some advan­ta­ges of Func­tion Point Analy­sis over UCP are lis­ted below:


1. The UCP can only be applied on soft­ware pro­jects whose spe­ci­fi­ca­tion has been expres­sed by Use Cases. The mea­su­re­ment of Func­tion Point Analy­sis (FPA) is inde­pen­dent of how the soft­ware requi­re­ments were expres­sed. This advan­tage of the Func­tion Point Analy­sis (FPA) was cited by Gus­tav Kar­ner in his ori­gi­nal work “Resource Esti­ma­tion for Objec­tory Pro­jects” (1993).


2. It´s not pos­si­ble to apply the UCP in the mea­su­re­ment of exis­ting appli­ca­ti­ons whose docu­men­ta­tion is either out­da­ted or even don´t exist. The alter­na­tive would be to write the Use Cases for these appli­ca­ti­ons and then mea­sure it! But this would make the mea­su­re­ment imprac­ti­ca­ble, on an analy­sis of cost ver­sus bene­fit. Using the Func­tion Point Analy­sis (FPA) is pos­si­ble to per­form the mea­su­re­ment by analy­zing the actual appli­ca­tion in use.


3. There is not a sin­gle stan­dard for wri­ting Use Cases. Dif­fe­rent sty­les of wri­ting Use Case or on its gra­nu­la­rity can lead to dif­fe­rent results in mea­su­re­ment using UCP. The mea­su­re­ment by FPA of the Use Cases for a sys­tem will even­tu­ally reach the same result regar­dless the wri­ting style of the Use Cases or its gra­nu­la­rity, because Func­tion Point Analy­sis (FPA) “bre­aks” the requi­re­ment at the appro­pri­ate level for the mea­su­re­ment using the con­cept of Ele­men­tary Process.


4. Due to the pro­cess of mea­su­ring of the UCP being based on Use Cases, the method can­not be employed prior to com­ple­ting the analy­sis of requi­re­ments of the pro­ject. In most cases there is a need to get an esti­mate before the end of this step. Also The Func­tion Point Analy­sis (FPA) pro­cess of mea­su­ring can only be used after the gathe­ring of the pro­ject requi­re­ments. But there are tech­ni­ques to esti­mate size in func­tion points that can be suc­ces­s­fully imple­men­ted before the requi­re­ments analy­sis is com­ple­ted. One exam­ple is the Indi­ca­tive and Esti­mate coun­ting pro­po­sed by NESMA. See the arti­cle Early Func­tion Points Count.


5. The UCP method does not include the mea­su­re­ment of soft­ware impro­ve­ment pro­jects (main­te­nance), only deve­lop­ment pro­jects. The Func­tion Point Analy­sis (FPA) addres­ses the mea­su­re­ment of deve­lop­ment pro­jects, impro­ve­ment pro­jects and appli­ca­ti­ons. These other types of mea­su­re­ment play an impor­tant role in metric pro­grams and in the hiring of soft­ware development.


6. There is no user group or orga­ni­za­tion res­pon­si­ble for the stan­dar­di­za­tion or evo­lu­tion of the UCP method, and the lite­ra­ture about this sub­ject is scarce. There isn´t an offi­cial kno­wledge body on UCP. To Func­tion Point Analy­sis (FPA), the IFPUG is res­pon­si­ble for main­tai­ning the Coun­ting Prac­ti­ces Manual — the kno­wledge body of the FPA, which is in con­ti­nu­ous evo­lu­tion. And there are also seve­ral dis­cus­sion forums about Func­tion Point Analy­sis (FPA) to exchange experiences.


7. The UCP method is not com­pli­ant with ISO/IEC 14.143 that defi­nes a model for the func­ti­o­nal mea­su­re­ment of soft­ware. The Func­tion Point Analy­sis (FPA), as the IFPUGmanual, is stan­dar­di­zed under ISO/IEC 20926 as a method of func­ti­o­nal mea­su­ring, adhe­ring to ISO/IEC 14.143.


8. There isn’t a cer­ti­fi­ca­tion pro­gram of pro­fes­si­o­nals who know the PCU tech­ni­que and apply it appro­pri­a­tely. The IFPUG has CFPS cer­ti­fi­ca­tion pro­gram for the Func­tion Point Analy­sis (FPA).


9. The envi­ron­men­tal fac­tor inser­ted into the UCP com­pli­ca­tes its appli­ca­tion in soft­ware metrics pro­grams and ben­ch­mar­king between orga­ni­za­ti­ons, because it makes the size of a pro­ject vari­a­ble, without even chan­ging its func­ti­o­na­lity. If the same pro­ject is deli­ve­red to two dif­fe­rent teams to score points by Use Case of this pro­ject, it will also be dif­fe­rent in each situ­a­tion. That is, the same pro­ject has two sizes!


10. The UCP deter­mi­na­tion of tech­ni­cal and envi­ron­men­tal fac­tors is sub­ject to a cer­tain degree of sub­jec­ti­vity which is dif­fi­cult to make the con­sis­tency of the method in dif­fe­rent orga­ni­za­ti­ons. The Func­tion Point Analy­sis (FPA) adjust­ment fac­tor also has the same pro­blem, although the IFPUG has spe­ci­fic gui­de­li­nes that help to mini­mize this impact. Howe­ver, the use of the adjust­ment fac­tor is opti­o­nal in the Func­tion Point Analy­sis (FPA) and the count of unad­jus­ted func­tion points is cur­ren­tly an objec­tive process.


Among the UCP disad­van­ta­ges quo­ted in rela­tion to Func­tion Point Analy­sis (FPA), some could be over­come with sim­ple adjust­ments. Howe­ver, there is no addi­ti­o­nal bene­fit ofUCP over Func­tion Point Analy­sis (FPA). Using both methods would not com­pen­sate the addi­ti­o­nal cost of mea­su­re­ment and the effort to train the staff in the two methods.


Although Func­tion Point Analy­sis (FPA) is not a per­fect tech­ni­que, there is a great matu­rity in the mar­ket regar­ding its use and IFPUG works con­ti­nu­ously to its evolution.



29. What kind of software can be measured by Function Points?


FPA is a tech­ni­que to mea­sure the func­ti­o­na­li­ties given by a soft­ware to the users; and this mea­su­re­ment is always made on an exter­nal pers­pec­tive, the users’ pers­pec­tive. Howe­ver, it is impor­tant to say that the con­cept of user for FPA is not only the one of the end-user of the soft­ware. The user for the FPA is any per­son or thing that inte­racts with the soft­ware at any time. In other words, the user for FPA can be both the per­son acting as end-user to the soft­ware and another soft­ware that uses the ser­vi­ces of the soft­ware in analy­sis.

Con­si­de­ring that every and any soft­ware exists to offer one or more ser­vi­ces (func­ti­ons) to some­one (per­son or thing); it is con­clu­ded that every and any soft­ware can be mea­su­red by Func­tion Points.


A usual mis­take for begin­ners with FPA is to use as the analy­sis’ point of view only the end-user view. In this case some softwa­res will be par­ti­ally (or com­ple­tely) “invi­si­ble” to this user. Then they mis­ta­kenly con­clu­des that FPA does not work for that soft­ware. The most com­mon is the per­son to learn the prin­ci­ples of the FPA applied to sys­tems with scre­ens and reports. Howe­ver, when this per­son faces softwa­res which do not have scre­ens, softwa­res with batch pro­ces­sing, mid­dlewa­res, basic softwa­res, it is natu­ral to have trou­ble at mea­su­ring.

Let’s ima­gine that the goal was to mea­sure a printer’s dri­ver. Well, there is no end-user (per­son) for this kind of soft­ware. In this pers­pec­tive, the printer’s dri­ver is invi­si­ble to the end-user. Howe­ver it exists to offer ser­vi­ces to some­one; in this case, the ope­ra­ting sys­tem. Thus, analy­zing the printer’s dri­ver in the pers­pec­tive of the ope­ra­ting sys­tem, it is pos­si­ble to see func­ti­ons, for exam­ple: to start the the prin­ter, inform the gene­ral situ­a­tion of the device, eject a sheet of paper, print, alert the level of the ink, etc...



30. Can FPA be used to produce estimates for acceptance and system testing?


In the lite­ra­ture, fre­quen­tly we face many dis­tor­ted sta­te­ments and ques­ti­ons regar­ding the tech­ni­que of func­tion point analy­sis, which does not show anything besi­des a lack of kno­wledge about the sub­ject. Who has not heard the false sta­te­ment “func­tion point analy­sis doesn’t serve to mea­sure object-oriented systems”?


More recen­tly, with the con­so­li­da­tion of the UML as the stan­dard mar­ket lan­guage for analy­sis and object-oriented design, another fre­quent false claim is that the func­tion point analy­sis is not meant to mea­sure sys­tems whose requi­re­ments were expres­sed accor­ding to spe­ci­fi­ca­ti­ons of use cases. A spe­ci­fic dis­cus­sion of this issue was pre­sen­ted in the March 2004 Bulletin.


Since the late 90’s a test mana­ge­ment tech­ni­que that ori­gi­na­ted in Hol­land, cal­led “TMap — Test Mana­ge­ment Appro­ach” is gai­ning fans, dri­ven by the wave of pro­cess impro­ve­ment ini­ti­a­ti­ves based on qua­lity stan­dards such as ISO and CMM. Its imple­men­ta­tion is sup­por­ted by a test esti­ma­tion tech­ni­que cal­led Test Point Analy­sis (TPA) which, so to speak, is based on Func­tion Point Analy­sis (FPA).


TPA is used spe­ci­fi­cally to esti­mate the effort requi­red in the exe­cu­tion of accep­tance tes­ting and sys­tem. For this, the TPA con­si­ders rele­vant, besi­des the func­ti­o­nal size deter­mi­ned by func­tion points, two other ele­ments: the tes­ting stra­tegy and the pro­duc­ti­vity. Even when the ele­ment is “size”, add more fac­tors that have more influ­ence on the effort then spe­ci­fi­cally in func­ti­o­nal size, as algo­rith­mic com­ple­xity, inte­gra­tion degree with other func­ti­ons and func­ti­o­nal uniformity.


Although it is a con­sis­tent and use­ful tech­ni­que for incre­a­sing the qua­lity of the pro­cess and soft­ware pro­duct, TPA pre­a­ches one more fuzzy con­cept on the analy­sis of func­tion point when it says that this can­not be used to esti­mate the effort in acti­vi­ties invol­ving accep­tance tes­ting and sys­tem. Neverthe­less , say this means that the Func­tion Point Analy­sis (FPA) con­si­ders the par­ti­cu­la­ri­ties of the deve­lop­ment pro­cess while applying the tech­ni­que of coun­ting. Which is not true.


The result of TPA appli­ca­tion is mea­su­red in a unit of effort (hours), unlike the func­tion point analy­sis, which mea­su­res the func­ti­o­nal size of soft­ware pro­ject. Thus, as indeed does not direc­tly mea­sure the effort used in the tests, the FPA also does not mea­sure the effort used in the analy­sis phase, design or cons­truc­tion of the soft­ware. Its main func­tion is to mea­sure the func­ti­o­na­lity deli­ve­red by the soft­ware pro­ject. Howe­ver, func­tion points can be used per­fec­tly well as an input to a pro­cess of effort esti­ma­tion of dif­fe­rent sta­ges of deve­lop­ment, as dis­cus­sed in the Janu­ary 2004 Bulletin.


The big­gest bene­fit of TPA is being able to gather, in a sys­te­ma­tic way, the fac­tors that influ­ence the effort of a spe­ci­fic stage of the deve­lop­ment pro­cess, pro­du­cing more accu­rate results.







31. What does the term “User” mean in terms of Function Point Analysis (FPA)?


When it comes to the infor­ma­tion tech­no­logy area the term “user” is usu­ally refer­ring to the per­son who uses or inte­racts with software.


As the Func­tion Point Analy­sis (FPA) a stan­dard method for mea­su­ring soft­ware from the user’s point of view, in this con­text, the term “user” has a bro­a­der mea­ning. Accor­ding to the Coun­ting Prac­ti­ces Manual, user is any per­son or thing that com­mu­ni­ca­tes or inte­racts with the soft­ware at any time. That is, beyond one per­son, a user may be a group of peo­ple who have a spe­ci­fic role during their inte­rac­tion with the soft­ware, the depart­ment mana­ger, another soft­ware or equip­ment. And for the Func­tion Point Analy­sis (FPA), inte­ract with the soft­ware means send data to the appli­ca­tion or receive data from it.


It should be noted that this defi­ni­tion of user has a mea­ning very close to the con­cept of an actor in a use case: any per­son or thing that inte­racts with the sys­tem and expects an obser­va­ble value result pro­du­ced by exe­cu­ting one or more cases of use.


Taking this user’s con­cept ampli­tude into con­si­de­ra­tion, during a func­tion points coun­ting should look at one pos­si­ble set of users whose vision best repre­sents the func­ti­ons that the appli­ca­tion pro­vi­des. For exam­ple, a bank appli­ca­tion for self-service that has as users: the bank cus­to­mer, the agency offi­cial, the depart­ment mana­ger. Base the count of this appli­ca­tion only in view of the end cus­to­mer and the bank’s self-service user is to have a limi­ted view of the appli­ca­tion. Also It is essen­tial to con­si­der the view of the user who spe­ci­fies the requi­re­ments and busi­ness rules, in this case, the depart­ment manager.



32. How does Function Point Analysis (FPA) define the term “Application”?


In the infor­ma­tion tech­no­logy area in gene­ral, the term “appli­ca­tion” is used to appoint an exe­cu­ta­ble pro­gram that meets a set of spe­ci­fic objec­ti­ves or one objec­tive for the users. As clas­si­cal exam­ples we can quote the Win­dows Cal­cu­la­tor, Word, etc.


Deve­lo­pers, in turn, tend to deter­mine the scope of appli­ca­ti­ons under the phy­si­cal seg­men­ta­tion of the soft­ware. Thus, a sin­gle set of rela­ted func­ti­ons is sepa­rate accor­ding to the fol­lowing tech­no­lo­gi­cal issues:


1) The phy­si­cal imple­men­ta­tion methods. For exam­ple, batch or online per­for­med functions


2) The phy­si­cal plat­form on which sub­sets of func­ti­ons reside. For exam­ple, main­frame or PC (low deck)


3) The archi­tec­tu­res under which the appli­ca­ti­ons are desig­ned. For exam­ple, desk­top, client-server, web, or 3-tier.


On Func­tion Point Analy­sis (FPA) , an appli­ca­tion is defi­ned accor­ding to the user’s view and accor­ding to busi­ness con­si­de­ra­ti­ons and not to tech­ni­cal issues. Accor­ding to the Coun­ting Prac­ti­ces Manual (CPM), an appli­ca­tion is a cohe­sive set of data and auto­ma­ted pro­ce­du­res that sup­port a busi­ness objec­tive, which may con­sist of one or more com­po­nents, modu­les or subsys­tems. Often, the term “appli­ca­tion” is used as a synonym for sys­tem, appli­ca­tion sys­tem or infor­ma­tion system.


For the func­tion points analy­sis the cor­rect unders­tan­ding of the term and, in turn, the cor­rect iden­ti­fi­ca­tion of an appli­ca­tion (enclo­sed by its boun­dary) is the basis for the con­sis­tent tech­ni­que use, avoi­ding over­si­zing or under­si­zing during the counts.



33. Is it possible to use FPA in a project using agile methodology?

Certainly! The APF is an technique that is independent of the technology used to model or implement software. Therefore, that software will have the same size in function points whether they use an agile methodology or any other approach.


What will distinguish the measurement of an agile project and other traditional methods are the artifacts that are being used to perform the analysis. In a more conventional approach, for example similar to RUP, artifacts used for measurement will probably be use case specifications, which are detailed descriptions of the functionality from the viewpoint of a user while interacting with the software.

In agile approach there is greater emphasis on delivering working software than producing a detailed documentation of what will be done. Therefore, it is more likely that user stories will be used in an agile methodology, which are brief descriptions of the desired functionality by the user.


However, user stories are not enough to provide all information necessary to measure function points (although they are sufficient to provide an estimate/approximation of the size in PFs). So how are we able to measure a project?


Sometimes, the developer cannot build the software only with the information provided by the user stories. More detailed requirements are necessary for one to build the desired software. Where can a developer attain more detailed information to build the desired software besides user stories? It is very likely that the developer will turn to the user. The agile methodology advocates that the user join the development team, having a very close interaction with the developers.


Therefore, assuming that the developer attains more detailed information about the requirements to build the software, that same information will be useful when counting FPs.




34. What are the objectives of the IFPUG’s Counting Practices Manual (CPM)?


• Pro­vide a clear and detai­led des­crip­tion on how to count func­tion points.

• Ensure that the counts are con­sis­tent with the prac­ti­ces of coun­ting rea­ched by IFPUGaffi­li­a­ted members.


• Pro­vide gui­dance on how to per­form func­tion points counts based on arti­facts of the tech­ni­ques and metho­do­lo­gies com­monly used in soft­ware development.


• Pro­vide a com­mon unders­tan­ding so that deve­lo­pers of tools pro­vide auto­ma­ted supp­port to the func­tion points counting.


• Be com­pli­ant to the ISO / IEC 14143–1 Mea­su­re­ment of func­ti­o­nal software.



35. How is the process of function point counting method?


Bri­e­fly, the func­tion points sco­ring pro­cess con­sists on the fol­lowing steps:


1. Iden­ti­fi­ca­tion of the coun­ting purpose.


In this step, the goal is to make clear what you want to achi­eve with the count that will be done, what pro­blem could be sol­ved with it. The way as the steps are con­duc­ted depends direc­tly on this purpose.


2. Deter­mi­ning the type of count.


There are three types of func­tion points coun­ting. The dif­fe­rence between the pro­ce­du­res adop­ted in these types of counts is in the applied for­mula on the final step of the count.


- Deve­lop­ment pro­ject: mea­su­res all func­ti­ons that the pro­ject will deli­ver and pos­si­ble data con­ver­sion func­ti­ons.
- Impro­ve­ment pro­ject: mea­su­res the alte­red func­ti­ons, inclu­ded and exclu­ded by the pro­ject and pos­si­ble data con­ver­sion func­ti­ons.
- Appli­ca­tion: mea­su­res the func­ti­ons of an ins­tal­led software.


3. Appli­ca­tion boun­dary iden­ti­fi­ca­tion and the scope of the count.


The boun­dary of the appli­ca­tion is the con­cep­tual inter­face between soft­ware and user. It deli­mits the soft­ware and the out­side world. It is an essen­tial ele­ment for the cor­rect data func­ti­ons and tran­sac­ti­ons iden­ti­fi­ca­tion in the fol­lowing steps. The coun­ting scope defi­nes what will be part of the func­tion points count.


4. Coun­ting the data type functions.


The data type func­ti­ons repre­sent sto­rage requi­re­ments of the user. It’s clas­si­fied as:


- Inter­nal Logi­cal Files (ILF): groups of logi­cally rela­ted data (from the user’s view­point) and main­tai­ned by the appli­ca­tion itself.

- Exter­nal Inter­face Files (EIF): groups of logi­cally rela­ted data (from the user’s view­point) and only refe­ren­ced from other applications.


In this step all system’s ILF/EIF are iden­ti­fied. The com­ple­xi­ties are deter­mi­ned based on two para­me­ters (data types and record types)and; asso­ci­a­ted to each com­ple­xity there is an amount of func­tion points relative.


5. Count of tran­sac­tion type functions.


The tran­sac­tion type func­ti­ons repre­sent pro­ces­sing requi­re­ments of the user. It’s clas­si­fied as:


- Exter­nal Inputs (EI): tran­sac­ti­ons in order to update inter­nal logi­cal files or modify the sys­tem beha­vior.
- Exter­nal Inqui­ries (EQ): tran­sac­ti­ons that repre­sent sim­ple retri­e­val of logi­cal files and/or inter­nal or exter­nal inter­face files.
- Exter­nal Out­puts (EO): tran­sac­ti­ons for the pur­pose of pre­sen­ting infor­ma­tion, but invol­ving addi­ti­o­nal logic pro­ces­sing to an exter­nal inquiry.


In this step all sys­tem tran­sac­ti­ons are iden­ti­fied . Its com­ple­xi­ties are deter­mi­ned based on two para­me­ters (data types and refe­ren­ced files); and to each com­ple­xity asso­ci­a­ted there is an amount of func­tion points corresponding.


6. Cal­cu­la­tion of adjust­ment factor.


The adjust­ment fac­tor repre­sents the influ­ence of tech­ni­cal and qua­lity requi­re­ments in the soft­ware size. It is cal­cu­la­ted based on the 14 Sys­tem Over­view (CGS) lis­ted below:

(1) Data Com­mu­ni­ca­tion
(2) Dis­tri­bu­ted Pro­ces­sing
(3) Per­for­mance
(4) Hea­vily Used Con­fi­gu­ra­tion
(5) Volume of Tran­sac­ti­ons
(6) Online Data Entry
(7) End-User Effi­ci­ency
(8) Online Update
(9) Pro­ces­sing Com­ple­xity
(10) Reuse
(11) Ease of ins­tal­la­tion
(12) Ease of ope­ra­tion
(13) Mul­ti­ple Loca­ti­ons
(14)Easy changes


Each of these cha­rac­te­ris­tics should be revi­ewed with res­pect to its level of influ­ence over the sys­tem and sco­red from 0 (no influ­ence) to 5 (great influ­ence). Then add all these sco­res to obtain the total level of influ­ence (TDI). Then sim­ply apply the fol­lowing for­mula to obtain the adjust­ment fac­tor: VAF = (TDI x 0.01) + 0.65.


Cur­ren­tly this is an opti­o­nal step in the coun­ting pro­cess. Many orga­ni­za­ti­ons over­look the adjust­ment fac­tor and use only the mea­su­re­ment of unad­jus­ted func­tion points. Still, the gui­de­li­nes for deter­mi­ning the VAF can be use­ful to help dis­tin­guish between func­ti­o­nal requi­re­ments and tech­ni­cal or qua­lity requi­re­ments.

7. Cal­cu­la­tion of adjus­ted func­tion points.


The final cal­cu­la­tion of adjus­ted func­tion points is basi­cally the adjust­ment fac­tor mul­ti­plied by the unad­jus­ted func­tion points. But there are spe­ci­fic for­mu­las for each type of score:

- Deve­lop­ment pro­ject: DFP = (UFP + CFP) x VAF, where:

UFP — func­tion points of the appli­ca­tion to be ins­tal­led
CFP — func­tion points of the data con­ver­sion fea­tu­res
VAF — value of adjust­ment factor


- Impro­ve­ment Pro­ject: EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB), where:


ADD — func­tion points of the added fea­tu­res
CHGA – func­tion points of the alte­red fea­tu­res
CFP — func­tion points of the data con­ver­sion fea­tu­res
VAFA — value adjust­ment fac­tor of the soft­ware after the impro­ve­ment pro­ject
DEL — func­tion points of the exclu­ded fea­tu­res
VAFB — value adjust­ment fac­tor of the soft­ware before the impro­ve­ment project


- Appli­ca­tion: AFP = ADD x VAF



36. Which productivity indicator (function points / man month) or delivery rate (hours per function point) should be used to estimate the effort


There is a great temp­ta­tion among pro­fes­si­o­nals invol­ved in esti­ma­tes to use the term named “mar­ket” indi­ca­tors for esti­ma­tes based on func­tion points. Cer­tainly there are seve­ral sour­ces where you can get num­bers rela­ted to pro­duc­ti­vity in func­tion points for vari­ous tech­no­lo­gi­cal con­texts. The ISBSG (Inter­na­ti­o­nal Soft­ware Ben­ch­mar­king Stan­dards Group) is one of it. Howe­ver, using these sour­ces dis­re­gar­ding the con­text of how those num­bers were obtai­ned and the con­text of it own orga­ni­za­tion is a seri­ous mis­take. Esti­ma­tes obtai­ned on this way will har­dly have the neces­sary reli­a­bi­lity or any prac­ti­cal use.


The best way to get the pro­duc­ti­vity indi­ca­tors that are actu­ally use­ful in the esti­ma­tion of func­tion points is to deter­mine this indi­ca­tor through pro­jects deve­lo­ped by the orga­ni­za­tion. But how?


The first step is to reco­ver from the past pro­jects the two mag­ni­tu­des that com­pose the pro­duc­ti­vity indi­ca­tor: size (in func­tion points) and effort (hours). With these two datas the pro­duc­ti­vity of that pro­ject can be achi­e­ved direc­tly. But if each pro­ject has a dif­fe­rent num­ber of pro­duc­ti­vity, which must be employed on the pro­ject to be estimated?


Cer­tainly, each pro­ject may have a dif­fe­rent num­ber, but if this pro­ce­dure is repe­a­ted for a lar­ger set of pro­jects, it will be pos­si­ble to observe that for cer­tain sub­sets the pro­duc­ti­vity is quite simi­lar. This hap­pens when pro­jects have simi­lar cha­rac­te­ris­tics in rela­tion to fac­tors that direc­tly affect the effort to deve­lop them. So It is rea­so­na­ble to con­clude that depen­ding on the nature of the pro­jects deve­lo­ped by the orga­ni­za­tion, there won’t be just one indi­ca­tor of pro­duc­ti­vity for all pro­jects of the orga­ni­za­tion, but pro­duc­ti­vity indi­ca­tors for groups of simi­lar design. Thus, the first step to esti­mate a new pro­ject is to frame it in a group of pro­jects and then use the appro­pri­ate indi­ca­tor of pro­duc­ti­vity. But what are the fac­tors that define these groups of projects?


Any vari­a­ble that is capa­ble of pro­du­cing a sig­ni­fi­cant impact in the design effort should be remem­be­red in that seg­men­ta­tion analy­sis of pro­ject groups. It should be stres­sed that the fac­tors may dif­fer from orga­ni­za­tion to orga­ni­za­tion. For exam­ple, the use or nonuse of a par­ti­cu­lar sys­tems deve­lop­ment metho­do­logy in the pro­ject may affect it pro­duc­ti­vity. Howe­ver, if a par­ti­cu­lar com­pany fol­low the same metho­do­logy for all the pro­jects , this fac­tor will be cons­tant and won’t have rele­vance to the seg­men­ta­tion of projects.


Without the intent to esta­blish a com­plete list, the fol­lowing fac­tors can be cited:


- Type of pro­ject: deve­lop­ment, impro­ve­ment, migra­tion, rede­ve­lop­ment, etc.
– Tech­no­lo­gi­cal plat­form, main­frame, web, cli­ent x ser­ver, embed­ded sys­tem, etc.
– Size of the pro­jects
– Size of the deve­lop­ment team
– Deve­lop­ment tools
– Metho­do­logy
– Busi­ness Area
– Num­ber of users



37. Where can I find the IFPUG’s Counting Practices Manual?


The coun­ting prac­tice manual is only pro­vi­ded by IFPUG. For the affi­li­a­tes it is avai­la­ble for free down­load. For non-members it must be pur­cha­sed direc­tly from the IFPUG. Unfor­tu­na­tely the manual is not avai­la­ble for public and free access, hin­de­ring the dif­fu­sion of func­tion points tech­ni­que. The orga­ni­za­ti­ons res­pon­si­ble for other methods of func­ti­o­nal mea­su­ring as the Mark II (UKSMA) and COSMIC-FFP (COSMIC) pro­vide free access to their manuals.


The ori­gi­nal ver­sion of the IFPUG manual is in English. Ver­si­ons in other lan­gua­ges are avai­la­ble in Spa­nish, Ita­lian, Korean, and also in Portuguese.



38. How many function points an analyst can count in a day?


There is a wide vari­a­tion of func­tion points coun­ting pro­duc­ti­vity per day for a pro­fes­si­o­nal, mainly cau­sed by:


1. Kno­wledge of the busi­ness on which the project/system works: if the metrics analyst has the kno­wledge of the busi­ness, will be easy to take the mea­su­re­ment, even if the docu­men­ta­tion of the project/system doesn’t have a good quality.


2. Qua­lity of docu­men­ta­tion avai­la­ble: the main source of infor­ma­tion for coun­ting is the docu­men­ta­tion of the project/system. If the docu­men­ta­tion is incom­plete or ambi­guous, more time will be con­su­med to elu­ci­date ques­ti­ons con­cer­ning the requi­re­ments. Insuf­fi­ci­ent docu­men­ta­tion for the mea­su­re­ment is the most com­mon pro­blem for­counts of appli­ca­tion and impro­ve­ment projects.


3. Coun­ters expe­ri­ence: the more expe­ri­ence the analyst takes on sco­res, fas­ter in requi­re­ments analy­sis he will be. He learns to search for what infor­ma­tion is rele­vant to mea­sure in the docu­men­ta­tion and dis­re­gard what does not mat­ter (saving time in analy­sis of something that will not affect the mea­su­re­ment). The expe­ri­ence also avoids was­ting time in analy­sis of situ­a­ti­ons he has alre­ady dealt before.


4. Users avai­la­bi­lity: often even with the avai­la­ble sys­tem docu­men­ta­tion, it is neces­sary to inter­view users to sup­ple­ment any need of infor­ma­tion that was not docu­men­ted or docu­men­ted on an unclear way. For legacy sys­tems that lack docu­men­ta­tion, the only way to mea­sure it is with the sup­port of users. If no user is avai­la­ble to sup­ply infor­ma­tion, the metrics analyst will be wai­ting such avai­la­bi­lity to be able to con­ti­nue the measurement.


5. Pur­pose of the count: depen­ding on the ques­tion that you want to answer with the count, the accu­racy of the count and tra­ce­a­bi­lity may not be pri­mary issues. So the docu­men­ta­tion can be analy­zed in a more super­fi­cial way and also avoid an addi­ti­o­nal effort on the docu­men­ta­tion of the count itself. In other words, you can cho­ose a size esti­mate ins­tead of the mea­su­re­ment pro­perly . Even the mea­su­re­ment can be made with dif­fe­rent levels of docu­men­ta­tion, which influ­ence the time spent in this activity.


6. Pro­cess Auto­ma­tion: sup­port soft­ware can haste the count, espe­ci­ally the parts of the pro­cess that does not involve the analysis.


7. Type of count: usu­ally the pro­duc­ti­vity to count impro­ve­ment pro­ject is higher than for pro­ject deve­lop­ment or appli­ca­tion count, espe­ci­ally if the appli­ca­tion that is suf­fe­ring main­te­nance (object of the impro­ve­ment pro­ject) has alre­ady been coun­ted. But the reverse can also occur if the mea­su­re­ment is for a pro­ject impro­ve­ment of an appli­ca­tion that has never been mea­su­red and has lit­tle docu­men­ta­tion available.


8. Count Guide: The count guide is a docu­ment that sim­pli­fies and con­tex­tu­a­li­zes theIFPUG rules for spe­ci­fic situ­a­ti­ons within an orga­ni­za­tion. For analysts with lit­tle expe­ri­ence or lit­tle kno­wledge of the con­text of the orga­ni­za­tion, the guide will make the mea­sure much easier , pro­vi­ding agility.


Loo­king at a worst-case sce­na­rio, where the above men­ti­o­ned fac­tors would be a nega­tive influ­ence on the mea­su­re­ment work, a lower limit for the pro­duc­ti­vity would be 100FP/day. For a best-case sce­na­rio would be rea­so­na­ble to con­si­der 1000 PF/day. It should be noted that the ave­rage pro­duc­ti­vity is not in the mid­dle of this range, but clo­ser to the worst-case sce­na­rio, which cor­res­ponds to situ­a­ti­ons that are more com­mon to find in every­day life. Depen­ding on the spe­ci­fi­ci­ties that an orga­ni­za­tion has, it could even­tu­ally pro­duce num­bers out­side the men­ti­o­ned range, but would not be a typi­cal beha­vior expec­ted. Pro­duc­ti­vity under 100 FP/day is a sign of trou­ble, the cau­ses should be inves­ti­ga­ted . Often the metrics analyst per­forms acti­vi­ties of requi­re­ments analy­sis, due to the lack of docu­men­ta­tion or low qua­lity of it. It would not be cor­rect to com­pute this effort as the mea­su­re­ment, but from requi­re­ments analysis.


It’s worth noting that pro­duc­ti­vity is not cons­tant throughout the pro­cess. The time of pre­pa­ra­tion, docu­men­ta­tion exa­mi­na­tion, answer the ques­ti­ons is more usual in the begin­ning of the count than in the count itself. After these steps the count will flow more quickly.

39. What tools are suitable for support and/or automate the use of Function Point Analysis (FPA)?


The first point to note in this issue is that there are no tools able to auto­ma­ti­cally pro­duce a reli­a­bly func­tion points count. Howe­ver there are tools avai­la­ble that can sup­port and par­ti­ally auto­mate the pro­cess of func­tion points count and also to store and manage the results of the counts.


The sim­plest tool to be used to record a func­tion points count is a spread sheet. In the sec­tion “resour­ces” of our web­site is fre­ely avai­la­ble a for­mat­ted spre­adsheet for func­tion points counts. Des­pite being the first and sim­plest tool to be used for many pro­fes­si­o­nals, it’s use begins to be imprac­ti­cal as it inten­si­fies the num­ber of counts. The con­trol of the count repo­si­tory is usu­ally manual, and with the incre­a­sing of data amount, the task beco­mes costly.

When the orga­ni­za­tion rea­li­zes that the spre­adsheet no lon­ger meets it needs, a natu­ral evo­lu­tion is to search tools with more resour­ces on the mar­ket. The IFPUG has a cer­ti­fi­ca­tion pro­cess for the tools to sup­port the func­tion points count. The list of tools cur­ren­tly cer­ti­fied can be viewed in Accor­ding to this pro­cess, the tools can be clas­si­fied into three types:


Type 1: The user does the func­tion points count manu­ally and the soft­ware pro­vi­des func­ti­o­na­li­ties for data col­lec­tion and calculations.


Type 2: The soft­ware pro­vi­des the func­ti­o­na­li­ties for data col­lec­tion and cal­cu­la­ti­ons, and the user and the sys­tem do the inte­rac­tive func­tion points count, using ques­ti­ons sub­mit­ted by the sys­tem and acti­ons being taken auto­ma­ti­cally depen­ding on the answers provided.


Type 3: The soft­ware auto­ma­ti­cally pro­du­ces a func­tion points count using vari­ous sour­ces of infor­ma­tion such as the data­base appli­ca­tion, the appli­ca­tion itself and arti­facts of the deve­lop­ment tools. The user can enter with the data inte­rac­ti­vely, but his invol­ve­ment is mini­mal during the count. It is impor­tant to tell that there are no such tools certified.


Although there are seve­ral opti­ons of tools on the mar­ket to sup­port the use of func­tion points, many orga­ni­za­ti­ons cho­ose to deve­lop an own tool inte­gra­ted to it sys­tems of inter­nal con­trol. Some rea­sons for this may be:

– The cost to deve­lop an inter­nal solu­tion is less than the cost of acqui­si­tion and main­te­nance of pac­ka­ges avai­la­ble on the mar­ket

– Lack of local sup­port for the solu­tion, due to the fact that most tools on the mar­ket are foreign


– Needs to inte­grate with inter­nal systems



40. Is the size of a software’s unadjusted function points determinant for the specification of the hardware needed for its execution? Why?


When it comes to hard­ware requi­re­ments for the exe­cu­tion envi­ron­ment of a par­ti­cu­lar soft­ware, the focus of the issue is on the tech­ni­cal or qua­lity requi­re­ments , as pro­ces­sing power, volume and tran­sac­tion data, num­ber of users, secu­rity, etc… The func­ti­o­nal requi­re­ments do not affect anything in this mat­ter. The­re­fore, there is no direct rela­ti­onship between the size of a soft­ware in func­tion points (whether it’s adjus­ted or not) with the neces­sary hard­ware for its implementation.


But the adjust­ment fac­tor, analy­zed in iso­la­tion from the  func­ti­o­nal size, inclu­des many gene­ral sys­tem fea­tu­res  (Dis­tri­bu­ted Pro­ces­sing, Per­for­mance, Hea­vily Used Con­fi­gu­ra­tion, Volume Tran­sac­tion) that could assist on the  defi­ni­tion  of the hard­ware requi­re­ments of a  soft­ware, but it would be an insuf­fi­ci­ent analy­sis to define the hardware .

41. Is it possible to apply Function Point Analysis (FPA) for system maintenance projects?


Yes, but not all of the soft­ware main­tance are likely to be mea­su­red with Func­tion Point Analy­sis (FPA). Only the main­tan­ces that change the soft­ware func­ti­o­nal requi­re­ments can be mea­su­red by the Func­tion Point Analy­sis (FPA), in this case IFPUG uses the term “impro­ve­ment” ins­tead of “main­tance”, exac­tly to make a point that the impro­ve­ment is not any kind of main­tance. In IFPUG’s con­cept , the impro­ve­ment mea­su­res all the func­ti­ons that will be added, chan­ged or exclu­ded from the apli­ca­tion, as well as even­tual func­ti­ons of data conversion.


Main­tance for cor­rec­tion of defects or to keep only non func­ti­o­nal requi­re­ments are not mea­su­red by Func­tion Point Analy­sis (FPA).



42. At what point of the life cycle of a software project function points can be counted?


The only infor­ma­tion requi­red for soft­ware to count func­tion points are its func­ti­o­nal requi­re­ments. Once the requi­re­ments are esta­blished, in wha­te­ver phase the pro­ject is, it’s pos­si­ble to achi­eve the mea­sure of its size. It’s impor­tant to know that the man­ner in which its requi­re­ments are docu­men­ted or expres­sed is irre­le­vant to the mea­su­re­ment, it just rein­for­ces that the Func­tion Point Analy­sis (FPA) mea­su­res the soft­ware in an inde­pen­dent way in which it is mode­led, desig­ned or constructed.


But it is valid to raise the fol­lowing ques­tion: if you can only count func­tion points after defi­ning the requi­re­ments, how to pro­duce esti­ma­tes for the pro­ject before that time, which is pre­ci­sely where the need for esti­ma­tes is more reques­ted? In this case func­tion points can still be useful?


Although it’s not pos­si­ble to count func­tion points in the early sta­ges of the pro­ject (before detai­ling requi­re­ments), it is still pos­si­ble to esti­mate its size in func­tion points. There are seve­ral tech­ni­ques to esti­mate the size in func­tion points of a soft­ware, among the most com­mon two were pro­po­sed by the Dutch asso­ci­a­tion of metrics — NESMA. Those are the indi­ca­tive count and the esti­mate count, detai­led in .



43. Is the Function Point Analysis (FPA) a software projects management technique?


No, the Func­tion Point Analy­sis (FPA) is a method for the mea­su­re­ment of the func­ti­o­nal size of a soft­ware. It quan­ti­fies only the fea­tu­res that the soft­ware pro­vi­des to users. Howe­ver the tech­ni­que can be one tool among many avai­la­ble, that the pro­ject mana­ger can use to sup­port him in the management.


The mea­su­re­ment pro­cess as much as the result of mea­su­re­ment, helps to bring visi­bi­lity to vari­ous aspects of the pro­ject such as scope and requirements.


The asso­ci­a­tion between func­ti­o­nal size and other quan­ti­ties such as effort, cost, num­ber of defects, allows the gene­ra­tion of use­ful indi­ca­tors for the mana­ge­ment to moni­to­ring pro­duc­ti­vity and qua­lity. The pro­duc­ti­vity indi­ca­tor is widely used to gene­rate esti­ma­tes (based on func­tion points) for the project.





44. Does the Function Point Analysis (FPA) overload a software project?


The essence of the Func­tion Point Analy­sis (FPA), pre­a­ched by IFPUG, is that the pro­cess of func­tion points count should be con­sis­tent (dif­fe­rent peo­ple mea­su­ring the same pro­ject should find simi­lar results) as well, but mainly that the count is sim­ple enough to mini­mize the mea­su­re­ment effort, redu­cing the impact on the ove­rall effort of the project.


Like any other acti­vity of deve­lop­ment pro­ject or soft­ware main­te­nance, make a func­tion points count requi­res the effort of a pro­fes­si­o­nal of the team. So there will be an addi­ti­o­nal effort in the pro­ject to arrange the measurement.


What you should con­si­der is that the bene­fits obtai­ned by per­for­ming a mea­su­re­ment outweigh the addi­ti­o­nal effort expen­ded. In the­ory, the soft­ware can be deve­lo­ped only with the coding acti­vi­ties, but other acti­vi­ties are under­ta­ken (such as analy­sis, plan­ning, mode­ling, tests , etc.) that will “encum­ber” the effort of the pro­ject but that pro­vide bene­fits that outweigh this extra effort.


Trans­la­ting into num­bers, the ideal would be that this effort cau­sed by the mea­su­re­ment doesn’t exceed 2% of the total pro­ject effort. It’s impor­tant to know that , in many cases where it does not occur, the cause is a defi­ci­ency in the requi­re­ments spe­ci­fi­ca­tion. In these cases the big­ger part of the efforts of the func­tion points count ends up being con­su­med in inter­vi­ews, revi­ews and detai­ling requi­re­ments. Acti­vi­ties that should have been held during the spe­ci­fi­ca­tion itself.



45. Which activities are included in the effort estimation (using function points) of a software project?


Basi­cally all the acti­vi­ties that have a direct rela­ti­onship with the cons­truc­tion and deli­very of the func­ti­o­nal requi­re­ments: sur­vey and requi­re­ment spe­ci­fi­ca­tion, analy­sis, pro­ject , mode­ling, pro­ject mana­ge­ment, coding, tests , user appro­val sup­port, deploy­ment and trans­fer of kno­wledge of the ser­vice exe­cu­ted. Since many arti­facts can be pro­du­ced in these acti­vi­ties, such as source code, dia­grams, models, use cases, manu­als, plans, minu­tes, etc..


In addi­tion to the pre­ce­ding para­graph, any acti­vi­ties not direc­tly rela­ted to the func­ti­o­nal requi­re­ments of the pro­ject deve­lop­ment / soft­ware main­te­nance are not within the scope of the esti­mate by Func­tion Point (FP). Exam­ples: users trai­ning , pro­duc­tion sys­tem moni­to­ring, data­base mana­ge­ment, answe­ring ques­ti­ons or com­plaints from users, acti­vi­ties to sup­port the tech­no­logy infras­truc­ture, etc..


Also an esti­mate can be held for only a few spe­ci­fic pro­ject acti­vi­ties. For this is neces­sary to know the effort dis­tri­bu­tion (%) that each phase usu­ally con­su­mes from the entire pro­ject. Knowing this rela­tion, the total pro­ject effort can be esti­ma­ted and the per­cen­tage of each phase desi­red can be applied to know the esti­ma­ted effort for those activities.



46. What are the main causes of errors in a function points counting?


Most of the errors found in a sys­tem of func­tion points count is cau­sed by four factors:


- Lack of the tech­ni­que : there is still a large num­ber of staff that are assig­ned to count func­tion points of a sys­tem without the neces­sary kno­wledge of the coun­ting pro­cess. Perhaps this occurs because there is wides­pread belief that the Func­tion Point Analy­sis (FPA) is very sim­ple. And indeed it is, but this does not mean it is not neces­sary pro­fes­si­o­nal trai­ning or a more dedi­ca­ted study of the tech­ni­que. With only a super­fi­cial kno­wledge of Func­tion Point Analy­sis (FPA) it’s quite likely that the analyst makes mis­ta­kes. On this aspect, the IFPUG esta­blished its pro­fes­si­o­nal cer­ti­fi­ca­tion pro­gram CFPS, which aims to ensure that the cer­ti­fied pro­fes­si­o­nal knows all the defi­ni­ti­ons and rules of its Coun­ting Prac­ti­ces Manual in its latest version.


- Allow the count be “con­ta­mi­na­ted” by the imple­men­ta­tion: Func­tion Point Analy­sis (FPA) is a tech­ni­que for mea­su­ring the func­ti­o­nal requi­re­ments of a soft­ware. In other words, mea­su­res what the user requests and recei­ves from the soft­ware regar­dless of how it was imple­men­ted. The­re­fore, the result of a func­tion points count must be the same, wha­te­ver the solu­tion of imple­men­ta­tion (pro­cess, archi­tec­ture, tools, com­pu­ting envi­ron­ment, etc.) taken by the deve­lo­per. Count func­tion points of a sys­tem is an exer­cise for abs­trac­tion of the user’s busi­ness pro­blem that the soft­ware must attend . But this is not always an easy task and even expe­ri­en­ced func­tion points analysts can shift the focus from the count to the deve­lo­per imple­men­ta­tion solu­tion. Often the analyst is indu­ced to this way for lack of pro­per documentation.


- Lack of busi­ness kno­wledge: there is no use being a spe­ci­a­list in Func­tion Point Analy­sis (FPA) and do not know the user busi­ness. To the func­tion points count be done cor­rec­tly, in other words, from the user’s point of view, it is neces­sary that the func­tion point analyst seeks to unders­tand the busi­ness first and only then do the func­tion points coun­ting. Often there is no time avai­la­ble to the point analyst seeks this kno­wledge. In this case he will act in part­nership with a busi­ness analyst or a user to be able to do the func­tion points count .


- Qua­lity of the requi­re­ments avai­la­ble: much is said in soft­ware engi­ne­e­ring on the impor­tance of the gathe­ring requi­re­ments and the impact that it has on the whole pro­ject when this task is not well exe­cu­ted. To the func­tion points count it’s not dif­fe­rent. If the docu­ments from where the func­tion point analyst extracts the user requi­re­ments to con­duct the count are ambi­guous, incom­plete or poorly writ­ten, almost cer­tainly that the result of the count will be affected.


This rela­tion of fac­tors is not pre­sen­ted in any par­ti­cu­lar order, but it’s fairly repre­sen­ta­tive of the main fac­tors that cause func­tion points count being in an incor­rect way.



47. What documents are needed for a function points counting?


There is not a spe­ci­fic docu­ment that is man­da­tory for mea­su­ring a soft­ware (or count func­tion points). Any docu­ment on which can be extrac­ted infor­ma­tion from the user requi­re­ments can be used on a func­tion points count.Whether they are use cases, manu­als, pro­toty­pes, vision docu­ments, data model, class model, etc.. This is con­sis­tent with the very pur­pose of the Func­tion Point Analy­sis (FPA) to be a tech­ni­que that is inde­pen­dent of the soft­ware imple­men­ta­tion. You can imple­ment a soft­ware by using dif­fe­rent methods and tools for analy­sis, mode­ling and cons­truc­tion for vari­ous com­pu­ting plat­forms, but none of this affects the mea­su­re­ment of the same in func­tion points.


It is clear that cer­tain types of docu­ments can pro­vide the neces­sary infor­ma­tion for a func­tion points count more easily. Other docu­ments may con­tain only part of the infor­ma­tion requi­red for the coun­ting of FPs, requi­ring the joint analy­sis of all docu­ments to make the mea­su­re­ment. As well as other docu­ments, because they have a more tech­ni­cal pro­cess for soft­ware deve­lop­ment, may be more dif­fi­cult to extract the user requi­re­ments. The best docu­ment to be used to count FP’s is one that con­tains the expli­cit user requi­re­ments in its busi­ness lan­guage, not on an IT language.


Each orga­ni­za­tion has its spe­ci­fic deve­lop­ment pro­cess, pro­du­cing a num­ber of docu­ments (or arti­facts) dis­tincts in a cer­tain sta­ges of the pro­cess. The­re­fore, the time at which the mea­su­re­ment is done also deter­mi­nes which docu­ments will be avai­la­ble to do the work of measurement(or esti­mate) of the pro­ject func­ti­o­nal size.




48. How significant are the software requirements for Function Point Analysis (FPA)?


The soft­ware requi­re­ments are fun­da­men­tal to the Func­tion Point Analy­sis (FPA), since the mea­su­re­ment pro­cess is based exclu­si­vely on them. The basic inputs of the mea­su­re­ment are the sys­tem requi­re­ments. It should be noted that the Func­tion Point Analy­sis (FPA) mea­su­res only a part of the user requi­re­ments for the sys­tem: the func­ti­o­nal requi­re­ments. Non-functional requi­re­ments are not mea­su­red by the Func­tion Point Analy­sis (FPA). Howe­ver in a model of cost esti­ma­tion based on FP (cost = size x $ / PF), both types of requi­re­ments (func­ti­o­nal and non­func­ti­o­nal) are con­si­de­red: the first will affect the func­ti­o­nal size and the second will affect the unit cost ($ / PF).


Due to this impor­tance of the requi­re­ments for the Func­tion Point Analy­sis (FPA), how bet­ter the qua­lity requi­re­ments is, easier and fas­ter beco­mes the mea­su­re­ment pro­cess, and more accu­rate the result will be. Bad qua­lity requi­re­ments nega­ti­vely affect the entire soft­ware pro­ject, inclu­ding the mea­su­re­ment acti­vity. But a bene­fi­cial side effect of the mea­su­re­ment pro­cess is cle­arly demons­tra­ted fai­lu­res in the requi­re­ments. soo­ner these faults in the pro­ject are iden­ti­fied, lower is the cost to cor­rect them, and gre­a­ter is the chance of the pro­ject success.