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.
...
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.
...
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.
COPYRIGHT (C) 2014-2020 2021 SECURITY REVIEWER SRL. ALL RIGHTS RESERVED.