Оцінка ризику проектів програмного забезпечення

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Оцінка ризику проектів програмного забезпечення

1. Введення

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

Ризик (за визначенням SEI (Software Engineering Institute)) - це можливість зазнати втрат.

Ризик проекту ПЗ - це можливість:

  1. зниження якості кінцевого продукту,

  2. підвищення вартості його розробки,

  3. затримки закінчення розробки або зриву проекту (тобто, відмови від проекту).

Величина ризику являє собою R = V * P твір величини втрат V від небажаної події в проекті та ймовірності P настання цієї події.

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

Ефективне управління ризиком полягає у прийнятті (по кожному ризику) компромісних рішень по:

  • врахування ризиків та аналізу старих проектів;

  • оцінці трудомісткості усунення певного ризику,

  • величиною потенційного негативного впливу цього ризику на проект,

  • в правильній оцінці взаємозалежності усуваються ризиків і можливого впливу прийнятих в певний (поточний) момент часу рішень на стан проекту в майбутньому;

  • резервування в проекті часу на боротьбу з ризиками.

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

2. Концепція управління ризиком проекту ПЗ

Базовими конструкціями концепції управління ризиком є:

  • функції управління ризиком,

  • таксономія (класифікація) ризику;

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

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

Рис. 1. Концепція управління ризиком

2.1 Функції управління ризиком

Таблиця 1 Характеристика функцій управління ризиком

Функція

Визначення функція

Мета функція

Ідентифікація

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

Шукати і знайти ризики проекту ПЗ до того, як вони переростуть у проблеми

Аналіз

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

Перетворити дані про ризики в інформацію для прийняття адекватних рішень

Планування

Процес, в ході якого приймаються рішення про заходи щодо усунення ризиків

Виробити рішення і план дій по кожному ризику. Інтегрувати ці рішення і плани в єдиний план управління ризиком проекту ПЗ.

Облік і контроль

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

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

Регулювання

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

Своєчасна та ефективна корекція відхилень у запланованих діях за ризиком

Комунікація

Організація взаємодії з управління ризиком стимулює виконання інших функцій і гарантує, що:

  • ризики та плани їх усунення інтерпретуються однозначно,

  • інформація про ризик є доступною для всіх членів проекту;

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

  • існує ефективний діалог між менеджером і командою проекту

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

2.2 Таксономія ризику

Таксономія ризику забезпечує базис для організації даних і вивчення різних аспектів ризику проекту ПЗ.

Таксономія ризику розроблялася SEI протягом трьох років і була перевірена на більш ніж 30 проектах ПЗ. Вона складена з урахуванням типових процесів життєвого циклу (ЖЦ) ПЗ і охоплює найбільш загальні області ризику проекту, що стосуються характеристик ПЗ, середовища і процесів розробки і обмежень проекту. Ця таксономія може частково видозмінюватися з урахуванням специфіки конкретного проекту.

Таксономія ризику SEI має ієрархічну структуру і систематизує джерела (області) ризику за трьома рівнями:

  • клас,

  • елемент класу,

  • атрибут елемента

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

Таблиця 2

Клас джерела (області) ризику

Характеристика класу

Елемент класу

Атрибут елемента

1. Технічні аспекти розробки (інженерія програмного продукту)

Пов'язаний з процесами (роботами) на стадіях ЖЦ ПЗ (розробка вимог, проектування, кодування, тестування та ін), а також характеристиками ПЗ (вимог, проекту, коду та інше) на цих стадіях

Вимоги

Стабільність




Повнота




Однозначність




Достовірність




Реалізованість




Новизна




Масштабність



Проект

Функціональність




Складність




Інтерфейси




Продуктивність




Тестованості




Апаратні обмеження




Купується, ПЗ



Кодування та автономне тестування

Реалізованість




Автономне тестування




Кодування / реалізація



Інтеграція та інтеграційне тестування

Середа




Інтеграція продукту




Інтеграція системи



Нефункціональні характеристики ПЗ

Зручність супроводу




Надійність




Захищеність




Безпека




Людські фактори




Специфікації

2. Середа і технологія розробки

Пов'язаний з методами, процедурами та інструментами, використовуваними в ході розробки ПЗ

Процес розробки

Формализованность




Укомплектованість




Контрольованість процесу




Досвід застосування




Контрольованість продукту



Система підтримки розробки

Потужність




Укомплектованість




Зручність застосування




Досвід застосування




Надійність




Сопровождаемость




Постачання



Процес управління

Планування




Організація проекту




Досвід управління




Організація взаємодії



Методи управління

Моніторинг




Управління персоналом




Забезпечення якості




Управління конфігурацією



Робоча обстановка

Якість роботи




Кооперація




Комунікація




Моральний клімат

3. Зовнішні обмеження проекту

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

Ресурси

Терміни розробки




Штат проекту




Фінансування




Засоби розробки



Умови договору

Тип договору




Обмеження договору




Договірні залежності



Інтерфейси проекту

Замовник




Суміжники




Співвиконавці




Головний виконавець




Вище керівництво




Продавці




Політичні принципи

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

Опитувальник, заснований на таксономії ризику (для стислості, TBQ, від Taxonomy-Based Questionnaire), є інструментом, застосування якого гарантує охоплення всіх потенційних областей ризику завдяки наявності в ньому питань, що стосуються нижнього рівня таксономії ризику - атрибутів. Кількість і форма запитань може бути різною в залежності від специфіки проекту, обраного методу інтерв'ювання та обробки його результатів. У будь-якому випадку вона повинна орієнтуватися на максимально повне і ефективне вилучення знань членів проекту (включаючи менеджерів, проектувальників, технічний персонал тощо) про ризики конкретного проекту ПЗ.

Таблиця 3 - Список 10 головних програмних ризиків

Програмні ризики

Техніка управління ризиками

1. Провали персоналу, поганий менеджмент

Пошук талантів; робоче змагання; побудова команди; персональні договору; перехресні тренування; приречення ключових фігур.

2. Нереальні терміни і бюджети, помилки в плануванні робіт над проектом

Деталізований аналіз вартості та очікуваних строків; оцінка вартості; покрокова розробка; повторне використання ПЗ; пом'якшення вимог.

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

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

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

Прототипування; сценарії; аналіз завдань; класифікація користувачів (функціональна, стильова, по завантаженню).

5. Втрата прибутковості, невміння укладати договори, неякісне впровадження

Зниження вимог; Прототипування; вартісний аналіз, оцінка вартості.

6. Невірно сформульовані вимоги або змінюються вимоги

Високий поріг змін; інкапсуляція інформації; покрокова розробка (відкладає зміни на подальші кроки розробки).

7. Провали в зовнішньому постачанні компонентами, невірний вибір комерційного ПЗ

Тестування; перевірки; довідкові перевірки; аналіз сумісності.

8. Провали в зовнішньо виконуваних завданнях, недостатнє тестування і погана інтеграція ПЗ

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

9. Провали продуктивності

Імітаційне моделювання; тестування; Прототипування; підгонка інструментарію.

10. Перевищення можливостей комп'ютерної науки

Технічний аналіз; аналіз прибутковості; Прототипування; довідкові перевірки.

2.3 Методологія оцінки та управління ризиком

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

  • з вивчення існуючої практики розробки конкретного проекту,

  • оцінці альтернативних прийомів управління ризиком,

  • виробленні концепції управління ризиком клієнта,

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

  • створення необхідної інфраструктури та плану управління ризиком ПЗ в організації-клієнті.

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

Процес управління ризиком проекту ПЗ включає наступні чотири стадії:

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

  • підготовка робіт - планування та координація майбутніх робіт з оцінювання ризику проекту ПЗ,

  • оцінка ризику - виконання функцій управління ризиком та отримання рекомендацій з управління ризиком проекту ПЗ,

  • підготовка до усунення ризику - розробка рекомендацій щодо усунення ризиків по всіх областях усунення ризику, розробка плану управління ризиком та приведення його в дію.

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

Розроблено 3 методології:

  • оцінювання ризику ПЗ - SRE (від Software Risk Evaluation),

  • безперервне управління ризиком - CRM (від Continuous Risk Мanagement),

  • колективне управління ризиком - TRM (від Team Risk Management).

2.3.1 Оцінювання ризику ПЗ

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

До основних функцій управління ризиком належать:

  • виявлення,

  • специфікація,

  • оцінювання,

  • структурування (консолідація)

  • усунення ризиків.

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

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

Існує багато способів специфікації ризику - від простого твердження про ризик до складного висловлювання з застосуванням умовних виразів виду "ЯКЩО <умова> ТО <наслідки>", зв'язок "І" та ін Вибір того чи іншого способу визначається ефективністю його практичного застосування для проекту і особливостями інструментальної підтримки обробки ризиків.

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

Існують різні механізми оцінювання величини ризику - від простих суб'єктивних оцінок по 3-бальною шкалою до суворих статистичних вимірювань. Приклади простих механізмів оцінювання величини ризику представлені на рис. 2.

Рис. 2. Матриця трирівневої оцінки ризику

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

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

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

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

2.3.2 Безперервне управління ризиком

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

Таблиця 3

Принцип управління ризиком

Характеристика принципу управління ризиком

1. Різнобічний (у різних проекціях) бачення предмета

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

2. Колективна робота

Спільна робота для досягнення спільної мети; оптимальні умови прояву таланту, знань і досвіду

3. Глобальні перспективи

Сприйняття розробки ПЗ в контексті великомасштабних робіт за проектом системи; допущення як сприятливих, так і неблагопріяних перспектив реалізації специфікацій продукту ПЗ (пов'язаних з перевищенням строків, вартості, програмними збоями та ін)

4. Далекоглядність

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

5. Відкрите взаємодія

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

6. Інтегроване управління

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

7. Безперервність процесу

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

2.3.3 Колективне управління ризиком

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

Методологія заснована на сім принципів управління ризиком (п. 2.3.2.) Та філософії бригадної роботи, до яких додає дві функції - ініціювання колективної роботи і власне колективне управління ризиком. Ці функції виконуються над кожним ризиком послідовно, але дії з управління ризиком проекту в цілому можуть бути як послідовними, так і паралельними, і ітеративними (наприклад, планування для одного ризику може поєднуватися з ідентифікацією іншого).

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

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

Один з можливих прикладів використання процесу управління ризиком представлений на рис. 3.

Рис. 3. Приклад застосування процесу управління ризиком

3. Організаційна структура управління ризиком

Процес управління ризиком проекту ПЗ починається зі створення координаційної групи (ради) з управління ризиком проекту. Чисельність групи може коливатися від однієї людини з частковою зайнятістю до кількох людей з повною зайнятістю. Кандидатами в координаційну групу можуть бути члени бригади проекту, представники користувачів, виконавців і співвиконавців. Лідером цієї групи є представник найманої незалежної групи експертів, який несе відповідальність за виконання забезпечують функцій планування і координації в рамках методу SRE. Інтерфейс організації-розробника з незалежною групою (в особі її лідера) здійснюється координатором дій з організації-розробника. Він несе відповідальність за підбір (у середовищі проекту) фахівців для інтерв'ювання та проведення брифінгів при відвідуванні організації-розробника незалежною групою експертів.

Власне, діяльність з управління ризиком проекту ПО повинна здійснюватися кваліфікованим персоналом, включеним до складу проекту (бригадою проекту), а розподіл ролей і відповідальності за управління ризиком - відбиватися в плані управління ризиком. Один з можливих способів розподілу відповідальності при управлінні ризиком представлений на рис. 4.

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

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

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

Рис. 4. Розподіл ролей при управлінні ризиком

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

  • він брав участь в управлінні принаймні одним проектом,

  • застосовував методології управління ризиком принаймні для одного проекту і

  • має досвід у відповідній проблемної області проекту.

Якщо не виконується хоча б одна з перерахованих умов, член проекту повинен мати можливість поповнити свої знання шляхом навчання. Способи придбання необхідних знань такі:

  • формальне навчання. Заняття з членами проекту проводяться організацією-замовником або незалежною організацією за відповідною програмою;

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

4. Розробка плану управління ризиком

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

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

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

Рис. 5. Блок-схема прийняття рішення при плануванні усунення ризику

Таблиця 4 Рекомендації щодо змісту плану управління ризиком

Розділ плану управління ризиком

Опис

Введення

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

Огляд процесів

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

Організація

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

Деталі процесу

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

1) методи і інструменти, які вибираються для підтримки кожної функції, а також критерії їх вибору;

2) посилання на інші плани, керівництва та навчальні матеріали з будь-якого методу або інструменту, який документований в іншому місці (наприклад, у відповідних документах проекту, документах рівня організації або документах замовника);

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

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

Ресурси та графіки

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

Документування ризику

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

5. Рекомендації щодо оцінки ризику проектів ПЗ

Аналіз методологій оцінки ризику, що пропонуються такими зарубіжними організаціями, як NASA Lewis Research Center, Defense Systems Management College, DSDC (Defense Logistics Agency Systems Design Center), BMPC (Best Manufacturing Practices Center), SEI та ін показав, що всі вони схожі в підходах до оцінювання ризику, розходяться в принципах ранжирування ризиків й у цілому грунтуються на запропонованій SEI таксономії ризику, модифікуючи перелік питань TBQ і змінюючи їх форму.

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

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

Питання для проведення інтерв'ювання сформульовані в такій формі, щоб на кожен з них можна було дати однозначну відповідь: "Так", "Ні", "Частково", "Не знаю", або "Не вживають".

Відповідь "Так" свідчить про відсутність ризику, суть якого сформульована в питанні.

Відповідь "Ні" або "Не знаю" свідчить про наявність ризику.

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

Відповідь "Не вживають" відповідає неправомірності завдання питання для даного проекту і не враховується при оцінці ризику.

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

Метод оцінки ризику BMPC включає наступні кроки:

1. Обчислення рангу ризику R по одному атрибуту. Ранг ризику атрибуту R обчислюється виходячи з кількості питань, на які було дано відповідь "Так" або "Частково". Визначається сума ваг цих відповідей. Потім обчислюється загальна сума ваги усіх питань для атрибута (вага атрибута), за винятком питань з відповідями "Не вживають". Після цього знаходиться процентне співвідношення цих сум за наступною формулою

R = i = 1, k Vдi / j = 1, n Vi - å j = 1, t Vнi)) * 100,

де Vдi - вага питання з відповіддю "Так" або "Частково", к - кількість таких відповідей,

Vi - вага кожного питання, n - загальна кількість питань у атрибуті;

Vнi - вага питання з відповіддю "Не вживають", t - кількість таких відповідей.

2. Обчислення рівня ризику атрибуту U.

Якщо ступінь ризику R = 100% -70%, то рівень ризику U - низький.

Якщо ступінь ризику R = 69% -30%, то рівень ризику U - середній.

Якщо ступінь ризику R = 29% -0%, то рівень ризику U - високий.

3. Обчислення рангу і рівня ризику кожного атрибута.

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

Наприклад, елемент "Вимоги" складається з 7 атрибутів (пріложеніе.1). Якщо з п'яти атрибутам був отриманий високий ризик, а по 2 - середній, то співвідношення ризиків на шкалі буде 2 / 7 для середнього та 5 / 7 для високого ризику.

4. Обчислення комбінованого ризику по всіх елементах.

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

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Контрольна робота
125.3кб. | скачати


Схожі роботи:
Оцінка ефективності інвестиційного проекту з розробки програмного забезпечення
Економічна оцінка розробки і застосування програмного забезпечення в системах телекомунікацій
Економічна оцінка розробки і застосування програмного забезпечення в системах телекомунікацій
Методи кількісного аналізу ризику інвестиційних проектів
Порівняльний аналіз ефективності інвестиційних проектів з урахуванням ризику
Проблематика аналізу інвестиційних проектів в умовах неорпеделенності і ризику
Облік невизначеності і ризику при оцінці ефективності інвестиційних проектів
Облік інфляції ризику та невизначеності при оцінці ефективності інвестиційних проектів
Застосування теорії нечітких множин в оцінці економічної ефективності і ризику інвестиційних проектів
© Усі права захищені
написати до нас