Software metrics and estimation lecture 1

1. Software metrics and
estimation
Engr. Faiz ul haque Zeya
Sr. Associate professor
SE department. BUKC

2. Introduction of course “Software metrics and
estimation”
• Software metrics is about metrics which are related to measurement
of software product, project or process attributes for their
improvements.

3. Why measure
• A measure is a number or a quantity that records a directly
observable value or performance.
• • To indicate the quality of the product
• • To assess the productivity of the people who produce the product
• • To assess the benefits derived from new software engineering
methods and tools
• • To form a base line for estimation
• • To help justify requests for new tools or additional training

4. Metric vs measurement
• Measurement is the quantity observed of a particular attribute.
• Metrics is derived or calculated from measurement
• Measurement is hour of work and errors in code.
• Metrics is error/hour calculated from measurement.

5. Why software metrics
• Help software engineers to gain insight into the design and
construction of the software.
• Focus on specific attributes of software engineering work products
resulting from analysis, design, coding, and testing.
• Provide a systematic way to assess quality based on a set of clearly
defined rules.
• Provide an “on-the-spot” rather than “after-the-fact” insight into the
software development

6. Characteristics of Good Metrics
• Intuitive: mathematical values should have natural values with an
intuitive scale. For example, a metric to measure quality should be high
for good quality software and low for bad quality software.
• Consistent and objective: the metric should have the same values no
matter who computes it.
• Easily obtainable: should be automatically computable in a reasonable
amount of time.
• Valid: the metric should measure what it is intended to measure.
• Robust: relatively insensitive to insignificant changes in the process or
product

7. Uses of metrics.
• Minimize a schedule.
• Stay on schedule.
• Reduce the number of bugs.
• Predict the number of bugs that will arise.
• Make bug fixing easier.
• Assess ongoing quality.
• Improve finished results.
• Improve maintenance.
• Detect risks such as schedule slips and adjust staffing and work effort to address
them.

8. Scales of metrics
• Nominal Scale: categorical labels with no notion of ordering among the
categories. Example: classify faults as arising from requirements, design, or
code.
• Ordinal Scale: categorical labels with ordering. Example: high, medium, low
priority for defects.
• Interval Scale: preserves ordering and differences between items, so addition
and subtraction are possible. Example: temperature.
• Ratio Scale: preserves ordering, differences, and ratios. Measurement must
start at zero and increase at equal intervals. Example: length.
• Absolute Scale: measurements made by counting elements. All arithmetic
operations possible. Example: LOC.

9. Nominal scale
• As an example of nominal data, one can measure the type of program
being produced by placing it into a category of some kind—database
program, operating system, etc. For such data, we cannot perform
arithmetic operations of any type or even rank the possible values in any
“natural order.” The only possible operation is to determine whether
program A is of the same type as program B. Such data are said to have a
nominal scale, and the particular example given can be an important
parameter in a model of the software development process. The data
might be considered either subjective or objective, depending upon
whether the rules for classification allow equally qualified observers to
arrive at different classifications for a given program

10. Ordinal scale
• Ordinal data, by contrast, allow us to rank the various data values,
although differences or ratios between values are not meaningful. For
example, programmer experience level may be measured as low,
medium, or high. (In order for this to be an objective metric, one
must assume that the criteria for placement in the various categories
are well defined, so that different observers always assign the same
value to any given programmer.)

11. Interval scale
• Data from an interval scale can not only be ranked, but also can
exhibit meaningful differences between values. McCabe’s complexity
measure might be interpreted as having an interval scale. Differences
appear to be meaningful; but there is no absolute zero, and ratios of
values are not necessarily meaningful. For example, a program with
complexity value of 6 is 4 units more complex than a program with
complexity of 2, but it is probably not meaningful to say that the first
program is three times as complex as the second.

12. Ratio scale
• Some data values are associated with a ratio scale, which possesses
an absolute zero and allows meaningful ratios to be calculated. An
example is pro gram size, in lines of code (LOC). A program of 2,000
lines can reasonably be interpreted as being twice as large as a
program of 1,000 lines, and pro- grams can obviously have zero length
according to this measure.