Function Point Analysis - Estimation

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 …

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

Project Management is about managing the Money, Minutes, Man, Material and Method to meet the Customer’s requirement. Managing these requires PM to manage expectations of several stakeholders.


Customer: Money, Minutes, Method and Requirements; Customer wants more requirements in less time and less money with high quality which comes with Method. Customer is not bothered with Man and Material used up to build the system.

Higher Management: Money, Man and Material; Company wants to meet the customer’s requirements by spending least money, least man and less material. They are not bothered about the time used, quality and method if customer is satisfied.

Team: Man, Minutes and Method; Team wants to work lesser time, with minimum people and less cumbersome methods to meet the requirements. If team is required to work more time(overtime at nights) results in unhappy team and resulting in problems in method and poor quality.

Manager has to manage these 3 stakeholders, keeping them happy by satisfying their expectation.


Reference:  http://www.objectmentor.com/ "Often managers will resort to pressure and motivation as their sole management techniques. They warn the developers of all the horrible things that will happen if they miss the date; and then they hang pictures of seagulls and people climbing rocks on the wall to motivate the developers to get the project done. They'll wander through the development area asking the developers how things are going. The developers will respond: "Pretty good!" And then, the managers go back to their offices to pray." <>

This is a perfect scenario, as described by Robert Martin, faced by project managers in their every project life.
Key to this; is planning the project by breaking it into measurable tasks. and then tracking the project by measuring the completion of these tasks.
This could be using the Agile methodology which breaks the  projects into stories and story points (Use Case).
OR It could be using simple planning using Work Break Down Struture which breaks the projects into small technical or non-technical tasks which are small in duration (1-2 days) and then tracking their completion. 

--Key is the project is broken down in measurable small tasks which are measurable as discrete 0 or 1 (0% finished or 100 % finished). And track their completion. Definition of completion should be passing of their decided acceptance tests. -- 

Scalable Teams

Universal Scalability principle also can applied to the fixing the team size.

Reference http://www.learningapi.com/blog/archives/000079.html

As defined by Amazon.com's Two-Pizza Team Rule "If a project team can eat more than two pizzas, it's too large."

1.Small problems are easier to grasp, examine, and solve than big ones. Small solutions are easier to explain, understand, test, and implement .

2. Small teams need less process, have few communications challenges, and lower overhead than larger ones. Small teams can get real work done while large ones are still trying to find common understanding about the problem.

This exactly in match with Universal Scalability Principle which says Job should be partitioned so as the smaller chunk has minimum coherency and minimum contention.

This for project team implies that Team should be so divided that there is minimum intra-team communication (so little time is lost for coordication) and minimum team contention for resources. That is team are autonmous, independent for their smaller chunk of larger project. Or else extra effort of communication for sub-task, sub-task dependecny, waiting will have to be accounted for.

Project Manager also take this account to be able to create a planned schedule for his project. He find the longest possible sequnce task which cannot be broken into parallel tasks and have sequence dependecy. This becomes his critical path (CPM) and is the total minimum duration of the project.

Rest of the smaller sub-tasks can be broken down into parallel sub-task stream, which can be allocate to independent resources to finish in the same duration parallelly.

What is Project Management?

 

Project Manager is CEO of the project. He is responsible for everything in a project similar to manner a CEO is for everything in his company. He is all in all responsible for the success and failure of a project. He has to manage the project in whatever manners possible.

Project Manager’s responsibility start as soon as he is assigned the project after the contract is signed.

Scenario
Let me take a scenario. A project estimated to be of 100 man days needs to be developed is assigned to Aditya, the PM. The project is a development project which would have to be follow entire SDLC phase. This project has been estimated to be of 80 FP with productivity taken for java for 10 hrs per FP.

First, Aditya does his own estimation to be convinced that he has taken the project with correct estimated effort.

Re Estimation
In case of major discrepancies in the effort, he needs to bring that out to his reporting manager, Shreya, which may mean some additional functionality or constraint not known at the time of estimation phase. In case, of some issue Shreya and Aditya may take up the issue with regards to change the contract or come to some agreement with the client. In case, of client not agreeing to the situation, Shreya and Aditya needs to take the call off choosing any of the many available options. One solution could be to project agree with his reporting manager to work with his own estimates.

If Aditya found the estimate to be correct and he is convinced of the estimate. Aditya now gets down to project management.

Planning

SPMP
Aditya starts with building the Software Project Management Plan (SPMP). In SPMP, Aditya documents the entire plan how he will be managing the project. He starts with listing the scope of the project, things out of scope of the project, the contact people of the project, risks of the project (there could be a separate Risk Management Plan for thing) with risk mitigation strategies for each risk. Aditya also documents what he will meet the various other processes of the project, configuration management; reporting and weekly report and expectation form the client with dates. Aditya documents the SLA for answering of the queries, and escalation mechanism on both sides.
Aditya communicate SPMP to his reporting manager, his counterpart, and other stakeholder like Quality Manager etc. All the people can agree or recommend the change in any of the procedure. Client PM can agree or disagree on the expectation from his side, SLAs and escalation procedure. This communication is healthy and sets the expectation from all sides.

Project Plan
Aditya now also starts on the project plan. He could be using any tools for this. Much used tool is Microsoft Project Plan (MPP). For 100 days project, he divides the project first into the phases.


This is tentative plan at high level for phases, it may change based on the company internal metrics phase breakup, project constraints like requirement phase, no architecture phase etc.



Based on this high level plan now Aditya is working out his low level plan in MPP,



Divide the phases into components to be built. Also display column “Work” which will have estimated hours from above table. Now when Aditya, enter estimate for that component in the work column and resource name in resource column, MPP calculates the duration based on the number of effort allowed and number resources working for that component.



Aditya also needs to enter precedence column for sequence. Review of component UC1 will start when UC1 completes. So once precedence is entered for all the start and end date is calculated automatically by MPP.

Aditya will enter plan only for phases he knows like Requirement and Architecture. For other he can just enter effort.

Ex- for Development effort is 280 hrs, with 3 developers DP1, DP2 and DP3.
MPP itself calculates 11.67 days and also gives start and end date – 12/1/80 – 12/17/08.
So Aditya can adjust number of resources based on the required dates for delivery.
Aditya also needs to see that optimum resourcing is done. In this example, developer, tester, test planner are entered as different people which may not be same.

Gantt chart

After, Aditya finalizes his initial plan he should baseline. Now, for tracking and progress this baseline plan is tracked.
As any of components is completed, enter in % completed. Example, Plan UCs, UC1, UC2, UC3 and Architecture Doc is 100% completed. Accordingly, Project is completed 11%