Jean-Louis Letouzey on SQALE Quality Model

by olivier gaudin|

    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...

    Can you present us SQALE in a few sentences ?

    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.

    What made you develop and publish the SQALE method ?

    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.

    Why does SQALE not weight requirements by severity ?

    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.

    Are they many users of the method and do you get significant feedback ?

    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 :

    • easy to implement
    • good acceptance from team since it does not generate false positives
    • easy to understand
    • supports decision making process

    Is SQALE compatible with ISO-9126 standard ?

    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.

    What is your recommended approach for implementing source code quality management ?

    I generally recommend to :

    • First, compare SQALE to other methods to make sure it fits your needs and context. The best way is to make a proof of concept on an application.
    • Then choose the tooling that is going to support the process in your organization. Sonar is obviously a good candidate, but again make sure it is going to fit your needs.
    • Get support to conduct the change. Since there is going to be a change of paradigm, change management is going to be a key factor of the success.

    What are the strengths and weaknesses of SonarSource implementation of SQALE ?

    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.