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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
ТРПЗ
Цикл розробки програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги • Специфікація • Архітектура • Дизайн • Реалізація • Тестування • Розгортання (Реліз) • Супровід
Методології • Процес
Гнучка • Чистого приміщення • DSDM • Ітеративна • RAD • RUP • Спіраль • Водоспад • XP • Scrum • Lean • V-Model • FDD • TDD • BDD
Допоміжні дисципліни
Керування конфігурацією • Документування • Якість ПЗ • Управління проектами • Досвід користування
Інструменти
Компілятор • Зневаджувач • Профілювальник • GUI designer • IDE
Спіральна модель (Бом, 2000). Кількість хибних уявлень походить із надмірних спрощень на цій широко поширеній діаграмі (на цій діаграмі наявні деякі помилки)[1]

Спіральна модель — генератор моделі процесу керування ризиками для проектів програмного забезпечення. Заснована на унікальних моделях ризиків даного проекту, спіральна модель скеровує команду на прийняття елементів однієї чи кількох моделей процесів, як-от інкрементного, водоспадного чи еволюційного прототипування[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-маркуванням — між Конструюванням та Переходом.

Зосередження на системі та її життєвому циклі[ред.ред. код]

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

Примітки[ред.ред. код]

  1. Бом, Баррі (9 лютого 2000). У Гансен, Вілфред Дж. Spiral Development: Experience, Principles and Refinements [Спіральна розробка: досвід, принципи та уточнення] (PDF) (спеціальна доповідь). Spiral Development Workshop (англійською). Піттсбург: Інститут програмної інженерії. с. 36. 
  2. Бом, Баррі (серпень 1986). A spiral model of software development and enhancement [Спіральна модель розробки та поліпшення програмного забезпечення]. ACM SIGSOFT (PDF) (англійською) 11 (4) (Нью-Йорк: Association for Computing Machinery). с. 14–24. doi:10.1145/12944.12948. 
  3. а б Бом, Баррі (травень 1988). A Spiral Model of Software Development and Enhancement [Спіральна модель розробки та поліпшення програмного забезпечення] (PDF) (стаття) (англійською) 21 (5). Інститут інженерів з електротехніки та електроніки. с. 61–72. 
  4. П'ю, Річард В.; Мавор, Анна С. Human-System Integration in the System Development Process: A New Look [Людино-системна інтеграція у процес розробки систем: Новий погляд] (PDF) (доповідь) (англійською). Вашингтон: National Academies Press[en]. с. 396. ISBN 978-0-309-10720-4. doi:10.17226/11893.