Побудова моделей якості програмної системи відповідно до стандарту iso/iec 9126

Мета: метою цієї роботи є дослідження методів побудови моделей якості програмної системи (ПС) відповідно до рекомендацій стандарту ISO/IEC 9126 (частини 1-4). Студенти вчаться застосовувати характеристики, підхарактеристики, атрибути та метрики якості стандарту ISO/IEC 9126 для побудови моделей зовнішньої та експлуатаційної якості ПС, що функціонує у визначеній предметній галузі.

 

Опис предметної області

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

Хід роботи

Оберемо наступні характеристики, підхарактеристики та атрибути якості:

1. Функціональність (Functionality):

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

1. Функціональна повнота (Suitability)

Завершеність реалізації функцій (Functional implementation completeness) – наскільки завершена розробка відповідно до вимогам специфікації.

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

, де A-кількість функцій, що відсутні; B-кількість функцій, що задекларовані в специфікації.

Чим ближче Х до 1, тим краще.

2. Точність (Accuracy)

Точність розрахунків (Computational accuracy) – як часто кінцевий користувач отримує неточні розрахунки.

Метод застосування: записати кількість неточних розрахунків основаних на специфікації.

, де А-кількість неточних розрахунків, з якими зустрівся користувач; Т-час роботи.

Чим ближче Х до 0, тим краще.

3. Захищеність (Security)

Запобігання порушенню цілісності даних (Data corruption prevention) – з якою частотою відбувається порушення цілісності даних.

Метод: перерахувати випадки подій значного і незначного порушення цілісності даних.

 

a) X= 1 – , де A – кількість разів, коли відбувалися події значного порушення цілісності даних, N – кількість випадків, коли подію порушення цілісності даних було викликано під час тестів;

Чим ближче значення Х до 1, тим краще.

 

b) Y= 1- , де B – кількість разів, коли відбувалися події незначного порушення цілісності даних;

Чим ближче значення Х до 1, тим краще.

 

c) Z= A / T or B / T, де

T - період операційного часу (протягом операційного випробування)

Чим ближче значення Х до 0, тим краще.

 

2. Надійність (Reliability):

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

1. Відмовостійкість (Fault Tolerance):

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

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

X= , де А1 - кількість серйозних і критичних збоїв, що вдалось уникнути, у порівнянні з числом тестових випадків збоїв, А2 – кількість оброблених тестових схем збоїв (що майже спричиняють відмову) під час випробувань;

 

3. Зручність використання (Usability):

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

1. Зрозумілість (Understandability):

Завершеність документації (Completeness of description) – який відсоток функцій (чи типів функцій) є зрозумілими після прочитання документації.

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

, де А-кількість зрозумілих функцій (або типів функцій); В-загальна кількість функцій (або типів функцій).

Чим ближче Х до 1, тим краще, 0≤Х≤1.

2. Керованість (Operability):

Корисна взаємодія (Attractive Interaction)– чи може користувач легко і вірно виконувати завдання користуючись підказками системи.

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

, де А- кількість неправильно виконаних завдань; В-час роботи користувача.

Чим ближче Х до 1, тим краще, 0≤Х≤1.

3. Вивчаємість (learnability)

Легкість у вивченні (Ease of function learning) – наскільки є привабливим інтерфейс для користувача і наскільки легко дається запам’ятовування функцій користувачем.

Т = час, на правильне вивчення функції ПС

Метод використання: опитування користувачів.

Чим менший час на вивчення функцій ПС – тим краще.

4. Ефективність (efficiency)

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

1. Реактивність (Time behaviour)

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

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

T = (час, за який отримано результат) - (час закінчення вводу команди)

2. Використовуваність ресурсів (resource utilization)

Середня помилка передачі за час (mean transmission error per time) - яка середня кількість передач пов'язані з повідомленням про помилки та невдачі протягом зазначеного періоду часу та зазначеного часу використання.

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

X= , де А= , В-бажана середня кількість передач пов’язаних з повідомленням про помилки та невдачі; Ai - число передач пов'язаних з повідомленням про помилки та невдачі на I-й оцінці; N- кількість оцінок.

Чим менше Х, тим краще.

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

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

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

1. Ефективність (Effectiveness):

· доля виконаних користувачем задач;

· доля правильно виконаних користувачем задач;

· відношення числа успішних дій до помилок;

· кількість використовуваних функцій і команд.

2. Продуктивність (Productivity):

· час, необхідний для виконання задачі;

· продуктивність виконання задачі;

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

· час, необхідний на попереднє навчання користування;

· час, що витрачається через помилки користувача;

· відсоток чи кількість помилок;

· частота використання документації;

· кількість повторних і помилкових дій (команд).

3. Безпека (Safety):

· вплив на здоров'я і безпеку користувачів;

· вплив на здоров'я і безпеку інших людей;

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

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

4. Задоволення користувача (Satisfaction):

· рейтингова оцінка по шкалі корисності продукту чи послуги;

· рейтингова оцінка по шкалі задоволення функціональністю продукту;

· кількість випадків, коли користувач відчував фрустрацію чи гнів при користуванні продуктом;

· рейтингова оцінка по шкалі технологічного керування задачею без втручання користувача;

· оцінка того, наскільки технологічне виконання задачі відповідає вимогам користувача;

· доля потенційних користувачів програми.

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

1. Ефективність (Effectiveness):

Частота помилок ( Error frequency) – як часто трапляються помилки.

Метод: тестування користувачем.

 

X = A/T, де A – кількість помилок, що зробив користувач, T – час або кількість завдань;

Чим ближче Х до 1, тим краще.

2. Продуктивність (Productivity):

Час задачі (Task time) – як багато часу необхідно користувачу щоб виконати задачу.

Метод застосування: юзер-тест.

Чим менше Х, тим краще.

3. Безпека (Safety):

Пошкодження програмного забезпечення (Softwere damage) – що собою являє пошкодження програмного забезпечення.

Метод: тестування користувачем

X = 1- , де A – кількість випадків пошкодження програмного забезпечення, B – загальна кількість робочих станцій;

Чим ближче Х до 1, тим краще.

 

4. Задоволення користувача (Satisfaction):

Величина задоволеності (Satisfaction scale) – наскільки задоволеним є користувач.

Метод використання: юзер-тест.

Х = , де А-результат опитування задоволеності, В-середній показник задоволеності

Чим більше Х, тим краще.

 

Метрики, що проектуються, можуть виглядати наступним чином:

- число успішних операцій повинно бути не нижче ніж 85%;

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

- доля потенційних користувачів програми більше, ніж у основного конкурента, на 30%.

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

Хід роботи

Оберемо наступні характеристики, підхарактеристики та атрибути якості:

5. Функціональність (Functionality):

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

1. Функціональна повнота (Suitability)

Завершеність реалізації функцій (Functional implementation completeness) – наскільки завершена розробка відповідно до вимогам специфікації.

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

, де A-кількість функцій, що відсутні; B-кількість функцій, що задекларовані в специфікації.

Чим ближче Х до 1, тим краще.

 

Кількість функцій, що були описані у відповідному технічному завданні В = 50, а кількість функцій, що не було реалізовано А =9, тому Х = 1- =0,82

 

2. Точність (Accuracy)

Точність розрахунків (Computational accuracy) – як часто кінцевий користувач отримує неточні розрахунки.

Метод застосування: записати кількість неточних розрахунків основаних на специфікації.

, де А-кількість неточних розрахунків, з якими зустрівся користувач; Т-час роботи.

Чим ближче Х до 0, тим краще.

Середнім часом функціонування обираємо Т = 240 хвилин, а кількість результатів, що не відповідають необхідній точності в середньому дорівнюватиме А = 12. Отже, точність нашої системи дорівнює Х = = 0,05

3. Захищеність (Security)

Запобігання порушенню цілісності даних (Data corruption prevention) – з якою частотою відбувається порушення цілісності даних.

Метод: перерахувати випадки подій значного і незначного порушення цілісності даних.

a) X= 1 – , де A – кількість разів, коли відбувалися події значного порушення цілісності даних, N – кількість випадків, коли подію порушення цілісності даних було викликано під час тестів;

Чим ближче значення Х до 1, тим краще.

Визначимо кількість разів, коли відбувалися події значного порушення цілісності даних А = 12, кількість випадків, коли подію порушення цілісності даних було викликано під час тестів N = 24. Звідси, Х = 1- = 0,75

 

 

b) Y= 1- , де B – кількість разів, коли відбувалися події незначного порушення цілісності даних;

Чим ближче значення Х до 1, тим краще.

 

Визначимо кількість разів, коли відбувалися події значного порушення цілісності даних B = 2, кількість випадків, коли подію порушення цілісності даних було викликано під час тестів Т = 10. Звідси, Х = 1- = 0,96

c) Z= A / T or B / T, де

T - період операційного часу (протягом операційного випробування)

Чим ближче значення Х до 0, тим краще.

Припустимо, що операційне випробування проходить протягом Т = 2400, тоді Z = = 0,005.

 

6. Надійність (Reliability):

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

 

 

1. Відмовостійкість (Fault Tolerance):

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

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

X= , де А1 - кількість серйозних і критичних збоїв, що вдалось уникнути, у порівнянні з числом тестових випадків збоїв, А2 – кількість оброблених тестових схем збоїв (що майже спричиняють відмову) під час випробувань;

Чим ближче значення Х до 1, тим краще.

Під час роботи з даним програмним продуктом було виявлено 12 проблем (А2=12), з них вдалось вирішити 5 (А1 = 5). Х = = = 0,42

7. Зручність використання (Usability):

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

1. Зрозумілість (Understandability):

Завершеність документації (Completeness of description) – який відсоток функцій (чи типів функцій) є зрозумілими після прочитання документації.

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

, де А-кількість зрозумілих функцій (або типів функцій); В-загальна кількість функцій (або типів функцій).

Чим ближче Х до 1, тим краще, 0≤Х≤1.

Під час роботи з даним програмним продуктом, користувачам були зрозумілі функції A=36 з загальної кількості B=41, тому X=

 

2. Керованість (Operability):

Корисна взаємодія (Attractive Interaction)– чи може користувач легко і вірно виконувати завдання користуючись підказками системи.

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

, де А- кількість неправильно виконаних завдань; В-час роботи користувача.

Чим ближче Х до 1, тим краще, 0≤Х≤1.

Під час опитування було виявлено, що користувачі здебільшого виконували правильно А=20 завдань за В=240 хвилин. Х=1- =0,91

3. Вивчаємість (learnability)

Легкість у вивченні (Ease of function learning) – наскільки є привабливим інтерфейс для користувача і наскільки легко дається запам’ятовування функцій користувачем.

Т = час, на правильне вивчення функції ПС

Метод використання: опитування користувачів.

Чим менший час на вивчення функцій ПС – тим краще.

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

8. Ефективність (efficiency)

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

1. Реактивність (Time behaviour)

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

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

T = (час, за який отримано результат) - (час закінчення вводу команди)

Час отримання результату в середньому складає від 10 до 15 секунд, тому візьмемо значення 13 секунди (Т = 13). Як верхню межу неприйнятну для нас поставимо 30 секунд. Т = 13

2. Використовуваність ресурсів (resource utilization)

Середня помилка передачі за час (mean transmission error per time) - яка середня кількість передач пов'язані з повідомленням про помилки та невдачі протягом зазначеного періоду часу та зазначеного часу використання.

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

X= , де А= , В-бажана середня кількість передач пов’язаних з повідомленням про помилки та невдачі; Ai - число передач пов'язаних з повідомленням про помилки та невдачі на I-й оцінці; N- кількість оцінок.

Чим менше Х, тим краще.

При роботі з даним програмним забезпеченням було проведено 5 оцінок (N=5), при цьому Аі мало такі значення: А1=0, А2=1, А3=2, А4=0, А5=1 а тому А= . Кількість допустимих повідомлень про помилку В=5, тому Х=

Побудуємо шкали ранжування для обраних внутрішніх метрик:

5. Ефективність (Effectiveness):

Частота помилок ( Error frequency) – як часто трапляються помилки.

Метод: тестування користувачем.

X = A/T, де A – кількість помилок, що зробив користувач, T – час або кількість завдань;

Чим ближче Х до 0, тим краще.

Користувачем було допущено 10 помилок (А=10) за час 240 хв (Т=240). Х=

6. Продуктивність (Productivity):

Час задачі (Task time) – як багато часу необхідно користувачу щоб виконати задачу.

Метод застосування: юзер-тест.

Чим менше Х, тим краще.

Для виконання задачі ми обрали 10 працівників і провели тест, у результаті якого з’ясувалось, що в середньому для виконання задачі користувачу потрібно 7 секунд (Т =7). Кількість, яку провів кожен з обраних користувачів рівна 50. Як неприйнятну межу візьмемо 20 секунд.

Х = 7

Чим менше Х, тим краще.

 

7. Безпека (Safety):

Пошкодження програмного забезпечення (Softwere damage) – що собою являє пошкодження програмного забезпечення.

Метод: тестування користувачем

X = 1- , де A – кількість випадків пошкодження програмного забезпечення, B – загальна кількість робочих станцій;

Чим ближче Х до 1, тим краще.

 

Кількість випадків пошкодження програмного забезпечення складає А=1, а загальна кількість робочих станцій В=24. Х= =0.95

 

8. Задоволення користувача (Satisfaction):

Величина задоволеності (Satisfaction scale) – наскільки задоволеним є користувач.

Метод використання: юзер-тест.

Х = , де А-результат опитування задоволеності, В-середній показник задоволеності

Чим більше Х, тим краще.

Опитування показало, що задоволеність працівників 76% (А = 76), а середній показник задоволеності становить 87% (В = 87).

Х = = 80 / 88 = 0.87

Чим більше Х, тим краще.

 

Тепер визначимо бальні показники та вагові коефіцієнти:

Завершеність реалізації функцій (Functional implementation completeness)

Максимальна оцінка: 100

Дійсна оцінка: 82

Ваговий коефіцієнт: 95

Точність розрахунків (Computational accuracy)

Максимальна оцінка: 100

Дійсна оцінка: 95

Ваговий коефіцієнт: 95

Запобігання порушенню цілісності даних (Data corruption prevention)

Максимальна оцінка: 100

Дійсна оцінка: 95

Ваговий коефіцієнт: 50

Уникнення збоїв (Failure avoidance)

Максимальна оцінка: 100

Дійсна оцінка: 42

Ваговий коефіцієнт: 30

Завершеність документації (Completeness of description)

Максимальна оцінка: 100

Дійсна оцінка: 87

Ваговий коефіцієнт: 50

Корисна взаємодія (Attractive Interaction)

Максимальна оцінка: 100

Дійсна оцінка: 91

Ваговий коефіцієнт: 50

Легкість у вивченні (Ease of function learning)

Максимальна оцінка: 100

Дійсна оцінка: 92

Ваговий коефіцієнт: 30

Тривалість відповіді (Response time)

Максимальна оцінка: 30

Дійсна оцінка: 13

Ваговий коефіцієнт: 95

Середня помилка передачі за час (mean transmission error per time)

Максимальна оцінка: 100

Дійсна оцінка: 84

Ваговий коефіцієнт: 95

Частота помилок ( Error frequency)

Максимальна оцінка: 100

Дійсна оцінка: 96

Ваговий коефіцієнт: 50

Час задачі (Task time)

Максимальна оцінка: 20

Дійсна оцінка: 13

Ваговий коефіцієнт: 95

Пошкодження програмного забезпечення (Softwere damage)

Максимальна оцінка: 100

Дійсна оцінка: 95

Ваговий коефіцієнт: 50

Величина задоволеності (Satisfaction scale)

Максимальна оцінка: 100

Дійсна оцінка: 87

Ваговий коефіцієнт: 95

 

Складемо таблицю отриманих коефіцієнтів:

Назва ознаки	Q/Qmax	W
Functional implementation completeness	82/100
Computational accuracy	95/100
Data corruption prevention	95/100
Failure avoidance	42/100
Completeness of description	87/100
Attractive Interaction	91/100
Ease of function learning	92/100
Response time	17/30
mean transmission error per time	84/100
Error frequency	96/100
Task time	17/20
Softwere damage	95/100
Satisfaction scale	87/100

 

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

U_q = 95*82 + 95*95 + 50*95 + 30*42 + 50*87 + 50*91 + 30*92 + 95*17 + 95*84+50*96+95*17+50*95+95*87 = 7790 + 9025 + 4750 + 1260 + 4350 + 4550 + 2760 + 1615 + 7980 + 4800 + 1617 + 4750 + 8265 = 63512

 

Інтегральна шкала буде мати вигляд:

 

 

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