- •Завдання комп’ютерного практикуму
- •Комп’ютерний практикум №1-2 .«розробка бізнес - плану іт проекту» Завдання комп’ютерного практикуму
- •Теоретичні положення та практичні настанови Структура бізнес - плану
- •Загальна характеристика бізнес – плану
- •Структура та написання бізнес – плану
- •Розділ 1: резюме.
- •Розділ 2: характеристика підприємницької діяльності та її можливості.
- •Розділ 3: конюнктура ринку.
- •Розділ 4: маркетинг і збут
- •Розділ 5: управління і власність
- •Розділ 6: план виробництва
- •Розділ 7: фінансовий план та стратугія його забезпечення
- •Розділ 8: оцінка можливих ризиків
- •Додатки
- •Перелік інформації, яка необхідна перед написанням бізнес – плану
- •Приклад бізнес-плану створення Інтернет – провайдера „ІнтернетПровайдер ”
- •1.7. Структура управління:
- •1.9. Спеціалізація діяльності:
- •1.10. Керівники підприємства та їх службові телефони:
- •Комп’ютерний практикум №3 «розробкастатуту іт проекту» Завдання комп’ютерного практикуму
- •Теоретичні положення та практичні настанови Статус Документу
- •Загальні відомості про проект
- •Функції членів команди проекту
- •Взаємодія сторін
- •Періодична звітність за проектом
- •Управління проблемами по ходу проекту
- •Управління змінами по ходу проекту
- •Управління проектною документацією
- •1.1 Формулювання цілей проекту
- •1.2 Розрахунок очікуваних переваг і визначення верхньої межі бюджету проекту
- •1.3 Оцінка здійсненності проекту
- •1.4 Формування команди проекту
- •2. Аналіз інформаційних потреб
- •2.1 Створення призначеної для користувача специфікації іс
- •2.2 Розробка плану перевірки придатності іс.
- •2.3 Ухвалення рішення про спосіб створення системи
- •2.4 Підготовка і проведення тендеру на постачання/створення елементів іс.
- •3. Технічний дизайн
- •7 Впровадження системи і її експлуатація
- •Теоретичні положення та практичні настанови
- •Терміни і визначення
- •Методика управління проектами за допомогою Microsoft Project . Основні можливості Планування проекту
- •Створення нового проекту
- •Призначення ресурсів
- •Ведення витрат
- •Визначення критичного шляху
- •Збереження плану по ходу виконання
- •Відстежування і управління ходом виконання
- •Контрольні запитання
- •Комп’ютерний практикум №9 .«розробка плану управління ризиками іт проекту» Завдання комп’ютерного практикуму
- •Теоретичні положення та практичні настанови
- •Визначення ризиків
- •Аналіз ризиків
- •Планування ризиків
- •Моніторинг ризиків
- •Контрольні запитання
- •Література
Планування ризиків
Планування полягає у визначенні стратегії управління кожним значущим ризиком, відібраним для моніторингу після аналізу ризиків. Тут також не існує загальноприйнятих підходів для розробки таких стратегій - багато що грунтується на "чутті" і досвіді менеджера проекту. У табл. 9.7 показані можливі стратегії управління основними ризиками, приведеними в табл. 9.6.
Таблиця 9.7 - Стратегії управління ризиками (приклад не копіювати)
Ризик |
Стратегія |
Фінансові проблеми організації |
Підготувати короткий документ для керівництва організації, що показує важливість даного проекту для досягнення фінансових цілей організації |
Проблеми некваліфікованого персоналу |
Попередити замовника про потенційні труднощі і можливу затримку проекту, розглянути питання про покупку компонентів системи |
Хвороби персоналу |
Реорганізувати роботу команди розробників так, щоб обов'язки і робота членів команди перекривали один одного, внаслідок цього розробники знатимуть і розумітимуть завдання, що виконуються іншими співробітниками |
Дефектні системні компоненти |
Замінити потенційно дефектні системні компоненти купувальними компонентами, що гарантують якість роботи |
Зміни вимог |
Спробувати визначити вимоги, найймовірніше схильні до змін; у структурі системи не відображати детальну інформацію |
Реорганізація компанії-розробника |
Підготувати короткий документ для керівництва компанії, що показує важливість даного проекту для досягнення фінансових цілей компанії |
Недостатня продуктивність бази даних |
Розглянути можливість покупки продуктивнішої бази даних |
Недооцінки часу виконання проекту |
Розглянути питання про покупку системних компонентів, досліджувати можливість використання генератора програмної коди |
Існує три категорії стратегій управління ризиками.
1. Стратегії запобігання рискам. Згідно цим стратегіям слід проводити заходи, що знижують вірогідність прояву ризиків. Прикладом може служити стратегія виключення потенційно дефектних компонентів, описана в табл. 7.
2. Стратегії мінімізацій. Направлені на зменшення можливого збитку від ризиків. Прикладом служить стратегія зменшення збитку від хвороби членів команди розробників (див. табл. 7).
3. Планування "аварійних" ситуацій. Згідно цим стратегіям необхідно мати план заходів, які слід виконати у разі прояву ризикової ситуації. У табл. 7 це стратегія поведінки при виникненні фінансових проблем у організації-розробника.
Моніторинг ризиків
Моніторинг ризиків полягає в регулярному перерахунку вірогідності ризиків і збитку, який вони можуть нанести. Для цього необхідно постійно відстежувати чинники, які впливають на вірогідність ризиків і можливий збиток. Ці чинники залежать від типів ризику. У табл. 8 приведені ознаки, які допомагають визначити тип ризику.
Таблиця 9.8 - Ознаки ризиків (приклад не копіювати)
Тип риска |
Признаки |
Технологічні ризики |
Затримки в постачанні устаткування або програмних засобів підтримки процесу створення ПО, численні документовані технологічні проблеми |
Ризики, пов'язані з персоналом |
Низький моральний стан персоналу, натягнуті відносини між членами команди розробників, низька якість виконаної роботи |
Організаційні ризики |
Розмови серед персоналу про пасивність і недостатню компетентність вищого керівництва організації |
Інструментальні ризики |
Небажання розробників використовувати програмні засоби підтримки, несхвальні відгуки про CASE-средствах, запити на могутніші інструментальні засоби |
Ризики, пов'язані з системними вимогами |
Необхідність перегляду багатьох системних вимог, незадоволеність замовника ПО |
Ризики оцінювання |
Зміни графіка робіт, численні звіти про порушення графіка робіт |
Моніторинг ризиків повинен бути безперервним процесом, що відстежує хід виконання заходів щодо управління ризиками, при цьому кожен основний ризик повинен розглядатися окремо.