5 Методи оцінювання показників якості програмного забезпечення критичного призначення

5.1 Методи оцінювання показників якості програмного забезпечення

5.1.1 Основними методами оцінки показників якості ПЗ повинні бути:

• інспекції (огляди);

• тестування ПЗ;

• статичний аналіз ПЗ;

• імовірнісна оцінка надійності ПЗ;

• аналіз видів, наслідків і критичності відмов програмного забезпечення – SFMECA;

• аналіз дерева відмов програмного забезпечення – SFTA.

5.2 Інспекції процесів розроблення програмного забезпечення

5.2.1 Інспекції або технічні огляди (Inspection/Walk-through Review) застосовують для перевірки коректності, повноти та несуперечності програмної документації, а також для виявлення аномалій і дефектів, пов’язаних з невірним розумінням вимог НД.

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

5.2.3 У таблиці 5.1 показано зв'язок між етапами розроблення ПЗ, відповідними видами програмного продукту, які є результатами етапів розроблення та видами інспекцій.

Таблиця 5.1—Види інспекцій програмного забезпечення

Етап розроблення ПЗ	Вид програмного продукту (результат етапу)	Вид інспекції
Розроблення вимог до ПЗ	Вимоги до ПЗ (програмна специфікація)	Інспекція вимог до ПЗ на відповідність вимогам до системи
Проектування	Проект ПЗ	Інспекція проекту ПЗ на відповідність вимогам до ПЗ
Кодування	Програмний код	Інспекція програмного коду на відповідність проекту ПЗ

5.2.4 Інспекції поділяють на :

– інспекції вимог високого рівня;

– інспекції вимог низького рівня.

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

– повністю визначені функції інформаційно-керуючих систем, які повинне виконувати ПЗ;

– вимоги до характеристик якості ПЗ деталізовані у вихідних вимогах високого рівня;

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

– вимоги не конфліктують одна з одною;

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

– процес розроблення вимог до ПЗ ПТК повністю відповідає стандартам на створення специфікації вимог і будь-які відхилення від стандартів обґрунтовані;

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

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

5.2.7 Інспекції (огляди) повинні включати наступні етапи:

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

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

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

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

1) дату та список присутніх;

2) посилання на вхідні документи;

3) основний зміст контрольних аркушів, використовуваних читачами;

4) список незначних коментарів, пов'язаних з ними пропозицій та граничних термінів для виправлень;

5) список суттєвих коментарів, пов'язаних з ними пропозицій і граничних термінів для виправлень.

5.2.8 Перевагами інспекцій є:

• простота організації та можливість проведення у стислий час;

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

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

5.2.9 Обмеженнями інспекцій є:

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

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

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

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

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

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

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