Editor's Note: this post contains outdated information. Find the latest on SonarQube here.
Six months ago, we would never have believed that one day we would be happy and excited to write about the implementation of a Quality Model in Sonar. Indeed the Quality Models that we knew at the time (most of them are based on ISO 9126 standard) are complex, expensive to implement, can be understood only by an elite of quality experts and are not fun at all. Displaying a global rating on an application is easy but insuring that this rating can be understood in less than 5 minutes by every stakeholder is much more difficult. Implementing one of those Quality Models in Sonar was a kind of non-sense, even if this feature was highly requested by big companies. Indeed they were in contradiction with the vision behind Sonar:
Managing the source code quality should be simple, should be cheap, should be accessible by all stakeholders (developer, architect, project manager, top manager, ...), should be valuable and should be fun (without pleasure, perfection cannot be reached)!
Having said this, we knew that a piece was missing to the puzzle : the platform was widely adopted by teams on the ground but not by the top management. LCOM4, complexity by method, code coverage, undocumented API... are technical indicators that are not adapted to top manager's needs. Further more it was difficult for managers and developers to have a discussion on source code quality as they did not have a common domain-specific language. This is by definition what Quality Model should bring in the equation.
About 18 months ago, we made an implementation of a simple and empirical Quality Model based on the Technical Debt metaphor. The goal was to be able to assess the overall quality of an application, estimate the remediation cost to fix source code quality flaws and offer the missing common language between managers and developers. This Technical Debt plugin was an unconscious baby step toward the Quality Model world.
With SQALE, Sonar can now fully embrace the Quality Model world as SQALE is the leading-edge method to assess Technical Debt while conforming to ISO 9126 standard. The method has been developed by DNV ITGS France and is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0. You can have a look at the SQALE Method Definition document to get a good understanding of the methodology, but here are the main principles :
- Quality means conformance to requirements, therefore those requirements should be first defined. They should be : atomic, unambiguous, non-redundant, justifiable, acceptable, implementable and verifiable. For example "each method should have a complexity lesser than 10". Those requirements are called rules in Sonar.
- The SQALE methodology assesses the distance to the requirements conformity by considering the necessary remediation cost to bring the source code to conformity. For instance, if the branch coverage of a source file is 60% whereas 65% is required for each file, the remediation cost will be effort to cover the missing number of branches to reach the required branch coverage threshold of 65%.
- The SQALE Method adds up remediation costs to calculate quality indicators. Indeed when you have several debts, does it really make sense to average them ?
- The SQALE Quality Model is orthogonal meaning that a quality flaw appears once and only once in the Quality Model.
The hierarchical structure of the SQALE Quality Model conforms to ISO 9126, so you'll find characteristic, sub-characteristic and source code requirements. Let's take an example here : the source code requirement "Don't use 'enum' as a java identifier" is by default part of "Language related portability" sub-characteristic which is itself by default part of the "Portability" characteristic which is part of the SQALE Index (total technical debt value). If there are 4 violations to this requirement and the unit cost to fix each requirement is 10 minutes, then the remediation cost to conform to this requirement is 40 minutes. And this remediation cost is aggregated at each level till assessing the overall SQALE Index. To get your overall technical debt ratio (SQALE Ratio), you then just have to divide your SQALE Index by the estimation effort to re-develop your application from scratch.
SonarSource has released a commercial SQALE plugin which is considered as an official implementation of the SQALE method. The two following screenshots should quickly allow you to understand the benefits of this SQALE plugin. On any projects and whatever is the development language (JAVA, PHP, COBOL, C, ...) you will quickly know the total amount of your technical debt and breakdown this technical debt by characteristics, sub-characteristics and source code requirements. When the SQALE plugin is used with the Views plugin you can even get this information at any organizational level : departement, service, team, ... :
A top manager and a developer are now able to talk together about technical debt because there is no complexity in the data shown, only an addition of atomic costs with functionality to breakdown each level to sub-levels and to drilldown from the projects to the source code.
On Nemo (our public instance for open source projects), the global technical debt (SQALE Index) is greater than 44,000 days for a total amount of 6 millions lines of code. 32% of this technical debt is due to a lack of branch coverage by unit tests.