Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».

Интересно оценивать evolvability.
Тут всё начинается с читабельности/понимабельности.
Насколько быстро читатель может понять, что там происходит -- и что-то исправить.
Берем десять программеров, и засекаем десять секундомеров. Типа

Ну, о субъективности подобного подхода писал еще Вейнберг. И Шнейдерман - тоже.
"rgthbvtyns были примерно такие. Берут несколько примерно равных по квалификации программеров и задают задачу написать программу.

Мой аспирант занимался этой проблемой, поскольку был одновременно начальником отдела АСУ и перед ним в полный рост стояла задача оценки качества кода и как следствие квалификация работы программиста.
...А качество он придумал оцифровать с помощью нечетких нейронных сетей Ванга-Менделя.

Программист должен помимо кода выдавать его "чертёж" --- собственноручно написанную документацию с предусловиями/постусловиями и набор отработанных им тестов на каждую процедуру. Вот тогда и будет качество.

Разрешите подписаться. Только когда "чертёж" есть, можно начинать о чём-то говорить.

И метриками обкладывали уже с начала проектирования. Естественно, сначала строилась модель, на которой считались метрики. Эта модель проходит "красной нитью" через всю методу.
Так что не все так однозначно неприемлемо.

Существуют различные метрики для оценки кода ПО. Некоторые их них это:

1. Цикломатическая сложность [2]
2. Сплоченность (cohesion)
3. Связность (coupling)
4. Глубина наследования (Depth of Inheritance)
5. Число строк кода (Lines of Code)

Учитываете ли вы эти метрики при разработке ПО?

Чем-то мне это напоминает внедрение СМК на предприятии.

Метрики кода <-> система менеджмента качества... Интересная аналогия: оценка качества производства в отрыве (не зависимо) от самого процесса производства?

Типа того. И в том, и в другом случае полезность под большим вопросом (по крайней мере, для меня).

Не спорю, что это дело может быть работоспособно и приемлемо. Мне не нравится сама постановка задачи.

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

По-моему, нужно разрабатывать методы и требования, нацеленные на сам процесс производства и выдаваемые результаты. Чтобы процесс стал систематическим, а результаты формально контролируемыми по нормативам. Без необходимости привлекать особо тренированных экспертов.

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

Среди специалистов отсутствует единое мнение о номенклатуре показателей качества (несмотря на то, что существуют и международные, и российские стандарты ). Роберт Гласс рассматривает качество ПО как совокупность семи свойств: надежности, переносимости, эффективности, удобства эксплуатации, понятности, тестируемости и модифицируемости. Карло Гецци с соавторами различают качество продукта и процесса. К качествам продукта они относят следующие: корректность, надежность и устойчивость, производительность, удобство, повторная применимость, верифицируемость, сопровождаемость, понятность, переносимость. Иан Грэхем , основываясь на исследованиях других авторов, приводит более обширный список критериев качества: корректность, устойчивость и надежность, возможность сопровождения и расширения, способность к взаимодействию, эффективность, возможность повторного использования и универсальность, переносимость, ясность, возможность верификации, безопасность, целостность, дружественность, возможности описания. Кроме того, он тоже разделяет качество продукта и качество процесса.
В стандартах устанавливается более короткий перечень показателей. ГОСТ 28195-89 содержит следующий список комплексных показателей качества программного продукта: надежность, корректность, удобство применения, сопровождаемость, эффективность и универсальность. В международном стандарте ISO 9126 прописаны следующие показатели: эффективность, надежность, сопровождаемость, функциональность, практичность и мобильность. Комплексные показатели называют также факторами качества или характеристиками качества.
Каждому из комплексных показателей соответствует определенный набор критериев качества. В свою очередь, каждый из критериев определяется своими метриками, которые составляются из оценочных элементов, определяющих заданное в метрике свойство. На разных этапах ЖЦ для разных классов программных продуктов применяются разные критерии качества.

1. Надо различать внешнее и внутренне качество. Внешнее качество - это как раз те свойства, которые легко наблюдаются и в некоторых случаях легко измеряются. А вот внутреннее качество - именно качество самой проги, тут много вопросов.