One of the stated purposes of function point analysis is to provide a size measure that can be used as an input to help estimate the cost, effort, schedule, and staff needed to develop a software project. The standards for how this is done are maintained by the International Function Point Users Group (IFPUG). In a nutshell, function point analysis identifies, from a user perspective, logical groups of data that a project or application maintains or accesses and logical processes that update, query, transmit, or report on that data. The counting rules are extensive, very specific, and assign function point values to these based on the number of data stores a process accesses and the data elements it touches. To help assure that function point counting is conducted in a standardized manner, IFPUG certifies counters who have demonstrated mastery of the counting rules through passing an exam. These counters have the title of Certified Function Point Specialists (CFPS).
There is a problem with using traditional function point analysis in the conceptual phase of a software project when the budget, schedule, and staffing are being planned: the information required to count function points according to the rules is normally unavailable and, in many cases, does not yet exist. To overcome this obstacle, function point counters have devised a number of quick counting methods to estimate project function point counts. Most of these are rules of thumb whose implementation varies from one counter to another.
SiFP was developed by Roberto Meli and associates in Italy. In 2019, IFPUG acquired the rights to the methodology and plans to integrate it into its portfolio in 2021. Follow this link for more details.
So how does SiFP differ from regular function point analysis, and why is it simpler? Three differentiators stand out:
-
Traditional function point analysis identifies three distinct input/output (I/O) processes: external inputs (EI), external outputs (EO), and external inquiries (EQ). SiFP identifies only one, which is called an Unspecified Generic Elementary Process (UGEP). All IFPUG I/O processes would be an SiFP process, which is to say an UGEP, and any UGEP would correspond to one of the three IFPUG transactional processes. The rules for identifying a process to be counted are virtually identical in both methodologies.
-
IFPUG function point analysis identifies two data functions: Internal Logical Files (ILF), which are logical groups of data that are updated by the project or application being counted, and External Interface Files (EIF), which are referenced, but not updated by the project or application being counted. SiFP counts one data function: an Unspecified Generic Data Group (UGDG) that includes both of the IFPUG data types. As was the case with identifying processes, the rules for identifying a data group to count are the same in both methodologies.
-
IFPUG assigns function points to a data function based on what type of function it is and its complexity, which is based on how many data elements (logical fields) it has and how many subgroups it contains. The count can vary from 5 to 15. SiFP counts 7 function points for each data group. Likewise, IFPUG counts function points for transactional processes based on the type of process it is and its complexity, which is based on how many logical data elements the process touches and how many logical data stores are involved in the process. The count can vary from 3 to 7. SiFP counts 4.7 function points for each process.
So how is SiFP simpler? Two things stand out. First, at project start-up, a lot of things are in flux. There is probably some form of a data model and a requirements document from which logical processes can be identified. What is missing are all of the details that go into determining the complexity of an IFPUG data or transactional function. So, SiFP can determine a project function point count simply by identifying a project’s data and transactional functions. Second, determining the complexity of IFPUG data or transactional functions and assigning function points to them based on the number of fields, subgroups, and logical files touched can be tedious and time consuming. SiFP simplifies counting by removing the complexity determination step.
So how consistent are projects that have been counted using both methodologies with each other? Pretty good, it turns out. The SiFP organization counted (using SiFP function points) 766 projects from the International Software Benchmarking Standards (ISBSG) database and compared them with their IFPUG function point counts (page 25 in this document). The Spearman's test and Kendall's were used to verify the correlation between UFP and SiFP. The Spearman's rank correlation test gave a value of rho = 0.988 ( p - value < 10-15). The Kendall's rank correlation test gave a value of tau = 0.907 ( p - value < 10-15). It can be concluded, therefore, that UFP and SiFP are very strongly correlated. Which is good news since SiFP provides another tool for determining project size early in the development lifecycle when budget, staffing, and schedule are established and little detailed information is available.
Learn more about QSM’s function point counting and scope sizing services here.