Методика оцінювання деяких характеристик якості прикладних програмних систем
Розглянуто основні складові такої характеристики якості як життєздатність та запропоновано методику їх оцінки: метрики, за допомогою яких вимірюються підхарактеристики життєздатності, розкрито зв`язок цих метрик з шаблонами проектування GRASP, шкали для вимірювання зазначених метрик та методика о...
Gespeichert in:
| Datum: | 2006 |
|---|---|
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Ukrainisch |
| Veröffentlicht: |
Інститут програмних систем НАН України
2006
|
| Schlagworte: | |
| Online Zugang: | https://nasplib.isofts.kiev.ua/handle/123456789/2328 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Методика оцінювання деяких характеристик якості прикладних програмних систем / В.М. Ткаченко // Проблеми програмування. — 2006. — N 4. — С. 16-27. — Бібліогр.: 15 назв. — укр. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859846058434101248 |
|---|---|
| author | Ткаченко, В.М. |
| author_facet | Ткаченко, В.М. |
| citation_txt | Методика оцінювання деяких характеристик якості прикладних програмних систем / В.М. Ткаченко // Проблеми програмування. — 2006. — N 4. — С. 16-27. — Бібліогр.: 15 назв. — укр. |
| collection | DSpace DC |
| description | Розглянуто основні складові такої характеристики якості як життєздатність та запропоновано методику
їх оцінки: метрики, за допомогою яких вимірюються підхарактеристики життєздатності, розкрито
зв`язок цих метрик з шаблонами проектування GRASP, шкали для вимірювання зазначених метрик та
методика отримання інтегральної оцінки життєздатності.
Рассмотрены основные составные такой характеристики качества как жизнеспособность и предложено методику их оценки: метрики с помощью измеряются подхарактеристики жизнеспособности, раскрыто связь этих метрик с шаблонами проектирования GRASP, шкалы для измерения указанных метрик и методика получения интегральных оценок жизнеспособности.
There is an overview of base parts of viability is given and evaluation methods of it are proposed in this article. Metrics for viability measurement was chosen. A correlation of these metrics and General Responsibility Assigned Pattern was exposed and scales for metrics evaluation were presented.
|
| first_indexed | 2025-12-07T15:39:17Z |
| format | Article |
| fulltext |
Методи і засоби програмної інженерії
© В.М. Ткаченко, 2006
16 ISSN 1727-4907. Проблеми програмування. 2006. № 4
УДК 681.3
В.М. Ткаченко
МЕТОДИКА ОЦІНЮВАННЯ ДЕЯКИХ ХАРАКТЕРИСТИК
ЯКОСТІ ПРИКЛАДНИХ ПРОГРАМНИХ СИСТЕМ
Розглянуто основні складові такої характеристики якості як життєздатність та запропоновано методику
їх оцінки: метрики, за допомогою яких вимірюються підхарактеристики життєздатності, розкрито
зв`язок цих метрик з шаблонами проектування GRASP, шкали для вимірювання зазначених метрик та
методика отримання інтегральної оцінки життєздатності.
Вступ
Програмна система протягом свого
життєвого циклу постійно еволюціонує.
Природою цих еволюцій може бути або
уточнення моделі предметної області, що
закладена в програмну систему (ПС), або
зміна нефункціональних вимог користувача.
Аналіз існуючих технологій створення ПС
показує, що ці проблеми, як правило, не
знайшли в них відображення або відобра-
жені лише частково.
Практичні проблеми, що виникають
на стадії супроводження функціонуючих
ПС [1], викликають необхідність аналізу
технології розробки та створення ПС з ме-
тою вивчення проблеми врахування їх ево-
люції на цій стадії.
Аналіз існуючих технологій створен-
ня ПС показує, що проблеми супроводжен-
ня або зовсім в них не відображені, або ві-
дображені лише частково.
Впровадження та управління числен-
ними та часто не передбачуваними змінами
в ході розробки та супроводження ПС є од-
нією з головних причин високої ціни розро-
бки великих та складних програмних
систем.
Прогалину в технологіях останнім
часом заповнюють численні публікації за-
кордонних та вітчизняних наукових видань
щодо відновлення знань про ПС та підходів
до проведення вимушеного реінжинірингу
ПС на стадії їх функціонування та супрово-
дження [2–5], що пов`язано із значними ви-
тратами ресурсів.
Пропонується підхід, який, на відмі-
ну від реінжинірингу, дозволяє вирішувати
проблеми супроводження ПС на стадії їх
розробки, доповнюючи середовище функці-
онування ПС засобами, що забезпечують їх
життєздатність при функціонуванні та су-
проводженні. Це дозволяє суттєво скороти-
ти кошти на розробку прикладних ПС
(ППС). В основі підходу покладена оцінка
однієї з найважливіших характеристик яко-
сті ПС – життєздатність [6]. Визначенню
цієї характеристики якості через підхарак-
теристики якості стандарту ISO/IEC 9126 та
методиці її оцінки й присвячено цю статтю.
Основні показники життєздатності при-
кладних програмних систем
Прикладні програмні системи в про-
цесі функціонування та супроводження за-
знають значних змін, природою яких може
бути або уточнення моделі предметної об-
ласті, що закладена в ПС, або зміна вимог
користувача, що розглядаються як нефунк-
ціональні вимоги до ПС. За властивості ПС
швидко та безболісно зазнавати змін відпо-
відає така характеристика якості як життє-
здатність.
Програмні системи називаються жи-
ттєздатними [6], якщо вони:
• забезпечені засобами пристосування
до змін в моделі предметної області (функ-
ціональні вимоги) та змін вимог користува-
ча (нефункціональні вимоги) на стадії фун-
кціонування та супроводження ПС. Такі за-
соби можна розглядати як засоби підтримки
еволюції ПС у аспекті забезпечення їх жит-
тєздатності;
• можуть бути швидко та якісно змінені
за допомогою цих засобів. Чим швидше та
якісніше, тим більш життєздатною є
система.
Методи і засоби програмної інженерії
17
Таким чином характеристика життє-
здатності найбільш актуальна на етапі вико-
ристання та супроводження життєвого цик-
лу ПС (рис. 1). Але закладається життєздат-
ність системи на етапі проектування ПС.
Тому найбільш цікаво вміти вимірювати її
саме на цьому етапі.
Як видно з рис. 1 зміна вимог корис-
тувача, або моделі предметної області,
впливає на всі етапи життєвого циклу ПС,
але перш за все розробників цікавлять пер-
ші чотири:
1) аналіз предметної області та
вимог користувача – зручно робити за до-
помогою існуючої моделі (UML-моделі)
системи;
2) перепроектування системи –
також зручно робити за допомогою існую-
чої моделі (UML-моделі) системи. На
цьому етапі для ефективної зміни системи
доведеться аналізувати існуючу модель;
3) модифікація системи – відбува-
ється безпосередня зміна системи, тому
від життєздатної ПС очікуються такі влас-
тивості як модернізованість та стабіль-
ність. Для ефективної зміни системи дове-
деться аналізувати існуючий код;
4) тестування системи – на цьому
етапі життєздатність ПС характеризують її
тестованість та аналізованість помилок.
За класифікацією характеристик яко-
сті ПС, наведеною в ISO/IEC 9126-2, до ха-
рактеристик життєздатності ПС можна від-
нести супроводжуваність (maintainability) –
властивості ПС, що обумовлюють її ефек-
тивну модифікацію, включаючи коригуван-
ня, удосконалення або адаптацію до зміни
середовища, вимог та функціональних спе-
цифікацій, а також переносимість (portabil-
ity) – властивості ПС, що обумовлюють її
здатність бути перенесеною з однієї середи
до іншої.
Основними підхарактеристиками
якості ПС, що забезпечують необхідну жит-
тєздатність при змінах функціональних та
нефункціональних вимог, зокрема, є насту-
пні [7–9]:
• аналізованість помилок;
• аналізованість коду/моделі;
• адаптованість (модернізованість);
Рис. 1. Основні етапи життєвого циклу ПС
1. Аналіз предметної області та
вимог користувача
2. Проектування
(перепроектування) системи
3. Розробка (модифікація) системи
5. Впровадження системи
4. Тестування системи
6. Використання та
супроводження системи
7. Завершення використання
системи
Зміни моделі предметної області
або вимог користувача
Методи і засоби програмної інженерії
18
• стабільність;
• тестованість.
Аналізованість помилок (error
analyzability) – це властивості ПС, що обу-
мовлюють здатність діагностування її недо-
ліків або чинників відмов, а також ідентифі-
кації частин, які потрібно модифікувати.
Один з шляхів підвищення аналізованості
помилок програми – обробка всіх можливих
виключних ситуацій з видачею зрозумілих
користувачеві повідомлень та створення в
ПС режиму логування, тобто ведення жур-
налу подій, в якому відображалися б усі збої
ПС, час їхнього виникнення, їх зміст та, як-
що це можливо, їх причина. В ISO/IEC 9126
та відповідних вітчизняних стандартах існує
характеристика аналізованість (analyza-
bility) визначення якої повністю співпадає з
вищеописаною підхарактеристикою. Але
оскільки далі введено підхарактеристику
аналізованість коду/моделі, запропоновано
перейменувати аналізованість в аналізова-
ність помилок.
Аналізованість коду/моделі (code /
model analyzability) – це властивості ПС, що
обумовлює можливість проаналізувати про-
грамний код, його структуру. А оскільки
код має відповідати моделі, то й саму мо-
дель. Для більшої аналізованості ко-
ду/моделі програми (в рамках парадигми
об'єктно-орієнтованого програмування) кла-
си мають виконувати пов’язані між собою
задачі та не виконувати робіт непомірних
обсягів. Дана підхарактеристика не опису-
ється в ISO/IEC 9126 та відповідних вітчиз-
няних стандартах, але є необхідною для ви-
значення такої характеристики якості як
життєздатність.
Адаптованість – модернізованість
(changeability) – це властивості ПС, що обу-
мовлюють її здатність виконувати встанов-
лені види модифікацій. Слід враховувати,
що будь-яку ПС можна змінити довільним
чином і питання модифікації є лише питан-
ням часу (а тому й грошей), що витрачаєть-
ся на модернізацію. Систему слід вважати
ідеально модернізованою, якщо будь-яку
зміну (що не вимагає збільшення функціо-
нальності) можна провести, маніпулюючи
даними (або метаданими) за допомогою
штатних засобів системи. В рамках концеп-
ції забезпечення життєздатності ПС дана
система буде називатися системою з ідеаль-
ною адаптивністю.
Стабільність (stability) – це власти-
вості ПС, що обумовлюють її здатність мі-
німізувати неочікувані ефекти модифікацій.
Для забезпечення стабільності ПС має мати
якомога меншу взаємопов’язаність класів.
Тестованість (testability) – властиво-
сті ПС, що обумовлюють її здатність допо-
магати перевірці ПЗ, що модифікується. Да-
на властивість залежить від системи тесту-
вання та ПЗ, що застосовується для тесту-
вання.
Метрики для оцінки показників
життєздатності
На даний час у галузі застосування
об'єктно-орієнтованої технології розробки
ПС вироблені та сформульовані загальні
принципи та стандартні рішення, які вдос-
коналюють розробку ПС. Ці принципи та
ідіоми систематизовані і структуровані у
вигляді шаблонів (patterns). Серед широко
відомих шаблонів можна назвати такі, як
GRASP (General Responsibility Assignment
Software Patterns – загальні шаблони розпо-
ділення обов'язків у ПС) і GoF (Gang of For
– союз чотирьох) [10, 11].
Шаблони GRASP використовуються
у процесі створення діаграм взаємодій при
розподіленні обов'язків між об'єктами та
розробці способів їх взаємодії. Діаграма
взаємодій є найважливішим видом артефа-
ктів в процесі розробки об'єктно-
орієнтованих ПС. Такі види діяльності при
розробці ПС, як створення прецедентів і
відповідних сценаріїв, що знаходяться у
відношенні “клас / об'єкт”, реалізація сце-
наріїв у вигляді кооперацій і відповідних
діаграм взаємодій, що знаходяться у від-
ношенні “інтерфейс / реалізація”, є основ-
ними на різних етапах створення об'єктно-
орієнтованих ПС. Їх успішна реалізація ви-
значає успіх проекту в цілому.
Розглянемо п’ять шаблонів GRASP
[10] та їх вплив на підхарактеристики яко-
сті системи:
• High Cohesion;
• Low Coupling;
• Expert;
• Creator;
• Controller.
Методи і засоби програмної інженерії
19
Шаблон High Cohesion (сильне за-
чеплення) – забезпечує можливість керу-
вання складністю системи класів. У термі-
нах об’єктно-орієнтованого проектування
зачеплення (точніше функціональне зачеп-
лення) – це міра пов’язаності та сфокусо-
ваності обов’язків класу. Вважається, що
клас має високу ступінь зачеплення, якщо
його обов’язки тісно пов’язані між собою і
він не виконує робіт непомірного обсягу.
Класи з низькою ступеню зачеплення ви-
конують багато різнорідних функцій або
не пов’язаних між собою обов’язків. За-
стосування даного шаблону дозволяє дося-
гти більшої ясності та простоти проектних
рішень, позбутися складності розуміння
кожного класу окремо, системи класів та
моделі ПС загалом. До того цей шаблон
допомагає позбуватися таких проблем як:
складності при повторному використанні,
складність в підтримці, ненадійність та мі-
нливість ПС [10].
Із вищеописаного та з наданих ви-
значень під характеристик якості випливає
що за допомогою використання High Cohe-
sion можна підвищити аналізованість ко-
ду / моделі.
Шаблон Low Coupling (низька
пов’язаність) – забезпечує можливість ке-
рування пов’язаністю класів між собою.
Ступінь пов’язаності – це засіб вимірю-
вання того, наскільки жорстко один клас
пов’язаний з іншими, або яку кількість да-
них про інші класи він має. Основною пе-
ревагою яку здобуває проектувальник при
використанні цього шаблону є те що зміна
одних компонентів мало впливає на праце-
здатність інших об’єктів [10]. Тобто за
означенням, цей шаблон напряму
пов’язаний з такою підхарактеристикою
якості як стабільність. Іншими перевага-
ми даного шаблону є зручність повторного
використання та зрозумілість принципів
роботи класів без вивчення інших компо-
нентів.
Після аналізу визначень шаблонів
Expert, Creator та Controller [10], можна
зробити висновок, що вони сильно
пов’язані з попередніми двома шаблонами
і впливають на ті ж самі підхарактеристики
якості. Тобто, всі розглянуті шаблони тією
чи іншою мірою впливають лише на дві
підхарактеристики якості: аналізованість
коду та стабільність. Це пояснюється тим,
що лише ці дві підхарактеристики зале-
жать від взаємозв’язків між класами. Та
інші три підхарактеристики залежать від
додаткової функціональності системи.
Зазначені характеристики життєздат-
ності можуть бути оцінені на ранніх стадіях
розробки ПС за допомогою деяких метрик
(чи їх комбінацій) та UML – моделі майбут-
ньої ПС.
Так, відповідно до ISO/IEC 9126-3
аналізованість помилок (EA) ПС може бути
оцінена за допомогою метрики, яка назива-
ється готовністю функцій діагностування
(readiness of diagnostic function). Призначен-
ням даної метрики є визначення наскільки
повним є забезпечення функціями діагнос-
тування. Вимірюється дана метрика за фор-
мулою
B
A
X = , (1)
де А – кількість функцій з яких відбувається
запис до журналу активності, В – кількість
функцій з яких необхідно проводити запис
до журналу подій.
Будемо вважати, що потрібно прово-
дити запис до журналу подій з усіх функцій
та методів системи. Тому будемо викорис-
товувати різновид цієї метрики-відношення
кількості методів ПС, в яких реалізовано
можливість запису до журналу подій ПС
(|Ml|), до загальної кількості методів ПС
(|M|) (показник логування).
M
Ml
EA = . (2)
Мова UML не передбачає засобів для
безпосереднього зображення методів які ма-
ють бути записані до журналу подій, але
його можливості дозволяють розв’язати цю
задачу за допомогою стереотипів (stereo-
types) (рис. 2).
OStoreItem
store : OStore
prodSpes : OProductSpecification
quant : Double
<<WithLog>> FindItem()
<<WithLog>> GetQuant()
Рис. 2. Зображення методів призначених для
запису до журналу подій в UML
Методи і засоби програмної інженерії
20
Дана метрика вимірюється за допо-
могою абсолютної шкали на інтервалі [0, 1].
Чим ближче до 1 значення метрики, тим бі-
льша аналізованість помилок у системі.
З визначення аналізованості коду /
моделі (CМA) ПС, випливає, що ПС з більш
аналізованим кодом, буде ПС класи якої ма-
ють більший рівень функціонального зчіп-
лення (функції якого більш пов’язані між
собою). Звідси можна зробити висновок, що
з більш аналізованим кодом будуть ті ПС,
які побудовані за допомогою шаблону
GRASP High Cohesion. Для виміру
зв’язаності використовується наступна мет-
рика: PCOM (Prosperity of Cohesion), яка ви-
значається для кожного класу системи як
середнє значення відношення кількості ме-
тодів класу які використовують змінну vi
класу (Nmi) до загальної кількості методів
класу (n), k – кількість змінних класу. Ана-
лізованість коду ПС визначається як серед-
нє значення PCOM для всіх класів системи
(с – кількість класів в системі)
∑
=
=
k
i
i
n
Nm
k
PCOM
1
1
, (3)
∑
=
=
c
i
iPCOM
c
CMA
1
1
. (4)
Дана метрика вимірюється за допо-
могою абсолютної шкали на інтервалі від 0
до 1. Чим ближче до 1 значення метрики,
тим більша аналізованість коду / моделі в
системі.
Адаптованість – модернізованість
(AM) можна оцінити за допомогою відно-
шення кількості змінних та бізнес-правил
предметної області, які можна змінити за
допомогою штатних засобів системи (|BRc|),
до загальної кількості змінних, констант та
бізнес-правил предметної області (|BR|)
(модернізованість як адаптованість) [12].
BR
BRc
AM = . (5)
Дана метрика вимірюється за допо-
могою абсолютної шкали на інтервалі від 0
до 1. Чим ближче до 1 значення метрики,
тим більша адаптованість системи.
З визначення стабільності (S) ПС
витікає, що ПС з меншим рівнем взаємо-
пов’язаності класів буде більш стабільною,
ніж з більшим рівнем взаємопов’язаності.
Звідси можна зробити висновок, що більш
стабільними будуть ті ПС, які побудовані за
допомогою шаблону GRASP Low Coupling.
Для виміру зв’язаності використовуються
наступні метрики: CBO (зв'язування між
об'єктами), CBOin (зв'язування між об'єкта-
ми в ієрархії наслідування), CBOout (зв'язу-
вання між об'єктами без ієрархії насліду-
вання) [13, 14]. Для виміру стабільності ви-
беремо CBOout яка визначається як:
IcMccCBOout −=)( , (6)
де Мс – набір класів, які залежать
(викликають методи або звертаються до
змінних) від класу С, Іс – набір класів які
знаходяться з класом С у відношенні під-
клас-суперклас. Тоді стабільність системи
можна визначити як середнє СВОout за всі-
ма класами системи.
∑
=
=
c
i
outCBO
c
S
1
1
. (7)
Дана метрика вимірюється за допо-
могою абсолютної шкали на інтервалі від 0
до нескінченності. Чим ближче до 0 значен-
ня метрики, тим більша стабільність
системи.
Відповідно до ISO/IEC 9126-3 тес-
тованість (T) ПС може бути оцінена з до-
помогою метрики, яка називається повнота
вбудованого теста (completeness of build-in
test). Призначенням даної метрики є визна-
чення наскільки повними є можливості вбу-
дованого тесту. Вимірюється дана метрика
за формулою
B
A
X = , (8)
де А – кількість вбудованих тестів призначе-
них для реалізації, В – кількість потрібних
вбудованих тестів.
Будемо вважати, що вбудовані тести
мають бути реалізовані для кожного класу
системи. Тоді в якості метрики тестованості
можна прийняти відношення кількості кла-
сів ПС, до яких написані тестові класи, до
загальної кількості класів ПС. Дана метрика
буде виміряти загальну тестованість ПС.
Але оскільки багато класів ПС вико-
нують допоміжні функції і може виникнути
потреба оцінити тестованість ПС насампе-
ред з точки зору предметної області (напри-
клад, нас може не цікавити тестованість
графічного інтерфейсу користувача, але ці-
кавить правильність виконання бізнесових
Методи і засоби програмної інженерії
21
обрахунків чи інших функцій системи з пе-
реліку функціональності ПС). Для цього ви-
падку більш підійде такий спосіб вимірю-
вання метрики: відношення кількості сцена-
ріїв системи (UCTN – Use Case Tested Num-
ber), які перевіряються тестовими класами,
до загальної кількості сценаріїв ПС (UCN –
Use Case Number).
UCN
UCTN
T = . (9)
Назвемо дану модифікацію метрики,
що вимірює тестованість системи, як тес-
тованість ПС в термінах предметної
області.
Мова UML не передбачає засобів для
безпосереднього зображення сценаріїв для
яких мають бути створені тести, але його
можливості дозволяють розв’язати цю зада-
чу за допомогою стереотипів (stereotypes)
(рис. 3).
Дана метрика вимірюється за допо-
могою абсолютної шкали на інтервалі від 0
до 1. Чим ближче до 1 значення метрики,
тим більша тестованість системи.
Рис. 3. Зображення сценаріїв для яких має
бути створено тести в UML
Оцінювання та прийняття рішень
Схема моделювання та одержання
варіанта проекту ПС, який має оцінки під-
характеристик життєздатності, що задово-
льняють вимоги користувача ПС, зображена
на рис. 4 [15].
У відповідності до цієї схеми на базі
„матеріалізованого досвіду” розробників
(шаблонів проектування GRASP) були ви-
значені метрики деяких підхарактеристик
життєздатності. Але для інтегрального оці-
нювання життєздатності потрібно ввести
такі шкали вимірювання її підхарактерис-
тик, які дозволяють порівнювати ці підхара-
ктеристики. В подібних випадках краще за
Варіанти про-
екту
Шаблони та
принципи
проектування
Метрики
життєздатност
і
UML-
модель ПС
Діаграми
взаємодії
Реліз ПС
Оцінки
життєздатн
Вимоги ко-
ристувача
Отримання
Моделю-
Внесення
Вибір Обмежують
Визначають
Спрямову-
ють
Визначають
Визначає
Визначає
Включає Змінює
Утворює
Вклю-
чає
Відповідає
Відповідають
Включає
Використо-
вує
Включає
Враховує
Базуються
Рис. 4. Схема моделювання та оцінювання характеристик життєздатності об’єк-
тно-орієнтованих ПС при їх створенні, модифікації та реінжинірингу
«With Test» 2.02 Перегляд об’ємів
продажу по клієнтах
Методи і засоби програмної інженерії
22
все використовувати бальні шкали для кож-
ної підхарактеристики і отримувати інтег-
ральне оцінювання життєздатності за допо-
могою вагових коефіцієнтів.
Даний розділ присвячений методиці
отримання інтегральної оцінки життездат-
ності та проведенню її вимірювання на при-
кладі UML-моделі CRM-системи.
Абсолютні шкали, в яких вимірю-
ються підхарактеристики життєздатності,
дозволяють порівнювати однакові підхарак-
теристики різних моделей системи. Але для
отримання інтегральної оцінки життєздат-
ності системи на основі оцінок підхаракте-
ристик життєздатності та порівняння цих
інтегральних оцінок різних моделей систе-
ми необхідно використовувати шкали для
метрик кожної з п’яти підхарактеристик
життєздатності. Всі оціночні шкали мають
однакову розмірність: 1 – погано, 2 – неза-
довільно, 3 – задовільно, 4 – добре, 5 – від-
мінно.
Бальну оцінку характеристики буде-
мо позначати літерою В з індексом з назви
характеристики. Наприклад, бальну оцінку
стабільності будемо позначати як ВS, аналі-
зованості помилок – ВEA та ін.
Кожен розробник може сам визначати
які підхарактеристики життєздатності є для
нього більш важливі. Тому вагові коефіціє-
нти підхарактеристик життєздатності буде-
мо визначати експертним методом, з розра-
хунком, що їх сума дорівнює одиниці. Але
для порівняльної оцінки різних моделей
мають використовуватися одні й ті самі ва-
гові коефіцієнти.
Отримані вагові коефіцієнти знахо-
дяться в табл. 1.
Тоді бальна оцінка життєздатності всі-
єї системи буде визначатися за формулою:
.TTSSAMAM
CMACMAEAEAsys
KBKBKB
KBKBB
+++
++=
(10)
Проведемо оцінку підсистеми “Про-
дажі” CRM-системи. Діаграма класів цієї
підсистеми показана на рис. 5.
Для того щоб було можливо виміря-
ти ЕА пропонуємо для методів ввести спе-
ціальний “стереотип” WithLog, як показано
на рис. 5.
Тоді за формулою (2) ЕА = 8/25 =0,72.
У відповідності зі схемою на рис. 5
BEA = 5.
На рис. 6 зображено клас OStoreItem –
клас позицій товарів, що є на складі, з всіма
його атрибутами та методами. Змінні
prodSpec та store доступаються з кожного
метода класу, quant – лише з GetQuant.
Тому за формулою (2) РСОМ
(OStoreItem) = (2/2+2/2+1/2)/3 = 0,83.
Величини РСОМ для всіх класів під-
системи записано в табл. 2.
Таблиця 1. Відповідність виміряних значень підхарактеристик бальним значенням та вагові
коефіцієнти підхарактеристик
Бальна оцінка підхарактеристики якості Вагові коефіцієнти Підхаракте-
ристики 1 2 3 4 5 Позначення Значення
Аналізованість
помилок [0-0.3] (0.3-0.45] (0.45-0.55] (0.55-0.7] (0.7-1] KEA 0,25
Аналізованість
коду/моделі [0-0.01] (0.01-0.03] (0.03-0.1] (0.1-0.3] (0.3-1] KCМA 0,25
Адаптованість [0-0.2] (0.2-0.4] (0.4-0.6] (0.6-0.8] (0.8-1] KAM 0,1
Стабільність [50-∞] (30-50] (15-30] (5-15] [0-5] KS 0,2
Тестованість [0-0.3] (0.3-0.5] (0.5-0.7] (0.7-0.9] (0.9-1] KT 0,2
Таблиця 2. Значення РСОМ для різних
класів підсистеми
Назва класу Величина
РСОМ
OStore 0,21
OStoreItem 0,83
OProductSpecification 0,3
OProductCatalog 0,6
OSale 0,1
OSalesLineItem 0,7
OSalesHistory 0,12
OCRMSystem 0,05
Методи і засоби програмної інженерії
23
Зазначимо, що класи OWorker та
OClient зображені на діаграмі класів лише
для більшого зрозуміння функцій підсисте-
ми, та не виконують функцій у рамках цієї
підсистеми.
За формулою (4) визначимо, що
СА = 0,36.
У відповідності з схемою на рис. 6
BСA = 5.
Системні аналітики визначили, що
дана підсистема має лише одну системну
змінну (визначення ПДВ у розмірі 20 %),
яку можна змінити штатними засобами сис-
теми. Тому значення АМ = 1 у відповідності
з схемою на рис. 4 BAМ = 5.
На рис. 7 зображена діаграма преце-
дентів підсистеми “Продажі”. Де стереотип
WithTest мають ті прецеденти підсистеми
які будуть мати тестові класи.
За формулою (9) Т = 0,33, тому у від-
повідності з схемою на рис. 5 BТ = 2.
За діаграмами взаємодії для операцій
підсистеми (див. рис. 8–15) у відповідності з
формулою (6), визначимо значення CBOout
для кожного з класів підсистеми.
Рис. 5. Приклад позначення на діаграмі класів методів, що мають логування
OStoreItem
store : OStore
prodSpes : OProductSpecification
quant : Double
<<WithLog>> FindItem()
<<WithLog>> GetQuant()
Рис. 6. Клас OStoreItem з всіма його атрибутами та методами
Методи і засоби програмної інженерії
24
Таблиця 3. Значення CBOout для різних класів підсистеми
Назва класу Величина CBOout
OStore 1
OStoreItem 1
OProductSpecification 2
OProductCatalog 1
OSale 2
OSalesLineItem 1
OSalesHistory 1
OCRMSystem 0
OWorker Не оцінюється
OClient Не оцінюється
Рис. 8. Операція “створення продажі”
Рис. 9. Операція “завершення продажі”
Рис. 7. Діаграма прецедентів підсистеми “Продажі” CRM-системи
Методи і засоби програмної інженерії
25
Рис. 10. Операція “отримання історії продажів за групами товару”
Рис. 11. Операція “отримання обсягу продажів за клієнтом”
Рис. 12. Операція “отримання історії продажів”
Рис. 13. Операція “складання ділової пропозиції”
Рис. 14. Операція “додавання пункту продажі”
Рис. 15. Операція “перегляд даних про наявність товарів на складі”
Методи і засоби програмної інженерії
26
Тоді за формулою (7) S = 1,125.
У відповідності з схемою на рис. 5 BS = 5.
За формулою (10), визначимо інтег-
ральну оцінку життєздатності підсистеми
“Продажі” типової CRM-системи.
BSYS = 5 · 0,25 + 5 · 0,25 + 5 · 0,1 + 5 · 0,2 +
+ 2 · 0,2=4,4 (Добре).
Проведення досліджень та розробка
методики забезпечення показників життє-
здатності прикладних програмних систем
здійснювалась за програмою фундамента-
льних досліджень Інституту програмних си-
стем НАН України за темою “Розробка
теоретичного підгрунтя та інструмен-
тальних засобів супроводження прикладних
програмних систем”. Автор висловлює щи-
ру вдячність керівнику теми кандидату тех-
нічних наук П.П. Ігнатенку за постановку
задачі та поради щодо її вирішення.
Висновки
Таким чином у відповідності з роз-
робленою раніше схемою моделювання та
оцінювання характеристик життєздатності
об’єктно-орієнтованих ПС при їх створенні,
модифікації та реінжинірингу (рис. 4) ви-
значено основні підхарактеристики життє-
здатності ПС, вплив деяких шаблонів прое-
ктування на ці підхарактеристики, метрики
за допомогою яких вони вимірюються, роз-
роблено оціночні шкали для метрик та на
прикладі підсистеми продажу загальної мо-
делі класу CRM-систем показали методику
оцінки характеристик життєздатності про-
грамної системи за її UML-моделлю.
За описаною методикою можна по-
рівнювати два або більше варіанти моделей
системи, як за окремими підхарактеристи-
ками якості так і в цілому, з урахуванням
вподобань замовників. Також методика доз-
воляє отримувати загальну оцінку життє-
здатності одного варіанта системи, з ураху-
ванням важливості підхарактеристик якості
для замовників.
1. Ігнатенко П.П. Проблеми забезпечення
життєздатності програмних систем та під-
ходи до їх вирішення // Проблемы програм-
мирования. – 2002. – № 3-4. – С. 58–73.
2. Ed. Robert S. Arnold. Software Reengineering
// IEEE Comput. Soc. Press. – 1994. – 676 р.
3. Ігнатенко П.П., Неумоїн В.М., Бистров В.М.
Аспекти реінжинірингу програмних систем
// Проблемы программирования.– 2000.–
№ 1 – 2. – С. 367–375.
4. Ігнатенко П.П., Неумоїн В.М., Бистров В.М.
Про забезпечення ефективного реінжиніри-
нгу прикладних програмних систем // Про-
блемы программирования. – 2001. - №1-2. –
С. 42 - 52.
5. Ігнатенко П.П., Бистров В.М., Заєць І.О.,
Ігнатенко О.П. Підхід до забезпечення ре-
інжинірингу об’єктно-орієнтованих про-
грамних систем // Проблемы программиро-
вания. – 2002. – №1-2. – С. 98–108.
6. Ігнатенко П.П., Бистров В.М., Ігнатенко
О.П., Ткаченко В.М. Задачі та засоби моде-
лювання і оцінювання життєздатних про-
грамних систем // Проблеми програмування.
– 2003. – № 3 – С. 59–70.
7. ISO/IEC 9126: Software Engineering – Soft-
ware Product Quality Part 1–4.
8. Андон Ф.И., Коваль Г.И., Коротун Т.М., Су-
слов В.Ю. Основы инженерии качества про-
граммных систем. – Киев.: Академперио-
дика, 2002. – 504 с.
9. Бабенко Л.П., Лаврищева Е.М. Основи про-
грамної інженерії. – К.: “Знання”. – 2001. –
269 с.
10. Ларман К. Применение UML и шаблонов
проектирования. – М.: Вильямс, 2001. –
496 с.
11. Gamma E., Helm R., Johnson R., and Vlissides
J. Design Patterns, Elements of Reusable Ob-
ject-oriented Software, – N. – Y.: Addison–
Wesley, 1995. – 345 p.
12. Chidamber S., Kemerer C.. A metrics suite for
object-oriented design // IEEE Transaction
Software Engineering. – 1994. – 20(6). –
Р. 476–493.
13. Chidamber S., Kemerer C.. Towards a metrics
suite for object-oriented design // Conf. Object-
Oriented Programming System, Languages and
Applications (OOPSLA’91). – 1991. –
Р. 197–211.
14. Auer K., Miller R. Extreme programming ap-
plied: playing to win - Pearson Education,
2002. – 326 р.
15. Ігнатенко П.П., Ткаченко В.М., Стрєлков
І.А., Дуднік Р.О. Концепція створення моде-
лі прикладної програмної системи з розви-
нутою функцією життєздатності // Пробле-
ми програмування. – 2004. – № 2–3. (спец.
вип.) – С. 163–172.
Получено 14.03.2006
Методи і засоби програмної інженерії
27
Об авторе:
Ткаченко Володимир Миколайович,
молодший науковий співробітник.
Місце роботи автора:
Інститут програмних систем НАН України,
03680, Київ-187,
проспект Академіка Глушкова, 40.
тел. (044) 496 9313
e-mail: v.tkachenko@ekotex.kiev.ua
|
| id | nasplib_isofts_kiev_ua-123456789-2328 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T15:39:17Z |
| publishDate | 2006 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Ткаченко, В.М. 2008-09-17T14:53:16Z 2008-09-17T14:53:16Z 2006 Методика оцінювання деяких характеристик якості прикладних програмних систем / В.М. Ткаченко // Проблеми програмування. — 2006. — N 4. — С. 16-27. — Бібліогр.: 15 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/2328 681.3 Розглянуто основні складові такої характеристики якості як життєздатність та запропоновано методику їх оцінки: метрики, за допомогою яких вимірюються підхарактеристики життєздатності, розкрито зв`язок цих метрик з шаблонами проектування GRASP, шкали для вимірювання зазначених метрик та методика отримання інтегральної оцінки життєздатності. Рассмотрены основные составные такой характеристики качества как жизнеспособность и предложено методику их оценки: метрики с помощью измеряются подхарактеристики жизнеспособности, раскрыто связь этих метрик с шаблонами проектирования GRASP, шкалы для измерения указанных метрик и методика получения интегральных оценок жизнеспособности. There is an overview of base parts of viability is given and evaluation methods of it are proposed in this article. Metrics for viability measurement was chosen. A correlation of these metrics and General Responsibility Assigned Pattern was exposed and scales for metrics evaluation were presented. uk Інститут програмних систем НАН України Методи і засоби програмної інженерії Методика оцінювання деяких характеристик якості прикладних програмних систем Методика оценки некоторых характеристик качества прикладных программных систем Evaluation principles for some software quality characteristics Article published earlier |
| spellingShingle | Методика оцінювання деяких характеристик якості прикладних програмних систем Ткаченко, В.М. Методи і засоби програмної інженерії |
| title | Методика оцінювання деяких характеристик якості прикладних програмних систем |
| title_alt | Методика оценки некоторых характеристик качества прикладных программных систем Evaluation principles for some software quality characteristics |
| title_full | Методика оцінювання деяких характеристик якості прикладних програмних систем |
| title_fullStr | Методика оцінювання деяких характеристик якості прикладних програмних систем |
| title_full_unstemmed | Методика оцінювання деяких характеристик якості прикладних програмних систем |
| title_short | Методика оцінювання деяких характеристик якості прикладних програмних систем |
| title_sort | методика оцінювання деяких характеристик якості прикладних програмних систем |
| topic | Методи і засоби програмної інженерії |
| topic_facet | Методи і засоби програмної інженерії |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/2328 |
| work_keys_str_mv | AT tkačenkovm metodikaocínûvannâdeâkihharakteristikâkostíprikladnihprogramnihsistem AT tkačenkovm metodikaocenkinekotoryhharakteristikkačestvaprikladnyhprogrammnyhsistem AT tkačenkovm evaluationprinciplesforsomesoftwarequalitycharacteristics |