Product Metrics in Software Engineering

Product metrics are software product measures at any stage of their development, from requirements to established systems. Product metrics are related to software features only.

Product metrics fall into two classes:

  1. Dynamic metrics that are collected by measurements made from a program in execution.
  2. Static metrics that are collected by measurements made from system representations such as design, programs, or documentation.

Dynamic metrics help in assessing the efficiency and reliability of a program while static metrics help in understanding, understanding and maintaining the complexity of a software system.

Dynamic metrics are usually quite closely related to software quality attributes. It is relatively easy to measure the execution time required for particular tasks and to estimate the time required to start the system. These are directly related to the efficiency of the system failures and the type of failure can be logged and directly related to the reliability of the software.

On the other hand, static matrices have an indirect relationship with quality attributes. A large number of these matrices have been proposed to try to derive and validate the relationship between the complexity, understandability, and maintainability. several static metrics which have been used for assessing quality attributes, given in table of these, program or component length and control complexity seem to be the most reliable predictors of understandability, system complexity, and maintainability.



Software Product Metrics :

S.No. Software Metric Description
(1) Fan-in/Fan-out Fan-in is a measure of the number of functions that call some other function (say X). Fan-out is the number of functions which are called by function X. A high value for fan-in means that X is tightly coupled to the rest of the design and changes to X will have extensive knock-on effects. A high value for fan-out suggests that the overall complexity of the control logic needed to coordinate the called components.
(2) Length of code This is measure of the size of a program. Generally, the large the size of the code of a program component, the more complex and error-prone that component is likely to be.
(3) Cyclomatic complexity This is a measure of the control complexity of a program. This control complexity may be related to program understandability.
(4) Length of identifiers This is a measure of the average length of distinct identifier in a program. The longer the identifiers, the more understandable the the program.
(5) Depth of conditional nesting This is a measure of the depth of nesting of if statements in aa program. Deeply nested if statements are hard to understand and are potentially error-prone.
(6) Fog index This is a measure of the average length of words and sentences in documents. The higher the value for the Fog index, the more difficult the document may be to understand.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

My Personal Notes arrow_drop_up


If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.


Article Tags :

1


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.