2/26/2011 Object Oriented Software Engg

2/26/2011 Object Oriented Software Engg
Software Process and Project

Metrics
• Outline:
• In the Software Metrics Domain:
o product metrics
o project metrics
o process metrics
• Software Measurement
o size-oriented metrics
o function-oriented metrics
• Metrics for Software Quality

Measure, Metrics, and Indicator
• Measure -- Provides a quantitative indication of the
extent, amount, dimensions, capacity, or size of
some product or process attribute.
• Metrics -- A quantitative measure of the degree to
which a system, component, or process possesses a
• given attribute.
Software Metrics -- refers to a broad range of
measurements for computer software.
• Indicator -- a metric or combination of metrics that
provide insight into the software process, a software
project, or the product itself.

Process Metrics and Software
Process Improvement
Project
Customer Business
characteristics conditions
Developmen
People t Technolog
environment y

In the Process and Project
Domains
• Process Indicator
• enable insight into the efficacy of an existing process
• to assess the current work status
• Goal -- to lead to long-term software process
• improvement
Project Indicator
• assess the status of an ongoing project
• track potential risks
• uncover problem areas before they “go critical”
• evaluate the project team’s ability to control the product
quality

Measurement
• What to measure?
• errors uncovered before release
• defects delivered to and reported by end users
• work products delivered
• human effort expended
• calendar time expended
• schedule conformance
• At what level of aggregation?

• By team?
• Individual?
• Project?
Privacy Issues
• Should they be used for personnel evaluation?
• Some issues?
• Privacy?
• Is total assignment being measured?
• Are the items being measured the same as for other
individuals being measured?
• Are the conditions of measurement the same across
individuals?
• However, they can be useful for individual improvement.

Use of Software Metrics
(process maturity)
• Use common sense and organizational sensitivity.
• Provide regular feedback to individuals and teams.
• Don’t use metrics to appraise individuals.
• Set clear goal and metrics.
• Never use metrics to threaten individuals or teams
• Problems != negative. These data are merely an
indicator for process improvement.
• Don’t obsess on a single metric to the exclusion of other
important metrics.
• Do not rely on metrics to solve your problems.
• Beware of people performing to metrics rather than
product quality or safety.
Example of Defect Analysis
(fish bone diagram)
missing ambiguous
specification
defects
wrong customer queried
customer gave
wrong infor.
inadequate inquiries
used outdated
information incorrect changes

Project Metrics
• Software Project Measures Are Tactical not
strategic
o used by a project manager and a software team
• The
o toIntent
adaptof Project
project Metrics
work Is Twofold
flow and technical activities
o to minimize the development schedule to avoid
delays and mitigate potential problems and risks
o to assess project quality on an ongoing basis and
modify the technical approach to improvement quality
• Production Rates(Inputs,work products and
effectiveness.)
o pages of documentation
o review hours
o function points
o delivered source lines
o errors uncovered
2/26/2011 Object Orientedduring SW engineering
Software Engg
Software Metrics
• Direct measures
o Cost and effort applied (in SEing process)
o Lines of code(LOC) produced
o Execution speed
o CPU utilization
o Memory size
o Defects reported over certain period of time
• Indirect Measures
o Functionality, quality, complexity, efficiency,
reliability, maintainability.

Software Measurement
• Size-Oriented Metrics
• are derived by normalizing quality and/or productivity
measures by considering the “size” of the software that
has been produced.
• lines of code often as normalization value.
project LOC effort $(000) pp.doc errors defects people

alpha 12,100 24 168 365 134 29 3
beta 27,200 62 440 1224 321 86 5
gamma 20,200 43 314 1050 256 64 6
.... ... ... ... ...

Typical Size-Oriented Metrics
• Errors per KLOC
• Defects per KLOC( QA when uncovers the errors)
• Expenditure per KLOC
• Pages of documentation per KLOC
• Errors per person month
• LOC per person month
• Expenditure per page of documentation

Software Measurement
• Function-Oriented Metrics
• use “functionality” to measure(derived from direct
• mesrs)
derived from “function point”
• using an empirical relationship
• based on countable (direct) measure of SW information
domain and assessments of software complexity
• Use of Function-Oriented Metrics
• Measuring scale of a project
• Normalizing other metrics, e.g., $/FP, errors/FP

Weighting Factor
measurement parameter count simple average complex
# of user inputs * 3 4 6 =
# of user outputs * 4 5 7 =
# of user inquiries * 3 4 6 =
#r of files * 7 10 15 =
# of external interfaces * 5 7 10 =
count_total

Computing function points
Rate each factor on a scale of 0 to 5
123456
no influence incidental moderate average significant essential
1. does the system require reliable backup and recovery?

2. are data communications required?
3. are there distributed processing functions?
4. is performance critical?
5. will the system run an existing ,heavily utilized operational environment?
6.does system requires online data entry?
7.does online data entry req. input transaction to be build on multiple
screens ?

Function point calculation
8. Are master files updated online ?
9.are I/ps , O/ps, files and inquires complex?
10.Is essential processing complex?
11.is code reusable?
12.are conversion and installation included in
design?
13.is system supports multiple installations ?
14.is application designed to facilitate change and
ease of use by user?

Function-Oriented Metrics
FP = count_total * [0.65 + 0.01 * sum of Fi]
Outcome:normalized measure as productivity , quality and
errors per FP
defects per FP
expenditure per FP
page of documentation per FP
FP per person_month

Function Point Extensions
• Function Points emphasizes “data dimension”
• Transformations added to capture “functional
• dimension”
Transitions added to capture “control dimension”

Metrics for Software Productivity
• LOC and FP Measures Are Often Used to Derive
Productivity Metrics
• 5 Important Factors That Influence SW Productivity
• people factors
• problem factors
• process factors
• product factors
• resource factors

Measures of Software
Quality
• Correctness
• is the degree to which the software performs its
required function. the most common measure for
correctness is defects per KLOC
• Maintainability
• the ease that a program can be corrected
• adapted if the environment changes
• enhanced if the customer desires changes in
requirements
• based on the time-oriented measure mean time to
change.

Measures of Software Quality (Cont’d)
• Integrity
• to measure a system’s ability to withstand attacks (both
accidental and intentional) on its security threat and
security are defined
• integrity = sum [ 1 - threat * (1- security)]
• Usability - an attempt to quantify “user friendliness”
• physical/intellectual requirement to learn
• time required to become moderately efficient
• the net increase in productivity
• user attitudes toward system

Defect Removal Efficiency
• A Quality Metric That Provides Benefit at Both the
Project and Process Level
• DRE = E / ( E + D )
E = # of errors found before delivery of the software to the
end user
D = # of defects found after delivery
• More generally,
DREi = Ei / ( Ei + Ei+1 )
Ei = # of errors found during SE activity i

Summary
• Metrics are a tool which can be used to improve the
productivity and quality of the software system
• Process metrics takes a strategic view to the
effectiveness of a software process
• Project metrics are tactical that focus on project work
flow and technical approach
• Size-oriented metrics use the line of code as a
normalizing factor
• Function-oriented metrics use function points
• Four quality metrics------correctness, integrity,
maintainability, and usability were discussed

METRICS
• CLCS Metrics Philosophy
Phase 1: Provide a mandatory, nearly automated, metrics
foundation to track lines of code and errors.
Phase 2: Provide additional high-return metrics with recognized
value.
 Schedule metrics (milestones)
 Additional S/W Problem metrics (actuals, trends, prediction)
 Defect correction metrics
 Run-time analysis metrics (McCabe tools, automated,
COTS)
Phase 3: Be driven to additional metrics only by absolute need.

METRICS

Identify your business goals.
Identify what you want to know or learn
Identify your sub goals
Identify the entities and the attributes related to sub goals.
Formalize your measurement goals
Identify quantifiable questions and indicators you will use
to measure goals
Identify data elements reqd. for construction of indicators
Define measures to be used to make it operational
Identify your actions
Prepare plan to implement measures

2/26/2011 Object Oriented Software Engg

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2/26/2011 Object Oriented Software Engg

Încărcat de

Drepturi de autor:

Formate disponibile

2/26/2011 Object Oriented Software Engg

Software Process and Project

• Metrics for Software Quality