Software metrics may be broadly classified as either product metrics (measures of the software product) or process metrics(measures of the software development process).
Metrics can also be classified as Objective (should always result in identical values for a given metric, as measured by two observers) and Subjective metrics.
Metrics can also be classified as Primitive (directly observed), or computed (computed from other metrics)
Product Metrics:
1. Size Metrics:
- LOC (Lines of code) - Can be interpreted differently based on blank lines and comment lines, non-executable statements, multiple statements per line, and multiple lines per statement. The most common definition of LOC seems to count any line that is not a blank or comment line, regardless of the number of statements per line.
- Function Points (Albrecht) - The value of function points is the total of the weighted values: inputs: 4, outputs: 5, inquiries: 4, and master files: 10.
2. Complexity Metrics:
- Cyclomatic Complexity - v(G) = e − n + 2, where e is the number of edges, and n is the number of nodes in the control flow graph wherein each node corresponds to a block of sequential code and each arc corresponds to a branch or decision point in the program.
- Knots - Drawing transfer-of-control lines from statement to statement in a program listing.
3. Quality Metrics:
One can generate long lists of quality characteristics for software—correctness, efficiency, portability, maintainability, reliability, etc. Unfortunately, the characteristics may overlap and conflict with one another; for example, increased portability (desirable) may result in lowered efficiency(Undesired).
- Defect Metrics - number of design changes; number of errors detected by code inspections; number of errors detected in program test; number of code changes required
- Reliability Metrics - mean time to failure (MTTF).
4. Effort Measurement Metrics:
- Testing: Effort spent in a. Requirement Analysis, b. Testware creation - Test Strategy, Test specifications, Checklists etc., c. Training and knowledge sharing, d. Test Automation, e. Test environment setup, f. Userstory testing, g. System Testing, h. Bug Validation
- Development: a. Requirement Analysis, b. Architecture & Design (HLD&LLD), c. Coding, d. Unit Testing, e. Integration, f. Bug fixing
Here are some practical standard Defect Metrics that I use:
BUG TRENDS
1. Find vs Fix Ratio: If plotted with a differnt curve for each priority can help let you know the progress towards release. High priority defects should reduce and lower priority defects should increase when the application is getting stabler. You may do it for individual components or modules to access the stablity for components.
2. Average Age of Defects: If plotted with a differnt curve for each priority can help let you know the right selection of defects by the development teams. You may do it for individual components or modules.
3. Open Defects by Severity/Priority/Developer: Tells about the current status of the project and can be exptrapolated (when project is plainly into bug fixing i.e. no further new implementation) to see the projection for meeting the schedule or schedule variance. Also helps you fix deferal targets.
4. Closed defects by Severity/Priority/Area: In a process driven company, it tells you about the quality of a certain area/project delivery. Detailed analysis can help in accessing areas of improvement upstream.
OTHERS
5. Build Breaks: Is indicative of the quality of the build and BVT process.
6. Test Code Coverage: Is indicative of the quality of the test cases. Can be helpful in acertaining the final quality of coverage using Automation.
7. Percentage Automation & percentage defects found by Automation: Maturity of Automation within the project/module
BUG TRENDS
1. Find vs Fix Ratio: If plotted with a differnt curve for each priority can help let you know the progress towards release. High priority defects should reduce and lower priority defects should increase when the application is getting stabler. You may do it for individual components or modules to access the stablity for components.
2. Average Age of Defects: If plotted with a differnt curve for each priority can help let you know the right selection of defects by the development teams. You may do it for individual components or modules.
3. Open Defects by Severity/Priority/Developer: Tells about the current status of the project and can be exptrapolated (when project is plainly into bug fixing i.e. no further new implementation) to see the projection for meeting the schedule or schedule variance. Also helps you fix deferal targets.
4. Closed defects by Severity/Priority/Area: In a process driven company, it tells you about the quality of a certain area/project delivery. Detailed analysis can help in accessing areas of improvement upstream.
OTHERS
5. Build Breaks: Is indicative of the quality of the build and BVT process.
6. Test Code Coverage: Is indicative of the quality of the test cases. Can be helpful in acertaining the final quality of coverage using Automation.
7. Percentage Automation & percentage defects found by Automation: Maturity of Automation within the project/module
8. Defects by injection phase: Indicator of most problematic phase in software development - Requirement analysis, design, coding, documentation, system test, Acceptance Testing
9. Defects by detection phase: Indicator of most efficient phase in software development, in terms of finding and removing bugs - Requirement analysis, test planning, feature testing, System Testing, Acceptance testing.
No comments:
Post a Comment