Software Metrics “Technical Report”

Hebron, Dura, Main Street

[email protected]

Software Metrics

“T e c h n i c a l R e p o r t ”

By

Anas A. Amro

Submitted To

Dr. Adel Taweel

A report submitted in partial fulfillment of the requirements for

Software Engineering Course

Palestine Polytechnic University

Deanship of Graduate Studies and Scientific Research

Master of Informatics

22 April 2012

Software Metrics Page 2 of 26

Transmittal Letter

Mr. Anas Amro


Palestine, Hebron, Dura

April 22, 2012

Dr. Adel Taweel


Palestine, Hebron

Dear Dr. Adel,

I am submitting to you the report, due April 22, 2012, that you requested. As

partial fulfillment of the Software Engineering course requirement. The report is entitled

“Software Metrics". The content of this report concentrates on the definitions,

understanding report topic...etc. This report also discusses classification software metrics.

If you should have any questions concerning my report please feel free to contact Anas

Amro at [email protected].

Yours sincerely,

Anas Amro Graduate Student

mailto:[email protected]


Abstract

This report has the aspect of software engineering, a software metrics, rather than

in spite of many efforts in this aspect, but that these efforts are limited placements interest

in this aspect. This report contains following parts; Software metrics history, importance

of measurement in software engineering, compare the different metrics that can be used

for measuring software, classification software metrics, the objectives of software

metrics, and its benefits. And will clarify a lot of things on this subject in the report.


Acknowledgment

I would like to express my gratitude to Dr. Adel Taweel, for his advice, support and

encouragement.

I wish to thank warmly the people who through their help and their work.

I must thank most especially to my friends for their help me.


Table of Contents

Transmittal Letter................................................................................................................ 2

Abstract ............................................................................................................................... 3

Acknowledgment ................................................................................................................ 4

Table of Contents ................................................................................................................ 5

Table of Figures .................................................................................................................. 7

Table of Equations .............................................................................................................. 7

Table of Tables ................................................................................................................... 7

1. Introduction ................................................................................................................. 8

2. Background .................................................................................................................. 9

3. Measurement Software importance ............................................................................. 9

4. Motivation of Metrics .................................................................................................. 9

5. Using metrics in software development for E-gov and E-com systems .................... 10

5.1 Internal metrics ................................................................................................... 10

5.2 External metrics.................................................................................................. 10

5.3 Combination between internal and external metrics .......................................... 11

5.4 Future trends ....................................................................................................... 11

6. The Darker Side of Metrics ....................................................................................... 12

7. Classification of Software Metrics ............................................................................ 12

7.1 Product Metrics .................................................................................................. 12

7.1.1 Size Metrics ................................................................................................ 12

7.1.1.1 Lines of Code (LOC) ................................................................................. 13

7.1.1.2 Function Point (FP) .................................................................................... 14

7.1.1.3 Bang ........................................................................................................... 15

7.1.2 Complexity Metrics .................................................................................... 15

7.1.2.1 Cyclomatic Complexity- v(G) ................................................................... 15

7.1.2.2 Information Flow ....................................................................................... 16

7.1.2.3 Knots .......................................................................................................... 17

7.1.3 Halstead’s Product Metrics ......................................................................... 17

7.1.3.1 Program Vocabulary .................................................................................. 17


7.1.3.2 Program Length ......................................................................................... 18

7.1.3.3 Program Volume ........................................................................................ 18

7.1.4 Quality Metrics ........................................................................................... 19

7.1.4.1 Defect Metrics ............................................................................................ 19

7.1.4.2 Reliability Metrics ..................................................................................... 19

7.2 Process Metrics: ................................................................................................. 19

7.2.1 COCOMO II ............................................................................................... 20

7.2.2 Statistical Model ......................................................................................... 20

7.3 Project Metrics: .................................................................................................. 20

8. Metrics Tools ............................................................................................................. 21

8.1 CCCC ................................................................................................................. 21

8.2 JMetric ................................................................................................................ 21

9. Measurement Scales for Software Metrics ................................................................ 21

10. Conclusion ............................................................................................................. 22

11. Additional Resources ............................................................................................. 22

12. References .............................................................................................................. 23

13. Appendices ............................................................................................................. 24

13.1 Example-1 Function Point .................................................................................. 24

13.2 Example-2 Classification of software measurement activities .......................... 26


Table of Figures

Figure (1) What Are Software Metrics ........................................................................ 8

Table of Equations

Equation (1) Cyclomatic Complexity ........................................................................ 16

Equation (2) Information Flow .................................................................................. 16

Equation (3) Halstead's Program Vocabulary ........................................................... 17

Equation (4) Halstead's Program Length ................................................................... 18

Equation (5) Halstead's Program Volume ................................................................. 18

Equation (6) Function Point ...................................................................................... 24

Table of Tables

Table (1) Classification of software measurement activities ..................................... 26


1. Introduction

One of the basic tools of science and engineering is software metrics, and the

increase for demand on E- Government and E-Commerce systems and the large

availability of these systems required a large number of developers and the need of tools

and specifications that is required for code measurement and for quality of code.

Software metrics is one of these tools, and also it is called software products,

these metrics is related with products properties such as its code, strives, and manuals,

and the processes of metrics is focused on system development and check error in order

to maximize the quality of the system.

One of the researcher defines Software Metrics as an “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”. (Goodman, 1993). And Figure (1)

shows what are software metrics.

Figure (1) What Are Software Metrics

Measurement

Based

Techniques

Processes,

Products &

Services

Engineering &

Management

Information

Applied

To

To Supply

To Improve


2. Background

Measurement is describe the number of values that can be assigned to the variable

inside entity that is used to describe the real world, and metrics is an empirical

assignment of values to the entity in order to describe a specific characteristics of entity.

In software development metrics are used to conducting the measurement. (Fenton, 2004)

Measure is the quantitative indication for any extent, or amount, capacity,

dimension, or size of some attribute of a product or service or process, for example find

number of errors in any process or service or any product. (Kan, 2002)

Metric is a quantitative measure for the degree of the system, or component or

process possesses a given attribute. Other researchers have defined the metric is a handle

or guess about a given attribute, and for example find number of errors for per person in

hours expended. (Kan, 2002)

Now we say the “software metrics deals with the measurement of the software product

and the process by which it is developed”. (Mills, 1988)

3. Measurement Software importance

There is no doubt that the process of measuring software, a very important

process, and its importance stems from determine the quality of the current product or

process or any service, also predict qualities of a product, process, service, and improve

quality of a product, process, service in the any software, and assessing the effectiveness

of a testing project, and keeping the current project on track for the developer, also

measuring allows you to quantify your schedule. (Mills, 1988)

4. Motivation of Metrics

We have some of motivation of metrics, including estimation the cost & schedule

of future projects, and evaluation the productivity impacts of new tools and techniques


that uses in the software. Also establish the productivity of trends over time, and improve

software quality, and forecast future staffing needs. Finally, reduce future maintenance

needs. (Mills, 1988)

5. Using metrics in software development for E-government and

E-commerce systems

This section is classified product metrics into internal metrics, and external

metrics and it will provide a brief description for each one, and finally explain advantage

and disadvantage for each type. The section concludes by presenting how these metrics

can be combined and used in software development for E- Government and E-commerce

systems. (Fenton, 2004)

5.1 Internal metrics

Used to measure the attributes of product directly as its own irrespectively

without attention to its behavior, and this category can be classified to three categories;

size, complexity and data metrics. The advantage of this category it is easy to automate

therefor data collection can be made in an easy and effective cost way.

On the other hand the disadvantage of this category, it is difficult to interpret,

which means the internal quantities measured are not clearly related to the external

quality characteristics. (Xenos, 2006)

5.2 External metrics

Used to measure the attribute of the product that can be measured just in the

actual environment of the product, there are four factors that affect software quality; these

factors are Functionality, Usability, Efficiency and Reliability. And the external metrics

is used to measure these factors or when it is combined.


The advantage of external metrics is representing in term of measure directly the

desired external product quality characteristics, and it is so attention to user satisfaction.

On the other hand the disadvantage of external metrics it is not objectively and required

additional effort to ensure the objectivity of it, and it is not cost effective and it is difficult

to conduct measurements due to high error. (Xenos, 2006)

5.3 Combination between internal and external metrics

For any product we want to develop we should prepare and determine the

required and appropriate available metrics “internal and, external” under which called

“quality manual”, In order to ensure the quality of the product and the ability to reduce

number of error under alpha test and beta test of the product.

5.4 Future trends

Software metrics “internal, and external” for the estimation of product related

issues (such as product size, required effort, time required for testing), the benefits from

the use of metrics are not commonly recognized. This is partly due to the lack of

awareness of metrics in small and medium size software developing companies.

More and more small and medium size E-Government and E-Commerce software

developing companies become aware of product metrics and measurements.

Another issues for the future of metrics is used and development another tools and

sophisticated, and increasing the number of available measurement tools in order to

increase the quality of software products, although combining metrics with decision

support tools for resolving uncertainty will lead to the development of valuable tools,

which can aid towards higher quality software. (Xenos, 2006)


6. The Darker Side of Metrics

During a long time of using software metrics, it provide advantage to the systems and

enable a high quality, but on the other hand it have a darker side that is represented in a

different sides, firstly; relationship between the metrics and what we want to measure,

this problem is results from fact that the measures we are taking are based on models and

assumptions about system and organizational behavior that are naïve at best. Second; the

over-powering side effects from the measurement programs. (Douglas, 2000)

7. Classification of Software Metrics

Software Metrics have many classification, the common classification, and divides

software metrics to three categories (Mills, 1988):

7.1 Product Metrics

This category describes the characteristics of the product, and other factors, for

example, efficiency, reliability, reusability, performance, and portability, etc. In this

category may measure the complexity of the software design, and size of final

documentation for the any project, or number of pages of any documentation.

7.1.1 Size Metrics

Measure the size of the project is essential to estimate the time required to complete a

specific project, and also the effort required for that, there are three important metrics to

measure size:

Lines of Code

Function Count (Point)

Bangs


7.1.1.1 Lines of Code (LOC)

The simplest way to measure the size of the problem is the LOC and this

measurement is very popular in the first place, so that it is simple to use, this

measurement measures the number of source instructions required to solve the problem.

While counting the number of source instructions, the commenting and black lines

that using lines are ignored. Moreover, LOC as a measure using to measure the problem

size has several weaknesses or limitations (Mills, 1988):

Measure the lines of code count at the end of a project is very simple and

easy, and measure at the beginning of a project is very hard and trickier. So to

measure the lines of code in the beginning of a project, we divided the

problems into modules by project managers, and each module into sub

modules, the dividing of operation continue until the lines of code can be

predicted.

A line of code gives sometimes a numeric value or number of the problem

size of the software.

Lines of code focuses on the coding activity, and ignoring the relative

complexity of design, testing. Some problems might be a very complex in the

design or in Lines of code we have some of units of measure, for example

(KLOC), Kilo Lines of code,, but the coding for this is very simple and easy.

In Lines of code we have some of units of measure, for example (KLOC), Kilo Lines

of code, And in the result line of code measure the number of lines in the source code of

the software, but excluding any comments and other black lines in the whole software.

(Pfleeher, Fenton, 1997), and includes all lines containing program headers, declarations,

and executable and non-executable statements. However Lines of code is the most widely

used software size metrics and easy to use, easy to compute, and also language and

programmer dependent. (Hareton & Zhang, 2003)


7.1.1.2 Function Point (FP)

Function point that is the functionality of measure from user point of view, and the

basic operation in this measure is what the user request and he receives in return or output

from the system, and also the function point used to measure functional units, and to

measure and therefore has been divided into two category (Hareton & Zhang, 2003) :

Data function types

- Internal Logical Files (ILF): Is a set of metadata related to the user's

logical with the system.

- External Logical Files (ELF): Is a set of metadata related to the user's

logical, but maintained within another system.

Transaction function types

- External Input (EI): this is the processed information that comes from

the outside and inputted to the system.

- External Output (EO): this is the processed information that comes

from the outside or inside to outside.

- External Inquiry (EQ): this is the processed information that comes

from the outside or inside to outside according to the information that

required by the any user.

The function point metric can be used as a means for predicting the size of a system

(derived from the analysis model), the function point metric is difficult and complex in

using because we has one must identify all for the parameters in the software product.

In Appendix, there is an example (Example 1) show the functionality by using

function point.


7.1.1.3 Bang

The bang metric was described firstly by DeMarco (DeMarco, 1982), and this metric

can attempt to measure the size of many projects but based on the functionality of the

system that detected during the time of design.

Bang used to predict the application size based on the analysis mode, the software

engineer first evaluates a set of primitives available at the analysis model, with the

evaluation of these primitives, software can be defined as either function-strong or data-

strong.

Once the bang metric is computed, past history must be used to predict software size

and effort (Mills, 1988).

7.1.2 Complexity Metrics

The following metrics focuses on the measurement of the complexity of the

executable code within procedures. Complexity is often positively correlated to code size,

measure of complexity that can be computer early in the software development cycle, and

will be greater value in software process; there are some of complexity metrics, such as:

Cyclomatic Complexity –v(G)

Information Flow

Knots

7.1.2.1 Cyclomatic Complexity- v(G)

The Cyclomatic Complexity was described firstly by McCabe, and might suggest

seeing the any program as a graph, then we finding out the all of expected number or

different paths through it.

When the program become very large, the complexity become very large too,

sometimes we refer the cyclomatic Number by v(G), now we can say the v(G) is a set of


independent paths through the graph used as a measure of program complexity, and the

(Equation 1) shows the v(G) in any program. (McCabe, 1976)

( )

Equation (1) Cyclomatic Complexity

Where:

- v(G) =Cyclomatic Complexity

- e = number of edges

- n = number of nodes in the graph

7.1.2.2 Information Flow

Information flow is a metric using to measure the complexity in the software, or

product. The information flow was appeared for the first time by Kafura and Henry

(Kafura & Reddy, 1987). This technique worked on identifying the number of calls to a

module, and the flow in the local information entering is called fan-in, but the technique

that identifying the number of calls from a module, and the flows of local information

leaving is called fan-out, however the complexity in information flow metric is

determined by equation(2). (Mills, 1988)

[ ] [ ]

Equation (2) Information Flow

Where:

- c = complexity of the module

- procedure length = a length of the module, this value could be given in LOC

or by using v(G) Cyclomatic Complexity, I explained that on the previous

page above.

- fan-in = The number of calls to the module.

- fan-out = The number of calls from the module.


7.1.2.3 Knots

"The knots are related to drawing the program control flow graph with a node for

every statement or block of sequential statements" (Mills, 1988). In knots must be

defined as a necessary crossing of directional lines in the graph for the program, finally

the number of knots in the module or produce or in the program is used is important to

measure the program complexity.

7.1.3 Halstead’s Product Metrics

In this section we talk about one of the product metrics, is called halstead's product

metrics, this proposed a unified set of metrics that apply to several aspects of program or

product. And in this section we discuss some of categories for this, such as (Mills, 1988):

Program Vocabulary (n)

Program Length (N)

Program Volume (V)

And all of this metrics used for computing the total effort and calculated development

time for any software product, and measured the complexity of software program by

counting the number of operator and operands.

7.1.3.1 Program Vocabulary

The program vocabulary means is the summation the unique operators and unique

operands, that defined in equation (3).

Equation (3) Halstead's Program Vocabulary

Where:

- n = program vocabulary

- n1 = number of unique operators

- n2 = number of unique operands


7.1.3.2 Program Length

The program length means is the summation the all operators and all operands, that

appearing in the implementation, and that defined in equation (4).

Equation (4) Halstead's Program Length

Where:

- N = program length

- N1 = all operators appearing in the implementation

- N2 = all operands appearing in the implementation

7.1.3.3 Program Volume

The program volume can be defined the size of the program and program length times

the logarithm on base two; the equation (5) shows that.

Equation (5) Halstead's Program Volume

Where:

- V = program volume

- N = program length (see equation 4)

- n = program vocabulary (see equation 3)


7.1.4 Quality Metrics

The quality metrics uses during the test or maintenance phase of the software

engineering, now we talk about two of the quality metrics (Mills, 1988):

Defect Metrics

Reliability Metrics

7.1.4.1 Defect Metrics

Defect metrics that help to find the number of defect found in order to have a record

of the number of changing in design phase, and the number of errors catches or detected

by code inspection, all of errors happens during integration testing, it is important to the

number of code changes, and the number of enhancements suggested to the system.

7.1.4.2 Reliability Metrics

In this metrics, we can use statistical methods applied to information obtaining during

development phase, or sometimes in maintenance phase of software engineering,

however we can estimate and predict the reliability of the software product, and

estimating form data collected on software defects as a function of time.

7.2 Process Metrics:

This category of software metrics describes the characteristics of the processes used

to develop the software product, for example for this, number of error found during

testing the software product, also time, and effort, etc. So process metrics used to

measures type of methodology that used in software development process, on the other

hand measure the average level of experience of the programming staff.


There are many of these metrics:

General Considerations

Empirical, Statistical, Theory-Based, Composite, Rayleigh, Reliability Models

COCOMO II

But we will describe two of them:

COCOMO II

Statistical Models

7.2.1 COCOMO II

COCOMO II is a new version of the COCOMO, and stands for Constructive Cost

Model for software effort, also used to determined effort, cost, and schedule estimation.

In COCOMO the code-size is given in thousand line of code and effort is in person-

month, and it provides three levels of models: basic, intermediate, and detailed.

7.2.2 Statistical Model

This is another approach to determine software effort, and using some equations to

calculate this effort for any software process.

7.3 Project Metrics:

This category describes the characteristics of the project in the software engineering,

for example for this category is number of software developers or programmers,

schedule, and cost, etc.


8. Metrics Tools

8.1 CCCC

This is a metric analyzer C, C++, Java, founded by Tim Littlefair. This metric

calculated Line of Code, Cyclomatic, and others of metrics, CCCC Generates HTML and

XML reports, and freely available version.

8.2 JMetric

This is the Object Oriented metric calculation tool, for Java code, and founded by

Cain and Vesa, The JMetric requires Java any version or JDK tools, and JMetric

measures Line of Code a Cyclomatic complexity.

9. Measurement Scales for Software Metrics

The data in software metrics should be collected with a specific purpose in mind;

there are four basic types of measured data:

Nominal

Ordinal

Interval

Ratio

Absolute


10. Conclusion

Software metrics is an important topic, and can be used to measure various factors

related to software product development, also are used to improve the process of

developing software and to improve all aspects of the management of that process.

Software metrics are applicable to the whole development life cycle from initiation, to

termination.

11. Additional Resources

Available for people interested and wanting additional information about software

metrics available on the following books: (Pfleeher, Fenton, 1997), (Kitchenham, 1996),

(Ian Sommerville,Addison-Wesley, 2001) (S.Pressman, 2001).


12. References

[1] DeMarco, T. (1982). Controlling Software Projects: Managemnet, Measurement

& Estimation. New York: Yourdon Press.

[2] Douglas, H. (2000). The Darker Side of Metrics. 1-8.

[3] Fenton, P. (2004). Software Metrics. A Rigorous & Practical Approach.

[4] Goodman, P. (1993). Practical Implementation of Software Metrics.

[5] Hareton, L., & Zhang, F. (2003). Software Cost Estimation. 3-5.

[6] Ian Sommerville,Addison-Wesley. (2001). Software Engineering. Practice Hall.

[7] Kafura, D., & Reddy, G. R. (1987). The Use of Software Complexity Metrics in

Software Maintenance. IEEE Trans. Software Eng. SE-13.3.

[8] Kan, S. (2002). Metrics and Models in Software Quality Engineering (2nd

Edition ed.). Addison Wesley Professional.

[9] Kitchenham, B. (1996). Software Metrics: Measurement for Software Process

Improvement. NCC Blackwell: Prentice-Hall.

[10] McCabe, T. (1976). A Complexity Measure. New York: Software Eng. SE-2 (4).

[11] Mills, E. E. (1988, December). Software Metrics. Curriculum Module, 3-15.

[12] Pfleeher, Fenton. (1997). Software Metrics: A Rigourous and Practical

Approach. Boston: MA: PWS Kent.

[13] S.Pressman, R. (2001). Software Engineering (5th ed.). Mc-Graw-Hill.

[14] Xenos, M. (2006). Software Metrics and Measurements. 1-5.


13. Appendices

13.1 Example-1 Function Point

[ ∑ ]

Equation (6) Function Point

Where:

- FP = Total number of adjusted function points

- Count Total the sum of all user inputs, outputs, inquiries, files and external

interfaces to which have been applied the weighting factor.

- Fi a complexity adjustment value.

Weighting Factor

Measurement Parameter Count Simple average complex total

number of user inputs 3 X 3 4 6 =9

number of user outputs 2 X 4 5 7 =8

number of user inquiries 2 X 3 4 6 =6

number of files 1 X 7 10 15 =7

number of external interfaces 4 X 5 7 10 =20

Count Total 50


Example-1 Function Point (Cont...)


13.2 Example-2 Classification of software measurement activities

ENTITIES ATTRIBUTES

Internal External

Products

Specifications size, reuse, modularity, redundancy,

functionality, syntactic correctness,

comprehensibility,

maintainability, ...

Designs

size, reuse, modularity, coupling,

cohesiveness, inheritance,

functionality, ...

quality, complexity,

maintainability, ...

Code

size, reuse, modularity, coupling,

functionality, algorithmic

complexity,

reliability, usability,

maintainability,

reusability

Test data control-flow structuredness, ...

size, coverage level, ... quality, reusability, …

Processes

Constructing

Specification

time, effort, number of

requirements changes quality, cost, stability, ...

Detailed design

time, effort, number of specification

faults

found,

cost, cost-effectiveness, ...

Testing time effort, number of coding faults

found

cost, cost-effectiveness,

stability,

Resources

Personnel age, price productivity, experience,

intelligence

Teams size, communication level,

structuredness productivity, quality

Organizations size, ISO Certification, CMM level Maturity, profitability

Software price, size usability, reliability

Hardware price, speed, memory size ... reliability

Offices size, temperature, light comfort, quality

Table (1) Classification of software measurement activities

Documents

Software Metrics “Technical Report”