CC BY
34
УДК 004.[015.5+891.3]:681.3.06 Проф. Ю.1. Грицюк, д-р техн. наук -
НУ "Льbeiecbm полтехшка "; здобувач П.Ю. Грицюк, магктр - НЛТУ Украти
СУЧАСН1 ПРОБЛЕМИ НАУКОВОГО ОЦ1НЮВАННЯ ЯКОСТ1 ПРИКЛАДНОГО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Проведено аншш сучасних проблем наукового оцшювання якост прикладного програмного забезпечення (ПЗ), результат якого дав змогу сформулювати рекомендацн щодо модифшацн наявних методiв i засобш побудови ПЗ, технологiй та моделей аналь зу якостi ПЗ. Розглянуто наявнi методи та засоби ощнювання якостi прикладного ПЗ та моделi управлшня його якiстю. Описано методологвд та обгрунтовано потребу застосу-вання технологГ! розроблення прикладного ПЗ через тестування (Test Driven Development - TDD) для шдвищення якост та надiйностi його роботи. З'ясовано, що технологiя TDD дае змогу: проводити модульне тестування та тестування функциональной! ПЗ; виявляти помилки в процес виконання ПЗ; проводити шэлГз програмного коду щодо покриття тестами ПЗ.
Ключовi слова: програмне забезпечення (ПЗ), яюсть прикладного ПЗ, надшшсть прикладного ПЗ, моделi та атрибути якостГ ПЗ, розроблення ПЗ через тестування, тера-цн тестування ПЗ.
Вступ. Вiдомо [8], що на сьогодш процес розроблення прикладного програмного забезпечення (ПЗ) - найбшьша сфера дшльносп у свiтовiй економщ, в якiй зайнято близько 3 млн. фахiвцiв (програмiстiв, розробниюв програмних продуктiв та in), водночас як iншi 5 млрд осiб безпосередньо залежать вiд 1хньо1 успiшноí дiяльностi. За останш декiлька десятилiть завдання, якi потрiб-но виконати шд час розроблення ПЗ, ршень 1хньо1 складностi та форми подання отриманих результатов кардинально змiнилися. Але й дониш наявнi шформа-цiйнi технологи виготовлення якiсного ПЗ не стали повсякденною нормою.
Джерела неполадок сучасного прикладного ПЗ вкрай рiзноманiтнi, i це тiльки ускладнюе проблему, а також збшьшуе li масштаб та варткть. На думку Д. Паттерсона [14], свггове гонiння за продуктившстю призвела до залежностi людини ввд технологiй, тому людству пора створювати такi iнформацiйнi технологи, на ят свiт дiйсно може покластися, повнiстю довiряючи 1м. Звiсно, ха-отичний перiод удосконалення ПЗ, коли значно бшьше уваги придшялось саме програмному коду, а не його якосп, став вiдходити у минуле. За останнi роки програмна iндустрiя досягла такого рiвня удосконалення, при якому вимоги до забезпечення якосп стали обов'язковим пунктом договорiв на предмет розроблення прикладного ПЗ, оскшьки саме його яшсть е найважливiшою характеристикою з точки зору користувача - безпосереднього споживача ПЗ.
Однак, у сферi забезпечення якосп ПЗ iснуе неприхована криза. Зпдно з маркетинговими дослiдженнями фiрми Standish Group International [5], витрати на розроблення ПЗ становлять близько 275 млрд $, але тальки 72 % програмних проектав сягають етапу впровадження та усього 26 % iз них завершуються усш-хом. Це означае, що тальки 71,5 млрд $ витрачаються на усшшш проекти, а решта 200 млрд $ задкш на провальш або незавершенi розробки. За щею ж статистикою 18 % програмних проектав нiколи не завершуються, 53 % проектов завершуються з перевитратами на 56 % i перевищенням термiнiв на 84 % i тiльки 29 % проектов вкладаються у термiни та бюджет.
Проведений ще у 1993 р. [16] ан^з програмних проекпв, що зазнали невдач^ дав змогу видiлити 10 причин провалiв, причому 7 i3 них повнiстю за-лежали ввд прийнятих рiшень керiвниками на початкових етапах ix реалiзацií:
1) KepiBH^H проеклв не повнiстю розумiють вимоги замовника;
2) масштаби peалiзацi'i проекту визначено неправильно;
3) змши до проекту впроваджуються з великими труднощами;
4) змiнам шддають обрану технологш проектування;
5) замовник часто змшюе вимоги до проекту;
6) встановлений термш виконання проекту нереальний;
7) замовник не приймае деяких ршень, без яких неможлива подальша реаль зацiя проекту;
8) швестицн на проект затримуються або повнiстю втрачено;
9) для peалiзацil проекту не вистачае виконавщв;
10) менеджери проекту не застосовують прогресивних мeтодiв управлшня. До^дження 50 проекпв, на mi витрачено понад 400 людинорокiв i якi
мiстили майже 3000000 рядкш коду, проведенi у Лабораторií проектування ПЗ NASA [4], показали, що шдвищена увага до раннього контролю якосп дае змогу ктотно знизити ршень помилок, але не знижуе загальних витрат на процес його розроблення. Водночас, у робоп [7] зазначено, що саме в кшщ етапу проектування можна й варто виявляти та усувати до 55 % всх помилок майбутньо-го ПЗ. Отже, забезпечення можливостi виявлення помилок у ПЗ як на раншх, так i пiзнiх етапах його життевого циклу дали б можливкть не тшьки зменшити витрати на його розроблення, але й уникнути багатьох шцидентш, причини яких можна виявити на етапах формулювання вимог щодо проектування.
На сьогодш розроблено чимало методов i засобiв, технологiй та моделей забезпечення якосп прикладного ПЗ. При цьому в основу процесу розроблення ПЗ покладено фундаментальну iдею: його проектування е формальним проце-сом, який можна вивчати i вдосконалювати. Хоча для цього залучаються крашд фахiвцi як в Украíнi - B.C. Харченко, Г.1. Коваль, В.Г. Тоценко, О.В. Поморова та ia; у крашах СНД - ВВ. Липаев, Ю.Д. Корольков та in, так i за кордоном -B.W. Boehm, А. Avizenis, H. Trauboth та iн., але яккть такого ПЗ, як i рашше, залежить вiд знань та досв^ роботи самих розробникiв.
Однак, через прагнення розробникш ПЗ зменшити собiвартiсть процесу його розроблення, формуються новi концепцл щодо розроблення прикладного ПЗ шляхом застосування таких новiтнiх технологш як: Rapid Application Development (RAD), Extreme Programming (XP), Agile Software Development (ASD), з використанням таких методiв, як: Test Driven Development (TDD), Behavior Driven Development (BDD) та Feature Driven Development (FDD). В зв'язку з цим набувае актуальносп завдання шдвищення якосп ПЗ шляхом модифiкацií наяв-них методiв, технологiй та моделей якосп.
Отже, теорiя та практика наукового ощнювання якостi прикладного ПЗ потребуе кардинальних змiн, позаяк яккне виконання цiеí роботи сприяе запо-бiганню техногенним катастрофам [8, 9], появою рiзних надзвичайних ситуацiй i навiть звичайних iнцидентiв, викликаних помилками роботи ПЗ.
Об'ект до^дження - яккть прикладного ПЗ на рiзних етапах його життевого циклу.
Предмет до^дження - методи i засоби ан^зу i оцiнювання якостi прикладного ПЗ на рiзних етапах його життевого циклу.
Мета роботи полягае в аналiзi сучасних проблем наукового ощнювання якостi прикладного ПЗ, результат якого дасть змогу сформулювати рекоменда-цш щодо модифiкацií наявних методiв, технологш та моделей якостi ПЗ.
Викладення основного матерiалу. Криза у сферi забезпечення якостi ПЗ була помггною ще понад пiв столiття тому, коли велик проекти стали вико-нуватися з вiдставанням вiд графжа виконання робiт або з перевищенням кош-торису витрат, розроблений програмний продукт не мав потрiбних функщ-ональних можливостей, продуктивнiсть його була низька, яккть прикладного ПЗ не влаштовувала споживачш. При наявностi ряду методiв i засобiв, залучен-ш кращих фахшщв для розроблення технологш та стандарпв забезпечення якостi ПЗ, його яккть, як i рашше, залежала i залежить вiд знань та досв^ самих розробниюв. В табл. 1 наведено помилки прикладного ПЗ з катастрофiчни-ми наслвдками [6], якi були внесет на раншх етапах життевого циклу.
Табл. 1. Анали помилок прикладного ПЗ та ixnix насйдшв
Под1я | Причина | Наслщки
Етап формулювання вимог
Збш у систем1 Нью-Йоркського банку Недостаттсть пам'ят1 через неправильн1 вимоги 32 млрд дол.
У 1990 р. на AT&T вщбу-лась 9-ти годинна аварш Проблеми з граничними умовами у специфшаци 75 млн. нездшснених дзвш-кiв, втрата 60 млн. дол.
У 1998 р. на AT&T вщбу-лась 26-ти годинна аварш Проблеми з прихованими граничними умовами у спе-цифшацп Непрацездатшсть служб, пов'язаних з передачею да-них
Помилка Y2K - помилка двоцифрового збереження року у дата (1999 р.) Неправильтсть або непов-нота специфшацп Втрати - 500 млрд дол.
Етап проектування
У 1983 р. на станцп "Сер-пухов-15" спрацювала система виявлення Неправильно спроектована система розтзнавання Свгг був на меж1 ядерно!' вшни
У 1991 р. система протира-кетно! оборони Patriot не перехопила 1ракську ракету Помилка заокруглення -некоректний розрахунок м1сцезнаходження ракети, що наближалась Загинули 28 американських солдат та близько 100 чоло-вш отримали поранення
Помилка Y2K - помилка двоцифрового збереження року у дата Неправильний проект Втрати 500 млрд дол.
"Смертельна" терапк у Национальному онколопчно-му 1нститут1 у Панама-С1т1 в 2001 р. Некоректне обчислення доз рад1ац11 у ПЗ компанп Multidata Systems International 28 пащенив зазнали над-м1рного опромшення, де-кшька хворих померли
Авар1я на завод1 з перероб-лення урану в Захщнш Австрали в 2001 р. Лопчна помилка у алгорит-м1 Викид радюактивно! речо-вини
У табл. 2 наведено розподш помилок, яю виникають на етапах форму-лювання вимог, проектування та реалiзацií прикладного ПЗ рiзного обсягу [4]. З ще1 таблицi видно, що помилки формулювання вимог та проектування станов-
лять 25-55% Bcix помилок, причому чим бшьший обсяг ПЗ, тим бiльше помилок вноситься саме на paHHix етапах. Варто врахувати також i той факт, що BapTicTb виправлення помилки проектування в 2-4 рази вища вартосп виправлення по-милки конструювання.
Табл. 2. РозподЫ помилок, припущених на pi3Hux етапах життевого циклу
Етап життевого циклу ПЗ
2 К
Обсяг ПЗ, Кбайт
8 К
32 К
128 К
512 К
Формулювання вимог, %
8*10
12*15
16*20
18*22
18*23
Проектування, %
12*15
15*19
20*25
22*28
26*32
Конструювання, %
60*75
53*66
44*55
40*50
36*45
Отже, забезпечення можливосп раннього виявлення помилок i ощню-вання якоси програмного проекту i прогнозування piвня якоси розроблюваного за проектом прикладного ПЗ ще на етат його проектування дали б змогу змен-шити витрати на процес його розроблення, а також уникнути ряду катастроф та шциденпв, причини яких були внесет на рантх етапах його життевого циклу.
Враховуючи основш тенденцп удосконалення iнфоpмацiйних технологiй на сучасному етапi становлення шформацшного суспiльства, виникае потреба в тдвищенш якостi та надiйностi прикладного ПЗ. Вiдомi на сьогоднi методологи та технологи контролю якостi та надшноси ПЗ, якi знаходять широке засто-сування на етапi розроблення прикладного ПЗ (рис. 1), дають змогу ефективно ощнювати характеристики вщповщних програмних пpодуктiв [14, 16].
Рис. 1. Тuпологiя програмно-апаратних комплексе критичного застосування [1]
Для формування наукових гшотез щодо шляхiв забезпечення якоси прикладного ПЗ розглянемо процес його розроблення з використанням технологи тестування Test Driven Development (TDD) [10] та сформуемо загальш ре-
комендацп щодо пiдтримки, оцiнювання та пiдвищення вщповщно якостi та на-дiйностi прикладного ПЗ.
В галузi якостi ПЗ юнуе безлiч стандартiв - нащональних, галузевих, вь домчих, корпоративних i т.д. Згiдно з ДСТУ 2850-94 i ДСТУ 2844-94 [2], тд яюстю ПЗ розумшть сутнiсть властивостей, що визначають ступiнь його при-датностi для використання за призначенням, а також видтяються такi характеристики якосп ПЗ: функцiональнiсть, надшшсть роботи, зручнiсть використання, ращональшсть, можливiсть супроводу та мобiльнiсть.
Анаиз лiтературних джерел в областi якосп та надiйностi ПЗ дае рiзнi визначення його якостi вiдомих фахiвцiв у галузi 1Т, серед яких набуло визнан-ня таке консолщоване визначення: якiсть прикладного ПЗ - динамiчна характеристика, яка визначае вщповщшсть кiнцевого програмного продукту вимогам замовника та забезпечуе вiдсутнiсть дефекпв у ньому.
Огляд наукових дослщжень, пов'язаних з якiстю ПЗ, дае змогу зробити висновок про те, що тут основною проблемою е розроблення конструктивних пiдходiв до побудови базово'1 моделi якостi ПЗ, яка була б придатною для рiз-них класiв i методологiй його розроблення, та визнавалась одночасно розробни-ком, замовником i користувачами. Шляхом проведення аналiзу вiдомих моделей якосп ПЗ визначено еволюцш пiдходiв до оцiнювання якостi та побудови вщповщно'' моделi якостi, яку наведено на рис. 3.
Модел! яко(гп Маккола (1977), Боема (1978), FURPS (1987), Дрогу« (1991)
Сформовано чинники, критерп, атрибута якосп: зрозумшсть, зручшсть, здатшсть до вщновлення, адекватшсть та ш.
ISOflEC 9126 (1991). Ушверсальна модель якост1
Визначено методи та засоби тестування програмного продукту для забезпечення необхщного р1вня якосп.
ISO/IEC 14598 (2000). Модель ощнювання якосп
Представлено методологи та модел1 ощнювання якосп: СММ, CMMI, QFD, СОСОМО II, Tick IT та ш.
ISO/IEC 9126 (2001-2004). Загальна модель якост1
Вщображено вимоги до якосп програмного забезпечення та галузев1 стандарти (галузевий прототип якосп).
Рис. 3. Еволющя пiдходiв до ощнювання якостт прикладного ПЗ [1]
На основi проведеного анаизу наявних моделей якосп ПЗ у роботi [1] наведено порiвняльну характеристику складових його якосп за рiзними моделями (табл. 3).
288
Серiя eKOHOMi4Ha
Табл. 3. Порiвняльна характеристика атрибута якостi ПЗ за рпними моделями
ATpu6yTH AKocri 1 2 3 4 5
Mo^HHBicTt TecTyBaHHa (Testability) + + +
npaBHHtHicTt (Correctness) +
Pe3yntTaTHBHicTt (Efficiency) + + + + +
3po3yMinicTt (Understand ability) + +
HagmmcTb (Reliability) + + + + +
rHymcTt (Flexibility) + +
OyHK^oHarnmcTb (Functionality) + + +
iH^eHepHa ncuxonoris (Human Engineering) +
^nicmcTt (Integrity) + +
CyMicHicTt (Interoperability) + +
3aBepmemcTt (Maturity) +
PeMOHTonpugaTHicTt (Maintainability) + + + + +
Mo^HHBicTt Mogu^iKyBaHHa (Changeability) +
Mo^HHBicTt nepeHeceHM (Portability) + + + +
noBTopHe BHKopucTaHHa (Reusability) + +
3py^HicTt BHKopucTaHHa (Usability) + + + +
Приштка: 1 - модель Боема; 2 - модель Маккола; 3 - модель FURPS; 4 - стандарт ISO 9126; 5 - модель Дромi
Шжнародним стандартом для визначення якосп ПЗ е ISO 9126:2001 [13]. Вш складаеться з таких частин тд загальним заголовком "Iнформацiйна технолопя, характеристики та метрики якостi програмного забезпечення": Час-тина 1. "Характеристики та субхарактеристики якостГ; Частина 2. "Зовнiшнi метрики якостi"; Частина 3. "Внутршш метрики якостi"; Частина 4. "Метрики якосп у використанш". Модель внутрiшнiх i зовшшшх характеристик якостi ПЗ вiдповiдно до ISO 9126:2001 складаеться iз шести груп базових показникiв, кожна з яких деталiзована набором нормативних субхарактеристик. Додатково кожна характеристика супроводжуеться субхарактеристикою узгодженосп, що мае вiдображати ввдсутшсть суперечностi з iншими стандартами i нормативни-ми документами, а також з шшими показниками в даному стандарт!
З точки зору процеав вишрювання якостi, то ця характеристика ПЗ по-дiляеться на внутршню якiсть, яка вимiрюеться за статистичними властивостя-ми коду; зовнiшню яккть, яка вимiрюеться за динамiчними властивостями коду в процесi виконання; яккть використання ПЗ, яка вимiрюеться за показником, якому вона вiдповiдае за вимогами користувача в робочому середовишд. Вза-емозв'язок мiж рiзними поданнями якостi прикладного ПЗ наведено на рис. 4.
Характеристики, субхарактеристики та атрибути якосп прикладного ПЗ iз позицií можливостi та точностi !х вимiрювання подшяються на три типи:
• категоршний - описовий, що вщображае Ha6ip властивостей i загальт характеристики об'екта - його функцп, якi можуть подаватися номшальною шкалою категорш-властивостей;
• юльккний - подаеться множиною впорядкованих числових точок, що вщобра-жають неперервнi закономiрностi функщонування програми та описуються ш-тервальною або вiдносною шкалою, яю можна об'ективно вимiряти та чисельно зютавити з вимогами;
• ятсний - складаеться з деюлькох впорядкованих або окремих значень - категорш, якi характеризуються порядковою або точковою шкалою набору встановлених категорiй, вибираються та оцiнюються значною мiрою суб'ективно та експертно.
Прикладне ПЗ Ефект вщ роботи ПЗ
Впливае Впливае
Biiyipiiiiiisi ЯШСТЬ Зовншшя ЯК1СТЬ Якать використання
— <-—
у Залежить вщ у Залежить вщ у Внутршт вишри Зовшшш вюшри Вюшри в npou,eci
використання
Рис. 4. Взаемозв 'язок мiж видами якоот прикладного ПЗ
Пеpеxодячи до ^оцесу забезпечення якоси ПЗ, потpiбно визначити по-няття iнженеpiï якостi, що e ^оцесом забезпечення y пpогpaмниx пpодyктax властивостей, якi xapaктеpизyють ïx якiсть. Вщповщно до [13] y пpоблемaтицi iнженеpiï якостi pозpiзнюють тpи особливостi ïï забезпечення: зaпобiгaння по-явi дефеклв y пpогpaмномy пpодyктi, виявлення та усунення дефектiв безпосе-pедньо на тих етапах його житного циклу, на яких вони були внесет, а також пiдвищення якостi тдчас його тестування. Вpaxовyючи описане вище, ^изна-чення пpоцесiв iнженеpiï якосп пpиклaдного ПЗ потpiбно пеpеглянyти вщпо-вiдно до новiтнix теxнологiй pозpоблення ПЗ [10, 12].
За pезyльтaтaми детального огляду вiдомиx методологiй загального уп-paвлiння якiстю ПЗ [12], таких як: TQM (Total Quality Management); pозгоpтaн-ня ^оцеав забезпечення якосл QFD (Quality Function Deployment); гнучк тех-нологiчнi лiнiï (Lean Software development, Quality Improvement Paradigm); схо-динки до якостi (CMM, SPICE, Bootstrap, Trillium), виявлено потpебy вдоскона-лення пpоцесy yпpaвлiння його яюстю на всix етапах житного циклу [11].
Вiдповiдно до стaндapтiв якостi ПЗ [3], одним iз нaйyживaнiшиx методiв забезпечення якостi e його тестування, тобто, стс^ежен^ за функщонуван-ням ПЗ в специфiчниx умовах pоботи для визначення ступеню його вщповщ-ностi встановленим вимогам. Рашше, а iнколи й тепеp, шиpоко викоpистовy-ються тaкi методи оцшювання якостi пpиклaдного ПЗ, яю базуються на його сyб,eктивномy с^ий^^ та iнтyïцiï експеpтiв. Однак, вщповщно до стaндapтy ISO 9126, концепция забезпечення якостi ПЗ за paxyнок тестових специфiкaцiй наведена на pra. 5.
Поpiвняeмо пpоцес тестування ПЗ з шшими методами оцiнювaння його якост1 Для цього скоpистaeмося звггами до пpоектy SCOPE [15], в якому видь лено методи та засоби оцшювання piзниx xapaктеpистик якоси ПЗ, а саме:
• вивчення документiв до програми шляхом пошуку проблемних мюць i перевiр-ки вщповщноста його стандартам, стилям програмування, прийнятим правилам i угодам: цшьове вивчення коду (code inspection); цшьове вивчення документа-ци (documents inspection);
• формалъний анал1з: формальне доведення властивостей програми (formal verification);
• автоматичний аналiз: анамз програмного коду (static analysis); аналiз архкек-тури та проекту (architecture review, design review); аналiз процесу розроблення (process analysis);
• вимiрювання:: визначення метрик ПЗ, проекту, документацп; вимiрювання про-дуктивност (benchmarks); профшювання (profiling);
• моделювання роботи: використання моделей ПЗ для оцшювання його властивостей: моделi використання (usability model); моделi над^оста (reliability model); моделi фyнкцiонyвання (model checking); моделi прототипування (prototyping).
Рис. 5. Модель концепци забезпечення якостг ПЗ за рахунок тестових специфтацш
Внаслщок проведеного анамзу наявних методiв оцшювання якостi ПЗ, а також управ-лiння його якiстю можна зробити висновок про те, що щ методи базуються на системному тд-ходi та передбачають формування комплексно! оцiнки якостi ПЗ, тому вони не можуть засто-совуватися в технологи тестування TDD пов-ною мiрою. Однак, за аналогiею з наявними методами оцiнювання та шдвищення якостi ПЗ технологiя TDD дае змогу: проводити модуль-не тестування та тестування функцюнальносп ПЗ; виявляти помилки в процесi виконання ПЗ; проводити аналiз програмного коду щодо пок-риття тестами.
Рис. 6. В1зуал1зац1я шераци тестування за технолог1ею TDD
Технологiя програмування TDD е однieю з основних практик екстре-мального програмування, при якш модульнi тести для Bcie'i програми або i"i фрагменту пишуться ще до процесу написання програмного коду, та, як насль док, управляють процесом його розроблення. Розроблення ПЗ в стилi TDD складаеться з коротких циклiв (iтерацiй), яю наведено на рис. 6. Базовi характеристики Test Driven керащ'1 починаються зi створення набору теспв i завер-шуеться успiшним виконанням тестiв.
Виникнення помилки при компшюванш ПЗ та помилкове виконання набору тес™ не е обов'язковим, що, водночас, пiдтверджуе ймовiрнiсть устшно-го виконання TDD ггерадй. На рис. 7,а та 7,б продемонстровано можливi варь анти проходження ггерадш за технологiею Test Driven Development.
Я) ............................""""б)
Рис. 7. Momnuei eapiaHmu виконання шерацп тестування за технологieю TDD
Ця технолопя мае значш переваги над шшими технологiями (такими як BDD чи FDD), позаяк значно шдвищуе яюсть прикладного ПЗ, а саме:
• тести запобтають появi помилок у новому код^ що безпосередньо шдвищуе якiсть ПЗ на всьому ци^ його розроблення;
• тести дають змогу проводити рефакторiнг коду, що дае змогу полшшити його структуру та повшстю замiнюе там методики пiдвишення якостi ПЗ, таю як статистичний аналiз програмного коду та арх^ектури, формальну верифiкацiю та ш. Окрiм цього, рефакторiнг коду замшюе процес верифкацп прикладного ПЗ з використанням таких методик як: нас^зний контроль, колегiальнi пере-вiрки та шспекцп, що значно шдвищуе його якють i зменшуе часовi та виробни-4i витрати на його розроблення;
• тести можуть використовуватися як документащя, що взагалi вилучае потребу цшьового вивчення документацп для пошуку проблемних мiсць та перевiрку ПЗ вiдповiдностi стандартам, що значно шдвищуе його якють;
• тести сприяють тдвищенню квалiфiкацil розробниюв (PSP, Personal Software process та TSP, Team Software process) та пришвидшують процес розроблення. Отже, згщно з вимогами сучасного замовника, та з врахуванням новiтнiх
кондепдй розроблення ПЗ проаналiзовано проблему пiдвищення якост та на-дiйностi прикладного ПЗ. При дьому за основу використано технологш розроб-
292
Серiя еконо!шчна
лення TDD, яка дае змогу формулювати рекомендаций щодо модифiкацií наяв-них методiв, технологiй та моделей якостi ПЗ. Проведений ан^з моделей та шдходш до оцiнювання якостi прикладного ПЗ визначае:
• потребу вдосконалення процесу управлшня якiстю прикладного ПЗ на вах ета-пах його ЖЦ та потребу перегляду призначення процеив iнженерií якостi для новiтнiх методологш розроблення ПЗ;
• потребу створення конструктивних концепцiй побудови базово'1 моделi якостi прикладного ПЗ, яка була б придатною для рiзних клаав i сучасних технологiй його розроблення.
Висновки та перспектива виконання подальших дос.'пджень
1. З результатiв аналiзу сучасного стану проблеми наукового ощнюван-ня якостi прикладного ПЗ, а також наявних методов i засобiв його ощнювання виникае потреба проведения наукових дослiджень з проблеми оцiнювання та прогнозування якостi ПЗ на уах етапах його життевого циклу.
2. Актуальнкть проблеми пiдвишения якостi прикладного ПЗ визначае потребу розроблення фундаментально! теори та методологи системного аналiзу його якосп та надiйностi, ощнювання та забезпечення (гарантування) якостi, а також потребу розроблення моделей якосп ПЗ, ят б враховували вплив рiзних чинникiв на процес управлшня якктю ПЗ.
3. Перспективою виконання подальших дослiджень е забезпечення пов-ноти та цiлiсностi показникiв i характеристик якостi ПЗ, для чого потрiбно:
• визначити функцц, яю за кiлькiсними оцiнками показникiв якоси прикладного ПЗ надаватимуть коректнi юльюст оцiнки характеристик якостi;
• визначити функщю, яка за кiлькiсними оцшками характеристик якостi прикладного ПЗ, враховуючи ixm взаемовпливи, надаватиме коректну та достовiрну кiлькiсну оцiнку якоси ПЗ загалом;
• розробити методолопю, яка враховуватиме взаемовпливи показникiв тд час ощнювання характеристик якостi та взаемовпливи характеристик за комплексного ощнювання якосп ПЗ.
Лгтература
1. Волкова С.О. Дослщження юнуючих шдходш пiдвищення якостi програмного забезпечення критичного застосування / С.О. Волкова, О.М. Трунов // Радюелектронш та комп'ютерш програми : наук.-техн. журнал. - Харюв : Вид-во НАУ 1м. M.G. Жуковского "Харкхвський аш-ащйний шститут". - 2008. - № 6. - С. 202-208.
2. ДСТУ 2844-94. Программ засоби ЕОМ. Забезпечення якосп. Термши та визначення. Введ. 1.08.1995. - К.: Вид-во Держстандарт Украши, 1995. - 57 с.
3. Канер С. Тестирование программного обеспечения / Сэм Канер, Джек Фолк, Енг Кек Нгуен. - К. : Изд-во "ДиаСофт", 2000. - 554 с.
4. Макконнелл С. Совершенный код. Мастер-класс / С. Макконнелл. - М. : Изд-во "Русская редакция", 2013. - 896 с.
5. Мищенко В.О. CASE-оценка критических программных систем. - В 3-ох т. - Т. 1: Качество / В.О. Мищенко, О.В. Поморова, Т.А. Говорущенко; под ред. В.С. Харченко. - Харьков : Изд-во НАУ им. Н.Е. Жуковского "ХАИ", 2012. - 201 с.
6. Поморова О.В. Аналiз методш та засобш ощнки якост програмних систем / О.В. Поморова, Т.О. Говорущенко // Радюелектронш i комп'ютерш системи : наук.-техн. журнал. - Харкв : Вид-во НАУ iм. М.С. Жуковського "Харкiвський ашацшний iнститут". - 2009. - № 6 (40). - С. 148-158.
7. Поморова О.В. Сучасш проблеми ощнювання якост програмного забезпечення / О.В. Поморова, Т.О. Говорущенко // Радюелектронш та комп'ютерш програми : наук.-техн. журнал. -
Харюв : Вид-во НАУ iM. M.G. Жуковского "Харювський ашацшний шститут". - 2013. - № 5. -С. 319-327.
8. Скляр В.В. Оценка качества и экспертиза программного обеспечения : лекционный материал / В.В Скляр. - Харьков : Изд-во НАУ им. Н.Е. Жуковского "ХАИ", 2008. - 204 с.
9. 20 Famous Software Disasters. [Electronic resource]. - Mode of access http://sandipsandil-ya.word-press.com/2011/01/17/20-famous-software-disasters/. - 18.11.2012 г.
10. Murphy Craig. Improving Application Quality Using Test-Driven Development / Craig Murphy. [Electronic resource]. - Mode of access http://www.Methodsandtools.coin/archive/ archive.php?id = 20.
11. Dubois, H.F.W. Harmonization of the European vaccination policy and the role TQM and reengineering could play / H.F.W. Dubois // Quality Management in Health Care. - 2002. - Vol. 10(2). -Pp. 47-57.
12. Introduction to Behavior Driven Development. [Electronic resource]. - Mode of access http://behaviour-driven, org/.
13. ISO/IEC 9126-2001 Software engineering - Product quality (Part 1 - 4) : Quality model, 2001. - 26 p.
14. Patterson, D. Recovery oriented computing: a new research agenda for a new century / D. Patterson // Proceedings of Eighth International Symposium on High-Performance Computer Architecture, 2002. - Pp. 125-127.
15. Rae А.К. Software Evaluation for Certification: Principles, Practice and Legal Liability / А.К. Rae, H.L. Hausen, and P. Robert (Editors) // McGraw Hill, International Software Quality Assurance Series, 1995. - Pp. 21-27.
16. Reiter G.J. Software management, IEEE Computer Society Press / G.J. Reiter. - Los Alamos, 1993. - 236 p.
17. Software goes wrong, we all know that, but just how wrong can it go?. [Electronic resource]. - Mode of access http://www.datareservoir.co.uk/bugs/. - Название с экрана на 18.11.2012 г.
Грыцюк Ю.И., Грыцюк П.Ю. Современные проблемы научной оценки качества прикладного программного обеспечения
Проведен анализ современных проблем научного оценивания качества прикладного программного обеспечения (ПО), результат которого позволил сформулировать рекомендации по модификации имеющихся методов и средств построения ПО, технологий и моделей анализа качества ПО. Рассмотрены существующие методы и средства оценивания качества прикладного ПО и модели управления его качеством. Описана методология и обоснована потребность применения технологии разработки прикладного ПО путем его тестирование (Test Driven Development - TDD) для повышения качества и надежности работы. Выяснено, что технология TDD позволяет: проводить модульное тестирование и тестирование функциональности ПО; выявлять ошибки в процессе выполнения ПО; проводить анализ программного кода по покрытию тестами ПО.
Ключевые слова: программное обеспечение (ПО), качество прикладного ПО, надежность прикладного ПО, модели и атрибуты качества ПО, разработка ПО через тестирование, итерации тестирования ПО.
Gryciuk Yu.I., Grytsyuk P.Yu. Contemporary problems of scientific evaluation of the application software quality
The analysis of the modern problems of scientific evaluation of the application software quality has been conducted in this research. The analysis result allows to provideto formulate the recommendations regarding modification of existing methods and tools for building software, technologies and models of quality analysis of software. The implicit methods and tools for evaluating the quality of the application software and models of the quality management software have been considered. The methodology has been described and the need for the introducing application of technology development of application software through its testing has been proved (Test Driven Development - TDD). TDD testing technology significantly improves the quality and reliability of software. It was found that TDD technology enables: to conduct unit testing software and test software functionality; to detect errors in the implementation of software; to conduct code analysis regarding software tests coverage.
Keywords: software, quality of the application software, reliability of the application software, model and attributes of software quality, software development through testing, iteration of software testing. _
