Software Functional Size 

Software is composed of different components and the size of these components is dependent on the functionality required (Singh, 2017). According to ISO, functional size must be independent of quality and technical aspects of the software (Abran, Al-Sarayreh, & CuadradoGallego, 2013) and it does not have any fixed proportional size relationship among those components (Singh, 2017).

Functional size measurement (FSM) is one of the techniques to measure the functionalities a software delivers to user (s) (ISO/IEC 14143-1 Standard, 2007) and it is applicable in software project management for different purposes: for example, to obtain system related technical indicators, development effort, manage scope in project, productivity studies, benchmark for future projects and normalize quality and maintenance ratios.

FSM is based on requirements and can provide size information early in the life cycle of the project (Ungan, Trudel, & Abran, 2018). When organizations collect the information from the past projects, they can build their own productivity and estimation models. This brings them the required data to measure their productivity from the past projects to find out their performance and how much it differs from the past projects. Having your own organization productivity model is a key advantage in the market and in the organization (Abran, 2015).

Research on FSM began with Allan Albrecht’s invention of Function Point Analysis (FPA) in 1979 (Lokan, 2005). One of the most important phases of FPA is recognizing system components that bring functionality to users (Zelkowitz, 2005). Abran and Robillard (1996) investigated the structure of FPA considering mathematical operations and scale types in the measurement process.

(Fetcke, 2001) proposed a generalized representation of available FSM methods focusing on commonalities and differences and concluded that the approach could be applicable using the experience of past projects and allowing FSM to be automated. (Berg, Dekkers, & Oudshoorn, 2005) applied FSM to UML-based user requirements and proposed a requirement space in four refinement levels: in their study, the FPA and COSMIC CFP were used and three case studies were investigated: the results were relatively on mark for both methods.

Software Sizing with COSMIC Method 

One of methods that is applicable to measure the functionality of a software from different domains is the COSMIC method (ISO/IEC 19761 Standard, 2011) accepted as an International Standard: ‘ISO/IEC 19761 Software Engineering, a functional size measurement method’. COSMIC FSM measures the functional size of the software derived from its FUR. COSMIC Function Point (CFP) is a unit of measurement that represents the data movement for software and 1 CFP is equal to the size of a single data movement of a single data group (COSMIC, 2017).

Function point sizing (FPS) quantifies the functional size of software and is used for various purposes in software project management, including effort estimation, project planning, project monitoring, productivity studies and benchmarking (ISO/IEC/IEEE 29148 Standard, 2011), (Desharnais & Abran, 2003). This makes FPS a tool of choice for planning techniques that require an early view of the software to be developed. Despite being available earlier than other sizing methods, a precise application of FPS requires that the functional requirements of the software be detailed, and its architecture defined (Santillo, 2000).

FSM patterns are applicable to the COSMIC method and useful for measurers to address different issues such as: early sizing estimation, measurement errors and decreasing measurement effort. A study by Abran et al. (2002) discussed an estimation model for a maintenance project to implement functionality in the existing software. In their study, two estimation models were investigated: a regression model with functional size only and a multiple regression model with two independent variables.

(Trudel, 2012) investigated the efficiency and effectiveness of COSMIC to identify defects in functional requirements. The FSM brings added value and saves the rework cost if the identified defects by measurer are corrected early in the development cycle. In another study (Trudel, Desharnais, & Clout, 2016) focuses on the application of FSM pattern with real-time embedded systems and suggests the potential benefits for the industry.

(Huijgens, Bruntink, Deursen, Storm, & Vogelezang, 2016) presented an exploratory study on FSM based on code and discussed challenges, obstacles, and opportunities the experts experience on software project code. 87% of the FSM experts have the same opinion that the FSM is an important tool for decision making and COSMIC with 25% is the most preferred FSM method.

Today, many software development companies have adopted the agile process. A study by (Hussain, Kosseim, & Ormandjieva, 2013) presented an approximate COSMIC functional size from informally written textual requirements and build a historical database by manually measuring the COSMIC functional size from textual requirements. (Sellami, Haoues, Borchani, & Bouassida, 2018) studied functional changes in agile projects and proposed a guide for decision makers in software development projects when they encounter changes in software requirements during agile sprints. The tool is based on user stories and the COSMIC sizing method and examined 15 software development projects.

COSMIC method is applicable in different domains such as (COSMIC, 2017): business applications, real-time software and several case studies are proposed by the COSMIC group in the mentioned domains, but not with AI applications. (Soubra, Abran, Stern, & RamdanCherif, 2011) proposed an FSM procedure for real-time embedded software based on COSMIC and documented the requirements with the Simulink tool. The automated tools reduce the measurement variances caused by interpretations made by different measurers. In parallel to this research project, Lesterhuis and Abran (2019) used the COSMIC method to extract the ML system requirements of an ML image classifier software in a neural network: it presents the ML functionalities and allows the ML expert to have more freedom to address additional ML challenges.