Качество vs. программное обеспечение

Готовя к публикации перевод главы SWEBOK "Software Quality" (будет доступен в ближайшие дни) не смог удержаться чтобы не коснуться этой темы отдельно в блоге. Я получил ряд откликов на использование мной такого словосочетания как "приемлемое качество" (как положительных, так и, не буду скрывать, негативных). Хотел бы прояснить то, что я подразумеваю под приемлемым качеством и почему часто использую такой, если позволите, термин ;)

Описание упомянутой мной области знаний SWEBOK начинается с введения:
"Что такое качество и почему оно должно быть столь глубоко представлено (в виде самостоятельной области знаний, прим. автора) в SWEBOK? На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process, прим. автора) описывает качество как “достижение отличного уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями” (“market-driven quality”). Критерий Бэлдриджа (Baldrige) для организационного качества (см. NIST - National Institute of Standards and Technology, “Baldrige National Quality Program”, http://www.quality.nist.gov) использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качествя используется в соответствии с определением системы менеджмента качества ISO 9001 как “степень соответствия присущих характеристик требованиям” (именно так это сформулировано в официальном переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь”, прим. автора)."

Такое восприятие качества, как мне кажется, естественно перекликается с используемым мной приемлемым качеством, определяемым не только уровнем запросов конечных потребителей в отношении параметров создаваемого продукта, но и заданным контекстом/ограничениями проекта. Это не значит, что “приемлемое качество” противопоставляется “качеству, диктуемому заказчиком” (custom-driven). Конечно, не стоит и проводить параллель “приемлемого качества” с “продуктом второй свежести”. Введение категории “приемлемости” в отношении качества является лишь прагматичным взглядом на желаемую степень совершенства создаваемого продукта (услуги), способную удовлетворить пользователей и достижимую в рамках заданных проектных ограничений. Интересно, что и сама “степень приемлемости” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества.

А что Вы думаете на этот счет?