Function point method

from Wikipedia, the free encyclopedia

The function point method (also analysis or method , FPA for short ) is used to evaluate the technical-functional scope of an information technology system , hereinafter referred to as application. The result of a function point evaluation is called the "functional size" and is specified in the unit "function points", or fp for short. The FPA is the most widespread expression of various evaluation methods summarized under the term Functional Size Measurement .

Function points are used in software development as a basis for cost estimation, benchmarking and generally to derive key figures for productivity and quality. A function point evaluation is independent of the underlying technology of the application.

The functional size is determined by breaking down the functional requirements of an application into the smallest activities that make sense for the user, the elementary processes. The same elementary processes are only rated once. A defined point value is assigned to each elementary process. The sum of the point values ​​of all elementary processes results in the functional size.

Strictly speaking, the FPA or its result is not to be regarded as a measured variable , the designation of the FPA as software metrics or in English as "Functional Size Measurement" is not entirely appropriate. It is correct to speak of an evaluation procedure.

Standards

Allan J. Albrecht (1927–2010) developed function point analysis for IBM in the late 1970s . The process has developed into different variants over the course of time, which are now summarized under the term Functional Size Measurement . This is defined by the ISO standard ISO / IEC 14143.

Current standard

As a rule, the term Function Point Analysis, FPA for short, is the variant of the International Function Point Users Group (IFPUG), which is standardized as the ISO norm ISO / IEC 20926. The current ISO standard corresponds to the IFPUG standard in version CPM 4.3.1, where CPM stands for "Counting Practices Manual".

For further alternatives to the FPA see also Functional Size Measurement .

Major changes

With the inclusion of the IFPUG standard in the ISO catalog for the first time in 2003, there has been a significant change compared to earlier versions: the so-called value factor (in the Standard Value Adjustment Factor, VAF for short, sometimes also referred to as weighting factor in German) as a rule no longer to be used; the distinction between "unadjusted" and "adjusted function points" is thus no longer necessary. This was reproduced by the IFPUG in their standard CPM 4.3.1.

In addition to the technical and functional requirements, the value factor should also take into account non-functional requirements in the function point value. However, this is no longer permissible according to the ISO standard ISO / IEC 14143. The use of the value factor has also been dispensed with in the past if, for example, function points were used as the basis for an effort estimate and these non-functional requirements have already been taken into account in the effort estimation model. This is the case with the cost estimation model COCOMO .

method

User view

The user view is decisive for determining the functional size. The concept of the user in the FPA corresponds conceptually to the actor in the Unified Modeling Language . A user can be a natural person, other software or, for example, a machine. The term user perspective should therefore by no means be taken literally. The user perspective focuses on the fact that only those functions of the software that support the respective business processes are to be considered in the assessment.

Identification of the transactions

An elementary process is defined as the smallest activity that makes the most sense for the user and that the system leaves in a consistent state after it has been carried out. Elementary processes are divided into three transaction types ("Transactional Functions").

  • Input ("External Input", EI)
  • Output ("External Output", EO)
  • External Inquiry (EQ)

The main purpose of the elementary process is decisive. The main purpose of an entry is to maintain an internal database and to process data that originate from outside the application. An output or a query have the main purpose of presenting information at the application boundary. For an output it is also required that its processing logic contains mathematical calculations or formulas, the creation of derived data, the maintenance of an internal database or a change in the system behavior.

The definition of the transactions shows that only those elementary processes are evaluated that are related to a data flow across the application boundary.

The same transactions should only be rated once. Two transactions are considered to be the same if they use the same data and contain the same processing logic, with minor variations not being excluded. In any case, variations are no longer considered "small" in this sense if the two transactions are based on two recognizably different technical and functional requirements.

Functional hierarchy tree

Example of a functional hierarchy tree

The process of identifying the transactions largely follows the procedure known from structured analysis . It therefore makes sense to present the result in the form of a functional hierarchy tree. The notation of this functional hierarchy tree is not part of the standard, but its use has largely become established in practice.

Identification of the databases

In addition to the transactions, the FPA also evaluates the databases managed by the software ("data functions"). A database is defined as a set of technically recognizable and logically related data. Here too, the assessment should be made from the user's point of view. Databases are still differentiated into

  • Internal data sets ("Internal Logical File", ILF for short) and
  • External databases ("External Interface File", EIF for short).

The terms are meaningful: Internal databases are those that are maintained within the evaluated application (write access). External databases are only referenced or read by the evaluated application, but are maintained in another application.

Determination of the functional size for an application

There are detailed rules in the standard for assigning the point value to transactions and databases, the so-called "complexity rules". The point value for a transaction results from the number of fields used and the number of data sets used in the transaction. For the data stocks, the point value is determined based on the number of fields contained and the number of field groups. A field group is a set of technically related data fields, for example the set of fields Salutation, Title, First Name and Last Name, which together represent the name of a natural person.

The following table shows the minimum, average and maximum point values ​​possible for the individual transaction types and data store types:

Elementary process Minimum
score		 Medium
score		 Maximum
point value
input 3 4th 6th
output 4th 5 7th
query 3 4th 6th
Internal database 7th 10 15th
External database 5 7th 10

The sum of the point values ​​of all transactions and databases is then the functional size of the application.

Functional size for software adjustments and extensions

The determination of a functional size is often not required for an existing application, but should be used to evaluate a project in which a new application is created or existing applications are adapted and expanded. There are simple rules for this in the standard.

The functional size of a new development project is equated with the result of the application delivered by the project.

The functional size of an expansion project is the sum of the point values ​​of all newly added, changed and removed transactions and databases. For a project, each transaction and each database is rated as changed a maximum of once, regardless of the actual scope of the specific changes. The assignment of the point values ​​to the respective transactions and databases takes place in accordance with the rules described above for determining the functional size of an application.

For both new development and expansion projects, if available, the functions that are used to convert data from earlier versions of the application are also evaluated.

Even if these rules seem quite simple at first glance, they have proven themselves in practice and offer a good basis for evaluating expansion projects, which are by far the most common project type in industrial software development practice today.

Rapid approximation

In practice, the rules of complexity play a minor role, since an approximation method known as "Rapid" is widely used. Thereafter, an input 4 fp, an output 5 fp, a query 4 fp, an internal database 7 fp and an external database 5 fp are assigned. For larger applications and projects (about> 100 fp) it is assumed that the error resulting from this approximation is negligible compared to a detailed complexity assessment.

example

A small example based on an application that is intended to support the planning, organization and implementation of seminars of a seminar organizer is used to illustrate this. In order to keep the example straightforward, the technical and functional requirements presented below only represent a section of the total requirements. It should be noted that in Part 4 of the CPM there are further detailed and complete examples, which in particular also describe the specific procedure for explain the identification of transactions and databases.

Technical and functional requirements

The customer has u. a. formulated the following specific requirements:

The application is intended to support the planning and administration of seminar events (hereinafter referred to as events). To do this, it must be possible to create an event with its relevant characteristics. Missing or incorrect entries should also be able to be corrected later. Of course, an overview of the events and a detailed view of individual events are also required. The following business cases should be supported:

  • Cancellation of an event for which there are no confirmed registrations
  • Cancellation of an event for which there are already confirmed registrations
  • Rescheduling an event

rating

For this application, the following transactions and datasets are identified, with the point value assigned according to the rapid approximation :

Elementary process Explanation Type Point value
Events Database in which the events and their characteristics are stored ILF 7th
Show event list also includes the option of filtering and sorting according to certain criteria EQ 4th
View event details In addition, a seminar status is calculated based on the number of registrations and the remaining time and displayed in the form of a traffic light EO 5
Create event New creation of an event with all features EGG 4th
Change event details not explicitly required, but necessary for the business process EGG 4th
Cancel an event without attendees a relatively simple processing logic EGG 4th
Cancel an event with attendees special processing logic required EGG 4th
Reschedule the event special technical processing logic EGG 4th
Sum of the assessed requirements 36

The last three transactions differ from the "Change event details" transaction because a special processing logic is defined for each of them. The transaction "Change event details" was included because it should be possible to correct incorrect entries when creating a new one. However, an appointment that has already been entered may no longer simply be overwritten.

Effort estimation

The function point method was defined by Allan J. Albrecht as a measure for determining the productivity of IBM's projects. It was not until later that attempts were made to derive effort estimates from the function point value.

It is obvious that the expected effort for a software project cannot be determined solely on the basis of the technical and functional requirements of the application. Instead, a number of other aspects must be taken into account. These include:

  • Nonfunctional requirements
  • Technological framework
  • Technologies, languages ​​and tools available for development
  • Qualification and experience of the project team
  • Framework conditions in the project environment

With the help of effort estimation models such as COCOMO , one tries to derive an expected project effort from the functional size and these additional effort factors. Effort estimates based on the functional size can of course also be carried out using reference data, but these must be sufficiently differentiated and ideally map the framework conditions of the project to be estimated as accurately as possible. The FPA is therefore not a cost estimation method in itself, but can be used as a measure for the technical-functional requirements and in connection with estimation models or reference data for cost estimates at an early stage in the project.

Criticism and discussion

The frequently expressed criticism of the FPA relates primarily to four aspects:

  • effort
  • Traceability or uniqueness
  • Topicality
  • Imbalance

effort

The effort associated with a function point assessment is often criticized.

It can be assumed that the effort required to carry out an assessment depends on various factors. Above all, this should be the type of implementation itself (how detailed is the assessment carried out?), The experience and qualifications of the persons performing it, and the quality and completeness of the documentation of the requirements or application to be assessed. In general, it can now be assumed that the expenditure for the FP assessment is in the range of a few per thousand of the expenditure to be expected for the development project.

In the MIT study carried out in 1990, it was found that a detailed assessment took an average of one hour per 100 fp. This contrasts with a typical development effort of around 400 to 1,600 hours per 100 fp.

Traceability and clarity

It is feared that the rules of the standard still leave scope for the assessment and that the results may therefore vary depending on the persons carrying out the work. There are studies with different results for this.

In the MIT study cited above, a variance of 11% was found in the results obtained by different individuals. A more recent study by Tsoi comes to significantly more pessimistic findings: according to this, the scatter is up to 30%. A major difference between the two studies was the size of the applications assessed (approx. 500 fp for MIT, approx. 40 fp for Tsoi) and the qualifications of the test subjects (the 54 test subjects examined by MIT had an average of 1.5 years experience with the FPA, while 15 of the 21 test persons used by Tsoi were students and none of the test persons had previous knowledge of the FPA).

The problem of the unambiguity of the results seems to be primarily a question of the qualification of the people carrying out the work.

Topicality

A frequently raised objection is that the FPA stems from the "era of mainframes" (around 1970s to 1980s) and the structured analysis that was customary at the time , and therefore has little meaningfulness for software based on more modern analysis and design methods.

On the other hand, function point evaluations are used today to evaluate agile, Scrum- based projects.

This objection is probably based on the confusion between procedures for analyzing requirements on the one hand and procedures for designing software on the other. It is correct that a functional breakdown of the technical-functional requirements is necessary for a function point assessment, but it is not a condition that this also becomes the basis for the technical design of the application.

Imbalance

According to this objection, the FPA “disadvantages” applications with a high proportion of system interfaces and batch processing , since, according to the rules of the FPA, only those functions are taken into account that a user can actually see.

This objection is based on the misunderstanding of the literal understanding of the user perspective (see above). In the FPA, however, it does not matter whether a program function is implemented in the context of dialog processing or batch processing, at a machine-human interface or at a system interface to another application. Incorrect undervaluation of system interfaces and batch processing can often be traced back to their inadequate technical and functional specification.

See also

literature

Web links

Individual evidence

  1. ^ A b Allan J. Albrecht: Measuring Application Development Productivity, Proc. of IBM Application Development Symp. In IBM Application Development Symp. (October 1979), pp. 83-92.
  2. ↑ a b ISO / IEC 14143-1: 2007: Information technology - Software measurement - Functional size measurement - Part 1: Definition of concepts, International Organization for Standardization, Geneva, Switzerland.
  3. ↑ ISO / IEC 20926: 2009: Software and systems engineering - Software measurement - IFPUG functional size measurement method 2009, International Organization for Standardization, Geneva, Switzerland.
  4. ↑ a b IFPUG CPM 4.3.1 - Function Point Counting Practices Manual Version 4.3.1, International Function Point Users Group, Princeton Junction / NJ, USA, 2010. ISBN 978-0-9753783-4-2
  5. ↑ Benjamin Poensgen: Function Point Analysis . A practical guide. 2nd Edition. dpunkt.verlag GmbH, Heidelberg 2012, ISBN 3-89864-762-5 , p. 96 .
  6. ↑ a b Chris F. Kemerer: Reliability of Function Point Measurements, Center for Information Systems Research, MIT, October 1990.
  7. ↑ Tsoi, Ho-Leung: To Evaluate The Function Point Analysis: A Case Study, in International Journal of The Computer, the Internet and Management Vo 13 # 1, pp 31-40, 2005.