Software Process and Project Metrics 1 Normalization for

Software Process and Project Metrics 1

Normalization for Metrics 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 person-month $ / page of documentation 3

Why Opt for Function Point (FP) Measures? 4

Analyzing the Information Domain 5

Taking Complexity into Account 6

LOC per Function Point Assembly language C COBOL Fortran C++ Visual Basic Smalltalk SQL 320 128 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 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 CS 499 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