Here we'll explain what SNAP is, its workarounds, and how it relates to APF in an integrated IFPUG suite for software management measurement support.

What's common

Initially before entering into the merits of the relationship between SNAP and APF, it is necessary to establish what they both have of common: Both are used in parametric models of estimation in the production of product units, whose quantity is the independent or known variable to estimate or prescribe effort or cost, as dependent or unknown variable.

The object measured in The Function Point Analysis

In the case of Function Point Analysis, function points are, depending on the purpose, measures or approximations of the amount and complexity of the functionality requested and delivered to the user. To this end, the measurement process exclusively considers the functional requirements of the user. Obviously, a software product does not exclusively meet functional requirements.

Productivity indicators in Function Points

Therefore, the use of productivity indicators at function points for estimates or software management presupposes balancing in effort or cost to meet the corresponding non-functional requirements in a given evaluated scope. Typically, this is achieved by a scope of a certain size and because the functional dimension reflects the behavior of the software when absorbing a user task or service, while meeting non-functional requirements is closer to a general behavior; therefore, approached by architecture. However, this is not always so; for example, when a demand refers specifically to the suitability of the software to meet a non-functional requirement.

Demands for Non-Functional Requirements

The very definition of what a demand like this is is not trivial. This is because if we change the referential of who is the user almost all demand can be considered as functional. This is the approach cosmic used to measure non-functional requirements.

One point of attention is the need to consider the particularities related to the different production processes at each user level.

For example, measuring architecture software, where users are software components interacting with each other, does not necessarily involve the same unit cost (R$ / PF ) or delivery fee ( HH / PF ) as the respective indicators for the development of commercial applications, where users are people and other applications at the same level.

Ifpug's Historical Solution – Adjustment Factor Value (VAF)

In the past, IFPUG tried to define a model in which its measurement unit was the result of measuring functional requirements and, to the result of this measurement, an adjustment factor was applied. This sought to capture in size the variance in the effort coming from different restrictions described in the 14 General System Characteristics (GSC).

This model went bankrupt when the universe of the application of APF greatly overcame the reality of the mid-1980s. At that time, the variation of 1% variation in size at each variation of 1 in the evaluation of the Levels of Influence (DI) of each GSC was reasonable. It hasn't been for a long time.

Moreover, it was and is useless to characterize the measurement specifically of demands related to services that are not specifically related to a user task or service: any adjustment factor value multiplied by zero is zero!

The inception of SNAP

Dai, the problem arises for which SNAP was born as a solution proposal. Its focus is to define a software evaluation procedure in terms of its non-functional requirements (SNAP is the acronym for Non-Functional Assessment Process Software) and the manual that defines its procedure is the APF (Assessment Practices Manual).

SNAP Points (SP): Unit of measure in SNAP: Calculated from design analysis divided into components, processes or activities used to meet non-functional requirements

SNAP use cases

As an example of the project items mentioned above we have:

• Project to tailor application in which the volume of transactions comes to compromise the maintenance of service levels of response time.
• Programs that implement some restructured functions for part of their processing to be online and the rest processed at the end of the day;
• Previously normalized database tables reorganized to now incorporate some redundancy in exchange for higher speed in data recovery

Snap Workarounds

We can say that SNAP comes as an alternative to some guidelines from the SISP Software Metrics Roadmap. He tried to use the application function points relative to the impacted functionalities and a factor according to the type of demand as the basis for calculating non-functional demands. The weak point in these SISP items is that effectively the work (effort or cost) related to meeting these demands may have little correlation with the function points; therefore, it introduces serious risks that cause underestimation or overestimation of effort or cost.

How SNAP works

The core of SNAP are the categories and subcategories that seek to frame design components, processes, or activities:

• Framed according to a hierarchy of 04 categories and 15 subcategories;
• It intends to address all non-functional requirements including technical and quality requirements;
• Meeting non-functional requirements may involve the use of components, processes, and activities in a number of subcategories.

For example: The project will be evaluated in terms of the subcategories "3.3 Batch Processes" and "3.2 Database Technology".

Each subcategory has common characteristics:

• SCU associated with each category
• Specific rules for identifying and weighing the amount of SP from the Evaluation of the SCU

For example: SCU of the Database Technology category is the elementary process (functional dimension)

The relationship between categories and CUS is shown in the table below:

<tabela>

for instance

Subcategory "3.2 Database Technology"

From the application of SNAP and APF we can see some models:

• Effort depending on the integral measurement of functional requirements and non-functional requirements:

HH = PF x Delivery Rate (HH/PF) + SP x Delivery Rate (HH/SP)

• Effort adjustment from SNAP-derived complexity

HH = PF x Delivery Rate (HH/PF) x SP/PF derived factor

• Selection of delivery rate based on SP/ PF complexity

HH = PF x Delivery Rate (HH / PF) according to SP / PF track table

In addition to these three cases, a variety of solutions can be developed; for example, consider the amount of HH/PF within a SP/PF deductible and, the functionalities above that deductible have some additional measurement.

Or, use only a few SNAP categories for project elements, for example Multiple Media, whose implementation promotes serious deviations from average productivity. Then, add to the production measurement units referring to the presence of these elements from a scheme of compatibilization of PF and SP.

Next steps

If you want to get to know SNAP better, please contact us about the interest because we think about setting up a seminar on the subject and the interest of our community is a critical factor in investing in this direction.