Simplen Trec

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

Спіральна модель – дизайн

Спіральна модель має чотири фази. Проєкт програмного забезпечення неодноразово проходить через ці фази в ітераціях, які називаються “Спіралі”.

Ідентифікація

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

Проєктування

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

Розробка

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

Оцінка та аналіз ризиків

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

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

Застосування спіральної моделі

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

• Коли є бюджетні обмеження.
• Для проєктів середнього та високого ризику.
• Довгострокове зобов’язання щодо проєкту через можливі зміни економічних пріоритетів, оскільки вимоги змінюються з часом.
• Клієнт не впевнений у своїх вимогах.
• Вимоги складні й потребують оцінки, щоб отримати ясність.
• Нова лінійка продуктів, яку слід випускати поетапно, щоб отримати достатньо відгуків клієнтів.
• Очікуються значні зміни в продукті протягом циклу розробки.

Спіральна модель – переваги

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

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

Переваги спіральної моделі SDLC такі:

• Адаптованість до вимог, які змінюються.
• Дозволяє широко використовувати прототипи.
• Вимоги можна сформулювати більш точно.
• Клієнти бачать систему раніше.
• Розробку можна розділити на менші частини, а ризиковані частини можна розробити раніше, що допомагає краще керувати ризиками.

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

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

Недоліки спіральної моделі SDLC:

• Управління більш складне.
• Кінець проєкту може бути не відомий раніше.
• Не підходить для невеликих проєктів або проектів із низьким ризиком і може бути дорогим для невеликих проектів.
• Процес складний
• Спіраль може тривати нескінченно.
• Велика кількість проміжних етапів вимагає надмірної документації.

У ітераційній моделі процес починається з простого впровадження невеликого набору вимог до програмного забезпечення. Цей процес відбувається ітеративно, тобто поетапно. І повторюється доки система не буде реалізована та готова до розгортання.

Ітерація — певний проміжок часу під час розробки, протягом якого потрібно виконати певні завдання.

Інкремент — частина продукту програмного забезпечення, яка належним чином розроблена і протестована.

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

Ітеративна модель – проєктування

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

Ітеративна та поетапна (інкрементальна) розробка – це комбінація ітераційного методу та моделі поетапної (інкрементальної) розробки.

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

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

Ітеративна модель – застосування

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

Ця модель найчастіше використовується в таких сценаріях:

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

Ітеративна модель – переваги

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

Переваги ітераційної та інкрементної моделі SDLC такі:

• Деякі робочі функції можна розробити швидко та на ранніх стадіях життєвого циклу.
• Результати отримують завчасно та періодично.
• Можна планувати паралельний розвиток.
• Прогрес можна виміряти.
• Зміна обсягу робіт чи вимог  є дешевшою.
• Тестування та налагодження під час меншої ітерації виконується легше.
• Ризики визначаються та усуваються під час ітерації.
• Легше керувати ризиками – спочатку виконується найбільш проблемна частина.
• З кожним інкрементом поставляється робочий продукт.
• Проблеми, виклики та ризики, виявлені під час ітерації, можна використовувати для полегшення наступного етапу.
• Протягом життєвого циклу програмне забезпечення створюється на ранній стадії, що полегшує комунікацію і зворотній зв’язок від клієнта.

Ітеративна модель – недоліки

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

Недоліки ітераційної моделі SDLC такі:

• Може портребувати більше ресурсів.
• Хоча вартість внесення змін чи коригувань менша, але ця модель не дуже підходить для вимог, що постійно змінюються.
• Потрібно більше уваги керівництва.
• Можуть виникнути проблеми з архітектурою або дизайном системи, оскільки не всі вимоги зібрані на початку життєвого циклу.
• Для визначення інкрементів може знадобитися визначення повної системи.
• Складність управління більше.
• Кінець проєкту може бути невідомим, що є ризиком.
• Для аналізу ризиків потрібні висококваліфіковані спеціалісти. Прогрес проєктів сильно залежить від фази аналізу ризиків.

Модель водоспаду була першою представленою моделлю процесу розробки програмного забезпечення. Її також називають моделлю лінійно-послідовного життєвого циклу . Його дуже просто зрозуміти та використовувати. У моделі водоспаду кожна фаза має бути завершена до початку наступної фази.

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

Модель водоспаду – стадії

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

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

Збір і аналіз вимог – Усі можливі вимоги до системи, яка буде розроблена, фіксуються на цьому етапі та документуються в документі специфікації вимог.

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

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

Інтеграція та тестування – усі блоки, розроблені на етапі розробки, інтегруються в систему після тестування кожного блоку. Після інтеграції вся система перевіряється на наявність помилок та збоїв.

Розгортання системи − після завершення функціонального та нефункціонального тестування; продукт розгортається в середовищі клієнта або випускається на ринок.

Технічне обслуговування – у клієнтському середовищі можуть виникати певні проблеми. Для вирішення цих проблем випускаються патчі. Крім того, для вдосконалення продукту може бути випущено кілька кращих версій. Технічне обслуговування виконується для внесення цих змін у клієнтське середовище.

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

Модель водоспаду – застосування

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

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

• Вимоги дуже добре задокументовані, чіткі та фіксовані.
• Визначення продукту стабільне.
• Технологія зрозуміла і не є динамічною.
• Немає неоднозначних вимог.
• Доступні достатні ресурси з необхідним досвідом для підтримки продукту.

Модель водоспаду – переваги

Можна встановити графік із кінцевими термінами для кожного етапу розробки, і продукт може проходити через етапи моделі процесу розробки одну за одною.

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

Деякі з основних переваг моделі водоспаду такі:

• Проста і легка для розуміння та використання
• Легко керувати завдяки жорсткості моделі. Кожен етап має конкретні результати та процес перевірки.
• Фази обробляються та завершуються одна за одною.
• Чітко визначені етапи.
• Легко призначати завдання. Процес і результати добре задокументовані.

Модель водоспаду – недоліки

Недоліком моделі водоспаду є те, що вона не допускає можливості переглядів та внесення змін. Коли програма перебуває на стадії тестування, дуже важко повернутися назад і змінити щось, що не було добре задокументовано або продумано на стадії концепції.

Основні недоліки моделі водоспаду такі:

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