Geeks With Blogs
SAM|NET »»» technology + aesthetics «««
You can't control what you can't measure.

Software practitioners are frequently challenged to provide early and accurate software project estimates. It speaks poorly of the software community that the issue of accurate estimating, early in the life cycle, has not been adequately addressed and standardized.

The ability to accurately estimate the time/cost taken for a project to come to its successful conclusion has been a serious problem for software engineers. The use of repeatable, clearly defined and well understood software development process has in recent years shown itself to be the most effective method of gaining useful historical data that can be used for statistical estimation. In particular, the act of sampling more frequently, coupled with the loosening of constraints between parts of a project, has allowed more accurate estimation and more rapid development times.


Popular methods for estimation in software engineering include:
  • Parametric Estimating
  • Wideband Delphi
  • Cocomo
  • SLIM
  • SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk (based on Brooks Law)
  • Function Point Analysis
  • Proxy Based Estimation (PROBE) (from the Personal Software Process)
  • The Planning Game (from Extreme Programming)
  • Program Evaluation and Review Technique (PERT)
  • Analysis Effort method

NOTE: Brooks' law was stated by Fred Brooks in his 1975 book The Mythical Man-Month as "Adding manpower to a late software project makes it later." Likewise, Brooks memorably stated "The bearing of a child takes nine months, no matter how many women are assigned."

The value to be gained from utilizing a functional sizing technique, such as Function Points, is primarily in the capability to accurately estimate a project early in the development process.

In words of Wikipedia

Function Point Analysis (FPA) is an ISO recognized method to measure the functional size of an information system. The functional size reflects the amount of functionality that is relevant to and recognized by the user in the business. It is independent of the technology used to implement the system.

The unit of measurement is "function points". So, FPA expresses the functional size of an information system in a number of function points (for example: the size of a system is 314 fp's).

The functional size may be used:
  • To budget application development or enhancement costs
  • To budget the annual maintenance costs of the application portfolio
  • To determine project productivity after completion of the project
  • To determine the Software Size for cost estimating

All software applications will have numerous elementary processes or independent processes to move data. Transactions (or elementary processes) that bring data from outside the application domain (or application boundary) to inside that application boundary are referred to as external inputs. Transactions (or elementary processes) that take data from a resting position (normally on a file) to outside the application domain (or application boundary) are referred as either an external outputs or external inquiries. Data at rest that is maintained by the application in question is classified as internal logical files. Data at rest that is maintained by another application in question is classified as external interface files .

Types of Function Point Counts:
Development Project Function Point Count

Function Points can be counted at all phases of a development project from requirements up to and including implementation. This type of count is associated with new development work. Scope creep can be tracked and monitored by understanding the functional size at all phase of a project. Frequently, this type of count is called a baseline function point count.

Enhancement Project Function Point Count

It is common to enhance software after it has been placed into production. This type of function point count tries to size enhancement projects. All production applications evolve over time. By tracking enhancement size and associated costs a historical database for your organization can be built. Additionally, it is important to understand how a Development project has changed over time.

Application Function Point Count

Application counts are done on existing production applications. This “baseline count” can be used with overall application metrics like total maintenance hours. This metric can be used to track maintenance hours per function point. This is an example of a normalized metric. It is not enough to examine only maintenance, but one must examine the ratio of maintenance hours to size of the application to get a true picture.

Productivity:

The definition of productivity is the output-input ratio within a time period with due consideration for quality.

Productivity = outputs/inputs (within a time period, quality considered)

The formula indicates that productivity can be improved by (1) by increasing outputs with the same inputs, (2) by decreasing inputs but maintaining the same outputs, or (3) by increasing outputs and decreasing inputs change the ratio favorably.

Software Productivity = Function Points / Inputs


Effectiveness vs. Efficiency:

Productivity implies effectiveness and efficiency in individual and organizational performance. Effectiveness is the achievement of objectives. Efficiency is the achievement of the ends with least amount of resources.

Software productivity is defined as hours/function points or function points/hours. This is the average cost to develop software or the unit cost of software. One thing to keep in mind is the unit cost of software is not fixed with size. What industry data shows is the unit cost of software goes up with size.

Average cost is the total cost of producing a particular quantity of output divided by that quantity. In this case to Total Cost/Function Points. Marginal cost is the change in total cost attributable to a one-unit change in output.

There are a variety of reasons why marginal costs for software increase as size increases. The following is a list of some of the reasons

  • As size becomes larger complexity increases.
  • As size becomes larger a greater number of tasks need to be completed.
  • As size becomes larger there is a greater number of staff members and they become more difficult to manage.

Function Points are the output of the software development process. Function points are the unit of software. It is very important to understand that Function Points remain constant regardless who develops the software or what language the software is developed in. Unit costs need to be examined very closely. To calculate average unit cost all items (units) are combined and divided by the total cost. On the other hand, to accurately estimate the cost of an application each component cost needs to be estimated.

  • Determine type of function point count
  • Determine the application boundary
  • Identify and rate transactional function types to determine their contribution to the unadjusted function point count.
  • Identify and rate data function types to determine their contribution to the unadjusted function point count.
  • Determine the value adjustment factor (VAF)
  • Calculate the adjusted function point count.

To complete a function point count knowledge of function point rules and application documentation is needed. Access to an application expert can improve the quality of the count. Once the application boundary has been established, FPA can be broken into three major parts

  1. FPA for transactional function types
  2. FPA for data function types
  3. FPA for GSCs

Rating of transactions is dependent on both information contained in the transactions and the number of files referenced, it is recommended that transactions are counted first. At the same time a tally should be kept of all FTR’s (file types referenced) that the transactions reference. Every FTR must have at least one or more transactions. Each transaction must be an elementary process. An elementary process is the smallest unit of activity that is meaningful to the end user in the business. It must be self-contained and leave the business in consistent state

Function Point calculation

The function point method was originaly developed by Bij Albrecht. A function point is a rough estimate of a unit of delivered functionality of a software project. Function points (FP) measure size in terms of the amount of functionality in a system. Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories

  • Number of user inputs
  • Each user input that provides distinct application oriented data to the software is counted.
  • Number of user outputs
  • Each user output that provides application oriented information to the user is counted. In this context "output" refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.
  • Number of user inquiries
  • An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.
  • Number of files
  • Each logical master file is counted.
  • Number of external interfaces
  • All machine-readable interfaces that are used to transmit information to another system are counted.

    Once this data has been collected, a complexity rating is associated with each count according to Table

    TABLE 1: Function point complexity weights.
    Measurement parameterWeighting factor
    Simple AverageComplex
    Number of user inputs346
    Number of user outputs4 57
    Number of user inquiries346
    Number of files71015
    Number of external interfaces5710

    Each count is multiplied by its corresponding complexity weight and the results are summed to provide the UFC. The adjusted function point count (FP) is calculated by multiplying the UFC by a technical complexity factor (TCF) also referred to as Value Adjustment Factor (VAF). Components of the TCF are listed in Table 2

    Table 2. Components of the technical complexity factor.

    F1 Reliable back-up and recovery F2 Data communications
    F3 Distributed functions F4 Performance
    F5 Heavily used configuration F6 Online data entry
    F7 Operational ease F8 Online update
    F9 Complex interface F10 Complex processing
    F11 Reusability F12 Installation ease
    F13 Multiple sites F14 Facilitate change

    Alternatively the following questionaire could be utilized

    1. Does the system require reliable backup and recovery?
    2. Are datacommunications required?
    3. Are there distributed processing functions?
    4. Is preformance critical?
    5. Will the system run in an existing, heavuly utilized operational enviroment?
    6. Does the system require on-line data entry?
    7. Does the on-line data entry require the input transaction to be build over multiple screens or operations?
    8. Are the master files updated online?
    9. Are the input, outputs, files or inquiries complex?
    10. Is the internal processing complex?
    11. Is the code designed to be reusable?
    12. Are conversions and installation included in the design?
    13. Is the system designed for multiple installations in different organizations?
    14. Is the applications designed to facilitate change and ease of use?

    Each component is rated from 0 to 5, where 0 means the component has no influence on the system and 5 means the component is essential (Pressman, 1997). The VAF can then be calculated as:

    VAF = 0.65 + (Sum of GSCs x 0.01) Where Sum of GSCs = SUM(Fi)

    The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5) (Fenton, 1997). The final function point calculation is:

    Final Adjusted FP = UFC x VAF

    Convert AFP into SLOC using appropriate conversion factor.

    The following calculations depends on the scenario applicable

    SLOC = 16 x SLOC/AFP [NOTE: 16 is the conversion factor]

    EFFORT = EAF x A x (SLOC)EX

    EAF = CPLX x TOOL

    A = 3.2= Constant based on the development mode.

    EX = 0.38= Constant based on the development mode.

    CPLX = 1.3 = Constant based on the development language.

    TOOL = 1.1 = Constant based on the development Tool.


    TDEV = 2.5 x (EFFORT) EX in months

    Abbreviations
    AFP:Adjusted Function Point
    UFP:Unadjusted Function Point
    GSC:General System Characteristics
    FTR:File Types Referenced
    FP: Function Point
    ILF: Internal Logical File.
    EIF: External Interface file
    EI : External Inputs
    EO : External Outputs
    EQ : External Enquiries
    RET : Record Element Type
    DET :Data Element Type
    FTR :File Type Reference
    GSC : General System Characteristic
    VAF : Value Adjustment Factor
    LOC : Line of code
    EAF :Effort Adjustment Factor
    SLOC :Source Lines of Code
    CPLX :Development/Technical Complexity Factor
    TOOL :Development/Technical Tool Complexity Factor
    TDEV :Development Time
    REFERENCES:
    http://www.fprecorder.com/
    http://www.codeproject.com/gen/design/Softwarecosting.asp
    http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=39
    http://www.softwaremetrics.com/Function%20Point%20Training%20Booklet%20New.pdf
    http://sern.ucalgary.ca/courses/seng/621/W98/johnsonk/cost.htm#Function%20Points
    http://msdn2.microsoft.com/en-us/library/bb245774.aspx
    http://www.methodsandtools.com/mt/download.php
    http://www.softwaremetrics.com/freemanual.htm
    http://www.ijcim.th.org/past_editions/v13n1/IJCIM-V131-pp3.pdf
    http://www.codeproject.com/gen/design/usecasep.asp
    http://www.codeproject.com/gen/design/cocomo2.asp
    http://www.codeproject.com/gen/design/estimate-manhour-software.asp
    http://www.codeproject.com/gen/design/Estimation.asp
    
    Posted on Thursday, March 1, 2007 11:33 AM Project Management | Back to top


Comments on this post: Estimation Techniques : Function Point Analysis (FPA)

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
nice. but i need some more points regarding estimation of software project and cost analysis of the project.
Left by karthick on Oct 04, 2007 2:43 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
nice....
but can i have some more examples to evaluate the size and cost of software.
Left by Ravi Bhardwaj on Jan 23, 2008 2:15 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
nice ,if possible give a comprasion wth other estimation techniqune with example.
Left by mayank on Feb 25, 2008 9:14 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Good one, It could be great if you could come up with an example., any way thanks for sharing..
Left by Sanjay on Mar 04, 2008 5:05 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Some examples might help
Left by Nimpee on Mar 12, 2008 3:19 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Good one, but example will give more clear idea
Left by Madhavi on Apr 21, 2008 11:32 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Good one
Left by . on May 05, 2008 10:13 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Thanks and you can have some ex and please tell me how to determine hours/fp
Left by manusang on May 18, 2008 1:47 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Nice but with the help of an example can prove to be more extra informative
Left by hafiz on Jun 26, 2008 10:57 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
It's helpful for me, but give an example will more useful
Left by Huong on Aug 13, 2008 5:06 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Looks like every area of FPA has been addressed but for somebody new like me, it would be appropriate to have samples with every procedures
Left by Shiva Kumar on Aug 28, 2008 12:27 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
it's helpful for me to prepare a assignment on this topic
Left by navien on Aug 31, 2008 9:00 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Looking for software estimation experts. Join online.
Work online. http://www.econcinnity.com
Left by Animesh Mehra on Oct 08, 2008 7:53 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Nice and Crisp introduction to FPA. Thanks for the article!
Left by Ranga on Dec 15, 2008 6:13 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Good and precise stuff for the beginners and the experienced as well.
Left by Sagar Bhegade on Feb 17, 2009 7:02 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
to have more samples and each steps to be elaborated . now its not that clear
Left by Phoenixxxx on Apr 09, 2009 12:11 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Gud one,Explanation with example would be helpful.
Left by Aruna R on May 03, 2009 11:24 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Hi,
Nice piece of Information on FPA. But it would be more helpful if somebody can come up with example demonstration. Because I understood the theory behind it, but not really clear that How to apply it on any real project/product/software development.

Thanks.
Left by Pankaj on May 05, 2009 3:49 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Very Good work.The explanation is clear and easy to follow.
Left by Surya on Jun 19, 2009 8:25 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Very concise, to the point and easy to understand. A practical example which calculates UFP and AFP of a project/task will complement the article. Also, the application of FPA, i.e. metrics collection and its usage to improve deliverables will also add value to the readers
Left by Deepak Dalvi on Dec 22, 2009 7:27 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
This is an great effort.Good Explanation
Left by siva on Jan 24, 2010 11:09 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Great piece of info here. It will be a great help if you could explain how FPA can be applied to test estimation. Can it be applied?
Left by Siddharth Bhattacharya on Feb 28, 2010 3:25 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
thank you it is very much useful for me for my research work
Left by R.Poornachandrasekhar on Aug 02, 2010 10:30 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
This document is very clear and i understood the concept of function point estimation.
I would suggest you add an real world example for applying the FPA estimations.
Left by srinivas rajaboina on Aug 04, 2010 5:57 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Nice article. Suggested improvements to make it a comprehensive learning pack om FPA
1 Include a small case study and demonstrate how to identify Ei, EO, EQ, ILF, EF's.
2 It is important to let the people understand on how to provide the weights for thesecategories. Often it comes from expert judgement or inductry averages from the historical data.
3 Explan in detail how to calculate the actual cost of the project and effort breakup's by deliverable/milestone. The IFPUG website providesa good working excel to do this This article can leverage some samples and present it in more comprehensive way.
Left by Jagadeesh on Sep 03, 2010 6:16 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
I use following Function Point Calculator Tool for estimating project effort. It's very friendly to use:
Online Function Point Calculator
Left by Adam on Mar 09, 2011 10:23 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
How to calculate bulk mailer functionality in FP estimation ? Kindly clarify.
Left by Raj on Mar 22, 2011 3:53 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Nice documentation on Function Point Estimation.
Left by Dang Dave on Aug 05, 2011 6:33 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Need more explaination
Left by suganthan on Sep 06, 2011 11:45 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
Could you give an extensive example of project using this method?

I mean what functions are considered ILF EIF, EI EO, or EQ..

Thanks in advance.
Left by Arman on Dec 05, 2011 2:38 AM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
i want an example of fp based cost estimation
Left by arnav on Feb 13, 2012 9:24 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
i want an example of fp based cost estimation
Left by arnav on Feb 13, 2012 9:24 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
I already have 6 yrs of Java/J2ee exp. Am interested to learn FP. Can anyone tell me scope of FP in IT industry. How about market availability for it ?.
Left by Hari on Apr 10, 2012 7:14 PM

# re: Estimation Techniques : Function Point Analysis (FPA)
Requesting Gravatar...
I prefer CRUD-based techniques over plain FPA. I build matrix with weights and got effort using spreadsheet formulas. Easy and intuitive:

http://blog.aplikacja.info/2011/12/crud-matrix-as-a-software-design-and-estimation-tool/
Left by Dariusz Cieslak on Sep 18, 2012 9:12 AM

Your comment:
 (will show your gravatar)
 


Copyright © Prabhat Samuel | Powered by: GeeksWithBlogs.net | Join free