|
Size - Rules of Thumb
The following Rules of Thumb offer ways of approximating the size of software in IFPUG Function Points. These are extremely rough size approximations that should only be used for early lifecycle approximations. No business decisions or quotations should be based on the use of any size derived from the use of these Rules of Thumb.
The Rule of the "Thirties" - Logical Tables and Logical Files
The logical number of logical tables in a logical data model equates approximately to the number of IFPUG Internal Logical Files. Various organisations have come up with a rule of thumb of one logical file equaling "thirty something" unadjusted function points of total software size for a development project. You can use this to obtain a rough size estimate. Their range is between 31 to 35 function points per logical file. So a system with 40 logical files can be very roughly sized as follows: 40 x 35 = 1,400 function points. This sort of rough estimate should have an allowance of + or -30%
The Rule of the "Thirties" - Use Cases
There is a rule of thumb of one Use Case being approximately 35 function points. Obviously this is a very rough approximation as Use Case sizes can vary significantly.
Use Case Points to Function Points
You can approximate function points from Use Case Points by dividing your Use Case Points by 1.25.
Functional Size and Duration Relationships
You can estimate project duration using your estimation of software size, your software development life cycle phase profile, (including overlap between phases and activities), staff availability and other factors. For a "ball park" or indicative estimate of duration, several "rules of thumb" equations, or quick estimating techniques are available. Two are shown below.
Functional Size and Duration
Analysis of data from the ISBSG repository has produced a detailed set of equations that you can use to achieve indicative estimates of project duration. Appendix 3 of the Practical Project Estimation 2nd edition contains a complete set of the equations. Here are three examples of duration estimates using the ISBSG equations:
For a project of 500 Function Points using the language only equation table:
| Project Class |
Equation |
Project DurationMonths |
| 3GL projects: |
Duration = 0.971* 500^ 0.351 |
8.60 months |
| 4GL projects: |
Duration = 0.622 * 500 ^0.405 |
7.71 months |
| Application Generator |
Duration = 1.472 * 500 ^0.280 |
8.39 months |
Interestingly, work by Capers Jones provides a similar 'rule-of-thumb' equation:
For example for a project of 500 Function Points, Jones equation results in:
Duration = 7.93 calendar months.
Finding similar results drawn from two sets of data collected in entirely different ways, lends support to the notion that, in general, there is a predictable relationship between the functional size of a Program(s) and the duration of the project to produce the program(s).
Work Effort and Duration Relationship
An analysis of 662 projects in the ISBSG repository that reported their project duration, the following equation was produced:
Duration (calendar months) = 0.38 * Effort ^0.3
You can create an Excel formula to use this equation: =SUM(0.38*(effort^0.37))
The above "rule of thumb" equations are useful as a first indication of possible project duration. Of course, other factors such as the availability of resources and the business environment, must always be kept in mind. These additional factors should be used to apply judgement before drawing conclusions from the values calculated using any of the equations above.
|