Simplen Trec

V-модель – це модель SDLC, де виконання процесів відбувається послідовним чином у V-подібній формі. Вона також відома як модель верифікації та валідації.

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

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

V-модель – етапи

У V-моделі є кілька етапів.

Аналіз бізнес-вимог

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

Проєктування системи

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

Архітектурне проєктування

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

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

Проєктування модуля

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

Фаза кодування

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

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

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

Інтеграційне тестування

Інтеграційне тестування пов’язане з етапом архітектурного проєктування. Інтеграційні тести виконуються для перевірки співіснування та зв’язку внутрішніх модулів у системі.

Тестування системи

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

Приймальне тестування

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

V-Модель – Застосування

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

Наступні умови є одними з найбільш поширених сценаріїв для використання V-моделі:

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

V-модель – переваги

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

Переваги V-моделі:

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

V-модель – недоліки

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

Недоліки методу V-моделі наступні:

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

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

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

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

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

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

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

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

Розробка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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