Technical debt in Sonar

Technical debt in Sonar

The computing of technical debt in sonar is based on SQALE (Software Quality Assessment based on Lifecycle Expectations, based on the Software Quality Assessment expected by the Life Cycle) methodology.

SQALE methodology was developed by in‑it and later open-source. If you have read the relevant documentation on sqale.org, you will understand that it is about "Organizing non-functional line requirements related to code quality. In the SQALE method implemented by SonarQube, the non-quality requirements refer to the encoding rules in the Quality configuration.

Yes, SonarQube implements SQALE based on separate rules and problems. It means that if you want to use SQALE to manage your technical debt, you first need to mark the rules in the public SonarQube Repository:

• Repeated code blocks

• Failed Unit Tests

• Insufficient branch unit test coverage

• Insufficient annotation Density

• Insufficient unit test row coverage

• Skip unit test

These rules are in a public repository because they are shared for all languages. Once you activate them, you can track each quality defect with a single problem to prepare for tracking technical debt (the SQALE method is measured in days.

The measured values of these days are obtained by adding the technical debt arising from each problem. You can see them in each problem block.

Technical debt sets a rule level for each problem. If you already know the commercial SQALE plug-in, you can adjust the estimation of each rule (of course, this is not necessary ).

Now you know how long it takes to fix an application, but how do you sort your work by priority? There is a widget called the technical debt pyramid, which does not look like the pyramid you have seen before.

Don't be confused because it is not like an ancient Egyptian gold tower. It is a metaphor pyramid. The reading method is bottom-up. The bottom row always has the smallest bar in the bar chart, but it has the largest entry because it is the basis. Each row of This widget represents a characteristic feature, and each feature is built on the basis below it. Testability is the bottom, because it is the most important: first, you need to ensure that your application is testable, and then you need to ensure its reliability, variability, and effectiveness, and so on.

Each entry in the figure shows the restoration time of each feature. The light blue part shows the time to clean up this feature, and the dark blue part shows the accumulated time from bottom up. As usual, each part of the component knows the exact location of a feature's technical debt by clicking the drill-down operation.

The SonarSource SQALE plug-in extends the built-in SonarQube plug-in functions. Extended functions include: You can adjust the SQALE model, and provide configurable widgets.

 

Http://docs.codehaus.org/display/SONAR/Technical+Debt

Sonar details: click here
Sonar: click here

This article permanently updates the link address: