2.1 SO, WHAT IS FUNCTION POINT ANALYSIS?

 < Day Day Up > 



2.1 SO, WHAT IS FUNCTION POINT ANALYSIS?

Function Point Analysis is a technique that can be applied to system specifications or existing applications to derive a measure of the size of the information processing requirements of that system/application. A variation of the technique can be used to size changes to the information processing requirements of a system

The concept of FPA was first presented to a joint SHARE/GUIDE/IBM conference in 1979 by the developer of the technique, Allan Albrecht, (1) . Albrecht had required a long term productivity measure for systems he was managing. The problem he faced was that his environment included different language types, and so he needed something that was technology independent, or at least independent of the programming language used. That was the start

Since then Function Point Analysis has moved from being a locally used metric within one organization (in fact in just one part of an organization), to the situation we see today which is that FPA is widely used in very many organizations in many parts of the world. Supporting this are a number of user groups, many consultancy organizations and many commercially available training courses. At times it seems as though there is a whole industry involved in promoting and supporting the use of FPA.

Given that Function Point Analysis has been so successful in terms of widespread adoption, at least within the data processing environment, it is sometimes surprising to realize that FPA provides a very basic item of data. FPA is simply a technique that can be used to derive a measure of the size of a software system.

The wide use of Function Point Analysis and the fact that it has been in the public domain has led to some problems. For example, there are many variants of FPA. Some of these have been developed to address perceived limitations in the original technique while others have been developed to extend the application domain of FPA beyond the data processing environment to the, real-time environment. For example, Charles Symons has developed a major variant of FPA, often called Mark II Function Point Analysis which has been adopted by the British civil service as a standard, (Symons, 1991). Being in the public domain has also meant that there has been numerous critical reviews of the technique, many of which have led the way to improvements in FPA or in its application.

Despite the wealth of information available on the subject, or perhaps because of it, many misconceptions exist about FPA. I would like to establish three basic ideas that should be appreciated by anyone before they start to use FPA. Before doing that I must stress that this chapter cannot fully explain or discuss Function Point Analysis. To do that would take a book of its own, and they do exist, so please view the rest of this chapter simply as an introduction to the technique and I would suggest that you contact either your national Sotware Metrics or Function Point User Group for further information. Having said that, we can now consider three of what I consider to be key points regarding FPA.

  • Function Point Analysis is a technique, hence the use of the word 'analysis' in the expression "Function Point Analysis." It is not a simple count of specific characteristics nor is it a totally de-skilled activity. Organizations that are seen as the most effective users of FPA often bring together an FPA expert and a system expert when they wish to size an application. To use FPA effectively requires training, may require support and will involve an investment of effort.

  • FPA produces a unit-less answer or score. This means that there is no such thing as a "Function Point." Appreciating this point can save much confusion later. If this appears odd then think of an FPA number as an index in the same form as the Dow Jones or Stock Market FTSE index. These are also unit-less measures and once you understand how the index behaves you can make use of the information it provides.

  • The number produced by FPA is a measure of system size, actually a measure of the information processing requirements for the system, or the change to those information processing requirements. Of itself this has little value but it is a basic data element. I must stress that FPA is not an estimating technique nor is it a device for productivity measurement. What FPA does is enable such activity by providing the basic data, size. Once you have a size value this can feed into the estimation process for effort or cost. Size values are also used in basic productivity measures and, as you will see later, in many other measures that provide meaningful information.

Having set the scene regarding some of the basics of Function Point Analysis we can consider the technique itself. This will involve a fair degree of technical detail and if you wish to avoid the next section then simply go on to the summary at the end of this chapter.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net