Function Point Analysis (FPA) W05

Function Point Analysis (FPA)

• Function points are a standard unit of measure that represent the functional size of a software application.
• FPA is a method to estimate costs based on counting the number of different data structures that are being used.
• In the FPA method it is assumed that the number of different data structures is a good size indicator.
• FPA is particularly suitable for projects aimed at realising business applications.

Function Points

Measured from the user’s perspective
The size of the application being measured is based on the user’s view of the system. It is based on what the user asked for, not what is delivered.

It is based on the way the user interacts with the system, including the screens that the user uses to enter input, and the reports the users receive as output.

It is also based on their understanding of the data that needs to be stored and processed by the system.

Technology-independent
It does not matter what technology is being used to implement the application.

Low cost
Historically, adding the process of counting FPs to a development process results in a cost increase of only 1%.

Repeatable
Studies have shown that multiple function point counters can independently count the same application to within 10% accuracy of each other. Repeatability is very important, because without it we could not begin to trust the data from the hundreds of applications that are stored in repositories around the world.

Work well with use cases
This process works extremely well with use cases, and can even work with the concept of “stories” in Extreme Programming.

Uses

The ability to accurately estimate:

• project cost
• project duration
• project staffing size

An understanding of other important metrics, such as:

• Project defect rate
• Cost per FP
• FP’s per hour
• The productivity benefits of using new or different tools

Function categories

EI – external inputs, which are the components responsible for introducing changes in system’s internal data.

• Data entry by users, data or file feeds by external applications.

EO – external outputs, which are the ways system’s internal data can be presented, but beware – there are a few similarities with EQ components, though.

• Reports created by the application where the reports include derived information.

EQ – external inquiries, which are the methods for reading system’s data without modifying it.

• Reports created by the application where the report does not include derived data.

ILF – internal logical files, which are files that are being used by the system itself.

• Tables in a relational database.

EIF – external interface files, which are responsible for exchanging data with other systems.

• Data that the application needs and uses but does not maintain. EIFs are the same as ILFS the difference is they are not maintained by the system but ILFs are.

Complexity guidelines

Weighting Factor
number of external inputs x 3 4 6 =
number of external outputs x 3 5 7 =
number of external inquiries x 3 4 6 =
number of internal logical files x 7 10 15 =
number of external interfaces x 3 4 6 =
Unadjusted FPcount = total

Value Adjustment Factors

Fi
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilised operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or operations
8. Are the master files updated online?
9. Are the inputs, outputs, files or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organisations?
14. Is the application designed to facilitate change and ease of use by the user?

Function Point Analysis

• When the values of these 14 factors are summed a Total Degree of Influence (TDI) is derived.
• TDI can vary from 0 (when all are low) to 70 (when all are high) i.e. 0 ≤ TDI ≤ 70.
• Hence, VAF can vary in the range from 0.65 (when all are low) to 1.35 (when all are high), i.e., 0.65 ≤ VAF ≤ 1.35.
• Value Adjustment Factor
  – VAF =0.65 + (0.01 x TDI )
• The constant values in the equation and the weighting factors that are applied to information domain counts are determined empirically.
  – Adjusted FP Count = Unadjusted FP Count * VAF

FPA Example

Continuing our example . . .
Complex internal processing = 3
Code to be reusable = 2
High performance = 4
Multiple sites = 3
Distributed processing = 5
Project adjustment factor = 17
Adjustment calculation:
Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)]
= 240 X [0.65 + (17 X 0.01)]
= 240 X [0.82]
= 197 Adjusted function points

Function Point Analysis

But how long will the project take and how much will it cost?

• If programmers average 18 function points per month.
  197 FP /18 = 11 person-months
• If the average programmer is paid €5,200 per month(including benefits), then the [labour] cost of the project will be . . .
  11 person-months X €5,200 = €57,200

Productivity

Organisations should collect their own data, in it’s absence this table can be used. The item that impacts productivity the most is the size of the project. It is interesting to note that nearly 75% of projects over 8,000 function points will fail and/or be cancelled.

Function Point Assessment

FPA is subjective:

• When calculating unadjusted function-point count.
• When assessing technology factors.
• There are problems with double counting. It is possible to account for internal complexity twice in weighting the inputs for the UFP and again in the VAF.
• FPA applies well only to systems, which are dominated by input-output and filing functions.
• Because function points largely ignore internal processing complexity, care must be taken in applying FPA to complex applications, even in the business area and it is difficult to apply to massively distributed systems..
• Different companies will calculate function points slightly different, making intercompany comparisons questionable

Function Points are useful:

• In measuring the size of the solution instead of the size of the problem.
• As requirements are the only thing needed for function points count.
• As it is independent of technology.
• As it is independent of programming languages.
• In estimating overall project costs, schedule and effort.
• As it quantifies and assigns a value to the actual uses, interfaces, and purposes of the functions in the software.
• In creating ratios with other metrics such as hours, cost, headcount, duration, and other application metrics.

Sources
http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/artan/functionpoints.htm

Read the following
http://www.softwaremetrics.com/Articles/estimatingdata.htm
http://www.softwaremetrics.com/Articles/estimating.htm