SNAP Points

SNAP is the acronym for "Software Non-functional Assessment Process", a measurement of non-functional software size. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional user requirements. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Practices Manual” (APM) now in version 2.4. The SNAP methodology has the IEEE standard IEEE2430-2019.

Introduction

“Software sizing or software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities (such as estimating or tracking). Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.”

A software application can provide two aspects of value to its users. The first aspect is its data processing capacity. This is basically the flow and storage of data through the application. This flow and storage can be defined as its "functionality". One metric used to measure the size of one unit of this functionality is the “function point.” By using an ISO-standard functional sizing metric (FSM) such as that in the IFPUG “Function Point Counting Practices Manual,”[1] (FSM ISO/IEC 20926:2009),[2] a function point counting specialist can examine the software application’s functional portion and measure its functional size in units of function points.

For more detail on the function point metric, and other organizations’ functional software sizing metrics, see the bibliography, the Wikipedia article “function point,” and numerous references in the literature.

A software application can also provide aspects other than data processing capacity. These types of software are defined by IFPUG as being “non-functional.” Their size is measured by SNAP. The IFPUG APM[3] details how to size the non-functional aspects of software applications. The SNAP methodology has the IEEE standard IEEE2430-2019.[4] The non-functional aspects are defined and classified in ISO/IEC 25010:2011, “Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models”.[5]

The functional size, together with the non- functional size, should be used for measuring the size of software projects. The two sizes should be used to measure the performance of the software project, setting benchmarks, and estimating the cost and duration of software projects.

The Non-functional Sizing Method

Similar to function point sizing, one unit of non-functionality is the “SNAP point” and the sizing of the non-functional portion of an application can be measured by using the procedure in the APM. Similar to function points, by using the IFPUG APM, a SNAP point counting specialist can examine the software application and measure the size of its non-functional portion in units of SNAP points. Also like function points, the number of SNAP points in an application correlates with the work effort to develop the non-functional portion of that application. The original research detailing this correlation is in CrossTalk The Journal of Defense Software Engineering, as the paper “A New Software Metric to Complement Function Points The Software Non-functional Assessment Process (SNAP)”.[6]

Each portion (the functional and the non-functional) of the software project requires work effort to develop, which is proportional to their software sizes. Software development organizations can use their correlations between function points and their work effort, and between SNAP points and their work effort, to help forecast their software development costs and schedules and to audit projects to determine how well funding was spent and schedules were managed

SNAP recognizes four categories and 14 subcategories of non-functionality. These are in the below table from the APM.

1. Data Operations
1.1.      Data Entry Validations 
1.2.      Logical and Mathematical Operations 
1.3.      Data Formatting 
1.4.      Internal Data Movements 
1.5.      Delivering Added Value to Users by Data Configuration
2. Interface Design
2.1.      User Interfaces
2.2.      Help Methods 
2.3.      Multiple Input Methods 
2.4.      Multiple Output Formats
3. Technical Environment
3.1.      Multiple Platform 
3.2.      Database Technology 
3.3.      Batch Processes
4. Architecture
4.1.      Component Based Software 
4.2.      Multiple Input / Output interfaces

For example, software development to change the field sizes for data in a data table does not represent changes in data processing capacity. However, this development requires work effort. Data Formatting is considered non-functional, and is countable under SNAP subcategory 1.3.

Help Methods (subcategory 2.2) are usually considered non-functional. When compared to the function point process, which requires data to cross an application’s boundary and maintain an internal logical file, the Help data may be coded to reside internally as part of the application development and be accessed upon command from the user. This access can be anything from bubble help over an icon on a screen, to access of part of an internally stored application operations manual. Data is not being processed per se, so Help is usually considered non-functional.

Function points and SNAP points measure two different aspects of software, and therefore are not added together. For example, an application of 500 function points and 300 SNAP points cannot be considered to be the size 800 of some metric; function points and SNAP points are intended to be orthogonal. A good reference for further detailed information regarding the relationship between functionality and non-functionality is in the document “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating”.[7]

Benefits

SNAP provides users and software development teams many benefits additional to the sole use of function points. Below are five of many examples.

  • Measuring the non-functional requirements improves the work effort estimation of software development based on functional sizing alone.
  • This improved work effort estimation should also lead to better estimates of scheduling, resource allocation, and risks.
  • Including the measure of non-functional size improves the work effort estimation to maintain the software after it is deployed.
  • The productivity rates of project teams can be better determined because more factors are included in their measured work output.
  • Including both functional and non-functional work products better demonstrates value delivered to the user.

Further, some software development efforts might be measured as having zero function points. For example, an Agile software maintenance sprint might be required only to change the length of data fields in data tables. This would be measured to have zero function points because it is non-functional; however, that work would be accountable in SNAP. SNAP at least partly solves the “0 function point” problem.

Areas for future research

The SNAP beta test in 2012 was conducted using 48 applications. More research will hopefully improve the calibration of the subcategory weighting factors to yield an even stronger statistical correlation. It is recommended that future research results be submitted to IFPUG’s Non-functional Sizing Standards Committee (NFSSC) for review.

See also

Bibliography

Buglione, Luigi, and Santillo, Luca, “NFR: L”Altra Meta Della Mela,” Newlsetter, Gruppo Utenti Function Point Italia Italian Software Metrics Association, www.gufpi-isma.org, December 2011.

International Function Point Users Group, “How Function Points and SNAP Work Together,” MetricViews, www.ifpug.org, Princeton Junction, NJ, 08550, USA, August 2015.

Jones, Capers, “A Guide to Selecting Software Measures and Metrics,” CRC Press, Boca Rotan, FL, 33487, USA, 2017.

Jones, Capers, “Quantifying Software Global and Industry Perspectives,” CRC Press, Boca Rotan, FL, 33487, USA 2018.

References
  1. IFPUG, “Function Point Counting Practices Manual” v. 4.3, Princeton Junction, NJ, 08550 USA 2009.
  2. International Organization for Standardization, ISO/IEC 20926:2009, https://www.iso.org/standard/51717.html, Geneva, Switzerland, 2009.
  3. IFPUG, “Software Non-functional Assessment Process Assessment Practices Manual” v. 2.4, Princeton Junction, NJ, 08550 USA 2017.
  4. IEEE 2430-2019, “Draft Standard for Software Non-Functional Sizing Measurements” IEEE Corporate Headquarters, 3 Park Avenue, 17th Floor, New York, NY 10016-5997 USA, 2019.
  5. ISO/IEC 25010:2011, Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
  6. CrossTalk The Journal of Defense Software Engineering, “A New Software Metric to Compliment Function Points The Software Non-functional Assessment Process,” Ogden ALC/TISE, Hill Air Force Base, Utah, July-August 2013.
  7. COSMIC, IFPUG, “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating,” v. 1.0, September 2015.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.