- •Питання на модульний контроль №1 з дисципліни “Менеджмент проектів пз”
- •3. Spider Project (Спайдер Проджект) — пакет з управління проектами, спроектований та розроблений російським розробником компанією «Спайдер Проджект» Технічні характеристики Spider Project
- •1.1. Технические характеристики
- •1.Рис.1. Ресурсный критический путь
- •Васильков
- •Суть прямого проходу при плануванні проекту.
- •Суть зворотного проходу при плануванні проекту.
- •Ролі в колективі розробників.
- •Життєвий цикл програмного продукту.
- •Уточнення замовлення на проект.
- •Функції менеджменту.
- •Наведіть схеми організації менеджменту проектів.
- •Функції, які виконуються розробниками програмного проекту.
- •Рольові кластери моделі проектної групи msf.
- •Принципи, які визначають регламент суміщення ролей.
- •Суміщення ролей.
- •Ключові ролі колективу розробників.
- •Ситуації, в яких діє менеджер при відборі кадрів.
- •Вирішення задач визначення кадрових ресурсів проекту.
- •Цілі розробки проірамного забезпечення.
- •Поняття діяльності в менеджменті програмних проектів.
- •Задачі менеджменту програмних проектів.
- •Модель Гантера.
- •Моделі життєвого циклу програмного забезпечення.
- •Класична ітераційна модель.
- •Каскадна модель.
- •Модель фази - функції.
- •Об'єктио-орієнтовані моделі життєвого циклу.
- •Передпроектна діяльність менеджера і початок фази дослідження.
- •Підтримка репутації компанії і менеджера.
- •Підготовка і початок проекту.
- •Загальна характеристика підготовчих робіт.
- •Визначення технічних ресурсів.
- •Визначення кадрових ресурсів.
- •Стратегії розподілу часу.
- •Календарні плани.
- •Мережеве планування.
- •Визначення фінансових ресурсів.
- •Фінансові потреби проекту.
- •Розподіл фінансових ресурсів.
- •Оцінка ймовірних прибутків від реалізації проекту.
- •Концепції розвитку проекту.
- •Загальні принципи і положення.
- •Спеціальні принципи і положення.
- •Переваги розподілу принципів.
- •Планування релізів.
- •Управління якістю проекту.
- •Додаткова інформація про підхід до розробки.
- •Тестування.
- •Вимірювання.
- •Зв'язки проекту.
- •Планування повторного використання програмних компонентів.
- •Самоорганізація діяльності менеджера.
- •Початок проекту.
- •Перехід від попереднього аналізу до першої ітерації.
- •Організація колективної роботи.
- •Схеми з розподілом відповідальності.
- •Схеми з розподілом відповідальності, орієнтовані на зменшення ризику проекту.
- •Деперсоніфікована схема.
- •Змішані схеми і планування організації колективної роботи.
- •Локальні взаємодії в колективі і ухвалення рішень.
- •Принципи контактних заходів.
- •Непланові взаємини в колективі.
- •Перша ітерація: метод "Спочатку в глибину".
- •Мотивація особливого підходу до виконання першої ітерації.
- •Етап і: початкове моделювання.
- •Етап II: моделювання рівня об'єктно-орієнтованого конструювання.
- •Головатий
- •Етап III: швидке програмування.
- •Етап IV : ітеративне нарощування можливостей.
- •Етап VI: програмування і зборка першої ітерації.
- •Етап VII: оцінка ітерації.
- •Людкевич
- •Особливості планування і управління.
- •Взаємини із замовником, листування.
- •Приймання робочих продуктів.
- •Управління проектом після виконання першої ітерації.
- •Аналіз вимог.
Фінансові потреби проекту.
При визначенні фінансових потреб показники, що задаються в ході з'ясування
технічних і кадрових ресурсів, переводяться в грошове вираження. Для кожного з таких
показників повинні бути відомі нормативи перекладу. Це або стандартизовані (зовнішні й
внутрішнфірмові) коефіцієнти, або просто ціни використовуваних у проекті товарів і
послуг. Якщо за якимись причинами точних нормативів перекладу ні, то замість них застосовуються експертні оцінки. Наприклад, при запрошенні для участі в проекті деякого фахівця може виявитися, що вимоги його заробітної плати не відповідають
кваліфікаційній сітці ставок, прийнятої в компанії. Для такого співробітника доводиться вводити індивідуальний норматив перекладу погодинної зайнятості в грошове вираження.
Ціни на товари й послуги також можуть варіюватися. У цьому зв'язку
використання їх як нормативів перекладу означає не точне визначення фінансових потреб,
пов'язаних із придбанням даного товару або з одержанням послуги, а вказівка нижньої й
верхньої границь необхідних коштів. У практиці оцінки фінансових ресурсів для
програмних проектів застосовуються розрахунки наступних видів:
• по мінімальній границі цін,
• по максимальній границі цін,
• по середній величині між максимальною й мінімальною ціною або
• по середньозваженій величині.
Останній варіант використовується для більш точного обчислення, коли вдається
оцінити розподіл імовірності придбання товару або послуги залежно від рівня цін.
Становлячи мінімальну й раціональну схеми розподілу потреб, не слід уважатися,
що в мінімальній схемі витратні характеристики обов'язково повинні будуватися виходячи
з мінімальних цін (хоча й це можливо). Поняття мінімальної схеми відбиває, насамперед,
результативний аспект розгляду замовлення, тобто те, які мінімально необхідні результати
передбачається одержати, а з фінансовими витратами воно зв'язане вже в другу чергу.
Корисно для мінімальної й для раціональної схем визначати як верхню, так і нижню границі фінансових потреб проекту. При використанні цін, як нормативів, не можна плутати варіантність вартості однорідної продукції в різних продавців і ситуації, коли рівень ціни відбиває рівень якість товару або послуги. Приміром, більш досконале обчислювальне встаткування робить поставку дорожче, чим при використанні побутових аналогів, програмна система може працювати як у полегшеної, так і в повній конфігурації встаткування. Усі подібні якісні варіації проекту слід відзначати в документах, відбиваючи їх вплив на обсяг і якість результатів, на строки розробки.
Фінансові потреби проекту розраховуються по-різному для короткострокових і
довгострокових проектів. Це пов'язане з тим, що для тривалих проектів починає
відігравати роль інфляційний фактор, і, як наслідок, доводиться враховувати
дисконтіювання. Іншими словами, обговорюючи проектні розв'язки, необхідно оперувати
інформацією, вираженої в порівнянних цінах.
Приведення пізніх витрат до цін початкового періоду розвитку проекту
здійснюється шляхом уведення поправочного коефіцієнта дисконтіювання:
Дt = (1 + б)t,
де б – дисконт (число з інтервалу 0…1),
t – час платежу, що вказується від початку проекту.
Цей коефіцієнт показує, що сьогоднішня покупка товару за p одиниць еквівалентна
покупці його за (1 + б)t
* p через t років за умови збереження сьогоднішніх грошей у банку з банківським відсотком б протягом t років. Приблизно в такому співвідношенні й відбуваються інфляційні процеси. Величина коефіцієнта дисконтіювання залежить від економічної ситуації, а не умов висновку контракту. Зокрема, із цієї причини неможливо точно сказати, які строки проекту характеризують його як тривалий.
Визначаючи фінансові потреби проекту, треба чітко розмежовувати ситуації, коли
документ пред'являється замовникові й коли він залишається у внутрішнфірмовому
документообігу. Як вказувалося вище, усі зовнішні документи повинні проходити через бухгалтерський контроль, у ході якого вони можуть перетерпіти зміни.
