- Історія
- Створення
- Альтернатива моделі водоспаду
- Особливості спіральної моделі
- Контроль ризиків
- Опис спіралі
- Родовий
- Гнучка
- Метамодель
- Етапи
- Визначте цілі, альтернативи та обмеження
- Оцінка ризиків
- Розробка та тестування
- Планування наступного циклу
- Приклад
- Перевага
- Циклічна структура
- Управління ризиками
- Участь клієнтів та відгуки
- Ідеально підходить для великих проектів
- Недоліки
- Дорогий
- Досить складний
- Управління часом
- Багато кроків
- Список літератури
Спіральна модель є прототипом процесу розробки додатків. В її основі лежить гіпотеза, що розробка програмного забезпечення - це ітеративний цикл, який повторюється до досягнення встановлених цілей. Він має можливість впоратися з великою кількістю ризиків, які можуть виникнути при розробці будь-якого програмного забезпечення.
Це одна з найважливіших моделей підтримки управління ризиками. Як випливає з назви, ця модель показана у вигляді спіралі, де різні етапи моделі розподіляються за різними циклами. Кількість циклів у моделі не фіксовано і може змінюватись від проекту до проекту.
Аналіз, оцінка, планування та розробка. Спіральна розробка програмного забезпечення Джерело: Beao commons.wikimedia.org
Історія
Створення
Спіральну модель визначив американський математик та професор програмної інженерії Баррі Бум. Після презентації своєї концепції у 1986 р. Щодо розробки складних застосувань він опублікував свою модель у 1988 р. У більш всеосяжній рамці у своїй статті "Спіральна модель розробки та вдосконалення програмного забезпечення".
Частина цієї публікації 1988 року зображала спіральну модель графічно, всебічно показуючи, як спірально виглядає процес розробки програмного забезпечення та підтримується циклами.
Бум відомий своїм численним внеском у розробку програмного забезпечення, таких як конструктивна модель витрат (COCOMO), спіральна модель програмного процесу, підхід G-Theory (win-win) до визначення вимог та управління ними. програмного забезпечення.
Альтернатива моделі водоспаду
У своїй публікації Бум описав спіральну модель як можливу альтернативу раніше встановленій моделі водоспаду, яка також послужила основою для його практики.
Спіральна модель була не першою, що обговорювала циклічний розвиток, але це була перша модель, яка пояснила, чому важлива ітерація. Як спочатку планувалося, він був націлений на великі складні проекти, ітерації яких зазвичай складають від 6 місяців до 2 років.
Ця модель не передбачає, що завдання на розробку програмного забезпечення розробляються лінійно, на відміну від моделі водоспаду, а радше розглядає їх як ітераційні завдання.
Ця циклічна модель вплинула на модельну архітектуру програмного забезпечення (MBASE) та екстремальне програмування.
Особливості спіральної моделі
Контроль ризиків
Що значно відрізняє цю модель від інших моделей програмних процесів, це те, що вона чітко визнає ризики. Таким чином, це значно зменшує збій великих програмних програм шляхом багаторазової оцінки ризиків та перевірки продукту, що розробляється, кожного разу.
Ця комп’ютерна модель містить компоненти майже будь-якої іншої моделі життєвого циклу програмного забезпечення, такі як модель водоспаду, модель прототипування, ітеративна модель, еволюційна модель тощо.
Через це він здатний впоратися майже з будь-яким типом ризику, який інші моделі, як правило, не справляються. Однак, завдяки наявності такої кількості компонентів, ця модель набагато складніша, ніж інші моделі розробки програмного забезпечення.
Опис спіралі
Кожен виток спіралі являє собою завершений цикл, через який завжди проходять чотири квадранти, що представляють чотири ступені моделі.
Зі збільшенням розміру спіралі збільшується і досягнутий прогрес. Тому етапи виконуються не один раз, а кілька разів спірально.
Хоча це циклічне повторення змушує проект повільно наближатися до встановлених цілей, ризик відмови процесу розвитку сильно зводиться до мінімуму.
Родовий
Чотири етапи реалізують лише основні цілі циклу, але вони не повинні проявлятися в кожному циклі.
Порядок кожного циклу теж не визначений. Тому модель можна комбінувати в будь-який час з іншими моделями.
Гнучка
Він досить гнучкий, оскільки здійснює визначення цілей, аналіз ризиків, процеси розробки та планування окремо для кожної фази проекту.
Метамодель
Він вважається метамоделою, оскільки включає інші моделі. Наприклад, якби спіраль була єдиним циклом, вона представляла б модель водоспаду, оскільки вона включає поступовий підхід цієї класичної моделі.
Він також використовує підхід до моделювання прототипів, оскільки на початку кожного циклу він збирає прототип для управління ризиком.
Крім того, вона сумісна з еволюційною моделлю, оскільки ітерації спіралі можна вважати еволюційними рівнями, за допомогою яких будується кінцева система.
Етапи
Визначте цілі, альтернативи та обмеження
Системні вимоги визначаються якомога детальніше, включаючи продуктивність, апаратні / програмні інтерфейси, ключові показники успішності тощо. і які цілі повинні бути пов'язані з поточним циклом розвитку, розглянуто.
Крім того, розглядаються різні альтернативи його реалізації, такі як build vs. купувати, використовувати повторно існуючі компоненти або передавати аутсорсинг тощо.
Так само визначаються такі обмеження, як вартість, графік роботи та інтерфейси, витрата часу тощо.
Оцінка ризиків
Усі запропоновані альтернативи оцінюються. Цілі та обмеження служать визначальними посиланнями для вибору найкращого рішення.
Крім того, визначаються ризики, які можуть перешкоджати успіху проекту, такі як відсутність досвіду, нові технології, чіткий графік роботи, дефіцитні процеси тощо, реалізація найбільш вигідних стратегій з найменшим ризиком.
Нарешті, використовуються такі методи, як прототипування, моделювання, аналітичні моделі та опитування користувачів.
Розробка та тестування
Вся необхідна розробка здійснюється з використанням технології та обраного рішення. З кожною ітерацією створюється краща версія програми.
Фактичний код записується і перевіряється кілька разів, поки не буде досягнуто бажаного результату, який потім послужить основою для подальших кроків розвитку.
Планування наступного циклу
Після завершення одного циклу починається планування наступного. Це планування могло б продовжуватись із проектом зазвичай, якби мета циклу була досягнута, враховуючи визначення наступної мети.
Можна було б знайти й інші рішення, якби попередній етап розвитку виявився недостатнім. Існуюча стратегія може бути замінена однією з раніше визначених альтернатив або новою. З цим розпочнеться нова спроба досягти поставленої мети.
Приклад
Військові Сполучених Штатів прийняли спіральну модель для розробки та вдосконалення програми модернізації систем майбутньої боротьби (SCF).
Офіційно запущені в 2003 році, СКФ були розраховані на оснащення військ транспортними засобами, підключеними в режимі реального часу до надзвичайно швидкої та гнучкої мережі полів боїв.
Проект був розділений на чотири спіралі розвитку, приблизно по два роки кожна. Спіраль 1 повинна була розпочатися у 2008 році та поставити прототипи для використання та оцінки.
Після завершення спіралі 1 планується розпочати спіраль 2 у 2010 році. Розробка остаточного продукту планується поставити у 2015 році.
У серпні 2005 року Boeing оголосив про завершення першої важливої віхи проекту - функціонального ремонту систем. Міжнародною корпорацією Boeing та Science Applications виступили співавторами проекту.
Однак на жовтень 2005 року Пентагон рекомендував відкласти проект через високий вплив на витрати на війну в Іраку та допомогу урагану Катріна.
Проект було скасовано у 2009 році після скорочення бюджету, не маючи змоги довести переваги спіральної моделі в цій місії
Перевага
Циклічна структура
Завдяки такому типу структури проблеми між дизайном та технічними вимогами програмного забезпечення мовчазно усуваються завдяки періодичним перевіркам.
Управління ризиками
Ризики аналізуються на кожному етапі продукту, перш ніж продовжувати далі. Це допомагає подолати або пом’якшити потенційні ризики.
Усі працівники виграють від великого значення аналізу ризиків у цій моделі, можливо, представляючи свою найбільшу перевагу перед іншими моделями технологічних процесів.
Регулярна оцінка ризику цінна при використанні нових технічних середовищ, які, як правило, пов'язані з певним потенціалом ризику через відсутність емпіричних значень.
Участь клієнтів та відгуки
Клієнти беруть участь у кожному етапі проекту, поки проект не буде завершений. Тому можна зібрати різні відгуки для покращення наступної версії проекту.
Також зворотній зв'язок можна отримати в будь-який час завдяки просуванню спіралеподібної форми. Таким чином, клієнти та користувачі можуть бути інтегровані з самого початку в процесі розробки.
Ідеально підходить для великих проектів
Він особливо популярний і відомий для великих та складних проектів, де бюджетний контроль є пріоритетним завданням для клієнтів та розробників. Ви маєте максимальний контроль над витратами, ресурсами та якістю програмного проекту.
Недоліки
Дорогий
Це може бути досить дорого, оскільки вимагає високого рівня знань для аналізу ризиків. Крім того, на розробку проектів потрібно багато часу, що може збільшити накладні витрати.
Досить складний
Потрібне дуже активне та складне попереднє управління проектом, де кожен цикл постійно та ретельно контролюється та документується.
Він порівняно складніший, ніж інші моделі, оскільки існує багато циклів, кожен проходить різні етапи, тим самим збільшуючи зусилля процесу документації.
Знання аналізу та управління ризиками, які часто недоступні, є важливим.
Управління часом
Часом важко керувати, оскільки кількість циклів невідома. Крім того, процес розробки може затягнутися в будь-який час, якщо важливі рішення повинні бути прийняті протягом одного циклу або шляхом додаткових дій при плануванні наступного циклу.
Багато кроків
Робити багато кроків у розробці програмного забезпечення не завжди сприятливо, тому що, незважаючи на універсальність тестування, незакінчені частини програми можуть дістатися до готової системи.
Як наслідок, завжди існує небезпека, що будь-яка концептуальна помилка чи непослідовність вплине на кінцевий продукт.
Список літератури
- Віктор Шрифт-молодший (2019). Спіральна модель. Кінцеве керівництво по SDLC. Взято з: ultimatesdlc.com.
- Іонос (2019). Спіральна модель: модель процесу розробки програмного забезпечення, керована ризиком. Взято з: ionos.com.
- Техуз (2018). Що таке спіральна модель? Просте пояснення життєвого циклу розробки програмного забезпечення спіралі (SDLC). Взято з: techuz.com.
- Тестування на одній зупинці (2020). Спіральна модель. Взято з: onestoptesting.com.
- Geeks for Geeks (2020). Інженерія програмного забезпечення - спіральна модель. Взято з: geeksforgeeks.org.
- Чанду (2019). Спіральна модель в інженерії програмного забезпечення. Взято з: medium.com.