Your SlideShare is downloading. ×
0
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Complexity metrics and models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Complexity metrics and models

1,620

Published on

Software Quality Management …

Software Quality Management
Anna University Syllabus
B.E. IV CSE
About Complexity Metrics and Models

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,620
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
118
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Quality Management  Unit – IV  G. Roy Antony Arnold  Asst. Prof. / CSE
  • 2. • The li h lines of code ( OC) count i usually f f d (LOC) is ll for executable statements.• LOC count represents the program size and complexity, it is not a surprise that .• More recent studies point to a curvilinear relationship between lines of code and defect rate:
  • 3. Maximum Source  Average Defect perLines of Modules 1,000 Source Lines 63 1.5 100 1.4 158 0.9 251 0.5 398 1.1 630 1.9 1000 1.3 >1000 1.4
  • 4. • Wh When module size b d l i becomes very l large, the h complexity increases to a level beyond a programmer s programmers immediate span of control and total comprehension.• The curvilinear model between size and defect density sheds new light on software quality engineering. It implies that there may be an g g p y optimal program size that can lead to the lowest defect rate.• Such an optimum may depend on language, project, product, and environment; apparently many more empirical i i i l investigations are needed. ti ti d d
  • 5. • Halstead (1977) distinguishes software science from computer science.• The premise of software science is that any programming task consists of selecting and arranging a finite number of program “tokens”, which are tokens .• A computer program, according to software di f science, .
  • 6. • Th primitive measures of H l t d software science The i iti f Halsteads ft i are• Based on these primitive measures, Halstead developed a system of equations expressing and other features such as development effort and the projected number of faults in the software.
  • 7. Vocabulary, Length, Length,Volume, Level, Difficulty, DifficultyEffort, Faults, 
  • 8. • The measurement of cyclomatic complexity b h f l i l i by McCabe (1976) was designed (maintainability).• It is the classical graph theory cyclomatic number, .• To determine the paths, the program procedure is represented .
  • 9. • The general formula to compute cyclomatic p y complexity is:• Wh Where, V(G) – Cyclomatic Number of G ( ) y e – Number of edges n – Number of nodes n Number of nodes p – Number of unconnected parts of the graph
  • 10. • 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 graphs  additive The complexity of several graphs considered as a group is equal to the sum  g p p of the individual graphs complexities.
  • 11. needing detailed inspections. g p likely to have a low defect rate and therefore have a low defect rate and thereforecandidates for development without detailed inspections. l , identify troublesome code, and estimate testing effort.estimate testing effort
  • 12. • McCabes cyclomatic complexity index is a .• It does not distinguish different kinds of control flow complexity such as p y .• In studying the quality and syntactic indicators among a sample of twenty modules of a COBOL compiler product product, found that at the module level can be estimated through the following equations:
  • 13. • Lo found that most developers were having difficulty  p g y mastering 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.
  • 14. • St t Structure metrics try to take into account the  ti t t t k i t t th .• The most common design structure metrics  are the  are the , which are  which are based on the  proposed by  (1979) and  (1978): A count of the modules that call a given  module : A count of modules that are called by a  given module given module
  • 15. • 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 Seligs work (1990) defines a hybrid form  of their information‐flow metric as of their information flow metric as where, C internal complexity of procedure p where, Cip – internal complexity of procedure p
  • 16. • C d d Gl (1990) d l Card and Glass (1990) developed a system complexity model d t l it d l Ct – System Complexity St – Structural (intermodule) System Complexity, S Structural (intermodule)  complexity, Dt – Data (intermodule) complexity• They defined relative system complexity as n – no. Of modules in the system• S Structure complexity is further defined as l i i f h d fi d S= ∑ f 2 (i ) n Where S – Structural Complexity, f(i) – Fan‐out of Module i,       n – no. Of modules in the system
  • 17. • D t C Data Complexity is further defined as l it i f th d fi d Di  Data Complexity of Module i, V(i)  I/O  Di – 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

×