Дипломна робота

Вимоги до якості програмного забезпечення програмно-технічних
комплексів критичного призначення

ЗМІСТ
c.

TOC \w \x \f \t «Заг1;1;Заг2;2;Заг3;3» ВСТУП PAGEREF _Toc132688497
\h IV

1 СФЕРА ЗАСТОСУВАННЯ PAGEREF _Toc132688498 \h 1

2 НОРМАТИВНІ ПОСИЛАННЯ PAGEREF _Toc132688499 \h 2

3 ТЕРМІНИ ТА ВИЗНАЧЕННЯ ПОНЯТЬ PAGEREF _Toc132688500 \h 2

4 ПОЗНАКИ ТА СКОРОЧЕННЯ PAGEREF _Toc132688501 \h 8

5 ВИМОГИ ДО ЯКОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ПРОГРАМНО-ТЕХНІЧНИХ
КОМПЛЕКСІВ КРИТИЧНОГО ПРИЗНАЧЕННЯ PAGEREF _Toc132688502 \h 9

5.1 Класифікація програмного забезпечення програмно-технічних комплексів
PAGEREF _Toc132688503 \h 9

5.2 Модель якості та сфера її застосування PAGEREF _Toc132688504 \h
12

5.3 Структура моделі якості PAGEREF _Toc132688505 \h 12

5.3.1 Взаємодія частин моделі якості програмного забезпечення PAGEREF
_Toc132688506 \h 12

5.3.2 Якість програмного забезпечення та життєвий цикл PAGEREF
_Toc132688507 \h 13

5.3.3 Використання моделі якості PAGEREF _Toc132688508 \h 16

5.4 Застосування характеристик якості програмного забезпечення PAGEREF
_Toc132688509 \h 21

5.4.1 Описові характеристики PAGEREF _Toc132688510 \h 23

5.4.2 Кількісні характеристики PAGEREF _Toc132688511 \h 28

5.4.3 Якісні характеристики PAGEREF _Toc132688512 \h 36

5.4.4 Узгодженість PAGEREF _Toc132688513 \h 42

5.5 Метрики програмного забезпечення PAGEREF _Toc132688514 \h 42

5.5.1 Порядок вибору та встановлення метрик і шкал PAGEREF
_Toc132688515 \h 42

5.5.2 Перший етап PAGEREF _Toc132688516 \h 42

5.5.3 Характеристики якості споживачів PAGEREF _Toc132688517 \h 43

5.5.4 Другий етап PAGEREF _Toc132688518 \h 44

5.5.5 Зовнішні та внутрішні атрибути PAGEREF _Toc132688519 \h 45

5.5.6 Внутрішні метрики PAGEREF _Toc132688524 \h 47

5.5.7 Зовнішні метрики PAGEREF _Toc132688525 \h 47

5.5.8 Взаємозв’язок між внутрішніми та зовнішніми метриками PAGEREF
_Toc132688526 \h 48

5.5.9 Метрики якості у використанні PAGEREF _Toc132688527 \h 48

5.5.10 Вибір і використання метрик якості програмного забезпечення
PAGEREF _Toc132688528 \h 49

5.6 Положення щодо адаптації нормативного документа PAGEREF
_Toc132688529 \h 57

5.6.1 Мета розділу PAGEREF _Toc132688530 \h 57

5.6.2 Принципи адаптації PAGEREF _Toc132688531 \h 57

5.6.3 Відповідальність за адаптацію нормативного документа PAGEREF
_Toc132688532 \h 60

Додаток А Зовнішні метрики PAGEREF _Toc132688533 \h 61

Додаток Б Внутрішні метрики PAGEREF _Toc132688534 \h 82

ДОДАТОК В Метрики у використанні PAGEREF _Toc132688535 \h 106

ДОДАТОК Г Бібліографія PAGEREF _Toc132688536 \h 110

ВСТУП

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

безпосередньої реалізації бортових і наземних комп’ютерних систем

управління, контролю та оброблення інформації;

автоматизації проектування цих систем;

вирішення різних завдань, що пов’язані із забезпеченням якості на всіх

етапах життєвого циклу.

Надійність і безпека об’єктів космічної техніки (ОКТ) стають усе

більш залежними від якості ПЗ. Це пов’язано з:

збільшенням частки програмно реалізованих функцій у ПТК комп’ютерних
систем всіх сегментів ОКТ;

ускладненням завдань, що розв’язуються програмними засобами;

збільшенням імовірності відмов та аварій ОКТ, що обумовлені дефектами
ПЗ, які не виявлено при тестуванні та випробуваннях.

Необхідною умовою вирішення цих проблем є розроблення нормативної бази,
що визначає вимоги до якості програмного забезпечення
програмно-технічних комплексів (ПЗ ПТК) космічних систем, та методи
оцінювання виконання встановлених вимог.

Власне методи і оцінка якості у даному нормативному документі не
розглядаються. Цей документ визначає вимоги до якості ПЗ ПТК, які
використовуються в ОКТ, та відповідні показники і метрики. Ця настанова
відповідає вимогам національних стандартів ДСТУ і гармонізована з
наступними міжнародними стандартами:

ISO/IEC 9126-1:2001 Software Engineering – Product Quality – Part 1:
Quality model (Інжиніринг програмного забезпечення – Якість продукту –
Частина 1: Модель якості);

ISO/IEC TR 9126-2:2003 Software Engineering – Product Quality – Part 2:
External metrics (Інжиніринг програмного забезпечення – Якість продукту
– Частина 2: Зовнішні метрики);

ISO/IEC TR 9126-3:2003 Software Engineering – Product Quality – Part 3:
Internal metrics (Інжиніринг програмного забезпечення – Якість продукту
– Частина 3: Внутрішні метрики);

ISO/IEC TR 9126-4:2004 Software Engineering – Product Quality – Part 4:
Quality in use metric (Інжиніринг програмного забезпечення – Якість
продукту – Частина 4: Метрики якості у використанні);

ISO/IEC 14598-1:1999 Information technology – Software product
evaluation – Part 1: General (Інформаційні технології – Оцінювання
програмного продукту. Частина 1: Загальний огляд).

Додатки А, Б, В до настанови є обов’язковими.

Додаток Г до настанови є довідковим.

НАСТАНОВА НАЦІОНАЛЬНОГО КОСМІЧНОГО АГЕНТСТВА УКРАЇНИ

Галузева система управління якістю

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

ПРОГРАМНО-ТЕХНІЧНИХ КОМПЛЕКСІВ

КРИТИЧНОГО ПРИЗНАЧЕННЯ

Отраслевая система управления качеством

ТРЕБОВАНИЯ К КАЧЕСТВУ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРОГРАММНО-ТЕХНИЧЕСКИХ КОМПЛЕКСОВ

КРИТИЧЕСКОГО НАЗНАЧЕНИЯ

Чинна від 2006-09-01

1 СФЕРА ЗАСТОСУВАННЯ

Ця настанова установлює вимоги до якості програмного запезпечення
програмно-технічних комплексів (ПЗ ПТК), які використовуються при
розробленні, відпрацюванні та експлуатації об’єктів космічної техніки
(ОКТ) і космічних комплексів (КК) на підприємствах, що знаходяться у
сфері управління НКАУ.

Настанова може бути застосованою при розробленні ПЗ, що не поставляється
(інструментальне ПЗ), але впливає на якість ПЗ ПТК.

Видання офіційне

2 НОРМАТИВНІ ПОСИЛАННЯ

У цій настанові є посилання на такі нормативні документи:

ДСТУ 2850-94 Програмні засоби ЕОМ. Показники і методи оцінювання якості

ДСТУ 3918-1999 (ISO/IEC 12207:1995) Інформаційні технології: Процеси
життєвого циклу програмного забезпечення

ДСТУ 3919-1999 (ISO/IEC 14102:1995) Інформаційні технології: Основні
напрямки оцінювання та відбору CASE-інструментів

ДСТУ ISO/IEC 14764:2002 Інформаційні технології: Супроводження
програмного забезпечення

УРКТ-01.01 Правила космічної діяльності в Україні. Розробка,
виготовлення та експлуатація космічної техніки.

3 ТЕРМІНИ ТА ВИЗНАЧЕННЯ ПОНЯТЬ

Нижче подано терміни, вжиті у цій настанові, та визначення позначених
ними понять.

3.1 атрибут (attribute)

Фізична або абстрактна властивість ПЗ, яка може бути виміряною [7].

Примітка. В [7] термін “атрибут” (“attribute”) використовують у
значенні, еквівалентному синонімічному терміну “характеристика”
(“characteristic”), однак в [3] термін „характеристика” використовують в
більш специфічному значенні

3.2 валідація

Показник якості ПЗ, що сформований на основі оцінки одного або декількох
атрибутів ПЗ.

Підтвердження того, що окремі вимоги щодо визначеного передбаченого
використання виконуються, і які здійснюються шляхом перевірки та
забезпечення об’єктивних доказів [ДСТУ 3918]

3.3 верифікація

Підтвердження виконання заданих вимог, що здійснюється шляхом перевірки
та забезпечення об’єктивних доказів [ДСТУ 3918]

3.4 відмова із загальної причини

Множина відмов, що відносяться до загальної причини [8]

3.5 відмова ПЗ (softwarw failure)

Індикується метрикою стану системи та виникає у випадку використання
програм або даних з дефектом [8]

3.6 властивості ПЗ

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

Властивості ПЗ можуть бути базовими (загальними), характерними для цього
класа продукції, і специфічними, що є характерними тільки для окремого
виду програмного забезпечення. За ступенем впливу на якість ПЗ
розрізняють на суттєві та несуттєві властивості [ДСТУ 2850]

3.7 вимірювання (measurement)

Процес визначення кількісного або якісного (категорійного) значення
атрибутів об’єкту оцінювання [4]

3.8 гармонізація (harmonization)

Аналіз і формування несуперечливих вимог міжнародних і/або національних
стандартів, що розроблені різними організаціями та відповідають одному
нормативному профілю [9]

3.9 дефект ПЗ (software fault)

Вплив помилки у програмі або даних, який призводить до неадекватного
виконання програми, якщо ПЗ використано цей сегмент програм або даних
[8]

3.10 життєвий цикл системи

Весь період існування системи від початку розроблення до завершення її
використання [ДСТУ 3918]

3.11 збій ПЗ

Визначається тривалістю відновлення обчислювального процесу після
викривлення програми, даних або обчислювального процесу, що реєструються
як порушення працездатності. За тривалості відновлення менше заданого
порогу дефекти та аномалії при функціонуванні програм відносять до
збоїв, а за тривалостістю відновлення, що перевищує граничне значення,
викривлення, що відбувається, відносять до відмови [14]

3.12 критичне програмне забезпечення (safety critical software)

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

Наприклад, програмне забезпечення, яке:

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

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

– безпосередньо виконує управління і контроль за умовами або станом
апаратних компонентів, і його невиконання, непослідовне виконання або
виконання, пов’язане з помилками персоналу, апаратною відмовою або
відмовою внаслідок впливу навколишнього середовища може спричинити
небезпеку або може призвести до існування умов виникнення ризиків [10]

3.13 метрика (metric)

Кількісна (або якісна) оцінка ступеня, в якому програмне забезпечення
або процес відповідають заданим властивостям, а також шкала і метод
оцінювання виміру [4]

3.14 модель життєвого циклу

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

3.15 надійність ПЗ

Група властивостей, що обумовлює здатність ПЗ зберігати працездатність
та перетворювати вихідні дані в очікуваний результат у заданих умовах за
встановлений період часу [ДСТУ 2850]

3.16 об’єкт космічної техніки

Матеріальний предмет штучного походження, що проектується,
виготовляється та експлуатується як у космічному просторі (космічний
сегмент, космічна інфраструктура), так і на поверхні Землі (наземний
сегмент, наземна інфраструктура) з метою дослідження та використання
космічного простору [УРКТ-01.01]

3.17 оцінювання

Систематичне визначення ступеня відповідності об’єкту (сутності) заданим
для нього критеріям [ДСТУ 3918]

3.18 оцінювання якості конкретного ПЗ

Дії, спрямовані на визначення ступеня задоволення потреб ПЗ відповідно
до призначення [ДСТУ 2850]

3.19 показники (характеристики) якості програмного забезпечення

Набір властивостей (атрибутів) програмного забезпечення, за допомогою
яких його якість описується та оцінюється. Характеристики якості
програмного забезпечення можуть бути уточнені на безлічі рівнів
комплексних показників (підхарактеристик) [3]

3.20 помилка (error)

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

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

3.21 початкова подія (initiating event)

Порушення в роботі (відмова) системи, зовнішня подія або помилка
персоналу, які спричиняють порушення нормальної експлуатації і можуть
призвести до порушення меж і/або умов безпечної експлуатації [12]

3.22 програмне забезпечення (software)

Програми, процедури, правила, а також уся відповідна документація, що
відноситься до функціонування комп’ютерної системи [8]

3.23 програмно-технічний комплекс

Сукупність технічних засобів автоматизації, що постачаються в комплекті
з програмним забезпеченням, необхідним сервісним устаткуванням і
експлуатаційною документацією, що з’єднується на місці експлуатації з
периферійним устаткуванням і/або з іншими програмно-технічними
комплексами для виконання усіх або частини функцій контролю та
управління у складі конкретної інформаційної або керуючої системи [15]

3.24 космічний комплекс

Сукупність ракети або ракет космічного призначення з функціонально
взаємозв’язаними технічними засобами і спорудженнями, призначеними для
забезпечення транспортування, зберігання, приведення і утримання в
готовності, технічного обслуговування, транспортування, підготовки,
запуску і контролю польоту ракети космічного призначення на ділянці
виведення [УРКТ-01.01]

3.25 система критичного застосування

Система, відмова якої здатна призвести до катастрофічних наслідків для
людей і/або навколишнього середовища [11]

3.26 тестове програмне середовище

Сукупність програмних засобів, які забезпечують реалізацію процесу
тестування, введення тестових наборів, генерацію тестових даних,
введення очікуваних результатів, генерацію очікуваних результатів [13]

3.27 якість програмного забезпечення (ПЗ)

Сукупність властивостей ПЗ, що обумовлюють його придатність задовольняти
певні потреби відповідно до призначення [ДСТУ 2850]

3.28 характеристика, підхарактеристика

Аспекти продукту, за допомогою яких його описують або оцінюють.
Характеристика може зводитися до кількох рівнів підхарактеристик, які
спираються на її властивість задовольняти заявлені потреби або потреби,
що можуть виникнути [ДСТУ 3919].

4 ПОЗНАКИ ТА СКОРОЧЕННЯ

4.1 У цьому НД застосовано такі скорочення:

ЕОМ – електронна обчислювальна машина;

ЄСПД – єдина система програмної документації;

ЖЦ – життєвий цикл;

КК – космічний комплекс;

КТ – космічна техніка;

НД – нормативний документ;

НПЯ – номенклатура показників якості;

ОЗП – оперативний запом’ятовуючий пристрій;

ОКТ – об’єкт космічної техніки;

ПЗ – програмне забезпечення або програмні засоби;

ПЗ ПТК – програмне забезпечення програмно-технічних комплексів;

ПК – персональний комп’ютер;

ПТК – програмно-технічний комплекс;

ПЯ – показник якості;

РМД – радіальні метричні діаграми;

ТЗ – технічне завдання.

5 ВИМОГИ ДО ЯКОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ПРОГРАМНО-ТЕХНІЧНИХ
КОМПЛЕКСІВ КРИТИЧНОГО ПРИЗНАЧЕННЯ

5.1 Класифікація програмного забезпечення програмно-технічних комплексів

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

Треба ураховувати наступні ознаки класифікації ПЗ ПТК:

належність ПЗ ПТК до сегментів КК;

функціональне призначення;

ступінь апробованості;

вплив на безпеку.

За цими ознаками ПЗ ПТК утворюють класифікаційну схему, у якій окремі
групи типів ПЗ відносно незалежні. Стрілки між рівнями класифікації
вказують на комбінації типів ПЗ ПТК відповідно до [2] (рисунок 5.1).

5.1.2 За належністю розрізняють ПЗ ПТК:

пілотованих і безпілотних космічних апаратів;

ракет-носіїв;

пускових установок, наземного устаткування та споруд;

корисних вантажів;

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

5.1.3 За функціональним призначенням ПЗ ПТК класифікується на:

загальне (або системне);

прикладне (або функціональне);

технологічне (або інструментальне), що використовується при

розробленні, тестуванні та верифікації.

5.1.4 За ступенем апробованості розрізняють наступні типи ПЗ ПТК:

розроблене вперше;

існуюче (розроблене раніше або покупне комерційне);

що конфігурується з типових модулів.

5.1.5 За впливом на безпеку розрізняють:

ПЗ, що впливає на безпеку (критичне ПЗ);

ПЗ, що не впливає на безпеку.

5.1.6 Ознака „належність” визначає специфічні вимоги до ПЗ ПТК
космічних апаратів, ракет-носіїв, пускових установок, корисних вантажів
і відрізняється від вимог до безпеки ПЗ ПТК для експериментів і
моделювання.

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

Ознака „ступінь апробованості” визначає обсяг вимог до ПЗ за належністю
та призначенням.

Рисунок 5.1 – Класифікація ПЗ ПТК

5.2 Модель якості та сфера її застосування

5.2.1 Відповідно до стандарту [3] модель якості ПЗ складається із двох
частин:

внутрішня і зовнішня якість;

якість у використанні.

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

5.2.2 Характеристики якості можуть бути застосовані для будь-якого виду
ПЗ відповідно до наведеної в п.5.1 класифікації, включаючи комп’ютерні
програми та дані, що прошиті у постійному запам’ятовуючому пристрої.

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

5.3 Структура моделі якості

5.3.1 Взаємодія частин моделі якості програмного забезпечення

5.3.1.1 Якість у використанні повинна включати вимоги в конкретному
середовищі. Ці вимоги необхідно враховувати при оцінюванні внутрішньої
та зовнішньої якості, використовуючи характеристики та підхарактеристики
якості. Оцінювання ПЗ є складовою частиною процесів життєвого циклу.

5.3.1.2 Якість ПЗ може бути оцінена шляхом виміру внутрішніх атрибутів
(наприклад, статичного аналізу проміжних продуктів) або виміру зовнішніх
атрибутів (найчастіше виміром процесу виконання коду), або виміру
атрибутів якості у використанні.

5.3.1.3 Остаточною метою оцінювання ПЗ є одержання необхідних
результатів у конкретному середовищі використання (див. рисунок 5.2).

З рисунка 5.2 видно, що якість процесів (якість процесів життєвого циклу
визначено у ДСТУ 3918-1999 (ISO/IEC12207) впливає на якість продукту ПЗ,
а якість продукту ПЗ впливає на якість у використанні.

Рисунок 5.2 — Якість у життєвому циклі ПЗ

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

5.3.1.4 Вимоги до якості ПЗ повинні включати оціночні критерії для
внутрішньої якості, зовнішньої якості і якості у використанні для
задоволення потреб розробників, супровідників, покупців і користувачів.

5.3.2 Якість програмного забезпечення та життєвий цикл

5.3.2.1 Вимоги до якості ПЗ не можуть бути повністю визначені до початку
проектування.

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

Рисунок 5.3 — Взаємозв’язок між метриками якості програмного
забезпечення

5.3.2.2 Якість у використанні (розрахункова або прогнозована) ? це
якість, що оцінюється або прогнозується для готового ПЗ на кожній стадії
розроблення для кожної характеристики якості у використанні та
ґрунтується на результатах вимірів внутрішньої та зовнішньої якості.
Якість у використанні – це точка зору користувача на якість ПЗ під час
його використання в конкретному середовищі та конкретному контексті
використання. При цьому виміряються межі, у яких користувач може досягти
бажаних цілей у конкретному оточенні, а не властивість самого ПЗ. Рівень
якості в середовищі користувача може відрізнятися від рівня в середовищі
розробника через різницю в потребах і можливостях різних користувачів,
розходження апаратного та підтримуючого середовища.

Вимоги до якості у використанні повинні бути визначені за допомогою
метрик якості у використанні, зовнішніх метрик та іноді внутрішніх
метрик. Одержання продукту, що задовольняє потребам користувача, вимагає
ітеративного підходу до розроблення ПЗ з безперервним зворотнім
зв’язком.

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

Вимоги до зовнішньої якості визначають рівень вимог до якості із
зовнішньої точки зору на продукт. Вони містять вимоги, що походять із
вимог якості для користувача, включаючи вимоги до якості у використанні.

Вимоги до зовнішньої якості повинні бути:

встановлені у специфікації вимог до якості з використанням зовнішніх

метрик;

перетворені у вимоги до внутрішньої якості;

використані як критерії оцінювання продукту.

5.3.2.4 Внутрішня якість ? це набір характеристик ПЗ із внутрішньої
точки зору. Внутрішня якість вимірюється та оцінюється відповідно до
вимог до внутрішньої якості з використанням внутрішніх метрик. Якість
може бути поліпшена у процесі написання, перегляду та тестування коду.

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

5.3.3 Використання моделі якості

5.3.3.1 Якість ПЗ повинна оцінюватися з використанням моделі якості.
Модель якості визначають після розроблення вимог до якості готового ПЗ
та проміжного продукту і вона є сукупністю атрибутів якості ПЗ,
класифікованих в ієрархічну деревоподібну структуру характеристик і
підхарактеристик. Верхній рівень цієї структури складається з
характеристик якості, а нижній – з атрибутів якості ПЗ. Ця ієрархія не є
строгою, тому що деякі атрибути можуть входити більш ніж в одну
характеристику.

Стандарт [3] надає загальноцільові моделі внутрішньої та зовнішньої
якості і якості у використанні.

5.3.3.2 Модель внутрішньої та зовнішньої якості визначає шість основних
характеристик якості ПЗ: функціональність, надійність, зручність
використання, раціональність, супроводжуваність і переносимість (див.
рисунок 5.4).

Рисунок 5.4 – Модель якості ПЗ

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

– функціональна повнота (Suitability) – здатність ПЗ забезпечити
відповідний набір функцій для заданих завдань та цілей користувача;

– правильність (Accuracy) – здатність ПЗ забезпечувати вірні або
припустимі результати або дії з необхідним ступенем точності;

– здатність до взаємодії (Interoperability) – здатність ПЗ взаємодіяти
із зазначеними системами;

– захищеність (Security) – здатність ПЗ забезпечити захист інформації та
даних (при їхньому зберіганні і передачі) таким чином, що неавторизовані
користувачі та системи не будуть мати можливості до їх читання і
модифікації, у той час як авторизованим користувачам і системам не буде
відмовлено у доступі до них;

– узгодженість функціональності (Functionality Compliance) – здатність
ПЗ до дотримання відповідних стандартів, угод, положень законів або
подібних рекомендацій, що стосуються функціональності.

5.3.3.2.2 Надійність (Reliability) – група властивостей, що обумовлює
здатність програмного забезпечення зберігати працездатність та
перетворювати вихідні дані в очікуваний результат у заданих умовах за
встановлений час, включає наступні підхарактеристики:

– безвідмовність (Maturity) – здатність ПЗ уникати відмов
(функціонування без відмов), які є результатом наявності дефектів у ПЗ;

– стійкість до відхилень (Fault Tolerance) – здатність ПЗ підтримувати
необхідний рівень працездатності у випадках прояву програмних дефектів
або порушення його інтерфейсу;

– відновлюваність (Recoverability) – здатність ПЗ відновлювати заданий
рівень працездатності, а також відновлювати дані, які безпосередньо
ушкоджені у випадку виникнення відмови, після перезапуску ПЗ
(автоматичного або оператором);

– узгодженість надійності (Reliability Compliance) – здатність ПЗ
дотримуватись відповідних стандартів, угод, положень законів або
подібних рекомендацій, що стосуються надійності.

Примітка. Готовність (Availability) є комбінацією зрілості
(безвідмовності), та відновлюваності й тому не виділена як окрема
підхарактеристика надійності.

5.3.3.2.3 Зручність використання (Usability) – здатність ПЗ бути
зрозумілим, придатним до вивчання і привабливим для користувача при його
використанні в заданих умовах, включає наступні підхарактеристики:

– зрозумілість (Understandability) – здатність ПЗ забезпечити
користувачеві зрозумілість того, чи може ПЗ бути використано і яким саме
чином, для конкретних завдань і умов застосування;

– придатність до вивчання – здатність ПЗ до надання користувачеві
можливості його вивчення;

–зручність інтерфейсу для користування (Operability) – здатність ПЗ до
надання користувачеві можливості управління та контролю за його роботою;

– привабливість (Attractiveness) – здатність ПЗ бути привабливим для
користувача (відноситься до графічного інтерфейсу);

– узгодженість використання (Usability Compliance) – здатність ПЗ до
дотримання відповідних стандартів, угод, положень законів або подібних
рекомендацій, що стосуються використання.

5.3.3.2.4 Раціональність (Efficiency) – здатність ПЗ забезпечувати
відповідну (допустиму) продуктивність із урахуванням займаних ресурсів у
заданих умовах, включає наступні підхарактеристики:

– часова раціональність (Time Behavior) – здатність ПЗ забезпечити
відповідний (допустимий) час відгуку, оброблення та пропускну здатність
при виконанні його функцій у заданих умовах;

– використовуваність ресурсів (Resource Utilization) – здатність ПЗ
використовувати відповідну (допустиму) кількість і тип ресурсів при
виконанні його функцій у заданих умовах;

– узгодженість раціональності (Efficiency Compliance) – здатність ПЗ до
дотримання відповідних стандартів або подібних рекомендацій, що
стосуються ефективності.

5.3.3.2.5 Супроводжуваність (Maintainability) – здатність ПЗ до
модифікації, що може містити у собі виправлення, поліпшення або
адаптацію ПЗ до змін середовища, вимог або функціональних специфікацій,
включає наступні підхарактеристики:

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

– змінюваність (Changeability) – здатність ПЗ до надання можливості для
виконання заданої модифікації його коду, структури та алгоритмів або
програмної документації;

– стабільність (Stability) – здатність ПЗ до запобігання неочікуваних
ефектів від модифікацій;

– тестопридатність (Testability) – здатність ПЗ до валідації його змін
(модифікацій);

– узгодженість супроводжуваності (Maintainability Compliance) –
здатність ПЗ до дотримання відповідних стандартів або подібних
рекомендацій, що стосуються супроводжуваності.

5.3.3.2.6 Переносимість (Portability) – здатність ПЗ бути перенесеним з
одного організаційного, апаратного або програмного середовища в інше,
включає наступні підхарактеристики:

– адаптованість (Adaptability) – здатність ПЗ бути адаптованим до різних
середовищ без застосування дій або засобів, відмінних від тих, що
передбачено для цієї мети в розглянутому ПЗ. Адаптованість містить у
собі масштабованість внутрішніх елементів ПЗ (екранних полів, таблиць,
форматів звітів тощо);

– налагоджуваність (Installability) – здатність ПЗ до інсталяції в
заданому середовищі;

– сумісність (безконфліктність) (Coexistence) – здатність ПЗ без
конфліктів співіснувати з іншим незалежним програмним забезпеченням у
загальному середовищі, що спільно використовує загальні ресурси;

– взаємозамінність (Replaceability) – здатність ПЗ до використання
замість іншого заданого ПЗ з тією ж метою та у тому ж середовищі;

– узгодженість переносимості (Portability Compliance) – здатність ПЗ до
дотримання відповідних стандартів або подібних рекомендацій, що
стосуються переносимості.

5.3.3.3 Модель якості у використанні визначає наступні чотири
характеристики (рисунок 5.5):

Рисунок 5.5 — Модель якості у використанні

5.3.3.3.1 Ефективність (Effectiveness) – здатність програмного
забезпечення дозволяти користувачеві досягати зазначених цілей з
точністю та повнотою в заданому контексті використання.

5.3.3.3.2 Продуктивність (Productivity) – здатність програмного
забезпечення дозволяти користувачеві витрачати відповідну кількість
ресурсів щодо ефективності, досягнутої в заданому контексті
використання.

5.3.3.3.3 Безпека (Safety) – здатність програмного забезпечення
досягати прийнятних рівнів ризику шкоди людям, бізнесу, ПЗ, майну або
навколишньому середовищу в заданому контексті використання.

5.3.3.3.4 Задоволеність (Satisfaction) – здатність програмного
забезпечення задовольняти користувачів у заданому контексті
використання.

5.4 Застосування характеристик якості програмного забезпечення

Для цілей вибору та застосування характеристик (показників) якості ПЗ,
що представлені у розділі 5.3, їх необхідно класифікувати за типами на:

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

кількісні, які можна виміряти та чисельно зіставити з вимогами;

якісні, які визначають експертним методом.

Схеми класифікації характеристик наведено на рисунках 5.6-5.7.

Рисунок 5.6 — Класифікація характеристик внутрішньої та зовнішньої
якості ПЗ

Рисунок 5.7 — Класифікація характеристик якості у використанні

5.4.1 Описові характеристики

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

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

5.4.1.1.1 Функціональна повнота – це набір і описи підхарактеристик і
атрибутів, що визначають призначення, номенклатуру, основні, необхідні
та достатні функції ПЗ, задані технічним завданням і специфікаціями
вимог замовника або потенційного користувача. У процесі проектування ПЗ
атрибути придатності повинні конкретизуватися в специфікаціях на
компоненти та на ПЗ в цілому.

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

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

5.4.1.1.2 Правильність – це здатність ПЗ забезпечити правильні або
придатні результати для користувачів. Вимогами до правильності можуть
бути верифіковані та взаємопов’язані вимоги до функцій ПЗ, компонентів і
модулів програм, а також правила їх структурного побудування,
організація взаємодії та інтерфейсів. Ці вимоги при розробленні повинні
бути простежені зверху до низу модулів та використовуватися як еталони
при встановленні необхідної правильності відповідних компонентів.

Вимоги до підхарактеристики „правильність” можуть зображуватися у виді
опису двох основних властивостей, яким повинні відповідати всі програмні
компоненти та ПЗ в цілому.

Перша вимога складається з виконання певного ступеню (%) відстежуваності
зверху донизу реалізації вимог технічного завдання та специфікації на ПЗ
при послідовній деталізації описів програмних компонентів до самих
текстів та об’єктного коду програм.

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

5.4.1.1.3 Здатність до взаємодії.

Із цим показником пов’язані правильність і уніфікованість міжмодульних
інтерфейсів, які визначаються двома видами зв’язків: за управлінням та
за інформацією. Зв’язки за управлінням становлять виклики програмних
модулів та повернення до модулів, які викликали. Обмін модулів
інформацією може відбуватися через обмінні змінні, що їх безпосередньо
підготували сусідні модулі, або через глобальні змінні між більшими
компонентами. Різноманітність та складність інформаційних зв’язків у
великих програмних засобах значно ускладнюють формалізацію та вимір
досягнутої правильності взаємодії програм.

5.4.1.1.4 Захищеність.

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

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

Вимоги до якості ПЗ ПТК критичного застосування за показником
“захищеність” повинні складатися з вимог:

а) до запобігання помилок персоналу;

б) до захисту від несанкціонованого доступу, і містити наступні основні
положення:

1) ПЗ ПТК повинно бути спроектовано так, щоб зводити до мінімуму
можливість прийняття помилкових рішень і запобігати небажаним наслідкам
помилкових дій;

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

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

4) повинні застосовуватися конструктивні рішення, що запобігають
можливості помилок при заміні елементів ПТК; використане при цьому
маркування повинно бути добре помітним і однозначно зрозумілим для
персоналу;

5) повинен бути передбачений захист від несанкціонованого доступу до
компонентів ПЗ ПТК, ліній зв’язку і даних з метою запобігання можливості
їх навмисної або ненавмисної зміни;

6) об’єктами захисту від несанкціонованого доступу повинні бути:

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

– комутаційні елементи для підключення зовнішніх ланцюгів;

– змінні складові частини, які розташовані усередині ПТК;

– органи ручного управління (вимикачі електроживлення, перемикачі
режимів роботи, засоби виведення з роботи резервованих каналів тощо);

– засоби ручного введення і виведення даних з носіїв (клавіатури,
дисководи тощо.);

– програмне забезпечення на носіях, які установлені у ПТК і перебувають
у сховищах;

7) для захисту від несанкціонованого доступу повинні бути розглянуті:

– організаційні рішення (наприклад, обмеження доступу в приміщення
сторонніх осіб);

–фізичний захист (наприклад, замки, пломби, спеціальні сітки);

– програмні методи (установка паролів, розміщення програм і даних у
захищених від запису областях пам’яті, засоби контролю цілісності даних,
засоби реєстрації подій, що відбуваються, засоби архівації і
резервування даних, механізми захисту при обміні та передачі даних
тощо);

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

–програмно-апаратні методи (пристрої ідентифікації і аутентифікації
користувачів, розмежування їх повноважень за доступом до інформації).

5.4.2 Кількісні характеристики

Відповідно до класифікації, яку наведено на рисунку 5.6, до другого типу
стандартизованих характеристик якості ПЗ відносять надійність і
раціональність. Значення цих характеристик впливають на функціональність
ПЗ. Вибір та обґрунтування необхідних значень повинні проводитися при
системному проектуванні ПЗ. Підхарактеристики показників надійності та
ефективності можуть бути описані вимірюваними значеннями, які повинні
бути встановлені та обрані замовниками і користувачами ПЗ. Надійність
оцінюють напрацюванням на відмову, імовірністю відмови (прояву
дефектів), середнім часом відновлення тощо.

5.4.2.1 Ці величини повинні вибиратися та фіксуватися у технічному
завданні або специфікації вимог і супроводжуватися методикою їх
чисельних вимірів при випробуваннях. Для кожної з них повинно бути
встановлено допустимий розкид чисельних значень і необхідна точність
вимірювання. Рекомендовані одиниці вимірювання і шкали характеристик та
підхарактеристик надійності викладено в таблиці 5.1.

Таблиця 5.1 – Значення підхарактеристик надійності

Характеристики якості надійності Одиниця виміру Шкала

Безвідмовність:

— напрацювання на відмову за відсутності рестарту

Години

10-1000

Стійкість до відхилень:

— напрацювання на відмову за наявності автоматичного рестарту;

— відносні ресурси на забезпечення надійності рестарту

Години

%

10-1000

10-90

Відновлюваність:

— тривалість відновлення

Хвилини

10-2 – 10

5.4.2.2 При застосуванні понять надійності до програмного забезпечення
треба враховувати:

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

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

для підвищення надійності комплексів програм особливе значення

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

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

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

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

5.4.2.2.1 Безвідмовність

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

5.4.2.2.2 Стійкість до відхилень

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

5.4.2.2.3 Відновлюваність

Після відмови ПЗ іноді буває непрацездатним протягом деякого періоду
часу, тривалість якого визначається його відновлюваністю. Основним
показником процесу відновлення є тривалість відновлення та його
імовірнісні характеристики. Відновлюваність характеризується також
повнотою відновлення нормального функціонування програм у процесі їх
ручного або автоматичного перезапуску — рестарту. Перезапуск повинен
забезпечувати поновлення нормального функціонування ПЗ, на що потрібні
ресурси ЕОМ та час. Тому повнота та тривалість відновлення
функціонування після збоїв і відмов визначає надійність ПЗ та можливість
його використання за прямим призначенням.

5.4.2.2.4 Для забезпечення надійності ПЗ ПТК критичного застосування в
технічних вимогах необхідно дотримуватися принципа одиничної відмови,
резервування, незалежності, різноманітності, захисту від відмов з
загальної причини.

5.4.2.2.4.1 Принцип одиничної відмови

ПЗ ПТК повинні виконувати задані функції при будь-якій передбаченій
вихідній події та при незалежній від вихідної події відмові одного з їх
елементів.

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

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

5.4.2.2.4.2 Принцип резервування

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

Для ПЗ ПТК, що виконують критичні функції, у технічному завданні
необхідно навести наступні вимоги:

– у складі ПТК повинні бути, як мінімум, два незалежних комплекти
апаратури;

– кожний комплект апаратури повинен бути реалізованим на основі
мажоритарної логіки, що призначається, виходячи із вимог до надійності,
заданих у ТЗ (мінімальна мажоритарність – «два з трьох»);

– керуючі сигнали (команди захисних дій) кожного комплекту повинні
передаватися до виконавчих елементів, як мінімум по двох незалежних
лініях зв’язку.

5.4.2.2.4.3 Принцип незалежності

ПЗ ПТК критичного застосування повинно зберігати здатність до виконання
заданих функцій при відмові або виведенні з конфігурації будь-якого
зарезервованого каналу ПТК або будь-якої пов’язаної з ними системи.

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

5.4.2.2.4.4 Принцип різноманітності

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

Дотримання принципу різноманітності передбачає розходження:

– алгоритмів виконання однієї і тієї ж функції;

– програм, що реалізують відповідний алгоритм, наприклад, створених з
використанням різних мов, різних засобів програмування, різними
розробниками тощо;

– технічних засобів реалізації функцій, наприклад, заснованих на різних

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

5.4.2.2.4.5 Вимоги до захисту від відмов із загальної причини

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

Як одиничні події або причини, здатні викликати відмову із загальної
причини, розглядають:

відмова елементів ПТК;

дефекти ПЗ;

помилки персоналу при експлуатації;

вплив аномальних природних явищ (землетрус, удари блискавок тощо);

відхилення умов експлуатації (температура, тиск, вологість, параметри
електроживлення) у місцях розташування ПТК.

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

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

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

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

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

Для ПЗ ПТК критичного застосування повинно бути:

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

– визначено наслідки прояву дефектів ПЗ;

– передбачено необхідні програмні засоби для виключення відмов із
загальної причини або зменшення їх наслідків до прийнятного рівня;

– проведено аналіз впливу такого ПЗ на безпеку, задокументовані
результати аналізу та вжито заходів.

5.4.2.3 Значення одиниць виміру і шкал характеристики “раціональність”
та її підхарактеристик викладено в таблиці 5.2

Таблиця 5.2 – Значення характеристик раціональності

Характеристики якості Одиниця виміру Шкала

Раціональність

Часова раціональність

– час відгуку — одержання результатів на типове завдання;

– пропускна здатність — число типових завдань, що виконуються за одиницю
часу

Секунди

Число за хвилину

0,1-1000

1-1000

Використовуваність ресурсів:

– відносна величина використання ресурсів ЕОМ при нормальному
функціонуванні ПЗ

Імовірність

0,7 — 0,99

5.4.2.3.1 Часова раціональність ПЗ визначається тривалістю виконання
заданих функцій. Вона залежить від швидкості оброблення даних, що
впливає безпосередньо на інтервал часу завершення конкретного
обчислювального процесу та від пропускної здатності, тобто від числа
завдань, які можна реалізувати на даній ЕОМ у заданому інтервалі часу.
Ці показники якості тісно пов’язані з часом реакції (відгуку) ПЗ на
запити при вирішенні основних, функціональних завдань. Величина цього
часу залежить від тривалості вирішення завдань центральним процесором
ЕОМ, від витрат часу на обмін із зовнішньою пам’яттю, на
введення-виведення даних і від тривалості очікування в черзі до початку
вирішення завдання. Цей показник тісно пов’язаний із тривалістю
оброблення типового запиту або з інтервалом часу вирішення типових або
найбільш частих функціональних завдань ПЗ. Пропускна здатність комплексу
програм на конкретній ЕОМ відображається числом повідомлень або запитів
на вирішення певних завдань, які обробляються за одиницю часу, що
залежить від характеристик зовнішнього середовища. Вона залежить від
функціонального змісту ПЗ та його конструктивної реалізації, тим самим
може розглядатися як один із внутрішніх показників якості програм.
Декомпозицію цього критерію доцільно проводити, орієнтуючись на
конкретні функції ПЗ та особливості його архітектури.

5.4.2.3.2 Використовуваність ресурсів показує кількість і ступінь
зайнятості ресурсів центрального процесора, оперативної, зовнішньої та
віртуальної пам’яті, каналів введення-виведення, терміналів і каналів
локальної мережі. Цей критерій визначається структурою та функціями ПЗ,
а також архітектурними особливостями і доступними ресурсами ЕОМ. Залежно
від конкретних особливостей ПЗ та ЕОМ при виборі критеріїв може
домінувати або величина абсолютної зайнятості ресурсів різних видів, або
відносна величина використання ресурсів кожного виду при нормальному
функціонуванні ПЗ. Ресурсна ефективність визначає принципову можливість
повноцінного функціонування ПЗ в умовах реально обмежених обчислювальних
ресурсів.

5.4.3 Якісні характеристики

Відповідно до класифікації, яку наведено на рисунку 5.6, третій тип
характеристик якості ПЗ – зручність використання, супроводжуваність та
переносимість, в основному, виражають якісними оцінками. Для багатьох
атрибутів цього типу характеристик доводиться застосовувати порядкові
міри експертних бальних шкал з невеликим числом (2-4) градацій. У
таблиці 5.3 наведено приклади можливих одиниць виміру і шкал основних
метрик підхарактеристик та їх атрибутів якості. Вони можуть бути
орієнтирами при виборі та установленні необхідних значень цих показників
якості в специфікаціях ПЗ.

Таблиця 5.3 – Значення характеристик: зручність використання,
супроводжуваність і переносимість

Характеристики якості Одиниця виміру Шкала

Зручність використання

Зрозумілість:

чіткість концепції ПЗ;

демонстраційні можливості;

наочність і повнота документації

Порядкова

Відмінно, гарно, задовільно,

незадовільно

Зручність інтерфейса для користування:

простота управління функціями;

комфортність експлуатації;

середній час уведення завдань;

середній час відгуку на завдання

Порядкова

Секунди

Секунди

Секунди

Відмінно, гарно, задовільно,

незадовільно

1-1000

1-1000

1-1000

Придатність до вивчення:

( трудомісткість вивчення застосування ПЗ;

Люд.-година

1-1000

тривалість вивчення; Година 1-1000

( обсяг експлуатаційної документації; Сторінки 1-1000

обсяг електронних підручників Кбайти 1-1000

Привабливість:

суб’єктивні або експертні оцінки

Порядкова

Відмінно, гарно, задовільно,

незадовільно

Супроводжуваність

Аналізованість:

стрункість архітектури програм;

уніфікованість інтерфейсів;

( повнота та коректність документації

Порядкова

Відмінно, гарно, задовільно,

незадовільно

Кінець таблиці 5.3

Характеристики якості Одиниця виміру Шкала

Змінюваність:

трудомісткість підготовки змін;

тривалість підготовки змін

Люд.-година

Година

1-1000

1-1000

Стабільність:

( стійкість до негативних проявів при змінах

Порядкова

Відмінно, гарно, задовільно,

незадовільно

Тестопридатність:

трудомісткість тестування змін;

тривалість тестування змін

Люд.-година

Година

1-1000

1-1000

Переносимість

Адаптованість:

трудомісткість адаптації;

тривалість адаптації

Люд.-година

Година

1-100

1-100

Налагоджуваність:

трудомісткість інсталяції;

тривалість інсталяції

Люд.-година

Година

1-100

1-100

Сумісність:

( стандартизація інтерфейсів з апаратним та операційним середовищем

Порядкова

Відмінно, гарно, задовільно,

незадовільно

Взаємозамінність:

( трудомісткість заміни компонентів;

тривалість заміни компонентів

Люд.-година

Година

1-100

1-100

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

5.4.3.1.1 Зрозумілість залежить від якості документації та первинних
вражень від характеристик ПЗ.

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

5.4.3.1.2 Зручність інтерфейсу для користування

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

5.4.3.1.3 Придатність до вивчення визначається трудомісткістю та
тривалістю підготовки користувача до повноцінної експлуатації ПЗ. Ці
атрибути залежать від можливості попереднього навчання і удосконалювання
у процесі експлуатації, від можливостей оперативної допомоги і підказки
при використанні ПЗ, а також від повноти, доступності та зручності
використання керівних документів та інструкцій з експлуатації.
Придатність до вивчення може також характеризуватись обсягом (числом
сторінок) експлуатаційної документації й/або обсягом (Кбайт) електронних
підручників.

5.4.3.1.4 Привабливість є пов’язаною із зовнішніми атрибутами оформлення
ПЗ та експлуатаційної документації, що спричиняють більшу або меншу його
привабливість для користувача.

5.4.3.2 Супроводжуваність за ДСТУ ISO/IEC 14764:2002 визначається
внутрішніми характеристиками якості комплексу програм, які відбиваються
на зовнішній якості і якості у використанні, а також на складності
управління конфігурацією ПЗ.

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

5.4.3.2.2 Змінюваність включає кодування, проектування та документування
змін. Для цього потрібні певні зусилля та час, що пов’язані з
виправленням дефектів і/або модернізацією функцій, а також зі зміною
умов експлуатації. В оцінюванні цієї підхарактеристики враховуються
вплив структури, інтерфейсів і технічних особливостей ПЗ та не
розглядаються впливи великих, принципових змін його функцій. Якщо ПЗ
повинен модифікувати кінцевий користувач, змінюваність може бути
передумовою та частиною простоти використання.

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

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

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

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

5.4.3.3.3 Налагоджуваність повинна встановлюватися кінцевим
користувачем. Легкість установки є передумовою зручності використання.
Так як і адаптованість, її виміряють трудомісткістю та тривалістю
процедур установки, а також ступенем задоволення вимог замовника і
користувача.

5.4.3.3.4 Сумісність залежить від ступеня стандартизації інтерфейсів ПЗ
з операційним і апаратним середовищем застосування. Сумісність оцінюють
експертно.

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

5.4.4 Узгодженість

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

функціями, сферою застосування та захистом ПЗ;

надійністю;

раціональністю використання обчислювальних ресурсів і часу
функціонування ПЗ;

взаємодією з користувачем;

супроводом і конфігураційним управлінням;

забезпеченням переносимості програм.

5.5 Метрики програмного забезпечення

5.5.1 Порядок вибору та встановлення метрик і шкал

Процеси вибору та встановлення метрик і шкал для опису показників якості
ПЗ розділяють на два етапи:

вибір та обґрунтування вихідних даних, що характеризують загальні
особливості і етапи ЖЦ проекту ПЗ та його споживачів, кожний з яких
впливає на певні характеристики якості комплексу програм;

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

5.5.2 Перший етап

На першому етапі як основу використовують всю базову номенклатуру
характеристик і підхарактеристик, що стандартизовані в [3]. Їх опис
попередньо впорядковують за пріоритетами з урахуванням сфери
застосування проекту ПЗ. Далі необхідно виділити та ранжирувати за
пріоритетами споживачів, яким необхідні певні показники якості
конкретного проекту ПЗ з урахуванням їх спеціалізації та професійних
інтересів. Широка номенклатура характеристик, яку надано в стандарті
[3], підтримує різноманітні вимоги, з яких треба вибирати необхідні з
позиції споживачів цих даних. Споживачів, для яких є необхідним вибір і
встановлення показників якості ПЗ, поділяють на групи:

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

замовники, які вимагають оцінювати ПЗ насамперед за значеннями критеріїв
для зовнішніх мір функціональних можливостей, надійності, зручності та
раціональності, що задані у специфікації вимог і визначають загальну
сферу застосування ПЗ;

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

особи, відповідальні за реалізацію ПЗ в різних апаратних та операційних
середовищах, зацікавлені оцінювати ПЗ, використовуючи метрики
переносимості;

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

5.5.3 Характеристики якості споживачів

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

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

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

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

5.5.4 Другий етап

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

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

5.5.5 Зовнішні та внутрішні атрибути

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

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

Внутрішні атрибути виступають як індикатори зовнішніх атрибутів.
Внутрішній атрибут може впливати на одну або більше характеристик, і
характеристика може підпадати під вплив більш, ніж одного атрибута (див.
рисунок 5.8).

Рисунок 5.8 — Характеристики якості, підхарактеристики і атрибути

Підхарактеристики повинні вимірюватися або внутрішніми, або зовнішніми
метриками.

Взаємозв’язок між внутрішніми атрибутами та зовнішніми вимірами ніколи
не буде строгим, і дія, яка впливає на внутрішній атрибут відповідно до
зовнішнього виміру, визначається досвідом і залежить від конкретного
середовища використання ПЗ ( рис. 5.9).

середовище

використання

Рисунок 5.9 — Взаємодія між типами метрик

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

5.5.6 Внутрішні метрики

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

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

5.5.7 Зовнішні метрики

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

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

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

5.5.8 Взаємозв’язок між внутрішніми та зовнішніми метриками

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

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

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

Для прогнозування значень метрик рекомендовано застосовувати внутрішні
метрики, максимально зв’язані з атрибутами, із зовнішніми метриками.

5.5.9 Метрики якості у використанні

До вимог якості у використанні повинні додаватися метрики якості у
використанні, зовнішні метрики та іноді внутрішні метрики.

Якість у використанні – це точка зору користувача на якість системи, що
містить ПЗ. Вона вимірюється у термінах результату використання ПЗ, а не
властивостей якості самого ПЗ. Якість у використанні – це спільний
результат реалізації вимог внутрішньої та зовнішньої якості для
користувача.

Вплив характеристик якості ПЗ на якість у використанні залежить від типу
користувача:

– кінцевий користувач, для якого якість у використанні характеризується
функціональністю, надійністю, використовуваністю, ефективністю;

– користувач, що супроводжує ПЗ, для якого якість у використанні
характеризується ремонтноздатністю;

– користувач, що встановлює ПЗ, для якого якість у використанні
характеризується переносимістю.

5.5.10 Вибір і використання метрик якості програмного забезпечення

Способи вибору та використання метрик містять у собі послідовні
реалізації наступних процедур:

а) визначення цільових характеристик якості ПЗ;

б) визначення складу метрик, що оцінюють цільові характеристики якості
ПЗ;

в) підготовка до оцінювання:

1) завдання цільових значень і шкал допусків;

2) завдання вагових коефіцієнтів (рейтингів) і правил згортки;

3) визначення необхідної програмної документації та складу вхідних
параметрів для розрахунку метрик;

4) уточнення фактичного складу метрик, що використовуються;

г) оцінювання вхідних параметрів і розрахунок метрик;

д) аналіз результатів оцінювання:

1) узагальнення результатів оцінювання, побудова і згортка радіальних
метричних діаграм;

2) порівняння розрахованих значень із заданими цільовими значеннями;

3) аналіз фактичної повноти та імовірності оцінювання;

4) формування експертного висновку за результатами оцінювання.

5.5.10.1 Підстава для вибору метрик

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

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

– користувач або група користувачів оцінюють якість ПЗ за допомогою
метрик якості у використанні;

– замовник оцінює якість ПЗ за значеннями атрибутів характеристик
зовнішньої якості: функціональності, надійності, використовуваності та
ефективності або характеристик якості у використанні за допомогою
відповідних метрик;

– супроводжуючий ПЗ оцінює продукт, використовуючи метрики
ремонтноздатності;

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

– розробник оцінює якість ПЗ за значеннями атрибутів характеристик
якості, використовуючи внутрішні метрики.

5.5.10.2 Визначення складу метрик

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

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

Відпрацювання використання додаткових метрик повинно проводитися за
необхідності розширення оцінки.

Базовий набір метрик якості (зовнішньої, внутрішньої та якості у
використанні) і способи обчислень метрик якості та джерела вхідних даних
для виміру викладено у додатках А, Б, В.

Розширений перелік метрик за необхідності може бути визначено на основі
стандартів [4, 5, 6], (див. додаток Г).

5.5.10.3 Підготовка до оцінювання

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

5.5.10.3.1 Завдання цільових значень і шкал допусків

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

Приклад:

Метрика «Функціональна відповідність»:

діапазон можливих значень: [0…1], чим ближче до 1, тим краще;

цільове значення:

— кількісне — 0,85;

— якісне—«відповідає повністю»;

якісна шкала допусків:

— «відповідає повністю» — [0,7…1];

— «відповідає частково» — [0,3…0,6];

— «не відповідає» — [0…0,2].

5.5.10.3.2 Завдання вагових коефіцієнтів (рейтингів) і правил згортки

Для узагальнення результатів метричного оцінювання, визначення рівня
якості ПЗ та одержання інтегральних оцінок за характеристиками і
підхарактеристиками якості необхідно задати правила для згортки
(інтеграції) оцінених значень метрик.

Основним типом згортки є адитивна згортка, при якій кожна
підхарактеристика якості ПЗ виражається середнім зваженим арифметичним
показником з урахуванням значень метрик, що оцінюють цю
підхарактеристику, та коефіцієнтів їхньої вагомості, які визначають за
формулою (1):

, (1)

N

де ?i – ваговий коефіцієнт i-ої метрики Meti, ? ?i=1;

i=1

N — кількість метрик, з використанням яких виконується
оцінювання підхарактеристики Sch.

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

, (2)

де Ri – рейтінг метрики.

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

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

У результаті виконання завдань 5.5.10.3.3 та 5.5.10.3.4 формують і
заповнюють шаблон, зміст якого наведено у таблиці 5.4.

Таблиця 5.4

Якість ПЗ

Характериc-тика якості

Підхарактериc-тика якості

Метрика

Рейтинг

(коефіцієнт

вагомості) Цільове значення Шкала допусків

якіc-не кіль-кісне “відпо-відає повніс-тю” “відпо-відає частко-во” “не
відпо-відає”

Якість ПЗ Функціональ-ність

Функціональна повнота

Функціональна відповідність

Повнота функціональної реалізації

Функціональна стабільність

Правильність Адекватність поводження ПЗ

… … …

5.5.10.3.3 Визначення необхідної програмної документації та складу
вхідних параметрів для розрахунку метрик

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

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

Таблиця 5.5

Метрика Значення метрики Параметр для розрахунку Значення параметра
Програмна документація

Функціональна відповідність

А-кількість функцій, у яких виявлені дефекти

Звіти експертизи і верифікації

В-кількість функцій, що описані у специфікації

Вимоги специфікації

5.5.10.3.4 Уточнення фактичного складу метрик, які використовуються

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

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

5.5.10.4 Оцінювання вхідних параметрів і розрахунок метрик

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

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

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

Таблиця 5.6

Якість ПЗ

Характеристика якості

Підхарактерис-тики якості

Метрика Розраховане значення Цільове значення Дефіцит якості

якісне кіль-кісне якісне кіль-кісне

Якість ПЗ

Функціональність

Функціональна повнота

Функціональна відповідність

Повнота функціональної реалізації

Функціональна стабільність

Правильність Адекватність поводження ПЗ

… … …

5.5.10.5 Аналіз результатів оцінювання

5.5.10.5.1 Узагальнення результатів оцінювання, побудова і згортка
радіальних метричних діаграм

свою чергу, згортаються в РМД якості верхнього рівня (див. рисунок
5.10).

Рисунок 5.10 – Приклад згортки РМД

5.5.10.5.2 Порівняння розрахованих значень із заданими цільовими
значеннями

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

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

5.5.10.5.3 Аналіз фактичної повноти та імовірності оцінювання

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

Card (Msch’)

L = ??i , (3)

i = 1

Card (Meti’)

Di = ?wi,j , (4)

j= 1

де ?i- – ваговий коефіцієнт i-ої подхарактеристики Schi ? MSch’ ;

MSch’ – підмножина підхарактеристик якості, за якими було розраховано
хоча б одну метрику;

wi,j– ваговий коефіцієнт метрики metij ? Mmeti’;

MMeti ‘– безліч дійсно розрахованих метрик, придатних для оцінювання
підхарактеристики i-ої Schi .

Показники L і Di є частковими показниками якості експертизи, у той час
як загальний показник якості експертизи з урахуванням (3) і (4)
оцінюють:

Card (MSch’) Card (MMeti’)

QE = ??ij ? ?wi,j , (5)

i= 1 j= 1

де QE – загальний показник якості експертизи.

5.5.10.5.4 Формування експертного висновку за результатами оцінювання

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

5.6 Положення щодо адаптації нормативного документа

5.6.1 Мета розділу

Метою цього розділу є надання користувачеві посібника з адаптації
настанови до вимог конкретного проекту ПЗ ПТК.

Мета адаптації – вибір, модифікація, додавання/видалення вимог для того,
щоб досягти оптимального співвідношення між вимогами до якості і
досягнутих проектних характеристик. Адаптація може бути виконана шляхом
видалення вимог, обмеження застосованості, задання нових вимог з
урахуванням забезпечення надійності та безпеки, якості продукту та
конкретних параметрів. Адаптацію настанови, як правило, проводять та
відображують у технічному завданні (ТЗ) на розроблення ПЗ на етапах його
розроблення, погодження і затвердження.

5.6.2 Принципи адаптації

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

5.6.2.1 Технічні фактори

До технічних факторів належать:

– новизна розроблення;

– складність ПЗ ПТК;

– рівень критичності;

– вплив на безпеку;

– розміри ПЗ;

– наявність вимог до повторного використання ПЗ, що розроблюється;

– рівень використання готових комерційних компонентів або існуючого ПЗ;

– рівень стабільності вимог користувача.

5.6.2.2 Експлуатаційні фактори

До експлуатаційних факторів належать:

належність ПЗ (наприклад, безпілотні або пілотовані апарати, пускові

установки, корисні вантажі, експерименти);

кількість потенційних користувачів ПЗ;

критичність ПЗ, що вимірюється в наслідок його відмови;

передбачуваний час життя ПЗ;

кількість обчислювальних систем, у яких ПЗ буде використовуватися;

обмеження по режимах роботи, технічній підтримці, переносу в інше

середовище та вилученню з використання.

5.6.2.3 Фактори управління

До факторів управління належать:

необхідні на розроблення ПЗ обсяги робіт і часу;

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

прийнятний для проекту рівень ризику;

тип моделі життєвого циклу;

вимоги графіка поставки ПЗ;

кількість людей, необхідних для розроблення, підтримки та експлуатації
ПЗ;

складність організаційної структури підприємства-постачальника;

фінансові ресурси.

Для кожного конкретного проекту можуть використовуватися додаткові
фактори.

5.6.2.4 Адаптація нормативного документа може бути виконана на основі
анкетування вимог до проекту.

Приблизний перелік питань при анкетуванні може бути таким:

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

у чому полягає складність проекту: у визначенні вимог або в
проектуванні;

який рівень підтвердження правильності (валідації) необхідний? Чи
повинен продукт відповідати всім вимогам на момент поставки або
розробляється прототип продукту, що буде уточнюватися на наступних
етапах розроблення;

який рівень верифікації необхідний? Чи необхідно верифікувати ПЗ

після кожного етапу його життєвого циклу;

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

чи є ПЗ критичним;

які вимоги до безпеки.

Для кожного конкретного проекту наведений лист опитування може бути
доповненим.

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

5.6.3 Відповідальність за адаптацію нормативного документа

Адаптація цієї настанови є завданням замовника та постачальника. При
підготовці запрошень на тендер замовник повинен запропонувати адаптовану
версію нормативного документа як вказівку застосованого для проекту
рівня проектування ПЗ. Деякі фактори адаптації (такі, як критичність,
деталізована складність проектування тощо) стають відомими тільки після
підписання контракту і можуть бути уточнені в процесі розроблення. У
зв’язку із цим постачальник теж повинен брати участь у процесі
адаптації.

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

Додаток А

(обов’язковий)

Зовнішні метрики

А.1 Метрики функціональності

Таблиця А.1.1 –Метрики придатності

Номер пункту Назва

метрики Призначення метрики Формула та метод обчислення Інтерпретація
Джерело вхідних даних для вимірів

А.1.1.1 Функціональна відповідність

(Functional adequacy) Наскільки функції ПЗ відповідають специфікаціям
X=1-A/B,

де A-кількість функцій, у яких

виявлені дефекти;

B-кількість функцій, описаних

у специфікації 0<=X<=1 Чим ближче до «1», тим краще Вимоги специфікацій. Звіт експертизи або верифікації А.1.1.2 Повнота функціональної реалізації (Functional implementation completeness) В якому об’ємі реалізована функціональність ПЗ X=1-A/B, де A- кількість нереалізованих функцій; B- кількість функцій, описаних у специфікації 0<=X<=1 Чим ближче до «1», тим краще Вимоги специфікацій. Звіт експертизи або верифікації А.1.1.3 Функціональна стабільність (Functional specification stability) Наскільки стабільні функціональні специфікації після закінчення основного етапу розроблення ПЗ X=1-A/B, де A- кількість функцій, що вимагають зміни за результатами виконання верифікації та експертизи; B- кількість функцій, описаних у специфікації 0<=X<=1 Чим ближче до «1», тим краще Вимоги специфікацій. Звіт експертизи або верифікації Таблиця А.1.2 – Метрики правильності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.1.2.1 Адекватність поводження ПЗ (Accuracy to expecta-tion) Чи існують відмін-ності між дійсним і очікуваним поводженням ПЗ Х=А/Т, де А- кількість випадків не- адекватного поводження ПЗ; Т- час функціонування ПЗ 0<=X Чим ближче до "0", тим краще Посібник користувача. Звіт експертизи або верифікації А.1.2.2 Правильність обчислень (Computational accuracy) Наскільки часто ПЗ видає неправильний результат Х=А/Т, де А-кількість випадків не- правильних обчислень; Т- час функціонування ПЗ 0<=X Чим ближче до "0", тим краще Вимоги специфікацій. Звіт про тестування (експертизи або верифікації) А.1.2. 3 Точність обчислень (Precision) Наскільки часто ПЗ видає результат з точністю, відмінною від необхідної Х=А/Т, де А- кількість випадків обчислень із точністю, відмінною від необхідної; Т- час функціонування ПЗ 0<=X Чим ближче до "0", тим краще Вимоги специфікацій. Звіт про тестування (експертизи або верифікації) Таблиця А.1.3 – Метрики здатності до взаємодії Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.1.3.1 Обмін даними (Data exchangeability) Наскільки коректно виконується перетворення форматів вхідних/ вихідних даних Х=А/В, де А- кількість успішно перетворених форматів даних; В-кількість підтримуваних форматів вхідних/вихідних даних відповідно до специфікацій 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт експертизи або верифікації Таблиця А.1.4 Метрики захищеності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.1.4.1 Реєстрованість доступу (Access audit ability) Чи реалізовано і в якому об’ємі аудит доступу до системи та даних Визначаються експертним методом або за формулою: Х=А/В, де А- кількість зафіксованих у базі даних випадків доступу до системи або даних; В- кількість фактичних випадків доступу до системи або даних 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт про тесту-вання (експертизи або верифікації) Кінець таблиці А.1.4 Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.1.4.2 Контрольованість доступу (Access controllability) Чи контролюється та наскільки успішно доступ до системи і даних Визначаються експертним методом або за формулою: Х=А/В, де А-кількість виявлених і відвернених спроб несан- кціонованого доступу до системи або даних; В-кількість спроб несанкці- онованого доступу до системи або даних 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт про тесту-вання (експертизи або верифікації) А.1.4.3 Захищеність від викривлення та втрати даних (Data corruption prevention) Чи реалізовано та наскільки успішно захист даних від викривлення та втрат Визначаються експертним методом або за формулою: Х=А/В, де А-кількість випадків виявлення та успішного відновлення викривлених або загублених даних; В-кількість випадків викрив- лення або втрати даних; Вимоги специфікацій 0<=X<=1 Звіт про тесту-вання (експертизи або верифікації) А.1.4.4 Захищеність від перехоплення даних (Data encryption) Чи реалізовано та наскільки успішно захист даних від перехоплення та розшифровки Визначаються експертним методом або за формулою: Х=1-А/В, де А-кількість успішних спроб перехоплення та розшифровки даних; В-кількість виконаних спроб перехоплення та розшифровки даним 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт про тесту-вання (експертиза або верифікація) Таблиця А.1.5 – Метрики узгодженості функціональності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.1.5.1 Узгодженість функціональ-ності (Functional compliance) Наскільки відповідає ПЗ вимогам стандартів та інших нормативних документів, що стосу-ються функціональності Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт експертизи та верифікації А.1.5.2 Узгодженість інтерфейсів (Interface standard compliance) Наскільки відповідають зовнішні інтерфейси ПЗ вимогам стандартів та інших нормативних документів Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт експертизи та верифікації А.2 Метрики надійності Таблиця А.2.1 – Метрики зрозумілості Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.1.1 Щільність дефектів (Fault density) Як багато дефектів було виявлено в ПЗ X=NAFU/SIZE, де NAFU-загальна кількість виявлених у ПЗ дефектів; SIZE- об'єм ПЗ в Кб або Мб 0<=X Чим ближче до "0", тим краще Звіти про тесту-вання, експертизу та верифікацію Продовження таблиці А.2.1 Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.1.2 Щільність прихованих дефектів (Estimated latent fault density) Як багато дефектів залишилося ще не виявленими в ПЗ, які можуть виявитися надалі X=|NPFU-NAFU|/SIZE, де NPFU-кількість передвіщених (за допомогою математичних мо- делей) дефектів у ПЗ; NAFU-загальна кількість виявлених у ПЗ дефектів; SIZE- об'єм ПЗ в Кб або Мб 0<=X Чим ближче до "0", тим краще Звіти про тесту-вання, експертизу та верифікацію А.2.1.3 Виявлення причин відмов (Failure Resolution) Яка імовірність виявлення причини відмови (дефекту, що призвів до відмови) X=NAFU/NAFI, де NAFU-кількість відмов ПЗ, для яких установлена причина виникнення; NAFI-загальна кількість зафік- сованих відмов ПЗ 0<=X<=1 Звіти про тесту-вання, експертизу та верифікацію А.2.1.4 Виправлення дефектів (Fault Removal) Яка імовірність виправ-лення дефектів X=NRFU/NAFU, де NRFU-кількість виправлених дефектів у ПЗ; NAFU-загальна кількість виявлених у ПЗ дефектів 0<=X<=1 Чим ближче до "1", тим краще Звіти про тесту-вання, експертизу та верифікацію Кінець таблиці А.2.1 Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.1.5 Середнє напрацювання на відмову (Mean time bet-ween failures) Як часто виникають відмови ПЗ MTBF=TSIB/NAFI, де TSIB-сума інтервалів часу між зафіксованими відмовами; NAFI-загальна кількість зафіксованих відмов ПЗ 0<=X Чим більше, тим краще Звіти тестування, експертизи та верифікації А.2.1.6 Передвіщений час до наступної від-мови (Mean time to the next failure) Як довго очікується робота ПЗ без відмов MTTF визначають за допомогою імовірнісних моделей надійності на основі аналізу статистичних даних тестування 0<=X Чим більше, тим краще Звіти тестування, експертизи та верифікації А.2.1.7 Тестове покриття (Test coverage) В якому об’ємі виконано тестування ПЗ Х=А/В, де А-кількість виконаних тестових наборів (сценаріїв); В-кількість тестових наборів (сценаріїв), необхідних для покриття всіх функцій і перевірки вимог ПЗ 0<=X<=1 Звіти тестування, експертизи та верифікації Таблиця А.2.2 - Метрики стійкості до відхилень Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.2.1 Стійкість до внутрішніх дефектів Наскільки ПЗ є стійким до прояву внутрішніх дефектів Х=А/В, де А-кількість зафіксованих проявів внутрішніх дефектів ПЗ; В-кількість зафіксованих випадків прояву внутрішніх дефектів ПЗ 0<=X<=1 Звіти тестування, експертизи та верифікації. Звіт з експлуатації А.2.2.2 Стійкість до помилок у вхідних даних Наскільки ПЗ є стійким до помилок у вхідних даних Визначають експертним методом або за формулою: Х=1-А/В, де А-кількість випадків відмови ПЗ через помилки у вхідних даних; В-кількість зафіксованих випад- ків помилкових вхідних даних 0<=X<=1 Звіти тестування, експертизи та верифікації. Звіт з експлуатації А.2.2.3 Стійкість до помилок користувачів Наскільки ПЗ є стійким до помилок користувачів Визначають експертним методом або за формулою: Х=1-А/В, де А-кількість випадків відмови ПЗ через помилки користувача; В-кількість зафіксованих помилкових дій користувача 0<=X<=1 Звіти тестування, експертизи та верифікації. Звіт з експлуатації Таблиця А.2.3 - Метрики відновлюваності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.3.1 Здатність до автоматичного відновлення (Restorability) Чи володіє ПЗ здатністю до автоматичного віднов-лення та наскільки Визначають експертним методом за формулою Х=А/В, де А-кількість випадків успішного автоматичного відновлення; В-кількість відмов ПЗ 0<=X<=1 Звіти тестування, експертизи та верифікації. Звіт з експлуатації А.2.3.2 Готовність Яка ступінь готовності ПЗ Х=Тр/(Тр+Тв), де Тр- час знаходження ПЗ у працездатному стані; Тв- час знаходження ПЗ у стані відновлення після відмов 0<=X<=1 Звіти тестування, експертизи та верифікації. Звіт з експлуатації А.2.3.3 Середній час автоматичного відновлення Який середній час автоматичного відновлення ПЗ Х=Sum (Т)/В, де Т- час автоматичного віднов- лення ПЗ після кожної відмови; В-кількість відмов ПЗ 0<=X Таблиця А.2.4 – Метрики узгодженості надійності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.2.4.1 Узгодженість надійності Наскільки відповідає ПЗ вимогам стандартів та інших нормативних документів, що стосуються надійності Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій Звіт експертизи та верифікації А.3 Метрики використовуваності Таблиця А.3.1 – Метрики зрозумілості Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.3.1.1 Зрозумілість функцій ПЗ (Function understand-ability) Наскільки зрозумілі корис-тувачеві функції ПЗ після прочитання керівництва користувача або довід-кової документації Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.1.2 Зрозумілість вхідних /вихідних даних (Understandable input and output) Наскільки зрозуміло користувачеві призначення вхідних / вихідних даних після прочитання посібника або довідкової документації Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.1.3 Доступність демонстрації (Demonstration accessibility) Чи доступна користу-вачеві наочна демонстрація виконання функцій під час роботи з ПЗ Визначають експертним методом 0<=X<=1 Звіт з експертизи та верифікації. Звіт з експлу-атації Таблиця А.3.2 – Метрики придатності до вивчання Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.3.2.1 Повнота доку-ментації корис-тувача та системи допомоги (Completeness of user documentation and/or help facility) Наскільки є повною документація користувача та система допомоги Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлуата-ції А.3.2.2 Ефективність (зрозумілість) документації користувача та системи допомоги (Effectiveness of user documentation and/or help system) Наскільки зрозуміло складено документацію користувача та систему допомоги Визначають експертним методом 0<=X<=1 Звіт з експертизи та верифікації. Звіт з експлуата-ції А.3.2.3 Доступність документації користувача та системи допомоги Чи доступна користувачу документація та система допомоги безпосередньо під час роботи з ПЗ Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлуата-ції А.3.2.4 Середній час навчання роботі з ПЗ (Ease of function learning) Як довго відбувається навчання роботі з ПЗ Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлуата-ції Таблиця А.3.3 – Метрики керованості Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.3.3.1 Доступність значень параметрів "за замовчуванням" (Default value availability in use) Наскільки легко користувач може задавати значення вхідних параметрів ПЗ Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.3.2 Перевірка коректності параметрів, які вводять користувачі (Input validity checking) Чи здійснюється перевірка коректності даних, які вводять користувачі Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.3.3 Відміна дій (Undoability) Чи може користувач скасувати або скорегувати свої дії шляхом повернення до попереднього стану Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.3.4 Зрозумілість системних повідомлень (Message understand-ability in use) Наскільки зрозумілі користувачеві повідомлення, що видає ПЗ Визначають експертним методом 0<=X<=1 Звіт з експертизи та верифікації. Звіт з експлу-атації А.3.3.5 Середній час між помилками користувача при роботі з ПЗ Як довго користувач може взаємодіяти з ПЗ без помилок Визначають експертним методом або за формулою Х=Т/В, де Т - час роботи ЗД; В - кількість помилок користу- вача, зроблених за час роботи з ПЗ 0<=X<=1 Чим ближче до "1", тим краще Звіт з експертизи та верифікації. Звіт з експлу-атації Таблиця А3.4 – Метрики привабливості Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.3.4.1 Привабливість інтерфейсу користувача (Attractive interface) Наскільки зручним та привабливим є інтерфейс користувача Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Звіт зекспертизи та верифікації. Звіт з експлуатації А.3.4.2 Налагоджу-ваність інтерфейсу користувача (Interface appearance customizability) Чи існує можливість індивідуального настроювання інтерфейсу користувача Визначають експертним методом 0<=X<=1 Звіт з експертизи та верифікації. Звіт з експлуатації Таблиця А3.5 – Метрики узгодженості та використовуваності Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.3.5.1 Узгодженість використовува-ності Наскільки відповідає ПЗ вимогах стандартів та інших нормативних документів, що стосуються використовуваності Визначають експертним методом 0<=X<=1 Чим ближче до "1", тим краще Вимоги специфікацій. Звіт з експертизи та верифікації А.4 Метрики ефективності Таблиця А.4.1 – Метрики часових характеристик ПЗ Номер пункту Назва метрики Призначення метрики Формула та метод обчислення Інтерпретація Джерело вхідних даних для вимірів А.4.1.1 Відносний середній час відгуку (Mean time for response) Яке відношення фактичного середнього часу виконання команд або запитів користувача до максимально допустимого Х=Тср./ТRср., де Тср. - виміряний середній час відгуку; ТRср. - максимально допустимий середній час відгуку 0

Похожие записи