Процес верифікації та валідації проекту
Томас Гамільтон
⚡ Розумний підсумок
Верифікація проєкту підтверджує, що вихідні дані проєкту відповідають задокументованим вхідним даним, тоді як валідація проєкту підтверджує, що готовий продукт задовольняє реальні потреби його користувачів. Обидва процеси виконуються протягом усієї розробки, а не один раз в кінці.
Перевірка дизайну
Перевірка дизайну – це метод підтвердження, шляхом перевірки та надання доказів, що вихідний результат розробленого програмного продукту відповідає його вхідним специфікаціям. Метою процесу перевірки проекту під час розробки програмного забезпечення є забезпечення того, що розроблений програмний продукт такий самий, як було зазначено.
Вхідні дані для проектування – це будь-які фізичні та експлуатаційні вимоги, що використовуються як основа для проектування. Вихідні дані для проектування є результатом кожного етапу проектування та загальних зусиль проектування. У регульованих галузях, таких як медичні вироби, кінцеві вихідні дані для проектування стають основою для головного запису пристрою, тому термінологія контролю проектування так часто зустрічається в документації з верифікації.
На практиці, верифікація порівнює два набори документів: специфікації, стандарти та обмеження, що були надані, з кресленнями, кодом та інструкціями з тестування, що були надані. Кожна невідповідність між ними є результатом верифікації.
Перевірка дизайну
Верифікація доводить внутрішню узгодженість. Валідація ставить складніше питання про те, чи описувала специфікація правильний продукт спочатку.
Перевірка дизайну – це процес оцінки програмного продукту на відповідність точним вимогам кінцевих користувачів або зацікавлених сторін. Метою валідації дизайну є тестування програмного продукту після розробки, щоб підтвердити, що він відповідає цим вимогам, коли він використовується у власному середовищі користувача.
Валідація пов'язана з демонстрацією узгодженості та повноти дизайну з урахуванням потреб користувача. Це етап, на якому ви фактично створюєте версію продукту та перевіряєте її на відповідність вимогам користувача.
Банер нижче позначає дві частини діяльності так, як вони зазвичай представлені в проектних документах.
Наведена нижче діаграма показує сам процес перевірки дизайну, від потреб користувача до перевірки продукту.
Мета полягає в тому, щоб довести за допомогою об'єктивних доказів, що продукт задовольняє задокументовані потреби користувача. Об'єктивні докази – це просто фізичний доказ результату — зображення, текстовий файл, аудіофайл або підписаний звіт — який показує, що процедура була фактично виконана.
За допомогою цих об'єктивних доказів процес послідовно перевіряє, чи відповідає продукт заздалегідь визначеним вимогам. Він включає тестування, перевірку, аналіз та подібні методи, тому валідація зазвичай спирається на тестування системи та приймальне тестування користувачами а не на перевірках на рівні підрозділів.
Різниця між перевіркою дизайну та валідацією
Завжди існують помилкові уявлення про верифікацію та валідацію. Це різні дії, і обидві виконуються на кожному етапі процесу розробки, а не на окремому етапі.
| Перевірка дизайну | Перевірка дизайну |
|---|---|
| Перевірка проекту використовується там, де фактичний результат проекту має бути таким самим, як очікуваний результат проекту, що відповідає специфікаціям продукту. | Валідація дизайну використовується для того, щоб переконатися, що остаточний дизайн відповідає очікуванням потреб користувача. |
| Перевірка дизайну запитує: чи правильно ви розробили продукт? | Валідація дизайну запитує: чи ви розробили правильний продукт? |
| Перевірка проекту включає блок та первинну тестування рівня інтеграції. | Перевірка дизайну включає інтеграцію вторинного або вищого рівня та тестування на рівні системи. |
| Певні аспекти валідації проекту можуть бути виконані під час верифікації проекту, але верифікація проекту не замінює валідацію проекту. | Перевірка проекту слідує за успішною перевіркою проекту. |
| Перевірка проекту може проводитися на окремому модулі або на готовій системі за будь-яких умов. | Перевірка проекту повинна проводитися за певних умов відповідно до вимог користувача. |
| Перевірка проекту може використовувати статичні методи. Вона включає системні перевірки, аналіз та формальні верифікаційні дії. | Валідація проекту складається з остаточного звіту про результати виконання тестів, який переглядається, затверджується та підписується. Ці документи зберігаються для подальшого використання. |
Корисний скорочений варіант: перевірка здебільшого статична робота щодо документів, тоді як перевірка здебільшого динамічне тестування проти запущеної збірки.
Процес перевірки дизайну
Процес верифікації проходить у п'ять етапів, і кожен з них створює артефакт, від якого залежить наступний етап.
Ідентифікація та підготовка:
- Під час розробки специфікації паралельно визначається верифікаційна діяльність. Це дозволяє розробнику переконатися, що специфікацію дійсно можна перевірити, щоб інженер з тестування міг розпочати розробку детальних планів та процедур тестування. Будь-які зміни до специфікації повинні бути повідомлені.
- Визначити найкращий підхід до проведення верифікації та визначити методи вимірювання, необхідні ресурси, інструменти та обладнання.
- Завершений план перевірки переглядається з командою проектувальників для виявлення проблем перед остаточним затвердженням плану.
Планування:
- Планування верифікації – це одночасна діяльність основної команди та команди розробників. Вона відбувається протягом усього життєвого циклу проекту та оновлюється щоразу, коли змінюються вхідні дані про проект.
- Під час цього етапу програмне забезпечення або система, що тестується, документується за обсягом.
- Попередній план тестування пишеться, а потім уточнюється. План фіксує критичні етапи, які знижують ризик проекту.
- Вибираються інструменти, тестове середовище та стратегія розробки, а також визначаються вимоги, які мають бути підтверджені шляхом перевірки або аналізу.
Розвитокping:
- Тестовий випадок розвиток збігається з Методологія SDLC впровадила команда проекту. На цьому етапі визначено різноманітні методи тестування.
- Вхідні дані для проектування повинні бути розроблені таким чином, щоб навіть найпростіші дії з верифікації були однозначними та такими, що підлягають перевірці.
- Час перевірки скорочується, коли подібні концепції перевіряються послідовно, оскільки результат одного тесту можна повторно використовувати як вхідні дані для наступного тесту.
- TracМіж тестовими випадками та відповідними їм вхідними даними проєкту створюються зв'язки спроможності, щоб гарантувати перевірку кожної вимоги та відповідність результатів проєкту вхідним даним.
Виконання:
- Процедури тестування, створені на етапі розробки, виконуються відповідно до плану тестування та суворо дотримуються під час верифікаційної діяльності.
- Якщо виникають недійсні результати або якщо будь-яка процедура потребує модифікації, зміни повинні бути задокументовані та офіційно затверджені.
- Будь-яка виявлена проблема реєструється як дефект через звичайний процес управління дефектами.
- A tracматриця доцільності створюється для перевірки того, що кожен вхідний проектний параметр, визначений у плані верифікаційного тестування, був перевірений, а також для визначення коефіцієнта проходження.
Доповіді:
- Ця дія виконується в кінці кожного етапу виконання перевірки.
- Звіт про перевірку проекту містить детальний огляд результатів перевірки, включаючи управління конфігурацією, результати кожного типу тестування та проблеми, виявлені під час перевірки.
- Перевірка дизайну tracЗвіт про працездатність створюється між вимогами та відповідними результатами тестування, щоб підтвердити, що всі вимоги були перевірені та що відповідні результати були зафіксовані.
- Будь-яка невідповідність документується та належним чином вирішується.
- RevПеревірки проводяться після завершення діяльності з перевірки проекту, а результати офіційно затверджуються.
Процес перевірки дизайну
Валідація не має однаково жорсткої послідовності. Натомість вона спирається на невеликий набір прийнятих методів, і проект зазвичай використовує більше одного з них.
- Порівняння з еквівалентними конструкціями. Деякі конструкції можна перевірити, порівнявши їх з аналогічним обладнанням, що служить аналогічному призначенню. Це особливо актуально під час перевірки змін конфігурації існуючої інфраструктури або стандартних конструкцій, які впроваджуються в нову систему чи програму.
- Демонстрація та перевірка. Для перевірки вимог та інших функцій продукту можна використовувати будь-який або обидва.
- Аналіз. Конструкцію можна проаналізувати за допомогою математичного моделювання або симуляції, яка відтворює необхідну функціональність.
- Тестування. Випробування проводяться на остаточному проекті для перевірки здатності системи працювати належним чином, тобто функціональне тестування та нефункціональне тестування відповідати вимогам користувача.
- Документація. План тестування, його виконання та результати повинні бути задокументовані та зберігатися як частина проектних записів. Валідація, зрештою, є зібраними результатами всіх заходів з валідації.
- Обґрунтування еквівалентності. Коли еквівалентні продукти використовуються в остаточній валідації проекту, виробник повинен задокументувати подібність та будь-які відмінності від початкового виробництва.
Приклад
Короткий розібраний приклад робить цю різницю конкретною.
- Візьмемо, наприклад, простий продукт: водонепроникний годинник.
- У документі з вимогами до продукту може бути зазначено, що «годинник має бути водонепроникним під час плавання». Це потреба користувача, і саме за цим вимірюється валідація.
- У специфікації дизайну може бути зазначено, що «годинник повинен функціонувати, навіть якщо користувач плаває протягом тривалого часу». Це вхідні дані дизайну, і саме за ними вимірюється верифікація.
- Результати випробувань повинні підтвердити, що годинник відповідає цим вимогам. Якщо ні, ітерації редизайну продовжуються, доки він не буде відповідати.
Зверніть увагу, як годинник може пройти перевірку, але все одно не пройти перевірку. Якщо специфікація визначає тривале плавання як п'ятнадцять хвилин, а справжні плавці залишаються у воді протягом години, вихідні дані проєкту ідеально відповідають вхідним, але все одно підводять користувача.
Переваги валідації та верифікації проекту
Безперервне виконання обох дій, а не їх завершення, дає переваги, наведені нижче.
- Проекти можна контролювати безперервно, що дозволяє виконувати визначені користувачем вимоги на кожному етапі.
- Перевірка дизайну вказує на різницю між тим, як працює функціональність, і тим, як вона має працювати.
- Документування процедур перевірки робить функціональність легкою для розуміння пізніше, коли вносяться зміни або вдосконалення.
- Час розробки постійно скорочується, а продуктивність підвищується, що допомагає видавати продукт відповідно до очікувань.
- Процес визначає діапазон та обсяг кожного методу валідації, який необхідно використовувати.
- Валідацію можна проводити з використанням детальних проектних даних, які відображають вимоги кінцевого користувача.
- Будь-яка різниця між результатом та документами, необхідними користувачеві, фіксується, а не втрачається.
- Зміни у перевіреному дизайні запускають повторну перевірку, тому запис ніколи не віддаляється від продукту.
- Документування кожної дії, що відбувається під час перевірки, є тим, що належним чином доводить, що дизайн відповідає вимогам користувача.
Тому перевірку та валідацію проекту найкраще планувати в рамках ширшого життєвий цикл тестування ПЗ і зіставлені з іншими види тестування програмного забезпечення, а не розглядатися як окрема процедура забезпечення відповідності.
