3. Модель прототипування програмного продукту

Даний підхід заснований на швидкому створенні прототипу програми. За допомогою макетів можна зняти невизначеність у вимозі замовника.

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

Недоліки моделі:

• замовник може прийняти макет за готову програму;

• розроблювач може упустити при конструюванні якісь елементи прототипу;

• замовник повинен володіти навичками роботи на комп'ютері.

 

4. Спіральна модель

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

Виходячи з можливості внесення змін, як в процес, так і в проміжний продукт було створено спіральну модель ЖЦ (рис.3).

Внесення змін орієнтоване на задоволення потреби користувачів одразу, як тільки буде встановлено, що створені артефакти або елементи документації не відповідають дійсному стану розробки.

Дана модель ЖЦ допускає аналіз продукту на витку розробки, його перевірку, оцінку правильності та прийняття рішення про перехід на наступний виток або повернення на попередній виток для доопрацювання на ньому проміжного продукту.

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

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

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

Спіральна модель (автор Барри Боэм, 1988) базується на кращих властивостях життєвого циклу й макетування з одночасним аналізом ризиків.

На кожному витку система розробляється по моделі життєвого циклу. Спочатку створюється перша версія з мінімальним набором функцій. На кожному наступному витку функціональність підвищується. Кожний виток закінчується виходом нової версії програми.

Ця модель має таку стадію як аналіз ризиків – вплив зовнішніх факторів (зміна конфігурації апаратної частини комп'ютерів, перехід на нову версію ОС, зміна в особливостях діяльності фірми-замовника й т.п.)

Недоліки моделі:

• новизна. Дана модель є однією із самих нових і відсутня достатня статистика  її ефективності;

• підвищені вимоги до замовника;

• труднощі контролю й керування часом розробки.