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

1. Лекція : Процеси перевірки: верифікація та валідація

ЛЕКЦІЯ :
ПРОЦЕСИ ПЕРЕВІРКИ:
ВЕРИФІКАЦІЯ ТА ВАЛІДАЦІЯ
NAU
Дишлевий О.П.

2.

2
Загальні ідеї та підходи
Верифікація та валідація
Аксіоматичні перевірки
Інші підходи
Перелік та перспективи
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

3. Процеси перевірки в життєвому циклі. Верифікація

3
Процеси перевірки в життєвому
циклі. Верифікація
В архітектурі процесів ЖЦ визначені 4 процеси підтримки які
направлені на підвищення якості ПЗ: Верифікація, Валідація, Сумісний
перегляд і Аудит.
Виходячи з положення стандарта ISO/IEC 12207 призначення
верифікації складається в підтвердженні того, що робочий продукт ПЗ
відповідає вимогам в результаті успішної реалізації процеса:
Буде розроблена і впроваджена стратегія верифікації;
Будуть встановлені критерії верифікації всіх необхідних робочих
продуктів ПЗ;
Будуть виконуватися належні дії з верифікації;
Буде виконуватися пошук дефектів у робочих продуктах та їх
усунення;
Забезпечуватиметься доступ замовника та інших зацікавлених сторін
до результатів верифікаційної діяльності ...
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

4. Валідація

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

5. Спільний перегляд

5
Призначення процесу спільного перегляду, відповідно до ISO / IEC
12207, полягає в тому, щоб «підтримувати відповідний рівень розуміння
замовником того, як проект просувається до цілей договору. Спільні
перегляди проводяться в результаті успішного здійснення процесу:
перегляди будуть проводитися в заздалегідь визначені терміни;
стан і продукти діяльності процесу будуть оцінюватися в ході
виконання спільного перегляду за участю замовників, постачальників та
інших відповідальних осіб і користувачів;
результати перегляду доводитимуться до всіх сторін, яких вони
стосуються;
заходи, рішення про виконання яких прийнято при переглядах,
відстежуватимуться до їх завершення;
проблеми будуть ідентифікуватися і вирішуватися
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

6. Цілі спільного перегляду

6
Мета періодичних спільних переглядів на рівні управління
проектом - Оцінити стан проекту по відношенню до
затверджених планів, графіків, стандартам і посібникам,
встановити, чи немає необхідності в зміні планів, чи
правильно розподілені ресурси, чи виконується
управління ризиками.
Мета періодичних спільних переглядів на технічному рівні
– оцінити стан робочих продуктів ПЗ по відношенню до
вимог замовника і критеріям приймання, зафіксованим в
договорі.
Мета внутрішніх періодичних спільних переглядів процесу
– оцінити його спроможність і придатність для проекту.
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

7. Аудит

7
Призначення процесу аудиту, згідно з ISO / IEC 12207, полягає в
незалежному встановленні відповідності вибраних продуктів і процесів
вимогам, планам та договором. В результаті успішного здійснення
процесу:
буде розроблена і впроваджена стратегія аудиту;
аудити будуть проводитися;
узгодженість обраних робочих продуктів ПЗ і / або послуг або
процесів до вимог, планами та договором буде встановлюватися
відповідно до стратегії аудиту;
проведення аудитів придатною для цього незалежною стороною буде
організовано;
проблеми, виявлені під час аудиту, будуть ідентифіковані, доведені до
тих, хто несе відповідальність за заходи з коригування, і вирішені.
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

8. Підтримка аудиту

8
Стандарт визначає робочі продукти і результати діяльності з
пропроцесу ЖЦ, що підлягають аудиту:
Відповідність коду програмного продукту проектної документації;
Адекватність вимог до приймальних переглядами і випробувань,
зафіксованих в документації, приймання програмного продукту;
Відповідність тестових даних специфікації;
Коректність звітів про випробування;
Усунення розбіжностей між фактичними і очікуваними
результатами;
Відповідність документації користувача встановленим стандартам;
Відповідність виконаних дій застосовним до них вимогам, планам і
договором;
Відповідність витрат і термінів плановим.

9. Зв'язок і відмінність процесів верифікації та валідації

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

10. Рівні цілісності програмного забезпечення

10
Рівні цілісності програмного
забезпечення
Рівні цілісності ПЗ системи зв'язуються з діапазоном значень
критичних характеристик ПЗ (надійності, безпеки функціонування,
захисту інформації, продуктивності, складності та ін), які дозволяють
утримувати ризики в прийнятних межах. Критичне вискоцілісне ПЗ
вимагає V & V, більше за обсягом і суворістю, ніж не критичне.
Критичність Опис
Рівні
Виска
Обрана функція служить критичним фактором для
ефективної роботи системи
4
Велика
Обрана функція потрібна для ефективної роботи системи
3
Помірна
Обрана функція впливає на роботу системи, але можуть
бути реалізовані стратегії обходу для компенсації втрати
ефективності
2
Обрана функція вносить істотний внесок в роботу системи.
Якщо вона не буде виконуватися належним чином,
користувач відчує незручності
1
Низька
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

11. Оцінка вимог до ПЗ

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

12. Вхідні дані V&V

Вхідні дані V&V
12
Опис проекту ПЗ
Потреби користувачів
Стандарти проектування
Звіти про критичність
задач
Звіти про аналіз загроз
Вихідний код
Плани та графіки розробки
Процедури тестування
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

13. Цілі V&V

Цілі V&V
13
Аналіз критичності
Аналіз розподілу системних
потреб
Створення/верифікація
тестування
Аудит інсталяційного
налаштування
Аналіз відсліжуваності
Аналіз загроз
Пробний запуск
Аналіз ризику
Створення кінцевого звіту
Аналіз інтерфейсів
Оцінка документу опису
концепції
Оцінка вимог до ПЗ
Оцінка стану керування
налаштуваннями
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

14. Результати V&V

Результати V&V
14
Звіти про задачі
Звіти про аномілії
Процедури тестування для V&V
Заключний звіт про V&V
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

15. Підтвердження узгодженості вимог до програмного засобу повинно бути засновано на:

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

16. Підтвердження повноти вимог до програмного засобу повинно бути засновано на:

Перевірці, чи визначено функціональні вимоги
(щодо алгоритмів, режимів/станів, входів/виходів,
обробки виняткових ситуацій, складання звітів
тощо), а також вимоги до технологічного процесу і
регламенту використання програмного засобу;
Перевірці,
чи
описані
інтерфейси
з
загальносистемним ПЗ, технічними засобами та
користувачами;

17. Підтвердження повноти вимог до програмного засобу повинно бути засновано на:

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

18. Підтвердження точності вимог до програмного засобу повинно бути засновано на…

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

19. Підтвердження читабельності вимог до програмного засобу повинно бути засновано на:

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

20. Підтвердження тестопридатності вимог до програмного засобу повинно бути засновано на…

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

21.

Завдання створення / верифікації плану
тестування з метою V & V системи виконується порізному, залежно від рівня цілісності програмного
засобу.
Для програмного засобу з рівнем цілісності 1
або 2 виконання цього завдання полягає у
верифікації відповідності плану тестування системи.
Перевіряється, чи охоплює тестове покриття
системні вимоги, чи вдало вибрані методи
тестування, чи можна буде ототожнити отримані
результати
з
очікуваними,
чи
здійснено
кваліфікаційне тестування і чи є можливості
виконувати і супроводжувати план.
Для більш високих рівнів цілісності програмного
засобу перевірки плану повинен бути побудований
самостійний план тестування системи з метою
підтвердження досягнення вимог.

22. Завдання верифікації та валідації проекту ПС з низькою критичністю

Цілі V & V - продемонструвати, що вимоги до
ПС коректно, точно і в повному обсязі перетворені в
проект, і не запроектовано будь-яких додаткових
властивостей програмного засобу, непередбачених
вимогами. У ході розгляду документів проекту
вирішуються три завдання веріфікації та валідації:
Оцінка проекту програмного засобу,
Створення / верифікація проектів тестів для V & V
інтеграції,
Створення / верифікація проектів тестів для V & V
системи.

23. Оцінка проекту програмного засобу

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

24. При верифікації та валідації проекту потрібно оцінити:

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

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

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

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

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

27.

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

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

Завдання створення / верифікації наборів тестів з
метою V & V інтеграції виконуються по-різному,
залежно від рівня цілісності програмного засобу.
Для програмного засобу з рівнем цілісності 1
або 2 виконання цих завдань полягає в
верифікації відповідності наборів тестів.
Для більш високих рівнів цілісності програмного
засобу перевірка наборів тестів, створених
розробником, повинна доповнюватися побудовою
нових наборів

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

Завдання створення / верифікації тестових
процедур з метою V & V інтеграції (системи)
виконуються по-різному, залежно від рівня
цілісності програмного засобу.
Для програмного засобу з рівнем цілісності 1
або 2 виконання цих завдань полягає в верифікації
відповідності тестових процедур.
Для більш високих рівнів цілісності програмного
засобу перевірка тестових процедур, створених
розробником, повинна доповнюватися побудовою
нових процедур.

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

Суть у підтвердженні результатів виконання
інтеграційного, системного та приймального
тестування (для рівнів цілісності 1 і 2) або виконання
додаткового тестування (для рівнів цілісності 3 та 4).
Включає вирішення двох завдань:
Виконання / верифікація тестів для V & V інтеграції;
Виконання / верифікація тестів для V & V системи.
Вихідними продуктами для виконання V & V
випробувань є плани і процедури для тестування
інтеграції (системи), а також вихідний і виконуваний
код програмного засобу.

31. Управління верифікацією та валідацією

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

32. Завдання управління верифікацією та валідацією

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

33. Завдання управління верифікацією та валідацією

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

34. Дії по V & V можуть виконуватися тільки:

Дії по V & V можуть виконуватися
тільки:
розробниками, рівними в правах,
групою розробки (менеджерами та
розробниками),
групою якості, спільно представниками
замовника і розробника,
тільки замовником або незалежними
експертами.

35.

Процеси V & V, що виконуються організацією
(підрозділом), що має певний рівень технічної,
адміністративної чи фінансової незалежності від
організації-розробника
(підрозділу-розробника),
називають незалежною верифікацією та валідацією
(IV & V, Independent V & V), а таку організацію
(підрозділ) - органом (групою ) IV & V.
IV & V доцільно застосовувати до великих
дорогих проектів або проектам критичних з безпеки
функціонування систем (safety critical system) для
досягнення об'єктивності перевірок і зниження
ризику розробки.

36. Види незалежності групи IV&V:

Види незалежності групи IV&V:
Технічна незалежність групи IV & V полягає в тому, що її
члени не беруть участі в розробці програмного засобу,
однак володіють знанням і досвідом розробки систем
даного класу і компетентні в прийнятті рішень, що
стосуються технічних аспектів програмного засобу.
Адміністративна незалежність означає, що IV & V
виконується
організацією,
адміністративно
не
пов'язаної ні з розробником, ні з замовником.
Фінансова незалежність означає, що фінансування робіт
з IV & V, а також контроль їх виконання здійснюється
організацією, не залежною від організації-розробника
програмного засобу.

37. Структура та зміст плану верифікації та валідації

У плані SVVP фіксується інформація,
необхідна для управління та виконання
процесів, дій і завдань по V & V в ході ЖЦ
програмного засобу.
Якщо по якомусь з пунктів плану інформація
не надається, це повинно вказуватися фразою
«дана тема не охоплюється планом» мати
обґрунтування. В план можуть бути додані й
інші пункти.

38. План верифікації та валідації програмного засобу

1. Призначення
2. Посилання
3. Визначення
4. Організація роботи з V & V
4.1. Організація
4.2. Графік робіт
4.3. Схема призначення рівнів цілісності ПО
4.4. Розподіл ресурсів
4.5. Відповідальності
4.6. Інструменти, методології та методи

39.

5. Процеси і дії з V & V
5.1. Процес: Управління
5.1.1. Дія: Управління V & V
5.2. Процес: Придбання
5.2.1. Дія: V & V підтримки придбання
5.3. Процес: Постачання
5.3.1. Дія: V & V планування
5.4. Процес: Розробки
5.4.1. Дія: V & V Концепції
5.4.2. Дія: V & V Вимог
5.4.3. Дія: V & V Проекту
5.4.4. Дія: V & V Реалізації
5.4.5. Дія: V & V Випробувань
5.4.6. Дія: V & V Введення в дію
5.5. Процес: Експлуатація
5.5.1. Дія: V & V Експлуатації
5.6. Процес: Супровід
5.6.1. Дія: V & V Супроводження

40.

6. Вимоги до звітних документів V & V
7. Вимоги до адміністративних процедур
7.1. Реєстрація та прийняття рішень по аномалії
7.2. Політика ітерації завдань
7.3. Регулювання відхилень від плану
7.4. процедури контролю
7.5. Стандарти практичні інструкції та угоди
8. Вимоги до документування V & V

41. Організація роботи з V & V. У цьому розділі повинні бути описані:

Організація роботи з V & V. У цьому
розділі повинні бути описані:
вид V & V (IV & V), взаємозв'язок процесів V & V з
іншими процесами ЖЦ. Мають бути чітко визначені
зв'язки(форма взаємодії) між організацією (групою), що
виконує V & V, і розробником, повноваження для
вирішення проблем, що виникають при виконанні
завдань V & V, і для приймання і затвердження
результатів V &V;
загальний план виконання дій, контрольні точки в V & V
і механізм зворотного зв'язку з процесом розробки.
Повинна бути описана прийнята модель ЖЦ розробки,
етапи виконання робіт, включаючи дати завершення
кожного етапу, передбачувані терміни поставки
програмних продуктів і передбачувані терміни
виконання дій по V & V (узгоджені з термінами
завершення етапів). Терміни повинні бути достатніми
для ефективного виконання завдань V &V;

42.

узгоджена схема рівнів цілісності ПЗ. Рівні цілісності повинні бути
призначені окремим компонентам , які вимагають застосування різних
підходів до V & V. Ці рівні повинні переглядатися перед початком
виконання дій по V & V для кожного основного процесу;
ресурси, необхідні для проведення V & V відповідно до обраного виду
V & V та організаційною структурою. Доцільно вказувати загальну
орієнтовну вартість виконання V & V, а також:
загальну трудомісткість (в людино-місяцях) і трудовитрати в розрізі
елементів оргструктури;
необхідну кваліфікацію персоналу та потреби навчання;
прогнозовану загальну вартість послуг з V & V ;
вартість придбання або розробки застосовуваних інструментів проведення
V&V;
вартість придбання, експлуатації та супроводу апаратного і
загальносистемного ПЗ в період виконання V & V, необхідного для
створення моделюючого комплексу;
витрати на задоволення спеціальних вимог щодо забезпечити захист, прав
доступу або управління документацією;

43.

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

44. Процеси і дії з V & V. Кожній дії процесу V & V потрібно описати:

Процеси і дії з V & V. Кожній дії
процесу V & V потрібно описати:
задачі V & V із зазначенням порядку їх виконання , входів і виходів. Одне і те
ж завдання може виконуватися для компонентів ПЗ різних рівнів цілісності з
різним ступенем строгості застосування методів і документування виходів;
методи і процедури виконання кожного завдання, а також критерії
оцінювання їх результатів;
входи для кожного завдання із зазначенням джерела і формату;
виходи для кожного завдання із зазначенням призначення, формату та
адресатів;
графік виконання завдань із зазначенням дати початку та завершення
виконання, а також отримання вхідної інформації і відправки результатів;
ресурси для виконання кожного завдання;
ризики та припущення, пов'язані з кожним завданням, а також рекомендації
щодо усунення, зниження чи спостереження ризиків;
обов'язки і відповідальність осіб, які беруть участь у вирішенні завдання.

45. Вимоги до звітних документів V & V.

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

46. Вимоги до адміністративних процедур.

У цьому розділі встановлюються вимоги по
наступних аспектах адміністративної підтримки
V & V:
складання звітів і прийняття рішень по
аномаліям;
повторне виконання завдання V & V;
оформлення відхилень від плану;
процедури контролю;
стандарти, практичні рекомендації та угоди.

47. Вимоги до документування V & V

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

48. Звіти з верифікації та валідації

Результати виконання дій і задач V & V
документуються у зведеному звіті про V & V,
який може включати:
звіт про завдання V & V;
підсумковий звіт про дію за V & V будь-якого з
основних процесів ЖЦ;
звіт про аномалії;
заключний звіт про V & V.

49. Альтернативи ЗЯ

49
Дефекти та ЗЯ
Дефект: помилка/відмова/збій.
Попередження / видалення / стримування дефектів.
Схема основних видів ЗЯ.
Профілактика дефектів: видалення джерел та блокування
помилок
Видалення дефектів: контроль / тестування / т.д.
Стримування дефектів: відмовостійкість і стримування
відмов(забезпечення безпеки)
Особливий випадок: формальні перевірки (та формальні
специфікації)
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

50. ЗЯ та формальні перевірки (ФП)

50
Формальні методи = формальні специфікації + формальні перевірки
Формальні специфікації (ФС):
Як частина запобігання дефектів
Формальні
запобігання/скорочення дефекту вкладання через
неточності,двозначності і т.д.
Менш покриті по відношенню
до ФП
Формальні перевірки(ФП):
Частина ЗЯ, але базується на
позитивних аспектах: “Доведення
відсутність відмов”
Інтенсивність роботи людей
Деякі часто використовувані
Якість та тестування програмного забезпечення
підходи
Вівторок, вересень 21, 2010

51. Формальні специфікації: Ідеї

51
Формальна специфікація:
Зосереджена на коректності
Різні рівні деталізації
Характеристики (3С): повна, якісна, послідовна
Два типи: описова та поведінкова
Описові ФС:
Логічні: перед/після умови
Математичні функції
Позначення та мовна підтримка
Поведінкові ФС: FSM, мережі петрі, і т.д.
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

52. Формальні специфікації: Ідеї

52
“Тестування показує наявність помилок, а не їх
відсутність” – Дейкстра
ФП: доказ конкретності
ФС: як пре/пост умови
Аксіоми для компонентів або формальних блоків
Склад
Розробка та перевірка разом
Інші схожі підходи
Напів-формальні перевірки
Перевірка моделей
Інспекція на коректність
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

53. Основи ФП

53
Основні підходи
Аксіоматичний підхід Флойд /Хоар
Дейкстра /Гріес з слабкими передумовами. (СП)
Обчислювальний/функціональний підхід Мілса
Базис перевірок
Логічні (аксіоматичні і СП)
Математичні функції (Міллс)
Інші формалізми
Використовувані процедури/дії
Аксіоматичні
Зворотного виводу (СП)
Попереднє складення (Міллс), і т.д.
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

54. Об’єктний та загальний підхід

54
Основна частина: вирази
Блок (початок/кінець)
Конкатенація
Умовні (if-then/if-then-else)
Цикл (while)
Призначення
ФП
Правила для більших частин
Складання
Зв’язувачі (логічні наслідки)
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

55. Аксіоматичний підхід

55
аксіоми/блок-схеми Флойда
Примітка на блок-схемі
Логічні відносини
Перевірка використовуваної логіки
аксіоми/формалізація Хоара
Перед/пост-умови
Склад
Цикли і функції/параметри
Інваріанти (цикли, функції)
Основа для багатьох пізніших підходів
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

56. Аксіоматична правильність

56
Позначення
Заяви: Si
Логічні умови: {P} і т.д.
Схема: {P} S {Q}
Аксіоми / правила: умови або схеми / висновок
Аксіоми:
Схема для призначення
Основні типи виразів
“З’єднання”
Циклові інваріанти
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

57. Аксіоматичний підхід: формальні характеристики

57
Аксіоматичний підхід: формальні
характеристики
ФС:
Логічного (описового) типу.
Перед/пост-умови
Пара, як специфікації на різних рівнях деталізації
Приклади специфікації на різних для сегменту:
Змінні вводу/виводу: x,y
Перед/пост-умови: P, Q
Передумови: невід’ємний вхід
Постумова: обчислюється квадратний корінь
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

58. Аксіоматичний підхід: Правила виводу

58
Аксіоматичний підхід: Правила
виводу
Правила виводу: Послідовність аксіом
Логічні
наслідки та висновки.
Гнучкість для різних пре/пост-умов.
Наслідок 1: послаблені пост-умови
Аксіома А1:
Наслідок 2: більш суворі передумови
Аксіома А2:
У порівнянні з СП
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

59. Аксіоматичний підхід: Аксіоми

59
Схема призначення:
Аксіома
А3:
Де
виходить з P з усіма вільними
входженнями у заміненого х.
Приклад:
з
Пост-умова
Передумова
(підтримання невід'ємного балансу)
чи
Аксіома 4. Послідовне обєднання:
Використовується для побудови доказів знизу догори
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

60. Аксіоматичний підхід: Аксіоми

60
Умовні аксіоми
Умова 1,if-then-else
(Аксіома 5):
Умова 2, пустий else
(Аксіома 6):
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

61. Аксіоматичний підхід: Аксіоми

61
Тип циклу: while умова do щось
Аксіома циклу
Спеціалізовані методи для циклів:
Інваріанта циклу: P (часто називають I)
Як вибрати інваріанта циклу?
Доказ основних циклів: Аксіома А7.
Цикл припинення перевірки
P позитивне в циклі
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

62. Аксіоматичні докази

62
Дано: програма, перед/пост-умови
Базова процедура доказу:
Додати анотації між заявами
Застосовувати аксіоми окремих заяв використовуючи
схеми при значення (A3)
Проста композиція (об’єднання, А4)
Наслідок правил (А1 та А2) як з’єднувачі змішані з
вищевказаними
Більш складна композиція:
if-then-else (A5) and if-then (A6)
Аксіома циклу (А7): часто в центрі уваги
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

63. Аксіоматичні докази

63
Базовий доказ фокусується на
наступному:
Припиненні
циклу та інваріантах
З'єднанні (знизу-вгору)
Використання
ієрархічної
(ступенева абстракція) структури
в якості керівництва для різних
частин (згори-вниз керівництво
знизу-вгору процедури)
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

64. Приклад аксіоматичного доказу

64
Факторіал функції
Приклад аксіоматичного
доказу
Передумови:
Постумови:
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

65. Приклад аксіоматичного доказу

65
Ключ доказу: цикл; інші кроки досить прості
Розвиток циклу інваріанту І:
має часткові результати
З'єднання з умовою циклу
Результат у постумові після циклу:
Спостереження за прикладом доказу: доказ
значно довший ніж сама програма
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

66. Аксіоматичні докази

66
Загальні спостереження:
Включає багато кроків
Довжина доказу: на порядок довше ніж
програма
Складності з циклами
Великі/складніші програми:
Багато елементів та (вкладених!) циклів
взаємодії, координації
Масиви та функції/процедури
більш складні схеми/аксіоми
Значно важче
Вибіркова перевірка ідей?
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

67. Підхід найслабших передумов (WP)

67
Підхід найслабших передумов
(WP)
Підхід Дейкстра/Грайза:
Схожий на аксіоматичний підхід:
Слабкі передумови:
Модель Дейкстра: Перетворюється предикат
Книга Грайза “Science of Programming”
Основна логіка як у анотаціях
Схожий блок (аксіоми)
інтерпретується як
Відмінність процедур:
Початок з постумов (вихідні дані)
Зворотнє виведення WP
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

68. Функціональний підхід

68
Функціональний підхід
Програма обчислення Мілса
Символічне виконання широко використовується
Ідеї читання/відриву/пізнання коду
Елементи функціонального підходу
Нотації Мілса
Основні функції, пов'язані з окремими заявами
Композиційні правила
Наступне покрокове/символічне виконання
Порівнянння з Дейкстровою WP
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

69. Функціональний підхід: символічне виконання

69
Функціональний підхід:
символічне виконання
Символічне виконання для:
Trace 1:
Trace 2:
Обидва залишки використовуються при перевірці
Деталі
у Мілсі (1987а)
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

70. Формальна перевірка: Недоліки

70
Сім міфів (Зелковиц, 1993):
FM гарантує що ПО є бездоганним
Вони працюють, довівши правильність
Тільки дуже критичні переваги системи
FM повязано зі складними математиками
FM збільшує вартість розробки
Вони є незрозумілими для клієнта
Ніхто не використовує їх для реальних проектів
Спростування дискусія (Зелковиц, 1993)
Проте деякі кількісні дії альтернативні FV
методам
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

71. Інші моделі/підходи

71
Виробництво FV більш легке/ширше для використання
Інші моделі для формальної перевірки:
Установка машин та перевірка моделей
Алгебраїчні дані специфікації/перевірки
Мережі Петрі
Зв’язок перевірених/підтверджених процедур
Загальне судження
Розширення для FM раніше
Додаткові переваги та зниження обмежень
Може призвести до додаткової автоматизації
Гібридні методи
Адаптація та напів формальні методи
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

72. Формальна перевірка: Інше

72
Алгебраїчна специфікація/перевірка:
Вкажіть і перевірте властивості даних
Поведінка специфікації
Базовий варіант
Конструкції
Домен/поведінка відображення
Використання у перевірці
Приклади стеку
Newstack
Push
Pop
Canonical form
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

73. Формальна перевірка: Інше

73
Модель перевірки:
Поведінкова специфікація через FSM
Пропозиція: власність інтересу проявляється в якості підходящої формули.
Перевірювач: перевірка обгрунтованої пропозиції алгоритма/програми
Твердження: результат позитивний
Контрприклад: результат негативний
Інші підходи та обговорення:
Алгоритм аналізу
Моделювання та аналіз мереж Петрі
Табличний/напівформальний метод
Основні формальні інспекції
Обмеження аспектів – легше виконання
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

74. FM: Застосування

74
Що може бути формально перевірене:
Програмний код
Формальний дизайн, документація, та інше
Протоколи: тимчасові властивості –
тупик(deadlock)/голод(starvation)
Апаратна перевірка
Розподілена програмна перевірка
Підключення до ПЗ процесу
Покрокове уточнення/перевірка процесу:
Дизайн та перевірка водночас
Різні рівні абстракції
Напр., UNITY система
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

75. Використання у безпеці ПЗ

75
Leveson підхід
Орієнтована
перевірка
Рухомий аналіз небезпеки
Розподілені по фазам розвитку
Яке FM? Необхідне
Інші використання:
Чисте
приміщення: поєднані зі статичними
випробуваннями
Yih/Tian: PSC
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

76. Формальна перевірка: Підсумки

76
Основні особливості:
Аксіоми/правила для всіх мовних особливостей
Ігнорувати деякі практичні питання:
Розмір, ємність, побічні ефекти і т.д.
Вперед/назазнизу-вверх процедури
Розробка інваріантів: ключ, але важкий
Загальна оцінка:
Важно, навіть на великих програмах
Дуже важко масштабувати
Невідповідна до математичних задач
Важко автоматизувати
Ручний процес – помилки
Варте для критичного застосування
Порівняння з іншими QA
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010

77. Запитання?

77
Якість та тестування програмного забезпечення
Вівторок, вересень 21, 2010