Cyclomatic Complexity

CYCLOMATIC COMPLEXITY

Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of the basis parthu testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program, and provides as with an upper bond for the number of tests that must be conducted to ensure that all statements have been executed at least once.

An independent path must move along at least one edge that has not been traversed before the path is defined.

Function Point Based Measures

FUNCTION POINT BASED MEASURES Function Point

Function points and feature points are “methods of estimating the “amount of functionality” required for a program, and are thus used to estimate project completion time. The basic idea involves counting inputs, outputs, and other features of a description of functionality.

Function Point Metric

Function point metric was proposed by Allan. Albrecht (1983), when he worked for IBM. Function oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Since functionality cannot be measured directly, it must be derived indirectly using other direct measures. Function points are derived using an empirical relationship based on direct measures of software’s information domain and assessments of software complexity.

Function points are computed by completing Table given below :

Table: Function Point Contribution of an Element

Function type Simple Average Complex
External input 3 4
External output 4 5 7
Logical internal file 7 10 15
External interface file 5 7 10
External inquiry 3 4 6

 

The different function types mentioned in Table are discussed as under :

  • External output types are transactions where data is output to user. Typically these would be printed reports.
  • External interface file types allow for output and input that might pass to and from other computer application.
  • External types are input :transactions that update internal computer files.
  • External inquiry types note US spelling of inquiry- are transactions initiated by the user that provide information but do not update the internal files. The inputs some information that directs the system to the details required.
  • Logical internal file types are the standing files used by the system. The term `file’ does not sit easily with modern information systems. It refers to a group of data that is usually accessed together. It might be made up of one or more record

Special Features

  • Function points can be estimated from requirement specification or design specifications, thus making it possible to estimate development effort in early phases of development.
  • Function point approach is independent of the language, tools or methodologies used for implementation; e., they do not take into consideration programming languages, database management systems, processing hardware or any other database technology.
  • Function points are directly linked to the statement of requirements; any change of requirements can easily be followed by are-estimate.
  • Function points are based on the system user’s external view of the system; non-technical users of the software system have a better understanding of what function points are measuring.

Advantages of Function Points

  • The necessary data is available early in a project and thus only a detailed specification is needed.
  • It is not restricted to code.
  • More accurate than estimated LOC
  • It is language independent
  • It can be used to easily estimate the size of a software product directly from the problem specification.

Drawbacks of Function Points

  • Hard to automate and difficult to compute
  • Oriented to traditional data processing applications
  • Subjective counting-different people can come up with different estimates for the problem.
  • Ignores quality of output.

Feature Point Metrics

A function point extension called feature points is a superset of the function point measure that can be applied to systems and engineering software applications. Therefore, its size should be larger compared to simpler functions.

  • Proponents of function point and feature point metrics claim that these metrics are language-independent and can be easily computed from the SRS document during project planning, whereas opponents claim that these metrics are subjective and require a sleight of hand. An example of the subjective nature of the function point metric can be that the way one would group logically related data items could be very subjective. For example if a data employee-details consists of the employee name and his address, one person can consider it a single unit of data while someone else can consider the address as one unit and name as another. Therefore, different engineers can arrive at different function point measures for the same problem.

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.