1 Introduction to Software Quality Metrics

Introduction

The main objective of this module is to introduce software quality metrics. It also explains about process and product metrics. This module shows the difference between reviews and standards. It helps to understand the importance of object oriented metrics.

Definitions

• Measurement is a quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. E.g., Number of errors in a program.

• Metric is a quantitative measure of degree to which a system, component or process possesses a given attribute. “A handle or guess about a given attribute.” For example, the number of errors found per person hours expended is a metric.

Software metrics

Software metrics are measurements which are used to measure the complexity and quality of software. Different metrics are available for process, product and project. Moreover, software metric is any type of measurement which relates to a software system, process or related documentation. It includes lines of code in a program, the Fog index and the number of person-days required to develop a component. It also allows the software and the software process to be quantified. Software metrics are used to predict the product attributes and to control the software process. Product metrics can be used for general predictions or to identify anomalous components.

Software quality metrics are also called as software quality attributes. Some of the important quality attributes are Safety, Security, Reliability, Resilience, Robustness, Understandability, Testability, Adaptability, Modularity, Complexity, Portability, Usability, Reusability, and Efficiency.

Metrics are useful for measuring the quality of a process, project and product with respect to software being developed. The software quality metrics is a subset o f software metrics that focuses on the quality aspects of the software development lifecycle phases and their outcome. Metrics have always been used by the managers to make effective on the quality of the software developed for their organizations. However, as technologies and methodologies evolve metrics also evolved and hence, different types of metrics are available now. Moreover, defect tracking has traditionally been used as a metric to measure software quality throughout the software development lifecycle. Metrics are analyzed by managers in a software organization since, they provide a guideline to the management on the overall quality of the process, project and product. Generally, the validation of the metrics used for evaluation is a continuous process spanning multiple projects. The kind of metrics employed by a manager generally accounts for whether the quality requirements have been achieved or are likely to be achieved during the software development process. As a quality assurance process, a metric is needed must be revalidated every time it is applied.

Quality measurement enables an organization to improve its software development process since it assists in planning, tracking and controlling the software project and assesses the quality of the software thus produced. Moreover, metrics provide a measure of specific attributes of the process, project and product that are used to compute the software metrics. In the past, two leading software organizations namely, IBM and Hewlett-Packard have provided a great deal of importance on software quality. In such a scenario, the IBM applies metrics to measure the user satisfaction and software acceptability in eight dimensions which are capability or functionality, usability, performance, reliability, ability to be installed, maintainability, documentation, and availability. On the other hand, the Hewlett-Packard normally followed the five Juran quality parameters namely the functionality, the usability, the reliability, the performance and the serviceability for measuring the quality.

Software metrics can be classified into three categories: product metrics, process metrics, and project metrics. Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level. Process metrics can be used to improve software development and maintenance. In general, software quality metrics are more closely associated with process and product metrics than with project metrics. Nonetheless, the project parameters such as the number of developers and their skill levels. Common software metrics include: Bugs per line of code, Code coverage, Cohesion, Coupling, Cyclomatic complexity, Function point analysis, Number of classes and interfaces, Number of lines of customer requirements, Order of growth, Source lines of code and Robert Cecil Martin’s software package metrics.

Importance of Software Metrics

Metrics and measurements are both important. But metrics can be improved. On the other hand, measurements cannot be improved. Therefore, metrics determine the quality of the current product or process. They also predict qualities of a product/process and improve their quality.

Motivation for Metrics

Metrics are useful for estimating the cost & schedule of future projects. They are used to evaluate the productivity impacts of new tools and techniques. Moreover, metrics establish productivity trends over time and help to improve software quality. They can forecast future staffing needs and hence it is possible to anticipate and reduce future maintenance needs.

Measure ment Versus Metrics

Software measurement is concerned with deriving a numeric value for an attribute of a software product or process. This allows for objective comparisons between techniques and processes. Although some companies have introduced measurement programmes, most organisations still don’t make systematic use of software measurement. There are few established standards in this area.

Some of the important metrics used in software development life cycle are defect rates and error rates. They are measured by either an individual or by a team during development. Errors can be categorized by their origin, type and cost.

Metrics can be classified into three groups namely products metrics, process metrics and resource metrics. Product metrics are nothing but the explicit results of software development activities. Therefore they contain both deliverables and documentation for each product. Process metrics are measurements used to measure the activities related to production of software. Finally, resource metrics are inputs into the software development activities and include hardware, knowledge and people.

Product and Process Metrics

Process Metrics are useful to improve the quality of software engineering tasks. It includes milestones and leads to long term process improvement. While the process metrics is to improve the methodology, product metrics are useful to improve the end product quality. It assesses the state of the project and tracks the potential risks and helps to uncover problem areas. It also adjusts workflow or tasks and evaluates the development team’s ability to control quality. Moreover, the product metric is a quality metric on product and hence is a predictor of product quality. The classes of product metric include the dynamic metrics which are collected by measurements made of a program in execution, the static metrics which are collected by measurements made of the system representations. Among them, d ynamic metrics help to assess the efficiency and reliability of software. On the other hand, static metrics help to assess the complexity, understandability and maintainability. Software process metrics are useful for control of measurements and also to improve the quality of software products. Based on software process management decision can be made by applying predictor measurements.

Metrics assumptions

The following assumptions are made on metrics

A software property can be measured.
The relationship exists between what can be measured and what is to be known. It is possible to measure internal attributes only in software development. However, developers are often more interested in external software attributes.
This relationship has been formalised and validated.
It may be difficult to relate what can be measured to desirable external quality attributes.

The measure ment process

A software measurement process may be part of a quality control process. Data collected during this process should be maintained as an organisational resource. Once a measurement database has been established, comparisons across projects become possible. In addition to the procedure oriented metrics discussed so far, some object oriented metrics are also used to measure the quality of software. They are depth of inheritance tree, method fan- in / fan-out, weighted methods per class and number of overriding operations.

Object-oriented metrics

Increasingly, object-oriented measurements are being used in the software industry to measure and predict the quality of software. This is supported by empirical results and the theoretical validity of the metrics. The validation of the object oriented metrics requires convincingly demonstrating that (1) the metric measures what it tries to measure and (2) the metric is associated with an important external metric, such as reliability, maintainability and fault-proneness. Often the object oriented metrics have been used as an early indicator of these externally visible attributes, because the externally visible attributes could no t be measures until too late in the software development process.

Metrics for Analysis

In object oriented analysis and design, the Coupling Factor is a metric which is evaluated as a fraction. The numerator represents the number of non-inheritance couplings. The denominator is the maximum number of couplings in a system. The maximum number of couplings includes both inheritance and non- inheritance related coupling. Inheritance-based couplings arise as derived classes (subclasses) inherit methods and attributes form its base class.

Empirical evidence supports the benefits of low coupling between objects. The main arguments are that the stronger the coupling between software artifacts, the more difficult it is to understand individual artifacts, and hence to correctly maintain or enhance them. Moreover, the larger the coupling, the sensitivity of change and defect propagation effects across artifacts also increases and consequently, the more testing required to achieve satisfactory reliability levels. Finally, excessive coupling between objects is detrimental to modular design and prevents reuse. To summarize, low coupling is desirable.

Cohesion refers to how closely the operations in a class are related to each other. Cohesion of a class is the degree to which the local methods are related to the local instance variables in the class. The Chidamber and Kemerer metrics suite examines the Lack of Cohesion, which is the number of disjoint/non- intersection sets of local methods.

Encapsulation

Information hiding is a way of designing routines such that only a subset of the module’s properties, its public interface, are known to users of the module. Information hiding gives rise to encapsulation in object-oriented languages. “Encapsulation means that all that is seen of an object is its interface, namely the operations we can perform on the object. Information hiding is a theoretical technique that indisputably proven its value in practice. Large programs that use information hiding have been found to be easier to modify.

Inheritance

Inheritance decreases complexity by reducing the number of operations and operators, but this abstraction of objects can make maintenance and design difficult. The two metrics used to measure the amount of inheritance are the depth and breadth of the inheritance hierarchy.

Depth of Inheritance Tree

The depth of a class within the inheritance hierarchy is defined as the maximum length from the class node to the root/parent of the class hierarchy tree and is measured by the number of ancestor classes. In cases involving multiple inheritance, the Depth of Inheritance Tree is the maximum length from the node to the root of the tree.

Well structured Object Oriented systems have a forest of classes rather than one large inherita nce lattice. The deeper the class is within the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior and, therefore, more fault-prone. Deeper trees require greater design complexity, since more methods and classes are involved. Indeed, deep hierarchies are also a conceptual integrity concern because it becomes difficult to determine which class to specialize from . Additionally, interface changes within the tree must be reflected throughout the entire class tree and object instances. However, the deeper a particular tree is in a class, the greater potential reuse of inherited methods.

Number of Children

This metric is the number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.

Weighted Methods/Class

It measures the complexity of an individual class. A class with more member functions than its peers is considered to be more complex and therefore more error prone. The larger the number of methods in a class, the greater the potential impact on children since children will inherit all the methods defined in a class. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse. This reasoning indicates that a smaller number of methods is good for usability and reusability.

Summary

Measurement is fundamental to any system for quality enhancement. It needs to be applied in all components of lifecycle. It helps to avoid failures. Object oriented metrics is different from procedure oriented metrics.

Web Links

www.sqa.net/softwarequalitymetrics.html

www.softwaretestinghelp.com/software-test-metrics-and-measurements/

https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Quality/Metrics