Содержание
- 2. Загальні ідеї та підходи Верифікація та валідація Аксіоматичні перевірки Інші підходи Перелік та перспективи Вівторок, вересень
- 3. Процеси перевірки в життєвому циклі. Верифікація В архітектурі процесів ЖЦ визначені 4 процеси підтримки які направлені
- 4. Валідація Призначення процесу валідації полягає в підтвердженні того, що вимоги, що стосуються конкретного застосування робочого продукту
- 5. Спільний перегляд Призначення процесу спільного перегляду, відповідно до ISO / IEC 12207, полягає в тому, щоб
- 6. Цілі спільного перегляду Мета періодичних спільних переглядів на рівні управління проектом - Оцінити стан проекту по
- 7. Аудит Призначення процесу аудиту, згідно з ISO / IEC 12207, полягає в незалежному встановленні відповідності вибраних
- 8. Підтримка аудиту Стандарт визначає робочі продукти і результати діяльності з пропроцесу ЖЦ, що підлягають аудиту: Відповідність
- 9. Зв'язок і відмінність процесів верифікації та валідації Верифікація виконується з метою своєчасного виявлення і усунення допущених
- 10. Рівні цілісності програмного забезпечення Рівні цілісності ПЗ системи зв'язуються з діапазоном значень критичних характеристик ПЗ (надійності,
- 11. Оцінка вимог до ПЗ Полягає в аналізі всіх видів вимог з метою перевірки і підтвердження їх
- 12. Вхідні дані V&V Опис проекту ПЗ Потреби користувачів Стандарти проектування Звіти про критичність задач Звіти про
- 13. Цілі V&V Аналіз критичності Аналіз розподілу системних потреб Аналіз відсліжуваності Аналіз загроз Аналіз ризику Аналіз інтерфейсів
- 14. Результати V&V Звіти про задачі Звіти про аномілії Процедури тестування для V&V Заключний звіт про V&V
- 15. Підтвердження узгодженості вимог до програмного засобу повинно бути засновано на: Перевірці, чи всі терміни та визначення
- 16. Підтвердження повноти вимог до програмного засобу повинно бути засновано на: Перевірці, чи визначено функціональні вимоги (щодо
- 17. Підтвердження повноти вимог до програмного засобу повинно бути засновано на: Перевірці, чи встановлені критерії ефективності програмного
- 18. Підтвердження точності вимог до програмного засобу повинно бути засновано на… …перевірці, чи задовольняє точність обчислень (усікання,
- 19. Підтвердження читабельності вимог до програмного засобу повинно бути засновано на: Перевірці, чи написана документація зрозуміло, дохідливо,
- 20. Підтвердження тестопридатності вимог до програмного засобу повинно бути засновано на… …перевірці наявності об'єктивних критеріїв приймання для
- 21. Завдання створення / верифікації плану тестування з метою V & V системи виконується по-різному, залежно від
- 22. Завдання верифікації та валідації проекту ПС з низькою критичністю Цілі V & V - продемонструвати, що
- 23. Оцінка проекту програмного засобу полягає в аналізі коректності, узгодженості, повноти, точності, читабельності та тестопридатності елементів проекту,
- 24. При верифікації та валідації проекту потрібно оцінити: Відповідність методів проектування і стандартів вимогам проекту; Відповідність потоків
- 25. Завдання верифікації та валідації реалізації програмного засобу з низькою критичністю Діяльність по V & V вихідного
- 26. Завдання верифікації та валідації реалізації програмного засобу з низькою критичністю Оцінка вихідного коду і документації вихідного
- 27. чи задовольняє цей код вимогам користувача; чи відповідає вихідний код чинним стандартам; чи існують об'єктивні критерії
- 28. Завдання верифікації та валідації реалізації програмного засобу з низькою критичністю Завдання створення / верифікації наборів тестів
- 29. Завдання верифікації та валідації реалізації програмного засобу з низькою критичністю Завдання створення / верифікації тестових процедур
- 30. Завдання верифікації та валідації випробувань програмного засобу з низькою критичністю Суть у підтвердженні результатів виконання інтеграційного,
- 31. Управління верифікацією та валідацією Управління діями по V & V при виконанні основних процесів ЖЦ, для
- 32. Завдання управління верифікацією та валідацією До завдань управління V & V входить постійний аналіз діяльності з
- 33. Завдання управління верифікацією та валідацією В ході управління V & V: Оцінюється кожне запропонована зміна в
- 34. Дії по V & V можуть виконуватися тільки: розробниками, рівними в правах, групою розробки (менеджерами та
- 35. Процеси V & V, що виконуються організацією (підрозділом), що має певний рівень технічної, адміністративної чи фінансової
- 36. Види незалежності групи IV&V: Технічна незалежність групи IV & V полягає в тому, що її члени
- 37. Структура та зміст плану верифікації та валідації У плані SVVP фіксується інформація, необхідна для управління та
- 38. План верифікації та валідації програмного засобу 1. Призначення 2. Посилання 3. Визначення 4. Організація роботи з
- 39. 5. Процеси і дії з V & V 5.1. Процес: Управління 5.1.1. Дія: Управління V &
- 40. 6. Вимоги до звітних документів V & V 7. Вимоги до адміністративних процедур 7.1. Реєстрація та
- 41. Організація роботи з V & V. У цьому розділі повинні бути описані: вид V & V
- 42. узгоджена схема рівнів цілісності ПЗ. Рівні цілісності повинні бути призначені окремим компонентам , які вимагають застосування
- 43. організаційна структура колективу, що виконує V & V, із зазначенням сфери відповідальності кожного його члена і
- 44. Процеси і дії з V & V. Кожній дії процесу V & V потрібно описати: задачі
- 45. Вимоги до звітних документів V & V. У цьому розділі зазначаються види, структура і зміст обов'язкових
- 46. Вимоги до адміністративних процедур. У цьому розділі встановлюються вимоги по наступних аспектах адміністративної підтримки V &
- 47. Вимоги до документування V & V У цьому розділі зазначаються призначення , формат і зміст документів
- 48. Звіти з верифікації та валідації Результати виконання дій і задач V & V документуються у зведеному
- 49. Альтернативи ЗЯ Дефекти та ЗЯ Дефект: помилка/відмова/збій. Попередження / видалення / стримування дефектів. Схема основних видів
- 50. ЗЯ та формальні перевірки (ФП) Формальні методи = формальні специфікації + формальні перевірки Формальні специфікації (ФС):
- 51. Формальні специфікації: Ідеї Формальна специфікація: Зосереджена на коректності Різні рівні деталізації Характеристики (3С): повна, якісна, послідовна
- 52. Формальні специфікації: Ідеї “Тестування показує наявність помилок, а не їх відсутність” – Дейкстра ФП: доказ конкретності
- 53. Основи ФП Основні підходи Аксіоматичний підхід Флойд /Хоар Дейкстра /Гріес з слабкими передумовами. (СП) Обчислювальний/функціональний підхід
- 54. Об’єктний та загальний підхід Основна частина: вирази Блок (початок/кінець) Конкатенація Умовні (if-then/if-then-else) Цикл (while) Призначення ФП
- 55. Аксіоматичний підхід аксіоми/блок-схеми Флойда Примітка на блок-схемі Логічні відносини Перевірка використовуваної логіки аксіоми/формалізація Хоара Перед/пост-умови Склад
- 56. Аксіоматична правильність Позначення Заяви: Si Логічні умови: {P} і т.д. Схема: {P} S {Q} Аксіоми /
- 57. Аксіоматичний підхід: формальні характеристики ФС: Логічного (описового) типу. Перед/пост-умови Пара, як специфікації на різних рівнях деталізації
- 58. Аксіоматичний підхід: Правила виводу Правила виводу: Послідовність аксіом Логічні наслідки та висновки. Гнучкість для різних пре/пост-умов.
- 59. Аксіоматичний підхід: Аксіоми Схема призначення: Аксіома А3: Де виходить з P з усіма вільними входженнями у
- 60. Аксіоматичний підхід: Аксіоми Умовні аксіоми Умова 1,if-then-else (Аксіома 5): Умова 2, пустий else (Аксіома 6): Вівторок,
- 61. Аксіоматичний підхід: Аксіоми Тип циклу: while умова do щось Аксіома циклу Спеціалізовані методи для циклів: Інваріанта
- 62. Аксіоматичні докази Дано: програма, перед/пост-умови Базова процедура доказу: Додати анотації між заявами Застосовувати аксіоми окремих заяв
- 63. Аксіоматичні докази Базовий доказ фокусується на наступному: Припиненні циклу та інваріантах З'єднанні (знизу-вгору) Використання ієрархічної (ступенева
- 64. Приклад аксіоматичного доказу Факторіал функції Приклад аксіоматичного доказу Передумови: Постумови: Вівторок, вересень 21, 2010 Якість та
- 65. Приклад аксіоматичного доказу Ключ доказу: цикл; інші кроки досить прості Розвиток циклу інваріанту І: має часткові
- 66. Аксіоматичні докази Загальні спостереження: Включає багато кроків Довжина доказу: на порядок довше ніж програма Складності з
- 67. Підхід найслабших передумов (WP) Підхід Дейкстра/Грайза: Слабкі передумови: Модель Дейкстра: Перетворюється предикат Книга Грайза “Science of
- 68. Функціональний підхід Функціональний підхід Програма обчислення Мілса Символічне виконання широко використовується Ідеї читання/відриву/пізнання коду Елементи функціонального
- 69. Функціональний підхід: символічне виконання Символічне виконання для: Trace 1: Trace 2: Обидва залишки використовуються при перевірці
- 70. Формальна перевірка: Недоліки Сім міфів (Зелковиц, 1993): FM гарантує що ПО є бездоганним Вони працюють, довівши
- 71. Інші моделі/підходи Виробництво FV більш легке/ширше для використання Інші моделі для формальної перевірки: Установка машин та
- 72. Формальна перевірка: Інше Алгебраїчна специфікація/перевірка: Вкажіть і перевірте властивості даних Поведінка специфікації Базовий варіант Конструкції Домен/поведінка
- 73. Формальна перевірка: Інше Модель перевірки: Поведінкова специфікація через FSM Пропозиція: власність інтересу проявляється в якості підходящої
- 74. FM: Застосування Що може бути формально перевірене: Програмний код Формальний дизайн, документація, та інше Протоколи: тимчасові
- 75. Використання у безпеці ПЗ Leveson підхід Орієнтована перевірка Рухомий аналіз небезпеки Розподілені по фазам розвитку Яке
- 76. Формальна перевірка: Підсумки Основні особливості: Аксіоми/правила для всіх мовних особливостей Ігнорувати деякі практичні питання: Розмір, ємність,
- 78. Скачать презентацию