НАДІЙНІСТЬ (RELIABILITY)

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

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

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

користувача.

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

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

U-ВИДНА КРИВА (BATHTUB CURVE)

РОЗПОДІЛУ ПОМИЛОК У ЖЦ ОБЛАДНАННЯ

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

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

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

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

failure).

The Bathtub Curve and Product Failure Behavior Part One - The Bathtub Curve, Infant Mortality and Burn-in. https://www.weibull.com/hotwire/issue21/hottopics21.htm

The Bathtub Curve and Product Failure Behavior Part Two - Normal Life and Wear-Out. https://www.weibull.com/hotwire/issue22/hottopics22.htm

ВЕРИФІКАЦІЯ (VERIFICATION)

1. підтвердження шляхом надання об'єктивних доказів, що вказані вимоги були виконані. [ISO 12207: 2017]
2. процес оцінки системи або компонента для визначення, чи відповідають результати даної фази розробки умовам, накладеним на початку цієї фази. [IEEE Std 1012-2016]

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

продукт потребам замовника (атестація/валідація).

Термін Верифікація визначений як у міжнародному стандарті (ISO 12207: 2017), так і у галузевому (IEEE Std 1012-2016).

• верифікація відповідає на питання, чи правильно створена система;
• атестація (валідація) відповідає на питання, чи правильно працює система.

АТЕСТАЦІЯ/ВАЛІДАЦІЯ (VALIDATION)

У контексті ЖЦ комплекс заходів для забезпечення впевненості у тому, що система здатна виконувати передбачуване використання, цілі та завдання. (ISO 12207:

2008)

Атестація розглядає більш широке питання – чи забезпечує продукт потреби замовника.

Важливість атестації підтверджується і тим, що її процеси розглядаються у кількох міжнародних (ISO 12207: 2008, ISO 15288: 2015) та галузевих стандартах (IEEE Std

1012-2016, PMBOK® Guide).

ВІДМІННІСТЬ ПОНЯТЬ

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

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

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

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

Верифікація перевіряє відповідність ПО системної специфікації, зокрема функціональним і нефункціональним вимогам

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

• тестування програми;
• проведення випробування обладнання.

Атестація проводиться після верифікації

Приклад

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

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

переводить продукт у ранню стадію ЖЦ.

НАДІЙНІСТЬ ПЗ ПРОТЯГОМ ЖЦ

ХАРАКТЕРИСТИКИ НАДІЙНОСТІ

МЕТОДИКИ ЗАБЕЗПЕЧЕННЯ НАДІЙНОСТ

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

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

використанню компонентів.

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

ЗАБЕЗПЕЧЕННЯ НАДІЙНОСТІ В ЖИТТЄВОМУ ЦИКЛІ ПЗ

На даному слайді умовно показано застосування методик забезпечення надійності у ЖЦ ПЗ.

ПРОГНОЗУВАННЯ ЗБОЇВ

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

МАТРИЦЯ ДЖЕРЕЛО/КЛАСИФІКАЦІЯ ЗБОЇВ

ПОПЕРЕДЖЕННЯ ЗБОЇВ

• Ітеративне уточнення SySR із моделюванням та перевіреними методиками розробки ПЗ
• Використовуються експертні оцінки та інспекційні перевірки
• Повторне використання модулів прискорює розробку, але може бути джерелом прихованих дефектів

УСУНЕННЯ ПОМИЛОК ТА ЗАБЕЗПЕЧЕННЯ СТІЙКОСТІ

• Тестування на етапі розроблення – процеси Quality Assurance
• Забезпечення стійкості до відмов на етапі введення в експлуатацію

ОЦІНЮВАННЯ В ХОДІ VERIFICATION & VALIDATION (V&V)

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

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

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

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

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

ПЛАНУВАННЯ V&V

V&V У ЖИТТЄВОМУ ЦИКЛІ ПРОГРАМИ

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

Основна увага у плані приділяється стандартам процесу тестування, а не опису конкретних тестів. Цей план призначений не тільки для керівництва, він в основному

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

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

програмні засоби.

МЕТОДИ V&V

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

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

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

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

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

проекту. Дефектами є помилки у вихідному коді, або невідповідності програми стандартам.

Тестування ПЗ. Запуск виконуваного коду з тестовими даними і дослідження вихідних даних і робочих характеристик програмного продукта для перевірки

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

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

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

програма.

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

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

характеристик проводиться тестування системи.

ПЕРЕВАГИ ІНСПЕКТУВАННЯ

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

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

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

специфікації, але таким способом, наприклад, неможливо оцінити динамічну поведінку системи. Більше того, нераціонально інспектувати закінчені системи, зібрані з

декількох підсистем. На цьому рівні можливо тільки тестування.

ІНСПЕКТУВАННЯ ФОРМАЛІЗОВАНЕ

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

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

відповідає за організацію процесу.

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

кілька ролей, тому кількість членів у групі інспектування може варіюватися).

УМОВИ ДЛЯ ІНСПЕКТУВАННЯ

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

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

ВИДИ ТЕСТУВАННЯ

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

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

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

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

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

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

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

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

МОДЕЛЬ ПРОЦЕСУ ТЕСТУВАННЯ ПЗ

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

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

TEST-DRIVEN DEVELOPMENT (TDD)

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

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

ПЛАНУВАННЯ ВЕРИФІКАЦІЇ ТА АТЕСТАЦІЇ

• визначається співвідношення між статичними і динамічними методами перевірки системи
• визначаються стандарти і процедури інспектування та тестування ПЗ
• затверджується технологічну карта перевірок програм
• складається план перевірки програми (увага на стандарти процесу тестування)

ПЛАН ВЕРИФІКАЦІЇ ТА АТЕСТАЦІЇ

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

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

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

відповідальним за те, щоб у групи тестування були всі необхідні апаратні і програмні засоби.

СКЛАД ПЛАНУ

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

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

Подібно іншим планам, план випробувань не є незмінним документом. Його слід регулярно переглядати, так як тестування залежить від процесу реалізації системи.

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

використовувати співробітників (незайнятих в даний момент) на інших роботах.