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