Software Process and Project Metrics
1
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
2
Typical Size-Oriented Metrics
errors per KLOC (thousand lines of code)
or FP
defects per KLOC or FP
$ per LOC or FP
page of documentation per KLOC or FP
errors / person-month
LOC per person-month
$ / page of documentation
3
Why Opt for Function Point (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
4
Analyzing the Information Domain
m easurement param eter
count
weighting factor
s im ple avg. com plex
num ber of user inputs
X 3
4
6
=
num ber of user outputs
X 4
5
7
=
num ber of user inquiries
X 3
4
6
=
num ber of files
X 7
10
15
=
num ber of ext.interfaces
X 5
7
10
=
count-total
complexity multiplier
function points
5
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
6
LOC per Function Point
Assembly language
C
COBOL
Fortran
C++
Visual Basic
Smalltalk
SQL
320
128
106
106
64
32
22
12
7
Criticism of Function Point
measurement
The weighting factor makes the FP number
highly dependent on the developer’s
experience:
The developer can essentially set the FP
number to what the developer wants
8
(All? Most?) Projects are Late
Project estimation is difficult
Effort is not progress
Management sets unrealistic goals
Schedules poorly monitored
Brooks law: adding persons to a late project
makes it later
NOTE: Your project will note be late!
9
Partitioning Tasks
Perfectly partitionable task
Unpartitionable task
Partitionable task requiring communication
Task with complex interelelationships
10
Programmers are Optimists
All will go well (Murphy’s Law doesn’t apply to our
project)
Each task will only take as long as it ought to
take
No one (on our project) will ever get sick, take
vacation time, or have family emergencies
Programmers get to spend all their time
programming (never in meetings, conferences,
travel)
11
Brooks Scheduling Rule of Thumb
1/3 Planning
1/6 Coding
 1/4 component and early system test
 1/4 system test
40-20-40 rule (40% design, 20% code, 40% test)
“Testing is usually the most mis-scheduled part of
programming”
12
Piwowarski Scheduling Algorithm
Estimate all tasks assuming the experience of the
person doing it (not yourself)
Add 25% to this for overhead (meetings,
vacation, travel, etc.)
Add 25% of the previous step for contingency
(nothing ever goes right)
If you do the above ….
13
You still may be late!
14
Scheduling Example
All tasks to be done by your team (including
testing documentation, etc.) 160 PM
Add 25% for overhead 200 PM
Add 25% for contingency 250 PM
The final number is over 50% greater than the
original estimate of “actual” work that needs to be
done
15
Programmer Productivity
Is lower (in LOC per PM) than you think!
Studies and models (Brooks, Pressman) vary
widely
Some projects at IBM used a rule of thumb of
100-200 lines per person month
16
Productivity
Reasons for low LOC/PM: (see Programmers are
Optimists)
Productivity highly dependent on the task:
 System Code vs. application code
 New programs vs. modification to current programs
 Experience of programmers
 10 to 1 difference in programmer productivity
No “formula” will work
You must make adjustments for your project
17
Brooks Advice for Late Projects
DON’T ADD PERSONS TO A LATE PROJECT
But you can:
Reschedule (but “take no small slips”) – Can’t be
done for your project
Trim the task (drop the unneeded features - the
“bells and whistles”)
18
What can be done for
CS499 projects
START ON TIME AND KEEP TO YOUR
SCHEDULE
Have project checkpoints during the semester to
keep you to your schedule
Drop the “bells and whistles” (but check with your
customer first), BUT:
Make sure essential customer requirements are
met
19