Студопедия
Новини освіти і науки:
МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах


РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання


ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ"


ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ


Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків


Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні


Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах


Гендерна антидискримінаційна експертиза може зробити нас моральними рабами


ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ


ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· діаграма дій (наприклад, 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. Управління ризиком

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

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

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

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

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

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

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

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


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

  1. Active-HDL як сучасна система автоматизованого проектування ВІС.
  2. VII. Етап проектування
  3. VII. Етап проектування
  4. Абстрактна модель оптимального планування виробництва
  5. Автоматизація проектування напівзамовлених ВІС.
  6. Алгоритм планування податкових платежів. Вибір оптимального варіанту оподаткування та сплати податків.
  7. Аналіз комерційної здійснимості (спроможності) проекту
  8. Аналіз та планування витрат організації на професійне навчання персоналу
  9. Аналіз чутливості інвестиційного проекту
  10. Аудит проекту розробки ПЗ
  11. Бар’єри стратегічного планування та заходи щодо їх подолання
  12. БІЗНЕС-ПЛАН ІНВЕСТИЦІЙНОГО ПРОЕКТУ




Переглядів: 584

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

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

  

© studopedia.com.ua При використанні або копіюванні матеріалів пряме посилання на сайт обов'язкове.


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