Метрики Чепіна

Метрики цикломатичної складності за Маккейбом

Показник цикломатичної складності – один із найрозповсюдженіших показників оцінки складності програмних проектів. Він був розроблений у 1976р., відноситься до групи оцінки складності потоку керування програмою і обраховується у вигляді орієнтованого графа, в якому обчислювальні оператори або вирази представляються у вигляді вузлів, а передача управління між вузлами – у вигляді дуг. Показник цикломатичної складності дозволяє не лише провести оцінку трудоємкості реалізації окремих елементів програмного проекту і скоректувати загальні показники оцінки діяльності та вартості проекту, але й оцінити пов’язані з ним ризики та прийняти необхідні управлінські рішення. Спрощена формула цикломатичної складності має вигляд:

де e – кількість ребер, а n – кількість вузлів на графі управляючої логіки. Як правило, при обчисленні цикломатичної складності логічні оператори не враховуються.

У процесі автоматизованого обчислення показника цикломатичної складності зазвичай застосовують спрощений підхід: граф не будується, а обчислення показника виконується на основі підрахунку кількості операторів управляючої логіки (if, switch і т.д.) та можливої кількості шляхів виконання програми. Цикломатичне число Маккейба показує кількість проходів, потрібних для покриття всіх контурів сильнозв’язного графа або кількості тестових прогонів програми, необхідних для вичерпного тестування по принципу «працює кожна вітка».

Існує велика кількість модифікацій показника цикломатичної складності:

· «модифікована» цикломатична складність – розглядає не кожне розгалуження оператора switch, а весь оператор як єдине ціле;

· «строга» цикломатична складність – включає всі логічні оператори;

· «спрощене» обчислення цикломатичної складності – обчислення на основі управляючих операторів, а не графа.

Існує кілька модифікацій даних метрик, розглянемо більш просту з точки зору практичного використання. Суть методу полягає в оцінці інформаційної «міцності» окремо взятого програмного модуля за допомогою аналізу характеру використання змінних із списку вводу-виводу. Всю множину змінних розбивають на 4 функціональні групи:

1) Множина «Р» - змінні, що вводяться для розрахунків і забезпечення виводу. Прикладом може слугувати змінна, що використовується у програмах лексичного аналізатора, яка містить рядок вихідного тексту програми – змінна не модифікується, а лише містить вхідну інформацію.

2) Множина «М» - змінні, що модифікуються або створюються всередині програми.

3) Множина «С» - змінні, що беруть участь в управлінні роботою програмного модуля (управляючі змінні).

4) Множина «Т» - «паразитні» змінні, що не використовуються у програмі.

Оскільки кожна змінна може виконувати одночасно кілька функцій, необхідно враховувати її у кожній відповідній фінальній групі.

де – вагові коефіцієнти. Вони використовуються для відображення різного впливу на складність програми кожної функціональної групи. На думку автора метрики, слід обирати коефіцієнти. Враховуючи це,

Нижче наведена загальна таблиця оцінок по базовим характеристикам метрик.

Таблиця 2 – Склад метрик, їх вплив і аналіз ефективності використання

Метрика	Навіщо потрібна	Впливає на…	Аналіз на основі статистичних даних (як тренд, так і прогноз)
Зусилля розробника при реалізації	Наскільки ефективна праця розробника.	Точність прогнозів оцінки трудоємкості при виконанні організацією типових запитів, або запитів, що мало відрізняються	Можна аналізувати зусилля розробника у часовому зрізі або у зрізі по релізам або проектам. Виявляти, на яких задачах програміст має повну віддачу, а які йому не по душі. Тренд дозволить менеджеру краще розуміти, хто і на яких задачах максимально ефективний при формуванні команди нового проекту, а також які підсистеми відносно складні, а які – прості.
Довжина й об’єм програми		Оцінку об’єму змін	Збільшується або змменшується об’єм програми в часі. Використовується для прогнозу складності на ранніх етапах на основі статистики.
Аналіз цикломатичної складності.		Оцінку складності змін	Складність росте чи ні? Використовується для прогнозу складності на ранніх етапах на основі статистики.
Зусилля програміста при розробці.	Для визначення складності реалізації того чи іншого блоку коду (класу, функції і т.д.)	Розуміння того, наскільки інтелектуально-затратною для розробника була та чи інша функція.	Аналізується збільшення або зменшення зусиль розробника в часі. На попередніх етапах метрику можна використовувати для прогнозу.
Кількість рядків на реалізацію вимоги.	Вимірюємо загальну температуру. Ця метрика приймається до уваги при анализі реалізації запиту.	Розуміння ККД. Відслідковуємо сплески.	Сигнал небезпеки при виявленні збільшення кількості рядків підчас виконання типового запиту. Використовується для оцінки складності на ранніх етапах на основі статистики.
Кількість коментарів на одиницю коду.	Код повинен бути документованим. Якщо співвідношення коду к коментарів не 1:4, то розробник повинен доопрацювати.	Якість коду, його прозорість.	Загальна культура розробників росте чи ні? Виділяються складні проекти, проблемні модулі або підсистеми.
Інші кількісні метрики (кількість функцій, класів, файлів).	Відношення нових функцій до змінених.	Кількість доданих, видалених і змінених рядків по відношенню до попередньої версії.	Глибокий аналіз змін по релізам (версіям, збіркам) дає оцінити кількість змін – скільки разів один і той же блок коду коректувався. Можна виявити вузьке місце в програмі: блок коду, що інтенсивно змінюється, може впливати на загальну якість програми. Можлливо, необхідно змінити архітектуру блоку.
Густина дефектів на одиницю коду.	Кількість дефектів на один рядок коду	Похідна метрика: кількість рядків/кількість дефектів.	Дана метрика корисніша для часової оцінки: густина збільшується від версії до версії.