A Primer to Function Point Analysis for the Software Project Manager
by Ron McFarland, Ph.D.
As a Software Development Project Manager, with the help of my team, I must size up the cost of doing a software development project. At the onset of the ‘costing’ effort, one of the common tools that a Project Manager has available is the Function Point Analysis (FPA) method. The FPA is not a distinct estimation effort but is a generic broad estimate on the cost and effort that can be used as a first pass to true software development costs. FPA considers the relationship between the size (scope) of the functional requirements and the amount of relative effort to build the requirement out (Balraj, 2018). FPA analysis can be later used as a cost driver to deeper project effort calculations, such as with Bohem’s COCOMO (Constructive Cost Model) process, developed in 1981 (Beal, n.d.).
To describe what a Function Point (FP) is, the FP is a unit of measure that is determined (through analysis). The FP is essentially the weight that a particular business or user functionality has for a given piece of software. This unit of measurement is combined with other Function Point measurements that the system has to offer. The analysis of the function points includes a relative weight for each function point and can be used to measure the time (and cost) for the varied parts of the designed software.
This brief article is a primer to FPA. FPA can be significantly more complex, however, the intention of this piece is to briefly describe a high-level view of FPA. Consider this a starter conversation.
In today’s software environment, Function Point Analysis (FPA) comprised of five standards for Functional Sizing (the ISO/IEC 14143 specifications discuss FPA). The FPA process is approved by the International Standards Organization (ISO). This standard is specifically expressed in the ISO/IEC 20926 standard entitled “IFPUG Functional Size Measurement” (Balraj, 2018).
There are 5 types of ‘functions’ abbreviated by EO, EQ, EI, EIF, and ILF. These 5 are defined by Alexander (2016) as follows:
1. Data Functions — Internal Logical Files (ILFs): ILFs represent data that is stored and maintained within the boundary of the application you are counting. (think relational database, flat files, etc.)
2. Data Functions — External Interface Files (EIFs): EIFs represent the data that your application will use in a read-only manner, and is not maintained (added-to, edited, or deleted) by your application. For an example of an EIF, first imagine that you work for a large corporation named MegaCorp. MegaCorp has an “employees” database table, and they insist that any application that is developed must read employee information from this table. The employees table is maintained by some other people and some other application you know nothing about; you just know that in your application, when you need employee information, you’re supposed to read it from this table. Because your application (a) uses that data but (b) does not maintain that data, it is considered an EIF for your application.
3. Transaction Functions — External Inputs (EIs): Here’s the official IFPUG definition of an EI: “An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.” General examples of EIs include — Data entry by users or Data or file feeds by external applications. A few specific examples of EIs include: Adding a post to Facebook or Creating a new tweet on Twitter.
4. Transaction Functions — External Outputs (EOs): IFPUG defines an EO as follows: “An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs, or alter the behavior of the system.” Examples of an EO include: Reports created by the application being counted, where the reports include derived information.
5. Transaction Functions — External Inquiries (EQs): The last transactional function is referred to as an EQ, or External Inquiry. The IFPUG definition of an EQ is as follows: “An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF of EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered.” Examples of EQs include: (a) Reports created by the application being counted, where the report does not include any derived data, (b) Other things, including “implied inquiries.” (implied inquiries are typically used to create dropdown widgets and other list and tree widgets in the UI, where those widgets are dynamically populated with data from ILFs and EIFs.).
Alexander (2016) depicted a system that contains screens, inputs/outputs, and associated applications that interface with the proposed software. His diagram, shown below, indicates the 5 types of functions:
To start using the FPA method, gather your existing system model and identify the ILFs, EIFs, EIs, Eos, and EQs in your model. Following that, count the following:
1. Determine the count of ILFs
2. Determine the count of EIFs
3. Determine the count of EIs
4. Determine the count of EOs
5. Determine the count of EQs
After the count of ILFs, EIFs, EIs, Eos and EQs, next determine the level of complexity for each of the 5 counted groups above. The level of complexity is another best guess. There are three levels of complexity that can be assessed including low, medium or high. For each of the 5 items above, determine the level of complexity. For example, if you have a count of ILFs, determine the complexity of the ILFs.
ILF Complexity Count (we have 5 total ILF in this example) with (1) Low = 4, (2) Medium = 1, and (3) High = 0.
Following the complexity count, there is a weighted value for each of the complexity levels. For ILFs, the weighted value is in this example (1) Low = 7, (2) Medium = 10, and (3) High = 15.
Multiply the complexity times the weight, giving you the FPA for the ILF portion. The ILF FPA Calculation consists of multiplying the count by complexity. For Low, we have a count of 4 multiplied by 7 giving an ILF value of 28. In a like manner, our Medium ILF value is calculated as 10 (1 x 10) and the High ILF value is calculated as 0 (0 x 15).
For the ILF functions in the ‘imaginary’ system, we have a function count of 38. Do this for the remainder of the system. An example spreadsheet is noted below for all 5 in this imaginary/example system.
In summary, Function Point Analysis (FPA) is one measuring stick that can help the software development Project Manager to gain understanding about the size and complexity of the proposed software system. FPA can be a complex process and this brief article is intended to be a high-level primer. FPA is a rough-cut estimate and can be further used as input for more refinement of costing software development, as with the COCOMO model. FPA is one of several tools used to measure project cost and is a valuable tool to have in the PM toolkit.
References
Alexander, A. (2016, October 25). How I Estimate Software Development Projects (free PDF). Retrieved March 11, 2019, from https://alvinalexander.com/programming/how-i-estimate-software-development-projects-free-pdf
Balraj, J. B. (2018, January 9). What is Function Point Analysis? Retrieved March 11, 2019, from https://stackoverflow.com/questions/37151310/what-is-function-point-analysis
Beal, V. (n.d.). COCOMO — Constructive Cost Model. Retrieved March 11, 2019, from https://www.webopedia.com/TERM/C/COCOMO.html
About the Author
Dr. Ron McFarland, CISSP, PMP is a Cyber Security Analyst at CMTC. He is a post-doctoral scholar for the University of Maryland University College. He received his doctorate from Nova Southeastern University’s School of Engineering and Computer Science and a post-doc graduate certificate in Cyber Security Technologies from the University of Maryland University College. He also holds multiple security certifications including the prestigious Certified Information Systems Security Professional (CISSP) certification and several Cisco certifications. He is a guest blogger at Wrinkled Brain Net (http://www.wrinkledbrain.net), a blog dedicated to Cyber Security and Computer Forensics. Dr. McFarland can be reached at his UMUC email: ronald.mcfarland@faculty.umuc.edu
