Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month…
Read the rest of this page »
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month…
Read the rest of this page »
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month…
Read the rest of this page »
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month… Read the rest of this page »
Sonar… in the Cloud to Bee !
I am sure you know Cloudbees already, but just in case here is a short description of the services they provide : CloudBees is a cloud-based SaaS solution that provides flexible and scalable tools, from development (dev@cloud) to production (run@cloud). By nature at SonarSource we are mostly looking at development environments, i.e. dev@cloud, and this is what I am going to talk about today.
Dev@cloud aims to provide a full development infrastructure for small to medium size teams. The beauty with Cloudbees is that not only you don’t need to own and / or manage any hardware but also you don’t have to install and / or manage any of the software running on it. Cloudbees started to operate about one year ago, offering Jenkins as a service. Last July, Cloudbees added partners services to have a more comprehensive proposition: Artifactory as a repository for dependencies, Sauce Labs for tests and Sonar for Code Quality !
Check it out, in a few clicks you get comprehensive development infrastructure. There are several offers you can choose from, ranging from totally free for open source projects to high spec machine costing 5 cts per minute for builds requiring lots of power. Having Sonar available in Cloudbees will cost you about 20 USD per month for the server instance and 2 cts per minute for analysing projects. The infrastructure is highly scalable as each build start on its own slave and therefore does not compete for resources with others. We found it so good that we decided to move our entire Nemo infrastructure onto Cloudbees: instead of 36 hours elapsed, it now takes 6 hours to analyze 150 projects!
I believe that Cloudbees is a very compelling proposition for getting a development infrastructure up and running in no time. You now have no excuse to not focus on what really matters: the development of your product! I expect that many teams (and not only small ones) make a move in the coming months to this type of services, similarly to what happened in CRM with SalesForce.
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month… Read the rest of this page »
Sonar 2.10 in screenshots
The Sonar team is proud to announce the release of Sonar 2.10. As usual, this new version includes improvements, bug-fixes and also new features that we believe are worth stopping your daily work for a couple of minutes to check out : internationalisation, e-mail notification and manual measure revamping. Read the rest of this page »
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month… Read the rest of this page »
Sonar in the news
Welcome to the roundup of blog posts and pages that mentioned Sonar last month… Read the rest of this page »
Jean-Louis Letouzey on SQALE Quality Model
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.
