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

Таким чином, у відповідному квадраті відбуваються такі дії: планування, прототипування, конструювання, оцінювання замов­ником і планування наступних дій.

Вертикальна вісь показує накопичувану вартість, а горизон­тальна - прогрес у розробці продукту.

Інкрементна модель забезпечує процеси побудови версії програм­ного забезпечення, що розробляється (рис 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 як стандарт оцінювання розміру ПЗ.