1 / 23

Estimating Software Development Using Project Metrics

Estimating Software Development Using Project Metrics. 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

caesar-owen
Download Presentation

Estimating Software Development Using Project Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Estimating Software Development Using Project Metrics

  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. 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. 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. 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. Why do we Measure? • To characterize • To evaluate • To predict • To improve

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

  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. 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. 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. 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. Normalization for Metrics

  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. Typical Function-Oriented Metrics • $ per FP • FP per person-month • errors per Function Point (FP) • defects per FP • pages of documentation per FP

  15. Why Opt for FP Measures?

  16. Computing Function Points

  17. Analyzing the Information Domain

  18. Taking Complexity into Account

  19. Typical Calculation FP Count 300 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. Program Size/Function Point Programming Language LOC/FP C 128 C++ 64 COBOL 106 Visual Basic 32 Smalltalk 22 PowerBuilder 16 SQL 12

  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. Defect Removal Efficiency DRE = (errors) / (errors + defects) where errors = problems found before release defects = problems found after release

  23. Managing Variation The mR Control Chart

More Related