ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

- зовнішній вивід (External Output - ЕО) - транзакція, при вико­нанні якої дані перетинають межу додатка зсередини. З ILF і EIF створюються файли виведення або повідомлення і відправляються іншому застосуванню. Виведення також містить похідні дані, що отримуються з ILF;

- зовнішній запит (External Inquiry -EQ) - транзакція, в разі ви­конання якої відбувається одночасне введення і виведення. У ре­зультаті інформація вертається з одного або більше ILF і EIF, Ви­ведення не містить похідних даних, a ILF не оновлюється.

Класи компонентів оцінюються ПО за складністю і належать до категорії високого, середнього або низького рівня складності. Для транзакцій (ЕІ, ЕО, EQ) рівень визначається ПО за кількістю фай­лів, на які посилається транзакція (File Types Referenced — FTR) і кількості типів елементів даних (Data Element Types - DET). Для ILF і EIF мають значення типи елементів записів (Record Element Types - RET) і DET. Типи елементів записів - цс підгрупа елементів даних у ILF або EIF. Типи елементів даних - це унікальне, не реку­рсивне поле підмножини ILF або EIF. Рівні складності і відповідні ним значення FTR і DET описані в FPCPM.

Наприклад, для ЕI з кількістю FTR від трьох і більше, і DЕТ(від 5 до 15) рівень складності визначається як високий. Далі компонен­ти розподіляються ПЗ за «ваговими категоріями» залежно від рівня їх складності. Наприклад, ILF середньої складності має значення 10, a EQ високої складності - значення 6. Після цього, робиться розрахунок нескоригованих функціональних точок (Unadjusted Function Point - UFP) ПЗ у відповідній формулі [1]:

,

де N_ij- i W_ij - кількість екземплярів класу і складності j і ного вагоме значення відповідно. Результат розрахунку може бути скоригова­ний за допомогою чинника регулювання вартості (Value Adjustment Factor - VAF). Під час розрахунку VAF враховуються чотирнадцять загальних характеристик системи (General System Characteristic -GSC), які оцінюють загальну функціональність застосування, що розробляється. Ці характеристики відображають можливість пов­торного використання коду, продуктивність, можливість розподі­леної обробки та інші властивості додатка. Кожній GSC привлас­нюється значення від 0 до 5. Після того, як враховані всі чотирнад­цяті, загальних характеристик системи, розраховується чинник ре­гулювання вартості ПО за формулою [4]

,

де C_j-ступінь виливу i-ї GSC. Останньою розраховується кількість повних функціональних точок: FP-UAF* VAF,

Існують додатки, під час оцінювання яких використання стан­дартних функціональних точок не ефективне. Ці застосування такі: управління процесом у реальному часі, математичні обчислення, симуляція, системні застосування, інженерні застосування, вбудо­вані системи. Перераховані застосування відрізняються високою інтенсивністю обчислень, часто заснованих на алгоритмах підви­щеної складності. Для вирішення завдань розрахунку розміру вка­заних застосувань у 1986 році організацією Software Productivity Research (SPR) була розроблена методика аналізу характерних то­чок ПЗ (feature points). Суть її полягає в тому, що оцінюється кіль­кість алгоритмів у програмі і частково модифікується ступінь зна­чущості (weighting values) для розрахунку FP. Ця методика вважа­ється експериментальною.

7.2. Методи і моделі оцінювання вартості програмного забезпечення

Методи і моделі оцінювання вартості ПЗ можна розділити на дві групи: неалгоритмічні методи і алгоритмічні моделі. До неалгорит-мінних методів належать Price-to-win, оцінка ПЗ Паркінсона, екс­пертна оцінка, оцінка за аналогією. До алгоритмічних моделей, на­лежать SLIM і COCOMO.

Суть неалгоритмічних методів полягає в тому, що при оціню­ванні вартості ПО використовуються певні схеми і принципи, а не математичні формули. Нижче проаналізуємо ці методи.

Price-to-win. Метод грунтується на принципі «клієнт, завжди має рацію». Суть методу полягає в тому, то незалежно від передбачу­ваних реальних витрат на розробку проекту, оцінка вартості ПО коригується відповідно до побажань замовника. Price-to-win фак­тично є політикою проведення переговорів з клієнтом, тому оціню­вання часто застосовується компаніями, що не мають засобів для якісного оцінювання проектів. Застосування методу може мати для розробника певні негативні наслідки: брак ресурсів для виконання проекту, невиконання термінів здачі проекту і як результат — втрата контракту або банкрутство.