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

Розмірно-орієнтовані метрики прямо вимірюють програмний продукт і процес його розробки. Грунтуються розмірно-орієнтовані метрики на LOC-оцінках (Lines Of Code). LOC-оцінка - це кількість рядків у програмному продукті.

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

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

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

Таблиця містить дані про проекти за останні кілька років. Наприклад, запис про проект aaa01 показує: 12 100 рядків програми були розроблені за 24 людино-місяці і коштували $ 168 000. Крім того, за проектом aaa01 було розроблено 365 сторінок документації, а протягом першого року експлуатації було зареєстровано 29 помилок. Розробляли проект aaa01 три людини.

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

;

;

;

.

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

1. широко поширені;

2. прості і легко обчислюються.

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

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

2. вимагають вихідних даних, які важко отримати на початковій стадії проекту;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип елемента даних - унікальне не рекурсивне (неповторюване) поле, розпізнаване користувачем.

Як приклад розглянемо табл. 2.2.

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

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

Рівень активності дня тижня
День	День	День	День
Понеділок	Понеділок	Понеділок	Понеділок
Вівторок	Вівторок	Вівторок	Вівторок
Середа	Середа	Середа	Середа
Четвер	Четвер	Четвер	Четвер
Пятниця	Пятниця	Пятниця	Пятниця
Субота	Субота	Субота	Субота
Неділя	Неділя	Неділя	Неділя
Сума по робочих днях	Сума по робочих днях	Сума по робочих днях	Сума по робочих днях
Сума по вихідних днях	Сума по вихідних днях	Сума по вихідних днях	Сума по вихідних днях

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

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

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

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

Елемент даних

Правило обліку

Група радіокнопок Група прапорців (перемикачів) Командні кнопки Списки

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

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

Обговоримо порядок обліку повідомлень. У додатку з графічним інтерфейсом генеруються три типи повідомлень: повідомлення про помилку, повідомлення підтвердження та повідомлення повідомлення. Повідомлення про помилку (наприклад, знадобиться пароль) і повідомлення підтвердження (наприклад, Ви дійсно хочете видалити клієнта?) Вказують, що сталася помилка або що процес може бути завершений. Ці повідомлення не утворюють самостійного процесу, вони є частиною іншого процесу, тобто вважаються елементом даних відповідної транзакції.

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

Повідомлення повідомлення розглядається як зовнішній вивід.

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

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

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

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

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

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

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

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

Типи елементів-записів	Елементи даних
	1-19	20-50	>50
1 2-5 >5	Низький (7) Низький (7) Середній (10)	Низький (7) Середній (10) Високий (15)	Середній (10) Високий (15) Високий (15)

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

Типи елементів-записів	Елементи даних
	1-19	20-50	>50
1 2-5 >5	Низький (5) Низький (5) Середній (7)	Ниький (5) Середній (7) Високий (10)	Середній (7) Високий (10) Високий (10)

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

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

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

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

Ім’я характеристики	Ранг, складність, кількість
	Низький	Середній	Високий	Разом
Зовнішні вводи	0x3 = __	0x4 = __	0x6 = __	= 0
Зовнішні виводи	0x4 = __	0x5 = __	0x7 = __	= 0
Зовнішні запити	0х3 = __	0x4 = __	0x6 = __	= 0
Внутрішні логічні файли Зовнішні інтерфейсні файли	0x7 = __ 0x5 = __	0x 10= __ 0x7 = __	0x15 = __ 0x10 = __	= 0 = 0
Загальна кількість				= 0

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

Кількість функціональних покажчиків обчислюється за формулою

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

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

Кожен коефіцієнт може приймати такі значення: 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 на його основі формуються метрики продуктивності, якості і т. д.:

;

;

;

.

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

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

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

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

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

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

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

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

Недолік функціонально-орієнтованих метрик: результати засновані на суб'єктивних даних, використовуються не прямі, а непрямі вимірювання. FP-оцінки легко перерахувати в LOC-оцінки. Як показано в табл. 2.13, результати перерахунку залежать від мови програмування, що використовується для реалізації ПЗ.

Таблиця 2.13. Перерахунок FP-оцінок в LOC-оцінки

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

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

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

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

Мета цієї діяльності - сформувати попередні оцінки, які дозволять:

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

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

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

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

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

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

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

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

Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.

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

LOC_{очік і} = (LOC_{кращ і} + LOC_{гірш і} +4 * LOC_{ймовірн і}) / 6.

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

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

2) для і-ї функції на основі метрики середньої продуктивності обчислюється настроюється величина продуктивності:

ПРОДУКТ_i = ПРОДУКТ_ср * (LOC_сер / LOC_{очік і}),

де LOC_cеp - середня LOC-оцінка, взята з метричного базису (відповідає середній продуктивності);

3) для і-ї функції величина продуктивності обчислюється по аналогу, взятому з метричного базису:

ПРОДУКТ_i = ПРОДУКТВ_{ан i} * (LOC_{ан i} / LOC_{очік i}).

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

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

;

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

.

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

,

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

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

 

де ПИТ_ВАРТІСТЬ_{ан i} - метрика вартості одного рядка аналога, взята з метричного базису. Приклад застосування даного процесу оцінки наведемо нижче.

8