Питання на модульний контроль №1 з дисципліни “Менеджмент проектів ПЗ”

ТУРКО

1. Програмне забезпечення для управління проектами Microsoft Project.

2. Програмне забезпечення для управління проектами Oracle Primavera.

3. Програмне забезпечення для управління проектами Spider Project.

4. Наведіть програмне забезпечення для управління проектами і дайте опис деякого з них.

5. Суть методу мережевого планування проектів.

6. Структурне планування.

7. Що таке критичний шлях. Зобразіть його графічно на графі.

ВАСИЛЬКОВ

8. Суть прямого проходу при плануванні проекту.

9. Суть зворотного проходу при плануванні проекту.

10. Ролі в колективі розробників.

11. Функціональна роль Замовника (Customer) в колективі розробників.

12. Функціональна роль Планувальника ресурсів (Planner) в колективі розробників.

13. Функціональна роль Менеджера проекту (Project Manager) в колективі розробників.

14. Функціональна роль керівника команди (Team Leader) в колективі розробників.

ГОС

15. Функціональна роль архітектора (Architect) в колективі розробників.

16. Функціональна роль проектувальника підсистеми (Designer) в колективі розробникі

17. Функціональна роль експерта предметної області (Domain Expert) в колективі розробників.

18. Функціональна роль розробника (Developer) в колективі розробників.

19. Функціональна роль розробника інформаційної підтримки (Information Developer) в колективі розробників.

20. Функціональна роль спеціаліста по користувацькому інтерфейсу (Human Factors Engineer) в колективі розробників.

21. Функціональна роль тестувальника (Tester) в колективі розробників.

Я

22. Функціональна роль біблотекаря (Librarian) в колективі розробників.

Для цілеспрямованого виконання проекту працівниками має бути виконаний ряд

робіт, різних як по своєму призначенню, так і по кваліфікаційних вимогах, що

пред'являються до розробників. Іншими словами, в ході розвитку проекту командою

розробників виконуються ті або інші функції. Розподіл функцій між виконавцями є нічим

іншим як розподілом ролей в команді, що виконує проект.

Зрозуміло, що значущість ролей розробників і тих, хто з ними пов'язаний,

розрізняється залежно від того, який проект виконує команда програміста. Проте, можна

вказати на ряд найбільш типових ролей, ігнорування яких приводить кращому випадку до

втрат продуктивності праці команди в цілому, а в найгіршому - до краху проекту. Як досить

повний перелік ролей можна вказати на наступний список, запропонований в рамках підходу

Центру об'єктно-орієнтованої технології фірми IBM :

Бібліотекар (Librarian) - відповідає за створення і ведення загальної бібліотеки

проекту, яка містить усі проектні робочі продукти. Він також відповідає за

відповідність робочих продуктів стандартам.

23. Життєвий цикл програмного продукту.

24. Життєвий цикл в об’єктно-орієнтованому проектуванні.

25. Заявка на проект.

26. Уточнення замовлення на проект.

27. Класифікація замовлень з точки зору документу “Заявка на проект”.

28. Функції менеджменту.

БАЗАР

29. Наведіть схеми організації менеджменту проектів.

30. Функції, які виконуються розробниками програмного проекту.

31. Рольові кластери моделі проектної групи MSF.

32. Принципи, які визначають регламент суміщення ролей.

33. Суміщення ролей.

34. Ключові ролі колективу розробників.

35. Ситуації, в яких діє менеджер при відборі кадрів.

ДУДА

36. Вирішення задач визначення кадрових ресурсів проекту.

37. Цілі розробки проірамного забезпечення.

38. Поняття діяльності в менеджменті програмних проектів.

39. Задачі менеджменту програмних проектів.

40. Модель Гантера.

41. Моделі життєвого циклу програмного забезпечення.

42. Класична ітераційна модель.

КОСЯК

43. Каскадна модель.

44. Модель фази - функції.

45. Об'єктио-орієнтовані моделі життєвого циклу.

46. Передпроектна діяльність менеджера і початок фази дослідження.

47. Підтримка репутації компанії і менеджера.

48. Підготовка і початок проекту.

49. Загальна характеристика підготовчих робіт.

МАЗУР

50. Визначення технічних ресурсів.

51. Визначення кадрових ресурсів.

52. Стратегії розподілу часу.

53. Календарні плани.

54. Мережеве планування.

55. Визначення фінансових ресурсів.

56. Фінансові потреби проекту.

57. Розподіл фінансових ресурсів.

ОКСАНА

58. Оцінка ймовірних прибутків від реалізації проекту.

59. Концепції розвитку проекту.

60. Загальні принципи і положення.

61. Спеціальні принципи і положення.

62. Переваги розподілу принципів.

63. Планування релізів.

64. Управління ризиками.

ПОНЧИК

65. Управління якістю проекту.

66. Додаткова інформація про підхід до розробки.

67. Тестування.

68. Вимірювання.

69. Зв'язки проекту.

70. Планування повторного використання програмних компонентів.

71. Самоорганізація діяльності менеджера.

ЩЕРБА

72. Початок проекту.

Початок проекту - це фази дослідження та аналізу здійсненності проекту. Вони

розмежовуються, насамперед, у зв'язку з тим, що при їх виконанні ставляться різні цілі,для досягнення якихзалучаються різні ресурси.

У фазі дослідження увага фокусується на розумінні призначення проекту.

Виконувана на цій фазі робота полягає вплануванні та координації, необхідних для

підготовки вимог для керівництва. Вимоги формулюються в такому вигляді, в якому вонидоступні для загальної оцінки проекту та стратегії виконання замовлення. Зокрема,визначається, чи повинен проект бути послідовним або ітеративно нарощуємо, доцільначидля нього комбінація цих підходів. У той же час, вже ця далеко не точне формулюваннявимог повинна давати уявлення про основні моменти проектованого вироби, щодозволяють намітити план для фази конструювання.

Фаза аналізу здійсненності - це робота, пов'язана з прийняттям загальних

проектних рішень, зокрема, із затвердженням вимог.

73. Перехід від попереднього аналізу до першої ітерації.

В цій темі задачі менеджменту обговорюються в контексті робіт, які повинні

завершувати попередній аналіз і починати итеративное нарощування можливостей

програмного виробу. У традиційній послідовній схемі явно виділяється період, коли

аналіз закінчується і починається конструювання; повернення до аналізу - це виправленняпомилки (з усіма наслідками, що випливають з неї наслідками). В об'єктно-орієнтованоїсхемою аналіз ніколи не закінчується, він відновлюється щоразу після оцінки ітерації.Можна сказати, що оцінка ітерації є основою для аналізу наступної ітерації. Але дляпершої ітерації такої основи не існує. Звідси випливають особливості переходу від етапуаналізу до конструювання першій ітерації, пов'язані з тим, що це час, коли змінюєтьсяточка зору на ітерацію і на проектований виріб в цілому:

замість проблемно-орієнтованих об'єктів розглядаються реалізаційні об'єкти;

моделі рівня аналізу замінюються моделями, що представляють реалізаційну

декомпозицію системи;

деякі класи, що виникають в ході аналізу, зникають, з'являються класи, специфічні

для реалізаційної середовища (наприклад, специфицируются інтерфейсні класи

звернення до баз даних);

конкретизуються і уточнюються стратегії і методики, намічені для виконання тих

чи інших робіт.

74. Організація колективної роботи.

Численні методи організації праці колективу, пов'язаного загальною роботою надпрограмним проектом, можна поділити на три категорії:

схеми з поділом відповідальності;

деперсоніфікованих схеми;

змішані схеми.

75. Схеми з розподілом відповідальності.

Методи першої категорії припускають, що для членів колективу виділені сфери

відповідальності, які в сукупності охоплюютьвсі завдання проекту. Вони визначаються

відповідно до уточненими замовленням і попереднім планом робіт. Кожна зі сфер

включає завдання, тематично пов'язані з методом рішення (в якості рішень продукуютьсяоднотипні робочіпродукти), або завдання, що охоплюють розробку відособлених одиницьдекомпозиції (ітерація, програмний модуль та ін.).Часто при обговоренні організаціїколективної діяльності поняття сфери відповідальності замінюється більш змістовним дляпрограмного проекту розбивкою робіт: розробка програмного компонента, виконанняорганізаційної функції (по Гантер це планування, розробка, обслуговування, випускдокументації, випробування, підтримка та супровід).

Для реального проекту конкретизація розподілу обов'язків, відповідна

розбиття проектних робіт в колективі (з урахуванням можливого суміщення ролей) - одназ основних задач менеджера.

76. Схеми з розподілом відповідальності, орієнтовані на зменшення ризику проекту.

Схеми з розділенням відповідальності не припускають від відповідальних

виконавців знання завдань суміжних сфер відповідальності, тим більше методів їх

вирішення в даному проекті за винятком випадків, коли залежності між сферами цьоговимагають (наприклад, якщо результати рішення однієї задачі використовуються длявирішення інших завдань).Знання такого роду розглядаються як порушення проектногорозподілу праці. Зрозуміло, що, якщо слідувати схемі розподілу відповідальності вчистому вигляді, то ступінь ризику проекту зростає. Тому звичайною справою при такійорганізації колективної праці є заходи, спрямовані на зниження ризиків. Досить часто дляцього застосовується так званий перехресний контроль, коли відповідальні виконавцірізних сфер перевіряють рішення один одного, досить глибоко вникаючи в завданнякожної сфери. Популярний метод підвищення надійності схем поділу відповідальності -призначення двох керівних працівників, один з яких стає головним відповідальнимвиконавцем, а інший - дублюючим експертом.