CC BY
89
4. 1НФОРМАЦ1ЙН1 ТЕХНОЛОГИ
НАТУ
УКРЛ1НИ
t ,
Hl/IUB
Науковий в1сник НЛТУ Украши Scientific Bulletin of UNFU http://nv.nltu.edu.ua https://doi.org/10.15421/40270433
Article received 13.05.2017 р. Article accepted 24.05.2017 р. УДК 004.414.3:681.322:855.5[075.8]
ISSN 1994-7836 (print) ISSN 2519-2477 (online)
1 ЁЕЗ Correspondence author Yu. I. Grytsiuk yurii.i.hrytsiuk@lpnu.ua
Ю. I. Грицюк, I. Ф. Лешкевич
Нацюнальнийушверситет "Львiвська полтехнжа", м. Львiв, Украша
ОСОБЛИВОСТ1 ВИЗНАЧЕННЯ ВИМОГ ДО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ТА ПРОБЛЕМИ IX АНАЛ1ЗУ
Проведено системний аналiз предметно'1 обласп, результати якоТ дали змогу достов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х потреб вiд майбутнього ПЗ; спшьш сесiТ визначення вимог до ПЗ; набори вимог до ПЗ у стилi контракту; вишрюваш цш застосування майбутнього ПЗ; прототипи - макети майбутнього ПЗ; прецеденти - технологiя доку-ментування вимог до ПЗ; специфiкацiя вимог до ПЗ.
Клю^ое^ слова: предметна область; системний аналiз предметноТ обласп; види дiяльностi аналiтика; визначення вимоги до програмного забезпечення (ПЗ); аналiз вимоги до ПЗ; показники якост ПЗ; модель визначення та аналiзу вимог до ПЗ.
Вступ. Успшне функцiонування програмного забезпечення (ПЗ) багато в чому залежить ввд правильно! оргашзацп процесу виконання робгг з визначення та ана-лiзу вимог до нього (Vigers, 2004). Члени команди роз-робниюв ПЗ можуть самосгiйно визначаги вимоги або залучати фахiвця-аналiгика. У будь-якому випадку заз-начена дiяльнiсгь вимагае не гiльки знання шженерп ПЗ (Lavrishheva & Petruhin, 2006), а й певного життево-го та професшного досвiду, вмiння спiлкуватися iз представниками вiд зацiкавлених сторiн i, що найваж-ливiше, аналiтичних здiбностей виконавц1в тако! робо-ти (Leffingujell & Uidrig, 2002). yci щ компетенцп по-тенцiйнi фахiвцi-аналiтики отримують у процесi вирь шення конкретних завдань у рiзних предметних областях як шд час навчання, так i протягом виробничо!' дь яльностi (Kobern, 2011).
Для засвоення особливостей виконання робiт з визначення та аналiзу вимог до ПЗ у навчальних закладах передбачеш як лекцiйнi, так i практичш заняття (Vigers, 2004). Проте, проблема полягае в тому, що вони дають змогу студенту оволодии необхвдним набором теоре-тичних знань i деяким практичним вмiнням, але не дають практичних навик1в, тобто можливостей змоделю-вати його взаемодто iз представниками оргашзацп-за-мовника ПЗ. Пов'язано це з тим, що проведения прак-
тичних занять у реальному середовищi органзацп-за-мовника трапляеться вкрай рiдко через часту вщмову самих органiзацiй проводити такi заняття, через немож-ливiсть проведення таких заходгв постiйно i, що найважливше, складнiсть повторення певного сценарию нашть для дек1лькох студент1в, а, як вщомо, таких груп студента здебиьшого е дек1лька i т. ш.
Використання д1лових iгор (Бе1еЫкоу & Birshtejn, 1989; Vedenina, 2013), де рол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в. Хоча в роботi (Кипдигееу, Б^Ико & Maru1in, 2010) запропоновано методику навчання основам про-ектування архiтектури ПЗ з використанням рольових ^ор, проте в нiй не розглянуто допустимi варiанти ре-алiзацil етапiв цього процесу, що заставляе викладач1в (не фах1вц1в у рiзних предметних областях) часто при-думувати не зовс1м реалiстичнi сценари.
^TyBaHHA 3a flCTy: rpu^KiK W. I., HewKeBM'H I. O. Oco6.nnBoCTi BH3HaHeHH?i BHMor go nporpaMHoro 3a6e3ne4eHHA Ta npo6.neMH ix
aHa^i3y. HayKOBMM BicHMK H.Ty yKparnui. 2017. Bun. 27(4). C. 148-158. Citation APA: Grytsiuk, Yu. I., & Leshkevych, I. F. (2017). The Problems of Definition and Analysis of Software Requirements. Scientific Bulletin of UNFU, 27(4), 148-158. https://doi.org/10.15421/40270433
Варто також згадати деяк проблеми, як часто вини-кають перед аналииками-початювцями п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дпов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 проблеми, яю стосуються процедури визначення вимог до ПЗ, встановити шляхи lx уник-нення чи пом'якшення;
2) охарактеризувати до аналiтикiв пiд час аналiзу вимог до ПЗ,
3) запропонувати представникам вщ оргашзацп-замовни-ка основш показники якостi ПЗ, яким мае вщповщати майбутне ПЗ;
4) удосконалити наявнi формалiзованi моделi вiдповiдниx процедур, яю стосуються визначення та аналiзу вимог до ПЗ;
5) зробити вщповщт теоретичнi висновки та надати реко-мендащ! щодо практичного i'x використання.
1. Нагальш проблеми визначення вимог до прог-рамного забезпечення. Розроблення ПЗ (англ. Software Development) - це дп компанп-виконавця, як мiстять iнженерiю вимог до процесгв проектування, кодування та тестування ПЗ з дотриманням правил iнженерi! його якосп. Така дiяльнiсть компанi!-розробника ПЗ вимагае ввд аналiтика детального вивчення предметно! обласп (Bobalo, et al., 2013), яка стосуеться безпосередньо! дь яльностi органiзацi!-замовника, та повного розумшня цiлей використання ними майбутнього програмного продукту (Mishhenko, Pomorova & Govorushhenko, 2012). На сьогоднi вiдома велика юлькютъ технологiй
реалiзацi! проект1в з розроблення ПЗ (Lavrishheva & Petruhin, 2006; McConnell, 2013). Незалежно вщ шдхо-ду, який використовуеться в тш чи iншiй технологi! розроблення ПЗ, на початковому еташ життевого циклу (ЖЦ) будь-якого програмного проекту аналиик мае провести грунтовний аналiз проблемно! областi, забез-печити формування достатнього набору вимог до майбутнього програмного продукту та здшснити !х узгодження з замовником. Саме на цьому еташ мають бути зафжсоваш реальнi потреби потенцшних користува-ч1в ПЗ, що стосуються функцюнальних, операцiйних i сервiсних його можливостей, як мае реалiзувати ком-пан1я-розробник. Правильно сформованi аналiтиком на-бори вимог до ПЗ е гаранпею того, що програмний продукт буде задовольняти усiм побажанням зацiкавлених сторiн пiд час його використання (Gilb, 1988).
Вiдомо (McConnell, 2013), що сучасне ПЗ супрово-джують так1 основнi проблеми його розроблення та ви-користання:
• складтсть опису його iерарxiчноl структури i вщповщ-них компонент, як! стосуються кожно! iерарxil;
• наявшсть множини ткно взаемопов'язаник компонент з локальними завданнями та цшями його використання;
• вщсутшсть певниx аналопв i, як наслщок, часта немож-ливкть використання будь-якиx типовиx проектниx рь шень;
• потреба iнтеграцii' наявного i розробленого ПЗ у едину корпоративну мережу, узгодження ^mx iнтерфейсiв;
• потреба функцюнування ПЗ у неоднородному середови-щ! на рiзниx апаратник платформаx як ближнix, так i в^дален^ користувачiв;
• вiдокремленiсть та р1знорщтсть окремиx груп розроб-ниюв ПЗ !з р!зним рiвнем квалiфiкацil його пращвниюв;
• велик термши реалiзацil програмного проекту через часта змши защкавленими сторонами вимог до ПЗ. Програмний проект (англ. Software Project) - це
комплекс взаемопов'язаних заходiв, спрямованих на до-сягнення поставлених завдань з чiтко визначеними щ-лями протягом заданого перюду часу та при встановле-ному бюджет (Gilb, 1988). Такi проекти часто зазнають невдач через помилки на раннiх етапах життевого циклу ПЗ, а саме (Pomorova & Hovorushchenko, 2013):
1) неадекватне формулювання вимог користувача до ПЗ чи неузгоджешсть lx з оргашзащею-замовником;
2) невдале проектування арxiтектури ПЗ або неефективне планування етапiв реалiзацil програмного проекту;
3) неправильне розумшня побажань замовника щодо мож-ливостей майбутнього програмного продукту або не-достатнш аналiз специфжаци вимог до ПЗ його розроб-никами, а також недостатня деталiзацiя етапiв реалiза-цп програмного проекту;
4) нереалiстичнi проектнi плани щодо вартостi та трива-лост реалiзацil програмного проекту, щодо ефектив-ност етапiв реалiзацil програмного проекту, щодо три-валостi життевого циклу ПЗ, щодо простоти та зруч-ност використання майбутнього програмного продукту та його кросплатформенностц
5) неправильно падбрат члени команди-розробника ПЗ, недостатня квалiфiкацiя керiвника програмного проекту. Вимоги до ПЗ (англ. Software Requirement) - набiр
характеристик щодо властивостей, якостi та функцш майбутнього програмного продукту, який потрiбно розробити або знаходиться у процес модернiзацi! (Vigers, 2004). Часто вимоги до ПЗ аналиики визначають пiд
час анашзу техшчного завдання на його розроблення та фжсують у ввдповщнш специфiкацiï вимог, дiаграмах прецедент1в й шших артефактах процедури аналiзу предметноï областi (Bobalo, et al., 2013).
За ieрархiчними р1внями розрiзняють таю види вимог до ПЗ (Lavrishheva & Petruhin, 2006):
• бiзнес-вимоги - встановлюють призначення ПЗ, ïx детально описують у документа про бачення (англ. Vision) та документа про межi проекту (англ. Scope);
• вимоги користувача - встановлюють rn6ip завдань ко-ристувача, яю мае реалiзувати готовий програмний продукт, а також сценарп 1хнього вирiшення в програмно-апаратнiй системi. Цi вимоги можуть мати вигляд твер-джень, варiантiв використання (англ. Use Case), кторш користувача (англ. User Stories), сценарпв взаемодй' (англ. Scenario) тощо;
• функцюнальт вимоги - встановлюють "що" мае робити готовий програмний продукт у програмно-апаратнш систем^ ïx детально описують у специфтаци вимог до ПЗ (англ. Software Requirements Specification, SRS).
Специфжа^я вимог до ПЗ (англ. Software Requirements Specification, SRS) - повний опис поведшки ПЗ, що потрiбно розробити, це основа, яка мктить множи-ну функцюнальних i нефункцюнальних (додаткових) вимог до майбутнього програмного продукту. Функщ-ональш вимоги описують в« взаемодй користувача з ПЗ, а нефункщональш вимоги - накладають обмеження на реалiзацiю програмного проекту чи можливосп фун-кцiонування ПЗ (IEEE 830-1998, 1998).
Помилки, внесенi пiд час формування набору вимог до ПЗ чи проектування його архиектури, становлять 25-55% вщ усiх помилок, причому чим бiльший обсяг ПЗ, тим бiльше помилок вноситься саме на раншх ста-дiях його ЖЦ (Pomorova & Hovorushchenko, 2013). Вва-жаеться (Bоegh, et al., 1999), що вартють виправлення помилки проектування архиектури ПЗ у 2-4 рази вища вiд вартостi виправлення помилки шд час його констру-ювання. Залежнiсть вартостi виправлення помилок ввд етапу ЖЦ ПЗ наведено у робот (IEEE 1031-2011, 2008).
Процес визначення вимог до ПЗ подияють на де-к1лька етапiв (Lavrishheva & Petruhin, 2006):
• виявлення вимог - збирання аналггиком побажань замов-ника, його бачень роботи та меж застосування майбутнього програмного продукту, встановлення потреб защкавлених сторiн i загальних можливостей прог-рамно-апаратно'1 системи;
• анал1з вимог до ПЗ - перевiрка цшсноста та завершенос-тi сформованого набору вимог до програмного продукту, узгодження ïx з представниками вщ защкавлених сторш, внесення та вiдстеження змiн;
• специфтащя вимог до ПЗ - документування вимог до програмного продукту зпдно з наявними стандартами та нормативними документами;
• тестування вимог до ПЗ - встановлення вщхилень роз-робленого ПЗ вщ зазначеного набору вимог до програмного продукту (Yakovyna, et al., 2010).
Для виявлення вимог, яким мае вщповвдати майбут-нш програмний продукт, використовують таю методи (Kungurcev, Kalinina & Novikova, 2013):
• сшлкування з майбутшми користувачами: iнтерв'ю, опи-тування, анкетування (Lukina, 2003);
• мозковий штурм, семшар, вiдео-конференцiя (Leffingu-jell, & Uidrig, 2002);
• спостереження за виробничою дiяльнiстю користувачiв майбутнього програмного продукту, "фотографування" Ухнього робочого дня;
• аналiз нормативно':' документацл та чинного законодав-ства (IEEE 1031-2011, 2008; IEEE 1061-26157, 1998; IEEE 830-1998, 1998);
• аналiз бiзнес-процесiв: моделей дiяльностi, конкурен-тних програмних продуктiв, статистики використання попередтх версiй ПЗ (iSO/IEC, ISO/IEC 25000, 2005; McCall, Richards, & Walters, 1977).
Вiдомi такi джерела, яю допомагають аналiтику здiйснювати аналiз вимог до ПЗ (Lavrishheva & Petruhin, 2006): законодавство - чинш укази та постанови; вимоги стандартов; бiзнес-процеси; очшування користу-вач1в вщ роботи ПЗ та ïхне бачення щодо функцюнальних можливостей майбутнього програмного продукту.
Рiзнi методологи розроблення ПЗ можуть по^зно-му оргашзовувати роботу аналтака щодо процедур визначення та аналiзу вимог до ПЗ (Lavrishheva & Petruhin, 2006). У дуже старш та не зовсш актуальнш на сьогоднi моделi водоспаду (англ. Waterfall) процедури визначення та аналiзу вимог до ПЗ е початковими (Lef-fingujell & Uidrig, 2002). Особливють njeï моделi поля-гае в тому, що ni процедури мають повшстю заверши-тися ще до початку етапу проектування архиектури ПЗ та етапу його розроблення, тому щ етапи не можуть по-чатися рашше завершення процедури аналiзу вимог.
В ггеративних методологiях розроблення ПЗ процедури визначення та аналiзу вимог до нього в рiзному обсязi е на кожнiй iтерацiï (Gilb, 1988).
2. Проблеми аналiзу вимог до програмного забез-печення. Як було зазначено вище, процедура визначення вимог до ПЗ полягае у з'ясуванш потреб виконання та встановлення умов функцюнування майбутнього програмного продукту, яю висуваються рiзними представниками ввд органiзацiï-замовника. Водночас, процедура аналiзу вимог до ПЗ зводиться до врахування мож-ливих суперечностей мiж рiзними вимогами та вирь шення рiзних конфлiктних ситуацп мiж замовниками та розробниками ПЗ, а також потенцшними його користувачами чи, наприклад, його бенефщарами1.
Вимоги користувач1в до ПЗ подають у виглядi твер-джень про 1'хш потреби, вираженi користувачем чи гру-пою осiб, защкавлених у яюсному створеннi майбутнього програмного продукту та в успшному його використанш. Вони стосуються багатьох особли-востей функцюнування ПЗ, зокрема i поведшкових. За-галом, поведiнковi вимоги користувачiв до ПЗ можна подiлити на два типи:
• функцiональнi вимоги - яю встановлюють, що саме мае бути реатзовано в ПЗ;
• вимоги до програмно'1' продуктивной - якi встановлюють, наскшьки добре це мае бути виконано. Функцюнальт вимоги (англ. Functional Requirements) - вимоги до ПЗ, яю описують внутршню роботу програмного продукту, його поведшку: калькулювання даних, манiпулювання даними, оброблення даних й ш-шi специфiчнi функци, яю вiн мае виконувати (Gilb, 1988). На вщмшу вiд нефункцiональних вимог, яю вста-
1 Бенефiцiар (вщ фр. benefice - прибуток, користь) - одержувач визна-чених вигод, що виникають внаслiдок реалiзацiï програмного проекту._
новлюють, яким програмний продукт мае бути, функщ-ональнi вимоги встановлюють, що продукт мае робити. Функцюнальш вимоги до ПЗ анаштик мае з'ясувати на першш стадп процесу розроблення ПЗ, тобто на етапi аналiзу вимог.
Нефунщюнальнi вимоги (англ. Non-Functional Requirements) - вимоги до ПЗ, як задають критери оцшю-вання якостi його роботи (McCall, Richards & Walters, 1977). На вщмшу вiд функцiональних вимог, як встановлюють, що програмний продукт мае робити, нефун-кцiональнi вимоги встановлюють, яким продукт мае бути. Нефункщональш вимоги аналиик мае з'ясувати також на еташ аналiзу вимог до ПЗ.
За призначенням нефункцiональнi вимоги до ПЗ спрямоваш на покращення безпеки ПЗ, його надшносп, швидкодп, зручностi у використанш тощо, а також на вдосконалення (масштабування, вiдновлюванiсть ...) властивостей ПЗ.
Практики розрiзняють такi види нефункщональних вимог до ПЗ:
1) Вимоги до штерфейсу (Interface Requirements) подшя-ють на:
■ апаратш iнтерфейси (Hardware Interfaces) - необхвдш для пiдтримки роботи програмно-апаратно1' системи, зокрема ïï лопчно'1 структури, фiзичних адрес i очiкуваноï поведш-ки;
■ iнтерфейси ПЗ (Software Interfaces) - штерфейси, з якими наявна аплшацм мае взаемодiяти з користувачем шд час ïï використання;
■ комушкацшш iнтерфейси (Communications Interfaces) - ш-терфейси для комунiкацiй (взаемоди) ПЗ з шшими прог-рамно-апаратними системами та/або пристроями.
2) Апаратш та програмш вимоги (Hardware/Software Requirements) - опис апаратно'1 та програмно'1 платформ, необхщних для надшно'1 роботи (i пiдтpимки) програмно-апаратно'1 системи.
3) Операцшш вимоги (Operational Requirements) вщповь дають за:
■ безпеку та конфiденцiйнiсть (Security and Privacy) даних у ПЗ;
■ надшнють (Reliability) роботи ПЗ у штатних i позаштатних ситуацiях;
■ вщновлюванють (Recoverability) ПЗ пiсля аварiйного завершения роботи;
■ програмну продуктивнють (Performance) ПЗ у рiзних наборах вхвдних даних;
■ потенщал (мiсткiсть) (Capacity) ПЗ стосовно обсягу об-роблюваних даних;
■ збереження даних (Data Retention) в оперативнш пам'ятi ПЗ;
■ управлiння помилками (Error Handling) в ПЗ, яш виника-ють внаслiдок його роботи, але не були виявленi шд час тестування (Futrell, Shafer, & Shafer, 2003);
■ правила перевiрки (Validation Rules) функцiональних мож-ливостей ПЗ;
■ узгоджеш стандарти (Convention Standards), зпдно з якими було розроблено ПЗ.
Отже, ус функцюнальш та нефункщональш вимоги до ПЗ шдлягають детальному аналiзу, узгодженню з представниками вiд замовникiв i розробниками програмного продукту. Здшснення такого аналiзу вимог до ПЗ е критичним етапом реалiзацiï програмного проекту, ввд як1сного виконання якого залежить усшшне його завершения (Kobern, 2011). Шд час такого аналiзу всi вимоги мають бути задокументованими, вимiряними, про-тестованими (Yakovyna, et al., 2010), пов'язаними з бiз-нес-потребами майбутнiх користувачгв ПЗ, а також описанi з ргвнем деталiзацiï, достатн1м для проектуван-
ня архiтектури ПЗ. Аналiз вимог до ПЗ анаштик мае здшснювати за архтектурними, структурными, пове-дтковими, функщональними та експлуатацтними характеристиками розроблюваного нового чи модифшо-ваного наявного програмного продукту.
Архтектура ПЗ (англ. Software Architecture) -структура програми або обчислювально!' системи, яка мютить програмш компоненти, видимi ззовнi власти-восп цих компонент, а також ввдносини мiж ними. Яюсний аналiз вимог до архиектури ПЗ з подальшим його документуванням значно спрощуе вщносини мiж зацiкавленими сторонами (англ. Stakeholders) та роз-робником ПЗ, дае змогу зафжсувати рiшення, прийнятi на раншх етапах реалiзацiï програмного проекту, узго-дити його як1сний дизайн, а також уможливлюе вико-ристання компонент цього дизайну i шаблошв проекту-вання повторно в шших програмних проектах (McCon-nell, 2013).
Проектування архтектури ПЗ - процес розроблення його iерархiчноï структури, що виконуеться пiсля процедур визначення й аналiзу вимог до ПЗ. Завдання такого проектування - перетворення сформованого набору вимоги до ПЗ у архиектуру ПЗ (Leffingujell & Uid-rig, 2002). Таку побудову аналиик мае здiйснювати шляхом визначення цшей дiяльностi реально].' системи, ïï вхвдних i вихiдних даних, декомпозици системи на пiдсистеми, на компоненти або модуш та об'еднання ïx у загальну структуру. Проектування архтектури ПЗ мо-же виконуватися рiзними методами (стандартизованим, об'ектно-орiентованим, компонентним й iн.), кожний з яких передбачае свiй перелiк виконання робщ а саме -визначення концептуально^ об'ектноï й iншиx моделей за допомогою вщповвдних конструктивних елементiв (блок-схем, граф1в, структурних дiаграм тощо).
Аналiз вимог до структури окремих програмних компонент i оргашзацп файловоï системи для мiжпрог-рамного обмiну даними стосуеться, в основному, шдго-товки програмноï документацiï до ПЗ. Розрiзняють зов-ншню програмну документацю, яка узгоджуеться iз замовником, i промiжну - внутршню документацт до програмного проекту.
Шд час шдготовки програмноï документацiï аналiтик мае спочатку розробити зовншш специфiкацiï вимог, а попм - внутрiшнi. Зовншм специфжаци вимог мктять перелiк вxiдниx i вихщних даних, ïx структурну оргаш-защю (статичну чи динамiчну), реакцiï ПЗ на винятковi ситуацiï, визначенiсть у тому, що саме мае робити ко-ристувач (за якими алгоритмами вш мае дiяти i звщки мае брати iнформацiю), а що мае виконувати програм-но-апаратна система. Тобто зовншш специфжаци вимог мають мктити все те, що побачив би користувач, коли б вш отримав готовий програмний продукт. Ефектившсть аналiзу зовнiшньоï специфiкацiï вимог до ПЗ залежать вiд тривалостi та стадш його життевого циклу.
Шд час розроблення iерарxiчноï структури ПЗ, перед початком реалiзацiï' програмного проекту, до процесу тестування зовншшх специфжацш вимог варто за-лучати потенцiйниx користувач1в майбутнього програмного продукту. Користувачам також варто показува-ти макети екрашв у порядку виконання програмою усix своïx функцiй, пiсля чого вони зможуть готувати даш для ïx тестування, а також згодом зможуть без зайвих зусиль апробувати та вщлагодити методику роботи з ус1м ПЗ загалом._
Внутршт специфтацп вимог мктять опис внутрш-шх даних програми (змiнних, особливо структурова-них) i опис алгоритмiв роботи усiеï програми та окре-мих ïï модул1в чи частин. Таю специфшацп подають у поеднанш з описом архiтектури ПЗ i внутршньо1 структури окремих його компонент.
3. Ди аналiтика пщ час аналiзу вимог до програмного забезпечення. Шд час ан^зу вимог до ПЗ аналь тик мае виконувати такi види дiяльностi (Futrell, Shafer & Shafer, 2003):
• виявлення/збирання потреб - завдання комуткаци ана-лiтика з представниками вщ замовника, зокрема з корис-тувачами майбутнього програмного продукту, для з'ясу-вання ïxнix потреб та узгодження сформованого набору вимог до нього;
• запис вимог - документування вимог до ПЗ у рiзниx формах, таких як опис звичайною мовою, у вигляда прецедента, користувацьких кторш дiяльностi чи тради-цшних специфiкацiй вимог;
• аналiз вимог до ПЗ - виявлення недолшв вимог до ПЗ (неточностей, неповноти, неоднозначностей чи супереч-ностей, конфл1ктних ситуацш) i ïx виправлення, а також перевiрка можливоста, тривалостi та вартостi реатзацп. Вiдомо (Blagodatskih, Volnin & Poskakalov, 2005),
що процедура аналiзу вимог до ПЗ може бути тривалою та ресурсовитратною, що вимагае вщ аналiтикiв знання деталей предметно1 обласп та застосування тонких пси-холопчних навикiв. Оскiльки нове ПЗ змiнюе середови-ще його використання та вщношення мiж користувача-ми, аналиикам важливо розпiзнати характернi особли-восп всiх зацiкавлених сторiн, взяти до уваги в« ïхнi потреби i переконатись в тому, що вони розумтоть нас-лiдки, як1 привносить нова програмна система в бiзнес-процеси.
Зазвичай, аналiтики можуть використати деюлька методiв, щоб отримати вимоги до ПЗ вщ кiнцевих ïï ко-ристувачiв (Vigers, 2004; Kobern, 2011; McConnell, 2013). Однак, кторично склалося так, що ця процедура мктить проведения iнтерв'ю чи оргатзащю фокус-груп (яку в цьому контекст частiше називають як майстерня вимог), де потреби представниюв вiд защкавлених сто-рiн ретельно записують, шсля чого цi записи обробля-ють вщповщно до наявних методик i створюють так зван набори вимог користувачiв.
До сучаснiших пiдходiв виявлення/збирання вимог до ПЗ належать прототипування та шдготовка преце-дентiв (Leffingujell & Uidrig, 2002). За потреби, аналии-ки можуть використовувати комбшащю цих методiв, щоб встановити точш потреби зацiкавлених сторiн, тоб-то розробити 1х так, щоб ПЗ тд час його використання повшстю вщповщало зазначеним бiзнес-потребам.
У робот (Lavrishheva & Petruhin, 2006) виокремлено такi основнi етапи процедури аналiзу вимог до ПЗ:
1) Визначення защкавлених апорт у розроблент ПЗ. З'ясування перелшу защкавлених сторiн, встановлення гхшх потреб та штенсивносп (частоти) викорис-тання майбутнього програмного продукту часто засто-совуеться для опису можливостей його застосування в iнших бiзнес-процесах. При цьому защкавлеш сторони - особи чи оргашзацп, якi дiйсно претендують на прид-бання програмного продукту, який може безпосередньо чи опосередковано впливати на 1хню бiзнес-дiяльнiсть. Багато практиюв вважають, що зацiкавленi сторони не
завжди обмежуються одшею компанiею-розробником ПЗ, яка присилае 1м сво!х аналггаюв для встановлення сценарив використання чи запису користувацьких кто-рiй дiяльностi.
До зацiкавлених сторiн можуть належати такi пред-ставники (Lavrishheva & Petruhin, 2006):
• ri, хто управлятиме ПЗ - звичайн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тики конструюють ПЗ.
2) 1нтерв'ю Ii зацжавленими сторонами щодо ïx-нЫ потреб eid майбутнього ПЗ. Проведення штерв'ю iз представниками вщ зацiкавлених сторiн е тради-цшним пiдходом, що використовуеться пiд час аналiзу вимог до ПЗ. Таке уточнення вимог слугуе одним iз шляхiв отримання цiлiсного та достовiрного знання, яке часто неможливо виявити в сп1льних сесiях iз замовни-ками i розробниками ПЗ, де ïхня увага п1дпорядкована забезпеченню биьш крос-функцiонального контексту. Понад це, особистий характер проведення штерв'ю iз конкретними респондентами надае аналиику б1льш до-вiрливе середовище для сп1лкування, де прогалини в його знаннях можна дещо детальшше пояснити.
3) Сптьш сесп визначення вимог до ПЗ. Вимоги до ПЗ часто мають крос-функщональш наслщки, якi не завжди вiдомi окремим представникам вiд защкавлених сторш, тому ïх часто пропускають чи неправильно описують пщ час проведення iнтерв'ю iз респондентами. Таю негативш наслiдки можна виявити шляхом проведення сесш мiж зацiкавленими сторонами у контрольо-ваному середовищ^ роботу якого стимулюе квалiфiко-ваний посередник - модератор1. При цьому защкавлеш сторони беруть участь у дискусп, внаслщок проведення якоï вдаеться виявити деякi крос-функцiональнi вимоги до ПЗ, проаналiзувати 1х деталi та, що найважливiше, розкрити 1х крос-функцiональнi наслiдки. При цьому мають бути присутш спецiально призначенi секретар i бiзнес-аналiтик, в обов'язки яких входить документування самоï дискусп та аналiз ïï конкретних моменпв вiдповiдно. Використання ж навикiв навченого посе-редника (модератора) для управлшня дискусiею зв1ль-няе бiзнес-аналiтика вщ зайвоï роботи, даючи йому змогу зосередити своï думки на проце« виявлення крос-функцiональних вимог до ПЗ (Futrell, Shafer & Shafer, 2003).
Сеси мiж представниками вщ зацiкавлених сторiн подiбнi до сесш сшльного проектування архiтектури ПЗ, яю спершу виявляють вимоги до архиектури ПЗ, а
1 Модератор (з лат. той, що стримуе) - людина, що проводить соцiологiчнi дослвдження; ведучий фокус-груп._
потш формашзують його властивостi, якi мають бути реашзоваш в майбутньому ПЗ для того, щоб задоволь-нити потреби його користувачiв.
4) Набори вимог до ПЗ у cmuui контракту. Тради-цшним способом документування вимог до ПЗ е фор-мування ïx перелiку в стил контракту. В складному ПЗ такий набiр вимог може розтягуватись на сотш сторь нок. Вiдповiдним аналогом може слугувати надзви-чайно великий асортимент продукцп в супермаркетi. Однак, набори вимог до ПЗ у сташ контракту не дуже щнуються аналииками пiд час ïx аналiзу, оскiльки вони показують малу ефектившсть у досягненш своïx бiзнес-цшей. Проте, такi вимоги трапляються ще й сьогоднi, особливо тодi, коли замовник ПЗ мае пркий досвщ прийняття в експлуатацiю програмного продукту, що не зовам ввдповвдав ïxнiм вимогам.
Документування вимог до ПЗ у сташ контракту мають таю переваги:
• контракт надае чггкий попунктовий нaбip вимог до ПЗ, конкретне формулювання та однозначне трактування;
• надае контракт мiж замовниками (спонсорами) програм-ного проекту та його розробниками;
• для складного ПЗ може надати детальный опис вимог до нього.
Недолши контракту вимог до ПЗ:
• таю набори вимог до ПЗ розтягуються на сотш сторшок, внаслщок чого ц вимоги майже неможливо повтстю осмислити й отримати повне розумшня роботи ПЗ;
• тaкi набори абстрагують всi вимоги до ПЗ, тому в них е мало контексту:
■ абстракщя вимог робить неможливим бачення того, як саме вони поеднуються м1ж собою чи взаемодгють разом;
■ абстракцiя вимог заважае правильно розставляти прюри-тети мiж ними;
■ абстракцiя вимог збшьшуе !х подiбнiсть та ймовiрнiсть неправильно! к iнтерпретацiï: чим бiльше фахiвцiв !х ос-мислять, тим бшьша кiлькiсть рiзних iнтерпретацiй з'явиться;
■ абстракщя вимог заважае розробникам ПЗ впевнитись в тому, що вони мають у наявност бiльшiсть вимог, яю пот-рiбно врахувати в готовому програмному продуктi;
• тaкi набори вимог створюють фальшиве вiдчуття взаемно-го поpозумiння мiж замовниками та розробниками ПЗ;
• набори вимог у стат контракту дають защкавленим сторонам фальшиве вiдчуття безпеки в тому, що розробни-ки ПЗ змушенi будуть досягти тих висот, як вони замо-вили. Однак, через свою природу таю набори вимог часто упускають критичн вимоги, як проявляються шзт-ше в пpоцесi розроблення ПЗ. Також розробники ПЗ часто використовують так вiдкpитi вимоги для того, щоб переглянути умови договору на свою користь;
• таю набори вимог не зовим допомагають розробникам ПЗ у ефективному його пpоектувaннi.
Як альтернатива до великих, попередньо описаних наборов вимог до ПЗ, е гнучке розроблення ПЗ, яке ви-користовуе кторн користувач1в для опису вимог про ïx-ню дiяльнiсть у повсякденних термiнаx.
5) Вимiрюванi цiлi застосування майбутнього ПЗ. Найкращi практики (проектанти та розробники ПЗ) бе-руть сформований набiр вимог як тдказку до процеду-ри проектування архтектури та власне розроблення ПЗ. При цьому вони можуть стосовно предметноï обласп запитувати замовника "чому це ввдбуваеться так, а не шакше?" доти, доки не стане зрозумшою справжня бiз-нес-цiль програмного продукту. Замовники ПЗ i його
розробники можуть скласти спещальш тести, яю дають 1м змогу вишряти рiвень досягнення поставлених щ-лей. Зазвичай такi цiлi змiнюються повшьшше, нiж дов-гий перелiк конкретних, але невимiрних вимог. Як тшь-ки невеликий набiр критичних, але вимiрних цшей буде встановлено, то швидке прототипування та короткi гге-ративнi етапи розроблення ПЗ часто можуть приносити значно б1льшу користь для замовника ПЗ, школи навиъ задовго до середини реалiзацil програмного проекту.
6) Прототипи - макети майбутнього ПЗ. Усере-диш 1980-их технологiю прототипування ПЗ розгляда-лось як найкраще рiшення до виршення проблеми ана-лiзу вимог до ПЗ. Прототипи ПЗ, тобто його макети, дають змогу розробникам ПЗ вiзуалiзувати ще не створе-ний програмний продукт. Водночас, прототипи допомагають майбутшм користувачам ПЗ уявити, як саме буде виглядати готовий програмний продукт, а також дае змогу розробникам ПЗ значно спростити процедуру прийняття архиектурних ршень. Свого часу шсля вве-дення прототишв спостерiгалося значне покращення комушкацн мiж замовниками ПЗ i його розробниками. Ранне бачення користувач1в майбутшх можливостей ПЗ дае змогу його замовникам значно зменшити кiлькiсть змш у подальшому його використаннi, що призводить до зменшення загально! вартосп розроблення ПЗ.
Однак, протягом останнього десятилгття прототипування, яке себе зарекомендувало як корисна методика аналiзу вимог до ПЗ, не повшстю вирiшило проблему визначення та аналiзу вимог до ПЗ, а саме:
• як тшьки замовники бачать прототип ПЗ, то вони перес-тають розумiти, чому розробники ПЗ не зможуть завершит програмний проект упродовж деякого часу;
• розробники ПЗ часто думають, що змушет будуть вико-ристовувати склеений докупи код прототипу в реальнш ПЗ, боячись "втратити час" почати заново;
• загалом, прототипи допомагають розробникам ПЗ у прийнятл архггектурних рiшень щодо проектування iнтер-фейсу користувача. Однак, прототипи не завжди можуть вказати 1м, якi вимоги були спочатку в замовника ПЗ;
• розробники ПЗ i кiнцевi його користувачi можуть занад-то довго зосередитись на побудовi вщповщних iнтер-фейсiв, i занадто мало - на розроблент власне ПЗ, яка мае виконувати певнi бiзнес-процеси;
• прототипи придатнi для розроблення штерфейив користувача, як1 вщображають реальнi под!1 на екранi, але не дуже корисш для реалiзацií пакетних чи асинхронних процесiв, яю можуть мiстити складнi розрахунки чи щ-леспрямованi запити для пошуку даних. Прототипи деяких елемент1в ПЗ можна подати у
виглядi плоских дiаграм (як1 часто називають каркасни-ми моделями) чи робочих програмних додатюв, що використовують синтезовану функцiональнiсть. Каркаснi моделi створюють за допомогою рiзноманiтних графiч-них дизайн-докуменпв, тому розробники ПЗ часто ви-даляють увесь колiр з дизайну (використовують чорно-бiлу палiтру) для того, щоб юнцеве ПЗ мало дещо безликий графiчний дизайн. Це допомагае розробникам ПЗ безпосередньо уникнути плутанини мiж концептом програми в дизайн-документi та 11 кшцевим виглядом.
7) Прецеденти - технологш документування вимог до ПЗ. Прецеденти дають змогу задокументувати потенцшш вимоги як до нового, так i для модифжова-ного ПЗ. Кожен прецедент надае один чи бшьше сцена-рй'в, яю виражають те, як ПЗ мае взаемодiяти з користу-вачем чи шшим ПЗ, щоб досягти конкретно! бiзнес-цiлi.
Прецеденти, зазвичай, уникають технiчного жаргону, вщдаючи перевагу мовi кiнцевого користувача чи дос-вiдченого експерта в предметнш областi. Iнженерiя вимог, як методолопя розроблення ПЗ, та защкавлеш сторони в усшшнш його реалiзацiï часто виступають сш-вавторами прецедентов.
Для початювщв часто прецеденти видаються оман-ливо простими шструментами для опису поведiнки ПЗ. Хоча прецедент i мктить текстовий опис вах способ1в, якими користувачi можуть працювати з ПЗ, однак вони не описують жодних внутршшх процеав у ньому, а також не пояснюють, як саме ПЗ мае бути реалiзоване. Вони просто показують кроки, яю користувач мае здшснити, щоб виконати свое завдання. За аналогiею можна описати й у« способи взаемодiï користувачiв з майбутнш ПЗ.
8) Специфтащя вимог до ПЗ (англ. Software Requirements Specification, SRS) - повний опис поведшки ПЗ, яке потрОбно розробити, мктить набОр прецеденпв, яю описують вс взаемодiï користувача з ПЗ. Прецеденти також ввдомО як функщональш вимоги до ПЗ. ОкрОм прецедент1в, SRS також мктить нефункщональш (до-датковО) вимоги, яю накладають обмеження на програмний проект чи його реалОзащю (таю як вимоги пев-ноï продуктивной ПЗ, дотримання стандарт1в якосп чи обмеження на проектування).
Рекомендовано шдходи для шдготовки специфiкацiï вимог до ПЗ описано в стандарт IEEE 830-19981, в якому зазначено в« можливО структури, бажану структуру та вмкт ïï елеменпв, а також яюсть програмного продукту загалом.
Валiдацiя вимог - це перевОрка вимог до ПЗ для пе-реконання в тому, що вони визначають саме дану ви-робничу систему. Замовник проводить експертизу за-фжсованого набору вимог для того, щоб розробник майбутнього ПЗ змк далО виконувати проектування його архиектури. Один з методОв валiдацiï - прототипу-вання, тобто швидке ввдпрацювання окремих вимог на конкретному шструменп, аналОз масштабу його вико-нання та потенцшш змши вимог, вишрювання функщ-ональносп та вартосп майбутнього програмного продукту, а також визначення зриосп процесов визначення вимог.
Верифтащя вимог - це процес перевОрки правильной специфiкацiï' вимог до ПЗ на ïхню ввдповщнкть стандартам i функщям програмноï' системи. Внаслвдок перевОрки вимог створюеться остаточний i погоджений документ, що встановлюе повноту i коректнкть вимог до ПЗ, а також можливкть продовжити проектування його архотектури.
4. Показники якостi програмного забезпечення. Як1сть ПЗ - сукупнкть властивостей програмного продукту, що встановлюють його спроможнкть задоволь-нити запити замовника, яю вш висловив у виглядО ко-ристувацьких вимог на початкових етапах розроблення ПЗ (McConnell, 2013). Згщно з мОжнародними та вотчиз-няними стандартами ощнювання р1вня якосп програмного продукту, вид1ляють два процеси забезпечення якосп ПЗ впродовж його життевого циклу: 1) гарантiя якостi ПЗ, що е результатом певних дш на
кожнш стадп життевого циклу програмному продукту
1 IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications - Description_
з перевiрки й пiдтвердження вiдповiдностi його стандартам i процедурам, оркнтованим на досягнення певних характеристик якостц 2) iнженерiя якостi ПЗ як процес надання програмному продукту, який потрiбно розробити або знаходиться у процеи розроблення, надiйностi, супроводу й шших характеристик якостi.
ЦО процеси забезпечення якосп ПЗ потребують (Futrell, Shafer & Shafer, 2003):
• ощнювання стандарта i процедур, що використовують-ся пiд час розроблення ПЗ;
• ревiзiï процеив управлiння, розроблення та забезпечення якост ПЗ, а також уск'1 проектно'1 документаци (звь тiв, графшв розроблення, повiдомлень);
• контролю за процесом проведення формальних шспек-цш та оглядев певних дiй на кожному етат реалiзацiï програмного проекту;
• аналiзу й контролю за процесом проведення тестування (випробування) ПЗ.
Функщональтсть ПЗ - сукупнкть властивостей, яю встановлюють спроможнкть програмного продукту виконувати в заданому середовищО упорядковану посль довнкть дш для задоволення споживчих властивостей, замовлених користувачем, ввдповщно до вимог оброб-лення даних i загальносистемних засобОв. Функцюналь-носп ПЗ характеризуеться такими атрибутами:
• функцюнальна повнота - атрибут, який показуе стушнь достатност основних функцiй програми для виршення спещальних завдань згiдно з ïï призначенням;
• правильтсть - атрибут, який показуе, як забезпечуеться досягнення правильних i погоджених результата оброб-лення даних внаслiдок виконання програми;
• ттероперабельтсть або сумютсть - атрибут, який вказуе на спроможнкть програми взаемодяти з шшими програмними системами й середовищами;
• захищетсть - атрибут, який вказуе на можливкть запо-бкати несанкцiонованому доступу до певних послщов-ностей дш, яю виконуються програмою, а також до даних, яю обробляються нею;
• узгоджетсть - атрибут, який вказуе на вщповщшсть програми чинним стандартам, угодам, правилам, законам i розпорядженням.
Надттсть ПЗ - це: 1) множина атрибупв, яю вка-зують на спроможнкть програмного продукту коректно перетворювати вхвдш дан на очжуваш результати; 2) сукупнкть властивостей, яка характеризуе здатнкть програмного продукту безввдмовно виконувати певн1 функцiï' та зберОгати заданий рОвень придатносп до роботи при заданих умовах функцюнування протягом певного штервалу часу з достатньо великою ймовОрнк-тю. Надшнкть ПЗ прийнято характеризувати рОвнем його завершеносп (ввдсутнктю помилок), стшюстю до появи помилок i можливктю перезапуску шсля ава-рiйноï зупинки. Зниження надшносп ПЗ вщбуваеться внаслвдок не виявлення помилок у вимогах до ПЗ, у неправильному виконанш процес1в його проектування та реалОзацп програмного проекту.
Надшносп ПЗ характеризуеться такими атрибутами:
• безвiдмовнiсть - атрибут, який встановлюе частоту вщ-мов програми внаслщок наявност помилок у нш;
• сттюсть до помилок - атрибут, який вказуе на забезпечення спроможност програми виконувати сво'1 фуикци в аномальних умовах (збо'1 апаратури, помилки в даних i штерфейсах, порушення в дшх оператора тощо);
• вiдновлюванiсть - атрибут, який вказуе на спроможшсть програми до 11 перезапуску для повторного виконання й вiдновлення даних тсля вiдмов у доступi до них;
• узгоджетсть - атрибут, який показуе вщповщтсть програми чинним стандартам, угодам, правилам, законам i розпорядженням.
Надiйнiсть ПЗ характеризуеться такими показника-ми (Blagodatskih, Уо1п1п & Poskakalov, 2005):
1) тривалють напрацювання на вiдмову - вимiрюеться тривалiстю роботоздатного стану ПЗ мiж двома посль довними вiдмовами або початком нормального функщ-онування ПЗ пiсля них;
2) тривалють вiдновлення - враховуе можливкть багато-разових вiдмов i вiдновлень пiсля аваршно! зупинки програми;
3) готовтсть до роботи - вщображае ймовiрнiсть мати вiдновлювану систему в роботоздатному сташ в до-вшьний момент часу. Значения показника вщповщае частцi тривалостi корисно! роботи ПЗ на достатньо великому штервал^ який мктить вiдмови i вщновлення;
4) напрацювання на ситуацт вгдмови або стттсть -значения тривалост мiж втратами роботоздатностi ПЗ незалежно вiд того, наскшьки швидко вщбулось його вiдновления.
Для визначення юльюсних значень показник1в на-дiйностi ПЗ використовують аналiтичнi та емпiричнi мо-делi надiйностi ПЗ - математичш моделi, побудованi для оцiнювання залежносп надiйностi ПЗ вiд деяких певних параметр1в (B1agodatskih, Уo1nin & Poskaka1ov, 2005). Наприклад, деяк1 типи програмних систем (реального часу, радарш, безпеки, комушкацн, медичного устаткуван-ня тощо) м1стять особливi вимоги до забезпечення висо-ко! надiйностi з такими атрибутами, як недопустимкть помилок, забезпечення безпеки, захищетсть i зручтсть застосування, а також достовiрнiсть результатiв роботи системи як основний критерш надiйностi.
■Зручтсть застосування ПЗ - множина атрибута, що характеризують умови взаемодп користувача iз програмним продуктом, характеризуеться такими ос-новними атрибутами:
• зрозумшсть - атрибут, який вказуе, наскшьки зрозумiлi користувачу для розпiзнавания логiчнi концепци ПЗ та умови 1х застосування;
• легюсть навчання - атрибут, який вказуе, наскшьки доступы (легю) для вивчення умови використання ПЗ;
• оперативтсть - атрибут, який характеризуе швидюстю реакци ПЗ на дп користувача;
• узгоджетсть - атрибут, який показуе вщповщтстю процесу розроблення ПЗ вимогам чинних стандарта, угод, правил, закошв i розпоряджень; Ефективтсть роботи ПЗ - зв'язок мiж результатами використання програмного продукту та кiлькiстю зад1яних для цього ресурав (апаратних, матерiальних, пращ обслуговувального персоналу тощо).
Супроводжуватсть ПЗ - зусилля, якi потрiбно вит-ратити на коригування, вдосконалення й адаптацию програмного продукту у разi змiни середовища його використання, вимог або функщональних специфiкацiй.
Супроводжуватсть ПЗ характеризуеться такими по-казниками й атрибутами:
• аналiзованiсть - показник, який встановлюе потрiбнi зусилля для диагностики причин вiдмов програми або щен-тиф^ци 11 частин, що потрiбно модифiкувати;
• змiнюванiсть - показник, який встановлюе потрiбнi зусилля на модифжащю програми, усунення помилок або внесення змiн у зв'язку з виявленими помилками чи но-вими можливостями середовища функцiонування;
• стабыьтсть - атрибут, що характеризуе ймовiрнiсть удосконалення та модифiкацil програми;
• тестоватсть - атрибут, що характеризуе зусилля, пот-рiбнi для проведення валiдацil та верифiкацil програми.
Переностсть ПЗ - здатшсть програмного продукту пристосовуватися до рiзних середовищ його розроблення та використання, забезпечуючи при цьому надшну та безперебшну роботу. До основних компонент середовища розроблення ПЗ належить: оргатзацшно-тех-нологiчне, апаратне, програмне.
Атрибути переносносп ПЗ е такими: адаптивнкть, налагоджуватсть, сумютсть, узгоджетсть, ттеро-перабельмсть.
Оцтювання якостi ПЗ - дц, яю мають визначити, якою мiрою програмний продукт вiдповiдае своему призначенню.
5. Модель процесу визначення та аналiзу вимог до ПЗ. Модель процесу визначення та аналiзу вимог до ПЗ - це схема процесгв його ЖЦ, що виконуються вщ початку зародження проекту майбутнього ПЗ i доти, доки не будуть визначеш та сформованi набори вимог, проаналiзованi та погодженi сформульоваш вимоги iз зацiкавленими сторонами. Також у цш моделi мають бути передбачеш процедури введення вiдповiдних змш до вимог, введення цих змш у поточнш версil ПЗ чи !х реструктуризац1я в наступних релiзах.
Перед тим, як навести модель процесу визначення та аналiзу вимог до ПЗ, спробуемо спочатку з'ясувати основш вимоги до тако1 модели Згiдно з даними, наве-деними в роботi (Kungurcev, Ka1inina & Novikova, 2013), вимоги до моделi процесу визначення та аналiзу вимог до ПЗ можуть мати такий вигляд:
1) Встановлення назви i коротко!' характеристики ПЗ, що дасть змогу аналiтику сформувати стратегiю i вибрати тактику реалiзацi!' подальших дш.
2) З'ясування структури дiяльностi оргашзацп-замовника в обсязi, достатньому для виявлення та отримання доступу до вих зацiкавлених осiб у розробленш ПЗ.
3) Подання способiв з'ясування потреб до ПЗ, асоцшова-них iз зацiкавленими особами, формування набору ви-мог.
4) Подання докуменлв i видiв дiяльностi, асоцiйованих з робочими мкцями в пiдроздiлах органiзацil-замовника.
5) Надання можливостi аналiтику вiдвiдувати робочi мiс-ця у пiдроздiлах оргашзацп-замовника, вибирати спо-соби виявлення !'хшх потреб, визначити i сформулюва-ти вимоги до ПЗ, а також сформувати фрагменти вщпо-вщно!' специфжацп вимог.
6) Надання аналiтику шдказок до рiзних методик вико-нання робiт та послiдовностi реалiзацil дш, пов'язаних iз процесом визначення вимог, однак не пов'язаних з конкретною оргашзащею-замовником.
7) Збершання послiдовностi (ктори) дiй роботи аналiтика для подальшого !'х аналiзу та оцiнювания сформовано-го набору вимог до ПЗ.
8) Оцшювання результатiв роботи аналгтка шляхом ана-лiзу його послщовноста дiй як експертною системою, так i реальними експертами i порiвияния розробленоl ним специфiкацil вимог з еталоном, наявним у системi. Структура моделi експертноХ системи. Надалi
будемо називати модель процесу визначення та аналiзу
вимог до ПЗ його моделлю експертно! системи. К мож-на подати у виглядi кортежу, який складаеться Í3 таких трьох моделей
M = {Mo,Mi,Ma) , (1)
де: Mo - модель оргашзацп-замовника (модель предметно! обласп); Mi - шформацшна модель; Ma - модель роботи аналггака.
Модель оргашзацп-замовника призначена для по-дання ii структури i, що найважливiше, робочих мiсць, для яких якраз i мае розроблятися ПЗ. Модель гштуе дь яльнкть конкретних робочих мiсць та ввдповщних шд-роздiлiв оргашзацп, зв'язки 1хнього пiдпорядкування та взаемодй, що кнують у нiй. Модель оргашзацп-замов-ника Mo подамо у виглядi множини вушв
Mo = {Uj, j = Щ , (2)
де n - кiлькiсть вузлтв. Кожен вузол е деякою структурною одиницею оргашзацй-замовника, який подамо у виглядi такого кортежу:
U = {uj = (N,W,H,S,С), j = 1~n} , (3)
де: N - назва (щентифшатор) вузла; W - структурний шдроздш (вiддiл), до якого входить вузол; H - множина зв'язкв "шдлеглий - начальник"; S - множина зв'язкв "начальник - шдлеглий"; С - множина зв'язюв сшвпра-nj мiж начальником i шдлеглим.
Кожен зв'язок можна подати кортежем, наприклад
H = {K, Z) , (4)
де: K = {ki, i = 1,m} - вузол, з яким пов'язаний N-ий вузол; Z = {zi, i = 1, m} - стан зв'язку: доступний для переходу - true, закритий - false; m - юльюсть зв'язюв.
ЫформацШна модель слугуе для подання шформа-цл, яку аналiтик-стажер може отримати на кожному ро-бочому мкщ у будь-якому пiдроздiлi оргашзацп-замов-ника, алгоритми управлiння процесом навчання, етало-ни вимог, якi потрiбно сформувати. Ii можна подати у виглядi кортежу, який складаеться iз трьох моделей
Mi = (R,P,D), (5)
де: R = {Rj, j = 1, Nv} - множина варiантiв отримання ш-
формацй про вимоги, пов'язаних з кожним вузлом мо-делi оргашзацй; P - система допомоги; D - визначення документацп, яку мае сформувати аналiтик-стажер; Nv - юльюсть варiантiв отримання шформацп про вимоги. Поточний j-ий варiант отримання шформацп про вимоги Rj можна подати у виглядi такого кортежу
R = = (Nj,Fw,Vi), j = 1Nv} , (6)
де: Nj = {nJi, i = 1, m; j = 1, Nv} - отримання í-о! шформацй
про вимоги iз поточного j-го вузла; Fw - функniя шд-твердження можливих дш аналiтика в поточному вузлц Vi = {Vj, j = 1, n} - множина варiантiв отримання шформацп аналииком i можливостi управлшня його подаль-шою поведiнкою.
Подамо кожен варiант Vj у виглядi такого кортежу
V ={vj = (Ver,Val,Fa,Fn), j = LÑV} , (7)
де: Ver - одна iз множини версш отримання вимог (Ver е MVer); Val - еталонний вибiр; Fa - функniя аналiзу вибору аналиика та формування елемента вимог в його редакци; Fn - функщя навтацй, яка керуе зв'язками мiж вузлами залежно вiд результапв дiяльностi аналiтика.
В iнформацiйнiй моделi Mi органiзацi!-замовника використовуються такi варiанти отримання вимог вiд Г! защкавлених осiб:
MVer = (Wi,Vuc,Vd, Va) , (8)
де: Wi - взяття штерв'ю; Vuc - фжсування основних ва-рiантiв використання ПЗ; Vd - визначення докуменпв, що беруть участь у документообйу органiзацi!-замов-ника; Va - прототипування.
Програмну документацiю можна подати такими двома складниками
Doc = (Cont,Seq) ,
де: Cont - змкт специфжацй вимог до ПЗ; Seq - мктить допустиму послiдовнiсть заповнення роздiлiв специфь кацií вимог до ПЗ.
Модель роботи аналтика слугуе для:
• щентифтацп аналггика, який здшснюе визначення та аналiз вимог до ПЗ;
• визначення вимог про ПЗ за вериею аналггака;
• вщновлення позицп аналiтика шсля перерви в робот з моделлю;
• оцшка роботи аналiтика з моделлю, нагромадження ста-тистичниx даниx про процес навчання.
Модель роботи аналиика можна подати у виглядi такого кортежу:
Mp = (Ns, Hs,Rs), (9)
де: Ns - прiзвище (щентифжатор) аналiтика; Hs - кто-р1я роботи аналiтика з моделлю; Rs - результати роботи аналггака з моделлю (специфжащя вимог).
!сторто роботи аналiтикiв можна подати у виглядГ такого кортежу:
Hs = (Nsj,Valj,Seqj, j = 1Na) , (10)
де: Nsj = {nji, i = 1, m; j = 1, Na} - множина вузл1в, до яких
отримав доступ j-ий аналиик; Valj = {vji, i = 1,m; j = 1, Na}
- оцшки поточно! д1яльносп j-го аналiтика в i-му вузлГ; Seqj = {sji, i = 1,m; j = 1, Na} - роздши еталона документа-
цй' у i-му вут, якГ були доступш для j-го аналiтика; Na
- юльюсть потенцшних аналiтикiв.
На початку роботи аналиика з експертною системою змкт специфiкацií вимог Cont кошюеться в специ-фiкацiю вимог аналиика Rs. У процесi виконання роботи виявленi аналiтиком вимоги до ПЗ заносяться до вщ-поввдних роздГл1в Rs.
Удосконалена вище модель дае змогу для аналтака органiзувати процес визначення та аналiзу вимог до ПЗ, який значною мГрою наближаеться до реального. Роз-роблено структури документiв, якГ не суперечать за-гальновизнаним вимогам, а також процедури !х вико-ристання та формування, що дае змогу формувати змк-товш звГти за результатами навчання, контролювати процес навчання, фiксувати помилки й оцiнювати знания та вмшня аналiтика. Запропоновану модель можна деталiзувати з метою використання у рГзних предмет-них областях.
Висновки: 1. Виявлено, що успiшне функцiонуван-ня ПЗ багато в чому залежить ввд правильно! органiзацi! процесу виконання робгт з визначення та аналiзу вимог до нього. При цьому необхвдш всГ вГдповГднГ компетен-цй потенцшш фахiвцi-аналiтики отримують у процесi виршення конкретних завдань у рГзних предметних областях як п1д час навчання, так i протягом виробничо! ДГЯЛЬНОСТГ.
2. З'ясовано нагальш проблеми, якi стосуються про-цедури визначення вимог до ПЗ, а також виявлено шляхи !х уникнення та пом'якшення. Встановлено, що рiзнi методологи розроблення ПЗ можуть по^зному оргаш-зовувати роботу аналтака щодо реашзацн процедур визначення та аналiзу вимог до ПЗ. Кожна з цих процедур е початковою, тобто вони повшстю завершуються ще до початку етапу проектування архiтектури ПЗ та етапу його розроблення. Водночас, в ггеративних мето-дологiях розроблення ПЗ процедури визначення та ана-лiзу вимог до нього в рiзному обсязi е на кожнiй ггерацн.
3. Встановлено, що процедура аналiзу вимог до ПЗ може бути тривалою та ресурсовитратною, що вимагае вiд аналiтикiв детального знання предметно! обласп та застосування тонких психолопчних навик1в. З'ясовано, що багатьма науковцями i практиками виокремлено тага основнi етапи процедури аналiзу вимог до ПЗ: визначення защкавлених сторш у розробленнi ПЗ; штерв'ю iз зацiкавленими сторонами щодо !хшх потреб вiд майбутнього ПЗ; сшльш сесi! визначення вимог до ПЗ; набори вимог до ПЗ у сташ контракту; вишрюваш цiлi застосування майбутнього ПЗ; прототипи - макети майбутнього ПЗ; прецеденти - технолопя документу -вання вимог до ПЗ; специфшащя вимог до ПЗ.
4. Виявлено, що часто аналиики шд час роботи з представниками ввд органiзацi!-замовника забувають чи не хочуть доводити до !хнього вiдома показники якосп, яким мае вiдповiдати майбутне ПЗ, зшмаючи тим самим з себе певну вiдповiдальнiсть за виконану роботу. Згiдно з мiжнародними та вiтчизняними стандартами оцiнювання р1вня якостi програмного продукту, видшя-ють два процеси забезпечення якостi ПЗ впродовж його ЖЦ: 1) гаранты якостi ПЗ, що е результатом певних дш на кожнш стадн його ЖЦ з перевiрки й шдтвер-дження вiдповiдностi його стандартам i процедурам, орiентованим на досягнення певних характеристик якостi; 2) тженерт якостi ПЗ як процес надання майбутньому ПЗ надшносп, супроводу й шших характеристик якостi.
5. З'ясовано, що модель процесу визначення та ана-лiзу вимог до ПЗ - це структура процес1в його ЖЦ, що мають бути виконаш вщ початку зародження проекту майбутнього ПЗ i доти, доки не будуть визначеш та сформоваш набори вимог, детально проаналiзованi та погоджеш сформульованi вимоги iз защкавленими сторонами. Також у цш моделi мають бути передбаченi процедури введення ввдповвдних змiн до вимог, внесен-ня цих змiн у поточнш версi! ПЗ чи !х реструктуризацiя в наступних релiзах. У формалiзованiй моделi удоско-налено вщповвдш процедури, якi стосуються визначення та аналзу вимог до ПЗ.
Перелж використаних джерел
Belchikov, Ya., & Birshtejn, M. M. (1989). Delovye igry. Riga:
AVOTS, 304 p. [in Russian]. Blagodatskih, V. A., Volnin, V. A., & Poskakalov, K. F. (2005). Stan-dartizacija razrabotki programmnyh sredstv: uchebn. posob. Moscow: Finansy i statistika, 288 p. [in Russian]. Bobalo, Yu. Ya., Volochii, B. Yu., Lozynskyi, O. Yu. et al. (2013). Matematychni modeli ta metody analizu nadiinosti radioelek-tronnykh, elektrotekhnichnykh ta prohramnykh .system: monohra-fiia. Lviv: Vyd-vo Lvivskoi politekhniky, 300 p. [in Ukrainian].
Boegh, J., Depanfilis, S., Kitchenham, B., & Pasquini, A. A. (1999). Method for Software Quality Planning, Control, and Evaluation. IEEE Software, 16(2), 69-77. https://doi.org/10.1109/52.754056
Futrell, R. T., Shafer, D. F., & Shafer, L. I. (2003). Quality software project management. New York: Prentice Hall PTR, 1136 p.
Gilb, T. (1988). Principles of Software Engineering Management. Reading MA: Addison Wesley, 464 p.
IEEE 1031-2011. (2008). IEEE Guide for the Functional Specification. Retrieved from: https://standards.ieee.org/findstds/standard/ 1031-2011.html
IEEE 1061-26157. (1998). Standard for Software Quality Metrics Methodology. Retrieved from: http://www.techstreet.com/cgi-bin/ detail ?product_id = 26157 (data obrashhenija: 20.06.2008).
IEEE 830-1998. (1998). Recommended Practice for Software Requirements Specifications. New York: IEEE, 44 p.
ISO/IEC, ISO/IEC 25000. (2005). Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE. - Geneva: International Organization for Standardization. Retrieved from: http://www.iso.org/iso/iso_catalogue/ catalog-ue_tc/catalogue_detail.htm?csnumber = 35683 (data obrashhenija: 26.07.2008).
Kobern, A. (2011). Sovremennye metody opisanija funkcionalnyh tre-bovanijksistemam. Moscow: Lori, 263 p. [in Russian].
Kungurcev, A. B., Kalinina, S. A., & Novikova, N. A. (2013). Model processa opredelenija trebovanij k programmnomu produktu. Visnyk NTU "KhhPI". Seriia: Novi rishennia v suchasnykh tekhnolo-hiiakh, 55(1011), 55-61. Kharkiv : Vyd-vo NTU "KhPI". [in Russian].
Kungurcev, A., Blazhko, A., & Marulin, S. (2010). Metodika prove-denija obuchenija osnovam proektirovanija programmnyh sistem v vide rolevyh kompjuternyh igr. Godishnik na tehnicheski universi-tet. In 3 vols. Vol. 1: Sbornik dokladov ot jubilejnoj nauchnoj kon-ferencii s mezhdunarodnym uchastiem (pp. 123-126). Varna: Varna. [in Russian].
Lavrishheva, E. M., & Petruhin, V. A. (2006). Metody i sredstva inzhe-nerii programmnogo obespechenija: uchebn. posob. Moscow: Izd-vo Moskovskogo fiziko-tehnicheskogo instituta, 304 p. [in Russian].
Leffingujell, D., & Uidrig, Don. (2002). Principy raboty s trebovani-jami kprogrammnomu obespecheniju. Moscow-Sankt-Petersburg: Izd. dom "Viljams", 450 p. [in Russian].
Lukina, M. (2003). Tehnologija intervju: uchebn. posobie [dlja VU-Zov]. Moscow: Aspekt Press, 480 p. [in Russian].
McConnell, S. (2013). Sovershennyj kod. Master-klass. Moscow: Izd-vo "Russkaja redakcija", 896 p. [in Russian].
McCall, J., Richards, P., & Walters, G. (1977). Factors in Software Quality. Three volumes: NTIS AD-A049-014, AD-A049-015, AD-A049-055. Retrieved from: http://oai.dtic.mil/oai/oai?&verb = get-Record&metadataPrefix = html&identifier = ADA049014 (data obrashhenija: 17.05.2008).
Mishhenko, V. O., Pomorova, O. V., & Govorushhenko, T. A. (2012). CASE-ocenka kriticheskih programmnyh sistem. In 3 vols. Vol. 1: Kachestvo; pod red. V. S. Kharchenko. Kharkov: NAU "KhAI", 201 p. [in Russian].
Pomorova, O. V., & Hovorushchenko, T. O. (2013). Suchasni prob-lemy otsiniuvannia yakosti prohramnoho zabezpechennia. Ra-dioelektronni ta kompiuterni systemy, 5, 319-327. Kharkiv : NAU "KhAI". [in Ukrainian].
Vedenina, V. (2013). Delovaja igra i ee vozmozhnosti. Retrieved from: http://tolerance.ru/teacher/kabinet/business-game.html (data obrashhenija: 26.02.2013). [in Russian].
Vigers, K. (2004). Razrabotka trebovanij k programmnomu obespec-heniju : per. s angl. Moscow: Izd.-torg. dom "Russkaja Redakcija", 576 p. [in Russian].
Yakovyna, V., Seniv, M., Chabaniuk, Ya., Fedasiuk, D., & Khimka, U. (2010). Kryterii dostatnosti protsesu testuvannia prohramnoho zabezpechennia. Visnyk Natsionalnoho universytetu "Lvivska poli-tekhnika". Seria: Kompiuterni nauky ta informatsiini tekhnolohii, 672, 346-358. [in Ukrainian].
Ю. И Грыцюк, И. Ф. Лешкевич
Национальный университет "Львовская политехника", г. Львов, Украина
ОСОБЕННОСТИ ОПРЕДЕЛЕНИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ
ОБЕСПЕЧЕНИЮ И ПРОБЛЕМЫ ИХ АНАЛИЗА
Проведен системный анализ предметной области, результаты которого позволили достоверно описать существующие проблемы, касающиеся процедур определения и анализа требований к программному обеспечению (ПО), выяснено виды деятельности аналитика для эффективного решения этих проблем, а также предложены основные показатели качества будущего ПО, усовершенствована формализованная модель для реализации процедур определения и анализа требований к ПО. Установлено, что процедура анализа требований к ПО может быть длительной и ресурсозатратной, что требует от аналитиков детального знания предметной области и применение тонких психологических навыков. Выяснено, что многими учеными и практиками выделены основные этапы процедуры анализа требований к ПО. При этом часто аналитики в процессе работы с представителями от организации-заказчика забывают или не хотят доводить до их сведения показатели качества, которым должно соответствовать будущее ПО, снимая тем самым с себя определенную ответственность за выполненную работу. Согласно международным и отечественным стандартам оценки уровня качества программного продукта, выделяют два процесса обеспечения качества ПО в течение его ЖЦ: гарантия качества ПО является результатом определенных действий на каждой стадии его ЖЦ по проверке и подтверждения соответствия его стандартам и процедурам, ориентированным на достижение определенных характеристик качества; инженерия качества ПО как процесс предоставления будущего ПО надежности, сопровождения и других характеристик качества.
Ключевые слова: предметная область; системный анализ предметной области; виды деятельности аналитика; определение требования к программному обеспечению (ПО); анализ требования к ПО; показатели качества ПО; модель определения и анализа требований к ПО.
Yu. I. Grytsiuk, I. F. Leshkevych
Lviv Polytechnic National University, Lviv, Ukraine
THE PROBLEMS OF DEFINITION AND ANALYSIS OF SOFTWARE REQUIREMENTS
Successful operation of the software largely depends on the proper organization of work to identify and analyze its requirements. Therefore the study aims at systematic analysing of the subject area. The results obtained enabled certain describing of the immediate problems related to procedures, and also identifying and analysing software requirements. The analysis has found activities to effectively address these issues and provide the main indicators of the quality of future software. A formalized model for implementation of procedures to identify and analyse software requirements is improved. The study has defined that potential experts can gain all the relevant competences in the process of solving specific problems in different subject areas both during training and production activities. The authors have highlighted the procedure for software requirements analysis can be quite extensive and resource intensive requiring detailed knowledge of the subject area and use subtle psychological skills. Moreover, many scientists and practitioners singled out the following main stages of the procedure of software requirements analysis: definition of interested parties in software development; interviews with interested parties on their needs in the future of software; joint session for definition of requirements for the software; sets of the requirements for the software contract in style; measurable targets for future software application; prototype - a model of future software; precedents - the technology for documenting requirements for software; specification of requirements for software. To conclude, firstly for proper software operation all the certain competences of field experts are required when performing specific tasks in various subject areas both during training and production activities. Secondly, urgent problems concerning procedures of determining requirements for software and the ways of their avoidance and mitigation are distinguished. Finally, appropriate procedures regarding the definition and analysis of software requirements are improved in the formalized model.
Keywords: systems analysis; subject area; analyst activities; definition of requirements for software; software requirements analysis; quality software; model definition and analysis of software requirements.
1нформащя про aBTopiB:
Грицюк Юрш 1ванович, д-р техн. наук, професор, Нацюнальний ушверситет '^bBiBCbKa полтехшка", м. Львiв, Украша.
Email: yurii.i.hrytsiuk@lpnu.ua
Лешкевич 1гор Федорович, мапстрант, Нацюнальний ушверситет '^BiB^^ полггехшка", м. Львiв, Украша.
Email: lif95.mailbox@gmail.com
