Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Планування проекту

Інтерфейс проекту

Менеджер по проектах повинен визначити групи (інтерфейс проекту), які можуть мати відношення до проекту: вони можуть бути внутрішніми або зовнішніми групами.

Існують наступні групи:

· ініціатори проекту,

· кінцеві користувачі,

· постачальники,

· субпідрядники,

· головні виробники,

· виробники субпродуктів.

Зовнішні визначення інтерфейсу повинні брати до уваги:

· перевірка порту інтерфейсу,

· інтерфейс повинен мати мінімальну кількість проміжних зв'язків,

· інтерфейс повинен мати не більше семи зовнішніх зв'язків.

Не залежно від розміру проекту, хороше планування є дуже важливим. Основними діями в плануванні є:

· визначення продукту,

· визначення дій,

· оцінка ресурсів і часу,

· діаграма дій (наприклад, PERT),

· розробка плану робіт і оцінка вартості.

План потрібно розробити для всіх фаз. Іноді потрібно зробити повторне планування для того, щоб отримати більш оптимальний план. Завдання іноді виконуються повторно, тому це повинно бути включено в план. Далі слідують початкові дані при розробці плану:

· документ вимог користувача (URD, user requirements document),

· документ вимог до ПЗ (SRD, software requirements document),

· документ архітектурного проектування (ARD, architectural design document),

· продукт і стандарти процесу,

· дані з минулих проектів для оцінки ресурсних і тимчасових витрат,

· оцінка витрат на постачання,

· дані про чинники ризику,

· опис технологічного середовища,

· дані про тимчасові обмеження,

· дані про ресурсні обмеження.

План управління проектом розробки ПЗ повинен мати:

· опис продукту (характеристики, мова опису, мова програмування),

· модель процесів, які будуть використані в життєвому циклі ПЗ, інструментів, методів, вводу/виводу всіх дій, типи моделіей (каскадна, еволюційна).

· структура роботи у формі ієрархії функцій,

· організація проекту,

· діаграма дій,

· графік робіт проекту,

· список ресурсів,

· оцінки проекту.

Зміст плану управління проектом розробки ПЗ

Спрощена форма структури плану управління проектом розробки ПЗ зображена нижче.

Структура заснована на ANSI/IEEE Std 1058.1-1987 Рекомендований вигляд специфікації вимог до ПЗ.

Організаційна інформація

Короткий звіт (не більше 200 слів) Зміст Статус документа (автори, заголовки, сигнатура і т.д.) Зміни після останньої версії

Тіло документа

1. Вступ (короткий опис, еволюція плану, визначення, акроніми, посилання). 2. Організація проекту (модель процесу, структура організації, обмеження, інтефейс). 3. Управління (завдання, припущення, взаємозв'язки, обмеження, управління ризиком, моніторинг, персональний план). 4. Технологія (інструменти, методи, техніка, документація, підтримувані функції). 5. Робочі пакети, розклади роботи, бюджет. 6. Доповнення: інший матеріал.

Оцінка ресурсів і часу

Оцінки ресурсів і часу містять в собі визначення ресурсів, список персоналу, ролі робітників у проекті, взаємозв'язку між ними. Для оцінки робочого навантаження застосовується метод конструктивної вартісної моделі або балової функціональної оцінки. Для оцінки значення інших чинників слід прийняти до уваги наступне:

· комерційний продукт входить в кінцевий продукт,

· комерційна продукція використовується для виробництва,

· внутрішні протоколи,

· зовнішні послуги,

· подорожі і професійні поїздки,

· доставку,

· страховку.

Технічне управління проектом

Менеджер по проектах повинен розуміти технологію і бути відповідальним за головні технічні рішення:

· методи і інструменти,

· стандарти проекту і написання коду,

· логічна модель,

· вимоги до ПЗ,

· фізична модель,

· архітектурна модель,

· вибір розробки,

· управління конфігурацією,

· перевірка і затвердження,

· гарантія якості.

У продуктах середнього і великого розміру менеджер по проектах повинен направляти деякі із завдань супервізорам команд.

13. Управління ризиком

Ризик - це вірогідність невдачі. У всіх проектах існує ризик. Чинники ризику повинні бути визначені і відстежені.

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

Менеджер управління ризиком повинен поставити собі питання: "що може піти не так", забувши про "все буде так, як повинно бути".

Найважливішими чинниками рзику є:

Чинники досвіду: нестача досвіду в управлінні проектом, в команді, відсутність перевірки кваліфікації членів команди, недолік стандартів.

Чинники планування: помилки оцінки часу, ресурсів, ціни, вандалізм, саботаж, незручні умови зв'язку, неправильний розподіл відповідальності, часті кадрові зміни.

Технологічні чинники: нова технологія, незрілість, помилково застосовані методи, необхідний досвід для застосування нових методів, низька якість використання комерційного продукту.

Зовнішні чинники: низька якість нестабільних або погано визначених вимог користувача, неправильний доступ зовнішніх систем.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Структура команди	\|	Матриця ризику

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.