| Author | Message | ||
     Abubucker |
Hi All I have a situation as given below. My Client has a legacy application that is to be Replatformed.It is also understood that functionally there will be some change, say a new module will be added or some existing functionality will be changed.However, the primary purpose is replatforming and integration afterwards. Given the legacy nature of the application, there is no sizing done so far. They have some releases planned over the next 18 months and client wants a FP Counting strategy to align to it. My key concern here is that if this project is FP countable in the first place. If it is what would you propose as a strategy. My thinking is that we can size the current application (legacy) to establish a baseline size and later size the completed application to establish the deviation/growth in size. I also feel that we can count at the end of different releases over the 18 month period to track how we are proceeding against the base size. Awaiting your inputs on what could be done. Being different is the Essential Quality of Leadership | ||
| ALOK KHARE |
Hi Abubucker, I am trying to understand your query. It has multiple questions. Let’s convert it into following scenarios: Scenario 1: Existing application where we need to add and change some functionality: - EFP (enhancement function point) is very much applicable here. - You can count EFP for each change request and then apply enhancement productivity to convert this into effort. - Having enhancement productivity is the biggest challenge here, so it is better to start capturing EFP and productivity from the day one. This will help you in future. - Counting baseline Application function point will also help you in o Determining application function point after each enhancement o Other metrics such as application stability, etc. Scenario 2: RePlatforming: I understand, this is change in platform without change in the business functionality e.g. mainframe Cobol code to Unix platform, change in the system s/w version, etc. Since, there are no changes to business functionality associated with this work. Function Point analysis is not much useful for estimating replatforming activities. Scenario 3: Migration using re-engineering approach: Understand the existing application and expected enhancement and develop new application. The development project function point is applicable in this scenario. We normally prepare SRS document, based on existing application and enhancement requirements. This SRS document will be used as input for the counting of development function point count. There should be one time data conversion requirement also, so Conversion FP count will be applicable for one time data conversion. Regards, | ||
| Egon W. Reich Username: Egonreich Post Number: 9 Registered: 12-2009 |
I have often used the following practical approach for estimating replatforming effort: counting the FP size of the entire application to be replatformed, and deriving the effort as a coefficient of the FP size. We used effort coefficients varying from 40% to to 80%, depending on the type of replatforming project. We defined the effort coefficients considering 100% the "classical" enhancement effort (EFP), and considering only the activities needed for replatforming (for example, testing 20%, coding 30%, and so on). Regards E.R. |
