Модель артефактів для управління проектом - програмні продукти

Ця модель була взята з реального проекту (його назва не буде згадуватися). Вона була створена з тієї причини, що через безліч процесів з RUP і процесів компанії виникала плутанина в наступних питаннях:

  • які саме результати потрібно отримати на виході,
  • хто відповідає за артефакт,
  • яка група повинна нести за нього відповідальність,
  • які кошти потрібно використовувати,
  • якими є стосунки між артефактами і елементами моделі,
  • чи використовується даний RUP-артефакт в цьому проекті,
  • на який ітерації даний артефакт створюється,
  • який рівень деталізації,
  • як слід пов'язати артефакти існуючого процесу з RUP-артефактів,
  • і т.д.

Ця інформація відноситься до проекту, в якому методологія RUP застосовувалася до більшості процесів, але не до всіх, оскільки були додаткові процеси, а процес "Аналіз та проектування" був пристосований до конкретного проекту. Це не остаточна модель RUP. Розглядайте її лише як ідею моделі, яка може бути створена для вашого проекту.

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

Перша наша проблема полягала в тому, що поки йшло планування, інші співробітники не могли приступити до роботи над артефактами, але ця проблема не пов'язана з даним тут рішенням, вона характерна лише для деяких проектів. Це вимагає окремого обговорення.

Були й інші проблеми, наприклад, деякі не розуміли набір інструментів, де повинен знаходитися той чи інший артефакт, де його слід шукати і т. Д.

Була також плутанина в тому, хто повинен відповідати за артефакти, за їх створення, за дотримання термінів і т. Д. До кого звертатися, якщо щось знадобиться виправити або поліпшити і т. П.

Існувала також серйозна проблема з жаргонними назвами артефактів, які придумувалися незважаючи на те, що артефакти в RUP вже мають назви.

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

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

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

Очевидно, при наявності стандартної моделі RUP, конкретний проект можна набагато швидше підігнати під стандарт RUP. Для малих проектів модель, ймовірно, взагалі не потрібна. Вирішення цього питання також залежить від того, наскільки добре проектна група знайома з RUP.

Файли для завантаження