Підхід до моделювання якості сімейств програмних систем

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

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2009
1. Verfasser:	Коваль, Г.І.
Format:	Artikel
Sprache:	Ukrainian
Veröffentlicht:	Інститут програмних систем НАН України 2009
Schlagworte:	Методи програмної інженерії
Online Zugang:	https://nasplib.isofts.kiev.ua/handle/123456789/6579
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Zitieren:	Підхід до моделювання якості сімейств програмних систем / Г.I. Коваль // Пробл. програмув. — 2009. — № 4. — С. 49-58. — Бібліогр.: 20 назв. — укр.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	nasplib_isofts_kiev_ua-123456789-6579
record_format	dspace
spelling	nasplib_isofts_kiev_ua-123456789-65792025-02-23T17:51:57Z Підхід до моделювання якості сімейств програмних систем Подход к моделированию качества семейств программных систем An approach to the software family quality modeling Коваль, Г.І. Методи програмної інженерії Аналізуються проблеми моделювання якості сімейств програмних систем (СПС), визначаються вимоги до моделі якості СПС та пропонується підхід до моделювання, який полягає у комбінуванні різнотипних моделей відповідно до рівнів архітектури СПС (ієрархічних, аналітичних та байєсівських моделей), а також методу аналізу ієрархій для встановлення пріоритетів вимог до характеристик якості і наступного визначення інтегрального показника якості СПС. Проанализированы проблемы моделирования качества семейств программных систем (СПС). Определены требования к модели качества СПС. Предложен подход к моделированию, который заключается в комбинировании разнотипных моделей в соответствии с уровнем архитектуры СПС (иерархических, аналитических и байесовских моделей), а также метода анализа иерархий для установления приоритетов требований к характеристикам качества и последующего определения интегрального показателя качества СПС. Problems of software family quality modeling are analysed. Requirements for the software family quality model are determined and an approach for the modelling consisting in combination of various models according to the architecture levels (hieratic, analytical and Bayesian models) of software family is offered, as well as analytic hierarchy method for the prioritization of quality requirements and next determination of integral quality characteristic of software family. 2009 Article Підхід до моделювання якості сімейств програмних систем / Г.I. Коваль // Пробл. програмув. — 2009. — № 4. — С. 49-58. — Бібліогр.: 20 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/6579 681.3.06 uk application/pdf Інститут програмних систем НАН України
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	2009
topic_facet	Методи програмної інженерії
url	https://nasplib.isofts.kiev.ua/handle/123456789/6579
citation_txt	Підхід до моделювання якості сімейств програмних систем / Г.I. Коваль // Пробл. програмув. — 2009. — № 4. — С. 49-58. — Бібліогр.: 20 назв. — укр.
work_keys_str_mv	AT kovalʹgí pídhíddomodelûvannââkostísímejstvprogramnihsistem AT kovalʹgí podhodkmodelirovaniûkačestvasemejstvprogrammnyhsistem AT kovalʹgí anapproachtothesoftwarefamilyqualitymodeling
first_indexed	2025-11-24T05:44:35Z
last_indexed	2025-11-24T05:44:35Z
_version_	1849649345419280384
fulltext	Методи програмної інженерії 49 УДК 681.3.06 Г.І. Коваль ПІДХІД ДО МОДЕЛЮВАННЯ ЯКОСТІ СІМЕЙСТВ ПРОГРАМНИХ СИСТЕМ Аналізуються проблеми моделювання якості сімейств програмних систем (СПС), визначаються вимоги до моделі якості СПС та пропонується підхід до моделювання, який полягає у комбінуванні різнотип- них моделей відповідно до рівнів архітектури СПС (ієрархічних, аналітичних та байєсівських моделей), а також методу аналізу ієрархій для встановлення пріоритетів вимог до характеристик якості і наступ- ного визначення інтегрального показника якості СПС. Вступ Однією з новітніх парадигм програм- ної інженерії є парадигма генерувального програмування, заснована на ідеї інженерії сімейств програмних систем у певній предметній області (ПрО) і генерації окре- мих програмних систем (ПС) як членів сі- мейства [1, 2, 3]. Її використання надає ор- ганізаціям-розробникам низку переваг, а саме: зниження вартості та ризику проек- тів окремих ПС, постійне підвищення ква- ліфікації співробітників, вдосконалення процесу розроблення, стимулювання ево- люції СПС і, найголовніше, досягнення встановлених вимог до якості ПС та забез- печення їх конкурентноздатності [4]. Однак, відповідність вимогам до яко- сті кінцевих ПС та інших не функціональ- них характеристик може бути забезпечена лише в тому разі, якщо забезпечується якість програмних та не програмних арте- фактів, створюваних під час розроблення СПС, які накопичуються в репозитарії ін- тегрованого середовища розроблення (IDE, від Integrated Software Development) СПС як готові ресурси (ГОР) та повторно вико- ристовуються в окремих ПС – членах сі- мейства. Забезпечення якості ГОР різних кате- горій, наприклад, окремих програмних компонентів, композицій компонентів, ва- ріантів архітектури, фреймворків, а також сімейства ПС загалом, потребує застосу- вання відповідних категорій моделей якос- ті, які враховують ресурсні обмеження розроблення СПС і експлуатації ПС. У роботі аналізуються проблеми мо- делювання якості ГОР СПС окремих кате- горій та пропонується диференційований підхід до моделювання їх якості. Проблеми моделювання не функ- ціональних характеристик СПС Сімейство ПС представлене у репо- зитарії IDE множиною: 1) програмних ГОР – скриптів, поча- ткового (вихідного) коду, бібліотек, вико- нуваних (exe-) файлів тощо, якими є: – окремі програмні компоненти; – композиції компонентів; – варіанти архітектури СПС, подані множиною взаємопов’язаних компонентів; – фреймворки (компонентні карка- си), на яких «розгортається» архітектура у IDE; – ПС – члени сімейства; 2) не програмних (інформаційних) ГОР – документів, моделей (схем). Це, зо- крема, характеристичні моделі ПрО, онто- логії, функціональні та поведінкові специ- фікації СПС та ПС, специфікації архітек- тури СПС та окремих її варіантів. Характеристики якості ГОР СПС розглядаються в загальному контексті не функціональних характеристик ПС, проек- тів та виконуваних процесів, серед яких також присутні ресурсні характеристики – час, трудовитрати, та характеристики про- грамно-технічних умов (обмежень) екс- плуатації – комп’ютерного, мережаного обладнання, продуктивності використову- ваного програмного забезпечення тощо. Відповідно модель не функціональних ви- мог до СПС має включати дві складові – модель якості та модель ресурсів СПС. © Г.І. Коваль, 2009 ISSN 1727-4907. Проблеми програмування. 2009. № 4 Методи програмної інженерії 50 Модель якості визначає множину ха- рактеристик якості та взаємозв’язки між ними і є базисом для специфікації вимог до якості СПС та її оцінювання [5]. Мо- дель ресурсів визначає ресурсні обмежен- ня, як щодо розроблення СПС і ПС, так і щодо роботи встановленої ПС, у межах яких є адекватною модель якості. На відміну від функціональних вимог до ПС, не функціональні вимоги (НФВ) змоделювати та перевірити набагато скла- дніше. Якщо функціональні вимоги моде- люються відомими методами і засобами (FODA, FORM, FeatureRSEB тощо) і реалі- зуються через програмні ГОР, присутність яких у складі ПС і відповідність вимогам легко перевірити (вони або реалізовані, або ні), – не функціональні вимоги не моде- люються через безпосереднє «розкладен- ня» не функціональних характеристик по компонентах. Їх моделювання викликає низку проблем. По-перше, не функціональні вимоги є суб’єктивними, по різному інтерпретують- ся й оцінюються учасниками проекту. По-друге, не функціональні характе- ристики взаємопов’язані і можуть чинити позитивний або негативний вплив одна на одну, наприклад: – підвищення рівня зручності вико- ристання зумовлює зниження рівня ефек- тивності; – підвищення рівня ефективності спричиняє зниження рівня готовності і мо- дифікованості; – підвищення рівня готовності зумо- влює зниження рівня безпечності; – підвищення рівня захищеності спричинює зниження рівня зручності ви- користання й ефективності; – підвищення рівня будь-якої харак- теристики якості зумовлює підвищення вартості системи. По-третє, не функціональні вимоги пов’язані з реалізацією функціональних вимог, перш за все на рівні архітектури, оскільки архітектурні рішення можуть сут- тєво впливати на досягнення НФВ. Множина конкретних цільових не функціональних характеристик СПС ви- значається лише після того, як досить по- вно визначені функціональні потреби ПрО й архітектурні можливості їх реалізації, оскільки тільки тоді НФВ можуть бути де- композовані за рівнями і окремими компо- нентами архітектури. Така декомпозиція сприяє оптимізації архітектури з ураху- ванням загальних функціональних і не фу- нкціональних вимог до СПС, а також по- будові ПС з найкращою у сенсі якості ар- хітектурою. Деякі характеристики якості, напри- клад, ефективність, захищеність або моди- фікованість досить суттєво залежать від архітектури СПС і мають «вбудовуватися» у систему на рівні архітектурних рішень. До того, реалізація кожної характеристики якості зазвичай не може бути локалізована у частині архітектури (що прийнятно щодо реалізації окремої функціональної вимоги). Зміна вимог до значення характеристики може спричинити широкомасштабну зміну всієї архітектури (приклад – «вбудовуван- ня» коду з захисту інформації у ПС). Таким чином, варіабельність харак- теристик якості має інтегруватися у процес систематизованого керування варіабельні- стю архітектури СПС, включаючи як про- грамну, так і технічну конфігурацію. Доцільно виділити три категорії си- туацій, у яких компроміс щодо якості СПС досягається шляхом забезпечення варіабе- льності окремих характеристик якості [6]: 1) компроміс між окремими характе- ристиками якості q1 i q2. Замість того, щоб розробляти одну систему з «усереднени- ми» значеннями конфліктуючих характе- ристик q1 i q2, можна розробити два варіа- нти її архітектури (в одному перевага на- дається характеристиці q1 у збиток харак- теристиці q2 , в іншому – навпаки) і нада- вати право користувачеві СПС комплекту- вати ПС за власним уподобанням. Прикла- дом є технічне рішення щодо довжини па- ролю доступу в систему. Відомо, що, чим довший пароль, тим вище рівень захисту інформації, але нижче ефективність систе- ми, і навпаки. Розробнику ПС на основі СПС треба надати можливість вибрати по- трібну комбінацію значень характеристик захищеності й ефективності; 2) компроміс між характеристикою якості qі і ресурсом проекту ri. Рівень зна- чення характеристики якості qі може варі- Методи програмної інженерії 51 юватися відповідно до рівня наявних ре- сурсів ri . Приклад – чим вищий рівень за- хищеності системи потрібний користува- чеві, тим дорожче це йому коштуватиме. У СПС треба забезпечувати встановлення (і реалізацію) декількох рівнів кожної харак- теристики і надавати користувачеві право вибирати найбільш прийнятний; 3) компроміс між характеристикою якості qі і експлуатаційним ресурсом сi. Приклад – чим вище роздільна здатність монітора, тим ширша кольорова гама і тим вище значення характеристики зручність використання за відповідним критерієм. У СПС треба реалізовувати механізм масш- табування ПС з урахуванням технічних обмежень і надавати користувачеві мож- ливість встановлювати значення характе- ристики відповідно до класу та призначен- ня ПС (обчислення, 3D-графіка тощо). Хоча засобом специфікації характе- ристик якості у СПС є моделі характерис- тик, вони не передбачають можливості ва- ріювання значень, зокрема, у неперервний спосіб, наприклад, в інтервалі (0, 1). Крім того, не ясно, яким чином змоделювати двосторонні впливи характеристик (напри- клад, q1 впливає на q2, а q2 впливає на q1). Одним з виходів є «трансформація» характеристик якості у функціональні ха- рактеристики, що, з одного боку, забезпе- чить можливість пошуку в СПС потрібно- го варіанта реалізації ПС, а з іншого – спричинить проблему суттєвого переван- таження характеристичних моделей. На- приклад, в характеристичній діаграмі мо- жуть виникнути такі функції, як «функція захисту з довгим паролем», «функція захи- сту з коротким паролем» тощо. Інший ви- хід – замість розроблення стратегій пошу- ку варіанта архітектури, який відповідати- ме встановленому рівню якості певної ха- рактеристики, розробити метод прогнозу- вання якості можливих варіантів архітек- тури (композицій компонентів) у СПС. Загальні вимоги до якості СПС та моделей якості Якість СПС асоціюється з множиною характеристик, поданих у табл. 1. Таблиця 1. Характеристики якості СПС Назва характе- ристики Зміст та підстави для забезпе- чення Повторна викорис- товува- ність ГОР Можливість багаторазового використання ГОР через за- стосування концепції і методів розроблення ПС з повторно використовуваних компонен- тів (ПВК) Гнуч- кість Забезпечення композиції неза- лежних компонентів на основі спільності властивостей Еволю- ційність Застосування модельного під- ходу до розроблення СПС та реалізація механізмів варіабе- льності СПС Ефекти- вність Наявність механізмів генерації ПС як членів СПС Прозо- рість Підтримка метаопису (аноту- вання) ГОР СПС Концепт- туальна ціліс- ність Забезпечення несуперечливос- ті різних категорій ГОР та від- сутності категорій ГОР, не пов’язаних з іншими жодними механізмами Повнота Достатність (на момент оці- нювання) ГОР певної категорії для потреб ПрО. Приклад – повнота переліку характерис- тик у моделі характеристик Корект- ність Забезпечення відповідності ГОР певної категорії вимогам до їх подання у репозитарії IDE (дотримання уніфіковано- сті опису ГОР) Доступ- ність Наявність в IDE механізмів пошуку ГОР певної категорії та маніпулювання ними. Від- сутність ГОР, які технічно не можуть бути використані для побудови ПС Стандар- тизова- ність Застосування стандартизова- них засобів для опису ГОР (рішень OMG, W3C); інтер- фейсів ГОР; процесу розроб- лення СПС і ПС Продук- тивність Використання готових про- грамно-технологічних рішень для побудови і ведення ГОР, зокрема готових інструментів Для того щоб модель якості СПС ефективно використовувалась щодо ГОР Методи програмної інженерії 52 різних категорій, вона має відповідати на- ступним вимогам [7]. По-перше, вона має бути гнучкою з огляду на контекст її використання, який включає: – тип організації, яка замовляє ПС і має власне бачення множини характерис- тик її якості. Підхід до моделювання якості СПС має забезпечувати адаптацію моделі до потреб кожної з організацій–учасників розроблення ПС на основі СПС; – клас розроблюваної ПС і особли- вості її експлуатації користувачами різних категорій. Модель має бути придатною для оцінювання якості Веб-застосувань, вбу- дованого програмного забезпечення тощо, а також враховувати погляди на характе- ристики якості різних категорій спожива- чів – менеджерів, персоналу супроводу, користувачів ПС; – виконуваний процес. Модель має адаптуватися до рівня зрілості організації- розробника ПС, досконалості процесів життєвого циклу (ЖЦ), готовності об’єктів до застосування щодо них програми вимі- рювання, починаючи на самих ранніх ста- діях ЖЦ, а також припускати поповнення даними у ЖЦ ПС та повторне уточнююче оцінювання. Оцінюваними об’єктами є ар- тефакти, розміщувані в репозитарії IDE і такі, що стосуються ПрО, процесу розроб- лення і ресурсів [3]. Модель має поєднува- ти кількісні (виміряні) та якісні (експертно оцінені) дані щодо об’єктів, які уточню- ються в ході ЖЦ ПС. По-друге, модель має бути повторно використовуваною, придатною для відо- браження узагальненого досвіду за мно- жиною проектів (відповідно до парадигми сімейства процесів [3]) і припускати отри- мання екземпляру моделі для нового прое- кту, максимально наближеного до вже представлених у сімействі. З одного боку, це підвищить ефективність і зменшить трудовитрати на моделювання якості для нових ПС, а з другого – підвищить точ- ність і ефективність оцінювання якості за- вдяки накопиченню досвіду оцінювання. Нарешті, модель якості має бути про- зорою щодо складу і змісту характеристи- ка їх взаємозв’язків і забезпечувати їх об- ґрунтованість та ідентифікацію. Ієрархічні моделі якості програм- них компонентів СПС Аналіз підходів до моделювання яко- сті СПС показав, що існують труднощі в застосуванні ієрархічних моделей якості, більшість з яких засновується на еталонній моделі характеристик у ISO/IEC 9126 [8]. Вони є статичними за природою і не опи- сують, як робити проекцію метрик від їх поточних значень на певному етапі проек- ту до нових значень на його подальших стадіях, що важливо для визначення ризи- ку проекту. Крім того, деякі з цільових ви- мог до якості було б природніше включати у функціональні вимоги до СПС і не вда- ватися для їх оцінювання до методів мет- ричного аналізу. Наприклад, характерис- тика «здатність до взаємодії» може транс- формуватися у функціональні вимоги до інтерфейсу ПС, а її досягнення перевіряти- ся тестуванням. Аналогічно можна вчини- ти і з характеристикою «переносність». У проблематиці побудови СПС ієра- рхічні моделі можуть використовуватися з метою специфікації окремих ГОР, що є COTS компонентами (готовими компонен- тами на ринку програмної продукції), які потребують сертифікації перед включен- ням у репозитарій IDE СПС. Постачальники COTS компонентів найбільшу увагу приділяють технічним аспектам їх проектування і реалізації у гі- потетичних середовищах, тоді як розроб- ники СПС і ПС на їх основі – асемблюван- ню систем з компонентів та розгортанню у конкретних цільових середовищах. З цієї позиції важливим для них є невизначеність щодо якості, і, перш за все, надійності компонентів через невідомість щодо сце- наріїв їх використовування (тобто, немож- ливість визначення їх операційних профі- лів [9]). Виникає потреба тестування ком- понентів (вже після придбання) у складі ПС. Проблем додають відсутність доступ- ного початкового коду і детальної докуме- нтації для супроводу компонентів. Повторне використання компонентів у цільових середовищах має гарантуватися через чітке специфікування програмних архітектур та сценаріїв, у яких можливе функціонування компонентів, а також об- межень щодо композицій компонентів, у Методи програмної інженерії 53 яких може спостерігатися зниження якості (наприклад, надійності або реактивності) системи. Іншою проблемою є відсутність су- проводжуваності та замінної здатності компонентів, що могло б зменшити залеж- ність від постачальників. На теперішній час для вирішення цієї проблеми можуть складатися договори на гарантійне обслу- говування (заміну) компонентів як умова їх сертифікації перед випуском. Крім того, компоненти мають бути гнучкими, адаптуватися до змін у потребах користувачів, і припускати, у відповідь, розширення специфікацій вихідних вимог до них з попередньою перевіркою непо- рушності обмежень. Об’єднуваною властивістю компоне- нтів є їх довірча придатність – властивість підтримувати довіру користувачів до якос- ті компонентів, які використовуються. Ця властивість може забезпечуватися через сертифікацію компонентів стороннім ор- ганом сертифікації. Як варіант (для некри- тичних компонентів) може застосовувати- ся сертифікація організацій-розробників компонентів. Процес сертифікації компо- нентів полягає у верифікуванні рівнів за- безпечуваних показників якості компонен- тів та надаванні сертифікату відповідності стандартам, а також адекватності заданій множині встановлених вимог. Процедура сертифікації потребує формування належ- ного середовища тестування компонентів. До того ж необхідні стандартизовані моде- лі якості компонентів для проведення сер- тифікації. Одну з таких моделей запропоновано в [10]. Її структуру показано на рис. 1. По- рівняно з еталонною моделлю якості в ISO/IEC 9126 у модель введено додаткові підхарактеристики якості – зовнішні (по- дані в прямокутниках), оцінювані під час виконання (конфігурованість, масштабо- ваність), і внутрішні (подані в заокругле- них прямокутниках), оцінювані під час розроблення (автономність, повторна ви- користовуваність). Крім того, виключено з моделі характеристику «аналізованість» та змінено назву підхарактеристики «здат- ність до встановлення» на «розгортува- ність». Рис. 1. Ієрархічна модель якості COTS На додаток до характеристик якості запропоновано оцінювати ресурсну харак- теристику компонентів «ринкова придат- ність», важливу для сертифікаційного про- цесу. Вона представлена підхарактерист- ками: – час розроблення – час, необхідний для розроблення компонента; – вартість – ціна компонента; – час до випуску – час, необхідний для випуску компонента на ринок; – ринковий обсяг – цільові обсяги випуску компонента на ринок; – попит – наскільки компонент ко- ристується попитом; – ліцензованість – наявність ліцензій компонента. Хоча ці характеристики не мають безпосереднього відношення до якості, во- ни є важливими для формування думки споживачів (розробників СПС) щодо дові- рчої придатності компонентів. Так, напри- клад, дані про час, необхідний для дове- дення компонента до випуску, може свід- чити про його завершеність. Поряд з представленою є й інші ком- біновані моделі, які включають характери- стики не лише якості, але й ресурсів (на- приклад, модель Т. Джілба [11], моделі COQUALMO [12], SQUID [13] тощо). Методи програмної інженерії 54 Вони розширюють можливості ієрар- хічних моделей і можуть адаптуватися до потреб окремої організації або класу ПС. Ці моделі враховують більшість чинників, що впливають на якість ПС [8], допомага- ючи уникнути конфліктів між різними ви- могами до якості, дають можливість указу- вати множину вимірів для функціонально розрізнених компонентів ПС (обчислюва- льних, інтерфейсних, інформаційних (баз даних)) і встановлювати різні правила ви- мірювань. Особливості моделювання архіте- ктури в контексті якості СПС Архітектура СПС визначає концепти, структуру та внутрішню будову СПС, не- обхідні для досягнення варіабельності ха- рактеристик ПрО у варіантах ПС (членах ПС) із забезпеченням максимального спі- льного використання частин (композицій компонентів) реалізації. Мета моделюван- ня архітектури – передбачення якості ПС до її побудови, виходячи із знань, який вплив матимуть архітектурні рішення на показники якості. Інша мета – з’ясування думок щодо адекватності архітектури ви- могам до СПС і визначення її слабких сто- рін. Існують два способи відображення якості в архітектурі: – використання архітектурних стилів та шаблонів для «вбудовування» вимог до якості у ПС; – використання профілів якості (на- приклад, розширень профілів UML), які доповнюють архітектурну модель певними аспектами якості та є засобом зіставлення вимог до якості й архітектурних рішень з метою оцінювання архітектури. Ці способи подання якості застосо- вуються у сучасних методологіях проекту- вання та оцінювання архітектури (HoPLAA [14], QADA [15] тощо). Однак, для забезпечення повної від- повідності вимогам до моделей не функці- ональних характеристик СПС у моделю- вання якості треба залучати методи інтеле- ктуального аналізу даних, зокрема, засно- вані на байєсівському підході [16]. В робо- ті [17] обґрунтовано доцільність його за- стосування для моделювання умовних зв’язків чинників якості та їх впливу на цільову характеристику якості ПС. Прак- тичної значущості цей підхід набув лише з появою байєсівських мереж (Bayesian Network), на базі яких будуються графічні байєсівські моделі (БМ) [18]. Основна пе- ревага БМ – підтримка прогнозування за- даного показника якості ПС і діагностики найбільш вірогідних причин (джерел) його не досягнення. До того ж, апарат байесів- ських мереж дозволяє будувати достатньо складні моделі (сотні вершин), які не мо- жуть бути реалізовані іншими методами. Використання БМ у проблематиці розроблення СПС дозволяє враховувати різні аспекти і джерела варіабельності – відмінні вимоги замовників щодо функці- ональних та не функціональних характери- стик множини ПС, створюваних на основі СПС, різновиди середовищ експлуатації цих ПС, особливі потреби щодо їх супро- водження, еволюції тощо. БМ репрезентує знання експертів у ПрО і досвід виконання подібних проектів. Вона стає невід’ємним ГОР у IDE, який повторно використовується в ЖЦ СПС для якісного аналізу впливу конфігурацій варі- антів рішень на показники якості. Приклад використання БМ для аналі- зу впливу варіантів архітектури на її якість показано на рис. 2. Це фрагмент байєсівсь- кої мережі SAABNet (Software Architecture Assessment Belief Network) для оцінювання архітектури [19]. Рис. 2. Модель оцінювання архітектури Методи програмної інженерії 55 Вершини БМ представляють: – атрибути архітектури на різних рі- внях подання (об’єктно-орієнтована мова програмування архітектури, архітектурний стиль тощо). Ці атрибути подано на рис. 2 вершинами БМ світло-сірого кольору; – підхарактеристики якості та відпо- відні їм метрики (складність, зрозумілість тощо). Вони подані на рис. 2 вершинами БМ темно-сірого кольору; – характеристики якості, заявлені у вимогах до ПС, наприклад, повторна вико- ристовуваність, супроводжуваність (вер- шини білого кольору). Дуги БМ встановлюють умовні зале- жності між сутностями у вершинах. Іншим відомим підходом до моделю- вання якості ПС, який використовує байє- сівські мережі і задовольняє встановленим вимогам до моделей якості СПС, є підхід Prometheus [7]. Це ціле-орієнтований під- хід до вимірювання та оцінювання якості СПС, який інтегрує кількісні та якісні ме- тоди моделювання. Процес моделювання включає три фази: – фаза специфікації вимог до якості, під час якої будується модель якості. По- слідовність кроків щодо специфікації мо- делі якості показано на рис. 3; Рис. 3. Кроки специфікації моделі якості – фаза застосування, в ході якої ви- конується оцінювання ступеня досягнення вимог з використанням моделі якості; – фаза накопичення досвіду, під час якої інформація щодо застосування моделі збирається і аналізується з метою покра- щення моделі та її повторного викорис- тання в інших проектах ПС. Вимоги до якості визначаються із за- стосуванням методології вимірювання «Ціль-Питання-Метрика» (GQM, від Goal- Question-Measure) [8]. Відповідно до мето- дології вони конкретизуються до переліку вимірюваних характеристик і підхаракте- ристик оцінюваних програмних об’єктів сімейства. Потім встановлюються взаємо- зв’язки між характеристиками (підхарак- теристиками) і вимірами. Розрізняються два типи зв’язків – декомпозиція характе- ристик (згори – вниз) і вплив рівня (зна- чення) однієї характеристики на значення іншої. Метрики можуть мати не кількісне, а якісне (експертне) подання (з викорис- танням, наприклад, порядкової шкали). Байєсівські мережі використову- ються в Prometheus для квантифікації зв’язків (впливів), а також комбінування кількісних і якісних даних. Модель якості будується через опитування експертів у ПрО, які визначають цілі та характеристи- ки якості. Недоліки названого підходу стосу- ються специфікації характеристик якості. По-перше, Prometheus не використовує ISO/IEC 9126 як орієнтир для побудови моделі якості, а по-друге, не надає форма- лізованої структури специфікації вимог до якості. Схема моделювання якості СПС Найбільш прийнятним підходом до моделювання якості СПС є підхід, який розвиває підхід Prometheus і полягає у ком- бінуванні різнотипних моделей відповідно до рівнів архітектури, наприклад: – ієрархічних моделей на рівні окре- мих компонентів; – аналітичних моделей залежностей для композицій компонентів; – байєсівських моделей щодо частин архітектури, для яких не можуть бути встановлені аналітичні залежності та на момент оцінювання відсутні значення ви- мірів якості у репозитарії IDE; – методу аналізу ієрархій (МАІ) для збалансування вимог до характеристик якості й/або визначення інтегрального по- казника якості СПС. Схему моделювання якості за запро- понованим підходом показано на рис. 4. Методи програмної інженерії 56 Рис. 4. Схема моделювання якості СПС Для кожної стадії ЖЦ СПС визнача- ються оцінювані об’єкти (щодо ПрО, ви- конуваних процесів і використовуваних ресурсів, включаючи людські) та їх атри- бути, встановлюються процедури їх вимі- рювання, вибираються метрики оцінюван- ня та будується байєсівська мережа. Залежно від оцінюваної характерис- тики якості, метрики можуть бути прости- ми, рекомендованими ISO/IEC 9126, або складними аналітичними моделями (на- приклад, для оцінювання надійності ком- понентів [18]). Специфікація вимог до якості ГОР виконується за шаблоном (табл. 2). Для формалізації процесу встанов- лення пріоритетів вимог до якості, роз- в’язання конфліктів з урахуванням погля- дів на якість всіх учасників проекту СПС, а також для кількісного порівняння різних варіантів архітектурних рішень з позицій якості, використовується МАІ. Цей метод вже використовувався в проблематиці інженерії якості для встано- влення пріоритетів компонентів функціо- нальної архітектури одиничної ПС і насту- пного розподілу за ними цільових вимог до якості ПС та оцінювання внеску компо- нентів у досягнення якості за встановле- ною характеристикою [20]. Запропонований підхід забезпечує можливості: – виконання оцінювання, починаючи з ранніх стадій ЖЦ; – ефективне навчання впродовж роз- роблення нових ПС на основі СПС; – уточнення моделі якості за послі- довними проектами ПС; – інтеграцію кількісних (заснованих на вимірюванні) і якісних методів; – комбінування різних контекстів індивідуальних поглядів на якість СПС (розробників, користувачів) і оцінюваних об’єктів (процесів, продуктів, ресурсів). Методи програмної інженерії 57 Таблиця 2. Шаблон специфікації вимог Атрибут специфі- кації Зміст атрибута специфікації Назва ха- рактерис- тики Стисле визначення або по- силання на стандарт, в якому подано визначення характе- ристики Опис ви- моги Обґрунтування потреб щодо забезпечення вимоги Контекст (фокус) Об’єкт, якого стосується ви- мога (ГОР, ПС, процес) Джерело Джерело інформації щодо вимоги (документи, замов- ники, розробники тощо) Зв’язки Зв’язок з характеристиками якості в еталонній моделі ISO/IEC 9126 Категорія Приналежність вимоги до рівнів якості (внутрішня, зо- внішня, експлуатаційна [8]) Пріоритет Значущість вимоги для утримувачів СПС (максима- льна, середня, низька) Обов’яз- ковість Обов’язкове / необов’язкове виконання вимоги Вплив Дії у процесах ЖЦ, інші ка- тегорії вимог, які зазнають впливу даної вимоги Чутли- вість Вплив з боку інших характе- ристик (позитивний / нега- тивний) Висновки Якість ПС, розроблюваних за пара- дигмою генерувального програмування, обумовлюється якістю окремих ГОР, ви- користаних на різних стадіях побудови ПС на основі СПС, зокрема, програмних ГОР та їх архітектурних сполучень. Для моделювання якості програмних ГОР можуть використовуватися відомі іє- рархічні моделі, але вони не застосовні для моделювання якості СПС. Моделювання якості СПС стикається з низкою проблем, які стосуються, насам- перед, його архітектури, яка має бути при- йнятною для будь-якої ПС сімейства та є критичною для досягнення таких характе- ристик якості як ефективність, безпечність, супроводжуваність. З іншого боку, зміни вимог до якості можуть зумовити зміну архітектури. Модель якості, яка б враховувала означені проблеми, має бути гнучкою, прозорою та повторно використовуваною для всіх ПС сімейства. Встановленим ви- могам відповідають байєсівські графічні моделі, які інтегрують кількісні та якісні оцінки щодо вимірюваних об’єктів СПС. Запропонований підхід до моделювання якості СПС полягає у комбінуванні різно- типних моделей відповідно до рівнів архі- тектури СПС (ієрархічних, аналітичних та байєсівських моделей), а також методу аналізу ієрархій для встановлення пріори- тетів характеристик якості СПС і, за необ- хідності, визначення інтегрального показ- ника якості. 1. Лавріщева К.М. Генерувальне програмування програмних систем і їх сімейств // Проблеми програмування. – 2009.– № 1. – С. 3 – 16. 2. Лавріщева К.М, Коваль Г.І., Коротун Т.М. Під- ходи інженерії якості сімейств програмних си- стем // Проблеми програмування. – 2008. – № 2-3. – С. 219 – 228. 3. Лавріщева К.М., Коваль Г.І., Слабоспицька О.О., Колєснік А.Л. Особливості процесів керу- вання при створенні сімейств програмних сис- тем // Проблеми програмування. – 2009. – № 3. – C. 40 – 49. 4. Framework for Software Product Line Practice, version 5 – http://www.sei.cmu.edu/productlines/ index.html 5. ISO/IEC 9126-1:2001 Software Engineering – product quality. Part 1 Quality model. 6. Myllarniemi V., Mannisto T, Raatikainen M. Qual- ity Attribute Variability within a Software Product Family Architecture – http://www.soberit.hut.fi/ vmyllarn/publications/Myllarniemi06bQualityAt- tributeVariability.pdf 7. Trendowicz A., Punter T. Quality Modeling for Software Product Lines – http://www-ctp.di.fct. unl.pt/QUASAR/QAOOSE2003/papers/QAOOSE _2003_TrendowiczPunter__Quality_Modeling_ for_Software_Product_Lines.pdf 8. Основы инженерии качества программных сис- тем / Ф.И. Андон, Г.И. Коваль, Т.М. Коротун, Е.М. Лаврищева, В.Ю. Суслов // 2-е издание. – Киев.: Академпериодика, 2007. – 672 с. 9. Коваль Г.И., Мороз Г.Б., Коротун Т.М. Конце- пция профилей в инженерии надежности про- граммных систем // Математичні машини і сис- теми. – 2004. – № 1. – С. 166 – 184. 10. Alvaro A., Almeida E.S., Meira S.R. Quality At- tributes for a Component Quality Model – http://research.microsoft.com/~cszypers/events/W COP2005/09%20-%20Alvaro.pdf 11. Gilb T. Principles of Software Engineering Man- agement, Addison-Wesley. – 1988. – 442 p. Методи програмної інженерії 58 12. Madachy R., Boehm B. Assessing Quality Processes with ODC COQUALMO // Lecture Notes in Computer Science. – 2008. – Vol. 5. – P.198 – 209. 13. Kitchenham B., Linkman S., Paquini A. The SQUID approach to defining a quality model // Software Quality Journal. – 1997. – Vol. 6. – P. 211 – 233. 14. Olumofin F.G., Misic V.B. Extending the ATAM Architecture Evaluation to Product Line Architec- tures. – http://www.cs.umanitoba.ca/~vmisic/pubs/ tr0502.pdf 15. Matinlassi M., Niemela E., Dobrica L. Quality- driven architecture design and quality analysis method. – http://www.vtt.fi/inf/pdf/publications/ 2002/P456.pdf 16. Моррис У. Наука об управлении. Байесовский подход. – М.: Мир, 1971. – 304 с. 17. Коваль Г.І. Байєсівські мережі як засіб оціню- вання та прогнозування якості програмного за- безпечення // Проблеми програмування. – 2005. – № 2. – С. 15 – 23. 18. Коваль Г.І., Коротун Т.М., Мороз Г.Б. Байєсів- ські мережі: застосування для керування про- грамними проектами // Вісник МНТУ. – 2008. – № 2. – C. 125 – 132. 19. van Gurp J. Variability in Software Systems. The Key to Software Reuse – http://www. jillesvangurp.com/static/Lic/licentiatethesis.pdf 20. Коваль Г.І., Мороз Г.Б. Моделювання вимог до якості програмних систем оброблення даних // Проблеми програмування (Спец. вип. конф. УкрПРОГ-2006). –2006. – № 2-3. – С. 237 – 244. Отримано 17.07.2009 Про автора: Коваль Галина Іванівна, кандидат фізико-математичних наук, старший науковий співробітник відділу. Місце роботи автора: Інститут програмних систем НАН України 03187, Київ-187, Проспект Академіка Глушкова, 40. Тел.: (044) 526 4579. e-mail: gagaips@ukr.net

Підхід до моделювання якості сімейств програмних систем

Institution

Ähnliche Einträge