• Лекція 12
• Роль атестації та верифікації в забезпеченні надійності програмного забезпечення протягом усього життєвого циклу
  • 12.1 Надійність (Reliability)
  • 12.2 U-видна крива (bathtub curve) розподілу помилок у жц обладнання
  • 12.3 Верифікація (Verification)
    • 12.3.1 Атестація/Валідація (Validation)
    • 12.3.2 Відмінність понять
  • 12.4 Надійність ПЗ протягом ЖЦ
    • 12.4.1 Характеристики надійності
  • 12.5 Забезпечення надійності в життєвому циклі ПЗ
    • 12.5.1 Прогнозування збоїв
    • 12.5.2 Матриця джерело/класифікація збоїв
• Рівень збоїв
• Дефекти проекту
• Дефекти кодування
• Адміністративні помилки
• Неадекватне відлагодження
• Помилки тестування
  • 12.5.3 Попередження збоїв
• 12.6 Усунення помилок та забезпечення стійкості
  • 12.6.1 Оцінювання в ході Verification & Validation (V&V)
• 12.7 V&V у життєвому циклі програми
• 12.8 Методи V&V
  • 12.8.1 Інспектування та тестування
• 12.9 Види тестування
  • 12.9.1 Модель процесу тестування ПЗ
• 12.10 Test-Driven Development (TDD)
• 12.11 Планування верифікації та атестації
  • 12.11.1 План верифікації та атестації

Лекція 12

Роль атестації та верифікації в забезпеченні надійності програмного забезпечення протягом усього життєвого циклу

12.1        Надійність (Reliability)

1. Здатність системи або компоненту виконувати необхідні функції в зазначених умовах у визначеному проміжку часу [ISO 24765]

2. Можливість програмного продукту підтримувати певний рівень продуктивності при використанні у визначених умовах [ISO 9126-1]

Надійність є важливим показником дл ПЗ.

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

Фактор, який в першу чергу впливає на надійність – складність ПЗ.

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

12.2        U-видна крива (bathtub curve) розподілу помилок у жц обладнання

Розподіл помилок протягом ЖЦ ПЗ демонструється U-видною кривою. ПЗ із часом не ломається, а просто виявляє помилки, яки були приховані раніше.

На ранній стадії (Early/Infant mortality period) відбувається зменшення рівня відмов. Показник зменшення відмов – DFR (decreasing failure rate).

Далі у нормальному періоді життя (також відомим як «період корисного використання» ) рівень відмов є низьким, відносно постійним – CFR (constant failure rate).

Наприкінці життєвого циклу (ЖЦ) продукту/обладнання спостерігається т.зв. період зношування (wear-out period), у якому рівень відмов зростає – IFR (increasing failure).

12.3        Верифікація (Verification)

1. Підтвердження шляхом надання об'єктивних доказів, що вказані вимоги були виконані. [ISO 12207: 2017].

2. Процес оцінки системи або компонента для визначення, чи відповідають результати даної фази розробки умовам, накладеним на початку цієї фази. [IEEE Std 1012-2016].

12.3.1        Атестація/Валідація (Validation)

1. 1. Підтвердження шляхом надання об'єктивних доказів, що вимоги щодо конкретного використання продукту були виконані. [ISO 15288: 2015].
2. 2. Процес надання доказів того, що ПЗ та пов'язані з ним продукти задовольняють системні вимоги, визначені наприкінці кожного етапу ЖЦ, правильно вирішують проблему і задовольняють потреби користувачів. [IEEE Std 1012-2016].
3. 3. Гарантія того, що продукт, послуга або система відповідає потребам замовника та інших зацікавлених сторін. [PMBOK® Guide].

12.3.2        Відмінність понять

Верифікація (verification)

«Чи правильно розроблений продукт?»

Атестація (validation) – процес контролю того, що ПЗ відповідає очікуванням замовника

«Чи правильний продукт розроблений?»

Приклад

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

12.4        Надійність ПЗ протягом ЖЦ

На рисунку нижче показана U-видна крива (Bathtub curve) для програмного забезпечення, яке розробляється ітеративно (від релізу до релізу). Випуск нової версії переводить продукт у ранню стадію ЖЦ.

12.4.1        Характеристики надійності

Зрілість (Maturity)

• • ступінь, до якого система, продукт або компонент задовольняє потреби в надійності при нормальній роботі

Доступність (Availability)

• • ступінь функціональності та доступності продукту або системи, коли вони повинні використовуватись

Стійкість до збоїв (Fault tolerance)

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

Відновлюваність (Recoverability)

• ступінь, до якого у випадку переривання або відмови продукт або система може відновити дані та потрібний стан системи

Методики забезпечення надійності

Теорія надійності визначає різні методики забезпечення надійності.

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

На етапах розробки застосовуються методики забезпечення стійкості до відмов.

На наступних слайдах ці методики будуть розглянуті детальніше.

Прогнозування

• • Моделі надійності, аналіз історичних даних

Попередження збоїв

• • Формальні методи, повторне використання ПЗ

Усунення помилок

• • Формальні інспекції, верифікація, атестація

Стійкість до відмов

• • Методики моніторингу, верифікація рішень, надлишковість, виключення

12.5        Забезпечення надійності в життєвому циклі ПЗ

12.5.1        Прогнозування збоїв

1. Визначення функціонального профілю

Відслідковування функцій щодо появи проблем

2. Визначення та класифікація помилок

За історичними данимикладається матриця джерело/класифікація збоїв

3. Ідентифікація потреб користувача щодо рівня надійності

Документуються в SyRS, повинні мати вимірні показники

4. Альтернітиви

За історичними даними аналізується ймовірність досягнення цілей

5. Визначення цілей щодо забезпечення надійності

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

12.5.2        Матриця джерело/класифікація збоїв

Помірний

Серйозний

Нестерпний

Інфекційний

Рівень збоїв	Дефекти проекту	Дефекти кодування	Адміністративні помилки	Неадекватне відлагодження	Помилки тестування
Слабкий
Дратівливий
Екстремальний
Катастрофічний

12.5.3        Попередження збоїв

Ітеративне уточнення SySR із моделюванням та перевіреними методиками розробки ПЗ.

Використовуються експертні оцінки та інспекційні перевірки.

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

12.6        Усунення помилок та забезпечення стійкості

Тестування на етапі розроблення – процеси Quality Assurance

Забезпечення стійкості до відмов на етапі введення в експлуатацію

12.6.1        Оцінювання в ході Verification & Validation (V&V)

Головна мета верифікації та атестації - упевнитися в тому, що система "відповідає своєму призначенню".

1. 1. Призначення ПЗ. Рівень достовірності відповідності залежить від того, наскільки критичним є розроблювальне програмне забезпечення з тих чи іншими критеріями. Наприклад, рівень достовірності для систем, критичних щодо забезпечення безпеки, має бути значно вищим аналогічного рівня достовірності для дослідних зразків програмних систем, що розробляються для демонстрації деяких нових ідей.
2. 2. Очікування користувачів. З початку 1990-х років терпимість користувачів до відмов у роботі програмних систем поступово знижується. Останнім часом створення ненадійних систем стало практично неприйнятним, тому компаніям, що займаються розробкою програмних продуктів, необхідно все більше уваги приділяти верифікації та атестації програмного забезпечення.
3. 3. Умови ринку програмних продуктів. При оцінці програмної системи продавець повинен знати конкуруючі системи, ціну, яку покупець згоден заплатити за систему, і призначений термін виходу цієї системи на ринок. Якщо у компанії-розробника кілька конкурентів, необхідно визначити дату виходу системи на ринок до закінчення повного тестування і налагодження, інакше першими на ринку можуть виявитися конкуренти. Якщо покупці не бажають здобувати ПЗ за високою ціною, можливо, вони згодні терпіти більшу кількість відмов у роботі системи. При визначенні видатків на процес верифікації та атестації необхідно враховувати всі ці фактори.

Планування V&V

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

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

Дану модель іноді називають V-моделлю (щоб побачити букву V, необхідно повернути рис. на 90 °). На цій схемі також показано поділ процесу верифікації та атестації на кілька етапів, причому на кожному етапі виконуються відповідні тести.

12.7        V&V у життєвому циклі програми

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

12.8        Методи V&V

Статичні методи

• • Інспектування

  • Автоматичний аналіз коду та документів

Динамічні методи

• • Тестування

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

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

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

12.8.1        Інспектування та тестування

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

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

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

Переваги інспектування

• на усіх етапах проекту

• виявляє > 60% помилок

• оцінює якісні хар-ки систем: відповідність стандартам, зручність супроводу …

У системних компонентах виявлення помилок шляхом інспектування більш ефективно, ніж шляхом тестування:

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

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

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

Інспектування формалізоване

• невелика група (≈ 4 ос.)

• у кожного своя роль:

автор

рецензент - «озвучує» програмний код

інспектор - перевіряє код

координатор - організує процес

Групи інспектування повинні бути малими, де у кожного учасника є своя роль.

Обов'язково повинні бути присутніми: автор, рецензент, інспектор, координатор. Рецензент «озвучує» програмний код, інспектор перевіряє його, координатор відповідає за організацію процесу.

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

Для початку процесу інспектування програми необхідно виконати наступні умови:

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

• члени інспекційної групи повинні добре знати стандарти розробки;

• в розпорядженні групи повинна бути синтаксично коректна остання версія програми (немає сенсу розглядати код, який «майже завершений»).

12.9        Види тестування

Незважаючи на широке застосування інспектування ПЗ, переважаючим методом верифікації залишається тестування.

Тестування виконується на етапі реалізації системи (для перевірки відповідності системи очікуванням розробників) і після завершення її реалізації.

На різних етапах процесу розробки ПЗ застосовують різні види тестування.

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

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

12.9.1        Модель процесу тестування ПЗ

Зазвичай ПЗ для комерційного застосування повинно пройти 3 етапи тестування:

1. 1. Тестування розробки (Development testing) - система тестується під час розробки для виявлення помилок та дефектів. В процесі тестування зазвичай задіяні проектувальники та програмісти системи.
2. 2. Тестування випуску (Release testing) - група тестувальників випробовує повну версію системи до її випуску для користувачів. Мета тестування випуску - перевірити, чи відповідає система вимогам зацікавлених сторін системи.
3. 3. Тестування користувачем (User testing) - користувачі або потенційні користувачі системи тестують систему у власному середовищі. Що стосується програмних продуктів, "користувач" може бути внутрішньою маркетинговою групою, яка вирішує, чи можна продавати, випускати та продавати програмне забезпечення. Серед типів тестування користувачів часто виділяють тестування для прийняття (Acceptance testing) - це один із типів, коли замовник формально тестує систему, щоб вирішити, чи слід її прийняти від постачальника системи чи необхідна подальша розробка.

12.10        Test-Driven Development (TDD)

Етапи процесу Test-driven development (TDD):

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

12.11        Планування верифікації та атестації

• визначається співвідношення між статичними і динамічними методами перевірки системи.

• визначаються стандарти і процедури інспектування та тестування ПЗ

• затверджується технологічну карта перевірок програм.

• складається план перевірки програми (увага на стандарти процесу тестування).

12.11.1        План верифікації та атестації

• надає технічному персоналу повну картину випробувань системи.

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

План випробувань ПЗ обов'язково повинен включати в себе:

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

• тестовані елементи (слід визначити всі «вихідні» продукти процесу розробки ПЗ, які необхідно тестувати),

• графік тестування (складається часовий графік тестування і розподіл ресурсів проводиться згідно з цим графіком, причому графік тестування прив'язаний до більш загального графіком розробки проекту),

• процедури запису тестів (для перевірки правильності виконання тестів),

• апаратні і програмні вимоги, обмеження (спробувати передбачити всі несприятливі фактори, що впливають на процеси тестування, наприклад, брак коштів, персоналу ...).

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