Керівник проекту + ризик = ?
Для початку визначимо що ми будемо розуміти під терміном ризику. Ризик це певна подія, що здатна вплинути на хід проекту. Основна його характеристика – ймовірність виникнення. Ризик, який реалізувався будемо розуміти під проблемою. Слід розрізняти поняття – вирішення проблеми та вирішення задачі.
В більшості випадків керівники проектів (розглянемо розробку програмного проекту) не враховують ризик через те, що виявлений ризик він сприймає як недолік його роботи. Але ж значно простіше внести зміни у проект у процесі відладки, ніж після його здачі. І продукт буде працювати стабільніше.
Ризик виникає із зародженням проекту. Він виникає за наступних умов: неправильно оцінений розмір та складність задач розробки, необхідні ресурси; використовуються недосконалі інструменти розробки проекту; проект розробляють не фахівці; визначення строків закінчення проекту проходить без врахування структури проекту та його складності; існування сильної залежності від конкретних людей; постійно змінюються вимоги до розробки; розміри проекту не відповідають його бюджету.
При роботі із програмними проектами можна виділити наступні типи ризиків: технічні ( можливе використання нових технологій, чи модифікація старих), програмні ( використання засобів та інструментів розробки третіми сторонами), вартісні ( проблеми фінансування проекту). Існує ще ряд ризиків , проте вони не є такими критичними ( наприклад, ризик невдоволення замовника та ін.) і в принципі їх можна ігнорувати. Способи зменшення ризиків можна звести до наступних :
1. Запобігання виникненню ризиків. Тут важливо розуміти, що зусилля направляється на мінімізацію значення ризику, а не на його ліквідацію. Ставиться завдання – зменшити його до прийнятного рівня, при врахуванні закону компенсації (необхідно зменшити один компонент, щоб збільшити інший).
2. Погодитись з існуючими ризиками. Це передбачає пасивне очікування реалізації ризику - створення проблеми. Можна розробити серію заходів після впровадження проекту на мінімізацію ризику.
Для виявлення та зменшення ризику існує два основних підходи: аналітичний та програмний. Під програмним необхідно розуміти експертну систему, що реалізована програмно, яка вкаже значення ризику та способи його зменшення. На теренах України та Росії таким продуктом може бути система ГРИФ. Вона найбільш адаптована до особливостей вітчизняних інформаційних систем. При потребі можна використати алгоритм ГРИФ у відповідності до ліцензійного погодження. Недоліком такого підходу є те, що програмний продукт може не дати реальних та точних показників через свою універсальність, а створювати систему оцінки ризиків доцільно тільки для великих глобальних систем.
Іншим підходом до виявлення ризиків є залучення фахівців із галузі захисту інформації. Ті в свою чергу, базуючись на експертному досвіді, можуть провести аналіз за такими методологіями : історичний( процес порівняння проекту з аналогами), аналітичний (аналіз за схемою “причина-наслідок”), наради (використання методу мозкового штурму), індивідуальне інтерв’ю ( проведення інтерв’ю із керівництвом та розробниками проекту). Особливістю даного підходу є те, що точність проведення такого аналізу залежить від досвіду експерта, який проводить аналіз. Загальний алгоритм проведення аналізу захищеності включає в себе такі кроки:
• Ініціювання процедури аудиту. Аудит проводиться не по ініціативі аудитора, а по ініціативі керівництва проекту.
• Збір інформації аудиту. Сюди входить така інформація як організаційна структура користувачів та обслуговуючих підрозділів, інформація про власника та розробників проекту, склад та структура проекту та системи захисту інформації і т.д.
• Аналіз даних. Сюди може входити оцінка ризиків, що пов’язані із реалізацією загроз безпеки, аналіз механізмів безпеки організаційного рівня, документації по забезпеченню режиму інформаційної безпеки і т.д.
• Генерація рекомендацій. На цьому кроці після проведення аналізу генерується перелік рекомендацій по вдосконаленню (заміни) аспектів, що впливають на загальний рівень безпеки системи.
Після визначення існуючих ризиків необхідно їх проранжувати, визначити пріоритет. Як результат проведення аудиту керівництву надається звіт куди повинні бути включені наступні компоненти: ціль проведення такого аудиту; які є вразливості проекту, їх опис; способи ліквідації вразливостей, вартість такої ліквідації.
Зазвичай процес аналізу проекту на наявні ризики проводиться на етапі тестування, і обов’язково до здачі його замовнику. На мінімізацію ризиків необхідно залишати щонайменше 10% ресурсу бюджету проекту. Процес визначення ризиків повинен проводитись на всьому етапі життя реалізованого проекту. Це дозволить запобігти нестандартним та небажаним ситуаціям.
Recent comments
13 years 4 weeks ago
13 years 6 weeks ago
13 years 40 weeks ago
13 years 47 weeks ago
14 years 33 weeks ago
15 years 4 weeks ago
15 years 10 weeks ago
15 years 15 weeks ago
15 years 17 weeks ago
15 years 32 weeks ago