Technical Debt

The Automated Technical Debt Measure estimates the effort to correct all instances of the 86 weaknesses included in the CISQ Automated Quality Characteristic Measures that remain in a software application’s code at release. This estimate can be used to predict future corrective maintenance costs. The cost to fix structural quality problems constitutes the principal of the debt, while the inefficiencies they cause, such as greater maintenance effort or excessive computing resources, represent interest on the debt. The measure expresses the cost of software quality in terms a business can understand by estimating future corrective maintenance costs to remedy structural defects in code.

 

Track finalization of the OMG® standard here: http://www.omg.org/spec/ATDM/

 

CISQ surveyed developers in a number of organizations to estimate how long it would take to fix each of the 86 weaknesses in well-constructed code. The estimates provided default values for the effort to fix each weakness. To calculate Technical Debt, we adjust the default value for each occurrence of a specific weakness by factors that affect the difficulty of fixing it such as the complexity of the component, its exposure to the rest of the system, etc. The adjusted efforts for each occurrence are summed to produce a total remediation effort for that weakness. The total remediation effort for the weaknesses in a Quality Characteristic are summed to create a remediation effort for that Characteristic. Finally, the remediation efforts for the four Quality Characteristics are summed to produce the Automated Technical Debt measure. This calculation is portrayed in the graphic below.

 

Technical Debt

 

To learn more, attend our upcoming webinar:

 

WEBINAR

 

New Automated Technical Debt Standard

January 16, 2018 from 11:00am – 11:30am ET

Dr. Bill Curtis, Executive Director, Consortium for IT Software Quality

To register: https://register.gotowebinar.com/register/7744757981740472834

 

 

In this webinar, Dr. Bill Curtis will introduce the new Technical Debt measure and outline how the specification is composed. He will present a full picture of the Technical Debt metaphor and how it can be used to communicate IT issues to the business. The measure is ready to be used by vendors of static code analysis (SCA) tools that detect violations of good coding and architectural practice in software. He will present a process for steadily reducing Technical Debt in critical business applications. Business leaders will learn how to use the measure to manage and reduce IT risk.