Software Metrics 2

8/10/2019 Software Metrics 2

1/83

Software MetricsHow do we measure the software?


2/83

To understand the importance of measurement

To describe and compare the different metrics

a can e use or measur ng so ware To understand the important factors that affect

the measurement of software


3/83

Scientific Accuracy

Repeatable

Quality


4/83

Software Metrics: What and Why ?

1. How to measure the size of a software?

.

3. How many bugs can we expect?

4. When can we stop testing?

5. When can we release the software?


5/83

6. What is the complexity of a module?

7. What is the module strength and coupling?

.

9. Which test technique is more effective?

10. Are we testing hard or are we testing smart?

11. Do we have a strong program or a week test suite?


6/83

To indicate the quality of the product

To assess the productivity of the people who producee pro uc To assess the benefits derived from new software

To form a baseline for estimation

training


7/83

easure - quan a ve n ca on o ex en , amoun ,dimension, capacity, or size of some attribute of a product or process. E.g., Number of errors

easuremen - e ac o e erm n ng a measure

- ,component or process possesses a given attribute. A handle

or guess about a given attribute. .g., um er o errors oun per person ours expen e


8/83

Estimate the cost & schedule of future projects

va ua e e pro uc v y mpac s o new oo s an ec n ques

Establish roductivit trends over time

Improve software quality

Forecast future staffing needs

Anticipate and reduce future maintenance needs


9/83

reas o pp ca ons

The most established area of software metrics is cost and sizeestimation techniques.

The rediction of ualit levels for software often in terms of

reliability, is another area where software metrics have an importantrole to play.

The use of software metrics to provide quantitative checks on

software design is also a well established area.


10/83

Software Metrics

i. Product metrics : describe the characteristics of the product such as

, , , , ,reliability, portability, etc.

.processes that produce the software product. Examples are:

time to produce the product

effectiveness of defect removal during development

number of defects found during testing maturity of the process


11/83

.

execution. Examples are :

number of software developers

s a ng pa ern over e e cyc e o e so ware

cost and schedule

productivity


12/83

Direct Measures (internal attributes)

Cost, effort, LOC, speed, memory

Indirect Measures (external attributes) , , , , ,

maintainability

Example: length of a pipe is a direct measure.the quality of the pipes can only be measured indirectly

b findin the ratio of the acce ted i es to the re ected.


13/83

Size Oriented Metrics


14/83

Based on the size of the software produced.

Project data measured, including cost and effort, pages,defectsetc.

Mainly uses the LOC as the normalization value.

Advantages: easily counted, large body of literature and databased on LOC

Disadvantages: language dependent, programmer dependent.

Useful for projects with similar environment.

ere ore, s ze-or en e me r cs are no un versa y accep eas the best way to measure the software process.


15/83

- Size of the software produced

- nes o e KLOC - 1000 Lines Of Code

Typical Measures:

Defects/KLOC

Cost/LOC Documentation Pages/KLOC


16/83

project effort cost kLOC Doc. errors people person-month)

pgs

Proj_1 24 168,000 12.1 365 29 3

Proj_2 62 440,000 27.2 1224 86 5


17/83

-

= kLOC / person-month

Quality = Errors / Size= rrors Cost = $ / kLOC Documentation = a es / kLOC

Other metrics can also be developed like: errors/KLOC,page/KLOC...etc. - -, , .


18/83

Function Oriented Metrics


19/83

- Based on functionality delivered by the software as the

normalization value.

Functionality is measured indirectly

Function points (FP) measure- derived using an empiricalrelationshi based on countable direct measures ofsoftwares information domain and assessments of softwarecomplexity

Alan Albrecht while working for IBM, recognized the problem in sizemeasurement in the 1970s, and developed a technique (which he called

,measurement problem.


20/83

system is decomposed into functional units.

Outputs : information leaving the system

re orts, screens, error messa es

Enquiries : requests for instant access toinformation e.g. an on-line input that

output response

Internal logical files: information held within thesys emExternal interface files : information held by other system

analyzed.


21/83

1. Count the information domain values.. ssess e comp ex y o e va ues.3. Calculate the raw FP (see next table).

4. Rate the complexity factors to produce thecom lexit ad ustment value CAVCAV = iF i = 1 to 14

.FP = raw FP x [0.65 + 0.01 x CAV]


22/83

oun ng unc on po n s

Functional Units

Low Average Highx erna npu s

External Output (EO) 4 5 7External Inquiries (EQ) 3 4 6

External logical files (ILF) 7 10 15External Interface files (EIF) 5 7 10

a e : unct ona un ts w t we g t ng actors


23/83

Table 2: UFP calculation table

CountCom lexit

ComplexityTotals

FunctionalUnits

Functional

Low x 3 Average x 4High x 6

===

ExternalInputs(EIs)

===


ExternalOutputs(EOs)

===


ExternalInquiries(EQs)

===


ExternallogicalFiles (ILFs)

===


ExternalInterfaceFiles (EIFs)

Total Unadjusted Function Point Count


24/83

The weighting factors are identified for all functional units and

multiplied with the functional units accordingly. The procedure for e ca cu a on o na us e unc on o n s g ven ntable shown above.


25/83

The procedure for the calculation of UFP in mathematical form is givenbelow:

= w Z UFP= =1 1i J

w u

Wij : It is the entry of the ith

row and jth

column of the table 1Zij : It is the count of the number of functional units of Type i thathave been classified as having the complexity corresponding toco umn .


26/83

Organizations that use function point methods develop a criterionfor determinin whether a articular entr is Low, Avera e or Hi h.Nonetheless, the determination of complexity is somewhatsubjective.

FP = UFP * CAF

Where CAF is complexity adjustment factor and is equal to [0.65 +0.01 x F . The F i=1 to 14 are the de ree of influence and arebased on responses to questions given in next slide


27/83

,

on a scale of 0 to 5

0 - No influence-

2 - Moderate-

4 - Significant


28/83

i

.2. Are data communications required?

3. Are there distributed rocessin functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational

env ronmen6. Does the system require on-line data entry?

-.over multiple screens or operations?

8. Are the master files updated on-line?9. Are the inputs, outputs, files, or inquiries complex?


29/83

10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in the design?

.organizations?

14. Is the application designed to facilitate change and ease of use bythe user?


30/83

The rating for all the factors, F 1 to F 14, are summed to

produce the complexity adjustment value (CAV)

CAV is then used in the calculation of the function point (FP)of the software


31/83

-

Productivity = Functionality / Effort= FP / erson-month

Quality = Errors / Functionality= Errors / FP

Cost = $ / FP Documentation = pages / FP


32/83

Advantages: language independent, based on data known

early in project, good for estimation

Disadvantages: calculation complexity, subjectiveassessments, FP has no h sical meanin ust a number


33/83

Feature points

applied to systems and engineering software. nc u es assessmen or comp ex a gor ms.

applied to real-time systems and engineered products (by

Boein integrates data dimension (normal FP) with functional and

control dimensions


34/83


35/83

Programming Language

Assembly Language

LOC/FP (average)

320CCobol

128105

or ranPascal 90

Object-oriented language

-

30

Code generators 15


36/83

Halsteads Software Metrics


37/83

Halsteads Software Science

o en oun

The size of the vocabular of a ro ram which consists of thenumber of unique tokens used to build a program is defined as:

= 1+

2

: vocabulary of a program

1

: number of unique operators

where

2 : number of unique operands


38/83

The length of the program in the terms of the total number of tokensused is

N = N +N

N : program lengthwhere

N1 : total occurrences of operators

2


39/83

V = N * l o g2 The unit of measurement of volume is the common unit for sizebits. It is the actual size of a program if a uniform binary encodingfor the vocabulary is used.

L = V* / VThe value of L ranges between zero and one, with L=1representing a program written at the highest possible level (i.e.,

.


40/83


41/83


42/83

122221 log += Log B

2211 += c

2/)log( =

, ,total operands are not specifically delineated.


43/83


44/83

5. Local variables with the same name in different functions arecounted as unique operands.

6. Functions calls are considered as operators.

7. All looping statements e.g., do {} while ( ), while ( ) {}, for ( ){}, all control statements e.g., if ( ) {}, if ( ) {} else {}, etc..

8. In control construct switch ( ) {case:}, switch as well as all thecase statements are considered as operators.


45/83

9. The reserve words like return, default, continue, break, sizeof,

etc., are considered as operators.10. All the brackets, commas, and terminators are considered as

11. GOTO is counted as an operator and the label is counted as an.

12. The unar and binar occurrence of + and - are dealtseparately. Similarly * (multiplication operator) are dealtseparately.


46/83

13. In the array variables such as array-name [index] array-name and index are considered as operands and [ ] is

14. In the structure variables such as struct-name, member-name

.

or struct-name -> member-name, struct-name, member-nameare taken as operands and ., -> are taken as operators. Some

counted as unique operands.

15. All the hash directive are ignored.


47/83

*

2(lo2(***

++=V

un que npu an ou pu parame ers2

Estimated Program Level / Difficulty

Halstead offered an alternate formula that estimate the programlevel.

)/(2 212 =

L

where

211 ==

22

L


48/83


49/83

V LV L2

* ==

Using this formula, Halstead and other researchers determined thelanguage level for various languages as shown below.


50/83


51/83

Measures


52/83


53/83

Sequence

If-then-else Until


54/83

raw t e contro ow grap o t e co e Count the number of edges = E

= Count the number of connected

components = P Complexity = E N + 2P


55/83

2


56/83

= V(G) = 9 7 + 2 = 4

V(G) = 3 + 1 = 4

as s e 1, 7 , , , ,

1, 2, 3, 4, 5, 2, 6, 1, 7 , , , , , , ,


57/83

9

4

2

65

7

What is V(G)?


58/83

s e num er o enc ose reg ons areas o e p anargraph

Number of regions increases with the number of decisionpaths and loops

A quantitative measure of testing difficulty and an indication ofultimate reliabilit

Experimental data shows value of V(G) should be no moreen - es ng s very cu y a ove s va ue


59/83

CK Metrics


60/83

e r cs: ec veCK metrics were designed:

To measure unique aspects of the OO approach.

To measure complexity of the design.

To improve the development of the software


61/83

Chidamber and Kemerer (CK) metric suite

consists of six metrics weighted methods per class (WMC), cou lin between ob ects CBO

depth of inheritance tree (DIT), response for a class (RFC),

.


62/83


63/83

DIT is the maximum length from a node to

the root base class

ewpo n s: Lower level subclasses inherit a number of methods

making behavior harder to predict Deeper trees indicate greater design complexity


64/83

s e num er o su c asses mme a e y

subordinate to a class

Viewpoints: As NOC rows reuse increases - but the abstraction ma be diluted

Depth is generally better than breadth in class hierarchy, since itromotes reuse of methods throu h inheritance

Classes higher up in the hierarchy should have more sub-classes

then those lower down NOC gives an idea of the potential influence a class has on the

desi n : classes with lar e number of children ma re uire moretesting


65/83


66/83

RFC is the number of methods that could becalled in response to a message to a class (local+ remote)

Viewpoints:

testing effort increases

harder it is to understand


67/83

a e c ass w 1, 2, 3

I = a b c d e I2 = {a, b, e}3 , ,

P = {(I1, I3), (I2, I3)} Q = {(I1, I2)}

Thus LCOM = 1


68/83

There are n such sets I1 ,, In

P = I I I I = Q = {(Ii, I j) | ( Ii I j ) }

a n se s i are en =

LCOM = | P | - | Q |, if |P | > | Q |

= o erw se


69/83

s e num er o emp y n ersec onsminus the number of non-empty intersections

This is a notion of degree of similarity of

If two methods use common instance variables then they are similar

LCOM of zero is not maximally cohesive |P | = | Q | or | P | < | Q |


70/83


71/83

Other Size, coupling, cohesion and inheritance metrics are: Number of Methods per Class (NOM): Number of Attributes per Class (NOA):

Data Abstraction Coupling(DAC)

- Number of Abstract Data Types in a class.

Message Passing Coupling (MPC)

Number of send statements defined in a class.


72/83

MIF = .

=

n

iii C M

1

)(

=i

ia C M 1

)(

in C

i Ma(C i) is the number of methods that can be invoked with C i Md(C i) is the number of methods declared in C i n is the total number of classes


73/83

Ma(C i) = Md(C i) + Mi(C i)

= overloaded + things inherited

MIF is 0 1 MIF near 1 means little specialization MIF near 0 means large change


74/83

CF= .),( _ C C client isi j ji

is_client(x,y) = 1 iff a relationship exists between

.

otherwise

(TC2-TC) is the total number of relationshipspossible

CF is [0,1] with 1 meaning high coupling


75/83

PF = .

i io C M )(

Mn() is the number of new methods

i iin

Mo() is the number of overriding methods

DC() number of descendent classes of a base class

,maximum number of possible distinct polymorphic situations


76/83

Metric Tools


77/83

, .

The Visual Quality ToolSet The Visual Testing ToolSet The Visual Reengineering ToolSet

Metrics calculated

McCabe Essential Complexity Module Design Complexity

n egra on omp ex y Lines of Code Halstead


78/83

A metric analyser C, C++, Java, Ada-83, and Ada-95(by Tim Littlefair of Edith Cowan University, Australia)

Lines Of Code (LOC) McCabes c clomatic com lexit C&K suite (WMC, NOC, DIT, CBO)

enerates an reports

http://cccc.sourceforge.net/

Jmetric


79/83

OO metric calculation tool for Java code (by Cainand Vasa for a project at COTAR, Australia)

Requires Java 1.2 (or JDK 1.1.6 with specialex ens ons

Lines Of Code per class (LOC)

LCOM (by Henderson-Seller)

Availability is distributed under GPL

http://www.it.swin.edu.au/projects/jmetric/products/jmetric/


80/83

GEN++


81/83

(University of California, Davis and Bell Laboratories) GEN++ is an application-generator for creating code analyzers

for C++ programs

simplifies the task of creating analysis tools for the C++ ,

the package these can both be used directly, and as a springboard for

other applications

http://www.cs.ucdavis.edu/~devanbu/genp/down-red.html


82/83

A Source of Information for Mission Critical SoftwareSystems, Management Processes, and Strategies

http://www.niwotridge.com/Resources/PM-SWEResources/SWTools.htm

Defense Software Collaborators (by DACS)p: www. e acs.com a a ases ur ey. s eyco e=

http://www.qucis.queensu.ca/Software-Engineering/toolcat.html#label208

Object-oriented metricshttp://me.in-berlin.de/~socrates/oo_metrics.html

Software Metrics Sites on the Web (Thomas Fetcke)

e r cs oo s or ++ r s o er o

http://www.chris-lott.org/resources/cmetrics/


83/83

A Source of Information for Mission Critical SoftwareSystems, Management Processes, and Strategies

http://www.niwotridge.com/Resources/PM-SWEResources/SWTools.htm

Defense Software Collaborators (by DACS)p: www. e acs.com a a ases ur ey. s eyco e=

http://www.qucis.queensu.ca/Software-Engineering/toolcat.html#label208

Object-oriented metricshttp://me.in-berlin.de/~socrates/oo_metrics.html

Software Metrics Sites on the Web (Thomas Fetcke)

e r cs oo s or ++ r s o er o

http://www.chris-lott.org/resources/cmetrics/

Software Metrics 2

Documents

Transcript of Software Metrics 2