Software Metrics

SOFTWARE METRICS

Software metrics are quantifiable measures that could be used to measure differentcharacteristics of a software system or the software development process.

Metrics and measurement are necessary aspects of managing a software development project. For effective monitoring, the management needs to get information about the project : how far it has progressed, how much development has taken place, how far behind schedule it is, and the quality of the development so far. Based on this information, decisions can be made about the project. Without proper metrics to quantify the required information, subjective opinion would have to be used, .which is often unreliable and goes against the fundamental goals of engineering. Hence, we can say that metrics-based management is also a key component in the software engineering strategy to achieve its objectives.

Definition

Software metrics can be defined as The continuous application of measurement based techniques to the software development process and its products to supply meaningful and timely management information, together with the use of those techniques to improve that process and its products.

Metrics ensure that the final product is of high quality and the productivity of the project stays high. In this sequence metrics for intermediate products of requirements and design is to predict or get some idea about the metrics of the final product. Several metrics have been designed for coding namely size, complexity, style and reliability.

Categories of Metrics

There are three categories of software metrics, which are as follows :

  1. Product Metrics : Product metrics describe the characteristics of the product such as size, complexity, design features, performance, efficiency, reliability, portability etc.
  2. Process Metrics : Process metrics describe the effectiveness and quality of the processes that produce the software product. Examples are :
  • Effort required in the process
  • Time to produce.the product
  • Effectiveness of defect removal during development
  • Number of defects found during testing
  • Maturity of the process
  1. Project Metrics : Project Metrics describe the project characteristics and execution.

Examples are :

  • Number of software developers
  • Staffing pattern over the life cycle of the software
  • Cost and schedule
  • Productivity

Attributes of Effective Software Metrics

Hundreds of metrics have been proposed for computer software, but not all provide practical support to the software engineer. Some demand measurement that is too complex, others are so esoteric that few real world professional have any hope of understanding them, and others violate the basic intuitive notions of what high-quality software really is.

Ejiogu defines a set of attributes that should be encompassed by effective software metrics. The derived metric and the measures that lead to it should be.

  • Simple and computable : It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time.
  • Empirically and intuitively persuasive : The metrics should satisfy the engineer’s intuitive notions about the product attribute under consideration.
  • Consistent and objective : The metric should always yield results that are
  • Consistent in the use of units and dimensions : The mathematical computation of
    the metric should use measures that do not lead to bizarre combinations of units.
  • Programming language independent : Metrics should be based on the analysis model, the design model, or the structure of the program itself.
  • An effective mechanism for high-quality feedback : That is, the metric should lead to a higher-quality end product.

Halstead’s Software Science

Software science is an approach-due to Halstead-to measuring software qualities on the basis of objective code measures. It is based on information theory, which in turn is based on the following measurable quantities, defined for a given program coded in any programming language :

  • R1, the number of unique, distinct operators appearing in the program;
  • R2, the number of unique, distinct operands appearing in the program;
  • N1, the total number of occurrences of operators in the program;
  • N2, the total number of occurrences of operands in the program.

The terms “operator” and “operand” have an intuitive meaning and is to be defined for different programming languages. The distinction is that operator works on operand.

Once we have defined R1 and R2 precisely, we can define the program vocabulary ri and the program length N as

R1 =R1 + R2 and N= N1 +N2 At this point, we can already consider some relations between the above quantities. A

first obvious relation is

< = N

Using these definition, Halstead suggests the equation

N= R1 log2 R1 + R2 log2 R2

where the “hat” has been placed on n to distinguish the quantity obtained, the calculated length, with this equation from the value of the length N obtained by, direct observation.

We decided to quote Halstead’s reasoning directly since, inspite of its intuitive attractiveness, it suffers from flaws that make it questionable. The major flaw is that a program is not a “single ordered set of n [distinct!] elements”, but a string, with possible repetitions.

Disregarding this observation, N is an estimate of the length of the program and not actual measured value of length of the program. So, when we compare N.Vs. N on the same sample codes or programs or published algorithms shows (N — N)/N is less than 10%.

Program level `1,’ is a measure of the ‘Level of abstraction’ of the formulation of an algorithm. Another important measure Halstead’s theory introduces is the effort ‘E’ defined as

Efforts = E = V/L

Halstead argues that E may be interpreted as the number of mental discriminations required to implement a program and also as the effort required to read and understand the program.

In conclusion, Halstead’s theory tries to provide a formal definition for such qualitative, empirical, and subjective software qualities as program complexity eases of understanding, and level of abstraction, based on the count of some low-level quantities, such as the number of operators and operands appearing in a program. The goal is to be able to predict the level of these qualities a program will have before the start of a project and then measure level mechanically to assess the quality of the resulting product.

Leave a Reply

Your email address will not be published. Required fields are marked *