- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •1 Сфера застосування
- •2 Нормативні посилання
- •3 Терміни та визначення понять
- •3.2 Безпека програмного забезпечення
- •3.8 Життєвий цикл системи
- •3.9 Інструментальний засіб (case-інструмент)
- •3.10 Категорія критичності програмного забезпечення
- •3.15 Оцінювання якості програмного забезпечення
- •3.16 Показники (характеристики) якості програмного забезпечення
- •3.19 Програмно-технічний комплекс
- •4 Познаки та скорочення
- •3.13 Надійність програмного забезпечення
- •5 Методи оцінювання показників якості програмного забезпечення критичного призначення
- •5.1 Методи оцінювання показників якості програмного забезпечення
- •5.2 Інспекції процесів розроблення програмного забезпечення
- •5.3 Методи тестування програмного забезпечення
- •5.3.1 Загальні положення щодо тестування програмного забезпечення
- •5.3.2 Методи функціонального тестування програмного забезпечення
- •5.3.2.1 Загальні положення щодо функціонального тестування програмного забезпечення
- •5.3.2.2 Тестування транзакцій
- •5.3.2.3 Тестування областей вхідних даних
- •5.3.2.4 Тестування синтаксису
- •5.3.2.5 Тестування логічних умов
- •5.3.2.6 Тестування станів
- •5.3.3 Метод структурного тестування програмного забезпечення
- •5.3.3.1 Загальні положення щодо структурного тестування програмного забезпечення
- •5.3.3.2 Тестування маршрутів
- •5.3.3.3 Тестування циклів
- •5.3.3.4 Тестування обробки даних
- •5.4 Методи статичного аналізу програмного забезпечення
- •5.4.1 Загальні положення щодо статичного аналізу програмного забезпечення
- •5.4.2 Аналіз потоку управління
- •5.4.3 Аналіз потоку даних
- •5.4.4 Метрична оцінка програмного забезпечення
- •5.5 Метод імовірнісної оцінки надійності програмного забезпечення
- •5.5.1 Загальні положення щодо імовірнісної оцінки надійності програмного забезпечення
- •5.5.2 Оброблення статистичних даних про відмови програмного забезпечення
- •5.5.3 Визначення параметрів моделей надійності
- •5.5.3.3 Мнпз, їхні допущення та аналітичні співвідношення
- •5.5.3.4 Модель Джелінського–Моранді
- •5.5.3.5 Модель Гела–Окумото
- •5.5.3.6 Модель базова s-подібна
- •5.5.3.7 Модель Шика–Уолвертона
- •5.5.3.8 Перша геометрична модель Моранди
- •5.5.3.9 Модель Муси–Окумото
- •5.5.3.10 Метод максимуму правдоподібності
- •5.5.3.11 Метод найменших квадратів
- •5.5.3.12 Приклади застосування моделей надійності програмного забезпечення
- •5.5.3.12.2 Оцінка показників надійності за допомогою мнпз, описаних у 5.5.3.4-5.5.3.9.
- •5.5.3.12.3 Модель Джелінського-Моранді
- •5.5.3.12.4 Модель Гела-Окумото
- •5.5.3.12.5 Базова s-подібна модель
- •5.5.3.12.6 Модель Шика-Уолвертона
- •5.5.3.12.7 Перша геометрична модель Моранді
- •5.5.3.12.8 Модель Муси-Окумото
- •5.5.4 Вибір моделі надійності програмного забезпечення
- •5.5.4.3 Критерій Колмогорова-Смирнова
- •5.5.4.4 Критерій 2
- •5.5.4.5 Критерій мінімального сумарного квадратичного відхилення:
- •5.5.5 Прогнозування показників надійності програмного забезпечення
- •5.6 Аналіз видів, наслідків і критичності відмов програмного забезпечення (sfmeca)
- •5.6.1 Загальні положення щодо аналізу видів, наслідків і критичності відмов
- •5.6.2 Основні принципи виконання sfmeca
- •5.6.2.1 Базування sfmeca
- •5.6.2.2 Визначення функціональної структури програмного забезпечення
- •5.6.2.3 Одержання вихідної інформації
- •5.6.2.4 Подання структури програмного забезпечення
- •5.6.2.5 Ідентифікація видів відмов
- •5.6.2.6 Аналіз відмов із загальної причини
- •5.6.2.7 Аналіз критичності
- •5.6.2.8 Зв'язок між sfmeca та іншими методами
- •5.6.3 Процедура виконання sfmeca
- •5.6.3.1 Процедура виконання sfmeca
- •5.6.3.2 Визначення вимог до програмного забезпечення
- •5.6.3.3 Розроблення діаграм, схем та інших математичних моделей і описів
- •5.6.3.4 Вибір рівнів програмного забезпечення і документації
- •5.6.3.5 Ідентифікація видів, причин і впливу відмов
- •5.6.3.6 Ідентифікація методів виявлення відмов та їх ізолювання
- •5.6.3.7 Опис значення відмов та альтернативних запобіжних заходів
- •5.6.3.8 Оцінка критичності та імовірності відмов
- •5.6.3.9 Розроблення рекомендацій і звіту за результатами sfmeca
- •5.7 Аналіз дерева відмов програмного забезпечення (sfta)
- •5.7.1 Загальні положення щодо аналізу дерева відмов програмного забезпечення
- •5.7.2 Процедура виконання sfta
- •5.7.2.1 Процедура виконання sfta
- •5.7.2.2 Визначення області аналізу
- •5.7.2.3 Ознайомлення з проектом, функціями і роботою програмного забезпечення
- •5.7.2.4 Визначення кінцевої події
- •5.7.2.5 Побудова дерева відмов
- •5.7.2.6 Логічний і чисельний аналіз дерева відмов
- •5.7.2.7 Розроблення звіту про результати аналізу
- •5.7.3 Умовні позначки для дерева відмов
- •5.8 Керівництво з адаптації нормативного документа
- •Додаток а
- •Бібліографія
5.7.2.6 Логічний і чисельний аналіз дерева відмов
Первинними цілями логічного (якісного) і чисельного (кількісного) аналізу дерева відмов є:
ідентифікація подій, які можуть безпосередньо викликати відмову ПЗ та системи, і визначення імовірності таких подій;
оцінка відмовостійкості ПЗ та системи (здатності функціонувати навіть після певної кількості відмов більш низького рівня або подій, які сприяють виникненню системної відмови);
перевірка незалежності відмов ПЗ та його компонентів;
оцінка даних, які визначають місцезнаходження критичних компонентів і механізмів відмови;
ідентифікація діагностування відмов, витрат на відновлення та стратегії супроводу.
Оцінка відмовостійкості системи включає визначення ступеня надмірності та перевірку того, що надмірність парирує відмови із загальної причини. Хоча головна частина оцінки відмовостійкості не вимагає використання числових даних, такі числові дані необхідні для оцінки комбінації подій, які з найбільшою імовірністю можуть викликати відмови.
Для логічного аналізу використовують три основні методи:
дослідження;
булеве скорочення;
визначення мінімального перетину.
Дослідження включає огляд структури дерева відмов, ідентифікацію загальних подій і пошук незалежних гілок. Дослідження забезпечує аналітика важливою інформацією, яка у деяких випадках може бути достатньою та виключає потребу у подальших дослідженнях. В усіх інших випадках дослідження є необхідним для ухвалення правильного рішення про види та ступінь подальших досліджень. Безпосередній візуальний аналіз побудованого дерева є можливим тільки для маленьких дерев, що містять не більше 70 подій. Дослідження більших дерев, виходячи з результатів аналізу фактичних систем, вимагає відповідних інструментальних засобів, але в цілому підхід залишається таким самим. Дослідження починається з огляду структури дерева відмов. Усі події, пов'язані з кінцевою подією безперервним ланцюжком зв'язків «АБО», є подіями, які викликають виникнення кінцевої події. Тому, якщо дерево відмов складається тільки зі зв'язків «АБО», подальший аналіз не потрібен. Якщо дерево відмов включає інші типи логічних зв'язків, аналізована система містить у собі деяку надмірність або інші засоби запобігання відмов, які внаслідок подій із загальної причини можуть стати недійсними. Дослідження повинно ідентифікувати події із загальної причини, але не повинно припускати, що їхня присутність не є шкідливою. Такі висновки може бути зроблено тільки після повного аналізу з використанням булевого скорочення або визначення мінімальних перетинів. Оскільки складність аналізу зростає разом з розміром дерева відмов, дослідження дозволяє ідентифікувати, які гілки дерева відмов є незалежними та можуть бути проаналізовані окремо.
Булеве скорочення використовують для оцінки впливу загальних подій (ідентичних подій, що відбуваються на різних гілках) у дереві відмов, де виникнення кінцевої події не залежить від вибору часу або послідовності подій. Булеве скорочення може бути виконане шляхом вирішення булевих рівнянь для дерева відмов. У дереві відмов, що складається тільки з логічних елементів «І», «АБО» та «НЕ», присутня взаємо-однозначна відповідність між булевим алгебраїчним виразом і представленням дерева відмов. Наприклад, для дерева відмов на рисунку 5.23, записують:
C = D E ; (5.61)
A = B C = B (D E) = B D B E. (5.62)
Набір зв'язків (перетинів) – це група подій, які, відбуваючись разом, можуть призвести до виникнення кінцевої події. Мінімальний перетин (мінімальна множина зв'язків) – це найменша група, в якій усі події повинні відбутися для виникнення кінцевої події. Якщо одна з подій у мінімальному перетині не відбувається, то кінцева подія теж не відбудеться. Якщо послідовність подій є істотною для настання кінцевої події, вплив послідовності подій може бути проаналізованим за допомогою додаткової діаграми станів. Вираз для кінцевої події може бути записаним у термінах мінімального перетину. Загальну форму представляють як
T = M1 + M2 +…+Мi +…+Mn, (5.63)
де T – кінцева подія,
Мi – мінімальні перетини. Кожний мінімальний перетин складається з комбінації певних відмов, і загальна мінімальна множина зв'язків може бути виражена як
M = X1 + X2 +…+Xi+…+Xn, (5.64)
де Xi – кількість зв’язків у мінімальному перетині.
Для дерева відмов на рисунку 5.24 мінімальними перетинами кінцевої події є B D та B E.
Мета кількісного аналізу полягає у тому, щоб забезпечити визначення імовірності виникнення кінцевої події або обраної множини подій. Кількісний аналіз також використовують для підтримки та доповнення логічного аналізу. Щоб виконати кількісну оцінку дерева відмов, необхідна наявність імовірнісних даних на рівні елементів. Для встановлення кількісних значень можуть використовуватися методи прогнозування надійності, статистичні випробування або дані з експлуатації.