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