Варіант предметної області №67.

Робота інтернет-магазину з продажу побутової техніки. Основною

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

1. Інженерія вимог з використанням методу Шлейєр і Меллора

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

Побудова Вимог
Побудова інформаційної моделі домену.
1
 На першому етапі визначимо об’єкти які відносятся до обраного домену.
Ролі: Замовник, Менеджер, Кур'єр.
Реально існуючі предмети: База даних.
Абстракції предметів:Каталог, Замовлення, Гостьова книга.
Перейдемо до побудови діаграми.
Система об’єктів та зв’язків між ними матиме наступний вигляд (рис. 1).

Рисунок 1. Інформаційна модель домену

Визначення відношеня спадкування

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

2
 Рисунок 2. Діаграма спадкування

Побудова діаграми та таблиці переходів у стани.

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

3
 Рисунок 3. Діаграма переходів у стани

На основі отриманої діаграми складемо відповідну таблицю (табл. 1).

4
 C
n\ П П П П П П П П
П 1 2 3 4 5 6 7 8
n
С
2
1
С
3
2
С
4
3
С
5 6
4
С
4
5
С
7
6
С
7 8

Таблиця 1. ТПС замовлення

Побудова моделі процесів у вигляді діаграми потоків даних (ДПДД).

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

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

Рисунок 4. Діаграма потоків даних дій для замовлення

На основі отриманої ДПДД побудуємо загальну таблицю процесів

(табл.2).
Ідентифікатор Повна назва Назва стану, у якому
Тип процесу Назва дії стану
процесу процесу визначений процес
аксесор, Переглянуто Перегляд каталогу
1 генератор каталог та обрано Перегляд каталогу товарів побутової
подій товар тезніки
Сформоване формування
генератор замовлення та Формування замовником певного
2
подій отримане замовлення замовлення з
менеджером обраним товаром
Менеджер
генератор зателефонував Менеджер прийняв
3 подій, процес- замовнику за Прийом замовлення замовлення та
обчислення підтвердженням обробив його
замовлення
генератор
Передача на Підтвердження Корегування
4 подій,
корегування замовлення замовлення
перевірка умов
5 генератор Знову корегування Підтвердження
подій зателефонувати Корегованого
замовнику за замовлення
підтвердженням
корекцій

6
 замовлення
Замовення
генератор
підтверджено та Передача замовлення
6 подій, процес- Передача кур’єру
готується для кур’єру
обчислення
передачі кур'єру
Кур’єру Отримав
генератор замовлення та Отримання
7 Доставка замовлення
подій організував замовлення
доставку
генератор Замовник отримав Передача товару
8 Отримння замовником
подій товар замовнику

Таблиця 2. Процеси ДПДД

7
 2. Інженерія вимог з використанням методології І.Джекобсона
Побудова сценаріїв програмної системи
Аналізуючи інформаційну модель системи визначимо основні сценарії її
використання користувачами. Використання системи полягає у створенні,
заповненні та перегляді електронних документів, тому відповідно маємо
наступні сценарії:
1. Перегляд каталогу — користувач, у даному випадку він є замовник,
виконує перегляд каталогу усіє продукції, яку надає інтернет-магазин з
ціллю зробити замовлення.
2. Вибір продукції — вибравши потрібну замовнику продукцію, він
виконує замовлення яке відправляється на обробку менеджером.
3. Залишення відгуку у гостьовій книзі — після того, як користувач
отримав товар, або не отримав, з деяких причин, він може зайти до
гостьової книги та залиши свій відгук про інтернет-магазин.
4. Обробка замовлення — менеджер отримує замовлення та формує його
для обробки магазином( перевіряє наявність та відповідність обраному
товару з тим що є з цим номером на складі), формує повну вартість
замовлення, вибираючи та добавляючи кур’єрські послуги та їх
вартість.
5. Підтвердження замовлення — після обробки та організації замовлення,
менеджер обов’язково повинен звітувати замовника про маніпуляції,
які він проводив із замовлення, оповістити його про повну вартість
замовлення та для передачі кур’єру підтвердити всі зміни та вибір
замовника власноруч.
6. Корегування інформації магазину — менеджер повинен підтримувати
відповідність переліку товарів з каталогом, замовленнями,
замовниками, наданням кур’єрських послуг та ведення гостьової
книги, тобто усієї інформації стосовно інтернет-магазину.
7. Передача кур’єру — передача безпосередньо самої інформації що до
замовлення кур’єру, підтвердження на видачу товару на складі.
Серед користувачів що можуть ініціювати події в системі можна виділити
наступних:
1. Менеджер — Користувач системи який приймає та підтверджує
замовлення, організовує інформацію що до переліку товарів та
загальної, яка відноситься до інтернет-магазину.
2. Замовник — користувач системи, який звертається до її послуг за
допомогою у виборі товарів, їх замовленні, та має можливість
залишити відгук про інтернет-магазин.

8
 З вище зазначеного побудована діаграма сценаріїв ПС яка зображена на
рис. 1. Також отримані діаграми розширення для сценарію «формування
замовлення»(рис. 5) та діаграми відношення «використання» також для
сценарію «формування замовлення»(рис. 6).

Рис 5. Діаграма сценаріїв для інтернет-магазину побутової техніки

Рис 6. Діаграма розширення сценарію «формування замовлення»

9
 Рис 7. Діаграма відношення “використовує” для сценарію «формування замовлення»

Побудова діаграми взаємодії об’єктів

На основі описаних сценаріїв використання системи побудуємо взаємодії
об’єктів для отриманого сценарію «формування замовлення» та сценарію
«корегування інформації товарів». Вибір сценарію «формування замовлення»
базується на тому, що це загальний сценарій роботи інтернет-магазину, робота
якого залежить від замовлень і також є функцією виконання обов’язків
менеджера для обслуговування замовника. Також сценарій «корегування
інформації магазину» менеджером є важливим сценарієм, функція якого
полягає у першочерговому наданні інформації замовнику, та у разі
невідповідності інформації її швидке корегування. Автоматизація цих сценаріїв
відіграє важливу роль у проектуванні ПС та стоїть метою завдання.
В процесі створення діаграм для сценарію «формування замовлення»
(рис. 4) було виділено наступні значущі об’єкти:
Об’єкт – інтерфейс:
1. Керування БД — система керування контролює екземпляри реляційної
БД ПС, приймає запити на вибірку, перегляд, зміну чи збереження
даних які використовує інтернет-магазин, за допомогою певних
операцій.
Об’єкт – сутність:
1. Каталог товарів — елемент БД у вигляді таблиці який відповідає за
список, перелік, та опис товарів побутової техніки, що надає магазин.
Завдяки каталогу замовник має змогу обирати, переглядати оцінювати,
порівнювати товари побутової техніки які йому потрібні.
2. Таблиця кур’єрів — елемент БД у вигляді таблиці яка відповідає
інформації стосовно усіх кур’єрів які надають свої послуги, вартість їх
послуг та можливостей.
Керуючий об’єкт:
Основними керуючими об’єктами системи є менеджер який виконує всі
керуючи дії відносно інтернет-магазину та сайту Інтернет-магазину. Також
10
 для виконання обов’язків менеджера використовується системи керування
базами даних.
Також в процесі створення діаграми для сценарію «корегування
інформації магазину» (рис. 8) було виділено наступні значущі об’єкти:
Об’єкт – інтерфейс:
1. Керування БД — система керування контролює екземпляри реляційної
БД ПС, приймає запити на вибірку, перегляд, зміну чи збереження
даних які використовує інтернет-магазин, за допомогою певних
операцій.
Об’єкт – сутність:
1. Каталог товарів — елемент БД у вигляді таблиці який відповідає за
список, перелік, та опис товарів побутової техніки, що надає
магазин. Завдяки каталогу замовник має змогу обирати,
переглядати оцінювати, порівнювати товари побутової техніки які
йому потрібні.
2. Таблиця замовлень — основний об’єкт ПС навколо якого
відбуваються події, оскільки він являється об’єктом автоматизації, і
об’єктом роботи інтернет- магазину.
3. Таблиця замовників — елемент БД у вигляді таблиці яка відповідає
усім даним стосовно замовників, тобто клієнтів Інтернет-магазниу,
їх персональні данні, попередні замовлення, контактні данні, та
інше.
4. Таблиця кур’єрів — елемент БД у вигляді таблиці яка відповідає
інформації стосовно усіх кур’єрів які надають свої послуги, вартість
їх послуг та можливостей.
5. Гостьова книга — елемент БД у вигляді таблиці який відповідає за
змогу замовнику залишити свій відгук про Інтернет-магазин
стосовно будь-якого аспекту замовлення, його виконання, доставки
та інше.
Керуючий об’єкт:
Основними керуючими об’єктами системи є менеджер, який виконує всі
керуючи дії відносно інтернет-магазину та сайту Інтернет-магазину. Також для
виконання обов’язків менеджера використовується СКБД.

11
 Рис 8. Діаграма взаємодії об’єктів для сценарію «формування замовлення»

Рис 9. Діаграма взаємодії об’єктів для сценарію «Корегування інформації магазину»

12
 3. Побудова моделей якості програмної системи відповідно до
стандарту ISO/IEC 9126

Побудова Моделей якості ПС

Модель зовнішньої якості
Модель зовнішньої якості зображена на рис. 10.

Рис. 10. Модель зовнішньої якості

Атрибути моделі якості

1. Функціональність
1.1. Функціональна повнота
 Список функцій — перелік функцій які виконує ПС та ті, можливо
не повністю реалізовані, або некоректно.
1.2. Захищеність
 Реєстр — реєстр доступу до ПС, ідентифікування користувачів,
аувтентифікування користувачів.
2. Надійність
2.1. Завершеність
 Головні функції — Перелік усіх безпосередньо відповідних до вимог
функцій, які виконють поставлені перед ПС головні задачі.
2.2. Відновлюванність
 Періодичне Резервне копіювання — можливість відновити
працездатність системи у разі її відмови, за допомогою отриманої
точки яку було збережено за певний період часу до відмови
3. Зручність використання
3.1. Вивчаємість
 ІнфоСправка до ПС — допомогає системі отримати здатність бути
освоєною для повного використання любим користувачем,
13
 моніторинг звернень до допоміжних матеріалів та інформаційна
підтримка
3.2. Привабливість
 Персоналізація — яка допоможе у індивідуалізація використовуючих
системою функцій
4. Супроводжуваність
4.1. Стабільність
 Записи моніторингу— які вестимуть моніторинг працездатності
функцій та роботи системи з можливістю зберігати результати.
4.2. Тестованість
 Робочі звіти ПС — Наявність записів у формі звітів з виконання
функцій ПС, використання ПС.

Відображення вимог якості

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

14
така вимога до програмної системи становиться не дуже суттєвою для її
виділення у вимогах зовнішньої якості.
Також вимога ефективності є не суттєвою для виділення у поставленій
програмній системі, оскільки усі процеси які буде виконувати система не є
швидкісними. Процес замовлення товару замовником потребує певний час, і
його будуть займати такі події як перегляд каталогу, очікування відповіді від
менеджеру, заповнення якихось даних та інші процеси які є повільно текучими.
Конфліктуючи характеристики
Конфліктуючими характеристиками є захищеність, яка конфліктує з
стабільністю, оскільки у разі виникнення несанкціованного доступу до ПС,
виявлення атак, стабільність працездатності системи може буде під загрозою.
Також конфліктуючими є функціональна повнота та завершеність, так як
функції ПС які не повністю реалізовані, не можуть відповідати завершеності
ПС.
Визначення вагових коефіцієнтів
При визначенні вагових коефіцієнтів скористаємося шкалою вагів від 10
до 100, вказавши таким чином на пріоритетність атрибутів у процесі оцінки
якості.
Характеристика Підхарактери- Назва атрибута Метрика Вага
Сi стика Aijk Mijk Wijk
Сij
Функціональність Функціональна Список функцій Functional 80
повнота implementation
Захищеність Реєстр Access auditability 100
Надійність Завершеність Головні функції Fault removal 80
Відновлюва- Періодичне Резервне Restartability 50
ність копіювання
Зручність Вивчаємість ІнфоСправка до ПС Effectiveness of the 60
використання user documentation
and/or help system
Привабливість Персоналізація Attractive interaction 70
Супроводжуваність Стабільність Записи моніторингу Modification impact 80
localisation
( Emerging failure
after change)
Тестованість Робочі звіти ПС Test restartability 50

Таблиця 3. Специфікація моделі зовнішньої якості

15
 Модель експлуатаційної якості
На основі концепції програмної системи та моделі зовнішньої якості
доцільним є включення до моделі експлуатаційної якості наступних
характеристик (рис. 11):

Рис 11. Модель зовнішньої якості

Визначення метрик експлуатаційної якості

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

Відображення характеристик зовнішньої якості на характеристики

експлуатаційної якості
1. Результативність
– Перелік реалізованих функцій(Task Completion)
– Список помилок допущених користувачем(Error frequency)
2. Безпека
– Список заявок користувачів про ураження ПС(Software damage)
3. Задоволеність

16
 – Перелік оцінок системи серед опитаних осіб, які
користувались(Satisfaction scale)
4. Продуктивність
– Список значень з таймерів виконання функцій(Task Time)
Відображення характеристик зовнішньої якості на характеристики
експлуатаційної якості
Результативність та безпека ПС залежить безпосередньо від таких
зовнішніх характеристик як функціональність та надійність, так як саме вони
характеризують систему в плані повноти та якості реалізованих в ній функцій, а
також визначають її стійкість у роботі, під впливом зовнішнього середовища
Задоволеність здебільшого залежить від якості реалізації не
функціональних вимог. Ключовими зовнішніми характеристиками в даному
випадку будуть зручність у використанні та задоволеність.
Також безпосередньо від якості супроводу, тестів моніторингу залежить
якість роботи, та стабільності ПС. Відповідно від того як розробник буде
супроводжувати ПС, та уникати відмов, поправлення помилок, буде залежати
продуктивність ПС, тому такі характеристики як Супроводжуваність, а також
надійності, так як у разі відмови, відновлені данні також відіграють важливу
роль (рис. 12).

.
Рис. 12. Діаграма відповідності характеристик зовнішньої та експлуатаційної якості

17
 4. Оцінка рівня якості програмної системи з використанням
метрик стандарту ISO/IEC 9126.
Оцінювання зовнішньої якості

Рисунок 13. Модель зовнішньої якості

Атрибути моделі якості
Рівень якості для побудованої моделі зовнішньої якості будемо
вимірювати за допомогою визначених для атрибутів ПС метрик (табл. 4).
Характеристика Підхарактери- Назва атрибута Метрика Вага
Сi стика Aijk Mijk Wijk
Сij

Функціональність Функціональна Список функцій Functional 80

повнота implementation
Захищеність Реєстр Access auditability 100
Надійність Завершеність Головні функції Fault removal 80
Відновлюваність Періодичне Резервне Restartability 50
копіювання
Зручність Вивчаємість ІнфоСправка до ПС Effectiveness of the user 60
використання documentation and/or
help system
Привабливість Персоналізація Attractive interaction 70
Супроводжуваність Стабільність Записи моніторингу Modification impact 80
localisation
( Emerging failure after
change)
Тестованість Робочі звіти ПС Test restartability 50
Таблиця 4. Специфікація моделі зовнішньої якості

18
 Назва Призначення Метод застосування Формула та елементи інтерпретац Тип шкали Тип міри Вихідні данні Процес ЖЦ
даних ія
виміряних
даних
Functional Наскільки Виконати тестування Х=1-А/В 0<=X<=1 Абсолютна А=кількість Спкеціфікації 6.5 Валідаці;
implementation правильно системи відповідно до А=кількість некоректно Чим ближче В=Кількість вимог; Звіт 6.3 Забезпечення
реалізовано специфікації вимог, на реалізованих або до 1, тим Х=Кількість/ оцінки якості;
функції пердмет конкретно відсутніх функцій; краще. Кількість 5.3 тестування
реалізованих функцій В=Кількість функцій в
специфікації вимог
Access auditability Наскільки повний Оцінити кількість Х=А/В 0<=X<=1 Абсолютна А=кількість Спкеціфікації 6.5 Валідація
контроль за доступів до системи А=Кількість записів про Чим ближче В=Кількість тестування; Звіт
доступом зареєстрованих в доступ до 1, тим Х=Кількість/ тестування
користувачів до журналі В=Кількість виконаних краще. Кількість
системи? спроб доступу під час
оцінки.
Fault removal Наскільки багато Килькість виправлених а) X= A / В 0<=X<=1 Абсолютна А=кількість Звіт тестування, 5. 3
помилок було помилок протягом Чим ближче В=Кількість Організація бази Розробницьке
виправлено тестування та суміщення А = кількість до 1, тим С=Кількість даних впровадження
з усіма номерами виправлених помилок краще. Х=Кількість/ 6.5 Валідація
помилок В = глобальна кількість Кількість 6.3 Забезпечення
актуальних помилок Y=Кількість/ якості
Кількість
b) Y= A / С
С = глобальна кількість
прелсказуємих скрітіх
помилок у ПС
Restartability Наскільки часто Кількість разів рестарту X=A/B 0<=X<=1 Абсолютна А=кількість Звіт тестування 5.3
19
 система може системи і проводення Чим більше Звіт операцій пользовательская
рестартуватися сервісу для поставленої A= Кількість рестартів та ближче до В=Кількість інтеграція
для сервису на кількості рестартів у які зустрілися з 1.0 тим Х=Кількість/ 5.3
заданий час період пробного поставленим часом краще. Кількість Квалификаційні
виористання підчас тестів тести
B= Повна кількість 6.5 Валідація
рестартів підчас тестів.
Effectiveness of the Яка пропорція Провести тест Х= A / B 0<=X<=1 Абсолютна А=кількість Операційні тести 6.5 Валідація
user documentation задач може бути користувача і Чим ближче В=Кількість та користувача
and/or help system скомпільована спостерігати за A= Кількість завдань до 1, тим Х=Кількість/ звіт,користувацьк 5.3
коректно після поведінкою користувача. успішно завершив після краще. Кількість ий моніторинг та Кваліфікаційні
використання отримання доступу до записи тести
користувацької Підрахуйте кількість оперативної довідки та / 5.4 Операція
документації завдань успішно або документації дизайну
завершених після інтерфейсу
отримання доступу до B = повна кількість
оперативної довідки та / тестованих завдань
або документації і
порівняти із загальним
числом завдань
Attractive Наскільки Анкета для користувачів Анкета для оцінки Залежить від Абсолютна Кількість Результати 6.5 Валідація
interaction привабливий привабливості способу його анкетування користувача
інтерфейс інтерфейсу для анкета 5.3
користувача? користувачів, після оцінок Кваліфікаційні
досвіду використання тести
5.4 дизайн
інтерфейсу
Modification impact Може користувач Граф помилок X= A / N 0<=X Абсолютна А=кількість Звіт Рішення 5.3

20
 localisation управляти входження після зміни, Чим менше проблеми Кваліфікаційні
A= Число відмов
( Emerging failure системою які взаємно ланцюжки і та ближче до И=Кількість тести
виникли після відмови не
after change) програмного залежить від змін. буде вирішена зміною 0 тим краще. Х=Кількість/ звіт про роботу 5.4 Операція
протягом зазначеного
забезпечення без Кількість дизайну
періоду
збоїв після N= Кількість дозволених інтерфейсу
відмов
технічного 5.5 підтримка
обслуговування?

Може
Супроводжуючий
легко пом'якшити
збої, викликані
побічними
обслуговування
ефекти?
Test restartability Може користувача Дотримуйтесь поведінку X=A/B 0 <= X <=1 Абсолютна А=кількість Звіт Рішення 5.3
і супроводжуючий користувача або Чим ближче В=Кількість проблеми кваліфікаційні тести
A = Кількість випадків, в
легко виконувати супроводжуючого, який яких супроводжуючий до 1, тим Х=Кількість/ 5.5 підтримка
може припиняти і
експлуатаційні тестує систему краще. Кількість звіт про роботу
відновлювати виконання
випробування з програмного тестового прогону на
потрібних точках, щоб
контрольно- забезпечення після
перевірити крок за
пропускних обслуговування. кроком
B= Число випадків паузи
пунктів після
виконання тестового
технічного прогону
обслуговування?
Таблиця 5. Метрики зовнішньої якості

21
 На основі опису метрик (табл. 5) визначимо для їх значень шкали
ранжування (табл. 6):
Інтервали значеннь
задовільн
Характеристика Назва метрики відмінні добрі і незадовільні
Functional
1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Функціональність implementation

Access auditability 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0

Fault removal 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Надійність
Restartability 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Effectiveness of
the user
1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Зручність documentation
використання and/or help system
Attractive
10 - 8 8-6 6-4 4-0
interaction
Modification
impact localisation
0,0 - 0,4 0,4 - 0,6 0,6 - 0,8 0,8 - 1,0
Супроводжуваність (Emerging failure
after change)
Test restartability 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0

Таблиця 6. Ранжування значень метрик атрибутів зовнішньої якості

Визначимо значення необхідні для оцінки атрибутів зовнішньої якості (табл. 7).
Позначення
Характеристика Назва Метрики Назва елемента данних Значення
єемента
Функціональність кількість некоректно
Functional A 4
реалізованих або відсутніх функцій
implementation
B Кількість функцій в специфікації вимог 18
Access auditability A Кількість записів про доступ 150
B Кількість виконаних спроб доступу під час 185

22
 оцінки
A кількість виправлених помилок 73
B глобальна кількість актуальних помилок 94
Fault removal
глобальна кількість предсказуємих скритих
C 124
Надійність помилок у ПС
Кількість рестартів які зустрілися
A 12
Restartability з поставленим часом підчас тестів
B Повна кількість рестартів підчас тестів. 14
Кількість завдань успішно
Effectiveness of the
A завершив після отримання доступу 7
Зручність user documentation
до оперативної довідки та / або документації
використання and/or help system
B повна кількість тестованих завдань 10
Attractive interaction X Кількість анкетної оцінки 8
Modification impact Число відмов виникли після
localisation A відмови не буде вирішена зміною 1
(Emerging failure протягом зазначеного періоду
after change) N кількість дозволених відмов 5
Кількість випадків, в яких супроводжуючий
Супроводжуваність може припиняти і відновлювати виконання
A тестового прогону на 21
Test restartability потрібних точках, щоб перевірити крок за
кроком
Число випадків паузи виконання тестового
B 25
прогону

Таблиця 7. Значення елементів даних метрик зовнішньої якості

Оцінка рівнів якості атрибутів ПС. Визначимо оцінки зовнішньої якості та

зобразимо на шкалах:
1. Функціональність
1.1.Functional implementation
Q1.1 = 1- A/B = 1 – 4/18 = 0,77[Добре]
1.2.Access auditability
Q1.2 = A/B = 150/185 = 0,81[Відмінно]
2. Захищеність
23
 2.1.Fault removal
Q2.1 = A/С = 73/124 = 0,58[Задовільно]
2.2.Restartability
Q2.2 = A/B = 12/14 = 0,85[Відмінно]
3. Зручність використання
3.1.Effectiveness of the user documentation and/or help system
Q3.1 = A/B = 7/10 = 0,7[Добре]
3.2.Attractive interaction
Q3.2 = 8[Відмінно]
4. Супроводжуванність
4.1.Modification impact localisation (Emerging failure after change)
Q4.1 = А/N = 1/5 = 0,2[Відмінно]
4.2.Test restartability
Q4.2 = A/B = 21/25 = 0,84[Відмінно]

24
25
 Рисунок 14. Шкали ранжування оцінок зовнішньої якості

Для визначення інтегрального рівня якості ПС визначимо коефіцієнти

його характеристик (табл.8). Зважаючи що кожній під характеристиці
відповідає в даному випадку лише один атрибут, то доцільно їх вагові
коефіцієнти W прирівняти до 1.
Характеристика Сi Ваговий Коефіцієнт характеристики Wi
Функціональність 30
Надійність 25
Зручність у використанні 20
Супроводжуванність 20
Таблиця 8. Вагові коефіцієнти характеристик та підхарактеристик моделі зовнішньої
якості ПС
На основі можливих значень рівнів якості атрибутів та відомих вагових
коефіцієнтів визначимо ранжування інтегрального рівня якості ПС (табл. 9).
Відмінно [перевиконано] = 30 * ( 80 * 1/1 + 100 * 1/1 ) + 25 * ( 80 * 1/1 +
50 * 1/1 ) + 20 * (60 * 1/1 + 70 * (1-10/10) ) + 20 * ( 80 * (1-0/0,4) + 50 * 1/1 ) =
12450;
Добре [цільові] = 30 * ( 80 * 0,8/1 + 100 * 0,8/1 ) + 25 * ( 80 * 0,8/1 + 50 *
0,8/1 ) + 20 * ( 60 * 0,8/1 + 70 * (1-(8/10))) + 20 * ( 80 * (1-(0,4/0,2)) + 50 * 0,8/1 )
= 7360;
Задовільно[мінімальноприпустимі] = 30 * ( 80 * 0,6/1 + 100 * 0,6/1 ) + 25 *
( 80 * 0,6/1 + 50 * 0,6/1 ) + 20 * ( 60 * 0,6/1 + 70 * (1-(6/10)) ) + 20 * ( 80 * (1-
(0,6/0,2)) + 50 * 0,6/1) = 3870;
Незадовільно [неприпустимі] = 30 * ( 80 * 0,4/1 + 100 * 0,4/1 ) + 25 * ( 80 *
0,4/1 + 50 * 0,4/1 ) + 20 * ( 60 * 0,4/1 + 70 * (1-(4/10)) ) + 20 * ( 80 * (1-(0,8/0,2)) +
50 * 0,4/1 ) = 380.
Інтегральні значення
Відмінно Добре Задовільно Незадовільно
(Перевиконано) (цільові) (Мінімально припустимі) (неприпустимі значення)
12450..7360 7360..3870 3870..380 <380

Таблиця 9. Інтервали ранжування інтегрального рівня якості ПС

26
 Інтегральний рівень якості знаходиться за наступною формулою:
I Ji K ij

U q =∑ W i ∑ W ij ∑ W ijk Q ijk
i=1 j=1 k =1

Скориставшись якою ми отримаємо наступне знаходження інтегральної

оцінки:30*( 80 * 0,77/1 + 100 * 0,81/1 ) + 25*( 80 * 0,58/1 + 50 * 0,85/1 ) + 20 *
( 60 * 0,7/1 + 70 * (1-(8/10) ) + 20 * ( 80 * (1-(0,2/0,2) + 50 * 0,84/1 ) = 8461;
Та зобразимо його на шкалі ранжування (рис. 14):

Рисунок 15. Шкала ранжування інтегральної оцінки якості ПС

Оціннювання експлуатаційної якості

Визначимо вагові коефіцієнти характеристик і атрибутів експлуатаційної
якості (табл. 10)
Ваговий
Коефіцієнт
 Характеристика характеристики Назва атрибута Метрика Вага
Сi Wi Aij Mij Wij
Перелік реалізованих Task
60
функцій Completion
Результативність 25 Список помилок
Error
допущених 80
frequency
користувачем
Список заявок
Software
Безпека 35 користувачів про 100
damage
ураження ПС

27
 Перелік оцінок системи
Satisfaction
Задоволеність 10 серед опитаних осіб, які 80
scale
користувались
Список значень з
Продуктивність 20 таймерів виконання Task Time 50
функцій(Task Time)

Таблиця 10. Вагові коефіцієнти характеристик і атрибутів моделі експлуатаційної якості

Опишемо визначені метрики характеристик, та формули їх рахування.

1. Task completion:
– Задачі метрики — Яка частина завдань будуть завершені?
– метод вимірювання — користувацький тест;
– формула обрахування — Х = А/В (А = число завдань завершена B
= загальна кількість завдань намагалися виконати);
– інтерпретація отриманих даних — 0 <= Х <=1 (чим ближче до 1,
тим краще);
– тип вимірювання — співвідношення;
– тип змінних — А = Кількість, В = Кількість, Х =
Кількість/Кількість;
– надання змінних — Експлуатаційний звіт, звіт з користувацького
моніторингу;
– етап життєвого циклу — валідація, кваліфікаційні тести,
експлуатація;
2. Error frequency:
– Задачі метрики — Що таке частота помилок?
– метод вимірювання — користувацький тест;
– формула обрахування — Х = А/Т (А = кількість помилок зроблених
користувачем Т = час чи кількість завдань);
– інтерпретація отриманих даних — 0<= Х(чим ближче до нуля тим
краще);
28
 – тип вимірювання — Абсолютна;
– тип змінних — А = Кількість;
– надання змінних — Експлуатаційний звіт, звіт з користувацького
моніторингу;
– етап життєвого циклу — валідація, кваліфікаційні тести,
експлуатація;

3. Software damage:
– Задачі метрики — Що таке псування програмного забезпечення?
– метод вимірювання — Статистика використання;
– формула обрахування — Х =1-А/В (А = Кількість входжень до
системи з порушенням, В = загальна кількість операцій з системою;
– інтерпретація отриманих даних — 0 <= Х <=1 (чим ближче до 1,
тим краще);
– тип вимірювання — Абсолютно;
– тип змінних — А = Кількість, В = Кількість, Х =
Кількість/Кількість;
– надання змінних — звіт з моніторинг користування ;
– етап життєвого циклу — експлуатація;

4. Satisfaction scale:
– Задачі метрики — чи є задоволений користувач?
– метод вимірювання — користувацький тест;
– формула обрахування — Х = А/В (А = Анкета виробництва
психометричних шкал B = Середня чисельність користувачів);
– інтерпретація отриманих даних — 0<Х(чим більше до 0 тим
краще);
– тип вимірювання — співвідношення;
– тип змінних — А = кількість Х = кількість;

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

5. Task Time:
– Задачі метрики — Скільки часу це займе, щоб завершити завдання?
– метод вимірювання — користувацький тест;
– формула обрахування — Х = Та (Та = час виконання завдання, хв);
– інтерпретація отриманих даних — інтервальні;
– тип вимірювання — 0<Х(чим більше тим краще);
– тип змінних — Т = час;
– надання змінних — Експлуатаційний звіт, звіт з користувацького
моніторингу;
– етап життєвого циклу — валідація, кваліфікаційні тести,
експлуатація;

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

оцінок метрик( табл.11).
Інтервали значеннь
Характеристика Назва метрики відмінні добрі задовільні незадовільні
Task Completion 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Результативність
Error frequency 0,0 - 0,2 0,2 - 0,4 0,4 - 0,6 0,6 - 1,0
Безпека Software damage 1.0 - 0.8 0,8 - 0,6 0,6 - 0,4 0,4 - 0,0
Задоволеність Satisfaction scale 0,0 - 0,2 0,2 - 0,4 0,4 - 0,6 0,6 - 1,0
Продуктивність Task Time 5 - 15 15 - 25 25 - 35 35 - 45
Таблиця 11. Інтервали ранжування оцінок експлуатаційної якості

Визначимо значення необхідні для оцінки атрибутів зовнішньої якості, з

джерел зазначених у описі метрик, та складемо таблицю( табл. 12).

30
 Позначення Значен-
Характеристика Назва Метрики Назва елемента данних
елемента ня

A Число завдань завершена 15

Task Completion Загальна кількість завдань намагалися
B 20
виконати
Результативність
Кількість помилок зроблених
A 4
Error frequency користувачем
Т Час чи кількість завдань 15
Кількість входжень до системи з
A 4
Безпека Software damage порушенням
B Загальна кількість операцій з системою 10
Анкета виробництва психометричних
A 7
Задоволеність Satisfaction scale шкал
B Середня чисельність користувачів 25
Продуктивність Task Time Та Час виконання завдання, хв 16
Таблиця 12. Значення елементів даних метрик експлуатаційної якості

Визначення метрик моделі експлуатаційної якості

Аналогічно до методики оцінювання використання для моделі зовнішньої
якості, приведемо значення експлуатаційної якості, та зобразимо на шкалах
ранжування ( рис. 5).
1. Результативність
1.1. Task completion
Q1.1 = A/B = 15/20 = 0,75[Добре];
1.2.Error Frequency
P1.2 = A/B = 8/15 = 0,53; Q1.2 = 1 - 0,53 = 0,47[Задовільно];
2. Безпека
2.1. Software damage
Q2.1 = 1 - A/B= 1 - 4/15= 0,58[Задовільно];
3. Задоволеність
3.1. Satisfaction scale
Q3.1 = A/B = 7/25 = 0,28[Добре];
4. Продуктивність
31
 4.1. Task time
Q4.1 = Ta = 16 [Відмінно].

Рисунок 16. Шкали ранжування оцінок експлуатаційної якості

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

коефіцієнтів визначимо ранжування інтегрального рівня експлуатаційної
якості( табл. 13).
32
 Відмінно [перевиконано] = 25* ( 60 * 1/1 + 80 * (1-(0,2/0,2))) + 35 *( 100 *
1/ 1) + 10 * ( 80 * (1-(0,2/0,2)) + 20 * (50 * (1-(5/5))= 5640;
Добре [цільові] = 25* ( 60 * 0,8/1 + 80 * (1-(0,2/0,2))) + 35 *( 100 *0,8/ 1) +
10 * ( 80 * (1-(0,2/0,2))) + 20 * (50 * (1-(15/25))) = 4400;
Задовільно[мінімальноприпустимі] = 25* ( 60 * 0,4/0,6 + 80 * (1-(0,6/0,4)))
+ 35 *( 100 *0,4/ 0,6) + 10 * ( 80 * (1-(0,2/0,4))) + 20 * (50 * (1-(25/35))) = 3019;
Незадовільно [неприпустимі] = 25* ( 60 * 0,2/0,4 + 80 * (1-(0,8/1))) + 35
*( 100 *0,2/ 0,4) + 10 * ( 80 * (1-(0,8/1))) + 20 * (50 * (1-(45/35))) = 2774.

Інтегральні значення
Відмінно Задовільно Незадовільно
Добре (цільові)
(Перевиконано) (Мінімально припустимі) (неприпустимі значення)
5640..4400 4400..3019 3019..2774 0<2774

Таблиця 13. Інтервали ранжування інтегрального рівня якості ПС

Інтегральний рівень якості знаходиться за наступною формулою:
I Ji K ij

U q =∑ W i ∑ W ij ∑ W ijk Q ijk
i=1 j=1 k =1

Скориставшись якою ми отримаємо наступне знаходження інтегральної

оцінки:
25* ( 60 * 0,75/1 + 80 * (1-(0,47/1))) + 35 *( 100 * 0,58/ 1) + 10 * ( 80 * (1-
(0,28/1))) + 20 * (50 * (1-(16/15))) = 4724[Добре];

Та зобразимо його на шкалі ранжування (рис. 15):

Рисунок 17. Шкала ранжування інтегрального рівня експлуатаційної якості

33
 5. Оцінювання внутрішньої якості ПС за метриками Холстеда та
Маккейба

Метрики Холстеда
Основну увагу необхідно зосередити на нефункціональних
характеристиках ПП (надійність, зручність використання, ефективність,
супроводжуваність, переносимість). Особливо важливою з них є
характеристика надійність. Для усіх трьох її підхарактеристик слід розрахувати
оцінки за допомогою метрик Холстеда (формули (5.1) – (5.14)) і окремо
побудувати прогнозні оцінки для помилок (формули (5.15), (5.16)).
Вхідні дані для метрик Холстеда:
n1 – кількість різних (відмінних один від одного) операторів програми;
n2 – кількість різних (відмінних один від одного) операндів програми;
N1 – загальна кількість операторів програми;
N2 – загальна кількість операндів програми.

На цій основі Холстед визначає такі метрики:

Словник програми (в умовних одиницях)
n = n1+n2 (5.1)
Довжина реалізації (в умовних одиницях)
N = N1+N2 (5.2)
Довжина програми (в умовних одиницях)
Ñ = (n1  log2 n1)+(n2log2 n2) (5.3)
Обсяг програми (у бітах)
V = (N1+N2)  log2(n1+n2) (5.4)
потенційний обсяг програми
V* = (n2*+2)  log2(n2*+2), (5.5)
де n2* – загальна кількість вхідних і вихідних параметрів.
рівень програми (в умовних одиницях)
L = V*/ V
34
 рівень мови
=LV*, (5.7)
інтелектуальний зміст програми (в умовних одиницях)
I=LV (5.8)
робота з програмування (в умовних одиницях)
E = V/L = V2/V* (5.9)
час на програмування (в умовних одиницях)
T = E/S, (5.10)
де S – число Страуда (5<S<20).
Для визначення кількості модулів M у програмі Холстед рекомендує
використовувати вираз:
M= n2*/6, (5.12)
де n2* – загальна кількість вхідних і вихідних змінних у програмі.
З рівняння роботи отримаємо таке рівняння помилок:
B=LE/E0, (5.13)
де В – кількість помилок у програмі, Е0 – середня кількість елементарних
відмінностей між помилками програмування.
Використовуючи перетворене рівняння роботи:
Е= (V*)3/2, (5.14)
а також значення рівня англійської мови (=2,16), як аналог мови
програмування і гіпотезу про «шість об'єктів» ідеальної за витратами пам'яті
програми (n1=n1*=2, n2=n2*=6), Холстед вивів таке рівняння для прогнозу
кількості помилок у програмі:
B= Е 2/3 /3000, (5.15)
або: B= V/3000, (5.16)
де V – обсяг програми (5.4).
Крім свого прямого призначення в практичному сенсі метрики довжини
програми (5.3) і довжини реалізації (5.2) можна використовувати для
виявлення недосконалостей програмування. Якщо розрахунки довжини

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

Вхідні дані
n1 = 150
n2 = 200
N1 = 1000
N2 = 2000
n2_ = 400
S=6
E0 = 500

Формули Результати обчислень

n  n1  n2
n=350
N  N1  N2
N=3000
N_  (n1 log(2 n1) )  (n2 log(2 n2))

V  ( N1  N2)  log( 2 n1  n2) N_ = 4,6 * 103

V_  ( n2_  2) log( 2 n2_  2) V = 3,54 * 103

V_ V_ = 6,4 * 103
L 
V
L = 0,18
La  L V_
La = 1115
I  L V
I = 6,3* 103
V
E 
L E = 3,5 *105

T 
E T = 5,9 *104
S
M = 66,667
n2_
M 
6 B = 126,4

B  L
E E2 = 1,1 *103
E0
B2 = 0,035
3
V_
E2  B3 = 1,18
2
La

36
 2
3
E2
B2  N = 3 * 103
3000

V
N_ = 4,6 * 103
B3 
3000 Nmax max( N N_)

Nmin min( N N_)

Nmax = 4,6 * 103

Nmin = 3 * 103
Nmin
Nratio    100
 Nmax 
Nratio = 65,22

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

B2  3.126 B3  18.733

Надалі шляхом обчислення мір під характеристик – завершеності і

відновлюваності перевіримо прогнозні оцінки. Міри цих під характеристик
обчислимо відповідно до метрик (ISO/IEC 9126-3).
Надійність (reliability)
 завершеність (maturity)
o Назва метрики — Fault removal (усунення несправностей)
Мета метрики — Як багато недоліків було виправлено?
Спосіб застосування
Підрахуйте кількість помилок видалені під час проектування /
кодування і порівняти його з кількістю виявлених
несправностей в огляді під час проектування / кодування.
Вимір, формула і дані елементів обчислення
X=A/B
A= число виправлених помилок в проектуванні / кодування
B= Кількість виявлених несправностей в огляді
Інтерпретація виміряного значення — 0 <= X <=1,
37
 Чим ближче до 1, Тим краще.
Тип шкали метрики — Абсолютна
Тип міри — X= кількість/ кількість, A= Кількість, B=
Кількість
Вхід для вимірювання
Змінна A Приходить з Звіт видалених несправностей
Змінна B Приходить з оглядового звіту.
Етап життєвого циклу — Верифікація , Спільний аналіз
Цільова аудиторія - Замовники , Розробники
 відновлювальність (recoverability)
o Назва метрики —Restorability (Відновлюваність)
Мета метрики
Як продукт придатний для відновлення себе після аномальної
події, або за запиту?
Спосіб застосування
Підрахуйте кількість реалізованих вимог по відновленню і
порівняти його з кількістю вимог по відновлюванню
рестровних у специфікації.
Вимір, формула і дані елементів обчислення
X=A/B
A= Кількість реалізованих вимог по відновленню
підтверджених в огляді
B= Число вимог по відновленню в специфікаціях.
Інтерпретація виміряного значення — 0 <= X <= 1
Чим більше X, тим краще відновлюваність
Тип шкали метрики — Абсолютна
Тип міри — X= кількість/ кількість, A= Кількість, B=
Кількість
Вхід для вимірювання
A приходить з оглядового документу
38
 B приходить з вимоги або проектно-технічної документації
Етап життєвого циклу - Верифікація , Спільний аналіз
цільова аудиторія — Розробники , Супроводжуючі
На основі опису метрик визначимо для їх значень шкали ранжирування:
Інтервали значень
Назва Добрі Задовільні
Відміні Незадовільні
метрики (цільові (мінімально
(перевиконані) (неприпустимі)
) припустимі)
Fault removal 1.0 - 0.9 0,9 - 0,7 0,7 - 0,5 0,5 - 0,0
Restorability 1.0 - 0.9 0,9 - 0,7 0,7 - 0,5 0,5 - 0,0

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

Назва Позначення і
Значення
метрики Назва елемента даних
A = число виправлених помилок в
19
проектуванні / кодування
Fault removal
B = Кількість виявлених несправностей в
25
огляді
A = Кількість реалізованих вимог по
7
відновленню підтверджених в огляді .
Restorability
B = Число вимог по відновленню в
10
специфікаціях

Оцінка рівнів якості атрибутів ПС

Надійність (reliability)
 завершеність (maturity, іноді –безвідмовність)
o Fault removal
Q1 = X=A/B = 19 / 25 =0,76 [Добре]
 відновлювальність (recoverability)
o Restorability
39
 Q2 = X=A/B = 7 / 10 = 0,7 [Добре]
Метрика завершеності показала добрий результат, було знайдено майже
стільки помилок скільки прогнозовано за формулами Холстеда. (19/25).
Метрики відновлюваності показала також добрий результат якості, що
корелює із відповідними зовнішніми метриками що були обчислені.

Метрика Маккейба
Метрика Маккейба є цикломатичним числом графу передач керування
програми і визначається виразом
M =m−n+2 , (5.17)
де m – кількість ребер графу; n – кількість вершин графу. Величину М,
розраховану за формулою (5.17), називають цикломатичним числом
Маккейба.
Цикломатичне число визначає кількість незалежних контурів у
повнозв'язному графі і, як наслідок, кількість різних шляхів, що ведуть з
початкової вершини в кінцеву.
У практичному аспекті цикломатичне число є мірою складності програми
і визначає кількість тестів, достатніх для тестування за критерієм покриття всіх
гілок програми. Для оцінювання складності програми діє таке правило: якщо
цикломатичене число більше десяти, програма має зайву складність і її варто
розбити на складові частини (незалежні модулі) з меншим значенням
цикломатичного числа.

Оцінимо складність алгоритмів для розроблених у роботі №2 двох

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

40
 Розрахунок цикломатичного числа для сценарію «Формування
замовлення»

M =m−n+2 ,
де m – кількість ребер графу; n – кількість вершин графу
m = 12
n = 10
M = 12-10+2 = 4

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

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

41
 Розрахунок цикломатичного числа для сценарію «Корегування
інформації магазину»

M =m−n+2 ,
де m – кількість ребер графу; n – кількість вершин графу
m = 15
n = 16
M = 16-15+2 = 1

Таким чином, сценарій Корегування інформації магазину має граф

керування з цикломатичним числом 1, що є досить не велике значення. В
цілому, за графом сценарій досить складний. Хоча цикломатичене число не
більше десяти, і не можна однозначно сказати що сценарій має зайву
складність, все ж можна замислитись над розбиттям його на складові частини
(незалежні модулі) з меншим значенням цикломатичного числа.

42
 ВИСНОВКИ
У ході виконання домашньго завдання було отримано велика кількість
знань з проектування програмних систем, у часності за стандартом ISO/IEC
9126. Було використано метод інжениріі вимог Шлеєра і Меллора, Побудовані
сценарії та функції ПС за методом інженерії Джекобсона. За стандартом
побудові моделі зовнішньої, внутрішньої та експлуатаційної якості програмної
системи. Проведені оцінки отриманих моделей якості.
Метод Шлеєра і Меллора містить у своєму складі засоби моделювання
доменів. Цей метод дозволяє використовувати первинні джерела
документування. Відповідно існує можливість достатньо точно визначити
вимоги до майбутньої програмної системи. В процесі виконання лабораторної
роботи дані методи були застосовані і представленні у вигляді діаграм і
таблиць, а саме:
– Діаграма інформаційного домену;
– Діаграма відношення спадкування;
– Таблиця ТПС;
– діаграма потоків даних дій;
– Загальна таблиця процесів.
Оскільки Метод Шлеєра і Меллора зазначає, що наявність вище
зазначених документів дозволяє переходити до безпосереднього проектування
ПС, то можна зробити висновок що роботу виконано, та отримано позитивний
результат, на основі якого можна переходити до проектування.
Метод інженерії вимог Джекобсона — це єдиний метод котрий вказує
послідовний підхід до виявлення об’єктів, суттєвих для домену проблемної
галузі.
Шляхом декомпозиції основної мети програмної системи на певні
складові, та побудови для них діаграм, а саме:

43
 – Діаграма загального сценарію програмної системи інтернет-магазину
побутової техніки;
– Діаграма розширення сценарію «формування замовлення»;
– Діаграма відношення «використання» сценарію «формування
замовлення»;
За допомогою отриманих сценаріїв можна оцінити вимоги до ПС та
визначити значущі об’єкти і їх взаємодію за допомогою побудованих діаграм
взаємодії об’єктів для сценаріїв «формування замовлення» та «корегування
інформації магазину».
Опис же отриманих сценаріїв дав змогу виявити певний перелік об’єктів ПС
та їх взаємодію у ПС, завдяки чому виявляється можливість ефективно
проводити інженерію вимог та формувати основу для наступних етапів
розробки ПС, за допомогою метода Джекобсона.
Побудова моделі зовнішньої якості залежить безпосередньо від тих
аспектів, на які впливають багато факторів, безпосередньо головним є сфера
використання ПС. На відміно від зовнішньої, експлуатаційна якість залежить
від замовника та детального аналізу середовища використання ПС.
У процесі побудови моделей якості ми отримали такі моделі:
– Зовнішьньої якості;
– Експлуатаціної якості.
Для яких були виділені певні характеристики, метрики та обидві моделі
були сопоставлені у відношеннях між собою.
В результаті проведення оцінки зовнішньої якості була визначена міра
задоволення вимог до ПС на етапі її тестування та введення в експлуатацію,
підтверджені заявлені характеристики системи, а також забезпечені дані для
можливої сертифікації системи. Проведена оцінка експлуатаційної якості
дозволила зрозуміти міру задоволення кінцевого користувача ПС. Визначений
рівень експлуатаційної якості дозволяє врахувати недоліки в проекті ПС та
застосовувати в подальшій роботі досвід в сфері конструювання актуального та
зручного ПЗ.
44
 Оцінка інтегрального показнику якості досліджуваної системи показала
високий рівень якості, не зважаючи на те, що деякі характеристики отримали
добру чи навіть задовільну оцінку. Такий результат викликаний тим, що нижчу
оцінку отримували зазвичай показники, які не є першочерговими для даної
системи, а тому їм приділялося менше уваги, а також коефіцієнти їх важливості
визначені меншими. Показники першочергової важливості (наприклад,
зручність у використанні, та інші) отримали високу оцінку, а оскільки їм
відповідають високі коефіцієнти важливості, інтегральна оцінка якості
виявилась високою.
В результаті обчислення метрики Холстеда була оцінена ефективність
реалізації в порівнянні з довжиною програми, яка виявилась достатньою. Також
була спрогнозована кількість помилок, що виявилась близькою до кількості
помилок які були насправді знайдені. За допомогою метрик оцінки рівня
внутрішньої якості була проведена оцінка даної системи, результати якої
підтвердили достовірність проведеної оцінки зовнішньої якості. Загалом,
показники якості захищеності та надійності прийнятні, хоча помітно що вони
не позиціонувались головними при розробці ПС. Оцінка складності сценаріїв за
метрикою Маккейба виявила що один із сценаріїв є досить складним за графом,
хоча отримане значення не велике.
В цілому, не існує єдиної метрики, яка б забезпечила універсальний
підхід до кількісної оцінки якості ПС. Вимірювання й оцінювання якості дають
спектр метрик, що є основою для прийняття рішень у процесі розроблення і
супроводження програмного забезпечення.

45