- •Галузева система управління якістю методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення Отраслевая система управления качеством
- •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.9 Розроблення рекомендацій і звіту за результатами sfmeca
Остання колонка робочої таблиці повинна надавати відповідні коментарі, що роз'ясняють вхідні дані SFMECA. Коментарі містять:
будь-які незвичайні умови;
результати відмов надлишкових елементів;
розпізнавання особливо критичних особливостей проекту;
будь-які зауваження, що доповнюють вхідні дані;
посилання на інші вхідні дані для наступного аналізу відмови.
Рекомендації з удосконалення проекту реєструють та викладають у звіті за результатами SFMECA. Звіт за результатами SFMECA може включатися до більш широкого дослідження або може використовуватися окремо. Звіт повинен містити висновки та детальні описи аналізу. Висновки повинні включати короткий опис методу аналізу та рівня, на якому він проводився, допущення та основні принципи. Крім того, він повинен містити:
рекомендації для проектувальників, обслуговуючого персоналу та користувачів;
відмови, які за одиничної початкової появи призводять до серйозних результатів;
зміни у проекті, які вже було внесено за результатами виконання SFMECA.
5.7 Аналіз дерева відмов програмного забезпечення (sfta)
5.7.1 Загальні положення щодо аналізу дерева відмов програмного забезпечення
5.7.1.1 Аналіз дерева відмов ПЗ (SFTA – Software Fault Tree Analysis) застосовують для ідентифікації умов і факторів, що викликають або впливають на виникнення певної небажаної події, яка істотно впливає на роботу ПЗ і системи. SFTA є різновидом FTA (Fault Tree Analysis – аналіз дерева відмов). Дерево відмов є організованим графічним поданням умов або інших факторів, що викликають або впливають на виникнення певної небажаної події, так званої «кінцевої події».
5.7.1.2 Аналіз дерева відмов по своїй суті є дедуктивним методом аналізу, націленим на точне визначення причин або комбінацій причин, які можуть призвести до певної кінцевої події. Головним чином, проводять якісний аналіз, але залежно від деяких умов він може також бути кількісним.
Завданнями проведення SFTA є:
ідентифікація причин або комбінацій причин, що призводять до кінцевої події;
ідентифікація факторів, що впливають на надійність, безпеку, ефективність та інші робочі характеристики ПЗ і системи;
ідентифікація суперечливих вимог або специфікацій, які можуть вплинути на надійність, безпеку та інші робочі характеристики ПЗ і системи;
визначення того, чи відповідають характеристики ПЗ та системи встановленим вимогам;
демонстрація відповідності характеристик ПЗ та системи встановленим вимогам;
ідентифікація відмов із загальної причини (загальних подій).
5.7.1.3 Застосування SFTA є найбільш доцільним для аналізу ПЗ систем, що включають декілька функціонально пов'язаних або залежних підсистем з різними робочими характеристиками, а також для випадків, коли розроблення ПЗ та системи вимагає співробітництва декількох робочих груп.
5.7.2 Процедура виконання sfta
5.7.2.1 Процедура виконання sfta
Процедура виконання SFTA містить у собі наступні дії, які розглянуто нижче:
визначення області аналізу;
ознайомлення із проектом, функціями та роботою ПЗ і системи;
визначення кінцевої події;
побудова дерева відмов;
логічний і чисельний аналіз дерева відмов;
розроблення звіту про результати аналізу.
