In SonarQube 5.5 we adopted an evolved quality model, the SonarQube Quality Model, that takes the best from SQALE and adds what was missing. In doing so, we’ve highlighted project risks while retaining technical debt. Read the rest of this page »
This week I want to talk about SQALE – which is commonly pronounced “scale.”
Before I joined SonarSource, I tried many times to understand what SQALE was about, but I just couldn’t get a grip on it. Recently, I sat down with SonarSource Senior Consultant David Racodon, who walked me through it, and made it seem simple. Since version 4.0 brought the fundamentals of SQALE into SonarQube core for everyone to use, I think it’s important to share what I learned in case anyone else is puzzled too. Read the rest of this page »
A few months back we released a Sonar implementation for SQALE that we called “the ultimate Quality Model to assess Technical Debt”. The SQALE method was created by Jean-Louis Letouzey who we met 2 weeks ago. We took advantage of this to ask him a few questions…
The most important thing about SQALE is that it changes the paradigm for analysis and quality management of source code. Traditional approaches use complex formulas that make indicators difficult to understand and utilize. This is slowing down adoption.
SQALE has a different approach which is much simpler to understand : it is built around the technical debt concept. This is an important change as it enables to deploy more widely the measurement and evaluation of the quality of source code to be used daily. Key indicators can be understood and utilized by every stakeholder from the developer to the CIO who can monitor his entire portfolio.
The second difference with traditional models is that SQALE follows the base principles of the measurement theory. I have published articles on this subject and my opinion is that the non-respect of this theory generates false-positives that also slow down adoption.
I have already mentioned 2 points that have been key to make this decision but the most important one is that I realized a couple of years ago that there was a real need that was not fulfilled by an approach yet.
As a consultant, I am regularly doing assignments for large firms. During those assignments, I realized that there was a strong need for a method dedicated to source code quality evaluation. This method should be agnostic from the tooling used to support it but also should be as independent as possible from the language of the application to be analysed. My employer, DNV ITGS, has been very supportive during the development phase.
Once the method was developed, it was obvious that it should be published in order to make it widely used and adopted.
This is a very recurrent question I am getting. This was done deliberately as part of the paradigm change. Indeed looking at severity is a very good idea, however evaluating a risk means combining its impact with its probability. Those 2 factors depend for a good proportion of external factors that have nothing to do with source code.
Having said this, we are now working on adding this dimension as SQALE should provide the big picture.
It is difficult to know the precise number of users as SQALE is distributed freely under creative commons license. However, we know that there was more than 2,500 download of the definition document from everywhere in the world. I am aware of the method be used in banks, insurance, telecom, car makers… SQALE was made public less that one year ago and I consider the adoption as very good and promising.
The user feedback is very good and here are the recognized strengths :
Yes, SQALE is compatible with ISO-9126 : it uses characteristics and sub-characteristics identified by the standard restrained to the one that are source code related. But SQALE also adds time as an other dimension by ordering the defects in categories depending on their impact during the lifecycle. In other words, SQALE takes into account the phase of development in which a defect has an impact on.
I generally recommend to :
The main strength are around the very good integration of the model with the rest of the platform, the easy navigation and the powerful drill downs. The weakness today is the fact that only one SQALE model can be defined at the time.
You probably remember that 4 months ago, we announced the availability of a SQALE plugin for Sonar. Since them, we have continued to work on it and have released a version 1.2. The new version greatly improves the usability of the plugin and makes it even easier for a non-technical manager to understand and manage the technical debt of his portfolio of projects.
Read the rest of this page »
My initial intention was to write a post on the plans for Sonar in 2011 and the associated roadmap. I started by quickly listing what was achieved in 2010. But after thinking about it, I realized that so much happened last year that it was worth to dedicate it an entire post ! Read the rest of this page »
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 :
Read the rest of this page »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) !
