Спіральна модель розробки

Спіральна модель процесу створення програмного забезпечення (рис. 3.7) була вперше запропонована в статті [47] і в даний час отримала широку популярність. На відміну від розглянутих раніше моделей, де процес створення ПЗ представлений у вигляді послідовності окремих процесів з можливою зворотним зв'язком між ними, тут процес розробки представлений у вигляді спіралі. Кожен виток спіралі відповідає однієї стадії (ітерації) процесу створення ПЗ. Так, самий внутрішній виток спіралі відповідає стадії прийняття рішення про створення ПЗ, на наступному витку визначаються системні вимоги, далі йде стадія (виток спіралі) проектування системи і т.д.

Кожен виток спіралі розбитий на 4 сектори.

1. Визначення цілей. Визначаються цілі кожної ітерації проекту. Крім того, встановлюються обмеження на процес створення ПЗ і на сам програмний продукт, уточнюються плани виробництва компонентів. Визначаються проектні ризики (наприклад, ризик перевищення термінів або ризик перевищення вартості проекту). Залежно від "проявлених" ризиків, можуть плануватися альтернативні стратегії розробки ПЗ.

2. Оцінка і дозвіл ризиків. Для кожного певного проектного ризику проводиться його детальний аналіз. Плануються заходи для зменшення (дозволу) ризиків. Наприклад, якщо існує ризик, що системні вимоги визначені невірно, планується розробити прототип системи.

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

4. Планування. Тут переглядається проект і приймається рішення про те, чи починати наступний виток спіралі. Якщо приймається рішення про продовження проекту, розробляється план на наступну стадію проекту.

Істотна відмінність спіральної моделі від інших моделей процесу створення ПЗ полягає в точному визначенні та оцінюванні ризиків. Якщо говорити неформально, то ризик - це ті неприємності, які можуть трапитися в процесі розробки системи. Наприклад, якщо при написанні програмного коду використовується нова мова програмування, то ризик може полягати в тому, що компілятор цієї мови може бути ненадійним або що результуючий код може бути не достатньо ефективним. Ризики можуть також полягати в перевищенні термінів або вартості проекту. Таким чином, зменшення (дозвіл) ризиків - важливий елемент управління системним проектом. У главі 4, присвяченій управлінню програмними проектами, можливі ризики та способи їх розв'язання розглядаються більш детально.

Мал. 7 Спіральна модель створення ПЗ (© +1988 IEЕЕ)

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

У спіральної моделі немає фіксованих етапів, таких як розробка специфікації або проектування. Ця модель може включати в себе будь-які інші моделі розробки систем. Наприклад, на одному витку спіралі може використовуватися протіпірованіе для більш чіткого визначення вимог (і, отже, для зменшення відповідних ризиків). Але на наступному витку може застосовуватися каскадна модель. Якщо вимоги чітко сформульовані, може застосовуватися метод формальних перетворень.