• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Структура моделі якості

Розгляд базових характеристик моделі якості.

Функціональність – сукупність властивостей, визначальних здатність системи надавати необхідну безліч функцій для вирішення задач відповідно до вимог. В моделі якості ця характеристика задається набором атрибутів q1 = {a11, a12, a13, a14, a15, a16}, семантика і оцінка яких приведена нижче.

a11 : функціональна повнота – властивість компоненту, яка показує ступінь достатності реалізованих в ньому функцій для вирішення задач у відповідності з його призначенням. Даний атрибут можна уявити у вигляді відношення всіх реалізованих функцій F ^з в компонентній системі (с), до функцій F ^т, заданих у вимогах (т):

;

a12 : коректність – атрибут, який указує на ступінь відповідності кожної функції F ^т, заданої у вимозі, і кожної функції F ^з, реалізованій в компонентній системі. При цьому система володіє властивістю коректності, якщо F ^т = F ^з та і часткової коректності, якщо F ^т Ì F ^з. Для більшості систем достатньо часткової коректності. Ступінь коректності компоненту можна визначити, як ступінь функціональної коректності за формулою:

Ö = 1– (card ( F ^т / F ^з ) /card F ^т.

a13 : точність – властивість, визначальна отримання системою злагоджених результатів з необхідним ступенем точності. Даний атрибут може оцінюватися відношенням Ñ різниці значення функції Fсі (Di) компоненту і значення функції Fті (Di), заданої вимогами на Di вхідному наборі до значення функції відповідно до виразу:

;

a14 : интероперабельність – властивість компоненту системи взаємодіяти з іншими компонентами і операційним середовищем;

a15 : захищеність – атрибут, який показує можливість компоненту (системи) фіксувати дефекти, які є слідством суб'єктивних помилок в його реалізації або викликані програмними або апаратними засобами при виконанні, а також помилок, пов'язаних з даними. Оцінку ступеня захищеності можна привести за допомогою виразу a15 = falz / fal, де falz – кількість дефектів, від яких компонент захищений; fal – загальна кількість дефектів в компонентах або ПС;

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

Таким чином, характеристика функціональність q1 обчислюється підсумовуванням її атрибутів з урахуванням метрик і їх вагових коефіцієнтів:

.

Надійність ПС будемо визначати як вірогідність того, що компоненти системи або сама система функціонують безвідмовно протягом фіксованого періоду часу в заданих умовах операційного оточення/середовища. В моделі якості надійність задається на безлічі атрибутів q2 = {a21_{, a22, a23, a24}}, які визначають здатність} системи перетворювати початкові дані в результати при умовах, залежних від періоду часу життя системи (знос і старіння не ураховуються).

Зниження надійності компонентів відбувається через помилки у вимогах, проектуванні і виконанні. Відмови і помилки в програмних компонентах можуть з'являтися на заданому проміжку часу функціонування компоненту/системи [26–30]. Розглянемо властивості кожного атрибута надійності.

a21: безвідмовність – властивість системи, яка визначає функціонування системи без відмов (програмних компонентів або устаткування). Якщо компонент містить дефект, викликаний суб'єктивними помилками при розробці, то в множині D={De|eÎL} всіх дефектів, можна виділити підмножину EÍD, для якого результати не відповідають функції Fт, заданій у вимогах на розробку. Вірогідність р безвідмовного виконання компоненту на De, випадково вибраному з D серед рівно імовірних, рівна:

р = 1–(card (E) / card (D)).

Відмова (failure) показує відхилення поведінки системи від того, що наказав і система перестає виконувати функції, що наказали їй. Крім того, поява відмови може бути причиною помилки (fault/ error), викличної його.

Якщо помилка зроблена людиною, то використовується термін mistake. Коли відмінність між fault і failure не є критичною, використовується термін defect, який означає або fault (причина), або failure (дія). Зв'язок між цими поняттями можна уявити так: fault ® error ® failure.

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

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

Для обчислення середнього часу Т напрацювання на відмову застосовується формула

,

де Ñti^E – інтервал часу безвідмовної роботи компоненту і-го відмови; N – кількість відмов в системі.

a22 : стійкість до помилок – властивість компонентів системи, яка показує на здатність програмної системи виконувати функції при аномальних умовах (збоях апаратури, помилках в даних і інтерфейсах, порушеннях в діях оператора і ін.). Оцінку стійкості можна отримати по формулі

¡ = Nv/N

де Nv– кількість різних типів відмов, для яких передбачені засоби відновлення; N – загальна кількість всіх відмов в системі.

a23 : відновлюваність – властивість системи, яка указує на здатність відновлювати функціонування системи після відмов і відновлювати в ній пошкоджені компоненти чи дані для повторного виконання. Середній час відновлення компоненту можна визначити по формулі

,

де Ñtib – час відновлення працездатності компоненту після і-го відмови; D – кількість дефектів і відмов в системі.

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

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

– загроза порушення безпеки системи;

– сукупність загроз, що приводять до порушення системи або середовища і ін.

Надійність постійно вивчається і розвивається. Новий її напрям – інженерія надійності ПО (Software reliability engineering – SRE), яка орієнтована на рішення наступних задач [20, 28]:

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

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

3) застосування сучасних методів інспекції, верифікації, валидації тестуванні ПС в процесі розробки, а також при експлуатації.

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

Кількісна оцінка характеристики надійності системи по всіх її розглянутих кількісних атрибутах і відповідних метриках має вигляд

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

a31 : розумність означає зусилля, затрачуване на розпізнавання логічних концепцій і умов застосування ПС;

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

a33: оперативність – реакція системи при виконанні операторів і операційного контролю;

a34: узгодженість – відповідність ПС вимогам стандартів, угод, правил, законів і розпоряджень.

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

Кількісна оцінка даної характеристики залежить від оцінок експертів, кількісного атрибута a33 і має вигляд:

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

До них відносяться:

a41 : реактивність – час відгуку, обробки і виконання функцій компоненту/системи;

a42 : ефективність – кількість використовуваних ресурсів при виконанні функцій ПС і тривалість їх обчислень;

a43 : узгодженість – відповідність даного атрибута заданим стандартам, правилам і розпорядженням.

Кількісна оцінка даної характеристики по всіх розглянутих якісних і кількісно виміряються атрибутах оцінюється експертне і аналітично з урахуванням відповідних метрик і має вигляд

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

a52 : анализовність – необхідні зусилля для діагностики відмов в ПС або ідентифікації частин, які будуть модифікуватися;

a53 : змінність – зусилля, які затрачуються на модифікацію компоненту, видалення помилок або внесення змін, доповнення нових можливостей в систему або середовище функціонування;

a54 :стабільність – ризик проведення модифікації компоненту /системи;

a53 :тестуємість – зусилля при проведенні верифікації в цілях виявлення помилок і невідповідностей вимогам (валидація), а також на необхідність виправлення знайдених помилок і проведення сертифікації системи;

a54 : узгодженість – відповідність даного атрибута певним стандартам, угодам, правилам і розпорядженням.

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

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

a61 : адаптивна – зусилля, затрачувані на пристосовування системи до різних операційних середовищ. Цей атрибут можна уявити у вигляді a61 = Za / Zd, де Za – витрати на пристосовування до нового операційного середовища; Zd – витрати на розробку нової системи для нового операційного середовища;

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

a63 : співіснування – можливість використовування спеціального ПО в середовищі діючої системи;

a64 :змінюваність – можливість взаємодії (інтероперабельності) з іншими програмами при спільній їх роботі і інсталяції або пристосовуванні системи;

a65 : узгодженість – відповідність стандартам або угодам і правилам перенесення програмної системи в інше середовище.

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

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

Якщо у вимогах до ПС було встановлено декілька показників, то прорахований кожний показник умножається на відповідний ваговий коефіцієнт, а потім все підсумовується по всіх показниках. В результаті виходить інтегральна оцінка рівня якості ПС.

У формулах оцінювання показників якості окремого компоненту наведені метрики ai ÌА, вагові коефіцієнти wi Ì W для кожного атрибута. Отримані значення qj за допомогою вагових коефіцієнтів wi Ì W приведені до єдиної системивимірювання. Використовуючи отримані оцінки qj характеристик якості стосовно окремого компоненту (соm), одержуємо інтегральну оцінку якості одного компоненту у вигляді

.

Якщо програмна система містить N-компонентів і для них проведена кількісна оцінка, то маємо остаточну комплексну оцінку якості системи (sys):

.

Таким чином, даний підхід до аналітичної оцінки атрибутів показників якості ПС дозволяє отримати кількісну оцінку якості готового програмного продукту.

Читайте також:

1. III. Географічна структура світового ринку позичкового капіталу
2. VІ. План та організаційна структура заняття
3. А) Структура економічних відносин.
4. Автокореляція залишків – це залежність між послідовними значеннями стохастичної складової моделі.
5. Адміністративно – територіальний устрій і соціальна структура Слобожанщини у половині XVII – кінці XVIII століття
6. Акти з охорони праці, що діють в організації, їх склад і структура.
7. Алгоритм реалізації моделі
8. Алгоритм реалізації моделі
9. Алгоритм реалізації моделі
10. Алгоритм реалізації моделі
11. Алгоритм реалізації моделі
12. Алгоритм реалізації моделі

Переглядів: 1266