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

Ю.І. Грицюк

Якість програмного забезпечення (ПЗ) є основною його характеристикою в різних сферах використання інформаційних технологій (Иеяка^ Zato- natska, 2011), яка вказує на ступінь його відповідності встановленим вимогам (ШО 9001, 2008). Зазвичай, такі вимоги трактують по-різному, що породжує декілька незалежних визначень цього терміна. Здебільшого, під якістю ПЗ розуміють набір властивостей програмного продукту, що характеризують його здатність задовольнити встановлені або передбачувані потреби замовника, які він висловив у вигляді користувацьких вимог до нього на початкових етапах його розроблення (Ротого- va & Hovorushchenko, 2013 а, 2013Ь).

Стандарт ШО/ІЕС 9126 (1991) регламентує зовнішні й внутрішні характеристики якості ПЗ. Якщо зовнішні характеристики відображають вимоги до функціонування ПЗ, то внутрішні характеристики використовують для підготовки плану досягнення необхідних значень зовнішніх характеристик його якості (ШО/ІЕС TR 9126-2, 9126-3, 2003). Як зовнішні, так і внутрішні характеристики якості відображають властивості самого ПЗ, а також погляди замовника і розробника на нього. Однак, безпосереднього користувача ПЗ в основному цікавить експлуатаційна його якість (ШОЛЕС 9126-1, 2001), тобто сукупний ефект від досягнення необхідних характеристик програми, значення яких вимірюється швидкістю та достовірністю отриманого результату, а не його властивістю. Це поняття значно ширше, ніж будь-яка окрема характеристика якості ПЗ, наприклад, зручність його використання чи надійність роботи (ISO/IEC TR 9126-4, 2004).

Зазвичай, під оцінюванням якості ПЗ розуміють дії, що визначають, як саме ПЗ відповідає своєму призначенню (Kuliamin, Petrenko, 2008). Якість ПЗ оцінюють з використанням моделі якості (ISO/IEC 9126-1, 2001). Таке оцінювання набуває особливого значення із розвитком і вдосконаленням технологій визначення якості ПЗ, а саме - методами метричного аналізу. Усе це призвело до потреби розроблення відповідного засобу для визначення якості ПЗ відповідними методами.

Аналіз останніх досліджень та публікацій. На сьогодні процес оцінювання якості ПЗ за стандартом ISO 25010:2011 (Gordieiev et al., 2014) відбувається в такому порядку: на підставі атрибутів якості, зазначених у стандарті ISO 25023:2016, оцінюють підхарактеристики та характеристики якості, які, водночас, надають комплексну оцінку якості ПЗ. Оцінювання ж якості ПЗ з використанням результатів метричного аналізу зводиться до того, що на підставі показників якості розраховують значення відповідних метрик якості та значення комплексного показника якості майбутньому програмному продукту. Згідно з стандартом ISO 24765:2010, метрику визначають як міру ступеня володіння властивістю деякого продукту, яка має числове значення.

Проблемі якості ПЗ присвячено багато робіт українських й іноземних науковців, а саме: В. Харченка і Б. Конорєва (Gordieiev et al., 2014; Kharchenko et al., 2007, 2012; Konorev et al., 2009), Маєвського (Maievskyi & Kozina, 2015; Maievskyi, 2013), В. Яковини (Yakovyna, 2012; Yakovyna, Fedasiuk & Mamrokha, 2010), В. Мі- щенка і О. Поморової (Mishhenko, 2010; Mishhenko, Po- morova, Hovorushchenko, 2012; Pomorova & Ivanchy- shyn, 2011), К. Лавріщевої (Lavrishcheva, 2008, 2013), 0. Харченка (Kharchenko, Galay & Yatcyshyn, 2011; Kharchenko & Yatsyshyn, 2009), Г. Майєрса (Myers, Badzhett & Sandler, 2012), С. МакКоннелла (McConnell, 2013,, Р. Фатрелла (Fatrell, Shafer & Shafer, 2003), І. Соммервілла (Sommerville, 2002), О. Медче (Maedche, Botzenhardt & Neer, 2012), С. Джонса (Jones, 2000; Jones, Bonsignour, 2012).

Проте, процедура оцінювання якості ПЗ та наявні методи і засоби забезпечення цієї якості, як власне і процес розроблення самого ПЗ залишаються незабезпе- ченими фундаментальною теорією та ефективною методологією (Andon et al., 2002). Усі дослідження у галузі оцінювання якості ПЗ, особливо на ранніх етапах його життєвого циклу, мають хаотичний, несистемати- зований характер (Braude, 2004). Водночас, як доведено у роботах (Pomorova & Hovorushchenko, 2013a, 2013b; Pomorova, Hovorushchenko & Tarasek, 2010), саме в кінці етапу проектування архітектури ПЗ можна й варто виявляти та усувати до 55 % всіх недоліків майбутнього програмного продукту. Безумовно, є багато фундаментальних досліджень з інженерії ПЗ (роботи Боема, Дейкстри, Мейєра), але відсутня завершена, протесто- вана та апробована теорія та методологія розроблення складного і, водночас, якісного ПЗ, а також методи і засоби оцінювання та прогнозування його якості на ранніх етапах реалізації програмного проекту. Тому проблема оцінювання якості ПЗ потребує нагальних змін для запобігання непередбачених втрат і неприємних інцидентів, викликаних помилками його роботи (Hovo- rushchenko, 2018).

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

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

Для реалізації зазначеної мети потрібно виконати такі основні завдання:

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

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

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

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

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

Сучасні технології розроблення ПЗ досягли такого рівня свого розвитку, що виникла потреба у використанні інженерних методів оцінювання результатів його проектування на всіх етапах реалізації програмного проекту, контролю ступеня досягнення запланованих показників якості та їх метричного аналізу, оцінювання ризику можливих небезпек і ступеня використання готових компонент для зниження вартості реалізації нового проекту (А^оп et аі., 2002; Lypaev, 2001). Основу інженерних методів оцінювання якості ПЗ становить можливість її підвищення шляхом формування відповідних вимог до критеріїв оцінювання якості, вдосконалення моделей метричного аналізу його якості та методів кількісного її вимірювання на всіх етапах реалізації програмного проекту (Pomorova & Hovorushchenko, 2009, 2010; Pomorova, Hovorushchenko & Onyshchuk, 2011; Pomorova, Hovorushchenko & Tarasek, 2010). Статичні технології оцінювання якості ПЗ наведено на рис. 1, водночас як динамічні технології так чи інакше пов'язані з безпосереднім його тестуванням.

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

Рис. 1. Статичні технології оцінювання якості ПЗ

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

Якість ПЗ як предмет стандартизації. Згідно з даними ГОСТ 2844-94, якість ПЗ представляє сукупність властивостей (показників якості) ПЗ, які забезпечують його здатність задовольняти потреби замовника відповідно до його призначення (Andon et al., 2002). Цей стандарт регламентує базову модель якості та показники, головним серед яких є надійність. Стандарт ISO/IEC 12207 визначає не тільки основні процеси етапів розроблення ПЗ, а й організаційні та додаткові процеси, які регламентують інженерію, планування й управління якістю ПЗ (Braude, 2004). Згідно з цим стандартом, на всіх етапах розроблення ПЗ повинен проводитися такий контроль його якості:

• перевірка відповідності користувацьких вимог до ПЗ з критеріями і показниками його якості;

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

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

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

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

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

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

Для будь-якого інженерного продукту існує безліч інтерпретацій його якості. Дотримання запланованих показників якості ПЗ можна вимагати від його розробників тою чи іншою мірою протягом усіх етапів його розроблення. Цих показників може бути небагато або вони можуть відображати певні властивості майбутнього програмного продукту, які хотіли б бачити його безпосередні користувачі та інші зацікавлені сторони, часто вони є результатом певного компромісу. Такий підхід повністю співпадає з розумінням такого поняття, як "прийнятна якість ПЗ", що є менш жорсткою точкою зору на забезпечення розробником якості ПЗ як гарантоване досягнення його досконалості (Koval & Moroz, 2006; Pomorova, Hovorushchenko & Onyshchuk, 2011).

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

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

Для наочної демонстрації залежності вартості реалізації програмного проекту від рівня якості ПЗ розглянемо особливості розроблення системи захисту інформації (СЗІ), а саме її функціональну модель (рис. 2) ^гусі- ик & Sivec, 2016; Игузіик & Sivets, 2016а, 2016Ь). В цій моделі не показано цінність інформації - об'єкта конфіденційності (наприклад, рахунки банківських вкладів чи коди доступу до них, позаяк ця інформація не втрачає своєї цінності з плином часу). Отже, на цьому рисунку введено такі позначення: P - рівень (ймовірність) забезпечення захисту інформації (практично О^^^О); Z(P) - допустимі витрати на захист інформації як функція від необхідного рівня її захисту. Ці витрати зростають при підвищенні вимог до певного рівня забезпечення захисту інформації.

Рис. 2. Основні особливості процесу оцінювання якості СЗІ

Прагнення досягти дуже високого рівня забезпечення захисту інформації, зазвичай, призводить до різкого зростання витрат, які можуть перевищити цінність самої інформації, яку потрібно захистити. Можливі втрати (збитки) власника інформації Щ(Р), понесені унаслідок неналежного рівня її захисту, є функцією від наявного рівня забезпечення її захисту Р. З рисунка видно, що сума 2(Р) + Щ(Р) визначає витрати V(Z, Щ) на забезпечення захисту інформації. При цьому оптимальний рівень її захисту Vop^(Z, Щ) відповідатиме мінімуму суми витрат на захист Z(P) і можливих збитків Щ(Р) унаслідок втрати інформації, тобто неповноти її захисту. Прагнення перевищити його призведе до різкого зростання витрат Z(P) на забезпечення захисту інформації; зниження ж рівня забезпечення захисту призведе до збільшення можливих збитків Щ(Р) унаслідок недосконалості функціонування СЗІ.

Отже, якість ПЗ є відносним поняттям, сенс якого замовники розуміють тільки при врахуванні реальних умов його застосування, тому вимоги, що пред'являються до якості ПЗ відповідними стандартами, повинні співвідноситися з умовами його використання та конкретною областю його застосування (Pomorova, Hovo- rushchenko & Onyshchuk, 2011). Якість ПЗ характеризується такими компонентами: якістю процесів розроблення ПЗ, якістю продуктів програмного проекту і якістю супроводу або впровадження ПЗ (рис. 3).

Рис. 3. Основні компоненти оцінювання якості ПЗ

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

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

Модель якості ПЗ має чотири рівні подання (Koval & Moroz, 2006).

Перший рівень відповідає визначенню характеристик (показників) якості ПЗ, кожна з яких відображає окрему точку зору користувача на його якість. Згідно з наявними стандартами (ISO/IEC 9126, ДСТУ 2844-1994, ДСТУ 2850-1994, ДСТУ 3230-1995), в модель якості входить шість характеристик/показників якості ПЗ (рис. 4): функціональність (Functionality), надійність (Realibi- lity), зручність використання (Usability), супроводжува- ність (Maitainnability), ефективність (Efficiency), переносність (Portability).

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

Третій рівень призначений для вимірювання якості за допомогою метрик, кожну з яких, згідно з стандартом ШОЛЕС 9126, визначають як комбінацію методів вимірювання атрибута і шкали встановлення його значень. Для оцінювання атрибутів якості ПЗ на всіх етапах його розроблення (при перегляді документації та продуктів проекту, а також за результатами їхнього тестування) використовують метрики з заданою їх вагомістю для нівелювання результатів метричного аналізу сукупних атрибутів конкретного критерію чи показника якості ПЗ. Атрибут якості визначають за допомогою однієї або декількох методик якості ПЗ на різних етапах його розроблення і на завершальному етапі його тестування.

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

Для розуміння зазначеного вище розглянемо більш детально показники якості ПЗ ^акоуупа, 2012; Ya- коуупа, Fedasiuk & Матто^а, 2010).

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

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

• правильність (точність) - атрибут, який показує ступінь досягнення правильних результатів роботи ПЗ;

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

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

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

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

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

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

До деяких типів критичних систем (реального часу, радарних, систем безпеки, комунікацій та ін.) висувають певні вимоги щодо забезпечення високої надійності (неприпустимість помилок, точність, достовірність, зручність застосування й ін.) (Zalewski, Kornecki & Pfister, 2018). Надійність ПЗ значною мірою залежить від кількості помилок, що залишилися й неліквідованих у процесі його розроблення на кожному з етапів. У ході експлуатації ПЗ помилки виявляють й усувають після аналізу причин їх появи. Якщо при виправленні помилок не вносяться нові або, принаймні, нових помилок вноситься менше, ніж їх усувають, то в ході експлуатації ПЗ його надійність безперервно зростає. Чим інтенсивніше експлуатують ПЗ, тим частіше виявляють помилки і швидше їх усувають, і, як наслідок, тим більшою стає його надійність.

На надійність ПЗ впливають такі чинники (Lav- rishcheva, 2008, 2013):

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

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

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

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

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

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

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

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

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

Питання надійності ПЗ протягом багатьох років розглядали різними фахівцями з використанням різних методів і технологій (Yakovyna, Fedasiuk & Mamrokha, 2010). Відображенням пошуку шляхів подолання цієї проблеми стала поява в англомовній літературі та наповнення новим змістом терміна "Dependability", що має більш широке тлумачення, ніж просто "надійність", якому він відповідає в українській мові. Тому в Україні в різних нормативних документах почали використовувати термін "гарантоздатність" (надійність у широкому змісті), який поєднує властивості класичної надійності (безвідмовність, ремонтопридатність, готовність і збе- режуваність) та безпеки як функціональної, так і інформаційної. На початку 2000-х років було узагальнено результати та зафіксовано підсумки розвитку гарантоз- датних (як надійних і безпечних) обчислень, визначена досить повна та збалансована система понять і таксономічних схем. До цього часу поняття "dependability" як гарантоздатність ("розширена" надійність) були вже визначені у тому або іншому варіантах низкою стандартів, технічних звітів і монографій.

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

• готовністю до використання (Availability);

• готовністю до безперервного функціонування (Reliability);

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

• секретністю та збереженням інформації (Confidential);

• здатністю до збереження ПЗ і стійкість до мимовільної її зміни (Integrity);

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

• готовністю й збереженням інформації (Security) і ін.

Табл. 1. Розподіл помилок, припущених на різних етапах

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

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

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

Сучасне ПЗ характеризується складністю опису, наявністю набору тісно взаємопов'язаних компонент з локальними завданнями та глобальними цілями, відсутністю повних аналогів і, як наслідок, неможливістю використання будь-яких типових проектних рішень. Окрім цього, нове ПЗ, зазвичай, вимагає повної інтеграції з наявним ПЗ, функціонуванням у неоднорідному середовищі на різних апаратних платформах, часто відокремленістю складових у просторі та різнорідністю груп користувачів із різним рівнем кваліфікації (Pomorova & Hovorushchenko, 2009).

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

З наведених даних у табл. 1 видно, що помилки формулювання вимог до ПЗ та проектування його архітектури становлять 25-55% від всіх можливих помилок, причому чим більший обсяг ПЗ, тим більше помилок вноситься саме на ранніх етапах його розроблення.

На сьогодні оцінювання якості ПЗ за стандартом ШО 25010:2011 відбувається в такий спосіб: на підставі атрибутів якості, зазначених у ШО 25023:2016, оцінюють підхарактеристики та характеристики якості ПЗ, які, водночас, надають комплексну його оцінку. Згідно з даними стандарту ШО 25010:2011, характеристика - це набір властивостей ПЗ, за допомогою яких можна описати та оцінити його якість. Підхарактеристика якості ПЗ виражається середньозваженим арифметичним показником з урахуванням значень атрибутів, що оцінюють цю підхарактеристику, та коефіцієнтів їхньої вагомості (Pomorova & Hovorushchenko, 2010).

Існує ряд моделей, що дають змогу розраховувати якість ПЗ, однак багатозначність трактування цих характеристик ускладнює такі розрахунки. Більшість моделей базуються на використанні різних метрик ПЗ (Po- morova, Hovorushchenko & Onyshchuk, 2011). Історія програмних метрик нараховує понад чверть століття, тобто з того моменту, коли вартість комерційних програмних продуктів почала зростати і знадобилися наукові методи аналізу процесів розроблення ПЗ. Сучасна ІТ- індустрія нагромадила велику кількість метрик, які дають змогу оцінити окремі виробничі та експлуатаційні властивості ПЗ (Andon et al., 2002; Zalewski, Kornecki & Pfister, 2018).

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

Свого часу введення кількісних метрик якості ПЗ мало сприяти вирішенню деяких практичних завдань (Lavrishcheva, 2008): 1) прогнозування кількості помилок у ПЗ від початку проектування; 2) прогнозування рівня складності ПЗ та його супроводу на підставі аналізу результатів проектування; 3) прогнозування рівня складності процесів тестування та кількості невиявле- них помилок на підставі аналізу коду програми; 4) прогнозування остаточного розміру коду програми на підставі аналізу оцінок складності проектування архітектури ПЗ; 5) визначення впливу окремих характеристик програмного коду на якість готового ПЗ; 6) контроль етапів реалізації програмного проекту; 7) аналіз явних і прихованих дефектів у готовому ПЗ; 8) виявлення кращих методів і технологій розроблення ПЗ на підставі їх порівняння.

Отже, якість ПЗ можна виміряти за допомогою метрик якості. За визначенням стандарту ISO/IEC 9126-2, метрика якості ПЗ є "... моделлю вимірювання атрибута, пов'язаного з характеристикою якості ПЗ. Це комбінація конкретного методу вимірювання (способу отримання значень) атрибута сутності й шкали вимірювання" (Andon et al., 2002). Згідно з даними стандарту ISO 24765:2010, метрику можна визначити як міру ступеня володіння властивістю, яка має числове значення. Загалом, метрика ПЗ - це міра, яка дає змогу отримати числове значення деякої властивості ПЗ як середньозважене арифметичне з урахуванням значень показників, що оцінюють цю метрику, та коефіцієнтів їхньої вагомості (Lavrishcheva, 2013).

Незважаючи на численні дослідження програмних метрик (Pomorova & Hovorushchenko, 2009; Pomorova, Hovorushchenko & Tarasek, 2010), однак залишається багато невирішених питань. Одним з таких питань є відсутність єдиних стандартів на метрики (створено більше тисячі метрик), тому кожен постачальник вимірювальної системи пропонує власні методи оцінювання якості ПЗ і відповідні метрики. Також є складним завдання інтерпретації значень метрик, позаяк для більшості користувачів як метрики, так і їх значення не зовсім є зрозумілими та інформативними. На етапі проектування архітектури ПЗ основна увага при виборі при-датного проекту приділяється вартості його реалізації, тривалості процесу розроблення, репутації фірми-про- ектанта та наявним технологіям розроблення ПЗ. За статистичними даними (Pomorova & Hovorushchenko, 2009; Pomorova, Hovorushchenko & Tarasek, 2010) тільки 1,5 % програмних компаній намагаються оцінити якість процесів і готового продукту кількісно за допомогою метрик, і тільки 0,5 % цих компаній намагаються покращити роботу, керуючись кількісними критеріями якості ПЗ з метою виготовлення бездефектних продуктів. Окрім цього, сучасні технології вимірювання якості ПЗ ще не досягли своєї "зрілості", оскільки тільки 0,5 % програмних компаній працюють за так званою моделлю зрілості здібностей СММ (англ. Capability Maturity Model) (Pomorova & Hovorushchenko, 2013a; Po- morova, Hovorushchenko & Tarasek, 2010).

За видом (станом) об'єкта вимірювання (робоча версія програми або сукупність документів і програмного коду) метрики умовно поділяються на зовнішні, внутрішні й експлуатаційні (Pomorova & Hovorushchenko, 2010, 2013a).

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

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

Метрики експлуатаційної якості дають змогу виміряти рівень якості ПЗ, встановлене в замовника й використовується у певному середовищі експлуатації за безпосереднім призначенням, задовольняє потреби користувачів стосовно ефективного, продуктивного та безпечного вирішення завдань, покладених на нього, а також справляє загальне позитивне враження на його безпосередній користувачів. Ці метрики допомагають оцінити не властивості самого ПЗ, а видимі результати його експлуатації, тобто експлуатаційну якість ПЗ (Koval & Moroz, 2006; Kuliamin & Petrenko, 2008).

Внаслідок проведеного аналізу метрик якості ПЗ з точки зору можливості їх застосування на ранніх етапах його розроблення з отриманням точного або прогнозованого значення було виділено деякі метрики, які вже на етапі проектування архітектури ПЗ мають точне значення (Pomorova & Hovorushchenko, 2013b): 1) метрика Чепіна - аналізує характер використання змінних з переліку введеної та оброблюваної інформації; 2) метрика зв'язності (зв'язність (cohesion) - внутрішня характеристика програмного модуля, яка залежить від типу модуля або проекту; 3) метрика зчеплення (coupling) - зовнішня характеристика модуля, яку бажано і варто зменшувати - міра взаємозалежності модулів за даними; 4) метрика Джилба (складова метрики) - модульна складність програми, за допомогою якої на етапі проектування можна підрахувати кількість міжмодульних зв'язків; 5) метрика Мак-Клура - спрямована на оцінювання архітектури ПЗ; 6) метрика Кафура - ґрунтується на врахуванні потоків даних; 7) метрика звертання до глобальних змінних - характеризується парою (p,r), де p - модуль, який має доступ до глобальної змінної г; 8) тривалість модифікації моделей - метрика процесу розроблення ПЗ; 9) кількість знайдених помилок при інспектуванні моделей і прототипів підсистем, модулів, функцій, вимог та густота помилок.

Аналіз метрик якості ПЗ з точки зору можливості їх застосування на етапі проектування його архітектури з отриманням точного або прогнозованого значення дає нам змогу також виділити ряд метрик, які мають прогнозоване значення на етапі проектування (Pomorova, Hovorushchenko & Onyshchuk, 2011): 1) очікувана LOC- оцінка (експертна); 2) метрика Холстеда - обчислюється на підставі аналізу кількості рядків і синтаксичних елементів вихідного коду програми; 3) метрика Маккейба - цикломатична складність; 4) метрика Джилба - відносна логічна складність програми; 5) прогнозована кількість операторів програми; 6) прогнозована оцінка складності інтерфейсів компонент ПЗ; 7) прогнозована загальна тривалість процесу розроблення ПЗ - метрика процесу розроблення ПЗ; 8) тривалість виконання робіт етапу проектування ПЗ - метрика процесу розроблення ПЗ; 9) очікувана вартість процесу розроблення ПЗ; 10) прогнозована вартість перевірки якості - метрика процесу розроблення ПЗ; 11) прогнозована продуктивність процесу розроблення ПЗ; 12) прогнозовані витрати на реалізацію коду - метрика процесу розроблення ПЗ; 13) прогнозований функціональний розмір FP - вимірює суть можливостей майбутньої програми; 14) прогнозована оцінка трудо- витрат і тривалості реалізації програмного проекту - за моделлю Боема.

Отже, для побудови інтелектуального методу оцінювання результатів проектування архітектури ПЗ та прогнозування характеристик його якості нами було обрано 9 метрик етапу його проектування з точними значеннями та 15 метрик етапу проектування ПЗ з прогнозованими значеннями. Інші метрики є похідними від обраних базових метрик (АМоп et аі., 2002; Pomorova & Hovorushchenko, 2009). Найбільш використовуваними джерелами інформації щодо складності ПЗ є метрики (Pomorova & Hovorushchenko, 2010; Pomorova & Гvanchyshyn, 2011; Pomorova, Hovorushchenko & Тага- sek, 2010): Чепіна, Мак-Клура, Кафура, Холстеда, Маккейба, Джилба. Щодо якості ПЗ, то найчастіше для його оцінювання використовують метрики зв'язності, зчеплення, очікуваної вартості розроблення, прогнозованої вартості перевірки якості, прогнозованої вартості розроблення, очікуваного загальної тривалості процесу розроблення ПЗ, прогнозованої тривалості етапу проектування.

Розглянемо для прикладу метрику Чепіна та метрику Кафура.

Метрика Чепіна аналізує характер використання змінних зі переліку введення-виведення, тобто оброблювану інформацію. Існує декілька модифікацій метрик Чепіна. Суть найпростішої метрики Чепіна з точки зору її практичного використання як достатньо ефективного методу полягає в оцінюванні інформаційної міцності окремо взятого програмного модуля за допомогою аналізу характеру змінних з переліку введення-виведення. У цьому переліку всю множину змінних поділяють на такі функціональні групи (Pomorova & Hovorushchenko, 2013а):

• множина "Р" - змінні, які вводять для виконання розрахунків і для забезпечення виведення отриманої інформації;

• множина "М" - модифіковані або створювані змінні всередині програми;

• множина "С" - змінні, які беруть участь в управлінні роботою програмного модуля (керуючі змінні);

• множина "Т" - не використовувані в програмі ("паразитні") змінні.

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

Метрику Чепіна можна обчислити за формулою (Ро- morova & Hovorushchenko, 2013Ь): програмний метричний якість

Is = Qm?(P + 2?M + 3?C + 0,5?T) ,

де: Qm - кількість модулів програми; Р - змінні для розрахунків і виведення; М - модифіковані або створені в програмі змінні; С - керуючі змінні; Т - не використовувані в програмі ("паразитні") змінні.

Метрика Кафура ґрунтується на врахуванні потоків даних. Згідно з даними, наведеними в роботах (Ьау- гі^^ега, 2008; Ротогоуа & Hovorushchenko, 2009), інформаційну складність ПЗ можна обчислити за такою формулою:

I = Qm ? (W ? R + WrRd ? (W + R + WrRd + 1))

де: дт - кількість модулів програми; Ш - середня кількість процедур модуля, які оновлюють структуру даних; Ш - середня кількість процедур модуля, які зчитують інформацію зі структури даних; ШrRd - середня кількість процедур модуля, які зчитують і оновлюють структуру даних.

Кількість модулів програми, виходячи з наведених формул метрик Чепіна та Кафура, можна визначити як на підставі метрики Чепіна

так і на підставі метрики Кафура

Прирівнявши їх між собою, матимемо такий вираз

з якого отримаємо

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

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

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

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

Отже, як на наш погляд, то актуальним завдання є подальше дослідження можливості використання метричного аналізу для визначення якості ПЗ на підставі інформації, отриманої зі специфікації вимог до ПЗ. Для цього нами було розроблено відповідний програмний засіб (рис. 5), призначений для визначення якості ПЗ на підставі метричного аналізу, тобто, з використання метрик якості з точними і прогнозованими значеннями (Andrushchakevych & Hrytsiuk, 2018). Перевагами нашого програмного засобу над відомими є можливість здійснювати аналіз ПЗ на підставі отриманих значень метрик із прогнозуванням подальшої успішності процесу його розроблення. Також внаслідок проведення відповідних розрахунків на виході можна сформувати відповідну множину даних, які дають змогу здійснити апроксимацію результатів метрик, надають кількісну оцінку якості продукту проекту та значення прогнозу характеристик якості розроблювального ПЗ.

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

Даний програмний засіб було розроблено в середовищі розробки Microsoft Visual Studio .NET 2017. Інтер- нет підєднання для коректної роботи засобу не вимагається. Виконання завдання розпочиналося з детального прототипування інтерфейсу користувача з поступовим нарощенням функціоналу програмного засобу. Розроблений інтерфейс програмного засобу можна переглянути на рис. 5,а.

Клас MetricsQualitySoftware.cs є абстрактним з базовими функціями, необхідними для знаходження значення метрики. Серед основних методів класу є: встановлення нового значення параметра метрики (Change Val- ue_OfParameter), отримання назви параметра (GetName- OfParameter), встановлення основної інформації про метрику (SetIпfbrmatюn_OfMetric), встановлення дефол- тних значень параметрів метрики (SetAПParameters WithDefaultValue_OfMetric), вивід довідкової інформа- ції метрики (ShowDescription_OfMetric), функція знаходження значення метрики (FindMetric), очищення значень параметрів метрики (QearAlLParameters_OfMetric).

Для легкого редагування, занесення та отримання даних з певних комірок таблиці DataGrid, використовується клас DataGridHelper.cs з основними методами: знаходження значення певної комірки за індексом рядка і стовпця ^еЮеІІ), а також індекса рядка (GetRow).

Класи CHPmetric.cs, CPPmetric.cs, MBQmetric.cs, MMTmetric.cs, RUPmetric.cs, CCCmetric.cs, СРТтеР ric.cs, SCCmetric.cs, SCTmetric.cs, SDTmetric.cs, SQCmetric.cs, FPmetric.cs, LCmetric.cs, DPmetric.cs - це класи метрик, що наслідують абстрактний клас Мєї- ricsQualitySoftware.cs та перевизначають його методи відповідно до вимог їхнього знаходження.

Класи MyTableInfo_OfAllMetrics.cs, MyTableIn- fo_OfAllParameters.cs, MyTableInfoCharacteristic_^г- MetricFp.cs - це класи-моделі, призначені для запису в них даних, отриманих з певних таблиць DataGrid та виводу сформованої табличної інформації.

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

Рис. 6. Графічне подання результатів у вигляді гістограми

Табл. 2. Вхідні дані для програмного засобу

Рис. 7. Отримані результати метрик

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

Рис. 8. Отримані результати розрахунку якості ПЗ на підставі метричного аналізу

Висновки