Процес верифікації та валідації проекту

Перевірка дизайну

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

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

На зображенні нижче показано процес перевірки дизайну.

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

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

Перевірка дизайну

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

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

Різниця між перевіркою дизайну та валідацією

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

Процес перевірки дизайну

Ідентифікація та підготовка:

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

Планування:

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

Розвиток:

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

Виконання:

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

Доповіді:

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

Процес перевірки дизайну

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

Приклад

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

Переваги валідації та верифікації проекту

• Ми можемо постійно контролювати проекти, що дозволяє нам відповідати вимогам, визначеним користувачем, на кожному етапі.
• Перевірка дизайну вкаже на різницю між тим, як працює функціональність, і тим, як вона буде працювати.
• Документування процедур перевірки допоможе легко зрозуміти функціональність на будь-якому етапі в майбутньому, якщо будуть внесені будь-які зміни або вдосконалення.
• Час розробки буде постійно скорочуватися, підвищуючи продуктивність, що дозволить постачати продукт, як очікувалося.
• Цей процес включає діапазон і обсяг кожного методу перевірки, який необхідно використовувати.
• Перевірку можна здійснити з використанням детальних проектних даних, які представляють кінцеві вимоги користувача.
• Необхідно зафіксувати будь-яку різницю між результатом і необхідними користувачам документами.
• Зміни в дизайні перевірки призводять до повторної перевірки.
• Важливо документувати кожну дію, яка відбувається під час перевірки, яка належним чином доводить, що дизайн відповідає вимогам користувача.