Повна модель передбачає побудову на основі успадкованого програмного продукту репозитарія повторно використовуваних компонентів і потім створення з його допомогою нового програмного продукту (рис. 6.17).
Ряс. 6.17. Повна модель
Моделі, орієнтовані на автоматичне виконання фаз життєвого циклу. Моделі автоматичного синтезу забезпечують автоматичну побудову програмного продукту шляхом переходу від неформальної специфікації до формалізованої специфікації завдяки автоматичному виконанню однієї або декількох фаз життєвого циклу (рис. 6.18).
Рис. 6.18. Модель автоматичного синтезу
Зазвичай для кожного проекту програмного забезпечення вибирають моделі життєвого циклу. Під час вибору використовуються характеристики таких елементів розробки:
- вимога;
- команда розробників;
- колектив користувачів;
- тип проекту і ризики.
Після вибору моделі здійснюється її підлаштування під процеси конкретного проекту.
Розділ 7. МОДЕЛІ, МЕТОДИ І ЗАСОБИ ОЦІНЮВАННЯ ВАРТОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Розвиток моделей, методів і засобів оцінювання вартості програмного забезпечення (ПЗ) сягнув рівня практичного застосування. Проте через відсутність інформації, засобів і фахівців зазначене не використовують під час розробки ПЗ в Україні.
У розділі наводяться результати аналітичного огляду літератури з урахуванням досвіду авторів ПЗ за вказаною темою. Розділ складається з трьох частин. У першій розглядаються одиниці розміру ПЗ, які використовуються в моделях, методах і засобах оцінювання вартості ПЗ, у другій - моделі і методи оцінки, у третій - засоби оцінки.
7.1. Одиниці розміру програмного забезпечення
Під час оцінювання вартості ПЗ використовують дві одиниці розміру: рядок коду (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 грунтується на концепції розмежування взаємодії. Суть її полягає в тому, що програма розділяється на класи компонентів ПЗ формату і типу логічних операцій. В основі цього поділу лежить припущення, що область взаємодії програми розділяється на внутрішню - взаємодія компонентів додатка, і зовнішню - взаємодія з іншими застосуваннями.
Відповідно до прийнятого стандарту використовуються п'ять класів компонентів, на яких грунтується аналіз: