Software Product Metrics

Measures, Metrics, and Indicators

• These three terms are often used interchangeably, but they can have
subtle differences
• Measure
• Provides a quantitative indication of the extent, amount, dimension,
capacity, or size of some attribute of a product or process
• Measurement
• The act of determining a measure
• Metric
• (IEEE) A quantitative measure of the degree to which a system, component,
or process possesses a given attribute
• Indicator
• A metric or combination of metrics that provides insight into the software
process, a software project, or the product itself

2
Metrics for the
Analysis Model
Function Points
 Introduction to Function Points(FP)
• First proposed by Albrecht in 1979; hundreds of books and papers have
been written on functions points since then
• Can be used effectively as a means for measuring the functionality
delivered by a system
• Using historical data, function points can be used to
• Estimate the cost or effort required to design, code, and test the software
• Predict the number of errors that will be encountered during testing
• Forecast the number of components and/or the number of projected source
code lines in the implemented system
• Derived using an empirical relationship based on
1) Countable (direct) measures of the software’s information domain
2) Assessments of the software’s complexity

4
 Information Domain Values
• Number of external inputs
• Each external input originates from a user or is transmitted from another
application
• They provide distinct application-oriented data or control information
• They are often used to update internal logical files
• They are not inquiries (those are counted under another category)
• Number of external outputs
• Each external output is derived within the application and provides information
to the user
• This refers to reports, screens, error messages, etc.
• Individual data items within a report or screen are not counted separately

(More on next slide) 5

 Information Domain Values
(continued)
• Number of external inquiries
• An external inquiry is defined as an online input that results in the generation of
some immediate software response
• The response is in the form of an on-line output
• Number of internal logical files
• Each internal logical file is a logical grouping of data that resides within the
application’s boundary and is maintained via external inputs
• Number of external interface files
• Each external interface file is a logical grouping of data that resides external to
the application but provides data that may be of use to the application

6
 Function Point Computation
1) Identify/collect the information domain values
2) Complete the table shown below to get the count total
• Associate a weighting factor (i.e., complexity value) with each count based
on criteria established by the software development organization
3) Evaluate and sum up the adjustment factors (see the next two slides)
• “Fi” refers to 14 value adjustment factors, with each ranging in value from
0 (not important) to 5 (absolutely essential)
4) Compute the number of function points (FP)
FP = count total * [0.65 + 0.01 * sum(Fi)]

Information Weighting Factor

Domain Value Count Simple Average Complex
External Inputs _____ x 3 4 6 = _____
External Outputs _____ x 4 5 7 = _____
External Inquiries _____ x 3 4 6 = _____
Internal Logical Files _____ x 7 10 15 = _____
External Interface Files _____ x 5 7 10 = _____
Count total ________
7
 Value Adjustment Factors
1) Does the system require reliable backup and recovery?
2) Are specialized data communications required to transfer information to or from the
application?
3) Are there distributed processing functions?
4) Is performance critical?
5) Will the system run in an existing, heavily utilized operational environment?
6) Does the system require on-line data entry?
7) Does the on-line data entry require the input transaction to be built over multiple screens or
operations?

(More on next slide) 8

 Value Adjustment Factors
(continued)
8) Are the internal logical files updated on-line?
9) Are the inputs, outputs, files, or inquiries complex?
10) Is the internal processing complex?
11) Is the code designed to be reusable?
12) Are conversion and installation included in the design?
13) Is the system designed for multiple installations in different organizations?
14) Is the application designed to facilitate change and for ease of use by the user?

9
Function Point Example
Information Weighting Factor
Domain Value Count Simple Average Complex
External Inputs 3 x 3 4 6= 9
External Outputs 2 x 4 5 7= 8
External Inquiries 2 x 3 4 6= 6
Internal Logical Files 1 x 7 10 15 = 7
External Interface Files 4 x 5 7 10 = 20
Count total 50

• FP = count total * [0.65 + 0.01 * sum(Fi)]

• FP = 50 * [0.65 + (0.01 * 46)]
• FP = 55.5 (rounded up to 56)

10
FP another example
• It is given that the complexity weighting factors for I, O, E, F and N are
4, 5, 4, 10 and 7, respectively. It is also given that, out of fourteen
value adjustment factors that influence the development effort, four
factors are not applicable, each of the other four factors have value 3,
and each of the remaining factors have value 4. Compute the value of
function point metric.
1:0,2:0,3:0,4:0,
5:3,6:3,7:3,8:3
9-14:4
VAF = (0+0+0+0+3+3+3+3+4+4+4+4+4+4)
The value of function point metric = UPF (count total) * VAF

Here,
UPF: Unadjusted Function Point (UFP) count
VAF: Value Adjustment Factor no of external inputs:30, O:60, E:23. F:8,N:2

UPF (count total) = 4*30 + 60*5 + 23*4 + 8*10 + 7*2 = 606

VAF = (TDI * 0.01) + 0.65

Here TDI (sum of Fi) is Total Degree of Influence

TDI = 3*4 + 0*4 + 4*6 = 36

VAF = (TDI * 0.01) + 0.65

= 36*0.01 + 0.65
= 0.36 + 0.65
= 1.01

FP = UPF * VAF
= 1.01 * 606
= 612.06
Hierarchical Architecture Metrics
• Fan out: the number of modules immediately subordinate to the module i,
that is, the number of modules directly invoked by module i
• Structural complexity
• S(i) = f2out(i), where fout(i) is the “fan out” of module i
• Data complexity
• D(i) = v(i)/[fout(i) + 1], where v(i) is the number of input and output
variables that are passed to and from module i
• System complexity
• C(i) = S(i) + D(i)
• As each of these complexity values increases, the overall architectural
complexity of the system also increases
• This leads to greater likelihood that the integration and testing effort will also
increase

13
• Shape complexity
• size = n + a, where n is the number of nodes and a is the number of arcs
• Allows different program software architectures to be compared in a straightforward manner
• Connectivity density (i.e., the arc-to-node ratio)
• r = a/n
• May provide a simple indication of the coupling in the software architecture

14
• size = 17 + 18 = 35
• arc-to-node ratio, r = a/n
r = 18/17 = 1.06
• Cyclomatic complexity = E - N + 2p
E - number of edges in graph
N - number of nodes in graph
p - number of connected components (often 1)
• The graph shows seven shapes(nodes), seven lines(edges), hence
cyclomatic complexity is 7-7+2 = 2
 E.g. Structural complexity of a module
• Structural complexity of a module p is Cp
Cp = (fan-in * fan-out)^2
Where,
Fan-in – no. of calls to a module and # of global data variables accessed by a module
Fan-out – no. of modules called by a module and # of global data variables modified by a
module
Example:
Module x Module y Module z
Fan-in 3 5 1
Fan-out 2 7 4

Cx = (3*2)^2 = 36
Cy = (5*7)^2 = 1175
Cz = (1*4)^2 = 16

Total structural Complexity for modules x, y, and z is 36 + 16 + 1175 = 1227

Maintenance Metrics
• Software Maturity Index provides an indication of the stability of a software
product (based on changes that occur for each release of the product).
Computes the following:
MT = the number of modules in the current release
Fc= the number of modules in the current release that have been changed
Fa= the number of modules in the current release that have been added
Fd = the number of modules from the preceding release that were deleted in
the current release
Software maturity index is computed as:
SMI = [MT - (Fa + Fc + Fd)] / MT

As SMI approaches 1.0 as product begins to stabilize

Software Process and Project metrics
Metrics in the Process Domain
• Process metrics are collected across all projects and over long periods
of time
• They are used for making strategic decisions
• The intent is to provide a set of process indicators that lead to
long-term software process improvement
• The only way to know how/where to improve any process is to
• Measure specific attributes of the process
• Develop a set of meaningful metrics based on these attributes
• Use the metrics to provide indicators that will lead to a strategy for
improvement

20
 Metrics in the Process Domain
• We measure the effectiveness of a process by deriving a set of metrics based on outcomes of the
process such as
• Errors uncovered before release of the software
• Defects delivered to and reported by the end users
• Work products delivered
• Human effort expended
• Calendar time expended
• Conformance to the schedule
• Time and effort to complete each generic activity

21
Metrics in the Project Domain
• Project metrics enable a software project manager to
• Assess the status of an ongoing project
• Track potential risks
• Uncover problem areas before their status becomes critical
• Adjust work flow or tasks
• Evaluate the project team’s ability to control quality of software work products
• Many of the same metrics are used in both the process and project domain
• Project metrics are used for making tactical decisions
• They are used to adapt project workflow and technical activities

22
• In summary
• As quality improves, defects are minimized
• As defects go down, the amount of rework required during the project is also
reduced
• As rework goes down, the overall project cost is reduced

23
Software Measurement
• Two categories of software measurement
• Direct measures of the
• Software process (cost, effort, etc.)
• Software product (lines of code produced, execution speed, defects reported over time, etc.)
• Indirect measures of the
• Software product (functionality, quality, complexity, efficiency, reliability, maintainability, etc.)
• Project metrics can be consolidated to create process metrics for an organization

24
Size-oriented Metrics
• Derived by normalizing quality and/or productivity measures by
considering the size of the software produced
• Thousand lines of code (KLOC) are often chosen as the normalization
value
• Metrics include
• Errors per KLOC - Errors per person-month
• Defects per KLOC - KLOC per person-month
• Dollars per KLOC - Dollars per page of documentation
• Pages of documentation per KLOC

25
Defect Removal Efficiency
• Defect removal efficiency provides benefits at both the project and process
level
• It is a measure of the filtering ability of QA activities as they are applied
throughout all process framework activities
• It indicates the percentage of software errors found before software release
• It is defined as DRE = E / (E + D)
• E is the number of errors found before delivery of the software to the end user
• D is the number of defects found after delivery
• As D increases, DRE decreases (i.e., becomes a smaller and smaller fraction)
• The ideal value of DRE is 1, which means no defects are found after delivery
• DRE encourages a software team to institute techniques for finding as many
errors as possible before delivery

26
Software Project Scheduling
• Project schedule simply means a mechanism that is used to
communicate and know about that tasks are needed and has to be
done or performed and which organizational resources will be given
or allocated to these tasks and in what time duration or time frame
work is needed to be performed.
 40-20-40 Distribution of Effort

Example: 100-day project

6/1 6/4 6/23 7/14 8/2 9/5
P Analysis Design Coding Testing

40 20 40

29
Task Network
• A task set is the work breakdown structure for the project
• Also called an activity network
• It is a graphic representation of the task flow for a project
• It depicts task length, sequence, concurrency, and dependency
• Points out inter-task dependencies to help the manager ensure
continuous progress toward project completion
• The critical path
– A single path leading from start to finish in a task network
– It contains the sequence of tasks that must be completed on schedule if
the project as a whole is to be completed on schedule

30
 Example Task Network

Task F Task G Task H

2 3 5
Task B
3

Task N
2
Task A
3 Task C Task E Task I Task J
7 8 4 5
Task M
0

Task D
5 Task K Task L
3 10

Where is the critical path and what tasks are on it?

31
 Example Task Network
with Critical Path Marked

Task F Task G Task H

2 3 5
Task B
3

Task N
2
Task A
3 Task C Task E Task I Task J
7 8 4 5
Task M
0

Task D
5 Task K Task L
3 10

Critical path: A-B-C-E-K-L-M-N

• Path 1 : A-B-C-E-K-L-M-N: 3+3+7+8+3+10+0+2 = 36- CRITICAL PATH
• Path 2: A-D-E-K-L-M-N : 3+5+8+3+10+0+2 = 31
• Path 3: A-D-E-I-J-M-N: 27
• Path 4: A-D-E-F-G-H-N : 28
• Path 5: A-B-C-E-F-G-H-N:32
• Path 6: A-B-C-E-I-J-M-N: 32
Timeline Chart
• Also called a Gantt chart; invented by Henry Gantt, industrial engineer, 1917
• All project tasks are listed in the far left column
• The next few columns may list the following for each task: projected start
date, projected stop date, projected duration, actual start date, actual stop
date, actual duration, task inter-dependencies (i.e., predecessors)
• To the far right are columns representing dates on a calendar
• The length of a horizontal bar on the calendar indicates the duration of the
task
• When multiple bars occur at the same time interval on the calendar, this
implies task concurrency
• A diamond in the calendar area of a specific task indicates that the task is a
milestone; a milestone has a time duration of zero

Jan Feb Mar Apr May Jun Jul Aug Sep Oct

Task # Task Name Duration Start Finish Pred.

1 Task A 2 months 1/1 2/28 None

2 Milestone N 0 3/1 3/1 1

Timeline chart:
4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3

Task # Task Name Duration Start Finish Pred.

A Establish increments 3 4/1 None
B Analyze Inc One 3 A
C Design Inc One 8 B
D Code Inc One 7 C
E Test Inc One 10 D
F Install Inc One 5 E
G Analyze Inc Two 7 A, B
H Design Inc Two 5 G
I Code Inc Two 4 H
J Test Inc Two 6 E, I
K Install Inc Two 2 J
L Close out project 2 F, K

Task network and the critical path:

 Timeline chart: SOLUTION
4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3

Task # Task Name Duration Start Finish Pred.

A Establish increments 3 4/1 4/3 None
B Analyze Inc One 3 4/4 4/6 A
C Design Inc One 8 4/7 4/14 B
D Code Inc One 7 4/15 4/21 C
E Test Inc One 10 4/22 5/1 D
F Install Inc One 5 5/2 5/6 E
G Analyze Inc Two 7 4/7 4/13 A, B
H Design Inc Two 5 4/14 4/18 G
I Code Inc Two 4 4/19 4/22 H
J Test Inc Two 6 5/2 5/7 E, I
K Install Inc Two 2 5/8 5/9 J
L Close out project 2 5/10 5/11 F, K

Task network and the critical path: A-B-C-D-E-J-K-L

B. Analyze C. Design D. Code E. Test F. Install
Inc One Inc One Inc One Inc One Inc One
3 8 7 10 5
A.
Establish L. Close
Increments out
3 Project
2
G. Analyze H. Design I. Code J. Test K. Install
Inc Two Inc Two Inc Two Inc Two Inc Two
7 5 4 6 2
Earned Value Analysis
• Earned value analysis is a measure of progress by assessing the percent of
completeness for a project
• It gives accurate and reliable readings of performance very early into a
project
• It provides a common value scale (i.e., time) for every project task,
regardless of the type of work being performed
• The total hours to do the whole project are estimated, and every task is
given an earned value based on its estimated percentage of the total

37
Determining Earned Value

• Compute the budgeted cost of work scheduled (BCWS) for each work task
i in the schedule
– The BCWS is the effort planned; work is estimated in person-hours or
person-days for each task
– To determine progress at a given point along the project schedule, the value
of BCWS is the sum of the BCWSi values of all the work tasks that should have
been completed by that point of time in the project schedule
• Sum up the BCWS values for all work tasks to derive the budget at
completion (BAC)
• Compute the value for the budgeted cost of work performed (BCWP)
– BCWP is the sum of the BCWS values for all work tasks that have actually been
completed by a point of time on the project schedule

38
Example 1:
If it is February 12 today, and a task is scheduled to last from February 10 to February
20, then the task should be 20% complete today.
If the Task Budget (Planned Cost) is $10,000, then the BCWS for the task is:
Task BCWS = 20% x $10,000 = $2,000

Example 2:
A project has a budget of $30 000 USD. It starts on June 1 (Project Start Date) and finishes
on December 1(Project Finish Date). Total Project Duration is 183 days (about 6 months).
Suppose that today is September 1, i.e. halfway point of the project when the project should
be 50 % complete according to the plan. At this point BCWS (Budgeted Cost of Work
Scheduled) is as follows:

BCWS = 50% from $30 000 USD = $15 000 USD.

However, in fact, the project has been only 30% complete by September 1, i.e. halfway
point. So project BCWS (Budgeted Cost of Work Scheduled) is as follows:

BCWP= 30% from $30 000 USD = $9 000 USD

Progress Indicators provided
through Earned Value Analysis
• SPI = BCWP/BCWS
– Schedule performance index (SPI) is an indication of the efficiency with which the
project is utilizing scheduled resources
– SPI close to 1.0 indicates efficient execution of the project schedule
• SV = BCWP – BCWS
– Schedule variance (SV) is an absolute indication of variance from the planned schedule
• PSFC = BCWS/BAC
– Percent scheduled for completion (PSFC) provides an indication of the percentage of
work that should have been completed by time t
• PC = BCWP/BAC
– Percent complete (PC) provides a quantitative indication of the percent of work that
has been completed at a given point in time t
• ACWP = sum of BCWP as of time t
– Actual cost of work performed (ASWP) includes all tasks that have been completed by
a point in time t on the project schedule
• CPI = BCWP/ACWP
– A cost performance index (CPI) close to 1.0 provides a strong indication that the
project is within its defined budget
• CV = BCWP – ACWP
– The cost variance is an absolute indication of cost savings (against planned costs) or
shortfall at a particular stage of a project

40 ☺
END OF CHAPTER