
- •Технологія програмування та створення програмних продуктів
- •(частина 2)
- •Візуальне моделювання на основі UML
- •MSF – Модель проектної групи (v. 3.1)
- •Анотація
- •1. Основи моделі проектної групи MSF
- •Основні принципи
- •Розподіл відповідальності при фіксації звітності
- •Наділення членів команди повноваженнями
- •Концентрація на бізнес-пріоритетах
- •Єдине бачення проекту
- •Прояв гнучкості і готовність до змін
- •Заохочення вільного спілкування
- •2. Ключові концепції
- •Команда соратників
- •Фокусування на потребах замовника
- •Націленість на кінцевий результат
- •Установка на відсутність дефектів
- •Прагнення до самовдосконалення
- •Зацікавлені команди працюють ефективно
- •3. Випробувані методики
- •Малі багатопрофільні проектні групи
- •Колективна робота
- •Загальна участь в проектуванні
- •4. Огляд моделі команди MSF
- •Задоволені замовники
- •Досягнення результату в рамках проектних обмежень
- •Створення продукту відповідно до специфікації
- •Схвалення випуску продукту лише після того, як всі дефекти виявлені і відлагоджені
- •Підвищення споживчої цінності продукту
- •Безпроблемне впровадження і супровід продукту
- •Ролеві кластери моделі проектної групи
- •I. Ролевий кластер "Управління продуктом"
- •Області компетенції
- •1. Планування продукту
- •2. Бізнес-віддача
- •3. Представлення інтересів замовника
- •4. Маркетинг
- •II. Ролевий кластер "Управління програмою"
- •Області компетенції
- •1. Управління проектом
- •2. Вироблення архітектури рішення
- •3. Контроль виробничого процесу
- •4. Адміністративні служби
- •III. Ролевий кластер "Розробка"
- •Області компетенції
- •1. Технологічне консультування
- •2. Проектування і здійснення реалізації
- •3. Розробка програмних рішень
- •4. Розробка інфраструктури
- •IV. Ролевий кластер "Тестування"
- •Області компетенцій
- •1. Планування тестів
- •2. Розробка тестів
- •3. Звітність про тести
- •V. Ролевий кластер "Задоволення споживача"_
- •Області компетенцій
- •1. Загальнодоступність
- •2. Інтернаціоналізація
- •3. Забезпечення технічної підтримки
- •4. Навчання користувачів
- •5. Зручність експлуатації (ергономіка)
- •6. Графічний дизайн
- •VI. Ролевий кластер "Управління випуском"
- •Області компетенції
- •1. Управління випуском
- •2. Інфраструктура
- •3. Супровід
- •4. Бізнес-процеси
- •Масштабування моделі проектної групи
- •Групи напрямів
- •Функціональні групи
- •Об'єднання ролей
- •Ескалація і підзвітність
- •Модель проектної групи немає організаційної структури
- •Зовнішня координація – на кому лежить відповідальність?
- •Висновок
- •MSF: Модель процесів
- •Анотація
- •Короткий огляд методології
- •Введення
- •Інші моделі процесів
- •Краще з двох світів
- •Базові принципи MSF
- •Єдине бачення проекту
- •Проявляйте гнучкість – будьте готові до змін
- •Концентруйтеся на бізнес - пріоритетах
- •Заохочуйте вільне спілкування
- •Ключові концепції моделі процесів MSF
- •Замовники
- •Зацікавлені сторони (учасники)
- •Що є рішення?
- •Створення базових версій
- •Рамки проекту
- •Управління компромісами
- •Трикутник компромісів
- •Матриця компромісів проекту
- •Характеристики моделі процесів MSF
- •Підхід, заснований на віхах
- •Характеристики підходу, заснованого на віхах
- •Головні і проміжні віхи
- •Віхи як точки синхронізації
- •Віхи як орієнтири виробничої відповідальності
- •Провідні ролі різних фаз
- •Аналіз пройдених віх
- •Ітеративний підхід
- •Характеристики ітеративного підходу
- •Випуск версій
- •Створення "живої" документації
- •Ранні базові версії, відкладені підсумкові версії
- •Щоденні білди
- •Управління конфігураціями проекту
- •Рекомендації для випуску версій рішення
- •Створюючи плани, передбачайте версіонування
- •Перш за все, поставляйте базову функціональність
- •Вибирайте пріоритети, враховуючи ризики
- •Здійснюйте часті ітерації розробки
- •Інституціюйте процедури контролю змін в проекті
- •Цілісний погляд на розробку і впровадження
- •Переваги інтегрованої моделі процесів
- •Зосередження на потребах підприємства
- •Покращена підтримка розробки веб-приложений
- •Покращена підтримка веб-сервісів
- •Поліпшення взаємодії з командою супроводу
- •Зауваження про використання інтегрованої моделі процесів
- •Тривалість фаз не однакова
- •Діяльність може виходити за межі однієї фази
- •Проекти, обмежені розробкою застосування або впровадженням інфраструктури
- •Фази і віхи моделі процесів MSF
- •Фаза вироблення концепції
- •Введення
- •Віха "Концепція затверджена"
- •Результати
- •Основні завдання проектної групи на фазі вироблення концепції
- •Проміжні віхи, що рекомендуються
- •Ядро проектної групи сформоване
- •Чорновий варіант концепції проекту складений
- •Фаза планування
- •Введення
- •Віха "Плани проекту затверджені"
- •Результати
- •Основні завдання проектної групи на фазі планування
- •Проміжні віхи, що рекомендуються
- •Верифікація технологій
- •Базова версія функціональної специфікації створена
- •Базова версія звідного плану проекту створена
- •Базова версія звідного календарного графіка проекту створена
- •Середовища розробки і тестування розгорнені
- •Фаза розробки
- •Введення
- •Віха "Розробка завершена"
- •Результати
- •Основні завдання проектної групи на фазі розробки
- •Проміжні віхи, що рекомендуються
- •Концепція підтверджена
- •Білд n завершений, білд n+1 завершений...
- •Фаза стабілізації
- •Введення
- •Віха "Готовність рішення затверджена"
- •Результати
- •Основні завдання проектної групи на фазі стабілізації
- •Проміжні віхи, що рекомендуються
- •Точка конвергенції
- •Точка досягнення нуля
- •Версії-кандидати
- •Контрольне тестування завершене
- •Тестування прийнятності для споживачів завершене
- •Пілотне впровадження завершене
- •Фаза впровадження
- •Введення
- •Віха "Впровадження завершене"
- •Результати
- •Основні завдання проектної групи на фазі впровадження
- •Проміжні віхи, що рекомендуються
- •Ключові компоненти розгорнені
- •Впровадження на місцях завершене
- •Упроваджене рішення стабілізоване
- •Методики моделі процесів MSF, що рекомендуються
- •Стимулювання винахідливості для розширення функціональності й обмеження ресурсів
- •Фіксування календарного графіка
- •Календарне планування на невизначене майбутнє
- •Використання паралельно працюючих компактних команд
- •Розбиття великих проектів на реальні частини
- •Отримання уроків з пройдених віх
- •Використання прототипіювання
- •Використання частих білдів і швидких тестів
- •Часті ітерації розробки і впровадження
- •Уникання розповзання рамок проекту
- •Оцінка з низу до верху
- •Інтеграція представлених проектною групою оцінок
- •Застосування A
- •Зміни в порівнянні з попередньою версією MSF
- •Висновок
- •Література
- •Анотація
- •Введення
- •Основні відомості про ризики
- •Базові принципи:
- •1. Гнучкість і постійна готовність до змін
- •2. Вільне спілкування
- •3. Отримання зі всього уроків
- •4. Розподіл відповідальності при фіксації звітності
- •Ключові концепції:
- •Найбільш ефективним є превентивне управління ризиками
- •2. Заохочення до виявлення ризиків
- •3. Постійна оцінка ризиків
- •4. Підтримка відкритого спілкування
- •5. Постійний аналіз ризиків
- •6. Кількість ризиків не характеризує реальне положення речей
- •Планування управління ризиками
- •Процес управління ризиками
- •Загальне уявлення
- •Етап 1. Виявлення ризиків
- •Введення
- •Початкові дані
- •Кроки по виявленню ризиків
- •Структурований підхід
- •Класифікація ризиків
- •Формулювання ризиків
- •Результати
- •Етап 1. Аналіз і пріоритезація ризиків
- •Введення
- •Мета
- •Початкові дані
- •Процес аналізу ризиків
- •Вірогідність ризику
- •Загроза ризику
- •Очікувана величина ризику
- •Додаткові кількісні методики
- •Результати
- •Головна таблиця ризиків
- •Інші методи проведення аналізу
- •Документ опису ризиків
- •Список головних ризиків
- •Деактивація ризиків
- •Планування ризиків_
- •Введення
- •Початкові дані
- •Заходи
- •Дослідження
- •Ухвалення
- •Уникнення
- •Перенесення
- •Запобігання
- •Пом'якшення наслідків (реагування)
- •Календарне планування
- •Результати
- •Діяльність по управлінню ризиками
- •Документування планів
- •Оновлення плану і календарного графіка проекту
- •Моніторинг ризиків_
- •Початкові дані
- •Заходи щодо моніторингу
- •Звітність про стан ризиків
- •Результати
- •Коректування ситуації_
- •Мета
- •Початкові дані
- •Дії з коректування ситуації
- •Результати
- •Витягання уроків з ризиків
- •Введення
- •Типи отримуваних уроків
- •Управління витяганням уроків
- •Контекстна класифікація ризиків
- •База знань про ризики
- •Досягнення зрілості в управлінні знаннями про ризики
- •Управління ризиками як складова частина життєвого циклу проекту_
- •Управління ризиками на підприємстві
- •Створення культури управління ризиками
- •Управління портфелем проектів_
- •Висновок
- •MSF: Дисципліна управління проектами
- •Анотація
- •Введення
- •Базові принципи MSF
- •Пр.1: Розподіл відповідальності при фіксації звітності
- •Пр.2: Наділення членів команди повноваженнями
- •Ключові концепції
- •1) Дисципліни MSF
- •2) Поняття управління проектом
- •3) Менеджмент проекту і менеджер проекту
- •4) Управління проектами і специфічні IT-процеси
- •Особливості управління проектами в MSF
- •Роль менеджера проекту покладається на кластер "Управління програмою"
- •Взаємодія "Управління програмою" з лідерами командних ролей
- •A. Функціональні групи
- •B. Групи напрямів
- •Масштабування функцій управління проектом
- •Обов'язки по управлінню проектами
- •Лідери груп
- •Кластер "Управління програмою"
- •Управління великими і складними проектами
- •Адміністративні служби проекту
- •Звітність перед замовником
- •Рекомендації проектним групам
- •Управління рамками проекту
- •Визначення рамок на етапі вироблення концепції
- •Рамки рішення і рамки проекту
- •Визначення рамок (scope definition)
- •Управління змінами рамок (scope change control)
- •Підготовка планів
- •Повторне використання документів
- •Плани проекту
- •Ієрархічна структура робіт
- •Відповідність між WBS, функц. специфікаціями і зведеним планом
- •Створення WBS
- •Рекомендації по декомпозиції роботи
- •Оцінка знизу вгору
- •Інтеграція представлених проектною групою оцінок
- •Формування реалістичних очікувань
- •Невизначеність і точність оцінок
- •Оцінюйте завдання нижнього рівня декомпозиції
- •Аналіз PERT
- •Рекомендації по складанню календарного графіка
- •1) Впорядкування завдань
- •2) Обмеження часу
- •3) Вибір пріоритетів, з врахуванням ризиків
- •Створення часових буферів
- •Висновок
- •MSF: Дисципліна "Управління підготовкою"
- •Анотація
- •Вступ
- •Базові принципи
- •Пр.1: Заохочення вільного спілкування
- •Пр.2: Інвестування в якість
- •Пр.2: Отримання уроків
- •Пр.3: Гнучкість та готовність до змін
- •Ключові концепції
- •1) Інвентаризація наявних знань
- •2) Прагнення до самовдосконалення
- •3) Підготовка повинна бути перманентним процесом
- •Випробувані методики
- •1) Планування підготовки
- •Оцінка і моніторинг професійного рівня і індивідуальних цілей
- •Відноситеся до пропусків в підготовці як до ризиків
- •Огляд процесу Управління підготовкою
- •1) Визначення:
- •2) Оцінювання:
- •3) Коригування:
- •4) Осмислення:
- •Превентивне Управління підготовкою
- •Підготовка впродовж життєвого циклу ІТ
- •Кроки процесу Управління підготовкою
- •Крок 1: Визначення
- •Скл. 1: Проектні сценарії
- •Скл. 2: Кваліфікаційні вимоги
- •Скл. 3: Професійні навики
- •Крок 2: Оцінювання
- •Оцінка знань, умінь, здібностей
- •Специфікація процесу оцінювання
- •Збір і обробка даних
- •Обробка результатів оцінювання
- •Аналіз невідповідностей
- •Створення планів навчання
- •Крок 3: Коригування
- •Навчання
- •Моніторинг прогресу
- •Крок 4: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок
1 (низька) |
До 1% |
Зрушення на 1 |
Невелика втрата |
|
|
тиждень |
продуктивності |
2 (середня) |
До 5% |
Зрушення на 2 тижні |
Помірне зниження |
|
|
|
продуктивності |
3 (висока) |
До 10% |
Зміщення на 1 |
Серйозний збиток |
|
|
місяць |
для продуктивності |
4 (критична) |
Від 10% |
Зрушення більше 1 |
Завдання не може |
|
|
міс. |
бути виконана |
Система оцінки дій повинна відображати політику і цінності організації і проектної групи. Збиток розміром $10,000 може бути терпимим для однієї проектної групи або організації, але абсолютно неприпустимим для іншої. Для обліку ризиків з дуже малою вірогідністю (але великою загрозою) необхідно, щоб шкала погроз була достатньо широкою, такою, що включає катастрофічні результати.
Очікувана величина ризику
Очікувана величина ризику (risk exposure) показує загальний рівень небезпеки ризику, вбираючи в одну числову величину інформацію про можливість реалізації ризику і рівень його загрози. Проектна група може потім використовувати цю величину для пріоритезації ризиків. У простому випадку кількісного аналізу ризиків очікувана величина обчислюється як твір вірогідності ризику і його загрози.
Коли для оцінки вірогідності і загрози використовуються шкали, може бути корисним створити матрицю можливих поєднань значень цих шкал і розділити ризики по категоріях – на малих, середніх і великих. Наприклад при використанні тризначної шкали для вірогідності і загрози, можливі значення очікуваної величини можуть бути представлені такою таблицею:
Вірогідність / загроза Нізкая=1 Средняя=2 Високая=3
Високая=3 |
3 |
6 |
9 |
Средняя=2 |
2 |
4 |
6 |
Нізкая=1 |
1 |
2 |
3 |
Перевага табличної форми представлення рівнів ризиків полягає в тому, що в звітах для спонсорів і інших зацікавлених осіб різні групи ризиків можуть бути виділені різними квітами. Наприклад, червоним – великі ризики (у правому верхньому кутку), жовтим – середні ризики уздовж діагоналі, і зеленим – малі ризики в нижньому лівому кутку. Таке розділення дуже чітко і що легко розуміється ("великий ризик" сприймається легше, ніж "велика очікувана величина").
Додаткові кількісні методики
Оскільки кінцевою метою аналізу ризиків є допомога в ухваленні необхідних проектних рішень, повинен бути вибраний метод пріоритезації ризиків, відповідний для даного проекту і зручний для проектної групи, зацікавлених осіб, сумісний з існуючою корпоративною інфраструктурою управління ризиками (засобами і процесами). У деяких проектах може бути доречним використання зважених багато-параметричних методів в цілях обліку таких додаткових чинників, як тимчасові обмеження, величина потенційно можливої вигоди, надійність імовірнісних оцінок, величина матеріальних або інформаційних активів і так далі нижче в таблиці представлений приклад такої зваженої матриці пріоритезації, що обчислюється за формулою:
97
Очікувана величина ризику = 0.5(вірогідність x загроза) – 0.2(термін) +0.3(витрати на реалізацію x вірогідність успішного управління), що враховує не тільки вірогідність і загрозу ризику, але також часові межі і витрати на ефективне управління.
Цей метод дозволяє врахувати в очікуваній величині ризику критичність тимчасового обмеження (необхідного терміну здійснення плану по управлінню і пом'якшенню) і вартість і ефективність плану. Таким чином, ці чинники виявляться взятими до уваги в процесі ухвалення рішення. Такий узагальнений підхід дозволяє проектній групі пріоритезувати ризики з урахуванням будь-якої поставленої в проекті мети.
Очікувана |
Вірогідність |
Загроза (у |
Термін |
Витрати на |
Вірогідність |
величина |
|
тис. Дол.) |
(when |
реалізацію (у |
успішного |
ризику |
|
|
needed) |
тис. Дол.) |
управління |
|
|
|
(тижні) |
|
|
125.025 |
0.5 |
500 |
1 |
2 |
0.5 |
83.596 |
0.84 |
200 |
4 |
4 |
0.33 |
37.64 |
0.33 |
200 |
2 |
20 |
0.84 |
4.9816 |
0.33 |
30 |
4 |
3 |
0.84 |
Вибір "правильного" методу або поєднання методів залежить від розумності тієї або іншої форми компромісу між витратою зусиль на аналіз ризиків і небезпекою помилковою або нечіткою пріоритезації. Завжди слід пам'ятати, що аналіз не самоціль – він потрібний для ухвалення правильних рішень. Тому на кількісні підходи до пріоритезації ризиків слід дивитися в контексті наявних бізнес-цілей, можливостей і перевірених управлінських методик. Ухвалюванні рішення не повинні автоматично диктуватися отриманими кількісними оцінками пріоритетів.
Результати
Аналіз ризиків надає проектній групі пріоритезований список ризиків, який необхідний на етапі планування. Дисципліна управління ризиками MSF називає його головною таблицею ризиків (master risk list). Детальна інформація про ризики, що включає умови проекту, контекст, першопричину ризику, використані в процесі аналізу значення оцінних величин і ін., може бути винесена для кожного ризику в окремий документ.
Головна таблиця ризиків
Головна таблиця ризиків містить умову виникнення ризику, потенційний ефект ризику (наслідок) і інформацію, використовувану для пріоритезації (таку як вірогідність, загроза і очікувана величина). Будучи відсортованої по убуванню очікуваної величини ризиків (або по іншому критерію, використовуваному для ранжирування), ця таблиця служить базисом для пріоритезації ризиків на етапі планування. Приклад головної таблиці ризиків при використанні двох-параметричної оцінки (вірогідність і загроза) приведений нижче.
Пріоритет |
Причина |
Наслідок |
Вірогідність |
Загроза |
Очікувана |
|
|
|
|
|
величина |
1 |
Затягнутий часовий |
Втрата |
80% |
3 |
2.4 |
|
графік проекту |
фінансування в |
|
|
|
|
|
кінці року |
|
|
|
2 |
Відсутність |
Випуск |
45% |
2 |
0.9 |
|
стандартів |
продукту, що |
|
|
|
|
кодування для |
містить помилки |
|
|
|
|
|
|
|
|
98 |
нової мови
програм-мирования
3 |
Відсутність |
Деякі вимоги не |
30% |
2 |
0.6 |
|
специфи-кации |
будуть |
|
|
|
|
вимог письмово |
реалізовані |
|
|
|
Мала загроза = 1, середня загроза = 2, сильна загроза = 3 Очікувана величина = вірогідність х загроза
Рівень деталізації головної таблиці ризиків відповідає рівню деталізації початкового списку ризиків. Ця таблиця є "живим" документом, лежачим в основі безперервного процесу управління ризиками. Вона повинна постійно коректуватися і доповнюватися впродовж етапів аналізу, планування і моніторингу.
Головна таблиця ризиків – це фундаментальний документ, що забезпечує активний і превентивний процес управління ризиками. Вона допомагає проектній групі в ухваленні рішень, надаючи основу для:
•Процесу пріоритезації;
•Виявлення критичних мерів, яких необхідно зробити;
•Виявлення взаємозалежностей.
Нижче приведений список елементів, що включаються в головну таблицю ризиків.
Метод, використаний для визначення очікуваної величини ризику, повинен бути чітко описаний в плані управління ризиками. Вироблювані в нім обчислення повинні відображати точку зору проектної групи на оцінку важливості різних чинників.
Елемент |
Призначення |
Обов'язковість |
Формулювання ризику |
Чіткий опис ризику |
Обов'язковий |
Вірогідність |
Кількісна міра можливості |
Обов'язковий |
Загроза |
Кількісна міра серйозності |
Обов'язковий |
|
збитку або вартості |
|
|
потенційної можливості |
|
Критерій пріоритезації |
Єдина міра значущості |
Обов'язковий |
Пріоритет |
Пріоритезація управління |
Обов'язковий |
Відповідальна особа |
Забезпечення проведення |
Обов'язковий |
|
планових заходів відносно |
|
|
ризику |
|
План запобігання |
Опис превентивних мерів |
Обов'язковий |
План реагування |
Опис виправних заходів |
Обов'язковий |
(пом'якшення наслідків) і |
|
|
його трігери |
|
|
Першопричина |
Початкова посилка появи |
Бажаний |
|
ризику |
|
Приношуваний збиток |
Забезпечення коректності |
Бажаний |
|
оцінки загрози |
|
Контекст |
Початкові міркування |
Бажаний |
|
проектної групи при |
|
|
виявленні ризику |
|
99
Час для реалізації |
Принципові тимчасові |
Бажаний |
|
обмеження на реалізацію |
|
|
планових заходів |
|
Інші методи проведення аналізу
Деякі проектні групи можуть включити в свою діяльність додаткові рівні аналізу для забезпечення кращого розуміння ризиків проекту. Необхідні додаткові методики описуються в підручниках по менеджменту і управлінню ризиками. Такі прийоми як аналіз дерев рішень, причинний аналіз, аналіз по Парето, імітація і аналіз чутливості практично довели свою ефективність для кількісного оцінювання ризиків. Вирішення про застосування цього додаткового інструментарію повинне бути засноване на упевненості проектної групи в тому, що його внесок в процес пріоритезації або планування окупить додаткові витрати.
Документ опису ризиків
Під час аналізу ризиків (як і під час подальшого планування заходів, що відносяться до ризику) зручно звести всю інформацію, що має відношення до даного ризику, в один документ, званий документом опису ризиків (risk statement form).
Цей документ зазвичай містить дані з головної таблиці ризиків, які доповнюються інформацією, необхідною для проведення процесу управління ризиком. Документи опису ризиків доречно розглядати окремо від головної таблиці ризиків у випадку, якщо планові заходи щодо управління ризиками доручені не вхідним в проектну групу особам або колективам.
У наступній таблиці представлена інформація, яку проектна група повинна врахувати при складанні документа опису ризиків.
Елемент |
Призначення |
Ідентифікатор ризику |
Унікальне ім'я ризику (використовується для моніторингу і |
|
звітності) |
Джерело ризику |
Загальна вказівка на початковий чинник ризику |
|
(використовується для пошуку першопричин) |
Умова виникнення ризику |
Опис існуючої умови/причини потенційного збитку (перша |
|
частина формулювання ризику) |
Наслідок ризику |
Опис негативного ефекту, що виникає при реалізації ризику |
|
(друга частина формулювання ризику) |
Вірогідність ризику |
Імовірнісна величина більше 0, але менше 100%, вказуюча |
|
на "шанси" реалізації ризику |
Класифікація загрози |
Загальна характеристика типу дії, до якої може призвести |
ризику |
ризик |
Загроза ризику |
Кількісна міра загрози ризику. Може бути як грошовою |
|
величиною, так і просто значення з деякої прийнятої шкали |
|
оцінки загрози |
Очікувана величина ризику |
Загальна міра важливості ризику, що бере до уваги як |
|
вірогідність ризику, так і його загрозу |
Контекст ризику |
Додаткова інформація, що прояснює природу ризику і |
|
пов'язані з ним обставини |
|
100 |