Traps to avoid during Software Quality projects
Trap #1 Deploying too much abstract indicators
When talking about Software Quality, most of articles cover best practices and development process to implement, in order to avoid that projects collapse under Technical Debt: identify risky components, do frequent code reviews, refactor complex artifacts, check coding rules, etc. However few guidelines can be found around the project itself: yes, deploying a solution for Software Quality Management should be considered as a project, with its stakeholders (CIO, developers, QA manager, subcontractors), milestones and -like any other project- the common traps that have to be avoided.
That’s why we, at Squoring, decided to share our hundred years of cumulated experiences on Software Quality Mangement tooling projects, in this expert opinion dedicated to a very common trap: Deploying too much abstract indicators.
Table of Content
• Introduction to Software Quality Management projects
• Trap #1: Too much abstract indicators
• What is clearly thought out is clearly expressed!
• The characteristics of an efficient quality indicator
• Technical Debt-based indicators: relevant, ready to use and easy to deploy
• The Squore indicators to manage your Technical Debt
A french version of this document is also available for download.