#13: Function Points.

This week we are going to calculate function points both for already existing and for the upcoming Use Cases. These FPs will help us to create a diagram for better time asigning. Here is an example of it:

Function Point 0.o

“What are those function points?” would be a reasonable first question. Here is a brief history/definition of FPs. Function Point Analysis is nowadays a widely used estimation technique that once replaced LoC (Lines of Code). Earlier, one tried to measure the size of a software application by counting the physical number of lines of code in the software program. In 1979 Allan J. Albrecht laid the foundations for the subject of ‘Functional Size Measurement (FSM)’ that fundamentally changed the concept of software sizing. Function point analysis is a method that helps breaking software application into smaller components. Thus people can better understand and analyze it. Function point is thereby a unit of measure of size of a software application. Function point measures software, by quantifying its functionality provided to the user, based primarily on the logical design (Hello Use Cases 😉). The definition of this method is now managed by the International Function Point Users Group (IFPUG) [1]. They also give us the opportunity to calculate the time, that should be spent on each Use Case. Therefore we can deliberately assign time to our new upcoming Use Cases.

To calculate FPs we will use a tool presented by Tiny Tools. In order to get more accurate calculations one has to fill the following table:

Once the table is filled out the next step comes. To unterstand it better we will provide you a brief introduction about the ILF, EIF, EI, EO and EQ (cf. Table 1).

ILF (Internal Logical Files)	EIF (External Interface Files)	EI (External Inputs)	EO (External Outputs)	EQ (External Inquiry)
is a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs.	is a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application.	is is an elementary process in which data crosses the boundary from outside to inside.  This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files.  The data can be either control information or business information.  If the data is control information it does not have to update an internal logical file.  The graphic represents a simple EI that updates 2 ILF’s (FTR’s).	is an elementary process in which derived data passes across the boundary from inside to outside.   Additionally, an EO may update an ILF.  The data creates reports or output files sent to other applications.  These reports and files are created from one or more internal logical files and external interface file.  The following graphic represents on EO with 2 FTR’s there is derived information (green) that has been derived from the ILF’s.	is an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files.  The input process does not update any Internal Logical Files, and the output side does not contain derived data. The graphic below represents an EQ with two ILF’s and no derived data.

Now one can figure out how many FTRs, RETs and DETs our Use Cases are touching. There are some points, like External Input or External Output, on which we had to examine our Use Cases. The following diagrams will explain you the meaning of these abbreviation.

Based on the new knowledge we now can create following table for our Use Cases.

This table helps us to create this diagram.