UNIT- 6.

METRICS & COST ESTIMATION

METRICS
 Used in real-time systems engineering in several
ways-
 During S/w requirements development for assisting cost
estimation.

 Benchmarking- computing metrics for successful

systems and setting them as benchmarks.

 Tracking project progress

 Testing – measuring desirable properties of s/w &

setting limits criteria.

 During testing, for Debugging purposes to focus on

likely sources of errors.
LINES OF CODE
 Easiest characteristic of s/w that can be measured.

 Measured as thousands of lines of code (KLOC)

 Also referred to as DSI or NCSS.

 i.e. no. of executable program instructions.

 Excluding – Comment statements
- Header files
- Formatting statements
- Macros
- Anything i.e not executable code or
Causes allocation of memory
 LINES OF CODE
 Another related metric is source lines of code(SLOC)
 E.g. if-then-else maybe single SLOC but multiple DSI.

 Disadvantages-
 Not likely that 1000LOC will have more errors that of 100 LOC
 It can only be measured after code has been written.
Predictions may not be accurate.

 Still a useful metric. Beco’z many metrics are based on

this.
 Delta KLOC- how many LOC is changed over period of time
MCCABE’S METRIC
 Based on complexity of the flow of control in the system.

 To attempt to measure software complexity, cyclomatic

complexity was introduced to measure program flow-of-
control
 The cyclomatic complexity is based on determining the
number of linearly independent paths in a program
module,
 suggesting that the complexity increases with this
number, and reliability decreases.

 C=e−n+2

5
MCCABE’S METRIC

 E.g. as in fig. 8.1, if sequence of instructions has

2 nodes, 1 edge then,
C= 1 - 2 + 2 = 1
 McCabe’s metric can be computed during
compilation by analyzing internal tree structure
generated during parsing phase.
6
 HALSTEAD’S METRICS
 Other metrics work well only with synchronous flow of
control.
 Halstead’s metrics algorithm:
 First, find n1.
This is essentially the number of distinct, syntactic begin–
end pairs (or their equivalent), called “operators.”
 Next find n2
the number of distinct statements. A statement is
determined by the syntax of the language; for example, a line
terminated by a semicolon is a statement in C.

 Next count N1, the total number of occurrences of n1 in the

program.
 Then count N2, the total number of occurrences of operands
or n2 in the program.
8
 From these statistics the following metrics can be
computed.
 The program vocabulary, n, is defined as
 n = n1 + n2
 The program length, N, is defined as
 N = N1 + N2
 The program volume, V , is defined as
 V = N log2n
 The potential volume, V∗, is defined as
 V∗ = (2 + n2) · log2 (2 + n2)
 The program level, L, is defined as
 L = V∗/V
 where L is a measure of the level of abstraction of the program.
It is believed that increasing this number will increase system
reliability.
 Another Halstead metric measures the amount of mental effort
required in the development of the code. The effort, E, is
defined as E = V/L 9
 FUNCTION POINTS

 Metrics based on simple source line count.

 The solution is to measure the functionality of software

via the number of interfaces between modules and
subsystems in programs or systems.

 Advantage of the function point metric is that it can be

calculated before any coding occurs

10
 FUNCTION POINTS

 The following five software characteristics for

each module, subsystem, or system represent its
function points:
 Number of inputs to the application (I )

 Number of outputs (O)

 Number of user inquiries (Q)

 Number of files used (F)

 Number of external interfaces (X)

 function point (FP) value:

 FP = 4I + 4O + 5Q + 10F + 7X

11
 FUNCTION POINTS
 FP = 4I + 4O + 5Q + 10F + 7X..................... Equation 8.8
 If Wi are weighting factors, Fj are “complexity adj. factors”,
and Ai are item counts, then FP is defined as:

 …Equation 8.9
 Higher the FP, more difficult is the system to implement.

 Complexity Adj. Factors(Fj) can be determined by answering

set of 14 questions with responses from scale of 0 to 5 :
 0 no influence
 1 incidental
 2 moderate
 3 average
 4 significant
 5 essential
12
 FUNCTION POINTS
 E.g. in inertial measurement unit system
 Engg. team was queried & following Que. & ans.
Obtained
 Q1. Does system require reliable backup & recovery?
 -Yes. This is critical system; Assign a 4 .
 Q2. Are data comm. required?
 -Yes. There is comm. Between various components; Assign a 5.
 Q3. Are there distributed processing functions?
 -Yes. Assign a 5 .
 Q4. Is information critical?
 -Yes. This is HARD real-time system; Assign a 5 .
 Q5. Will system run in existing, heavily utilized operational
Environment?
 -Yes. Assign a 5 .
 Q6. Does system require on-line data entry?
 -Yes. Via sensors ; Assign a 4 .
 FUNCTION POINTS
 Q7. Does on-line data entry require input transactions over
multiple screens or operations?
 -Yes. Assign a 4 .
 Q8. Are master files updated on-line?
 -Yes. Assign a 5.
 Q9. Are inputs, outputs, files, or inquiries complex?
 -Yes. They involve complex sensor inputs; Assign a 4 .
 Q10. Is the internal processing complex?
 -Yes. Algorithms are nontrivial /complex; Assign a 4 .
 Q11. Is code designed to be reusable?
 -Yes. Development costs are high. So its imp. Assign a 4 .
 Q12. Are conversion & installation included in design?
 -Yes. Assign a 5 .
 Q13. Is system designed for multiple installations in difft Org?
 -Not Org. but in difft Applns so it must be flexible. Assign a 5 .
 Q14. Is application designed to facilitate change & ease of use?
 -Yes absolutely. Assign a 5 .
 FUNCTION POINTS
 Applying these values to the FP equation,
0.01∑ Fj = 0.01.( 6 . 4 + 8 . 5 )= 0.64
 Now Suppose in SRS its determined that,
 A1= I= 5 , A2=U= 7, A3= Q= 8, A4=F=5, A5= X= 5
 Using weighting factors from equation 8.8
 W1=4, W2=4, W3=5, W4=10, W5=7
 putting these values to equation 8.9,
 FP= [5.4+7.4+8.5+5.10+5.7].[0.65+0.64] ≈ 223
 FEATURE POINTS

 Extension of function points.

 Computed similarly as Function point except a new
factor for no. of algorithms A is added.
 The empirical weightings are:
 W1=3, W2=4, W3=5, W4=4, W5=7, W6=7.
 The feature point metric

 E.g. for inertial measurement, using same item counts

and with item count for algorithm A=10 & same
complexity factor,

16
 METRICS FOR OBJECT ORIENTED S/W

 Some of the metrics for object oriented code include:

 A weighted count of methods per class
 Depth of inheritance tree.
 No. of children in inheritance tree
 Coupling between object classes
 Lack of cohesion in methods.

 OBJECTIONs to Metrics
 More powerful the language, less productive the programmer
 Missused for “proving a point” to Managers
 Low cyclomatic complexity leads to reliability but no way to
prove why.

17
 COST ESTIMATION USING COCOMO
 Cost estimation is important component of Engineering
real-time software systems.

 Software cost estimation techniques also provides an

essential part of the foundation for good software
management.

 The cost in a project is due to:

 Requirements for software, hardware
 Human resources needed

 Most cost estimates are measured in person-months (PM)

 COCOMO
 Acronym for Constructive Cost Model.
 First introduced in 1981 by Boehm & is predictive model

 The COCOMO model predicts the effort and duration

of a project based on inputs relating to -
 Size of the resulting systems
 and a number of "cost drivers" that affect productivity

 Three Versions of original COCOMO-

 Basic
 Intermediate
 Detailed

 Latest is the COCOMO II model.

BASIC COCOMO
 Based on thousand lines of DSI (KDSI)
 For given software,

T= Effort/time to complete the s/w

L= no. of lines of KDSI
 a and b are function of type of software to be constructed

 E.g for inertial measurement system(37.6 KLOC using

feature points) T= 2.8*(37.6K)1.2 = 169K

Type of system a b
Assume using CASE,
2000 LOC per month Organic 3.2 1.05
Semi-detached 3.0 1.12

Embedded 2.8 1.20

 INTERMEDIATE AND DETAILED COCOMO
 It considers the kinds of adjustments used.
 Adjustments are made to T based on-
 A- Adaptation adjustment factor
 E- Effort adjustment factor

 Additional adjustments (E’ )made based on Product

attributes, computer attributes, personnel attributes and
project attributes.
 Then 2nd Adj, factor E” = E’ * E and
 In detailed COCOMO effort multipliers are used
for each phase of s/w lifecycle.

COCOMO II -
 Original COCOMO was defined in terms of DSI

 COCOMO-II uses Source lines of Code (SLC)

 It also accommodates modern languages & S/w

generation tools.
 COCOMO II involves following imp factors-
 Project novelty
 Development flexibility
 Architectural/ risk resolution
 Team cohesion
 Process maturity