Questions and answers about Function Point of Analysis

 

We have a complete list of our frequently asked questions about Function Point Analysis that were developed from trainings, workshops, consulting services and discussions provided by FATTO Software Consulting.

 

We understand that this list is very useful for our clients and also for all website visitors interested in Function Point Analysis. It will provide help to them. We review and update this with frequently new questions.

 

 

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

 

Func­tion Point Analy­sis (FPA) is a software measurement tech­ni­que based on the users point of view. It measures the software functions and Func­tion Point (FP) is its mea­su­ring unit. The method 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 estimation 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 soft­ware projects.

 

 

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

 

Func­tion Point Analy­sis (FPA) was invented in 1970's 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. To do this he developed a method to measure software inde­pen­dently of the pro­gram­ming lan­guage used, chec­king only the exter­nal aspects of the soft­ware, primarly 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.

 

Nowadays, the standard recog­ni­zed for Func­tion Point Analy­sis (FPA) is defined in Coun­ting Prac­ti­ces Manual (CPM) mantained 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­tenance by the use of the Func­tion Point Analysis.

 

 

 

 

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 a peer review process.

 

- A tool for esti­ma­ting costs and resour­ces for software development and main­ta­nance. 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 software deve­lop­ment and 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­s is that it is based on the USERS POINT OF VIEW, 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 its imple­men­ta­tion. This mea­su­re­ment is based only on the requi­re­ments that the soft­ware must attend to.

 

 

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 of 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 first publi­ca­tion of Func­tion Point Analysis proposed 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 gist 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, deve­lop­ment metho­do­logy or pro­gram­ming lan­guage used for its construction.

 

After the foun­ding of IFPUG in 1986, sys­te­ma­ti­c and 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 the editing and updating of 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 the 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 func­tion point counts accu­rately and con­sis­tently and that also know the IFPUG’s latest coun­ting practices.

 

To be cer­ti­fied, the pro­fes­si­o­nal must pass the exam that is pre­pa­red by IFPUG whose mini­mum grade to pass 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 pass because of the time avai­la­ble and high accu­racy rate, but unfor­tu­na­tely the IFPUG does not dis­close any infor­ma­tion in regards to pass/fail exam rates.


The cer­ti­fi­cate is valid for three years, after this the owner must take 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 allows you to extend the certification validity by two years 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 or her cer­ti­fi­ca­tion.

Until the start of early 2008, the cer­ti­fi­ca­tion exa­mi­na­tion was con­duc­ted by paper with a manual cor­rec­tion. From July 2008 on, the exam was auto­ma­ted and became applied by any Pro­me­tric accre­di­ted cen­ter in the world. From November 2016 on, iSQI started to apply the exam, instead of Prometric, in the Flex mode, wich means that the candidate can apply for the exam at home if desired. You can cho­ose between having the test in English, Por­tu­guese or Italian.

There is no prerequisite of higher edu­ca­tion, evi­dence of expe­ri­ence with Func­tion Point Analy­sis (FPA) or atten­dance of 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 with 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 taking the exam to renew the cer­ti­fi­ca­tion, pre­pa­ra­tion is nee­ded and studying andexer­ci­ses are essen­cial. Our CFPS Exam Pre­pa­ra­tion course is desig­ned spe­ci­fi­cally to sup­port the can­di­date to take the IFPUG’s exam on his jour­ney for 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 in regards to cer­ti­fi­ca­tion is the ideal time for pre­pa­ra­tion for 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, from which 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 are no remaining doubts. Some exam ques­ti­ons are based on some of 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 material. The best pre­pa­ra­tion indi­ca­tors are the simu­la­ted exercises.

 

FATTO’s course CFPS Exam Pre­pa­ra­tion offers more than 1,000 ques­ti­ons in exam style as a resource to sup­port the can­di­date, moreover the ins­truc­tor will sup­port the student until the exam date. In the Demo Ver­sion CFPS Exam Pre­pa­ra­tion, it´s 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.

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 with the IFPUG throughout the dura­tion of their cer­ti­fi­ca­tion. The­re­fore, cer­ti­fi­ca­tion costs should be analy­sed con­si­de­ring IFPUG mem­bership dues also.

 

Regar­ding mem­bership dues, see: http://www.ifpug.org/?page_id=26

 

There are seve­ral types of memberships:

  • 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 that are inte­res­ted in cer­tifying at least 3 peo­ple, the Cor­po­rate Affi­li­a­tion option may be the most cost effective. Otherwise, the best option is the indi­vi­dual membership.

 

The Pro­me­tric price for the exam is US$ 250.00. 

 

Howe­ver, it is stron­gly recom­men­ded that you look for good pre­pa­ra­tion for the exam, having sufficient study time, 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 costs.

 

 

 

 

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. Therefore, a piece of soft­ware has the same funcational size in func­tion points, whether it´s deve­lo­ped using OO tech­no­logy or another appro­ach.


What may be dif­fe­rent between 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 construction buil­ding: 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, the only differing factors will be the cons­truc­tion time or cost.

 

 

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

 

It is desi­ra­ble within 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 rigorous and for­ma­l on its mana­ge­ment than small pro­jects. Using the same appro­ach for any size pro­ject means burdening smaller projects with a relatively high cost of management, ie, waste of resources.

 

There is no indus­try stan­dard defi­ni­tion to define 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 for 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 summary, 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 summary, 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 would be lower than if you hire the same firm to con­duct the entire lifecy­cle of soft­ware deve­lop­ment, from requi­re­ments gathering 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, seve­ral papers must be deli­ve­red (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 to have dif­fe­ren­ti­a­tion of $/FP in regards 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 go through. Usu­ally, the effort to main­tain a func­tion tends to be lower than to deve­lop it. Thus, there may be a 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 one price for a func­tion point and also there is no public and upda­ted price list avai­la­ble, where the func­tion point price could be seen. Also 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 past, through the offi­cial bra­zi­lian gazette or direc­tly with the govern­ment organanization.

 

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 data of soft­ware pro­jects (e.g. ISBSG — www.isbsg.org) and provide a deli­very rate indi­ca­tors con­ver­sion (H/PF) to price ($/FP). But even if we could get a list of the $/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, it is bet­ter to derive this from projects that have alre­ady been under­ta­ken. For pro­jects alre­ady com­ple­ted, 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 attained through a mea­su­re­ment or an esti­mate, just by revi­ewing the requi­re­ments. Having the price of the pro­ject and its size in func­tion points,  the price per func­tion point ($/FP) can be attained. 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, because a sin­gle price point 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 result, 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 for its achi­e­ve­ment. Howe­ver, taking into account the knowledge with all of the requests in a given period of time, we can arrive 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 elimination of 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 evaluate whether or not 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 interaction 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 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 requiring more deve­lop­ment effort, 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 products 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 results 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 products 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 the 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 80,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. Another 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.

 

Source

Con­ver­sion Fac­tor (COBOL)

Quan­ti­ta­tive Soft­ware Management

77 LOC/PF

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, applying 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, IFPUG high­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 the 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, a group cal­led WG12 (Wor­king Group 12) was formed, 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 the IEC (Inter­na­ti­o­nal Engi­ne­e­ring Consortium).

 

As a result of the work of WG12, the stan­dard 14.143 was esta­blished, which is spli­t 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 of the IFPUG 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 — In 1997 a group of rese­ar­chers from the Uni­ver­sity of Que­bec 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 the COSMIC (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­led COSMIC-FFP, in prac­tice was a refi­ne­ment of the FFP method. It is not a tech­ni­que as wides­pread as the IFPUG, but there is much rese­arch being con­duc­ted on this method.

 

 

 

 

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 how to relate (and show to spon­sors) Func­tion Point Analy­sis may con­tri­bute to some of the organization´s goals, and 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 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 holds 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.

 

- Sign up key peo­ple that are involved in the process in open Function Point classes. 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 the 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 where Func­tion Point Analy­sis is is restricted. 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 an 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 duration, defects and team size, the most com­mon use is 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 its own num­bers, the orga­ni­za­tion may use the data from pre­vi­ous pro­jects and reco­ver infor­ma­tion such as effort and size in func­tion points. Grou­ping simi­lar pro­jects, it 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, below are pre­sen­ted 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 the contracting model used is that of man-hour, where the provider remuneration is not based on presented results, yet in the quantity of work hours in an established period, FPA can be used, for example, for monitoring productivity for the team. 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 to both pieces of 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 the value of the func­tion point to obtain the amount of new fea­tu­res is applied . 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 they will incur more profit in regards to the service provided. If there is an incre­ase in  the scope of ser­vice, stressful negotiations will not be requi­red to esta­blish the value for the addi­ti­o­nal service.

 

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

 

In any of the types of con­tracts adop­ted, we 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 worst case scenario, 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  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 this 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 for them 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 this 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.

 

Therefore, the ben­ch­mar­king is realized 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 it 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) Is 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) Even though they might be dif­fe­rent, is the risk of this vari­a­tion 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. It is noteworthy state that when more pro­jects are used in the ben­ch­mar­king pro­cess, the more accurate the results. 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.

 

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. This infor­ma­tion could be extra­po­la­ted for appli­ca­tion in esti­ma­tes pro­ces­ses of new projects.

 

To simplify, if it is we know HOW MUCH is to be pro­du­ced, we can extra­po­late what the effort, time and cost invol­ved in this work will be. 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 the effort percent distribution determined by the production process is adopted by that 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 services invol­ves basi­cally the same ques­ti­ons to out­source any other acti­vity. Spe­ci­fic situ­a­ti­ons are high­ligh­ted below where the out­sour­cing may be favo­ra­ble to the con­trac­ting 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 shadowing by the client team can haste the pro­cess and also help in absorp­tion of prac­ti­cal kno­wledge by the team. Its a type of men­to­ring of sorts.

 

- 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 beneficial to hire an out­side expert in coun­ting. This would be done with interaction with a pro­fes­si­o­nal from inside the orga­ni­za­tion that knows the sys­tems to be counted.

 

- When the counting needs are spo­ra­dic, the cost-benefit to train a pro­fes­si­o­nal in-home and keep him upda­ted may be disad­van­tageous in regar­ds to hiring an 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 contracting 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 in which spe­cifying and mode­ling sys­tems was done. The UML and Use Cases quic­kly became industry stan­dard of software.

Within this con­text, in 1993 Gus­tav Kar­ner pro­po­sed the metho­do­logy of the Use Case Points (based on Func­tion Point Analy­sis) in an aca­de­mic article  with a view of esti­ma­ting resour­ces for soft­ware pro­jects using object-oriented deve­lo­pment 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, using a cost benefit analysis. 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 documentation about this sub­ject is scarce. There isn´t an offi­cial kno­wledge body on UCP. For 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 body of kno­wledge 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 IFPUG manual, 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 know how 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 Cases of this pro­ject, it will also be dif­fe­rent in each situ­a­tion. In order words, 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 in turn 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 of UCP 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 common mis­take for begin­ners with FPA is to only consider the end-users´point of view. In this case some types of softwa­re will be par­ti­ally (or com­ple­tely) “invi­si­ble” to this user. Then they mis­ta­kenly con­clu­de that FPA does not work for that kind of soft­ware. The most com­mon is for 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 some softwa­re domain which do not have scre­ens, like batch pro­ces­sing, mid­dlewa­res, basic softwa­res, it is natu­ral to have some difficulties on mea­su­ring it.


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 some articles, we fre­quen­tly 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 traction, 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, in turn, is based on Func­tion Point Analy­sis (FPA).

 

TPA is used spe­ci­fi­cally to esti­mate the effort requi­redin the exe­cu­tion of accep­tance and system tes­ting. 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”, it adds more fac­tors that have more influ­ence on the effort than spe­ci­fi­cally on func­ti­o­nal size, as algo­rith­mic com­ple­xity,  degree of integration 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 points when it says that this can­not be used to esti­mate the effort in acti­vi­ties invol­ving accep­tance and system tes­ting. Neverthe­less , 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.

 

Being that Func­tion Point Analy­sis (FPA) is 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, a 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­racting with the soft­ware means sending data to the appli­ca­tion or receiving 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 widely defined user con­cept into con­si­de­ra­tion, during a func­tion point coun­t, it is appropriate to look at the set of possible users whose vision better represents the functions that the application provides. For exam­ple, an ATM appli­ca­tion has the following users: the bank cus­to­mer, the agency offi­cial, the depart­ment mana­ger. Base the count of this appli­ca­tion only from the point of 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 field 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­ple that we can quote is 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 components. 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 use of the tech­ni­que, 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 FPA is an technique that is independent of the technology used to model or construct software. Therefore, that software will have the same size in function points whether someone use an agile methodology or any other approach to develop it.

 

What will probably 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 to specify requirements, 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)?

The Counting Practices Manual - CPM, of the IFPUG has the following objectives:

 

• 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 define what you want to achi­eve with the count that will take place, what pro­blem(s) could be sol­ved with it. The way the following 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 in 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 ins­tal­led software.

 

3. Identifying the appli­ca­tion boun­dary 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 identification of data func­ti­ons and tran­sac­ti­ons in the subsequent steps. The coun­ting scope defi­nes what will be included in the func­tion point count.

 

4. Coun­ting the data type functions.

 

The data type func­ti­ons repre­sent sto­rage requi­re­ments of the user. They are divided in the following categories:

 

- 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 (low, medium, high) are deter­mi­ned based on two para­me­ters (data types and record types). Each range of data types/record types correlate to a certain complexity and eventually a function point amount.

 

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. They are divided in the following categories:

 

- 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. Their com­ple­xi­ties are deter­mi­ned based on two para­me­ters (data types and refe­ren­ced files); and to each associated com­ple­xity, there is a relevant amount of func­tion points.

 

6. Cal­cu­la­tion of the 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). Afterwards, 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 (FP/man month) or delivery rate (hours per FP) should be used to estimate the effort of a project?

 

There is a big temp­ta­tion amongst pro­fes­si­o­nals invol­ved in esti­ma­tes to use the term “mar­ket” indi­ca­tors for esti­ma­tes based on func­tion points. There are certainly seve­ral sour­ces where you can get pro­duc­ti­vity metrics 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 them. 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 the own orga­ni­za­tion is a seri­ous mis­take. Esti­ma­tes obtai­ned on this way will rarely have the neces­sary reli­a­bi­lity for 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 recover the two variables that make up the productivity indicator:  size (in function points) and effort (hours). With these two pieces of data, the productivity of that pro­ject can be achi­e­ved direc­tly. But if each pro­ject has a dif­fe­rent pro­duc­ti­vity rate, 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 the pro­duc­ti­vity. Howe­ver, if a par­ti­cu­lar com­pany fol­lows 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 the IFPUG. For its 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 the func­tion point 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 pro­vide free access to their manuals.

 

The ori­gi­nal ver­sion of the IFPUG manual is in English. The manual is also available in other lan­gua­ges such as Spa­nish, Ita­lian, Korean, and also in Portuguese.

 

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

There is a wide range of productivity in regards to the number of func­tion points that can be counted by a professional in one day, mainly caused 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, it will be easy to perform the mea­su­re­ment, even if the project/system docu­men­ta­tion is subpar.

 

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 spent answering questions in regards to requirements. Insuf­fi­ci­ent docu­men­ta­tion for the mea­su­re­ment is the most com­mon pro­blem for­ appli­ca­tion and impro­ve­ment project counts.

 

3. Coun­ter’s expe­ri­ence: the more expe­ri­ence the analyst has counting, the faster the requirements analysis will be. That person is more likely to identify relevant information quicker and disregard that information that is of no value (saving time in this analysis).

The expe­ri­ence itself also saves time as that person will know how to react in situations that that person has encountered in the past.

 

 

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 additional infor­ma­tion that was not docu­men­ted or docu­men­ted in an unclear manner. 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 until such avai­la­bi­lity presents itself to continue 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. Therefore the docu­men­ta­tion can be analy­zed in a more super­fi­cial way and thus 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 detailed mea­su­re­ment. 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 on this activity.

 

 

6. Pro­cess Auto­ma­tion: sup­porting soft­ware can speed up the count process, espe­ci­ally the parts of the pro­cess that do not involve the analysis.

 

7. Type of count: usu­ally the pro­duc­ti­vity to count an impro­ve­ment pro­ject is higher than a deve­lop­ment pro­ject or appli­ca­tion count, espe­ci­ally if the appli­ca­tion that is being main­tained (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 an improvement pro­ject 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 the IFPUG 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 typical expected behavior. Pro­duc­ti­vity less than 100 FP/day is a sign of trou­ble, the cau­ses should be inves­ti­ga­ted. Often the metrics analyst per­forms requi­re­ment analy­sis activities, with a lack of docu­men­ta­tion or bad 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. Preparation time, docu­men­ta­tion analysis, answering ques­ti­ons is the more predominant activity 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 available that auto­ma­ti­cally count func­tion points reliably. Howe­ver there are tools avai­la­ble that can sup­port and par­ti­ally auto­mate the pro­cess of func­tion point counts and also to store and manage the results of the counts.

 

The sim­plest tool to be used to record a func­tion point count is a spread sheet. In the “resour­ces” sec­tion of our web­site, there is a fre­e and for­mat­ted spre­adsheet for func­tion point counts available for download. Des­pite being the first and sim­plest tool to be used by many pro­fes­si­o­nals, its use begins to be imprac­ti­cal as the num­ber of counts increases. The con­trol of the count repo­si­tory is usu­ally manual, and with the incre­a­sing amount of data, 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 course of action is to search tools with more capabilities on the mar­ket. The IFPUG has a cer­ti­fi­ca­tion pro­cess for the tools to sup­port the func­tion point counts. The list of tools cur­ren­tly cer­ti­fied can be viewed here: http://www.ifpug.org/?page_id=316. Accor­ding to this pro­cess, the tools can be clas­si­fied into three categories:

 

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 point 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 the data inte­rac­ti­vely, but his invol­ve­ment is mini­mal during the count. It is impor­tant to note 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 in-house tool inte­gra­ted with its 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 regard. 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 required for its implementation.

 

But the adjust­ment fac­tor, analy­zed by itself 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 in 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­tenances are likely to be mea­su­red with Func­tion Point Analy­sis (FPA). Only the main­tenances 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­tenance”, exac­tly to make the point that the impro­ve­ment is not any kind of main­tenance. 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 appli­ca­tion, as well as even­tual func­ti­ons of data conversion.

 

Main­tenance 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, regardless of wha­te­ver phase the pro­ject is in, 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 inde­pen­dently of the form 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 do you produce estimates for the pro­ject before that time frame, which is pre­ci­sely when the need for esti­ma­tes is requested the most? 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 http://www.fattocs.com.br/traduzido/earlyfpa.asp.

 

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

 

No, 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 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 mana­ge­ment to moni­to­r 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 Func­tion Point Analy­sis (FPA), pre­a­ched by IFPUG, is that the pro­cess of func­tion points counting 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 deve­lop­ment pro­ject or soft­ware main­te­nance activity, making a func­tion point counts requi­res the effort of a pro­fes­si­o­nal of a 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. 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 “burden” the effort of the pro­ject but that will pro­vide bene­fits that outweigh this extra effort.

 

Trans­la­ting this into num­bers, the ideal situation 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 point count ends up being con­su­med in inter­vi­ews, revi­ews and detai­ling requi­re­ments. These are 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: user 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, it 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­tionship, 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. Counting 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 not knowing the user's busi­ness. For the func­tion point count be performed cor­rec­tly, in other words, from the user’s point of view, it is neces­sary that the func­tion point analyst to seek to unders­tand the busi­ness first and only then perform the func­tion point coun­t. Often there is no time avai­la­ble for the function point analyst to seek this kno­wledge. In this case he will act in conjuction  with a busi­ness analyst or a user to be able to perform 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. It is no different with func­tion points counting. 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 list 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 soft­ware (or count func­tion points). Any docu­ment on which information regarding user requirements can be extrac­ted can be used in 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 use 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 dis­tinct  docu­ments (or arti­facts) in cer­tain sta­ges of the pro­cess. The­re­fore, the time at which the mea­su­re­ment is performed also deter­mi­nes which docu­ments will be avai­la­ble to perform the 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 of 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),

the bet­ter the qua­lity requi­re­ments are, the easier and fas­ter the mea­su­re­ment pro­cess becomes, and more accu­rate the results 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. The soo­ner these faults in the pro­ject are iden­ti­fied, lower the cost to cor­rect them, and gre­a­ter the chance of the pro­ject success.

 

 

.

 

.