Technical debt in sonar a brief understanding of _sonar

The calculation of technical debt in sonar is based on the methodology of Sqale (Software Quality assessment based on lifecycle expectations, software quality assessment based on life cycle expectations).

Sqale methodology was developed by Inspearit, which was later open source. If you read the relevant documentation on the sqale.org, you will see that it is about "organization-related non-functional line requirements for code quality." In the Sqale method of sonarqube implementation, those non quality requirements refer to the coding rules in the quality configuration.

Yes, Sonarqube has implemented sqale based on separate rules and issues. That means that if you want to manage your technical debt with Sqale, you first need the tags of those rules in the public Sonarqube repository:

Duplicate blocks of code

Failed unit tests

Insufficient Branch unit test coverage

Insufficient annotation density

Insufficient unit Test line coverage

Skipping unit tests

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

The measured values for these days are the sum of the technical debt that appears in each problem, which you can see in each problem block.

Technical debt sets the rule level for each issue. If you already know the business Sqale plug-in, you can adjust the estimate of each rule (of course, this is not necessary).

Now you know how long it takes to fix apps, but how do you prioritize your work? Here's a widget, called the tech debt pyramid, that doesn't look like a pyramid you've seen before.

Don't be confused by this unlike an ancient Egyptian gold tower, it's a parable of the pyramid. The way to read it is bottom-up. The bottom line always has the smallest bar in the bar, but it has the largest entry because it is the base. Each row of this widget represents a feature (characteristic), and each feature is based on it. Testability is the bottom, because it's most important: first, you want to make sure that your application is testable, and then you want to make sure it's reliable, variability, effectiveness, and so on.

Each of the graphs shows the repair time for each feature. The light blue section shows the time it took to clean up the feature, and the dark blue section shows the cumulative time of the bottom-up work. As always, each part of the widget by clicking on the drill lets you know the exact location of the technical debt of a feature.

The Sonarsource Sqale plug-in expands the functionality of the Sonarqube built-in plug-in. Extended features include the ability to adjust the Sqale model, provide widgets to add, and so on.

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