Кто - нибудь использовал метрики оценки качества ПО для установления финансовых условий по договору с разработиком? Поделитесь опытом.

iscrafmя думаю - все
Все - это навряд ли.
Думаю, что, напротив, меньшая часть клиентов использует.

iscrafmвсе каким-то образом формируют свои требования, которые ложатся в основу ценообразования. Пусть явно не называют это именно "метриками качества", но всегда в основе есть функциональность, надежность, переносимость, удобство использования и сопровождения, производительность. Именно за это и платятся деньги, именно это определяет цену. А то, что это не называется "нужными" терминами, не означает что продукты не оцениваются в привязке к данными метрикам. IMHO.
Ну это понятно. Но это общие слова.
Нужны примеры конкретных формулировок ограничений по качеству, хоть метриками их называйте, хоть нет.
Также нужны формулировки на режим запроса информации от разработчика: что он и в каком объеме имеет право запрашивать и какова должна быть регламентная трудоемкость получения такой информации.
Насчет "удобства" - у меня большие сомнения, что этот субъективный показатель можно формализовать и воткнуть каким-то боком в договор.

Rudyshin Sergey, спасибо за ответ.

Я вот тоже размышляю, и думаю, что надо применить нечто наподобие вашего п.1

Вот только какой показатель самый иллюстративный? Ведь если ставить разработчика на бабки, то на научно обоснованной основе.

По договору, если при эксплуатации ПО выявлена ошибка и есть формулировка, аргументация, и ошибку можно воспроизвести на базе разработчика, то разработчик в своей системе фиксирует эту ошибку под определенным номером и "рангом", и в зависимости от этого идет устранение бага.
Думаю, что, наверное, можно поставить поставить след. ограничения:
1. Количество зафиксированных багов любого ранга <N1
2. Количество зафиксированных багов высокого рангa <N2
3. Среднее время устранения бага.
4. Наличие (количество) багов с длинной и практически бесконечной историей ("висяки")< N3
5. Среднее время результативной консультации по проблеме (консультация, приводящая к устранению проблемы)
6. Среднее количество "транзакций" (уточнений) по багу < N4 (высокий показатель говорит о том, что специалист разрабочика "не в теме", и компенсирует свое незнание бесконечными уточнениями)

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

...Run time error...