Unit 2

The objectives of measurement should be established

before data collection begins.
1. Formulation - The derivation of software measures and
metrics appropriate for the representation of the software
that is being considered.
2. Collect information - The mechanism used to accumulate
data required to derive the formulated metrics.
3. Analysis information - The computation of metrics and
the application of mathematical tools.
4. Interpretation -The evaluation of metrics results in an
effort to gain insight into the quality of the
representation.
5. Feedback - Recommendations derived from the
interpretation of product metrics transmitted to the
software team.

Principles Of Measurement
Types of Measures

•Direct Measures (internal attributes)

–Cost, effort, LOC, speed, memory

•Indirect (external attributes)

–Functionality, quality, complexity, efficiency,
reliability, maintainability
Estimating Cost
•Costs for developer, not buyer
•We need our costs to manage and assess

Estimating Price
•There is not a simple relationship between the
development cost and the price charged to the customer.
•Broader organisational, economic, political and business
considerations influence the price charged.

Costing and pricing

Size-related measures
•Must be based on some output from the software
process
•Delivered source code
•Object code instructions

Function-related measures
•Based on an estimate of the functionality of the
delivered software.
•Function-points are the best known of this type of
measure

Productivity Measures
Examples of cost models
COCOMO Models

1/31/2018 7
The software cost estimation provides:
 the vital link between the general concepts and
techniques of economic analysis and the particular
world of software engineering.
 Software cost estimation techniques also provides an
essential part of the foundation for good software
management.

Motivation
1/31/2018 8
Software Cost Estimation
1/31/2018 9
 The COstructive COst Model (COCOMO) is the
most widely used software estimation model in the
world.
 The COCOMO model predicts the effort and
duration of a project based on inputs relating to the
size of the resulting systems and a number of "cost
drives" that affect productivity.

Introduction to COCOMO models

1/31/2018 10
 Effort Equation
◦ PM = C * (KDSI)n (person-months)
 where PM = number of person-month (=152 working hours),
 C = a constant,
 KDSI = thousands of "delivered source instructions" (DSI) and
 n = a constant.

Effort
1/31/2018 11
 Productivity equation
◦ (DSI) / (PM)
 where PM = number of person-month (=152 working hours),

 DSI = "delivered source instructions"

Productivity
1/31/2018 12
 Schedule equation
◦ TDEV = C * (PM)n (months)
 where TDEV = number of months estimated for software
development.

Schedule
1/31/2018 13
 Average Staffing Equation
◦ (PM) / (TDEV) (FSP)
 where FSP means Full-time-equivalent Software Personnel.

Average Staffing
1/31/2018 14
 COCOMO is defined in terms of three different
models:
◦ the Basic model,
◦ the Intermediate model, and
◦ the Detailed model.
 The more complex models account for more factors
that influence software projects, and make more
accurate estimates.

COCOMO Models
1/31/2018 15
 the most important factors contributing to a project's
duration and cost is the Development Mode
 Organic Mode: The project is developed in a familiar, stable
environment, and the product is similar to previously
developed products. The product is relatively small, and
requires little innovation.
 Semidetached Mode: The project's characteristics are
intermediate between Organic and Embedded.
 Embedded Mode: The project is characterized by tight,
inflexible constraints and interface requirements. An embedded
mode project will require a great deal of innovation.

The Development mode 1/31/2018 16

Feature Organic Semidetached Embedded

Organizational Thorough Considerable General

understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems

Need for software Basic Considerable Full

conformance with
pre-established
requirements

Need for software Basic Considerable Full

conformance with
external interface
specifications

Modes 1/31/2018 17
Feature Organic Semidetached Embedded

Concurrent Some Moderate Extensive

development of
associated new
hardware and
operational
procedures

Need for innovative Minimal Some Considerable

data processing
architectures,
algorithms
Premium on early Low Medium High
completion
Product size range <50 KDSI <300KDSI All

1/31/2018 18
 Cost Estimation Process

Cost=SizeOfTheProject x Productivity

1/31/2018 19
 Effort
Size Table
Development Time
Lines of Code
Estimation Process
Number of Use Case Number of Personnel

Function Point Errors

Cost Estimation Process

1/31/2018 20
1. Number of functional requirements
2. Cumulative number of functional and non-functional requirements
3. Number of Customer Test Cases
4. Number of ‘typical sized’ use cases
5. Number of inquiries
6. Number of files accessed (external, internal, master)
7. Total number of components (subsystems, modules, procedures,
routines, classes, methods)
8. Total number of interfaces
9. Number of System Integration Test Cases
10. Number of input and output parameters (summed over each
interface)
11. Number of Designer Unit Test Cases
12. Number of decisions (if, case statements) summed over each routine
or method
13. Lines of Code, summed over each routine or method
Project Size - Metrics 1/31/2018 21
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

Project Size – Metrics(.) 1/31/2018 22

 STEP 1: measure size in terms of the amount of functionality
in a system. Function points are computed by first calculating
an unadjusted function point count (UFC). Counts are made
for the following categories
◦ External inputs – those items provided by the user that
describe distinct application-oriented data (such as file
names and menu selections)
◦ External outputs – those items provided to the user that
generate distinct application-oriented data (such as reports
and messages, rather than the individual components of
these)

Function Points
1/31/2018 23
 ◦  External inquiries – interactive inputs requiring a
response
◦  External files – machine-readable interfaces to other
systems
◦  Internal files – logical master files in the system

Function Points(.)
1/31/2018 24
 STEP 2: Multiply each number by a weight factor, according
to complexity (simple, average or complex) of the parameter,
associated with that number. The value is given by a table:

Function Points(..)
1/31/2018 25
 STEP 3: Calculate the total UFP (Unadjusted Function
Points)
 STEP 4: Calculate the total TCF (Technical Complexity
Factor) by giving a value between 0 and 5 according to the
importance of the following points:

Function Points(...)
1/31/2018 26
 Technical Complexity Factors:
1. Data Communication
2. Distributed Data Processing
3. Performance Criteria
4. Heavily Utilized Hardware
5. High Transaction Rates
6. Online Data Entry
7. Online Updating
8. End-user Efficiency
9. Complex Computations
10. Reusability
11. Ease of Installation
12. Ease of Operation
13. Portability
14. Maintainability

Function Points(....) 1/31/2018 27

 STEP 5: Sum the resulting numbers too obtain DI (degree of
influence)
 STEP 6: TCF (Technical Complexity Factor) by given by the
formula
◦ TCF=0.65+0.01*DI
 STEP 7: Function Points are by given by the formula
◦ FP=UFP*TCF

Function Points(.....)
1/31/2018 28
Example 1/31/2018 29
Example (.) 1/31/2018 30
Technical Complexity Factors:
1. Data Communication 3
2. Distributed Data Processing 0
3. Performance Criteria 4
4. Heavily Utilized Hardware 0
5. High Transaction Rates 3
6. Online Data Entry 3
7. Online Updating 3
8. End-user Efficiency 3
9. Complex Computations 0
10. Reusability 3
11. Ease of Installation 3
12. Ease of Operation 5
13. Portability 3
14. Maintainability 3

DI =30 (Degree of Influence)

1/31/2018 31
 Function Points
◦ FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*30)=52.25

◦ That means the is FP=52.25

Example (…)
1/31/2018 32
 Relationship:

◦ LOC = Language Factor *

FP

◦ where
 LOC (Lines of Code)
 FP (Function Points)

Relation between LOC and FP

1/31/2018 33
Assuming LOC’s per FP for:
Java = 53,
C++ = 64

aKLOC = FP * LOC_per_FP / 1000

It means for the SpellChekcer Example: (Java)

LOC=52.25*53=2769.25 LOC or 2.76 KLOC

Relation between LOC and FP(.)

1/31/2018 34
 The Basic COCOMO model computes effort as a function of
program size. The Basic COCOMO equation is:
◦ E = aKLOC^b
 Effort for three modes of Basic COCOMO.

Mode a b

Organic 2.4 1.05

Semi- 3.0 1.12
detached
Embedded 3.6 1.20

Effort Computation
1/31/2018 35
Example
1/31/2018 36
 The intermediate COCOMO model computes effort as a
function of program size and a set of cost drivers. The
Intermediate COCOMO equation is:
◦ E = aKLOC^b*EAF
 Effort for three modes of intermediate COCOMO.

Mode a b

Organic 3.2 1.05

Semi- 3.0 1.12
detached
Embedded 2.8 1.20

Effort Computation
1/31/2018 37
  Effort Adjustment Factor
Cost Driver Very Low Nominal High Very Extra
Low High High
Required Reliability .75 .88 1.00 1.15 1.40 1.40
Database Size .94 .94 1.00 1.08 1.16 1.16
Product Complexity .70 .85 1.00 1.15 1.30 1.65
Execution Time Constraint 1.00 1.00 1.00 1.11 1.30 1.66
Main Storage Constraint 1.00 1.00 1.00 1.06 1.21 1.56
Virtual Machine Volatility .87 .87 1.00 1.15 1.30 1.30
Comp Turn Around Time .87 .87 1.00 1.07 1.15 1.15
Analyst Capability 1.46 1.19 1.00 .86 .71 .71
Application Experience 1.29 1.13 1.00 .91 .82 .82
Programmers Capability 1.42 1.17 1.00 .86 .70 .70
Virtual machine Experience 1.21 1.10 1.00 .90 .90 .90
Language Experience 1.14 1.07 1.00 .95 .95 .95
Modern Prog Practices 1.24 1.10 1.00 .91 .82 .82
SW Tools 1.24 1.10 1.00 .91 .83 .83
Required Dev Schedule 1.23 1.08 1.00 1.04 1.10 1,10

Effort computation(.) 1/31/2018 38

Total EAF = Product of the selected factors

Adjusted value of Effort: Adjusted Person Months:

APM = (Total EAF) * PM

Effort Computation (..)

1/31/2018 39
1/31/2018 40
 Development Time Equation Parameter Table:
Parameter Organic Semi- Embedded
detached
C 2.5 2.5 2.5
D 0.38 0.35 0.32

Development Time, TDEV = C * (APM **D)

Number of Personnel, NP = APM / TDEV

Software Development Time

1/31/2018 41
 A development process typically consists of the
following stages:
 - Requirements Analysis
 - Design (High Level + Detailed)
 - Implementation & Coding
 - Testing (Unit + Integration)

Distribution of Effort
1/31/2018 42
The following table gives the recommended percentage distribution
of Effort (APM) and TDEV for these stages:

Percentage Distribution of Effort and Time Table:

Req Design, Implementation Testing

Analysis HLD + DD

Effort 23% 29% 22% 21% 100%

TDEV 39% 25% 15% 21% 100%

Distribution of Effort (.)

1/31/2018 43
 Calculate the estimated number of errors in your design, i.e.total errors found in requirements,
specifications, code, user manuals, and bad fixes:
◦ Adjust the Function Point calculated in step1

AFP = FP ** 1.25
◦ Use the following table for calculating error estimates

Error Type Error / AFP

Requirements 1
Design 1.25
Implementation 1.75
Documentation 0.6
Due to Bug Fixes 0.4

Error Estimation
1/31/2018 44
The Modes
 Three calculation models:
◦ Basic: single-variable static model
 Effort in staff months = C1b * (KDSI) P1
 Schedule in total months= C2 * (Effort)P2
◦ Intermediate: Two variables.
 Effort in man months = C1i * EAF * (KDSI) P1
 Schedule in total months = C2 * (Effort)P2
 EAF = E1 * E2 * … E15
◦ Detailed: Intermediate + assessed per phase (analysis,
design, etc)
Table Values
Assume that the size of an organic type software product has
been estimated to be 32,000 lines of source code. Assume that
the average salary of software engineers be Rs. 15,000/- per
month. Determine the effort required to develop the software
product and the nominal development time.

From the basic COCOMO estimation formula for organic

software:
Effort = 2.4 х(32)1.05= 91 PM
Nominal development time = 2.5 х(91)0.38=14 months
Cost required to develop the product = 14 х15,000= Rs.
210,000/-

Example
i) Cost / Size - Size in LOC, FP, etc
ii) Cost of rework
iii) Rework effort in person- hour, staff-hour, etc
iv) Effort * cost per staff-hour
v)Person-month, person-hour, staff-hour, etc
vi)Rework index = % project effort spent in rework
vii)Avoidable Fault Cost (AFC) = Determined by FST
and the average estimated cost of finding a fault in a
specific phase of the software life-cycle

Cost Metrics
LOC(Lines of Code)
 Source lines of code (SLOC or LOC) is a software
metric used to measure the size of a software
program by counting the number of lines in the text
of the program's source code. SLOC is typically used
to predict the amount of effort that will be required to
develop a program, as well as to estimate
programming productivity or effort once the software
is produced.

Measurement methods
 There are two major types of SLOC measures:
physical SLOC (LOC) and logical SLOC (LLOC).
Consider this snippet of C code as an example of the ambiguity
encountered when determining SLOC:

for (i = 0; i < 100; i += 1) printf("hello"); /* How many lines of

code is this? */

In this example we have:

1 Physical Lines of Code (LOC)
2 Logical Line of Code (LLOC) (for statement and printf
statement)
1 comment line
Depending on the programmer and/or coding standards, the
above "line of code" could be written on many separate
lines:
for (i = 0; i < 100; i += 1)
{
printf("hello");
} /* Now how many lines of code is this? */

In this example we have:

4 Physical Lines of Code (LOC): is placing braces work to
be estimated?
2 Logical Line of Code (LLOC): what about all the work
writing non-statement lines?
1 comment line: tools must account for all code and
comments regardless of comment placement.
•Determine the quality of the current product or
process

•Predict qualities of a product/process

•Improve quality of a product/process

Why Measure Software?

Quantitative measure of degree to which a system, component or
process possesses a given attribute. A handle or guess about a given
attribute.
E.g., Number of errors found per person hours expended. Motivation
for Metrics
• Estimate the cost and schedule of future projects.
• Evaluate the productivity impacts of new tools and techniques.
• Establish productivity trends over time.
• Improve software quality.
• Forecast future staffing needs.
• Anticipate and reduce future maintenance needs.

Metric
•Correctness degree to which a program operates according to
specification
– Defects/KLOC
–Defect is a verified lack of conformance to requirements
–Failures/hours of operation

•Maintainability degree to which a program is open to change

–Mean time to change
–Change request to new version (Analyze, design etc)
–Cost to correct

•Integrity - degree to which a program is resistant to outside attack

–Fault tolerance, security and threats

•Usability easiness to use

–Training time, skill level necessary to use, Increase in productivity,
subjective questionnaire or controlled experiment

Measures of Software Quality

 Defect rates
 Error rates

Example Metrics
Software testing tests 500,000 lines of code and discovers
33 defects.
defect rate = (33/500000) × 100 = 0.0066%

Code defects are also commonly measured as defects per

thousand lines of code. This can be calculated with the
formula:
defects per thousand lines of code = defects / (lines of
code /1000)
In the example above this results in a defects per thousand
lines of code of:
defects per thousand lines of code = 33 / (500000 / 1000)
= 0.066

Example
The definition of software quality consists of two
levels:
intrinsic product quality and customer satisfaction.

The metrics we discuss here cover both levels:

• Mean time to failure
• Defect density
• Customer problems
• Customer satisfaction.

Product Quality Metrics

MTTF: Mean time to failure describes the expected
time to failure for a non-repairable system.

For example, assume you tested 3 identical systems

starting from time 0 until all of them failed. The first
system failed at 10 hours, the second failed at 12
hours and the third failed at 13 hours. The MTTF is
the average of the three failure times, which is
11.6667 hours.
Intrinsic product quality is usually measured by the number of bugs
(functional defects) in the software or by how long the software
can run before encountering a crash. In operational definitions,
the two metrics are defect density (rate) and mean time to failure
(MTTF).
The MTTF metric is most often used with safety critical systems
such as the airline traffic control systems, avionics, and weapons.
For instance, the U.S. government mandates that its air traffic
control system cannot be unavailable for more than three
seconds per year. In civilian airliners, the probability of certain
catastrophic failures must be no worse than 10-9 per hour
(Littlewood and Strigini, 1992). The defect density metric, in
contrast, is used in many commercial software systems.