Overview of Function Points

A1 Background Functional Size Measurement (FSM)

SCOPE supports the rules of the Functional Size Measurement Method IFPUG 4.1 and 4.2 and ISO/I EC 20926:2003 standard -Function Point Analysis Method CPM 4.3 Unadjusted. This technique is often referred to as IFPUG Function Point Analysis or "FPA". Functional Size Measurement (FSM) is a technique for measuring software in terms of the functionality it delivers. The ISO/I EC standard for Functional Size Measurement 14143-1:1998 defines FSM as a means of quantifying the Functional User Requirements ie functions that the user has required to be delivered.

The Functional Size can be used for many purposes. However, it is primarily used at the planning stage for input into project resource estimation algorithms for cost, effort and schedule. At the completion of a project it is used to compare performance in terms of the cost effectiveness and efficiency of the development and support teams.

FSM measures the functional requirements of the software. This means that it can be applied before development commences, rather than retrospectively as is the case with other forms of software measurement, such as counting lines of code and/or other physical objects. This capability to measure early, enables accurate estimates to be made, risks to be evaluated, and project scope to be negotiated, before final commitments are made.

FSM also enables comparison of applications and projects based on their size. Productivity rates for applications of a similar attribute profile can be compared for benchmarking and improvement purposes. Productivity rates from past projects can also be used to predict effort, once a project 's Functional Size has been determined.

FSM is used to size software work product. This work product is the output of software new development and enhancement projects. It is the software which is migrated to the production application at project implementation.

Function Point Analysis (FPA) is the IFPUG Method for functionally sizing and is most commonly used Functional Size technique. The second most common method if COSMIC-FFP for sizing real time and control software.

A2 Introduction to Function Point Analysis (FPA)

IFPUG Function Point Analysis (FPA) has been used since the late 1970s to assess the functionality delivered to the user based on the users external business view of the functional requirements. It measures the logical view of an application as compared to measuring the physically implemented view or the internal technical view.

FPA measures these functional requirements in terms of the:

  • business transactions (e.g., Enquire on Fault Record) that the user can perform using the software,
  • business data (e.g., FAULT File) that the software can store and access.

The process of performing Function Point Analysis is called a 'Function Point Count' and it involves the identification, classification and weighting of each of these transactions and data components. The weightings are combined to give the functional size as an Unadjusted Function Point Count. An additional step, involves assessing the technical and quality features embedded in the software product and adjusting the functional size accordingly. The result is referred to as the Adjusted Function Point Count.

The Function Point Analysis technique is used to assess the functionality delivered by software and a 'function point' is the unit of measurement.

A3 Identification of Functional Components

The technique of functional modeling (functional analysis/ functional decomposition) is used to model the relationship between the transactions and the application as a whole. The transactions are mapped onto a functional hierarchy of the application under the business activity to which they contribute.

The following criteria is used, where possible, to check each task to determine if it is a unique elementary process (logical business transaction). It is counted as a unique logical transaction when:

  • it has processing logic (editing, validation etc) different from other similar transactions,
  • it accesses a unique combination of fields and files,
  • on completion, it leaves the business in a consistent, predictable state,
  • it is user recognisable and definable,
  • it is created by business requirements and not the technical requirements of the chosen solution,
  • it is logically independent of other transactions (although it may in some cases be triggered by another transaction),
  • it is logically triggered by an external event,
  • it achieves a business objective, not a technical objective.

The technique of data modelling (information engineering, entity relationship diagramming) is used to identify the data and the relationship between the data. The data files are then mapped to the transactions on the hierarchy which access them.

Data files are logical master groups of data from a business user perspective. They are a group of data that tends to be created as a 'set' although parts of the data may be modified independently. They may be a business reference file eg. Currency Details which are referenced by transactions or business entities maintained by the business transactions.

Data Files do NOT include files created for technical , performance, security, navigation reasons. They are permanent groups of data not stores for temporary data.

A4 Classification of Functional Components

Once all the functional components have been identified they are classified into types depending on the type of activity they perform for the user.

Transactions can be classified into three types:

Þ Inputs

eg. Create Fault Record = Input (enable the user to input data into the software to be stored,)

Þ Outputs

eg. Aged Faults Report = Output (enable the user to extract derived information from the software),

Þ Enquiries

eg. Display Fault Details = Inquiry (enable the user to query stored data

Data files can be classified into two types:

Þ Internal Files

store data input by the user transactions

eg. Fault File = Internal File (store data accessed by the user transactions but not maintained by the users' transactions)

Þ External Files

eg. Account File = External File (where this file is maintained by another system)

A5 Weighting of Functional Components

Once the functional components have been identified and classified they are evaluated for their functional complexity using a set of prescribed attributes. The functions are categorised into either low, average or high complexity. Functional components are awarded Function Points according to their classification of type and categorisation of complexity.

eg.

Create Fault record

Currency File

= External Input

= Internal File

= High Complexity

= Low Complexity

= 6 Function Points

= 7 Function Points

Once all functional components are identified, classified into type, assessed for complexity and awarded 'points' these points are accumulated into a total Un adjusted Function Point Count.

The final step within the IFPUG methodology is to adjust this count for quality and technical characteristics by using the value adjustment factor (range 0.65 - 1.35) for the Adjusted Function Point Count. However in the ISO standard for the IFPUG technique (ISO/IEC 20926) this step is optional, the functional size is reported as the unadjusted value.