1.1.2 Спіральна модель
Застосування більш сучасних методів привело до появи ітераційного підходу до керування процесом розробки – так званої спіральної моделі, проілюстрованої на рис. 1.2. Ця модель підрозділяється на наступні чотири стадії:
дослідження – аналіз вимог і попереднє планування;
пророблення – проектування додатків;
перехідний період – оцінка й стабілізація додатка;
створення – реалізація додатка.
Кожна із цих стадій звичайно підрозділяється на п'ять фаз:
збір вимог;
проектування;
реалізація;
розгортання;
керування.
У рамках спіральної моделі процес розробки складається зі згаданих вище чотирьох стадій, на кожній з яких ці п'ять фаз виконуються багаторазово. Наприклад, на стадії дослідження може знадобитися чотири ітерації, тобто чотириразове виконання циклу. Ціль ітераційного підходу – домогтися послідовного уточнення характеристик і архітектури продукту, що забезпечує його постійне наближення до остаточного виду.
Планування та
аналіз
Проектування
Реалізація
Оцінка та
стабілізація
Рис. 1.2. Спіральна модель
Як і модель водоспаду, спіральна модель породжує наступні проблеми:
Затримка реалізації функціональних можливостей – реалізація складних компонентів, що представляють особливу важливість для замовників і користувачів, відкладається на завершальні ітерації. Це затягує виконання проекту й підвищує вартість робіт.
Ніколи що не закінчуються проекти – проекти, реалізовані по спіральній моделі, часто починають жити власним життям, коли робота над проектом фактично перетворюється в роботу для проекту; такі проекти або ніколи не кінчаються, або кінчаються нічим. При зміні цілей проекту ітераційний підхід змушує групу продовжувати роботу над реалізацією колишніх цілей, ігноруючи нові завдання. Це веде до втрати орієнтації й різкому зниженню корисності проекту.
Невідома вартість – постійне повторення стадій і затягування реалізації складних вимог утрудняє оцінку вартості й прибутковості проекту. Це, у свою чергу, ускладнює оцінку витрат і ефективності при обґрунтуванні наступних проектів.
Відсутність стабільності – постійна зміна системи формує в замовників і користувачів думка про нестабільність продукту. Постійне відновлення всіх складових проекту на кожній ітерації різко збільшує витрати й підвищує вартість розгортання продукту.
Відсутність автоматизації – необхідність інвестицій в автоматизацію процесу розробки програмного забезпечення часто упускається з виду. Значні первісні витрати на засоби автоматизації й підвищення продуктивності при цьому розглядаються як витрати, а не як капіталовкладення. Однак під час відсутності засобів автоматизації ітераційний підхід до розробки приводить до значних затримок випуску продукту. Навіть по закінченні розробки відсутність засобів автоматизації розгортання значно утрудняє установку нових версій продукту на комп'ютери користувачів.
1.1.3 Універсальний процес
Універсальний процес (Unified Process, UP) – широко розповсюджений метод аналізу, проектування й розробки додатків масштабу підприємства. Основні характеристики цього процесу, що базується універсальною мовою моделювання, такі:
сценарії використання як основа проекту;
пріоритет архітектури;
ітераційний і інкрементний процес розробки;
прогнозування ризиків;
об’єктно- і сервісно-орієнтоване проектування;
активне нагромадження й повторне використання об’єктно-орієнтованих шаблонів і об'єктів.