лів, званих ітераціями, тривалістю не більше двох тижнів. Кожна ітерація забезпечує проходження всіх фаз проекту забезпечуючи інкремент (приріст) функціональності. Однак ітерація, як правило, недостатня для випуску нової версії продукту. По закінченні ітерації команда розробників оцінює і вибирає пріоритети розробки. Основний метрикою даної методології стає робочий продукт, а не система письмової документації. Далі була створена модель RAD - Rapid Application Development (швидка розробка додатків), яка стала основою технологій створення і розгортання програмних продуктів. Ця модель передбачає:
· інструментальну підтримку процесу розробки, мінімізацію часу і трудовитрат;
· використання прототипу для уточнення вимог замовника;
· циклічність розробки - кожна нова версія продукту грунтується на оцінці результату роботи попередньої версії замовником;
· поступове розширення функціональності;
· розподіл ролей у команді розробника, можливість їх суміщення;
· управління проектом створення програмного продукту.
Модель RAD може приймати одну з трьох форм: макет (у вигляді креслення форми документа, схеми діалогу), що працює макет для обмеженого набору функцій або типовий програмний продукт, який підлягає налаштуванні. Макетування грунтується на багаторазовому повторенні ітерацій, в яких беруть участь замовник і розробник, і починається зі збору та уточнення вимог до створюваного програмного продукту.
Інкрементна модель об'єднує елементи послідовної Водоспадної моделі з ітераційної основою макетування.
Малюнок 2. Схема виконання проектних робіт по моделі RAD
Вона реалізована як серія поставок (інкрементів, релізів), що представляють собою послідовність фаз аналізу, проектування, кодування і тестування. Розробка першого инкремента дозволяє отримати базовий продукт, який реалізує базові вимоги, при цьому багато допоміжні вимоги залишаються нереалізованими. План наступних інкрементів передбачає послідовну модифікацію базового продукту, що забезпечує додаткові характеристики і функціональність. За своєю природою інкрементний процес ітератівен, але, на відміну від макетування, інкрементна модель забезпечує в кінці инкрементной ітерації працюючий продукт. Сучасна реалізація інкрементного підходу - екстремальне програмування (ХР), яке орієнтоване на дуже малі збільшення функціональності.
Еволюційна стратегія отримала своє втілення в ряді моделей: спіральної, компонентно-орієнтованої. Автором спіральної моделі є американський вчений Б. Боем (1988).
Спіральна модель об'єднала властивості класичного життєвого циклу та макетування, але доповнила їх аналізом ризику. Ця модель включає в себе чотири обов'язкові фази:
) планування - визначення цілей, варіантів, обмежень;
) аналіз ризику - аналіз варіантів і розпізнавання (вибір) ризику;
) конструювання - розробка продукту наступного рівня;
) оцінювання - оцінка замовником поточних результатів розробки.
Черговий цикл по спіралі виконується в напрямку від центру до периферії, поступово створюються повні версії програмного продукту. Рішення приймаються на актуальної інформації про стан розробки. До достоїнств спіральної моделі відносять: еволюційний розвиток розробки програмного продукту, облік ризиків на кожному витку спіралі, використання методів моделювання для аналізу ризиків.
Спіральна модель орієнтована на великі, дорогі і складні проекти. При цьому потрібно:
. Постійна взаємодія з потенційними користувачами, з'ясування змінюються вимог до програмної системи.
2. Розробка архітектури системи, що визначає концепцію побудови програмного продукту, відкритою для змін.
3. Наявність розробників високої кваліфікації, інструментарію розробки, відповідного масштабом і складності програмного продукту.
Малюнок 3. Схема виконання проектних робіт по спіральній моделі: 1 - планування проекту та життєвого циклу; 2 - концепція експлуатації; 3 - специфікація вимог; 4 - перевірка вимог; 5 - детальний дизайн; 6 - кодування; 7 - модульне тестування; 8 - інтеграція і тестування; 9 - приймальне тестування; 10 - розгортання.
Компонентно-орієнтована модель - подальший розвиток спіральної моделі, засноване на еволюційної стратегії розробки програмних продуктів. Нова розробка повинна грунтуватися на повторному використанні існуючих програмних компонентів. Це призводить до зменшення часу розробки і зниження вартості програмного продукту, а також зростанню п...
