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

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2006
Автори:	Райчев, І.Е., Харченко, О.Г.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2006
Теми:	Методи та засоби програмної інженерії
Онлайн доступ:	http://dspace.nbuv.gov.ua/handle/123456789/1549
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Концепція побудови сертифікаційної моделі якості програмних систем / І.Е. Райчев, О.Г. Харченко // Проблеми програмування. — 2006. — N 2-3. — С. 275-281. — Бібліогр.: 23 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-1549
record_format	dspace
spelling	irk-123456789-15492008-08-29T12:00:59Z Концепція побудови сертифікаційної моделі якості програмних систем Райчев, І.Е. Харченко, О.Г. Методи та засоби програмної інженерії У статті розглянуті питання формулювання концепції побудови сертифікаційної моделі якості програмних систем (ПС), для яких сертифікація відповідності є обов'язковою. Розроблені методи формалізації вимог до ПС та побудови моделі якості. Створення цих методів дає можливість підвищити ефективність випробувань, що зменшує трудомісткість сертифікації та збільшує достовірність її результатів. In the article the questions of formulation of the concept of construction of the certified quality model of program systems, for which a certification of correspondence is a mandatory procedure, are considered. Methods of formalization of requirements and construction of the quality model are developed. Creation of these methods allow to increase efficiency of tests, that reduces labour input of certification and raises reliability of her results. 2006 Article Концепція побудови сертифікаційної моделі якості програмних систем / І.Е. Райчев, О.Г. Харченко // Проблеми програмування. — 2006. — N 2-3. — С. 275-281. — Бібліогр.: 23 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/1549 004.4:006.015.5 uk Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Методи та засоби програмної інженерії Методи та засоби програмної інженерії
spellingShingle	Методи та засоби програмної інженерії Методи та засоби програмної інженерії Райчев, І.Е. Харченко, О.Г. Концепція побудови сертифікаційної моделі якості програмних систем
description	У статті розглянуті питання формулювання концепції побудови сертифікаційної моделі якості програмних систем (ПС), для яких сертифікація відповідності є обов'язковою. Розроблені методи формалізації вимог до ПС та побудови моделі якості. Створення цих методів дає можливість підвищити ефективність випробувань, що зменшує трудомісткість сертифікації та збільшує достовірність її результатів.
format	Article
author	Райчев, І.Е. Харченко, О.Г.
author_facet	Райчев, І.Е. Харченко, О.Г.
author_sort	Райчев, І.Е.
title	Концепція побудови сертифікаційної моделі якості програмних систем
title_short	Концепція побудови сертифікаційної моделі якості програмних систем
title_full	Концепція побудови сертифікаційної моделі якості програмних систем
title_fullStr	Концепція побудови сертифікаційної моделі якості програмних систем
title_full_unstemmed	Концепція побудови сертифікаційної моделі якості програмних систем
title_sort	концепція побудови сертифікаційної моделі якості програмних систем
publisher	Інститут програмних систем НАН України
publishDate	2006
topic_facet	Методи та засоби програмної інженерії
url	http://dspace.nbuv.gov.ua/handle/123456789/1549
citation_txt	Концепція побудови сертифікаційної моделі якості програмних систем / І.Е. Райчев, О.Г. Харченко // Проблеми програмування. — 2006. — N 2-3. — С. 275-281. — Бібліогр.: 23 назв. — укр.
work_keys_str_mv	AT rajčevíe koncepcíâpobudovisertifíkacíjnoímodelíâkostíprogramnihsistem AT harčenkoog koncepcíâpobudovisertifíkacíjnoímodelíâkostíprogramnihsistem
first_indexed	2025-07-02T04:57:51Z
last_indexed	2025-07-02T04:57:51Z
_version_	1836509846031040512
fulltext	Методи та засоби програмної інженерії УДК 004.4:006.015.5 КОНЦЕПЦІЯ ПОБУДОВИ СЕРТИФІКАЦІЙНОЇ МОДЕЛІ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ І.Е. Райчев, О.Г. Харченко Національний авіаційний університет 03058, Київ, проспект космонавта Комарова,1, тел. 406 7336, e-mail: raychev@zeos.net У статті розглянуті питання формулювання концепції побудови сертифікаційної моделі якості програмних систем (ПС), для яких сертифікація відповідності є обов'язковою. Розроблені методи формалізації вимог до ПС та побудови моделі якості. Створення цих методів дає можливість підвищити ефективність випробувань, що зменшує трудомісткість сертифікації та збільшує достовірність її результатів. In the article the questions of formulation of the concept of construction of the certified quality model of program systems, for which a certification of correspondence is a mandatory procedure, are considered. Methods of formalization of requirements and construction of the quality model are developed. Creation of these methods allow to increase efficiency of tests, that reduces labour input of certification and raises reliability of her results. Вступ При сертифікації програмних систем оцінюється ступінь відповідності властивостей розробленої системи вимогам до неї [1–3]. Для цього на першому етапі необхідно представити сертифікаційні вимоги до ПС у загальноприйнятому формалізованому вигляді. Вимоги, що сформульовані при розробці ПС, для цього не можуть бути використані, бо вони, як правило, недостатньо формалізовані й носять суб'єктивний характер. У роботі [4] запропонована деяка стандартизована форма представлення вимог на основі моделі якості ПС, побудованої у відповідності до стандарту з якості ISO/IEC 9126. Другим етапом є розробка моделей, методів та алгоритмів визначення характеристик, які увійшли в сертифікаційну модель якості, побудовану на попередньому етапі. Так як при сертифікації ПС, як правило, необхідно здійснювати комплексну оцінку якості за широким спектром властивостей, то використання для цього моделі якості, побудованої на основі множини стандартизованих характеристик із застосуванням вибору метрик та мір є обґрунтованим. Методи сертифікації, орієнтовані на оцінювання окремих характеристик якості, використовують різну аксіоматику при відображенні вимог на множину показників і можуть привести до некоректних результатів [5–9]. Тому напряму використати отримані результати при побудові комплексної сертифікаційної моделі якості ПС неможливо. Робота присвячена розробці концепції побудови сертифікаційної моделі ПС, яка спирається на єдину аксіоматику при відображенні вимог на характеристики ПС. Модель використовує рекомендації стандарту з якості ISO/IEC 9126 при уніфікації вимог і виборі метрик та мір. 1. Аналіз вимог до ПС У даний час у програмній інженерії використовується декілька підходів до представлення вимог. Так, в [10] пропонується розділити вимоги до ПС на С-вимоги, або вимоги замовника, та D-вимоги, або вимоги розробника. Але чіткого розділення та класифікації вимог на формалізовані групи не дається. В роботі [5] пропонується розділити D-вимоги на типи, такі як функціональні, нефункціональні та зворотні. Але не даються чіткі правила поділу, а тому можуть виникати колізії, такі як змішування вимог, необґрунтоване їх об'єднання та ін. У роботі [11] для більшої формалізації пропонується відобразити типи вимог на розділи стандарту IEEE830–1993. Однак, багато розділів цього стандарту носять досить загальний характер і не можуть бути використані при сертифікації. Достатньо повний перелік властивостей містить документація на готову ПС, підготовлена у відповідності зі стандартом ISO/IEC 12119–1994. Однак, ця інформація може бути використана лише як проміжна при формалізації вимог. Тому найбільш прийнятним, на наш погляд, є використання підходу, який запропоновано в [4]. Викладемо його суть, використовуючи формальні методи специфікацій [12]. Множина вимог V до програмної системи формується користувачем та розробником і складається з функціональних вимог 1,, IiXxx ii ∈∈ та нефункціональних 2,, IjYyy jj ∈∈ (де ,...,,,, 21 IIYXV - скінченні множини). Функціональні вимоги описують поведінку системи та її функції. Якщо вони записані користувачем, то вони описують поведінку системи в загальному вигляді, водночас як розробник описує їх максимально детально, включаючи вхідні й вихідні дані та специфікації. Нефункціональні вимоги пов'язані, в 276 основному, з інтеграційними характеристиками, такими, як надійність, реактивність, розмір системи, і відображають, в більшому ступені, потреби користувача. Таким чином, YXV ∪= . Але вимоги, як правило, містять обмеження на функціональні характеристики 3,, IkBBB kk xx ∈∈ , а вимоги предметного середовища можуть задати нові функціональні вимоги 1,, JiXxx ii ∈∈ , нові обмеження 2,, JkBBB kk xx ∈∈ , а також інструкції на виконання деяких операцій 3,, JUuu ∈∈ ααα . Замовники сертифікації, якими можуть бути розробники та користувачі програмного забезпечення (ПЗ), через відсутність уніфікованої форми класифікації, формують вимоги до ПЗ, виходячи зі своїх суб'єктивних представлень [5]. Це призводить до ряду некоректностей та нечіткого формулювання вимог. Наприклад, при виконанні операції об'єднання вимог можуть виникнути ускладнення, пов'язані з тим, що при записі вимог користувача може відбуватись наступне: - змішування вимог, коли нема чіткого розподілу на функціональні й нефункціональні вимоги; - об'єднання вимог, коли різні вимоги описуються як єдина вимога, та ін. Для подолання цього недоліку в [5] пропонується розробити стандартну форму запису й класифікації вимог та неухильно її дотримуватись. Однак, вплив суб'єктивного фактора може призвести до того, що кожний розробник буде мати свій варіант такої форми, що буде заплутувати як замовників, так і користувачів. Таке положення може спричинити некоректні висновки щодо результатів перевірки відповідності, які можуть бути як підтверджені, так і спростовані, або не визнані якоюсь із сторін. Для вирішення цієї проблеми пропонуємо проводити первинний аналіз вимог, який дає можливість видалити явні некоректності та побудувати нормативну модель вимог. На основі аналізу вимог замовника сертифікації та нормативних документів, об'єднуючи всі перераховані вимоги та обмеження, запишемо нормативну модель вимог, як множину, у загальному вигляді: },,,),,,,{( 323211 JJIkIjJIiuByxQ kxjiN ∈∪∈∈∪∈= αα . (1) Але користуватися моделлю (1) для перевірки відповідності при сертифікації складно. Справді, модель (1) не є конструктивною, тому що наявні в ній вимоги ii yx , зазнали впливу суб'єктивних факторів, неформалізовані, а тому неможливо вибрати обґрунтовані метрики та міри для вимірювання ступеня досягнення властивостей. Для проведення сертифікаційних випробувань ПЗ потрібно мати: - записаний у формалізованому вигляді перелік характеристик iC та підхарактеристик iS , до яких пред'являються вимоги; - перелік атрибутів (показників) iA , які показують ступінь досягнення властивості кожної характеристики; - метрики iM , в яких вимірюються iA , і множини припустимих значень атрибутів iP . 2. Концепція побудови сертифікаційної моделі якості ПC На основі аналізу існуючих формалізацій, що містяться у стандартах, авторами було вибрано найбільш повний класифікатор, який запропонований у серії стандартів [13-16]. Дійсно, більш логічним та економічним підходом до розробки стандартної форми запису вимог є використання класифікації характеристик ПЗ, що викладена в стандарті якості ISO/IEC 9126-1 [13]. В цьому стандарті дана вичерпна класифікація характеристик, що налічує 27 підхарактеристик. В якості ознак класів сертифікаційної моделі оберемо характеристики, атрибути, метрики та обмеження. Однак, стандарти визначають загальні поняття й рекомендації, які не можна прямо використати для конкретних обчислень рівня якості ПЗ. Тому для кожного класу ПС необхідно будувати модель якості з огляду на предметну область і специфіку використання ПЗ. Відзначимо, що концепція аналітичної оцінки характеристик якості [17], яка базується на загальній моделі [13], не враховує специфіку класів ПС і є в галузевому розумінні занадто широкою. Тому пропонується відображати галузеві нормативні вимоги на характеристики загальної моделі, звужуючи її. У такий спосіб одержимо шукану модель сертифікації, у якій вагові множники при атрибутах якості будуть відповідати за специфіку предметної області [4]. Наприклад, для програмного забезпечення автоматизованих систем контролю польотів (ПЗ АСКП), яке розглянемо в якості ілюстрації, функціональна повнота й точність важливіше мобільності [18]. Такий загальний підхід пропонується використати для створення концепції побудови моделі якості програмних систем, що функціонують у різних галузях. Основою концепції може служити принцип доцільної повноти моделі для кожного класу ПЗ, що розглядається. Дійсно, різні класи ПЗ мають різний пріоритетний набір розв'язуваних задач, який залежить від специфіки використання ПЗ, що приводить нас до необхідності розробки концепції побудови моделі якості галузевого ПЗ, яка придатна для сертифікації. Методи та засоби програмної інженерії 277 Концепція визначає систему відображень для переходу від моделі вимог до стандартизованої моделі якості, яку можна використати для сертифікації ПЗ. При побудові концепції слід врахувати вимоги замовника сертифікації, галузевих нормативних документів, вимоги користувача, а також рекомендації державних стандартів, після чого відобразити отриману множину вимог на характеристики якості [13]. Концепція побудови сертифікаційної моделі якості складається з наступних етапів: 1. Ґрунтуючись на сертифікаційних вимогах до ПЗ, будуємо нормативну модель вимог шляхом об'єднання функціональних і нефункціональних вимог та обмежень. Нормативна модель вимог, у першу чергу, залежить від набору вимог замовника сертифікації та галузевих вимог до ПЗ. В цій моделі можуть з'являтися й конфліктні вимоги, що випливає із суперечливості деяких вимог замовника й вимог галузевих та міжнародних стандартів. 2. Нормативна модель вимог не є конструктивною, тому що вимоги до ПЗ не стандартизовані (не задані атрибути та метрики для їх виміру). Для приведення вимог до формалізованого вигляду пропонуємо виразити їх за допомогою уніфікованих характеристик. Тому, на другому етапі концепція передбачає побудову загальної моделі якості на основі рекомендацій ISO/IEC 9126. Ґрунтуючись на базових програмних комплексах ПЗ, виконуємо поділ характеристик загальної моделі на критичні й другорядні. 3. Здійснюємо відображення вимог із нормативної моделі на загальну модель якості з вибіркою характеристик та сполученням атрибутів. Для вимог, які не мають відповідності у загальній моделі за назвою, шукаємо аналог за змістом. Конфліктні характеристики узгоджуємо. Сукупність вибраних елементів загальної й нормативної моделей складе сертифікаційну модель якості, у якій відповідність показників атрибутів вимогам залежить від обмежень. Перший етап було розглянуто у п.1. На другому етапі будуємо загальну ієрархічну модель якості, що запишеться у вигляді множини: {{ { } } } I i J j K k L lijklijklijklijkijiG iijijkWMEASCQ 1 111 ,, = ===      = , (2) де iC – і-та характеристика; ijS – j-та підхарактеристика і-ї характеристики; ijkA – k-й атрибут j-ї підхарактеристики і-ї характеристики якості. Для того щоб модель (2) була завершеною, необхідно обрати метрики ijklM вимірювання елементів атрибутів підхарактеристик ijklE , та вагові коефіцієнти ijklW . З метою спрощення моделі, запропоновано, по-перше, ввести в модель тільки критичні характеристики (функціональність, надійність і відображення необхідних вимог замовника та галузевих характеристик), а, по- друге – потрібні другорядні характеристики. Врешті, із метою деталізації моделі необхідно вирішити задачу визначення атрибутів підхарактеристик. Атрибути й елементи атрибутів пропонується виділяти з галузевих стандартів і нормативних документів, а для підхарактеристик, що залишилися – із загальних стандартів якості, оскільки галузеві документи задають базові вимоги до ПЗ, що функціонує в заданій предметній області. Якщо галузеві нормативні документи відсутні, то вибір атрибутів варто залишити на розсуд експертів із лабораторії сертифікації, які повинні керуватися загальними стандартами якості ПЗ, а також вимогами технічного завдання на розробку ПЗ. Зауважимо, що з точки зору користувача вимоги до властивостей ПЗ виділяються з галузевих стандартів і нормативних документів, а з точки зору органів, що перевіряють (орган сертифікації), і сторони, що проводить сертифікаційні випробування (акредитована лабораторія сертифікації), ці показники повинні бути уніфікованими і вибиратися із загальних стандартів якості ПЗ. Нарешті, розробник ПЗ може користатися власною системою оцінки якості, що може бути заснована на контролі ряду вищезгаданих показників, а також деяких внутрішніх характеристик якості [6, 19]. З вищесказаного випливає, що на черзі тепер стоїть задача відображення вимог галузевих стандартів на множину показників загальних стандартів і визначення нормативних показників. На третьому етапі концепція передбачає відображення моделі (1) на модель (2), що вимагає врахування специфіки застосування ПЗ. Таке відображення не є тривіальним, бо представляє собою рішення задачі логічної класифікації вимог на множині характеристик якості, і включає класифікацію кожної вимоги iV з (1) шляхом аналізу внутрішнього змісту відповідної властивості й вибору адекватної характеристики iVC й підхарактеристики в (2), із подальшим сполученням з нею атрибута. При цьому метрики ijklM вимірювання елементів вибираємо з урахуванням рекомендацій стандарту ISO/IEC 9126, а також особливостей області застосування ПЗ. При відображенні, за рахунок використання атрибутів та їх елементів, долаємо нечітке формулювання вимог. Після цього, в залежності від специфіки предметної області, проводимо поділ елементів на критичні й другорядні, назначаючи вагові коефіцієнти ijklW . Сукупність вибраних характеристик загальної моделі складе сертифікаційну модель, яка має вигляд: {{ { } } Ce Ce iCe ijCe ijk ijkli I i J j K k ijkijk L l ijklCeijklijklijkijVCe PAWBMEASCQ 1 1 11 ,,,, = ===           ∈= , (3) 278 де атрибути ijkA повинні належати множині припустимих атрибутів ijkP (критерій – задоволення елементів ijklE обмеженням сертифікації ijklCeB ), а кожна з інструкцій αu відповідає своєму елементу атрибута ijklE . Сертифікація полягає у перевірці належності значень атрибутів моделі припустимій множині (див. формулу (3)). Ця перевірка здійснюється шляхом сертифікаційних випробувань. Подібний підхід (відображення вимог на множину уніфікованих характеристик якості загальних стандартів) можна застосувати для будь-яких класів ПС. Діаграма побудови сертифікаційної моделі якості ПС показана на рис. 1. Вимоги Загальна модель якості ISO/IEC 9126 - QG Вимоги замовника і користувача ПЗ Вимоги розробника ПЗ Сертифікаційна модель якості ПЗ - QCe Галузеві стандарти та нормативні документи Нормативна модель вимог - QN В и б ір ка Відображення Міжнародні стандарти в області якості ПЗ Рекомендації Рис. 1. Структурна схема побудови сертифікаційної моделі якості ПЗ 3. Побудова моделі якості ПЗ АСКП Використаємо розроблену концепцію для побудови сертифікаційної моделі якості ПЗ АСКП. Сертифікаційна модель має враховувати, з одного боку, вимоги замовника ПЗ та галузевих нормативних документів, а з іншого – максимально задовольняти рекомендаціям міжнародних та національних стандартів в області якості ПЗ. Модель якості насамперед буде складатися з показників якості, які пропонується класифікувати згідно з наявними базовими програмними комплексами цих систем, що показано на рис. 2. Комплекс програм відтворення параметричної інформації Програма підготовки градуювальних характеристик Програмне забезпечення АСКП Комплекс програм допускового контролю Комплекс програм контролю якості функціонування об'єкта Показники якості відтворення параметричної інформації Показники якості виявлення небезпечних відхилень Показники якості функціонування Показник якості інформаційного забезпечення Рис. 2. Класифікація показників якості ПЗ АСКП Методи та засоби програмної інженерії 279 Обрані показники якості являються характеристичними, бо вони є типовими для будь-яких автоматизованих систем контролю об'єктів за вимірювальною інформацією, оскільки ці системи обов'язково містять у собі вищенаведені комплекси й програми. Можливо, що з огляду на специфіку предметної області й класів розв'язуваних задач, для деяких систем будуть додаватися й інші показники, однак обрані показники якості залишаться основними. Ці показники є загальними, бо характеризують якість відтворення, виявлення подій контролю та якість функціонування об'єкта контролю. У даній роботі пропонується співвіднести ці показники з уніфікованими показниками якості загальних стандартів якості ПЗ. Обмеження для атрибутів характеристик формуємо на підставі аналізу нормативних документів для програмних систем даного типу. Отже, введені в розгляд характеристики якості являються універсальними даного класу ПС, бо характеризують якість основних комплексів програм, із яких складаються ці системи. Властиві ПЗ АСКП характеристики точності відтворення параметрів і контролю допусків при виявленні подій, визначаються с залученням метрик, заданих у числовому виді. Тому, у даній роботі пропонується виділити функціональність як базовий показник якості критичних систем цільового призначення [5], до яких відноситься клас ПЗ автоматизованих систем контролю. Висока питома вага даного показника забезпечить готовність ПЗ до виконання очікуваних дій у зв'язку з призначенням в процесі експлуатації. Таким чином, показники функціональності та надійності [7, 8] є базовими показниками якості ПС, що оцінюють стан об'єктів контролю. Після визначення всіх елементів моделі (3) переходять до сертифікаційних випробувань, в ході яких обчислюються фактичні значення атрибутів підхарактеристик якості. Для критичних елементів атрибутів вони порівнюються з нормативними обмеженнями. Програмне забезпечення АСКП будемо вважати придатним до застосування, якщо воно задовольняє вимогам, викладеним у державному стандарті України [20] і нормативних документах [21–23]. У створенні документів [22,23], а також стандарту [20], провідна роль належить фахівцям кафедри комп'ютерних інформаційних технологій НАУ. Ці документи затверджені Державним Департаментом авіаційного транспорту України, а нормативний документ [21] затверджений Міждержавним Авіаційним Комітетом країн СНД. Документи і стандарти включають вимоги до ПЗ у частині інформаційного і програмного забезпечення й переліку обов'язкових задач. Для визначення факту відповідності ПЗ АСКП вимогам стандарту і нормативних документів необхідно проводити сертифікаційні випробування, загальна методика яких викладена в документі [23]. Сертифікаційні випробування ПЗ АСКП являють собою встановлену процедуру, за допомогою якої експериментальним шляхом установлюється відповідність якісних і кількісних характеристик ПЗ вимогам вищевказаних нормативних документів [21–23]. Нормованими вимогами згідно ДСТУ 3275–95 [20] є : - рішення переліку обов'язкових задач; - інформаційне забезпечення; - точність відтворення зареєстрованих параметрів; - вірогідність результатів контролю з метою виявлення небезпечних відхилень; - загальні вимоги до ПЗ, що зводяться до рішення в повному обсязі переліку обов'язкових задач і наявності властивостей мобільності, інтероперабельності, підтримки національного алфавіту, задоволення вимогам відкритих систем; - вимоги до документації на програмний продукт, яка повинна бути достатньою для установки, експлуатації і супроводу ПЗ. Використовуючи характеристики якості, введені в ISO/IEC 9126-1, встановимо наступне відображення : 1) рішення переліку обов'язкових задач – характеристика якості функціональність, підхарактеристика повнота функцій; 2) інформаційне забезпечення – функціональність, повнота функцій; 3) точність відтворення параметрів – функціональність, точність; 4) вірогідність результатів контролю – функціональність, точність. Відображення пунктів 1), 3) і 4) очевидно, а для 2) помітимо, що в контексті стандарту [20], під інформаційним забезпеченням розуміється наявність ряду спеціальних файлів даних (що перевіряється простим порівнянням) і здатність ПЗ АСКП працювати в даній предметній області, тобто, обробляти ці формати даних очікуваним від нього образом, що віднесемо до функціональності. Загальні вимоги до ПЗ добре погоджуються з характеристикою функціональність, підхарактеристика повнота функцій. Наявність у повному обсязі властивостей мобільності, інтероперабельності, підтримки національного алфавіту та задоволення вимогам відкритих систем не впливає на безпеку життєдіяльності об'єкта контролю, який контролюється розглянутим ПЗ. Тому ця група характеристик буде належати до другорядних показників. Вимоги до документації також є загальними і перевіряються простим порівнянням. На основі аналізу вимог до ПЗ АСКП здійснимо вибір показників якості. Враховуючи вищесказане, в даній роботі пропонується класифікувати нормовані галузеві вимоги [20], здійснюючи їх відображення на характеристики моделі якості ISO/IEC 9126, як показано на рис. 3. Запропонована концепція використана авторами для побудови моделі якості ПЗ АСКП і числового розрахунку рівня його якості. Враховуючи вимоги загальних стандартів та нормативних документів, побудовано модель якості ПЗ АСКП. У цю модель введено 5 характеристик, 10 підхарактеристик і 14 атрибутів, що містять у цілому 48 елементів. З них 36 елементів атрибутів є критичними, а 12 – другорядними. В цей спосіб одержано цільову модель якості для заданої предметної області. 280 Виконання переліку обов'язкових задач ( x1 ) Відтворення параметричної інформації ( x11 ) Графічне представлення АП і РК ( u15 ) Синхронізація відображення ( Bx11 ) Вимога Атрибут вимоги Інструкція Обмеження Вірогідність результатів контролю ( x8 ) Оцінка помилок I роду ( x81 ) Критерій Неймана-Пірсона ( u8 ) Розрахунковий метод E1<0.01 ( Bx81 ) ... ... ... ... Відображення Точність відтворення параметрів ( x7 ) Інформація не менш ніж для 12 АП і 12 РК ( x71 ) Урахування дискретності опитування ( u71 ) Реєстраційний метод (так/ні) ( Bx71 ) ... ... ... ... Нормативна модель вимог ПЗ АСКП (ДСТУ 3275-95) Характеристика Функціональність ( C1 ) Функціональність ( C1 ) ... Функціональна повнота ( S11 ) ? Точність ( S12 ) ... ... Атрибут ... Елемент атрибуту ? ... ... Метрика ? ... ... Функціональність ( C1 ) ... Захищеність ( S14 ) ... ... ... ... ... ... ... Надійність ( C2) або (y9) ... Безвідмовність (S21) або (y91) ... ... ... ... ... ... ... Загальна модель якості ISO/IEC 9126 Підхарактеристика Вибірка, сполучення, узгодження Функціональність ( C1 ) Функціональна повнота ( S11 ) Відтворення параметричної інформації ( A111 ) Графічне представлення АП і РК ( E1115 ) Зовнішня номінальна метрика M1115 Синхронізація відображення (Bce11 ) Функціональність ( C1 ) ... Точність ( S12 ) ... Точність відтворення параметрів ( A121 ) ... ... Інформація не менш, чим для 12 АП і 12 РК (E1211) Номінальна метрика M1211 Реєстраційний метод (так/ні) ( Bce71 ) ... ... Функціональність ( C1 ) Точність ( S12 ) Вірогідність результатів контролю ( A122 ) Оцінка помилок I роду ( E1221 ) Метрична абсолютна шкала М1221 Розрахунковий метод E1<0.01 ( Bce81 ) Надійність ( C2 ) ... Безвідмовність ( S21 ) ... Частота відмов ( A211 ) ... ... Модель Шика- Волвертона (E2111) Абсолютна шкала М2111 Cтатистичні дані: X=\|A1-A2\|/B (Bce91) ... ... Сертифікаційна модель якості ПЗ АСКП ... ... ... ... ... ... ... ... ... ... ... ... ОбмеженняМетрикаЕлемент атрибуту Характеристика Підхарактеристика Атрибут Рис. 3. Побудова сертифікаційної моделі якості ПЗ автоматизованих систем контролю польотів Методи та засоби програмної інженерії 281 Таким чином, побудована шукана модель якості, для якої необхідно тепер визначити методику розрахунку елементів атрибутів. Отримані в даній роботі результати можуть бути застосовані, також, розробниками для створення власної системи управління якістю ПС. Висновки Отримано такі результати: 1. Розроблено концепцію побудови сертифікаційної моделі якості, суть якої полягає у відображенні вимог до ПС на характеристики загальної моделі якості, що сформована на основі рекомендацій стандартів серії ISO/IEC 9126. Концепція дає можливість отримати уніфіковані методи оцінки атрибутів якості. 2. За допомогою створеної концепції побудовано сертифікаційну модель якості ПЗ АСКП. 1. ДСТУ 2462–94. Сертифікація. Основні поняття. Терміни та визначення. – Чинний від 01.01.95. – К.: Держстандарт України, 1994. – 27 с. 2. ДСТУ 2844–94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення. –Чинний від 01.01.96. – К.: Держстандарт України, 1995. –15 с. 3. ДСТУ 2853–94. Програмні засоби ЕОМ. Підготовлення і проведення випробувань.–Чинний від 01.01.96. – К.: Держстандарт України, 1994. – 17 с. 4. Райчев І.Е., Харченко О.Г. Проблеми оцінювання якості критичних програмних систем при їх сертифікації // Проблемы программирования. – 2004. – № 2-3. – С.198 – 207. 5. Соммервилл И. Инженерия программного обеспечения : Пер. с англ. – М.: Изд. дом “Вильямс”, 2002. – 624 с. 6. Основы инженерии качества программных систем / Ф.И. Андон, Г.И. Коваль, Т.М. Коротун, В.Ю. Суслов. – Киев: Академпериодика, 2002. – 504 с. 7. Липаев В.В. Оценка качества программных средств // Сетевой журнал. – 2002. – № 3. – С. 52–56. 8. Бабенко Л.П., Лаврищева К.М. Основи програмної інженерії. Навч. посіб. – К.: Т-во “Знання”, КОО, 2001. – 269 с. 9. Грабовский М. Современные технологии и стандарты разработки программного обеспечения // Корпоративные системы. –2000. –№ 1. – C. 75–80. 10. Software Specification: A Framework, www.sei.cmu.edu/topics/publications/documents/cms/cm.011.html (12/99). 11. Брауде Э. Технология разработки программного обеспечения : Пер. с англ. – СПб.: Питер, 2004. – 655 с. 12. Gehani, Narain, and Lally, S., Software Specification Techniques (International Computer Science), Reading, MA: Addison-Wesley, 1985. 13. ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model, 2001. – 26 p. 14. ISO/IEC TR 9126-2. Software engineering – Product quality – Part 2: External metrics, 2003. – 86 p. 15. ISO/IEC TR 9126-3. Software engineering – Product quality – Part 3: Internal metrics, 2003. – 66 p. 16. ISO/IEC TR 9126-4. Software engineering – Product quality – Part 4: Quality in use metrics, 2004. – 70 p. 17. Лаврищева Е.М., Рожнов А.М. Концепция аналитической оценки характеристик качества программных компонентов // Проблемы программирования. – 2004. – № 2-3. – С. 180 – 187. 18. Райчев І.Е. Проблеми сертифікації програмного забезпечення автоматизованих систем контролю // Вісник Національного авіаційного університету. – 2004. – № 1. – С. 23–28. 19. Фатрелл Роберт Т., Шафер Дональд Ф., Шафер Линда И. Управление программными проектами : достижение оптимального качества при минимуме затрат. : Пер. с англ. – М.: Издательский дом “Вильямс”, 2003. – 1136 с. 20. ДСТУ 3275–95. Системи автоматизованого оброблення польотної інформації наземні. Загальні вимоги.–Чинний від 01.07.96. – К.: Держстандарт України, 1996. –7 с. 21. Единые требования МАК к системам обработки и анализа полетной информации. – М.: Изд-во МАК, 1993. Введен указанием ДВТ Минтранса РФ от 14.01.94. – 31 с. 22. Звід авіаційних правил України. Порядок збирання та практичного використання інформації бортових систем реєстрації на підприємствах цивільної авіації України. АПУ–3. Експлуатація повітряних суден. Введено в дію наказом Міністерства транспорту України від 02.12.96 за № 386. – К.: 1996. – 110 с. 23. Програма перевірки відповідності програмного забезпечення контролю польоту вимогам ДСТУ 3275–95 і “Порядку збирання та практичного використання інформації бортових систем реєстрації на підприємствах цивільної авіації України”. – К.: Державний Департамент авіаційного транспорту України, 1997. –11 с.

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

Репозитарії

Схожі ресурси