1. 1 Software Process and Project Metrics

2. 2 Normalization for Metrics

3. 3 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. 4 Why Opt for Function Point (FP) Measures?

5. 5 Analyzing the Information Domain

6. 6 Taking Complexity into Account

7. 7 LOC per Function Point  Assembly language 320  C 128  COBOL 106  Fortran 106  C++ 64  Visual Basic 32  Smalltalk 22  SQL 12

8. 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. 9 (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. 10 Partitioning Tasks  Perfectly partitionable task  Unpartitionable task  Partitionable task requiring communication  Task with complex interelelationships

11. 11 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. 12 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. 13 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. 14 You still may be late!

15. 15 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. 16 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. 17 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. 18 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. 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