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