Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
45
Добавлен:
12.03.2016
Размер:
5.48 Mб
Скачать

Розділ 10

291

 

 

 

Формою подання мережної моделі є графова, таблична, діаграмна

тощо.

Головній сутністю усіх моделей – состав робіт і порядок їх виконання у часі. У таких моделях роботи характеризують процеси їх виконання у часі. Їм відповідають вершини, а дугам відношенням між роботами. В якості вершин могуть бути також події, що позначають номерами або іменами. Цим подіям відповідає завершення однієї або декількох робіт, які попереджують (вхідні) до неї події і що створює умови для початку наступних (вихідних) робіт. Подія, що не має вхідних робіт, зветься початковою, а подія, що не має вихідних робіт – кінцевою або завершеною. Перша подія є ціллю проекту і відповідає досягненню окремих підцілей проекту.

Різновидом таких моделей є імовірнісна, в якої параметрам робіт відповідає випадкова величина (наприклад аварія, неотримання потрібних ресурсів, фінансовий кризи тощо).

Головне призначення мережних моделей – оцінка фактичного і майбутнього стану проекту і вироблення керуючих дій, а також оцінка ефективності від цих дій та вибору кращих з них.

Відомими методами керування проектами є метод критичного шляху СРМ

(Critical Path Method) та PERT (Program Evaluation and Review Technique). Останній метод відомий у СРСР як ПЕРТ, що був створений у 1958р. групою керування спеціальними проектами. Розглянемо їх.

10.2.1. Метод критичного шляху – СРМ

Цей метод було створено при дослідженні можливості ефективного використання обчислювальної машини Univac на фірмі Dupon для планування й складання планів-графіків великих комплексів робіт для модернізації заводів цієї фірми. Як результат було розроблено раціональний і простий метод (Уолкера - Келлі) керування проектом з використанням ЕОМ, що було названо методом критичного шляху CPM.

Критичний шлях — послідовність робіт, з’єднаних початковою і кінцевою роботами, відображаючи найдовший повний шлях у мережі. Наприклад, на , критичний путь (рис.10.3) це:

Початок робіт, А1, А3, А6, кінець робіт.

Роботи, що лежать на цьому шляху, називають критичними. Саме тривалість критичного шляху визначає найменшу загальну тривалість робіт у проекті в цілому. Час виконання всього проекту в цілому може бути скорочено за рахунок скорочення часу виконання задач на критичному шляху. Роботам на критичному шляху приділяють особливу увагу, оскільки будь-яка затримка виконання задач на критичному шляху призводить до збільшення часу виконання проекту і строків закінчення усього комплексу робіт в плані невиконання проекту своєчасно. Тому менеджер проекту повинний забезпечувати концентрацію уваги, саме, на критичних роботах.

292

 

 

 

 

 

 

Розділ 10

 

 

 

A3

 

 

 

 

 

A1

1 тиждень

3тижні

A6

1тиждень

 

 

 

 

 

 

 

3тижні

2тижні

 

 

 

 

 

 

 

 

2тижні

 

 

 

 

 

A4

 

 

 

 

 

 

 

 

 

 

початок

 

 

 

 

 

кінець

 

робіт

 

 

 

 

 

робіт

 

4 тижні

 

 

 

 

 

 

 

A2

 

 

 

3 тижні

 

 

 

 

 

 

 

 

 

 

2 тижні

A5

 

 

 

 

 

Рис. 10.3. Граф завдання строків виконання робіт

Іншими словами, основною особливістю

методу

критичного шляху є

можливість

керування загальними

строками

проекту

за

спостереженням

тривалістю

окремих робіт важливих

завдань, які знаходяться

на критичному

шляху. Цей метод дозволяє розрахувати можливі календарні графіки виконання комплексу робіт на основі поданої логічної структури мережі й необхідності оцінок часу виконання кожної роботи окремо [8, 11].

Метод базується на графічному представленні робіт і видів дій у проекті із зазначенням орієнтовного часу їхнього виконання. При такому представленні у вершинах розташовуються роботи, а час виконання кожної з робіт під вершинами або на дугах графа, як це показано на рис 10.3.

Граф доцільно будувати тоді, коли роботи й час їхнього виконання є заданими (визначеними).

Критичний шлях у графі вказує максимальну тривалість робіт на графі (від початкової роботи до кінцевої). У ході реалізації проекту вибираються й виконуються роботи за часом, які не впливають на строки виконання інших (незалежних) робіт проекту або на їхню тривалість.

Роботи на критичному шляху можуть скорочуватися за рахунок зміни часу виконання. Подання в такому вигляді робіт граф називають ще мережевою діаграмою, яка у наглядному вигляді відображає роботи, їхні взаємозв'язки, послідовності і час виконання. Цей граф є найпоширенішим схематичним представленням мережі на сьогоднішній день.

10.2.2. Метод аналізу й оцінки проекту – PERT

Паралельно з розробкою CPM, у військово-морських силах США було створено (фірма «Буз, Аллен & Гамільтон») метод аналізу й оцінки програм PERT для реалізації проекту розробки ракетної системи «Polaris», що поєднує близько 3800 підрядників із числом операцій більш як 60 тис. [11].

Застосування методу PERT дає змогу керівникам даної програми точно знати, що потрібно робити в кожний момент часу і який виконавець це робить, а також визначати ймовірність своєчасного завершення окремих операцій. Керування

Розділ 10

293

 

 

 

програмою створення ракетної системи виявилося настільки успішним, що проект було завершено на два роки раніше запланованого строку.

Метод PERT представляється мережевими діаграмами з вершинами–подіями, а робота – у вигляді лінії між двома подіями з наступними призначеннями (рис. 10.4):

початкова точка – подія або набір подій, які відбулися до початку виконання даного відповідного процесу за набором умов її початку;

кінцева точка процесу – контрольна точка, подія, у якій замовник перевіряє якість отриманих результатів процесу;

тривалість – інтервал часу, за який успішно повинно завершитися проміжна

подія;

строк – дата, до якої процес повністю або частково завершує своє виконання.

9

1.21.1

 

 

 

13

 

 

1.3

 

 

 

 

12

 

11

2.1

11

2.2

 

 

3.1

 

10

 

15

2.3

 

 

 

 

5

 

3.2

2.4

0

 

0

 

 

Рис. 10.4. Вид графа робіт і строків (на дугах) для проекту

Дузі, що виходить з початкової вершини й входить у кінцеву вершину, відповідає часова позначка 0, а на інших дугах – час виконання.

У графі можуть відображатися циклічні шляхи. За графом проводять аналіз шляхів, тобто даних про тривалість кожного з них.

Значна частина сучасних засобів відображення таких мережних графів є візуальною, вершини, а також лінії виділяються кольорами, що з’єднують ці вершини між собою.

Розбіжності між цими розглянутими двома методами мережевого графового подання методами CPM і PERT незначні. Однак метод PERT, на відміну від CPM, ураховує виникаючі невизначеності в часі виконання кожної операції.

Представлення складніших зв'язків між роботами для завдання вузлів графа у вигляді вершина–подія є більш складним, і тому цей метод рідше використовується на практиці.

294

Розділ 10

У цьому методі можливий час виконання операцій оцінюється за допомогою трьох оцінок:

оптимістичної (ПРО), песимістичної (P), імовірнісної (B).

Цей час визначають за формулою: (ПРО+4В+Р)/6 із зазначенням його на мережевому графіку.

10.2.3. Планування і контроль проекту

Планування – це процес розподілу й призначення ресурсів (матеріальних і людських) з урахуванням вартості й часу виконання проекту. Неадекватне планування може спричинити зрив проекту або отримання в середовищі проекту неадекватних результатів.

Планування й перепланування – най ємнісна в часі частина керування проектом, починаючи з ранніх процесів проекту. У минулому проекти в галузі ПС не мали планів і оцінок їхньої реалізації і виконання. Сучасні методики пропонують засоби для виправлення цієї ситуації, надаючи в розпорядження менеджерів проектів інструменти й методи, які дозволяють планувати реальні роботи і досягати їхнього виконання.

Види планів організації проекту. Планування робіт проекту є першим кроком, на якому створюють плани-графіки, проводять їхній облік, контроль та регулювання. Результатом планування є різні види планів, які відповідають усім видам організаційної діяльності в процесі виконання проекту. Взагалі складаються такі плани:

керування проектом за методами критичного шляху СРМ, PERT або

іншими;

план-графік робіт з проектування і строків їх виконання за відповідними методами керування і планування;

– розподіл робіт між розробниками відповідно плану;

план досягнення якості, а також плани верифікації, валідації й тестування для отримання результатів проектування;

поставки і регулювання технічних, CASE і людських ресурсів на проекті;

супроводження, змінювання деяких вимог і усунення різних недоліків. Керування проектом охоплює всі вказані плани і може мати в своєму складі

додаткові плани, пов’язані з деякими особливостями або вказівками замовника проекту.

При формуванні планів проекту встановлюють взаємозв’язок наведених планів з різних сторін розроблення та керування проектом. Процес планування починається на початку проекту, під час аналізу предметної області і визначення вимог до неї.

Тобто аналіз проекту виконується за методами СРМ, PERT, системного аналізу, аналізу витрат тощо. Цілі проекту розробляються таким чином, щоб оцінки продукту, були документованими задля подальшого їхнього моніторингу, види діяльності були затвердженими, а групи та розробники виконували підписані плани робіт з проекту.

Обґрунтування планів базується на реалістичних (якісних експертних) оцінках щодо робіт та їхнього затвердження керівником і замовником проекту. В

Розділ 10

295

 

 

 

плані проекту збалансовується сукупність інструментів, джерел даних, методологій, процесів і процедур, які забезпечують відповідні трудовитрати на запланованих роботах. У ньому враховуються зовнішнє середовище – інфраструктура організації, інструменти, людські ресурси, політика щодо до персоналу, ситуації на ринку тощо.

План проекту містить у собі календарний план, перелік документів та плану розроблення програмного продукту. Цей план враховує задану вартість, об’єм та план-графік робіт, відстеження ризиків і застосування затверджених методологій і інструментів розроблення проекту. Графік робіт складається за схемою, наведеною на рис. 10.5.

Після узгодження плану його з замовником їм користується менеджер. Розроблений план проекту поновлюється протягом ЖЦ для проведення змін за календарним планом і результатами перевірок проекту в контрольних точок.

На базі плану розроблення проекту можуть складатися індивідуальні плани робіт кожного члена колективу проекту, які можуть переглядатися і уточнюватися щомісячно за результатами перевірки робіт у проекті.

 

 

 

 

Зв'язок

 

 

Оцінка

 

 

Розподіл

 

 

 

 

Визначення

 

 

 

 

ресурсів

 

 

 

 

 

 

 

 

між

 

 

 

 

персоналу

 

 

Визначення

етапів

 

 

 

 

для

 

 

 

 

 

 

етапами

 

 

 

 

заетапами

 

 

графіка

 

 

 

 

 

 

етапу

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Вимоги

Графік

допроекту

 

Рис. 10.5. Кроки складання графіка робіт на проекті

При плануванні за методом PERT подія або дата в плані є певною віхою здійснення окремих робіт у проекті. Віха слугує відображенню і оцінки стану завершення тих або інших робіт. У проекті менеджери використовують віхи для того, щоб позначити важливі проміжні результати, яких треба буде досягти в процесі реалізації проекту. Послідовність віх, визначених менеджером, часто називається планом за віхами або за подіями. Визначення плану досягнення відповідних віх утворює календарний план.

Планування за методом СРМ або діаграми Ганта [11–13], які допомагають:

структуризації робіт на основні компоненти й підкомпоненти;

визначенню напрямів діяльності для досягнення комплексу цілей;

розподілу відповідальних за виконання окремих робіт у проекті;

отриманню звітності й узагальнення інформації про усякі дії проект.

План можна представляти етапами, станами і діяльностями (рис.10.6). У плані відображаються зв'язки між процесами, визначається інтервал часу для виконання кожної діяльності, час початку й завершення, а також опис різних видів демонстрацій функцій, надійності, захисту для замовника. До документів плану

296

Розділ 10

належать: комплект опису виконання заданого набору робіт і операцій та різних видів комунікації.

Рис 10.6. Операційний граф плану проекту

Крім того, є діаграма Ганта це горизонтальна лінійна діаграма, на якій завдання проекту представляються строками у вигляді відрізків часу і мають дати початку й закінчення, можливо із затримками й іншими часовими параметрами.

Моніторинг проекту. Моніторинг (облік та контроль) забезпечує відстеження «факту відповідно плану» шляхом перегляду надбань та результатів у ході виконання проекту, і вироблення належних заходів з коригування. Ці заходи можуть вміщати виправлення плану розроблення ПС, щоб відобразити у ньому фактичний стан справ щодо надбань та результатів, перепланувати залишкову роботу та/або передбачити в плані дії з вдосконалення виконання роботи.

Моніторинг проводять для того, щоб фактичні результати було простежено за планами проекту з метою повернення проекту в планові рамки. При моніторингу аналізуються такі дані:

строки (факт/план);

витрати (матеріальні, трудові) (факт/план або % плану);

виконана робота (% запланованої);

об’єм документів (сторінок);

об’єм програм за кількістю функцій кожного компонента (факт/план або %

плану);

об’єм тестування компонентів проекту (виконано/заплановано або %

плану);

безвідмовність (кількість збійних тестів/проведених або % проведених);

досягнута коректність (кількість ототожнених та виправлених дефектів розробником/кількість помилок, визначена тестувальником).

Менеджер проекту використовує дані, отримані під час моніторингу, а також дані з верифікації та тестування для оцінки проекту в цілому.

Розділ 10

297

 

 

 

10.2.4. Оцінювання вартості проекту

Однією з робіт на проекті є оцінка їх вартості. Загальна вартість проекту визначається виходячи з вартості окремих частин, умов виконання робіт, наявного штату виконавців, застосованих методів і інструментів. У вартість проекту входить все, що створює імідж проекту: комп'ютери, ПС, обладнання, кімнати, меблі, телефони, модеми, канцелярські товари тощо. Іноді необхідно створити додаткові умови (наприклад, безпека).

Додаткові витрати – це вартість засобів і інструментів тестування,

кодування або інші CASE системи. Основна

оцінка в проекті визначає витрати на

розроблення

проекту, тобто людино-дні

робіт виконавців проекту. Вона

виконується на початку проекту й складання його плану. Оцінювання здійснюють «знизу» або «вгору». При наявності застарілої системи вартість екстраполюється на нову з деякими корегуваннями або проводиться песимістична, оптимістична і реальна оцінка шляхом опитування всіх членів робочої групи з виведенням найбільш ймовірної.

Головними чинниками визначення вартості проекту є тип і кількість ресурсів, а також період часу, необхідний ресурсам для виконання робіт з проекту. Ресурси планових операцій і їхня тривалість використовуються як ключові входи цього процесу, а як ресурси виступають людські ресурси, їхні тарифні ставки.

До ресурсів відносять, зокрема, робочу силу, матеріали, обладнання, послуги, приміщення, інформаційні технології, а також особливі статті витрат, наприклад, врахування рівня інфляції або витрати на непередбачені обставини.

Вартісна оцінка ресурсів планових операцій може даватися параметрично, наприклад, через кількість рядків у коді програми або годин робочого часу, витрачених на них.

Для оцінки вартості проектів широко застосовується програмне забезпечення з управління проектами з такими засобами: крупноформатні електронні таблиці, а також інструментальні засоби з моделювання і обробки статистичної інформації. Це сприяє швидшому розгляду різноманітних альтернативних варіантів.

Оцінка вартості операцій – це кількісна оцінка приблизної вартості ресурсів, необхідних для виконання планових операцій.

Розроблення бюджету витрат – це об’єднання оцінок вартості окремих планових операцій або пакетів робіт з метою створення загального базового плану з вартості для визначення ефективності виконання проекту з детальним описом бюджетних запитів, необхідних для вартісної оцінки планових операцій.

Алгоритмічні методи оцінки. До них належить модель, у якій відображаються зв'язки між витратами в проекті й чинниками, що на них впливають. Модель – це рівняння, у якому витрати – залежна, а чинники – незалежні змінні.

Наприклад, вартість проекту визначається за формулою: E = (a+bSc) m (X), де S — розмір системи, а, в, с — емпіричні константи, Х — вектор чинників вартості розмірністю n, m — регулюючий множник за витратами чинників.

У [10] пропонується модель у вигляді співвідношення, отриманого експериментальним шляхом: E = 5.25S0.91. Ця модель застосовувалася для оцінки проекту, у якому програмні системи мали розмір від 4000 до 467000 рядків коду, 28 різними мовами програмування високого рівня для 66 комп'ютерів, і на які витрачено від 12 до 11758 людино-місяців.

298

Розділ 10

Крім того, пропонується техніка моделювання, що використовується в

рівнянні витрат організації-розробника:

E = 5.5+0.73S1.16.

У більшості моделей оцінка залежить від розміру системи в рядках коду. Модель COCOMO Боєма увібрала в себе три техніки вимірів проекту. У перших моделях застосовувалися показники ціни, враховувався персонал, властивості проекту, продукту й середовища. Модель містить у собі оцінку трьох процесів ведення проекту. На першому будується прототип для завдань підвищеного ризику (інтерфейс користувача, ПС, система взаємодії, реалізації та ін.) і проводиться оцінка витрат (наприклад, число таблиць у БД, екрани й звітні форми тощо).

На другому процесі ведуть оцінку витрат з проектування й реалізації робіт у функціональних точках проекту, що наведені у вимогах до проекту. На третьому процесі оцінка належить до завершеного проектування, коли розмір системи визначається у термінах готових рядків програми й інших чинниках.

Базовою моделлю оцінки слугує таке рівняння: E=bSc m(X), де первинна оцінка b Sc коригується за допомогою вектора вартості m (X). Ця модель розвивається з урахуванням аналізу об'єктів (число старих і нових об'єктів). Параметр с у рівнянні змінюється від 0 до 1.0 для першої стадії й від 1.01 до 1.26 для інших.

10.3. Методи керування ризиками у проекті

Причиною виникнення ризиків у проекті є деякі невизначеності в плані обсягу робіт на кожного працюючого та ін. Ризики можуть бути «відомі», які визначені і оцінені, їх планують, а також планують і ризики «невідомі», які можуть з’явитися [3, 4, 11].

Ризик – це небажана подія, що може мати непередбачені негативні наслідки. Якщо в проекті ідентифіковано безліч можливих подій ризику, які можуть викликати негативні наслідки, то такий проект схильний до ризику.

Багато компаній приділяють увагу розробці й застосуванню корпоративних методів керування ризиками з урахуванням специфіки проектів і корпоративних методи керування.

Американський Інститут PMI менеджменту розробив стандарти з керування проектами й останнім часом переробив розділи, що регламентують процедури з ризиків. У новій версії стандарту PMBOK є шість наступних процедур.

1.Планування робіт з керуванням ризиків шляхом вибору підходів і методів діяльності з їх находження.

2.Ідентифікація ризиків як визначення тих, які здатні вплинуть на реалізацію проекту і його документацію.

3.Якісна оцінка ризиків, як аналіз ризиків і умов їхнього виникнення з метою визначення їхнього впливу на успіх проекту.

4.Кількісна оцінка, як кількісний аналіз імовірності виникнення й впливу наслідків ризиків на проект.

5.Планування реагування ризиків, як визначення процедур і методів зменшення негативних наслідків ризикових подій і використання можливих переваг.

6.Моніторинг і контроль ризиків, як визначення ризиків, що залишаються, виконання плану керування ризиками проекту й оцінка дій з мінімізації ризиків.

Розділ 10

299

 

 

 

Всі ці процедури взаємодіють одна з одною, а також з іншими процедурами. Кожна процедура виконується, принаймні, один раз у кожному проекті. Незважаючи на те, що ці процедури розглядаються як дискретні елементи із чітко визначеними характеристиками, на практиці вони можуть частково збігатися й взаємодіяти.

Планування керування ризиками – це процес прийняття рішень з застосування й планування керування ризиками для конкретного проекту. Цей процес може містити в собі рішення про організацію, кадрове забезпечення, вибір кращої методології, джерел даних для ідентифікації ризику та аналізу ситуації. Сплановані роботи з керування ризиками є адекватними як рівню й типу ризику, так і важливості проекту для організації.

Ідентифікацію ризиків проводять менеджери проекту, замовники, користувачі й незалежні фахівці шляхом опису ризиків, які здатні вплинути на проект. Ця процедура виконується як ітераційний процес і не буде ефективною, якщо проводиться нерегулярно протягом реалізації проекту. Ідентифіковані менеджерами проектів ризики переглядають аналітики проекту. Практично роботу з цими ідентифікованими ризиками виконують розробники проекту. Для формування об'єктивної оцінки стану проекту відносно наявності ризиків чи їх відсутності залучаються незалежні фахівці на завершальному процесі.

Якісна оцінка ризиків – це процес проведення якісного аналізу ідентифікації ризиків, з метою швидкого реагування на них. Така оцінка визначає ступінь важливості ризику й вибір способу реагування. Доступність супровідної інформації допомагає легше розставити пріоритети для різних категорій ризиків. Якісна оцінка ризиків – це оцінка умов виникнення ризиків і визначення їхнього впливу на проект за допомогою стандартних методів і засобів. Вони допомагають частково уникнути невизначеностей, які часто зустрічаються в проекті. Постійна переоцінка ризиків відбувається протягом ЖЦ проекту.

Кількісна оцінка ризиків – це визначення ймовірності виникнення ризиків і впливів їх наслідків на проект, а прийняття правильних рішень. Ця оцінка визначає наступне:

імовірність досягнення кінцевої мети проекту;

ступінь впливу ризику на проект й обсяги непередбачених витрат і матеріалів, які можуть знадобитися;

ризики, що вимагають якнайшвидшого реагування й більшої уваги, а також впливу їх наслідків на проект;

фактичні витрати й передбачувані строки закінчення робіт в проекті. Кількісна і якісна оцінки ризиків базується на ідентифікації ризиків і

проводять їх окремо або разом, залежно від часу й бюджету.

Планування і реагування ризиків – це розроблення методів і технологій з зниженню негативного впливу ризиків на проект. Ці методи призначені для ефективного захисту проекту від впливу на нього ризиків. Планування як ідентифікація і розподіл кожного ризику за категоріями потребує їхнього реагування і визначення наслідків впливу ризиків (позитивно або негативно) на проект.

Ця стратегія повинна відповідати типам ризиків, рентабельності ресурсів і часових параметрів. Ризики, що обговорюються під час зустрічей, повинні бути адекватними завданням на кожному процесі проекту й погоджені з усіма членами

300

Розділ 10

групи виконавців з менеджером проекту. Може бути кілька варіантів стратегій реагування на ризики.

Моніторинг і контроль – це процедури спостереження за ідентифікацією ризиків, забезпечення виконання плану ризиків і оцінки його ефективності з урахуванням зниження ризику. Показники ризиків, пов'язані зі здійсненням умов виконання плану, фіксуються. Моніторинг і контроль супроводжує процес впровадження проекту в життя.

Якісний контроль виконання проекту надає інформацію для прийняття ефективних рішень для запобігання виникнення ризиків. Для надання повної інформації про ризики у проекту необхідна взаємодія між усіма менеджерами проекту і розробниками.

Ціль моніторингу й контролю полягає в з'ясуванні таких ситуацій:

реакцію на ризики впроваджено відповідно до плану й необхідності змін;

зміна ризиків у порівнянні з попередніми значеннями;

визначення впливу ризиків і вживання необхідних заходів;

реакція на ризики відповідно плану.

Контроль може викликати вибір альтернативних стратегій, прийняття коректив, перепланування проекту для досягнення базового плану. Між менеджерами проекту й групою ризику повинна бути постійна взаємодія й фіксація всіх змін і явищ. Звіти про виконання проекту й системи ризиків регулярно формуються.

Керування ризиками ґрунтується на двох основних типів ризику: загальний ризик і специфічний.

До загального типу ризику належить ризик, що виникає, коли наявне недостатнє розуміння вимог, брак професіоналів або недостача часу на тестування. Ризик другого типу виражається недоліками проекту (незавершеність проекту за обіцяний строк та ін.).

Для кожного можливого ризику визначається показник ступеню його ймовірності й показник витрат, пов'язаних з ризиком. Під час проведення регресивного тестування здійснюється пошук критичних помилок. Залежно від того, наскільки ця помилка критична й від того, які показники ризику діють, обчислюються збитки ризику. Діяльність керування ризиком пов’язана з виконанням таких завдань: зменшення ризику, планування ризику, резолюцію на виявлений ризик. Зменшення ризику можна досягти, якщо уникати ризику при зміні вимог, перерозподіляти ризик, відслідковувати ризик й керувати ним.

Систему керування ризиком можна представити у вигляді відношення:

збиток до мінімізації – збиток після мінімізації ціна мінімізації ризику.

Мінімізації ризику можна досягти прототипуванням. Боєм [10] ідентифікував 10 найпоширеніших причин ризику в проекті:

1.Скорочення штату або набір некваліфікованих співробітників.

2.Нереалістичні плани й бюджети в проекті.

3.Розроблення функціонально неправильних програмних елементів.

4.Розроблення невдалого інтерфейсу користувача.

5.Невдала постановка вимог.

6.Постійна зміна вимог.

Соседние файлы в папке Разное