| Author | Message | ||
     Reji Mathai |
Hi All, We are having a standard Web Based application being developed using J2EE/Oracle , its Adjusted FP count is around 450. We would be executing it using the traditional waterfall methodology of Requirements-Design-Development-Testing. I had following queries regarding as to how(or whether) we can proportion the Function Point count of the application to monitor the productivity during the execution phase. a)Proportion FP across the different Phases: For each phase(i.e. Requirements, Design, Development, Testing) we would need to assign a FP count of 450 and Monitor its productivity individually. Is this a correct approach? b)Proportion FP within each Phase: Assume that we are in the development phase and the Project work items has been broken down(WBS) as per the functional modules, further each functional module has been broken down into J2EE and Oracle components and assigned to individual team members. We also have work items to develop the framework and other utility classes. In such a scenario how does one Proportion the FP across the different work items(of the WBS) from an objective to monitor the productivity(hr/FP) within that phase? | ||
| N.Venkateswaran |
Hi Reji Mathai, Typically the proportion varies from organization to organization and from application to application. You have measured 450 FPs for the total project, It has to be divided amomg all activiites say, from requyirement gathering to implementation and documentation. If it is a new developement project, more percentage could be provided to Architecture and Design and if it is a maintainence project it varies and probably architecture could find a lesser share on the pie. In your case for example you can divide 15% for requirements 25% for design 40% for developement and testing 8 to 10% for project management and 10 to 12% for Implementation and documentation. You have to divide the UI, middle tier and Database part among developers and testers within the 40%. All the above are practised by most of the cmmi5 organisations and again this may vary. You have to arrive on how many FPS are deliverable by you. again rthis deponds upon various factors. The client sometimes specifies you the delivery period. Say for an example if he specifies that you have to deliver this project/product within 225 days, then you have to minimum deliver 2 FPS per day and you have to drive and measure towards that. For measuring the productivity of the developer, use 90 lines of code per fp for java, 32 lines of code in oracle. Cheers | ||
| Peter Hudson |
Hi Reji, For your first question: yes - if you know your organisation's work proportion (%) per phases then certainly you can apply the rule. As you have correctly pointed out, I would use 450 FPs for each phase. As regaurds your second question - the objective of your asking the question is a bit unclear to me. Why would you want to attribute "pseudo" FPs to work-items that total to 450 and individually follow those items? If you are working by phases then as and when each phase is over you know what % of work is done. Cheers. | ||
| Peter Hudson |
Hi Reji, For your first question: yes - if you know your organisation's work proportion (%) per phases then certainly you can apply the rule. As you have correctly pointed out, I would use 450 FPs for each phase. As regaurds your second question - the objective of your asking the question is a bit unclear to me. Why would you want to attribute "pseudo" FPs to work-items that total to 450 and individually follow those items? If you are working by phases then as and when each phase is over you know what % of work is done. Cheers. | ||
| Peter Hudson |
Hi Reji, For your first question: yes - if you know your organisation's work proportion (%) per phases then certainly you can apply the rule. As you have correctly pointed out, I would use 450 FPs for each phase. As regaurds your second question - the objective of your asking the question is a bit unclear to me. Why would you want to attribute "pseudo" FPs to work-items that total to 450 and individually follow those items? If you are working by phases then as and when each phase is over you know what % of work is done. Cheers. | ||
| hemanant |
Hudson, No problem.Only you can develop your own product with 450 fps for each phase. No body in the world will use 450 Fps for each phase when the total project size is 450 FPs. | ||
| Steve Neuendorf |
Hello Reji, Either approach would work. The first would be best. The second approach is very much like an earned value approach. It gets to be problematic if the project changes much during its course, but certainly doable. A good analogy for the first approach would be to use our house. Its size is so many square feet. It is still the same size whether you are going to just vacuum it or replace the carpet. Only the delivery rates and costs are different. Also using your first approach, it is much easier to accommodate changes in project scope. Hope this helps, Steve | ||
| shave |
steve, you mean to say we can use 450 for design,450 for requirement ,450 fps for developement,450 FPs for testing? | ||
| Steve Neuendorf |
Hi Shave, Absolutely. Say your overall delivery rate is 10 FP/WM and testing is 20% of the overall effort. Your overall delivery rate for testing would be 50 FP/WM, and your testing size would be the same size as at every other point in the process. Hope this helps, Steve | ||
| shave |
Steve, you mean to say that I should use 450 X 20 / 100 = 90 FPs for testing? in the Reji Mathai's example? | ||
| Sameer Kalra |
Hi Reji, In my opinion, your project size will remain fix(450 FP) even if you want to determine productivity for different phase. if 20% is for testing phase, you can not say I am testing 90 FP for testing, you are still testing a 450 FP project. Idealy you should have productivity for diff phase and you should not divide size by distributing FP for different phase. As if yos say I am testing for 90 FP for testing phase, statement is incorrect as you are still testing 450 FP project. Sameer | ||
| shave |
Hi samir, what i am trying to understand is assume that we have a productivity rate of 1 FP per day, so as per rejki's 450 Fps, it will take 450 Mandays to complete the project. Can we allocate 90 mandays for testing out of this 450 Mandays? Regards | ||
| Reji Mathai |
Hi Peter, The objective of assigning pseudo FP's was to track the productivity within each phase itself. For e.g. if the development phase is over a 3 month period then we wanted to track the completed FP's on a weekly basis. We basically have a project management tool within our organziation that allows to assign a size to each work item and log the planned/actual hours against it. Hi Steve, If we assume that the project scope does not change much is there any approach to apply earned value using FP? i.e How do we split the application size of 450 across the different work items within a phase? | ||
| Sameer Kalra |
Hi Shave, Dividing the effort is fine as per my understanding and that is the correct way. And if we are saying about productivity of only testing phase it will be 5fp/day Regards Sameer | ||
| Steve Neuendorf |
Hello Shave, That would be Reji's second approach. You would use the same delivery rate in each phase. My recommended approach is to use the 450 FP in each phase and adjust the delivery rate for each phase. In essence, both approaches are the same, except the variable delivery rate approach makes it much easier to accommodate scope changes. Thanks, Steve | ||
| prakash kumar sk |
Hello Sameer/Reji, I feel using FP as suggested in the previous post is not good. Let me give you an example. When we travel from point A to point B(assume a distance of 200 miles) we say we travelled at an average speed of 50 miles/hr. Say for the first 50 miles it can be 80, next 50 miles 30 and so on. In the example of travel you can use that. But in case of FP it is difficult to apportion the effort for indiviual phases. So you should always calcualte the overall productivity at any point in time. Its like calculating Required Run rate in cricket( for people familiar with cricket). You will have to extrapolate the current effort deviation and assume that current deviation (positive or negative) would not change. Example Estimate Total FP :450 Estimated Total Effort: 450 man days Actual Effort spent till now: 350 days Estimated effort till now: 300 Effort deviation is 300- 350= - 50 days: Estimated actual effort from now= 350+150 (remaining initial estimated effort)= 500 mandays.(assumption is that for the remaining 150 days there would be no effort deviation) So now your productive would drop below 1FP/Man day. Regards, Prakash | ||
| Reji Mathai |
Hi, I think the majority are of the view that we should apply 450 FP’ to each phase i.e. we would be executing 450 FP’s for Requirements phase , 450 FP’s for Design phase, 450 FP’s for Development phase and 450 FP’s for the testing phase. I was still a bit unclear about the other query. Assume Requirements, Design phases have been completed and we have entered the Development phase. Assume the estimated effort for the Development phase is around 2000 hours(derived using the organization Development PDR) and is planned across a schedule of 3 person months. The Development scope has been further broken down into individual work items(framework classes, utilities, oracle stored procs etc). In such a scenario how does one Proportion the FP across the different individual work items(within the development phase) from an objective to monitor the productivity(hr/FP) within the development phase on a weekly basis? Or does it make sense to measure the productivity only at the end of the development phase. | ||
| prakash kumar sk |
Hello Reji, You cannot do it. It will not make sense. FP is to size functional requirements that is being developed. Dont go in that direction. You always need to calculate overall productivity and effort at the work package level. Regards, Prakash | ||
| N.Venkateswaran |
Hi Reji, your understanding is wrong. What everybody meant here is to keep 450 as constant and from that calculate the percentage based on the alloted ratio. Say 20% out of 450 FPs and 40% for developement and testing out of 450. Taking shave's example of 1 FP productivity, you can deduct 90 days from the 450 and cannot calculate design effort of 25% from 360 (450 - 90). It should be calculated from 450 only. Hope this clarifies Cheers | ||
| Reji Mathai |
Hi Nvenk, I think we are speaking the same. I am saying from a conceptual view point we are executing 450 FP's in each phase, i was not referring to the effort here. I do agree that we would need tp split the effort derived from the 450 FP's across each phase. | ||
| KSV challam |
RejiMethai, combining N's 2 messages gives the clear industry practise | ||
| Peter Hudson |
Friends There are clearly 2 different needs. One is to "estimate" the work and the other is to calculate Earned Value. For EV: my recommendation is to stay clear of FPs. Use anything but FPs - it will be much simpler. For estimations: the approach I would use and I would recommend to all is as follows: (a) calculate the total size and total costs of the projects. As said several times in different posts ahead - let's assume 1 FP per day as productivity and so the project size is 450 days. (b) These 450 days must be split in phases. If you have historical data that shows that Requirements and Design phase takes 25% of effort, Coding and unit testing phase takes 30% of time, and Testing takes 45% of time then you divide your 450 days in this ratio. Coming back to EV situation: To take the example somebody gave of travelling from point A to point B. Let's add the complexity that the travel is done by different modes of transport. Point A to an intermediary point is done on foot, thereafter some part by bus, followed by some part by train, followed by some part by bus, and finally some part by foot. We know that the average time to do the journey from A to B takes 80 minutes with a productivity of 15 kmph. But that does not mean that each stretch takes the same productivity. In this case how do we calculate EV? I would tend to stick with distance covered divided by total distance to travel. But some may prefer to measure it in terms of time (i.e. time spent so far divided by the total time estimated for the travel). By the way, in case I do not come back on the discussion board before 2010 - here's wishing each and every one of you a very happy new year 2010. Cheers. | ||
| Anand Bharadwaj |
Hi, I agree with Mr. Hudson on project Monitoring aspect. We should not be using FPs (or splits of it like 20% etc) for productivity monitoring during project execution, because that simply does not makes sense. Because, let us assume we completed Requirement phase for 450 FPs project, if this amounts to 20% FP, does it makes sense to say 20% of 450, aka 90 FPs are Delivered? Is the user getting the functionalities introduced through this 90 FPs? Hence for all project monitoring activities, it is better to convert the FPs-> Hours based on the 'HISTORICAL' data of that organization on similar project and monitor that way. As Mr. Hudson suggested it is simpler and logical to be away from FPs till the project execution is completed. | ||
| N.Venkateswaran |
Hi Anand, refering to your second paragraph question Is the user getting the functionalities introduced through this 90 FP's? the answer is 'yes and it depends on the methodology also'. Say the methodology is waterfall, this 90 days makes perfect sense and the requirements document is the deliverable after 90 days. | ||
| ALOK KHARE |
"Wish you a very happy and prosperous New Year 2010!" I don’t think we get 90 FPs functionality after the requirement phase. We get SRS document (an intermediate work product) for 450 FPs after the requirement gathering phase. Similarly, after design we get only design document of 450 FPs, Unit Tested code after construction phase, etc. But, as far as end user is concerned, he gets 450 Function points application after it moves to production. So, one has to assign 450 FPs to each phase. As mentioned by Mr Hudson, normal practice is to have productivity for complete life cycle and its percentage distribution across phase i.e. 1.Technology: <java/dotnet> 2. Productivity: <12-24> hours per FP; 3. Percentage distribution across phases: Requirement Gathering: 10-15%; Design: 25-30%; Construction: 25-30%%; Testing: 25- 30%; UAT Support: 5%; Documentation: 5%; Project Management: 8% There are issues in above method as many times we don’t get opportunity to perform end-to-end projects, so having one productivity figure for end-to-end is of not much use and capturing and storing project data is also difficult. The other way of data storage is to capture productivity data for the applicable phases i.e Requirement Gathering: <2-4> hours per FP; Design: <4-6> hours per FP; Construction: <4-6> hours per FP; Testing: <4-6> hours per FP UAT Support: <1-2> hours per FP; Documentation: <1-2> hours per FP; Project Management: %age of total project Using this method, we can store, compare and normalize all project data for future usage. Even we can set the target to improve the productivity by focusing on skill index, tools usage, etc for applicable phases. We can also club data for different technology for different phases like Req. Gathering, Testing, UAT support, documentation, etc. to get more data points. | ||
| N.Venkateswaran |
Hi Alok, What I told was, we will get a requirement document after 90 days for a project whose FP size is 450. Please note I am also saying that the FP size remains consistent with 450 FP's for each Phase Cheers. | ||
| Steve Neuendorf |
Certainly me, and probably everyone else on this board would wince if someone said, "we did 90 Function Points this month" or if someone asked us how many Function Points we had done so far. But that is just us. What about those, usually the mucky mucks, who have heard all of the "% complete" they are going to hear and would like some sort of demonstration that those doing the work have some clue about what they are doing?  (They all know the rule that says the first 90% of the project takes the first 90% of the time and budget, and the last 10% of the project takes the second 90% of the time and budget; don't give me percent done!) So what is so wrong, if we have a 450 FP project, and we have completed what we can show as 20% of the work as complete by reporting that 90 FP of the 450 FP project are done. Of course the danger is that we may be told to "run with it" when we had 420 FP "done", but we can use our house analogy. We would say that if our 450 square foot house had only 420 square feet done, we still could not move in because the weather can still get in through that 30 square feet remaining and will ruin everything we have accomplished so far. Good Luck, Steve | ||
| Wayne Wild |
We divide the functional components of our projects into functional/testable iterations of code of about 60 to 100 FPs each. This creates iterations of 2 to 4 weeks each. We then track the status of each component within each iteration each week to determine the development status of the project. Developers and tester understand transactions and files better than FPs and they can also demonstrate their status, if there is any question. | ||
| venkataraghava |
Can we please re articulate Reji's question as follows to make more sense in terms of project management. (Assuming we follow water fall model,each phase gets completed before other starts): 1. How do you measure project functionality getting delivered? (say Requirements, Design, etc.,) 2. Can we measure productivity of each phase? Answer to question 1 could be: Say Requirement phase has delivered all application functionality (+ or - 450 FP). We need FP counting/re validation of old counts at the end of each project phase to ensure a phase is complete (including scope creep if any). This process gets repeated at the end of each phase say Design, Coding, etc., Increase in FP count means increase in project scope. Sure will points to revisiting the project timelines, etc., lead to project management interventions Answering question 2, we need matured organizations who have productivity baselines (say hours /FP getting spent in each project phase for a particular technical line). At the end of each project phase, if we do a simple math of number of hours consumed /FP, we can potentially start measuring team productivity and forecast project overrun / underrun accordingly. I will leave these answer for your comments....Going back to Reji's question, we cannot proportion FP across phases. Each phase will deliver same FP (unless there is scope change) to next phase. We will need to find a smart way of using the FP counts delivered out of each phase to measure team productivity and scope creeps. Regards, | ||
| Reji Mathai |
Hi Venkataraghava, I guess you comments more or less agrees with what was said in the earlier posts within this thread. Just for clarification my second question was not "whether we can proportion FP's across each phase" but "whether we can proportion FP's within a phase" and previous posts in this thread have provided their comments on the same. | ||
| Wayne Wild |
We breakdown our functional components into iterations and then develop & deliver code in iterations, as well. We also track hours charged to project by PM, RQ, DS, DV & TS, so we may compare our productivity to industry numbers tracked by ISBSG.org. Once you collect your own project delivery rate and phase percentages then you should be able to predict your future effort very accurately. For us, we have found our numbers to be accurate within +/- 5%. For C# projects under 500 FPs, our PDR is 14 to 16 hrs/FP and our phase breakdown is; PM=15%, RQ=19%, DS=11%, DV=35% & TS=20%. | ||
| Reji Mathai |
Hi Wayne, Thanks for sharing your practical experience. Just wanted to know what are the typical activities that you have included under Testing(TS=20%). Does it include Performance(Non Functional) Testing and User Acceptance Testing as well? | ||
| Wayne Wild |
Our Testing Methods included in the 20% are; 1. Writing test cases, testing the functionality of the code, documenting bugs and tracking them until they have been fixed by a Developer and retested. 2. Creating a Project Quality Plan Plan System 3. Create Test Scripts including creating & running automated tests. 4. Creating Incident/Defect Lists 5. Component Testing 6. Regression Testing It does not include system integration testing, performance testing or the final UAT. | ||
| N.Venkateswaran Username: Nvenk Post Number: 181 Registered: 07-2009 |
Performance testing, UAT and system Intregration testing should be included in the testing itself. cheers |
