Albrecht function point analysis

This is a top-down method that was devised by Allan Albrecht when he worked for IBM. Albrecht was investigating programming productivity and needed some way to quantify the functional size of programs independently of the programming languages in which they had been coded. He developed the idea of function points (l"Ps).

The basis of function point analysis is that computer-based information systems comprise five major components, or external user types in Albrecht *s terminology, that are of benefit to the users:

• External input types are input transactions that update internal computer files.

• External output types are transactions where data is output to the user. Typically these would be printed reports, since screen displays would come under external inquiry- types (see below).

• Logical internal file types are the standing files used by the system. The term •file' does not sit easily with modern information systems. It refers to a group of data that is usually accessed together. It might be made up of one or more record types. For example, a purchase order file might be made up of a record type PuRCHASEORDER plus a second that is repeated for each item ordered on the purchase order - PurchaseOrderItem.

• External interface file types allow for output and input that might pass to and from other computer applications. Examples of this would be the transmission of accounting data from an order processing system to the main ledger system or the production of a file of direct debit details on a magnetic or electronic medium to be passed to the Bankers Automated Clearing System (BACS). Files shared among applications would also be counted here.

• Externul inquiry types - note the US spelling of inquiry - are transactions initiated by the user that provide information but do not update the internal files. The user inputs some information that directs the system to the details required.

The analyst has to identify each instance of each external user type in the projected system. Ivach component is then classified as having either high, average or low complexity. The counts of each external user type in each complexity band are multiplied by specified weights (see Table 5.2) to get FP scores, which are summed to obtain an overall FP count, w hich indicates the information processing size.

See A. J. Albrecht and J. E. Gaffney Jr.. Software Function. Source Lines of Code, and Development Effort Prediction: A Software Science Validation" in M. Shopperd (ed.) Sottware Engineering Metrics Volume t. McGraw-Hill. 1993.

Albrocht also specifies that outgoing external interlace files should be double counted as logical internal file types as well.

The International FP User Group (IFPUG) have developed and published extensive rules governing FP counting. Hence Albrecht FPs are now often referred to as IFPUG FPs.

Table 5.2 Albrecht complexity multipliers

External user type


Multiplier Average


External input type




External output type




Logical internal file type




External interface file type




External inquiry type




Exercise 5.5 The task for which Brigette has been made responsible in Exercise 5.2 needs a program that will extract yearly salaries from the payroll file, and the details of courses and hours taught on each course by each member of staff from two files maintained by the time-tabling system. The program will calculate the staff costs for each course and put the results into a file that will then be read by the main accounting system. The program will also produce a report showing for each course the hours taught by each member of stall" and the cost of those hours.

Using the method described above, calculate the Albrecht function points for this subsystem, assuming that the report is of high complexity, but that all the other elements are of average complexity.

One problem with I'Ps as originally defined by Albrecht was that the question of whether the external user type was of high, low or average complexity was rather subjective. The International IP User (¡roup (IFPUG) have now promulgated rules on how this is to be judged. For example, in the case of logical internal files and external interface files, the boundaries shown in Table 5.3 aa* used to decide the complexity level.

Table 5.3 IFPUG file type complexity

Number of record types

Number of data types


20 to 50


2 to 5 >5

low low average

low average high

average high high

Example 5.2 A logical internal file might contain data about purchase orders. These purchase orders might be organized into two separate record types: the main PurchaseOrder details, namely purchase order number, supplier reference and purchase order date and then details for each PuRCHASEORDERlTEM specified in the order, namely the product code, the unit price and number ordered. The number of record types for that file would therefore be 2 and the number of data types would be 6. According to Table 5.3, this file type would be rated as 'low*. This would mean that according to Table 5.2. the I I' count would be seven for this file.

Tables 5.4 and 5.5 are used to allocate scores to external inputs and external outputs. Each external inquiry has to be counted both as if it were an external input and an external output and whichever score is higher is used.

Table 5.4 IFPUG External input complexity

Number of file types accessed Number of data types accessed


5 to 15


0 or 1 low 2 low > 2 average

low average high

average high high

fable 5.5 IEPUG External output complexity

Number offile types Number of data types


6 to 19

2 or 3 low > 3 average

low average high

average high high

Further details on TCA can be found in the Albrecht and Gaffney paper.

Some of these conversion factors do not seem to be very convincing (e.g. 6 SLOC per function point for spreadsheets).

l-unction point analysis now goes on to take into account the fact that the effort required to implement a computer-based information system will relate not just to the number and complexity of the features to be provided but also to the environment in which the system is to operate.

Fourteen factors have been identified that can influence the degree of difficulty associated with implementing a system. The list that Albrecht produced related particularly to the concerns of information system developers in the late 1970s and early 1980s. Some technology that was then new and relatively threatening is now well established.

The technical complexity adjustment (TCA) calculation has had lots of problems. Some have even found that it produces less accurate estimates than using the unadjusted function point count. Because of these difficulties, we are going to omit further discussion of the TCA.

Tables have been calculated to convert the I Ps to lines of code for various languages. For example, it is suggested that 91 lines of Cobol are needed on average to implement an FP, while for C the figure is 128 and for QuickBasic is 64.

Exercise 5.6 In the ease of the subsystem described in Exercise 5.5 for which Brigette is responsible at Brightmouth College, how many lines of Cobol code should be needed to implement this subsystem, according to the standard conversion?

Was this article helpful?

+1 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment