Характеристики моделі процесів MSF



 

Трьома особливостями моделі процесів MSF є:

 

• Підхід, заснований на фазах і віхах.

 

• Ітеративний підхід.

 

• Інтегрований підхід до створення і впровадження рішень.

 

Підхід, заснований на віхах

 

Характеристики підходу, заснованого на віхах

 

Займаючи центральне місце в методології MSF, віхи використовуються як опорні точки для планування і моніторингу ходу проекту.

 

Головні і проміжні віхи

 

MSF вводить два типи віх: головні (major) і проміжні (interim). Вони мають наступні особливості:

 

• Головні віхи служать точками переходу від однієї фази до іншої. Вони також визначають зміни в поточних завданнях ролевих кластерів.

 

• У MSF використовуються узагальнені головні віхи, більшість з яких може застосовуватись у будь-якого типу IT - проектах.

 

• Проміжні віхи показують досягнення в ході проекту певного прогресу і розчленовують великі сегменти роботи на менші, осяжні ділянки.

 

• Проміжні віхи можуть варіюватися від проекту до проекту. MSF рекомендує використовувати певний набір проміжних віх, але на практиці проектна група може сама встановлювати їх відповідно до особливостей своєї роботи.

 

Віхи як точки синхронізації

 

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

 

54


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

 

Віхи як орієнтири виробничої відповідальності

 

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

 

Провідні ролі різних фаз

 

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

 

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

 

Віха Провідні ролеві кластери
Концепція затверджена Управління продуктом
   
Плани проекту затверджені Управління програмою
   
Розробка завершена Розробка, Задоволення споживача
   
Готовність рішення затверджена Тестування, Управління випуском
   
Впровадження завершене Управління випуском
   

 

Аналіз пройдених віх

 

Кожна головна віха надає можливість осмислити і витягувати уроки з фази, що тільки що завершилася. Аналіз пройдених віх під час спеціальних зборів (post-milestone reviews), що проводяться, допомагає підвищити віддачу від такого осмислення. MSF окремо розглядає збори, на яких результати фази обговорюються разом із замовником і іншими зацікавленими сторонами (milestone reviews), і подальше лікування уроків усередині колективу (post-milestone reviews). Остаточні збори такого роду проводяться вже після завершення проекту. У деяких організаціях вони носять назву постмортемів (postmortems).

 

Ітеративний підхід

 

Характеристики ітеративного підходу

 

Ітеративний підхід до процесу розробки широко використовується в MSF. Програмний код, документація, дизайн, плани і інші робочі матеріали створюються, як правило, ітеративними методами.

 

Випуск версій

 

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

 

55


для одного вирішення ряду версій. Рис. 7 показує, як із створенням нових версій еволюціонує функціональність рішення.

Версії рішення не обов'язково слідують одна за одною. Зрілі програмні продукти зазвичай розвиваються по декількох напрямах паралельно. Тимчасові інтервали між випусками версій залежать як від розміру і типу проекту, так і від потреб і стратегії замовника.

 

Рисунок 11. Версіонуванння

 

Створення "живої" документації

 

Ітеративний підхід до процесу розробки вимагає використання гнучкого способу ведення документації. "Живі" документи (living documents) повинні змінюватися у міру еволюції проекту. Такий підхід істотно відрізняється від принципів ведення документації в каскадній моделі, де процес розробки починається лише після того, як готові і зафіксовані всі вимоги і специфікації.

 

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

 

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

 


Дата добавления: 2018-05-09; просмотров: 288; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!