CC BY
45
НЛТУ
ы КРАЖИ
»mutet*
Науковий в!сн и к НЛТУ УкраТни Scientific Bulletin of UNFU
http://nv.nltu.edu.ua https://doi.org/10.15421/40280130 Article received 20.02.2018 р. Article accepted 28.02.2018 р.
УДК 004.056:65.012.2
ISSN 1994-7836 (print) ISSN 2519-2477 (online)
El Correspondence author Yu. I. Hrytsiuk yurii.i.hrytsiuk@lpnu.ua
Ю. I. Грицюк, М. Р. Жабич
Нацюнальнийунiверситет "Львiвська полШехтка", м. Львiв, Украта
УПРАВЛ1ННЯ РИЗИКАМИ РЕАЛ1ЗАЦН ПРОГРАМНИХ ПРОЕКТ1В
Запропоновано тдхщ до управлшня ризиками реалiзацií програмних проекив, на mдставi якого встановлено особливос-т оцiнювання ризикових подiй на стан процесу розроблення програмного забезпечення (ПЗ), що дало змогу визначити величину можливих втрат вщ настання негативних ситуацш. Охарактеризовано таю поняття, як управлiння програмними проектами та ризиками 'х реалiзацií, що дало змогу визначити компоненти такого управлшня, основш категори ризиюв, ризик-орieнтовний пiдхiд до процесу управлшня, а також уможливило визначення прийнятного рiвня ризику устшного завершен-ня (провалу) програмних проектiв 1Т-компашею. Встановлено, що при збiльшеннi витрат на тдвищення безпеки реалiзацii' програмних проекив так званi виробничi ризики зменшуються, але зростають професiйно-полiтичнi ризики. Виявлено, що тдготовка ефективних заходiв реагування на потенцiйнi проблеми зводиться до визначення певного набору дш, яю потрiб-но зробити для того, щоб пiдсилити позитивнi результати прояву ризикових подш i послабити негативш 'х наслiдки. Роз-роблено методику оцшювання ризикiв реалiзацii' програмних проекив, яка дае змогу встановити порушення термiнiв вико-нання завдань проекту вщносно 'х запланованих термтв, де виявленi такi порушення, серед тих завдань проекту, що мають виконуватися на поточний момент. При цьому величину потенцшних втрат можна оцшити шляхом встановлення значення найбшьшого з можливих проявiв ризикових подш на окремi завдання проекта з моменту оцшювання цього впливу, яю зага-лом позначаються на остаточному термт виконання усього проекту. Встановлено особливост оцiнювання впливу ризикових подш на хщ реалiзацil програмного проекту, що дало змогу розробити методику визначення величини можливих втрат вщ настання негативних ситуацш. При цьому процедура оцшювання щентифжованих ризиюв реалiзацil програмного проекту Грунтуеться на ефективност запланованих заход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 професшною тд-тримкою його виконавщв. П1д ризиком в iнженерiï ПЗ, зазвичай, розумшть умову, яка може привести до втра-ти очшуваного прибутку, або подiю, яка може поставите тд загрозу успiх реалiзацiï програмного проекту (Sommervill, 2002; Braude, 2004; DoD. USA, 2014). Управлшня ризиками - невщ'емна складова ефективного управлiння будь-яким програмним проектом (Johnson & Tennessee, 2006). При цьому керiвник проекту як особа, що плануе, управляе та здiйснюe постiйний контроль за вйма етапами виконання завдань проекту, повинен чгг-ко i ефективно управляти ризиками ïx реалiзацiï (Williams, Pandelios & Behrens, 1999). Вш також мае прогно-зувати потенцшш прибутки та оцiнювати можливють втрат вiд запровадження того чи шшого заходу, а також прагнути до зменшення збитк1в при настанш ризикова-них подiй. Впровадження мiжнародниx стандартiв у процес управлiння ризиками дае змогу керiвникам проекпв зробити це управлiння бiльш ефективним i макси-
мiзувати потенцiинi можливосп та мiнiмiзувати непе-редбаченi втрати в ходi досягнення як тактичних, так i стратегiчних цiлеИ реалiзацiT програмних проектiв (ISO/IEC 12207, 2008; ISO/IEC 33001, 2015).
Управлiння проектами (англ. Project Management) -це область знань з планування, оргашзацп та управлшня ресурсами, спрямована на ефективне досягнення щ-леИ та устшне завершення завдань проекту (Reshke & Shelle, 1994). Iнодi таке управлiння ототожнюють з уп-равлiнням програмами, але програма - це значно вищий рiвень, тобто група пов'язаних i взаемозалежних проек-тiв. Водночас проект (вiд лат. Projectus - кинутий вперед) в управлiннi проектами - це обмежена в чай, ресурсах i вимогах якосп ушкальна сукупшсть процесiв чи явищ, направлена на створення ново! цiнностi. У зв'язку з широким використанням технологiИ управлшня проектами у рiзних областях знань юнуе И багато визначень термша "проект" (Mykhailovska, 2008).
В програмуванш програмний проект (англ. Software Project) - це набiр файлiв, з якими користувач працюе тд час створення прикладно! програми в об'ектно-орiентованому чи будь-якому шшому середовищi (Lipa-ev, 2005; Gultiaev, 2008; Singaevskaia, 2008). В iерархil
^фор^^я про aBTopiB:
Грицюк Юрiй lвaнович, д-р техн. наук, професор кафедри програмного забезпечення. Email: yurii.i.hrytsiuk@lpnu.ua Жaбич Мaринa PoMaHiBHa, студентка кафедри програмного забезпечення. Email: maryna.zhabych.pi.2014@lpnu.ua Цитyвaння 3a ДСТУ: Грицюк Ю. I., Жабич М. Р. Управлшня ризиками реaлiзaцiï програмних проекпв. Науковий вкник НЛТУ
УкраТни. 2018, т. 28, № 1. С. 150-162. Citation APA: Hrytsiuk, Yu. I., & Zhabych, M. R. (2018). Risk Management of Implementation of Program Projects. Scientific Bulletin of UNFU, 28(1), 150-162. https://doi.org/10.15421/40280130
систем управлшня шд програмним проектом розумшть ieрарх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ки 1Т-компанп, зазвичай, стають конкурентоспроможними тiльки за рахунок ш-новацiйноï дiяльностi, яка за своею суттю пов'язана з ризиком, тобто ймовiрнiстю виникнення збитшв або не-доотримання прибутк1в порiвняно з прогнозованими (Williams, Pandelios & Behrens, 1999; Zyl, 2010). Ризик -важлива складова прийняття ршень, неврахування яко-го призводить до вироблення, аналiзу й прийняття не-обгрунтованих i малоефективних управлiнських рь шень. Отже, ризик е одночасно як причиною можливих збитшв, так i джерелом потенцшних прибутк1в (Bori-sov, Krumberg & Fedorov, 1990). Основне завдання уп-равлiння ризиками - не вiдмовигись вiд ризику як такого взагал^ а приймати ризиковi рiшення, грунтуючись на об'ективних критерiях i допустимих втратах. Прийнятi керiвником проекту ризик-орiентованi ршен-ня часто приводять до бшьш ефективно1' реалiзацiï програмних проектiв, вщ яких отримують свою вигоду як замовники i розробники ПЗ, так i його безпосередш користувачi.
Управлiння ризиками реалiзацiï програмного проекту безпосередньо пов'язане з такими проблемами як уп-равлшня процесом розроблення ПЗ, управлiння вимога-ми до ПЗ та проблемою ризик-менеджменту, тобто упра-влiння страховим ризиком (DeMarko & Lister, 2005). Для досягнення бажаних результатiв у встановлеш термiни та в допустимих межах фшансових i матерiальних вит-рат етапи реалiзацiï програмного проекту потрiбно ре-тельно й досконало планувати та як1сно ними управляти.
Анaлiз останшх досл1джень та публшацш. Проб-леми розроблення ПЗ в рiзний час були розглянутi в ба-гатьох наукових публiкацiях вичизняних i закордонних учених, таких як С. 1ванько (Ivanko, 2008), К. Кастелла-нi (Kastellani, 1982), В. Ковальов (Kovalev, n.d.), В. Шкыр (Shkvir, Zahorodnii & Vysochan, 2007). Проте, у сво1'х дослiдженнях i публшащях вони мало придiляли уваги аналiзу причин появи ризик1в, яш необхiдно вра-ховувати у процеа розроблення ПЗ.
Питання управлiння ризиками розроблення ПЗ широко розглянуто в рiзних наукових джерелах, почина-ючи з нормативних документiв Мшстерства оборони США (Williams, Pandelios & Behrens, 1999), в роботах, написаних з використанням цих даних (Johnson & Tennessee, 2006), i завершуючи виданнями для широкого загалу (DeMarko & Lister, 2005). Наприклад, в роботах (DoD. USA, 2014; Johnson & Tennessee, 2006; Williams, Pandelios & Behrens, 1999) процес оргашзацп ризик-менеджменту розглянуто як проект всередиш програмно-го проекту. Автори стверджують, що цей проект мае
сво1' етапи життевого циклу i управлiння ним потрiбно проводити паралельно з управлiння програмним проектом. У робой (DeMarko & Lister, 2005) хоча матерiал й викладено дещо спрощено, проте його головна iдея -ризик-менеджмент складна, але необхiдна складова життевого циклу будь-якого програмного проекту.
Осшльки джерела (DoD. USA, 2014; Johnson & Tennessee, 2006; Williams, Pandelios & Behrens, 1999; DeMarko & Lister, 2005) - закордонш, то вони мало прис-тосованi для виршення проблем розроблення ПЗ. Також в уйх цих дослщженнях не було враховано еконо-мiчних i локальних особливостей процесу розроблення ПЗ компашями, як1 знаходяться в Украшг Хоча в робо-ri (Johnson & Tennessee, 2006) й розглянуто спрощену модель управлiння ризиками в програмному проектi, однак описаш в iнших роботах деяк1 методологи управлшня ризиками не розглядають 1'х як iнструмент для по-будови моделей ризик1в пiд час розроблення ПЗ.
Управлiння ризиками е достатньо дискусшною темою, тому особливоси реалiзацiï цього процесу широко розглянуто в багатьох наукових вичизняних (Kulikova, 2008; Lipaev, 2005; Maksimov & Nikonov, 2004) i закордонних (Heckerman, 1995; SWEBOK, 2004; DeMarko & Lister, 2005) джерелах. Ц публiкацiï призначенi для р!з-них дослiдникiв - як для професiоналiв з ризик-менеджменту та розроблення ПЗ (Heckerman, 1995; SWEBOK, 2004; Golenko, 1968), так i для широкого загалу (DeMarko & Lister, 2005; Kulikova, 2008; Sobol, 1972; Sommervill, 2002).
В роботах (Kulikova, 2008; Lipaev, 2005) розглянуто шльшсний аналiз ризишв у контексп управлшня ними. Наприклад, у робой (Lipaev, 2005) зосереджено увагу на особливостях аналiзу ризишв i зменшення 1'х шль-коси пiд час реалiзацiï проектiв складних програмних систем. Також в нш дослвджено моделi та процеси оргашзацп ризик-менеджменту у великому проекп розроблення ПЗ.
1снують рiзнi моделi управлiння ризиками (Braude, 2004; Zyl, 2010; Sommervill, 2002; Terekhov, 2003), серед яких найбшьшого використання набула модель 1н-ституту програмно! iнженерiï Карнеги-Меллон (англ. Software Engineering Institute, SEI), що мютить як вимо-ги стандартiв (ISO/IEC 12207, 2008; ISO/IEC 33001, 2015), так i вiдомi кращi практичш рекомендацiï щодо хх запобiгания чи знешкодження. В роботах (Golenko, 1968; Kulikova, 2008; Sobol, 1972) розглянуто теоретич-m основи iмiтацiйного моделювання та створення !миа-цiйних моделей на базi метода Монте-Карло. В роботах (Borisov, Krumberg & Fedorov, 1990; Leonenkov, 2003) розглянуто теоретичш основи апарату нечiткоï логiки, а в роботах (Heckerman, 1995; Hugin Expert, n.d.; Terekhov, 2003) наведено теоретичш основи Байеавсько! мереж! довiри (БМД) та приклади !х використання.
Однак, незважаючи на наявш теоретичнi та практич-m наирадювання в сферi управлiния ризиками, !х ефек-тивному використанню в сферi управлiния програмни-ми проектами за наявних украшських реалiй заважають деяк1 обставини. Насамперед це стосуеться стандарив, як1 розробленi закордонними оргашзацгями та призна-ченими для застосування у великих IТ-компанiях (ISO/IEC 12207, 2008; ISO/IEC 33001, 2015), досвщчет фахiвцi яких пройшли вщповщну шдготовку та володь ють сучасними методами ризик-менеджменту (Mame-dova, 2005; Mykhailovska, 2008). Також розробники цих
стандарпв, здебшьшого, прямо вказують на те, що "щентифшащю ризик1в бiзнес-дiяльностi оргашзацп, як правило, мають проводити незалежш експерти". Тому вiтчизнянi ризик-орieнтованi 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í програмних проекпв, яш дають змогу встановити порушення термшв виконання зав-дань проекту вщносно 1х запланованих термiнiв i величину можливих втрат вiд настання ризикових подiй.
Метою дослiдження е розроблення тдходу до управлшня ризиками реалiзацií програмних проектiв i на його основi встановити особливосп оцiнювання впливу ризикових подiй на стан процесу розроблення ПЗ, що дасть змогу визначити величину можливих втрат вщ настання негативних ситуацш.
Для реалiзацií зазначено! мети потрiбно виконати так1 основш завдання:
1) охарактеризувати таю поняття, як управлшня програм-ними проектами та ризиками 1х реал1зацп, що дасть змогу визначити компоненти такого управлшня, основ-т категорп ризиюв, ризик-ор1ентовний шдхщ до процесу управлшня, а також уможливить визначення прийнятного р1вня ризику устшного завершення (провалу) програмних проекпв 1Т-компашею;
2) з'ясувати основш завдання процесу управлшня ризиками реал1зацп програмних проекпв, що уможливить пе-редбачення кер1вництвом 1Т-компанп появу негативних ситуацш чи несприятливих подш, яю вимагають попередньо! тдготовки персоналу до 1хнього настання;
3) розробити шдхщ до ощнювання ризиюв реал1зацп програмних проекпв, який дасть змогу встановити порушення термшв виконання завдань проекту вщносно 1х запланованих термшв, де виявлеш таю порушення, серед тих завдань проекту, що мають виконуватися на поточний момент;
4) встановити особливосп ощнювання впливу ризикових подш на хщ реал1зацп програмного проекту, що дасть змогу визначити величину можливих втрат вщ настання негативних ситуацш;
5) зробити вщповщш висновки та надати рекомендацп щодо використання розроблено! методики ощнювання ризиюв реал1зацп програмних проекпв.
1. Управл1ння програмними проектами та ризиками 1х реал1зацп
Зараз слова "проект", "менеджер проекту", "управлшня проектами", "ризики реалiзацií проектiв" стали вельми популярними, проте, вживання !х у багатьох ви-падках не виправдане (Mykhailovska, 2008). Часто ке-рiвництво компанп, слвдуючи данинi моди, називають проектом ту чи шшу звичайну роботу, а управлiнський персонал нижчо! ланки величають не керiвниками вщ-дiлiв, а "менеджерами проекпв". Це при тому, що таю менеджери виконують роботу, яку "проектом" назвати не можна в принцит. Насправдi ж, пiд "проектом" пот-рiбно розумiти тимчасовi роботи, спрямоваш на ство-рення унiкальних продукпв або надання послуг, тобто таких, яш мають iстотнi вiдмiнностi вщ iнших, можли-во й схожих, продукпв або наданих послуг (Gultiaev, 2008).
Тут у багатьох може виникнути таке запитання: чо-му, власне, тимчасовi роботи? Тому що у проекп мае iснувати ознака його початку й завершення. Хоча проекта можуть тривати роками - 1х не можна розглядати як щось постшне. Вони тимчасовi за своею суттю, тому мають бути рано чи тзно завершена Однак, не варто плутати проекти з перюдичними роботами. Основна вiдмiннiсть проекту ввд перiодичних робiт у тому, що проект завершуеться пiсля досягнення певно! мети, тодi як перюдичш роботи можуть бути завершенi та знову вщновлеш в подальшому (Singaevskaia, 2008). Часто на-вiть команду виконавщв проекту набирають тiльки для досягнення певно! мети проекту та розпускають тсля його завершення, що ще бшьше пiдкреслюе його тимча-сову природу.
Управлiння проектами - це певний набiр дiй, що мiстить методолопю управлiння технологiчними опера-цiями, методи виршення окремих завдань, вимоги до продукту проекту (очшуваного результату), шструмен-ти, регламенти та процедури виконання рiзних робiт (Fatrell, Shafer & Shafer, 2003). Цей набiр дай також мю-тить компоненти оргашзацшно! структури 1Т-компанп, як1 об'еднанi в едину цiлеспрямовану систему, що вико-ристовують для управлiння як окремими проектами, так i !хньою сукупшстю.
Управлiння програмними проектами - особливий вид дiяльностi 1Т-компанп, що передбачае системний шдхщ до оргашзацп процесу управлшня, який застосо-вують до тдготовки планiв розроблення ПЗ, а також визначае знання, навики, шструментальш засоби, як1 використовують для реалiзацií цих проектiв (Lipaev, 2005). Для 1Т-компанп - це сукупнiсть взаемно пов'яза-них компонент, таких як:
1) моделг, методи г засоби системи управлшня, яю дають змогу кер1внику компанп здшснювати тдготовку обгрунтованих р1шень щодо реал1зацп програмних проекпв, науково анал1зувати альтернативи !х вирь шення та обгрунтовано приймати ршення у встановле-т термши \ з достатньою точшстю;
2) наявний персонал - група фах1вщв (менеджер1в, кер1в-ниюв, б1знес-аналггиюв), що мають вщпов1дну тдго-товку з управлшня проектами, д1ють за единими правилами виршення вщповщних завдань, яю регламентова-т чинними нормативно-правовими документами в га-луз1 1Т - стандартами, постановами, наказами, ршен-нями тощо;
3) iHcmpyMeHmrnbHi засоби - автоматизована шформа-цшна система, що створюе единий iнформацiйний npocTip для учасникiв програмних проекпв i забезпе-чуе реалiзацiю методологи управлiння технологiчними операцiями незалежно вiд мiсця знаходження наявного персоналу;
4) ресурси - людсью (аналггиюв 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 та оргашзацшш проекти (Fatrell, Shafer & Shafer, 2003). Оск1льки в цьому дослвдженш нас щкав-лять тшьки проекти розроблення та удосконалення ПЗ, то вони мають так1 основш особливостг
1) Процес розроблення ПЗ здшснюеться з використанням методологiй, методiв i пiдходiв програмно1 шженерп.
2) Програмна iнженерiя (англ. Software Engineering) - це шженерна дисциплiна, яка пов'язана з умма особливос-тями технолопчного процесу розроблення ПЗ -вщ по-чатково1 стадп створення специфжацп вимог до ПЗ, ре-алiзацil стадiй його проектування, конструювання та тестування, до завершення стадп тдтримки програм-но1 системи пiсля здачi ПЗ в експлуатацiю.
3) Модель програмного процесу - це спрощений опис тех-нологiчного процесу розроблення ПЗ, поданий з деяко! точки зору. Моделi завжди е дещо спрощеннями реаль-ностi.
4) Метод програмно! шженерп - це системний шдхщ до процесу розроблення ПЗ, нацшений на створення ефек-тивного програмного продукту найбшьш прибутковим (рентабельним, cost-effective) шляхом. Практично всi методи П1 побудованi на ще1 створення графiчних моделей системи з подальшим використанням цих моделей як специфжацп вимог або архiтектури системи. Реалiзацiя програмних проектiв, особливо середньо!
та велико! складносп, - е недостатньо визначеним i, що найважливiше, детермшованим процесом (Lipaev, 2005). Використання сучасних програмних засобiв, складшсть виконання завдань проекту, часта вщсутшсть як у за-мовника проекту, так i його виконавцiв необхiдно! ква-лiфiкацil - це основнi чинники, що вказують на неод-нозначнiсть можливих ситуацш пiд час реалiзацi! програмного проекту та формують невизначешсть очшува-них результатiв (Leonenkov, 2003). Завдяки цим i ба-гатьом шшим чинникам х1д реалiзацi! еташв програмного проекту i остаточш його результати часто вiдрiз-няються вiд попередньо запланованих, тобто юнують так званi ризики реалiзацi! програмного проекту.
Хоча ризики реалiзацil програмних проекпв й подiлено на дешлька основних категорiй (Kuzminykh, Khaustov & Korostelov, 2010), однак, у кожному конкретному випадку можуть бути додаш й iншi типи ри-зик1в, як1 не розглянуто тут. Отже, до основних катего-рш ризик1в належать:
• ризики, пов'язат з неповнотою вимог до ПЗ, тобто передба-чають врахування очевидних i реал1защю другорядних вимог, а також неврахування критичних i вщкладання концеп-туальних вимог тощо;
• технологгчт ризики - ризики, пов'язаш з незнаниям технологи, яю плануеться використовувати персоналом для роз-
роблення ПЗ, або з низькою апробащею й вщпрацьовашстю цих технологи в колективi виконавщв проекту;
• ризики, пов'язат з низькою квалiфiкацiею персоналу, тобто керiвник проекту повинен знати можливост сво!х иращв-никiв i, за потреби, оргашзувати !х навчання ще до початку реалiзацп проекту, щоб не витрачати час на л^щащю по-милок у розробленому ПЗ;
• полтичт ризики - саботаж, який, зазвичай, не вистав-ляеться напоказ, проте може занапастити будь-який проект, якщо його учасники матимуть сво! цiлi дiяльностi, яю не завжди збтатимуться з цiлями керiвника проекту.
Одним 1з заход1в, що за таких умов шдвищуе ймо-в1ршсть усшшного завершення проекту, - запроваджен-ня сучасних метод1в управл1ння ризиками реал1зацп програмних проекпв. Тут тд управлгнням ризиками ро-зумшть виконання процедур щентифшацп та анал1зу ризикових подш як запланованих, так 1 випадкових, а також анал1зу наслщшв в1д !хнього настання як пози-тивних, так 1 негативних. При цьому ставиться за мету максим1зувати ймов1ршсть появи сприятливих подш та !хшх позитивних результапв 1 мш1м1зувати ймов1ршсть виникнення несприятливих подш 1 негативш наслвдки !хнього прояву. Однак, досить часто кер1вники проекпв обмежуються тшьки роботою з несприятливими подь ями, тобто потенцшними небезпеками та негативними наслщками в1д !хнього прояву.
Зрозумшо, ризики виникнення потенцшних небез-пек юнують в уйх проектах, але не завжди вони в1дбу-ваються. Проявлена небезпека, зазвичай, перетво-рюеться на проблему як поточну, так 1 майбутню. Прог-нозування потенцшних небезпек у багатьох випадках -це передбачення прояву деяких ризикових подш, що, як правило, мають негативно вплинути на х1д реал1зацп програмного проекту та на його остаточш результати. У такому контексп ризик виникнення потенцшно! не-безпеки розглядають як прояв деяко! випадково! поди, яка мае ймов1ршсний характер (Kulikova, 2008).
Кшьшсно ризик виникнення потенцшно! небезпеки визначають як добуток ймов1рносп прояву випадково! поди на оч1куваний розм1р збитку, що може завдати ре-ал1зована небезпека, тобто матиме такий вигляд: R = Р-З,
де: Р - ймов1ршсть (частота) виникнення потенцшно! небезпеки, под1я/час; З - очшуваний розм1р збитку, що може завдати проявлена (реал1зована) небезпека, зби-ток/под1я. Тут практично беруть шльшсть несприятливих подш, яш вщбулися за певний пром1жок часу, мно-жать на величину середнього збитку за одну подш й отримують загальну величину збитку, збиток/час.
Для прогнозування ризику виникнення потенцшних небезпек потр1бно визначити частоту появи несприятливих подш 1 очшуваний збиток в1д них. Осшльки ймо-в1рн1сть - величина безрозм1рна, то узагальнений по-казник ризику R мае вим1рюватись в одиницях збитку в1д проявлено! небезпеки за певний пром1жок часу. Потреба ощнювання ризику зумовлюе запровадження заход1в, спрямованих на його зниження 1, як наслвдок, пом'якшення насл1дк1в прояву несприятливих подш. Це не що шше, як забезпечення безпеки реал1зацп програмного проекту у конкретних умовах, адже, як ведомо, безпека - прийнятний р1вень ризику. Виходячи з цього п1д час управлшня ризиками реал1зац1! програмного проекту часто використовують ризик-оргентовний тд-х1д (РОП), що грунтуеться на плануванш процесу уп-
равлшня ризиками, 1х iдентифiкацií, якiсному, юльюс-ному та комплексному оцiнюваннi, плануванш реалiза-ци заходiв щодо зниження рiвня ризикiв на основi пос-тiйного монiторингу (Mykhailovska, 2008).
На практищ досягнути нульового рiвня ризику, тоб-то абсолютноI безпеки реаизаци програмного проекту неможливо, позаяк юнують обмеження на ресурснi можливост 1Т-компани. 1з збiльшенням витрат на тд-вищення тако*1 безпеки керiвництво 1Т-компани виму-шене зменшувати витрати на виртення, наприклад, професiйно-полiтичних проблем и працiвникiв. Надмiр-нi витрати на забезпечення безпеки реалiзацií програмного проекту можуть завдати шкоди якостi самому ПЗ (Fatrell, Shafer & Shafer, 2003). Окрiм цього, в наявних програмних системах, яю використовують для тдтрим-ки процесу розроблення ПЗ i його тестування, взагалi неможливо забезпечити нульовий ризик.
Сучасна концепцiя забезпечення безпеки реалiзацií програмного проекту грунтуеться на досягненш прийнятного (допустимого) ризику, тобто такого його рiвня, яке керiвництво 1Т-компани спроможне забезпечити на даний момент, виходячи з наявного рiвня фь нансування, матерiально-технiчного забезпечення, про-фесiоналiзму персоналу та розвитку методiв шженери ПЗ. Прийнятний рiвень ризику - це компромiс мiж рiв-нем безпеки i можливостями и досягнення. Концепцiю прийнятного (допустимого) ризику часто застосовують 1Т-компани для визначення ризиюв реалiзацií програмних проеклв за рш, де продукти проектiв - прикладне ПЗ мають використовуватися в будь-якiй сферi дшль-ностi, галузi виробництва чи на окремих тдприемствах.
На рис. 1 наведено схему, яка шюструе шдхщ до визначення прийнятного рiвня ризику усшшного завер-шення (провалу) програмних проеклв IТ-компанiею за рiк. З рисунка видно, що при збшьшенш витрат на тд-вищення безпеки реалiзацií програмних проектiв вироб-ничi ризики (ризики неповноти вимог + технолопчш) зменшуються, але зростають так зваш професшно-поль тичнi ризики (ризики низько'1 квалiфiкацií персоналу + полггичш). Пiд час вирiшення проблем забезпечення та-ко*1 безпеки потрiбно виходити з того, що iснуе ризико-вий баланс мiж перевагами та недолжами запроваджен-ня вiдповiдних заходiв, тобто настае такий момент, коли переваги поступаються недолiкам (Maksimov & №-копоу, 2004).
V 1,1 Г 1,ЗГ 1,5Г 1,7С 2,0 К 2,3К 2,1 V 3,1 К 3,5К 4,1V 4,6К 5,4К Витрати на безпеку реал1защ програного проекту, ум. од.
Рис. 1. Визначення прийнятного (допустимого) ризику
Отже, проблема прогнозування ризику виникнення потенцшних небезпек 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рнiсть того, що деякий ризик стане несприятли-вою подiею, яка за сво*1м впливом на подальший хiд ре-алiзацií програмного проекту перетвориться в проблему, яку керiвнику проекта доведеться виршити чи Ьно-рувати. Тут, зазвичай, застосовують конкретну юльюс-ну шкалу, пов'язану з числовими значеннями, позаяк йдеться про реальш збитки вщ прояву то'! чи шшо'! нес-приятливо'1 поди, а також збшьшення, як насл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 глобальних заходiв. Завдання керiвника проекта поля-гае в тому, щоб з множини можливих заходiв вибрати такi iз них, яю дадуть змогу зменшити ймовiрнiсть виникнення несприятливих подш або пом'якшити нега-тивнi наслiдки вiд Кхнього прояву. При цьому бажано, щоб витрати ресурсiв на 'ххню локалiзацiю та лiквiдацiю у межах уЫе! системи управлiння проектами були мшь мальними (Netyksha, 2004).
При обранш певного напряму боротьби з ризиками тд час управлiння програмними проектами (табл. 1) ке-рiвнику проекта потрiбно прийняти до уваги той факт, що наслдаи прояву несприятливих подш i запровадже-них заходiв для 'ххнього уникнення, перенаправлення чи пом'якшення для одного з програмних проеклв можуть
значною мiрою вплинути на хiд реатзацп iнших прог-рамних проектiв як безпосередньо, так i опосередкова-но. Це особливо важливо при розглядi комплексних програмних проектiв, пов'язаних спшьними ресурсами
- персоналом, матерiальними чи фшансовими, !хшми замовниками та iнвесторами, що е основою процесу уп-равлiння програмними проектами (Zyl, 2010).
Табл. 1. Осипли напрями боротьби з ризиками реа. изаци програмних проекпи
Напрями боротьби з ризиками Вар1анти заход1в Рiвень загрози ризику
Пом'якшення Зменшення ймов1рност1 виникнення потенцшних ризиюв та (або) величини можливих втрат в1д настання несприятливих подш, що сприяе мшшзаци р1вня впливу ризиюв на хщ реал1зацп етатв програмного проекту. При цьому джерело ризику не усувають. Виправданий ризик
Прийняття Пгдтвердження можливост настання несприятливих подш, свщоме ршення прийняти !х наслщки \ компенсувати збитки за рахунок власних кошпв. При цьому робляться спроби завчасного виявлення потенцшних ризиюв \ усунення !х. Прийнятний ризик
Ухилення Повне усунення потенцшних небезпек або джерела ризику через вилучення можливост настання несприятливих подш. Неприпустимий ризик
Передача Перенесення в1дповвдальност1 за настання несприятливих подш на 1нших учасниюв проекту (наприклад, страховш компанп) без усунення джерела ризику. Виправданий ризик
Отже, управлiння ризиками - багатоетапний процес, який мае на мет! зменшити або компенсувати втрати для 1Т-компанн при настаннi несприятливих подш (DeMarko & Lister, 2005). При цьому основнi принципи процесу управлiння ризиками е такими:
• принцип максим1зацп - прагнення до найширшого аналiзу можливих причин i обставин виникнення ризику, тобто на зведенш чиннишв випадковостi, невизначеност та неповно-ти шформаци до мшмуму;
• принцип мтм1зацп - намагання звести до мiнiмуму перелж можливих ризикiв, а також зменшити стутнь впливу ризи-кiв на свою повсякденну дiяльнiсть;
• принцип адекватностi реакци - необхдао адекватно й швидко реагувати на змши вимог до ПЗ, яю можуть приз-вести до появи ризишв реатзаци програмного проекту;
• принцип прийнятностi ризику - деякий компромю мiж рiв-нем безпеки i можливостями його досягнення, тобто можна прийняти тшьки обгрунтований ризик.
Оскшьки управлiння ризиками реалiзацi! програмного проекту е складовою управлiння процесом розроб-лення ПЗ, то багато науковщв i практиков вважають (Fatrell, Shafer & Shafer, 2003; Kuzminykh, Khaustov & Korostelov, 2010), що таке управлiння схоже до управ-лiння виробництвом, яке може здшснити хто-небудь з навиками i практикою управлiння, але без знання особ-ливостей програмування. Джон С. Рейнольдс у сво!й робо-ri (Reynolds, 1998) дещо спростовуе цю точку зору i стверджуе, що управлiння процесом розроблення ПЗ дшсно е повнiстю творчою роботою, при цьому вш по-рiвнюе менеджерiв проектiв, як не вмтоть програмува-ти, з редакторами газет, як не вмiють писати.
Загалом, процес управлiння ризиком реалiзащ! програмного проекту можна подати у виглядi блок-схеми, наведено! на рис. 2.
Рис. 2. Узагальнена блок-схема процесу управлiння ризиком
Для оргашзацп процесу управлшня ризиками KepiB-нику проекта нeобхiдно, пepeдусiм, навчитись прогно-зувати причини виникнення тих чи шших потeнцiйних проблем, появи негативних ситуацiй чи несприятливих подш. Шд прогнозом потpiбно pозумiти науково обгрунтоване судження про можливi стани процесу управлшня в майбутньому, про альтернативт траекторп упpавлiння й термши його виконання. Прогнозування управлшських piшeнь найтiснiшe пов'язане 3i стратепч-ним i тактичним плануванням ризиюв peалiзацiï програмних проекпв.
2. Завдання управлшня ризиками реалiзацiï програмних проеклв
Найголовнiшe завдання в управлшт ризиками ре-алiзацiï програмних проекпв е передбачення кepiвниц-твом IT-компанп появи негативних ситуацiй чи несприятливих подш, яю вимагають попepeдньоï пiдготовки персоналу до ïхнього настання (Gultiaev, 2008). Таку пiдготовку потpiбно вiдобpажати в розроблених заходах реагування на вiдповiднi подiï ще до початку виникнення потенцшних проблем у межах вае1' системи управлшня програмними проектами. Пepeлiк шсл1дюв прояву несприятливих nodiü, що вимагають розроблен-ня заходiв реагування на них, доцшьно документувати у паспорт! проекту як первинному документ!. що опи-
суе основнi дiï його peалiзацiï, та потpiбно використо-вувати в мipу виявлення цих подш, ix iдeнтифiкацiï та груповому аналiзу.
Водночас, пiдготовка заxодiв реагування на потен-цшт проблеми зводиться до визначення певного набору дш, яю потpiбно зробити для того, щоб тдсилити пози-тивнi результати прояву ризикових nodiü i послабити не-гативш ïx наслiдки. Сукупнiсть таких заxодiв реагування е основою процесу упpавлiння ризиками peалiзацiï програмних проекпв. У паспоpтi проекту, окpiм захода реагування на нeспpиятливi та pизиковi подп, також до-цшьно передбачати вiдповiдальниx осiб для ïx ввдсте-ження, виявлення, локалiзацiï та лiквiдацiï, тepмiни виконання та перюдичшсть ïx монiтоpингу (Kulikova, 2008).
Можливi ризики peалiзацiï програмних проекпв ма-ють досить розвинуту iеpаpxiчну структуру (рис. 3), яка показуе, що бшьшють iз них можна пею чи iншою мi-рою врахувати ще на початкових етапах розроблення ПЗ (Grytsiuk, Grytsiuk & Gryciuk, 2017). Метою попе-реднього планування ризиюв е ретельне ощнювання впливу прояву несприятливих i ризикових подш на динам^ тepмiнiв i ваpтостi peалiзацiï програмних проек-тiв. Тому кepiвництво IT-компани мае постiйно прово-дити аналiз можливих ризик1в i враховувати ïx пiд час прогнозування показниюв peалiзацiï програмних проектов.
Рис. 3. Структура ризикв peалiзацiï програмних проеклв i джерела ïxньоï появи
На остаточш тepмiни та ваpтiсть виконання завдань програмних проеклв впливають таю категори ризиюв ïx peалiзацiï (Mykhailovska, 2008):
• ризики перевищення витрат - збшьшення передбачежй к1лькост1 завдань проекту та ^хто^ ваpтостi, потреба виконання додаткових завдань проекту;
• ризики затримок виконання завдань проекту - збшьшення тривалосл виконання завдань проекту чи перенесення термшв ïx пepeдачi замовнику;
• ризики несвoeчаснoстi постачання апаратних засoбiв i програмних мoдулiв - збшьшення чи перенесення термшв виконання завдань проекту через ввдсутшсть шструмен-тальних засобтв чи програмних модултв в1д подрядников;
• ризики затримок nлатежiв вiд iнвестoрiв проекту чи його кредитoрiв - вщкладання початку чи продовження термшв виконання завдань проекту через ввдсуттсть фiнансування. На термши та варпсть peалiзацiï програмного проекту також можуть впливати ризики, яю належать до
майбутшх умов (наприклад, фшансових) або обставин (природних чи соц1ально-пол1тичних), що знаходяться за межами контролю кер1вництва IT-компанií тд час виконання вiдповiдних завдань. Хоча виникнення цих ризиюв зовйм не обов'язкове, але íхнiй прояв на будь-якому етапi може негативно вплинути на подальшi ета-пи реалiзацií програмного проекту. Поява ознак настання несприятливих подш як передбачених, так i врахова-них попередньо при складанш планiв виконання зав-дань проекту, е безумовним сигналом до аналiзу íхньо-го можливого впливу на поточний стан процесу розроб-лення ПЗ та до запровадження заходiв з компенсацп íх-нiх негативних наслiдкiв.
Часта поява несприятливих подш е потенцшними проблеми реалiзацií проекту, позаяк вони виникають у найбiльш неочiкуваний момент. Хоча не ва проблеми можна заздалепдь передбачати чи навiть уникнути, але багато з них можна пом'якшити чи передати, i це дае
можливють керiвництву IT-KOMnaHiï здiйснювати вщпо-вщне управлiння ризиками. За вiдношенням до самого процесу розроблення ПЗ потенцшш проблеми peanÏ3a-цiï проекту подшяють на внутрiшнi та зовнiшнi. Внут-рiшнiми вважають тaкi несприятливi поди, на яю керiв-ник проекта чи його шдошчш здaтнi безпосередньо впливати. Зовтшт негaтивнi ситуaцiï не залежать нi вiд керiвництвa IT-компани, нi вiд групи упрaвлiння ними, але всi учасники проек^в мають бути обiзнaнi з ïx-нiми проявами, а також мають мати навики реагування на них i запроваджувати вщповщш заходи для усунення чи компенсаци негативних наслщюв.
Планування ризикiв реaлiзaцiï програмного проекту складаеться з таких кроюв: iдентифiкaцiï ризикiв; оць нювання ризиюв; розроблення зaxодiв реагування на ri ризики, якi цього вимагають.
1дентифкащя ризикiв (ознак настання несприятливих i ризикових подiй) полягае у визначенш тих ризикiв iз наявних множин, яю здaтнi вплинути на подaльшi етапи реaлiзaцiï програмного проекту та iншi проекти, пов'язaнi з ним у межах спшьних завдань чи виконува-них робiт. 1дентифжащя ризикiв - не разова дiя, вона мае проводитися протягом всього перюду реaлiзaцiï програмного проекту, тобто регулярно. Мета щентифь кaцiï ризиюв - скласти перелiк ризикових подш, зафж-сувати ознаки ïxньоï появи та негативш нaслiдки вiд прояву, здшснити пiдбiр зaxодiв з нaявноï множини для ïxньоï лiквiдaцiï чи компенсаци наслщюв.
Iдентифiкaцiю ризикових подш мають проводити вщповщальш особи групи управлшня проектами на пiдстaвi своïx знань i попереднього досвiду роботи. При цьому потрiбно визначати основш ризики, ймовiрнiсть ïxньоï появи та величини втрат вщ ïxнього прояву станом на момент ïxнього оцшювання.
Оцiнювaння ризикiв виконують з точки зору ïxнього впливу на подальший xiд реaлiзaцiï програмного проекту i на конкретш результати кожного з його етатв. Метою такого aнaлiзу е визначення тих ризикових подш, яю вимагають розроблення нових зaxодiв реагування на них, а яю - ш. Для того, щоб обгрунтовано виршувати тaкi завдання, потрiбно пов'язати кожну ризикову по-дiю з ймовiрнiстю ïxньоï появи. Значення ймовiрностi появи ризиюв i величину потенцшних втрат можна оць нити як деяю дискретш величини, якi визначають за-лежно вiд порушень термiнiв виконання завдань проекту на рiзниx етапах його реaлiзaцiï. Процедуру оцшювання ризикових подш потрiбно виконувати за допомо-гою якiсниx, юльюсних або комплексних покaзникiв.
3. Оцшювання ризиюв реал1зацн програмних проект1в
Для висв^лення цього питання зупинимося на таких показниках, як ймовiрностi появи ризиюв i величиш можливих втрат вщ ïx негативних нaслiдкiв (Kuz-minykh, Khaustov & Korostelov, 2010).
Ймовiрнiсть появи ризитв мае ввдображати сукупнi усереднет eiÔHOCHi порушення термШв виконання уЫх завдань проекту (у %), яю реaлiзуються на момент оць нювання впливу цих ризиюв. Цю ймовiрнiсть можна оцшити показником, який визначае вiдношення пору-шених термiнiв виконання завдань проекту до ïx запла-нованих термшв, де виявленi тaкi порушення, серед тих завдань проекту, що мають виконуватися на поточ-ний момент.
Для розумшня сут цього показника, розглянемо рис. 4, на якому введено таю позначення:
• п - кшьккть завдань проекта, що виконуються на момент ощнювання впливу ризишв;
• ГГп = {йп, I = 1, п} - дата початку виконання /-го завдання проекта на момент оцшювання впливу ризишв;
•Г)3 = {й3, \ = 1, п} - дата завершення виконання /-го завдання проекта на момент ощнювання впливу ризишв;
•Г)в = {йв, \ = 1, п} - дата внесення даних про стан виконання /-го завдання проекта на момент ощнювання впливу ризиюв;
•Г)о = {й°, \ = 1, п} - дата оцшювання впливу ризику на стан виконання /-го завдання проекта.
с!" $ с1? (Л1 б/',3
Дата, мюяць
Рис. 4. Визначення частки виконання завдання проекта за прогнозами плану його реал1зацл (1) та за фактичними даними на дату ощнювання впливу ризишв (2)
Вважатимемо, що до дати внесення даних (йв) на стан виконання /-го завдання не виявлено шякого впливу ризиюв, тобто, це завдання до ще! дати виконува-лось р1вном1рно за встановленим планом (див. рис. 4, пром1жок й* ^ йв). Тому частку виконання /-го завдання проекта на дату внесення даних про його стан можна визначити за такою формулою
^=/а-=^,/=-n
й] - < 1 ^ Водночас, прогнозовану за планом частку виконання /-го завдання проекта на дату оцшювання впливу ризиюв (див. рис. 4, пром1жок йв ^ йо), можна визначити за такою формулою
=/а; = ^, г=-n ЛУг d: -d:
(2)
Фактичну ж частку виконання /-го завдання проекта на дату оцшювання впливу ризикових подш, яка врахо-вуе негативш наслщки !х впливу, можна встановити тшьки експериментально, однак и значення не мае пе-ревищувати прогнозованого за планом, а саме
Ро ={ро: ро < ргп, i = Ш}. (3)
Тод1 усередненI вгдносш порушення термгмв виконання ус1х завдань проекту, яю реал1зуються на момент оцшювання впливу ризиюв, можна визначити за такою формулою
1 n
= 11 ( fi - pD.
nTÎ
(4)
Тепер, на пiдстaвi встановленого значення x можна оцiнити ймовiрнiсть появи ризикових подiй та 1'хнш вплив на стан виконання завдань проекту шляхом подь
лу як1сно1 шкали на п'ять р1вн1в, що досить детально в1-дображае р1зш можлив1 ситуацп тд час анал1зу цих подш. Приклад такого под1лу наведено в табл. 2, де визна-чено як яшсну, так 1 к1льк1сну шкали ощнювання ймо-в1рност1 появи ризикових подш за результатами ощню-вання шформацп про стан виконання завдань проекту.
Табл. 2. Оцiнювання ймовiрностi появи ризикових подiй
Имовiрнiсть появи ризикових Стан виконання завдань
подш (I), бали проекту (x), %
Слабо-ймовiрна 1 0 < х < 10
Малоймовiрна 2 10 < х < 30
Имовiрна 3 30 < х < 60
Вельми ймовiрна 4 60 < х < 90
Майже можлива 5 90 < х < 100
Проведемо ще деяк1 додатков1 розрахунки. З рис. 4 видно, що на дату завершения виконання /-го завдання проекта на момент ощнювання впливу ризишв з враху-ванням негативних 1х наслщшв, прогнозовану фактичну частку 1х виконання (р°) можна встановити, виходячи з таких м1ркувань.
п о 1 ю
Р1 - Р1 _1 - л
Осшльки
dO
di
, i = 1, n ,
ТОД1
P,О =
=1 - dH p - ро), г=1
(5)
(6)
Оск1льки
, i = 1, n ,
(7)
ТОД1
D" = / d'3 =
d■ . 1—, ' = 1,n
(8)
тобто прогнозована фактична дата завершення вико-нання 1-го завдання проекта буде дещо бшьшою в1д по-передньо заплановано1 дати.
Нижче спробуемо показати на реальному приклад1 мехашзм виконання вщповвдних розрахунк1в за наведе-ними вище формулами.
Величина можливих втрат в1д негативних наслщ-шв прояву ризикових подш мае вщображати загальне
ту загалом. Величину потенцшних втрат можна оцшити шляхом встановлення значення найбшьшого з можливих прояв1в ризикових подш на окрем1 завдання проекта з моменту ощнювання цього впливу, як загалом позначаються на остаточному термш виконання усього проекту.
Отже, усереднет eidnocni порушення величини можливих втрат (у %) на шдстав1 анал1зу результапв стану виконання завдань проекту на момент ощнювання впливу ризишв можна визначити за такою формулою
y = dp • max{(рп - p°) • d - df), i = Vn} . (9)
де dп = max{di3, i = 1,n} - mm{d", i = 1,n} - планова трива-лють реал1зацп усього проекту.
Тепер, на шдстав1 встановленого значення у можна оцшити величину можливих втрат (B) вщ негативних наслщшв прояву ризикових подш на стан виконання завдань проекту за даними табл. 3, де показано як шль-шсш, так i яшсш шкали ощнювання.
Табл. 3. Ощнювання величини можливих втрат ввд негативних наслвдюв прояву ризикових подiй
тобто прогнозована фактична частка виконання /-го завдання проекта буде дещо меншою (<100 %) в1д по-передньо заплановано1 частки.
Також з цього рисунку видно, що прогнозовану фактичну дату завершення виконання /-го завдання проекта (d'¡3) на момент ощнювання впливу ризишв з врахуван-ням негативних наслвдшв 1х впливу, можна встановити, виходячи з таких м1ркувань.
п
Р-_ —
Величина можливих втрат (В), бали Стан виконання завдань проекту (у), %
Мтмальна 1 0 < у < 10
Низька 2 10 < у < 30
Середня 3 30 < у < 60
Висока 4 60 < у < 90
Максимальна 5 90 < у < 100
Приклад. Спробуемо на реальному приклад1 проде-монструвати мехашзм виконання вщповвдних розра-хунк1в за наведеними вище показниками. В табл. 4 внесено даш про виконання п=10 завдань проекту на момент ощнювання впливу ризишв. Для спрощення розра-хуншв дати виконання завдань проекта показано по мь сяцях поточного року (до 12-го мюяця), а якщо значення становить бшьше 12, то щ дати стосуються мюящв наступного року. Вважатимемо, що дата внесення да-них про стан виконання /-го завдання проекта (d¡) мо-же бути р1зною (що цшком ймов1рно) 1 проводиться ближче до завершення поточного року. Водночас, дата ощнювання впливу ризику на стан виконання /-го завдання проекта (d°) е постшною, позаяк на цю дату пев-ною службою може бути встановлена деяка тдозра про настання несприятливих ситуацш Ус 1нш1 значення стовпщв табл. 4 визначено за наведеними вище формулами.
вiдносне порушення термiнiв виконання завдань проек-
Табл. 4. Розрахунок частки виконання завдань проекту (х) та величини можливих втрат (у) тсля потенцшного настання негативних наслздюв
Завдання dп di di di di - di в Pi п Pi о Pi п о Pi - Pi di - di Ау. to P' d'
1 5 10 15 20 5 0,3333 0,6667 0,6499 0,0168 5 0,0839 0,9776 20,46
2 4 12 15 16 8 0,6667 0,9167 0,7010 0,2157 1 0,2157 0,7699 20,78
3 9 10 15 23 1 0,0714 0,4286 0,3209 0,1077 8 0,8612 0,8349 27,55
4 6 11 15 19 5 0,3846 0,6923 0,5486 0,1437 4 0,5747 0,8180 23,23
5 2 12 15 17 10 0,6667 0,8667 0,7294 0,1373 2 0,2746 0,8444 20,13
6 4 10 15 16 6 0,5000 0,9167 0,7102 0,2065 1 0,2065 0,7797 20,52
7 9 11 15 20 2 0,1818 0,5455 0,3960 0,1495 5 0,7474 0,8007 24,98
8 3 10 15 16 7 0,5385 0,9231 0,8738 0,0493 1 0,0493 0,9474 16,89
9 5 13 15 22 8 0,4706 0,5882 0,4355 0,1527 7 1,0691 0,7760 28,35
10 7 10 15 21 3 0,2143 0,5714 0,5703 0,0011 6 0,0068 0,9984 21,03
min= 2 16 Z= 1,1802 Z= 1,0691 max= 28,35
max= 9 13 d"= 23 cf= 21 x= 11,80% y= 5,09% max/d^ 1,2326
де: Ay = (pi - р°) • (d': - d°), i = 1,n; d'п = max{di3, i = 1,n} - запланована дата завершення виконання завдань проекту.
З таблиц видно, що сукупш усереднеш вiдноснi порушення термiнiв виконання усix завдань проекту, якi заплановано реaлiзувaти на момент оцiнювaння впливу ризиюв, становитимуть х = 11,80 %. Це свщчить про те, що ймовiрнiсть появи ризику (I) оцшюватиметься в 2 бали (див. табл. 2), тобто буде мaлоймовiрною, а стан виконання завдань проекту (x) зменшиться не iстотно. Водночас, величина можливих втрат (B) ощнюватиметься в 1 бал (див. табл. 3), тобто буде мМмальною, а стан виконання завдань проекту (y) загалом попршить-ся в середньому на 5,09 %. О^м цього, прогнозована фактична частка виконання ( р'0 ) завдань проекту на
дату ïx завершення буде рiзною, тобто ш одне завдання не виконаеться вчасно. Аналопчно прогнозована фактична дата завершення кожного завдання проекта ( d'з )
також дещо збшьшиться, а максимальне ïï перевищення вщносно запланованоТ дати становитиме 28,35/23 - 1 = 0,2326 ^ 23,26 %.
4. Оц1нювання впливу ризикових подш на хщ реал1заци програмного проекту
Для ощнювання можливого впливу ризикових подш на хщ реaлiзaцiï програмного проекту потрiбно вико-ристати показник ризику, який дае змогу визначити величину можливих втрат (у балах) вщ настання негативних ситуацш (Netyksha, 2004). Також цей показник дае можливють комплексно оцшити заходи реагування на ризиковi поди* та рiвень 1хньо1 загрози загалом. Показ-ник ризику обчислюють за такою формулою
R = I • B, (10)
де: I = fi(x) - ймовiрнiсть появи ризикових подiй, вста-новлена за даними табл. 2 (у балах); В = f2(y) - величина можливих втрат, встановлена за даними табл. 3 (у балах); f1(), f2() - таблично-задаш функци, що визначають перехщ вiд значень оцiнок х та у, обчислених на пщста-вi даних про xiд реaлiзaцiï проекту, до щло-чисельних бальних оцiнок (табл. 5).
Табл. 5. Оцшювання величини показника ризику
вщ ймов1рност1 появи ризикових подш та величини
Ймовгршсть появи ризикових подш (I), бали Величина можливих втрат (B), бали
1 2 3 4 5
Слабо-ймов1рна 1 1 2 3 4 5
Малоймов1рна 2 2 4 6 8 10
Ймовгрна 3 3 6 9 12 15
Вельми ймов1рна 4 4 8 12 16 20
Майже можлива 5 5 10 16 20 25
Яюсш ощнки iдентифiковaниx ризикiв можна вира-зити через ймовiрнiсть появи цих подш (I) i величину можливих втрат (B), яю в сукупност характеризують ступiнь ïx впливу на подальший xiд реaлiзaцiï програмного проекту. Для цього використовують таку яюсну шкалу градаци, як високий, середнш i низький ступiнь впливу ризиюв. Однак на практищ важливо визначити юльюсне значення ступеня впливу кожного ризику, для чого використовують шкалу вщ 1 до 25 бaлiв. Водночас, показник ризику дае змогу оцшювати величини можливих втрат (в балах), яю визначають за допомогою матриц мЙмовiрнiсть-Втрaтим, що дае можливють ро-бити деяю висновки про вiдповiдну ступiнь впливу ризику та певш рiвнi 1хньо1 загрози (рис. 5).
Ймов1ршсть появи ризику
1. Слабо-ймов1рна
2. Малоймов^рна
3. Имов1рна
4. Вельми ймсдарна
5. Майже можлива
Матриця
"Имов1ршсть-Втрати"
5
5 10 15 20 25
4 8 12 16 20
3 6 9 12 15
2 4 6 8 10
1 2 3 4 5
Стуишь впливу ризиюв
- 1гнороваш (1 < R < 4) -Незначт (5<R<8)
- noMipHi (9 < R < 10)
- IcTOTHi (12 < R < 16)
- Критичш (20 < R < 25)
PieeHb загрози ризиюв
[] - Прийнятний (1 < R < 4) [] - Виправданий (5 < R < 10) [| - Неприпустимий (12 < R < 25)
1 2 3 4 5
Можливг втрати *
Величина втрат
1. Млшмальна
2. Низька
3. Середна
4. Висока
5. Максимальна
Рис. 5. Оцшювання щентифжованих ризикових подш на хщ ре-ал1зац11 програмного проекту (Netyksha, 2004)
Процедура оцшювання щентифжованих ризикiв реaлiзaцiï програмного проекту грунтуеться на ефектив-ностi запланованих зaxодiв реагування на ризиковi по-дй* за ступенем 1хнього впливу згiдно з поточним зна-ченням показника ризику (R). На пiдстaвi значення цього показника сaмi ризиковi подЙ клaсифiкують за ступенем 1хнього впливу на стан виконання завдань проекта i за рiвнем 1хньо1 загрози подальшим етапам реaлiзaцiï всього проекта.
Клaсифiкaцiя ризикових подш за ступенем 1хнього впливу на стан виконання завдань проекта мае такий вигляд:
• 1гнороваш ризики (1 < R < 4):
- мало вщчутний вплив на xiд реашзацп програмного проекту;
- незначне збтьшення тривaлостi виконання деяких завдань проекту;
• незначт ризики (5 < R < 8):
- збтьшення тривалосл виконання запланованих завдань проекту;
- потрiбно виконати деякi додaтковi завдання проекту в межах бюджету i запланованих термшв його завершення;
- присутш деяю програмш дефекти, яю у виконаних завдан-нях проекту можна швидко усунути;
- недотримання деяких функцюнальних вимог, яю не вимагають погоджень iз замовником;
- незначне зниження ефективносл виконання еташв проекту, якi допустимi для замовника;
• пом1рн1 ризики (9 < R < 10):
- збтьшення тривалосп виконання багатьох завдань проекту;
- потрiбно виконати багато додаткових завдань проекту поза межами його бюджету i запланованих термтв завершення;
- присутш багато програмних дефеклв, усунення яких у виконаних завданнях проекту вимагають додаткових зусиль його виконавщв;
- недотримання багатьох проектних ршень, особливо функць ональних вимог, яю вимагають деяких погоджень iз замов-ником;
- значне зниження ефективносл виконання еташв проекту, яю вимагають деяких погоджень iз замовником;
• 1стотш ризики (12 < R < 16):
- значне збтьшення тривалосл виконання бтьшосл завдань проекту;
- потрiбно виконати значну ктьюсть додаткових завдань проекту поза межами його бюджету i запланованих термтв за-вершення;
- присутня значна ктьюсть програмних дефеклв, усунення яких у виконаних завданнях проекту вимагають додатково-го фшансування;
- недотримання бтьшосл проектних ршень, особливо функцюнальних вимог, яю вимагають обов'язкового погоджен-ня iз замовником;
- загальне зниження ефективностi виконання еташв проекту, яю вимагають погоджень iз замовником;
- припинення реaлiзaцiï програмного проекту через можливють втрати знaчноï частки прибуток;
• критичт ризики (20 < R < 25):
- припинення реатзаци програмного проекту через можли-BicTb втрати всього прибутку;
- припинення реалiзацiï програмного проекту через можли-вiсть втрати частки майна компани.
Класифiкацiя ризикових подш за р1внем 1хньо1 заг-рози подальшим етапам реал1зацл всього проекта мае такий вигляд:
• прийнятний ризик (1 < R < 4):
- розглядаеться до прийняття проектних ршень, в т.ч. вимог до ПЗ;
- рiвень загрози ризику мае перюдично переоцiнюватися ке-рiвником проекту;
• виправданий ризик (5 < R < 10):
- визначаеться як вторинний для оброблення та аналiзу;
- ризик мае мати певну стратепю його оброблення, аналiзу та реагування;
- ризик потрiбно обробляти доти, доки рiвень його загрози не знизиться до прийнятного;
- ризик мае знаходитися тд постшним контролем керiвника проекта;
- рiвень загрози ризику мае постшно переоцiнюватися керiв-ником проекту;
• неприпустимий ризик (12 < R < 25):
- ризик визначаеться як первинний для оброблення, анатзу та реагування;
- ризик мае мати певну стратепю його оброблення, анал1зу, реагування та мониторингу;
- ризик потр1бно наполегливо 1 без зупинки обробляти доти, доки р1вень його загрози не знизиться до виправданого;
- ризик мае знаходитися шд постшним 1 безпосередшм контролем кер1вника проекта;
- р1вень загрози ризику мае систематично переоцшюватися кер1вником проекту.
Залежно в1д отриманого значення показника ризику (Л) для кожно1 з можливих ризикових подш потр1бно встановити стутнь 11 впливу на подальший х1д реал1за-цл програмного проекту залежно в1д категорп ризику та визначити заплановаш заходи реагування на них. В обгрунтованих випадках визначен тривалост та вар-тост! виконання завдань проекту можуть бути скорего-ван на величину очшуваних результатгв, пов'язаних з цими завданнями.
Залежно в1д р1вня загрози ризишв визначають сшиб 1х оброблення: прийняття, пом'якшення, ухилення або передача (табл. 1). Виходячи з цього, а також з вра-хування даних, наведених у робот! (Netyksha, 2004), розроблено алгоритм визначення того чи шшого способу оброблення ризишв (рис. 6).
Рис. 6. Квт загроз ризишв та способи 1х оброблення
Розроблений вище тдх1д до ощнювання ступеню впливу ризишв на остаточн результати реал1зацл програмного проекту дае змогу достатньо просто реал1зува-ти його як надбудову до деякого стандартного ПЗ. При цьому з'являеться можливють оперативно ощнювати стутнь впливу ризишв за вс1ма проектами, що викону-ються на поточний момент анал1зу 1хнього стану реаль заци. Це вкрай важливо при анал1з1 етатв розроблення ПЗ загалом, бо дае можливють 1хшм менеджерам 1 ви-щому кер1вництву (з роллю 1нвестор1в програмних про-екпв) оперативно виявляти серед них ризиков1 проекти та зосереджувати свою увагу на тих проектах, що пот-ребують негайного втручання та особистого впливу, 1 не турбуватися про т 1з них, що виконуються в рамках дозволених в1дхилень.
Використання заироионовано1 системи ощнювання ризишв тд час управл1ння програмними проектами з використанням програмних засоб1в анал1зу за наведе-
ним вище алгоритмом дае змогу як менеджерам програмних проектгв, так i вищому кер1вництву 1Т-компанп ощнювати стан процесу розроблення ПЗ i виявляти серед них найбшьш критичт з тим, щоб найскорше зап-ровадити заходи для усунення можливих негативних наслвдшв прояву ризишв.
Висновки
Запропоновано тдхвд до управл1ння ризиками ре-ал1зацп програмних проекпв, на тдстав1 якого встанов-лено особливост шльшсного отнювання впливу ризикових подш на стан процесу розроблення ПЗ, що дало змогу визначити величину можливих втрат ввд настання негативних ситуацш. За результатами досл1дження можна зробити так основн висновки:
1. Охарактеризовано таш поняття, як управл1ння програмними проектами та ризиками 1х реал1зацп, що дало змогу визначити компонента такого управл1ння,
основш категорп ризик1в, ризик-орieнтовний пiдхiд до процесу управлiння, а також уможливило визначення прийнятного рiвня ризику устшного завершения (провалу) програмних проекпв IТ-компанieю. Встановлено, що при збшьшенш витрат на пiдвищення безпеки реаль зацп програмних проектiв так зваш виробничi ризики (ризики неповноти вимог + технолопчш) зменшуються, але зростають професiйно-полiтичнi ризики (ризики низько! квал!ф!кацп персоналу + полiтичнi). Вирiшення проблеми забезпечення тако! безпеки зводиться до того, що юнуе ризиковий баланс мiж перевагами та недо-лiками запровадження вщповщних заходiв реагування на настання негативних ситуацiй.
2. З'ясовано основнi завдання процесу управлiння ризиками реал!зацп програмних проектiв, розроблено ввдповвдт рекомендаций як1 дають змогу керiвництву ГГ-компани передбачити появу негативних ситуацш i, як наслiдок, подальших потенцiйних проблем, що ви-магатиме вiд них попередньо! пiдготовки персоналу до !хнього настання. Виявлено, що тдготовка заходiв реагування на потенцшш проблеми зводиться до визначення певного набору дш, як потрiбно зробити для того, щоб пiдсилити позитивнi результати прояву ризико-вих подiй i послабити негативш !х наслiдки.
3. Розроблено методику ощнювання ризик1в реал!за-ци програмних проектiв, яка дае змогу встановити по-рушення термшв виконання завдань проекту вiдносно !х запланованих термiнiв, де виявленi так! порушення, серед тих завдань проекту, що мають виконуватися на поточний момент. При цьому величину потенцшних втрат можна ощнити шляхом встановлення значення найбiльшого з можливих прояв!в ризикових подш на окремi завдання проекта з моменту ощнювання цього впливу, яш загалом позначаються на остаточному тер-мш виконання усього проекту.
4. Встановлено особливосп оцiнювання впливу ризикових подш на хвд реал!заци програмного проекту, що дало змогу розробити методику визначення величи-ни можливих втрат вщ настання негативних ситуацiй. При цьому процедура ощнювання щентифшованих ри-зишв реал!заци програмного проекту грунтуеться на ефективносп запланованих заходiв реагування на ризи-ков! поди за ступенем !хнього впливу зпдно з поточним значенням показника ризику.
Перелiк використаних джерел
Artamonov, A. A. (2003). Funkcii Upravlenija riskami v processe re-alizacii investicionnyh stroitelnyh proektov. Abstract of doctoral dissertation for economic Sciences. Sankt-Peterburg, 20 p. [In Russian].
Borisov, A. N., Krumberg, O. A., & Fedorov, I. P. (1990). Priniatie reshenii na osnove nechetkikh modelei: primery ispolzovaniia. Riga: Izd-vo "Zinatne". 184 p. [In Russian]. Braude, E. Dzh. (2004). Tekhnologiia razrabotki programmnogo obespecheniia. Sankt-Petersburg: Izd-vo "Piter". 655 p. [In Russian].
DeMarko, T., & Lister, T. (2005). Valsiruia s medvediami: upravlenie riskami v proektakh po razrabotke programmnogo obespecheniia. Moscow: Izd-vo "Kompaniia p.m. Office". 190 p. [In Russian]. DoD. USA. (2014). Department of Defense Risk, Management Guide for Defense Acquisition Programs. 7th Edition (Interim Release) December 2014. Office of the Deputy Assistant Secretary of Defense for Systems Engineering, (pp. 6-11). Washington, D.C. Retrieved from: http://acqnotes.com/wp-content/uploads/2014/09/DoD-Risk-Mgt-Guide-v7-interim-Dec2014.pdf
Fatrell, R. T., Shafer, D. F., & Shafer, L. I. (2003). Upravlenie prog-rammnymi proektami: dostizhenie optimalnogo kachestva pri minimume zatrat: per. s angl. Moscow: Izd. dom "Viliams". 1136 p. [In Russian].
Grytsiuk, M. Yu., Grytsiuk, P. Yu., & Gryciuk, Yu. I. (2017). The risks analysis in projects management of sustainable tourism development in the Carpathian region of Ukraine. In L. Karczewski, H. A. Kretek (red.). Kulturowe, spoleczne, prawne i etyczne aspekty zarzadzania gospodarka i biznesem. Chapter: Multidisciplinar)/ determinants of business and management, (pp. 215-229). Raciborz: Wydawnictwo Panstwowej Wyzszej Szkoly Zawodowej w Reci-borzu. 318 p.
Gultiaev, A. K. (2008). Microsoft Office Project Professional 2007. Upravlenie proektami: prakticheskoe posobie. Sankt-Peterburg: KORONA-Vek, 480 s. [In Russian].
Heckerman, D. (1995). A Tutorial on Learning With Bayesian Networks. Microsoft Research. Technical Report. 124 p.
Hugin Expert. (n.d.). Система для построения Байесовых систем. Retrieved from: http://www.hugin.com. [In Russian].
ISO/IEC 12207:2008. Systems and software engineering - Software life cycle processes
ISO/IEC 33001:2015. Information technology - Process assessment
Ivanko, S. (2008). Vnedrenie avtomatizirovannoi sistemy upravleniia organizatciiami. Korporativnye sistemy, 1, 20-25. [In Russian].
Johnson, D. L., & Tennessee, N. (2006). Risk Management and the Small Software 1. Project.
Kastellani, K. (1982). Avtomatizatciia resheniia zadach upravleniia. Moscow. 472 p. [In Russian].
Kovalev, V. (n.d.). Problemy vnedreniia korporativnykh sistem. Retrieved from: http://www.infocity.kiev.ua/other/content/ot-her061. phtml. [In Russian].
Kulikova, E. E. (2008). Upravlenie riskami. Innovatcionnyi aspekt. Moscow: Izd-vo "Berator-pablishing". 224 p. [In Russian].
Kuzminykh, V. O., Khaustov, D. V., & Korostelov, Ye. Yu. (2010). Analiz ryzykiv u korporatyvnii systemi upravlinnia proektamy. Reiestratsiia, zberihannia i obrobka danykh, 12(3), 99-107. [In Ukrainian].
Leonenkov, A. (2003). Nechetkoe modelirovanie v srede MATLAB i fuzzyTech. Sankt-Petersburg: Izd-vo "BKhV-Peterburg". 736 p. [In Russian].
Lipaev, V. V. (2005). Analiz i sokrashhenie riskov proektov slozhnykh programmnykh sredstv. Moscow: Izd-vo "Sinteg". 208 p. [In Russian].
Maksimov, V. I., & Nikonov, O. I. (2004). Modelirovanie riska i ris-kovykh situatcii : uchebn. posob. Ekaterinburg : Izd-vo GOU VPO UGTU - UPI. 82 p. [In Russian].
Mamedova, T. A. (2005). Model risk-menedzhmenta v INTERNET-kompanii. Retrieved from: http://masters.donntu.org/2005/fvti/ma-medova/library/doc_2.htm. [In Russian].
Mikhailik, O. (2008). Vnedrenie sistemy "Galaktika ERP". Korporativnye sistemy, 3, 53-55. [In Russian].
Mykhailovska, O. V. (2008). Operatsiinyi menedzhment: navch. po-sibnyk. Kyiv: Konkord. 550 p. [In Ukrainian].
Netyksha, Oksana. (2004). Upravlenie riskami. Finansovyj direktor, 10. Retrieved from: http://www.management.com.ua/finan-ce/fin097.html. [In Russian].
Reshke, Kh., & Shelle, Kh. (Eds.) (1994). Mir upravleniia proektami: osnovy, metody, organizatciia, primenenie: sbornik. Posviashhaet-sia iubileiu R. V. Gutcha. (Trans. from English). Moskva: Alans. 303 p. [In Russian].
Reynolds, John C. (1998). Theories of Programming Languages. Cambridge University Press. 650 p.
Shkvir, V. D., Zahorodnii, A. H., & Vysochan, O. S. (2007). Informat-siini systemy i tekhnolohii v obliku (3d ed.). Kyiv: Znannia. 439 p. [In Ukrainian].
Singaevskaia, G. I. (2008). Upravlenie proektami v Microsoft Project. Moscow: Dialektika, 800 s. [In Russian].
Sobol, I. M. (1972). Metod Monte-Karlo. Moscow: Izd-vo "Nauka". 68 p. [In Russian].
Sommervill, I. (2002). Inzheneriia programmnogo obespecheniia. Sankt-Petersburg: Izd. dom "Viliams". 624 p. [In Russian].
SWEBOK. (2004). Guide to the Software Engineering Body of Williams, R. C., Pandelios, G. J., & Behrens, S. G. (1999). Software
Knowledge. A project of the IEEE Computer Society Professional Risk Evaluation (SRE) Method Description.
Practices Committee. Washington IEEE. 204 p. Zyl, S. (2010). Proektirovanie, razrabotka i analiz programnogo obes-
Terekhov, S. A. (2003). Vvedenie v baiesovy seti. Moscow: Izd-vo MI- pecheniia sistem realnogo vremeni. Sankt-Petersburg: Izd-vo
FI. 188 p. [In Russian]. "BKhV-Peterburg". 336 p. [In Russian].
Ю. И. Грыцюк, М. Р. Жабич
Национальный университет "Львовская политехника", г. Львов, Украина
УПРАВЛЕНИЕ РИСКАМИ РЕАЛИЗАЦИИ ПРОГРАММНЫХ ПРОЕКТОВ
Предложен подход к управлению рисками реализации программных проектов, на основании которого установлены особенности оценки рисковых событий на состояние процесса разработки программного обеспечения (ПО), что позволило определить размер возможных потерь от наступления негативных ситуаций. Охарактеризованы такие понятия, как управление программными проектами и рисками их реализации, что позволило определить компоненты такого управления, основные категории рисков, риск-ориентированный подход к процессу управления, а также определено приемлемый уровень риска успешного завершения (провала) программных проектов IT-компанией. Установлено, что при увеличении затрат на повышение безопасности реализации программных проектов так называемые производственные риски уменьшаются, при этом растут профессионально-политические риски. Выявлено, что подготовка эффективных мер реагирования на потенциальные проблемы сводится к разработке определенного набора действий, которые нужно использовать для усиления положительных результатов проявления рисковых событий и ослабить негативные их последствия.
Разработана методика оценки рисков реализации программных проектов, позволяющая установить нарушение сроков выполнения задач проекта относительно запланированных сроков, где обнаружены такие нарушения, среди тех проектов, что должны выполняться на текущий момент. При этом размер потенциальных потерь можно оценить путем определения значения наибольшего из возможных проявлений рисковых событий на отдельные задачи проекта с момента оценки этого влияния, которые в целом сказываются на конечном сроке выполнения всего проекта. Установлены особенности оценки влияния рисковых событий на ход реализации программного проекта, что позволило разработать методику определения величины возможных потерь от наступления негативных ситуаций. При этом процедура оценки идентифицированных рисков реализации программного проекта базируется на эффективности запланированных мер реагирования на рисковые события по степени их влияния согласно текущего значения показателя риска.
Ключевые слова: программное обеспечение; рисковые события; негативные последствия; потенциальные проблемы; вероятность наступления неблагоприятных событий; приемлемый риск; риск возникновения потенциальных опасностей.
Yu. I. Hrytsiuk, M. R. Zhabych
Lviv Polytechnic National University, Lviv, Ukraine
RISK MANAGEMENT OF IMPLEMENTATION OF PROGRAM PROJECTS
An approach to the implementation of risk management software projects, on the basis of which the specific features of the evaluation of risk events on the state of the software development process, which allowed to determine the size of potential losses from the occurrence of negative situations. Characterized by terms such as software project management and risk their realization, allowing to determine the components of such a control, the main categories of risks, risk-based approach to the management process, as well as the defined acceptable level of risk the successful completion (failure) software project IT-company. It was found that an increase in the cost of improving the safety of the implementation of software projects so-called operational risks reduced, while increasing professional and political risks. Clarified the main tasks of the risk management process, the implementation of software projects, to develop appropriate recommendations to management of IT-companies to predict the appearance of negative situations and, as a consequence, further potential problems that require advance preparation guide staff prior to their occurrence. It was revealed that the preparation of an effective response to potential problems is to develop a specific set of actions that should be used to enhance the positive results of manifestation of risk events and mitigate their negative effects.
The technique of risk assessment implementation of a software project, allowing a violation of the terms of the project objectives with respect to the planned terms, where such violations are found, among the projects that must be carried out at the moment. The size of the potential losses can be estimated by determining the maximum value of the possible manifestations of risk events into individual tasks of the project since the evaluation of this effect, which generally affect the long term performance of the project. The features of assessing the impact of risk events on the progress of a software project, which allowed to develop a method for determining the magnitude of potential losses from the occurrence of negative situations.
Keywords: software; risk events; negative consequences; potential problems; the probability of occurrence of adverse events; acceptable risk; the risk of potential hazards.
