Sign in Subscribe

Спіральна модель Боема (Boehm’s Spiral Model)

Zosym Maxym

• 5 min read

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

Я вже розглядав роботи Боема в перекладі статті Вартість змін у командах розробників ПЗ (Cost of Change on Software Teams)

Вперше цю модель описав Баррі Боем у своїй статті 1986 року "Спіральна модель розробки та вдосконалення програмного забезпечення". 1988 року Боем опублікував аналогічну статтю для ширшої аудиторії. У цих статтях представлено діаграму, яка була відтворена в багатьох наступних публікаціях, що обговорюють спіральну модель.

У цих ранніх роботах використовується термін "модель процесу" для позначення спіральної моделі, а також інкрементального, водоспадного, прототипування та інших підходів. Однак, спіральна модель вже містить у собі характерне для інших моделей процесів поєднання ризик-орієнтованого підходу з рисками:

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

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

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

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

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

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

Шість інваріантів спіральної моделі

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

Одночасне визначення артефактів (Define artifacts concurrently)

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

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

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

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

Виконуйте чотири базові дії в кожному циклі (Perform four basic activities in every cycle)

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

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

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

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

Ризик визначає рівень зусиль (Risk determines level of effort)

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

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

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

Ризик визначає ступінь деталізації (Risk determines degree of details)

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

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

Використовуйте опорні точки-віхи (Use anchor point milestones)

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

  1. Цілі життєвого циклу (Life Cycle Objectives - LCO). Чи є достатнім визначення технічного та управлінського підходу, який би задовольняв умови виграшу для всіх? Якщо зацікавлені сторони погоджуються, що відповідь "так", то проект пройшов LCO етап життєвого циклу. В іншому випадку, проект може бути закритий, або зацікавлені сторони можуть взяти на себе зобов'язання щодо наступного циклу, щоб спробувати досягти "Так".
  2. Архітектура життєвого циклу (Life Cycle Architecture - LCA). Чи є достатнім визначення переважного підходу до задоволення умов виграшу для всіх, і чи всі значні ризики усунені або пом'якшені? Якщо зацікавлені сторони погоджуються, що відповідь "Так", то проект пройшов цей етап LCA. В іншому випадку, проект може бути закритий, або зацікавлені сторони можуть взяти на себе зобов'язання щодо наступного циклу, щоб спробувати досягти "Так".
  3. Початкова операційна спроможність (Initial Operational Capability - IOC). Чи достатньо підготовлені програмне забезпечення, сайт, користувачі, оператори та технічні працівники для того, щоб запуск системи задовольнив умови виграшу всіх сторін? Якщо зацікавлені сторони погоджуються, що відповідь "так", то проект пройшов етап IOC і може бути запущений. В іншому випадку, проект може бути припинений, або зацікавлені сторони можуть взяти на себе зобов'язання щодо наступного циклу, щоб спробувати досягти "Так".

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

Три опорні віхи легко вписуються в Rational Unified Process (RUP), де LCO позначає межу між фазами Початок і Розробка (Inception and Elaboration phases), LCA позначає межу між фазами Розробка і Будівництво (Elaboration and Construction phases), а IOC позначає межу між фазами Будівництво і Перехід (Construction and Transition phases).

Зосередьтеся на системі та її життєвому циклі (Focus on the system and its life cycle)

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