М. Сидоров: Вступ до інженерії програмного забезпечення

Рис. 6.13. Стадійна модель

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

- засновані на застосуванні компонентів багатократного використання;

- засновані на повторному використанні успадкованого програм­ного забезпечення.

Моделі компонентної розробки орієнтуються на багатократне використання готових компонентів, наприклад, методом об 'ектно-оріентованого програмування. Для розроблення компонентів пе­редбачається три можливості (рис. 6.14):

- розробка «з нуля»;

- використання існуючих класів;

- повторне використання успадкованого програмного забезпе­чення.

Рис. 6.14. Компонентна модель розробки

Існує три типи моделей, заснованих на повторному використан­ні; швидка, ітеративна і повна.

Швидка модель передбачає розробку шляхом зміни коду успад­кованого програмного продукту з подальшою зміною інших робо­чих продуктів фаз життєвого циклу (рис. 6.15).

Рис. 6.15. Швидка модель

Ітеративна модель припускає аналіз успадкованого програм­ного забезпечення і побудову нового продукту шляхом послідо­вних змін робочих продуктів успадкованого програмного проду­кту (рис. 6.16).

Рис. 6.16. Ітеративна модель

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

Ряс. 6.17. Повна модель

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

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

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

- вимога;

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

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

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

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

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

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

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

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

,