4.5.3. Методи оцінки розміру

SLOC. Цей метод базується на вимірюванні найбільш очевидної характеристики програмного забезпечення – кількості рядків коду у вихідних текстах.

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

Позитивними рисами цього методу є його наочність, легкість автоматизації, відсутність необхідності у навчанні спеціалістів, які будуть використовувати цей метод, легкість перевірки результатів [14].

Завдяки цим якостям метод SLOC набув широкого застосування, оскільки, головні його недоліки можна компенсувати введенням стандартів на стиль написання коду та чітким визначенням поняття рядка коду.

FPA. Головною метою розробників методу FPA є встановлення загальної одиниці виміру функціонального розміру програмного забезпечення (ПЗ), шкали виміру та методу вимірювання функціонального розміру. На відміну від методу SLOC, функціональний розмір не залежить від технологій, використаних для створення системи, стилю написання коду, або мови програмування. За стандартом ISO/IEC, функціональний розмір (ФР) програмного забезпечення є кількісною мірою його функціональності та визначається, як кількісна оцінка функціональних вимог користувача до ПЗ. Функціональні вимоги визначають процеси та процедури, які будуть виконуватись ПЗ, або, іншими словами, що буде програма робити. ФР не залежить від того, як буде ПЗ працювати (наприклад, від вимог до якості або продуктивності), або від особливостей реалізації ПЗ. Метод FPA придатний до вимірювання ПЗ у всіх сферах застосувань і був успішно застосований у широкому колі проектів, від систем керування ракетною зброєю до систем фінансової звітності.

FPA базується на таких визначеннях:

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

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

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

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

Для оцінки складності елементів, розглядаються такі їх характеристики, як кількість задіяних елементарних даних, типів записів та типів файлів.

Тип запису (ТЗ, Record Element Type, RET). ТЗ – підгрупа даних у файлі (ВЛФ або ЗІФ), яка розглядається користувачем як одне ціле. На відміну від файлів, в яких можуть бути виділені підгрупи даних, у ТЗ зазвичай дані тісно пов’язані та окремі елементи даних не несуть корисної інформації.

Тип файлу (ТФ, File Type Referenced, FTR). ТФ – файл (ВЛФ або ЗІФ), задіяний у транзакції.

Елементарний тип даних (ЕТД, Data Element Type, DET). ЕТД – значення у складі ТЗ, ВЛФ або ЗІФ, які розпізнаються користувачем як окремі, та не повторюються в межах однієї транзакції, запису або файлу. Повторювані поля враховуються як одне елементарне дане.

Функціональний розмір елементів системи залежності від кількості задіяних ТФ, ТЗ та ЕТД визначається таблицями 4.1-4.5:

Таблиця 4.1 - Складність та функціональний розмір внутрішнього логічного файлу

Кількість ТЗ	Кількість ЕТД
	1-19	20-50	> 50
1	Низька (7)	Низька (7)	Середня (10)
2-5	Низька (7)	Середня (10)	Висока (15)
> 5	Середня (10)	Висока (15)	Висока (15)

Таблиця 4.2 - Складність та функціональний розмір зовнішнього інтерфейсу

Кількість ТЗ	Кількість ЕТД
	1-19	20-50	> 50
1	Низька (5)	Низька (5)	Середня (7)
2-5	Низька (5)	Середня (7)	Висока (10)
> 5	Середня (7)	Висока (10)	Висока (10)

Таблиця 4.3 – Складність та функціональний розмір зовнішнього вводу

Кількість ТФ	Кількість ЕТД
	1-4	5-15	> 15
< 2	Низька (3)	Низька (3)	Середня (4)
2	Низька (3)	Середня (4)	Висока (6)
> 2	Середня (4)	Висока (6)	Висока (6)

Таблиця 4.4 - Складність та функціональний розмір зовнішнього виводу

Кількість ТФ	Кількість ЕТД
	1-5	6-19	> 19
< 2	Низька (4)	Низька (4)	Середня (5)
2 або 3	Низька (4)	Середня (5)	Висока (7)
> 3	Середня (5)	Висока (7)	Висока (7)

Таблиця 4.5 - Складність та функціональний розмір зовнішнього запиту

Кількість ТФ	Кількість ЕТД
	1-5	6-19	> 19
< 2	Низька (3)	Низька (3)	Середня (4)
2 або 3	Низька (3)	Середня (4)	Висока (6)
> 3	Середня (4)	Висока (6)	Висока (6)

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

MkII FPA. Метод MkII є клоном оригінального методу FPA, орієнтованим на оцінювання систем, які працюють з базами даних. Відповідно, з точки зору MkII, система складається з трьох типів елементів: Вхідні дані (Це дані, які надходять у систему, перетинаючи її межу), Результуючі дані (Це дані, які виходять із системи, перетинаючи її межу), Обробка даних (Це процес, який використовує вхідні дані та породжує результуючі дані) [14].

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

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

,

де N – відповідно, кількість вхідних або результуючих даних, або процесів обробки даних, а константи W мають значення W_вх=0.58, W_рез=0.26, W_обр=1.66 [15].

COSMIC FFP. COSMIC FFP базується на тих самих визначеннях межі ПЗ та елементарного процесу, що і FPA. Але, на відміну від FPA, відповідно до [16], система складається з процесів переміщення даних та процесів обробки даних, як показано на рис. 4.3.

Для оцінювання розміру у системі виділяються 4 типи базових процесів: Зовнішній ввід, Зовнішній вивід, Внутрішнє зчитування, Внутрішній запис.

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

,

де Card(множина) – це потужність множини підпроцесів певного типу.

Рис. 4.3 – Модель ПС з точки зору методу COSMIC FFP

Оцінювання процесів маніпулювання даними у версії методу, яка аналізувалася (v.2.2), не було визначене.

4.5.3 Методи оцінювання трудомісткості, тривалості та вартості проектів

COCOMO. У основі моделі COCOMO лежить припущення, що розмір системи, Size, виражений у одиницях KSLOC, та величина зусиль, необхідних для розробки проекту, виражена у людино-місяцях, PM, пов’язані таким співвідношенням:

Це припущення було перевірено на базі, яка включала 161 проект з розробки ПЗ [17].

Розрахунок зусиль на розробку. Оцінка зусиль на виконання проекту (у людино-місяцях) за COCOMO проводиться відповідно до наведених формул. Індекс NS у значень PM та TDEV позначає те, що ці оцінки зусиль та тривалості відносяться до номінального розкладу, тобто такого, який не враховує фактор стиснення/розтягування розкладу, SCED (Required Development Schedule – необхідний розклад розробки). Бюджет, виражений у людино-місяцях (person-month, PM), , оцінюється за формулою:

де

Константи A та B дорівнюють, відповідно, 2.94 та 0.91 [18].

Розрахунок тривалості та ціни. Тривалість розробки (time to develop, TDEV), , оцінюється за формулою:

де

Значення n, кількості мультиплікативних факторів, EM_i, дорівнює 16. Символом SF_j позначено експоненційні фактори. Розмір має бути вираженим у одиницях KSLOC. Константи C та D дорівнюють, відповідно, 3.67 та 0.28 [18].

Вартість проекту визначається множенням кількісної величини зусиль, виражених у людино-місяцях, на вартість людино-місяця.

4.5.4. Побудова методики оцінювання проектів

Аналіз можливості застосування досліджених методів. Як вже згадувалось у розділі , найбільш важливими параметрами проекту для управління є розмір проекту, трудомісткість, час, необхідний для виконання та вартість. Корисно відмітити, що серед цих параметрів три останніх залежать від першого параметра – розміру. Тому оцінювання цих параметрів можна розбити на два етапи: оцінювання розміру та оцінювання трудомісткості, вартості та тривалості з використанням вже отриманого значення розміру.

Для розрахунку цих трьох параметрів добре підходить модель COCOMO, оскільки вона розроблялась саме з метою оцінки бюджету, вартості та тривалості проектів та є зараз найбільш широко застосовуваною моделлю. Модель COCOMO використовує як вхідний параметр розмір програмної системи у рядках вихідного коду (KSLOC). Отримати точний розмір у таких одиницях можна лише після завершення проекту. На будь-якому попередньому етапі розмір має визначатись за допомогою експертних оцінок або за допомогою деякої методики оцінювання розміру проекту, яка може дати оцінку в одиницях KSLOC. В той же час найкращим вибором для оцінювання розміру проекту є метод FPA: він має об’єктивний характер, простий у застосуванні, є найбільш широко застосованим у індустрії розробки ПЗ, має статус міжнародного стандарту та є загально доступним. Проте цей метод дає розмір системи у одиницях UFP, в той час як для подальший розрахунків необхідні одиниці KSLOC. Враховуючи наявність внутрішніх стандартів на стиль коду та використовувані засоби розробки у організації, можна зробити припущення про існування відповідності між розмірами системи у UFP та KSLOC. Тоді можна буде поєднати ці методи у єдину схему, яка приведена на рис. 4.4. Існуючі методи експертних оцінок також включені в схему, оскільки застосування більш формалізованих методів у певних випадках може бути неможливим або невигідним.

Організаційна побудова підходу до оцінювання проектів. Схема запропонованої організаційної побудови процесу оцінювання представлена на рис. 4.5. За цією схемою, процес оцінювання ділиться на чотири етапи:

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

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

Рис. 4.4 – Покриття цілей оцінювання за допомогою методів FPA та COCOMO.

Оцінювання зусиль та вартості (За допомогою обраного методу оцінюються необхідні зусилля та вартість виконання проекту) Оцінювання термінів виконання проекту (За допомогою обраного методу оцінюються терміни виконання проекту), Підготовка звіту про оцінювання (Готується документ, який містить результати, отримані на попередніх етапах).

Оцінка ефективності застосування метода FPA. Для успішного впровадження методу FPA необхідно оцінити такі його характеристики:

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

2) узгодженість із статистикою по індустрії. Необхідно, щоб оцінки, отримані за цим методом, можна було використовувати за межами організації.

3) узгодженість оцінок між проектами. Відповідно до припущення про існування співвідношення розмірів проектів у одиницях SLOC та UFP, величина цього співвідношення для різних проектів має бути однаковою.

Рис. 4.5 – Повна схема процесу оцінювання проекту

Для цього було проведено оцінювання декількох проектів кількома різними експертами.

Підбір проектів та експертів проводився за такими критеріями:

1) проект було реалізовано на мові C++ або Java. Ці дві мови є найпоширенішими у організації та в індустрії в цілому, що дає можливість зіставити результати оцінювання;

2) експерт мав досвід у відповідній прикладній області або мав змогу звернутись до розробника проекту за поясненнями;

3) процес оцінювання має покрити весь діапазон розмірів проектів, наявний у організації.

4) сумарні зусилля на проведення оцінок не мали перевищувати 80 людино-годин

Результаті отриманих даних і приклади наведені у Додатку 5.

Методика калібрування моделі COCOMO. Модель COCOMO дає змогу отримати більш точні результати, якщо відкалібрувати її за даними по історичних проектах. COCOMO використовує таке рівняння для оцінки бюджету проекту:

, де

У цьому рівнянні присутні дві калібровочні константи, A та B₀. Маючи достатню кількість даних про вже виконані проекти, можна визначити значення цих констант для умов у даній організації.

Нехай у наявності є дані по n проектах. Нехай – порядковий номер проекту. Після логарифмування та очевидних перетворень рівняння (1) матиме такий вигляд:

Позначимо

Тоді

,

або у векторному вигляді

Якщо ввести позначення

то матимемо

,

звідки можна отримати K як

,

або

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

Калібрування моделі COCOMO. Розрахунки проводилися за вище наведеними формулами. Було отримано такі результати (табл. 1.9, стовпчик “Локальна калібровка”):

Таблиця 1.6 – Результати калібрування моделі COCOMO

Константа	Стандартна калібровка	Локальна калібровка
A	2.54	2.23
B0	0.91	0.49

Для порівняння у стовпчику “Стандартна калібровка” наведені значення констант для стандартної калібровки COCOMO.

Аналіз результатів калібрування. За результатами калібрування було розраховано зусилля на розробку проектів та порівняно з фактичними даними та результатами обчислень за стандартною калібровкою. Отримані значення та відхилення у відсотках від фактичного значення приведені у таблиці 1.10.

Таблиця 1.7 – Результати обчислень за каліброваною моделлю

№	PM фактичне	PM, стандартна калібровка	Відхилення, %, стандартна калібровка	PM, локальна калібровка	Відхилення, %, локальна калібровка
1	3.38	1.96	42%	1.37	60%
2	11.30	18.83	67%	6.40	43%
3	13.00	16.09	24%	5.75	56%
4	24.72	43.03	74%	10.84	56%
5	5.58	33.11	493%	10.66	91%
6	34.64	144.57	317%	29.14	16%
7	37.07	56.75	53%	15.40	58%
8	2.88	25.73	793%	8.97	211%
9	3.19	25.03	685%	8.81	176%
10	3.37	28.38	742%	9.60	185%
11	3.43	10.72	213%	4.94	44%
12	25.28	109.66	334%	24.13	5%

Ці ж результати у графічному вигляді подані на рис 1.6. Можна бачити, що калібрування моделі за базою історичних проектів дозволяє отримати оцінки, у більшості випадків більш близькі до фактичних, ніж з використанням стандартної калібровки. Але навіть для моделі з локальною калібровкою величини та розкид відхилень оцінок від фактичних значень (стовпчик “Відхилення, %, локальна калібровка”) роблять надто ризикованим використання таких оцінок.

Є наступні можливі причини таких відхилень:

1) вибірка проектів надто мала для калібрування моделі;

2) вихідні дані містять шуми або «викиди»;

3) у вибірці проектів присутні проекти, розроблені із використанням різних мов програмування. На процес розробки могли вплинути фактори, пов’язані із мовою програмування та супутніми технологіями, які не враховуються моделлю COCOMO.

Збільшення обсягу вибірки призвело б до включення проектів, які не відповідають моделі COCOMO, та, відповідно, до збільшення зашумленості вихідних даних.

Збільшення точності вихідних даних є неможливим, оскільки значення параметрів KSLOC, EAF, SF вимірюються точно, а уточнення значень PM пов’язане з великими часовими та фінансовими витратами. Результати співставлення цих моделей у Додатку 5.