CC BY
36
Ключевые слова: преобразование, цитологические изображения, погрешность, контур.
Berezsky O.N. Research error of biomedical image contours transformation
The analysis of histological and cytological image characteristic features and automated systems of biomedical image processing is carried out. The errors components of "contour -contour" transformation are analysed and their estimation is carried out. The computer experiments of contours transformation errors are conducted on the example of cytological image.
Keywords: transformation, cytological image, error, contour.
УДК 004.4 Доц. В.В. Яцишин1, канд. техн. наук доц. О.Г. Харченко2,
канд. техн. наук; проф. О.А. Пастух1, д-р техн. наук; асист. 1.О. БоднарчуК
МЕТОД ЗАБЕЗПЕЧЕННЯ ЯКОСТ1 ПРОГРАМНИХ СИСТЕМ НА РАНН1Х СТАД1ЯХ ЖИТТ6ВОГО ЦИКЛУ
Розглянуто метод забезпечення якост вимог, що е одним з аспекпв управлшня та забезпечення якост програмних систем. На осж^ теоретико-множинних нотацш проведено формшшащю вимог якост до програмного забезпечення, проан^зовано крите-ри якост вимог та запропоновано способи i методи ix штеграцп у процес розробки ПЗ. Розроблено алгоритм збирання i класифжацп вимог якосп, процедуру побудови вимог до програмних систем на основi моделей якост стандарту ISO 25010, що дало змогу застосувати метод комушкаци вимог якост на стадiях життевого циклу.
Ключовi слова: якiсть вимог, яюсть програмного забезпечення, критерп якост вимог, управлiння якiстю програмного забезпечення.
Вступ. Актуальнiсть. Сучасне програмне забезпечення характери-зуеться високою функцюнальною iнтегрованiстю, мобiльнiстю, кросплатфор-мнiстю та орiентацiею на широке коло користувачiв. Тому важливим i одним з основних аспектiв розробки будь-якого програмного забезпечення е гаранту-вання якосп кiнцевого продукту. Саме якiсть продукту безпосередньо впливае на його конкурентоспроможнкть та можливiсть масового використання.
Як показують дослiдження [1, 2], яккть програмних продуктiв зали-шаеться не надто високою. Основними негативними факторами впливу на якiсть кiнцевого продукту е слабка формалiзацiя вимог якосп, вiдсутнiсть мето-дiв та процедур ix комунiкацií на стадiях життевого циклу, а також термшоло-пчш розбiжностi мiж замовниками та розробниками ПЗ. Для швелювання негативного впливу, наведених вище факторiв на яккть юнцевого програмного продукту, необхiдно вирiшити низку проблем, пов'язаних з iнтерпретацiею вимог до ПЗ та штегращею процесу управлiння вимогами на стадiях життевого циклу.
Продукто-орiентованi та процесо-орiентованi пiдходи до розробки програмного забезпечення не гарантують якосп продукту, оскшьки iснують потен-цiйнi ризики перевищення планово1 вартосп та часу виконання проекту. Це пов'язано з недосконалктю методов контролю та управлшня якктю ПЗ на стадь ях проектування або ж оркнтащею лише на якiсть виконання процеав життево-
1 Тернопiльський НТУ iM. 1вана Пулюя;
2 Нацюнальний авiацiйний ун1верситет, м. Кшв
го циклу. Тому актуальним завданням у сферi забезпечення якостi ПЗ е ство-рення нового тдходу, який би поеднував переваги продукто- та процесо-орiентованих пiдходiв до розроблення программного забезпечення.
1. Метод забезпечення якога вимог до програмних систем. Оскшьки вимоги е фундаментом у плануванш проекту, то для забезпечення якосп прог-рамного продукту, передусiм, пот^бно забезпечити якiсть самих вимог. Для цього необидно визначити критерií якосп, виходячи з рекомендацiй мiжнарод-них стандарта та практики розроблення програмного забезпечення. Стандарт [5] визначае таю основш критерií якостi вимог:
• коректтсть - вiдповiднiсть реальним потребам замовника.
• однозначтсть - однозначтсть розумiння (трактування) вимог.
• повнота - вимоги мають вiдображати Bci основнi потреби у ПС.
• узгоджетсть - узгодженiсть мiж рiзними типами вимог.
• впорядкованiсть - впорядковатсть вимог за важливiстю i стабiльнiстю.
• тестованiсть - можливють перевiрки виконання вимог.
• модифшоватсть - здатнiсть до редагування (додавання, видалення) вимог.
• простежуванiсть - можливють пов'язати вимогу з шдсистемами, модулями та операц1ями, якi вщповщають за ix виконання, i з тестами, що перевiряють ix ви-конання.
Для забезпечення якосп готового програмного продукту вимоги до якос-ri ПС повиннi бути простежуваними на вах стад1ях ЖЦ, а тому ix представления мають задовольняти таю вимоги [4, 7]:
• бути зрозумшими та форматзованими;
• бути об'ективними i вимiрюваними;
• мiстити критерп ощнювання;
• бути вщстежуваними i контрольованими на стадiяx ЖЦ.
Виходячи з практики розроблення програмного забезпечення, процес уп-равлiння якiстю вимогами мае базуватись на структурованих та документова-них вимогах. З метою забезпечення однозначности коректностi та повноти вимог до програмного забезпечення запропоновано 1х представляти в термiнаx моделей якосп стандарту ISO 25010 з попередньо проведеною формалiзацiею у виглядi теоретико-множинних нотацiй.
На стадп аналiзу вимог до ПЗ визначено низку процесш, першим з яких е процес збирання вимог (потреб). Зазвичай, таю потреби отримують шляхом анкетування, штерв'ю та аналiзу предметно! областi у довшьнш текстовiй фор-мi. Для формалiзованого представлення вимог запропоновано такий вираз:
{P, с1к}, i = \Т, k = 1K, (1)
де: Pi - вимоги користувача в текстовому вигляд^ Cik - обмеження на потреби.
Приведения вимог (1) до ушфжованого вигляду виконано шляхом !х вь дображення на структуру моделi якосп у використаннi стандарту ISO 25010:
Ruse = {HU, Aj, Cj Mu}, i e Nu, j = IF" , (2)
де: H" - характеристики моделi якостi у використаннi, A," - атрибути якостц Mij - метрики моделi якостi у використаннi.
Для задоволення i подальшого оцiнювання критерйв простежуваносп та здатностi до модифiкацií вимог до ПЗ запропоновано таку процедуру воображения (1) на структуру (2):
• представления (1) у виглядi шаблону {sb s 2, s 3, s4} де: s1 - поле "iдентифiкатор вимоги", s2 - поле "назва компоненту, до якого сформульована вимога", s3-поле "атрибут або характеристика якоси", видшет з тексту (1) та s4 - поле "метрика вимiрювання";
• класифшащя атрибутiв s3 за стандартизованими наборами характеристик i метрик з використанням бази знань, сформовано! експертним шляхом. У базi знань мiстяться асоцiацií мiж атрибутом шаблона та стандартною характеристикою i вщповщним !й атрибутом якостi, визначеним з анатзу предметно! областi та специфши класу, до якого належить ПЗ. Класифшащю проводять шляхом по-шуку в базi знань тако! пари {s1n, s 2n, s3n, s 4n} та {H", Лр, Mp} для яко! вико-
нуеться нерiвнiсть {Supp i} >= {Supp i} , де {Suppi}, l = 1,L, - пiдтримка асощ-
ацп, {Suppi} - визначений граничний рiвень асоцiацi!.
Оскiльки на якiсть програмного продукту впливають ризики, пов'язанi з невиконанням або частковим виконанням вимог, тому для кожного атрибута Лр моделi якостi стандарту доцiльно встановлювати ступiнь ризику Risk{F,f}, Fjj - фактор ризику. Ризики можна категоризувати ввдносно характеристик якосп стандарту ISO 25010. Тода основним завданням гарантування, а вiдтак i управлiння якктю ПЗ, е мiнiмiзацiя ризикiв, тобто
Risk{F,"} ® min . (2)
Однак при мiнiмiзацií ризикiв необидно враховувати ще й фактори тер-мiну i вартостi ix усунення.
Комунiкацiю (трасування) вимог якостi на стадiяx життевого циклу запропоновано реалiзувати вiдповiдно до методологи QFD, основою я^' е вста-новлення залежностi мiж користувацькими властивостями та техшчними характеристиками продукту. Суть методу, стосовно задачi комушкацп вимог, полягае у встановленш залежностi мiж вимогами якостi на сумiжниx стадiяx життевого циклу, шляхом побудови "будинку якостi". Схему застосування цього методу наведено у [9].
2. Алгоритм розробки вимог до програмних систем на 0CH0Bi моделей якост стандарту ISO 25010. Загальний процес розробки вимог до ПС, зпдно з [8], починають з аналiзу предметноí' областi, на основi якого проводять збiр i класифiкацiю вимог, а також визначають ik прюритетшсть. При цьому розробники для формування та аналiзу вимог використовують схему, наведену на рис. 1.
Ця схема (див. рис. 1) е узагальненою i не ушфжованою, оскшьки кожен розробник використовуе освоеш ним технологй' збирання, класифжацц i специ-фжацл вимог. При цьому яккть процесу розробки вимог прямо залежить вiд цих технологш.
Рис. 1. Узагальнена схема алгоритму розробки та аналiзу вимог до ПС
Для того, щоб структурувати i забезпечити комушкацш вимог, а також одночасно стандартизувати вимоги в загальному випадку, ми розробили алгоритм, який наведено на рис 2.
Рис. 2. Схема розробки та aHmi3y вимог до ПС на ocHoei моделей якост1 стандарту
ISO 25010
З анаизу схеми алгоритму процесу розробки та аналiзу вимог, наведено-го на рис. 2, видно, що формування вимог здшснюеться за трьома моделями якосп, характеристики яких е стандартизованими.
Алгоритм, наведений на рис. 2, е загальним вщносно до реалiзащí само'' процедури побудови моделей якосл на етапi розробки вимог. Дамо детальш-ший його виклад, починаючи з аналiзу предметно'' обласп i закiнчуючи специ-фшащею системних вимог.
Замовник програмного продукту формулюе сво' потреби, mi визначають функцiональнiсть ПС i загальний вигляд iнтерфейсу, а також вимоги до якостi, якi видшяються з потреб. При цьому представлення потреб може бути подане у довшьшй форм^ шляхом опису майбутнiх функцш ПС та особливостей штер-фейс1в, якi здебiльшого вiдповiдають критерiям простоти та зрозумiлостi.
На наступному крощ замовник спiльно з розробником проводять аналiз предметно' областi i сформульованих потреб Rc = {P, CiK}, i = 1, N, K = 1,Mt. Внаслщок аналiзу визначаються вимоги якосп користувача (замовника), якi за-писуються у виглядi множини атрибут1в {AiK}, K = 1,Si.
На основi сформованого набору атрибупв {AiK}, K = 1, Si будуеться модель якостi у використанш Основнi завдання, яш при цьому необхiдно викона-ти, полягають у класифшацп атрибутiв за вiдповiдними характеристиками мо-делi якостi у використанш та розв'язанш конфлiктностi атрибутiв.
Для класифжацп атрибутав за характеристиками моделi якостi у вико-ристаннi розроблено шаблон, який наведено у виглядi табл. При цьому передба-чаеться розподал атрибутiв множини {AiK}, K = 1, Sj за стандартизованими характеристиками моделi якостi у використаннi {И", М"}, i = 1,4, j = 1,Bi. Наступна
иеращя полягае в уточненнi та узгодженш з розробником ПС моделi якостi у використаннi на основi аналiзу вибраних метрик. Внаслiдок цього одержуемо вимоги якосп у використанш Ruse, представленi у структурованому, стандарти-зованому вигляд {И", A"., C"k, M"k}, i е N"k, K = 1,St.
Пiсля побудови моделi якосп у використаннi будуеться модель зов-нiшньоí' якостi. Для цього, з множини атрибутав, якi не увшшли до складу пер-шо' модел^ проводиться класифiкацiя за стандартизованими характеристиками та шдхарактеристиками моделi зовнiшньоí' якосп {ИХ, Щ, Mij}, i = 1,6, j = 1, Ki. Процедура здiйснюеться знову ж таки на основi шаблону (див. табл.)
Табл. Шаблон класифтацп ampu6ymie за структурою моделей якостi
Характеристика Iнтерпретацiя характеристики моделi якоси
Пщхарактеристика Iнтерпретацiя пiдхарактеристики моделi якостi
Назва атрибуту 1нтерпретащя атрибута моделi якостi
Визначення атрибуту Короткий опис атрибута моделi якост1, зв'язок з потребами
Мета/Мотивац1я Призначення атрибута з позицп потреби, яку необ-хiдно реалiзувати
Шкала вимiрювань Тип шкали для вимiрювання значения атрибута
Процедура визначення, протокол, Х Вказуеться процедура отримання та тип приналеж-ностi атрибута вщповщному учаснику проекту.
Примiтки |
Тип збору даних та пдрахунку Тип збору атрибута (ручний, автоматизований)
Метрика Назва метрики
Прюритетшсть Вказуеться вага атрибута у загальнш якоси ПС
Однак з метою уточнення та доповнення моделi зовшшньо' якостi проводимо аналiз атрибутав моделi {И", A"k, C"k, М"}, i е N"k, K = 1, Si, якi можуть вь
дображатись у вщповщт атрибути моделi, що будуеться. Внаслiдок цього от-римуемо вимоги зовшшньо' якостi ПС Rexct у виглядi {н?, ПК, Afc, СК, MK},
i e Nx, К = 1, Fix. Вимоги в такш формi використовуються на етат проектування архiтектури ПС для розробки теспв, тестуваннi, та ощнювання якостi робочого продукту цього етапу, що вiдповiдае рекомендац1ям стандарту ISO/ IEC 12207.
Побудова моделi внутршньо'* якостi здiйснюеться по аналоги до побудо-ви моделi зовнiшньоí якосп, однак при цьому враховуються вщображення ат-рибутiв моделi {H?, П?К, A?K, С?К, M?K}, i e Nx, К = 1, Fix на ii структуру. Внаслiдок цього отримуемо вимоги внутршньо! якостi R,n у виглядi {H?, ПК, AK, СК, MK}, ie Nx, К = \Wx.
Виходячи з ггерацш, якi необхiдно виконати для розробки вимог у виг-лядi структури моделей якостi, каскадну процедуру представимо у виглядi, як показано на рис. 3.
Рис. 3. Каскадна процедура розробки вимог якост1
Анаиз процедури проектування вимог, що наведена на рис. 3, показуе, що потреби замовника ПС i атрибути предметно' обласп е початковими даними для розробки i структурування вимог за моделями якосл. Висновки:
1. На 0CH0Bi анаизу факторiв впливу на якiсть вимог до програмних систем i критерпв, яким вони повиннi задовольнити, сформульовано задачу забезпе-чення якостi вимог, як фундамент забезпечення якост програмних систем.
2. Розроблено метод забезпечення якост програмних систем, який використо-вуе формалiзованi представлення моделей якост стандарту ISO 25010 та метод комушкацп вимог якостi на стадiях життевого циклу.
3. Розроблено алгоритми збирання та класифшацп вимог якоси, а також процедуру каскадного ix проектування, що дае змогу пiдвищити ефективнiсть i
повноту вiдображення вимог на наступних стадiях життевого циклу.
Лiтература
1. The Standish group report. CHAOS Manifesto 2013, Think Big, Act Small. [Electronic resource]. - Mode of access http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf.
2. The Standish group report. The CHAOS Manifesto 2012: The Year of the Executive Sponsor. [Electronic resource]. - Mode of access http://www.versionone.com/assets/img/files / CHAOSManifes-to2012.pdf.
3. Kharchenko A. The method of quality management software / A Kharchenko, I. Galay, V. Yatcyshyn // Perspective Technologies and Methods in MEMS Design (MEMSTECH), 2011 Proceedings of VlIth International Conference on 11-14 May 2011.
4. Hull E. Requirements Engineerig / E. Hull, Ken Jackson, Jeremy Dick. // Springer Science+Bu-siness Media. - 2005. - 240 p.
5. IEEE 982.2 Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software.
6. ISO/IEC 25010. Software Engineering - product quality. Quality model4.
7. Sommerville I. Deriving Information Requirements from Responsibility Models / I. Sommer-ville, R. Lock, T. Storer, J. Dobson // Proc. CAiSE 2009. 21st International Conference on Advanced Information Systems Engineering, Amsterdam, June 2009. - Рр. 515-529.
8. Брауде Е. Технология разработки программного обеспечения / Е. Брауде. - СПб. : Изд-во "Питер", 2004. - 655 с.
9. Харченко О.Г. Методи забезпечення та контролю якост web-застосувань на стадях життевого циклу / О.Г. Харченко, В.В. Яцишин, 1.О. Боднарчук // Вишрювальна та обчислю-вальна технжа в технолопчних процесах. - Хмельницький. - 2011. - № 1. - С. 21- 27.
Яцишин В.В., Пастух О.А., Боднарчук И.О., Харченко О.Г. Метод обеспечения качества программных систем на ранних стадиях жизненного цикла
Рассмотрен метод обеспечения качества требований, что является одним из аспектов управления и обеспечения качества программных систем. На основе теоретико-множественных нотаций проведена формализация требований качества к программному обеспечению, проанализированы критерии качества требований и предложены способы и методы их интеграции в процесс разработки ПО. Разработан алгоритм сбора и классификации требований качества, процедуру построения требований к программным системам на основе моделей качества стандарта ISO 25010, что позволило применить метод коммуникации требований качества на стадиях жизненного цикла.
Ключевые слова: качество требований, качество программного обеспечения, критерии качества требований, управление качеством программного обеспечения.
Yatcyshyn V. V., Pastuh OA., Bodnarchuk I.O., Kharchenko O.G. The method of quality assurance software systems on the early stages of life cycle
The article is devoted to the method of quality assurance requirements, which is one of the aspects of management and quality assurance software systems. On the set-theoretic notation was conducted formalization of quality requirements to software, analyzed quality criteria requirements and suggested ways and methods for their integration in the process of software development. An algorithm for the collection and classification of quality requirements, the procedure of building requirements for software systems based on models of quality standard ISO 25010 was developed. This algorithm and procedure are allowing us to apply the method of communication quality requirements on the stages of the life cycle.
Keywords: quality requirements, software quality, quality criteria requirements, quality management software.
