Метрики ПЗ

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

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

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

Проект Витрати, чіл.-мес Вартість, тис. $ KLOC, тис. LOC Прогр. док- ти, сторінок Помилки Люди
ааа01     12,1      
bbb02     27,2      
ссс03     20,2      

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

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

;

;

;

.

Достоїнства розмірно-орієнтованих метрик:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип елементу даних — унікальне не рекурсивне (неповторюване) поле, розпізнаване користувачем. Як приклад розглянемо табл. 15.2.

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

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

Рівень активності дня тижня
День Хіти % від Сума хітів Сеанси користувача
Понеділок   16,41  
Вівторок   13,45  
Середа   17,17  
Четвер   13,83  
П'ятниця   19,21  
Субота   11,18  
Неділя   8,73  
Сума по робочих днях   80,08  
Сума по вихідних днях   19,91  

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

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

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

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

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

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

Зазвичай одному екрану GUI відповідає декілька транзакцій. Типовий екран включає декілька зовнішніх запитів, супроводжуючих зовнішнє введення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Початкові дані для розрахунку зводяться в табл. 15.10.

Таблиця 15.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 x ), (2.1)

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

Кожен коефіцієнт може набувати наступних значень: 0 — немає впливу, 1 — випадкове, 2 — невелике, 3 — середнє, 4 — важливе, 5 — основне.

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

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

Системний параметр Опис
  Передачі даних Скільки засобів зв'язку потрібно для передачі або обміну інформацією з додатком або системою?
  Розподілена обробка даних Як обробляються розподілені дані і функції обробки?
  Продуктивність Чи має потребу користувач у фіксації часу відповіді або продуктивності?.
  Поширеність використовуваної конфігурації Наскільки поширена поточна апаратна платформа, на якій виконуватиметься додаток?
  Швидкість транзакцій Як часто виконуються транзакції? (щодня, кожного тижня, кожного місяця)
  Оперативне введення даних Який відсоток інформації треба вводити в режимі онлайн?
  Ефективність роботи кінцевого користувача Додаток проектувався для забезпечення ефективної роботи кінцевого користувача?
  Оперативне оновлення Як багато внутрішніх файлів оновлюється в онлайновій транзакції?
  Складність обробки Чи виконує додаток інтенсивну логічну або математичну обробку?
  Повторна використовувана Додаток розроблявся для задоволення вимог одного або багатьох користувачів?
  Легкість інсталяції Наскільки важкі перетворення і інсталяція додатку?
  Легкість експлуатації Наскільки ефективні і/або автоматизовані процедури запуску, резервування і відновлення?
  Різноманітні умови розміщення Чи була спроектована, розроблена і підтримана можливість інсталяції додатку в різних місцях для різних організацій?
  Простота змін Чи була спроектована, розроблена і підтримана в додатку простота змін?

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

;

;

;

.

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

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

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

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

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

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

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

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

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

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

Мова програмування Кількість операторів на один FP
Асемблер З  
Кобол  
Фортран  
Паскаль  
C++  
Java  
Ada 95  
Visual Basic  
Visual C++  
Delphi Pascal  
Smalltalk  
Perl  
HTML3  
LISP  
Prolog  
Miranda  
Haskell  

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  




Подборка статей по вашей теме: