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