News, Publications

Unveiling the Mystery of Software Metrics: A Guide to Understanding Function Points, SNAP, COSMIC, Nesma, and SFP

23 August, 2023 | reading 5 min.

Photo with title of the article "Unveiling the Mystery of Software Metrics: A Guide to Understanding Function Points, SNAP, COSMIC, Nesma, and SFP

Are you feeling lost in the complex world of software metrics? Do not worry, this guide will help you understand the differences between the different methods such as Function Points, SNAP, COSMIC, Nesma and SFP in a simple way. 

Whether you are a developer, project manager or just interested in learning more about how software development works, this guide will give you the knowledge you need to enter the world of software metrics with greater confidence. Are you ready? 

IFPUG Function Points (FPA): The Key to Measuring Software Functionality 

IFPUG Function Points are a de facto standard method for measuring the functionality of a software system. Introduced by Allan J. Albrecht in the late 1970s, it provides a standardized way to estimate the size and complexity of a project. This facilitates improved resource allocation and project planning. 

It involves categorizing the system’s functionalities into two types: transactional functions and data functions. These are evaluated for their components, and function points are assigned values based on their complexity (low, medium, or high). Summing up these function points provides a measure of the project’s size. 

The advantage of using Function Points lies in their objective measurement of a software system’s functional size. This enables the comparison of different projects, estimation of development effort and resources, and tracking of productivity. They also serve as a common language among developers, project managers, and other stakeholders, promoting better communication and understanding. 

Quantifying Non-functional Requirements with SNAP 

While Function Points focus on the functional aspects of a software system, SNAP measures non-functional requirements (Software Non-functional Assessment Process). These requirements include factors such as performance, maintainability, security, and reliability. 

SNAP follows a similar approach to Function Points, but instead of measuring functionality (“what” the software will do), it measures the size and complexity of non-functional requirements (“how” the software will perform). Thus, SNAP complements Function Points and is crucial for improving effort and schedule forecasts. 

SNAP is useful because it provides a quantitative measure of non-functional requirements, allowing us to assess the quality attributes of a software system. This helps to identify potential risks and problems early in the development process and therefore to take corrective action and ensure compliance with desired quality standards. 

COSMIC: In-depth Exploration of Software Complexity 

COSMIC is another metric used to measure the functional size and complexity of a software system. Developed by the Common Software Measurement International Consortium (COSMIC), COSMIC FFP is based on data movements at different hierarchical levels and components called pairs. 

Each pair contains functional processes based on data movements, such as inputs, outputs, reads, and writes. Each data movement is assigned a value of 1 CFP (Cosmic Function Point). The size of a functional process is determined by summing up the sizes of data movements, and the total functional size of the software is obtained by adding the sizes of all functional processes. In the case of software modifications, the modification’s size is calculated considering changes in data movements. The resulting total functional size of the software system can be used for estimation, project planning, and performance measurement. 

COSMIC provides a more detailed and accurate measure compared to other methods by accounting for data structure complexity and processing logic. 

The Nesma Method: Software Metrics Adapted to Evolution 

The Nesma method, developed by the Netherlands Software Metrics Association (Nesma), is another popular software metric. It is used to measure the size and complexity of a software system, especially for maintenance or enhancement projects, by considering changes made to transactional and data functions.  

How do you count these changes? As follows: new functions are counted as in the IFPUG method, modified functions are counted considering the impact of the changes made, and deleted functions have a fixed value. An impact factor is used to determine what percentage of the function was affected by the changes. This makes it possible to calculate how many function points of the entire function are affected.

The main advantage of the NESMA method lies in its tailored approach to enhancement projects, offering a more accurate and reliable measurement of software size and changes. 

Simple Function Points or Streamlined Measurement 

The Simple Function Point (SFP) method, designed by Roberto Meli in 2010, is a simplified version of the traditional function point metric. Its objective is to offer a more accessible, rapid, and practical approach to measuring software size and effort, especially when information is limited. 

SFP focuses on only two basic functional components: Elementary Processes and Logical Files. It does not require identifying the “main intent” of functionalities or distinguishing between internal and external logical files. Additionally, it does not consider the internal complexity of components, making the process faster and requiring fewer details. 

Among its advantages, SFP allows for quicker and simpler estimation of software size and effort. Moreover, it is a rapid and easy-to-learn method, applicable in the initial stages of the software lifecycle due to its minimal detail requirements. It also integrates well with story points in agile processes. 

Metrics Reimagined… 

Have you made it this far but still feel a bit unclear? Let us imagine for a moment that developing a software product is akin to organizing an event. You need to estimate the time and effort required to execute it. 

  • With Function Points, you would measure the event’s functionality, the “what”: you would categorize different event functions into two types—activities performed (transactional functions) and necessary elements like decorations, music, and food (data functions). You would assign points to each activity and element based on their components and complexity. Summing all points would give you a measure of the event’s size and complexity. This would aid in allocating appropriate resources and better planning. 
  • Using SNAP, you would measure the event’s non-functional requirements—how the activities will be carried out: performance, security, and event quality. For instance, you could measure event duration (performance), implement security measures for attendees (security), and ensure high-quality music and entertainment (quality). SNAP would provide a quantitative measure of how well the event meets these non-functional requirements. 
  • For event organization, COSMIC would help measure the complexity and quantity of tasks involved in preparation. Instead of merely counting activities and elements, COSMIC would consider data movements and interactions among them. For example, you could measure the number of speakers, duration of each presentation, logistical arrangements, and technical requirements for presentations. Adding up these metrics would yield a more precise measure of complexity and effort involved in organizing the event. 
  • Suppose you have organized similar events in the past and aim to enhance your processes. With the Nesma method, you would measure the event’s size and complexity, accounting for changes and improvements compared to previous events: whether you have modified the schedule, added new activities, or changed catering. Using Nesma, you would calculate how much the event has changed in terms of size and complexity, considering new or modified elements. 
  • And with Simple Function Points, you would focus on just two basic components: the number of essential event activities (elementary processes) and the number of elements like food and beverages needed (logical files), without assessing their complexity. This approach would enable quick and simple estimation of the required size and effort for organizing the event. 

As you can see, these metrics share the common goal of measuring software size and complexity, but they differ in their approaches, rules, and guidelines. Evaluating the organization’s needs and project requirements is essential before selecting the most suitable metrics. 

If you are interested in learning any of these software measurement methodologies, visit our Academy to explore upcoming online courses. You can also request a demo of our Quanter software estimation SAAS tool, which makes estimation and project tracking even more accessible for your development projects. 

Do not miss our next article, where we will discuss the advantages of using metrics and provide tips for their successful implementation.