2.2 USING FUNCTION POINT ANALYSIS

< Day Day Up >

At this point I would like to give you a feel for what is involved in an FPA exercise. The variant used to describe an FPA exercise is the Mark II form of FPA, the design authority for which is the United Kingdom Software Metrics Association (UKSMA, www.uksma.co.uk). There is no claim in this book that the Mark II variant is "better" than any other form of the technique. It is, however my preferred approach and I claim "authors privilege."

2.2.1 Performing an FPA Exercise

People work in different ways. I would never try to force any individual to follow the description below sequentially. The important thing is to get the information you need and use it accordingly. We will approach this as if we were sizing the requirements for a new system or an existing application but will allude to other uses of the technique. Starting at the beginning, it would be nice to know whet we are sizing. So...

2.2.2 Defining the System Boundary

The System Boundary is the conceptual interface between the application or system being sized and the world in which it exists.

Information moves into the application from users and from other applications across the System Boundary. Likewise, the application will produce information which is passed to users and to other applications. This information will move across the System Boundary. The processing that the application carries out is done within the System Boundary.

Defining the system boundary is the first step in FPA. The boundary is used to limit the scope of the sizing exercise and to help identify the other external parameters.

There are three views of the system boundary depending upon the type of FPA exercise that is being carried out. First we have the application or product boundary. This encompasses a full application and this type of count is often done at the end of a development project when handing over to the maintenance group or when an organization first starts to use FPA. This type of FPA count can also be derived from a live system.

Second is the initial development project boundary. This is a very similar kind of count to the previous one, the difference being that the count derives from requirements for which no system exists.

Finally we have the enhancement project boundary. This situation arises where a system exists and further releases are made of that system. The system boundary envisaged and used when applying FPA to an enhancement project may be partially that of the whole application The enhancement project FPA approach differs from the previous situation in that added, changed and deleted functionality is considered rather than the totality of the system. Do not fall into the trap of counting the total system before enhancement, then after and subtracting one total from the other. This is not a valid approach as you can see if you consider a project that adds a certain amount of functionality and deletes the same amount in another part of the system. Subtracting the size of the system before the project from the size after the project will give you a project size of zero!

This discussion of the system boundary may appear complicated but just remember that it is that conceptual line between the system and its world and most of the other stuff falls into place.

There is a subjective element in determining the system boundary and, obviously, changing the system boundary will change the FP score. While this may seem an unscientific approach, in practice the guideline that the analyst should consider is to look at what is managed as a discrete whole. This enables most system boundaries to be defined easily. From this point, FPA is a more mechanistic process but still demands skill unless you are operating a fully electronic design support system. Let's face it, most organizations are not!

Function Point Analysis is not difficult, in many senses, but can be vexing when there is little or no documentation — guess how often that happens!

Having defined the system boundary, break the system down into sub-systems and then into business operations. Keep going until you get to the lowest level business operation that, when completed either because the operation has been achieved or because the operation has bombed out because of an error condition, leaves the system in a consistent and predictable state. This lowest level of business operation is called a Logical Transaction.

Now, for each Logical Transactions you need to identify the number of unique data elements, such as a record key, entering the Logical Transaction. Next identity the unique data elements leaving the Logical Transaction as output. The final element is the number of Data Entities contained in the Logical Data Model of stored data for the system that are accessed during the course of the Logical Transaction. Note that this is the number of entities accessed, not the number of times that they are accessed.

So, for each Logical Transaction, you now have three simple counts:

Input Data Element Types;
Output Data Element Types; and,
Data Entities Referenced.

Now these are weighted, using industry standard weights that look more precise than they probably are - but they work.

The weights are:

For Input Data Element Types	0.58;
Output Data Element Types	0.26; and,
Data Entities Referenced	1.66.

Sum the weighted counts and then sum the counts for all of the Logical Transactions. Eh voila, we have our system size! I kid you not, it is that simple, at a conceptual level but, obviously there are details such as how dates are dealt with, what to do with post or zip codes, how to handle arrays, etc. To give you an idea, a training course typically takes two days to complete.

click to expand
Figure 2.1: FPA Example

This diagram shows a simple example of Mark II FPA applied to a single Logical Transaction. In this case, a key (1 Input Data Element) is entered into the application which accesses two data entities to retrieve the information to format and present a simple report. In this case, the report is simply a list of the hotels and the number of rooms in each for a particular resort. You score 1 Output Data Element for the resort name and one each for the list of hotel names and the corresponding list of room numbers (note that you do not count the number of entries in the list because you will not know this). Apply the appropriate weights to the basic counts and add the results up to get the overall score, or Function Point Index (FPI), for that Logical Transaction. The sum of the sores for all the Logical Transactions would give you the overall FPI for the full system.

This book is not an FPA training course but this hopefully gives you a feel for how the technique is applied. The principles behind the technique are both elegant and simple, borne of a managers need to control and report his work and that of his teams. It works; correlations of 0.7 and higher between size in terms of Function Points and development and enhancement effort are common in homogenous environments.

Remember also that you may come across a situation that is specific to your organization and that is not covered by advice in any set of counting guidelines. This simply reflects the fact that, as Albrecht has said at numerous venues, FPA is an evolutionary technique. In such cases it is up to you as the practitioner to make a decision or formulate a rule based on your experience and the experience of others with whom you have contact. The most important consideration is to document that rule and to apply it consistently. For the benefit of other practitioners it would be of great assistance if you were to advise the relevant governing bodies so that they can ensure a consistent and standardized application of FPA across the industry:

The International Function Point User Group (IFPUG; www.ifpug.org);
The United Kingdom Software Metrics Association (UKSMA, www.uksma.co.uk).

< Day Day Up >