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