М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Рис. 6.18. Модель автоматичного синтезу

Зазвичай для кожного проекту програмного забезпечення виби­рають моделі життєвого циклу. Під час вибору використовуються характеристики таких елементів розробки:

- вимога;

- команда розробників;

- колектив користувачів;

- тип проекту і ризики.

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

Розвиток моделей, методів і засобів оцінювання вартості прог­рамного забезпечення (ПЗ) сягнув рівня практичного застосування. Проте через відсутність інформації, засобів і фахівців зазначене не використовують під час розробки ПЗ в Україні.

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

Під час оцінювання вартості ПЗ використовують дві одиниці розміру: рядок коду (Line of Code - LOC) і функціональну крапку (Function Point - FP).

Line of Code - це рядок початкового коду ПЗ (виключаються порожні рядки, коментарі і специфічні оператори). До переваг ви­користати! LOC, як одиниці розміру ПЗ, відносять простоту, а не­доліками є: розмір проекту в LOC може бути визначений лише піс­ля його завершення; LOC залежить від мови програмування; LOC не враховує якість коду. Продуктивність (S) програміста з викори­станням LOC розраховується ПЗ за такою формулою:

,

де n - кількість рядків коду, написаних програмістом (LOC); m -час роботи програміста (у людино-годинах). Видно, що чим більше рядків коду, тим вище продуктивність розробника. Проте можна реалізувати одну і ту ж функцію, написавши меншу кількість ряд­ків коду. Одиниця розміру LOC не відображає функціональні влас­тивості коду. Тому, якщо розробник прагне оптимізувати процес розробки задля зменшення трудовитрат На реалізацію проекту, то при використанні LOC як основної одиниці розміру проекту під зменшенням трудовитрат мається на увазі Зменшення кількості рядків коду в програмі, при цьому не оцінюється його функціональ­ність.

Існують також проблеми із застосуванням LOC і в проектах, що використовують декілька мов програмування. Наприклад, 10.000 LOC мови С++, очевидно, не можна порівнювати з 10.000 LOC мо­ви COBOL, а в разі застосування автоматизованих або заснованих на шаблонах візуальних засобів розробки розрахунок LOC тим менш ефективний, ніж більше коду створюється автоматично.

Function Point була введена як альтернатива LOC. Методика аналізу функціональних точок була розроблена А. Дж. Альбректом (A. J. Albrecht) для компанії IBM у середині 70-х років XX ст., коли виникла потреба и підході до оцінювання витрат праці на розробку ПО, який би не залежав від мови і середовища розробки. З 1986 р. просування методики і розробку відповідного стандарту продовжує International Function Point User Group (IFPUG). Ця організація розробила керування програмним забезпеченням на практиці засто­сування розрахунку функціональних точок (Function Point Counting Practices Manual - FPCPM) і остання версія цього документа (4.1) офіційно визнана ISO як стандарт оцінювання розміру ПЗ.

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

Відповідно до прийнятого стандарту використовуються п'ять класів компонентів, на яких грунтується аналіз:

- внутрішній логічний файл (Internal Logical File - ILF) — група логічно пов'язаних даних, меж додатка, що знаходяться всередині, і підтримуваних введенням ззовні;

- зовнішній інтерфейсний файл (External Interface File - EIF) -група логічно пов'язаних даних, меж додатка, що знаходяться ззов­ні, і що є внутрішнім логічним файлом для іншого застосування;

- зовнішнє введення (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]