Software Process and Project Metrics

1. 0 Software Process and Project Metrics

2. 0 Normalization for Metrics

3. 0 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

4. Why Opt for Function Point (FP) Measures? 0

5. Analyzing the Information Domain 0

6. 0 Taking Complexity into Account

7. 0 LOC per Function Point • 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 developer’s experience: The developer can essentially set the FP number to what the developer wants

9. 0 (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!

10. 0 Partitioning Tasks • Perfectly partitionable task • Unpartitionable task • Partitionable task requiring communication • Task with complex interelelationships

11. 0 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)

12. 0 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”

13. 0 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 ….

14. 0 You still may be late!

15. 0 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

16. 0 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

17. 0 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

18. 0 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”)

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