Експерименти, що співвідносять показники коду з щільністю помилок

Мені цікаво, чи хтось зробив експерименти, що співвідносили кодові метрики (SLOC, Cyclomatic Complexity тощо) з щільністю помилок в об'єктно-орієнтованих додатках.

Я не шукаю експериментів, які лише доводять або спростують кореляцію, але на обох. Я не намагаюся знайти срібну кулю, оскільки вважаю, що щільність помилок проекту може співвідноситися з однією або декількома показниками для даного проекту чи команди, і кореляція може змінюватися протягом життя проекту / команди.

Моя мета - це

1. Виміряйте всі цікаві показники протягом 2-3 місяців (у нас їх уже досить багато із сонару).
2. Знайдіть один показник, який співвідноситься з кількістю нових помилок.
3. Зробіть аналіз першопричини, щоб перевірити, чому це відбувається (наприклад, чи не вистачає нам певної дизайнерської майстерності?).
4. Вдосконаліть навички та змініть зміни за пару ітерацій.
5. Промийте і повторіть з 2.

Якщо у вас немає досвіду з цього приводу, але пам’ятаєте, що бачили статтю / блог на цю тему, я буду вдячний, якщо ви можете поділитися цим.

Поки що я знайшов наступні посилання з деякою інформацією з цього приводу

• Чи знаходяться помилки у складному коді? - лише слайди з презентації.
• Зміни та помилки: видобуток та прогнозування діяльності з розробки - просто демонструйте презентацію. Підсумок - чим більше залежностей, тим вище шанси помилок (я думаю, це цілком загальне правило).
• Невдача - це чотирибуквене слово - Парада про співвідношення помилок та показників.

Щоразу, коли я чую про спроби пов’язати якийсь тип кодової метрики з дефектами програмного забезпечення, перше, про що я думаю, - це цикломатична складність МакКейба . Різні дослідження виявили, що існує кореляція між високою цикломатичною складністю та кількістю дефектів. Однак в інших дослідженнях, які розглядали модулі з аналогічним розміром (з точки зору рядків коду), було встановлено, що кореляція може не бути.

Для мене, як кількість рядків у модулі, так і цикломатична складність можуть слугувати хорошими показниками можливих дефектів, або, можливо, більшою ймовірністю того, що дефекти будуть введені, якщо в модуль будуть внесені модифікації. Модуль (особливо на рівні класу чи методу) з високою цикломатичною складністю зрозуміти важче, оскільки існує велика кількість незалежних шляхів через код. Модуль (знову ж таки, особливо на рівні класу чи методу) з великою кількістю рядків також важко зрозуміти, оскільки збільшення рядків означає, що відбувається більше речей. Існує багато інструментів статичного аналізу, які підтримують обчислення як вихідних рядків коду, що відповідають визначеним правилам, так і цикломатичної складності, схоже, що їх захоплення сприйняло б низький вищий плід.

Заходи щодо складності Галстеда також можуть бути цікавими. На жаль, їх обгрунтованість виглядає дещо обговорюваною, тому мені не потрібно було б покладатися на них. Одним із заходів Гальстеда є оцінка дефектів на основі зусиль чи обсягу (співвідношення між тривалістю програми у перерахунку на загальну кількість операторів та операндів та словник програм з точки зору різних операторів та операторів).

Існує також група показників, відома як метрика CK. Перше визначення цього набору показників виявляється у статті під назвою "Метричний набір для об'єктно-орієнтованого дизайну" Чідамбер та Кемераре. Вони визначають зважені методи на клас, глибину дерева спадкування, кількість дітей, з'єднання між класами об'єктів, відповідь для класу та відсутність згуртованості у методах. У їх роботі представлені обчислювальні методи, а також опис способів аналізу кожного з них.

З точки зору наукової літератури, яка аналізує ці показники, вас може зацікавити Емпіричний аналіз метрик CK для об'єктно-орієнтованої складності проектування: наслідки для програмних дефектів, авторами яких є Раманат Субраманям та М. С. Кришна. Вони проаналізували три з шести показників КК (зважені методи на клас, з'єднання між класифікованими об'єктами та глибиною дерева спадкування). Поглянувши на папір, виявляється, що вони виявили, що це потенційно дійсні показники, але їх слід трактувати обережно, оскільки "покращення" може призвести до інших змін, які також призводять до більшої ймовірності дефектів.

Емпіричний аналіз об'єктно-орієнтованих метрик проектування для прогнозування несправностей високої та низької ступеня тяжкості, авторами яких є Юмін Чжоу та Харетон Леунг, також вивчають показники CK. Їх підхід полягав у визначенні, чи можуть вони прогнозувати дефекти на основі цих показників. Вони встановили, що багато показників СК, за винятком глибини дерева спадкування та кількості дітей) мали певний рівень статистичної значущості для прогнозування областей, де можуть бути розташовані дефекти.

Якщо у вас є членство в IEEE, я рекомендую шукати в IEEE транзакції з програмної інженерії більш академічні публікації та IEEE Software для деяких реальних та прикладних звітів. АСМ також може мати відповідні публікації у своїй цифровій бібліотеці .

Я обговорював можливі кореляції в одному зі своїх публікацій в блозі :

Кореляція між цикломатичною складністю та щільністю помилок: це справжній випуск?

Відповідь - ні. Підтримуючи постійний розмір, дослідження не показують кореляції між КК та щільністю дефектів. Однак є ще два цікавих кореляції для вивчення:

Перший з них: чи сильно співвідносить КС тривалість виявлення та виправлення дефектів? Іншими словами, якщо КК нижче, ми витрачаємо менше часу на виправлення та виправлення дефектів?

Другий: чи сильно співвідносить КС із коефіцієнтом зворотного зв'язку несправностей (FFR, середня кількість дефектів, що є результатом застосування однієї зміни або виправлення одного дефекту)?

Потрібно більше розслідувати, щоб дізнатись, чи хтось вивчав цю кореляцію емпірично. Але моє відчуття кишки та відгуки, які я отримую від колективів, з якими працюю, - це сильна позитивна кореляція між цикломатичною складністю на одній стороні та тривалістю виявлення та виправлення дефекту чи впливу зміни на іншій стороні.

Це хороший експеримент. Будьте в курсі результатів!

В книзі Code Complete, с.457, Стів МакКоннелл говорить, що "складність потоку управління важлива, оскільки вона корелює з низькою надійністю та частими помилками". Потім він згадує кілька посилань, які підтверджують цю кореляцію, включаючи самого МакКейба (якому приписують розроблення метрики циклічної складності). Більшість із них достроково використовували об'єктно-орієнтовані мови, але оскільки ця метрика застосовується до методів у цих мовах, посилання можуть бути те, що ви шукаєте.

Ці посилання:

• МакКейб, Том. 1976. "Захід про складність". Операції IEEE з інженерії програмного забезпечення, SE-2, вип. 4 (грудень): 308-20
• Шень, Вінсент Ю. та ін. 1985. "Виявлення програмного забезпечення, схильного до помилок - емпіричне дослідження". Операції IEEE з інженерії програмного забезпечення SE-11, №4 (квітень): 317-24.
• Ward, William T. 1989. "Профілактика дефектів програмного забезпечення з використанням метрики складності McCabe". Журнал Hewlett-Packard, квітень, 64-68.

З мого власного досвіду, метрика McCabe, як її можна обчислити програмою на багатьох розділах коду, є корисною для пошуку методів і функцій, які є надскладними та мають високу ймовірність вмісту помилок. Хоча я не підраховував, розподіл помилок у функціях високої цикломатичної складності порівняно з функціями низької цикломатичної складності, дослідження цих функцій дозволило мені виявити недооцінені помилки програмування.