CC BY
44
p-ISSN 1607-3274. Рaдiоeлeктpонiкa, iнфоpмaтикa, yпpaвлiння. 2017. № 4 e-ISSN 2313-688X. Radio Electronics, Computer Science, Control. 2017. № 4
УДК 006.015.5
Гусева Ю. Ю.1, Мартиненко О. С.2, Кадикова I. М.3, Чумаченко I. В.4
1Канд. техн. наук, доцент, доцент кафедри управлння проектами в мському aoonodapomei i 6ydieHuumei, Харквський
нацональний унверситет мськоао аосподарства iменi О. М. Бекетова, Харкв, Украна 2Аспрант кафедри управлшня проектами в мському aосподарствi i бyдiвництвi, Харквський нацональний унверситет
мськоао аосподарства iменi О. М. Бекетова, Харюв, Украна 3Канд. екон. наук, доцент, доцент кафедри управлння проектами в мському aосподарствi i бyдiвництвi, Харквський
нацональний унверситет мськоао аосподарства iменi О. М. Бекетова, Харкв, Украна 4Д-р. техн. наук, професор, завдувач кафедри управлшня проектами в мському aосподарствi i бyдiвництвi, Харквський
нацональний унверситет мськоао аосподарства iменi О. М. Бекетова, Харкв, Украна
МЕТРИКИ ПРОЦЕС1В УПРАВЛ1ННЯ ТА КОНТРОЛЮ ВИМОГ _У ПРОЕКТАХ_
Актуальтсть. Процеси управлшня вимогами е одним з ключових чиннигав ycnixy або невдачi проекту. Дослщження у галузi проектного менеджменту вказують, що саме щ процеси е недостатньо формалiзованими. Отже, е необхщшсть розробки та формалiзащl метсдов управлшня i контролю вимог, зокрема, для проек^в, управлшня яких здшснюеться за традицшними або комбшованими методолопями.
Мета роботи - формалiзацiя метрик процеав управлшня вимогами у проектах. Об'ектом дослщження е процеси управлшня та контролю вимог у проектах, предметом дослщження - метрики, як характеризуюсь вимоги у проекта
Метод. Використано методи аналiзy та синтезу, методи нечггких множин та операци над матрицями. Запропоновано використання модели яка встановлюе зв'язки мiж окремими характеристиками проекту (ризики, роботи, ресурси, вимоги, стейкхолдери та вщповщальш особи проекту) за допомогою iерархiчноl структури робгг. Запропоновано формалiзацiю метрик модел^ що дозволить вщстежувати динамжу виконання проекту та iдентифiкyвати защкавлеш сторони проекту за визначеними напрямами.
Результати. На основi спiвставлення iерархiчноl структури робiт з iерархiчними структурами вимог, ризиюв, ресyрсiв та оргашзацшною структурою проекту розроблено метод формалiзацil метрик yправлiння вимогами проекту. Запропонований метод дозволяе вщстежувати виконання вимог защкавлених сторш проекту у чаш у вщповщност до обсягу фактично витрачених ресуршв по аналоги з методом освоеного обсягу. Адаптившсть методу до традицшних процесiв менеджменту проекив дае змогу використовувати вихiднi дан - вже сформованi активи проекту та стандартне програмне забезпечення (зокрема, MS Project, Open-Proj) для практично! реалiзацil методу.
Висновки. Запропонований метод формалiзyе процеси yправлiння вимогами у проекту дозволяе визначати ресурсне та ризикове навантаження вимог, що доповнюе юнуючи моделi класифжаци вимог даними метриками. Метод формалiзацil метрик управлшня вимогами проекту дозволяе також отримати шструменти для ощнювання ефективност команди проекту та класифжаци защкавлених сторш проекту. Проведет експерименти пщтвердили працездатнiсть запропонованого математичного забезпечення i дозволяють рекомендувати його використання на практищ при прийняттi проектних ршень щодо yправлiння змiнами та вимогами стейкхолдерiв проекту. Перспективи подальших дослщжень можуть полягати у розробцi програмного забезпечення, що реалiзyе запропонований метод.
Ключовi слова: управлшня вимогами, проект, метрика, ресурси, стейкхолдери, ризики.
НОМЕНКЛАТУРА
PMI - Project Management Institute;
WBS - Work Breakdown Structure (iepapxiчнa етрук-typa робгт проекту);
F - функщя, що опиcye взaeмозв'язок м1ж двомa еле-мeнтaми модел1 у читай формц
Mi,i-1 - мaтpиця взaeмозв'язкiв робгт р1вшв i тa i-1 iepapxiчноï етруктури робгт проекту;
Recourse^ - мaтpиця розподшу рееурив зa i-м р1внем iepapxiчноï етруктури робгт проекту;
recoursek - k-й pecypc проекту;
R(esource)BS - iepapxiчнa cтpyктypa рееуре1в проекту;
Requirementi - мaтpиця розподшу вимог зa i-м р1внем iepapxiчноï етруктури робгг проекту;
requirementi - l^a вимогa проекту;
R(equirement)BS - iepapxiчнa cтpyктypa вимог проекту;
Responsibilityi - мaтpиця розподшу вiдповiдaльниx ое1б зa i-м р1внем iepapxiчноï етруктури робгт проекту;
responsibilityz - z-тa вiдповiдaльнa оcобa проекту;
R(esponsibility)BS - оpгaнiзaцiйнa cтpyктypa проекту;
Riskj - матриця розподiлу ризикiв за i-м piBHeM iepap-xi4Hor структури po6iT проекту;
riskv - v-й ризик проекту;
R(isk)BS - iерархiчна структура ризиюв проекту;
RRec - матриця взаемозв'язку вимог i ресуршв, не-обхщних для гх виконання;
RRes - матриця взаемозв'язку вимог i ошб, вщповь дальних за гх виконання;
RRis - матриця взаемозв'язку вимог i ризиюв, що ви-никають при гх виконаннi;
S - матриця розподшу вимог мiж стейкходерами проекту;
stakeholde ru - u-й стейкхолдер проекту;
wi,j - j-та робота i-го рiвня iерархiчноr структури робгг проекту;
Ф - функщя, що описуе взаемозв'язок мГж двома еле-ментами моделi у нечпгай форм^
ВСТУП
Управлiння вимогами на сьогодш е одним з ключових процеив для досягнення устшних результатiв про-ектiв та програм. Дослiдження у галузi проектного уп-
© ryceßa Ю. Ю., Mapтинeнко О. С., Кaдиковa I. М., Чyмaчeнко I. В., 2017 DOI 10.15588/1607-3274-2017-4-20
равлiння Project Management Institute [1, 2] за останш роки вказують, що проблеми у po6oTÍ з вимогами по-сiдають друге-трете мiсце серед чинниюв, якi виклика-ють провали проектав. Доля респондентiв, яка вказуе саме таку причину невдачi проекту стабшьно складае 37-38%. До того ж вщповщно [3] лише 49% респондента вщок-ремлюють ресурси для здшснення процесiв управлiння вимогами у проекта, а 47% - не здатш формалiзувати процеси для об'ективно1 вал^ацп вимог. Отже, е не-обх^шсть у створеннi методичного забезпечення про-цесiв управлiння вимогами у проектах i програмах.
У роботах [4, 5] пропонуеться використовувати ствставлення АерархАчно1 структури робiт проекту з насту пними iерархiчними структурами:
- R(equirement)BS - iерархiчна структура вимог проекту;
- R(isk)BS - iерархiчна структура ризиюв проекту;
- R(esource)BS - iерархiчна структура ресурсiв проекту;
- R(esponsibility)BS - оргашзацшна структура проекту.
Таким чином, встановлюються вАдповщноста «робо-та-вимога», «робота-ресурс», «робота-вАдповАдальний», «робота-ризик» («work-requirement», «work-resource», «work-responsibility», «work-risk»). Графiчно модель взае-мозв'язкiв мiж елементами iерархiчних структур проекту можна представити у виглядi кубу, гранями якого е ризики, роботи, ресурси, вимоги, стейкхолдери та вщпо-в^альш особи проекту (risk, resource, requirement, responsibility, work, stakeholders - 4R & WS).
Метою дано1 статта е формалiзацiя метрик процесiв управлшня вимогами у проектах. Об'ектом дослщження е процеси управлiння та контролю вимог у проектах i програмах, предметом дослщження - метрики, яю характеризуюсь вимоги у проекта.
1 ПОСТАНОВКА ЗАДАЧ1
Вхiдними даними для аналiзу е iерархiчна структура робгт проекту. В ходi досл^ження вона доповнюеться iнформацiею щодо розподшу ресурсiв та вiдповiдальних осiб за окремими роботами (цi зв'язки наявш при пла-нуваннi проекту в чгткому вид), та даними щодо розпо-дiлення вимог та ризиюв за роботами проекту (дат такого роду зазвичай вщсутш у ч^кш формА, тому пропонуеться моделювати вАдповАдш зв'язки за допомогою методiв нечгтких множин).
При формуванш вихщних даних необхАдно врахову-вати юнування рАзних титв вимог у проекта: взаемовик-лючних (двА або бшьше вимог, яю не можуть бути вико-наш одночасно в проекта); тдтримуючих (виконання одше1 вимоги сприяе виконанню шшо1); незалежних (виконання одше! вимоги не впливае на виконання шшо!); обов'язкових (вимог, яю повинш бути виконаними, на-приклад, у вщповщноста до чинного законодавства) [6].
Результатом розробки методу буде встановлення фор-мальних зв'язюв мАж окремими елементами моделА 4R & WS. Зокрема, використання методу надасть змогу визна-чити ресурсо- та ризиконавантаженшсь певно1 вимоги, що, в свою чергу, забезпечить вАджгадними метриками процеси управлшня та контролю вимог у проекта.
2 ОГЛЯД ЛГГЕРАТУРИ
Аналiз i управлiння вимогами у проектах здшснюеть-ся дослщниками за трьома основними напрямами:
- у межах бiзнес-аналiзу Так, BABOK (A Guide To The Business Analysis Body Of Knowledge, [7]) мае двi окремi галузi знань, якi описують задачi управлiння вимогами: Requirements Life Cycle Management та Requirements Analysis and Design Definition.
- у межах традицшного проектного менеджменту. Одним з найпоширешших стандартав проектного менеджменту е A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - стандарт, виданий PMI. У 2013 р. у п'ятому виданш цього стандарту [8] з'явилась нова галузь знань - управлшня защкавленими сторонами проекту, де, зокрема, розглядаються i питання аналiзу вимог З 2014 р. за результатами видання стандарту Business Analysis for Practitioners: A practice Guide [9] PMI стандартизуе термш «бiзнес-аналiз» як критичну компетенцiю проектного управлшня i з цього часу розг-лядае «управлiння вимогами» як компоненту бiзнес ана-лiзу. У 2016 р. PMI видае окремий стандарт з управлшня вимогами - Requirements Management: A Practice Guide [3], який розглядаеться як елемент, що пов'язуе [8] i [9].
- у сферi шформацшних технологш. На цей час бшьш^ть дослщжень, якi присвячено питанням аналiзу вимог (Requirements Engineering), стосуються розробки програмного забезпечення та шформацшних систем. Requirements Engineering описуе процеси визначення, документування та виконання вимог i е складовою час-тиною системно! та комп'ютерно! шженерп. На цей час о^м «нишевих» методiв аналiзу та управлшня вимогами [10] юнуе стандарт, який пов'язуе гнучю методологii розробки програмного забезпечення i методи бiзнес-аналiзу - Agile Extension to the BABOK Guide [11].
Слщ зазначити, що, хоча стандарти [3, 7-9, 11] сфор-мованi на осжда «кращих практик», вони мютять лише рекомендацii щодо використання певних методiв роботи з вимогами, без докладного опису методiв та вказiвок щодо !х адаптацii до тае! або iншоi галузi. При цьому знач-на частина методiв е стльними для усiх стандартiв, на-приклад, це аналiз беклогу, використання функщональ-ного моделювання, прiоритезацiя вимог, використання UML, тощо. Щодо практичного !х впровадження, бiльшiсть вiдповiдних дослщжень iснуе в сферi IT: визначення при-орiтетiв за допомогою методу MoSCoW та time-boxing [12], Quality Analyzer of Requirements Specification, Vienna development method (VDM) [13], Z notation [14].
У той же час у галузi традицшного проектного менеджменту дослщники переважно придшяють увагу питанням управлшня стейкхолдерами проектав, а не !х вимогами: вщокремлюються такi невирiшенi завдання, як вiдсутнiсть сформульованого перелiку фактс^в визначення якостi управлiння стейкхолдерами; необх^шсть подальшого розвитку стандартiв стейкхолдер-менедж-менту; нестача практичних пiдходiв до управлшня; вщсутшсть аналiзу зв'язку мiж дiями з управлiння стейкхолдерами та усшшшстю проекту [15]; обгрунтовуеться актуальнiсть створення механiзмiв багатомiрного аналь зу стейкхолдерiв. Наявнi працi мають описи алгоритму аналiзу, але не мютять математичного пiдгрунтя для його
p-ISSN 1607-3274. Радюелектрошка, шформатика, управлiння. 2017. № 4 e-ISSN 2313-688X. Radio Electronics, Computer Science, Control. 2017. № 4
проведения [16]; придшяеться увага створенню програм-ного забезпечення для проведения стейкхолдер-аналiзу. Наявнi розробки засноваш на використання iснуючих метседв аналiзу стейкхолдерiв, отже, наслiдують ix недо-лiки, зокрема, використання невелики кiлькостi факторiв для аналiзу, використання експертного оцiнювання без процедури його верифжацп [17]. Вiтчизнянi вченi, яю займаються питаннями класифiкацii стейкxолдерiв при-дiляють увагу переважно економiчним, а не управлшсь-ким аспектам [18]. Однак необхщно зазначити, що питан-ня управлiння зацiкавленими сторонами проекпв вже розглядаеться як стратегiчне завдання [19], що корелюе з позищею PMI.
Отже, е об'ективна необхщшсть у розробцi та форма-лiзацii методiв управлiння i контролю вимог у проектах поза межами IT-галуз^ зокрема, для проектiв, управлш-ня яких здiйснюеться за традицiйними або комбiновани-ми методологiями.
3 МАТЕР1АЛИ I МЕТОДИ
Зв'язки мiж роботами рiзниx рiвнiв WBS можуть бути представлен у виглядi матрицi (1), елементи яки вказу-
ють на наявшсть або вiдсутнiсть зв'язку мiж роботами i-го та (,'-1)-го рiвнiв: F=1, якщо зв'язок е, i F =0 за вщсут-шстю зв'язку:
wi-1,1 Wi_ 1,2 . wi -1,m
wi,1 F (wi,b wi- ,1) F (wi,1 wi -1,2) . . F(wi,1 wi- 1,m )
wi,2 F(wi,2, wi- 1,1) F(wi,2 wi -1,2) . . F (wi,2 , wi -1,m )
wi,n F(wi,n, wi- 1,1) F(wi,n wi -1,2) . . F(wi,n, wi- 1,m ).
Mi
). (1)
У свою чергу, кожна з елементарних робгг проекту може бути асоцшована з певним ресурсним наванта-женням, вимогами стейкxолдерiв, виконання яких тдтри-муе дана робота, вiдповiдальними виконавцями та ризи-ками, якi пов'язаш з роботою [4]. Цi зв'язки також можуть бути задаш у матричнш формi:
- взаемозв'язок ресурмв та робiт i-го рiвня. Кожен з елементiв матрицi визначаеться як доля вщ загального обсягу певного ресурсу, що використовуеться при вико-нанш роботи,
wi,1 wi,2 • . w,,n
recourse1 F (recourse1, wi 1) F(recourse1, w, 2) . . F (recourse1, w, ,n)
recourse2 F (recourse2, wi 1) F(recourse2, w, 2) . . F (recourse2, w ,n )
recoursek F (recoursek, w, 1) F(recoursek, w, 2) . . F (recoursek, w, ,n )
(2)
- взаемозв'язок вщповщальних осiб та робiт i-го рiвня. Елемент матрицi дорiвнюе 1, якщо певна особа вщповщае за виконання роботи, або 0 у шшому випадку,
wi,1 ... w,,n
responsibility1 F (responsibility1, w, 1) ... F (responsibility^ w, n )
responsibility 2 F (responsibility 2, w, 1) ... F (responsibility 2, w ,n )
responsibility z F (responsibility z, w, 1) ... F (responsibility z, w, ,n )
(3)
- взаемозв'язок вимог стейкxолдерiв проекту та робiт i-го рiвня. Цей зв'язок може бути заданий у нечитай формi. Нехай 0(requirementl, w,, j): requirementi х w,, j ^ [0;1j е функцiя приналежностi нечеткого бiнарного вiдношення (4).
Для вшх requirementi е requirement та w,, j e w, функцiя 0(requirementi, wt j) - це стутнь, у якому виконання j-i роботи i-го рiвня зумовлюе виконання вимоги l. Вiдношення можна представити у матричнш формi
wi,1 ... wi,n
requirement 0(requirement1, w, 1) ... 0(requirement1, wt ,n )
requirement2 0(requirement2, w, 1) ... 0(requirement2, wt ,n)
requirementl 0(requirementl, w, 1) ... 0(requirementl, wt ,n )
(4)
- взаемозв'язок ризиюв проекту та робгт i-го рiвня. Цей зв'язок може бути заданий у нечеткш формг Нехай €>(riskv, wi, j ) : riskv х wi, j ^ [0;1j е функцiя приналежностi нечiткого бшарного вiдношення (4). Для всix riskv e risk
та w;-, j e wi функцiя ф(riskv, w,, j ) - це стутнь, у якому виконання j-i роботи i-го рiвня зумовлюе виникнення ризику v. Вiдношення можна представити у матричнш формi
W,1 wi,2 • • wi,n
risk1 Ф(riskl, wi 1) Ф(riskl, Wi,2) • . Ф(riskl, wi n )
risk 2 Ф(risk2, wi 1) Ф(risk2, Wi,2) • • Ф(risk2, wt ,n )
riskv Ф(riskv, wi 1) , Wi,2) • • Ф(riskv, wt ,n )
(5)
Також можна встановити зв'язок ]шж стейкхолдерами проекту та 1х певними вимогами:
requirement1 • •• requirement t
stakeholder F (stakeholder, requirement1) • •• F (stakeholder, requirementt)
S = stakeholder2 F (stakeholder2, requirement1) • •• F (stakeholder2, requirement t)
stakeholderu F (stakeholderu, requirement1) • •• F (stakeholderu, requirementl)
(6)
Елемент матрицi визначае наявшсть або вiдсутнiсть зв'язку мiж l-ю вимогою та u-м стейкхолдером -
F(stakeholder, requirementi)=1, якщо зв'язок е, i
F(stakeholderu, requirementi )=0 за вiдсутнiстю зв'язку.
Використовуючи формули (1-5), отримуемо розподiл характеристик (елементiв моделi), що вивчаються, за (i—1)-м рiвнем робгт:
- ресурсiв: Recourseг-1 = Mi г-1 • Recoursei ; (7) - вщповщальноста: Responsibilityi-1 = Mi i-1 • Responsibilityi; (8) - вимог: Requirement— = Mii-1 • Requirementi; (9)
- ризишв: Riski-1 = Mi,i-1 • Riski. (10)
Це надасть змогу встановити зв'язки мiж окремими характеристиками. Наприклад, формули (10-12) пов'я-зують вимоги стейкхолдерiв з ресурсами, необхщними для 1х виконання, вiдповiдальними особами та ризиками, яю можуть виникнути при виконання вимог:
RRec = Requerementi-1 • Recourset
4-1'
(11)
RRes = Requerementi-1 • Responsibilityi-1, (12)
RRis = Requerementi-1 • Riski-1.
(13)
Надалi, використовуючи iнформацiю щодо стейкхол-дерiв та 1х вимог (6), можна сшввщнести ресурсне i ризи-кове навантаження окремих вимог зi стейкхолдерами, якi 1х висувають, що надасть змогу класиф^вати защкав-леш сторони проекту за цими характеристиками.
Отже, для використання запропонованого методу формалiзацil метрик управлшня вимогами проекту не-обхiдно виконати наступне:
1. Обрати рiвень ieрархiчноl структури робгт проекту, для якого слiд отримати iнформацiю щодо ресурсного та ризикового навантаження вимог На основi ШБ8 проекту побудувати матрицi М1 г-1, яю зв'язують елементарнi ро-
боти проекту з сумарними роботами обраного рiвня.
2. Сформувати матрицi
Recoursei, Requirementi , Responsibilityi та Riski для рiвня ШБ8, який вщповщае елементарним роботам проекту.
3. Послщовно використовуючи формули (7-10) отримати розподш характеристик, що вивчаються, за дослщ-жуваним рiвнем робгт.
4. За формулами (11-13) отримати матриц (вектори), якi пов'язують вимоги стейкхолдерiв з ресурсами, необ-шдними для 1х виконання, вiдповiдальними особами та ризиками, яю можуть виникнути при виконання вимог
4ЕКСПЕРИМЕНТИ
Розглянемо умовний проект, ieрархiчну структуру робгт якого представлено на рис. 1.
Рисунок 1 - WBS умовного проекту
p-ISSN 1607-3274. Радюелектронжа, шформатика, управлiння. 2017. № 4 e-ISSN 2313-688X. Radio Electronics, Computer Science, Control. 2017. № 4
Припустимо, що в проекп використовуеться три типи ресурив (resource resource2, resource3), яю розподше-но м1ж елементарними роботами (третього р1вня) на-ступним чином:
Resource3 =
i проект реал1зуе дв1 вимоги стейкхолдер1в (requirement1, requirement2), виконання яких розподiлено мiж елемен-тарними роботами проекту так:
0,2 0,05 0
0,5 0 0,4
0,1 0,55 0
0,2 0 0,1
0 0,4 0,2
0 0,05 0,3
Requirement3 =
5 РЕЗУЛЬТАТИ
Зв'язки мiж роботами третього та другого рiвня проекту описуе матриця М32:
0 0,3
0,5 0
0 0,6
0,25 0
0,25 0
0 0,1
M32 =
1 1
0 0
0 0 11
00000
В свою чергу, зв'язки мiж другим та першим рiвнем робiт проекту задае вектор М21: М21 = | 1 1 1 |.
Аналiз проекту проводимо для другого рiвня ШБ8: розподiл ресурсiв для другого рiвня робот:
Resource2 = M32 • Resourse3 =
1110 0 0 0 0 1 1 0 0 0 0 0
0,2 0,05 0
0,5 0 0,4
0,1 0,55 0
0,2 0 0,1
0 0,4 0,2
0 0 0,3
0,8 0,6 0,4
0,2 0,4 0,3
0 0 0,3
- сшввщношення вимог стейкхолдерiв i ресурсiв для другого рiвня робот:
T
RReR = Requerement3 • Resourse3 =
0,5 0,5 0 0,9 0 0,1
0,8 0,6 0,4
0,2 0,4 0,3
0 0 0,3
0,5 0,5 0,35 0,72 0,54 0,39
Таким чином, визначаеться ресурсне навантаження певжй вимоги: перша вимога споживае 0,5 першого ресурсу; 0,5 другого ресурсу i 0,35 третього ресурсу; для другш вимоги значення споживання ресуршв, вщповщ-но, 0,72, 0,54 i 0,39.
Матриця RRec не враховуе розподшу «стльних» ре-сурсiв мiж окремими вимогами. З iншого боку, сума за стовбцями цiеï матриц характеризуе ефективнiсть вико-ристання певного ресурсу щодо виконання вимог стей-кхолдерiв. Так, показник ефективност використання resource 1 складае 1,32, resource - 1,04, resource3 - 0,74.
Для врахування спiльного використання ресурсiв роз-рахуемо ресурсонавантаженiсть окремо за requirement 1:
та requirement2:
0,4 0,3 0,2
0,1 0,2 0,15
0 0 0
0,72 0,54 0,36
0 0 0
0 0 0,03
Спiльнi ресурси визначаються наступною матрицею, кожен з елементiв я^ визначаеться як мiнiмальний з еле-ментiв двох попереднiх матриць:
0,4 0,3 0,2 000 000
Отже, requirementx споживае ресурси
0,2 0,15 0,1
0,1 0,2 0,15
0 0 0
а requirement2 -
0,52 0,39 0,26 000 0 0 0,03
Сшввщношення вимог стейкхолдерiв i ресурив для другого рiвня робот з урахуванням спiльного використання ресурив (за умови рiвномiрного ïх розподiлу):
0,3 0,35 0,25 0,52 0,39 0,29
Аналопчно можна отримати матрицю взаемозв'яз-ку вимог i омб, вiдповiдальних за ïх виконання (RRes ) та матрицю взаемозв'язку вимог i ризикiв, що виникають при ïх виконаннi ( RRis ).
6 ОБГОВОРЕННЯ
У робота отримано формалiзацiю зв'язкiв мiж окремими характеристиками моделi 4R & WS - ризиками, роботами, ресурсами, вимогами, стейкхолдерами та вщповщальним особами проекту.
X
X
X
В^значимо, що iснуючи методи моделюють лише взаемозв'язки мiж роботами та ресурсами проекту, ок-ремо вiдокремлюючи часовi ресурси. Практичною реа-лiзащею таких методiв е програмне забезпечення для управлшня проектами - наприклад, MS Project, OpenProj, Gantter для традицiйного проектного менеджменту, Jira i Trello - для гнучких методологiй розробки.
Так, MS Project дозволяе задати три типи ресурмв (рис. 2) та закршити ïx за роботами проекту, тривалють яких встановлюеться окремо (рис. 3).
Такий шдхщ дозволяе не тальки розрахувати бюджет та тривалють проекту, а й вiдстежувати його виконання за допомогою методу освоеного обсягу, який контро-люе виконання проекту за часом та бюджетом. Виконання вимог стейкxолдерiв не вщстежуеться.
При використаннi гнучких методологш завдання на проект формулюються у виглядi «user stories» - юторш користувача, якi е в^ображенням вимог вiдповiдного стейкхолдера. Кожна задача пов'язана з виконавцем та часом (iншi ресурси не враховуються), який по^бен на ïï виконання. Вщсутш явно заданi зв'язки мiж окремими задачами.
Вiдмiнною рисою запропонованого методу е його адаптившсть пiд традицiйнi процеси проектного управлшня, що спрощуе отримання виxiдниx даних та надалi надасть змогу використовувати стандартне програмне забезпечення для практичноï реалiзацiï методу.
При формуванш виxiдниx даних необх^но врахову-вати обмеження щодо ^нування рiзниx типiв вимог у проекта (взаемовиключних, пiдтримуючиx, незалежних i обов'язкових), а також коректно використовувати методи неч^ких множин при формуванш матриць Requirementi та Risk.
ВИСНОВКИ
Для прийняття обгрунтованих рiшень i формалiзацiï процесiв управлшня вимогами необх^но створити
iнструменти, яю визначатимуть основнi характеристики вимог у проекта. Результатом дослщження е встановлен-ня формальних зв'язкiв мiж ризиками, роботами, ресурсами, вимогами, стейкхолдерами та вщповщальним особами проекту. Використання методу формалiзацп метрик управлшня вимогами проекту дозволяе визначити ресурсо- та ризиконавантаженшсь певно! вимоги, що надае можливють доповнити юнуючи моделi класифь кацп i приоритезацп вимог даними характеристиками. Аналогiчно, можна отримати метрики для ощнювання ефективноста команди проекту та класифжацп защкавле-них сторiн проекту.
Таким чином, у робота виршено актуальну задачу формалiзацiя метрик процесiв управлiння вимогами у проектах.
Науковою новизною роботи е розробка методу фор-малiзацil метрик управлшня вимогами проекту, який, на вiдмiну вщ iснуючих, дае змогу вiдстежувати виконання вимог стейкхолдерiв проекту, враховуючи !х ризикове та ресурсне навантаження.
Практична щнтстъ роботи полягае в тому, що запро-понований метод дозволяе контролювати виконання проекту не лише за часовими та вартасними характеристиками, а й вщстежувати ступiнь задоволеностi зацiкавлених сторш проекту, що пiдвищуе обrрунтованiсть проектних рiшень вiдносно управлiння змiнами та стейкхолдерами в проекта. Перспективою подальших дослщжень е про-грамна реалiзацiя запропонованого методу. ПОДЯКИ
Роботу виконано в рамках держбюджетно! науково-досл^но! теми Харкiвського нацiонального ушверсите-ту мiського господарства iменi О. М. Бекетова «Методо-логiя та шформацшш технологи управлiння стейкхолдерами проеклв та програм мiського розвитку» (ДР № 011би003371).
Рисунок 2 - Лист ресурав проекту
Рисунок 3 - Д1аграма Ганта проекту
p-ISSN 1607-3274. Радюелектронжа, шформатика, yправлiння. 2017. № 4 e-ISSN 2313-688X. Radio Electronics, Computer Science, Control. 2017. № 4
10^ Sommerville L Software Engineering - 9th ed / L Sammem!^ -
Addison-Wesley, 2011 - 790 p^ 11 The Agile Extension to the BABOK® Guide^ - IIBA, 2013 -134 p^
12^Miranda E^ Timeboxing Planning: Buffered Moscow Rules / E^ Miranda // ACM SIGSOFT Software Engineering Notes^ - 201L -Volume 36, Number 6^ - P 1-5^ DOI: 10.1145/2047414.2047428. ^Fitzgerald J^ S^ Vienna development method / L S^ Fitzgerald, P^ G^ Larsen, M^ Verhoef // Wiley Encyclopedia of Computer Science and Engineerings - 2008^ - P 1-11 DOI: 10Л002/ 9780470050118^ecse447^ 14^ Spivey J^ M^ The z notation: a reference manual / J^ M^ Spivey -
Oriel College, 1998^ - 1168 p^ 15^ Stakeholder management in construction: An empirical study to address research gaps in previous studies / [J Yang, G^ Q^ Shen, M^ Ho et al] // International Journal of Project Management -2011 • - Vol 29, No^ 7^ - P 900-910^ DOI: 10Л016/ j•ijproman•2010•07•013 16^ Macharis C Multi actor multi criteria analysis (MAMCA) as a tool to support sustainable decisions: State of use / C Macharis, К Turcksin, K Lebeau // Decision Support Systems - 2012^ - Vol 54, No^ 1 -P 610-620^
17^ Damian D^ StakeSource2^0: using social networks of stakeholders to identify and prioritize requirements / D^ Damian, A^ Finkelstein // Proceedings of the 33rd international conference on Software engineerings - ACM^ - 2011 - P 1022-1024^ 18•Мамонов К А^ Теоретико-методичнi положения та особли-востi формування стейкхолдерiв на тдприемствах житлово-комунального господарства / К А^ Мамонов, О^ О^ Конопл^ на, €• В^ Гавриленко // Актуальш проблеми економiки: науко-вий економiчний журнал^ - 2014^ - № 8^ -С 127-134^
19^ Кадыкова И Н Информационная технология стратегического управления проектно-ориентированной организацией / И Н Кадыкова, С А^ Ларина, И В^ Чумаченко // Вкник Нац техн ун-ту «ХП1»: зб^ наук пр^ Сер^ : Стратепчне управлш-ня, управлiння портфелями, програмами та проектами -Харюв : НТУ «ХП1», 2017^ - № 3 (1225) - С 9-15^
Стаття надiйшла до редакци 12^06^2017^ Пiсля доробки 21^08^2017^
Гусева Ю^ ЮЛ Мартыненко А^ СД Кадыкова И НД Чумаченко И В*
1Канд^ техн наук, доцент, доцент кафедры управления проектами в городском хозяйстве и строительстве, Харьковский национальный университет городского хозяйства имени А^ Н Бекетова, Харьков, Украина
2Аспирант кафедры управления проектами в городском хозяйстве и строительстве, Харьковский национальный университет городского хозяйства имени А^ Н Бекетова, Харьков, Украина
3Канд^ экон наук, доцент, доцент кафедры управления проектами в городском хозяйстве и строительстве, Харьковский национальный университет городского хозяйства имени А^ Н Бекетова, Харьков, Украина
4Д-р техн наук, профессор, заведующий кафедры управления проектами в городском хозяйстве и строительстве, Харьковский национальный университет городского хозяйства имени А^ Н Бекетова, Харьков, Украина
МЕТРИКИ ПРОЦЕСОВ УПРАВЛЕНИЯ И КОНТРОЛЯ ТРЕБОВАНИЙ В ПРОЕКТАХ
Актуальность. Процессы управления требованиями являются одним из ключевых факторов успеха или неудачи проекта^ Исследования в области проектного менеджмента показывают, что именно эти процессы недостаточно формализованы Следовательно, есть необходимость разработки и формализации методов управления и контроля требований, в частности, для проектов, управление которых осуществляется по традиционным или комбинированным методологиям^
Цель работы - формализация метрик процессов управления требованиями в проектах^ Объектом исследования являются процессы управления и контроля требований в проектах, предметом исследования - метрики, характеризующие требования в проекте^
Метод. Использованы методы анализа и синтеза, методы нечетких множеств и операции над матрицами Предложено использование модели, которая устанавливает связи между отдельными характеристиками проекта (риски, работы, ресурсы, требования, стейк-холдеры и ответственные лица проекта) с помощью иерархической структуры работ Предложена формализация метрик модели, которая позволит отслеживать динамику выполнения проекта и идентифицировать заинтересованные стороны проекта по определенным направлениям^
Результаты. На основе сопоставления иерархической структуры работ с иерархическими структурами требований, рисков, ресурсов и организационной структурой проекта разработан метод формализации метрик управления требованиями проекта^ Предложенный метод позволяет отслеживать выполнение требований заинтересованных сторон проекта во времени в соответствии с объемом фактически израсходованных ресурсов по аналогии с методом освоенного объема^ Адаптивность метода к традиционным процессам менеджмента проектов позволяет использовать исходные данные - уже сформированые активы проекта и стандартное программное обеспечение (в частности, MS Project, OpenProj) для практической реализации метода^
Выводы. Предложенный метод формализует процессы управления требованиями в проекте, позволяет определять ресурсную и рисковую нагрузку требований, дополняет существующие модели классификации требований данным метриками Метод формализации метрик управления требованиями проекта позволяет также получить инструменты для оценки эффективности команды проекта и классификации заинтересованных сторон проекта^ Проведенные эксперименты подтвердили работоспособность предложенного математического обеспечения и позволяют рекомендовать его использование на практике при принятии проектных решений по управле-
СПИСОК ЛГГЕРАТУРИ
1. PMI's Pulse of the Profession®: The High Cost of Low Performance [Electronic resource]. - Access mode: http : II www.pmi.orgI-ImediaIpmiIdocumentsIpublicIpdfIlearningIthought-leadershipIpulseIpulse-of-the-profession-20l6.pdf?sc_lang_temp=en
2. Pulse of the Profession®: Capturing the Value of Project Management [Electronic resource]. - Access mode: http : II www.pmi.orgI-mediaIpmiIdocumentsIpublicIpdfIlearningIthought-leadershipIpulseIpulse-of-the-profession-20l5.pdf
3. Requirements Management: A Practice Guide. - Newtown Square, Pa. : Project Management Institute, Inc., 201б. - 93 p.
4. Гусева Ю. Ю. Матрична модель 4R & WS для класифшаци стейкхoлдерiв прoектy I Ю. Ю. Гусева, О. С. Мартиненко, I. В. Чyмаченкo II Вкник Шц. техн. ун-ту «ХШ»: зб. наук. пр. Сер.: Стратепчне управлшня, управлшня портфелями, програмами та проектами. - Харюв : HTУ «ХШ», 2017. - № 2 (1224). - С. 1S-22.
5. Гусева Ю. Ю. Процесний шдхщ до моделювання i мошторин-гу вимог защкавлених сторш I Ю. Ю. Гусева, О. С. Мартиненко, I. В. Чумаченко II Ыформацшш технологи та шноваци в економщ, управлшш проектами i програмами: за заг. ред.
B. О. ^мофеева, I. В. Чумаченко. - Х. : ХHУPE, 2016. -
C. 289-296.
6. Гусева Ю. Ю. Управлшня защкавленими сторонами освгтшх проекта I Ю. Ю. Гусева, М. В. Сидоренко, I. В. Чумаченко II Вкник ^щонального техшчного ушверситету «ХШ». Збiрник наукових праць. Cерiя: Стратепчне управлшня, управлшня портфелями, програмами та проектами. - Х. : HTУ «ХШ». - 2016. - № 2 - С. 8-12.
7. A Guide To The Business Analysis Body Of Knowledge. - 3d Edition. - IIBA, 2015 - 657 p.
S. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). - Fifth Edition. - Newtown Square, Pa. : Project Management Institute, Inc., 2013. - 614 p.
9. Business Analysis for Practitioners: A practice Guide. - Newtown Square, Pa. : Project Management Institute, Inc., 2015. - 206 p.
нию изменениями и требованиями стейкхолдеров проекта. Перспективы дальнейших исследований могут заключаться в разработке программного обеспечения, реализующего предложенный метод.
Ключевые слова: управление требованиями, проект, метрика, ресурсы, стейкхолдеры, риски.
Husieva Yu. Yu.1, Martynenko O. S.2, Kadykova I. M.3, Chumachenko I. V.4
'PhD, docent, associate professor of the Department of Project management in urban economy and construction, O. M. Beketov National University of Urban Economy in Kharkiv, Kharkiv, Ukraine
2Post-graduate student of the Department of Project management in urban economy and construction, O. M. Beketov National University of Urban Economy in Kharkiv, Kharkiv, Ukraine
3PhD, docent, associate professor of the Department of Project management in urban economy and construction, O. M. Beketov National University of Urban Economy in Kharkiv, Kharkiv, Ukraine
4Dr. Sc. Professor, Head of the Department of Project management in urban economy and construction, O. M. Beketov National University of Urban Economy in Kharkiv, Kharkiv, Ukraine
METRICS OF MANAGEMENT AND CONTROL REQUIREMENTS PROCESSES IN PROJECTS
Context. The processes of requirements management are a key factor in the success or failure of the project. Researches in the field of project management indicate that these processes are not formalized. Thus, there is need to develop and formalize methods of requirements management and control, particularly for projects which are carried out by combined or traditional methodologies.
Objective of the article is formalizing of requirements management processes metrics in projects. The object of the research is management and control requirements processes of projects, the subject of the study - metrics that characterize the requirements of the project.
Method. Methods used are analysis and synthesis, methods of fuzzy sets and operations on matrices. The use of a model that establishes relationships between individual characteristics of the project (risks, resources, requirements, stakeholders and decision-makers of the project) through WBS is proposed. A formalization of model metrics is proposed that will keep track of the project and identify project stakeholders through the defined areas.
Results. Based on the comparison of WBS with a hierarchical structure of requirements, risks, resources and organizational structure of the project method of formalizing metrics requirements management project is developed. The proposed method allow to track the performance of project stakeholders' requirements according to the actual amount of resources spent by analogy with the method of earned value. Adaptability to the traditional project management processes lets you use the original data - assets of the project and standard software (eg, MS Project, OpenProj) for the practical implementation of the method.
Conclusions. The proposed method formalizes requirement management processes in the project, determines resource and risk load of requirements, supplementing the existing requirements classification models with these metrics. The proposed method can also provide metrics for evaluation the performance of the project team and project stakeholders classification. The conducted experiments have confirmed the efficiency of the proposed mathematical software and allow recommending it for use in practice for making project decisions about change management and requirements management of the project. Prospects for further research may include developing of software that will implement the proposed method.
Keywords: requirements management, project, metrics, resources, stakeholders, risks.
REFERENCES
1. PMI's Pulse of the Profession®: The High Cost of Low Performance [Electronic resource]. Access mode: http:// www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2016.pdf?sc_lang_temp=en
2. Pulse of the Profession®: Capturing the Value of Project Management [Electronic resource]. Access mode: http:// www.pmi.org/-media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2015.pdf
3. Requirements Management: A Practice Guide [Text]. Newtown Square, Pa., Project Management Institute, Inc., 2016, 93 p.
4. Husieva Yu. Yu., Martynenko O. S., Chumachenko I. V. Matrychna model' 4R & WS dlja klasyfikacii' stejkholderiv proektu, Visnyk Nac. tehn. un-tu "HPI": zb. nauk. pr. Ser.: Strategichne upravlinnja, upravlinnja portfeljamy, programamy ta proektamy. Harkiv, NTU "HPI", 2017, No. 2 (1224), pp. 18-22.
5. Husieva Yu. Yu., Martynenko O. S., Chumachenko I. V. za zag. red. V. O. Timofjejeva, I. V. Chumachenko Procesnyj pidhid do modeljuvannja i monitoryngu vymog zacikavlenyh storing, Informacijni tehnologii' ta innovacii v ekonomici, upravlinni proektamy i programamy. Kharkiv, HNURE, 2016, pp. 289-296
6. Husieva Yu. Yu., Sydorenko M. V., Chumachenko I. V. Upravlinnja zacikavlenymy storonamy osvitnih proektiv, Visnyk Nacional'nogo tehnichnogo universytetu «HPI». Zbirnyk naukovyh prac'. Serija: Strategichne upravlinnja, upravlinnja portfeljamy, programamy ta proektamy. Kharkiv, NTU «HPI», 2016, No. 2, pp. 8-12
7. A Guide To The Business Analysis Body Of Knowledge. 3d Edition, IIB A, 2015, 657 p.
8. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition. Newtown Square, Pa.: Project Management Institute, Inc., 2013, 614 p.
9. Business Analysis for Practitioners: A practice Guide. Newtown Square, Pa.: Project Management Institute, Inc., 2015, 206 p.
10. Sommerville I. Software Engineering 9th ed. Addison-Wesley, 2011, 790 p.
11.The Agile Extension to the BABOK® Guide, IIBA, 2013, 134 p.
12. Miranda E. Timeboxing Planning: Buffered Moscow Rules, ACM SIGSOFT Software Engineering Notes, 2011, Volume 36, Number 6, pp. 1-5. DOI: 10.1145/2047414.2047428.
13. Fitzgerald J. S., Larsen P. G., Verhoef M. Vienna development method, Wiley Encyclopedia of Computer Science and Engineering, 2008, pp. 1-11. DOI: 10.1002/ 9780470050118.ecse447.
14.Spivey J. M. The z notation: a reference manual. Oriel College, 1998, 1168 p.
15.Yang J., Shen G. Q., Ho M., Drew D. S., Xue X. Stakeholder management in construction: An empirical study to address research gaps in previous studies, International Journal of Project Management, 2011, Vol. 29, No. 7, pp. 900-910. DOI: 10.1016/ j.ijproman.2010.07.013
16.Macharis C., Turcksin L., Lebeau K. Multi actor multi criteria analysis (MAMCA) as a tool to support sustainable decisions: State of use, Decision Support Systems, 2012, Vol. 54, No. 1, pp. 610-620.
17. Damian D., Finkelstein A. StakeSource2.0: using social networks of stakeholders to identify and prioritize requirements,
Proceedings of the 33rd international conference on Software engineering, ACM, 2011, pp. 1022-1024.
18. Mamonov K. A., Konoplina O. O., Gavrylenko Je. V. Teoretyko-metodychni polozhennja ta osoblyvosti formuvannja stejkholderiv na pidpryjemstvah zhytlovo-komunal'nogo gospodarstva, Aktual'ni problemy ekonomiky: naukovyj ekonomichnyj zhurnal, 2014, No. 8, pp. 127-134.
19. Kadykova I. N., Larina S. A., Chumachenko I. V. Informacionnaja tehnologija strategicheskogo upravlenija proektno-orientirovannoj organizaciej, Visnik Nac. tehn. un-tu "HPI": zb. nauk. pr. Ser. : Strategichne upravlinnja, upravlinnja portfeljami, programami ta proektami. Kharkiv, NTU "HPI", 2017, No. 3 (1225), pp. 9-15.
