SNAP Points

Introduction

The International Function Point Users Group [1] now recognizes two complementary software sizing metrics. The first metric is “function points”. Function points (FP) are units of measurement to express the amount of business functionality a software application provides to the user. It measures the flow and storage of data through a software application. Specifically how that is done through IFPUG is described in the IFPUG Counting Practices Manual (CPM). The International Organization for Standardization, ISO, describes functional user requirements as “a subset of the User Requirements (UR). Requirements that describe what the software shall do, in terms of tasks and services.”

The IFPUG Software Non-functional Assessment Practices Manual (APM) describes how to size the non-functional requirements. SNAP currently recognizes four general categories, each broken down into subcategories. Each subcategory is measured using the process in 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

The correlation between non-functional size using SNAP points and the work effort to provide them was proven during the beta test conducted in the fall 2012. The statistical correlation between the SNAP size of 48 randomly, internationally selected applications and the corresponding work effort to develop the SNAP points for those applications was found to be close to 0.89.

The overall size of software consists of separate components, functional and non-functional, for example, “400 function points and 200 SNAP points”. The two sizes do not sum up to one single size. The IFPUG functional sizing methodology does not change when measuring the non-functional requirements using SNAP.

Non-functional sizing requires recognition of similar artifacts of software used to measure functional size, for example: data element types (DETs) and file types referenced (FTRs).

Separating functional and non-functional requirements is important when performing a cost forecast (or other forecast such as scheduling or staffing) for software development. In principle, a cost forecast can now be made for the function point development effort, and a second forecast must be made for the SNAP development effort. The sum of both efforts will support the best estimate of the total effort for the software development. There are a few other comments to make as cost forecasting models built before SNAP were built on function points alone.

Some function point-based cost estimation models may already consider factors that are non-functional. For example, some of the traditional General Systems Characteristics (GSC) which may be traditionally included as part of the adjusted function point count as the “Value Adjustment Factor” (VAF) (CPM, v. 4.3.1, Appendix C) are also currently measured with SNAP.

Some commercial software cost estimators may have productivity settings that account for the impact of non-functionality.

Some care is needed to avoid the effect of duplication when arriving at cost estimates using both function points and SNAP points. Work effort used to develop function points cannot be also credited with developing SNAP points, as these are two separate aspects of software.

Function points have been in academia and industry since the publication of Allan Albrecht’s paper “Measuring Application Development Productivity.”; the methodology has matured by years of research and practice into what is now recognized as the IFPUG CPM. SNAP is new. The IFPUG Non-functional Sizing Standards Committee (NFSSC) expects that SNAP, too, will mature over the years as it is being released into academia and industry for research and practice. These are exciting times, as software cost forecasting (and other forecasting) continues to move away from being an art into a science.

Benefits

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.

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.

Furthermore, there are (as stressed in the IFPUG FPA CPM, according to the ISO/IEC 14764:2006 process) some types of maintenance projects that don’t have impacts on FURs, therefore being ‘zero-FP projects’. SNAP can provide a way to manage in a more structured way also those kinds of activities/projects. The effect will be – during next years – also the effort data gathering for the solely non-functional side of projects, allowing refining more and more estimates for projects taking into account measures for both sizes.

Areas for Future Research

The beta test 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.