One of the most important quotes in business management states, “If you can’t measure it, you can’t improve it.”. When you think about this quote, it should immediately become apparent how true it is. It’s like trying to improve your running speed, but never keeping score, so you don’t know if you’re actually getting better or not. The importance of measuring the size of software projects (software sizing) before you start developing is much like looking at a map before starting a road trip or reading the blueprints before building a house.

One can even argue that the ability to measure software size early in the project life cycle (i.e. estimating the size before development) can be the most important resource for software development companies in terms of management and control of project resources.

Software functional size

The primary measurement of software is size, more specifically, functional size. Software size is principally measured in function points. It can also be measured in source lines of code (SLOC) which is functional code excluding comments.

Whilst measuring SLOC is interesting, it is more of an indication of effort than of functionality. Two developers could develop a functionality using different techniques, one might only need to write a few lines of code, and the other might need to write many more lines to achieve the same functionality. The most reliable method for measuring software size is technique-independent and is based on the user’s point of view, in “function points”.

What are Function Points?

The concept of Function Point was first introduced by Alan Albrecht of IBM in 1979. A function point is a “unit of measurement” used to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost (in euros or hours) of a single unit is called productivity and is calculated based on past projects.

The most commonly used functional size measurement (FSM) methods are IFPUG (International Function Point Users’ Group) and COSMIC (Common Software Measurement International Consortium) Function points. They are ISO standards.

The IFPUG method

The IFPUG measurement process includes 5 main steps:

• The first step is to identify the counting scope. The purpose of the count determines the counting scope. This step basically involves determining the type of function point count – development, enhancement, or application.
• The second step is to define the application boundary. Basically, a boundary indicates the border between the project or application being counted, and the external applications or users. It is very important to draw the application boundary from the user’s point of view and not from the point of view of the technical implementation.
• The figure bellow shows the functionality as viewed from the user’s perspective and according to IFPUG.
• The third step is to identify and rate the data functions. The data functions include Internal Logic Files (ILF) and External Interface Files (EIF). Data functionality satisfies the functional user requirements to store and/or reference data.
• ILF: Logical group of data maintained by the application under study (e.g., Employee file)
• EIF: Logical group of data referenced but not maintained by the application under study (e.g., Global state table)

• The fourth step is to identify and rate the transaction functions. The transaction functions include External Inputs (EIs), External Queries (EQs), and External Outputs (EOs). Transaction functionality satisfies the functional user requirements that process data.
  • EI: Maintains an ILF or passes control data into the application under study
  • EO: Formatted data sent out of application with added value (e.g., calculated totals)
  • EQ: Formatted data sent out of application without added value
• The last step is to calculate functional size. After identifying and rating the data functions and transaction functions, the purpose and counting scope shall be considered when selecting and using the appropriate formula to calculate the functional size. The size of a software project is different from the size of the resulting software product. The resulting measure is called Unadjusted Function Point (UFP). This count specifies the size of the application or the project, based on the functionality provided from the user perspective.

The COSMIC Function Points method

The COSMIC method may be used for software sizing in cases such as business applications; real-time software; infrastructure software such as in operating systems; and hybrids of these. The common characteristic of all these types of software is that they are dominated by functions that input data, store and retrieve data, and output data.

Similarly to IFPUG, boundaries should be drawn between the application under study and functional users.

There are four types of data movement sub-processes (see figure bellow) that should be identified from specifications:

• An “Entry” moves a data group from a functional user into the software,
• An “Exit” moves a data group out of the software,
• A “Read” move a data group from persistent storage,
• A “Write” move a data group to persistent storage.

The size of a piece of software is then defined as the total number of data movements (Entries, Exits, Reads and Writes) summed over all functional processes of the piece of software. Each data movement is counted as one ‘COSMIC Function Point’ (‘CFP’).

The figure bellow shows the four types of data movements.

Conclusion

Both IFPUG and COSMIC are standard methods to measure the size of a software application. One may wonder which method is more suitable for his/her projects.

Although similarities and differences between the two methods were studied and discussed by multiple studies, the choice between these methods is not as easy as it could appear. Some comparison studies conclude that IFPUG is more suitable for MIS applications and COSMIC is more suitable for real time applications but both methodologies are competing against one another for their place in the software industry as the primary method for sizing software applications.

Another question that is often raised concerns the convertibility between the IFPUG and COSMIC Function Points. When, for example, a part of a business application has been measured in IFPUG FP and other parts in COSMIC function points, which is the real measure of the whole application?

Some researchers namely Desharnais suggest a conversion factor from COSMIC to IFPUG. Multiple studies conclude that the correlation between the two methods depends on the context.