Лекція 15. Вимірюваня і оцінка складності програм

Метрики ПЗ

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

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

Таблиця 15.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. Кількість зовнішніх інтерфейсних файлів. Підраховуються всі логічні файли з інших застосувань, на які посилається дане застосування.

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

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

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

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

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

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

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

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

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

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

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

Таблиця 15.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

Приклади елементів даних для різних характеристик приведені в табл. 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 >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
1 2-5 >5	Низький (7) Низький (7) Середній (10)	Низький (7) Середній (10) Високий (15)	Середній (10) Високий (15) Високий (15)

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

Типи елементів-записів	Елементи даних
	1-19	20-50	>50
1 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. Визначення системних параметрів додатку

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

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

;

;

;

.

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

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

Таблиця 15.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, результати перерахунку залежать від мови програмування, використовуваного для реалізації ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

f1, f2.,f_n.

• Крок 2. Для кожної функції fi, планувальник формує кращу LOCлучшi (FРлучшi), гіршу LOCхудшi (FРхудшi) і вірогідну оцінку LOCвероятнi (FРвероятнi). Використовуються досвідчені дані (з метричного базису) або інтуїція. Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.

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

LOCожi =(LOCлучшi + LOCхудшi +4x LOCвероятнi )/ 6.

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

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

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

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

Проїзвi =ПРОИЗВ_срх(LOCср /LOCожi),

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

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

Проїзвi =ПРОИЗВ_анiх(LOCанi /LOCожi).

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

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

;

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

.

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

,

де Уд_стоїмостьср — метрика середньої вартості одного рядка, узята з метричного базису.

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

де Уд_стоїмостьанi — метрика вартості одного рядка аналога, узята з метричного базису. Приклад застосування даного процесу оцінки приведемо нижче.

Конструктивна модель вартості

У даній моделі для виведення формул використовувався статистичний підхід — враховувалися реальні результати величезної кількості проектів. Автор оригінальної моделі — Баррі Боем (1981) — дал їй назва СОСОМО 81 (Constructive Cost Model) і ввів в її склад три разные по складності статистичні подмодели [1].

Ієрархію подмоделей Боема (версії 1981 року) утворюють:

• базисна СОСОМО — статична модель, обчислює витрати розробки і її вартість як функцію розміру програми;

• проміжна СОСОМО — додатково враховує атрибути вартості, що включають основні оцінки продукту, апаратури, персоналу і проектного середовища;

• вдосконалена СОСОМО — об'єднує всі характеристики проміжної моделі, додатково враховує вплив всіх атрибутів вартості на кожен етап процесу розробки ПО (аналіз, проектування, кодування, тестування і т. д.).

Подмоделі СОСОМО 81 можуть застосовуватися до трьом типам програмних проектів. По термінології Боема, їх утворюють:

• поширений тип — невеликі програмні проекти, над якими працює невелика група розробників з хорошим стажем роботи, встановлюються м'які вимоги до проекту;

• напівнезалежний тип — середній за розміром проект, виконується групою розробників з різним досвідом, встановлюються як м'які, так і жорсткі вимоги до проекту;

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

Рівняння базової подмодели мають вигляд

Е=аbx(KLOC) [чел-мес];

D = cbx (E) [мес],

де Е — витрати в людино-місяцях, D — час розробки, KLOC — кількість рядків в програмному продукті.

Коефіцієнти аb, bb, сb, db беруться з табл. 2.14.

Таблиця 15.14. Коефіцієнти для базової подмодели СОСОМО 81

Тип проекту	аb	bb	сb	db
Поширений	2,4	1,05	2,5	0,38
Напівнезалежний	3,0	1,12	2,5	0,35
Вбудований	3,6	1,20	2,5	0,32

У 1995 році Боем ввів досконалішу модель СОСОМО II, орієнтовану на застосування в програмній інженерії XXI століття [21].

До складу СОСОМО II входять:

• модель композиції додатку;

• модель раннього етапу проектування;

• модель етапу пост-архитектуры.

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

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

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

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

• обговорюється взаємодія ПО і комп'ютерної системи;

• оцінюється продуктивність;

• визначається ступінь зрілості технології.

Модель композиції додатку орієнтована на застосування об'єктних покажчиків.

Об'єктний покажчик — засіб непрямого вимірювання ПО, для його розрахунку визначається кількість екранів (як елементів призначеного для користувача інтерфейсу), звітів і компонентів, потрібних для побудови додатку. Як показано в табл. 2.15, кожен об'єктний екземпляр (екран, звіт) відносять до одного з трьох рівнів складності. Тут місця підстановки зміряних і обчислених значень відмічені прямокутниками (прямокутник грає роль мітки-заповнювача). У свою чергу, складність є функцією від параметрів клієнтських і серверних таблиць даних (див. табл. 2.16 і 2.17), які потрібні для генерації екрану і звіту, а також від кількості уявлень і секцій, що входять в екран або звіт.

Таблиця 15.15. Оцінка кількості об'єктних покажчиків

Тип об'єкту	Кількість	Вага			Разом
		Простій	Середній	Складний
Екран	0	х1	х2	х3	= 0
Звіт	0	х2	х5	х8	= 0
3GL компонент	0			х10	= 0
Об'єктні покажчики					= 0

Таблиця 15.16. Оцінка складності екрану

Екрани	Кількість серверних (срв) і клієнтських (клт) таблиць даних
Кількість уявлень	Всього < 4 (< 2 срв, <3клт)	Всього < 8 (2-3 срв, 3-5 клт)	Всього > 8 (>3срв, >5клт)
<3	Простій	Простій	Середній
3-7	Простій	Середній	Складний
>8	Середній	Складний	Складний

Таблиця 15.17. Оцінка складності звіту

Звіти	Кількість серверних (срв) і клієнтських (клт) таблиць даних
Кількість уявлень	Всього < 4 (< 2 срв < 3 клт)	Всього < 8 (2-3 срв, 3-5 клт)	Всього > 8 (>3срв > 5 клт)
0 або 1	Простій	Простій	Середній
2 або 3	Простій	Середній	Складний
>4	Середній	Складний	Складний

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

Для обліку реальних умов розробки обчислюється відсоток повторного використання програмних компонентів %REUSE і визначається кількість нових об'єктних покажчиків NOP:

NOP = (Об'єктні покажчики) х [(100 - %REUSE) /100].

Для оцінки витрат, заснованої на величині NOP, треба знати швидкість розробки продукту PROD. Цю швидкість визначають по табл. 2.18, що враховує рівень досвідченості розробників і зрілість середовища розробки.

Проектні витрати оцінюються по формулі

ВИТРАТИ = NOP /PROD [чіл.-мес]

де PROD — продуктивність розробки, виражена в термінах об'єктних покажчиків.

Таблиця 15.18. Оцінка швидкості розробки

Досвідченість / можливості розробника	Зрілість / можливості середовища розробки	PROD
Дуже низька	Дуже низька	4
Низька	Низька	7
Номінальна	Номінальна	13
Висока	Висока	25
Дуже висока	Дуже висока	50

У розвиненіших моделях додатково враховується безліч масштабних чинників, формувачів витрат, процедур поправок.