- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •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.6.3.5 Ідентифікація видів, причин і впливу відмов
Для процедур ідентифікації видів, причин і впливу відмов їхня ефективність може бути підвищена шляхом підготовки відповідних списків відмов, очікуваних:
під час використання ПЗ;
у певному компоненті ПЗ ;
у певному режимі роботи;
за умови обмеження у часі;
за умови змін навколишнього середовища.
Визначення видів, причин і впливу відмов залежить від рівня аналізу. В міру просування аналізу причини відмови, ідентифіковані на більш високому рівні, можуть стати видами відмови на більш низькому рівні. Так само види відмови на більш низькому рівні можуть стати причинами відмови на більш високому рівні. Загальний список видів відмов наведено у таблиці 5.22. Можливі причини, пов'язані з кожним встановленим видом відмови, повинні бути ідентифіковані та описані. Причини кожного виду відмови ідентифікуються, щоб оцінити імовірність його виникнення, виявити вторинні ефекти та розробити рекомендаційні коригувальні дії. Тому що вид відмови може мати більш ніж одну причину, усі потенційні незалежні причини для кожного виду відмови повинні бути ідентифіковані та описані. Причини відмови у межах суміжних системних рівнів також повинні бути розглянуті.
Наслідки впливу кожного передбачуваного виду відмови на роботу ПЗ, функції, або стану ідентифікують, оцінюють та реєструють. Супровід і призначення системи також розглядають щоразу, коли це необхідно. Вплив відмови концентрується на аналізованій діаграмі на певному елементі, який порушується цією відмовою. Відмова може також впливати на наступному більш високому рівні. Вплив відмов на кожному більш високому рівні повинен бути оціненим. При цьому розглядають локальний і кінцевий впливи відмов. Локальний вплив вказує на вплив виду відмови на розглянутий компонент ПЗ. Наслідки кожної постульованої відмови на виході компонента описуються поряд із вторинними наслідками. Мета визначення локального впливу полягає у тому, щоб забезпечити підставу для ухвалення рішення під час оцінки існуючого альтернативного забезпечення або розроблення рекомендаційних коригувальних дій. В окремих випадках локальний вплив може не виникнути внаслідок самого виду відмови.
Під час ідентифікації кінцевої події вплив постульованої відмови на найвищому системному рівні визначають та оцінюють за допомогою аналізу усіх проміжних рівнів. Кінцевим описаним впливом може бути результат множинної відмови. Наприклад, відмова пристрою безпеки призводить до катастрофічного кінцевого наслідку тільки у випадку, коли відмовляють пристрої безпеки і основна функція, для якої розроблений пристрій безпеки, виходить за дозволені межі. Ці кінцеві події, що випливають із множинних відмов, вказують у робочих таблицях.
5.6.3.6 Ідентифікація методів виявлення відмов та їх ізолювання
Методи виявлення та ізолювання різних видів відмов повинні бути описані. Види відмов, які відрізняються від розглянутих та які призводять до ідентичних симптомів, повинні бути проаналізовані та враховані. Також повинна бути врахована необхідність окремого виявлення відмов надлишкових елементів протягом операції.