Розмірно-орієнтовані метрики

Виміри у конструюванні

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

Метрики складності програм розділяють на 3 основні групи:

· Метрики розміру програм;

· Метрики складності потоку управління програм;

· Метрики складності потоку даних програм;

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

Метрики другої групи базуються на аналізі керуючого графа програми. Їх представником являється метрика Мак-Кейба. Управляючий граф може бути побудовано на основі алгоритмів модулів, тому метрики другої групи також можуть застосовуватися для оцінки складності проміжних продуктів розробки.

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

Розмірно-орієнтовані метрики напряму виміряють програмний продукт та процес його розробки. Вони базуються на LOC-оцінках (Lines of Code). Замість підрахунку LOC-оцінок розглядається не розмір, а функціональність або корисність даного продукту. В організаціях, зайнятих розробкою програмної продукції для кожного проекту прийнято реєструвати наступні показники:

· Загальні трудозатрати (у людино-місяцях, людино-годинах);

· Об’єм програми (у тисячах рядків вихідного коду);

· Вартість розробки;

· Об’єм документації;

· Помилки, виявлені протягом року експлуатації;

· Кількість людей, які працювали над виробом;

· Строк розробки.

На основі цих даних зазвичай підраховуються прості метрики для оцінки продуктивності праці (KLOC/людино-місяць). Ці метрики не універсальні, особливо метрика LOC, яка суттєво залежить від обраної мови програмування. Найпростішим і розповсюдженішим способом оцінки об’єму робіт по проекту є кількість рядків вихідного коду (LOC, SLOC – Source LOC). Спочатку даний показник виник як спосіб оцінки роботи по проекту, в якому застосовувались мови програмування, що мали досить просту структуру: «один рядок коду = одна команда мови». Проте відомо, що одну функціональність можна написати різною кількістю рядків, а сучасні середовища розробки генерують тисячі рядків коду. Тому LOC метод є лише оціночним методом, який слід приймати до уваги, але не опиратися на нього в оцінках.

Залежно від того, яким чином враховується вихідний код, виділяють 2 основних показники SLOC:

1) Кількість «фізичних» рядків коду – SLOC (також використовують абревіатури LOC, SLOC, KLOC, KSLOC, DSLOC) – визначається як загальна кількість рядків вихідного коду, включаючи коментарі та порожні рядки. При вимірі показника на кількість порожніх рядків, як правило, вводиться обмеження – враховується не більш як 25% від кількості рядків у блоці коду, що вимірюється.

2) Кількість логічних рядків коду – SLOC (також використовуються абревіатури LSI, DSI, KDSI, де SI – source instructions) – визначається як заальна кількість команд і залежить від мови програмування, що використовується. Якщо мова програмування підтримує розміщення кількох команд на одному рядку, то один фізичний рядок повинен бути врахованим як кілька логічних, при умові, що він містить більше, ніж одну команду мови.

Для метрики SLOC існує багато похідних показників для визначення:

· Кількості порожніх рядків;

· Кількості рядків, що містять коментарі;

· Відсоток коментарів;

· Середня кількість рядків для функцій (класів, файлів);

· Середня кількість рядків для модулів.

Іноді важливо дізнатися густину коментарів, тобто в якій частині код був документований добре, а потім – погано. Суть метрики проста: код розбивається на n рівних частин і для кожної визначається:

Отже, потенційні недоліки SLOC наступні:

· Неправильно зводити оцінку роботи людини до кількох числових параметрів. Менеджер може назначити найбільш талановитих програмістів на найважчу частину роботи, де, відповідно, виникне найбільша кількість помилок і найбільші затрати часу. Інший менеджер по таким даним може погано оцінити їх роботу;

· Метрика не враховує досвід працівників та інші їх якості;

· Неточність: немає метрик, які були б одночасно і значущими, і достатньо точними. Наприклад, кількість рядків коду не дає уявлення про складність задачі, що вирішується.

· Метрика не відображає трудоємкості створення програми.

Метрики складності

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

Дата добавления: 2014-01-07