Simplen Trec

Життєвий цикл розробки програмного забезпечення (SDLC) — це процес проектування, розробки та тестування програмного забезпечення. Метою SDLC є створення високоякісного програмного забезпечення, яке відповідає очікуванням клієнтів і готове до використання у визначені терміни та відповідно до встановлених кошторисів.

ISO/IEC 12207 — це міжнародний стандарт для процесів життєвого циклу програмного забезпечення. Даний стандарт визначає завдання, необхідні для розробки та підтримки програмного забезпечення.

Етапи SDLC

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

Етап 1: Планування та аналіз вимог

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

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

Етап 2: Визначення вимог

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

Етап 3: Проектування архітектури продукту

SRS є орієнтиром для архітекторів продукту, щоб створити найкращу архітектуру для продукту, який буде розроблено. На основі вимог, зазначених у SRS, зазвичай пропонується більше ніж один підхід до проектування архітектури продукту та документується в DDS (Design Document Specification) — специфікації проектної документації.

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

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

Етап 4: Створення або розробка продукту

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

Розробники повинні дотримуватися вказівок щодо кодування, визначених їхньою організацією, а для створення коду використовуються інструменти програмування, такі як компілятори, інтерпретатори, налагоджувачі тощо. Для кодування використовуються різні мови програмування високого рівня, такі як C, C++, Java, C#, Python та інші. Мова програмування вибирається залежно від типу програмного забезпечення, що розробляється.

Етап 5: тестування продукту

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

Етап 6: Розгортання на ринку та обслуговування

Після того, як продукт протестований і готовий до розгортання, він офіційно випускається на відповідному ринку. Іноді розгортання продукту відбувається поетапно відповідно до бізнес-стратегії організації. Спочатку продукт може бути випущений в обмеженому сегменті та протестований у реальному бізнес-середовищі (UAT-User acceptance testing).

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

Моделі SDLC

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

Приклади моделей SDLC, які застосовуються в процесі розробки програмного забезпечення:

• Модель водоспаду
• Ітеративна модель
• Спіральна модель
• V-Model
• Модель великого вибуху
• Інші пов’язані методології – гнучка модель, модель RAD,  моделі прототипування.

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

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

Верифікація та валідація

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

Валідація – це визначення відповідності розробленого програмного забезпечення очікуванням та потребам користувача, системним вимогам.

Однак постає питання у чому ж відмінності між верифікацією та валідацією?

Спростимо надані визначенння і трохи перефразуємо їх.

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

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

Ключова різниця між верифікацією та валідацією

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

Верифікація не передбачає виконання коду, тоді як валідація передбачає виконання коду.

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

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

Верифікація виявляє помилки на початку циклу розробки, тоді як валідація знаходить помилки, які верифікація не може виявити.

Ключові артефакти

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

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

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

Ключовий показник

Тестове покриття – один з показників якості тестування, який відображує щільність покриття тестами умов або коду.