В свое время довелось лично наблюдать, как контроль качества на основании общих представлений о том, что “любой продукт должен обладать свойствами A, B и C) давал в разы меньше ценных результатов, чем то же самое, но с учетом целей текущего этапа проекта.

Вывод, который я сделал для себя тогда — контроль качества без привязки к задачам проекта так же бесполезен, как создание “общей платформы для решения любых задач” в разработке.

Помимо принципиальной реализуемости правильного варианта, нужно чтобы реализация этого варианта входила в установленные рамки (scope) проекта.

Ещё любопытно вот это исследование Канера, в котором он пытается подвести юридическую базу под понятие дефекта ПО: http://www.kaner.com/pdfs/defects4.pdf

А моё любимое определение вот такое (источник — http://www.sei.cmu.edu/sema/pdf/defect-prediction-techniques.pdf):
“Software Defect: any flaw or imperfection in a software work product or software process
- software work product is any artifact created as part of software process
- software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software work products”