The purpose of this case study is to illustrate assessing extensive mathematical operations under the “Logical and Mathematical Operations” sub-category of the SNAP methodology.  This case study will --

•    Discuss why both function points and SNAP are important to consider in software sizing.
•    Discuss why it is important to distinguish between simple or routine mathematical operations and extensive mathematical operations.
•    Define and describe the terms “simple” or “routine” mathematical operations and “extensive” mathematical operations.
•    Provide examples of both simple or routine mathematical operations and extensive mathematical operations and how to count them.

In this case study, the term “function point” refers to the International Function Point Users Group (IFPUG) functional size measurement method, unless otherwise indicated.  Assume that when discussing the function point counts of external outputs (EOs), these refer to EOs which incorporate mathematical operations in their generation.

Mathematical operations include the operations of arithmetic, algebra, geometry, trigonometry, calculus, and other higher level mathematical operations. They also include operations of applied mathematics such as business applications of calculation of corporate income tax, earned value, project scheduling, optimization, and queuing applications. Other examples can be found in engineering applications and calculation of planetary orbits.

One of the most important reasons to size software is to be able to forecast the work effort required to develop the software. This was a fundamental principle of Dr. Allan Albrecht’s 1977 paper “Measuring Application Development Productivity” where he showed the statistically significant correlation between the function point sizes of sampled applications with their corresponding work effort. Historically, sizing an elementary process was determined by the type of processing logic used by the external input (EI), EO, or external inquiry (EQ). While this can give a higher size to the elementary process that contains mathematical operations, it does not necessarily correlate to the effort needed to produce extensive mathematical operations.   

The size of humans can be measured (in part) by height and weight. If one is interested in “height,” then the measurement tool is either a ruler or a meter stick with either “inches” or “meters” being the metric of choice. If one is interested in “weight,” then the measurement tool is a scale and the metric is either “pounds” or “kilos.”  Sometimes both height and weight are needed, so both inches and pounds (or, meters and kilos) are used. Neither height nor weight is “more important” or “better” than the other – rather, each is appropriate for a given circumstance. IFPUG recognizes two metrics for software sizing. If functional size is being measured, then function points is the appropriate metric. If non-functional size is being measured, then SNAP points is the appropriate metric. Use both function points and SNAP points if both functional and non-functional sizes are being measured.

Sizing EOs requires a functional metric, so function points are used. The sizing factors are the number of data element types (DETs), and the number of file types references (FTRs) (i.e. internal logical files (ILFs), and/or external interface files (EIFs) used for the EO).  Sizing extensive mathematical operations requires a non-functional metric, so SNAP points are used as the metric.  The sizing factors for SNAP points in this situation are also the number of DETs, and the number of FTRs.  When sizing non-functional requirements using SNAP, use the definitions for DETs and other sizing terms from the IFPUG SNAP Assessment Practices Manual, which may be somewhat different than the definitions for sizing functional requirements from the IFPUG function point Counting Practices Manual.

SNAP defines an “extensive” mathematical operation as a mathematical operation which includes using one or more algorithms. An algorithm is defined for SNAP as a series of mathematical equations and calculations executed in conjunction with, or according to, logical operators to produce results identifiable to the user. Examples of extensive mathematical operations include using the Program Evaluation Review Technique (PERT) to calculate the expected completion date of a project, calculating the optimal profit for a business process using linear programming, determining the way to formulate the fastest flowing waiting lines using queuing theory, and finding the shortest route through a network. Examples of other algorithmic mathematical operations fitting the definition of “extensive” include solving calculus integration formulas, calculating federal income taxes, GPS calculations, gaming, weather forecasting, and perhaps calculating retirement pensions.  

“Simple” or “routine” mathematical operations are defined here as not using algorithms. Examples can include adding a column of numbers, balancing a checking account, totaling daily sales, and calculating averages. Also, an application may require a simple or routine mathematical operation to be iterated many times. For example, a fast food restaurant manager may need to place an order for ketchup packets from a supplier. The manager first counts the current inventory of ketchup packets, forecasts the expected usage, and places an order to make up for the expected resulting shortfall. This is a simple or routine mathematical operation. If the manager has 100 types of items in inventory, and must perform this calculation 100 times to complete the total order with the supplier, then this is still defined as being a simple or routine mathematical operation because the simple or routine mathematical operation is iterated 100 times:  “extensive” refers to the depth of the algorithm(s), not to the number of simple or routine calculation iterations needed.

There are two examples in this case study. The first is intended to illustrate a class of simple or routine mathematical operations. Its result is an EO with 3 DETs and 1 FTR, and its work effort correlates with its functional size of 4 function points. The second is intended to illustrate a class of extensive mathematical operations having the same functional size as the first class, and additionally having non-functional size. Its work effort is the sum of the work effort correlating with its functional size, and the additional work effort correlating with its non-functional size.

In the function point analysis of each example, the focus is on the functional size of each EO only. Assume that the only mathematical processing relevant to the example is that needed to eventually generate the EO.

Login as a member to access this resource.

Non-Members: $20.00, purchase the publication here: https://ifpug.memberclicks.net/fpamicroservices