LECTURE 14: Software Metrics

Ivan Marsic
Rutgers University 1
 Topics

 Why Measure Software

 Fundamentals of Measurement Theory
 Use Case Points

2
 Why Measure Software

 To estimate development time and budget

 To improve software quality
– If a software module shares characteristics of modules
that are known often to fail, then these should be the
focus of quality improvement

3
 Measurement Scale (1)

 Nominal scale – group subjects into categories

– Example: designate the weather condition as “sunny,” “cloudy,”
“rainy,” or “snowy”
– The two key requirements for the categories: jointly exhaustive &
mutually exclusive
– Minimal conditions necessary for the application of statistical
analysis

 Ordinal scale – subjects compared in order

– Examples: “bad,” “good,” and “excellent,” or “star” ratings
– Arithmetic operations such as addition, subtraction, multiplication
cannot be applied

4
 Measurement Scale (2)

 Interval scale – indicates the exact differences between

measurement points
– Examples: traditional temperature scale (centigrade or Fahrenheit
scales)
– Arithmetic operations of addition and subtraction can be applied

 Ratio scale – an interval scale for which an absolute or

nonarbitrary zero point can be located
– Examples: mass, temperature in degrees Kelvin, length, and time
interval
– All arithmetic operations are applicable

5
Subjective Metrics

 




 


6
Subjective Metrics


 







7
 Use Case Points (UCPs)

 Size and effort metric

( https://en.wikipedia.org/wiki/Use_Case_Points )
 Advantage: Early in the product development (after
detailed use cases are available)
 Drawback: Many subjective estimation steps involved
 Use Case Points = function of (
– size of functional features (“unadjusted” UCPs)
– nonfunctional factors (technical complexity factors)
– environmental complexity factors (ECF)
)
 Derived from Function Points — ISO/IEC 19761:2011
( https://en.wikipedia.org/wiki/Function_point )
8
 Actor Classification and Weights
Actor type Description of how to recognize the actor type Weight
The actor is another system which interacts with our
Simple system through a defined application programming 1
interface (API).
The actor is a person interacting through a text- or
Average numeric-based user interface, or another system 2
interacting through a protocol, such as a network
communication protocol.

Complex The actor is a person interacting via a graphical user 3

interface (GUI).

 Weights recommended by a standards body (panel of expert developers)

 Simple actors’ input (thorough API) can be automatically checked
 “Hyper-complex” modern interfaces should be assigned weights >3
– Examples of “non-explicit” interactions (unlike GUI-based):
• On iPhone, user interaction involves shaking the phone for an “undo” operation
• Detecting user’s emotional or physical state to customize the music playlist
9
 Example: Safe Home Access
Actor classification for the case study of home access control:
Actor name Description of relevant characteristics Complexity Weight
Landlord is interacting with the system via a graphical user
Landlord Complex 3
interface (when managing users on the central computer).
Tenant is interacting through a text-based user interface
(assuming that identification is through a keypad; for
Tenant Average 2
biometrics based identification methods Tenant would be a
complex actor).
LockDevice is another system which interacts with our
LockDevice Simple 1
system through a defined API.
LightSwitch Same as LockDevice. Simple 1
AlarmBell Same as LockDevice. Simple 1
Database Database is another system interacting through a protocol. Average 2
Timer Same as LockDevice. Simple 1
Police Our system just sends a text notification to Police. Simple 1

Unadjusted Actor Weight (UAW) represents the “size” of all actors:

UAW(home access) = 5  Simple  2  Average  1  Complex = 51  22  13 = 12
10
 Use Case Weights
Use case
category Description of how to recognize the use-case category Weight

Simple user interface.

Up to one participating actor (plus initiating actor).
Simple 5
Number of steps for the success scenario:  3.
If presently available, its domain model includes  3 concepts.

Moderate interface design.

Two or more participating actors.
Average Number of steps for the success scenario: 4 to 7. 10
If presently available, its domain model includes between 5
and 10 concepts.
Complex user interface or processing.
Three or more participating actors.
Complex 15
Number of steps for the success scenario: 7.
If available, its domain model includes 10 concepts.

Use case weights based on the number of transactions

11
 Example: Safe Home Access
Use case classification for the case study of home access control:
Use case Description Category Weight
Unlock Simple user interface. 5 steps for the main success scenario.
Average 10
(UC‑1) 3 participating actors (LockDevice, LightSwitch, and Timer).
Lock Simple user interface. 2+3=5 steps for the all scenarios.
Average 10
(UC‑2) 3 participating actors (LockDevice, LightSwitch, and Timer).
Complex user interface. More than 7 steps for the main
ManageUs
success scenario (when counting UC‑6 or UC‑7). Two Complex 15
ers (UC‑3)
participating actors (Tenant, Database).
ViewAcces Complex user interface. 8 steps for the main success scenario.
sHistory 2 participating actors (Database, Landlord). Complex 15
(UC‑4)
Authentica Simple user interface. 3+1=4 steps for all scenarios.
teUser 2 participating actors (AlarmBell, Police). Average 10
(UC‑5)
Complex user interface. 6 steps for the main success scenario
AddUser
(not counting UC‑3). Two participating actors (Tenant, Average 10
(UC‑6)
Database).
RemoveUs Complex user interface. 4 steps for the main success scenario
Average 10
er (UC‑7) (not counting UC‑3). One participating actor (Database).
Login Simple user interface. 2 steps for the main success scenario.
Simple 5
(UC‑8) No participating actors.

UUCW(home access) = 1  Simple  5  Average  2  Complex = 15  510  215 = 85 12

Technical Complexity Factors (TCFs)
Technical factor Description Weight
T1 Distributed system (running on multiple machines) 2
Performance objectives (are response time and throughput performance
T2 1()
critical?)
T3 End-user efficiency 1
T4 Complex internal processing 1
T5 Reusable design or code 1
Easy to install (are automated conversion and installation included in the
T6 0.5
system?)
T7 Easy to use (including operations such as backup, startup, and recovery) 0.5
T8 Portable 2
T9 Easy to change (to add new features or modify existing ones) 1
T10 Concurrent use (by multiple users) 1
T11 Special security features 1
Provides direct access for third parties (the system will be used from
T12 1
multiple sites in different organizations)
T13 Special user training facilities are required 1

13
 Technical Complexity Factors (TCFs)

13
TCF = Constant-1  Constant-2  Technical Factor Total = C1  C 2  Wi  Fi
i 1

Constant-1 (C1) = 0.6

Constant-2 (C2) = 0.01
Wi = weight of ith technical factor
Fi = perceived complexity of ith technical factor

14
 Scaling Factors for TCF & ECF

1.4 (70, 1.3) 1.4 (0, 1.4)

1.2 1.2
1 1
TCF

0.8 0.8

ECF
0.6 0.6
(0, 0.6)
0.4 0.4
(32.5, 0.425)
0.2 0.2
0 0
0 10 20 30 40 50 60 70 80 0 10 20 30 40
Technical Factor Total Environmental Factor Total

(a) (b)

15
 Example
Calculated Factor
Technical Perceived
Description Weight (WeightPerceived
factor Complexity
Complexity)
Distributed, Web-based system, because of
T1 2 3 23 = 6
ViewAccessHistory (UC‑4)
Users expect good performance but nothing
T2 1 3 13 = 3
exceptional
End-user expects efficiency but there are no
T3 1 3 13 = 3
exceptional demands
T4 Internal processing is relatively simple 1 1 11 = 1
T5 No requirement for reusability 1 0 10 = 0
Ease of install is moderately important (will
T6 0.5 3 0.53 = 1.5
probably be installed by technician)
T7 Ease of use is very important 0.5 5 0.55 = 2.5
No portability concerns beyond a desire to
T8 2 2 22 = 4
keep database vendor options open
T9 Easy to change minimally required 1 1 11 = 1
T10 Concurrent use is required (Section 5.3) 1 4 14 = 4
T11 Security is a significant concern 1 5 15 = 5
T12 No direct access for third parties 1 0 10 = 0
T13 No unique training needs 1 0 10 = 0
Technical Factor Total: 31
16
 Environmental Complexity Factors
(ECFs)
Environmental factor Description Weight

E1 Familiar with the development process (e.g., UML-based) 1.5

E2 Application problem experience 0.5

E3 Paradigm experience (e.g., object-oriented approach) 1
E4 Lead analyst capability 0.5
E5 Motivation 1
E6 Stable requirements 2
E7 Part-time staff 1
E8 Difficult programming language 1

8
ECF = Constant-1  Constant-2  Environmental Factor Total = C1  C 2  Wi  Fi
i 1
Constant-1 (C1) = 1.4
Constant-2 (C2) = 0.03
Wi = weight of ith environmental factor
Fi = perceived impact of ith environmental factor
17
 Example
Environmental complexity factors for the case study of home access:
Calculated Factor
Perceived
Environmenta (Weight
Description Weight Impa
l factor Perceived
ct
Impact)
Beginner familiarity with the UML-based
E1 1.5 1 1.51 = 1.5
development
E2 Some familiarity with application problem 0.5 2 0.52 = 1
E3 Some knowledge of object-oriented approach 1 2 12 = 2
E4 Beginner lead analyst 0.5 1 0.51 = 0.5
Highly motivated, but some team members
E5 1 4 14 = 4
occasionally slacking
E6 Stable requirements expected 2 5 25 = 5
E7 No part-time staff will be involved 1 0 10 = 0
Programming language of average difficulty
E8 1 3 13 = 3
will be used
Environmental Factor Total: 11

18
 Calculating the Use Case Points (UCP)

UCP = UUCP  TCF  ECF

From the above calculations, the UCP variables have the following values:
UUCP = 97
TCF = 0.91
ECF = 1.07

For the sample case study, the final UCP is the following:
UCP = 97  0.91  1.07 = 94.45 or 94 use case points.

19
 Project Duration

Productivity Factor (PF)

Duration = UCP  PF

20