Контрольні запитання

1. Як визначаються основні властивості проекту.

2. Якими засобами MS Project треба користуватися для створення плану проекту.

3. Якими засобами MS Project треба користуватися для побудуви календаря проекту

4. Якими засобами MS Project треба користуватися для організацыъ списку завдань проекту.

5. Що таке і як позначити основні віхи проекту.

6. Яку інформацію містить Діаграма Ганта.

7. Якими засобами MS Project треба користуватися для створення списку ресурсів і призначення їх на виконання завдань проекту.

8. Що таке критичний шлях проекту.

9. Якими засобами MS Project треба користуватися для отримання звітів з стану та виконання проекту .

Комп’ютерний практикум №9 .«розробка плану управління ризиками іт проекту» Завдання комп’ютерного практикуму

Порядок виконання роботи

1. Вивчити пропонований теоретичний матеріал.

4. Побудувати список можливих ризиків з вказівкою назви ризику, його опис і типу.

5. Провести аналіз ризиків.

6. Описати стратегію планування ризиків.

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

Зміст звіту

У звіті слід вказати:

1. Мета роботи

2. Введення

3. Програмно-апаратні засоби, використовувані при виконанні роботи.

4. Основну частину (опис самої роботи), виконану згідно вимогам до результатів виконання лабораторного практикуму (п.2).

5. Висновок

6. Список використовуваної літератури

Теоретичні положення та практичні настанови

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

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

1. Ризики для проекту, які впливають на графік робіт або ресурси, необхідні для виконання проекту.

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

3. Бізнес-ризики, що відносяться до організації-розробника або постачальників.

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

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

Таблиця 9.4 - Можливі ризики програмних проектів

Ризик	Тип ризику	Опис ризику
Текучість розробників	Ризик для проекту	Досвідчені розробники покидають проект до його завершення
Зміна в управлінні організацією	Ризик для проекту	Організація міняє свої пріоритети в управлінні проектом
Неготовність апаратних засобів	Ризик для проекту і для продукту, що розробляється	Апаратні засоби, які необхідні для проекту, не поступили вчасно або не готові до експлуатації
Зміна вимог	Ризик для проекту і для продукту, що розробляється	Поява великої кількості непередбачених змін у вимогах, що пред'являються до того, що розробляється ПО
Затримка в розробці специфікації	Ризик для проекту і для продукту, що розробляється	Специфікації основних інтерфейсів підсистем не поступили до розробників відповідно до графіка робіт
Недооцінка розміру системи, що розробляється	Ризик для продукту, що розробляється	Розмір системи значно перевищив первинну оцінку
Недостатня эффективностьCASE-средств	Бізнес-ризик	CASE-средства, призначені для підтримки проекту, виявилися менш ефективними, чим очікувалося
Зміни в технології розробки ПО	Бізнес-ризик	Основні технології побудови програмної системи замінюються новими
Поява конкуруючого програмного продукту	Ризик для проекту	На ринку програмних продуктів до закінчення проекту з'явилася конкуруюча програмна система

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

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

2. Аналіз ризиків. Оцінюється вірогідність і послідовність появи ризикових ситуацій.

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

4. Моніторинг ризиків. Постійне оцінювання вірогідності ризиків і виконання заходів щодо пом'якшення наслідків прояву ризикових ситуацій.