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

Технологія розробки програмного забезпечення

Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Вимоги Специфікація Архітектура Дизайн Реалізація Тестування Розгортання Реліз Супровід
Методології Процес
Гнучка Чистого приміщення DSDM Ітеративна RAD RUP Спіраль Водоспад XP Scrum Lean V-Model FDD TDD BDD
Допоміжні дисципліни
Керування конфігурацією Документування Якість ПЗ Управління проєктами Досвід користування
Практики
Неперервна інтеграція Керована поведінкою розробка
Інструменти
Компілятор Зневаджувач Профілювальник GUI designer IDE Автоматизація складання Інфраструктура як код Тестування
Стандарти та галузі знань
CMMI ISO 9001 ITIL PMBOK SWEBOK
п о р

Спіральна модель — генератор моделі процесу керування ризиками для проєктів програмного забезпечення. Заснована на унікальних моделях ризиків даного проєкту, спіральна модель скеровує команду на прийняття елементів однієї чи кількох моделей процесів, як-от інкрементного, водоспадного чи еволюційного прототипування^[en].

Дану модель було вперше описано Баррі Бомом^[en] у його статті 1986 року «Спіральна модель розробки та поліпшення програмного забезпечення»^[2]. 1988 року Бом опублікував схожу статтю^[3] для більшої аудиторії. Ці статті вводять діаграму, яку було відтворено у численних майбутніх публікаціях про спіральну модель.

Ці ранні статті використовували термін «модель процесів» для позначення спіральної моделі поряд з інкрементним, водоспадним, прототипним та іншими підходами. Проте, спіральним моделям притаманна суміш керування ризиками вже наявних особливостей інших моделей процесів:

	Керована ризиками підмножина кроків спіральної моделі дозволяє їй містити будь-яку відповідну суміш орієнтованих на специфікацію, прототип, симуляцію, автоматичну трансформацію чи будь-що інше підходів до розробки програмного забезпечення. Оригінальний текст (англ.) Risk-driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.
— Баррі Бом[en], [3]

У пізніших публікаціях Бом описує спіральну модель як «генератор моделі процесів», де вибори, засновані на ризиках проєкту, породжують відповідну модель процесів для проєкту. Таким чином, інкрементна, водоспадна, прототипна та інші моделі процесів є особливими випадками спіральної моделі, що охоплює моделі ризиків даних проєктів.

Бом також визначив кількість хибних уявлень, що випливає з надмірних спрощень на початковій діаграмі спіральної моделі. Найнебезпечнішими хибними уявленнями він назвав такі:

• те, що спіраль є простою послідовністю водоспадних інкрементів;
• те, що всі діяльності проєкту слідують єдиній спіральній послідовності;
• те, що кожна діяльність на діаграмі повинна бути виконана, і в зазначеній послідовності.

Хоч ці хибні уявлення можуть відповідати моделям ризиків окремих проєктів, вони не будуть відповідними для більшості проєктів.

У доповіді^[4] Національної ради з науково-дослідної роботи дану модель було розширено шляхом включення ризиків, пов'язаних із людським фактором.

Для кращого розрізнення їх від «небезпечних спіральних двійників» Бом навів шість характеристик, спільних для всіх автентичних застосувань спіральної моделі^{[джерело?]}.

Аутентичні застосування спіральної моделі керуються циклами, що завжди відображають шість характеристик. Бом проілюстрував кожну з них прикладом «небезпечного спірального двійника», що порушує інваріантність.

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

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

1. Вимоги є відомими завчасно до реалізації.
2. Вимоги не мають жодних невирішених, ризикованих наслідків, як-от ризики вартості, графіку, продуктивності, гарантії, безпеки, користувацьких інтерфейсів, організаційних впливів та ін.
3. Природа вимог не змінюватиметься надто сильно протягом розробки чи еволюції.
4. Вимоги є сумісними з усіма ключовими очікуваннями зацікавлених сторін від системи, включно з користувачами, клієнтом, розробниками, підтримкою та інвесторами.
5. Правильна архітектура для реалізації вимог добре розуміється.
6. Достатньо календарного часу для послідовного виконання.

У ситуаціях, коли ці припущення є застосовними, наявний ризик проєкту не визначити вимоги та не виконувати послідовно. Таким чином, водоспадна модель стає випадком спіральної моделі з управлінням ризиками.

Даний інваріант визначає чотири основні дії, що повинні відбуватися на кожному циклі спіральної моделі:

1. Розглянути умови виграшу всіх критичних до успіху зацікавлених сторін.
2. Визначити й оцінити альтернативні підходи до задоволення умов виграшу.
3. Визначити та вирішити ризики, що стають на заваді обраних підходів.
4. Отримати схвалення всіх критичних до успіху зацікавлених сторін, а також зобов'язання щодо переходу на наступний цикл.

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

Деякі процеси «небезпечних спіральних двійників» порушують даний інваріант, усуваючи ключових зацікавлених сторін від деяких послідовних фаз або циклів. Наприклад, підтримка й адміністратори системи можуть бути не залучені до визначення та розробки системи. Як наслідок, система може не задовольняти виграшних умов.

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

Наприклад, виділення додаткового часу на тестування програмного продукту часто знижує ризик відкликання з ринку поганого продукту. Проте, додатковий час тестування може збільшити ризик того, що конкурент раніше вийде на ринок. З точки зору спіральної моделі тестування повинно відбуватися до мінімізації сумарного ризику, і не далі^{[джерело?]}.

«Небезпечні спіральні двійники», що порушують даний інваріант, містять еволюційні процеси, які ігнорують ризик заради масштабованості, та інкрементні процеси, які забагато вкладають у технічну архітектуру того, що повинно бути перепроєктовано чи замінено для забезпечення майбутніх інкрементів продукту.

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

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

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

1. Завдання життєвого циклу. Чи існує достатнє визначення технічного й управлінського підходу для задоволення умов виграшу кожного? Якщо зацікавлені особи погоджуються з відповіддю «Так», то проєкт пройшов віху LCO. Інакше проєкт може бути покинуто чи зацікавлені особи можуть спробувати на іншому циклі отримати «Так».
2. Архітектура життєвого циклу. Чи існує достатнє визначення найкращого підходу для задоволення умов виграшу кожного, і чи всі значні ризики усунуто чи зменшено? Якщо зацікавлені особи погоджуються з відповіддю «Так», то проєкт пройшов віху LCA. Інакше проєкт може бути покинуто чи зацікавлені особи можуть спробувати на іншому циклі отримати «Так».
3. Початкові операційні можливості. Чи існує достатня підготовка програмного забезпечення, сайту, користувачів, операторів і підтримки для задоволення умов виграшу кожного при запуску системи? Якщо зацікавлені особи погоджуються з відповіддю «Так», то проєкт пройшов віху IOC та запущений. Інакше проєкт може бути покинуто чи зацікавлені особи можуть спробувати на іншому циклі отримати «Так».

«Небезпечні спіральні двійники», що порушують даний інваріант, містять еволюційні й інкрементні процеси, що виділяють значні ресурси не реалізацію рішення з погано визначеною архітектурою^{[прояснити]}.

Три опорні точки легко вписуються в Rational Unified Process (RUP) з LCO-маркуванням границі між фазами RUP Початок і Розробка, LCA-маркуванням — між Розробкою та Конструюванням, та IOC-маркуванням — між Конструюванням та Переходом.

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