Name |
Technical Debt Plugin |
Authors |
Freddy Mallet, Olivier Gaudin |
Jira |
http://jira.codehaus.org/browse/SONARPLUGINS/component/13850 |
Most Recent Version |
0.2 |
State |
Under development |
License |
LGPL v3 |
Sources |
|
Download |
Latest stable : technical-debt-0.2.jar |
Compatibility with Sonar
Plugin versions |
1.8 |
1.9 |
1.10 |
|---|---|---|---|
0.1 |
|
|
|
0.2 |
|
|
|
0.3-SNAPSHOT |
|
|
|
Description / Features
The Technical Debt plugin is an unified metric combining quality axes (Duplication, Violations, Complexity, Coverage, Documentation).
The basic principle is to calculate how much it would cost to clean all defects from every axis (no violation, no duplication...) : that means reimbursing the Technical Debt.
The plugin contains 4 indicators :
- The cost of the debt in $$
- The cost of the debt in man days
- The debt ratio (%)
- The repartition of the debt across the axis
A note indicates at the bottom of repartition if coverage measure was not available (light projects).

Objectives of the plugin
- give helicopter view on the global quality of a project
- compare projects
- understand where the cost to improve lies
- communication tool with outside to explain why quality improvement is required
How all this gets calculated
Full details of calculation is available here.
The debt ratio
The debt ratio enables to compare projects. Indeed having $ 10,000 debt on a "small" project does not mean the same as the same debt on a big project. The debt ratio consists in comparing the actual debt with the total possible debt for the project (the project has got 100% lines duplicated, 0% coverage...)
Drill down
Clicking on the debt brings to the usual drill down page showing modules / packages / classes most impacted
Configuration
Most of the settings / default values can be configured by going to Configuration -> Settings -> Technical Debt.
Usage & Installation
- Copy the jar into /extensions/plugins/ directory
- Restart Sonar Web server
- Launch a new quality analysis and the technical debt metrics will be fed
Known limitations
A significant improvement to the would be to gather manual measures : see SONARPLUGINS-91
Having a real cost to resolve for each rule would add a lot accuracy

