Data Structure Metrics

In the size metric, we have learned to measure/ determine the size of a program by various software metrics such as line of code, Function count, and Token Count.

A program consists of data also, and it becomes necessary to measure the data of a program. Scientists introduced data structure metrics to measure the data of the program.

Data structure metrics are based on the pre-stored data (input, internal, and output data).

For example- Software is designed based on software planner. Software planner plans how many teams, efforts, and what cost is required to make software. Software planner provides the following data:

Software Planner

Input data	Internal data	Data output
Program Size	Rate per developer	Project effort
Number of developers	Other factors	Project completion duration
Duration of software		The estimated cost of the developer

It's all about data; we have to find out "how and which data is arranged (linked) in best possible way," Suppose there is two software planner (A and B) having input, internal and output data and find VARS (count of variables).

VARS = count of variables

  n₂ = VARS + unique constants + labels

N₂ = n₁ V₁ + n₂ V₂+ n₃V₃ + n₄ C₁ + n₅  C₂ + n₆  L₁+ n₇ L₂+.....

 N₂ and n₂parametersare robust and best, to sum up, all the computations in the software.

Even changes in algorithm and computations are calculated effortlessly with them.

Definition -"A total amount of data used as input, that is processed in and produced output from software is called data structure metrics."

Most data metrics focus on the variables and constant within each module but not on input/output dependencies.

Few metrics only concentrate on input/ output situations.

In the data structure, we will discuss the following points related to data.

• The amount of data measured
• Usage of data within a module
• The degree to which data is shared among modules.

Usage of data within a module

In this, we understand how data is used in a module itself.

Live variable – "A variable is live at certain point if it holds the value that is required in future or the value may be read before the next time the variable is written to."

"A variable is live from its first reference to its last reference within a module or procedure or program.

For example: Suppose in a program variable is declared names like 'x.' Value assigned to x variable will be live until another value is added.

Some misconception about live variable are:-

• A variable is live from starting to the ending of a program written.

For example: In this program, two variables are declared (

int a, int b where a = 5 and b= 10).

We can read variable 'a' from starting to end, but variable 'b' is live only once in the program (at the time of declaration).

So this statement is wrong; a variable doesn't need to remain life from the beginning of the procedure to the end of the procedure.

• When a variable is assigned a certain number before or after the statement, then it is considered as a live variable at that particular statement. For example, suppose we have to find live variable 'c' on a particular statement like print f (....). We track variable all the above and below statement to print f. So this statement is also wrong.

Find the average number of live variable?

LV = sum of the count of the live variable of each statement/ count of executable statement.

Example: Find out the average number of a live variable?

Variable span

 A variable span is a metric that captures "how often a variable used in a program." The life span in a program or module of a program is called its span(SP).

The size of the span indicates several statements that pass between successive uses of variables.

N statements ← n-1 spans.

For example:

Here's a program code from line 21 to 60 containing live variables a & b. In between statement from 21 to 60 doesn't deal with a & b variable.

Number of reference of 'a' variable = 5

Number of reference of 'b' variable = 3

Therefore variable 'a' is used more.

Average span (SP)

Average span = Difference between lines having live variable/ total number of lines.

Average span of 'a' = 10, 12, 7, 6 = 35/4

Average span of 'b' = 23, 14 = 37/2 = 18.7

Applying knowledge (Formula's) to programs

Program weakness

How to track software metrics?

As we know, software metrics act as a backbone in the software development process.

They help the software development team track the software development, set new goals, and measure the performance of the software.

Despite all the merits, software metrics can distract software developers from goals such as delivering useful software and increasing customer satisfaction.

This data collection of software measurement metrics is more critical because work on the software is done based on collected data.

Software metrics work should be done precisely so that the software development team can work better for the software, and it wouldn't create any problem in creating code/ source code. Therefore software metrics should have some characteristics like:-

• Accurate and reliable
• Adaptable and calibrate
• Must be computable and simple
• Consistent (as it uses the consistent unit for measurement) and unambiguous
• Metrics must be independent of programming languages
• Easy and cost-effective to obtain high-quality software products

The presence of these characteristics in software metrics can assure of delivering good quality software to the customers.

Because of this, software development platforms that automatically measure and track metrics are essential.

But the significant risk of having too much data for measuring leads to errors for the software development team.

So, technically it becomes essential to learn how data of software metrics are collected, calculated, and reported. Some points describe how to track or make appropriate use of software metrics.

1. Software metrics are linked to goals

To achieve a standard quality of software, specific goals are achieved by the software development team.

Therefore software metrics like reducing lines of code, removing some bugs reported, increasing task completion time, and some software iterations are linked to the goals such as improving software usefulness and user experience.

For example, the LOC (line of code) metric is a size-based software metric indicating coding complexity or software efficiency.

LOC is used to measure source code lines and make developers reduce the complexity and simplify functions.

So, to reduce complexity, software developers write more functions with few lines of code to achieve the target.

Therefore it stated that to achieve a particular goal, the software development team choose the software metric and align metrics with these goals.

2. Track trends, not numbers.

The result of software metrics measurement is in simple numbers that are easy to compare. These resulting numbers are essential for the management because they make it easy to declare the success of getting metric software target.

When the software development team does not reach these set numbers, it states its failure to reach the target. These clarified goals or target doesn't reflect how software metrics are trending.

Moving of trending line in a particular direction tells about the progress of the process in a particular direction. Trends tell the effect any change in the process has on progress.

3. Set shorter measurement periods.

When software development teams measure the software at once, that may result in failure of reaching the target.

To solve this software development team break the measurement periods into smaller time frames to determine how well the software metric is working.

By setting shorter management period provide more particular data points that are step ahead in reaching not just metric software target but also software development goals.

4. Don't use such a metric that doesn't lead to progress.

The main focus of using software metrics should be a software improvement, but when repeating actions result in no change in solving errors, then goals are not achieved.

If software developers keep doing the same thing that's not getting them closer to close, it reflects that they are focusing on software metrics that don't lead to any change.

Therefore software development and management team have to focus on such metrics that progress towards goals and improvement.