1. 1 Estimating Software Development Using Project Metrics

2. 2 Project Estimating  It is Possible to Estimate Software Projects Accurately  Accurate Estimates Take HISTORY and TIME  Estimation Procedure Must Be Formal Standards  Accurate Estimates Need a Quantitative Tool  Estimates Must be Redone After Every Life Cycle Phase Once All Stakeholders agree on estimation procedures, negotiations can involve Inputs (features & resources) NOT Outputs (time & dollars)

3. 3 Activities to be Estimated Obvious  Planning  Design  Coding  Procedures  Testing  Conversion  Documentation  Operations  Maintenance Not Obvious User/Customers Interaction Prototype Demonstrations Reviews and Approvals Problem/Design Fixes Prior Project Support Documentation redoes Training, vacations, sick,...

4. 4 Danger Signs  Estimates the Project Team Does NOT Accept  Estimates Your Experts Do Not Accept  Estimates that Include Overtime  Estimates Assuming Over 80% Utilization  Estimates Without Detailed Task Plans  Estimates More Than A “Month” Old  Estimates NOT UNDER CHANGE CONTROL

5. 5 Measurement & Metrics... collecting metrics is too hard... it's too time-consuming... it's too political... it won't prove anything... Anything that you need to quantify can be measured in some way that is superior to not measuring it at all.. Tom Gilb

6. 6 Why do we Measure?  To characterize  To evaluate  To predict  To improve

7. 7 A Good Manager Measures measurement What do we use as a basis? size? size? function? function? project metrics process metrics process product product metrics

8. 8 Process Metrics  majority focus on quality achieved as a consequence of a repeatable or managed process  statistical SQA data  error categorization & analysis  defect removal efficiency  propagation from phase to phase  reuse data

9. 9 Project Metrics  Effort/time per development task  Errors uncovered per review hour  Scheduled vs. actual milestone dates  Changes (number) and their characteristics  Distribution of effort on development tasks

10. 10 Product Metrics  focus on the quality of deliverables  measures of analysis model  complexity of the design  internal algorithmic complexity  architectural complexity  data flow complexity  code measures (e.g., Halstead)  measures of process effectiveness  e.g., defect removal efficiency

11. 11 Metrics Guidelines  Use common sense and organizational sensitivity when interpreting metrics data.  Provide regular feedback to the individuals and teams who have worked to collect measures and metrics.  Don’t use metrics to appraise individuals.  Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.  Never use metrics to threaten individuals or teams.  Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.  Don’t obsess on a single metric to the exclusion of other important metrics.

12. 12 Normalization for Metrics

13. 13 Typical Size-Oriented Metrics  errors per KLOC (thousand lines of code)  defects per KLOC  $ per LOC  page of documentation per KLOC  errors / person-month  LOC per person-month  $ / page of documentation

14. 14 Typical Function-Oriented Metrics  $ per FP  FP per person-month  errors per Function Point (FP)  defects per FP  pages of documentation per FP

15. 15 Why Opt for FP Measures?

16. 16 Computing Function Points

17. 17 Analyzing the Information Domain

18. 18 Taking Complexity into Account

19. 19 Typical Calculation FP Count300 Complexity Factor 1.2 FP (Estimated) 360 Productivity Factor (measured) 8 FP/pm $/pm $8,000 $/FP $1,000 Estimated Cost of Project $360,000

20. 20 Program Size/Function Point Programming Language LOC/FP C128 C128 C++ 64 C++ 64 COBOL106 COBOL106 Visual Basic 32 Visual Basic 32 Smalltalk 22 Smalltalk 22 PowerBuilder 16 PowerBuilder 16 SQL 12 SQL 12

21. 21 Measuring Quality  Correctness — the degree to which a program operates according to specification  Maintainability—the degree to which a program is amenable to change  Integrity—the degree to which a program is impervious to outside attack  Usability—the degree to which a program is easy to use

22. 22 Defect Removal Efficiency DRE = (errors) / (errors + defects) where errors = problems found before release defects = problems found after release

23. 23 Managing Variation The mR Control Chart