Как формализовать оценку приемлемого уровеня качества ПО?

Известно, что тестировать/исправлять программный продукт, улучшая его качество, можно бесконечно, но "идеал недостижим". Таким образом необходимо иметь объективный критерий, чтобы определить достаточный для завершения работ и выпуска продукта уровень качества.
Цель - достичь консенсуса между Отделами качества и разработки или Исполнителем и Заказчиком на основе заранее выработанной и утверждённой методики формирования независимой оценки (например, числового порогового значения, для принятия решения об удовлетворительном или неуд. качестве). Очевидно, этот критерий требуется, например, при составлении плана тестирования или плана приёмо-сдаточных работ.
Вероятно, опираться он должен на многофакторный анализ (полнота, портируемость, сопровождаемость, юзабилити, надёжность, эффективность, безопасность...) и строиться по результатам всего спектра проверок в рамках функционального и нефункционального тестирования, точнее по видам, важности, количеству выявленных недостатков и соответствующих им оценок рисков.
Может быть это какая-то весовая функция, формируемая на основе ограничений: сроки, цена...

Вопрос: кто знает, где-нибудь описана методика формирования объективной интегральной оценки для принятия решения о допустимом качестве ПО?

Просьба: поделитесь пож-та опытом, фрагментами реальных планов с описанием критериев допустимого качества, оценок рисков!

Цель - достичь консенсуса между Отделами качества и разработки или Исполнителем и Заказчиком на основе заранее выработанной и утверждённой методики формирования независимой оценки (например, числового порогового значения, для принятия решения об удовлетворительном или неуд. качестве). Очевидно, этот критерий требуется, например, при составлении плана тестирования или плана приёмо-сдаточных работ.
Вероятно, опираться он должен на многофакторный анализ (полнота, портируемость, сопровождаемость, юзабилити, надёжность, эффективность, безопасность...) и строиться по результатам всего спектра проверок в рамках функционального и нефункционального тестирования, точнее по видам, важности, количеству выявленных недостатков и соответствующих им оценок рисков.
Может быть это какая-то весовая функция, формируемая на основе ограничений: сроки, цена...

Вопрос: кто знает, где-нибудь описана методика формирования объективной интегральной оценки для принятия решения о допустимом качестве ПО?

Просьба: поделитесь пож-та опытом, фрагментами реальных планов с описанием критериев допустимого качества, оценок рисков!

Длительное время я настраивала НСИ для одного руководителя. Каждый раз его желания менялись и преумножались, при третьей личной встрече мы распечатали НСИ, он сделал свои пометки – по корректировкам и подписал каждый лист по моей просьбе. После получения готового продукта, темперамент его поубавился, и просьбы стали ласковыми и быстро исчерпали себя. При четко поставленных задачах и закрепленных печатями проще определять критерий.

Вопросы Ваши интересны, ответов нет. Хотелось бы помочь Вам и протестировать - проанализировать то, что у Вас получилось. Для меня подобный анализ неразлучен с сравнением старой версии ПО и новой. В виде чаши весов правосудия. Думаю, профильность программного продукта имеет немаловажное значение, учитывая технологию и ее цепочки, понимаешь глубину и важность той или иной оценки. Расставить нужно приоритеты в перечисленном Вами ранее (полнота… надёжность, эффективность, безопасность...) и, в зависимости от этого строить пропорции оценок. Судьей будет время и пользователи ПО. Вероятно, Вы предусмотрели время на эксплуатацию нового ПО, для выявления основных требований доработок. Далее между заказчиком и исполнителем может быть составлен и заверен документ с четко изложенными пожеланиями доработок и сроков - прелюдия финала. А чем Вам плох бесконечный контракт - "все для Вас за Ваши деньги"? Может утопия в том - что нужен финал?

К сожалению, в подобных выводах о готовности ПО к эксплуатации я доверяю лишь своим возможностям в тестировании и 2-х недельной эксплуатации версии – позволяющей выявить основные недостатки. Без этого, я к любой многогранной оценке отнесусь скептически, и буду иметь активный резерв со старой сборкой программного обеспечения.

"Формирование оценки" - да.
"Объективной" - это очень сложно. Чтобы точность была в пределах 5-10% процедура оценки должна стоить очень дорого. Может быть даже дороже самого проекта.
Так что примите за неизбежность погрешность оценки (большую погрешность).

--

Можно воспользоваться ГОСТ 9126 и 28195 (http://www.gosthelp....kakachestv.html). Работать по ним непросто, зато это стандарт.

Просьба: поделитесь пож-та опытом, фрагментами реальных планов с описанием критериев допустимого качества, оценок рисков!

http://software-testing.ru/forum/topic/14142/
http://software-test...um/topic/10636/
Ссылка на статью (в одном из вышеприведенных топиков), убитая при переезде сайта:
http://msdn.microsof...e/cc163785.aspx
Поищите по форуму "показатель качества"

А вообще, я согласен с мнением, которое высказал SALar - объективная цифра наврядли получится.
Особенно, если она одна, а не набор показателей. Мы набор критериев используем. Без численной оченки. Грубо, схема такая - 4 цветовых статуса: белый - не проверяли, красный - не удовлетворяет, зеленый - удовлетворяет, желтый - не совсем, но сойдёт.
Идея - пока есть красное или белое - надо копать. Если все зеленое + желтое - значит вроде как готово. Правда критерии у нас там не только по тестированию, но и по разработке тоже.
Рисками не пользуемся, хотя были попытки.

Ссылка на статью (в одном из вышеприведенных топиков), убитая при переезде сайта:

Ссылку пофиксил. Если где видите битые ссылки -- жалуйтесь, постараемся восстановить.