Jump to content

Function point

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Guruparan18 (talk | contribs) at 13:33, 20 August 2009 (→‎Function point analysis). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A function point is a unit of measurement to express the amount of business functionality an information system provides to a user. Function points are the units of measure used by the IFPUG Functional Size Measurement Method. The IFPUG FSM Method is an ISO recognised software metric to size an information system based on the functionality that is perceived by the user of the information system, independent of the technology used to implement the information system. The IFPUG FSM Method (ISO/IEC 20926 SOFTWARE ENGINEERING - FUNCTION POINT COUNTING PRACTICES MANUAL) is one of five currently recognised ISO standards for Functionally sizing software.

Introduction

Function points were defined in 1979 in A New Way of Looking at Tools by Allan Albrecht at IBM.[1] The functional user requirements of the software are identified and each one is categorized into one of five types: outputs, inquiries, inputs, internal files, and external interfaces. Once the function is identified and categorised into a type, it is then assessed for complexity and assigned a number of function points. Each of these functional user requirements maps to an end-user business function, such as a data entry for an Input or a user query for an Inquiry. This distinction is important because it tends to make the functions measured in function points map easily into user-oriented requirements, but it also tends to hide internal functions (e.g. algorithms), which also require resources to implement. Over the years there have been different approaches proposed to deal with this perceived weakness, however there is no ISO recognised FSM Method that includes algorithmic complexity in the sizing result. The variations of the Albrecht based IFPUG method designed to make up for this (and other weaknesses) include:

  • Early and easy function points. Adjusts for problem and data complexity with two questions that yield a somewhat subjective complexity measurement; simplifies measurement by eliminating the need to count data elements.
  • Engineering function points. Elements (variable names) and operators (e.g., arithmetic, equality/inequality, Boolean) are counted. This variation highlights computational function.[2] The intent is similar to that of the operator/operand-based Halstead measures (see Halstead Complexity Measures).
  • Bang measure - Defines a function metric based on twelve primitive (simple) counts that affect or show Bang, defined as "the measure of true function to be delivered as perceived by the user." Bang measure may be helpful in evaluating a software unit's value in terms of how much useful function it provides, although there is little evidence in the literature of such application. The use of Bang measure could apply when re-engineering (either complete or piecewise) is being considered, as discussed in Maintenance of Operational Systems--An Overview.
  • Feature points. Adds changes to improve applicability to systems with significant internal processing (e.g., operating systems, communications systems). This allows accounting for functions not readily perceivable by the user, but essential for proper operation.

Function point analysis

The method of measuring the size of an information system and expressing it in a number of function points is called function point analysis (FPA). The method is kept up to date by worldwide cooperating FPA user groups like NESMA and IFPUG. A function point analysis expresses the functional size of an information system in a number of function points (for example: the size of a system is 314 FPs). There are many uses and benefits of function points [3] and the functional size may be used as input into many types of project and organization decisions including determining the:

  • budget for application development or enhancement costs.
  • budget for the annual maintenance costs of the application portfolio.
  • project productivity after completion of the project.
  • Software Size for cost estimating.

Many organizations measure function points to different levels of accuracy [4] depending on the purpose for which the software size will be used.

FPA can also be used to find the testing effort required in the information system; The formula is Number of Test Cases = (Function Points)1.2[5]

Function Points measures systems from a functional perspective - they are independent of any underlying technology. Regardless of language, development method, or hardware platform used, the number of function points for a system will remain constant. The only variable is the amount of effort needed to deliver a given set of function points.

The Functional User Requirements have two types of functions, Data Functions and Transactional Functions. These are categorised into the 5 types measured by the IFPUG and NESMA FSM Method and assigned function points.

  1. Data Functions → Internal Logical Files
  2. Data Functions → External Interface Files
  3. Transaction Functions → External Inputs
  4. Transaction Functions → External Outputs
  5. Transaction Functions → External Inquiries


Data Functions → Internal Logical Files:
Group of user recongnized, logically related data. Example : Employee data stored in Employee file (Employee Name, Employee ID, Employee Date of Birth, Date of Joining).

Data Functions → External Interface Files:
Group of logically related data, meant for reference purpose only, data is external to application(maintained by the other application). External interface file is internal logical file of the other application. Example: Company share data stored outside the system.

Transaction Functions → External Inputs:
Data coming from outside and getting stored in internal files. Example like Add a User, Add an Employee. The validation that we are making in the transaction is not the External input. For example, the register email is not directly the external input. This contain several transactions like validating the email id and email id availability and submitting the data. Final submit is the only external input. The others will become the external inqueries.

Transaction Functions → External Outputs:
Data from inside that goes outside and that is the derived data. Example: Tax calculation, Salary calcution.

Transaction Functions → External Inquiries:
Data from outside comes inside but this is not maintained in internal files. Data from inside goes outside but not the derived data. Example: Check account balance in ATM, Checking employee details with query.


Criticisms of Function Points

Function points, and many other software metrics, have been criticized as adding little value relative to the cost and complexity of the effort.[6][7] The effort in computing function points has only a marginal error reduction, in part, because much of the variance in software cost estimates are not considered (such as business changes, scope changes, unplanned resource constraints or reprioritizations, etc.). Also, if the measurement is used for the decision of whether to invest in the software, then a given measurement effort, it is argued, is more valuable if it is applied to measure benefits than costs. Applied information economics, which computes the economic value of such measures, often leads users to spend measurement efforts on other issues.

Some technical criticisms are indicated in Change points: A proposal for software productivity measurement, Journal of Systems Software, Vol. 31, September 1995, by Vernon V. Chatman III. A proposal to 'evolve' function points was published in Crosstalk: The Journal of Defense Software Engineering, February 2001, by Lee Fischman.

References

  1. ^ A. J. Albrecht, “Measuring Application Development Productivity,” Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14–17, IBM Corporation (1979), pp. 83–92.
  2. ^ Engineering Function Points and Tracking System, Software Technology Support Center, Retrieved on May 14, 2008
  3. ^ Uses and Benefits of Function Point Counts - Pam Morris Total Metrics - Function Point Resource Centre]
  4. ^ Levels of Function Point Counting - Pam Morris Total Metrics - Function Point Resource Centre
  5. ^ Estimating Software Costs - T. Capers Jones
  6. ^ Douglas Hubbard The IT Measurement Inversion, CIO Magazine, 1999
  7. ^ Douglas Hubbard How to Measure Anything: Finding the Value of Intangibles in Business, John Wiley & Sons, 2007

See also

Retrieved from "https://en.wikipedia.org/w/index.php?title=Function_point&oldid=309064206"