Есть ли работа по применению мер сложности Холстеда для определения качества программного обеспечения?

В 1977 году Морис Говард Холстед представил свои меры сложности для программных систем , которые включали измерения словаря программы, длины программы, объема, сложности, усилий и предполагаемого количества ошибок в модуле. Согласно Википедии, трудность связана с трудностью понимания программы при ее чтении или написании, и усилия могут быть переведены во время, необходимое для написания кода приложения, где Время = (Усилие / 18) секунд.

Измерение бесполезно, если только данные и расчеты не связаны с каким-либо аспектом разработки программного обеспечения. Тем не менее, я не нашел работы, в которой говорится, что трудность определенного значения или выше имеет тенденцию к статистически значительному увеличению количества дефектов или взаимосвязи между трудностью и временем чтения кода (трудность N дает в среднем M часов, потраченных понимание основы кода) или любой анализ способности вычислять время после того, как факт полезен для определения качества (особенно потому, что время для записи должно было уже записываться как измерение). Меня особенно интересует оценка ошибок Холстеда (которая не упоминается в Википедии) - количество ошибок в приложении можно оценить по объему / 3000 или усилию ^ (2/3) / 3000.

Я ищу две вещи:

Кто-нибудь использовал меры сложности программного обеспечения Halstead в реальных приложениях для оценки качества программного обеспечения? Если да, то как вы их применили, и оказались ли они полезным, достоверным и / или надежным измерением?
Проводятся ли какие-либо научные исследования в форме опросов, анализов или тематических исследований, в которых обсуждается обоснованность (или недействительность) мер сложности Холстеда применительно к качеству программного обеспечения?
Существуют ли какие-либо академические исследования в форме опросов, анализов или тематических исследований, которые демонстрируют использование строк исходного кода (SLOC) для вычисления чего-то похожего на метрики Халстеда: объем, сложность, усилие, время и ошибки? Я подозреваю, что объем может просто соответствовать количеству SLOC, а уровень сложности может соответствовать цикломатической сложности (и, возможно, другим показателям). Я также хорошо понимаю, что измерение усилий, производительности или времени в SLOC может ввести в заблуждение.

quality metrics measurement

— Томас Оуэнс
источник

У вас будут некоторые проблемы с поиском результатов за последние 15 лет, поскольку работа по метрике Холстеда была проведена более 30-40 лет назад, и сильная корреляция с SLOC была обнаружена почти сразу. (Это из памяти, из выступления нового кандидата наук в UT Остин, ок. 1977 г.)

— Джон Р. Штром,

Спасибо за это. Я обновлю вопрос и перефокусирую свои усилия по поиску, сын старых работ.

— Томас Оуэнс

Ответы:

Microsoft Research проделала определенную работу в этой области. Проверьте эту страницу: http://research.microsoft.com/en-us/people/nachin/ . Хотя Начи и его команда не были специально основаны на Халстеде, они провели некоторое исследование с использованием Халстеда, цикломатической сложности, оттока кода и других мер для оценки относительного риска и хрупкости при внесении изменений в области кода. Есть также интересная статья о том, как организационная эффективность также играет большую роль, но это не по теме. :)

— nithins
источник

Мне придется прочитать хотя бы некоторые из них. Определенно что-то меня интересует, но меня (по крайней мере, сейчас) особенно интересует Холстед, поэтому я сосредоточусь на этом. Я сделал закладку на сайт, чтобы я мог прочитать его, когда у меня будет больше времени, но пока что +1.

— Томас Оуэнс

Показано, что цикломатическая сложность МакКейба в реальном коде очень сильно коррелирует с необработанным SLOC до такой степени, что при его вычислении нет никакого возрастающего значения.

— Джон Р. Штром

Таких исследований довольно много. Google твой друг.

Метрики Холстеда потеряли популярность, когда было продемонстрировано, что все они тесно связаны с необработанным SLOC (исходные строки кода). В этот момент становится проще измерить SLOC и покончить с этим.

Вот результат из Google Книг .

— Джон Р. Штром
источник

Я занимался поиском в Google с тех пор, как задал этот вопрос, но мне еще не удалось найти опубликованные статьи или другие авторитетные источники. Кроме того, я не вижу, как показатель, связанный с SLOC, может быть плохим. SLOC / время - плохая мера производительности, но другие метрики на основе SLOC обычно считаются действительными, например, дефекты / SLOC.

— Томас Оуэнс

@ Томас: Дело не в том, что показатели Холстеда «связаны» со SLOC, а в том, что они сильно коррелированы. Статистика 102. Сказать, что Y и X являются сильно коррелированными, означает, что отношение Y / X является практически постоянным для всех наборов данных. В этом случае нет смысла измерять Y, если проще измерить X, потому что Y на самом деле не говорит вам ничего, чего вы еще не знаете из X.

— Джон Р. Стром,

Это имеет смысл. Метрики Холстеда основаны на количестве отдельных и полных операторов и операндов. Это здравый смысл, что более длинная программа будет иметь больше полных операторов / операндов и, скорее всего, будет иметь больше различных операторов / операндов. Метрики объема и сложности могут быть получены с использованием SLOC вместо операторов / операндов. Однако это не относится к валидности, приложениям и значению (или отсутствию смысла) метрик Effort, Time и Bugs. Даже когда вычисляются с SLOC вместо операторов / операндов, говорят ли эти метрики что-нибудь значимое о системе?

— Томас Оуэнс

SLOC легче посчитать и, вероятно, более полезен. Оценки SLOC используются несколькими методами оценки затрат, отслеживаемыми в PSP и TSP, и могут использоваться в других показателях, таких как плотность дефектов. Для меня это говорит, что подсчет SLOC может быть лучше, чем подсчет операторов / операндов. Во-вторых, и до сих пор остается без ответа достоверность показателей Effort, Time и Bugs, независимо от того, какие измерения используются для их вычисления. Я согласен, что вычисление их с SLOC может быть лучше, но даже если бы я это сделал, они что-нибудь значат?

— Томас Оуэнс

@ThomasOwens: Вероятно, нет. Если Effort, Time и Bugs тесно связаны с SLOC, то это говорит о том, что все программы определенного размера занимают примерно одинаковое время и усилия и имеют одинаковое количество ошибок. Первые два - это то, на чем основывается оценка на основе SLOC (например, COCOMO), и все равно, что сказать, что вода влажная. Третий не очень помогает вам.

— Джон Р. Штром

То, что объем Холстеда соотносится с SLOC, интересно, но ограничено. Базовая статистика: линейная корреляция не транзитивна. X соотносится с Y, Y соотносится с Z НЕ ОЗНАЧАЕТ, что X соотносится с Z.

— user1704475
источник

Когда X и Y просто коррелируют, а Y и Z просто коррелируют, да, X и Z не обязательно коррелируют из-за относительно высоких уровней шума в первых двух корреляциях. Когда X и Y сильно коррелированы, а Y и Z сильно коррелированы, возникает очень, очень мало шума, и в любом конкретном случае становится очень вероятным, что X и Z окажутся коррелированными.

— Джон Р. Штром