Таким чином, у відповідному квадраті відбуваються такі дії: планування, прототипування, конструювання, оцінювання замовником і планування наступних дій.
Вертикальна вісь показує накопичувану вартість, а горизонтальна - прогрес у розробці продукту.
Інкрементна модель забезпечує процеси побудови версії програмного забезпечення, що розробляється (рис 6.6). Модель об'єднує каскадну модель з ітераційним підходом до розробки програмного забезпечення, Інкрементна модель може комбінуватися з іншими.
Рис. 6.6. Інкрементна модель
Покрокова модель припускає визначення пріоритетних функцій розробки програмного забезпечення у відповідній фазі життєвого циклу. Відповідно до певних пріоритетів визначається кількість кроків і кожна фаза реалізується покроково (рис. 6-7). Після виконання кроку виходить програмний продукт, який передається замовникові для експерименту і перевірки.
Модель швидкої розробки (рис. 6.8) введена у використання фірмою IBM. Суть моделі полягає в такому:
- користувач програмного забезпечення бере участь у всіх фазах життєвого циклу;
- скорочується час переходу від вимог до створення повного програмного забезпечення за рахунок використання відповідних інструментальних засобів і повторного використання.
Рис. 6.7. Покрокова модель
Рис. 6.8. Модель швидкої розробки
Модель прототипування забезпечує створення програмного забезпечення у двох примірниках. Перший примірник називається прототипом і використовується для вимог. Після того, як вимоги узгоджені, прототип викидається і програмне забезпечення створюється наново (рис. 6.9). Гасло моделі "давайте будувати двічі»,
Еволюційна модель - розробляється перша версія програмного продукту, яка передасться замовникові. Потім вона доопрацьовується і знову передасться замовникові, І так до тих пір, доки не буде побудована остаточна версія продукту. Еволюційна модель забезпечує еволюційний процес розробки програмного забезпечення (рис 6.10),
Рис. 6.9. Модель прототипування.
Рис. 6.10. Еволюційна моделі.
V-модель життєвого циклу була введена для ідентифікації дій, пов'язаних з тестуванням на всіх стадіях розробки програмного продукту. Лівий бік моделі (рис. 6.11) містить традиційні фази каскадної моделі, проте окрім робочого продукту виробляється відповідний тест. Правий бік моделі пов'язаний з інтеграцією і тестуванням.
Рис. 6.11. V-модель
W-модель життєвого циклу є модифікацією V-моделі і реалізує метод, відповідно до якого результат кожної фази перевіряється на коректність, змістовність і завершеність (рис. 6.12). Суть моделі полягає у проведенні аудиту, перегляданні і тестуванні робочих продуктів, які здійснюються паралельно з виконанням фаз.
Рис. 6.12. W -модель
Стадійна модель життєвого циклу. Ця модель є модифікацією еволюційної моделі (рис, 6.13). Суть її полягає в розгляді супроводу розробленого програмного продукту як процесу розробки.
Рис. 6.13. Стадійна модель
Моделі, орієнтовані на використаних готових компонентів. Розрізняють дві групи моделей:
- засновані на застосуванні компонентів багатократного використання;
- засновані на повторному використанні успадкованого програмного забезпечення.
Моделі компонентної розробки орієнтуються на багатократне використання готових компонентів, наприклад, методом об'ектно-оріентованого програмування. Для розроблення компонентів передбачається три можливості (рис. 6.14):
- розробка «з нуля»;
- використання існуючих класів;
- повторне використання успадкованого програмного забезпечення.
Рис. 6.14. Компонентна модель розробки
Існує три типи моделей, заснованих на повторному використанні; швидка, ітеративна і повна.
Швидка модель передбачає розробку шляхом зміни коду успадкованого програмного продукту з подальшою зміною інших робочих продуктів фаз життєвого циклу (рис. 6.15).
Рис. 6.15. Швидка модель
Ітеративна модель припускає аналіз успадкованого програмного забезпечення і побудову нового продукту шляхом послідовних змін робочих продуктів успадкованого програмного продукту (рис. 6.16).
Рис. 6.16. Ітеративна модель
Повна модель передбачає побудову на основі успадкованого програмного продукту репозитарія повторно використовуваних компонентів і потім створення з його допомогою нового програмного продукту (рис. 6.17).
Ряс. 6.17. Повна модель
Моделі, орієнтовані на автоматичне виконання фаз життєвого циклу. Моделі автоматичного синтезу забезпечують автоматичну побудову програмного продукту шляхом переходу від неформальної специфікації до формалізованої специфікації завдяки автоматичному виконанню однієї або декількох фаз життєвого циклу (рис. 6.18).
Рис. 6.18. Модель автоматичного синтезу
6.2.2. Вибір моделей життєвого циклуЗазвичай для кожного проекту програмного забезпечення вибирають моделі життєвого циклу. Під час вибору використовуються характеристики таких елементів розробки:
- вимога;
- команда розробників;
- колектив користувачів;
- тип проекту і ризики.
Після вибору моделі здійснюється її підлаштування під процеси конкретного проекту.
Розділ 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 як стандарт оцінювання розміру ПЗ.
