Chapter 4Software Process and Project Metrics

Lecture Objectives:

To comprehend:

Basic concepts of software metrics

Process Metrics

Project Metrics

Normalization of metrics

Measurement & Metrics

... collecting metrics is too hard ... ... collecting metrics is too hard ...

it's too time-consuming ... it's too it's too time-consuming ... it's too

political ... it won't prove anything ...political ... it won't prove anything ...

Anything that you need to Anything that you need to quantify can be measured in quantify can be measured in some way that is superior to some way that is superior to not measuring it at all ..not measuring it at all ..

Tom GilbTom Gilb

Why do we Measure?

• To characterize• To evaluate• To predict• To improve

Important Concepts

• Measure (A quantitative indication of an attribute)• Measurement (Act of measure)• Metrics (A quantitative measure of the degree to

possess a given attribute)• Indicator (A metric or combination of metrics

which provide an insight)

Steps to create a metric

• Define the goal of a metric

• Identify the requirements of a metric

• Determine the baseline figure of the metric

• Review the metric created

Process as controllable factor

Product

TechnologyPeople

Process

Business Conditions

Customer Characteristics

Development Enviornment

Metrics Guidelines• Use common sense and organizational sensitivity when

interpreting metrics data.• Provide regular feedback to the individuals and teams who

have worked to collect measures and metrics.• Don’t use metrics to appraise individuals.• Work with practitioners and teams to set clear goals and

metrics that will be used to achieve them.• Never use metrics to threaten individuals or teams.• Metrics data that indicate a problem area should not be

considered “negative.” These data are merely an indicator for process improvement.

• Don’t obsess on a single metric to the exclusion of other important metrics.

Process Metrics - strategic

• majority focus on quality achieved as a consequence of a repeatable or managed process

• statistical SQA data– error categorization & analysis

• defect removal efficiency– propagation from phase to phase

• reuse data

• The efficacy of a software process can be measured indirectly

• Process metrics are also derived by measuring the characteristics of specific software engineering tasks

• There are “private and public” uses for different types of process data

• The derivation of simple indicators give way to a more rigorous approach “Statistical Software Process Improvement (SSPI)”

Process Metrics:

Project Metrics - tactical

• The first application of project metrics occurs during estimation

• Metrics collected from the past projects are used as a basis for current projects

• As project proceeds, measures of effort and calendar time expended compared to the original estimates

• This data is used by the Project Manager to monitor and control the progress

Project Metric

• Effort/time per SE task• Errors uncovered per review hour• Scheduled vs. actual milestone dates• Changes (number) and their characteristics• Distribution of effort on SE tasks

Project Metric

• The intent of project metric is twofold:

1) They are used to minimize the development schedule and mitigate problems and risks

2) They are used to assess and improve quality

• Every Project should measure:o Inputso Outputso Results

Normalization for Metrics

Normalized data are used to evaluate the process and the product (but never individual people)

size-oriented normalization —the line of code approach function-oriented normalization —the function point approach

Size Oriented Metrics

Project LOC Effort $(000) Pp.doc Errors Defects People

alpha 12100 24 168 365 134 29 3

beta 27200 62 440 1224 321 86 5

gamma 20200 43 314 1050 256 64 6

Typical Size-Oriented Metrics

• errors per KLOC (thousand lines of code)• defects per KLOC• $ per LOC• page of documentation per KLOC• errors / person-month• LOC per person-month• $ / page of documentation

LOC Based Estimation

An Example of LOC-Based Estimation

Function Estimated LOC

User interface and control facilities (UCIF) 2300

Two-dimensional geometric analysis 5300

Three-dimensional geometric analysis 6800

Database management 3350

Computer graphics display facilities 4950

Peripheral control function 2100

Design Analysis Modules 8400

Estimated lines of code 33200

How you get estimated LOC

3D geometric Analysis Function:

Optimistic LOC = 4600

Most Likely LOC= 6900

Pessimistic LOC= 8600

Estimated LOC For 3D = (Opt. + 4 Most Likely + Pessi.) / 6

= (4600 + 4 (6900) + 8600) / 6 = 6800 LOC

Estimated LOC = 33200

Suppose

Organizational Average Productivity = 620 LOC / pm

Labor Rate = Rs. 8000 / month

Find cost per LOC, Total Project Cost, and Estimated effort?

Cost per LOC = Labor Rate / Productivity = 8000 / 620 = Rs. 12.90 /LOC

Total Project Cost = Estimated LOC * cost Per LOC = 33200 * 12.90

= Rs. 428280

Estimated Effort = Estimated LOC / Productivity = 33200 / 620 = 54 PM

Typical Function-Oriented Metrics

• errors per FP (thousand lines of code)• defects per FP• $ per FP• pages of documentation per FP• FP per person-month

Analyze information domain of the application and develop counts

Weight each count by assessing complexity

Assess influence of global factors that affect the application

Compute function points

Establish count for input domain and system interfaces

Assign level of complexity or weight to each count

Grade significance of external factors, F such as reuse, concurrency, OS, ...

FP = Count Total * [ 0.65 + 0.01 * (Fi)]

i

Computing Function Points

Analyzing the Information Domain

complexity multiplier

function points

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces

measurement parameter

3 4 3 7 5

countweighting factor

simple avg. complex

4 5 4 10 7

6 7 6 15 10

= = = = =

count-total

X X X X X

Taking Complexity into Account

Factors are rated on a scale of 0 (not important) to 5 (very important):

data communications distributed functions heavily used configuration transaction rate on-line data entry end user efficiency

on-line update complex processing installation ease operational ease multiple sites facilitate change

FP = Count Total * [ 0.65 + 0.01 * Σ(Fi) ]

Why Opt for FP Measures?independent of programming language uses readily countable characteristics of the "information domain" of the problem does not "penalize" inventive implementations that require fewer LOC than others makes it easier to accommodate reuse and the trend toward object-oriented approaches

Measuring Quality

• Correctness — the degree to which a program operates according to specification

• Maintainability—the degree to which a program is agreeable to change

• Integrity—the degree to which a program is resistant to outside attack (“Threat and Security”)

• Usability—the degree to which a program is easy to use