[ Оцінка ризику проектів програмного забезпечення ]! | Пов'язаний з процесами (роботами) на стадіях ЖЦ ПЗ (розробка вимог, проектування, кодування, тестування та ін), а також характеристиками ПЗ (вимог, проекту, коду та інше) на цих стадіях | Вимоги | Стабільність | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Повнота | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Однозначність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Достовірність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Реалізованість | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Новизна | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Масштабність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Проект | Функціональність | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Складність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Інтерфейси | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Продуктивність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Тестованості | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Апаратні обмеження | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Купується, ПЗ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Кодування та автономне тестування | Реалізованість | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Автономне тестування | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Кодування / реалізація | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Інтеграція та інтеграційне тестування | Середа | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Інтеграція продукту | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Інтеграція системи | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Нефункціональні характеристики ПЗ | Зручність супроводу | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Надійність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Захищеність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Безпека | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Людські фактори | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Специфікації | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2. Середа і технологія розробки | Пов'язаний з методами, процедурами та інструментами, використовуваними в ході розробки ПЗ | Процес розробки | Формализованность | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Укомплектованість | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Контрольованість процесу | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Досвід застосування | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Контрольованість продукту | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Система підтримки розробки | Потужність | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Укомплектованість | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Зручність застосування | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Досвід застосування | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Надійність | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Сопровождаемость | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Постачання | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Процес управління | Планування | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Організація проекту | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Досвід управління | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Організація взаємодії | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Методи управління | Моніторинг | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Управління персоналом | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Забезпечення якості | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Управління конфігурацією | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Робоча обстановка | Якість роботи | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Кооперація | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Комунікація | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Моральний клімат | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3. Зовнішні обмеження проекту | Пов'язаний із зовнішніми для проекту факторами: наявність ресурсів розробки, умови укладених договорів, форми та особливості взаємодії організацій-учасників проекту ПЗ та ін | Ресурси | Терміни розробки | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Штат проекту | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Фінансування | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Засоби розробки | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Умови договору | Тип договору | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Обмеження договору | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Договірні залежності | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Інтерфейси проекту | Замовник | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Суміжники | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Таксономія ризику забезпечує систематизацію ризиків за вказаними у ній аспектам програмної інженерії і служить основою для розробки методів ідентифікації джерел ризику шляхом інтерв'ювання членів проекту з використанням опитувальника, який відповідає цій таксономією. Опитувальник, заснований на таксономії ризику (для стислості, TBQ, від Taxonomy-Based Questionnaire), є інструментом, застосування якого гарантує охоплення всіх потенційних областей ризику завдяки наявності в ньому питань, що стосуються нижнього рівня таксономії ризику - атрибутів. Кількість і форма запитань може бути різною в залежності від специфіки проекту, обраного методу інтерв'ювання та обробки його результатів. У будь-якому випадку вона повинна орієнтуватися на максимально повне і ефективне вилучення знань членів проекту (включаючи менеджерів, проектувальників, технічний персонал тощо) про ризики конкретного проекту ПЗ. Таблиця 3 - Список 10 головних програмних ризиків
2.3 Методологія оцінки та управління ризиком Дослідження ризику - це тривалий (кілька місяців) процес, в ході якої вживаються спільні зусилля провідною організацією з питань управління ризиком (в рамках країни, певної галузі чи державної структури) і організацією-клієнтом:
Оскільки управління ризиком, віднесено до рівня 3 моделі технологічної зрілості організацій-розробників, оцінка та управління ризиком - це досить віддалена перспектива для вітчизняної програмної інженерії. Процес управління ризиком проекту ПЗ включає наступні чотири стадії:
Процес управління ризиком застосовується незалежно від стадії ЖЦ, на якій знаходиться проект ПЗ, і незалежно від конкретного сценарію і форм організації взаємодії замовника, виконавця, співвиконавців та ін при розробці проекту. Розроблено 3 методології:
2.3.1 Оцінювання ризику ПЗ Методологія SRE пропонує формальний метод ідентифікації, аналізу, контролю та усунення ризику ПЗ, який застосовується спочатку на самій ранній стадії розробки проекту ПЗ (ще до укладення договору з розробником) та періодично в ході всього ЖЦ проекту. Пропоновані SRE функції управління ризиком поділяються на основні і забезпечують. До основних функцій управління ризиком належать:
Виконання функції виявлення ризиків забезпечує систематичний і повне охоплення всіх потенційних областей ризику із застосуванням адекватних інструментів і технологій, зокрема, опитувальника TBQ. Виконання функції специфікації ризику стосується фіксації всіх аспектів ідентифікованого ризику ПЗ. Специфікація ризику являє собою структуру, яка спрощує вирішення завдань пріоритезації ризиків, локалізації джерел та причин виникнення ризиків, визначення методів і зусиль, що вживаються для усунення ризиків у джерелах їх виникнення. Існує багато способів специфікації ризику - від простого твердження про ризик до складного висловлювання з застосуванням умовних виразів виду "ЯКЩО <умова> ТО <наслідки>", зв'язок "І" та ін Вибір того чи іншого способу визначається ефективністю його практичного застосування для проекту і особливостями інструментальної підтримки обробки ризиків. Функція оцінювання ризику полягає у визначенні величини кожного ризику ПЗ, що служить підставою для присвоювання пріоритету ризику та виявлення найбільш важливих на поточний момент ризиків проекту. Існують різні механізми оцінювання величини ризику - від простих суб'єктивних оцінок по 3-бальною шкалою до суворих статистичних вимірювань. Приклади простих механізмів оцінювання величини ризику представлені на рис. 2.
Рис. 2. Матриця трирівневої оцінки ризику Функція консолідації ризиків стосується перетворення розрізнених даних про кожного ризику в концентровані інформаційні блоки для прийняття рішень з управління ризиком. Перетворення даних грунтується на застосуванні прийомів об'єднання, структурування та абстракції даних про окремі ризики ПЗ (що, наприклад, необхідно, у разі виявлення ідентичних ризиків у різних сеансах інтерв'ювання, різних проявів одного і того ж ризику, поглинаючих ризиків від одного джерела, ризиків, мало відрізняються за величиною, та ін.) Функція усунення ризиків полягає у визначенні областей проекту (областей усунення ризику), на яких необхідно зосередити ресурси, а також розробці стратегій і рекомендованих дій, здатних знизити і усунути загрозу успішного виконання проекту. Область усунення ризику являє собою логічну угруповання подібних ризиків, зручну з точки зору ефективного управління цими ризиками. Результатом виконання даної функції є план управління ризиком проекту ПЗ, а також елементи організаційно-методичної, технологічної та інструментальної підтримки управління ризиком проекту ПЗ. Власне усунення кожного ризику здійснюється відповідно до конкретного плану його усунення. До забезпечує функцій при оцінюванні ризику відносяться функції узгодження дій з управління ризиком, їх планування та координації, перевірки та затвердження, а також навчання і створення умов для ефективного господарювання (зберігання, поновлення, видалення) інформації про ризик. Організації, в яких впроваджується процес управління ризиком проектів ПЗ, як правило розробляють власний або адаптують наведений метод оцінювання ризику до потреб та інфраструктурі власних проектів. 2.3.2 Безперервне управління ризиком Ця методологія заснована на певних принципах управління ризиком в ході всього ЖЦ проекту і не залежить від конкретних застосовуваних методів та інструментів оцінки та усунення ризику. Сім принципів управління ризиком такі: Таблиця 3
2.3.3 Колективне управління ризиком Ця методологія визначає додаткові дії в діяльності з управління ризиком, які пов'язані із здійсненням спільного управління ризиком з боку замовника проекту ПЗ та його виконавця. Її застосування забезпечує формування середовища, що містить безліч процесів, методів та інструментів, необхідних для спільної роботи замовника і виконавця над безперервним управлінням ризиком в ході ЖЦ проекту. Методологія заснована на сім принципів управління ризиком (п. 2.3.2.) Та філософії бригадної роботи, до яких додає дві функції - ініціювання колективної роботи і власне колективне управління ризиком. Ці функції виконуються над кожним ризиком послідовно, але дії з управління ризиком проекту в цілому можуть бути як послідовними, так і паралельними, і ітеративними (наприклад, планування для одного ризику може поєднуватися з ідентифікацією іншого). Ініціювати колективну роботу може або замовник, або виконавець. При цьому обидва колективи повинні усвідомлювати необхідність дотримання принципів колективної роботи і відповідальність за її результати. Колективне управління передбачає формалізацію відносин замовник-виконавець і формування узагальнених поглядів на ризики ПЗ. Систематичне і періодичне спільне застосування методів управління ризиком забезпечує одноманітність у розумінні ризиків проекту та їх відносної важливості і отримання узагальненої інформації про ризики, пріоритети, метриках і плани дій. Основні положення трьох методологій, представлених вище, послужили базисом для формування підходу до управління ризиком проектів ПЗ в термінах процесу управління ризиком, його оргструктури і стадій виконання, а також необхідної інструментальної підтримки моделі прийняття рішень при оцінюванні ризику. Один з можливих прикладів використання процесу управління ризиком представлений на рис. 3.
Рис. 3. Приклад застосування процесу управління ризиком 3. Організаційна структура управління ризиком Процес управління ризиком проекту ПЗ починається зі створення координаційної групи (ради) з управління ризиком проекту. Чисельність групи може коливатися від однієї людини з частковою зайнятістю до кількох людей з повною зайнятістю. Кандидатами в координаційну групу можуть бути члени бригади проекту, представники користувачів, виконавців і співвиконавців. Лідером цієї групи є представник найманої незалежної групи експертів, який несе відповідальність за виконання забезпечують функцій планування і координації в рамках методу SRE. Інтерфейс організації-розробника з незалежною групою (в особі її лідера) здійснюється координатором дій з організації-розробника. Він несе відповідальність за підбір (у середовищі проекту) фахівців для інтерв'ювання та проведення брифінгів при відвідуванні організації-розробника незалежною групою експертів. Власне, діяльність з управління ризиком проекту ПО повинна здійснюватися кваліфікованим персоналом, включеним до складу проекту (бригадою проекту), а розподіл ролей і відповідальності за управління ризиком - відбиватися в плані управління ризиком. Один з можливих способів розподілу відповідальності при управлінні ризиком представлений на рис. 4. У даному прикладі кожен член бригади несе відповідальність за безперервний процес ідентифікації, оцінювання та класифікації ризиків та формування планів усунення ризиків. Стверджують ці плани технічні лідери бригади проекту. Відповідальність за відстеження стану ризиків проекту може бути покладена і на окрему особу або групу осіб у проекті. Менеджер проекту проводить ревізію і інтеграцію інформації про ризики, призначення відповідальних за ризики та плани усунення, а також забезпечує взаємодії із зовнішнім оточенням проекту. Бригада проекту періодично надає звіти про свою діяльність керівництва організації-замовника. Ці результати стосуються стану групи ризиків найбільшої важливості (наприклад, першої десятки або, в загальному випадку, першою Н-ки ризиків) і планів з їх усунення. Крім того, надається інформація про ефективність процесу управління ризиком (наприклад, дані про інтенсивність ідентифікації нових ризиків по відношенню до інтенсивності усунення ризиків та ін.) Детальна ревізія цієї інформації проводиться менеджером проекту на періодичній і подієвої основі.
Рис. 4. Розподіл ролей при управлінні ризиком Особи, які здійснюють функції управління ризиком проекту ПЗ, повинні володіти знаннями в галузі програмної інженерії, проблемної області, для якої розробляється ПЗ, а також знати принципи управління ризиком та володіти методами та інструментами управління ризиком. Вважається, що людина володіє необхідними знаннями для управління ризиком, якщо:
Якщо не виконується хоча б одна з перерахованих умов, член проекту повинен мати можливість поповнити свої знання шляхом навчання. Способи придбання необхідних знань такі:
4. Розробка плану управління ризиком Управління ризиком конкретного проекту ПЗ здійснюється відповідно до плану управління ризиком, складеними з урахуванням рекомендацій, отриманих від незалежної групи експертів та зафіксованих у підсумковому звіті про проведення оцінки ризику проекту ПЗ. План управління ризиком проекту ПО визначає, яким чином процес управління ризиком буде виконуватися в рамках конкретного проекту розробки ПЗ, і вказує процеси, дії, етапи робіт, методи та інструменти, використовувані членами бригади проекту, відповідальними за управління ризиком проекту ПЗ. Цей план може бути частиною плану управління ризиком системного рівня, частиною плану управління проектом або самостійним планом. Вибір того чи іншого способу планування залежить від обсягу та складності проекту, складу і розмірів бригади проекту, а також загальних принципів планування, яким слідує організація, яка здійснює управління ризиком. План управління ризиком може піддаватися модифікації при появі нових інструментів, методів або інших елементів управління ризиком, необхідних для управління ризиком конкретного проекту. Поточний список ризиків і плани по їх усуненню не рекомендується включати в план управління ризиком проекту ПЗ, щоб не довелося безперервно його коригувати.
Рис. 5. Блок-схема прийняття рішення при плануванні усунення ризику Таблиця 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. Обчислення комбінованого ризику по всіх елементах. Аналогічним чином може бути встановлений комбінований ризик проекту в цілому шляхом визначення співвідношення ризиків всіх атрибутів таксономії. Будь ласка, не зберігайте тестовий текст. |