A Quick Primer on Counting Function Points


Garmus, David, and David Herron. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison Wesley, 2001.


This appendix is a quick primer. It does not attempt to tell you everything there is to know about counting the size of a piece of work using function points. However, it is sufficient to get started, and could possibly make you better at estimating than many organizations are at the moment.

Function points are a measure of functionality. They are considered useful because of the following simple premises:

  • The more functionality contained within the work, the more effort needed to study it and gather its requirements.

  • The amount of functionality within the work is a direct result of the data it processes.

  • The more data there is, and the more complex it is, the more functionality is needed to process it.

  • Because data is more visible and measurable, it makes sense to measure the data and extrapolate the functionality from it.

As the development proceeds, your analysis models become more accurate, and thus your measuring can become more accurate along with them. Because you are still at the requirements stage, however, these guidelines are appropriate:

  • Count function points quickly. Given the early stage of the project, good measurements now are more useful than perfect measurements later.

  • Count the function points for the work in its entirety or treat each ofthe business use cases as a unit of work and count it separately.

Scope of the Work

You start counting function points by using what you already have. During the blastoff you built a context model of the work area. We discussed this model in Chapter 3, but for your convenience we reproduce it here as Figure C.1.

Figure C.1.

The context model is one of the inputs to function point counting. It showsthe flows of data entering and leaving the work area. Each flow triggers some functionality or is the product of some functionality. The amount of functionality is in proportion to the amount of data carried by the flow.


The context diagram shows the flows of data entering and leaving the work. Each flow that enters the work must be processed. The amount of functionality needed to process it depends on the amount of data carried by each occurrence of the flow. Thus one of the measurements used by function point counting is the number of data elementsyou can also call these "attributes"contained by the flow. Counting these elements is easier if you have already written a data dictionary entry for each flow. If not, the process is simple enough to do without this definition.

Data Stored by the Work

Another determinant of the needed functionality is the data to be storedby the work. Each database, file, or other storage medium for data requiressome functionality to maintain it. Again, the amount of functionality depends on the amount of data (expressed as the number of data elements) and thecomplexity of the data (the number of records or tables the data is organized into). Quantifying these measures is easy enough if you have a class model of the data. We discussed this model in Chapter 14 when we were reviewing the specification; we reproduce it here as Figure C.2 for your convenience.

Figure C.2.

The stored data model for the work area. The model includes a number of classes; the workstores data about the real-world artifacts represented by each class. Each class has a number of attributes. The function point counting procedure uses both of these numbers.


Each of the classes shown in the data model contains attributesthat is, the elementary items of data that together describe the class. There is a simple way to distinguish between attributes and classes: Attributes have alphanumeric values, and classes do not.

If you look at both the context model in Figure C.1 and the class model in Figure C.2, you can imagine how the work uses the incoming data to process and maintain the stored data. These two models should be seen as two views of the same piece of work.

If you do not have a data model, we suggested alternative ways of determining and listing the classes in Chapter 14. At this stage, considering that speed is more important than hyperaccuracy, a list of classes will suffice.

Business Use Cases

With business use cases, you can again make use of what you already haveto count the function points. In Chapter 4 Event-Driven Use Cases, we examined the idea of partitioning the work using business events. A business event is either a happening outside the work or a happening caused by the passage of time that triggers a response (we call it a business use case) from the work. Business use cases are not only a convenient way to gather requirements, but also a convenient way to count function points. Let's assume you have partitioned the work into business use cases, and show how they are measured.

Unfortunately, the UML use case diagram is of no help to us here, as it does not contain any information about the inputs, outputs, or stored data. Instead, we will use a data flow model of a business use case to illustratehow function points are counted. We hasten to add it is not necessary to draw these diagrams before counting function points; we use them in this appendix purely for illustrative purposes.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

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