1. Function Point Analysis

2. Function Points Analysis (FPA) What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent the functional size of a software application. It is designed to estimate and measure the time, and thereby the cost, of developing new software applications and maintaining existing software applications. It is also useful in comparing and highlighting opportunities for productivity improvements in software development. It was developed by A.J. Albrecht of the IBM Corporation in the early 1980s.

3. Objectives of Function Point Analysis Measure software by quantifying the functionality requested by and provided to the customer. Measure software development and maintenance independently of technology used for implementation. Measure software development and maintenance consistently across all projects and organizations.

4. Important FPA notes Measured from the user's perspective Technology-independent Low cost Repeatable Work well with use cases

5. FPA How is Function Point Analysis done? Working from the project design specifications, the following system functions are measured (counted): External Inputs (EI) External Outputs (EO) Files (ILF-internal logical files) External Inquires (EQ) Interfaces (ELF – external logical files)

6. FPA External Interface Files Internal Logical Files Inquiries InputOutput Boundary

7. FPA EI: An elementary process in which data crosses the boundary from outside to inside.  Data input screen  Another application  Business data: does update ILF  Control data: does not update ILF EO: An elementary process in which derived data passes across the boundary from inside to outside.  Creates reports  Creates output files sent to other applications  Created from ILF and ELF

8. FPA EQ:An elementary process with both input and output components that result in data retrieval from one or more ILF and ELF  Sent outside the application boundary  Input process does not update ILF  Output side does not contain derived data ILF: A User identifiable group of logically related data that entirely within the applications boundary and is maintained through External Inputs EIF: A User identifiable group of logically related data that is used for reference purposes only.  Resides entirely outside application  Maintained by another application  It is an ILF for another application

9. Unadjusted FP Calculation Functional Count by (Complexity) Complexity rated by three categories: Simple Average Complex Each of the 5 functional components has its own unique complexity matrix weighting based on level of complexity

10. Degrees of Influence (DI) Data communications Distributed functions Perfomance objectives Heavily used configuration Transaction rate On-line data entry End-user efficiency On-line update Complex processing Reusability Installation ease Operational ease Multiple sites Facilitate change General characteristics to be ranked by degree of influence from 0-5 Degree of Influence Measures Not Present, or no influence present=0 Insignificant Influence=1 Moderate Influence=2 Average Influence=3 Significant Influence=4 Strong influence, throughout=5

12. FP Calculation Complexity Adjustment Factor (CAF)  CAF = 0.65 + 0.01 x DI each degree of influence is worth 1 percent of a Total count factor which can range from 0.65 to 1.35 Adjusted Function Points (AFP)  AFP = CAF x UFP

13. Complexity of Files& Transactions Data Element Type (DET) A unique user recognizable field from a business perspective which participates in a transaction or is stored on a logical data file. Record Element Type (RET)  A user recognizable subgroup of data elements within an ILF or EIF. (orders types) The complexity of an transaction is determined by counting the number of logical File Types Referenced (FTRs) and the number of DET.

14. Productivity Index Function points method can be used for measuring the productivity of development activities

15. Critics to FPA The calculation of function counts tends to take a black box view of the system. The user defined function types currently established may not be wholly appropriate for current technology. Function point counts are affected by project size Difficult to apply to massively distributed systems or to systems with very complex internal processing Difficult to define logical files from physical files

16. Critics to FPA The classification of the user function types into simple, average, and complex appears to be oversimplified The choice of weights was determined by debate and trial. The restriction to 14 processing complexity factors is not going to be satisfactory for all time

17. Benefits of FPA Organizations that adopt Function Point Analysis as a software metric realize many benefits including:  improved project estimating  understanding project and maintenance productivity  managing changing project requirements; and gathering user requirements

18. 3D Function Points Each class is an internal file Messages sent across the system boundary as transactions Require a greater degree of detail in order to determine size and consequently make early counting more difficult.

19. Object-Oriented Function Points(OOFP) Characterized by a mapping of FP concepts (logical files and transactions) to OO concepts (classes and methods), and by a flexible method for handling specific OO concepts like inheritance and aggregation.

20. OOFP Uses OMT Model  Object Model * Static representation of classes and objects First to be developed so can be measured early stages  Function Model Data Flow Diagrams Identifiying and Design some methods in early stages  Dynamic Model State machiness Use case and Scenarios

21. OOFP Central Analogy to map FP to OOFP  Logical files (collection of user identifiable data)  Classes(encapsulates collection of data items)  Transactions  Methods Application Boundary  External classes encapsulates non-system components (external services and reused library classes); EIF  Classes with in the App. Boundary is ILF

22. OOFP OOFP Calculation

23. OOFP Process Analyze object model and identify units to be counted as LF. Calculate the complexity of each LF and SR. Convert complexity values to numbers If LF is “reused” its OOFP value is calculated with a scale factor f<=1 All OOFP values are summed up.

24. OOFP Process

25. OOFP Identify LF  Classes are mapped to LF  Aggregation and Inheritance is encountered Mainly a concern of implementation  At analysis phase Each class is a LF Scale factor =1 (Origin of class does not matter)  At design phase Scale factor <1, reuse makes classes easier to develop For designer, each class is LF For user perspective, it is complicated

26. OOFP Ways to Identify LF  Simple LF Sigle Class is a LF  Composite LF Aggregation Generalization/Specialization Mixed (combine aggregation and generalization)

27. Single Aggregation Generalization Mix

28. OOFP Calcution of DET and RETs  One RET for each ILF/ELF  Simple LF Simple attributes sucs as integer and strings counted as DET Associations are counted as DET or RET accoring to cardinality Single valued association is DET Multiple valued association is RET

29. OOFP Composite LF  DETs and RETs are counted as in simple LF, except for aggregation  Aggregations act as subgroups in composite LF  One RET is counted for aggregations For each OOFP, weighted vector table for ILF and ELF in IFPUG ( international function point user group )

30. OOFP Service Requests  Concrete methods are only counted once, abstract methods are not counted Simple Items: (analogy to DET) simple data items referenced as a argument simple global variables referenced by the method Complex Items: (analogy to FTR) Complex arguments, objects and complex global variables references by the method For each OOFP(SR), weighted vector table for EI,EQ in IFPUG

31. OOFP