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

Розмірно-орієнтовані метрики прямо вимірюють програмний продукт і процес його розробки. Базуються розмірно-орієнтовані метрики на LOG-оцін­ках (Lines Of Code). LOС-оцін­ка – це кількість стрічок в програмному продук­ті.

Вихідні дані для розрахунку метрик заносяться в таблицю (табл. 2.1).

Таблиця 2.1. Вихідні дані для розрахунку LOС-метрик

Проект	Затрати люд.-міс.	Вартість, тис. грн	KLOC, тис. LOC	Прог. док., стор.	Помилки	Люди
Проект 1	24	168	12,1	365	29	3
Проект 2	62	440	27,2	1224	86	5
Проект 3	43	314	20,2	1050	64	6

Таблиця містить дані про проекти за декілька останніх років. На протязі першого року експлуатації виявлено 29 помилок.

На основі таблиці обраховуємо розмірно-орієнтовані метрики продук­ти­в­ності та якості (для кожного проекту):

Прод. = Довжина (тис. LOС )Затрати (люд.-міс.);

Якість = Помилки (одиниць) Довжина (тис. LOС );

Питома вартість = Вартість (тис. грн..)  Довжина (тис. LOС );

Документованість = Сторінок (стор.)  Довжина (тис. LOС ).

Перевагами розмірно-орієнтованих метрик:

• широке застосування;

• простота та легкість обчислень.

Недоліки розмірно-орієнтованих метрик:

• залежність від мови програмування;

• вимога вихідних даних, які складно отримати на початковій стадії проекту;

• не пристосованість до не процедурних мов програмування.

Функціонально-орієнтовані метрики

Функціонально-орієнтовані метрики дотично вимірюють програмний продукт і процес його розробки. Замість розрахунку LOС-оцінки при цьому розглядається не розмір, а функціональність або корисність продукту.

Використовується 5 інформаційних характеристик.

1. Кількість зовнішніх входів. Підраховуються всі вводи користувача, по яких вводяться різні прикладні дані. Вводи повинні бути відділені від запитів, які підраховуються окремо.

2. Кількість зовнішніх виводів. Підраховуються всі виводи, по яких до користувача поступають результати, обчислені програмним додатком. В цьому контексті виводи означають звіти, екрани, роздруківки, повідомлення про по­милки. Індивідуальні одиниці даних в середині звіту окремо не підраховуються.

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

4. Кількість внутрішніх логічних файлів. Підраховуються всі логічні файли (тобто логічні групи даних, які можуть бути частиною бази даних або окремим файлом).

5. Кількість зовнішніх інтерфейс них файлів. Підраховуються всі логічні файли з інших додатків, на які сси лається даний додаток.

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

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

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

Внутрішній логічний файл – розпізнавана користувачем група логічно зв’язаних даних, яка розміщена в середині іншого додатку і підтримується їм. Зовнішній файл даного додатку є внутрішнім логічним файлом в іншому додат­ку.

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

Для транзакцій впорядкування базується на кількості звертань на файли і кількості типів елементів даних. Для файлів впорядкування базується на кіль­кості типів елементів-записів і типів елементів даних, що входять у файл.

Тип елемента-запису – підгрупа елементів даних, що розпізнається ко­ристувачем в межах файлу.

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

В цій таблиці 10 елементів даних: День, Хіти, % від Суми хітів, Сеанси користувача, Сума хітів (по робочим дням), % від Суми хітів (по робочим дням), Сума сеансів користувача (по робочим дням), Сума хітів (по вихідним дням), % від Суми хітів (по вихідним дням), Сума сеансів користувача (по ви­хідним дням). Відмічаємо, що поля День, Хіти, % від суми хітів, Сеанси корис­тувача мають рекурсивні дані, які в розрахунку не враховуються.

Таблиця 2.2. Приклад для розрахунку елементів даних

Рівень активності дня неділі
День	Хіти	% від Суми хітів	Сеанси користувача
Понеділок	1887	16,41	201
Вівторок	1547	13,45	177
Середа	1975	17,17	195
Четвер	1591	13,83	191
П’ятниця	2209	19,21	200
Субота	1286	11,18	121
Неділя	1004	8,73	111
Сума по робочим дням	9209	80,08	964
Сума по вихідним дням	2290	19,91	232

Приклади елементів даних для різних характеристик наведено в табл. 2.3, а в табл. 2.4 містить правила обліку елементів даних з графічного інтерфе­йсу користувача (GUI).

Таблиця 2.3. Приклади елементів даних

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

Таблиця 2.4. Правила врахування даних з графічного інтерфейсу користувача

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

Наприклад, GUI для обслуговування клієнтів може мати поля Ім’я, Ад­ре­са, Місто, Країна, Почтовий індекс, Телефон, Email. Таким чином, маємо сім полів або сім елементів даних. Восьмим елементом даних може бути командна кнопка (добавити, змінити, видалити). В цьому випадку кожний із зовнішніх вводів Добавити, Змінити, Видалити буде складатися з 8 елементів даних (7 по­лів + командна кнопка). Як правило одному елементу GUI відповідає декілька транзакцій. Типовий екран включає декілька зовнішніх запитів, які супровод­жу­ють зовнішній ввід.

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

Дані для визначення рангу і оцінки складності транзакції і файлів наве­дені в табл. 2.5 – 2.9 (числова оцінка вказана в круглих дужках). Використання їх дуже проста. Наприклад, зовнішньому вводу, який посилається на 2 файли і має 7 елементів даних, по табл. 2.5 назначається середній ранг і оцінка складно­сті 4.

Таблиця 2.5. Ранг і оцінка складності зовнішніх вводів

Посилання на файли	Елементи даних
	1 - 4	5 - 15	15
0 – 1	Низький (3)	Низький (3)	Середній (4)
2	Низький (3)	Низький (3)	Високий (6)
2	Середній (4)	Високий (6)	Високий (6)

Таблиця 2.6. Ранг і оцінка складності зовнішніх виводів

Посилання на файли	Елементи даних
	1 - 4	5 - 19	19
0 – 1	Низький (4)	Низький (4)	Середній (5)
2 - 3	Низький (4)	Середній (5)	Високий (7)
3	Середній (5)	Високий (7)	Високий (7)

Таблиця 2.7. Ранг і оцінка складності зовнішніх запитів

Посилання на файли	Елементи даних
	1 - 4	5 - 19	19
0 – 1	Низький (3)	Низький (3)	Середній (4)
2 - 3	Низький (3)	Середній (4)	Високий (6)
3	Середній (4)	Високий (6)	Високий (6)

Таблиця 2.8. Ранг і оцінка складності внутрішніх логічних файлів

Посилання на файли	Елементи даних
	1 - 4	5 - 19	19
0 – 1	Низький (7)	Низький (7)	Середній (10)
2 - 5	Низький (7)	Середній (10)	Високий (15)
 5	Середній (10)	Високий (15)	Високий (15)

Таблиця 2.9. Ранг і оцінка складності зовнішніх інтерфейс них файлів

Посилання на файли	Елементи даних
	1 - 4	5 - 19	19
0 – 1	Низький (5)	Низький (5)	Середній (7)
2 - 5	Низький (5)	Середній (7)	Високий (10)
 5	Середній (7)	Високий (10)	Високий (10)

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

Після отримання всієї необхідної інформації переходять до розрахунку метрики – кількості функціональних показників FP (Function Points). Автором даної метрики є А. Албрехт (1979).

Вихідні дані для розрахунку формуються в табл. 2.10.

Таблиця 2.10. Вихідні дані для розрахунку FP-метрик

Ім’я характеристики	Ранг, складність, кількість
	Низький	Середній	Високий	Результат
Зовнішні вводи	3=__	4=__	6=__	= 
Зовнішні виводи	4=__	5=__	7=__	= 
Зовнішні запити	3=__	4=__	6=__	= 
Внутрішні логічні файли	7=__	10=__	15=__	= 
Зовнішні інтерфейсні файли	5=__	7=__	10=__	= 
Загальна кількість = 

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

FP = Загальна кількість (0,65 + 0,01 ,

де F_i – коефіцієнт регулювання складності.

Кожен коефіцієнт може приймати наступні значення: 0 – нема впливу; 1 – випадковий; 2 – невеликий; 3 – середній; 4 – важливий; 5 – основний.

Значення вибираються емпірично в результаті відповіді на 14 запитань, які характеризують системні параметри додатку (табл. 2.11).

Таблиця 2.11. Визначення системних параметрів додатку

№	Системний параметр	Опис
1	Передача даних	Скільки засобів зв’язку необхідно для передачі або обміну інформацією з додатками або системою
2	Розподіл обробки даних	Як обробляються розподілені дані і функції обробки
3	Продуктивність	Чи необхідна користувачу фіксації часу відповіді або продуктивність?
4	Розповсюдженість конфігу­ра­ції що використовується	Наскільки поширена дана апаратна платформа, на якій буде виконуватись додаток?
5	Швидкість транзакції	Як часто виконуються транзакції? (кожен день, кож­ну неділю, кожен місяць)
6	Оперативний ввід даних	Який процент інформації необхідно вводити в режи­мі онлайн?
7	Ефективність роботи кінцевого користувача	Додатки проектувалися для забезпечення ефективної роботи кінцевого користувача?
8	Оперативне оновлення	Як багато внутрішніх файлів обновляється в онлай­но­вій транзакції
9	Складність обробки	Чи виконує додаток інтенсивну логічну або марема­ти­чну обробку?
10	Повторне використання	Додатки розроблялись для одного чи багатьох користувачів?
11	Легкість інсталяції	Наскільки складне перетворення та інсталяція додатку?
12	Легкість експлуатації	Наскільки ефективні іабо автоматизовані процедури запуску, резервування та відновлення?
13	Різноманітні умови розміщення	Чи була передбачена можливість інсталяції додатків в різних умовах для різних організацій
14	Простота змін	Чи була передбачена в додатках простоти змін?

Після обчислення FP на його основі формуються метрики продуктивності, якості та інше:

Продуктивн. = ФункцПоказник (FP )Затрати (люд.-міс.)

Якість = Помилки (Одиниці) ФункцПоказник (FP )

Питома Вартість = Вартість (тис. грн..) ФункцПоказник (FP )

Документованість = СтрінДокументу (стор.) ФункцПоказник (FP )

Область застосування методу функціональних показників – комерційні інформаційні системи. Для продуктів з високою алгоритмічною складністю ви­користовуються метрики показника властивості (Features Points). Їх можливо застосовувати і при інженерному ПЗ, ПЗ реального часу та вбудованих ПЗ.

Для розрахунку показника властивості добавляється одна характерис­ти­ка – кількість алгоритмів. Алгоритмом тут визначено обмежену програму об­числень, яка включається в загальну комп’ютерну програму. Приклади алго­ри­тмів: обробка переривань; інвертування матриці; розкодування бітової стрічки. Для формування показника властивостей складається табл. 2. 12.

Таблиця 2.12. Вихідні дані для розрахунку показника властивостей

№	Характеристика	Кількість	Складність	Сума
1	Вводи		4	=
2	Виводи		5	=
3	Запити		4	=
4	Логічні файли		7	=
5	Інтерфейсні файли		7	=
6	Якість алгоритмів		3	=
Загальна кількість =

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

Переваги функціонально-орієнтованих метрик:

1. Не залежить від мови програмування.

2. Легко обчислюється на любій стадії проекту.

Недоліки функціонально-орієнтованих метрик: результати базуються на суб’єктивних даних, використовуються не прямі, а посередні виміри.

FP- оцінки легко перерахувати в LOC-оцінки. Як показано в табл.2. 13, результати перерахунку залежать від мови програмування, що використовує­ть­ся для реалізації ПЗ.

Мова програмування	Кількість операторів на один FP
Асемблер	320
С	128
Кобол	106
Фортран	106
Паскаль	90
С++	64
Java	53
Ada 95	49
Visual Basic	32
Visual C++	34
Smalltalk	22
Perl	21
Delphi Pascal	29
HTML 3	15
LISP	64
Prolog	64
Miranda	40

Виконання оцінки в ході керівництва проектом

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

Проведення оцінки проекту на основі LOC i FP-метрик

Ціль цієї роботи – сформувати попередні оцінки, що дозволяють:

• подати замовнику коректні вимоги по вартості і витратам на розробку програмного продукту;

• скласти план розробки програмного проекту.

При проведенні оцінки можливі два варіанти використання LOC i FP-даних:

• в якості оціночних змінних, які визначають розмір кожного еле­мента продукту;

• в якості метрик, зібраних за минулі проекти і які входять в метрич­ний базис фірми;

Обговоримо кроки процесу оцінки.

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

f₁, f₂,…, f_n.

2. Крок 2. Для кожної функції f_і планувальник формує кращу LOC_кращ (FP_кращ), гіршу LOC_гірш (FP_гірш) та імовірнісну оцінку LOC_імов (FP_імов). Викорис­товуються дослідні дані (з метричного базису) або інтуїція. Діапазон значень оцінок відповідає передбаченій невизначеності.

3. Крок 3. Для кожної функції f_і в відповідності з -розподілом вирахо­вується очікуване значення LOC (або FP-) оцінки:

LOC_очік = (LOC_кращ + LOC_гірш + 4 LOC_імов)/6.

4. Крок 4. Визначає значення LOC або FP- продуктивності розробки функції.

Використовується один з трьох підходів:

1. для всіх функцій приймається одна й таж сама метрика середньої продуктивності ПРОД_сер вибрана з метричного базису;

2. для і-тої функції на основі метрики середньої продуктивності вирахо­вується налаштовувана величина продуктивності:

3. ПРОД_і = ПРОД_сер  (LOC_сер/ LOC_очік),

4. для і-тої функції налаштовувана величина продуктивності розрахову­ється за аналогом, що береться з метричного базису:

5. ПРОД_і = ПРОД_{анал і}  (LOC_{анал і}/ LOC_{очік і}).

Перший підхід забезпечує мінімальну точність (при максимальній прос­тоті обчислень), а третій підхід – максимальну точність (при максимальній складності обчислень).

5. Крок 5. Обчислюється загальна оцінка затрат на проект:

для першого підходу

ЗАТРАТИ = [люд-міс];

для другого та третього підходу

ЗАТРАТИ = [люд-міс].

6. Крок 6. Обчислюється загальна оцінка вартості проекту:

для першого та другого підходів

ВАРТІС =

ПТ_ВАРТІСТЬ_сер – метрика середньої вартості одної стрічки, взята з мет­ричного базису.

для третього підходу

ВАРТІС = ,

де ПТ_ВАРТІСТЬ_сер – метрика середньої вартості одної стрічки аналога, взята з мет­ричного базису.