SQALE

Technical debt (also known as ‘effort to go’, ‘design debt’ or ‘code debt’) is a neo-logistic metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. Unaddressed technical debt increases software entropy. Security Reviewer participates to ‘Managing Technical Debt’ Agile Alliance group

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

SQALE (Software Quality Assessment based on Lifecycle Expectations) is a method to support the evaluation of an application source code. It is a generic method, based on ISO 9126 e ISO 25010:2011, and it is independent of the language and Static Analysis tools. It was developed by Inspearit France (formerly DNV ITGS France). It is used by many organizations for applications of any type and any size. This validated software quality assessment method produces some defined indices and indicators, Technical debt included, but most of SQALE implementations are limited to measure a number of quality aspects only.  Security Reviewer enhance SQALE indicators with in-depth Security  (400+ rules), Dead Code and Best Practices (100+ rules) violations detection, avoiding to consider ‘rules’ the enormous number of micro and useless controls provided by other products, typically solved by setting the proper options into compilers or IDE.  Further, the algorithm used to compute the Technical debt, rather than consider LOC or Function Points only, has been enhanced using Effort Estimation techniques. SQALE Rating calculated by Security Reviewer is considered the more accurate in the market.

Quality Reviewer and SQALE module are fully integrated inside Security Reviewer’s GUI. Thus Quality Reviewer installation kit and included SQALE module, will be always a part of Security Reviewer setup Kit. Please refer to Security Reviewer’s documentation, for further information about how to install.

Security Reviewer is recognized as an Official SQALE Tool.

We calculate Technical Debt following the OMG ATDM specifications.

We measure Software Resilience following CISQ specifications.

Methodology

SQALE methodology represents the state-of-the-art of ISO 9126 and ISO 25010:2011 compliance, related to Static Analysis. SQALE means “Software Quality Assessment based on Lifecycle Expectations”. You can download the SQALE Method Definition Document here: http://www.sqale.org/

Organizations and software editors can freely use and implement the SQALE method. The following are the main principles:

• The Quality of the source code is a non-functional requirement. It is organized in three hierarchical levels. The first level is composed of Characteristics, the second of Sub-characteristics. The third level is composed of Requirements that relate to the source code’s internal attributes. These requirements usually depend on the software’s context and language.
• 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 < 20″. Those requirements are called rules.
• The SQALE methodology assesses the distance to the requirements conformity by considering the necessary Remediation cost to bring the source code to conformity. Assessing the quality of a source code is in essence assessing the distance between its state and its expected Quality Target. 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 Quality Model is orthogonal meaning that a quality flaw appears once and only once in the Quality Model.
• The SQALE Method’s Quality Model includes an organized set of expectations (requirements) based on lifecycle needs

The SQALE Method normalizes the reports resulting from the Static Analysis tools by transforming them into costs.  To do this remediation functions and non-remediation functions are used.

The remediation function’s goal is to normalize findings related to one requirement into remediation costs. This normalization is performed from the technical team point of view. In  order  to  do  this  normalization,  one  can  simply  use  a  multiplicative  factor  that  corresponds  to  the  average remediation cost unit for bringing the code into conformity. The value of this factor will depend on the activities that have to be carried out in order to remedy the non-conformity. The  set  of  remediation  functions  associated  to  a  Quality  Model  constitutes  a  Technical  Debt estimation model. The non-remediation function’s goal is to normalize findings into non-remediation costs. This normalization is performed from the Business or Product Owner point of view. The set of non-remediation functions associated to a Quality Model constitutes a Business Impact estimation model.  This  Business  Impact  should  represent  all  the  damages  inferred  by  the  non-conformity,  damages  that  can be numerous.