Function Point Metrics in Software Engineering is a method that combines some rules to follow Functional Size Measurement. According to Allan J. Albrecht, the scientist who first developed it at IBM, Function Point Metrics gives a dimensionless number defined in function points which we have found to be an effective relative measure of function value delivered to our customer. It is a measure of quantitative assessment for the functioning size of the software work product. There is a certain amount of business that is provided to the user by the system that is being operated as information or product.
Function Point Metrics is the standard to measure that. Software is the objects that are subjected to be measured under the unit. Being a software engineering student from IIT Madras, all this data was quite easy for me to recollect, but good software engineering courses aren’t easy to come by.
The sizing is different regarding different organisations or public specifications. Some well-known ISO Standards are IFPUG, Mark-II, Nesma, and COSMIC. According to the International Function Point User Group (IFPUG), the most standardised and automated Function Point Metrics that can be found and implementable is the OMG Automated Function Point (AFB) specification. The spoken automated function point specification is led by the Consortium for IT Software Quality. After new developments, there have been some limitations that have been restrictions to these standards. The standards which are used to compute Function Points are not able to detect and distinguish between the two components without upfront configuration – External Output (EO) and External Inquiries (EQ).
The data that is extracted through the Function Point Metrics are divided into five different forms when they are extracted. They are outputs, inquiries, inputs, internal files and external interfaces. When a task is computed by the Function Point Metrics, there are a series of functions that are detected by the system. Once the function is detected, it is reviewed and categorised into one of the listed categories. There are complexities and mixtures which are given different function points according to their behaviour. The data is entered by the user, and therefore, the encryption only allows the functional user requirements map to end by the user business function that it provides.
The function points that are distributed according to the categorisation is important because it makes it easier for the information to get user-oriented, according to user requirements. The function points map easily categorise the functions and organises them accordingly. The only drawback that is noticed is that it tends to hide internal functions. The algorithms, which are major participants in resources to implement, are hidden in the process.
ISO has been trying to figure out the way out of this problem, but no Function Points Metrics method is detected or discovered yet, which has the ability to include algorithmic complexities when it computes the sizing of the software for the user-optimization. In the latest news that we got regarding the search of the relevant Function Points Metrics method to include the algorithmic complications, different approaches have been seen to the condition, amongst which one of the approaches was to deal with the weakness of the result that we get through the method of Function Point Metrics method to not be able to accumulate all the data. There are various commercial software products that promise to be able to fix the loopholes when implemented, but they have just turned out to be void announcements.
There are variations of the Allan J. Albrecht-based International Function Point User Group method discovered and tried to cope up with the flaws of the existing system. In the first approached method, the function points are preferred to be adjusted in a way that it compensates for the missing data. The two major principles that this method was inclined on were the subjective complexity measurement and elimination of the need to count data elements to measure the complexities discovered in the process.
This was not the end to finding a process to simplify the problem to calculate the Function Points of the algorithmic complexities. There is a second approach to it, which is commonly described as Engineering function points. In the process, the variable names of the program, operators used in the program – be it arithmetic, Boolean or equality – were counted too. The computation function was taken under the count of Function Points this way. The approach was similar to the intent of operator or operand-based Halstead complexity measures.
There was another in-famous method which was a logistic and more sincere approach. It was the Bang measure – it defines a function metric based on twelve primitive counts that affect or show Bang. This method can be simplified to explain the evaluation of the software’s unit value in terms of how useful the function has been there by the user. The error can show up in the calculation, but alternate methods to find those small entities were also spoken about. This method can be proven to be effective when the re-encapsulation of the engineering is considered.
There were a lot of other approaches made from different working bodies, but this was the closest that all of us could come to solving the problem of not being able to find out the exact Function Points count of the algorithmic complexity.
Here are a few points about the Function Point Metrics in Software Engineering that I would like to conclude with –
- This metric overcomes the shortcoming of the LOC metric.
- In LOC, metric size can be determined accurately only after the product has fully been developed, but in function point, size can be determined directly from a program specification.
Here, the size of a software product is directly dependent on the number of different functions or features it supports. It also depends on the number of the file and the interfaces.
- It is certain that a product that supports many features is larger in size than a product with few features.
FAQs
- What is the price of one Function Point?
The value of a Function Point in the market will vary with respect to the work required for the delivery of software functionality, in accordance with the technical standard and quality required by customers, as well as the number of deliverables required by the customer. In summary, everything that significantly affects the cost but has no direct relation to the size measured. - What are the steps of function point analysis?
The steps to summarise how it works are it determines the type of function point count. Next, it identifies the counting scope and the application boundary, identifies all data functions and their complexity. - What is the unit function point?
A Function Point (FP) is a unit of measurement to express the amount of business functionality an information system (as a product) provides to a user. FPs measure software size.
This article does a great job of explaining function point metrics in software engineering. Thank you!