SIZE ESTIMATION USING FUNCTION POINT

Size: px
Start display at page:

Download "SIZE ESTIMATION USING FUNCTION POINT"

Transcription

1 SIZE ESTIMATION USING FUNCTION POINT Monika Dixit Project Assistant, CDAC-NOIDA C-21A, Lane 12, Shashi Garden, Mayur VIhar 1, Delhi Abstract: Software practitioners are facing the problem to provide early and accurate software project estimates. By far, the project sizing technique that delivers the greatest accuracy and flexibility is the International Function Point Users Group (IFPUG) Function Point methodology. Based on logical, user defined requirements; IFPUG Function Points permit the early sizing of the software problem domain. In addition, the IFPUG Function Point methodology presents the opportunity to size a user requirement regardless of the level of detail available. An accurate Function Point size can be determined from the detailed information included in a thorough user requirements document or a functional specification. Keywords- Data Element Type, Function Point, IFPUG, Record Element Type, VAF. I. INTRODUCTION Function Points are basis or unit of measure of software like watt for power, degrees for temperature.function point was developed by Alan Albrecht. They provide the means to quantify the functionality which is going to be delivered to the end users. Function Point Estimation For function point estimation following steps are involved: 1. Determine the type of function point count: There are three types of function point counts. Development project function point count This type of function point count is concerned with new development work (that is to be developed). Enhancement project function point count This type of function point count measures updation or modifications to existing applications and includes the combined functionality provided to users by adding new features, deleting old features and updating the existing features. Application function point count This type of function point count measures an existing production application. 2. Identify the application boundary (being delivered to the user). We need to identify how the data moves in from the application. And see how the application maintains the data. 3. Identify and rate transactional function types to determine their contribution to the unadjusted function point count. Transaction is an elementary process which is the smallest unit of activity. External Input (EI) this is an elementary process in which there is a flow of data across the boundary of the application.the data must be received from outside the application boundary. When you are counting External inputs or inputs for your application you must see following aspects: Are you adding something? Are you updating/changing something? Are you deleting something? Etc., 20 Monika Dixit

2 External Output (EO) is an elementary process in which the data flows from inside to outside the application boundary. When you are counting External outputs or inputs for your application you must see following aspects : Output screens Print screens Reports screens Retrieve screens and etc. External Enquiry (EQ) is an elementary process which is a combination of both input and output that results in data retrieval from one or more internal logical files or external interface files. This does not updates any ILF. When you are counting External enquiries for your application you must see following aspects: Search for records Listing records Login Screens and etc 4. Identify and rate data function types to determine their contribution to the unadjusted function point count. Internal Logical Files is a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs. This includes the all the files contained within the application. External Interface Files is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. To be counted as an EIF it must be an ILF in some other application. 5. Determine Unadjusted Function Point Count. The unadjusted function point count reflects the specific countable functionality Provided to the user by the project or application. It does not cover anything about non functional user requirements such as system usability, Reliability, performance etc. 6. Determine the Value Adjustment Factor Fourteen General System Characteristics. The Value Adjustment Factor is based on 14 general characteristics that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help to determine the degrees of impact of the characteristics. Each GSC is evaluated in terms of its degree of impact on a scale of 0 to 5 0- No impact 1- Incidental (by chance) impact 2- Moderate impact 3- Average impact 4- Significant impact 5- Strong impact throughout 7. Calculate the final Adjusted Function Point count. Complexity Matrix Used For EI FTR 1 to 4 DET 5 to 15 DET 16 or more DET 0 to 1 LOW LOW AVERAGE 2 LOW AVERAGE HIGH 3 or more AVERAGE HIGH HIGH 21 Monika Dixit

3 Complexity Matrix Used For EO & EQ FTR 1 to 5 DET 6 to 19 DET 20 or more DET 0 to 1 LOW LOW AVERAGE 2 to 3 LOW AVERAGE HIGH 4 or more AVERAGE HIGH HIGH Complexity matrix used for ILF and ELF RET 1 to 19 DET 20 to 50 DET 51 or more DET 1 LOW LOW AVERAGE 2 to 5 LOW AVERAGE HIGH 6 or more AVERAGE HIGH HIGH Complexity Values Complexity Level Low Average High External input External Output External Enquiry Internal Logical Files External Interface File II. FUNCTION POINT ESTIMATION FOR EMPLOYEE INFORMATION SYSTEM Employees are the important assets of an organization. Employee Information System is used to manage and keep track of the employee information of an organization. This system will have various module but for the sake of complexity S.No. Information Contents 1. Employee_Basic_Info Emp_Id, Name, Father_name, Mother_Name, date of Birth, Pr_Phone, Sec_Phone, credential_id Perm_Add(street, city, state,pincode, state, country) Corr_Add(street, city, state, pincode, state, country), , Department,Date of Joining, Branch/Center Details, Grade 2. Further Info PF_ Number, PAN_Number, Passport_No, Passport_Status, Driving_License_Number, Driving_License_Status, Mother_Tongue, Marital_Status, Blood_group,Emp_Id 3. Department Dept_Id, Emp_Id,Dept_name 4. Salary ,Emp_Id,Basic_Salary, Hra, Grade_Pay,DA,Total_Allowances 5. Account Emp_Id, Bank_Name, Amount,Acc_No. 6. Tour Emp_Id,Dept_Id,Tour_Date,Place,Time 22 Monika Dixit

4 Internal Logical File S. No. ILF Name DET RET Complexity UFP 1. Employee_Basic_Info 24 1 Low 7 2. Further_Info 10 5 low 7 3. Department 3 1 low 7 4. Salary 7 2 Low 7 5. Account 4 2 Low 7 6. Tour 5 2 low 7 Total UFP External Interface Files S. No. ELF Name DET RET Complexity UFP 1. Payment_Info 6 2 LOW 5 Total UFP External Inputs S.No. EI Name DET FTR Complexity UFP 1 Employee_Add 24 2 High 6 2 Employee_Modify 23 2 High 6 3 Employee_Delete 24 2 High 6 4 Further_Info_Add 10 1 Low 3 5 Further_Info_Modify 9 1 Low 3 6 Further_Info_Delete 10 1 Low 3 7 Department_Add 3 1 Low 3 8 Department_Modify 1 1 Low 3 9 Department_Delete 3 1 Low 3 10 Salary_Add 7 1 Low 3 11 Salary_Modify 6 1 Low 3 12 Salary_Delete 7 1 Low 3 13 Account_Add 4 1 Low 3 14 Account_Modify 3 1 Low 3 15 Account_Delete 4 1 Low 3 16 Tour_Add 5 1 Low 3 17 Tour_Modify 3 1 Low 3 18 Tour_Delete 5 1 Low 3 Total UFP 23 Monika Dixit

5 Data Element type (DET) & File Type Referenced (FTR) for External Output (EO) S.No. EO DET FTR Complexity UFP 1. Employee_Basic_Info 24 1 Average 5 2. Further_Info 10 1 Low 4 3. Department_Info 3 1 Low 4 4. Salary_Info 7 1 Low 4 5. Account_Info 4 1 Low 4 6. Tour_Info 5 1 Low 4 Total UFP DET & File Type Referenced (FTR) for External Inquiry (EQ) S.No. EQ DET FTR Complexity UFP 1. Employee_Details 6 1 Low 3 2. Salary_Status 4 2 Low 3 Total UFP Value Adjustment Factor: System General Characteristics 24 Monika Dixit Impact Value Data Communication 3 Distributed Data Processing 4 Performance 4 Heavily Used Configuration 2 Transaction Rate 1 Online data Entry 0 End User Efficiency 3 Online Update 1 Complex Processing 1 Reusability 4 Install 2 Operational Ease 2 Multiple Site 5 Facilitate Change 4 Total 36 VAF = (Impact Score *0.01) +.65 =(48*0.01)+.65

6 =1.13 Function Point Function point is calculated by the below formula: FP= UFP * VAF S.No. Function Type UFP VAF FP 1. External Inputs External Output External Enquiry Internal Logical Files External Interface files 5 6 Total So in the similar way the function point for the other modules can be calculated. And hence the size can be estimated. III. CONCLUSION: Size estimation for the project is proved to be beneficial not only for the organization as well for the client as they receive product within deadline with high quality.often to meet the hard deadline of the client enough time is not devoted for the testing so size estimation will help the testing team to calculate the time required to test the features of the product well. Through size estimation the testing team will be able to estimate the test effort required for testing the product. IV. REFERENCES: [1] Roger Heller, Vice President, Q/P management Group, An Introduction to Function Point Analysis [2] INC [3] [2] The Principles of Sizing and Estimating Projects Using International Function Point User Group [4] (IFPUG) Function Points, David Garmus, The David Consulting Group, 2006 [5] [3] Function Point Sizing, Innovative Solutions in Cost Estimating, Bruce Fad, PRICE Systems LLC, [6] Dayton SCEA Chapter November 4,2002 [7] [4] Function Point Counting Practices Manual (Release 4.1), International Function Point User s Group [8] (IFPUG), May 1999 [9] [5] User Guide: Function Point Analysis Spreadsheet, Angela H. Benton, 1996 BellSouth [10] Telecommunications, Inc, April 1996 [11] Muhammad Danyal Ashraf, Prof. Naeem U. Janjua Test Execution Effort Estimation (Teee) Model In Extreme Programming, International Journal of Reviews in Computing 31st December Vol. 8 [12] IFPUG: Function Point CountingPractices Manual, Release [13] R. S. Pressman, Software Engineering: A Practitioner's Approach, McGraw-Hill, Monika Dixit

7 [14] Chintala Abhishek, Veginati Pavan Kumar, Harish Vitta, Praveen Ranjan Srivastava Test Effort Estimation Using Neural Network, J. Software Engineering & Applications, 2010, [15] Jiangping Wan1, Ruoting Wang Empirical Research on Critical Success Factors of Agile Software Process Improvement*, J. Software Engineering & Applications, 2010, [16] David Talby, Arie Keren,Orit Hazzan and Yael Dubinsky Agile Software Testing in a Large-Scale Project I E E E C o m p u t e r S o c i e t y, 2006 [17] Andreas Schmietendorf, Martin Kunz, Reiner Dumke Effort estimation for Agile Software Development Projects [18] Edward R Carroll Estimating Software Based on Use Case Points [19] D. S. Kushwaha and A. K. Misra, Software Test Effort Estimation, ACM SIGSOFT Software Engineering Notes, Vol. 33, No. 3, May [20] M. Chemuturi, Software Estimation Best Practices, Tools & Techniques: A Complete Guide for Software Project Estimators, J. Ross Publishing, Lauderdale, July [21] R. S. Pressman, Software Engineering A Practitioner s Approach, 5th Edition, McGraw Hill, New York, [22] B. T. Rao and B. Sameet, A Novel Neural Network Approach for Software Cost Estimation Using Functional Link Artificial Neural Network, International Journal of Computer Science and Network Security, Vol. 9, No. 6, June 2009, pp [23] H. Zeng and D. Rine, Estimation of Software Defects Fix Effort Using Neural Network, IEEE 28th Annual International Computer Software and Applications Con- ference (COMPSAC 04), Los Alamitos, September 2004, Vol. 2, pp [24] K. K. Agarwal, P. Chandra, et al., Evaluation of Various Training Algorithms in a Neural Network Model for Software Engineering Applications, ACM SIGSOFT Software Engineering Notes, Vol. 30, No. 4, July 2005, pp [25] S. Nageswaran, Test Effort Estimation Using Use Case Points (UCP), 14th International Software/Internet Qua- lity Week, San Francisco, 29 May-1 June [26] T. E. Hastings and A. S. M. Sajeev, A Vector-Based Approach to Software Size Measurement and Effort Estimation, IEEE Transactions on Software Engineering 26 Monika Dixit