Complexity metrics and models

19
Software Quality Management Unit – IV G. Roy Antony Arnold Asst. Prof. / CSE

description

Anna University, Final CSE, Software Quality Management

Transcript of Complexity metrics and models

Page 1: Complexity metrics and models

Software Quality Management Unit – IV 

G. Roy Antony Arnold Asst. Prof. / CSE

Page 2: Complexity metrics and models

h li f d ( OC) i ll f• The lines of code (LOC) count is usually forexecutable statements.

• LOC count represents the program size andcomplexity, it is not a surprise that

.• More recent studies point to a curvilinearrelationship between lines of code and defectrate:

Page 3: Complexity metrics and models
Page 4: Complexity metrics and models

Maximum Source Lines of Modules

Average Defect per1,000 Source Lines

63 1.5100 1.4158 0.9251 0.5398 1.1630 1.91000 1.3>1000 1.4

Page 5: Complexity metrics and models

Wh d l i b l h• When module size becomes very large, thecomplexity increases to a level beyond aprogrammer's immediate span of control and totalprogrammer s immediate span of control and totalcomprehension.

• The curvilinear model between size and defectThe curvilinear model between size and defectdensity sheds new light on software qualityengineering. It implies that there may be ang g p yoptimal program size that can lead to the lowestdefect rate.

• Such an optimum may depend on language,project, product, and environment; apparently

i i l i ti ti d dmany more empirical investigations are needed.

Page 6: Complexity metrics and models

• Halstead (1977) distinguishes softwarescience from computer science.

• The premise of software science is that anyprogramming task consists of selecting andprogramming task consists of selecting andarranging a finite number of program“tokens” which aretokens , which are

.di f• A computer program, according to software

science,.

Page 7: Complexity metrics and models

Th i iti f H l t d' ft i• The primitive measures of Halstead's software scienceare

• Based on these primitive measures, Halsteaddeveloped a system of equations expressing

and otherfeatures such as development effort and the projectednumber of faults in the software.

Page 8: Complexity metrics and models

Vocabulary, Length,Length, Volume, Level, DifficultyDifficulty, Effort, Faults, 

Page 9: Complexity metrics and models

h f l i l i b• The measurement of cyclomatic complexity byMcCabe (1976) was designed

(maintainability).• It is the classical graph theory cyclomaticnumber,

.• To determine the paths, the programprocedure is represented

.

Page 10: Complexity metrics and models

• The general formula to compute cyclomaticcomplexity is:p y

Wh• Where,V(G) – Cyclomatic Number of G( ) ye – Number of edgesn Number of nodesn – Number of nodesp – Number of unconnected parts of the graph

Page 11: Complexity metrics and models

• If we count the edges, nodes, and disconnected parts of the graph, 

• The iteration test in a looping statement is• The iteration test in a looping statement is counted as one binary decision. In the preceding simple example, since there are two binary decisions, M = 2 + 1 = 3

• The cyclomatic complexity metric is additive The complexity of several graphsadditive. The complexity of several graphs considered as a group is equal to the sum of the individual graphs' complexities.g p p

Page 12: Complexity metrics and models
Page 13: Complexity metrics and models

needing detailed inspections.g plikely to 

have a low defect rate and thereforehave a low defect rate and therefore candidates for development without 

ldetailed inspections.

, identify troublesome code, and estimate testing effortestimate testing effort.

Page 14: Complexity metrics and models

• McCabe's cyclomatic complexity index is a.

• It does not distinguish different kinds of controlflow complexity such asp y

.• In studying the quality and syntactic indicatorsIn studying the quality and syntactic indicatorsamong a sample of twenty modules of a COBOLcompiler product found thatcompiler product, found that

at the module level can be estimatedthrough the following equations:through the following equations:

Page 15: Complexity metrics and models

• Lo found that most developers were having difficulty p g ymastering the DO WHILE construct.

• As a result, minimizing the use of DO WHILE was one of the actions the team took to reduce defects in the compiler product.

Page 16: Complexity metrics and models

St t t i t t t k i t t th• Structure metrics try to take into account the 

.• The most common design structure metrics are the which areare the  , which are based on the  proposed by 

(1979) and (1978):

A count of the modules that call a given modulemodule

: A count of modules that are called by a given modulegiven module

Page 17: Complexity metrics and models

I l d l ith l f i• In general, modules with a large fan‐in are 

. • In contrast, modules that are large and complex are likely to have a small fan‐in.

structure complexity is defined as:

• Henry and Selig's work (1990) defines a hybrid form of their information‐flow metric asof their information flow metric as

where, Cip – internal complexity of procedure pwhere, Cip internal complexity of procedure p

Page 18: Complexity metrics and models

C d d Gl (1990) d l d t l it d l• Card and Glass (1990) developed a system complexity model

C – System Complexity S – Structural (intermodule)Ct – System Complexity, St – Structural (intermodule) complexity, Dt – Data (intermodule) complexity

• They defined relative system complexity as

n – no. Of modules in the systemS l i i f h d fi d• Structure complexity is further defined as

ifS ∑= )(2

Where S – Structural Complexity, f(i) – Fan‐out of Module i,      

n

n – no. Of modules in the system

Page 19: Complexity metrics and models

D t C l it i f th d fi d• Data Complexity is further defined as

Di – Data Complexity of Module i, V(i) – I/ODi  Data Complexity of Module i, V(i)  I/O Variables in module i, f(i) – fan‐out of module i

D – Data (intramodule) Complexity, D(i) – Data Complexity of module i, n = Number of new modules in the system