Чи є якась робота над застосуванням заходів складності Halstead для визначення якості програмного забезпечення?

У 1977 році Моріс Говард Холстед представив свої заходи щодо складності програмних систем , які включали вимірювання програмної лексики, довжини програми, обсягу, складності, зусиль та приблизну кількість помилок у модулі. Згідно з Вікіпедією, складність пов'язана з труднощами розуміння програми під час її читання або написання, а зусилля можуть бути переведені на час, необхідний для кодування програми, де Час = (зусилля / 18) секунд.

Вимірювання марно, якщо дані та розрахунки не стосуються певного аспекту розробки програмного забезпечення. Однак я не знайшов жодної роботи, яка б стверджувала, що складність певного значення або вище має тенденцію до статистично значущого збільшення дефектів або взаємозв'язку між труднощами та часом для читання коду (складність N дає середнє витрачене M годин розуміння бази коду) або будь-який аналіз можливості обчислити час після того, як факт корисний для визначення якості (тим більше, що час для запису повинен був бути записаний вже як вимірювання). Мене особливо цікавить оцінка помилок Halstead (яка не згадується у Вікіпедії) - кількість помилок у додатку можна оцінити за Volume / 3000 або Effort ^ (2/3) / 3000.

Я шукаю дві речі:

• Хтось використовував заходи комплексності програмного забезпечення Halstead в додатку в реальному світі для оцінки якості програмного забезпечення? Якщо так, то як ви їх застосували і чи виявилися вони корисними, достовірними та / або надійними вимірюваннями?
• Чи є які-небудь академічні дослідження у формі опитувань, аналізів або тематичних досліджень, які обговорюють обгрунтованість (або недійсність) заходів складності Halstead, коли вони застосовуються до якості програмного забезпечення?
• Чи є які-небудь академічні дослідження у формі опитувань, аналізів або тематичних досліджень, які демонструють використання вихідних ліній коду (SLOC) для обчислення чогось подібного до показників Гальстеда об’ємності, складності, зусиль, часу та помилок? Я б підозрював, що Об'єм може просто відповідати кількості SLOC, а складність може відповідати цикломатичній складності (і, можливо, іншим заходам). Я також добре знаю, що вимірювання зусиль, продуктивності чи часу в SLOC потенційно вводить в оману.

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

Таких досліджень досить багато. Google - ваш ДРУЗЬ.

Показники Галстеда не прихильні, коли було продемонстровано, що всі вони були сильно корельовані з необробленими SLOC (вихідними рядками коду). В цей момент стає простіше виміряти SLOC і зробити це з ним.

Ось результат із Google Книг .

Те, що об'єм Гальстеда співвідноситься зі SLOC, цікаво, але обмежено. Основна статистика: лінійна кореляція не є перехідною. X корелює з Y, Y співвідноситься з Z НЕ означає, що X корелює зі Z.