Software Process and Project Metrics

1
Software Process and Project Metrics
0
2
Normalization for Metrics
0
3
Typical Size-Oriented Metrics
0

• 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

4
Why Opt for Function Point (FP) Measures?
0
5
Analyzing the Information Domain
0
6
Taking Complexity into Account
0
7
LOC per Function Point
0

• Assembly language 320
• C
  128
• COBOL
  106
• Fortran
  106
• C
  64
• Visual Basic
  32
• Smalltalk
  22
• SQL
  12

8
Criticism of Function Point measurement

• The weighting factor makes the FP number highly
  dependent on the developers experience
• The developer can essentially set the FP number
  to what the developer wants

9
(All? Most?) Projects are Late
0

• 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!

10
Partitioning Tasks
0

• Perfectly partitionable task
• Unpartitionable task
• Partitionable task requiring communication
• Task with complex interelelationships

11
Programmers are Optimists
0

• All will go well (Murphys Law doesnt 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)

12
Brooks Scheduling Rule of Thumb
0

• 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

13
Piwowarski Scheduling Algorithm
0

• 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 .

14
0

• You still may be late!

15
Scheduling Example
0

• 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

16
Programmer Productivity
0

• 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

17
Productivity
0

• 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

18
Brooks Advice for Late Projects
0

• DONT ADD PERSONS TO A LATE PROJECT
• But you can
• Reschedule (but take no small slips) Cant be
  done for your project
• Trim the task (drop the unneeded features - the
  bells and whistles)

19
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