Measuring the Function Points for Migration Project: A Case Study

: In this study, we extend the study of Function Point Analysis (FPA) for the measurement of source code based migration project using the migration tooling options. FPA is an objective and structured technique to measure software size by quantifying its functionality provided to the user, based on the requirements and logical design. It is noticed that the procedure for the above measurement is not fully described in FPA method. Hence, the same estimation concept has been applied to an in-house project in an experimental basis at a leading software development organization. The yielded results are compared with FPA for the reengineering project.


INTRODUCTION
One of the most important activities in the early stages of software development is estimation. Size of the software [1] , be it Function Points or Lines of Code, plays a pivotal role in this process and forms the base for deriving a number of metrics to measure various aspects of the software throughout the development cycle. Hence, measuring the size of the software becomes critical though many other sizing measures such as objects, classes, modules, screens, programs and so on. Accurately predicting the size of the software has always troubled the software industry over the years. Function Points are becoming widely accepted as the standard metric for measuring software size.
We sketch briefly for existing software systems [2] and in particular legacy systems, where the functional documentation is often missing or obsolete. Hence, the standard Function Point Analysis (FPA) is not applicable for the sizing of enhancement projects (the implementation of change requests) as back firing is not applicable either it only refers to the complete software system and its precision is not sufficient to size individual enhancement projects. A method to perform FPA based on the source code is proposed. This method is instantiated for COBOL and JCL (Job Control Language). It can be integrated into the maintenance process such that each change request is defined in terms of the objects from the Function Point (FP) conceptual model. In this way, the sizing of a change request is obtained for free.
It is demonstrated that simplified way of the IFPUG (International Function Point Users Group) function points based on the simplification ideas suggested by NESMA (Netherlands Software Metrics Association) to estimate the size of management information systems [3] . He analyzed nearly twenty web applications using the simplified method, whose result were very close to the ones using the IFPUG detailed method. The simplified method is based on assigned low complexity to all the data and transactional functions. Thus, when data and transactional functions are identified, their complexity is determined automatically for Web based applications [4] .

Function points analysis:
Function Point Analysis is a well-known method to estimate the size of software systems and software projects [5] . This technique breaks the system into smaller components so that they can be better understood and analyzed. Function Point count can be applied to development projects, enhancement projects and existing applications as well. Function Point Analysis is expected to obtain the following objectives [6] : * Determine the type of Function Point count. * Determine the application boundary * Identify and rate transactional function types to calculate their contribution to the Unadjusted Function Point count (UFP). * Identify and rate the data function types to calculate their contribution to the UFP. * Determine the Value Adjustment Factor (VAF) by using General System Characteristics (GSCs). * Finally, calculate the adjusted Function Point count.
There are 5 major components of Function Point Analysis which capture the functionality of the application. These are External Inputs (EIs), External Outputs (EOs), External Inquiries (EQs), Internal Logical Files (ILFs) and External Interface Files (EIFs). First three are treated as Transactional Function Types and the last two are called Data Function Types. Each of the components of Function Point Analysis is explained in brief in the following sub-sections [6][7][8] .

External input (EI):
External Input is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information.

External output (EO):
External Output is an elementary process in which derived data passes through the boundary from inside to outside. Additionally, an EO may update an internal logical file. The data creates reports or output files sent to other applications. These reports and files are created from information contained in one or more internal logical files and external interface files. The derived data is processed beyond direct retrieval and editing of information from internal logical files or external interface files.

External inquiry (EQ):
External Inquiry is an elementary process with both input and output components that results in data retrieval from one or more internal logical files and external interface files. The input process does not update or maintain any FTRs (Internal Logical Files or External Interface Files) and the output side does not contain derived data.

Internal logical file (ILF):
Internal Logical File is a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs. Even though it is not a rule, at least one external output and/or external inquiry should include the ILF as an FTR.

External interface file (EIF):
External Interface File is a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application boundary and is maintained by external inputs of another application. In other words, the external interface file is an internal logical file for another application. At least one transaction, external input, external output or external inquiry should include the EIF as a File Type Referenced.
This FPA model, developed by Albrecht [9,10] is widely used in software industry. The model estimates software size by counting "function points". This is done using three steps [11] : Step 1: Computing an Unadjusted Function Count (UFC): Using the above five type of components (EI, EO, EQ,ILF and EIF), the number of items in the system is counted and the level of complexity is determined (distinguishing between simple, medium and complex). Thus the total number of items are 5 components multiply with 3 level of complexity. Each level has a weight (provided by the model). The UFC is computed as follows [9][10][11] : Step Once all the GSCs have been rated, Total Degrees of Influence (TDI) is obtained by summing up all the ratings [11] .
Where, F i is the weight of attribute I Now, Value Adjustment Factor is calculated using the formula [10] : Step 3: After determining the Unadjusted Function Point count (UFP) out of transactional and data function types and calculating the Value Adjustment Factor (VAF) by rating the general system characteristics, the final Function Point count can be calculated using the formula [ To use this model, the software development organization has to maintain a database of its projects, including duration, cost, manpower effort and function points (FE). Based on this database, the cost (in terms of time and money) of one FP can be computed. Henceforth, the FP of any new project can be computed as described above and the cost estimates derived.

Re-engineering case study:
To measure the Function Point for re-engineering application, we apply the FPA method for the in-house re-engineering project at one of the leading software organization. Identity is not disclosed honouring the industry sentiments.

About the project:
The Project is an application namely Resource Requirement Form (RRF) which is basically developed for associates who are working for the organisation. The Project has the following features: * Each request form has a unique ID, which is used for tracking and status viewing. * It automates all functions of the workflow pertaining to hardware and software installation processing. * Generates automatic mail between users to draw their attention. * Approving Authorities name, time and data is endorsed from the terminal. * When the form is accepted /submitted by higher authorities, the associate receives feedback on email with date and time of the approval of the request. * E-mail notification is sent at every transition of the flow of the process. The Project was developed in VB, ASP with SQL server environment and is being used successfully by the associates. Over the period, the higher authorities decided to redesign and redevelop this in .Net environment with some additional requirements. We measured the FP as per given requirements documents. Detail is given in Table 1.
We also estimate the FP count for the same project which was developed using Migration Model for Legacy Source (MM LC ) [12] . Using this model, the legacy source codes are loaded into .Net migration tool. The tool converts 45 % of source code into target environment successfully. A migration tool cannot resolve the remaining compatibility issue and the developer need to fix the issues [13] . The developer needs to pay attention to the following activities in this regard.
1. The development team will have to rewrite the code before using the migration tool as and when the target environment does not support certain features [14] . 2. The duplicate code removal, implementing coding standards, upgrading the problematic syntax and controls should be done [15] . 3. Once the migration tool is loaded, the development team needs to take care of certain editing like syntax changes, changes in control object models, unsupported functions requiring complete redesign, etc [16] . FP = UFC * VAF 4. Another important factor is knowledge transfer related to Focus on Future Re-engineering (FFR). In this stage, the developer, should share knowledge and train the co-developers for transparency leading to be better understanding and accurate and fast achievement of the desired objectives of the project. The FP count as per MM LC is given in Table 2.

DISCUSSION
Variances of Functional Count of normal reengineering process and in using migration model were very less. To be advantageous for the customer Function Points can be used to help specify to a vendor the key deliverables, so as to ensure that appropriate levels of functionality will be delivered and to develop objective measures of cost-effectiveness and quality. They are most effectively used with fixed price contracts as a means of specifying exactly what will be delivered. From a vendor perspective, successful management of fixed price contracts depends absolutely on accurate representations of effort. Function Points offer a vast number of benefits by capturing the size of the software from its functionality standpoint. FPA does have some disadvantages as follows, Kitchenham [17] Developer's experience: Implementation of a specific logic differs based on the level of experience of the developer. Hence, the number of lines of code differs from person to person. An experienced developer may implement certain functionality in fewer lines of code than another developer of relatively less experience does, though they use the same language.

Advent of GUI tools:
With the advent of GUI-based languages/tools such as Visual Basic, much of the development work is done by drag-and-drops and a few mouse clicks, where most of the time the programmer virtually writes no piece of code. It is not possible to account for the code that is automatically generated in this case. This difference invites huge variations in productivity and other metrics with respect to different languages, making the lines of code more and more irrelevant in the context of GUI-based languages/tools, which are prominent in the present software development arena.

CONCLUSION
This study has taken the critical view of Function point estimation issues with migration tool related to reengineering software perspective. The estimated result is close to normal FPA estimation process, but it specifies a particular migration tool. This method must be validated by applying a number of re-engineering applications with a known FPA model. The results have to be discussed with the team of software engineers for further enhancement.