chapter04 soft process metrics rpl

8/10/2019 Chapter04 soft process metrics RPL

1/18

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach,5/e and areprovided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001

Chapter 4Software Process and Project Metrics


2/18


Measurement & Metrics

... collecting metrics is too hard ...

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

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

Anyth ing that you need to

quant i fy can be measured in

som e way that is super ior to

no t measu ring it at all ..

Tom Gilb


3/18


Why do we Measure?

To characterize

To evaluate

To predict

To improve


4/18


A Good Manager Measures

measurement

What do we

use as a

basis?

size?

function?

project metricsprocess metrics

process

product

product metrics


5/18


Process Metrics

majority focus on quality achieved as aconsequence of a repeatable or managedprocess

statistical SQA data error categorization & analysis

defect removal efficiency propagation from phase to phase

reuse data


6/18


Project Metrics

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


7/18


Product Metrics

focus on the quality of deliverables

measures of analysis model

complexity of the design internal algorithmic complexityarchitectural complexitydata flow complexity

code measures (e.g., Halstead)

measures of process effectivenesse.g., defect removal efficiency


8/18


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.

Dont use metrics to appraise individuals.

Work with practitioners and teams to set clear goals andmetrics that will be used to achieve them.

Never use metrics to threaten individuals or teams.

Metrics data that indicate a problem area should not beconsidered negative. These data are merely an indicator forprocess improvement.

Dont obsess on a single metric to the exclusion of other

important metrics.


9/18


Normalization for Metrics

Normalized data are used to evaluate the process

and the product (but never individual people)

size-oriented normalizationthe line of code approach

function-oriented normalizationthe function pointapproach


10/18


Typical Size-Oriented Metrics

errors per KLOC (thousand lines ofcode)

defects per KLOC

$ per LOC

page of documentation per KLOCerrors / person-month

LOC per person-month

$ / page of documentation


11/18


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


12/18


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 thatrequire fewer LOC than others

makes it easier to accommodate reuse and thetrend toward object-oriented approaches

C ti F ti P i t


13/18


Computing Function PointsAnalyze informationdomain of theapplicationand develop counts

Weight each count byassessing complexity

Assess influence ofglobal factors that affectthe application

Computefunction points

Establish countfor input domain andsystem interfaces

Assign level of complexity or weightto each count

Grade significance of external factors, Fsuch as reuse, concurrency, OS, ...

degree of influence: N = Fi

complexity multiplier: C = (0.65 + 0.01 x N)

function points = (count x weight) x C

where:

i


14/18


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


15/18


Taking Complexity into Account

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

data communicationsdistributed functions

heavily used configurationtransaction rateon-line data entryend user efficiency

on-line updatecomplex processing

installation easeoperational easemultiple sitesfacilitate change


16/18


Measuring Quality

Correctness the degree to which a programoperates according to specification

Maintainabilitythe degree to which aprogram is amenable to change

Integritythe degree to which a program isimpervious to outside attack

Usabilitythe degree to which a program iseasy to use


17/18


Defect Removal Efficiency

DRE = (errors) / (errors + defects)

whereerrors= problems found before release

defects= problems found after release


18/18


Managing Variation

0

1

2

3

4

5

6

1 3 5 7 9 11 13 15 17 19

Project s

Er,Erro rs fo u nd /re vie w

ho u r

The mR Control Chart

chapter04 soft process metrics rpl

Documents