- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •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.7 Розроблення звіту про результати аналізу
Результати аналізу повинні бути задокументовані таким чином, щоб вони могли бути переглянуті та модифіковані з обліком будь-яких необхідних змін проекту, процедур експлуатації або вдосконалення розуміння природи відмов.
Звіт про результати SFTA повинен включати:
а) мету та область аналізу;
б)опис системи та ПЗ:
1) опис проекту;
2) опис роботи ПЗ і системи;
3) опис меж ПЗ та системи;
в) допущення:
1) допущення щодо проекту;
2) допущення щодо експлуатації, супроводу, випробувань та експертизи;
3) допущення щодо моделювання надійності та безпеки;
г) визначення та критерії відмови;
д) аналіз дерева відмов:
1) опис процедур виконання аналізу;
2) похідні дані;
3) використані символи;
е) результати та висновки.
До звіту про результати SFTA додатково можуть бути включені:
блоки–схеми ПЗ;
чисельні значення метрик ПЗ;
опис дерева відмов у форматі, придатному для автоматизованого оброблення за допомогою комп'ютера.
5.7.3 Умовні позначки для дерева відмов
5.7.3.1 Кожна подія на дереві відмов повинна бути однозначно визначена. Події повинні бути марковані так, щоб могло бути встановлене посилання дерева відмов на відповідну проектну документацію. Необхідно, щоб тільки єдина кінцева подія могла бути пов'язана з цим деревом. Якщо кілька подій на дереві відмов відносяться до різних видів відмов одного елемента, такі події повинні бути відзначені таким чином, щоб їх можна було відрізнити. У той же час повинно бути ясно, що вони є групою подій, пов'язаних з тим самим елементом.
5.7.3.2 Якщо конкретна подія виникає на дереві відмов у декількох випадках, або, якщо це відбувається у декількох деревах, то всі такі події повинні мати однакове марковання. Однак, події, які є подібними, але які впливають на різні елементи, не повинні мати тієї ж ідентифікації. Код типової події повинен містити інформацію щодо ідентифікації системи, ідентифікації компонентів і виду відмови.
5.7.3.2 Кожний елемент дерева відмов повинен мати одну вихідну подію та одну або більше вхідних подій. Вхідні події ідентифікують можливі причини та умови виникнення вихідних подій. Однак, такий зв'язок не обов'язково визначає послідовні (часові) відносини між подіями. Основне дерево відмов використовує елементи «І», «АБО» та «НЕ». Однак, для аналізу складних систем можуть знадобитися додаткові логічні символи. Для побудови дерева відмов повинна використовуватися відповідна символіка та ідентифікація, для з'ясування, за необхідністі того, що:
подію або цілу гілку також використовують в іншому місці на дереві;
зображена частина дерева включає події, які використовують також в іншій частині дерева;
подія із загальної причини, яка показана в одній частині дерева, далі розроблена в іншому місці.
Далі у таблиці 5.24 представлено перелік стандартизованих символів, які використовують для побудови дерев відмов. Символи надані відповідно до [13].
Таблиця 5.24—Символи, які використовують на діаграмах дерев відмов
Символ |
Альтернативний символ |
Назва символу |
Опис |
|
|
Елемент «І» |
Подія відбудеться тільки, якщо усі вхідні події відбудуться одночасно |
|
|
Елемент «АБО» |
Подія відбудеться, якщо відбудеться одна із вхідних подій або відбудеться будь-яка комбінація вхідних подій |
|
|
Елемент «Виключаюче АБО» |
Подія відбудеться, якщо відбудеться тільки одна із вхідних подій |
|
|
Елемент «НЕ» |
Подія представляє умову, що є інверсною стосовно вхідної події |
|
|
Резервована структура |
Подія відбудеться, якщо принаймні відбудуться m з n вхідних подій |
|
|
Загальний елемент |
Загальний символ для введення додаткових елементів (якщо це необхідно) |
|
– |
Елемент затримки |
Подія відбудеться тільки, якщо вхідна подія відбудеться за умови формування вихідної події |
|
– |
Блок опису елемента |
Ім'я, код, опис або імовірність події |
Кінець таблиці 5.24
Символ |
Альтернативний символ |
Назва символу |
Опис |
|
– |
Базова подія |
Подія, що не може бути розділена |
|
– |
Нерозглянута подія |
Подія, яка не розглядається через відсутність такої необхідності |
|
– |
Подія, розглянута на іншому дереві відмов |
Подія, що буде розглянута на іншому дереві відмов |
|
– |
Обов'язкова подія |
Подія, що відбулася або обов'язково відбудеться |
|
– |
Неймовірна подія |
Подія, що не може відбутися |
|
– |
Перехід у дерево відмов |
Подія визначена в іншому місці дерева відмов |
|
– |
Перехід з дерева відмов |
Повторювана подія, що використовується також у іншому місці |
