Function point analysis

The function point method (also analysis or method, short FPA) is used to assess the technical and functional scope of an Information Technology Systems, hereinafter referred to as an application. The result of a function point assessment is referred to as "functional size " and the unit " Function Points ", short fp specified. The FPA is the most common expression of various summarized under the term Functional Size Measurement, evaluation procedures.

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

The Functional size is determined, in which the functional requirements of an application into small, meaningful for the user activities that elementary processes are decomposed. In the same elementary processes are evaluated only once. Each elementary process is assigned to a defined point value. The sum of the point values ​​of all elementary processes yields the functional size.

Strictly speaking, is not to be regarded as a measure of the FPA or its result, the names of the FPA as a software metric or in English as " Functional Size Measurement " are so far not quite accurate. Rightly, we should speak of an evaluation process.

  • 2.1 user perspective
  • 2.2 Identification of transactions
  • 2.3 Functional hierarchy tree
  • 2.4 Identification of data resources
  • 2.5 Determination of the functional size of an application
  • 2.6 Functional size for software modifications and enhancements
  • 2.7 Rapid approximation
  • 3.1 Technically -functional requirements
  • 3.2 review
  • 5.1 effort
  • 5.2 Traceability and uniqueness
  • 5.3 Actuality
  • 5.4 Ungleichgewichtigkeit

Standards

Allan J. Albrecht (1927-2010) developed the Function Point Analysis in the late 1970s for the company IBM. The process has evolved over time in different variants, which are summarized today as the Functional Size Measurement. This is defined by the ISO standard ISO / IEC 14143.

Current standard

As a rule is called function point analysis, short FPA, refers to the variant of the International Function Point Users Group ( IFPUG ), which is standardized as ISO standard ISO / IEC 20926. The current ISO standard, meets the standard of IFPUG CPM in version 4.3.1, with CPM for "Counting Practices Manual" is.

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

Significant changes

With the inclusion of the IFPUG standards in the ISO catalog for the first time in 2003, there has been a significant change from previous versions: a so-called value factor (in the standard Value Adjustment Factor, short VAF, the Germans sometimes referred to as weighting factor ) no longer applicable as a rule, the distinction between " unadjusted " and " adjusted function points" is omitted it. This was followed by the IFPUG CPM 4.3.1 in its standard.

The value factor in addition to the technical and functional requirements and non-functional requirements should be considered in the function point value. This is according to the ISO standard ISO / IEC 14143, however, no longer permitted. On the application of the value factor was also formerly been superfluous if the Function Points were used as a basis for cost estimation, and these non-functional requirements are Also taken into account already in the effort estimation model. This is the case with the cost estimation model COCOMO.

Method

User's perspective

To determine the functional size the user point of view ( "User View" ) is relevant. The concept of the user ( user) in the FPA corresponds conceptually to the actor in the Unified Modeling Language. A user can be both a natural person, any other software as well, for example, be a machine. The concept of the user's perspective, therefore, not to take literally. The user perspective is focused on the fact that in evaluating only those features of the software are to be considered, which serve to support the relevant business processes.

Identification of transactions

An elementary process is defined as the most appropriate for the user, the smallest activity that leaves the system in a consistent state after execution. Elementary processes are distinguished according to three types of transactions ( " Transactional Functions" ).

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

The crucial factor is the main purpose of the elementary process. An entry has as its main objective the maintenance of an internal data holdings and processing of data that originates from outside the application. An output or query have the primary purpose of the presentation of information to the application boundary. For an output is additionally required that their processing logic mathematical calculations or formulas, the creation of derived data, the maintenance of an internal database or a change in the system behavior involves.

From the definition of the transactions results in that only elementary processes are evaluated in connection with a data flow on the application line.

In the same transactions are to be counted only once. Two transactions are deemed to be equal if they use the same data and the same processing logic include, with smaller variations are not excluded. Variations no longer apply in any case be considered " small " in this sense if the two transactions are two appreciably different technical and functional requirements as a basis.

Functional hierarchy tree

Largely the process of identification of the transactions follows the well-known from the structured analysis approach. Therefore, it is natural to represent the result in the form of a functional hierarchy tree. The notation of this functional hierarchy tree is not part of the standard, however, its use has largely naturalized in practice.

Identification of data resources

In addition to the transactions, the FPA also evaluated the managed by the software databases ( "data functions" ). A database is defined as a set of recognizable professionally and logically related data. Again, the evaluation should be done from the user perspective. Data stocks continue to be distinguished in

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

The designations are saying: Internal data sets are those that are within the rated application maintained ( write access). External databases are only referenced by the rated application or read, but maintained in another application.

Determining the functional size for an application

For the assignment of the point value to transactions and data sets there are detailed rules in the standard, the so-called " complexity rules." The point value for a transaction resulting from the number of fields used and the number of data sets used in the transaction. For the data sets the point value based on the number of fields contained and the number of field groups is determined. As a field group is a lot of technically related data fields understood as the set of fields address, title, first name and last name, together representing the name of a natural person.

The following table shows the possible for the individual types of transactions and database types minimum, average and maximum pixel values ​​:

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

Functional size for software modifications and enhancements

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

The functional size of a redevelopment project is set equal to 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 remote transactions and data resources. Each transaction and each dataset is at most once counted as changed for a project, regardless of the actual volume of concrete changes. The assignment of point values ​​to the respective data sets, and transactions performed according to the rules described above for determining the functional size of an application.

Both are for Neuentwicklungs as well as for expansion projects, if any, shall also assess the functions that serve to convert the data from earlier versions of the application.

Although these rules seem pretty simple at first glance, they have proven themselves in practice and provide a good basis for the evaluation of extension projects that should be today by far the most common type of project in the industrial practice of software development.

Rapid approximation

In practice, the complexity rules play a minor role, as widespread an approximation method, under the name " Rapid " is known, is applied. Thereafter assigned to 5 fp basically a command 4 fp, fp a issue 5, a query, 4 fp, an internal database, 7 fp and an external data set. For larger applications and projects ( about > 100 FP) it is assumed that the resulting error due to this approximation to a detailed review complexity is negligible.

Example

This is illustrated by a small example based on an application that will support the planning, organizing and conducting seminars a seminar organizer. To keep the example manageable, set the shown in the following technical and functional requirements only a part of the total requirements dar. It should be noted that there are more detailed and complete examples in Part 4 of the CPM, the particular and the concrete procedure for explain the identification of transactions and data resources.

Technically -functional requirements

The customer has, inter alia, the following specific requirements formulated:

The application is to support the planning and management of seminars (in the following events). This it must be possible to create an event with their relevant characteristics. Missing or incorrect entries will be corrected later. Of course, an overview of the events as well as a detailed view of individual events is required. There are the following business cases are supported:

  • Cancellation of an event for which there is still no confirmed registrations
  • Cancellation of an event for which there is already confirmed entries
  • Postponement of an event

Assessment

For this application, the following transactions and data resources are identified, the point value according to the Rapid approximation is assigned:

The last three transactions differ from the transaction " event details change," because for them each a special processing logic is defined. The transaction " change event details " was included because it should be possible to correct erroneous entries when creating new. But it must approximately one already entered date not be simply overwritten.

Cost Estimation

The function point method is defined by Allan J. Albrecht as a measure for determining the IBM productivity projects. Only later they tried to derive cost estimates from the function point value.

It is obvious that the expected cost of a software project can not alone determine the application because of the technical and functional requirements. To this end, a number of issues rather be considered. These include:

  • Non-functional requirements
  • Technological conditions
  • Available for the development of technologies, languages ​​and tools
  • Qualification and experience of the project team
  • Conditions in the project environment

With the help of cost estimation models such as COCOMO one tries to derive from the functional size and this additional effort factors an expected project cost. Cost estimates based on the functional size are of course the basis of reference data feasible, but it must be sufficiently differentiated and ideally reflect the conditions of the project to be estimated as closely as possible. The FPA is therefore no effort estimation methodology in itself, but can be used as a measure of the technical and functional requirements and in conjunction with estimation models or reference data for cost estimates already at early project times.

Criticism and discussion

The frequently voiced criticism of the FPA refers mainly on four aspects:

  • Expenditure
  • Traceability and uniqueness
  • Relevance
  • Ungleichgewichtigkeit

Expenditure

Criticism is often the overhead associated with a function point assessment.

It is likely that the cost of implementing an evaluation of various factors. This should especially the way the implementation itself ( the assessment is carried out as detailed? ) Be the experience and qualifications of persons conducting and the quality and completeness of the documentation of the imported requirements or application. In general, one can assume that the cost of the FP- assessment in the field is less per thousand of the expected cost for the development project today.

In the 1990 study conducted at MIT, expenses of an average of one hour per 100 fp was found for a detailed review. This compares to a typical development effort of about 400 to 1600 hours per 100 fp.

Comprehensibility and clarity

It is feared that the rules of the standards still leave scope for valuation and can scatter the results therefore depends on the persons conducting. To this end, there are studies with different results.

In the above-cited study from MIT a spread of 11% was found in the determined by different individuals results. A recent study of Tsoi is clearly more pessimistic findings: after the scattering is up to 30 %. A major difference between the two studies was the size of the evaluated applications (about 500 fp at MIT, about 40 fp at Tsoi ) and in the qualification of the test subjects ( the studied at MIT 54 test subjects had an average of 1.5 years of experience with the FPA, while 15 of the documents used by Tsoi 21 subjects were students and none of the subjects had prior knowledge of the FPA. )

The problem of uniqueness of the results thus seem to be primarily a question of the qualification of the persons conducting.

Relevance

A frequently made argument is that the FPA ( ie about 1970 to the 1980s ) and the then usual structured analysis come from the " time of the mainframe ", and so on based on modern analysis and design methods software possess little significance.

This contrasts with that Function Point Reviews agile today also about the evaluation, based on Scrum projects are used.

Probably this objection is the confusion of methods for analysis of requirements on the one hand and methods for the design of software on the other hand is based. It is true that a functional decomposition of the technical and functional requirements necessary for a function point assessment, however, it is not a condition that this is also the basis for the technical design of the application.

Ungleichgewichtigkeit

According to this objection " disadvantaged" the FPA applications with a high percentage of system interfaces and batch processing, because according to the rules of the FPA only those functions are taken into account, which could also see a user.

This objection is the misunderstanding of the literal understanding of the user perspective (see above) is based. However, it plays in the FPA not matter if a program function is implemented on a machine -human interface or a system interface to another application in the context of dialogue processing or batch processing. False positive feedback of system interfaces and batch processing are often due to their lack of technical and functional specification.

Actor (UML) Scrum (software development) Carl Hanser Verlag
355872
de