A very old blog written by me.... when I was doing lot of project estimations. Had been in draft...
FP is most widely used estimation technique when you have information about the functionality to be provided. It is technique which removes some amount of subjectivity from the estimation. It also is language independent.
If the concepts of FP is applied as per the definition then FPA technique used by different people should arrive at similar estimates in terms of FP (unit of function point analysis).
Then,
FP x Productivity (in terms of #Hrs per FP) = Total Effort in Hrs.
Productivity is where effort should different for different company. If delivery person thinks his team is capable of giving the very productivity then he can take higher figure for Productivity.
If somebody has tools which will be able to give higher productivity then account for that in Productivity again.
Productivity has different figure for different language and different company, which should give competitive estimates not FP estimates itself.
Some of common mistakes we do while estimating using FPA.
1) I have existing code so I will be able to copy the code from there hence let me give lower complexity. Or I have tool which will allow me to do these 3 screens in 1 hour.
Do not get biased by implementation technique while estimation. Ex- Do not think that you have done similar thing be able to copy the code from there hence give a lower complexity while estimating. You are the person estimating it and you may not be developing it.
You can account for it by taking high productivity…
2) FP usually gives estimation 20% higher. So let me adjust it by reducing it.
May be it is other way round. You are taking productivity 20% lower, may be you should increase your productivity and you will start getting 20% lower estimates.
3) I can make add, modify and delete and display functionality in one single screen.
Do not think of implementation while estimation. FP is based on functionality rather on number of screens.
4) Customer Details is 3 ILF, Customer Name, Address is different table, Customer relatives is different table
Again, do not think of implementation while estimation. FP does not think of ILF as table. Tables are not normalized here.
The major components of FPA estimation are:
1) EI
2) EO
3) EQ
4) ILF
5) EIF
EI, EO and EQ are through which system interacts with Users.
EI – External Input is a screen field which is used to get information from user. This field when obtained by system from user is stored in a file which ILF. The information which is displayed to user can come from other type of file called EIF.
ILF from EIF in the sense that ILF is the file or information which is maintained (added, modified and deleted in the system). EIF is the file or information which is not maintained or which is static information.
EO and EQ is again screen or report field which are displayed to the user. They are almost same EQ is simply displayed where as EO is derived field which is result of some calculation.
So process of counting FP is,
Take functionality like, “Add a Customer detail”.
EI –
- Count number of fields which are in screen which are asked from user.
- Count number of FTR or file transactions (number of file referenced ILF + EIF), which could be for saving in file or getting from file for display.
EQ – functionality like “Display Customer details.” This will be simple query from file.
- Count number of fields which are in screen which displayed.
- Count number of FTR or file transactions (number of file referenced ILF + EIF),
EQ – functionality like “Display Customer Addition Report” . This would be a derived query or complex query.
- Count number of fields which are in screen which displayed.
- Count number of FTR or file transactions (number of file referenced ILF + EIF),
- Some of the fields like sum, average and other calculations …
This reference table is used for knowing the complexity of EI.
1-4
5-15
>15
<>2
Average
High
High
Low – 3
Average - 4
High – 6
You will FTR has more effect on complexity. DETs may not be very accurate. DETs can be in counted in blocks. They can be in range of 1-4, 5-15 or > 15 ( no need for to be very accurate).
Similar, is case with EO and EQ.
For ILF, You count Data Elements and RET (Record Element Type).
Data Elements - Again fields like Customer Name, Customer Age
RET - Field group (repeatable, counted once) like Customer Address(office add, resd add etc.)
Record Element Types (RET)
Data Elements (DET)
1-19
20-50
> 51
1 RET
Low
Low
Average
2 – 5
Low
Average
High
6 – more
Average
High
High
Low – 7
Average - 10
High – 15
Again, you can see – no need to very accurate in counting fields. It can be block of 1-19, 20-50 or > 51. Give you judgment. RETs are more important.
You will also notice ILF and EIF are more important. As they give higher FP counts.
With counting EI,EQ,EO and ILF and EIF. The reference tables give the FP count.
Total of all FP count is the UnAdjusted Function Point.
Which is then adjusted by a factor which is derived from getting the complexity of the system, like whether it is highly interactive, distributed system….
These factors when applied using adjustment formula.
Value Adjustment Factor
FP is most widely used estimation technique when you have information about the functionality to be provided. It is technique which removes some amount of subjectivity from the estimation. It also is language independent.
If the concepts of FP is applied as per the definition then FPA technique used by different people should arrive at similar estimates in terms of FP (unit of function point analysis).
Then,
FP x Productivity (in terms of #Hrs per FP) = Total Effort in Hrs.
Productivity is where effort should different for different company. If delivery person thinks his team is capable of giving the very productivity then he can take higher figure for Productivity.
If somebody has tools which will be able to give higher productivity then account for that in Productivity again.
Productivity has different figure for different language and different company, which should give competitive estimates not FP estimates itself.
Some of common mistakes we do while estimating using FPA.
1) I have existing code so I will be able to copy the code from there hence let me give lower complexity. Or I have tool which will allow me to do these 3 screens in 1 hour.
Do not get biased by implementation technique while estimation. Ex- Do not think that you have done similar thing be able to copy the code from there hence give a lower complexity while estimating. You are the person estimating it and you may not be developing it.
You can account for it by taking high productivity…
2) FP usually gives estimation 20% higher. So let me adjust it by reducing it.
May be it is other way round. You are taking productivity 20% lower, may be you should increase your productivity and you will start getting 20% lower estimates.
3) I can make add, modify and delete and display functionality in one single screen.
Do not think of implementation while estimation. FP is based on functionality rather on number of screens.
4) Customer Details is 3 ILF, Customer Name, Address is different table, Customer relatives is different table
Again, do not think of implementation while estimation. FP does not think of ILF as table. Tables are not normalized here.
The major components of FPA estimation are:
1) EI
2) EO
3) EQ
4) ILF
5) EIF
EI, EO and EQ are through which system interacts with Users.
EI – External Input is a screen field which is used to get information from user. This field when obtained by system from user is stored in a file which ILF. The information which is displayed to user can come from other type of file called EIF.
ILF from EIF in the sense that ILF is the file or information which is maintained (added, modified and deleted in the system). EIF is the file or information which is not maintained or which is static information.
EO and EQ is again screen or report field which are displayed to the user. They are almost same EQ is simply displayed where as EO is derived field which is result of some calculation.
So process of counting FP is,
Take functionality like, “Add a Customer detail”.
EI –
- Count number of fields which are in screen which are asked from user.
- Count number of FTR or file transactions (number of file referenced ILF + EIF), which could be for saving in file or getting from file for display.
EQ – functionality like “Display Customer details.” This will be simple query from file.
- Count number of fields which are in screen which displayed.
- Count number of FTR or file transactions (number of file referenced ILF + EIF),
EQ – functionality like “Display Customer Addition Report” . This would be a derived query or complex query.
- Count number of fields which are in screen which displayed.
- Count number of FTR or file transactions (number of file referenced ILF + EIF),
- Some of the fields like sum, average and other calculations …
| Functionality | Type | # of DET | # of FTR |
Add a customer | EI | (no of fields of input) | (nos. of file referenced) |
Display a customer | EQ | (no of fields of displayed) | (nos. of file referenced) |
Customer Report | EO | ||
| .. | … | .. | .. |
This reference table is used for knowing the complexity of EI.
FTR | Data Elements (DET) |
< 2 | Data Elements (DET) |
1-4
5-15
>15
<>2
Average
High
High
Low – 3
Average - 4
High – 6
You will FTR has more effect on complexity. DETs may not be very accurate. DETs can be in counted in blocks. They can be in range of 1-4, 5-15 or > 15 ( no need for to be very accurate).
Similar, is case with EO and EQ.
For ILF, You count Data Elements and RET (Record Element Type).
Data Elements - Again fields like Customer Name, Customer Age
RET - Field group (repeatable, counted once) like Customer Address(office add, resd add etc.)
Record Element Types (RET)
Data Elements (DET)
1-19
20-50
> 51
1 RET
Low
Low
Average
2 – 5
Low
Average
High
6 – more
Average
High
High
Low – 7
Average - 10
High – 15
Again, you can see – no need to very accurate in counting fields. It can be block of 1-19, 20-50 or > 51. Give you judgment. RETs are more important.
You will also notice ILF and EIF are more important. As they give higher FP counts.
With counting EI,EQ,EO and ILF and EIF. The reference tables give the FP count.
Total of all FP count is the UnAdjusted Function Point.
Which is then adjusted by a factor which is derived from getting the complexity of the system, like whether it is highly interactive, distributed system….
These factors when applied using adjustment formula.
Value Adjustment Factor
- General System Charactertics
- Degree
- Data Communication
- Distributed Processing
- Performance
- Heavily Configurable
- Transaction rates
- Online Data Entry
- Design End User Efficiency
No comments:
Post a Comment