| Software Metrics |
Why Metrics?
- You can’t track project status meaningfully unless you know the actual effort and time spent on each task compared to your plans.
- You can’t sensibly decide whether your product is stable enough to ship unless you’re tracking the rates at which defects are found and fixed.
- You can’t quantify how well your new development processes are working without some measure of your current performance and a baseline to compare against.
- Metrics help you better control your software projects and learn more about the way your organization works.
|
Any successful improvement program must have a way to measure its effectiveness.
Software measurement |
- Quantifies Work effort and Product size.
- Tracks Project status objectively.
- Provides a basis for estimates.
- Track and analyze defects.
- Compares Quality performance
- Allows to experimentally validating best practices.
|
| Software measurement is a challenging but essential component of a healthy and capable software engineering culture |
|
| What to Measure? |
- Identify what to measure - based on Goals.
- Define How to measure.
- Define the Procedure.
- Define Instruments to collect data.
- Define Responsibility for collecting.
- Define Procedure for analyzing and reporting.
- Define Frequency
|
| Some of the most essential metrics |
| Product size |
- Count lines of code.
- Function points.
- Object classes.
- Number of requirements, or GUI elements.
|
| Estimated and actual Schedule |
- (Calendar time) and effort (labor hours):
- Track for individual tasks,
- Project milestones
- Overall product development
|
| Work effort distribution: |
| Record the time spent in the following activities |
- Project management
- Requirements specification
- Design
- Coding
- Testing
- Maintenance
|
| Defects: |
- Defects found during testing
- Defects found by customers
- Defect type
- Defect severity
- Defect status (open or closed)
|
Processes determine the quality of the product
Product improves only when the process improves
Metrics for Software Developers, Teams, and Organizations |
| Group |
Appropriate Metrics |
| Individual Developers |
- Work effort distribution
- Estimated vs. actual task duration and effort
- Code covered by unit testing
- Number of defects found by unit testing
- Code and design complexity
|
| Project Teams |
- Product size
- Work effort distribution
- Requirements status (number approved, implemented, and verified)
- Percentage of test cases passed
- Estimated vs. actual duration between major milestones
- Estimated vs. actual staffing levels
- Number of defects found by integration and system testing
- Number of defects found by inspections
- Defect status
- Requirements stability
- Number of tasks planned and completed
|
Development Organization
|
- Released defect levels
- Product development cycle time
- Schedule and effort estimating accuracy
- Reuse effectiveness
- Planned and actual cost
|
|
| If no process exists to gather, analyze and act upon metrics then organizations have no way to monitor and achieve progress toward their goals. |
| Metrics Etiquette |
- Metrics in the organization should not be used to measure individuals
- Clear goals to be set to define Metrics
- One metric should not be emphasized to the exclusion of other metric
- Focus on project data on improving process
|
|
| |
