Software Metrics – part 2

Mehran Rezaei

Software Metrics

• Objectives– Provide State-of-art measurement of software

products, processes and projects

• Why Measure?– “you cannot control what you cannot measure”

Tom DeMarco

What is Measurement

• measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined unambiguous rules

Example of Entity and Attributes

Types of Metric

• Process metrics are collected across all projects and over long periods of time

• Project metrics enable a software project manager to– Assess the status of an ongoing project– Track potential risks– Uncover problem areas before they go “critical”– Adjust work flow or tasks– Evaluate the project team’s ability to control quality of

software work products

Process Metrics and Software Process Improvement

• We measure the efficacy of a s/w process indirectly, based on outcomes

• Probable outcomes are– Measures of errors uncovered before release of the

s/w– Defects delivered to and reported by end-users– Work products delivered (productivity)– Human effort expended– Calendar time expended– Schedule conformance etc.

Process Metrics and Software Process Improvement - Cont’d

• Error– Some flaw in a s/w engineering work product that

is uncovered before the s/w is delivered to the end-user

• Defect– A flaw that is uncovered after delivery to the end-

user

8

Process attributes

Process characteristic

Key issues

Understandability To what extent is the process explicitly defined and how easy is it to understand the process definition?

Standardization To what extent is the process based on a standard generic process? This may be important for some customers who require conformance with a set of defined process standards. To what extent is the same process used in all parts of a company?

Visibility Do the process activities culminate in clear results, so that the progress of the process is externally visible?

Measurability Does the process include data collection or other activities that allow process or product characteristics to be measured?

Supportability To what extent can software tools be used to support the process activities?

9

Process attributes

Process characteristic

Key issues

Acceptability Is the defined process acceptable to and usable by the engineers responsible for producing the software product?

Reliability Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?

Robustness Can the process continue in spite of unexpected problems?

Maintainability Can the process evolve to reflect changing organizational requirements or identified process improvements?

Rapidity How fast can the process of delivering a system from a given specification be completed?

10

Process measurement

• Wherever possible, quantitative process data should be collected– However, where organisations do not have clearly defined process

standards this is very difficult as you don’t know what to measure. A process may have to be defined before any measurement is possible.

• Process measurements should be used to assess process improvements– But this does not mean that measurements should drive the

improvements. The improvement driver should be the organizational objectives.

11

Process metrics

• Time taken for process activities to be completed– E.g. Calendar time or effort to complete an activity

or process.• Resources required for processes or activities

– E.g. Total effort in person-days.• Number of occurrences of a particular event

– E.g. Number of defects discovered.

Project Metrics

• Used during estimation• Used to monitor and control progress• The intent is twofold

– Minimize the development schedule– Assess product quality on an ongoing basis

• Leads to a reduction in overall project cost

13

Software Measurement

• S/W measurement can be categorized in two ways:

1. Direct measures of the s/w process (e.g., cost and effort applied) and product (e.g., lines of code (LOC) produced, etc.)

2. Indirect measures of the product (e.g., functionality, quality, complexity, etc.)

14

Size-Oriented Metrics

• Lines of Code (LOC) can be chosen as the normalization value

• Example of simple size-oriented metrics– Errors per KLOC (thousand lines of code)– Defects per KLOC– $ per KLOC– Pages of documentation per KLOC

15

Size-Oriented Metrics – Cont’d

• Controversy regarding use of LOC as a key measure– According to the proponents

• LOC is an “artifact” of all s/w development projects• Many existing s/w estimation models use LOC or KLOC

as a key input– According to the opponents

• LOC measures are programming language dependent• They penalize well-designed but shorter programs• Cannot easily accommodate nonprocedural languages• Difficult to predict during estimation

16

Function-Oriented Metrics

• The most widely used function-oriented metric is the function point (FP)

• Computation of the FP is based on characteristics of the software’s information domain and complexity

17

Function-Oriented Metrics – Cont’d

• Controversy regarding use of FP as a key measure– According to the proponents

• It is programming language independent• Can be predicted before coding is started

– According to the opponents• Based on subjective rather than objective data• Has no direct physical meaning – it’s just a number

18

Object-Oriented Metrics

• Number of Scenario scripts• Number of key classes• Number of support classes• Average number of support classes per key class• Number of subsystems

19

Use-Case Oriented Metrics

• The use-case is independent of programming language

• The no. of use-cases is directly proportional to the size of the application in LOC and to the no. of test cases

• There is no standard size for a use-case

20

Web Engineering Project Metrics

• Number of static Web pages• Number of dynamic Web pages• Number of internal page links• Number of persistent data objects• Number of external systems interfaced• Number of static content objects• Number of dynamic content objects• Number of executable functions

21

Metrics for Software Quality

• Goals of s/w engineering– Produce high-quality systems– Meet deadlines– Satisfy market need

• The primary thrust at the project level is to measure errors and defects

22

Defect Removal Efficiency (DRE)

• Can be used at both the project and process level• DRE = E / (E + D), [E = Error, D = Defect]• Or, DREi = Ei / (Ei + Ei+1), [for ith activity]

• Try to achieve DREi that approaches 1