Incident Count per 1k Lines of Code
What is this metric?
Amount of incidents per 1,000 lines of code.
Why is it important?
- Defect drill-down analysis to inform the development of design and code review strategies and to improve the internal QA process
- Assist teams to locate projects/modules with higher defect severity and density, and clean up technical debts
- Analyze critical points, identify good/to-be-improved practices that affect defect count or defect rate, to reduce the amount of future defects
Which dashboard(s) does it exist in
N/A
How is it calculated?
The number of incidents divided by total accumulated lines of code (additions + deletions) in the given data range.
Data Sources RequiredThis metric relies on
- issues collected from Jira, GitHub or TAPD.
- commits collected from GitHub, GitLab or BitBucket.
This metric relies on
- "Issue type mapping" in Jira, GitHub or TAPD's transformation rules page to let DevLake know what type(s) of issues can be regarded as incidents.
- "PR-Issue Mapping" in GitHub, GitLab's transformation rules page to let DevLake know the bugs are fixed by which PR/MRs.
How to improve?
- From the project or team dimension, observe the statistics on the total number of defects, the distribution of the number of defects in each severity level/type/owner, the cumulative trend of defects, and the change trend of the defect rate in thousands of lines, etc.
- From version cycle dimension, observe the statistics on the cumulative trend of the number of defects/defect rate, which can be used to determine whether the growth rate of defects is slowing down, showing a flat convergence trend, and is an important reference for judging the stability of software version quality
- From the time dimension, analyze the trend of the number of test defects, defect rate to locate the key items/key points
- Evaluate whether the software quality and test plan are reasonable by referring to CMMI standard values